Manual order validation
🧩 Buying Policy System Overview
Buying Policies in DJUST define how customer orders are approved before being sent to suppliers.
🔗 Association to Customer Accounts
- Each Buying Policy is linked to a specific Customer Account.
- Users within the same account may have different roles in the purchasing process.
👥 Roles in the Buying Workflow
A Customer Account can include two distinct roles:
- Buyer: A user who creates and submits an order.
- Approver: A user responsible for validating the order before it reaches the supplier.
AttentionBoth the Buyer and the Approver must belong to the same Customer Account.
✅ Order Approval Process
- Order creation
- A Buyer initiates a new order from the store.
- Once submitted, the order enters the status: Waiting customer approval
- Approver notification
- If enabled in Settings > Email templates editor, DJUST automatically sends an “Order validation” email to all approvers in the Customer Account.
- This informs them that an order requires validation.
- Approval by Approver
- An Approver reviews and approves the order.
- Once approved, the order moves to the next stage: Waiting supplier approval.
NoteOnly one Approver is required to validate the order.
🔄 Buying Workflow
sequenceDiagram
participant Buyer
participant System as Djust
participant Approver
participant Mailer as 📧 Email Notification
Buyer->>System: Create an order
activate System
System->>System: Status = "Waiting customer approval"
System-->>Buyer: Order created successfully
System->>Mailer: Send "Order validation" email
Mailer-->>Approver: Email received (if enabled)
deactivate System
Buyer->>Approver: Request approval
activate Approver
Approver->>System: Approve the order
activate System
System->>System: Status = "Waiting supplier approval"
System-->>Approver: Order approved successfully
deactivate System
deactivate Approver
⚙️ Updating Buying Policies
- Buying Policies cannot be edited directly from the Djust BackOffice.
- Any changes must be performed via external integration, such as API updates or file imports.
AttentionChanging a Buying Policy impacts all pending associated orders.
🔄 Updating Approvers via API
The following Administration API route allows you to update the list of approvers for a given Buying Policy:
- API Endpoint: PUT /v1/buying-policies/{id}/approvers
Body format:
{
"approverIds": ["0000002771", "0000004197"]
}
AttentionThis operation uses REPLACE mode by default: Submitting a new list replaces all existing approvers with the new list provided.
Impact on Existing Orders
When the list of approvers on a Buying Policy is updated, DJUST applies the change to pending orders as follows:
- All existing orders linked to the policy that are still awaiting customer approval (status
WAITING_CUSTOMER_APPROVAL) will have their approver(s) reassigned according to the updated list. - Only approvals with status
WAITING_APPROVALwill be updated. - Orders that are already in or beyond the
CUSTOMER_APPROVEDstatus are not affected.
sequenceDiagram
participant Admin as 👤 Platform Operator (Admin)
participant API as 🔗 DJUST API
participant Orders as 📦 Affected Orders
Admin->>API: Updates approver list for a buying policy<br>PUT /v1/buying-policies/{id}/approvers
activate API
API->>API: Replace approvers in policy
API->>Orders: Find orders in WAITING_CUSTOMER_APPROVAL
loop For each order with approvals in WAITING_APPROVAL
API->>Orders: Update approver(s) on order
end
API-->>Admin: Approver update successful
deactivate API
🔄 Updating Buyers via API
It is also possible to update the list of Buyers assigned to a Buying Policy via API. This allows platform operators to adjust who is allowed to initiate orders that follow a specific approval workflow.
- API Endpoint: PUT /v1/buying-policies/{id}/buyers
Body format:
{
"buyerIds": ["0000002771", "0000004197"]
}
AttentionThis operation uses REPLACE mode by default: Submitting a new list replaces all existing buyers with the new list provided.
Impact on Existing Orders
When buyers are updated on a Buying Policy, DJUST will perform logic to update linked orders if they are still in early stages.
✅ Update scenarios
- If no related orders exist:
- The Buying Policy is updated, no other impact.
- If related orders exist in early stages (<
WAITING_SUPPLIER_APPROVAL) and:- A buyer is removed from the policy:
- Their associated order approval entries are deleted.
- If no other approval is required, the order is automatically promoted to
WAITING_SUPPLIER_APPROVAL.
- A buyer is added to the policy:
- Any of their pending orders (not yet validated) will be enriched with approvals defined by the updated policy.
- A buyer is removed from the policy:
NoteOnly orders in which all approval statuses are
WAITING_APPROVALare affected. Orders that are already approved, rejected, or pastCUSTOMER_APPROVEDare not updated.
sequenceDiagram
participant Admin as 👤 Platform Operator (Admin)
participant API as 🔗 DJUST API
participant Orders as 📦 Affected Orders
Admin->>API: Submits buyer update<br>PUT /v1/buying-policies/{id}/buyers
activate API
API->>API: Replace all buyers on policy
API->>Orders: Identify related orders in early stage
loop For each order
alt Buyer removed and order has no valid approver
API->>Orders: Remove approval, auto-advance to WAITING_SUPPLIER_APPROVAL
else Buyer added to policy
API->>Orders: Enrich with approvals from updated policy
end
end
API-->>Admin: Update successful or warning returned
deactivate API
Updated 22 days ago
