|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
