Troubleshooting
Problem
Explanation for date time stamps for Procurement TO and for SO afer scheduleOrderLines API invocation --> using Use End of Shift Time flag is Sourcing/Scheduling rules
Symptom
Steps to Simulate:
---------------------------
1) Go to DOM --> Cross
Application --> Sourcing And Scheduling --> Basic Configuration --> Check "Find
Node based on Sourcing rule set up" for products being shipped.
2)
Configure the sourcing rule for products being shipped. Give the FromNode and
check Transfer/Transfer to this node when inventory is not available.
3)
Configure the sourcing rule for procurement as well accordingly.
4) Once
the configuration for procuring is done, set up the calendar NODE1 and NODE2
with shift from 07:00 to 21:00 and working all the seven days of the week.
5) Set this calendar as the Shipping and Receiving calendar in
Sourcing/Scheduling rules in Node Attributes.
6) Check "Use End of
Shift Time" flag Sourcing/Scheduling rules in Node Attributes.
6) Create
a sales order with an item. Dont give ship node and give a date ahead
(01-July-06) as delivery date.
7) Once the draft order gets created, see
the line availability and it should say that inventory is available for the
ship node on the delivery date mentioned as it can procure the item from
ProcureFromNode.
8) Confirm the order. Up on confirming the order invoke
scheduleOrderLines API with the input XML as below:
<Promise
DocumentType="0001" EnterpriseCode="DEFAULT" OrderNo="VijOrd#047">
<PromiseLines>
<PromiseLine DeliveryDate="20060701"
OrderLineKey="2006062705280444023" Quantity="1" ShipNode="NODE1"/>
</PromiseLines>
</Promise>
9) This API would create a Procurement
TO.
PART: Distributed Order Management 7.3SP1 Platform
Cause
Resolving The Problem
Setup:
====
Server is running on UTC timezone (GMT +00:00) Both Node
(Procurement and Shipping) are on EST/EDT, which is equal to UTC - 4
hours.
Both Nodes have their 'Use End of Shift Time' checked in their
Sourcing/Scheduling Rules.
Scenario 1:
========
1) Create an
order with Delivery Date = 06/30/2006.
2) Called the scheduleOrderLines API
with DeliveryDate = '2006-06-30T14:00:00' (UTC). Note the time stamp is
14:00:00
Observation:
A Procurement TO was created with
DeliveryDate='6/30/2006 1:00:00 AM' UTC that is 06/29/2006 21:00:00 EST. We
find that it is 1 day before order's delivery date.
Scenario
2:
========
3) Create an order with Delivery Date = 06/30/2006.
4)
Called the scheduleOrderLines API with DeliveryDate = '2006-06-30T08:00:00'
(UTC). Note the time stamp is 08:00:00
Observation:
A Procurement TO was
created with DeliveryDate='6/30/2006 1:00:00 AM' UTC that is 06/29/2006
21:00:00 EST. Again we find that it is 1 day before order's delivery
date.
Scenario 3:
========
5) Create an order with Delivery Date =
06/30/2006.
6) Called the scheduleOrderLines API with DeliveryDate =
'2006-06-30T00:00:00' (UTC).
Note the time stamp is 00:00:00. Whenever no
timestamp is passed in input xml for DeliveryDate, by default this is the
timestamp. For example DeliveryDate='20060630'.
Observation:
A
Procurement TO was created with DeliveryDate='6/29/2006 1:00:00 AM' UTC that is
06/28/2006 21:00:00 EST. Here we find that it appears 2 days before delivery
date.
Scenario 4:
========
7) Create an order with Delivery Date =
06/30/2006.
8) Called the scheduleOrderLines API with DeliveryDate =
'2006-06-30T01:01:00'. Note the time stamp is 01:01:00
Observation:
A
Procurement TO was created with DeliveryDate='6/30/2006 1:00:00 AM' UTC that is
06/29/2006 21:00:00 EST. We find that it is 1 day before delivery
date.
Conclusion:
========
We find that in Secnario 3, the
Procurement TO has DeliveryDate = '6/29/2006 1:00:00 AM' UTC that is 06/28/2006
21:00:00 EST. Even though it appears it is 2 days before delivery date, it is
still NOT a defect. See below for the explanation.
The explanation is as
follows:
=====================
In Scenario 3, we called
scheduleOrderLines API with DeliveryDate='2006-06-30T00:00:00' (UTC). This date
in EST = '2006-06-29 20:00:00' since EST=UTC-4 hours. Now Procurement TO will
be created with Delivery Date which is One day less than the Order's
DeliveryDate, that is 2006-06-28 21:00:00 EST. The time 21:00:00 is chosen
since the Node's shift is from 07:00-21:00, since our rule says, 'Use End Of
Shift time', it will choose 21:00 since this is End of the Shift.
Now
2006-06-28 21:00:00 EST = 2006-06-29 01:00:00 UTC (since UTC = EST+4) Hence
this is correct and working as Designed.
To compare this with other
Scenario, let us take Scenario 1.
we called scheduleOrderLines API with
DeliveryDate='2006-06-30T14:00:00' (UTC). This date in EST = '2006-06-30
10:00:00' since EST=UTC-4 hours. Now Procurement TO will be created with
Delivery Date which is One day less than the Order's DeliveryDate, that is
2006-06-29 21:00:00 EST.
Now 2006-06-29 21:00:00 EST = 2006-06-30 01:00:00
UTC (since UTC = EST+4)
Please Note:
=========
The Date/Time
in input XML is in Server's Locale, and we must NOT consider it as the actual
Date/Time that the Node will see. We must first convert this Date/Time that is
passed the input XML to that of Node's Locale Date/Time and then check if
things are fine. So even if it is 30th at Server, it could be still 29th at
Node and based on the time shift, it will decide the delivery date of the
Procurement TO.
If customer needs the Procurement TO be delivered on
30th, then they must pass date as 30th along with timestamp with time greater
than 1 AM. If only Date is passed without timestamp, then by default it is mid
night and it is less than 1 AM and Node's shift is still not complete (if UTC
is mid night, Node's EST time is 20:00 and is still in previous day shift,
since Node's shift completes only at 21:00 that is 1AM in UTC). If they pass
date as 30th with no time stamp, Node thinks that order needs to be delivered
on 29th 8pm, so it will try to create Procurement TO for 28th 9pm.
Historical Number
PRI49678
Product Synonym
[<p><b>]Fact[</b><p>];
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21550539