[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Towards a LedgerNPO

Hi Josh;

1.2 will make this far easier for you.  I will also add the skeleton
of an en_NPO translation so that people more knowledgable in the
terminology can add necessary translations.

New features which will make this possible in 1.2 include:
1)  A standard way of extending the database schema so that
industry-specific modifications will be forward-maintainable.
2)  A simpler customization system for forward-maintainable changes.

This way we can make something work specifically for SPI without
touching the main core code.  More comments inline:

On 9/25/06, Josh Berkus <..hidden..> wrote:
Chris^2, all:

We're proceeding with LedgerSMB 1.1 as the accounting system for Software
In The Public Interest, Inc.  JD has already set up a hosted instance for

However, LedgerSMB is of course set up for a retail, delivery or shipping
business rather than a non-profit.  I'd like to do the following:

1) Identify which NPO transactions correspond with which SMB transactions;

See below

2) Re-theme LedgerSMB to re-label the interfaces and forms to correspond to
NPO language;

The translation engine can take care of that :-)   I will add the
translation to the catalog.

3) Where necessary, adjust the LedgerSMB code to support both NPO and SMB
transactions on the same code base.

1.2 adds better support for custom database fields, and these will be
supported (minimally) on all orders, quotations, and invoices.  Other
modules may be supported as well through a few API calls.

The idea would be to eventually have an "LedgerNPO" which would be the same
as LedgerSMB except theme differences.  Not only does SPI need it, but I
think we'd see a lot of uptake and participation from non-profits,
especially OSS non-profits.  Currently, there is nothing like this in OSS

Right.  I am very interested in making this happen.

Requirements Draft

Donors:  Customers

Designations: a specific goal which donated funds must be used towards
(e.g. Debian Conference, PostgreSQL Development). Generally implemented by
creating an obligation towards a chart of accounts entry.  Could be
associated with a "product"; I'm not sure what works.

Parts could be used, but it would be better to see these as "services"
which are bought and sold.  You can handle markup automatically this
way by using a sell price of $1.00 and a purchase price of $0.95 for

        Designations also need to be associatable with Users in some fashion, so
that specific Users can run reports only on specific Designations.

That will require some custom database extensions.  May require some
additional generic API's to be created.

Transaction Types

Pledges: Pledges are are agreements to make a donation at some later date.
They have an associated Donor and Designation, but might or might not have
Payment Method or Transaction Fees.

From our earlier discussions, I would associate pledges with sales orders.

Donations:  Money actually received.  Has a Donor, Designation, Payment
Method and Transaction Fees.  Equivalent to a GL post?  I'm not sure.  One
change from standard SMB is that transaction fees, such as credit card
fees, must be assessed at the time of Donation because they will often
reduce the amount assigned to the Designation rather than coming out of a
central fund.

I would associate donations with sales invoices.

Expenses:  All outgoing checks.  Each should be associated with a

Vendor invoices.

Transfers:  between bank accounts, and between Designations.

Transfers between accounts is already handled.  Designations might
require more work.  I would need to understand this requirement more.
Can you send me some useful scenarios?  I suspect we can make this
work with existing functionality, but I would want to make sure.

There are no other types of transactions for NPOs; thus types of
transactions which do not apply should be hidden.

Already supported in the application, though a few buttons may need to
be disabled.

SPI claims 5% off the top of any Designated funds Donated to be used for
General Overhead.  This should somehow be automatic.   Few other NPOs do
this, however.

Again, this could be handled by treating designations as services with
a purchase price that is $1.00 minus markup and a unit of USD or the
equivalent.  Again, this could be adapted to other currencies by
varying the unit, etc.

Best Wishes,
Chris Travers