On 18 Feb 2009, at 19:35, Chris Travers wrote: > The short version of my last post is that I don't like building > accounting systems where there are no clearly defined right numbers > that are supposed to come out of it. Once we get off the basic GAAP > (FASB/IASB common ground and accepted processes),* it becomes > impossible to define exactly how the accounting program is supposed to > behave mathematically without covering new ground. The last thing one > wants is for accounting logic and mathematics to be "innovative." > > The solution is to stop thinking "I want to repost invoices" for > example, and shift this to "I want an easy way to correct a mistake in > an invoice." The first statement will get us nowhere really fast, but > the second one is productive and we can do what is necessary to meet > that need.
I have not snipped this at all, because it is quite perfect just the way it is. I do understand, appreciate & even admire the principles you're working to. They strive towards elegance. On 19 Feb 2009, at 00:50, Chris Travers wrote: > On Wed, Feb 18, 2009 at 4:14 PM, Chris Bennett wrote: > >> As Chris suggested, a one button, quick reversal system would be >> great. >> Perhaps there may be a way of excluding the mistaken and their >> reversed >> transactions from informal reports (but never from formal reports). >> > Actually one of the elements we are working on will do exactly that > (and exclude from formal reports as well, provided the transaction is > not posted to the books): Drafts and vouchers. This is also a > bigger deal for larger businesses. Let me explain the basics: > > ... So in this case, one person could create > a GL, AR, AP, payment, or other transaction and save it to the system > without posting it to the books. A second person has to come around, > review the transaction, make sure everything looks good, and post it. > ... > > A single one of these is what we call a "draft." A collection of > these would be a "batch" of "vouchers." These terms arise from > paper-oriented workflows. > > ... Until > a draft or voucher is approved it is not a financial transaction. > People with permission to do so could edit an invoice if necessary > before it is approved. > > ... > Unapproved transactions are excluded from all financial reports > because they are not financial transactions yet. I was not entirely "fixated" upon deletions over "an easy one-button reversal", but it was not previously clear that the above was planned. The facility to exclude from reports is especially pleasing and I appreciate the explanation. From the point of view of my workflow, I really want the "draft" you describe to be printable and look just like an invoice; I guess I can just copy the invoice.tex to the new template, perhaps adding a big "watermark" of draft across the page. I find it much easier to review the printed format for mistakes than I do from looking at the textboxes on the invoice entry screen. I don't really know why this is - whether one is unused to irrevocability in webpages or whether my invoice layout is simpler and I can more easily see if an item is missing a price. I enter & print a number of invoices at a time. Either immediately after or the next day I check the physical printouts look right before putting them in envelopes and mailing them, and it is only at this stage I would expect to post them in LedgerSMB under your proposed workflow. I think a number of my concerns relate to quirks inherited from SMB- Ledger. For instance, if I receive a payment for a customer and forget to tick a box on the "Cash" screen a new negative invoice is generated instead of the payment being credited to the appropriate existing invoice. Naturally I want to delete this negative invoice [1] and in the past have used SQL-Ledger's "delete button" before resetting the "next invoice" number in settings. If I make this mistake now, because it has been repeated here so many times that such deletions are unsupported, I shutdown postgres, restore my database from backup and then re-enter any transactions. Stroller. [1] I think this negative invoice is even "illegal" under UK law, as invoices should always be for a positive amount owing. I think that paperwork relating to a refund is required to be described as a "credit note" and perhaps should not interrupt the invoice numbering sequence. When a credit note is printed it should use a different LaTeX template to invoices. The refunds on a credit note should be shown as positive. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
