Ajout du support de la devise coréenne South Korean Won (KRW) :
La dernière version 3.60.0 apportait la prise en charge de la devise coréenne KRW dans l'ensemble des API front et d'administration. Elle est désormais disponible dans les devises du BackOffice Djust sur l'ensemble de ses pages (Taux de change, Offres...)
API
📘
NEW
Buying Lists
Ajout de la pagination sur la route de récupération de listes d'achats :
Afin de répondre à une problématique de design historique de l’API BUYLIST-500 qui n’a pas de pagination, la route BUYLIST-501 a été ajoutée.
⚠️
Attention
Cette route reste une route temporaire qui sera dépréciée afin de forcer les utilisateurs à migrer vers les routes Cart v2 pour utiliser pleinement le potentiel des listes d’achats.
La route BUYLIST-501 reprend le format strictement identique à la route BUYLIST-500 tout en y ajoutant le support de la pagination.
BUYLIST-501 - GET /v2/shop/buying-lists
👍
UPDATE
Suppliers
Ajout de la gestion des id externes sur les routes d'administration supplier :
Les routes d'administration suivantes sont maintenant accessibles via les id externes de fournisseur :
GET /public/v1/suppliers/{supplierId}
PATCH /v1/suppliers
PUT /v1/suppliers/{supplierId}
POST /v1/suppliers/{supplierId}/supplier-user
GET /v1/suppliers/{supplierId}/supplier-users
PUT /v1/suppliers/{supplierId}/customer-accounts
GET /v1/suppliers/{supplierId}/customer-accounts
Le paramètre de requête supplémentaire idType est ajouté afin de pouvoir utiliser ces routes soit par l’id Djust soit par id externe.
idType peut prendre deux valeurs : DJUST_ID ou EXTERNAL_ID
Par défaut, l’idType est à DJUST_ID.
Product Variants
La route d'administration permettant la récupération des variants de produits est complétée avec l'ajout des nouveaux paramètres de requêtes suivants :
New request parameter
Mandatory
Description
brand
No
Récupération des variants par marque
locale
No
Récupération des variants en fonction de la locale
productIds
No
Récupération des variants par id produit parent
variantIds
No
Récupération des variants par id
Le paramètre de requête productSku est devenu optionnel.
Search
Ajout des unités de produit dans le retour des API de search :
Afin de compléter le retour d’API de la page liste produit et de l’autocomplete, l’information d’unité de produit a été rajoutée dans les routes suivantes :
Cette information permet notamment l'affichage de l'unité de vente d'un produit, exemple au litre, à la palette...
PRODUCT-552 - GET /v2/shop/search
PRODUCT-553 - GET /v2/shop/autocomplete
Le déclenchement de la capture manuelle est désormais possible dans les conditions suivants :
L'environnement concerné doit avoir le feature flag MANUAL_CAPTURE_AUTHORIZED à true (pour en bénéficier, il faut se rapprocher de votre CSM).
La commande doit être au statut de paiement AUTHORIZED.
Le moyen de paiement doit être CREDIT_CARD.
La possibilité de capturer les paiements se fait depuis le bouton d’action Capture payment disponible sur la page détail d’une commande :
API
📘
NEW
PAY
Gestion des cartes de paiement enregistrées :
La sauvegarde des cartes bancaires est possible sans surcoût avec Djust Pay.
On peut donc choisir de laisser l’utilisateur sauvegarder ses informations bancaires, pour du paiement récurrents par exemple.
Afin de gérer correctement ces sauvegardes d’informations bancaires (appelées également token de cartes), on aura recourt à un nouveau feature flag : ENABLE_CREDIT_CARD_STORAGE
Affichage des moyens de paiement enregistrés :
La route PAY-501 de récupération des moyens de paiement éligibles permet de manière transparente sans adaptation la remontée de ces cartes enregistrées.
Proposition de sauvegarde de cartes bancaires en front :
Une case à cocher est proposée dans le composant front de paiement pour donner la possibilité à l’utilisateur de sauvegarder ou non ses informations bancaires pour un usage futur.
Cette case à cocher s’affiche si le feature flag ENABLE_CREDIT_CARD_STORAGE est activé. (Vous pouvez vous rapprocher de votre CSM pour activation).
La valeur de ce feature flag est transmise au front client via l’attribut enableCreditCardStorage de la réponse de l’API PAY-501.
Sauvegarde des cartes à enregistrer :
Pour prendre en compte la sauvegarde d’une carte de paiement, l’API PAY-101 évolue pour signifier que la carte utilisée pour le paiement doit également être tokenisée.
Ainsi les 2 paramètres suivants sont ajoutés en paramètre de requête :
Paramètre de requête
Obligatoire
Type
Description
storePaymentMethod
Non
boolean
Default value : false
Choix de l’utilisateur de sauvegarder ou non son moyen de paiement.
referenceType
Non
string
Default value : COMMERCIAL
Précise le type d’order manipulée : LOGISTIC ou COMMERCIAL
Suppression des moyens de paiement enregistrés :
Il est possible pour un utilisateur de gérer lui-même ses moyens des paiement déjà enregistrés et de les supprimer. Pour y arriver, la route PAY-300 a été ajoutée :
La suppression se fait sur l’id du moyen de paiement enregistré storedPaymentMethodId sans autre paramètre particulier.
Déclenchement de capture CB par un opérateur :
Dans le cadre de l’utilisation de Djust Pay, un opérateur a la possibilité de demander une capture sur une transaction CB autorisée (Voir paragraphe Intégration de la capture manuelle : de cette release note).
Il utilise alors l’API d’administration ADM-PAY-101 - POST /v1/payments/captures.
Cette API permet le déclenchement multiple de captures sur un ensemble de commandes logistiques passées dans le body :
Il est important de noter que le status de la réponse n’est pas le statut réel de la capture mais bien la demande qui a été effectuée. Les demandes en succès positionnent les commandes logistiques correspondantes en CAPTURE_PENDING. Un traitement asynchrone positionnera de manière définitive le statut de paiement en REFUSED ou en PAID si la demande de capture est refusée ou en succès.
👍
UPDATE
Permissions
Gestion des rôles d'un user group :
Afin de simplifier la récupération des rôles d’un user-group, le retour du endpoint d'administration GET /v2/user-groups/{userGroupId}/roles a été modifié.
Il renvoie désormais l’ensemble des rôles du client avec un attribut enabled pour indiquer ceux activés pour le groupe.
Un query param OnlyEnabled a été ajouté pour ne récupérer que les rôles actifs
Devises
Ajout du support de la devise South Korean Won (KRW)
Le support de la devise sud coréenne KRW a été ajouté dans les devises disponibles.
Les routes d'administration suivantes la prennent désormais en compte :
GET /v1/currency-exchange-rates
POST /v1/currency-exchange-rates
GET /v1/logistic-orders
POST /v1/logistic-orders
GET /v1/logistic-orders/{orderLogisticId}
GET /v1/logistic-orders/{orderLogisticId}/approvals
GET /v1/logistic-orders/{orderLogisticId}/lines
PATCH /v1/logistic-orders/{orderLogisticId}/lines/{orderLogisticLineId}
PUT /v1/logistic-orders/{orderLogisticId}/lines/{orderLogisticLineId}
GET /v1/offer-inventories
PATCH /v1/offer-inventories
POST /v1/offer-inventories
GET /v1/offer-inventories/{offerInventoryId}
PUT /v1/offer-inventories/{offerInventoryId}
GET /v1/supplier-quotes/{supplierQuoteId}/orders
GET /v1/transactions/unreconciled
Les routes frontend suivantes la prennent également en compte :
BUYLIST-500 - GET /v1/shop/buying-lists
BUYLIST-100 - POST /v1/shop/buying-lists
BUYLIST-550 - GET /v1/shop/buying-lists/{buyingListId}
BUYLIST-200 - PUT /v1/shop/buying-lists/{buyingListId}
BUYLIST-110 - PUT /v1/shop/buying-lists/{buyingListId}/items
CART-500 - GET /v1/shop/carts
CART-100 - POST /v1/shop/carts
CART-201 - PUT /v1/shop/carts/{cartId}
CART-200 - PUT /v1/shop/carts/{cartId}/lines
ORDER-560 - GET /v1/shop/commercial-orders
ORDER-100 - POST /v1/shop/commercial-orders
ORDER-561 - GET /v1/shop/commercial-orders/{commercialOrderId}/lines
ORDER-500 - GET /v1/shop/commercial-orders/{orderCommercialId}
ACCOUNT-550 - GET /v1/shop/customer-accounts/orders
ACCOUNT-555 - GET /v1/shop/customer-accounts/organisations/{organisationId}/orders
PRODUCT-550 - GET /v1/shop/list
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-555 - GET /v1/shop/logistic-orders/{orderLogisticId}/lines
ORDER-206 - PATCH /v1/shop/logistic-orders/{orderLogisticId}/lines/{orderLogisticLineId}
OFFER-550 - GET /v1/shop/offer-inventories
PRODUCT-508 - GET /v1/shop/product-variants/{productVariantId}/offers
PRODUCT-502 - GET /v1/shop/products/{productIdentifier}/offers
PRODUCT-509 - GET /v1/shop/products/{productIdentifier}/paginated-offers
PRODUCT-503 - GET /v1/shop/products/{productIdentifier}/related-products
PRODUCT-553 - GET /v2/shop/autocomplete
PRODUCT-552 - GET /v2/shop/search
ORDER-107 - POST /v2/shop/supplier-quotes/{supplierQuoteId}/initialize-orders
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 Types de documents : Settings > Document Types.
Page de gestion des Utilisateurs du backoffice : Settings > Internal Users.
Page de gestion des Attributs produits : Settings > Product Attributes.
API
👍
UPDATE
Orders
Filtrage des commandes à l'utilisateur connecté :
Afin de pouvoir récupérer l’ensemble des commandes d’un customer user sur tous ses comptes (via customerAccountIds) un nouveau filtre est ajouté sur la route de récupération de commandes ORDER-550.
Ainsi, la route ORDER-550 - POST /v1/shop/logistic-orders (et la route historique dépréciée GET /v1/shop/logistic-orders) évoluera comme ceci avec l’ajout de l’attribut suivant :
connectedUserOnly : booléen optionnel pour préciser si oui ou non la réponse doit être filtrée sur le customer user connecté.
Si le param connectedUserOnly est à true, alors les commandes remontées seront celles du customer user de l’ensemble des accounts précisés dans la liste d’ids customerAccountIds.
Récupération des commandes commerciales par référence :
La route de récupération de commandes commerciales fonctionne avec l’attribut idType servant à distinguer si l'id est de type business_id ou cart_id.
L’id de base pour une commande est la référence. Ainsi, la valeur REFERENCE a été ajoutée à la liste des valeurs possibles d’idType sur la route ORDER-500 - GET /v1/shop/commercial-orders/{orderCommercialId} afin de pouvoir récupérer une commande depuis une référence.
Jobs
Data Hub - Paramètre cronExpression désormais optionnel
Jusqu’à présent, le paramètre cronExpression était requis dans le payload de création ou de mise à jour d’un job, via les endpoints :
POST /v2/mapper/job
PUT /v1/mapper/job/{jobId}
Cela impliquait qu’un job devait toujours être déclenché selon une planification.
Dans certains cas d’usage, il est nécessaire de créer un job sans planification automatique, qui ne sera déclenché que manuellement (via un appel explicite à l’exécution du job).
Nouveauté
Le champ cronExpression devient optionnel dans ces endpoints
Comportement attendu
Présence du cronExpression
Comportement du job
cronExpression renseigné
Le job est déclenché automatiquement selon la planification définie dans le scheduler
cronExpression omis ou null
Le job n’est pas planifié : il peut uniquement être déclenché manuellement
Exemples
Avec cronExpression (job planifié automatiquement)
Data Hub - Amélioration de la route GET /v2/mapper/job/generic-job-types?flux=import
Cette route permet d’obtenir la liste des types de jobs disponibles pour un flux d’import ou d’export, des connexions client disponibles (FTP, Connecteur API ou Mirakl) et des formats de fichiers acceptés (JSON, CSV, XML). Elle a été enrichie afin de mieux refléter les différentes configurations possibles.
Ce qui change
Ancien champ
Remplacé par / Déplacé vers
acceptedClients
Inclus dans availableConfigurations[].clientType
acceptedFormats
Inclus dans availableConfigurations[].acceptedFormats
(nouveau) flux
Indique le sens du flux : IMPORT ou EXPORT
(nouveau) trigger
Décrit le type de déclenchement du job : SCHEDULED ou EVENT
Améliorations graphiques et optimisations de design
Dans la continuité de la refonte globale du Back Office de Djust, un redesign de la page des product tags a été revu afin de simplifier l'expérience utilisateur.
Cette page est accessible via l’interface de Settings > Product Tags.
API
📘
NEW
Djust PAY
Ajout de la prise en charge du 3DS dans les paiements CB :
Le contrat de la route d'initialisation de paiement évolue pour prendre en compte des éléments supplémentaires nécessaires au bon fonctionnement de transaction 3DS.
La route concernée par ce nouveau workflow est :
PAY-101 - POST /v1/shop/payments
Query parameter
Required
Type
Description
customerUserIP
✅
string
Adresse IP du customer user connecté qui passe la commande.
browserInfo
✅
object
L’objet browserInfo contient l’ensemble des éléments issus du browser du client. Il provient de l’élément state.data.browserInfo du widget de Drop-In.
Une fois le retour effectué du parcours 3DS, il est nécessaire de vérifier les informations liées à la transaction afin de terminer le workflow de paiement. Pour obtenir ces informations, une nouvelle route a été ajoutée :
PAY-102 - POST /v1/shop/payments/details
Il n'existe qu'un seul paramètre à envoyer dans le body :
Query parameter
Required
Type
Description
details
✅
string
Résultat de l’authentification encodée en base64
La réponse du POST est la suivante, elle est similaire au /payments hors 3DS :
Ajout de la gestion des mentions légales d'exonération de taxes :
L’ensemble des APIs de gestion de commande évolue avec l’ajout de l’attribut taxLegalNotice à la ligne de commande.
L’utilisation de ce champ reflète la nécessité d’apposer une mention légale d’exonération de TVA dans le cas où celle-ci ne doit pas être payée par l’acheteur au vendeur, la facture s’effectuant ainsi hors-taxe.
Le cas le plus courant est celui d’une livraison intracommunautaire.
Le nouveau champ taxLegalNotice est ajouté dans l’objet taxInformation déjà existant au niveau des prix de chaque ligne.
Afin de respecter une contrainte de décomissionnement d’Octobat chez Mirakl, il sera possible d’alimenter cet attribut depuis le front office via les APIs de Cart v1 uniquement. En effet, le Cart v2 et les nouvelles routes de gestion des commandes sans panier passeront à terme par un traitement back pour alimenter ces informations.
En conséquence, les routes de modifications de panier suivantes sont impactées :
CART-200 - PUT /v1/shop/carts/{cartId}/lines
L’attribut taxLegalNotice est ajouté à l’objet tax du body.
CART-500 - GET /v1/shop/carts
POST /v1/shop/carts
PUT /v1/shop/carts/{cartId}
PUT /v1/shop/carts/{cartId}/lines
L’attribut taxLegalNotice est ajouté à l’objet tax de la réponse.
Les routes d'orders sont également touchées avec l'ajout de l'attribut taxLegalNotice dans le snapshot des offer prices des lignes de commandes :
GET /v1/logistic-orders
POST /v1/logistic-orders
GET /v1/logistic-orders/{orderLogisticId}
GET /v1/logistic-orders/{orderLogisticId}/approvals
GET /v1/logistic-orders/{orderLogisticId}/lines
PATCH /v1/logistic-orders/{orderLogisticId}/lines/{orderLogisticLineId}
PUT /v1/logistic-orders/{orderLogisticId}/lines/{orderLogisticLineId}
ORDER-560 - GET /v1/shop/commercial-orders
ORDER-100 - POST /v1/shop/commercial-orders
ORDER-561 - GET /v1/shop/commercial-orders/{commercialOrderId}/lines
ORDER-500 - GET /v1/shop/commercial-orders/{orderCommercialId}
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-555 - GET /v1/shop/logistic-orders/{orderLogisticId}/lines
ORDER-206 - PATCH /v1/shop/logistic-orders/{orderLogisticId}/lines/{orderLogisticLineId}
ORDER-107 - POST /v2/shop/supplier-quotes/{supplierQuoteId}/initialize-orders
L’attribut taxLegalNotice est facultatif et n’est pas soumis à une vérification de format. Le front est responsable de la donnée injectée.
Ouverture de la modification des quantités de lignes :
Un nouveau droit est ajouté pour pouvoir modifier les quantités des lignes de commande en tant qu’utilisateur non propriétaire.
Le nom du droit sera : ORDER_UPDATE_LINES_ON_ALL_ACCOUNT. Il s’applique sur les commandes au statut DRAFT_ORDER ou DRAFT_ORDER_ON_HOLD.
Ainsi, la route d’update globale suivante est ouverte à modification si l’utilisateur qui en fait la demande possède ce droit :
ORDER-250 - PUT /v1/shop/logistic-orders/{orderLogisticId}/lines
Modification des commandes groupées par un utilisateur différent de celui qui a créé la commande :
Afin de pouvoir modifier les CF des commandes d’autres utilisateurs en tant que customer user, un nouveau droit a été créé et est déjà en place sur ORDER-205 : ORDER_UPDATE_CF_ON_ALL_ACCOUNT
Ce droit doit s’appliquer désormais à l’ensemble des commandes de l’account du customer user au statut DRAFT_ORDER_ON_HOLD et permet la modification des custom fields des commandes sur la route ORDER-250.
⚠️
Attention
Le droit ORDER_UPDATE_CF_ON_ALL_ACCOUNT permet la modification de CF de toutes les commandes de TOUS les accounts auxquels le customer user est rattaché.
Suppliers
La possibilité de filtrer l’api SUPPLIER-550 - GET /v1/shop/suppliers avec les externals IDs des CFs au supplier a été ajoutée.
⚠️
Attention
Les customs fields supportés sont les suivants :
Text
Long text
Boolean
List
Search
La route d'administration pour la récupération des informations des jobs d'indexation a été enrichie :
GET /v1/jobs
Cette modification permet de connaitre le statut de l’indexation mais aussi la date de début et de fin d’une indexation. Il sera aussi possible de connaitre la durée de cette indexation.
Le statut de l'indexation est disponible dans l'attribut jobStatus. Les valeurs possibles sont :
SUCCESS
🆕 IN_PROGRESS
FAILED
La durée de l'indexation se trouve quant à elle dans l'attribut durationInMillis et contient donc la durée de l'indexation en millisecondes.
Améliorations graphiques et optimisations de design
Dans la continuité de la refonte globale du Back Office de Djust, un redesign de la page des customers tags a été revu afin de simplifier l'expérience utilisateur.
Cette page est accessible via l’interface de Settings > Customer Tag Management.
API
📘
NEW
Djust PAY
Onboarding KYC/KYB
Afin de garantir la conformité réglementaire et faciliter la gestion des paiements, une nouvelle route d’administration d’onboarding pour les utilisateurs de Djust Pay a été créée :
ADM-PAY-100 - POST /v1/legal/onboarding-links
Le body contient les éléments pour assurer la redirection vers le parcours d’onboarding géré par notre partenaire Adyen :
Le retour de l’API donne en résultat le lien généré par Adyen afin que le Backoffice Djust fasse la redirection nécessaire.
⚠️
Attention
Cette route n’est pas utilisable en dehors du Backoffice Djust.
Initialisation du widget de paiement front
Un nouveau widget front de paiement va être prochainement intégrable pour les clients sous contrat Djust PAY.
L’initialisation de ce widget commence par la récupération des moyens de paiement éligibles. L’API suivante permet cette récupération dans un contexte donné :
PAY-501 - GET /v1/shop/payments/payment-methods
Les attributs d’entrée sont :
Query parameter
Required
Type
Description
countryCode
string
Code pays sur deux lettres
locale
string
La combinaison d'un code de langue et d'un code de pays pour spécifier la langue à utiliser dans le paiement
reference
✅
string
Référence de la commande
La réponse renvoie la liste des moyens de paiement utilisables pour le contexte d’entrée donné qui est à transmettre au widget front :
Paiement CB (avec paramètres nécessaires à la gestion du 3DS) :
Le paiement CB est initié lorsqu’une demande d’autorisation est faite. Le client renseigne ses informations de CB et une demande est faite à sa banque émettrice pour savoir si les fonds sont disponibles ou non. La demande est faite via l’API suivante :
PAY-101 - POST /v1/shop/payments
Le body contient les paramètres suivants :
Query parameter
Required
Type
Description
reference
✅
string
Référence de la commande
paymentMethodData
✅
object
L’objet paymentMethod a terme aura d’autres attributs. Chacun des attributs est potentiellement propre à un moyen de paiement donné.
returnUrl
✅
string
URL de retour post paiement (OK ou KO)
customerUserIP
✅
string
Adresse IP du customer user connecté qui passe la commande.
browserInfo
✅
object
L’objet browserInfo contient l’ensemble des éléments issus du browser du client. Il provient de l’élément state.data.browserInfo du widget de Drop-In de paiement.
La réponse contient les éléments nécessaires au traitement de l’autorisation et de l'éventuel challenge 3DS qui suit :
La gestion complète du 3DS est en cours et sera livrée dans la release suivante.
👍
UPDATE
Djust PAY
Nouveau statut de paiement possible à l'initialisation :
Un nouveau statut de paiement est ajouté lorsqu’une commande est créé. Par défaut le statut de départ sera mis en INIT_PAYMENT.
⚠️
Attention
Seuls les utilisateurs de Djust PAY sont pour le moment touchés par ces changements.
Les routes concernées par ce nouveau statut sont :
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/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/{orderCommercialId}
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
Nouveau provider de paiement pour la création de commande cart v1 :
Les routes suivantes évoluent avec l'ajout d'une nouvelle valeur possible dans la liste des fournisseurs de paiement : DJUSTPAY.
ORDER-100 - POST /v1/shop/commercial-orders
ORDER-212 - PUT /v1/shop/commercial-orders/{orderCommercialId}/created
ORDER-507 - GET /v1/shop/commercial-orders/{orderCommercialId}/payment-page
ORDER-105 - POST /v1/shop/commercial-orders/{orderCommercialId}/preauthorization
ORDER-104 - POST /v1/shop/commercial-orders/{orderCommercialId}/card-registration
Search
La route PRODUCT-552 - GET /v2/shop/search évolue pour autoriser la remontée des produits sans offres dans les résultats du search.
Le champ currency est également rendue facultatif.
Stores
Il est maintenant possible d'ajouter des customs fields au store.
Pour cela, on peut utiliser les apis d'administration suivantes pour configurer les custom fields aux stores :
GET /v1/custom-fields
POST /v1/custom-fields
⚠️
Attention
L’interface de configuration dans le back-office Djust n’est pas encore disponible
Les routes suivantes d'administration permettent d'ajouter, d'éditer ou supprimer des valeurs de custom fields aux stores :
GET /v1/stores
POST /v1/stores
PUT /v1/stores/{storeExternalId}
GET /v1/stores/{storeId}
La route front suivante permet aussi de récupérer les valeurs configurées ainsi que tout le contenu d'un store dédié :
Il est désormais possible d’associer une même adresse pour plusieurs Accounts depuis le job d’import d’Account. Si une adresse existe déjà et est associée à un autre account, celle-ci ne sera plus rejetée.
API
👍
UPDATE
Offers
La création d'une offre (stock) par API via la route POST /v1/offer-inventoriespermet désormais de préciser les minimum et maximum commandables pour une commande.
Les nouveaux attributs sont minOrderQuantity et maxOrderQuantity.
💡
Usages
minOrderQuantity ne peut être < 0.
maxOrderQuantity doit être >= minOrderQuantity et >= 0. Cet attribut est nullable.
Orders
La route de mise à jour des lignes de commandes commerciales ORDER-150 est complétée avec les deux propriétés optionnelles suivantes :
lineType : les valeurs possibles sont OFFER_PRICE et PRODUCT_VARIANT. La valeur par défaut est OFFER_PRICE.
lineIdType : les valeurs possibles sont EXTERNAL_ID et DJUST_ID. La valeur par défaut est EXTERNAL_ID.
Ces attributs supplémentaires permettent de cible quels éléments sont ajoutés à la commande, des offres (stock) ou des variants ainsi que le type d'ID qui y font référence.
❗️
DELETE
Orders
La route d'administration GET /v1/logistic-orders/{orderLogisticId}/shipments est supprimée. Il s'agit d'une route historique dont le périmètre fonctionnel n'est plus d'actualité.
Ajout de l’éligibilité aux devis des offres dans le connecteur Mirakl
Lors de l’importation des offres Mirakl, le connecteur récupère désormais la valeur du champ allow_quote_requests, indiquant si une offre est éligible à une demande de devis.
Cette valeur est à mapper sur un Custom Field d’Offre de type boolean à créer sur DJUST.
Grâce à ce champ, vous pourrez proposer un devis sur votre Store Front seulement pour les offres éligibles.
Transcoding API
Avec la nouvelle API de transcoding vous pouvez convertir automatiquement des valeurs d’entrée vers une nouvelle valeur de sortie.
Cette fonctionnalité est configurable au niveau des jobs d’import et pour chaque mapping.
Nouveaux endpoints API
L’API offre les opérations suivantes :
Méthode
Endpoint
Action
POST
/v1/mapper/job/{jobId}/transcodings
Créer une nouvelle conversion de valeur pour un job d’import
GET
/v1/mapper/job/{jobId}/transcodings
Lister toutes les conversions de valeurs pour un job d’import
Mettre à jour une conversion de valeur d’un job d’import
Paramètres de l’API
Paramètres
Type
Définition
id
string
Identifiant unique du transcoding
jobId
string
Identifiant du job d’import pour lequel s’applique la conversion
mappingTo
string
Nom de la colonne du mapping du job
inputValue
string
Valeur d’entrée à convertir
outputValue
string
Valeur de sortie après conversion
active
boolean
Indique si la conversion est activée (true) ou désactivée (false)
Règles de conversion
Application automatique : Si une conversion est active pour un mapping, outputValue remplace automatiquement inputValue.
Multiples entrées pour une sortie : Un outputValue peut être associé à plusieurs inputValue.
Unicité de la sortie : Un inputValue ne peut être associé qu’à un seul outputValue.
Validation des valeurs :
Un inputValue peut être une chaîne vide (""), mais pas null.
outputValue doit être non vide et non null.
Les valeurs d’entrée doivent être de type string.
Exclusion : Les Custom Fields ne sont pas concernés par la conversion.
Back-Office
Améliorations graphiques et optimisations de design
Les pages de configuration des Custom Fields bénéficient d'un nouveau bandeau de page pour gagner en clarté et lisibilité. Les filtres et listes ont été également revus afin de faciliter l'expérience utilisateur.
Page Account
Cette version apporte la possibilité de modifier un compte client qui se trouve en statut WAITING_APPROBATION. Jusqu'à présent ce statut interdisait toute modification, c'est désormais possible.
API
📘
NEW
Customer Accounts
Il est maintenant possible de récupérer la liste de tous les accounts et leurs customs fields à partir d'un utilisateur connecté.
La route historique ACCOUNT-501 n'est plus adaptée dans un contexte d'utilisation multi comptes, elle ne retourne en effet qu'un seul account. La nouvelle route ACCOUNT-506 retourne désormais les mêmes éléments sous forme de liste comprenant tous les accounts auxquels est rattaché l'utilisateur :
ACCOUNT-506 - GET /v2/shop/customer-accounts
👍
UPDATE
Search/Autocomplete
Paramètre currency optionnel :
Afin de pouvoir permettre la recherche d'offres sans prix pour les configurations qui l'autorisent, le paramètre de requête currency n'est plus obligatoire. Il reste cependant vivement conseillé pour les environnements qui possèdent différentes devises ou qui n'acceptent pas les offres sans prix.
Ainsi les deux routes suivantes bénéficient de l'évolution :
PRODUCT-553 - GET /v2/shop/autocomplete
PRODUCT-552 - GET /v2/shop/search
Identification des catégories de navigation :
Les catégories de navigation liées aux produits remontent désormais dans les routes de search et d'autocomplete.
La réponse est complétée comme suit au niveau du contenu de chaque products :
Les deux routes suivantes bénéficient de l'évolution :
PRODUCT-553 - GET /v2/shop/autocomplete
PRODUCT-552 - GET /v2/shop/search
Global
Nouveau rôle ENABLE_QUOTE_REQUESTS :
Toutes les apis manipulant des Custom Fields sont agrémentées d'une nouvelle valeur de rôle en lien avec l'évolution du Data Hub sur les imports d'offres Mirakl et de la valeur de l'attribut allow_quote_requests. (Voir section Ajout de l’éligibilité aux devis des offres dans le connecteur Mirakl ci-dessus).
La nouvelle valeur role est ENABLE_QUOTE_REQUESTS.
Cette valeur est également disponible en propriété de requête sur les routes d'administration :
PUT /v1/custom-field-roles
POST /v1/custom-fields
⚠️
Attention
Il n'est pas encore possible de configurer via le BackOffice Djust ce rôle ni de bénéficier du comportement cible au moment de l'ajout à un devis (hors traitement pur frontend) ou du passage de commande.
Custom Fields aux Stores :
Une évolution prochaine (3.57.0) apportera la possibilité de bénéficier de Custom Fields sur les entités Stores. En prévision de cette évolution, la liste de valeurs possibles sealedTarget des Custom Fields se voit complétée de la valeur STORE.
Ainsi les routes d'administration suivantes vont être impactées :
GET /v1/custom-fields
DELETE /v1/custom-fields/{id}
PATCH /v1/custom-fields/{id}
PUT /v1/custom-fields/{id}
GET /v1/custom-fields/{id}/media
POST /v1/custom-fields/{id}/media
Les routes utilisables en front touchées sont :
GET /v1/shop/custom-fields
GET /v1/shop/custom-fields/{id}/media
POST /v1/shop/custom-fields/{id}/media
⚠️
Attention
Il n'est pour le moment pas possible d'utiliser les Custom Fields aux Stores, la feature devrait être rendue disponible en 3.57.0.
Ajout des informations de paiement dans l'export XML des commandes
Une nouvelle section a été ajoutée dans l'export XML des commandes pour inclure les paiements. Désormais, chaque fichier XML contiendra une balise <payments> qui liste les transactions effectuées.
Détails techniques :
Ajout d'une balise <payments> au sein de l'élément <Order>.
À l'intérieur de <payments>, ajout d'une ou plusieurs balises <payment>, correspondant aux transactions liées à la commande.
Chaque balise <payment> contient :
<amount> : Montant du paiement effectué.
<transactionId> : Identifiant de la transaction associée.
Améliorations graphiques et optimisations de design
Les pages suivantes bénéficient d'un nouveau bandeau de page pour gagner en clarté et lisibilité. Des éléments mineurs des pages ont également été changés afin de gagner en homogénéité visuelle globale.
Settings > Manage Internal Users
Offers
La version 3.53.0 permettait l'affichage de l'external Id dans la page de détail d'une offre (stock) quelque soit sa source. Il est maintenant également possible de l'ajouter directement à la création d'une offre :
API
📘
NEW
Buying Policies
La possibilité de modifier les acheteurs d'une buying policy est ouverte grâce à la nouvelle route d'administration suivante :
PUT /v1/buying-policies/{id}/buyers
La liste des acheteurs est alors transmises dans le body :
{
"buyerIds" : ["0000002771", "0000004197"]
}
⚠️
Attention
Le mode par défaut est du REPLACE, c’est à dire que si l’on envoie un seul acheteur et qu’il en existait 3, ils seront remplacés intégralement par le nouvel acheteur donné.
👍
UPDATE
External Orders
Dans le cadre de la mise en place des commandes externes (sources autres que Djust), la nouvelle valeur EXTERNAL_ORDER a été ajoutée à l'attribut orderOrigin.
Les routes suivantes sont concernées :
GET /v1/logistic-orders
POST /v1/logistic-orders
GET /v1/logistic-orders/{orderLogisticId}
GET /v1/logistic-orders/{orderLogisticId}/approvals
GET /v1/logistic-orders/{orderLogisticId}/shipments
GET /v1/supplier-quotes/{supplierQuoteId}/orders
GET /v1/shop/commercial-orders
POST /v1/shop/commercial-orders
GET /v1/shop/commercial-orders/{orderCommercialId}
GET /v1/shop/customer-accounts/orders
GET /v1/shop/customer-accounts/organisations/{organisationId}/orders
GET /v1/shop/logistic-orders
POST /v1/shop/logistic-orders
POST /v1/shop/logistic-orders/{logisticOrderId}/incidents
GET /v1/shop/logistic-orders/{orderLogisticId}
PATCH /v1/shop/logistic-orders/{orderLogisticId}
PUT /v1/shop/logistic-orders/{orderLogisticId}/approve
GET /v1/shop/logistic-orders/{orderLogisticId}/approvers
PUT /v1/shop/logistic-orders/{orderLogisticId}/cancel
PUT /v1/shop/logistic-orders/{orderLogisticId}/confirm-reception
PUT /v1/shop/logistic-orders/{orderLogisticId}/disapprove
POST /v2/shop/supplier-quotes/{supplierQuoteId}/initialize-orders
Améliorations graphiques et optimisations de design
Les pages suivantes bénéficient d'un nouveau bandeau de page pour gagner en clarté et lisibilité. Des éléments mineurs des pages ont également été changés afin de gagner en homogénéité visuelle globale.
Settings > Product Units
Settings > Mirakl Settings
Settings > Application Settings
Page Offer
L'external Id est désormais affiché dans la page de détail d'une offre (stock) quelque soit sa source. Historiquement cet external Id n'était affiché que si la source était Mirakl.
Page Order
Le design de la page de commande a entièrement été revue. Elle est déployée pour le moment en phase de beta sur certains environnements de pré-production. Parmi les évolutions notables on pourra lister :
Possibilité de trier les lignes de commande
Pouvoir ajouter des colonnes sur le tableau de lignes de commande
Meilleur affichage des incidents et des messageries (à la ligne ou à la commande)
Layer latéral pour afficher et gérer les lignes de commandes
Design global revu
Une communication plus étendue sur cette nouvelle page sera partagé prochainement. Pour plus de détails, veuillez vous rapprocher de votre CSM.
Page Order List
Filtres page order list :
La page liste de commandes va également prochainement bénéficier d'un nouveau bloc de filtres. Il segmente désormais de manière plus efficace les différentes typologies de custom fields afin de gagner en lisibilité. Ce bloc est aussi déployé en beta sur certains environnements de pré-production. On notera notamment les évolutions suivantes :
Meilleure gestion des filtres par Custom Fields
Visibilité accrue des filtres sélectionnés même lorsque les sections sont refermées
Bloc de filtres actuel
Nouveau bloc de filtres
Statut online/offline :
Une information est ajoutée dans la colonne statut afin de visualiser d'un coup d'oeil si le produit est en ligne ou hors ligne.
Page devis
Un nouveau bloc est ajouté dans la page devis afin d'afficher la ou les commande(s) liées au devis lorsqu'elle(s) est/sont passée(s).
Page Product
Statut online/offline :
Une information est ajoutée dans l'entête de la page à côté du statut afin de visualiser d'un coup d'oeil si le produit est en ligne ou hors ligne.
API
👍
UPDATE
Products
Un nouvel attribut online a été ajouté à l'ensemble des objets produits remontés sur les routes back-office. Il s'agit de signaler si le produit lié a été indexé et est visible par au moins une segmentation client.
Les routes suivantes sont concernées :
GET /v1/products
PATCH /v1/products
POST /v1/products
PUT /v1/products/back-office/{productId}
GET /v1/products/catalog-views/{id}
GET /v1/products/with-count
GET /v1/products/{id}
PUT /v1/products/{productId}
GET /v1/products/{productId}/related-products
PUT /v1/products/{productId}/related-products/{relatedProductId}
Une évolution importante des modes de connexion est en préparation. Il s'agit du support prochainement du SSO (Single Sign-On).
Nouvelle route de récupération des providers configurés :
GET /auth/sso/providers
Cette route permet de récupérer les providers SSO configurés sur un tenant. Voici le retour de l'API :
[
{
"alias": "kc-store",
"provider": "AZURE" // valeurs possibles pour le moment : "AZURE" / "GOOGLE"
}
]
Nouvelle route de redirection vers la mire d'authentification du provider d'authentification :
GET /auth/sso/init
Cette route permet de rediriger l’appelant vers la mire de connexion de l’IDP (Identity Provider) paramétré sur le tenant.
Nouvelle route de transfert de token du provider vers le front web :
POST /auth/sso/token
Ce endpoint échange le code renvoyé par l’IDP avec un jeton JWT du keycloak DJUST pour l'authentification sur le front web client.
Incidents
Nouvelle route de création d'incident à la commande :
Afin de simplifier la lecture et l’usage de la route de création d’incident, la route initiale de création des incidents à la commande est remplacée par la suivante :
ORDER-101 - POST /v1/shop/incidents
⚠️
Attention
La route historique POST /v1/shop/logistic-orders/{orderLogisticId}/incidents est dépréciée et ne doit plus être utilisée. Elle sera supprimée prochainement au profit de la nouvelle route citée ci-dessus.
L'équivalent de cette API de création d'incident à la ligne de commande arrivera également dans une future release.
Vérifications de rattachement account à la création d’incident :
Lorsqu’un incident est créé à la commande ou à la ligne de commande, l’utilisateur qui en fait la demande doit être lié à un account auquel est rattaché la commande.
Dans le cas où l’order ne fait pas partie d’un account lié à l’utilisateur qui en fait la demande, on remontera désormais une erreur 403 - FORBIDDEN.
👍
UPDATE
Search
La route de search PRODUCT-552 évolue pour accepter les filtres par le nom de product tags.
Offers
L'API de récupération des offres et prix OFFER-550 gagne en flexibilité pour pouvoir cibler directement des offres ou des prix.
Le paramètre de requête idsest supprimé et remplacé par les deux paramètres suivants :
offerPriceIds : ids des prix à retourner
offerIds : ids des offres (stocks) à retourner
Le paramètre obligatoire currency est ajouté afin de gérer les devises des prix. Les devises acceptées sont USD, EUR, GBP, INR, AUD, CAD, SGD, CHF, MYR, JPY, CNY, SEK, DKK, NOK, AED, TRY, BRL, MXN, HUF, PLN.
Data Hub
Authentification OAuth 2.0 Grant Type Client Credentials
Un nouveau type de client d’authentification a été introduit pour prendre en charge l’OAuth 2.0 avec le grant type “client credentials”
Endpoints concernés
/v1/mapper/client/
/v1/mapper/jobout/
Ajout de la valeur CLIENT_CREDENTIALS dans le champ grantType
Cette valeur permet de définir une méthode d’authentification en OAuth 2.0 pour le connecteur API.
