ATP Does Not Honor Receiving Calendar
(Doc ID 1947000.1)
Last updated on FEBRUARY 03, 2019
Oracle Global Order Promising - Version 12.1.3 and later Information in this document applies to any platform.
VCP 184.108.40.206 Patch 14247039 Plus patch 19208014 - MSCGATPB.pls 120.39.12010000.58
SCENARIO --------------- 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
ISOLA 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.
PROBLEM ----------------- 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:
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!