Release Notes
Start typing to search…
Back to All

Djust 3.79.0 - Semaine du 18 Aout 2025

about 1 month ago

Périmètre

BackOffice Djust

Améliorations graphiques et optimisations de design :

Dans la continuité de la refonte globale du Back Office de Djust, un redesign des pages suivantes a été apporté afin de simplifier l'expérience utilisateur.

  • Page de creation d'un produit / variant : Product -> Create.
  • Page de creation/mise à jour des clients d'interfaces pour le DataHub : Data Hub -> Client -> Create/Update.

API

📘

NEW

Buying Policies

  • Récupération des raisons de blocage des commandes

Un nouvel endpoint d’administration permet aux opérateurs de récupérer la liste des buying policies ayant bloqué une ou plusieurs commandes logistiques.

L’objectif est de faciliter le diagnostic et la résolution des blocages, sans surcharger les réponses standard de l’API Orders.

🔍 Récupération des raisons de blocage

ADM-BUYING-POLICY-552 - GET /v1/buying-policies/blocking-reasons

Renvoie, pour chaque commande logistique fournie, la liste des buying policies qui ont empêché sa validation (ex. CREDIT_CONTROL, QUOTA, MANUAL_VALIDATION).

Query parameters :

  • logisticOrderIds (requis) : liste des IDs des commandes logistiques concernées
  • idType (optionnel, défaut REFERENCE) : type d’identifiant (DJUST_ID, EXTERNAL_ID, REFERENCE)
ℹ️

Règles :

  • Si un ID est invalide, il est ignoré
  • Si aucune policy ne bloque une commande, le tableau blockingPolicies est vide
  • Maximum 20 policies retournées par commande
{
  "blockingReasons": [
    {
      "logisticOrderId": "ORD-001",
      "blockingPolicies": [
        {
          "type": "MANUAL_VALIDATION",
          "id": "BP-MANUAL-001"
        }
      ]
    }
  ]
}

👍

UPDATE

Orders x Buying Policies

  • Filtrage des commandes par type de buying policy

La route d’administration POST /v1/logistic-orders permet désormais de filtrer les commandes bloquées par un ou plusieurs types spécifiques de buying policies.

Cette évolution complète le filtre blockedByBuyingPolicy en permettant de cibler uniquement certaines policies.

🔍 Filtrer par type de buying policy

Nouveau paramètre facultatif : blockingPolicyTypes (array)

  • Permet de lister un ou plusieurs types de buying policies pour restreindre la recherche.
  • Les valeurs fonctionnent en OU : si au moins une policy correspond, la commande est incluse dans le résultat.
{
  "blockedByBuyingPolicy": true,
  "blockingPolicyTypes": ["CREDIT_CONTROL", "MANUAL_VALIDATION"]
}

Valeurs possibles :

  • CREDIT_CONTROL
  • QUOTA
  • MANUAL_VALIDATION
ℹ️

Règles importantes :

  • Le filtre blockingPolicyTypes n’est pris en compte que si blockedByBuyingPolicy = true.
  • Si blockedByBuyingPolicy est false ou absent, blockingPolicyTypes est ignoré.
  • Le statut de commande doit être BLOCKED_BY_POLICY pour que le filtre soit appliqué.

Comme énoncé ci-dessus, un nouveau statut a été ajouté dans le workflow de commande : BLOCKED_BY_POLICY. Il est présent sur les routes suivantes :

GET /v1/logistic-orders
POST /v1/logistic-orders
POST /v1/logistic-orders/export
GET /v1/logistic-orders/{orderLogisticId}
GET /v1/logistic-orders/{orderLogisticId}/approvals
GET /v1/logistic-orders/{orderLogisticId}/history
GET /v1/supplier-quotes/{supplierQuoteId}/orders

ORDER-560 - GET /v1/shop/commercial-orders
ORDER-100 - POST /v1/shop/commercial-orders
ORDER-500 - GET /v1/shop/commercial-orders/{commercialOrderId}
ACCOUNT-550 - GET /v1/shop/customer-accounts/orders
ACCOUNT-555 - GET /v1/shop/customer-accounts/organisations/{organisationId}/orders
N/A - GET /v1/shop/logistic-orders
ORDER-550 - POST /v1/shop/logistic-orders
ORDER-501 - GET /v1/shop/logistic-orders/{orderLogisticId}
ORDER-205 - PATCH /v1/shop/logistic-orders/{orderLogisticId}
ORDER-200 - PUT /v1/shop/logistic-orders/{orderLogisticId}/approve
ORDER-556 - GET /v1/shop/logistic-orders/{orderLogisticId}/approvers
ORDER-201 - PUT /v1/shop/logistic-orders/{orderLogisticId}/cancel
ORDER-203 - PUT /v1/shop/logistic-orders/{orderLogisticId}/confirm-reception
ORDER-204 - PUT /v1/shop/logistic-orders/{orderLogisticId}/disapprove
ORDER-107 - POST /v2/shop/supplier-quotes/{supplierQuoteId}/initialize-orders

Offers

  • Remontée de l'information online/offline sur les offres

Afin de savoir si une offre est live ou non, l'information online est remontée sur l'ensemble des APIs d'administration d'offres suivantes :

GET /v1/offer-inventories
PATCH /v1/offer-inventories
POST /v1/offer-inventories
GET /v1/offer-inventories/{offerInventoryId}
PUT /v1/offer-inventories/{offerInventoryId}
PATCH /v1/offer-inventories/{offerInventoryId}/offer-prices
POST /v1/offer-inventories/{offerInventoryId}/offer-prices
PUT /v1/offer-inventories/{offerInventoryId}/offer-prices

Orders

  • Ajout de la date de dernière synchronisation du panier (lastSyncAt)

Un nouveau champ lastSyncAt a été ajouté à la Commercial Order.

Il indique la date et l’heure de la dernière synchronisation réussie du panier (nouvelle API qui sera déployée dans la prochaine version).

Le format est ISO 8601 (ex. "2025-07-22T14:30:00Z").

La modification est visible dans la réponse de l'appel à :

ORDER-107 - POST /v2/shop/supplier-quotes/{supplierQuoteId}/initialize-orders
ORDER-560 - GET /v1/shop/commercial-orders
ORDER-100 - POST /v1/shop/commercial-orders
ORDER-500 - GET /v1/shop/commercial-orders/{commercialOrderId}

  • Ajout d’un champmetadata

Un nouveau champ metadata est désormais disponible dans la route API :

ORDER-561 - PUT /v2/shop/commercial-orders/{commercialOrderId}/lines

Ce champ permet d’associer, à chaque ligne, sous la forme de paires clé/valeur libres, des données contextuelles (ex. : localisation, informations logistiques, unité de vente etc.) qui seront transmises à l’API externe dans le cadre du Real-Time Pricing qui sera déployé prochainement.