Thinking of another requirement:
It would be extremely handy if a transaction could hold a reference to the
transaction it is a reversal of and which transaction reverses it: we could
add links to those transactions as cross references on the transaction
screen.
Regards,
Erik.
On Sat, Sep 20, 2014 at 4:16 PM, 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.
>
>
>> 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.
>
--
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
