We have looked into this sort of thing many many years ago, with 405 CD, and
with earlier versions. I do not recall the premature "MZ" condition. In my
memory, if shop order purge determined that an order was unfinished, no part
of the order got coded as completed by the purge.

We run shop order purge at end-week, via CST900 which calls several
sub-programs. Consequently we NEVER call SFC900 directly.

It is not unusual for BPCS to do math "greater than zero" not properly
processing any "less than zero" condition. For example, negative on-hand
can cause improper MRP demands to manufacture to bring the quantity up to

We are aware that many places in BPCS there can be incorrect totals
calculated, such as when some fields should have been driven negative, due
to float in labor reporting (the manufacture of an assembly uses a lower
shop order # than multiple manufactured sub-assemblies of that assembly due
to how our parts are #d and how shop order#s are issued), but not all BPCS
processes properly process negatives.

If there are some holes in the reporting of labor against some shop order
that some person might think is completed, such as not properly reporting
scrap, or claiming the labor reporting is completed, but not having issued
all the material involved, we don't want the shop order taken to a
conclusion and purged, until our inventory is correctly and completely
updated. Thus a shop order against which someone has reported labor
completed, is not in fact completed until all the inventory reporting is

If there is inventory still to be issued then the "allocated to orders"
field should already correctly reflect both this requirements, and any
others already in our system. If a shop order is force closed, I am not
sure whether that action subtracts any requirements, or whether the clean up
occurs at shop order purge time.

There's a query we run after shop order purge that lists orders coded as
labor completed, but not removed by the purge, showing inventory
requirements. In some cases it is obvious the labor completed was reported
in error. In other cases, the order is 99% completed, so I suggest
downsizing the quantity to make, to agree with the quantity actually made,
then run a zero labor quantity report on the lowest operation, so that the
order will be recalculated as Ok to purge.

Al Mac
-----Original Message-----
From: bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx] On Behalf Of
Bailey, Dick
Sent: Wednesday, June 30, 2010 10:50 AM
To: BPCS ERP System
Subject: [BPCS-L] FMA file Record Closing

We are in BPCS, having converted four months ago from an earlier version.

We have found that program SFC900B, at month-end, goes through these steps,
after determining that a shop order has been reported complete:

* It reads through the FMA file for the shop order number.
* Calculates the difference between the quantity required (MQREQ) and
the quantity issued (MQISS).
* If the result is greater than zero, it updates the "Allocated to
Product Orders" (IPRDA) field in IIM for the component.
* It also updates the "Allocated to Orders" (WCUSA) field in the IWI
* It then updates the FMA record id field (MID) with "MZ".

This makes no sense to me. If the component record shows that we have not
yet issued all the parts required, the record should stay open until it is
fixed. Correspondingly, if the record is inactive, the allocation does not
belong in the allocation totals, which then do not match the orders screen
in INV300 inquiry.

Has anyone else noticed this problem? Am I wrong in my analysis or

Dick Bailey

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-2021 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.