Re: S.O close at BPCS release 6.0.04 -- BPCS-L

We are recent converts to BPCS 405 CD from BPCS on S/36 so our reality might 
not be a good match, but you might consider the following concepts.

If you are going to be modifying shop orders - be sure you get all the 
requisite files & their inter-relationships
FSO FMA FOD 

If you are going to be modifying what happens when there is reporting against 
shop orders - be sure you understand what is happening with SFC JIT & CimPath
There is the risk that modifications for one will be invalidated by what is 
going on in the other software.

CST900 purges shop orders coded complete & updates your costs with whatever 
was reported to those shop orders.  If you do not need to capture costs, then 
use SFC900.

What causes a shop order to become coded complete, so that CST900 will 
actually purge them?  It is the reporting of labor whose aggregate exceeds 
the quantity required.  Sometimes we muck with the shop order coding to block 
the purge, so that addional inventory transactions can go in, such as scrap 
repairs, but then the SO codes say "do not purge this" and someone needs to 
remember to put it back the way it was, or have a report listing candidates 
for maintenance.

We have volatile customers who change dates when they want stuff that is in 
production, so we sometimes have shop orders that are not finished, but we 
want to prematurely close them, without losing the cost data.  On BPCS/36 
when you deleted or killed a shop order, you lost all the data that had been 
reported to it.  I have not yet researched whether this is also true for 
BPCS/400.  

What we did in that scenario was
1. Use SO Maintenance program to down-size the order quantity so it was below 
the work that had been done so far.
2. (only because we had modifications) Enter a zero labor zero inventory 
transaction to run it through all the flags to recognize that this order 
should now be coded for purge.
That can be time consuming.  

An opposite scenario is a customer increasing their requirements & we are 
tempted to increase the quantity needed in the shop order that was released 
due to their earlier quantity requested.  But if the order is already coded 
for purge, this is not a good approach.

Depending on your process of reporting labor & inventory, a shop order may 
become coded for purge when you still have more transactions you want to post 
to it, so there is the need for a mechanism to reverse the coding prior to 
CST900 run.

Other posters to BPCS_L have solved this with outside programs, now on my 
to-do list to write.

I think we need a program like SO Maintenance in which production control 
keys in the order # & if it is closed, it can be re-opened & all FSO FMA FOD 
records in concert, and possibly some variation on MRP250 - if we release new 
shop orders based on revised requirements, also have the option of using the 
MRP process to close out orders that are reccommended for ending, in which we 
could impose some constraints like "do not mess with any orders which have 
had transactions posted to them in the last 48 hours, since they are 
obviously active."

Al Macintyre
Central Industries of Indiana
http://www.cen-elec.com

> Subj:  S.O close at BPCS release 6.0.04
>  From:        tarek.helmy@pharma.Novartis.com
>  
>  I'm using BPCS 6.0.04 release, S.O. closing program CST900, close the 
orders
>  that quantity finished equal or greater than quantity required.
>  And this is not in all cases.
>  Orders not closed increase the work in Process (WIP) and affect the 
planning
>  cycle,  We are updating the order status for such orders by external 
program,
>  Is there any better idea?
>  Tarek
+---
| 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
+---