Re: Labor Oops then Purge

Another doubt has come up for which I need to research or clarify.

JIT600 backflushing is from FMA whose quantities needed are based on the
quantity ordered.  Suppose we produce a shop order in excess of the original
MRP ordered quantity, because a customer has requested more quantity but
production control has not maintained the shop orders to sustain the greater
quantity,

will the raw inventory & sub-assemblies backflushed be in proportion to the
quantity reported as manufactured, or
will the backflushing stop at the amounts allocated by the FMA file?

Then suppose AFTER the labor has been keyed in by JIT600 in excess of the
order quantity, production control notices this & increases the shop order
quantity so that it exceeds the quantity produced, will we still have the
problems that

a) the act of producing up to or beyond order quantity caused the shop order
to become coded as completed
b) the excess production consumed material that BPCS did not consume

How do other companies handle this?

Our reality is that we are using clerical people to enter our labor reporting
with the clerical staff shift ending an hour after the factory floor shift,
so that all the work for a factory shift is into the system the same work
day, then next day the factory management are looking at last day's input &
seeing what adjustments are needed, but meanwhile some evenings I have done
shop order purge, so it is too late to make some adjustments to some orders.

I was watching some people entering tickets, because I am trying to help
streamline the process, and I could see that they were taking the defaults
off the inventory backflushing screen & they were getting F13 F14 go arounds
ALL THE TIME which means that the data going in was correct according to the
shop floor, but un excess of what was ordered according to the shop orders.
I was thinking that when they had to take an F13 or F14 (excess quantity
reported) on first screen that perhaps they should have special instructions
how to handle the backflushing screen on those orders, but no it was just get
screen, press enter (taking defaults).  Is that the way other companies
handle this?

===== My Previous Question about this =====

August 10

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 most raw 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

Is there some code in item master that says an item is qualified for "pull
through"?
We might have set up items based on someone understanding that we did not
want this, then corporate memory forgotten that nuance.

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)