We are using Baan IVc4 (SP 19). We have items set up to represent the scrap which is generated through a normal manufacturing process. For every so many pounds of material required on the BOM, a negative amount of scrap material is also required. This creates a byproduct of scrap which then goes into inventory, outbounded to a sales order for the customer (our scrap dealer), and invoiced. Our current scrap items are set up as purchased items. We do not ever actually purchase these items. We do not utilize purchase price lists.

Our cost price calculation code is set to the following priority:
- Latest Purchase Price
- Average Purchase Price
- Current Purchase Price

The problem… when these items were set up, the system prompted the user to automatically populate the other purchase prices with the value entered into the Purchase Price field and they answered ‘Yes’. So now there are average and latest purchase prices. Since our cost price calculation priorities are what they are we can never update the standard cost since the Average and Latest Purchase prices are stagnant (remember we don't purchase these items). We have set up different cost price calculation codes which use the Current Purchase Price as the first priority (which will allow us to change the price temporarily), but we do not use the Single-Level cost price calculation method so eventually the top-level or a lower-level item will be recalculated using Top-Down or Bottom-Up methodology and using our standard cost price calculation code will revert the cost to the Latest Purchase Price which is not the one we want.

My question is: Although not entirely proper... since this item has no actual purchase history, is it OK to zero out the Average Purchase Price and the Latest Purchase Price for this particular item? If the answer is yes, other than verifying that there is no actually purchase history, are there any additional checks that I should make?


Thank you for any help you can provide.

Eddie,
Wanted to clarify few things about your case...
1) You mentioned scrap is generated through a manufacturing process. Does this mean you get excess when the production order is completed and then you transfer this excess to an item code you have created for storing scrap?
2) If the cost of this scrap changes frequently, have you thought of using projects(pcs)?

sk

The particular instance of manufacturing this revolves around is a coil of material running through a stamping press which produces a part and the residual coil (scrap). The finished good has a production BOM which looks like this:

Position 10, Item=Brass, Net Quantity=407 lbs
Position 20, Item=BrassScrap, Net Quantity=-132 lbs

So when they issue all material to the production order, Brass goes from inventory to the production order and Brass Scrap goes from the production order into inventory. Granted, it is the theoretical amount of scrap that should be genereated, but that is how our production people have set it up. The scrap inventory sits in the warehouse until the end of the month when they generate a sales order to sell the scrap to our scrap dealer. Hopefully this clears up your first question.

As far as using the PCS, I don't think that PCS functionality would gain us anything in regards to rolling up the price, plus that would mean we would have to maintain over 100 different projects for all of the different material types we use and their respective rates.

I needed to resolve this so I went to support to pose the same question. They agreed that under the conditions mentioned above it would be ok to zero out the Average and Latest Purchase Price.