We are a mid-side manufacturing company implementing Epicor Kinetic in a few months. We are currently using a different (much older) ERP system. I found a few posts on this forum related to auto-consume stock but did not find something directly related to the issue we are seeing.
In our old system today we have phantom parts that are completed within the same method. For example a purchased ring (Part D) that has two surfaces machined at one level (Part C), holes drilled at the next level (Part B), and then a sub-assembly of another purchase part and the ring with finished machined dimensions after assembly (Part A).
Our current system has the following settings:
Part A - Stocked internal part (jobs are released at this level)
Part B - Phantom part- Inventory could technically be stocked at this level but not by default. If there is inventory available the system will consume this first. The balance will be made within the manufacturing process.
Part C- Same as Part B phantom part
Part D- Purchased stock part
We were thinking we could replicate this setup in Kinetic with the following settings with a combination of pull as assembly and auto-consume stock. However, with these settings the system is creating job suggestions for parts B and C even when there is no inventory on hand. This is exponentially increasing the number of jobs in our system because of the number of phantom parts from our old system.
Setting Auto-consume FALSE on part B and C does prevent the system from suggesting jobs at these levels. However, if we make extra parts at either of these levels they would not be consumed by the next run without some manual intervention.
Has anyone else run into this issue?
Kinetic settings:
Manfuactured/Purchased
Quantity Bearing
Non-stock
Auto-Consume
Pull As Assembly
Backflush
Part A
M
TRUE
FALSE
FALSE
FALSE
TRUE
Part B
M
TRUE
FALSE
TRUE
TRUE
TRUE
Part C
M
TRUE
FALSE
TRUE
TRUE
TRUE
Part D
P
TRUE
FALSE
FALSE
FALSE
TRUE
Here is a screen shot of part C time phase with Auto-Consume TRUE.
Unfortunately, Epicor doesn’t have any sort of function for “if this exists, then use it, otherwise use this”. Epicor creates a copy of the BOM when the job is created and it’s now a standalone copy of the BOM. So if you change the master, any firm jobs out there already will not be updated automatically.
Because it’s set up that way, the system won’t really know what’s in stock at the time of consumption, so it won’t know which way to go. You can issue assemblies to jobs if you happen to have them in stock, but it’s in no way automatic, and your planning isn’t going to adjust for that until you actually issue them to the job, or at least you add the pull qty to the assembly in the job.
You can set the “Pull Qty” to something other than 0 on an assembly and then the system will plan for that, buy someone has to do that manually. They would have to know about (or check for) any inventory in stock, then go to the jobs and set the pull qty on those specific jobs. Then the assemblies will have to be issued to the job, because there is not backflush for that part of the system.
The best that I’ve come with in the past is creating some dashboards that looks at job assemblies, and inventory, and if it finds inventory on hand shows up on the list for someone to do something about it. It’s not a great solution, and requires manual diligence to actually get it to work correctly.
@Banderson Thanks for the explanation. The list you suggested is something I was trying to avoid but seems like the only way around the issue. Appreciate the help!
Creates jobs to make them separately. But having the subassembly as Plan As and Non-Stock means that the system will create a Job to Job demand link. I would also turn on Multi-Job so they all consider each other when scheduling.
Ah! that was our issue where I worked. The “ability” (willingness) to do the jobs/transactions in the right order so that cost followed correctly wasn’t something they would do. They wanted it all on one job.
That’s what I run into as well. The bean counters don’t want to have to look across multiple job costs. But I suppose a baq report could pull all related jobs into one dataset, right?
It will, but make sure the job being received to is also firmed up. If you firm the earlier job and leave the later job unfirmed and MRP runs again, both jobs will be FUBAR and you’ll have transactions referencing a nonexistent job number.
That pretty much killed any desire from our manufacturing team to use job-to-job links.
The moral of the story, is that Epicor does not react well to unexpected changes. It helps you make a plan, and if you stick to that plan (jobs and quantities, dates etc) it works well. But if you start doing things like make extra, or not enough, or in a different order, just generally not following the plan, things don’t go well.
It sucks that the real world isn’t often that cut and dry, but it was designed to work in a perfect world, for better or worse.
