RE: Padding BPCS Fields (was: MPS - Customer Demand and General ECL Date Questions)

--
[ Picked text/plain from multipart/alternative ]
Paul

There is the issue of what values need to be in what fields to get the job
done.
I know some of that, but not the whole story.
Perhaps that sort of discussion should continue on separate threads.

Then there is the question of repopulating some value when it is discovered
that everything needs to be changed from 5 days to 3 days, or 1 day to 2
days, or whatever.  I can help with the latter, since we have done that
sort of thing not very heavily, but fairly often, so that over the years we
have accumulated over a dozen different fix it programs.

I put this stuff in separate fix it programs so that if the rules change,
90% of the fix it programs will still be valid, we only have to change the
fix-its where the rules changed.  Also the rate at which various fields
become critical is another reason to keep them separate.  They started
separate because easier to test during implementation.

If you can precisely define the file.field that needs to get some fixed
value, like 3 days, plugged into 100% of your records, or to 100% of those
that are a particular item type class, that you make for a particular
customer, then that is an obvious example of a need for a fix it program
that will plug in that value.  We had a case of that with MRP planning.

Some of the IIM CIC fields needed to be a certain way for the wire we
extrude, another way for other WIP items, a third value for end items to
customers.  Simple enough for a program to plug all that in to all items,
and if the rules changed, simple to change the program to the new
value.  Then we just run this program regularly to make sure all items have
the new rules.

Problem = some manual exceptions, thus it only plugs in the latest business
rules value if the field was previously zero, or the previous rules.  This
leaves alone those items where someone has keyed in some other value.  We
also have a Query/400 to list items with other values outside the standard
business rules so we can audit that they are in fact correct.

There are 3 scenarios we have.
    * In researching some BPCS problem, we discover that we have a field
that has not been populated properly in the past.  So now there are tens of
thousands of records in several files that need to get the correct value
plugged in.  You might run into this with MRP/CAP implementation, in that
some fields were not important to SFC/ORD/PUR/INV etc. but now it is
critical to MRP/CAP working correctly, that those fields get populated in
some particular way.  We have been using CAP in a small way, but not
heavily.  I anticipate that CAP will become much more important to us in
the near future, at which point we will discover fields that did not cause
headaches for SFC/INV/PUR or MRP but are not right for CAP to work right.
    * At some point in the company's historical past, we thought it best to
populate some field with some standard value, but now business has evolved,
and we need something different.  An example is that we now have end
customer parts with an unused BPCS field populated with the NUMBER of wires
in the harness, which is a measure of complexity, that is more meaningful
to our people than the BOM Routing Steps.  That is entered manually, but
then we can use that complexity value (if less than 10 wires, if more than
75 wires, etc.) to adjust our lead times to be higher on higher complexity
items.  We did not have the complexity rating in our data base when we
first set lead times eons ago.  I sure wish I had a list of unused BPCS
fields that are safe to populate with anything we please.  There is a risk
that we might experiment with some field and think it is safe to swipe,
then we turn on some other module and discover that it is critical to that
module to work right.
    * We have a growing volume of people keying in data to new items,
particularly new end customer items.  We get the customer demand, the BOM
setup, so that MRP off of ORD for which no SFC yet released, that drives
PUR for the raw material needed, while engineering is keying in the FRT
needed.  Well there is a risk that the person entering new end customer
item might not seed all the esoteric fields the way they ought to be setup,
and data validity checking manually might miss a part or a field.  So we
want to impose certain values in any records that miss what we consider
essential.
We have a query program that lists items whose item class means the on-hand
should never be a decimal value, that do in fact have a decimal value ...
this is a tip off that the BOM needs fixing.

When items become identified as inactive & obsolete, we change their item
class.
We have query to list those items apparently in usage again.

Before MRP500 600 we run our MRP80W which updates KPF.FHWSE and CIC.ICPLLN
Planning warehouse based on facility and type of item ... our definitions
have evolved over the years as to which items treated differently, but
basically now we want end customer items to be MRPed into our shipping
warehouse, and all other items to be MRPed into our WIP warehouse.  BPCS
only supports one warehouse per facility for production work, but we are
using two.  I could see in the future that perhaps the work for a
particular customer might need to be MRPed to some place separate.  We do
have a field in our item master for end items that gives the customer we
making it for, so that shows up on INV300 BOM300 etc. but we have not
cascaded that value down to sub-assemblies that are not common.  This is an
obvious application for another fix it plug in program if ever needed in
the future.

We have INV80S program that forces IIM.IMPSD = MPS demand code to be letter
S for all items.
This is an example of the scenario where this might have not been populated
correctly and not made a difference prior to getting MRP working correctly.
It is a very simple program
input IIML01
If read a record with IID = 'IM' and IMPSD NE to IMPSD
MOVE 'S' to IMPSD
and update that IIM record

We have INV80W program that forces all IIM.IMBWIP WIP Tracking to be value
1 (one) ... at one time we were only doing this for IIM.IITYP 1 (one) end
items, but now we doing it for all items.
We also have MRP80B doing something similar to all CIC.ICBWIP

We have some fix it programs for data in wrong facilities, but you are global.
They populate CIC and other files for items that we manufacture in one
facility for use as raw materials in another.

You might want something like that in FRT, but first look at the lead time
fields in IIM.

Al Macintyre
BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/
See Al http://www.ryze.com/view.php?who=Al9Mac
Find BPCS Documentation Suppliers
http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html

 >>> laflammep@kennedydc.com >>>

>Thanks Chick, your first paragraph describes exactly what I'm seeing in
>testing. I'm just not sure how we should get it to back the LRDTE up one
>day. I could do it with Move days, but that means every router of every item
>(we use a lot of muliple routers for the same part). It would be quite a
>project and require a LOT of ongoing maintenance.
>
>Paul

Paul also wrote in answer to Al's MRP INPUT perspective (all the stuff that
needs to be working right, which includes people attitudes, if MRP/CAP
gonna be successful)

I'd sure like to figure out how to "pad" all the manufactured end items with
a day of lead time from the LRDTE (in ECL) though. We've also thought about
adopting a strategy that would ask manufacturing to have all manufactured
items available to ship 5 days prior to the customer request date. (lrdte)

Further reason why I don't want to do the padding in the router. What
happens when management decides we should change the 5 days prior to 3 days
prior? Then I must change every router and alternate router of every item we
manufacture!


>-----Original Message-----
>From: Chick Doe
>
>if i remember properly we ran into a problem with lead times. when mrp (and
>probably mps) du their planning they use the 'lead time' to determine when
>the components are due. but when you actual create a shop order sfc500
>calculates the due date based upon the shop order due date and the run,
>setup, move, and queue hours in the routing. this caused us some major
>discrepancies where mrp was planning components for one due date and then
>suddenly that due date changed once the real shop order was cut.
>
>i know we went through an effort to try to synchronize planning lead times
>to real routing lead times, but that was some time ago and it's probably out
>of snyc again. perhaps this is one contributor to the 200+ page mrp
>exception reports.
>
>as far as the mrp exception reports go they are too voluminous. we wrote our
>own summary version with a filter in it. if we set the filter to 10 days,
>they won't report any reschedules that mrp is recommending that are 10 days
>or less from the existing order due date. (mrp stores it's recommended
>reschedule date in the FSO and HPH files and you can easily access this and
>the current due date to write you own reports.
>
>chick doe
>barton instrument systems
>
> >>> laflammep@kennedydc.com 12/11/02 02:15PM >>>
>--
>Hi Judi,
>
>To clarify my question - should a lead time set on the end item for an item
>master (IIM) (not planning by facility) effect the MPS planning for an MPS
>item? What I'm seeing is that once I say an item is an MPS item using the M
>code on the Item Master (IIM) the system will not consider the lead time
>field in the item master. Instead, it looks solely at the BOM and Router to
>determine when a particular shop order must be started to finish when
>needed. Now if my BOM components of that end item have lead times, the
>system may be factoring that in - I didn't get that far yet.
>
>Paul
>
>-----Original Message-----
>From: Judi Svoboda
>
>Paul, if I understand the question, lead time days is for purchased as
>well as manufactured items.  If you have different levels in your BOM
>need to enter the lead time for each level according to actual time to
>produce plus wait move and queue.

>Judi Svoboda Ridewell
>
>-----Original Message-----
>From: Paul LaFlamme
>
>
>We're using BPCS V405CD(ptf2) and getting ready to begin using MPS/MRP.
>We're a discrete order job shop Die Cast manufacturer (Order Policy H on
>MPS items) and will rely on Customer Orders to drive the MPS.
>
>I see that it is the LRDTE field (Request Date) in ECL (Order line file)
>that feeds to the MPS.  The order entry department will back the transit
>(shipping) time from our shipping dock to the customer's location and
>enter that date in the LRDTE field.
>
>The challenge I have is that Shop order due dates, and planned order due
>dates as they appear in the MPS system are the same date as the REQDATE.
>This means that the system won't plan the shop orders to be finished
>till some time during the day that the order is supposed to ship out.
>
>Is the REQDATE really meant to be a "Request to complete manufacturing"
>or a "Request to Ship?"
>
>If it is in fact, a request to complete manufacturing, would I simply back
>the date up by one day. I'd love to hear from other BPCS users as to how
>their system is communicating customer requirements to manufacturing's
>MPS.
>
>Another way I thought I could handle it is by

>adding a 1 day std move time to the last operation.

>But this would mean changing the router of EVERY
>Item and every alternate router as well.
>
>Lead time is for purchase order items, correct?
>
>Also, how are the Schedule Ship Date LSDTE & Schedule Receive Dates
>LSCDT used by the system?

>Should these be updated after an MPS committment? If
>so, by whom?
>
>Thank You!
>
>Paul LaFlamme
>Manager of MIS
>Kennedy Die Castings, Inc.
>508-752-5234 X3044
--