Re: Shop Orders (within a Shop Order) -- BPCS-L

Let's take the first item 064250
Key that (or cut paste) into MRP300, in the facility that you doing this.
Then F13 for pegging, meaning where-used why do we need this item.

If there is a parent part or order, such as a customer order, then the needs of that order is driving when you need the part. MRP300 will also show if the part is needed to replenish minimum balance safety stock.

Depending on product structure, you may need to go higher.
Mouse wipe a parent part from the pegging list, and EDIT COPY it.
Then cursor in item # field we looking into & EDIT PASTE there
Enter then F13 to peg another level up.

Assuming you using the same kind of interface and version as me.

What I see is that the MRP reschedule date is zero on most of the orders.
That means that MRP is happy with the regular schedule & is not making any suggestions.

In our query selection, we exclude from the listing, any in that condition.
We have a separate query to just list those where MRP date is all 9's meaning need to cancel the orders, confiscate the paperwork on shop floor.

You have six shop orders where MRP says not needed for another year.
This is how it works. I don't see anything out of the ordinary here, except when we get reschedule dates it is usually only a few weeks or months difference.

We generally ignore when the change is only a day or two.
We suspect rounding in lead times.
Our past due situation is such that a day or two won't make much difference.

On some queries we are doing date math to get # days difference between two dates, and only list on basis of # days away from current date (the date we ran the query)

I am glad to see that some of my suggestions struck a nerve.
You were able to use my information effectively, in a learning process.

Al,

Does anything stick out here? I pushed the date of the end-item out a
whole year, reran MPS/MRP, now I see that the re-schedule date in the
FSO only shows up on certain shop orders?

S.O. # Item Number Due Reschedule Item
Date Date Type
From MRP
36529 064250 20,090,603 0 B
36530 066025 20,090,603 0 B
36531 400259 20,090,603 0 B
36532 851136 20,090,617 20,100,618 B
36533 855122 20,090,603 0 B
36534 857124 20,090,617 20,100,618 B
36535 859425 20,090,617 20,100,618 A
36536 859426 20,090,601 0 B
36537 859429 20,090,617 20,100,618 B
36538 859430 20,090,617 20,100,618 A
36539 859435 20,090,617 20,100,618 A
36540 859436 20,090,610 0 B
36541 859461 20,090,610 0 B
36542 859462 20,090,610 0 B

Don C

-----Original Message-----
From: bpcs-l-bounces+dcavaiani=amerequip.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+dcavaiani=amerequip.com@xxxxxxxxxxxx] On Behalf
Of macwheel99@xxxxxxxxxx
Sent: Thursday, September 25, 2008 3:26 PM
To: BPCS ERP System
Subject: Re: [BPCS-L] Shop Orders (within a Shop Order)

One thing to watch out for when rescheduling orders, then rerunning MRP.
MRP cannot reschedule when it would make the due dates past due, with
respect to your planning date.
MRP cannot reschedule when the parts involved have effectivity dates
that are invalid in some date range.

The query I described earlier is called MATAVAIL = material availability
with respect to readiness to do next step.

We have another query called ENGRESCH meaning engineering collection ...

need to reschedule production.

It shows
shop order # & item #
Due date from original creation or last change to the order The constant
'-Change to-'
Date recommended by MRP
quantity required
quantity finished

Selection criteria is shop order still open, item type finished product,
date range, facility specified,
SQFIN LT SQREQ (more still to do, ignoring scrap)
MRP date not zero ... when MRP date is zero that means MRP is not
suggesting any change ... when MRP date is all 9's that means MRP thinks
the order should be cancelled

FSO only file needed for on the report, except link to IIM to get item
type

In our reality we make to customer orders which can fluctuate rapidly
with
date due, quantity due, etc. An order is pulled up, delayed ... this
happens after shop orders launched.

The customer order is the highest level of MRP ... change CO & run MRP,
it reccommends date changes for the SO's but does not actually change
those dates ... we have to change them, either manually, or write some
program.

Same deal for lower levels.

But we only change the due date in the FSO, then rerun the MRP.
The dates in the system are now recalculated one level further down.

Main problem is due date on the printed labor tickets.
Changing date in system does not change date originally printed.

We have the added complication that if MRP says do it sooner, we want to
do it sooner, but if MRP says do it later, our people want to decide
that individually, since they may know stuff about raw material
availability where the corrected expected dates have not been keyed into
the PO's, or there may be some temporary shop floor bottleneck.

Because of this we have altered some of the shop floor reportsd that shw
the work still to be done.
In some cases, we are substituting the MRP date for the original due
date.

We have thousands of queries. It can sometimes be a challenge ... we
remember we had a query to do X, what did we call it?

I have a CL to copy directory of query definitions to an *OUTFILE for
yet another query to list them by the description we gave.

Don Cavaiani wrote
> Al,
>
> Looks like, in my testing, that once a S.O. is created, nothing you do

> DATE WISE on any other screens (and followed by MPS and MRP
> regenerations) will CHANGE the due dates of the S.O.'s and the
> Material Allocations file. It would take a manual intervention on
> each and every related S.O. # to change the dates due.
>
> Don
>
> -----Original Message-----
> From: bpcs-l-bounces+dcavaiani=amerequip.com@xxxxxxxxxxxx
> [mailto:bpcs-l-bounces+dcavaiani=amerequip.com@xxxxxxxxxxxx] On Behalf

> Of macwheel99@xxxxxxxxxx Sent: Wednesday, September 24, 2008
> 2:08 PM To: BPCS ERP System Subject: Re: [BPCS-L] Shop Orders (within
> a Shop Order)
>
> We have a similar situation.
>
> The people in Assembly are organized into teams around what we call a
> "wheel" where maybe 10 people each doing their thing on a panel that
> comes around slowly, combining maybe 20 sub-components into a combined

> upper level part.
>
> The person who is setting up a wheel to do some part, that person
> wants to be sure that we have everything feady ... they key in the
> shop order for the part to be assembled. This links to the FMA file
> of that shop order, which lists all the compoenent items going into
> that part, for which we can get at the on-hand of those componennts in

> the right warehouse, and for the components where the on-hand is
> insufficient, access any open shop order to make that component, as
> identified by the FSO file, then bring up details on that shop order.

> The leader of the assembly operation can then use that to track down
> how soon we will be done with those shop orders, or select some other
> part to assemble soon.
>
> We have a CL to put queries/400 on a menu ... you do not have to give
> people command line authority to run a query/400 definition.
>
> Here's how our query combines files FMA FSO IIM FOD in 405CD
>
> Field Test Field
> MPROD EQ IPROD
> MORD EQ SORD
> MPROD EQ ODPRD
>
> Here's corporate IIM on-hand, but you could go after relevant
warehouse
> OH iADJ+iRCT+iOPB-iISS
>
> Here's what is still to be made on the lower level parts
> NEEDED mqreq- mqiss
>
> Here are the fields selected for the query/400 inquiry The files are
> 1.FMA 2.FSO 3.IIM 4.FOD
>
> Field
> T01.MORD
> T02.SPROD
> T01.MPROD
> T03.IDESC
> NEEDED
> QP
> OH
> T04.OORD
> T04.OQTY
> T04.OOPNO
> T04.OOPDS
> T04.ODEPT
> T04.OQTYP
>
> Selection criteria
>
> AND/OR Field Test Value (Field, Number,
> SPROD EQ 'Enter Part Number'
> AND SID NE 'SZ'
> AND NEEDED GT OH
> AND ODID EQ 'OD'
>
> Hope this gets you a chunk of the way to a solution.
>
> As for rescheduling ... when shop orders are released, they get a
> planning date based on time of launching. If at a later date, you
> change the upper level due date & rerun MRP, it recalculates MRP date
> only one level down, so we have reports listing shop orders where the
> MRP recalculated date says to do something sooner, later, cancel,
> whatever, so that people then have the option of going down one level
> & doing maintenance to agree with the MRP advice, or removing from
> shop floor those orders that MRP says we do not need any more.
>
> All orders below customer orders, such as purchase orders, have the
> original date we planned, or changed to, and the MRP recalculated date

> based on other stuff going on in the system. We have date math, in
> which we are not interested in MRP changes of only a day or two, only
> when the rescheduling is significant.
>
> Al Macintyre
> who uses Query/400 a lot because most managers & users want new stuff
> setup yesterday & are quite happy to get quick & dirty, irrespective
> of performance & other issues
>
> Don Cavaiani wrote
> > Anyone dealt with this issue:
> >
> > The system generates a shop order for a Manufactured (welded)
> > assembly. At the same time, it also generates say 15 other shop
> > orders for the fabrication of the manufactured components which GO
> > INTO the this upper level (welded) assembly.
> >
> > Now, for whatever reason - say a shortage of a purchased component,
> > the scheduler wants to "back-off" the scheduled due date of the
> > (welded) assembly.
> >
> > If this is done via the system, then MAYBE it reschedules all of the

> > Shop Orders for all of the manufactured components as well??
> >
> > But, let's say the scheduler just wants to immediately pull that
> > (welded) Assembly out of the actual production pipeline, along with
> > all of the shop orders for all of the manufactured parts as well.
> >
> > Is there anyone who has a developed a query or some other method of
> > LINKING all of the 15 manufactured parts shop orders to the (welded)

> > assembly shop order?
> >
> > Seems like it would not be that difficult?
> >
> > Thanks,
> > Don C.
> >
> > 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 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@xxxxxxxxxx
>
> --
> WOW! Homepage (http://www.wowway.com)
>
> --
> This is the 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: dcavaiani@xxxxxxxxxxxxx
> --
> This is the 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@xxxxxxxxxx

--
WOW! Homepage (http://www.wowway.com)

--
This is the 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: dcavaiani@xxxxxxxxxxxxx
--
This is the 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@xxxxxxxxxx