Troubleshooting
Problem
Troubleshooting 101: ScheduleOrder ScheduleOrderLines findInventory getATP
Symptom
PART: API-IM 5.5 Platform
PRODUCT: Distributed Order
Management
COMPONENT: findInventory
OS: Solaris - 2.8
DATABASE: Oracle
- 9.2.0.4
WEB SERVER: Websphere AE - 5.2
WEB BROWSER: Internet Explorer -
6.0 sp1
How to troubleshoot the behavior of the api's ScheduleOrder
ScheduleOrderLines find Inventory getATP.
Cause
Resolving The Problem
Yantra's Availability Logic can be split into 3 layers
OrderManagement Layer
> Promise Layer > InventoryLayer
ScheduleOrderLines
>
ScheduleOrder > findInventory > getATP
getPossibleSchedules
>
Troubleshooting Steps
1. Use GetATP to isolate the
problem.
This will confirm available Supply by SupplyTypes and Demands
by Demand Types.
Any common user errors like mismatched UOM's
ProductClass etc will be exposed by this results.
For e.g., in one
case we got
Supply=ONHand=20,000
Demand=OpenOrder =
476
Demand=BackOrder = 50
Demand=StockOpenOrder.ex =
450
Demand=NFBackOrder = 50
Demand=Allocated = 200
Total
Demand=1226
Problem is NOT with Inventory Layer.
Next Check
PromiseLayer
2. Try different setting changes in the FindInventory
api.
Using DemandTypes, FulfillmentTypes, dateranges etc.
Document
Scenarios where Inventory is found and Scenarios where Inventory is NOT
found.
In this case,
FindInventory gives No Result if 'Blank'
DemandType is passed
does give Result if 'OpenOrder'
DemandType is passed
In your InventoryConsiderations Screen
(ParticipantModelling(DEFAULT)>Applications>InventorySynchronization>Invento
ryTypes&Considerations)
Check and make sure you have accurately matched your
Demand and Supply Types.
In this case, we found that there was a deviation
from Factory Setup and RSRV_ORDR and RESERVED where not matched with any Supply
Type. (Also Checked the Code and found out that Blank DemandType is interpreted
as RSRV_ORDER, This is a bug and will be fixed in 5.5, Blank Demand Type should
be interpreted as whatever is set in
ProcessType>Details>Inventory>DemandTypeForSchedule='Scheduled')
3.
Also check the Demand Type Screen or Table
In this case DemandType table for
Scheduled was flagged as Non-Committed as opposed to Promised
(FactoryDefault)
The Committed Level (Released/Promised/Non-Committed) is
very important in deceiding which demands will be knocked off against
Supply.
The settings here control the Promised/Allocated and PriorityFlags
in the InventoryDemandType Table
4. The above steps should bring to
light any inconsistencies in the data setup that result in inconsistencies in
the PromiseLayer behavior.
If the results in this layer are consistent
but you still have problems in the Order Management Layer,
then the problem
should be with factors like Scheduling Rules, BackOrderReprocess Interval, ATP
Horizon and AdvNotificationTime etc.
Troubleshooting steps will be added
here later.
Historical Number
PRI49425
Product Synonym
[<p><b>]Fact[</b><p>];
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21536579