Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 310 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Serious issues with Order Promising
Miklos_Hollender
Member Posts: 1,598
Hello,
It seems I'm completely stuck with the Order Promising issues at a client. The root of the problem is the following:
Say if you have a part, Check-Avail. Period Calc. of one year, a sales order due half a year into the future for 100 pieces (not reserved) for the part, 100 pieces in stock for the part and four weeks of purchase lead time, and you put in another Sales Order for the part, running Order Promising will tell you to buy it (i.e. gives a date four weeks ahead), even though you could supply this SO from stock and replenish it later on for the other SO. The OP engine simply looks a year ahead into the future (Check-Avail. Period Calc.), decides that it won't be available then as there is no PO for it, and therefore concludes it can't be available now either...
I think it expects that future demand is always supposed to be supplied by a PO or at least a requisition line even if normally you don't care about demand too far ahead... which they don't, AFAIK, they just run the requisition 4-5 weeks ahead and don't care for the rest.
A workaround would be to set the Check-Avail. Period Calc. to the longest lead time they usually have (which is four weeks) or hack the code to always limit the Check-Avail. Period Calc. period to the lead time for purchased parts as demand after the lead time should not be taken into account.
However, this does not seem to work. If it's part of a BOM and you are selling a manufactured item, the following happens with a Check-Avail. Period Calc. of 4 weeks and a sales order for the part 5 weeks ahead (and having current stock as well, which could be used):
1. Is the finished item avaible today? Nope - no production order yet.
2. Could we manufacture it for today? No - only for tomorrow. (We'll get back to this.)
3. Then it jumps four weeks ahead. Can we manufacture it then? From a capacity point of view, yes. How about the components four weeks ahead? It runs the Order Promising for the component, which happily adds *another* *four* *weeks* of Check-Avail. Period Calc. again, because, after all, it's just another Order Promising calculation, so now we are *eight* weeks ahead in time. So if it finds the sales order 5 weeks from now, for the part (not the finished item), then won't be available then, but it can be bought in 4 weeks, so it's happy.
4. Then it starts a heuristic to find the ideal date by starting to halve the distance between that day 4 weeks from now and now. So it first looks 2 weeks ahead. Is the component available? Again, looks at the period 2 weeks ahead plus 4 weeks of Check-Avail. Period Calc., but we have a sales order 5 weeks from now, so it's not available. Can it be bought in? No, because to have it 2 weeks from now you had to have ordered it 2 weeks ago, because of the 4 weeks lead time. Therefore, the heuristic stops right here, the best possible date is what it found earlier, which is 4 weeks from now.
Practically,then, with a Check-Avail. Period Calc. of 4 weeks if you have an SO for the part within 6 weeks it's considered unavailable if it's a part of an assembly. This seems to be the case there - for the examples they showed me there are sales order for around 02/04/08, six weeks from now.
To be perfectly honest, this seems so complicated and so wrong that I'm not sure I can fix it. I mean yes, I could simply tell it to not look ahead another 4 weeks for components, or to start the heuristic from today, but it took a considerable time to figure these all out and making such an arbitrary change in such a complicated routine would open up possibilities for bugs that would take another quite considerable time to track down.
(At first there seems to be a possible workaround at 2. Basically the default setting for Default Safety Lead time is 1D which means you can't manufacture stuff on the same day when you are supposed to ship it, but the day before. Also the default setting for Offset (Time) in Order Promising Setup is 1D meaning that don't promise anything for today, but only for tomorrow. Setting both to zero makes it work as 2. becomes true, but it would mean it would promise manufactured assemblies for today, which is plainly wrong. So it isn't a possible workaround.)
Any idea would be welcome - they are getting impatient and and I have no idea what to do with it.
It seems I'm completely stuck with the Order Promising issues at a client. The root of the problem is the following:
Say if you have a part, Check-Avail. Period Calc. of one year, a sales order due half a year into the future for 100 pieces (not reserved) for the part, 100 pieces in stock for the part and four weeks of purchase lead time, and you put in another Sales Order for the part, running Order Promising will tell you to buy it (i.e. gives a date four weeks ahead), even though you could supply this SO from stock and replenish it later on for the other SO. The OP engine simply looks a year ahead into the future (Check-Avail. Period Calc.), decides that it won't be available then as there is no PO for it, and therefore concludes it can't be available now either...
I think it expects that future demand is always supposed to be supplied by a PO or at least a requisition line even if normally you don't care about demand too far ahead... which they don't, AFAIK, they just run the requisition 4-5 weeks ahead and don't care for the rest.
A workaround would be to set the Check-Avail. Period Calc. to the longest lead time they usually have (which is four weeks) or hack the code to always limit the Check-Avail. Period Calc. period to the lead time for purchased parts as demand after the lead time should not be taken into account.
However, this does not seem to work. If it's part of a BOM and you are selling a manufactured item, the following happens with a Check-Avail. Period Calc. of 4 weeks and a sales order for the part 5 weeks ahead (and having current stock as well, which could be used):
1. Is the finished item avaible today? Nope - no production order yet.
2. Could we manufacture it for today? No - only for tomorrow. (We'll get back to this.)
3. Then it jumps four weeks ahead. Can we manufacture it then? From a capacity point of view, yes. How about the components four weeks ahead? It runs the Order Promising for the component, which happily adds *another* *four* *weeks* of Check-Avail. Period Calc. again, because, after all, it's just another Order Promising calculation, so now we are *eight* weeks ahead in time. So if it finds the sales order 5 weeks from now, for the part (not the finished item), then won't be available then, but it can be bought in 4 weeks, so it's happy.
4. Then it starts a heuristic to find the ideal date by starting to halve the distance between that day 4 weeks from now and now. So it first looks 2 weeks ahead. Is the component available? Again, looks at the period 2 weeks ahead plus 4 weeks of Check-Avail. Period Calc., but we have a sales order 5 weeks from now, so it's not available. Can it be bought in? No, because to have it 2 weeks from now you had to have ordered it 2 weeks ago, because of the 4 weeks lead time. Therefore, the heuristic stops right here, the best possible date is what it found earlier, which is 4 weeks from now.
Practically,then, with a Check-Avail. Period Calc. of 4 weeks if you have an SO for the part within 6 weeks it's considered unavailable if it's a part of an assembly. This seems to be the case there - for the examples they showed me there are sales order for around 02/04/08, six weeks from now.
To be perfectly honest, this seems so complicated and so wrong that I'm not sure I can fix it. I mean yes, I could simply tell it to not look ahead another 4 weeks for components, or to start the heuristic from today, but it took a considerable time to figure these all out and making such an arbitrary change in such a complicated routine would open up possibilities for bugs that would take another quite considerable time to track down.
(At first there seems to be a possible workaround at 2. Basically the default setting for Default Safety Lead time is 1D which means you can't manufacture stuff on the same day when you are supposed to ship it, but the day before. Also the default setting for Offset (Time) in Order Promising Setup is 1D meaning that don't promise anything for today, but only for tomorrow. Setting both to zero makes it work as 2. becomes true, but it would mean it would promise manufactured assemblies for today, which is plainly wrong. So it isn't a possible workaround.)
Any idea would be welcome - they are getting impatient and and I have no idea what to do with it.
0
Comments
I'm right now facing the same issues you have with order promis function.
First of all we have had an issue when we have a workcenter (assembly) with 7 employees but only one at at time works on a prod.order so we use concurrent capacities = 1 in the routing. But the capable to promise doesn't look at concurrent as one employee working on one prod.order. We have developed so that this now works but now we're facing the same issues that you describe. Did you manage to fix this in some way? If you did I'd appreciate to know how you did this.
/ Christian
NAV Freelance Consultant