RE: Padding BPCS Fields

Hi Al,

That's a good thought, but I don't want to add another operation that we
have to post to or call complete to get the shop order to close. If I make
it a non reportable operation (description only) then it wouldn't use my
"padding" in planning.

Thanks,

Paul

-----Original Message-----
From: bpcs-l-admin@midrange.com [mailto:bpcs-l-admin@midrange.com]On
Behalf Of Al Mac
Sent: Saturday, December 21, 2002 1:08 PM
To: bpcs-l@midrange.com
Subject: RE: Padding BPCS Fields


Summary
=======
We use operation 999 exclusively for final operation of end customer parts
for special purposes that would work for Paul's needs.  It is a NO
OPERATION which means no one in the factory needs to do anything for
operation 999.  You can set it to CONSUME ONE DAY, so that BPCS will
schedule everything else that is to be done to complete the day before the
day of shipping.

Once you have operation 999 seeded in all your end customer parts, it will
be very simple to later change the rules if ONE DAY is no longer what
management wants.

Detail story
========
As I have stated before, our end items that we sell customers all have a
final operation 999 for the purpose of some end of production clean up ...
different reasons than Paul but similar solution.

Down side of this is someone does need to make final transaction post to
operation 999 ... pack ship check A-Ok ... our production manager uses
SFC600 for this ... it is an operation calling for zero materials, zero
labor or machine time.

In our case we not want shop order purged prematurely ... there is
sometimes some clean up adjustment needed.  But it also makes blanket adj
fix it program easy.

Suppose we wanted to make 100% of operation 999 a standard move or queue
time of 1 day or 1/2 a day ... very simple RPG program vs. FRT file whose
operation is 999 ... alternatively we could have a different rule by
facility ... plus we have populated some other fields of other files so we
could look up what customer we make this for, complexity of wiring harness
... populate some differently according to business rules.

In your case, if you not yet have such an operation, and have to add it, I
strongly suggest you do like we have done ... operation 999 is exclusively
for this purpose, so that future fix it programs simplified.  Otherwise the
program would have to read item master plus routings to determine only
those items that are end items, get at only the operation that is the last
operation & in our case we use op status 3 additional description ... there
are logicals that access only the lines that have work centers, excluding
the additional notes stuff & it might be smart to have one that does
operations in reverse sequence for ease of accessing only the last
operation.

All of our operation 999's use the main assembly work center of the
corresponding facility.  I guess they could use a work center unique to
operation 999.  I not know work centers well enough to know if you could
slip a one day queue in there.  If so, then when changing the rules, there
would be just the one place to do it, no programming needed.

I am an RPG programmer, but right now I feeling a bit lazy (scrambling with
lots to do at my day job).
It can also be done with SQL.  Since I on the same version of BPCS as you
(405) except for facilities, I could send you some code to try out ... you
would need to TEST it in test environment since my programs not always work
perfect on first go.  Any number of other people can also do this for you.

I am not as sharp on SQL as I am on RPG.
I suspect it can be done with a single line of SQL code, but woe betide you
if you do el typo while keying an SQL command line.

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

>Hi Al,
>
>You wrote: "You might want something like that in FRT, but first look at
the
>lead time fields in IIM."
>
>The reason I don't think lead time will work for me is the shop order due
>date is equaling the LRDTE even with data in the lead time field of IIM.
The
>CIC file is not relevant because I'm not planning by facility.
>
>We've used fix-it programs like you've described, but the trick here would
>be that it must update only the last operation of every finished item's
>router. I'm sure an RPG programmer could do it (I'm not an RPG programmer).
>
>Paul
>
>-----Original Message-----
>From: Al Mac
>
>--
>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
>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

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