Hi Chris,
On Thu, Sep 18, 2014 at 5:06 AM, Chris Travers <[email protected]>
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.
------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
