How to Use Direct Inventory Updates (Obsolete)
Author:
Fluent Commerce
Changed on:
30 Apr 2025
Overview
Direct Updates are one of the two reference ways to send last-on-hand updates into your workflows. Direct Updates are best used when you have a small volume of updates (maximum of 1000 updates).
Introduction
Author:
Fluent Commerce
Changed on:
30 Apr 2025
Overview
Direct Updates are one of the two reference ways to send last-on-hand updates into your workflows. Direct Updates are best used when you have a small volume of updates (maximum of 1000 updates).
As part of the Inventory Module, we have provided a reference implementation. This includes the JSON, rules, & configurations required to implement direct updates.
Key points
- Direct updates are designed to be used when the number of Inventory updates is quite small, less than 1000 updates
- Capabilities of the platform this process uses
- Supplementary guides
When should you use direct updates?
Direct updates are designed for use when the number of updates is quite small, less than 1000. Using direct updates results in quicker processing of vs. batch uploads when operating at these lower volumes.
Direct updates are best used in conjunction with batch updates. When a specific job has 1000 or fewer updates, direct updates should be used; if the job has more than 1000 updates, the batch should be used.
Capabilities of the platform this process uses
Capability | Description |
API to send the events against |
Supplementary guides
Guide | Description |
Learn how to send delta updates via events | |
Learn how to submit Batches and follow the suggested best practices |
Send Direct updates
Author:
Fluent Commerce
Changed on:
30 Apr 2025
Key Points
- Perform smaller inventory updates by sending an event into your workflow via event API.
Steps
Step 1: Authenticate against the Retailer you are sending the direct updates
For use of authentication please read: Authentication
The returned token will be used for later API calls.
Step 2: Send the direct inventory update event request
To send a direct update you need to ensure your data matches the below type. This will be a JSON object with the defined fields populated.
Parameter | Description | Data Type |
ref | ref | String |
type | The position type | String |
productRef | The ref of the variant product associated with the position | String |
locationRef | The ref associated with the position | String |
qty | The quantity | Integer |
correctedQty | corrected quantity | Integer |
inventoryQuantity | Extra optional attributes sent as part of the payload | JSON |
1{
2 "name": "INVENTORY_UPDATE",
3 "accountId": "YOUR_ACCOUNT",
4 "retailerId": "1",
5 "entityRef": "DEFAULT:2",
6 "entityType": "INVENTORY_CATALOGUE",
7 "entitySubtype": "DEFAULT",
8 "rootEntityType": "INVENTORY_CATALOGUE",
9 "rootEntityRef": "DEFAULT:2",
10 "attributes":
11 {
12 "inventoryUpdates":
13 [
14 {
15 "ref" : "testref1",
16 "productRef": "D45",
17 "locationRef": "LOC_MEL",
18 "qty": 350,
19 "correctedQty":0,
20 "type":"DEFAULT"
21 }
22 ]
23 }
24}
How to Use Enhanced Inventory Attributes in Your Payloads
Author:
Fluent Commerce
Changed on:
9 Feb 2025
Overview
This guide explains how to leverage the `attributes`
object to include custom data in your payloads. By supporting both simple key-value pairs and complex JSON structures, the `attributes`
object offers the flexibility to meet diverse business requirements—whether you’re managing detailed product information, optimizing processes, or integrating with custom workflows. You’ll also learn about recommended fields like `expectedOn`
, `storageAreaRef`
, and `condition`
, which are automatically integrated into workflows for streamlined updates and better data consistency.
Key points
- Flexible Attribute Structure: The
`attributes`
object supports any combination of key-value pairs, including complex JSON structures and arrays. This flexibility allows you to customize the data sent in your inventory payloads to meet specific business needs. - Recommended Attributes: Certain key attributes, such as
`expectedOn`
,`storageAreaRef`
, and`condition`
, are automatically integrated into our platform’s workflows. These fields will be directly updated in the inventory quantity associated with the incoming record, facilitating seamless integration with existing fields. - Custom Attribute Availability: Any custom attributes that you include in the
`attributes`
object will be available in workflows via`inventoryPosition.inventoryQuantity.attributes.<fieldname>`
. This enables you to incorporate custom data into rule-based processes or other logic tailored to your business requirements. - ISO 8601 Date Format: For any date-related attributes, it is recommended to use the ISO 8601 format (e.g.,
`YYYY-MM-DDTHH:MM:SSZ`
) to ensure consistency and proper handling within the system. - Integration with Workflows: The system is designed to handle both recommended and custom attributes, making them accessible within the workflow context. This ensures that you can leverage these attributes in custom rules and other logic, depending on the specific needs of your implementation.
- Extensibility: While the table of recommended attributes provides a useful starting point, you are encouraged to extend the
`attributes`
object with any additional fields relevant to your business processes. The flexibility of this structure allows for robust customization.
Prerequisite: Workflow and Plugin Requirements
Leveraging Recommended Attributes
While the `attributes`
object gives you the freedom to define and send any custom fields, we recommend using certain key attributes that are optimized for our platform. These recommended fields, such as `expectedOn`
, `storageAreaRef`
, and `condition`
, are automatically integrated into our platform’s management workflows. This means that these fields will be directly updated in the quantity associated with the incoming record, ensuring seamless operation and enhanced performance.
Flexibility for Custom Attributes
Beyond the recommended attributes, you have the flexibility to include additional fields that are specific to your business requirements. Whether you need to send simple key-value pairs, nested JSON structures, or arrays, our system will these and make them available within the via `inventoryPosition.inventoryQuantity.attributes.<fieldname>`
. This allows you to incorporate your custom data into rule-based processes or other logic tailored to your specific business scenarios.
The table below provides examples of the recommended attributes along with their descriptions, usage, and examples. However, you are not limited to these fields—you can extend the `attributes`
object with any custom fields that meet your needs. These will be accessible within the for your custom implementations.
Recommended Attributes Table
Attribute Description | Recommended Attribute Key Name | Example | Notes |
Specific storage locations in a . |
| "LOC1-SR-1" | Available in the via |
Date when new stock is expected. |
| "2024-10-31T00:00:00.00Z" | Available in the via |
Information on the manufacturing country. |
| "France" | Available in the via |
Details like production date and . |
|
| Available in the via |
Indicates the last date a product is safe to use. |
| "2025-12-31T23:59:59.00Z" | Available in the via |
Unique identifier for each supplier. |
| "SUP12345" | Available in the via |
Details on how is quantified. Use Case: Ensure consistency in counting, aid in , and simplify stocktaking processes. |
| "PCS" | Available in the via |
Unique identifier for high-value items. |
| "SN123456789" | Available in the via |
Links to specific purchase orders. |
| "PO987654321" | Available in the via |
Source of transfer. |
| "STORE01" | Available in the via |
Purpose of the . |
| "For Sale" | Available in the via |
Indicates the condition of the item. |
| "NEW" | Available in the via |
Integration guidelines for Direct Updates with Attributes
Author:
Fluent Commerce
Changed on:
30 Apr 2025
Overview
This document provides guidelines for handling message size limitations when sending updates via the `INVENTORY_UPDATE`
. It highlights the importance of keeping message sizes around 200KB and offers strategies for estimating the number of updates per message. Recommendations for optimizing message content and ensuring efficient integration are also included.
Key points
- Message size limit: 200KB for inventory update messages.
- Payload structure: Inventory updates include multiple attributes, which affect message size.
- Size estimation: Approximately 160-170 updates per message, based on average update size of 1.2KB.
- Integration strategies: Manage attributes, batch updates effectively, and test thoroughly to ensure proper handling of message size.
Message Size Considerations
When sending updates through the `INVENTORY_UPDATE`
, the message size should be kept around 200KB. This ensures efficient processing and prevents message delivery failures.
Estimating the Number of Inventory Updates per Message
The number of updates that can fit into a single message depends on the size of each update, which varies based on the number and size of the attributes. A typical update, similar to the following sample payload, is approximately 1.2 KB.
Sample Payload Structure:
1{
2 "name": "INVENTORY_UPDATE",
3 "accountId": "YOUR_ACCOUNT",
4 "retailerId": "1",
5 "entityRef": "DEFAULT:2",
6 "entityType": "INVENTORY_CATALOGUE",
7 "entitySubtype": "DEFAULT",
8 "rootEntityType": "INVENTORY_CATALOGUE",
9 "rootEntityRef": "DEFAULT:2",
10 "attributes": {
11 "inventoryUpdates": [
12 {
13 "ref": "testref1",
14 "productRef": "D45",
15 "locationRef": "LOC_MEL",
16 "qty": 350,
17 "correctedQty": 0,
18 "type": "DEFAULT",
19 "inventoryQuantity": {
20 "attributes": {
21 "expectedOn": "2024-10-31T00:00:00.00Z",
22 "storageAreaRef": "LOC_MELB_RET2-SR1",
23 "condition": "NEW",
24 "countryOfOrigin": "China",
25 "expiryDate": "2025-12-31T23:59:59.00Z",
26 "supplierId": "SUP12345",
27 "unitOfMeasurement": "PCS",
28 "serialNumber": "SN123456789",
29 "purchaseOrderNumber": "PO987654321",
30 "transferFrom": "STORE01",
31 "inventoryPurpose": "For Sale",
32 "manufacturingBatchInfo": {
33 "batchNumber": "BATCH001",
34 "productionDate": "2024-01-15T00:00:00.00Z"
35 }
36 }
37 }
38 }
39 ]
40 }
41}
42
`
`
Estimating Update Size
A typical update like the example above is 1.2 KB. This estimate is based on average-sized strings for fields like `refs`
, `dates`
, and `IDs`
.
Calculating Updates per Message
Given the 200KB size limit, approximately 160-170 inventory updates can be included in a single message, depending on sizes. This estimate includes a small buffer for variability in size.
Recommendations for Integration
- Dynamic Calculation: Implement a dynamic size calculation in your code to stay within the 200KB limit. The actual number of updates may vary based on the content of each update.
- Attribute Management:
- The number and size of attributes impact how many updates fit into a message.
- Omit null or empty attributes to save space.
- Use concise attribute names and values where possible.
- Batching Strategy:
- Start with batches of 150 updates per message as a safe margin.
- Monitor for failures and adjust batch sizes accordingly.
- Be ready to split large batches into multiple messages if necessary.
- Testing:
- Test thoroughly with various update sizes and attribute combinations to ensure your integration can handle different scenarios effectively.