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.

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é.

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 ACTIVE et 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é.
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 + sourceId est optionnel, mais si sourceId est renseigné, sourceType est 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 :
    1. recommendedQuantity > 0 → utilisée,
    2. sinon minQuantity > 0 → utilisée,
    3. sinon 1,
  - puis bornage par minQuantity / maxQuantity s’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).

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) — format field: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.

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