Re: shop floor posting -- BPCS-L

thank you mr macwheel.

you are correct that simply changing the shop order required qty to
match the actual qty produced does not close the shop order. this is a
major mis- perception in our factory. we can use the SFC500 action 21 to
close a shop order, even if the individual operations have not been
closed, but not in all cases. if there is an outside operation on the
shop order you cannot force close it at the shop order level. the
outside operations must be closed and costed before the shop order can
be closed. 

i know enough to figure out the various steps necessary to get these
work orders closed, but it is a complicated navigation process within
bpcs. we're going to have to develop a work order closure process to
make sure we get all of the records in the right status.

also, we do not like to report 'qty bad' because these get booked to
the general ledger at the full value of the parent part that it being
made. we lose a part or two during first article set-up on a machine. we
report that the component part was scrapped, not the end item being
machined.

thanks again for you confirmation of the process.

>>> macwheel99@xxxxxxxxxxx 02/16/04 01:52PM >>>
I can explain how this works in 405 CD

What causes the entire order to be coded as closed is EITHER someone
goes 
into shop order maintenance and force closes it, or the combined labor
and 
inventory reporting equals or exceeds what is needed to make the part. 
If 
you have an almost finished order, and you decide that any more
quantity 
needs to be in a later shop order, then you have a choice of methods to

tell BPCS that you are now done with that order.
    * You can force close the order, which can cause labor variance 
depending on how big the difference between ordered and made.
    * You can alter the order quantity to what was really made, then
report 
a zero transaction to force BPCS to rethink all the flags.
What causes operations to be coded as closed is EITHER someone reports
the 
finished flag, or the quantity posted equals or exceeds what is to be
made, 
at the time of the labor being posted.  If you have a requirement for
100, 
and you post 98, THEN change the requirement to 98, that does not cause

BPCS to recognize that the order is done, but you can then post a 
transaction for zero hours, zero made, zero scrap ... BPCS will process
the 
whop order using the done nothing transaction, and conclude "aha" we
are 
all done here.

We have a shop order for 100 ... we report 98 MADE and 2 SCRAPPED
BPCS consumes the material for 100, receives the inventory for 98, and

codes the order as closed.
Our people not like that because at the moment of scrap, our shop 
floor  REPAIRS the 2 that had to get scrapped, or makes 2 REPLACEMENTS,
so 
we end up reporting 100 made ad 2 scrapped on an order to make 100, and
if 
we have more than one shop order open, BPCS tries to post the excess 
reporting to some other one, and often as not gets it messed up.

We have a shop order for 1000 ... we get 800 done and due to change in

requirements, we only need 800 now, so
    * We use SFC540 to change the shop order to only need 800 (what was
made)
    * We then post a zero transaction via SFC600 ... zero hours, zero
made, 
zero scrap, using a dummy employee # like 99999 to the shop order
It is the act of reporting labor against a shop order, that causes the
shop 
order to be coded finished by BPCS 405 CD and earlier versions, when
that 
reporting process observes that what has been reported so far equals or

exceeds the quantity that is to be made.

It is very important in this scenario to down size the shop order to 
exactly what was made, then post the zero transaction.  Suppose in the

above example the order was down sized to 100, some arbitrary # by
someone 
who just wanted the order closed without having to look up how much has

been made, or track down all labor tickets in process of being 
posted.  When the shop order purges ... the standard would say "We
needed 
to make 100" but the Actual would say "We used enough materials to make

800" which would cause a labor cost variance of that part eight times 
standard, and if that part later used in higher parent parts, they too
get 
contaminated.

We use last cost ... if you use weighted averaging you may be better
off in 
my last scenario.

There's also such a thing as having a modification to get direct access
to 
individual flags, such as reopening closed operations.

Pull through can also complicate this ... look in ITH ... do you have
any 
WF WT transactions?

, you wrote:
>version 6.1
>
>i need some help understanding how SFC650 works. suppose we cut a
work
>order for 100 pieces and suppose somewhere along the way we lose a
>couple so we are only going to get 98 pieces. if we post 98 good the
>operations do not get closed and we only get 98 posted complete to
>inventory leaving a balance of 2 remaining due on the work order. to
>reflect that there are no more coming we change the work order qty to
98
>to match the qty actually produced. but this does not 'close' the
work
>order and the operations are still open and show on the capacity and
>dispatch reports.
>
>we tried to post 98 at each operation with the complete flag set to
yes
>with each posting. this completed each operation and removed the
>remaining load associated with that operation fro the dispatch
reports.
>but it posted 98 to inventory at the last operation but it did not
close
>the work order (even though we said the last operation was complete).
>the only way i can see to get the remaining balance of 2 out or mrp
is
>the manually close the work order also (SFC500 action 21).
>
>is there any way to automatically close the work order using the
>information posted via SFC650 when you are going to get less than the
>required qty?
>_______________________________________________
>This is the SSA's BPCS ERP System (BPCS-L) mailing list
>To post a message email: BPCS-L@xxxxxxxxxxxx 
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/mailman/listinfo/bpcs-l 
>or email: BPCS-L-request@xxxxxxxxxxxx 
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/bpcs-l.
_______________________________________________
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx 
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l 
or email: BPCS-L-request@xxxxxxxxxxxx 
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.