Uploaded image for project: 'OFBiz'
  1. OFBiz
  2. OFBIZ-9500

Maintain accountingQuantity for all COGS valuation methods




      From http://ofbiz.135035.n4.nabble.com/AccountingQuantity-COGS-method-and-inventory-valuation-td4700867.html

      Why accounting quantity?

      When inventory is shipped, there's an accounting transaction that debits the inventory on hand value and credits Cost of Goods Sold (COGS).

      There's more than one way of deciding what value is added to COGS.

      First and most obvious is the actual cost of the inventory item. But companies may prefer other strategies. OFBiz has the option of three others: average cost, first-in-first-out or last-in-first-out. There's a nice survey of why you might choose one of these at http://www.dummies.com/business/operations-management/choosing-an-accounting-method-for-the-cost-of-goods-sold-expense/, http://www.dummies.com/business/accounting/the-fifo-method-for-cost-of-goods-sold/, http://www.dummies.com/business/accounting/the-lifo-method-for-cost-of-goods-sold/

      Note that if you choose anything other than inventory item cost, the money amount transferred to the COGS account may be different to the cost price of the inventory items being shipped. When you choose FIFO or LIFO, the amount may have originated from a different inventory item, received at a different time.

      Current situation in OFBiz

      The cogsMethodId field in the PartyAcctgPreference entity is a enum with four possible values: COGS_INV_COST, COGS_AVG_COST, COGS_FIFO, COGS_LIFO..

      The accountingQuantity field in the InventoryItem entity and accountingQuantityDiff in the InventoryItemDetail entity track the quantity of an item still "live" for the purpose of inventory valuation and COGS.

      In the service createAcctgTransForShipmentReceipt implemented in /applications/accounting/minilang/ledger/GeneralLedgerServices.xml

      the accountingQuantity is always set to the same value as the quantity received (i.e. the same as the quantityOnHand) for a newly received inventory item regardless of the COGS method.

      When items are shipped, the service createAcctgTransForSalesShipmentIssuance will only reduce the accounting quantity if the COGS method is FIFO or LIFO (http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/minilang/ledger/GeneralLedgerServices.xml?view=markup#l1127). With FIFO, when an item is shipped, inventory items for the product with a non-zero accounting quantity are found sorted from earliest to latest received. The quantity of the item shipped must be decremented from the accounting quantities, starting with the earliest. Similarly, with LIFO, items are sorted from latest to earliest, and the latest item or items are decremented.

      In other words, if you have chosen a COGS method of COGS_INV_COST or COGS_AVG_COST, the accounting quantity is meaningless and in OFBiz as of
      now, should be ignored.

      And yet, the Inventory Valuation report uses accounting quantity, regardless of the the COGS method (http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/widget/ReportFinancialSummaryForms.xml?view=markup#l535). In other words, the Inventory Valuation report is broken for COGS methods of COGS_INV_COST or COGS_AVG_COST.

      What should happen

      The Inventory Valuation report, and anybody else who cares, should always be able to trust the accounting quantity. For COGS_INV_COST and COGS_AVG_COST, maintaining the accounting quantity is simple - createAcctgTransForSalesShipmentIssuance should just adjust it to match the remaining quantity on hand for the InventoryItem.

      So shipping an InventoryItem may cause adjustments to accounting quantities in other items for FIFO and LIFO, but when the COGS method is actual or average cost, the adjustment is always in-place - the actual InventoryItem being shipped.

      No matter what the COGS method, the total accounting quantity for a product across all inventory items should always be equal to the total QOH.




            • Assignee:
              paulfoxworthy Paul Foxworthy
              paulfoxworthy Paul Foxworthy
            • Votes:
              2 Vote for this issue
              1 Start watching this issue


              • Created: