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
+---
