[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ledger-smb-devel Digest, Vol 93, Issue 15

Hi, its been a long time but one of the requirements we have is to support per line or if it is not possible leger note traceability. 

Not sure if by journal you mean the ledger journal or something else tough, so i send apologies if this is not the thread to send this ingormation.

Regards

> El 20/09/2014, a las 10:14, ..hidden.. escribió:
> 
> Send Ledger-smb-devel mailing list submissions to
>    ..hidden..
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
> or, via email, send a message with subject or body 'help' to
>    ..hidden..
> 
> You can reach the person managing the list at
>    ..hidden..
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ledger-smb-devel digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Draft: Requirements of Journal Entries, Batches,
>      Vouchers, and Reports (Chris Travers)
>   2. questions for: Chart of Accounts Changes (Chris Travers)
>   3. Minor tweak to Fixes.sql for 1.4.1 (Chris Travers)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sat, 20 Sep 2014 07:40:17 -0700
> From: Chris Travers <..hidden..>
> Subject: Re: [Ledger-smb-devel] Draft: Requirements of Journal
>    Entries, Batches, Vouchers, and Reports
> To: Development discussion for LedgerSMB
>    <..hidden..>
> Message-ID:
>    <CAKt_ZfvQacpKZAz=Bx_8DD3BQw2MTHhj1VHZ04=..hidden..>
> Content-Type: text/plain; charset="utf-8"
> 
>> On Sat, Sep 20, 2014 at 7:16 AM, Erik Huelsmann <..hidden..> wrote:
>> 
>> 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.
> 
> 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
>> ..hidden..
>> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> Message: 2
> Date: Sat, 20 Sep 2014 07:54:51 -0700
> From: Chris Travers <..hidden..>
> Subject: [Ledger-smb-devel] questions for: Chart of Accounts Changes
> To: Development discussion for LedgerSMB
>    <..hidden..>
> Message-ID:
>    <CAKt_Zfu3f36qTQ=4w7rhxJKY=s98fx7yS=..hidden..>
> Content-Type: text/plain; charset="utf-8"
> 
> In order to support a statement of cash flows I will need to extend the
> current chat of accounts structure to specify operational vs
> non-operational changes in cash standing.
> 
> In addition, do we want to have a setting on the account which will flag it
> is floating in another currency?  It seems to me that this might be helpful
> in foreign currency reporting, payments handling, and more.
> 
> -- 
> Best Wishes,
> Chris Travers
> 
> Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
> lock-in.
> http://www.efficito.com/learn_more
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> Message: 3
> Date: Sat, 20 Sep 2014 08:14:28 -0700
> From: Chris Travers <..hidden..>
> Subject: [Ledger-smb-devel] Minor tweak to Fixes.sql for 1.4.1
> To: Development discussion for LedgerSMB
>    <..hidden..>
> Message-ID:
>    <CAKt_Zft001iCoF0PbPHB7t8Q=j6=..hidden..>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi all,
> 
> Given the minimal nature of this tweak I will not do another RC but it
> seems safer to archive rows before modifying them so I added this tweak.
> 
> Feel free to review the pull request:
> 
> https://github.com/ledgersmb/LedgerSMB/pull/358
> 
> I expect to have another pull request tomorrow updating docs about theCOGS
> fix,
> 
> -- 
> Best Wishes,
> Chris Travers
> 
> Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
> lock-in.
> http://www.efficito.com/learn_more
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> ------------------------------------------------------------------------------
> 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
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
> 
> 
> End of Ledger-smb-devel Digest, Vol 93, Issue 15
> ************************************************

------------------------------------------------------------------------------
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
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel