Available-to-promise (ATP) is a simple calculation meant to provide a customer with a promise date for delivery. The business model is Make-to-Stock. This means that we have inventory on the shelf based on a forecast or a safety stock.
We typically use automatic reservation in Microsoft Dynamics AX so we do not run the risk of selling the same inventory twice. Nowadays we can control the automatic reservation in the Item Model group.
If we create a sales line for a quantity that we do not have in stock and we have automatic reservation, we will get the shortage window that allows us to look up on-hand in other sites or other companies.
Is this not enough? We have a backorder and we will try to fill it ASAP. But most customers will not accept a simple “Your items are on backorder, we will call you when they arrive”! We need to give the customer a “promise date”. And this should be an “informed” promise date based on actual receipts that are on the way.
With ATP, we use the information regarding existing supply orders. The system goes through the entire ATP time fence and calculates an “ATP Quantity” for every day, which is nothing more than the expected supply minus already promised quantities to other customers.
ATP will only deal with the receipt of the Finished item that is in the sales line. It is a single level look up. (as opposed to capable-to-promise or CTP, which will be addressed in a separate article).
Note: ATP works on the site level. The warehouse is not relevant. If we end up delivering from another warehouse, we have to remember that it is no problem at all to have the sales line say “Warehouse A” while the reservation is on Warehouse B. Of course the system will only do this when we leave the warehouse on the sales line blank. In such a scenario, the sales order will ship nicely from Warehouse B.
How does it work?
This is the ATP information screen that can be found under the pull-down menu “Product and Supply” on the sales line.
In this example the promise date would be 8/23/2016. On that date, the ATP quantity is large enough to handle the sale of 20 EA that we are entering in the system right now. How does the system calculate that ATP quantity? Receipts are 300 EA, a purchase order that is supposed to arrive on that day. Issues is any other sales order that is in the system already, a total of 30 EA. On hand is – 24 EA. This is not physically on hand but simply the balance of receipts and issues from previous dates.
This promise date will automatically populate in the requested delivery date on the sales line shown below. No transportation time has been defined between our warehouse and the customer address, so the requested receipt date becomes also 8/23/2016.
The screen “Simulate delivery dates” gives the same information.
Here we have the option to click a button and populate the confirmed delivery date.
The two dates “requested” and “confirmed” delivery date always create discussion and sometimes confusion. By design, the system populates the “requested delivery date” with a calculated ATP date but many companies would like to use this field for the date the customer originally requested. When we type in that requested date and it happens to be earlier than the ATP date, the system will send a warning, presenting the window below.
We can only get this earlier date saved if we switch off delivery date control. If we enter a requested date that is later than the ATP date, there is no problem but there is also no business case to save the difference between “requested” and “promised” delivery date.
I have not seen this to be a very big issue. Most companies were more interested in their own performance regarding “keeping the promise,” the difference between the confirmed delivery date and the actual ship date. Let the requested delivery date be a system calculated date. If the customer does not accept this date, we will try to find a way to accommodate the customer, and if successful, we type in that earlier date while overriding delivery date control.
The ATP quantity calculation is doing the exact same thing as the “physically reserved” and “ordered reserved” calculations by keeping track of how many “un-promised” supply still exists. The difference with the reservation mechanism is that ATP displays an ATP quantity for every day. It does not show a cumulative total as the reservation quantity does in the on-hand screen.
The ATP quantity reflects what we have available on a specific day. An ATP quantity can never be negative.
Look at an example below to understand one other peculiarity that was unexpected for me. In the ATP information screen you do NOT see the quantity of your current sales line included yet.
I am just entering a third sales order line for 23 EA right now. Even though I saved it, and I have already received my ATP date of 8/23/2016, the total “issue” quantity (total quantity promised in earlier sales lines) will NOT include my current sales line yet.
When I enter another sales order line for this item or put my cursor on an older sales line, only then will I see my quantity of 23 EA be included in the “Issues” quantity on 8/23/2016.
This is important to know: The Issues quantity always excludes the quantity of the sales line you are currently on. This rule is required for correct functioning of the ATP logic. The ATP quantity answers the question “What can I sell on the date indicated for that ATP quantity?” The ATP quantity on a certain date is the difference between receipts and issues. The system should not include my new sales line in the “Issues” just yet as I have to evaluate my quantity against the ATP quantity as it is now, without including my new sales quantity.
What about those “backward” parameters?
These parameters are somewhat intimidating at first sight but when testing, it turns out to be very simple functionality that is necessary. We all agree that past-due sales lines and past-due supply orders have to be somehow included in the ATP calculation. But how? These parameters control that in detail.
Almost every company has past-due sales orders (backorders) as well as past-due supply orders. What should ATP do with these? Ignore these quantities? That seems like a mistake as my ATP quantity would be too low. The parameter “backward time fence” determines how far into the past the system can reach to pick up past-due quantities and include them in the ATP calculation. “Demand” is about the past-due sales orders, “Supply” is about purchase, production or transfer orders. The other two parameters only make sense if the system does catch a quantity in the past. The question becomes: If I can include these past-due quantities, on which date should these quantities show in the ATP info screen? The ATP info screen does not show dates in the past. We have to decide on which future date these past-due quantities should appear. With an offset = 0, they will appear today. With an offset of 1 day, they will appear tomorrow.
It is hard to give any advice on how to set these parameters. The system has a default setting that is as shown below and does seem to partially represent a “best practice” for contemporary companies in the Make-to-Stock scenario. Any past-due beyond two days should be considered cancelled.
Some further consideration:
The ATP time fence should be at least the item lead time. The five-day default has nothing to do with any best practice. ATP time fence should be long enough to include supply orders that come in at a normal lead time. This is exactly the same argument we use for the “coverage time fence” in Master planning where we set it to at least the longest lead time of any item in our database.
ATP backward demand time fence should reflect how many days past-due sales orders in my company can be and still be valid. I would never expect to see more than a few days here. In Make to Stock scenarios, past-due sales orders are either fulfilled in a few days or are canceled. (Note: We have a customer that wrote a customization that automatically cancels any backorder quantities. If my customer regularly re-orders the same thing, it makes no sense to keep backorders in the system.)
ATP backward supply time fence has the same logic. A few days into the past at a maximum would seem reasonable.
I would set ATP delayed demand offset time at zero, so past-due quantities always appear today.
The same consideration for the ATP delayed supply offset time.
I am not aware of any business reason to include planned orders in the ATP calculation. I would not recommend it. Let ATP be based on actual orders only.
ATP and issue margin
This setting adds the number of days in the dynamic plan to the ATP date, to account for internal operations to get something from a warehouse shelf to the out-dock.
Only a safety margin on the Dynamic plan(which is set in the Master Planning parameters) will be seen. A safety margin in the coverage group is ignored.
The ATP information screen will look the same. Nothing has changed there. But in the Sales line requested delivery date, we will find a later date.
ATP in Sales quotations
ATP in Sales quotationsSales quotations have Delivery date control and ATP does seem to work. The date that is popping into the Sales quotation line follow the ATP logic just like Sales order lines do. But appearances deceive.
The Sales Quotation quantity is never added to the “ISSUES” quantity to subsequent sales quotations or sales orders are getting wrong information. If I only have one Quotation, the ATP date will be correct. But after that, my ATP will function as if this quotation does not exist so I keep re-promising the same quantity in the next Quotation.
We remain hopeful. Maybe we have to remember that in Master Planning, Quotations are only included when the attached opportunity has a percentage of success greater or equal to the parameter in the master plan. But this setting does not affect the ATP logic. ATP does not work for Sales quotations, it does not matter whether I add an Opportunity with a high percentage of success.
The ATP Info screen is available in the Sales quotation line so we can conclude the user will be easily put on the wrong foot here.
ATP and ship complete
We can easily imagine a scenario with many sales order lines that all get different ATP promise dates but the customer wants a complete shipment. This will require we adjust the date of all lines to the latest date of all lines. This can be done easily using the header “Requested Delivery Date” or “Confirmed Delivery Date”.
This will bring up the window below where we would leave the default choice in the bottom intact: disable delivery date control.
The system does not really check whether all order lines ship. “Ship complete” in the sense of “All order lines” is a customization. The standard system has ship complete in the sense of “the full quantity of the sales line”, which is the checkbox below, on the general tab.
ATP Summary
This concludes our overview of the ATP functionality. For Make-to-Stock scenarios it is the standard order promising functionality that every ERP system provides. Dynamics AX has a pretty nice interpretation of it. The graphical view of inventory is in my view of very limited use, one can much more easily just look at the numbers. The test results all seem correct, although I had to get used to the fact that the current sales line quantity is never included in the “ISSUES” quantity. This causes the ATP quantity to be different for each sales line because your current line quantity is always excluded. This is something one has to get used to. The design decision to have ATP work on the site level is a good one. It is a disappointment that the Sales quotation ATP is not functional against all appearances of the contrary.
