Re: 405 CD FOD.TOCMP "Y" Complete Shop Order Operation

>  We have similar problems with BPCS operations marked complete 
>  " accidentally ".
>  What we do have as well is operations marked complete 
>  without any labour transactions done at all. 
>  We can release a shop order one day and the next day 
>  operations are marked complete on the work centre schedule. 

These operations that mysteriously got marked "complete" by accident.
Do you check history in FLT file on the shop orders involved to find out if 
there was any labor transaction on them?
If you find such postings, do you check the original labor tickets they came 
from & the edit lists of human data entry to find out if they were keyed 
correctly but changed in the JIT620 SFC620 job stream?  We have found that if 
we over-report labor to a shop order, BPCS automatically transfers the ticket 
to some other open shop order on same item/warehouse, if any is available, to 
spread the work around.  We are able to confirm this was not a keying error 
by seeing it correctly posted in the JIT610 SFC610 edit listings but wrong in 
the JIT620 SFC620 job stream.

The most agregious for us is when it is scrap that tips the order over the 
quantity required.  The way we handle scrap is to repair / replace the 
operational imperatives AT THE TIME OF THE PRODUCTION so that what we produce 
is precisely what is called for, but BPCS treats scrap as something that is 
to be replaced later.

Now let's suppose we have a final labor reporting on a shop order, which 
includes both the quantity that takes it over the quantity required, by the 
amount of the scrap, and also we say this is completed operation.  BPCS will 
post this to some other order that is open & say it is completed instead.

What we need is some clue at the JIT600 SFC600 input screen point that some 
input is at risk of this happening & an option to increase the order quantity 
to accommodate both the completed & scrapped, or alter the BPCS substitution 
rules to exclude scrap.  I think that belongs in SYS800 so that companies 
would have the option of including or excluding scrap from this equation.

A phenomena I have noticed is that some people use as a technique to verify 
their input by looking for the resulting transactions, and if they cannot 
find them, rekey them as if the original input did not exist.

You see that in physical inventory tags for example, or bogus costs.
Someone was keying something legitimate, put it on a wrong customer #, or 
item #, or facility, then could not find it in the right one, and rekeyed it 
correctly, but now you have the bad input being processed because BPCS cannot 
tell the difference.

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