Re: COGS incorrect when invoices are reposted

[David Tangye <..hidden..>]

On Wed, 2006-09-20 at 19:15 -0700, Chris Travers wrote:
> This is not a show-stopper.  And I will explain why.  The only
> show-stopper is just that SQL-Ledger lets you butcher your books.
 What **are** you saying :-) Hmm, lets move right on.

> IANACPA
?? Sorry where's a link to these email codes?

> Or you could as advice from an accountant :-)  Invoices should only be
> posted when you are ready to bill.  That is a central principle of
> accrual-based accounting...
...
> But if you are re-posting your invoices you have learned some
> bad habits, I'm afraid. 
Good point. As I see it the issue revolves around the implementation of
'posting' as defined. In a nutshell, I want to save and post the new
invoice record, but later should be able to make *some* changes, eg to
notes at least. Hmm, what else, essentially anywhere where I made an
error I want to correct it. If auditing is on, then I thought I was
adhering to best accounting practices. However that is not the point.
The point is that the update of the data, even to correct trivial values
is done via (re)post, which might corrupt the accounts.

I see where you are saying that in applying best accounting practices
there is no such thing as trivial data in a posted record. Therefore I
agree that if the system is to adhere to best accounting practices, then
(re)posting should be disallowed. The problem is that then the system no
longer works to easily help me work how I want to in the real world.

> The showstopper here is that SL lets you do the wrong thing rather
> than that it can't keep track of the money.
OK, I have to think about that: it seems to be spitting hairs to me.

> In most cases, inaccuracies are unlikely unless the price of a part is
> particularly volitile.

> If you are the director of a company, you are not going to approve of
> reposting invoices :-)
No, but I want a system that allows easy updates to invoice records
between time of creation and time of submitting to the client, while
keeping the accounts accurate.
> It is an issue with broken workflows and an
> unwillingness to insist on making people enter data the correct
> accounting way.
No its an issue of having a system that lets people correct their
mistakes or change information to an invoice quickly and easily. The
system can do what it needs to do to keep things 'the correct accounting
way'.

> This problem can be remedied simply by insisting on enforcing
> transaction reversal, which can be set easily enough.
What is wrong with having audit on, allowing updates, and having the
system process them correctly. (Whether updates are processed by
database update or delete-insert should be a technical backend issue of
little or no interest to most users.)
> 
> I think our approach ought
> to be to try to ensure  that people are required do enter data into
> their database in the *correct* manner from an accounting perspective,
> but we ought to make this as easy as possible.
Agreed. This discussion seems to be about maybe the system currently
falls between those two stools, but worse still, can corrup the
accounting in the first place.