ISTech Support Forum

ISTech Support Forum
http://www.istechforum.com/YaBB.pl
Evo-ERP and DBA Classic >> Problem Reports - Sporadic >> Backordered items Cost-of-Goods Sold missing
http://www.istechforum.com/YaBB.pl?num=1235666264

Message started by chrisbowden on 02/26/09 at 09:37:44

Title: Backordered items Cost-of-Goods Sold missing
Post by chrisbowden on 02/26/09 at 09:37:44

Keyed a sales order this past Friday in Classic, and had to part-ship the order due to lack of stock. Ran a Booking report for last week's orders after part-shipping & BO'ing that order, and the COGS for that SO was way too low. Looked at the SO Header (BKARINV) and the COGS matched the Booking Report. Looked at the SO Lines (BKARINVL), and 2 of the 5 items that we shipped 0 of (shipped none & backordered entire order quantity) still had the item COGS populated. However, the other 3 lines that we part-shipped and backordered the balance had 0 for the COGS for all 3 items. I have no idea why DBA zeroed the COGS on these 3 part-shipped & BO'd items. Anyway, I edited the SO through SO-A, zeroed the BO's, and added the 5 items to the SO as new lines to the end of the SO which restored the correct COGS for the items/order. I do not know if we had invoiced the SO as it was if DBA would have corrected this or posted the COGS wrong per the SO lines.

Has anyone else had problems with COGS on backordered SO's? We almost never BO orders, so I've not had the opportunity to look at this before. We may be part-shipping this customer for a while, so I would much rather BO than cancel and re-key every order for them. However, if Classic is going to post the wrong COGS on the BO's, I can't use the BO function.

Title: Re: Backordered items Cost-of-Goods Sold missing
Post by Lynn_Pantic on 03/02/09 at 18:56:12

The COGS on the booking report is nothing more than an estimate. It uses the Standard Cost of the items on the order. When an invoice is posted, the COGS is updated based on the current actual cost of the items being shipped. If your backordered items had never been made before or for some other reason the current Average (Or LIFO/FIFO if you are on that costing method) was 0 yet you posted a line on the invoice to show the backordered quantity, the invoice posting updated the COGS ot the current actual cost.

If a line is not being shipped at all and you do not want the COGS affected, then rather than backorder the quantity, do not release the line at all. It is a future shipment and a non-entity as far as the first invoice is concerned.

Title: Re: Backordered items Cost-of-Goods Sold missing
Post by chrisbowden on 03/03/09 at 07:16:21

In the future I will remember not to release items not shipped at all. However, since DBA appears to be zeroing the costs on part-shipped, part-invoiced line items, the booking report's cost listing is inaccurate. Is there a report somewhere else that I don't know about that would give us an accurate snap-shot of the current costing of open orders? Also, is this a bug in DBA that is causing it to clear/zero the cost of part-shipped line items? Shouldn't it maintain the initial, current costing of any line items until they are invoiced as "complete"?

Title: Re: Backordered items Cost-of-Goods Sold missing
Post by kevind on 03/03/09 at 09:03:45

I just checked this in the test company, and here is what I observed:
1. Average cost of A-200 = 5, Last cost = 6, Standard cost = 3.21
2. Order entered for qty 10 of A-200, RTI = N on header
3. BKARINV.BKAR_INV_COGS = 0, BKARINVL.BKAR_INVL_PCOGS = 3.12
4. Released qty 5 of A-200, printed packing list, printed invoice, posted invoice
5. BKARINV.BKAR_INV_C0GS = 25, BKARINVL.BKAR_INVL_PCOGS = 0

When the order is entered, an ESTIMATE of COGS is made using the STD COST (as Lynn indicated above).
(BKARINV.BKAR_INV_COGS shows zero until invoiced, BKARINVL.BKAR_INVL_PCOGS is set to STD COST ea)

When the order is printed and posted, the header is updated with the COGS using the current Average cost
and the line item COGS is zeroed.
(BKARINV.BKAR_INV_C0GS = 25 (5*5) and BKARINVL.BKAR_INVL_PCOGS = 0)

The invoice history files seem to show correct numbers.
(BKARHINV.BKAR_INV_COGS = 25 and BKARHIVL.BKAR_INVL_PCOGS = 5.

Is it desired behavior for partially shipped line items to reflect a line item cost of zero as a result of a partial shipment??

Should the remaining items retain the STD COST as an estimate or should it be updated with the AVG COST snapshot
that the shipped items were posted with??

Title: Re: Backordered items Cost-of-Goods Sold missing
Post by Lynn_Pantic on 03/03/09 at 09:11:11

I wouldn't call it a "BUG" but I agree, it isn't great design. We can change it if we can get a concensus as to what it should do.

I would think that for consistency of reporting, the open order should always retain the Standard cost as the item COGS but the invoice be updated to the actual cost at the time of invoice posting (as it currently does). Comments???

Title: Re: Backordered items Cost-of-Goods Sold missing
Post by chrisbowden on 03/03/09 at 09:21:53

Standard Cost would work fine for me. In most cases for us, standard and actual do not differ by enough to matter.

I appreciate you looking into this for me, by the way. At first glance, the booking report appeared wrong, and I was afraid that the invoice was going to post with no costing. It is good to know that DBA will post with actual costing at invoice time even if part-shipping causes the booking report to be inaccurate. This info makes me and the owner feel better about what DBA is doing on part-ships.

Thanks!

Title: Re: Backordered items Cost-of-Goods Sold missing
Post by kevind on 03/03/09 at 09:43:52

Lynn_Pantic wrote:

I wouldn't call it a "BUG" but I agree, it isn't great design. We can change it if we can get a concensus (sic) as to what it should do.

I would think that for consistency of reporting, the open order should always retain the Standard cost as the item COGS but the invoice be updated to the actual cost at the time of invoice posting (as it currently does). Comments???

I agree on both points ... retaining standard cost on open items keeps the process deterministic.