LedgerSMB is a fork of SQLLedger:



Note from Developers

LedgerSMB is very much in transition and will be for a number of years. We are unhappy with the old financial framework (messy code, SQL assembled as strings, HTML printed to STDOUT) and are trying to move to a more modern/postmodern architecture which uses stored procedures as named queries, supports applications written in many languages, and the like. What we are shooting for is an accounting engine written in SQL which can be automated by applications written in whatever languages folks want to use. This ideal is still many years out, but we do have an application which is working today and can be customized with some patience and effort.

Also clarifications as requested:

We chose Moose over other object frameworks in Perl because it offers a heavily declarative object system along with a very rich set of property constraints. We use this extensively. However it does have a startup cost, which is why, in 1.4, FCGI will be the preferred way to run the software. Moose is an extremely powerful object system which borrows many ideas from CLOS.

Dojo is a Javascript framework for dynamic web applications. It handles everything from tabular-like layout to complex controls, like date selections with popup calendars.


Evaluation of Reporting UseCases

Evaluation of Reporting UseCases for Fund Accounting

Can each of these reports be generated, confined to a specific temporarily restricted asset type?

Developer's note: I am not sure I understand the requirements of reporting temporarily and permanently restricted funds well enough to give a definite answer. I think one could do this with a reporting dimension (like we use for projects and funds) in 1.4 (currently in beta, with the dimensions having a beta-quality backport for 1.3). However for reporting purposes, this would currently hit the trial balance, chart of accounts, income, and expense reporting capabilities. I would need to understand the use cases of temporarily restricted assets in reconciliation reports in this case before implementing such a feature, and the income and expense reporting is currently geared to for-profit businesses. In both 1.3 and 1.4 it would be trivial to implement separate income and expense reporting rather than the income statement form that we have now but since the reporting has been replaced, it would be double the (small amount of) work to support both versions.

Note that for 1.4 and the backport, reporting dimension units can be limited by dates, so any needed functionality could bootstrap on that.

Evaluation of Fund Accounting UseCases

Collaborating evaluation

Evaluation of Double-entry Accounting UseCases

Evaluation of TrackingDocumentation UseCases

Evaluation of Handling multiple currencies UseCases

Evaluation of draft transaction UseCases

Evaluation of WorkFlow UseCases

Evaluation of the Reading and Reporting API

(Developer's evaluation here).

Reporting in LedgerSMB 1.3 is done by basically programming in new reports. I would not recommend going that way for new deployments since we have a backport of the 1.4 reporting engine which is stable and tested. With this add-on basically, to create a new tabular report you have to create the following things at a minimum (particularly complex reports may require more):

  1. A Template Toolkit template for the criteria for the report to run.
  2. A workflow script for handling the request (this is trivial Perl code and I have examples on my blog). Basically all this does is map a given target to a report (in 3 lines of code, typically).
  3. A PL/PGSQL or SQL user defined function to turn those inputs into report data, and
  4. A largely declarative Perl module which describes the report's inputs and outputs, and optionally preprocesses some of it.

Now, if you want to access the report from a thick client, you have a little more work to do but not too much. This does require a programmer to do, but the primary skill required is SQL, and an ability to copy/paste Perl and modify based on documentation is sufficient there.

Evaluation of the Storage API

(Developer's review here) Currently in 1.3 and 1.4, most transactions do not have ready to use db-level storage APIs and the ones inherited from SQL-Leger are a pain to work with from an external application perspective. I would not recommend going through our old code here to post things although it can be done. There are working invoice (for defined goods/services) classes using new code for invoices, but they are not part of the main project. They are, however, maintained by the project and therefore expected to continue to be usable for 1.3 and 1.4. For simple amount entries there are currently no good classes available but these could be written in an afternoon (and I would be happy to contribute that work to be honest). I would expect that such classes would be the basis for whatever we do in 1.5 in this area.

Evaluation of the Community Health

(Self-evaluation here, by developer in community)

Caveats and further notes by developer:

[1] We have payment and receipt searching functions done but no report built on them in the new code. There is an old code report inherited from SQL-Ledger. However, we only replaced it in the 1.4 beta.

[2] It should be trivial to put together two different variants of the income statement report for this.

[3] Currently everything is done in a master currency and everything except journal entries assumes a single conversion rate per direction for a day (i.e. one buy and one sell rate for each currency). Allowing multiple conversion rates for the day would be a significant amount of work, but the key issue would be one of testing and making sure that everywhere that expected the single rate conversion was moved over. This is not a trivial amount of work but it isn't tremendous either. It would benefit from significant collaboration with the current developers though. This is something we plan on tackling though in 1.5 (allowing for per-transaction conversion rates). Also floating values in a foreign currency (for example having a bank account in a currency that is not one's book currency) is more work in terms of reporting fx gains and losses than we would like at the moment.

If you go with LedgerSMB, my recommendation would be to start working with the 1.4 beta. There are likely to be additional bugs you will run into but: 1. You can define additional reporting dimensions (like restricted asset groups, or funds). 2. Reporting is a lot easier. I can write 2 or so moderately complex reports in a day on the current framework. 3. More consistency with the 4-eyes principle and unapproved transactions. 4. Better code for use in other environments in many cases. Also have proof of concept invoicing code for thick clients for both 1.3 and 1.4.

This being said the old code that we inherited is painful to work with. To the extent it must be modified it's good to work with others and we in the community can help. We do hope to have all the financial code on the new framework by 1.5.

Finally I am not very happy with the design of the financial portions of the database. These were largely inherited from SQL-Ledger and we have not re-engineered them yet because we wanted to get the framework up to snuff first. We have the worst of the issues under control but the db is needlessly complex here and will likely be simplified to some extent in the future.

Finally for any additional modules, we'd recommend using PGObject::Simple::Role as a database interface if using Perl. If you want to use a different language we'd be happy to work with you to help create a db adaptor in your language of choice (we currently have them for Perl and PHP, but hope to have them in a number of different languages soon including Java, Python, and Ruby). I have a proof of concept point of sale that uses PGObject::Simple::Role and that module is quite a bit more full-featured than our existing database routines (it is BSD-licensed btw). There is no question we will be moving to that interface for 1.5.