I used a previous version of Epicor called Manage 2000 (or M2K). For each part I had the ability to bucket demand by a certain amount of days. It was order policy = Interval, then interval time set = a number, then days/hours would be selected.
Ex) 30 days, vs 12 hours. We would use this so that any demand that fell in that time frame would be “bucketed” together as one job through the system with a due date for all pieces based on the first need by date. I’m not seeing a way to do that in E10, that we always have to choose a manufacture lot size min/max instead. Am I missing that?
1 Like
Days of Supply is this, I think.
Days of Supply is also fabulously complicated, so buckle up. But in short and at its core, DOS is a fancy lot size based on time not quantity.
3 Likes
Oh yeah I don’t know about all that. I think you only get round numbers of days.
3 Likes
Agree with Days of Supply. This is set on Part → Site.
When MRP encounters an instance where it needs to create a supply record, it will look at all demand ‘days of supply’ # of days forward from that instance and also account for that demand when it generates the supply record.
3 Likes
Okay great! I figured it had to be there. When I initially read the application help description, I misinterpreted the explanation. Just to confirm, if I had a part set to 30 days of supply it would bucket not only the next 30 days into one demand, but all subsequent demand would be grouped similarly?
1 Like
This is where it gets complicated. It won’t group all demand in 30 day buckets full stop.
Things like the cadence of when demand is entered into your system, and how far in advance, how frequently you run MRP, and other factors I am not thinking of, will effect how many days of demand are actually captured in your supply records.
The way I interpret that is, it will do it’s best to bucket demand based on the days of supply setting. supply/demand changes and process MRP affects how it interprets the data. If MRP is ran nightly it would capture the updates daily and bucket any changes that occur. Through out the day it might look off because of new orders or scrap.
IIRC, the purpose is to eliminate some of the noise and group demand together into fewer shipments. My understanding is that once it finds the first demand, it looks out that many days from the date of the first demand and pulls all of the demands in that date range (first demand + # days) into the order. It then does the same for the next demand, and so on. So, it’s not really bucketing but it would essentially do so if it was an active part.
2 Likes
@Mark_Wonsil , you are pretty much correct. Once it finds the first demand, it goes out that many days from that first one, full stop. Subsequent demand is not affected by DOS as the window has already been set by the first demand.
@nmulkey , this may not do what you want as there are multiple factors in play here. Do you allow scheduling in the past? Do you run MRP with a Cutoff date? Also, it will not group it together unless you have a job lot size.
2 Likes
This is a good way to look at it. Start playing around with it and see if it gets you closer to what you need.
We want to use Days of Supply here but because of certain things we can’t get value out of it.
We run MRP nightly here. Add to that our orders are entered with very little buffer compared to our lead times, so we really have no luxury of leaving unfirmed jobs/po suggestions/etc sit for multiple days.
1 Like
Oh yeah - it’s not your fault! The help is dead wrong.
I reported this in 2019. It’s (incorrectly) copied from lead time.
Good news, though, they accepted this as a bug six years ago! Any day now it should be fixed, right? Right?
3 Likes
I asked support for an update about the field help. They said it’s fixed in 2025.1.
Would anyone be able to check this on a 2025 version? It’s the help on Days of Supply in Part Tracker, for example. (It should not say “lead time.”)
Sorry (not sorry) but I am skeptical, since the PRB has no updates still.
1 Like
To be fair, the person did say 2025.1.15+. I should have specified.
So… they could still be right.
1 Like
Thank you.
I want to add about 20 emoji to this. but, in short:
Here comes the 
bait…
So, the description is wrong, is an easy fix, makes Epicor look bad. It leads people astray. (No offense @nmulkey – you actually saw through the lies.) Sure, all true.
But what I think this really emphasizes is how Very, v e r y hard it is to communicate problems to support/development.
Problems.
It’s hard to communicate problems to them.
Not “why did MRP do this?” Not “Please remove this landing page.” Problems are a mystery to the crew.
No updates on the PRB for seven years, except that random mass update we all got for some odd reason. I ask about the PRB, tech says it is fixed, yet the PRB was never updated.
Then over the weekend I get an email saying the PRB was “updated with comments.” The comment isn’t in the email, nor in anything I can see in the PRB. Status is still Not Yet Planned. But it does imply that someone (probably the tech) read the PRB - the relevant one. Yet the response to me is to say that it’s fixed when it is not.
The point is, this is what we do see, and what I can illustrate, but it’s really just a microcosm of how you are truly talking to a wall when talking to Support. It gives you no confidence in the communication.
AI will fix everything, right?
5 Likes
As others have CORRECTLY stated, Days Of Supply (DOS) is the answer. DOS is litterally DAYS of supply… Whenever the system sees that there is a new supply suggestion needed (Either a JOB, PO, or Transfer order) the system will LOOK FORWARD the number of DOS days, and gather all the future demands together and create one supply job/po/transfer order. It is very consistant in the behaviour.
There are a few exceptions.
Max Lot Size: if you have this set, then the DOS will never exceed the max.. if the need is for something more, then a new supply order will be created, but it could be within that DOS number of days. Example, of your DOS is 30, but you have a max lot size of 100, and you have two demands within the next 30 days of 100 each, it will still create two supply orders on the dates needed.
Personal Recommendations:
I typically state that DOS should never be less than 1, but most companies I would say “Set it to 7” so that you never are building less than 7 days worth of demands.
Cheaper/Small items that are easy to store (and dont expire): Set to 365
Expensive/big items that are hard to store (or expiring items): set to a low number.
2 Likes
Agree totally, having the same frustrations with PRBs we’ve sent in too. A few for field help issues in fact.
Is Make Direct demand also an exception to DaysOfSupply gathering together? I mean will it make a single supply job with many Job-to-job demand links?
make direct will ignore DOS.. there is a order-job link or a job-job link so it will not automatically connect jobs in a make direct world.
1 Like