[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: COGS incorrect when invoices are reposted



Chris Travers wrote:
The problem is not with inventory numbers, it is with the calculation
of cost of goods sold, which is calculated on a first-in first-out
basis.

In other words, I buy four parts for different prices.  When I sell
the first part, it grabs the price of the first part I bought, deducts
it from the inventory account and adds it to the COGS account.  When I
sell the second part, it does the same with the second part I
purchased of a given part category.  So if prices are volitile, it is
important that I grab the price associated with the right purchase.

The problem happens when an invoice is reposted.  It doesn't know
which item was originally sold so it takes the one most recently sold.
 If the prices are volatile then the expected COGS could be quite
different from the real COGS as happens in the example I posted.  In
this case, you on-hand numbers will still be correct, but Cost of
Goods Sold and inventory value will be off.  In practice it seems to
deallocate the most recent sale rather than try to match the sale with
the purchase.

Voiding a trasaction may well cause a similar problem.
  
Adjusting/Voiding of website orders happens all the time.  On our site, customers are invoiced and inventory levels are adjusted when credit card approval is received.  Hence, the next customer can only order items that are available AFTER the prior orders have been allocated.

It would seem that reposting or voiding could have troublesome side effects for some or all of the following

Time-dependent functions:
  • Cost of Goods Sold (which cost is allocated to which purchase)
  • Inventory Levels (adjusted after each transaction)
  • Tax Rate applied (rates change, shipping address changes cause different tax rates to apply)
  • Currency Conversion Rate applied (todays rate is different than yesterdays)
  • Shipping Rates applied (shipping rates change)
  • Discounts applied  (some discounts are only applicable within a time period)
  • Selling Price applied (some price tables change at a specific date
If an order is accepted on Dec 31,2005 at 11:59 PM then voided/adjusted the next day, what are the proper accounting and customer acceptable actions with regard to all the above time-dependent rates above?

How does LedgerSMB handle these time-dependent prices and rates?  How should it?

Roland