SendEventToUpdateInventoryQuantity
Changed on:
19 July 2024
Overview
The triggers re-calculation with name provided in the input parameter with +/-ve quantities of each item on the basis of the type of operation.
| Plugin Name | Order Reference Module |
|---|---|
| Namespace | [[account.id]].order |
The is the foundation for order-related implementations. It provides reference workflows for , and mixed baskets and those needed to build your own. Extensible by design, use this Module as a base to build a solution to your customers' needs.
UI Description
Triggers inventory re-calculation event with event name provided in the input parameter with +/-ve quantities of each item on the basis of the type operation like RESERVE, UNRESERVE or RESET_RESERVE.
Accepts
- FULFILMENT
Actions
- This rule creates and sends an event to Inventory Catalogue with item quantity details that need to be updated.
Rule parameters
Parameter | Description |
inventoryCatalogueRef | The ref of catalogue where need to be updated. |
operation | Operation type (RESERVE/UNRESERVE or RESET_RESERVE) to be used for updating accordingly.
|
eventName | The name of to be triggered. |
retailerId | The retailer id. |
Event attributes
This does not directly identify any attributes.
Exceptions
This will throw an RubixException: 500 in case of an error.
Configuration example
1{
2 "name": "<ACCOUNTID>.order.SendEventToUpdateInventoryQuantity",
3 "props": {
4 "inventoryCatalogueRef":"{{inventoryCatalogueRef}}",
5 "operation":"RESET_RESERVE",
6 "eventName":"UpdateInventoryQty",
7 "retailerId":"{{invRetailerId}}"
8 }
9}Detailed Technical Description
Based on the `operation` parameter of this , this will send a cross-workflow with the configured `eventName` to the catalogue defined by `inventoryCatalogueRef` parameter. When the catalogue belongs to a different retailer, the `retailerId` parameter can be used to defined the corresponding id.
The `operation` parameter drives the logic what quantities will be sent in the attributes for each item in the fulfilment. The general payload structure is as follows:
1{
2 "retailerId": "{{retailerId}}",
3 "accountId": "{{accountId}}}}",
4 "name": "{{eventName}}",
5 "entityRef": "{{inventoryCataloguRef}}",
6 "entityType": "INVENTORY_CATALOGUE",
7 "rootEntityType": "INVENTORY_CATALOGUE",
8 "rootEntityRef": "{{inventoryCataloguRef}}",
9 "attributes": {
10 "items": [
11 {
12 "skuRef": "{{variantProductRef}}",
13 "reserveQty": 0, //quantity which will be reserved
14 "cancelQty": 0, //quantity which will be cancelled/rejected
15 "saleQty": 0, //quantity which will was sold/picked
16 "correctionQty": //quantity which will was not sold/miss-picked
17 "locationRef": "{{locationRef}}",
18 "fulfilmentId": "{{fulfilmentId}}"
19 "quantity": //legacy,
20
21 }
22 ]
23 }
24}The following `operation` parameter values are available:
- RESERVE
This operation will set the reserveQty field in the event to the quantity which was requested for each item. In the inventory catalogue workflow, this usually results in an inventory quantity of type`RESERVED`for each item to be created. - UNRESERVE
This operation will set the cancelQty field in the event to the quantity which was cancelled or expired for each item. In the inventory catalog workflow, this usually results in inventory quantities to be deactivated. - RESET_RESERVE
This operation will set the saleQty and correctionQty fields in the event to the quantity which were confirmed or rejected. In the inventory catalogue workflow, this usually results in inventory quantities of type`SALE`and`CORRECTION`to be created as well as the deactivation of the corresponding`RESERVED`record.
Version History
v1.0.0
refers to
