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, ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
