@DWright- Thanks Deborah, this is great information. I will definitely be using this! That being said, that was not exactly what I was looking too accomplish. I did a bad job at explaining but let me try again. My company has utilized Epicor very poorly for many years. Currently they have no way to plan capacity. When a sales order comes onto the system it may have a due date of 9/30. Epicor will issue a manufacturing suggestion to a start date and finish date of 9/27. This is because we have no routings or standards in our system. When I was utilizing SAP at another company (which also did not have routings or standards in place), we utilized logic called in house production time. If a part took 10days to build we could input this value into that field. If a sales order came on for 9/30 for a part that had 10 days of manufacturing lead time, this then would create a manufacturing suggestion to have a start date of 9/13 and a finish date of 9/27. We did not have visibility into over loads or under loads into specific work cells however this at least gave us a rough cut capacity outlook that we could plan for. I am trying to accomplish the same in Epicor until we have resources to load routings/standards. I have tested this logic with inputting values into the field of Cumulative time and this level time within Part-- Sites-- Planning. When I plugged in 10 days into those fields and reran MRP, the manufacturing suggestion did not back date the start date like I anticipated. I am thinking maybe I am using the wrong fields or possibly I can need to have some other settings in place for this logic to work. Any chance you have experience with these types of efforts? Any insight is greatly appreciated!
I think we are on the same page. We have truly been fighting this same monster for quite some time. Let me try a screen shot here.
So, hereās our Time Phase. We have unfirm suggestions, as you can see. Although the Due Date on this suggestion shows 9/12, itās deceptive. You have to look at the job.
By going to Job Tracker, we can see that this job actually has a final operation date for 9/6/2019. The Due date is relative to when the parts should leave the building - the last possible second. The actual Final Operation date is occurring 5 business days prior to when those parts are scheduled to leave the building.
This is accomplished by utilizing Scheduling Planning under the Part.
Also, by utilizing using days of supply, we can lump those suggestions into 5 day buckets.
Our corporate has decided to use a Planning Time Fence of 5, which Iām not thrilled about at all. She called it buckets, but I disagree. Itās function is exactly what itās name implies. Itās a FENCE.
In āMom Speakā, itās essentially Epicor saying that all new job suggestions or change suggestions are to stay this many days away from the date inputted for MRP processing, regardless of whether you need those parts or not. Youāll see a suggestion, the suggestion will reference the requirements, but it will not appear within the time those requirements are needed. It wonāt appear until itās on the other side of that FENCE - whatever distance you set that fence at.
Iām still not completely clear on the Delta I/O and how thatās working out. I just think we should leave the fence alone, as we work hard to try to meet our customers urgent needs.
Now, back to youā¦ If you want that 10 days lead time for manufacturing, try that receive time. You can also utilize the production prep buffer and kit time to accomplish the same thing if you want to break that time down into different categories. But, overall, it was quickest and easiest for us to use the receive time to accomplish our goals at a plant level without having to meddle with build plans and operations and whatnot.
Also, without the Fence, we will get the back dating.
This is great! thank you for the detailed explanation. I really appreciate this!!
Here is an Epicor Idea you can vote up to add Site options to be able to include Move Time & Queue Time:
Add Site Options to Include Move Time & Queue | Epicor Kinetic Ideas (aha.io)