Re: COGS incorrect when invoices are reposted

["Chris Travers" <..hidden..>]

Hi David;

Sorry to say it looks like you have picked up some bad habits.

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.  I
guess I should probably set it to enforce transaction reversal by
default.  I will do this for 1.1 so as to prevent this serious
problem.

> Oh dear. I have not taken enough notice of this issue. Now that it is
> clearly explained I see what a show-stopper it is. What you are saying
> is that once an invoice is created and saved (via the 'post' button) you
> cannot make *any* changes to it at all if the invoice includes parts, ie
> over 50% of my invoices, and 100% of some people's. Quite often I need
> to add or change something, even just a bit of a note.
IANACPA

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.  If you make a mistake, then you should void
and create a new one.  Or at least that is the correct way of tracking
invoices.

If you need to add/remove parts, use sales orders instead.

If you would like a detailed discussion as to *why* this process is
necessary from an accounting perspective, I would be happy to
elucidate.  I will however note that the application probably
shouldn't allow this by default and I will correct this for 1.1...

I think that one of the serious flaws on both Quickbooks and
SQL-Ledger is that it makes it somewhat easy to do the wrong thing.  I
would like to see a point where LedgerSMB requires proper reversal of
all transactions and doesn't allow you to handle them incorrectly.

> If this functionality is that badly broken, I no longer consider this a
> useful accounting package at all. I mean, what use is an accounting
> package that cannot invoice and correctly account for those $'s? I mean
> that is the core of what this system is: writing invoices for goods and
> services, recording the banking of payments, and recording expenses. If
> it cannot account 100% correctly those operations, it ain't an
> accounting package.

The showstopper here is that SL lets you do the wrong thing rather
than that it can't keep track of the money.
> Fortunately, in my case, the $ value of parts is relatively low,

Actually the problem is in the variation of the cost of parts over
time.  But if you are re-posting your invoices you have learned some
bad habits, I'm afraid.  These habits may result in inherent
inaccuracies in your income tax returns regardless of which software
you use (the problems involve exactly when income is recorded on your
books according to accrual-based accounting practices).

> compared to services, so although it sounds likely that running SL has
> led to my making **incorrect** tax returns for the past 2 years, I $
> value is *unlikely* to be very significant.

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

I just hope the tax office
> see it that way!!! As company director I do not relish the thought of
> copping a fine from the government because I took it upon myself to
> trust the professionalism of some dickhead open source outfit that
> thought they knew how to develop software. (Note that I said 'develop
> software', not write program code).

If you are the director of a company, you are not going to approve of
reposting invoices :-)

Let me rephrase this-- if your processes are GAAP compliant this is
not an issue.  It is an issue with broken workflows and an
unwillingness to insist on making people enter data the correct
accounting way.  Quickbooks is as bad as SL in this regard.

This problem can be remedied simply by insisting on enforcing
transaction reversal, which can be set easily enough.

This whole re-posting of invoices is a crutch that needs to be
disposed of.  If people find the workflow cumbersome, let's make the
workflow simpler but ensure that on the back-end things are done in
GAAP-compliant ways (Josh's void and clone suggestion is basically a
reverse and re-enter). If we can do that, we will be the best
accounting app out there.

We still have some work to do on defining the math that goes into
calculations for voiding invoices but that should be reasonable for
1.2, I would think...

You are welcome to use another package, but 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.

Best Wishes,
Chris Travers