Order Incident Management (Order & Order Line)
DJUST enables Customer Users to report and view incidents related to orders or individual order lines. These incidents may reflect delivery issues, missing items, damaged goods, or other anomalies requiring supplier attention.
🧠 Concept Overview
- Incidents are issues reported on a logistic order (
linkedType = ORDER) or a logistic order line (linkedType = ORDERLINES). - Each incident can include:
- One or more reason codes (e.g. DAMAGED, MISSING)
- An associated thread of messages
- Affected quantity per line
- Optionally: custom fields, photos, and external references
- Incidents are grouped by functional ID, even if multiple lines are affected.
- Incidents statuses are
OPEN,ON_GOINGandCLOSED.
📝 Order Incident Creation
✏️ Standard workflow
sequenceDiagram
participant User as 👤 Customer User
participant Front as 🖥️ Frontend App
participant API as 🔗 DJUST
participant Hub as 🧬 Data Hub Connector
%% Déclaration d’un incident (commande ou ligne)
User->>Front: Click "Report an incident" or "Ask for a refund"...
User->>Front: Select one or more reasons
User->>Front: Optionally add some elements (files, photos...)
User->>Front: Create new incident
Front->>API: ORDER-101
API-->>Front: Incident created (id, threadId)
%% Synchronisation vers le data hub
Note over API,Hub: Optional synchronization
API-->>Hub: Export incident via API Connector
Hub-->>API: Synchronize statuses
When Customer Users wish to report an incident to an order or order line, they use a form in which they specify:
- the reason(s) for the incident
- if necessary, add additional information such as photos, an invoice, etc.
Incidents are created using the ORDER-101 route. This replaces older routes:
-
POST /v1/shop/logistic-orders/{orderLogisticId}/incidents -
POST /v1/shop/logistic-orders/{orderLogisticId}/lines/incidents
Important
- The historical route
THREAD-100cannot be used with the new Order Incident process.- Mirakl support for order incident is not yet available throughout the new Order Incident APIs.
📏 Quantity control
The sum of incident quantities per line cannot exceed the order line’s original quantity (by default).
Example
- Line ordered quantity = 10
- Incident #1 = 5 → ✅ accepted
- Incident #2 = 6 → ❌ rejected
This is the default behaviour.
For various reasons, you may want your platform to work without this check. In this case, contact your CSM to disable it for you using the
VERIFY_ORDER_LINE_QUANTITIES_FOR_INCIDENTfeature flag.This will allow you to report incidents that go beyond the initial quantity of the line.
🧮 Default quantity behaviour
If quantity is omitted, it defaults to the remaining quantity on that line.
Example
- Ordered = 10
- Previous incidents = 3 + 5
- Omitted quantity ⇒ 2 (10 – 3 – 5) for any new incident declared
🧰 Incident declaration supports
| Feature | Supported |
|---|---|
| Unified endpoint for incidents (order and order line) | ✅ |
| Multiple lines in a single declaration | ✅ |
| Incident grouping logic | ✅ |
| Quantity control | ✅ (with feature flag override) |
| Custom fields (order and order line incidents) | ✅ |
| External ID support for external management | ✅ |
| Access control on accounts | ✅ |
🔍 Order Incident Consultation
✏️ Standard workflow
This section covers two key steps in how Customer Users interact with order-related incidents in the frontend application:
- Fetching the list of incidents linked to orders or order lines.
- Retrieving the details of a specific incident using its ID.
sequenceDiagram
participant User as 👤 Customer User
participant Front as 🖥️ Frontend App
participant API as 🔗 DJUST
%% Consultation d’un ou plusieurs incidents
User->>Front: Views incident list
Front->>API: ORDER-559
API-->>Front: Incident list
%% Visualisation d’un thread
User->>Front: Click on an incident
Front->>API: ORDER-503
API-->>Front: Incident details
🧾 Step 1 – Viewing the List of Incidents
The user accesses a view showing incidents associated with their past orders (at the order or order line level) via ORDER-559.
Incidents can be filtered with the following parameters:
| Parameter | Required | Description |
|---|---|---|
linkedType | ✅ Yes | ORDER or ORDERLINES. Both combined is not allowed. |
ids | ❌ No | Comma-separated list of order or line incident IDs |
status | ❌ No | e.g. OPEN, CLOSED, ON_GOING |
orderLineStatus | ❌ No | Filter on statuses at line level |
reasonCodes | ❌ No | Filter by reason code external IDs |
customFields | ❌ No | Filter on specific custom field values |
customerAccountId | ❌ No | Optional: override the header account ID |
suppliers | ❌ No | Filter by supplier external ID |
💡 Suggested Frontend Use:
- Display a badge or highlight on affected orders/lines.
- Group by status or supplier if needed.
- Display incident status, count or last update date.
- Link to incident detail page
🔎 Step 2 – Viewing a Specific Incident’s Details
The customer user accesses a detailed view of a specific incident associated with their past orders (at the order or order line level) via ORDER-503. This endpoint retrieves full metadata for a single incident:
- What it is linked to (order or order line)
- Reason(s), quantity, custom fields
- Associated thread ID for messaging
💡 Suggested Frontend Use:
- Show incident details and metadata
- Provide access to the discussion thread (using
threadId) - Include an action button to reply or escalate
Updated 8 days ago
