Périmètre
Back Office
- Ajout de la suppression d'adresse dans le détail d'un account
La suppression d’une adresse directement depuis la page de détail d’un account est désormais possible, avec les contraintes suivantes :
- Un account doit toujours posséder au moins une adresse de billing.
- L’option de suppression n’est donc disponible que si l’account a plus d’une adresse.
- Ajout de la possibilité de configurer les URLs front d'un environnement (hors multi-stores)
Il est désormais possible de configurer les URLs front d'un environnement mono store comme il était possible de le faire pour les environnements multi-stores.
La page Application Settings a été complétée pour configurer ces URLs en autonomie.
API
NEW
Operations
- Récupération des opérations visibles par un acheteur
Contexte :
Les customer users (acheteurs) peuvent désormais consulter la liste des opérations actives auxquelles leur compte a accès, directement depuis leur environnement connecté.
Cette évolution leur permet de découvrir les campagnes en cours et de démarrer leurs achats sur les opérations pertinentes selon leur store et leurs droits.
⚙️ Cette route est réservée aux clients de type ACCOUNT et protégée par le Feature Flag OPERATIONS.
Fonctionnement métier :
- Visibilité
- Seules les opérations au statut ACTIVE et actives temporellement sont visibles (now ∈ [
startDate,endDate]). - Type
PUBLIC→ visible par tous les accounts rattachés au store effectif. - Type
PRIVATE→ visible uniquement si le customer user ou son account est explicitement associé à l’opération.
- Seules les opérations au statut ACTIVE et actives temporellement sont visibles (now ∈ [
API correspondante :
🔍 Récupérer les opérations visibles pour l’acheteur
OPERATION-550 - GET /v1/shop/operations
{
"operations": [
{
"id": "SUMMER_OPE_0825",
"name": "Summer Operation · Fine Food",
"type": "PRIVATE",
"startDate": "2025-11-21T00:00:00Z",
"endDate": "2025-11-28T23:59:59Z",
"createdAt": "2025-08-04T12:34:56Z"
}
]
}- Récupération unitaire d’une opération par l’acheteur
Contexte :
Les customer users (ACCOUNT) peuvent désormais consulter le détail d’une opération spécifique à laquelle ils ont accès, directement depuis leur environnement connecté.
Cette évolution permet d’afficher la page de détail d’une opération (nom, description, période, champs personnalisés, etc.) sans exposer l’ensemble du catalogue de produits associé.
⚙️ Cette route est réservée aux clients ACCOUNT et protégée par le Feature Flag OPERATIONS. 🔒 Elle ne renvoie que les métadonnées d’une opération (pas les lignes produits).
Fonctionnement métier :
- Visibilité
- Seules les opérations :
- au statut ACTIVE,
- et actives temporellement (now ∈ [
startDate,endDate]) sont consultables.
- Les opérations de type PUBLIC sont visibles par tous les accounts du store effectif.
- Les opérations de type PRIVATE ne sont visibles que si le customer user ou son account y est explicitement associé.
- Seules les opérations :
API correspondante :
🔍 Récupération unitaire d’une opération
OPERATION-500 - GET /v1/shop/operations/{operationId}
{
"id": "VIP_OPE_2025",
"type": "PRIVATE",
"status": "ACTIVE",
"startDate": "2025-09-01T00:00:00Z",
"endDate": "2025-09-30T23:59:59Z",
"createdAt": "2025-07-20T09:00:00Z",
"name": "VIP Autumn Sale",
"description": "Exclusive offers for selected accounts.",
"customFieldValues": [
{
"customField": {
"externalId": "TAX_RATE",
"externalSource": "MIRAKL",
"name": {
"en-GB": "Tax rate",
"fr-FR": "Taux de taxe"
},
"role": "PRODUCT_TAX_RATE",
"status": "ACTIVE"
},
"value": "5%"
}
]
}- Récupération des lignes d’une opération par l’acheteur
Contexte :
Les customer users (acheteurs) peuvent désormais récupérer la liste des produits (variants) d’une opération à laquelle ils ont accès, avec leurs libellés localisés et contraintes de quantités (minQuantity, maxQuantity, recommendedQuantity).
Cette évolution permet d’afficher l’assortiment réel visible pour le compte connecté, en respectant le scoping catalogue et les règles de visibilité applicables au store effectif.
⚙️ Cette route est réservée aux clients de type ACCOUNT et protégée par le Feature Flag OPERATIONS.
Fonctionnement métier :
- Visibilité de l’opération
- Seules les opérations
ACTIVEet actives temporellement (now ∈ [startDate,endDate]) sont consultables. - Type PUBLIC → visible pour tous les accounts du store effectif.
- Type PRIVATE → visible uniquement si le customer user ou son account est explicitement associé.
- Seules les opérations
- Visibilité des variants
- Les variants retournés sont ceux présents à la fois dans l’assortiment de l’opération et dans le catalogue visible pour l’account connecté.
- Les variants non visibles sont ignorés silencieusement.
- Si aucun variant n’est visible → 200 OK avec lines: [].
API correspondante :
🔍 Récupération des lignes produits d’une opération
OPERATION-551 - GET /v1/shop/operations/{operationId}/lines
{
"lines": [
{
"variantId": "VAR-000123",
"variantName": "Brie de Meaux AOP",
"sku": "SKU-100045",
"minQuantity": 0,
"maxQuantity": null,
"recommendedQuantity": 3
},
{
"variantId": "VAR-000456",
"variantName": "Comté 18 mois",
"sku": "SKU-100078",
"minQuantity": 2,
"maxQuantity": 10,
"recommendedQuantity": 5
}
]
}
UPDATE
Opérations
- Créer une commande depuis une Opération (FULL ou PARTIAL)
Contexte :
Les acheteurs (ACCOUNT) peuvent désormais initialiser une commande directement depuis une Opération à laquelle ils ont accès.
Deux modes sont proposés :
- FULL : ajout automatique de toutes les lignes éligibles et visibles de l’Opération, avec des quantités par défaut.
- PARTIAL : création de la commande vide mais liée à l’Opération, puis ajout des lignes au cas par cas.
⚙️ Feature flag requis : OPERATIONS
🏬 Store effectif : dj-store s’il est fourni, sinon store par défaut du tenant (le user doit y être rattaché).
🔐 Visibilité Opération : uniquement les opérations ACTIVE, dans la fenêtre [startDate, endDate], et visibles pour l’acheteur :
PUBLIC→ tous les accounts du store effectif,PRIVATE→ seulement si l’account (ou le user) est explicitement associé.
Fonctionnement métier :
- Source unique par création
- La commande peut être créée à partir d’une seule source (MVP : OPERATION uniquement).
- Le couple
sourceType+sourceIdest optionnel, mais sisourceIdest renseigné,sourceTypeest requis.
- Modes d’initialisation des lignes
- FULL (isFull = true, défaut quand une source est fournie)
- Ajoute toutes les lignes de l’Opération éligibles & visibles pour l’acheteur (catalogue, offre/prix/variant actifs, fenêtre de dates, éligibilité tarifaire, stock…).
- Quantité par défaut par ligne :
recommendedQuantity> 0 → utilisée,- sinon
minQuantity> 0 → utilisée, - sinon 1,
- puis bornage par
minQuantity/maxQuantitys’ils existent.
- PARTIAL (isFull = false)
- La commande est créée vide mais marquée comme issue de l’Opération.
- Les lignes sont ajoutées ensuite via ORDER-150, avec application des contraintes de l’Opération uniquement pour les variants appartenant à l’Opération (date/visibilité + min/max).
- Les variants hors Opération restent autorisés (règles standards uniquement).
- FULL (isFull = true, défaut quand une source est fournie)
API correspondante :
✅ Créer une commande (support de la source OPERATION)
ORDER-108 - POST /v2/shop/commercial-orders
Champs ajoutés / utilisés :
sourceType∈ OPERATION | QUOTE | ORDER | CART (MVP : OPERATION uniquement)sourceId(externalId de l’Opération)isFull(bool, défaut true si une source est fournie)
Exemples de requêtes :
{
"sourceType": "OPERATION",
"sourceId": "OPE-UK-SUMMER-2025",
"isFull": true,
"customFieldIdType": "EXTERNAL_ID",
"customFields": [
{"customFieldId": "DELIVERY_NOTE", "customFieldValue": "Leave at reception"},
{"customFieldId": "INTERNAL_TAG", "customFieldValue": "VIP"}
]
}{
"sourceType": "OPERATION",
"sourceId": "OPE-UK-SUMMER-2025",
"isFull": false
}{
"id": "ord_0001FZ4Y8CTZ9",
"reference": "FO-2025-000123"
}✏️ Ajouter / modifier des lignes après création (PARTIAL)
ORDER-150 - PUT /v2/shop/commercial-orders/{commercialOrderId}/lines
Comportement spécifique “commande issue d’Opération” (PARTIAL) :
- Pour un variant de l’Opération → application conjointe des règles standard + contraintes Opération (date/visibilité, min/max).
- Pour un variant hors Opération → règles standard uniquement.
Exemples de requêtes :
{
"customFieldIdType": "EXTERNAL_ID",
"lineIdType": "EXTERNAL_ID",
"lineType": "OFFER_PRICE",
"updateOrderCommercialLines": [
{
"id": "offp_ext_123",
"quantity": 6,
"updateAction": "ADD_QUANTITY",
"metadata": { "unit": "2" }
}
]
}{
"lineIdType": "EXTERNAL_ID",
"lineType": "PRODUCT_VARIANT",
"updateOrderCommercialLines": [
{ "id": "VAR-000777", "quantity": 12, "updateAction": "REPLACE_QUANTITY" }
]
}Buying Policies
- Tris sur la liste des blocages de comptes (Credit Hold)
Contexte :
Les opérateurs peuvent désormais trier la liste des blocages de comptes (credit holds) pour analyser plus rapidement les situations (nouveaux blocages, fin proche, derniers modifiés, etc.).
Cette amélioration s’applique à la route existante de listing et vient compléter les filtres introduits précédemment.
Fonctionnement métier :
- Tri par date de création décroissante par défaut → les blocages les plus récents apparaissent en premier.
- Possibilité de combiner plusieurs tris pour affiner l’ordre d’affichage (ex. trier par date de fin puis, à égalité, par compte).
- Cas particuliers gérés pour éviter les surprises d’affichage (ex. dates de fin non renseignées envoyées en dernier).
API correspondante :
🔍 Lister les blocages (triable)
ADM-OPERATION-550 - GET /v1/buying-policies/credit-control/holds
Nouveau paramètre de tri
sort(répétable) — formatfield:direction- Champs autorisés :
createdAt,updatedAt,startDate,endDate,accountId - Directions :
asc|desc - Multi-tris : répéter le paramètre, ex.
?sort=endDate:asc&sort=accountId:asc - Tri par défaut :
createdAt:desc - Comportements spécifiques :
- Pour
endDate, les valeurs null sont toujours renvoyées en dernier, quel que soit le sens. - Règle Djust : tout tri invalide ou mal formé est ignoré silencieusement ; la requête réussit avec les tris valides restants.
- En cas d’égalité, le tri par défaut (
createdAt:desc) est ajouté en tie-breaker.
- Pour
- Champs autorisés :
Exemples d'appels :
Derniers modifiés d’abord :
?sort=updatedAt:desc
Blocages qui finissent bientôt :
?sort=endDate:asc
Puis par compte à égalité :
?sort=endDate:asc&sort=accountId:asc
