Re: Request for SFC600 -- BPCS-L

>  From:    Ralph_Steffen@astamedica.pt
>  Hello, BPCS-Community!

Hello from Al Macintyre - BPCS 405 CD - who first learned the ropes on BPCS/36

>  It might be, that our company only received basic instruction for BPCS
>  version 4.0 level 04 and we are actually changing up to version 6.1, but in
>  the meantime I would like to know, if anyone knows something about the
>  following:
>  We are unable to post the real hours of execution in the different
>  workcenters, because if the posting (SFC600) is not registered (SFC610 and
>  SFC 620) the modified values are canceled. So, only at the end of orders
>  life, the runtimes are registered. That makes no sense for me ! I am
>  convinced that there is a way to proceed.
>  
>  Thanks a lot for ideas,
>  
>  Ralph Steffen @ ASTA Medica

Check LOAD CODE.  Work Centers are coded as being Machines or Humans.  If you 
report your labor with the wrong load code, you just threw away most of your 
transaction.  BPCS does not say "hey, did you make a mistake - did you really 
mean to do this?" or allow for default labor input to the correct load code 
for the work center.

SFC600 creates a batch of transactions, in a work member associated with the 
work station that keyed them in, so you need to keep track of which session 
did which work.  We have had multi-session users lose track of where they 
entered their data.

SFC620 updates shop orders & other files with your batch.  If you have 
multiple people working with the same shop orders, you would be wise for them 
to coordinate their actions.

We have had a scenario in which SFC600 captured perfectly fine labor 
reporting, but the data entry person left the batch open overnight because we 
have a large 1st shift & a small 2nd shift & the data entry person wanted to 
add the 2nd shift work in the morning, so that reports off of that batch 
would get 100% of the day's work in one easy to reference picture.  However, 
in the evening, MIS ran a shop order purge, and one or more of the shop 
orders in the SFC600 batch went away, so that the SFC620 next day ran into 
some serious problems with that input.

SFC610 is an optional edit listing of your input to make sure you got all 
right, but there is also an on-line batch inquiry while you are in SFC600.  
The only reason anyone would want SFC610, in my opinion, is if you have 
modified the reports to get at stuff that is useful at input time & not 
convenient later from labor history.  We are interested in catching labor 
reporting where a person has worked more than 25 hours in a day (when the 
time changes - that day is 25 long), due to wrong date or human spoofing 
their time.  We are interested in percentage scrap by factory machine.  
There's lots of stuff we have added at this point.

If you report your shop orders via JIT, the numbers are the same.
JIT600 enters reporting to a batch.
JIT620 does the updates from the contents of that batch.

SFC620 or JIT620 update the shop orders & output to some history files - 
inventory history, labor history.

At the end of the shop order's life - CST900 shop order purge - the contents 
of the shop order update various master files - work center master - costing 
- some information comes from the history files.  This is more complicated if 
you are using performance measurement.  If you are not using the costing 
module, then SFC900 is safe.

Get to a command line & DSPFFD a layout of what is stored in the major files 
of Shop Orders FSO FOD FMA.  Run query listing data on some order #s before & 
after SFC620.  You will see that there is a lot of useful information there 
related to the management of shop orders, but there is even more destined for 
work centers in the history of the labor tickets, which only gets there if 
the orders are closed normally, as opposed to being canceled.

Thus your actual data is reported & may not be obvious through SFC300 & other 
programs, but it is there, tucked away waiting on normal CST900 closure.

I hope I have grasped what you are asking & given a useful answer.

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