We are still pushing for LedgerSMB 1.4, beta 1 by the end of the month. We have a lot of work to do to get there but are closing the gap fast. I will put out a longer post at that time with a list of all of the improvements we have made, but for now I want to highlight only a few.
First, we have ditched tablefunc and gone to WITH RECURSIVE common table expressions, which means we now will require PostgreSQL 8.4 and higher. Readers will recall a previous post discussing this in greater detail as well as the benefits we have seen.
One area I am particularly excited by is the new reporting framework. This allows one to quickly and easily turn a stored procedure into a report using a common set of interface components. Reports support subtotals on various criteria, ordering of results by users clicking columns, and more. Most code for specific reports is boilerplate code. Our main modules do most of the work. Some reports like the income statement will have to override this and supply their own interface components, but this is relatively rare.
Reports can be exported to CSV, ODS, and PDF files and contain identifying information so that one does not get confused as to where a report came from. A future post will look inside our reporting engine.
Additionally files can be attached to persons and companies, which means that this goes for customers, vendors, employees, leads, etc. This brings full-fledged CRM a step closer. The files are stored in the database as bytea types.
The final feature I want to mention here is that projects and departments are being replaced by a system of reporting dimensions. These reporting dimensions can be nested, so projects can now contain other projects, and departments can contain other departments. Funds etc can be added by configuring the application rather than by customization.
This feature makes heavy use of common table expressions. We can now check for business reporting units and descendants within a report. This allows us to do more flexible reporting than we would be able to do without many of the features found first in PostgreSQL 8.4.