infor.com
concierge
infor u
developer portal
Home
Groups
FACTS - Partner Community
Ramifications of Changing ADU calculation
Legacy Contributor
I'm posting this out here as a recommendation from Infor Support. Curious if anyone else has run into this or has any recommendations.
I have a customer that wants the ADU value to be representative of workdays per month versus calendar days per month. He is indicating that "as is" his ADU is understated by 43% and he does not want to adjust min or safety stock to cover for the variance. The problem we're running into is that in some places ADU is the AMU divided by 30. In other areas AMU is calculated by taking the ADU and multiplying it by 30. Our technicians are concerned that this would have to be changed in various locations and we don't really know ramifications to making this change. The customer is indicating that they'd be ok with us just changing ADU calculation to be AMU divided by 21 and leaving the other calculations but we're not very comfortable with that. Can you provide any recommendations? How would Grant Howard handle a situation where ADU is understated by 43% because the calculation includes weekends?
Find more posts tagged with
Comments
Cheng Ruan
I think perhaps there is a misunderstanding as to how average daily usage is calculated. I asked Grant and he commented that while the SX.e product does use monthly buckets and derives ADU by dividing by 30, that is not the case with FACTS. Here is Tim Plotner's explanation:
"ADU is the actual calculation. It’s based on true daily usage based on # months to analyze for the item and type (trend/back/forward), including lead time advance for trend. And it updates daily, so if I’m looking at 3 months, it’s actual yesterday, back 90 days instead of waiting until the month is closed.
When we show AMU, it’s always ADU * 30."
Legacy Contributor
Thanks so much for the response. The customer is balking at the use of 30 as they do not work 30 days in a given month. That is why they want the multiplier/divisor used to be 21 instead of 30 so that they know their ADU based on work day versus calendar day. Does that make sense?
Cheng Ruan
Teresa -
While that's true, think of how that number is used. The "Show Calculations" button in the BCC breaks down the process of how it arrives at the suggested purchase quantity. Consider too, that lead time also includes weekends and holidays, so I believe the data is consistent. If you adjusted usage, you would need to adjust lead time as well for purchases that spanned non-working days.
Remember that usage is no longer stored as monthly buckets in ICWHSE. Instead, each transaction that affects usage is stored in ICRDST. And usage spans are likewise day based. Let's say an item has a 90 usage window. Starting today, 9/25/2015 that would go back to 6/26/2015. Not the total of Sep-Aug-Jul buckets.
Perhaps in a perfect world, FACTS would offer a "Business Calendar" as you find in the TakeStock product that tracked actual working days. All usage and lead time calculations would then observe those boundaries.
Important Links
Community Hubs
Discussion Forums
Groups
Community News
Popular Tags
ION Connect
ION Workflow
ION API Gateway
Syteline Development
CPQ Discussion Ask a Colleague
Infor Data Fabric
Infor Document Management (IDM)
LN Development
FAQs, How-To, and Best Practices
API Usage