[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: COGS incorrect when invoices are reposted
- Subject: Re: COGS incorrect when invoices are reposted
- From: "Chris Travers" <..hidden..>
- Date: Wed, 20 Sep 2006 19:15:51 -0700
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
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.
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
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
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
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.