Re: Draft: Requirements of Journal Entries, Batches, Vouchers, and Reports

Hi Chris,

On Thu, Sep 18, 2014 at 5:06 AM, Chris Travers <..hidden..> wrote:

For the first portion of the rewrite, I will focus on getting a basic journal/ledger structure up on fully rewritten code. This will include basic financial statements, batches, vouchers, journal entries, etc.

I expect to start on this in 2-3 weeks. Below is a draft of what I hope to accomplish. The scope of this part is just general ledger/general journal-related functionality.

I Strategic Requirements

Very old data may be purged without affecting reports outside that period. Companies can set their own retention policies. We do not need to provide a user interface immediately for such purging though. Access to this should be through the standard financial interface with additional options selected.

Agreed. I'd like to add that (even though it's not part of your original scope), retension periods for customer information, customer transactions and ledger data may be different.

Within the retention period, all state transitions for financial transactions must be auditable. This includes deleting and updating drafts and vouchers.

We need to support faster locking and lock unlocking for discretionary locks.

Wondering what you mean by "faster locking and unlocking". What kind of locks are you talking about?

II: Journal Entry Specifics

Journal entries must balance to be entered into the books.
Journal entries do not cross dates
Journal entries may not be marked deleted after being approved
Journal entries may exist as templates, drafts, vouchers, or approved transactions
Approved transactions may be reversed.
Drafts, templates, and vouchers may be non-destructively "deleted"
Deleted templates may be purged.

* It must be possible to use multiple FX rates for the same currency on one day (i.e. it must be possible to use a transaction with "today's rate" and it must be possible to reverse a transaction from a closed period - today - at the rate of the original posting).

currently we have a technicality in place for performance reasons: each locked period has summarized balance totals available. Do we need to say something about that in terms of requirements? Or do we simply keep it an implementation detail?

Moreover, do we want to state something about multi-currency requirements in terms of accounting here and in terms of reporting below? I'm thinking the following three cases:

1. transaction currency is base currenty (simple)

2. transaction currency is not base currency ("normal" multi currency)

3. reporting currency is not base currency (should be reported below)

Also, because the bank accounts are kept as a normal ledger journal, I think it would be tremendously helpful - so I'd like to list it as a requirement - if it would be possible to list the bankaccount details in the transaction currency instead of in the base currency; after all, bank accounts in a non-base currency get bank statements in that currency as well. Saves a lot of calculating back and forth.

Do you plan to create something like transaction schedules again? where a transaction is posted repeatedly as a copy from an original transaction or template? If so, I'd like to add the requirement that the schedule must be calculated by the software and presented in the web-ui in order to prevent misunderstandings about the actually entered repetition and beginning and end-dates. With the old one I never know how many transactions I actually entered (is the schedule including or excluding the current transaction? What are the actual posting dates going to be? What transaction references are going to be generated? etc., etc.)

III: Reports for this phase include:

General Ledger and Transaction Search
Current Balances/Chart of Accounts
Trial Balance
Income Statement
Balance Sheet

These reports must be able to tolerate purged data and be tested with purged data.

Speaking from my own experience: it would be great if these reports allowed so called "translation": reporting in another currency than the currency of the books themselves.

The general ledger and transaction search report must have options to show templates and deleted transactions, as well as individual vouchers and drafts.

Draft and batch approval will go through this report.

IV: Transaction Approval:

Draft approval will go through gl and transaction search
Batch approval will have an additional listing that will click through to the general transaction search.

The stage after this will be basic ar/ap without inventory.

Thanks for writing this all up! Looking forward to see this develop!

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.