ATP In Order Management

Available To Promise



Functionality: In this competitive world of business, it is always critical for an enterprise to provide the availability of the product to customer immediately.
In a real world, when a customer calls to order a product, they expect the accurate delivery date to be told to them on Phone itself. If the enterprise cannot provide the material on the request date, it is suppose to provide the various combinations of dates, quantities and price to provide options to the customer to choose and confirm.


Enterprise Requirement: Most of the enterprises use ERP system in their environments. A lot of permutation and combinations are required to respond to customer product availability requirements and the factors on which it depends are many.


Following are the expectations of the customers:
a) Immediate Response: Customers expect to get the expected delivery date over the phone at the time of placing the order. The ERP system should be quick enough to respond to such need. The turn over time is couple of minutes.


b) Commitment should be met: Once the enterprise commits the customer a delivery date, in normal condition it is expected to deliver on the same date. This is very important to build the trust with the customers.


c) Provide Alternate Options: If the enterprise is not able to provide the materials on the request date of the customer, it should provide various options to the customer in terms of alternate items, breaking the delivery quantity to deliver quantities part by part, different option of costs



Solution: Oracle has a functionality of ATP which caters to this requirement. The sales representative, who enter the sales orders for the customers enters the Sales order line with item information and then calls this functionality to figure out if the item with the desired quantity can be fulfilled.
How ATP works:


ATP can be based on one of the following 2 factors:
a) Planning output – For this APS need to be installed
b) Data Collection – For this APS installation is not necessary.
If ATP is run from OM, this uses Data collection and thus we will discuss only this process further in this document.
Since ATP requires furnishing the results instantly, there is a request set called “Data Collection Request Set” which is run to populate the temporary table with latest item supply demand information which is used by the ATP to furnish the results. This program summarizes the supply/demand picture in a summary table which is used by ATP program.
A Standard request set called “ATP Data Collection” is present in the system with below shown configuration. ATP Data Collection is a program which is run in order to collect data from ERP source transactional schema (INV, BOM, OM, PO, WIP etc) and store the data in a recognizable format in the APS destination schema (MSC Schema) for ATP.
When ATP is done from OM, it means the source and destination objects for Data collection are in the same instance. This is called Centralized configuration and only 1 instance is involved in this. ERP Source Data and APS destination data, both are stored in a single instance.

The complete Data collection process consist of 2 Step




a) Planning Data Pull (PDP)




b) Planning ODS Load





Planning Data Pull: This program is configured in the system as ATP Data Pull. This is the first step where data is pulled from different ERP source and gathered in MSC_ST% tables.
Planning ODS Load: This is the Operations Data Store (ODS) load process. The data from MSC_ST% process is validated and then inserted in the corresponding MSC% base tables. For each MSC_ST% table there is a corresponding MSC% base table in the schema. For example, for MSC_ST_BOMS there is a corresponding base table called MSC_BOMS.
The next step is to call the ATP APIs in order to call the programs which uses the ODS to provide the ATP results. When the Availability button is clicked in OM, or if scheduling is automatic, on entering order lines, the ATP will be fired automatically (it is integrated in the OM workflow). For calling ATP, public APIs MRP_ATP_PUB.CALL_ATP & MSC_ATP_PUB.CALL_ATP are used. MRP_ATP_PUB.CALL_ATP calls the MSC_ATP_PUB.CALL_ATP to get the ATP results. These programs store the data in MRP_ATP_DETAILS_TEMP and MRP_ATP_SCHEDULE_TEMP tables to generate the final data which is sent back through the API to the calling program.
The final analysis can be obtained from the table MRP_ATP_SUPPLY_DEMAND.
Once the ATP result is furnished, the data stored in the MRP_ATP_DETAILS_TEMP and MRP_ATP_SCHEDULE_TEMP are of no use and should be purged. A concurrent program “Purge ATP Temp Table” can be used to purge the data from these tables.


Setup Requirements for Enabling ATP Profile options:
INV:Capable to Promise – This profile option value indicates whether one uses the ATP based on Collection or ATP based on Planning output. For ATP based on collection, choose the value as ATP Based on Collection Data.
OM:Autoschedule - This profile option value if set to Yes, will automatically trigger scheduling as soon as a sales order line is saved.
OM:Authorized to Override ATP – If the value of this profile option is Yes, the authorized user will be allow to change the Schedule Ship / Arrival date and thus can override the date suggested by ATP.

Setup the ATP rules by following the navigation as shown below
Inventory -> Setup -> Rules -> Available to Promise





ATP rules are assigned at Item & Organization level. If the ATP rule at item level is not set, then the program checks the value at Organization level