Re: Backflushing components only

[Al Mac <macwheel99@xxxxxxxxxxx>]

Dan gave you some great guidance.
It is great that you have JIT.  I had not remembered at what version of 
BPCS that got added.
We are on 405 CD and use JIT600 for 95% of our labor reporting.
As for the other 5% ... suppose we discover that something went in wrong 
and we need to make a correction.  JIT600 does not support the concept of 
keying in a negative made or negative scrap.  So when making corrections, 
we often use SFC600 for the labor, and INV500 for the inventory implications.

JIT6* programs are SFC6* under the covers with extra stuff included.  I 
suggest you locate your library of help source and print out for reference, 
since it is not clear on some screens how to get to other screens, such as 
the TEAM screen for example, where you key in a list of employees who 
worked on one product, needing their labor hours shared, but only one 
inventory consequence.

We have modified our JIT6 stuff, to provide more fields of reporting, 
additional checks against improper input, backflush vs. the correct 
warehouse, easier to verify input, and help data entry go much faster.

We report pieces good (made) and pieces scrap.
The good triggers a PR transaction (what was made), on the final operation, 
and CI (components issued) when the operation being reported has BOM to be 
consumed at that operation.
The scrap triggers an RJ reject reference transaction on the parent (no 
change in inventory, just a reference that we had scrap) and CI components 
consumed related to the wastage.
It is not unusual for us to report good made and scrap quantity on the same 
labor ticket.

We run all sorts of reports on this, to show where we have patterns of scrap.

One problem ... the BOM has to have operations in sync with reportable 
routings.  We use additional description, instead of notes, on our labor 
tickets, to guide workers through manufacturing steps.  If the BOM in error 
says to consume one of those additional description operations, or left 
that field blank, JIT600 cannot consume it.  However, the INV500 
transactions that backflush an entire part's components, regardless of 
operation, are not encoumbered by this engineering glitch.

Another problem ... the way BPCS defines an order as being completed is if 
the quantity made plus scrapped equals or exceeds the quantity ordered to 
be made.  Now in our case, when we have some rejects, we immediately make 
more to replace that, so that as the parts move to the next sub-assembly, 
we have no shortage.  But if we do not take action with the shop orders, 
they can get closed prematurely, then when we purge, away goes an order we 
had wanted to report the replacements against.  This can be avoided by 
increasing the order quantity by the amount of the scrap, before the scrap 
labor is keyed in, or by modifying BPCS to have it ignore scrap in this 
calculation.  This scenario can be further complicated if you have scrap at 
more than one operation.

Another problem is how we structure at what operations the raw materials 
are to be consumed.  We deduct the materials at the operations that 
actually consume them, and add inventory back in at the final operation 
that completes the part.  This means that we have high accuracy reliability 
on inventory, provided the labor reporting is complete and timely, but it 
is very disruptive to accounting costs.  In the time frame between raw 
materials going into WIP, and completed parts, our costs of WIP are in like 
an accounting black hole, where it seems like we are throwing costs into 
limbo, then having the costs reappear from nowhere.  Fixing this from an 
accounting cost perspective can be very disruptive to MRP and inventory 
quantities accuracy.

Another problem ... suppose you have operation 100 200, with the scrap at 
operation 200 ... pieces good got the CI at 100, scrap got the CI at 200, 
but our cost attributed to scrap may go into BPCS as what happened at 200, 
not reflecting the now wasted at 100.

Sounds like your user is asking for activity without cost 
implications.  Any action in BPCS carries the cost structure along with the 
item, and our management is extremely interested in the cost implications 
of everything we do.  Is your user request in sync with your company's cost 
management philosophy?

Al Macintyre
Evansville Indiana and Lawrenceville Illinois (near Vincennes IN)

> The other day I had a user ask if it was possible to enter scrap
> transactions that would backflush components only but no labor or overhead.
> There's nothing that I'm aware of in the transaction effect code that would
> accommodate this.  The only thing that I could think of was duplicate parts
> with duplicate bills-of-material and duplicate routings.  I REALLY don't
> want to go down that road because it would be a mess to maintain.  My other
> thought is that if it's work in process there's probably some amount of
> labor and overhead associated with it.  Is it possible to partially scrap a
> finished good at a particular operation in the routing?  The only other
> option that comes to mind is scrapping out the components individually.
> Any thoughts?
>
> We are on 4.02.  Thanks.
>
>
> Dave Parnin
> --
> Nishikawa Standard Company
> Topeka, IN  46571
> daparnin@xxxxxxxxxxxxxx
>
> --
> 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.
>
> Delivered-To: macwheel99@xxxxxxxxxxx