No matter how hard we try WIP for finished goods on MTO jobs always get’s goofed up. We can have lbr qty of 160 and then 3 WIP qty of 69, 69, and 91 that math’s doesn’t work. Often shipments won’t clear WIP like it should either. Is there any reason we can’t bring MTO finished to inventory bins then ship from inventory bins rather than WIP, then close the jobs.
#WipIsGarbage
I don’t know all the details but we currently put everything to stock then ship from stock. My last company did that too. I am not sure what accounting had to do…I have to think about it.
Is it user error issue? Since we don’t allow overproducing, we have a customization where they can’t enter more than the required quantity (taking into account what has already been reported) this saved us a ton of headaches. But that depends on if you need to be able to report some extra here or there.
Math’s ??? Are you moving to Europe?
That is exactly what we do. We have MTO and MTS. But ship everything from inventory. Keeps things simple for users and stock is more visible since even MTO parts remain in stock for some time before shipment which is typically a few days after it is produced.
The jobs are closed once the entire quantity produced on the job is received into stock.
Works for us.
Vinay Kamboj
.
Are you able to ship that MTO stuff from multiple bins. Shipping is telling me that they can for stock but can only ship from one bin for MTO that doesn’t seem right but worth an ask.
It’s not really though, if I look at job tracker and see 3 labor transactions for 69,69 and 22 then i have this straggler that is 91 in WIP (which is 69 + 22) that makes no sense. I’m sure it’s an order of operations thing, but it should be smarter than that. Epicor lives in a picture perfect world we by no means have that luxury.
Since we are physically shipping multiple truckloads while the job is being produced, Epicor “shipping” is more of a virtual exercise for us. When it’s done it it just goes into Gen1 and get’s shipped from there (usually a quantity of 1). So we don’t have those issues. Different business models. If you are actually needing to locate and put away MTO orders, I think personally I would lean more to make to stock, because that more close matches what you are doing. If you are shipping it right off the assembly line, then the move can be to a generic bin. (and an auto move at that)
Actually 
the moves might be part of what your problems are. We just use auto move for all of our WIP processes. If you are actually moving them with a transaction, things could get goofed up there.
Ain’t that the truth!
It’s not 
We can sit on MTO waiting to ship with other MTO or stock to save on freight. MTO could sit in the warehouse from 1 to 20 days easily. We are very tight on space so moving it around it a necessary Evil. I just recall that 9.05.600 we were told we couldn’t bring MTO into stock it had to be shipped from the job. Either that was true then and is not now, or the consultant was wrong and we just held onto the line of thinking.
That’s correct, except for AMM allows you to “locate” it. It’s not really in stock. Although, you can adjust your order and make it come from stock later if you want. It’s a pain, but you can do it.
One more note on Make to Order and Make to stock. This can be either good or bad, depending on what you want out of your system, but making things to stock will adjust the average price because it’s based on moves in and out of inventory. Make to Order does not.
Another important not about WIP, we basically ignore the WIP information because, “it’s garbage”. If you don’t do the things it the right order it’s hosed. We’ve never had a problem with the WIP clearing though. Although we don’t look that hard either.
We for sure want to make to order to maintain that relationship to the order, but we build everything to standard anyways and calc avgs for our needs later. All good there.
So you are standard costing?
I believe when you do MTO, every piece is costed at standard except for the last piece. The last piece will be costed at standard +/- variances for every piece.
All that is tracking just fine, mostly concerned with the inventory location stuff and shipping constraints right now. Appreciate the input though!
If it is recorded in multiple bins in inventory then we can select them in packing slip.
Vinay Kamboj
We have been receiving MTO parts to stock from our E9 days and then shipping from there. All our parts are avg costed, so that tells us the true cost on the part tracker, which is helpful for pricing and other things.
Vinay Kamboj
Sweet we’ll trial some out and see how it works. I don’t get it WIP seems to work pretty well for raw but finished it’s just a crap shoot. Hoping some creativity cleans things up thanks for the input all.
Are you able to accurately to report on inventory quantity of parts?
I can’t seem to get the WIP calculation right for our pieces to start the inventory process.
I have a part setup, when reporting quantity against it, puts the correct quantity into Inventory but reduces WIP by a different amount. As an example, I’ll report 1 piece (Final Op/Auto Move enabled so no material queue) and 1 piece will go to inventory, but the WIP of the previous part will reduce by 2.
Really is throwing things off, and not entirely sure how to fix it.
Yeah that’s the general type of tom foolery we see, hence why I’m trying to ignore that whole table in whole if I can. No idea how to fix it haven’t really put time into troubleshooting it that’s a black hole I want no part of ha ha
We generally will just looks at completions vs run quantity and display things that way. Instead of trying to to move a part to a place, and see when it gets consumed. If I can simply see that all of the operations have the full qty completed, I call it good to go.
For this system to work with the goofy things that could happen, it would have to allow for negatives (in order to be able to handle things done out of order) and I’m not sure that it does. So I think some of the problems have to do with when it consumes something from a previous operation and when it doesn’t. Maybe not true, but that’s my theory for now.