Re: 405 Shop Order Close -- BPCS-L

> Subj:  Shop Order Close
>  From:        abney@iquest.net (Lisa Abney)
  
>  We're on version 4.0.5, and would sure appreciate some help with the shop
>  order close process.  We went up on BPCS in March '95, and were told at 
that
>  time by our consultants not to run Shop Order Close (CST900, as we have
>  costing installed), as we wouldn't be able to make adjustments to shop
>  orders.  

In earlier versions of BPCS, it was SFC900 you were not supposed to run by 
itself, since embedded in CST900 it closed out shop orders after updating the 
costs, while if you ran SFC900 by itself, you got no costing updates.  We are 
able to make adjustments to shop orders via SFC540 & other means, the problem 
is only in those orders that BPCS thinks are finished.

>  Now, I'm sure they meant that to be a temporary thing, as we went
>  through the initial learning process, but 4 1/2 years later, we still
>  haven't done it!

We went live on BPCS 405 CD August 1998 & delayed running CST900 the first 
few months due to some problems I have not yet fixed, but it became 
neccessary to run it & we do so approx once a week, while I wade through a 
mountain of fixes desired by sundry users.

I load this to the JOBQ with MRP500 & MRP600 for the respective facilities 
loaded behind it - you do not want to be doing the MRP before CST900.

Depending on time availability, you probably also want to run SYS120 ASAP 
afterwards on FSO FOD FMA

One problem = blow up the spool file with reports no one has time to dig 
through, so we have to run it one facility at a time, then kill the 10,000 
pages on each one.

We report labor by both SFC600 series & JIT600 series --- JIT is normally 
used for most transactions, with SFC for cleanup when orders need it.

Another problem, which may be unique to Central Industries.
We manufacture operations in an overlapping fashion - when one step is 
partially completed, its output goes to the next operation to start work, and 
we are not using data collection so sometimes the labor tickets for the 3rd 
operation are being keyed in before anything is reported to the computer on 
the 1st operation.  This causes BPCS to make certain assumptions about the 
labor that was not reported, then that labor comes along & I suspect the info 
is duplicated, leading to premature claim of labor completion.

CST900 purges all orders whose FSO is coded for LABOR complete, irrespective 
of INVENTORY reporting, when we would prefer the opposite scenario, so the 
production control people run a query listing shop orders coded LABOR 
complete, for which the inventory is not yet all done, and they either chase 
down the transactions, or use DFU to flip the flag to not complete so that 
CST900 won't wipe it out.

>  The biggest reason we need to do it, we've discovered, is that we would 
like
>  to do some clean-up in our item master, but you can't inactivate an item
>  master that has a shop order.

You might also have some problems with routings & BOM & other areas impacted 
by those open shop orders.

>  I called the SSA help desk on this, and they warned me this may take in the
>  neighborhood of days (or weeks?!) to run the first time, as we have 220,000
>  records in the FSO file.  (He said most people run this process at least
>  weekly ... whoops!)

Although we run this by facility, it can also be run by other ranges --- I 
suggest you call up the prompt screen, without running CST900 & check out 
what I mean, then get some FSO statistics & think in terms of getting the job 
done on a different portion of your total data base over an extended time 
period.
  
>  I've played around with this in a test envionment, and it's going to be a
>  real pain, I can tell.  We also have performance measurement installed
>  (although we've never used), which apparently means I have to close each
>  period for each facility individually before I can even do CST900.
>  
>  Does anyone have an easy solution?  All I really care about is cleaning up
>  my FSO (and, I suppose, the FMA) so that I will be able to inactivate some
>  item numbers ... I don't care about performance measurement, the costing
>  stuff, etc.

When we do our physical inventory, we deliberately clear FSO FMA FOD, then 
after the physical is all done, we run full MRP regen & re-release new shop 
orders based on the new reality.  However, this killing of shop orders is 
only after CST900 on as much as possible, because those records have captured 
actual cost information that you sure might want to have in your cost files.

I suggest you ask the help line what the consequences would be of clearning 
FSO FMA FOD & restarting your shop orders from scratch.

If in fact you don't care about the data that is there, such as 
work-in-process, this would seem like a logical approach.  You will need to 
do some reorg like ELA file & what the totals are of the current orders, and 
be very careful about any adjustments to system parameters to avoid FLT 
merger of history, and might look into the practicality of downsizing some 
files.

Martha wrote

> Our wrinkle was that Operations Managers still wanted to be able to 
> view closed shop orders on-line for awhile after they were closed 
> and the nightly CST900 would purge them.  

One of the modifications asked of me is to delay orders being coded for purge
until several days have gone by from when BPCS thinks the job is finished, to 
allow time for any corrections to get in --- I suggested that Production 
Control use SFC540 to jack up the quantity to be produced to a bit more than 
we really plan to produce, then downsize the required quantity when they are 
ready for the orders to actually purge, but they did not like this since it 
gives a false picture to the people trying to produce the orders that are 
really finished.

Bill wrote

> We have set up a job to reopen closed shop orders for this purpose, 

Does your job update only FSO or what?

> only certain users are allowed to do it 

Our modifications use the BPCS security prefixes to control who is authorized 
to categories of updates.

> and no one gets to do it if the S/O was closed in a prior period.

We have been running CST900 helter-skelter relative to end-of-month, 
because there will always be transactions that do not get into the system
for the past month, until after the end-of-month processing was completed.
This is a concept that a lot of people who run reports listing labor just 
cannot
seem to grasp, with vast numbers of reports incomplete almost by definition.

> Regarding the statement about how long it will take to close these orders, 
> it may be a little misleading.  You see, unless you have made the mod's
> to SFC900, it reads through every S/O whether it was previously closed or 
not.

Thanks for the idea

Al Macintyre
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---