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