On Sat, Sep 20, 2014 at 7:16 AM, Erik Huelsmann <[email protected]> wrote:
> 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.
>
This is true and something to be bourne out in database design aspects.
>
>
>> 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?
>
During batch payment workflows we write lock records to the database so
that two people dont accidently pay the same invoices. These are tied to
the sessions and so disappear when the sessions time out.
This is currently done by updating a field in the transactions table, but I
think it would be a lot faster to have a locks table for this.
We can't use db locking facilities because these locks have to last across
transactions and db sessions, which rules out both normal locks and
advisory locks.
>
>
>> 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).
>
Good point. That needs to be a part of the spec too.
>
> 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?
>
I think we should keep that functionality as it is.
>
> 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)
>
Question: Do we want to allow three-currency transactions?
Suppose our main books are in US Dollars and we transfer money from a Euro
account to a GBP account?
>
> 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.
>
Agreed. Perhaps a selectable currency in search and ledger?
>
> 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.
>
Sure. I look forward to developing the requirements for this.
>
>
>>
>> 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
>
>
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
------------------------------------------------------------------------------
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
