The inventory change transaction

The Inventory Change transaction is used for setting up events that involve inventory changes.

Invoked by

  • The adjustInventory() API
  • Any other API that is capable of doing a status change
Note: When the Promising server is being used, this transaction is not called on the Order server.

Attributes

The following are the attributes for this transaction:

Table 1. Inventory change atributes
Attribute Value
Base Transaction ID INVENTORY_CHANGE
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

Events raised

This transaction raises the following events:

  • Legacy platformSUPPLY_CHANGE

    This event is raised for every inventory supply change within Sterling™ Order Management System. It publishes detailed information about the changed supply.

    Key Data: INSTALL_DIR/xapidocs/api_javadocs/dbd/INVENTORY_CHANGE_SUPPLY_CHANGE_dbd.txt Data Published: INSTALL_DIR/xapidocs/api_javadocs/XSD/HTML/INV_INVENTORY_CHANGE.SUPPLY_CHANGE.html

  • Legacy platformSUPPLY_CHANGE_LIST

    This event is raised at the end of an adjustInventory API call to include all supply changes during this call.

    Key Data: None.

    Data Published: INSTALL_DIR/xapidocs/api_javadocs/XSD/HTML/INV_INVENTORY_CHANGE.SUPPLY_CHANGE_LIST.html

    Note: This event must be enabled at the Hub level.
  • Legacy platformDEMAND_CHANGE

    This event is raised for every inventory demand change within Sterling Order Management System. It publishes detailed information about the changed demand. Order information is published when the inventory organization is set to create demand details.

    Key Data: INSTALL_DIR/xapidocs/api_javadocs/dbd/INVENTORY_CHANGE_DEMAND_CHANGE_dbd.txt

    Data Published: INSTALL_DIR/xapidocs/api_javadocs/XSD/HTML/INV_INVENTORY_CHANGE_DEMAND_CHANGE.html

  • EXTERNAL_SUPPLY_CHANGE

    This event is raised for every supply change for externally maintained inventories within Sterling Order Management System.

    Key Data: INSTALL_DIR/xapidocs/api_javadocs/dbd/INVENTORY_CHANGE_EXTERNAL_SUPPLY_CHANGE_dbd.txt

    Data Published: INSTALL_DIR/xapidocs/api_javadocs/XSD/HTML/INV_INVENTORY_CHANGE_ EXTERNAL_SUPPLY_CHANGE.html

  • EXTERNAL_DEMAND_CHANGE

    This event is raised for every demand change for each organization that does not maintain its inventory within Sterling Order Management System.

    Key Data:

    INSTALL_DIR/xapidocs/api_javadocs/dbd/INVENTORY_CHANGE_EXTERNAL_DEMAND_CHANGE_dbd.txt Data Published: INSTALL_DIR/xapidocs\api_javadocs\XSD\HTML\INV_INVENTORY_CHANGE_ EXTERNAL_DEMAND_CHANGE.html

  • Legacy platformINVENTORY_CHANGE

    This event is raised only when we adjust Inventory with ONHAND_SUPPLY supply type. For example, when Inventory changes from HELD to ONHAND supply. It publishes detailed information of the changed supply. Key Data: INSTALL_DIR/xapidocs/api_javadocs/dbd/INVENTORY_CHANGE_INVENTORY_CHANGE_dbd.txt Data Published: INSTALL_DIR/xapidocs/api_javadocs/dbd/INVENTORY_CHANGE_INVENTORY_CHANGE_dbd.txt

  • Legacy platformON_INV_OWNERSHIP_TRNSFR

    This event is raised each time a transfer of inventory ownership happens. It publishes the information about the transfer of inventory ownership. Key Data: INSTALL_DIR/xapidocs/api_javadocs/dbd/INVENTORY_CHANGE_INVENTORY_TRANSFER_dbd.txt Data Published - INSTALL_DIR/xapidocs/api_javadocs/XSD/HTML/INV_INVENTORY_CHANGE.ON_INV_OWNERSHIP_TRANSFER.html

  • Legacy platformON_INV_MISMATCH_LIST

    This event is raised when mismatched supplies exist during inventory synchronization. The yfs.synchLoadedInventory.onInvMismatchEventListSize property determines the maximum number of inventory mismatch records allowed in one event. If this property is not defined, the batch size for the event is set to 1000.

    Key Data: None.

    Data Published: INSTALL_DIR/xapidocs/api_javadocs/XSD/HTML/INVENTORY_CHANGE.ON_INV_MISMATCH_LIST.html

Note: When defining one of the following events:
  • SUPPLY_CHANGE
  • DEMAND_CHANGE
  • EXTERNAL_SUPPLY_CHANGE
  • EXTERNAL_DEMAND_CHANGE
You should not call the changeOrder API as a result of these events. Doing so could cause the API to raise the event that called it, create an infinite cycle.