Don,
You asked two questions-- I will give to the short answer to the questions
1- Planned orders as well as shop orders are backwards scheduled. If you do finite forward scheduling based upon the shop orders that you generate you then will see if you have enough capacity available to produce the orders within the promised dates. The finite forward scheduling is different then the shop orders that you placed because it is an additional process.
2- Firm planned orders are planned orders that will not move in date or quantity when you regenerate MPS/MRP. In other words it frezes the planned order. BPCS has that function. The firm planned order continues to explode down to the necessary components and place gross requirements on those components. The shop order, once placed, does not explode down to the lower level of the components. The shop order should reserve those components so they can not be used for other products. Firm planned orders are much different process then shop orders.
Those are the answers to your questions.
Regards,. Bihun MBA, CFPIM
Matthews MacKenizetabihun@xxxxxxxxxxx> From: bpcs-l-request@xxxxxxxxxxxx> Subject: BPCS-L Digest, Vol 5, Issue 173> To: bpcs-l@xxxxxxxxxxxx> Date: Sat, 6 Oct 2007 12:00:01 -0500> > Send BPCS-L mailing list submissions to> bpcs-l@xxxxxxxxxxxx> > To subscribe or unsubscribe via the World Wide Web, visit>
http://lists.midrange.com/mailman/listinfo/bpcs-l> or, via email, send a message with subject or body 'help' to> bpcs-l-request@xxxxxxxxxxxx> > You can reach the person managing the list at> bpcs-l-owner@xxxxxxxxxxxx> > When replying, please edit your Subject line so it is more specific> than "Re: Contents of BPCS-L digest..."> > > *** NOTE: When replying to this digest message, PLEASE remove all text unrelated to your reply and change the subject line so it is meaningful.> > Today's Topics:> > 1. FW: Sandbox Warrior Team Meeting- fwd. vs backward schedueing> (Don Cavaiani)> 2. Re: FW: Sandbox Warrior Team Meeting- fwd. vs backward> schedueing (Al Mac)> 3. Re: We are plugging Lead Times (Al Mac)> > > ----------------------------------------------------------------------> > message: 1> date: Fri, 5 Oct 2007 18:38:23 -0500> from: "Don Cavaiani" <dcavaiani@xxxxxxxxxxxxx>> subject: [BPCS-L] FW: Sandbox Warrior Team Meeting- fwd. vs backward> schedueing> > This is fairly complicated - please comment if you would.> > Thanks,> Don> > ________________________________> > From: John Campbell > Sent: Friday, October 05, 2007 3:54 PM> To: Don Cavaiani> Cc: Tina Hartmann; Doug Thompson> Subject: Sandbox Warrior Team Meeting> > > Don, the following two questions were raised during our last Sandbox> Warrior Team Meeting:> > > 1. I thought that backward scheduling was always the norm when that> respective parameter was selected whether it's a shop order or planned> order. According to some of our team members shop orders are backward> scheduled however, planned orders are forward scheduled. Could you> please clarify or present this question to your friends on the BPCS> consortium?> > 2. What are our options within BPCS to enable us to add firm planned> orders? Can we substitute a firm planned order rather than a shop order> if we want to? Could you please clarify or present this question to your> friends on the BPCS consortium?> > Thanks in advance,> > John W. Campbell, CPIM> Purchasing Manager> Amerequip Corporation> 1015 Calumet Avenue> Kiel, WI 53042-9624> Tel: (920) 894-7063 Ext. 309> Fax: (920) 894-3799> jcampbell@xxxxxxxxxxxxx> > > > ------------------------------> > message: 2> date: Sat, 06 Oct 2007 01:43:36 -0500> from: Al Mac <macwheel99@xxxxxxxxxxx>> subject: Re: [BPCS-L] FW: Sandbox Warrior Team Meeting- fwd. vs> backward schedueing> > It has been a while since I studied the relevant documentation, so > hopefully someone else can give you a better answer, but it might be until > some time next week.> > We don't use firm planned orders. The act of releasing a shop order or a > purchase order is like having a firm planned order. We went this route > because the company was trying to keep clerical person costs to a minimum.> > My understanding is that a firm planned order is an optional step between > independent demand, and the orders that get the job done. You still need > the latter, unless you don't care about some stuff we care about.> > For example, suppose you "create" some part without going through a shop > order, which you can do via INV500 transactions to add the made part, and > consume the raw materials. In the absense of shop order to a conclusion > (hey don't delete it), the actual cost will never trickle up to the end items.> > This is important to us because some of our raw material components are > like gasoline pricing on steroids, We need to have rapid access to knowing > what end item profits have been adversely affected by fluctuations in raw > material pricing.> > However, an alternative:> Create a new cost set ... call it TRUE COST or whatever floats your boat.> Zero out everything in that cost set if you previously used it for > something else> Copy 100% of your material costs & whatever else is important to TRUE COST> Do a standard cost rollup of TRUE COST.> You now have an actual cost that does not have to wait on shop orders to > make all the parts, then get purged, or deal with parts that you "made" > without using shop orders.> You can NOT copy TRUE COST back into actual cost.> > Note that BPCS has no provision to get rid of a cost set when you are done > with it, but UPI has an archiving product called Locksmith, that can do > this for you, amontg other things.> > We have been running into problems with customers expecting shorter and > shorter lead times on new parts, which can overwhelm our engineers in > setting up BOM & routings. We get the BOM in first, so new customer orders > can trigger purchase of raw materials before the routings completed. But > we have to be careful with effectivity dates ... BPCS defaults them to date > they go in, but MRP does not back plan new orders into a date that is > ineffective or past due on arrival.> > We get some compensation for this by having safety stock early.> > Also as year end approaches, there is high risk that people who have been > keying in 07 for year all year, will forget to key in 08 for year.> > Commodity Pricing and Nulls are royal pains. This weekend I am reverse > engineering vendor freight expenses to end customer items. The path is > rather snakey.> > We have rather long lead times (over a month) on some raw materials, and we > have some customers that change their requirements on short notice, which > means MRP replans when stuff is due. There is a field in the orders that > has the MRP reschedule date ... we run reports to identify orders where MRP > is telling us to pull up previously released orders to do them sooner.> > MRP only does this one level down ... so we use the report to adjust due > dates on parent items, then after another MRP, go again for the next level > down.> > There's been discussion about automating this, but no, people need to see > the data, to review glitches and exceptions.> > We created a report to compare vendor history with planned lead times to > identify items where the lead times were out of sync with vendor behavior.> > The on-line documentation from BPCS is like a sledge hammer across the > brain to comprehend ... I suggest you tackle it a little at a > time. Instead of using the front end, we go in with PDM against file > BPCSDOC in library *LIBL. If you can afford it, there are some great 3rd > party manuals for BPCS, with pricing starting around $250.00 each.> > On more than one occasion, there has been a significant difference of > memory between me and co-workers on exactly what is going on various > places, such as with planning, expected costs, whether various things can > happen (like we are able to (accidentally) pay for a PO that we never > received), so we come up with tests to figure out exactly what is going on.> > BPCS does support various simulations and test environment, but if you are > having trouble understanding what's going on in the regular data, this > stuff is not very helpful.> > There are a gazillion codes for items in IIM item master and CIC item > facility planning file. When keying in new items, BPCS defaults to some > values which may be contrary to your company's standards, and easy for some > people to overlook. We have created some programs that do mass updates of > our items to enforce some rules, and thus reduce hassle for data > entry. You might want to review your in-house rules, to make sure you are > not getting some items not setup quite right.> > For example, we report labor using JIT600 because it combines SFC600 with > INV500 ... lots more results with less keying. But there are some > gotchas. BPCS lets us create BOM that does not identify routing operation > where some part is used ... well if we individually report each operation, > none of which match some component in the BOM, then the component item is > never backflushed, to the detriment of inventory accuracy. So you have to > know how to root out glitches in your total data.> > There may be variables in the system parameters, that vary with the version.> > I suggest you run SYS800, screen print every screen, and make them > available for various people review "What does this mean?" but don't change > anything until you have studied what it means. BPCS Security is rather > tight on the BPCS Business Rules, but you can also access a lot via > Query/400 vs. ZPA file. Remember that BPCS Business Rules are actually > located in several different places, including Transaction Effects, and > Accounting.> > In our setup, the shop orders have several collection points, in which the > first operations can need to be done a day or so before the later > operations, based on BPCS calculation how long all the steps will > take. The final operation is due when the next level needs the part, so I > figure OUR shop orders are being backward scheduled.> > We use 405 CD to manufacture wiring harnesses for OEMs.> I hope my remarks have been somewhat helpful.> Al Macintyre ... Computer Janitor, programmer, data forensics> > >This is fairly complicated - please comment if you would.> >> >Thanks,> >Don> >> >________________________________> >> >From: John Campbell> >Sent: Friday, October 05, 2007 3:54 PM> >To: Don Cavaiani> >Cc: Tina Hartmann; Doug Thompson> >Subject: Sandbox Warrior Team Meeting> >> >> >Don, the following two questions were raised during our last Sandbox> >Warrior Team Meeting:> >> >> >1. I thought that backward scheduling was always the norm when that> >respective parameter was selected whether it's a shop order or planned> >order. According to some of our team members shop orders are backward> >scheduled however, planned orders are forward scheduled. Could you> >please clarify or present this question to your friends on the BPCS> >consortium?> >> >2. What are our options within BPCS to enable us to add firm planned> >orders? Can we substitute a firm planned order rather than a shop order> >if we want to? Could you please clarify or present this question to your> >friends on the BPCS consortium?> >> >Thanks in advance,> >> >John W. Campbell, CPIM> >Purchasing Manager> >Amerequip Corporation> >1015 Calumet Avenue> >Kiel, WI 53042-9624> >Tel: (920) 894-7063 Ext. 309> >Fax: (920) 894-3799> >jcampbell@xxxxxxxxxxxxx> >> >--> >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> > > > > ------------------------------> > message: 3> date: Sat, 06 Oct 2007 01:55:59 -0500> from: Al Mac <macwheel99@xxxxxxxxxxx>> subject: Re: [BPCS-L] We are plugging Lead Times> > We have done something similar, perhaps not as complicated.> > We had to think through ... how to undo this later if there are unintended > consequences ... someone did not realize some consequence, and now they > want stuff put back the way it was.> > Some stuff I have not yet figured out how to undo ... for example ... we > came up with a system for planner codes based on combination of customer # > and item class, then after updating end item, cascaded the same planner > code down the BOM which includes some sub-assemblies common to different > planner codes. We don't want to undo everything, just part of it.> > We allowed for exceptions. Basically there was an "old rule" and a "new > rule" in the mass update program collection.> (actually a collection of rules for various combinations of item type and > class)> > If the content of some item did not agree with the "old rule" we make the > assumption, that some human being, who knew what they were doing, figured > some exception to the rules for that item, so do not mass update replace > that. Audit trail identify such items for review.> > If later you need to update some item, remember that updating IIM does not > automatically replace CIC story.> > Al Macintyre> BPCS Guru (the hard way ... by immersion ... sink or swim)> > >After a group study of this issue, we will be UPDATING our Lead Times > >(Based on the total of MOVE + QUEUE times, on ACTIVE Operations, and > >taking into account the AFFECTIVITY dates).> >> >The rules are:> >> >On active and effective Routing operations only - sum up the MOVE + QUEUE > >times> >For Item types (A and B only)> >Plug this new L/T into the Item Master Lead Time - ILEAD> >Plug this new L/T into the Facility master Lead Time - ICLEAD> >> >THE NEW Calculated LEAD TIME WILL BE PLUGGED INTO EACH OF THE ABOVE LEAD > >TIME FIELDS.> >-------------------------------------------------------------------------------------------------------------------------------------------------------> >Anyone care to comment on the validity of this (before we actually do it)?> >> >> >> >Don F. Cavaiani> >IT Manager> >Amerequip Corp.> >920-894-7063> >> >"It's amazing what you can accomplish if you don't care who gets the > >credit." Harry S. Truman> >> >> >> >--> >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> > > > > ------------------------------> > -- > This is the SSA's BPCS ERP System (BPCS-L) digest 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.> > > > End of BPCS-L Digest, Vol 5, Issue 173> **************************************
midrange.com
