Ajout du nom du compte dans le retour API de récupération des blocages de BP d'encours
La réponse de l'API ADM-BUYING-POLICY-550 évolue pour remonter également le nom du compte : accountName. Il permet de mieux identifier les comptes associés aux configurations de blocages des buying policies d'encours.
Le nouvel attribut accountName est également filtrable et triable.
Alimentation en continu de l'encours courant pour chaque compte
Désormais, les buying policies d'encours évoluent pour alimenter en continu l'encours courant de chaque compte. Jusqu'à présent, on se basait uniquement sur les valeurs synchronisées avec un système distant sur chaque compte. C'était source d'erreurs potentielles pour les validations, l'encours n'était recalculé que sur un jour calendaire et non sur une période glissante.
Maintenant, l'encours est systématiquement incrémenté à chaque commande validée pour refléter au plus près la réalité. Il peut être écrasé par une synchronisation quotidienne comme c'était le cas jusqu'à présent.
La plateforme évolue pour adopter une gestion catalogue unifiée au niveau du variant, aussi bien dans les Assortiments que dans les Catalog Views.
Cette évolution améliore la lisibilité, le contrôle et la cohérence de la gestion des catalogues.
🎯 Objectif
Permettre aux opérateurs de :
contrôler précisément quels variants sont visibles dans les catalogues,
comprendre rapidement où un produit ou un variant est utilisé,
gérer les contenus sans doublons ni ambiguïté.
📋 Listes Assortments
La liste des assortiments permet aux operators de visualiser et de gérer efficacement leurs assortiments grâce à des informations enrichies et des outils de recherche avancés.
Chaque assortiment affiche désormais le nombre de produits et le nombre de variants qu’il contient, offrant une meilleure compréhension de sa composition. La liste peut être affinée à l’aide d’une recherche textuelle insensible à la casse sur le nom et l’identifiant externe de l’assortiment, ainsi que de filtres par source, date minimale de création ou de mise à jour, et catégories de navigation personnalisées. Ces fonctionnalités facilitent l’identification rapide des assortiments pertinents et améliorent leur gestion dans l’interface, sans modifier le comportement existant des assortiments.
📋 Listes Produits & Variants
Introduction de deux vues complémentaires dans la page de detail d’un assortiment et restrictions de catalogue:
Vue Produit : vision globale avec indicateur de couverture des variants.
Vue Variant : vision détaillée des variants réellement inclus.
Bascule instantanée entre les vues
Recherche intégrée, adaptée à la vue active.
➕➖ Ajout et retrait (Assortiments & Catalog Views)
Ajout possible :
par produit (tous les variants inclus),
ou par variant (gestion granulaire).
Actions unitaires ou en masse, avec confirmation.
Prévention des doublons : éléments déjà présents grisés.
Retrait possible par produit ou par variant, avec nettoyage automatique.
🧾 Pages de détail produit et variant
Variant
Affiche les :
Assortiments
Catalog Views
Navigation Categories dans lesquels le variant est utilisé.
Recherche disponible dans chaque section.
Produit
Vue consolidée des usages via ses variants :
assortiments
catalog views concernés
🔌 APIs – Détail des évolutions
🆕 Nouveaux endpoints
Catalog Views
GET /v1/catalog-views/{id}/product-variants
Liste paginée des variants inclus dans un Catalog View
Recherche sur les champs variant et produit parent
Tri par défaut : product.name, variant.name
POST /v1/catalog-views/{id}/product-variants
Ajout de variants à un Catalog View
DELETE /v1/catalog-views/{id}/product-variants
Retrait de variants d’un Catalog View
Assortiments
GET /v1/assortments/{id}/variants
Liste paginée des variants d’un assortiment
Filtrage possible par produit
Produit
GET /v1/products/{id}/assortments
Liste des assortiments contenant au moins un variant du produit
GET /v1/products/{id}/catalog-views
Liste des Catalog Views contenant des variants du produit
Variant
GET /v1/product-variants/{id}/assortments
GET /v1/product-variants/{id}/catalog-views
GET /v1/product-variants/{id}/navigation-categories
Tous les endpoints ci-dessus supportent le paramètre search.
🔄 APIs mises à jour
GET /v1/catalog-views/{id}/products
Ajout des champs :
variantsIncludedCount
variantsTotalCount
Introduction d’un nouveau DTO allégé.
GET /v1/assortments/{id}/products
Désormais basé sur l’association assortment ↔︎ variant.
GET /v1/assortments
Enrichissement de la réponse avec les champs :
productCount
productVariantCount
Introduction d’un nouveau DTO dédié afin d’éviter les impacts sur les usages existants.
Ajout de nouveaux paramètres de recherche et de filtrage :
search : recherche insensible à la casse sur :
nom de l’assortiment
external ID de l’assortiment
externalSources : filtrage par source (valeurs documentées dans le Swagger ; toute valeur inconnue retourne simplement aucun résultat)
createMinDate : date minimale de création (borne inférieure uniquement)
updateMinDate : date minimale de dernière mise à jour (borne inférieure uniquement)
navigationIds : récupération des assortiments liés à une ou plusieurs catégories de navigation custom
⚠️ dépréciées :
POST /v1/catalog-views
Dépréciation de la liste des produits au profit de la gestion par variants.
API
👍
UPDATE
Djust Pay Marketplace
Calcul dynamique des commissions et application des splits à la capture CB
Contexte
Djust PAY gère désormais le calcul dynamique des commissions et l’application des splits financiers directement lors de la capture carte bancaire.
Jusqu’à présent, l’autorisation CB était réalisée sans split, et la capture ne permettait pas de refléter précisément les répartitions contractuelles entre la plateforme, la marketplace et le fournisseur.
Cette évolution permet d’appliquer, au moment de la capture, des splits complets et conformes aux accords financiers, tout en conservant un haut niveau de sécurité et de traçabilité.
Fonctionnement métier
Les commissions sont calculées exclusivement côté backend Djust PAY, sans aucune influence possible des clients ou fournisseurs.
Deux sources de vérité sont utilisées :
le taux de commission plateforme (settings tenant),
le taux de commission marketplace fournisseur (matrice marketplace).
Chaque taux est optionnel.
API
Le contrat API de la capture CB ADM-PAY-101 ne change pas, il s'appuie juste automatiquement sur les règles de splits configurées.
Commandes
Nouveau droit de validation des commandes logistiques pour les customer users
Contexte
Il est désormais possible, pour les administrateurs de la plateforme, de donner ou retirer le droit de valider une commande logistique à un customer user, y compris pour ses propres commandes.
Cette évolution répond à des besoins de séparation des rôles et de supervision, notamment lorsque certaines commandes doivent être relues, corrigées ou reprises par un utilisateur tiers (manager, superviseur, back-office interne).
Fonctionnement métier
🆕 Nouveau droit : ORDER_VALIDATE
Un nouveau droit explicite est introduit pour contrôler la capacité d’un utilisateur à sortir une commande de la phase de checkout.
ORDER_VALIDATE = true (cas par défaut)
comportement identique à l’existant :
l’utilisateur peut valider ses propres commandes,
s’il dispose aussi de ORDER_VALIDATE_ON_ALL_ACCOUNT, il peut valider toutes les commandes du compte (les siennes et celles des autres).
ORDER_VALIDATE = false
l’utilisateur ne peut plus valider ses propres commandes,
même s’il dispose de ORDER_VALIDATE_ON_ALL_ACCOUNT, il ne peut valider que les commandes des autres utilisateurs du compte, jamais les siennes.
👉 Ce droit est distinct de ORDER_VALIDATE_ON_ALL_ACCOUNT, qui contrôle uniquement le périmètre des commandes (toutes vs autres), pas l’auto-validation.
Impact sur le workflow de commande
Le contrôle du droit ORDER_VALIDATE est appliqué à toutes les actions permettant de quitter la phase de checkout, notamment :
Validation directe de la commande
PUT /v1/shop/commercial-orders/{orderCommercialId}/created (ORDER-212)
Mise en attente de la commande
PUT /v1/shop/commercial-orders/{orderCommercialId}/hold (ORDER-207)
Initialisation d’un paiement
POST /v1/shop/payments (PAY-101)
Si le droit ORDER_VALIDATE est à false, ces routes retournent désormais : 403 – F-E-030 (Permission denied).
Buying Policies
Ajout du nom du compte dans le retour API de récupération des tolérances de BP d'encours
La réponse de l'API ADM-BUYING-POLICY-551 évolue pour remonter également le nom du compte : accountName. Il permet de mieux identifier les comptes associés aux configurations de tolérance des buying policies d'encours.
Le nouvel attribut accountName est également filtrable et triable.
Consultation de la liste des commissions marketplace
Contexte
Les opérateurs disposent désormais d’une vue globale des commissions marketplace configurées sur la plateforme.
Cette fonctionnalité permet de consulter l’ensemble des règles de commission par fournisseur, afin de comprendre précisément quels taux sont appliqués lors des calculs de split de paiement à la capture.
Elle complète les fonctionnalités existantes de création, mise à jour, activation/désactivation et suppression des commissions marketplace, en apportant une vision transverse et auditable.
Fonctionnement métier
• La liste retourne toutes les lignes de commission marketplace existantes, chacune associée à un fournisseur identifié par son externalId.
La consultation est strictement réservée aux utilisateurs OPERATOR.
Nouveauté API
🔍 Lister les commissions marketplace
ADM-PAY-550 - GET /v1/payments/marketplace-commissions
La réponse expose la liste complète des règles de commission marketplace.
👍
UPDATE
Search
Nouveau paramètre de requête pour le comportement de navigation dans l'API de recherche
Un nouveau paramètre de requête facultatif menuCategory a été ajouté à l'API de recherche.
menuCategory permet de distinguer la navigation par menu de la navigation par facettes.
Lorsque menuCategory est utilisé, les facettes de navigation sont limitées aux navigations liées aux produits renvoyés par la recherche.
Mise à jour API
GET /v2/shop/search
Nouveau paramètre de requête : menuCategory (facultatif)
Il est désormais possible de déposer un document à la commande quelque soit le statut de cette dernière. Jusqu'à présent seuls certains statuts étaient possibles, la limitation a été levée pour correspondre à un plus grand nombre de cas d'usages.
Nouveau rôle pour la gestion du numéro de facture pour le paiement PCard L3
Un nouveau rôle INVOICE_NUMBER associé à un custom field de type TEXT de la commande commerciale a été ajouté à la page de gestion des rôles pour permettre la construction des éléments à envoyer aux systèmes bancaires dans le cadre d'un paiement par Cartes Achats niveau 3.
API
📘
NEW
Global
Déclaration de l’entité légale du tenant
Contexte
Les opérateurs peuvent désormais déclarer et maintenir l’entité légale du tenant (raison sociale et adresse du siège).
Cette information, portée au niveau tenant, constitue une donnée de référence transverse pouvant être utilisée par différents services.
Le premier cas d’usage est le paiement par carte achat niveau 3 (P-Card L3), afin de transmettre au PSP les informations du merchant of record (la plateforme), et non celles du fournisseur marketplace.
Fonctionnement métier
La donnée est globale au tenant (pas de multi-entités légales à ce stade).
Les champs gérés sont :
legalName (raison sociale),
registeredAddress (adresse du siège : adresse, complément, ville, région, code postal, pays).
Nouveautés API
🔍 Consulter l’entité légale du tenant
ADM-SETTINGS-501 - GET /v1/settings/legal-entity
Retourne la raison sociale, l’adresse du siège et la date de dernière mise à jour.
✏️ Créer / mettre à jour l’entité légale du tenant
ADM-SETTINGS-202 - PUT /v1/settings/legal-entity
Opération d’upsert (création ou mise à jour).
Djust Pay Marketplace
Mise à jour du taux de commission marketplace par fournisseur
Contexte
Les opérateurs peuvent désormais mettre à jour le taux de commission marketplace associé à un fournisseur existant.
Cette évolution permet d’ajuster dynamiquement le pourcentage de commission appliqué lors des calculs de split de paiement en capture, sans recréer ni supprimer la règle existante.
Cette fonctionnalité complète le socle de gestion des commissions marketplace.
Fonctionnement métier
La mise à jour concerne exclusivement le taux de commission (commissionRate) :
exprimé en pourcentage,
≥ 0 et < 100,
avec un maximum de 4 décimales, sans arrondi automatique.
La commission est identifiée uniquement par le externalId du fournisseur.
Une seule ligne de commission existe par fournisseur ; l’opération met à jour la règle en place.
Aucun impact rétroactif :
les splits déjà calculés restent inchangés,
seuls les paiements futurs utilisent le nouveau taux.
Nouveauté API
✏️ Mettre à jour une commission marketplace
ADM-PAY-200 - PUT /v1/payments/marketplace-commissions/{supplierId}
{ "commissionRate": 2.5000 }
Data Hub
Dupliquer la configuration d’un job
Ajout d’une nouvelle route API permettant de dupliquer un job existant :
POST /v1/mapper/jobs/{jobId}/duplicate
La duplication copie toute la configuration du job, avec le job inactif et le scheduler réinitialisé et désactivé.
Possibilité de refuser définitivement une commande bloquée par une buying policy
Une commande qui est bloquée par une buying policy d'encours ou de quota peut être désormais refusée définitivement (la validation forcée reste également possible).
API
📘
NEW
PCard L3
Gestion du numéro de facture pour les paiements P-Card Niveau 3
Contexte
Dans le cadre du support des paiements par carte achat Niveau 3 (P-Card L3), Djust PAY intègre désormais une gestion standardisée du numéro de facture lors de la capture.
Certains schémas Level 3 (ex. VGIS, LID) exigent en effet un invoice number obligatoire pour constituer l’addendum transmis aux systèmes de paiement.
Cette évolution introduit un rôle générique invoiceNumber, indépendant du PSP, permettant de résoudre automatiquement le numéro de facture depuis un Custom Field porté par la commande logistique.
Fonctionnement métier
Un Custom Field peut être associé au rôle invoiceNumber (scope ORDER_LOGISTIC, type TEXT).
La valeur :
est optionnelle lors de la création de la commande,
devient obligatoire au moment de la capture pour un paiement P-Card L3.
Impact API & Paiement
Le comportement de la route ADM-PAY-101 est enrichi :
l’erreur fonctionnelle F-E-001 couvre désormais le cas invoice number manquant, lorsque le rôle est configuré.
Aucun nouveau code d’erreur n’est introduit ; la compatibilité API est conservée.
Djust Pay Marketplace
Création d’une commission marketplace par fournisseur
Contexte
Djust PAY permet désormais aux opérateurs de créer une ligne de commission marketplace associée à un fournisseur, afin de définir le taux de commission (%) appliqué lors du calcul des splits de paiement au moment de la capture.
Fonctionnement métier
Une commission marketplace est définie :
pour un fournisseur existant, identifié uniquement par son externalId,
avec un taux exprimé en pourcentage, strictement compris entre 0 (inclus) et 100 (exclu).
Un fournisseur ne peut avoir qu’une seule ligne de commission marketplace : tout doublon est refusé.
Nouveauté API
ADM-PAY-103 - POST /v1/payments/marketplace-commissions
Les opérateurs peuvent désormais supprimer définitivement une ligne de commission marketplace associée à un fournisseur, lorsqu’il n’est plus éligible au modèle de commissionnement (changement contractuel, sortie du catalogue, évolution du schéma de rémunération, etc.).
Cette action garantit que le fournisseur concerné ne sera plus jamais inclus dans aucun calcul de split de paiement, tout en préservant l’historique des transactions déjà réalisées.
Fonctionnement métier
La suppression porte uniquement sur la ligne de commission marketplace (pas sur le fournisseur lui-même) et est définitive.
Activation / désactivation d’une ligne de commission marketplace
Contexte
Les opérateurs peuvent désormais activer ou désactiver une ligne de commission marketplace associée à un fournisseur, sans modifier les paramètres financiers sensibles (taux, historique, fournisseur).
Cette évolution permet de piloter finement l’éligibilité d’un fournisseur au split marketplace, tout en conservant la ligne de commission pour un usage futur.
Fonctionnement métier
La mise à jour porte exclusivement sur le statut de la ligne de commission :
ACTIVE → la commission est appliquée lors des calculs de split,
INACTIVE → la commission est ignorée sans être supprimée.
Nouvelle version /v2 pour la mise à jour des informations de livraison (ORDER-215)
Contexte
L’API historique ORDER-215 (/shipping-information) reposait uniquement sur un business ID Djust de commande commerciale dans le path, ce qui n’est plus aligné avec les standards actuels du checkout v3 basés sur les REFERENCE IDs.
Afin d’unifier les pratiques et de faciliter l’intégration côté front et partenaires, une nouvelle version /v2 de la route est introduite, tandis que la version existante est désormais dépréciée.
Fonctionnement métier
Cette opération permet toujours de mettre à jour les informations de livraison d’une commande commerciale pendant le checkout, son fonctionnement général est inchangé.
Seul le format d’identifiant attendu dans le path évolue.
Nouveauté API
Une nouvelle route est désormais disponible :
ORDER-215 - PUT /v2/shop/commercial-orders/{commercialOrderId}/shipping-information
-> commercialOrderId doit être un REFERENCE ID.
Nouvelle version /v2 pour la validation des commandes commerciales (ORDER-212)
Contexte
L’API historique ORDER-212 (/created) reposait uniquement sur un business ID Djust de commande commerciale dans le path, ce qui n’est plus aligné avec les standards actuels du checkout v3 basés sur les REFERENCE IDs.
Afin d’unifier les pratiques et de faciliter l’intégration côté front et partenaires, une nouvelle version /v2 de la route est introduite, tandis que la version existante est désormais dépréciée.
Fonctionnement métier
Cette opération permet toujours de valider d’une commande commerciale pendant le checkout, son fonctionnement général est inchangé.
Seul le format d’identifiant attendu dans le path évolue.
Nouveauté API
Une nouvelle route est désormais disponible :
ORDER-212 - PUT /v2/shop/commercial-orders/{commercialOrderId}/created
-> commercialOrderId doit être un REFERENCE ID.
Dépôt de documents autorisé quel que soit le statut de la commande logistique
Contexte
Jusqu’à présent, le dépôt de documents sur une commande logistique via l’API d'administration était limité à certains statuts (WAITING_SHIPMENT, SHIPPED, COMPLETED).
Ce comportement bloquait plusieurs cas d’usage métier, notamment le dépôt de documents dès les premières étapes du cycle de vie (ex. bons de commande joints dès le checkout).
Évolution apportée
La contrainte de statut est désormais levée :
• Le dépôt de documents est autorisé quel que soit le statut de la commande logistique.
• Cette évolution s’applique à la route d'administration : POST /v1/documents
Customer users
Mise à jour de l’adresse email d’un Customer User
La route PUT /v1/customer-users/{userId} permet désormais de modifier l’adresse email d’un Customer User
Comportements
Le champ email remplace l’adresse email existante.
Les règles de validation restent inchangées :
L’adresse email doit être unique parmi les Customer Users
Si le champ email est vide ou non renseigné, aucune mise à jour n’est effectuée.
Customer Account
Création de compte sans utilisateur
La route POST /v1/customer-accounts permet désormais de créer un compte client sans créer un utilisateur. Le champ createCustomerUserRequest devient ainsi optionnel.
La route ADM-CUSTOMER-USER-250 permet de rattacher un Customer User à un ou plusieurs Customer Accounts existants.
Global
Lorsqu’on appelle une API avec le mauvais type de client (ex: OPERATOR alors que CUSTOMER est attendu), on a actuellement une erreur 403 avec le détail suivant :
code:"GEN0001", message:"Access forbidden"
Afin de respecter les standards API, le retour sera désormais :
code:"F_E_030", message:"Permission denied. User with this role is not allowed to perform this action on this entity."
Correction d’un dysfonctionnement pouvant affecter l’export des incidents.
Job Order Validation
Evolution technique permettant de gérer les commandes DRAFT dans le mécanisme de BYPASSED
Indexation
Navigation
Evolution du système de cache des navigations pour permettre de gérer l’update technique du job de navigation (DataHub). Cet update technique permets d'améliorer la gestion de notre système de position de navigation.
API – Update
Customer Account – Création de compte sans utilisateur
La route POST /v1/customer-accounts permet désormais de créer un compte client sans créer un utilisateur. Le champ createCustomerUserRequest devient ainsi optionnel.
Gestion des commissions marketplace par fournisseur
Djust PAY introduit une gestion centralisée des commissions marketplace par fournisseur, via une matrice dédiée administrée exclusivement par les opérateurs.
Cette fonctionnalité permet de définir, contrôler et tracer le taux de commission (%) appliqué à chaque fournisseur, utilisé lors du calcul des splits de paiement côté marketplace, tout en garantissant qu’aucun fournisseur ne puisse modifier ou consulter son propre taux.
Consultation de la commission marketplace d’un fournisseur
Contexte
Les opérateurs peuvent désormais consulter la ligne de commission marketplace configurée pour un fournisseur, afin de connaître le taux appliqué lors des calculs de split en capture de paiement.
Cette fonctionnalité apporte de la transparence et facilite le diagnostic des montants reversés dans un contexte marketplace, sans exposer ni modifier de données sensibles.
Nouveauté APIADM-PAY-500 - GET /v1/payments/marketplace-commissions/{supplierId}
s’applique aux variants et aux custom fields présents dans le payload
ne s’applique pas à la master quote, qui ne possède pas encore d’external ID
Le comportement par défaut reste inchangé :
👉 si idType n’est pas fourni, l’API continue d’interpréter les identifiants en DJUST_ID pour garantir la compatibilité existante.
Création d'une commande depuis un devis :
Contexte
Les customer users (ACCOUNT) peuvent désormais créer une commande à partir d’un devis auquel ils ont accès, via la route de checkout v3 ORDER-108 - POST /v2/shop/commercial-orders.
L’objectif est de permettre la conversion directe d’un devis en commande, en reprenant ses lignes et conditions, tout en conservant un contrôle strict sur l’éligibilité du devis et le cycle de vie de la commande.
Fonctionnement métier
Nouvelle source QUOTE supportée dans ORDER-108
La création de commande supporte désormais deux types de source :
OPERATION (déjà existant)
QUOTE (nouveau)
Pour pouvoir être transformé en commande, le devis doit :
être valide (non expiré, non annulé),
être au statut WAITING_FOR_CUSTOMER au moment de l’appel,
appartenir à l’account du caller,
être dans le store effectif (scoping via dj-store ou store par défaut).
Si une de ces conditions n’est pas remplie, la création est refusée.
Contrairement aux opérations, seul le mode FULL est accepté.
La commande créée est au statut initial DRAFT_ORDER_ON_HOLD.
Elle est non éditable : les appels de type ORDER-150, ORDER-213, ORDER-215… sont refusés.
Le paiement via PAY-101 est autorisé ; en cas de succès, la commande passe en CREATED (workflow standard).
Revue des lignes de prix et ajout du prix remisé dans l'affichage des lignes de prix d'une offre :
Le champ quantité min n’est plus bloqué et lié au champ articles par lot.
Dans le cas d’un prix par unité, la notion d'articles par lot n’existe pas.
Dans le cas d’un prix par lot, la valeur d'articles par lot n’est pas égale à la valeur de quantité min
Ajouts des nouveaux rôles pour la gestion du flux cartes achats niveau 3 :
Deux nouveaux rôles distincts sont ajoutés pour le flux cartes achats niveau 3.
Rôle identifiant de marché à l'account :
Le rôle MARKET_ID est associé à un custom field à l'account de type TEXT. Il est disponible dans l'interface de configuration des rôles.
Rôle identifiant d'engagement :
Le rôle ENGAGEMENT_ID est associé à un custom field à la commande commerciale de type TEXT. Il est disponible dans l'interface de configuration des rôles.
API
📘
NEW
Orders
Consultation des informations de paiement d’une commande logistique :
Contexte
Une nouvelle route d’administration permet désormais aux opérateurs et fournisseurs autorisés de consulter les métadonnées de paiement associées à une commande logistique.
L’objectif : offrir un accès rapide et lisible au provider, au mode de paiement et au statut du cycle de paiement, sans jamais exposer d’informations sensibles.
Fonctionnement métier
> Ce que retourne la route
Uniquement 3 champs métier, strictement limités à l’information de paiement :
provider - prestataire utilisé (ex. DJUST_PAY, LEMONWAY, MANGOPAY)
Afin de pouvoir réduire le nombre d’incidents à traiter en front et de faciliter la recherche, un filtre par motif d’incident est ajouté.
Il fonctionne de la même manière que le filtre customerAccountIds, il s'agit d'une liste d'id de reasons passées en query param sur la route ORDER-559 - GET /v1/shop/incidents.
Le param reasonCodes ajouté prendra en entrée une liste d’ID de reasons et fonctionne via un OU logique entre chaque valeur.
Tri des incidents par fournisseur :
Contrairement au filtre par fournisseur, le tri par fournisseur doit s’appliquer sur le nom du fournisseur via la route ORDER-559 - GET /v1/shop/incidents.
Ainsi la possibilité de trier sur les noms des fournisseurs se fait désormais avec le sort suivant :
supplierName:asc ou supplierName:desc qui trient respectivement les incidents par noms de fournisseurs dans l’ordre croissant (A > Z) et décroissant (Z > A).
Buying Policies
Refus / abandon d’une commande logistique en statut BLOCKED_BY_POLICY par un opérateur
Contexte
Historiquement, seule une logique “fournisseur” permettait de refuser une commande logistique, et uniquement lorsqu’elle était en attente de traitement (ORDER_CREATED, WAITING_SUPPLIER_APPROVAL).
Avec l’arrivée des buying policies (encours, quotas), certaines commandes peuvent désormais rester bloquées très tôt dans leur cycle, au statut BLOCKED_BY_POLICY.
Pour permettre un abandon explicite dans ces situations, la route de decline est étendue :
• NEW Les opérateurs peuvent désormais refuser une commande bloquée par une buying policy.
• Les fournisseurs conservent leur comportement historique.
• Les customer users (ACCOUNT) ne peuvent jamais utiliser cette action.
La route API mise à jour :
ADM-ORDER-200 - PUT /v1/logistic-orders/{logisticOrderId}/decline
L'action dans le backoffice sera disponible prochainement
Nouvelle version d'API pour la mise à jour de adresses de facturation - ORDER-213
Contexte :
L’API historique ORDER-213 (/billing-information) n’acceptait qu’un business ID Djust dans son path, ce qui ne correspond plus au standard actuel des routes Checkout v3 basées sur les REFERENCE IDs.
Pour corriger cela, une nouvelle version /v2 de la route est introduite, tandis que la version existante est désormais dépréciée.
Fonctionnement :
• Aucun changement fonctionnel : seul le type d’ID attendu dans le path évolue.
Nouveauté API :
ORDER-213 - PUT /v2/shop/commercial-orders/{commercialOrderId}/billing-information
• commercialOrderId doit être un REFERENCE ID, conformément au comportement des routes du checkout order v3.
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.
