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 configuration des roles de custom fields : Settings > Custom Field Roles.
Page de configuration des éléments d'affichage du panier : Settings > Cart Settings.
Djust PAY
Validation et contrôle des commandes au paiement
Lorsque les commandes en checkout v2 et v3 sont passées via Djust Pay, les contrôles supplémentaires suivants sont opérés pour garantir que la commande est viable : Order Validation Rules
API
📘
NEW
Déclenchement automatique de capture CB :
Lorsque la commande est mise au statut SHIPPED (depuis le BO Djust ou en automatique via le Data Hub) et si celle-ci respecte TOUS les critères :
statut de paiement différent de PAID
moyen de paiement = credit card
Alors la capture automatique est déclenchée.
L’appel est identique à celui fait lors d’une capture manuelle livrée en 3.60.0.
La commande passe alors de la même manière au statut CAPTURE_PENDING puis PAID ou REFUSED en fonction du retour PSP et des organismes bancaires.
👍
UPDATE
Customer Accounts
Recherche par nom d'account :
Il est dorénavant possible de rechercher sur le nom d’un account dans la page liste account d’un Back Office Fournisseur.
GET /v1/customer-accounts
Le paramètre de requête search permet ainsi de rechercher par id, externalId et nom d'account.
Paiement par virement bancaire
L’API d’initialisation de paiement PAY-101 évolue pour prendre en charge les paiements par virement bancaires.
Il faut désormais ajouter le paramètre countryCode qui permet de donner le contexte pays/région d’appel pour les virements bancaires.
⚠️
Attention
Ce paramètre est rendu obligatoire pour tous les types de paiement.
Le retour de l’API évolue dans ce cas d’un virement bancaire, l’objet action remonte les informations nécessaires pour effectuer le virement par le client :
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 configuration du DAM : Settings > Product images management.
Data Hub - Configuration du mode d’exécution des jobs
Il est désormais possible d’empêcher l’exécution simultanée de plusieurs instances d’un même job d’import. Pour activer cette option, il est nécessaire d’en faire la demande auprès de l’équipe support.
Lorsque cette option est activée, vous pouvez définir le comportement d’une nouvelle instance de job si une exécution est déjà en cours. Deux choix sont possibles :
Exécuter dès que possible :
L’instance du job est mise en file d’attente et sera exécutée dès la fin de l’exécution en cours. Le statut de l’instance différée sera alors JOB_PENDING.
Passer à la suivante :
L’instance du job est annulée, et seule la prochaine exécution planifiée sera lancée. Le statut de l’instance annulée sera alors JOB_SKIPPED.
Le mode d’exécution peut être configuré directement depuis la page de configuration du job d’import.
API
📘
NEW
Punchout OCI
Il est désormais possible d'effectuer des parcours de punchout avec le protocole OCI (cXML était le seul supporté à date).
Initialisation du parcours de punchout OCI :
La première phase d’un parcours de punchout OCI consiste à permettre à l’acheteur de passer du système d’eProcurement sur lequel il s’est connecté vers le site catalogue de son fournisseur.
Cette étape se déroule comme suit :
Pour connecter la solution d’eProcurement OCI vers Djust, il faut passer par l'étape intermédiaire d’authentification via le endpoint :
ADM-PUNCHOUT-100 - POST /punchout/setup/{tenantConfigurationKey}
Ce endpoint est le même que celui utilisé pour la connexion cXML. La clé attendue, est une clé définie par Djust et fournie par votre CSM.
En cas de succès d’authentification, l’utilisateur est redirigé vers le catalogue fournisseur correspondant. Dans le cas contraire il est redirigé vers une page d’erreur.
Génération du panier et envoi à la solution d’eProcurement :
Une fois que l’acheteur a décroché de la solution d’eProcurement vers le catalogue fournisseur et qu’il a pu naviguer et ajouté des éléments à son panier, il doit retourner vers la solution d’eProcurement avec le panier nouvellement créé.
Le parcours se passe ainsi :
Afin de pouvoir envoyer le panier à la solution d’eProcurement, le front client doit appeler la route de génération de panier suivante :
ADM-PUNCHOUT-500 - GET /punchout/{tenantConfigurationKey}/commercial-orders/{commercialOrderId}/oci
Cette route retourne une liste clé/valeur d'éléments constituants le panier respectant la norme OCI :
Ces éléments sont transformés par le front dans un formulaire posté ensuite vers la solution d’eProcurement.
👍
UPDATE
Product Variants
Ajout de la gestion des id externes sur les routes d'administration de variants :
Les routes d'administration suivantes sont maintenant accessibles via les id externes de variant :
PATCH /v1/product-variants
DELETE /v1/product-variants/{productVariantId}
GET /v1/product-variants/{productVariantId}
PUT /v1/product-variants/{productVariantId}
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.
Orders
Ajout de la gestion des id externes sur les routes d'administration de commandes :
Les routes suivantes sont maintenant accessibles via les id externes de commande :
POST /v1/logistic-orders
GET /v1/logistic-orders/{orderLogisticId}
PATCH /v1/logistic-orders/{orderLogisticId}
PUT /v1/logistic-orders/{orderLogisticId}/accept
GET /v1/logistic-orders/{orderLogisticId}/approvals
PUT /v1/logistic-orders/{orderLogisticId}/cancel/{customerUserId}
PUT /v1/logistic-orders/{orderLogisticId}/complaint
PUT /v1/logistic-orders/{orderLogisticId}/complete
PUT /v1/logistic-orders/{orderLogisticId}/confirm-shipment/{customerUserId}
PUT /v1/logistic-orders/{orderLogisticId}/created
PUT /v1/logistic-orders/{orderLogisticId}/decline
PUT /v1/logistic-orders/{orderLogisticId}/export
GET /v1/logistic-orders/{orderLogisticId}/history
GET /v1/logistic-orders/{orderLogisticId}/lines
PATCH /v1/logistic-orders/{orderLogisticId}/lines/{orderLogisticLineId}
PUT /v1/logistic-orders/{orderLogisticId}/lines/{orderLogisticLineId}
PUT /v1/logistic-orders/{orderLogisticId}/lines/{orderLogisticLineId}/delete
GET /v1/logistic-orders/{orderLogisticId}/lines/{orderLogisticLineId}/threads
PUT /v1/logistic-orders/{orderLogisticId}/payment/invalidate/{customerUserId}
PUT /v1/logistic-orders/{orderLogisticId}/payment/reconcile
PUT /v1/logistic-orders/{orderLogisticId}/payment/validate/{customerUserId}
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.
Accounts
Ajout de la gestion des id externes sur les routes d'administration de comptes clients :
Les routes suivantes sont maintenant accessibles via les id externes de compte :
PATCH /v1/customer-accounts\
GET /v1/customer-accounts
GET /v1/customer-accounts/name
GET /v1/customer-accounts/{customerAccountId}
PUT /v1/customer-accounts/{customerAccountId}
GET /v1/customer-accounts/{customerAccountId}/addresses
POST /v1/customer-accounts/{customerAccountId}/addresses
DELETE /v1/customer-accounts/{customerAccountId}/addresses/{addressId}
PUT /v1/customer-accounts/{customerAccountId}/addresses/{addressId}
POST /v1/customer-accounts/{customerAccountId}/customer-organisations
PUT /v1/customer-accounts/{customerAccountId}/customer-organisations/{organisationId}
GET /v1/customer-accounts/{customerAccountId}/customer-users
POST /v1/customer-accounts/{customerAccountId}/customer-users
PATCH /v1/customer-accounts/{customerAccountId}/payment-type
PATCH /v1/customer-accounts/{customerAccountId}/validate
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
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 liste des Stores : Stores. (Pour les clients concernés)
Page liste des Offres : Offers.
Page liste des Organisations : Customers > Organisations.
Page de détail de commande
Afin de faciliter la relecture des lignes de commandes, le nombre de ligne affiché a été augmenté à 50 lignes. Il offre ainsi une aisance de lecture grandement améliorée.
Page liste des accounts
La recherche d'accounts est facilitée avec l'ajout d'un nouveau filtre de recherche par ID (Djust pour le moment, la prise en charge des IDs externes arrivera dans une version prochaine).
API
👍
UPDATE
Orders
Filtrage des commandes commerciales sur une liste d'accounts :
Il est désormais aussi possible de récupérer les commandes commerciales en filtrant sur une liste d'id d'accounts via le paramètre de requête customerAccountIds :
ORDER-560 - GET /v1/shop/commercial-orders
⚠️
Attention
Si une valeur est renseignée dans le paramètre customerAccountIds, alors automatiquement l'identifiant du compte passé dans le header est ignoré.
Filtrage des commandes commerciales à l'utilisateur connecté :
Afin de pouvoir récupérer l’ensemble des commandes commerciales 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-560.
Ainsi, la route ORDER-560 - GET /v1/shop/commercial-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.
Data Hub
Création multiple de transcoding
L’endpoint POST /v1/mapper/job/{jobId}/transcodings accepte désormais une liste d’objets pour convertir plusieurs valeurs pour plusieurs mappings sur un job d’import donné.
Exemple:
POST /v1/mapper/job/ad249986-0048-4a95-9fb7-8c4d1e01617f/transcodings
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 liste des Assortiments : Catalog > Assortments.
Page liste des Fournisseurs : Suppliers.
Page liste des Comptes : Customers > Accounts.
Page de gestion des locales : Settings > Locales management.
API
📘
NEW
Customer users
Récupération des customer users d'une liste de comptes :
Afin de permettre la gestion des users multi compte, une api a été créé pour récupérer la liste de tous les users des différents accounts.
ACCOUNT-502 - GET /v1/shop/customer-accounts/users
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 liste des Restrictions de catalogues : Catalog > Catalog Views.
API
📘
NEW
Customer users
Ouverture de la modification d'un customer user en front :
Il est désormais possible de modifier les informations d’un user du même account.
Le body est similaire à la route de modification du customer user connecté USER-201.
🗒️
Note
L'utilisation de cette route est soumise au droit : USER_FOC_MANAGEMENT. Pour l'activer, veuillez vous rapprocher de votre CSM.
Association/dissociation d'un customer user à son compte client :
Afin de permettre une administration plus approfondie des utilisateurs d’un même compte, il est maintenant possible d’associer un utilisateur à son compte alors qu’il est déjà présent sur un autre compte. Il est aussi possible de le dissocier de son compte.
L'utilisation de cette route est soumise aux droits suivants :
FOC_CUSTOMER_USER_ACCOUNT_ASSIGN pour l'association d'un user à un compte
FOC_CUSTOMER_USER_ACCOUNT_REMOVE pour la dissociation d'un user à un compte
Pour l'activer, veuillez vous rapprocher de votre CSM.
Product variants
Une nouvelle route API a été créé afin de permettre la récupération des informations d’un variant spécifique.
PRODUCT-510 - GET /v1/shop/product-variants/{productVariantId}
👍
UPDATE
Product variants
Ajout de la gestion des id externes sur les routes d'administration de variants :
Les routes d'administration suivantes sont maintenant accessibles via les id externes de variant :
PATCH /v1/product-variants
DELETE /v1/product-variants/{productVariantId}
GET /v1/product-variants/{productVariantId}
PUT /v1/product-variants/{productVariantId}
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.
Offers
Ajout de la gestion des id externes sur les routes d'administration d'offres :
Les routes d'administration suivantes sont maintenant accessibles via les id externes d’offre :
PATCH /v1/offer-inventories
PATCH /v1/offer-inventories/{offerInventoryId}/offer-prices
DELETE /v1/offer-inventories
GET /v1/offer-inventories
GET /v1/offer-inventories/{offerInventoryId}
PUT /v1/offer-inventories/{offerInventoryId}
PUT /v1/offer-inventories/{offerInventoryId}/offer-prices
DELETE /v1/offer-inventories/{offerInventoryId}/offer-prices/{offerPriceId}
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.
Customer Accounts
Ajout de nouvelles adresses partagées sur un compte client :
Il est maintenant possible pour une adresse d’être partagée par plusieurs accounts lors d’une création depuis le Back Office.
POST /v1/customer-accounts/{customerAccountId}/addresses
🗒️
Note
Aucun changement n'est visible sur le contrat de l'API. En revanche, l'ajout d'une adresse avec un id externe déjà existant n'est plus bloqué.
En effet, si l'adresse est reconnue via son id externe, alors elle est affectée au compte sans prendre en compte d'éventuels changements donnés.
Customer Organisations
Modification de la pagination de la récupération des utilisateurs d'une organisation :
La route d'administration de récupération des utilisateurs d'une organisation évolue avec une pagination corrigée et similaire aux autres routes.
GET /v1/customer-organisations/{organisationId}/customer-users
Products
Prise en charge des bundles dans la récupération d'un produit :
Le retour de l’appel API de récupération des informations d'un produit a été modifié afin de préciser si un bundle est relié au produit ou non.
Le champs ajouté est un booléen : isBundle.
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 gestion des règles d'achats / parcours de création / suppression de règles d'achats : Customers > Buying Policies.
Data Hub
Mécanisme de retry automatique pour les exports par Connecteur API
Lorsqu’un export par Connecteur API échoue (par exemple pour cause d’indisponibilité temporaire ou d’erreur réseau), le système effectuera désormais jusqu’à 3 tentatives supplémentaires espacées de 5 minutes chacune.
Importer plusieurs adresses pour des Accounts par Connecteur API
Il désormais possible de créer plusieurs adresses pour un même Account depuis le Connecteur API.
Le format de la réponse API attendu par le Connecteur API est le suivant:
Ajout de la gestion des id externes sur les routes d'administration produits :
Les routes d'administration suivantes sont maintenant accessibles via les id externes de produit :
PATCH /v1/products
POST /v1/products/with-count/back-office
PATCH /v1/products/status/activate
GET /v1/products/with-count
GET /v1/products/{id}
DELETE /v1/products/{productId}
PUT /v1/products/{productId}
GET /v1/products/{productId}/related-products
DELETE /v1/products/{productId}/related-products/{relatedProductId}
PUT /v1/products/{productId}/related-products/{relatedProductId}
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
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.
