Re: Keep sequence of labour tickets in S.O.

[MacWheel99@xxxxxxx]

>From Al Macintyre BPCS 405 CD AS400

> Subj:  Keep sequence of labour tickets in S.O.
>  From:    hason@pbsvb.cz (PBS Velka Bites, a.s. - AIS)
>  
>  BPCS v.6.0.04 AS400

Have you modified shop orders or are you running vanilla?
What SFC-related modules are you using in conjunction with SFC?
CIM INV JIT MRP PRF SFC 

>  We are looking for parameter setting to keep sequence of labour tickets
>  according to operation nr in shop orders.
We do not have this problem, but then we are heavily modified
The file FOD has logicals keyed on So# then Operation#

>  Second question:
>  Is it possible not to allow receipt to stock from a shop order until
>  posting all labour tickets (FOD.ORUN=FOD.ORUNP & FOD.OSET=FOD.OSETP)?
Depending on what kind of reporting you do, there may be some other fields 
... RUN is the human labor ... we also have reporting on automated factory 
machines.
  
>  Any experiences?
>  
>  Thanks in advance
>           Otto

Our recent interest & experience is somewhat the opposite of yours, but we 
did do something similar when we were on BPCS/36.

One challenge is that labor reporting drives shop order purging ... as soon 
as all the operations have got their act together from a labor reporting 
perspective, SSA deems the time right for that shop order to disappear in the 
normal shop order purge cycle, even if the inventory transactions are not 
complete up-to-date, so if you want to delay inventory input for some reason, 
you will need to scramble when the labor is all in, or risk losing a key 
window of opportunity.

Currently we are using JIT6* very heavily, in which the inventory is consumed 
in sync with the labor reporting.  On BPCS/36 we had to do SFC6* for the 
labor and INV5* for the inventory sides of shop floor reporting, which was 
deemed as being duplicate entry work, so we wrote a modification called 
"Backflushing from Labor" in which the labor history transactions between 
some date range were used to compute the inventory transactions that must 
have been involved in doing that labor & this was usually done each evening 
for the prior day's input - Mondays we did it for thru the weekend just in 
case someone worked the weekend.  This Backflushing was done before any 
Purging.

There were some complications - we had to modify the whole purge cycle to 
block purging until the inventory was satisfactory.  We had added fields to 
the file layouts to include stuff that is now on BPCS 405 but was not on 
BPCS/36, to say WHO did this transaction (user sign on) and WHEN was it 
entered (system date of keying) not when they said the transaction occurred.  
I thought some people were getting confused which date to use in which 
circumstances.

Eventually we abandoned the Backflushing from Labor because we found we had 
serious reporting problems with the labor compared to the accuracy of the 
inventory control clerks, at which point we only used the portion that was 
Backflushing Scrap reporting.

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