My Oracle Support Banner

ATP Does Not Honor Receiving Calendar (Doc ID 1947000.1)

Last updated on FEBRUARY 20, 2019

Applies to:

Oracle Global Order Promising - Version 12.1.3 and later
Information in this document applies to any platform.


VCP Patch 14247039
Plus patch 19208014 - MSCGATPB.pls 120.39.12010000.58

We need ATP to respect Calendar setups to have Supplier deliver on certain days of the week to the MFG/Shipping org to ship out the product after post processing LT is completed.
So using both Supplier capacity calendar to get
ATP_Check: manufacturing_cal_code := PRD:Thursday

and then Supplier sourcing calendar per note 730061.1 - to get
ATP_Check: receiving_cal_code := PRD:Monday

TEST1 is our supplier and they have 3 manufacturing plants that ship to 9 of our locations.
Each plant/location combination my have a different shipping day.
Due to restrictions of having only single Global ASL per each supplier site, we have created different supplier sites - so up to 27 supplier site so that we can adhere to the requirement of only 1 Global ASL per supplier site.

There is no capacity defined. We only use capacity calendars which restrict the shipping days. For all practical purposes the volume capacity is infinite, but it has 6 days of pre-processing lead time plus variable post-processing time, usually 3 days.

After much configuration and setups - we have achieve most of our requirements, but found that ATP appears to be using offset 2x times when computing the date.
Here is the scenario tested:

Capacity calendar : Thursday
Shipping method lead time :0
Receiving calendar : Monday - I expect receipt to calculate to the next Monday after shipping on Thursday
Pre-Processing lead time: 6 days
Today is 15-sep-14

Here is what i expect:
Today: 15-sep-14
6 business days later : 24 -sep-14
Next Thursday: 25-sep-14
Monday after that: 29-sep-14

Therefore the SSD should come out as 29-sep-14

The attached ATP file session-1093292 shows that the date does indeed get calculated initially to be 29-sep-14:

ATP_Check: receiving_cal_code := PRD:Monday
ATP_Check: intransit_cal_code := @@@
ATP_Check: shipping_cal_code := @@@
ATP_Check: manufacturing_cal_code := PRD:Thursday
ATP_Check: demand_source_type :=

but then does something odd applying some kind of offset and ending up with 06-oct-14. Seems to be similar issue as when I used the postprocessing time in my previous update

ATP_Check: Ship Date: 02-OCT-14
ATP_Check: ___________________Start Offset___________________
ATP_Check: --- Capacity to Dock ---
ATP_Check: Date after adding intransit LT using VIC: 02-OCT-14
ATP_Check: Date after validating on SSC: 02-OCT-14
ATP_Check: Date after validating on ORC: 06-OCT-14
ATP_Check: Date after subtracting PLT using SMC : 02-OCT-14
ATP_Check: Date after subtracting pre PLT using OMC : 24-SEP-14
ATP_Check: Date after adding PPLT using OMC: 06-OCT-14
ATP_Check: ___________________End Offset___________________
ATP_Check: ship date is 06-OCT-14
ATP_Check: original is 06-OCT-14
l_atp_lt_offset_ship_date := 06-OCT-14
ATP_Check: p_atp_record.ship_date := 06-OCT-14
ATP_Check: single level results is better than multi-level
ATO update details_temp date single lev: 06-OCT-14

-- SO THEN ---
Customer reviewed the ATP code and says -- "I understand what is happening now"
Let’s reiterate the scenario:
Today is: 16–sep-14
LT is 6 days = 24-sep-14
Next Thursday (MFG calendar)= 25-sep-14
Next Monday(Receiving Calendar)= 29 –sep-14 – this is the expected SSD/Dock date

Here is how ATP calculates the date:
Today is: 16–sep-14
LT is 6 days = 24-sep-14, this is calculated by MSC_ATP_PVT.ATP_Check
The MSC_ATP_PVT.ATP_Check offsets the 24-sep-14 to next business day of the Monday receiving calendar =29-sep-14 (next Monday)
This date is fed into MSC_ATP_REQ.Get_supplier_Atp_info as a new starting point of the calculation into MSC_ATP_REQ.Get_supplier_Atp_info, which calls MSC_CALENDAR.NEXT_WORK_DAY to find the next working Thursday (MFG calendar) =02-oct-14
This date is again offset by the receiving calendar to next Monday which is 06-oct-14
The problem is that the receiving calendar offset is done twice, pushing the manufacturing date out.
The receiving date should not be calculated before the manufacturing date as the product cannot be received before it is manufactured.

We need a fix so that the receiving offset is not done twice.




To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!

In this Document

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.