Périmètre

🚀 Gestion catalogue centrée sur le variant

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.