Labor Oops then Purge

A question came up in the last few days, in trying to explain physical 
inventory variances, that I did not feel real comfortable with a simple yes 
or no answer, and for which my digging raised other questions, so perhaps 
someone can get a better answer than I had.

We are on BPCS 405 CD
We by facility
Our applications include SFC JIT INV MRP DRP CAP
We not using PRF Performance Measurement, Outside Operations, Co-Products, or 
Currency modules
Many of our sub-assemblies have several operations

Let's suppose one has operation 100 that consumes materials then operation 
200 that finishes the parts.

Let's suppose the shop floor paperwork on operation 100 got misplaced or 
delayed processing the input to BPCS & only operation 200 got reported to 
BPCS.

Let's suppose operation 200 got entered alleging operation complete
or quantity done (plus scrap) on this last operation equals or exceeds 
quantity ordered

In that scenario,
will BPCS code the shop order as closed,
and will next shop order purge get rid of it,
even though not all FMA's raw materials have been backflush consumed?
or is a shop order not coded as complete until all operations "completed" via 
labor reporting?

My uncertainty includes:

I know CST900 inspects ITH inventory history relevant to the shop order to 
make sure all inventory posted before it purges, but I suspect that's 
receipts, not neccessarily issues.

I know operation reporting out of sequence can trip "pull through" WT & WF 
transactions that assume earlier operations "must" have occurred, even though 
not reported, but I not know if that process also gets corresponding 
consumptions according to operation # in FMA material allocations.

I ran a count of ITH by transaction type
1 million total ITH
33 WF & WT
that sounds like we aint missing much on our scale of
620 thousand CI component issues
assuming I figuring this right

For the most part our WF & WT item/quantity offset each other
Does this mean that if missing operation 100 gets posted before shop order 
purged, we can expect BPCS to somehow recognize it created a simulation 100 
from the 200 and to create a reversal of its earlier simulation, and that it 
might be smart to cycle count items that did not get a reversal?
or am I misinterpreting significance of mismatched WF & WT?

JIT620 documentation SSARUN20 explains pull-through

In the hypothetical scenario I gave of operation 100 consumes raw materials 
but was non-reporting, while op 200 claims completion, this would cause 
material issues to pull through op 100 at standard estimation that must have 
been done to make op 200 work.

However, there is no claim in our BPCS documentation that later reporting of 
the "non reporting" op 100 would cause totals to come out right.

Thus I suspect that our efforts to correct missing postings after order purge 
might be the cause of many variances.

What happens in real life is that the operation 100 labor ticket shows up 
after the shop order is gone, and this stuff needs to be reported, because we 
tracking data by employee & other things.  So the operation 100 labor is 
deliberately reported to the wrong shop order ... another one making the same 
part, because the right shop order is gone.  But the folks making this 
retroactive fix may not be aware of the "pull through" phenomena & not 
properly compensate for it.

Our main problem might be staffing assigned to cleaning up shop orders before 
they get purged, so that missing input can be identified on a timely basis.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)


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