DeeDee
Some more thoughts ... hope I not being unconstructive here
We often get customer requirements on new parts before the customer 
approves the samples.  We enter BOM and customer requirements, so that the 
MRP will plan the raw materials in time, then enter the Routings when the 
samples are approved.  We have a hard time differentiating for our factory, 
which customer orders are not REAL yet, because samples not yet 
approved.  There has been some experimentation, placing "S" in buyer 
planner code when sample not yet approved, but looks to me like that is not 
yet working, because I have seen shop orders released on such parts that 
are not yet ready.
We have had evolving business needs in our mainly make to order reality, in 
which we recently have been doing some things differently.  We have a 
growing volume of customers in which we need to have a safety stock of 
finished product, that we send out when the customer asks for it with 
almost no lead time, compared to how long it takes us to make it.
To make this work, we are using minimum balance safety stock in CIC 
file.  Sometimes questions have come up, when we moved product from which 
factory made it (new factory needs CIC safety stock, old factory not need 
that any more), and I have discovered that CIC safety stock demand does not 
show up on MRP300 ... you trace the pegging and it goes invisible.  I am 
wondering if other requirements from other sources in BPCS can also go 
invisible, whether you looking INV300 DRP300 etc.  As we implement changes 
in how we do things, we need to be alert to the risk of invisibility in 
what's going on why.
We manufacture parts in one facility to be used in another, so they have to 
be item master coded manufactured parts.  In the facility where they used, 
we have some new staff who are unfamiliar with our item # systems item 
classes and so forth, who sometimes have something to be made on short 
notice, they look at the BOM and release shop orders on purchased and other 
parts that should not be in that situation if they had better understanding 
of our systems.  Oh yes training issues abound.
-
Al Macintyre
BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/
Thank you very much for your responses so far.
We are set up similar to Al, where we run MRP nightly and don't use order
policy K...
Robert, we have a mix of both stock items and made to order; but I don't
think the made to order items will stop us from using the prorated forecast
- we are trying to enforce having our sales employees enter customer orders
for those items, which would then drive requirements.  If we do end up
forecasting them, we'll make the start and end dates the same...  I couldn't
agree more on it being an issue of training and all.
I've set up our test environment to run a prorated forecast.  In a nutshell,
requirements appear prorated, but orders don't (most apparent on MRP300
screen --Planning/Pegging Inquiry).  The main reason we are forecasting is
to have more reliable MRP results; our next step is to start using PUR640 PO
Consolidation/Release - our goal is to automate creating and distributing
POs based on MRP... I'm going to do some further testing - thinking I might
have a parameter set up wrong, else this prorate flag is useless to us.
DeeDee Virgei
Project Leader
Nelson Stud Welding, Inc.
7900 West Ridge Rd
Elyria, OH 44036
 
As an Amazon Associate we earn from qualifying purchases.
	
 
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.