I am curious if there is any Epicor functionality that allows for grouping or associating jobs together. Our factory process requires picking a number of parts off Kanban shelves and placing them on a cart. These carts hold about 60 parts that go into making the finished good, but there are about 30 jobs that get created to kit them on a cart, weld some together, and then paint some of them, as this is the next transaction point before assembly occurs. I am curious if Epicor has any functionality that is capable of associating all these jobs together that go into one cart (and further downstream into one finished good).
Right, a PCID could be used to identify the cart and all the parts scanned onto it, but I’m more curious if jobs can automatically get created and grouped into a PCID or some other functionality.
Our situation is a fully make-to-order company where a job is generated for the finished good that consumes painted weldments and painted piece parts. Individual jobs get created for each of those painted weldments and each painted part and both get consumed from our Kanban. The finished good job is the source that dictates what jobs should be processed together to fill a cart representing what is to become the finished good. We just haven’t been able to figure out how the top-level job can dictate the grouping of underlying jobs.
This sounds like you also could possibly benefit by Job Batching functionality that is available… what it does is it will combine the jobs into one job (either temporarily or permanently) for various operations. For example, you can have 5 jobs that all need painted at the end of the job… you can batch those jobs together into one job for the final paint step. You can also batch jobs at the beginning of the jobs, batching the first operation(s) together, and then the jobs will split back out to their individual jobs again. Batching is all done within the Resource Scheduling board… you select a set of operations that all use the same resource and batch them (see the actions/overflow menu).
You can split a batch back out and get the original jobs operation to open again? Anytime we did batching if we needed to pull out of that batch and split it back up we had a lot of trouble with that. Maybe something changed since we played with it or we were doing something wrong. I’ve never found that batching does anything more than close original operations and create a new job with a consolidated operation.
Is the problem, that since you’re using Kanban - no easy way to know which supply jobs are related to a specific top level job - so time is wasted manually looking them up and grouping them for “current work”?
Does the top level job have a demand link to an SORel?
Are all your your jobs are created via MRP, manually or a mix?
All the lower level job materials are pulled from Kanban?
Correct. Current state we have one finished good job that contains all operations between picking kanban shelves all the way to assembly. The material handler that kits the carts is trained to look at the finished good and know the 60 or so parts that he has to put on the cart. Future state company wants to introduce a transaction point midway thru the factory, so he will no longer see the finished good job. On the plus side, now he will have an actual raw material list to pick with accurate bin locations, but he will need to know the boundaries that jobs 2 thru 30, go to a cart for top level job 1. Otherwise, we just envision him getting a stack of 300 jobs for the day but no way to delineate them.
Yes.
Current state is manually, but future state we are implementing scheduling and resources to begin automatically producing jobs.
Mostly. Probably 95% of the low level job is pulled from Kanban with a few exceptions for purchased components included in weldments such as couplings and studs.
Yeah, been there too and never found a great solution. Just a couple things I’ve seen others do below:
I saw one that used Projects - manually assigned to the SOLine, and all jobs involved.
At another site that already used MRP and was having similar issues keeping track of the sub jobs/materials they:
set up a UD table with fields for SO, parent job and material job(s).
after manually creating the top level job and releasing it
they would immediately run MRP (so they could be reasonably sure that any new jobs/POs created were for that top level job)
query for new jobs/POs, copy to Excel, populate columns for SO/TLJob values
paste/insert into the UD table
Of course, The more orders/jobs the more a pain this would be.
Was OK at this site because they typically only released a maximum of one new top level job a week AND they were pulling from STOCK, not using Kanban. i.e. simpler than your environment, not too hard to maintain manually.