Re: More user cases where editing is nessesary

Hi;

I was thinking about this some more and had a couple more thoughts to toss out here. Part is explaining where I see LSMB going and part is trying to make sense of Peeter's requirements (please correct any misunderstandings on my side, Peeter).

An overview of the current status and approach:

I mentioned before the separation between entry and approval (and approval is the point where it becomes permanent and unalterable). I guess after talking with Erik, we may have a 1.4 bug in editing drafts. That is a bug and we need to fix it :-).

Another thought occurred to me as well, and that is that one important concept we may want to think about here is the difference between a journal and a presentation of data from the journal. In paper accounting, of course, the journal is also a prime component of the audit trail. One of the key shifts we have been trying to make starting in 1.3 has been a shift in thinking of ledgers as primary to thinking of journals as primary. That is not yet complete. If the journal is primary and contains as much audit-trail information as possible, then you can think of a lot of things as being presentations of that event stream.

The current design assumes that journal entries, once approved, are unaltered. Anything that is calculated based on current state is deferred for approval. So you can edit invoices until they are approved, but on approval COGS is calculated. This reduces the need for editing existing transactions in ways that messes up inventory quite a bit. I am not sure it is enough to meet Peeter's needs entirely, but it gets us quite far in that regard I think.

Now, not everything is unalterable after approval. We do allow some things to be edited after the fact. These include internal notes, whether an item is subject to 1099 reporting (or equivalent elsewhere) and so forth. There may be a few other things we may add to that. But the journal basically represents a tagged series of approved financial events of record. Something like tax reporting status is a good candidate for something that is editable after the fact. Number of items sold is not.

My understanding of Peeter's needs:

As I understand it, Peeter's needs boil down to four things:

1. Efficient workflow for dealing with data entry errors. At this point I don't know how much the approval stage buys us there.

2. Ability to hide data entry errors from customer. There are legitimate reasons I can see for this (for example, it makes it easier for the customer to reconcile their books). We need a solution to this problem.

3. Ability to handle incomplete information on an invoice. I think we can handle this though if you want to print the draft invoice some light customization is required.

4. Tax period vs invoiced period for invoice. We need a solution here.

5. Ability to show or hide invoices for tax reporting. We currently do this for line-items for 1099 and equivalents (1099 is cash-basis though and thus US-specific). We do support equivalent accrual reports though. If this goes by line item, the tax form subsystem may already do most of the work here and we may need to just write more tax reporting modules. If this is per invoice, then we have some further extensions we may want to add.

I don't have specific proposals yet because I want to make sure I understand the needs first.

Best Wishes,

Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.

http://www.efficito.com/learn_more