Dynamics AX 2012 Available-to-Promise (ATP): Are You Using It to Full Effect?

August 15 2016

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 can work on the site level. In that case we have to make sure we don’t put a warehouse in the sales line and our site specific order parameters have a blank in the sales warehouse field. The ATP screen will show a blank warehouse, the ATP quantity will be for the site. However, ATP is not auto populating the sales line warehouse, so the user is responsible to update the warehouse field. If we deliver from multiple warehouses, we leave the sales line warehouse blank and make sure the reservation is for two warehouses. The picklist will print two lines, one for each warehouse.

Note: ATP does not require automatic reservation. The ATP quantity is calculated independently. With the availability of advanced warehousing in AX, the basic functionality of “Release to Warehouse” requires a physical reservation of the sales order line but when using “Loads” the reservation can be postponed. See the article by Scott Hamilton about this topic. 

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.

300 - 30 -24 = 246 EA.

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 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. (For manufactured items one could make the ATP time fence equal to the cumulative lead time.)

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 then a few days here. In Make to Stock scenarios, past-due sales orders are either fulfilled in a few days or are cancelled. (Note: We have a customer that wrote a customizationthat 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.

The system has the option to include planned orders in the ATP calculation. One can argue that the dates of planned orders can change after every MRP run so using these dates for ATP is not a good idea. On the other hand it can be considered a better alternative compared to “end of ATP time fence” which is what the ATP date will be if no supply orders are found at all. So the option can be useful. A final thing to say here is that typically within the ATP time fence planned orders would normally not be found. If the ATP time fence corresponds to the lead time, these planned orders should have been firmed. We conclude that the option to include planned orders can be useful.

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

Sales 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 and Delivery schedules

When we use Sales order line delivery schedules, the ATP calculation will work. When the schedule is finished, we can do the ATP inquiry on each schedule line just as we would do for a regular sales line. The screen below is where we create Delivery schedules.

Dynamics AX ATP Delivery Schedule 

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.

An extensive analysis of the Order promising functionality in AX 2012 within an S&OP context can be found in this article by Scott Hamilton.

FREE Membership Required to View Full Content:

Become a MemberLogin
Joining MSDynamicsWorld.com gives you free, unlimited access to news, analysis, white papers, case studies, product brochures, and more, and it’s all FREE. You’ll also have the option to receive periodic email newsletters with the latest relevant articles and content updates. Learn more about us here
About Evert Bos

I am Evert J Bos, ERP consultant since 1986. I started in Europe with IMS7 (A Honeywell Bull Mainframe ERP system) and the BaaN ERP system. Since 1995 I have worked in the USA and since 2004 I have been working with Dynamics AX.  I work for Sikich and focus mostly on manufacturing companies that make complex, engineered products.

More about Evert Bos


leifwoxlin's picture

Very good overview and conclusions to agree upon – thanks. The ATP-functionality is a significant time-saver for any make-to-stock-business.

Larri's picture

Thanks for the good article! Although I disagree that ATP is calculated only on site level. If you set "Primary stocking" parameter to 'Yes' on Storage dimension group, ATP window will show quantities for the specific/given warehouse. If it is 'No', then quantities are on site level. Of course this parameter will also have other consequences.

ej34bos's picture

Will have to make a correction indeed. It depends on your set up. Just tested this at a customer. If you don't put a sales warehouse in the site specific order parameters, then ATP will work per site, if you leave the warehouse blank on the sales line... you ATP quantity will be for the site. Sorry for this oversight I will update the article soon.