Re: GAAP (was Re: Patch for serious bug in LedgerSMB 1.2.16)

[Chris Travers <..hidden..>]

Turtle:

Part of the problem is that when you edit and repost an invoice, there
are a number of nasty corner cases which can bite you.  Since the
workflow is non-GAAP, there are no accepted mathematical solutions to
this problem.

Let me give you an example.  Suppose you sell an item which has a very
volitile price, and you repost invoices out of order.  You can end up
with CLEARLY wrong results on a FIFO inventory system (which
Quickbooks doesn't use, BTW-- they do average cost iirc) because of
which items are used as the basis for inventory calculations.

For example.....

I buy 10 items of a part from vendor A at $0.10 each.
I sell them all to 10 customers at $1 each.

Now my income shows $10, COGS shows $1, Inventory shows $0.

Another customer comes in and needs that part tomorrow.  So I order it
from vendor B, and have to pay $3 for it in order to get it the next
day.  I sell it to this customer for $6.

Now, my income shows $16, cogs shows $4, inventory shows $0.

Now, I repost one of the older invoices.  What happens is we delete
the original transaction and de-allocate the part from the most recent
sale.  So far so good.

Income shows $9.00, COGS shows $3.90, inventory shows $0.10

Now, we repost the transaction, using the most recent part as the part to sell.

Income is back to $10.  Cogs now shows $6.90, inventory shows $-2.90.
There are no parts in inventory, and the numbers are obviously wrong.

Now, I repost that invoice again.  The same discrepancy will continue to grow.

In short there is no accepted solution to the problem because the
problem does not exist in an accepted process.

One option would be to restock the part at the value it was purchased,
but you don't always know this value, so we can't assume we do.  (A
line item from an invoice could have multiple different purchase
values associated with it), that causes other problems, though
arguably not as severe.

The way Quickbooks gets around this problem is by not doing FIFO
inventory calculations (FIFO really is the best for being able to do
financial planning from the data) and simply tracking average cost of
onhand inventory.   IMO, this would also cause a loss of other
functionality, and I would rather see the workflow supported via
GAAP-compliant ways than compromising on what inventory value
calculations are possible.

Furthermore, rewriting the inventory control structures to use average
cost is not going to be any less work than creating scripts to
automatically handle the GAAP issues in the requested workflows, and
would certainly be more disruptive.

The solution is not to say "we don't care about GAAP or about proving
the most useful numbers" but rather "people want to be able to do
something by clicking on a single button, so let's give it to them,
but do so in the right way."

Best Wishes,