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 reversedtransactions 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.