* PHP integration classes working for areas of the software re-engineered since 1.3 (though may need some extension to reach all these areas)

## 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.

<a id="evaluation"></a>

## Evaluation

### Evaluation of [[Reporting|UseCases/GeneratingReports]] UseCases

- [[Trial Balance Report|UseCases/GeneratingReports#trial-balance]]: Yes

- [[Bank Reconciliation Report|UseCases/GeneratingReports#bank-reconcilation]]: Yes.  Also as of 1.3, past bank reconciliation reports can be retrieved and reviewed.

- [[Chart of Accounts|UseCases/GeneratingReports#chart-of-accounts]]: Yes

- [[Cash Disbursements Journal|UseCases/GeneratingReports#cash-disbursements]]: Partial, some work needed in 1.3.[1]  Fully supported in 1.4 beta.

- [[Income Report|UseCases/GeneratingReports#income-report]]: Partial, some work needed.[2]

- [[Expense Report|UseCases/GeneratingReports#expense-report]]: Partial, some work needed [2]

### Evaluation of [[Reporting|UseCases/GeneratingReports]] UseCases for Fund Accounting

Can each of these reports be generated, confined to a specific temporarily

restricted asset type?

- [[Trial Balance Report|UseCases/GeneratingReports#trial-balance]]: FIXME

- [[Bank Reconciliation Report|UseCases/GeneratingReports#bank-reconcilation]]: FIXME

- [[Chart of Accounts|UseCases/GeneratingReports#chart-of-accounts]]: FIXME

- [[Cash Disbursements Journal|UseCases/GeneratingReports#cash-disbursements]]: FIXME

- [[Income Report|UseCases/GeneratingReports#income-report]]: FIXME

- [[Expense Report|UseCases/GeneratingReports#expense-report]]: FIXME

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/FundAccounting]] UseCases

- [[Fund-only View|UseCases/FundAccounting#fund-view]]  As of 1.4, reporting dimensions can be used for funds, and these are supported for most reports (trial balance, income, expense, etc).

- [[Funds as part of whole org View|UseCases/FundAccounting#fundless-view]] Not sure about this one.  Right now one would have to run a single report for every relevant fund.

- [[Ignore Funds for operations|UseCases/FundAccounting#fundless-view]] Attaching a transaction to a fund (or project, or department, etc) is optional with the 1.4 code (or backport).

### [[UseCases/Collaborating]] evaluation

- [[Simultaneous Editing of Ledger|UseCases/Collaborating#simultaneous-ledger-edits]]: Do you mean simultaneous entry?  Yes, that is fully supported.  Do you mean simultaneous other operations (like entry and reconciliation)?  Yes.  However we try very hard to avoid editing existing entries.  This is hardly supported except in a few edge cases of non-approved transactions (which have not hit the books). 

### Evaluation of [[Double-entry Accounting|UseCases/DoubleEntryAccounting]] UseCases

- Does the system implement pure double-entry accounting?  Yes.

### Evaluation of [[TrackingDocumentation|UseCases/TrackingDocumentation]] UseCases

- Does the system [[link up to external documentation|UseCases/TrackingDocumentation#document-link-up]]?  Yes, for ledger transactions.  The software can store the documentation in the db if needed.   However, it also supports storing URL's to external documentation.  Obviously backup lifecycles for external documentation is separate.

- Does it have a [[the ability to explore transactions via documentation linkage|UseCases/TrackingDocumentation#document-link-explore]]?  No.  This would have to be added. 

### Evaluation of [[Handling multiple currencies|UseCases/MultiCurrency]] UseCases

- Does it support the concept of

  [[a single functional currency|UseCases/MultiCurrency]], while still

  permitting multi-currency entries?  Yes, with some limitations. [3]

### Evaluation of [[draft transaction|UseCases/DraftTransactions]] UseCases

- Does the system allow

  [[generally for draft transactions|UseCases/DraftTransactions#draft-general]]

  that can be later approved before officially being posted to the books? Yes.  Both individual draft transactions and batches of vouchers are supported as of 1.3 for all non-inventory transactions (for inventory transactions one can implement 4-eyes principles in other ways in 1.3, but 1.4 beta has drafts and vouchers for them as well and I could backport that if needed).

### Evaluation of WorkFlow UseCases

- Is a [[specific workflow dictated by the system|UseCases/WorkFlow#workflow-dictated]] ?  To some extent.

- Is a [[the workflow configurable|UseCases/WorkFlow#workflow-configurable]] ?  Not really.If a workflow is supported it can't really be restricted.  This would be a place for customization.

- [[Unaccrued Invoice|UseCases/WorkFlow#unaccrued-invioice]] ?  Not yet.  This is on our roadmap.  What we'd like to do is attach accrual periods to invoices so that adjusting can be done automatically in the course of reporting but this is probably not going to happen until 1.5 at the earliest.

### Evaluation of the [[Reading and Reporting API|UseCases/ReadingAPI]]

(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|UseCases/StorageAPI]]

(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|UseCases/CommunityHealth]]