× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Al Macintyre again via office PC connection - this e-mail is not from Tim
we are on BPCS 405 CD on AS/436

We have some Shop Orders with the following properties:
Various people think they ought to disappear in the shop order purging & are
asking me why not;
Their quantity manufactured is equal to or exceeds quantity required;
Their raw material issued is equal to or exceeds quantity required;
Their labor on all operations have zero machine or labor run time left to
report.

I suspect too many cooks poorly communicating to each other about unfinished
adjustments, and corporate internal inconsistent practices for cleaning up
shop orders that are candidates for purge, but would like to double check
that I do have my core facts right.

CST900 = what we use for shop order closeout, purge & cost capture.  I have
been running it by facility to try to reduce the likelihood of spool blow-up
due to the high volume number pages generated by CST270.  It is my
understanding that CST900 does not care about any qualifications or
candidacy for purge other than whether or not an order is coded for purge.

Orders normally become coded for purge as a result of labor reporting via
SFC620 or JIT620 if at the time the reported completions equal or exceed the
quantity called for.

Inventory reporting via INV500 or JIT600 does not cause a shop order to
become coded for purge unless labor within JIT600 takes the order over the
required quantity threshhold.

Order maintenance such as SFC540 or JIT510 does not cause an order to become
coded for purge.
e.g. We have an order for 2,000; we produce & report 1,900; the customer now
says they only want 1,750; we change the shop order to only need 1,750; and
the shop order sits open in perpetuity until someone runs a zero labor
quantity transaction hrough SFC620 or JIT620 at which point the labor update
will notice the aggregate labor reporting is greater than what's actually on
order & code this shop order for purge.

Alternatively, an order is coded for purge & someone wants to do more
transactions.
If DFU (or other method) uncodes purge coding, it will remain so until
either someone reverses the DFU flags or labor is reported such that the
aggregate reported exceeds required quantity.

The way you can tell if a shop order is not coded for purge:
Record Ids are
SO in FSO
MA in FMA
OD in FOD
and the FSO status is "E"

Coded for purge has Z in 2nd column of record id
and FSO status is "Y"

Am I mis stating anything?

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.