MRP500 600 work a little different if you are running individually by facility or for the whole company irrespective of facility. In general you run your company a certain way, and setup codes in various files consistent with that way.

On the basis of all the info available, MRP creates "planned orders" which you can firm up several ways, such as by releasing shop order, purchase order. resupply order, etc. using the due date of the MRP planned due date. Then the customer order gets changed so now we really need the parts on a sooner date, or in a larger quantity. MRP will put a reccommended reschedule date into those shop orders, purchase orders, resupply orders, etc. but if you do not change the date in those orders, MRP assumes the humans know what they are doing, like not paying attention to MRP advice, on purpose.

For example, you have subcomponents that really need to get in house sooner, because the customer order got pulled up, but MRP drives due date of components based on due date of firmed up shop order, not on reschedule date suggested because customer order got changed. Then if you update parent shop order to agree with MRP expedite date, and rerun MRP regen, it goes down another level (or more?) to provide reschedule dates for the child items.

There are multiple opportunities to not setup your items correctly, leading to MRP ignoring items because of your collective errors of omission. Depending on your version of BPCS, there are other things that can go wrong.

Suppose you have negative inventory ... will MRP seek to replenish it? In our case, the negatives are probably because of float in reporting and processing transactions, and we would prefer that BPCS compute as if the on hand was zero. Suppose you have negative allocations ... will MRP fail to plan those items? In our case, we need to run an allocations reorg to fix this. Suppose you enter a customer order that is past due when you key it in, and also dated prior to your MRP planning date. Will MRP ignore it?

Suppose you have a brand new item, and when you key in the BOM, you use an effectivity date of the day you key it in, and you get a customer order right away, and there are lead times that go back a few days, to a date before the date you keyed in the parts, with a current effectivity date, which means you need the components before the date you entered the engineering for the parts. Will MRP ignore the requirements because they are past due relative to the effectivity date?

These questions, and more, are why we need to study the documentation, and TEST TEST TEST, to make sure it is working the way we think.

Oh and one more thing ... before you came to work at your company, is there a possibility that prior employees modified stuff so that MPS MRP does not work at your company the standard BPCS way? Do you know how to figure out if that is the situation?

     Hi,



   Sorry to botherou, but..



   Finally, is the following correc ?



   MPS / MRP Logic<P>

   1)     Forecast or Customer Ordr creates Demand or Requirement for
   ?0? level MPS item i.e. KMR for Fiished Product.



   2)     MS run (MRP500) then takes this KMR as input,



           a)     hecks minimum balance for Finished Product in IIM or
   CIC   depending upon how you have set up in MRP system paameters),



        &nsp;  b)     adds this minimum balance to the abov
   requirements,



       &nbp;   c)     checks scrap factor from MBM, ads that much %
   (for e.g. if scrap is 90%, then takes requirement as 110%),


           )     checks the available inventory balance (in IIM, WI,
ILI files), reduce this available inventory from above requirements, < /FONT>



           e     checks any Scheduled Receipts from shop orders (oen
   shop order) (FSO File ???), reduces this & works out Net Requiremen &



        &nbsp  f)       then create Planned Order (KP) equal to this
   Net Requirement for this Finished Product.

   < Indent>Net Requirements = (Requirements rom KMR +
   Min.Balance) * scrap factor ­ Inventory Available ­ Schedule
   Receipts from Shop Order;

   Planned Order = Net Requirement



   3)&bsp;     MPS run will also create Planned Orders (KFP)or all down
   levels of child MPS items, if exist, considering net requiremnt logic
   as explained above (only the difference is it takes requirement o
   demand from Planned order of Parent (KFP)).



   4)     MRP run (MRP600), takes parent MPS item?s KF as it?s input,



          a)     works out net requiremen as above,



        &bsp;  b)     creates requirements (KMR) for all dwn levels
   child MPS as well as non-MPS items &



   <FONT ize=2>        c)   &nbp; Only Planned Orders (KFP) for all
   down level child non-MPS items only.<FONT>



   Net Requirements = Requirements from Parent Planned Orders i.e. KFP
   using BOM + Min.Balance) 96 Inventory Available ­ Scheduled Receipts
   from Purchase Order;<P>

   Planned Order = Net Requirment



   regards,



   Prashanth
--
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.

Delivered-To: macwheel99@xxxxxxxxxxx

-
Al Macintyre  http://www.ryze.com/go/Al9Mac
Find BPCS Documentation Suppliers http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/
Replacement company web site (same company, new domain) http://www.globalwti.com/

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.