Re: Scrap in Cost of Sales -- BPCS-L

Al,

A couple of questions for you. Are you using phantoms in your B/M's to 
represent "common parts lists"? As you know, you can stock a phantom, and 
I believe you can assign a yield factor to compensate for an "average" 
expected scrap rate. The other question would be how are you doing order 
entry? Are you using a configured item based on features and options, or 
are you just taking orders for a "generic" configuration? It sounds like 
you have a good application for using features and options and releasing 
Final Assembly shop orders. As far as tracking scrap to a specific 
customer without doing actual shop order reporting will be a challenge, 
and that was why I suggested the co-product, by-product approach. That 
would breakout the cost of good and expected bad product by item number 
and then you could track which customers ordered those parts. The Sales 
Analysis module would help you summarize those costs, quickly. Good luck. 




Al Mac <macwheel99@xxxxxxxxxxx> 
Sent by: bpcs-l-bounces+amkavoulakis=sealinfo.com@xxxxxxxxxxxx
09/15/2005 08:10 PM
Please respond to
"SSA's BPCS ERP System" <bpcs-l@xxxxxxxxxxxx>


To
"SSA's BPCS ERP System" <bpcs-l@xxxxxxxxxxxx>
cc

Subject
Re: [BPCS-L] Scrap in Cost of Sales






Thanks for the suggestions.

For many other reasons we have problems with conflicting needs
* the need to produce parts based on unique characteristics of the 
physical 
part, not because it is a particular numbered wire of a final customer 
assembly
** we might have a bunch of 100 wire harnesses for a bunch of customers in 

which 15 of the wires are physically identical on any given harness with 
scores of other parts some for same customer some for others, so we have a 

unique item # assigned to some wire that is some length, guage, color, 
copper compound, has what connectors on the ends ... that might end up 
hundreds of different end items for many different customers ... from 
perspective of factory efficiency, we need to have this as one part #, not 

hundreds of different part #s for parts that are physically identical to 
each other
  * the desire to be able to access end customer relevant to 
sub-components 
being produced, because sometimes production planners get the word that 
the 
parts for some customer need to be expedited before this info has been 
updated in BPCS and MRP regenerated, also as the common parts flow into 
items that are uniquely identified by end customer identification, we do 
have our factory organized into areas by end customer needs.
* I have already been trying to do end customer identification, and we 
having a lot of inaccuracies due to our system not really setup to track 
that way, which is why I was considering pro-rating based on which end 
items actually got shipped, or were on order, that share the components 
that got scrapped

Frederick is correct that our scrap is like a cost of doing business.
Our scrap has no financial value that we can get $ back for it that is 
more 
than the cost of hauling it away.  It is like getting rid of used computer 

paper, the $ from recycling it, is like a subsidy to reduce the cost of 
hauling it away.

A portion of our scrap is from inspection finding that some parts did not 
measure up to standards and nature of the work is such that either it 
cannot be repaired, or is uneconomical to repair ... makes more sense to 
make replacement parts.

A portion of our scrap is related to setup costs ... some equipment has 
some wastage until it gets up to speed doing the product perfectly, so 
that 
in essence it not matter if we make 10 parts or 10,000 parts, there will 
be 
1 or 2 scrap from each run.

Through the process of labor reporting, we experience scrap rates of 2% 
plus or minus 2% scrap across the board.  In other words, some work has no 

reported scrap, while other work has up to 4 % reported, with overall 
average being around 2%.  I run various reports against this, such as by 
work center, parent part, components impacted and so forth.

The 8% was added for certain types of raw materials consumed in the 
operations where the highest scrap already being reported, because we were 

having a problem with inventory shortages that management suspected might 
be due to under-reporting of scrap.  There may be problems with the 8% not 

applied uniformly to new engineering changes.  We are still having 
shortages.  I do not have a sense of how the scale has changed.

Thus we are consuming our raw materials on the average 10% of our parts 
being scrapped, which is a big chunk of $ relative to our profit margins.
The 2% average that is being reported, in the range of 0-4%.
The 8% that is being assumed across the board for the component parts that 

are correctly coded to do so (a lot are not)
Actually the 2 are combined ... we telling BPCS to assume 8% extra scrap, 
so then the 4% (or whatever) actually reported also has within it an extra 

8% of that 2% eaten.

However, I have my doubts about the veracity of this.  If our physical 
inventory, or cycle counting, finds that we have an excess of inventory 
that the 8% consumed, it will get added back into our system.  Plus our 
error rate in other areas such that what needs to be adjusted is often the 

sub-components made out of the supposedly 8% scrapped stuff.

Several years ago we captured what equipment was making parts that got 
scrapped, which went into bins by machine, then each time a bin was 
emptied, it was weighed to find the total scrap weight by machine.  The 
parts had a sample weight in the engineering so that the labor reporting 
data could be sorted by what machine the scrap was reported on then 
compute 
the reported scrap into scrap weight by machine based on BOM of what was 
allegedly scrapped, then effort to reconcile reported with the actual 
weighing.  The result was pretty much same results, too close to see any 
discernable discrepancies.  We can't do that again today because other 
economy measures are not recording as much engineering details as we have 
in the past.

I checked out the BOM documentation on by-products ... looks like we would 

need to install API to use that, while most of API not applicable to our 
kind of business.

Thanks again for the ideas ... I hope I get similarly good feedback on my 
overhead question.

-
Al Macintyre  http://www.ryze.com/go/Al9Mac
BPCS/400 Computer Janitor ... see
http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html