IBM Support

Duplicate Message created ON_INV_MISMATCH for INVENTORY_CHANGE transaction if inventory is updated to 0 using loadInventoryMismatch API.

Troubleshooting


Problem

Attempts to run loadInventoryMismatch API raises a duplicate ON_INV_MISMATCH event in IBM Sterling Selling and Fulfillment Suite.

Symptom

Steps to reproduce:

  1. Run the below loadInventoryMismatch input xml:

    <Item ApplyDifferences="Y" CompleteInventoryFlag="Y"
       InventoryOrganizationCode="DEFAULT" ItemID="item4" ProductClass=""
       ReasonCode="" ReasonText="" ShipNode="Store1" UnitOfMeasure="EACH"
    YantraMessageGroupID="90012016082900003">
       <Supplies>
           <Supply ActualQuantity="100.00" AvailabilityType="TRACK"
               ChangedQuantity="-100.00" ExpectedQuantity="0.00" Segment=""
               SegmentType="" SupplyLineReference="" SupplyReference=""
               SupplyReferenceType="" SupplyType="ONHAND"/>
       </Supplies>
    </Item>


  2. Run the API again with the below input:

    <Item ApplyDifferences="Y" CompleteInventoryFlag="Y"
       InventoryOrganizationCode="DEFAULT" ItemID="item4" ProductClass=""
       ReasonCode="" ReasonText="" ShipNode="Store1" UnitOfMeasure="EACH" YantraMessageGroupID="90012016082900003">
       <Supplies>
           <Supply ActualQuantity="0.00" AvailabilityType="TRACK"
               ChangedQuantity="0.00" ExpectedQuantity="0.00" Segment=""
               SegmentType="" SupplyLineReference="" SupplyReference=""
               SupplyReferenceType="" SupplyType="ONHAND"/>
       </Supplies>
    </Item>
The second instance of the event will create a duplicate message for one inventory update and may create confusion.

Cause

This is a product defect.

Diagnosing The Problem

When inventory updates sent to OMS are being consumed using loadInventoryMismatch and syncLoadedInventory APIs, ON_INV_MISMATCH event gets raised twice when an inventory record is updated from available to unavailable i.e the change is happening from non zero quantity to 0 quantity.
In this circumstance - the event is raised twice - once when the quantity changes from non-zero to zero and a second time when it moves from 0 to 0.

These events are raised only when the supply for an item is to be zeroed out. When the supply of an item is set to 0, product deletes the record from the supply table and an additional processing of the zero supply record is called.

Resolving The Problem

Workaround:
To avoid this confusion, you can implement a solution to ignore the events that are raised with ActualQuantity=0.00 and ChangedQuantity=0.00.

[{"Product":{"code":"SS6PEW","label":"IBM Sterling Order Management"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Component":"--","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All","Edition":"","Line of Business":{"code":"LOB59","label":"Sustainability Software"}}]

Document Information

Modified date:
16 June 2018

UID

swg22004337

Page Feedback