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.
Data Hub - Export de commandes SFTP | Nom de fichier court
Il est désormais possible de configurer le format du nom de fichier pour les exports de commandes via SFTP.
Formats disponibles :
Format standard (par défaut) :
DJUST_ORDERID_SUPPLIERID_TIMESTAMP_orders.FORMAT
Exemple : DJUST_172-189-1896838-1_FRMO_1721891899392_orders.xml
Format simplifié (nouveau format, sur demande) :
ORDERID.FORMAT
Exemple : 172-189-1896838-1.xml
Le format simplifié est disponible sur demande.
Back-Office
Visualisation des restrictions de catalogues (Catalog Views) sur une page produit
Il est désormais possible via la page produit d’identifier dans quelle restriction de catalogue se trouve le produit.
API
📘
NEW
Orders
Une évolution importante des commandes est en préparation. Elles vont apporter la possibilité de créer une commande sans panier ni devis au préalable et y ajouter un comportement similaire à celui du panier.
Nouvelle route de création de commande commerciale :
ORDER-108 - POST /v2/shop/commercial-orders
Cette route permet de créer une nouvelle commande commerciale avec l'ajout possible de custom fields liés. Voici le body de l'API :
Nouvelle route de modification de commande commerciale :
ORDER-222 - PUT /v2/shop/commercial-orders/{commercialOrderId}
Cette route permet la mise à jour d'une commande commerciale à partir de son id externe ou de se référence. Son body est similaire à celui de ORDER-108, il permet l'update des CF de la commande commerciale.
Nouvelle route d'ajout de ligne à la commande commerciale :
ORDER-150 - PUT /v2/shop/commercial-orders/{commercialOrderId}/lines
Cette route permet d'ajouter des lignes de commande (automatiquement ventilées sur les commandes logistiques liées). Son comportement est semblable à l'ajout de lignes à un panier.
{
"lineType": "OFFER_PRICE", // OFFER_PRICE or PRODUCT_VARIANT
"lineIdType": "EXTERNAL_ID", // DJUST_ID or EXTERNAL_ID
"customFieldIdType": "DJUST_ID",
"lines": [
{
"id": "123456", // can be offer price id or variant id
"quantity": 10,
"updateAction": "ADD_QUANTITY",
{
"customFields": [
{
"customFieldId": "string",
"customFieldValue": "string"
}
],
}
]
}
⚠️
Attention
Le path param commercialOrderId est de type unique REFERENCE. Les business ids ou les external ids ne sont pas acceptés.
Nouvelle route de récupération des lignes d'une commande commerciale :
ORDER-561 - GET /v1/shop/commercial-orders/{commercialOrderId}/lines
Cette route est dédiée à la récupération paginée des lignes d'une commande commerciale. Il est possible de la filtrer par ids de fournisseur, de variants ou d'offer prices.
Nouvelle route de suppression de commande commerciale :
Cette route pouvant être sensible, elle est contrainte par un droit utilisateur CHECKOUT_ORDER_DELETE. Si l'utilisateur possède ce droit, alors il sera autorisé à supprimer une commande commerciale. L'ensemble des commandes logistiques liées doivent être en statut DRAFT_ORDER.
Nouvelle route de suppression de ligne d'une commande commerciale :
ORDER-350 - DELETE /v2/shop/commercial-orders/{commercialOrderId}/lines
Cette route permet la suppression d'une ou plusieurs lignes d'une commande commerciale.
"lines": [
{
"offerPriceId": "string",
}
]
👍
UPDATE
Orders
Les routes suivantes de gestion des commandes commerciales évoluent pour préparer les futures évolutions de réapprovisionnement automatiques.
L'ensemble des routes évoluent avec les changements de propriétés suivantes :
🆕
Nouvelles propriétés
customerAccountSnapshot : les informations d'account sont enregistrées au niveau de la commande commerciale
lineCount : nombre total de lignes de produits contenus dans les différentes commandes logistiques
productCount : nombre total de produits contenus dans les différentes commandes logistiques. Si une ligne contient une quantité 10, on ajoutera 10 au productCount.
custom fields : les custom fields sont désormais présents au niveau de la commande commerciale
updatedAt : date de dernier update de la commande commerciale
validatedAt : date de passage en statut CREATED de l’ensemble des commandes logistiques
📘
Information
Le nombre de lignes n’est pas égal au nombre de produits. En effet, une ligne correspond à un prix. Sur un produit, il peut par exemple y avoir plusieurs conditionnements avec des offres/prix différents. Pour un produit on aura donc plusieurs lignes correspondantes.
❌
Propriétés supprimées
numberOfLines : ancienne propriété non utilisée pour le nombre de lignes du commande
numberOfProducts : ancienne propriété non utilisée pour le nombre total de produits
Routes d'administration back-office 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
Routes front-office concernées :
ORDER-560 - GET /v1/shop/commercial-orders
GET /v1/shop/customer-accounts/orders
GET /v1/shop/customer-accounts/organisations/{organisationId}/orders
GET /v1/shop/logistic-orders
POST /v1/shop/logistic-orders
Vous pouvez désormais sélectionner votre méthode d’authentification directement depuis la section “Authentication type” lors de la configuration de la connexion client:
No Auth
OAuth 2.0 (password grant) : avec les champs requis pour configurer votre accès sécurisé (Access Token URL, Client ID, Client Secret, Username, Password).
Changements côté API POST /v1/mapper/client
Ajout du type API_OAUTH2_CLIENT
Un nouveau type de client d’authentification a été introduit pour prendre en charge l’OAuth 2.0 avec le grant type “Password”.
Ajout du champ connectionInformation :
Ce champ permet de configurer les informations nécessaires à l’authentification, incluant :
baseUrl : l’URL de base de l’API.
accessTokenUrl : l’URL pour obtenir le token d’accès.
clientId et clientSecret : identifiants du client.
grantTypeInformation : contient le grant type utilisé (PASSWORD) et les champs username et password.
Les routes suivantes d'administration back office ont été modifiées pour homogénéiser et fiabiliser les paramètres de pagination :
Modification des valeurs min des paramètres de requête page à 0 et size à 1 :
Routes d'administration back-office concernées :
GET /public/v1/suppliers
GET /v1/assortments
GET /v1/buying-policies/{id}/customer-users
GET /v1/customer-accounts
GET /v1/customer-accounts/{customerAccountId}/customer-users
GET /v1/customer-organisations/{organisationId}/customer-users
GET /v1/customer-users
GET /v1/logistic-orders
POST /v1/logistic-orders
GET /v1/logistic-orders/{orderLogisticId}/lines
GET /v1/mail-templates
GET /v1/mapper/jobout/{jobOutId}/exported-item-statuses
GET /v1/mapper/status/all/{jobId}
GET /v1/mapper/statusout/{jobOutId}/all
GET /v1/operator-users
GET /v1/product-variants
GET /v1/products/with-count
POST /v1/products/with-count/back-office
GET /v1/stores
GET /v2/user-groups/{groupId}/users
Routes front-office concernées :
PRODUCT-551 : GET /v1/shop/autocomplete
ACCOUNT-550 : GET /v1/shop/customer-accounts/orders
ACCOUNT-503 : GET /v1/shop/customer-accounts/organisations (deprecated)
ACCOUNT-555 : GET /v1/shop/customer-accounts/organisations/{organisationId}/orders
ACCOUNT-504 : GET /v1/shop/customer-accounts/organisations/{organisationId}/users
ACCOUNT-502 : GET /v1/shop/customer-accounts/users
PRODUCT-550 : GET /v1/shop/list
N/A : GET /v1/shop/logistic-orders (deprecated)
ORDER-550 : POST /v1/shop/logistic-orders
ORDER-555 : GET /v1/shop/logistic-orders/{orderLogisticId}/lines
QUOTE-500 : GET /v1/shop/master-quotes
PRODUCT-503 : GET /v1/shop/products/{productIdentifier}/related-products
SUPPLIER-550 : GET /v1/shop/suppliers
SUPPLIER-551 : GET /v1/shop/suppliers/{supplierId}/evaluations
PRODUCT-553 : GET /v2/shop/autocomplete
PRODUCT-552 : GET /v2/shop/search
Suppression du paramètre de requête pageable:
Routes d'administration back-office concernées :
GET /v1/attributes
GET /v1/buying-policies
GET /v1/catalog-views
GET /v1/catalog-views/{id}/products
GET /v1/customer-organisations
GET /v1/customer-organisations/{organisationId}/customer-users
GET /v1/customer-tags
GET /v1/mapper/status/all/{jobId}
GET /v1/mapper/statusout/{jobOutId}/all
GET /v1/product-tags
GET /v1/products/catalog-views/{id}
GET /v1/stores
GET /v1/supplier-quotes
GET /v1/supplier-quotes/{supplierQuoteId}/orders
GET /v1/transactions/unreconciled
GET /v2/user-groups/{groupId}/users
Routes front-office concernées :
N/A : GET /v1/shop/attributes
ACCOUNT-550 : GET /v1/shop/customer-accounts/orders
ACCOUNT-503 : GET /v1/shop/customer-accounts/organisations (deprecated)
ACCOUNT-555 : GET /v1/shop/customer-accounts/organisations/{organisationId}/orders
ACCOUNT-504 : GET /v1/shop/customer-accounts/organisations/{organisationId}/users
ACCOUNT-502 : GET /v1/shop/customer-accounts/users
SUPPLIER-550 : GET /v1/shop/suppliers
SUPPLIER-551 : GET /v1/shop/suppliers/{supplierId}/evaluations
Ajout du paramètre de requête pagemanquant sur les routes :
Routes d'administration back-office concernées :
GET /v1/attributes
GET /v1/buying-policies
GET /v1/catalog-views
GET /v1/catalog-views/{id}/products
GET /v1/customer-organisations
GET /v1/customer-tags
GET /v1/product-tags
GET /v1/products/catalog-views/{id}
GET /v1/supplier-quotes
GET /v1/supplier-quotes/{supplierQuoteId}/orders
GET /v1/suppliers/{supplierId}/supplier-users
GET /v1/transactions/unreconciled
Routes front-office concernées :
N/A : GET /v1/shop/attributes
ORDER-560 : GET /v1/shop/commercial-orders
Ajout des paramètres de requête sizeet sort manquants sur les routes :
Routes d'administration back-office concernées :
GET /v1/attributes
GET /v1/buying-policies
GET /v1/catalog-views
GET /v1/catalog-views/{id}/products
GET /v1/customer-organisations
GET /v1/customer-tags
GET /v1/jobs
GET /v1/product-tags
GET /v1/products/catalog-views/{id}
GET /v1/supplier-quotes
GET /v1/supplier-quotes/{supplierQuoteId}/orders
GET /v1/suppliers/{supplierId}/supplier-users
GET /v1/transactions/unreconciled
Routes front-office concernées :
N/A : GET /v1/shop/attributes
ORDER-560 : GET /v1/shop/commercial-orders
Modification des valeurs par défaut des paramètres de requête page à 0 et size à 20 :
GET /v1/customer-accounts
Orders
Les routes de récupération de commande se voient enrichies par l'id externe de la catégorie de classification. Il n'y avait jusqu'à présent que le nom de la catégorie dans les réponses API.
La nouvelle propriété se trouve dans l'objet orderLogisticLineProductDto de la réponse.
Routes d'administration back-office :
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/logistic-orders/{orderLogisticId}/shipments
Routes front-office :
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 (deprecated)
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-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-556 : GET /v1/shop/logistic-orders/{orderLogisticId}/approvers
ORDER-555 : GET /v1/shop/logistic-orders/{orderLogisticId}/lines
ORDER-206 : PATCH /v1/shop/logistic-orders/{orderLogisticId}/lines/{orderLogisticLineId}
ORDER-560 : GET /v1/shop/commercial-orders
ORDER-100 : POST /v1/shop/commercial-orders
ORDER-500 : GET /v1/shop/commercial-orders/{orderCommercialId}
ORDER-107 : POST /v2/shop/supplier-quotes/{supplierQuoteId}/initialize-orders
Il est désormais aussi possible de récupérer les commandes logistiques en filtrant sur une liste d'id d'accounts via le paramètre de requête customerAccountIds :
N/A : GET /v1/shop/logistic-orders (deprecated)
ORDER-550 : POST /v1/shop/logistic-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é.
mapper
La valeur JOB_SKIPPED a été ajoutée à la liste des valeurs possibles pour l'attribut status de la réponse.
GET /v1/mapper/job
POST /v1/mapper/job
GET /v1/mapper/job/{jobId}
PATCH /v1/mapper/job/{jobId}
PUT /v1/mapper/job/{jobId}
GET /v1/mapper/status/all/{jobId}
GET /v1/mapper/status/{jobId}
POST /v2/mapper/job
Rôles des utilisateurs
Le paramètre de requête client des routes d'administration des rôles des utilisateurs devient obligatoire :
GET /v1/roles
POST /v1/roles
POST /v2/user-groups
Paniers
Il est désormais possible d'utiliser les paniers comme des buying lists. Il suffit pour cela de préciser son type via la propriété typedes APIs suivantes :
CART-100 : POST /v2/shop/carts
CART-200 : PUT /v2/shop/carts/{cartId}
Les valeurs possibles sont CART et BUYING_LIST.
ℹ️
Point d'attention
La valeur par défaut sur l'appel à CART-100 du paramètre type est CART.
En revanche, un appel sans valeur renseignée pour le paramètre type sur CART-200 conservera la donnée. Il n'y a dans ce cas aucune valeur par défaut.
Les pages de configuration des offres sont enrichies avec les quantités minimum et maximum commandables.
Ceux-ci sont disponibles directement dans le détail de chaque offre.
API
👍
UPDATE
Search
Actuellement, la route historique de recherche (V1) PRODUCT-550 a un paramètre order.type qui accepte les valeurs suivantes :
BRAND
CREATION
CATEGORY
NAME
SCORE
PRICE
Les 3 premières valeurs (BRAND, CREATION, CATEGORY) n'ont pas d'impact sur la recherche et sont dépréciées.
Products
La route d'administration de récupération de listes produits POST /v1/products/with-count/back-office évolue afin de pouvoir remonter l'information "online/offline" de chaque produit.
Un produit est dit "online" si celui-ci est visible en ligne sur le site web client. A l'inverse il sera "offline".
La valeur est disponible dans l'attribut online de chaque élément retourné. Si l'attribut est à true, alors il est réputé online, s'il est à false alors il sera offline.
⚠️
Attention
Cet attribut n'est disponible que dans un contexte de Search V2.
Les pages de configuration des custom fields sont enrichies des custom fields aux threads de messagerie., à la commande commerciale et aux incidents.
Ceux-ci sont disponibles dans la section Settings > Order management
Data Hub
Amélioration des imports de catégories de classification
Avec le job d’import de classifications par fichier CSV, il est désormais possible d’activer ou désactiver les fonctionnalités suivantes du Search V2:
Searchable
Faceted
Sortable
API
🚀
NEW
Quotes
Ajout de la possibilité de récupérer l'ensemble des commandes associées à un devis la route d'administration :
GET /v1/supplier-quotes/{supplierQuoteId}/orders
La réponse est une liste de commandes logistiques qui ont été issues du devis passé en paramètre.
👍
UPDATE
Connecteur MangoPay
Le route de création de compte chez MangoPay PAY-100 évolue pour prendre en compte les éléments suivants :
la possibilité de préciser si l'utilisateur créé est un legal ou un natural user :
userType : type du user à créer, il prendra au choix la valeur NATURAL ou LEGAL afin de créer respectivement un natural user ou un legal user chez MangoPay.
savoir si les CGU ont été acceptées (contrainte légale) :
termsAndConditionsAccepted : booléen à true si les CGU sont acceptées, false sinon.
Offers
La route d'administration des offres (inventories) se voit agrémentées de deux nouveaux attributs pour gérer les minimum et maximum de quantité commandable :
PUT /v1/offer-inventories/{offerInventoryId}
Deux attributs existants dans le modèles sont désormais disponibles à l'édition par API :
minOrderQuantity et maxOrderQuantity
⚠️
Attention
L'édition dans le BackOffice de ces champs sera rendue possible dans la version suivante 3.49.0.
Search
La route PRODUCT-552 accepte désormais la recherche de fournisseurs sur des id externes :
GET /v2/shop/search?currency={{currency}}&locale={{locale}}&suppliers=**supplierExternalId**
📘
Information
Le fonctionnement de recherche actuel sur les noms des fournisseurs est maintenu :
GET /v2/shop/search?currency={{currency}}&locale={{locale}}&suppliers=**supplierName**
Attributs
La route de récupération d'administration des attributs GET /v1/attributes permet maintenant de renvoyer tous les attributs de la plateforme si aucune valeur n'est donnée pour le header dj-store.
Un nouveau bouton pour forcer le déclenchement d'un export d'une commande a été ajouté. Il permet ainsi d'exécuter un nouvel export manuellement.
⚠️
Attention
Deux conditions doivent être remplies pour effectuer un export manuel d’une commande :
Un job d’export de commande doit avoir été créé.
Le statut de la commande doit figurer parmi les statuts autorisés pour l’export définis dans le job d’export.
Data Hub
Amélioration de la page des jobs d’export dans le Back Office
La page des jobs d’export a été enrichie avec de nouvelles informations pour une meilleure lisibilité et gestion :
Nom du job : Chaque job est désormais identifié par un nom spécifique.
Date de mise à jour : Une colonne indique la dernière mise à jour de chaque job.
Statut : Le statut actuel (Active/Inactive) est désormais affiché.
Amélioration du téléchargement des rapports d’intégration dans le Back Office
Les problèmes de téléchargement des rapports volumineux (+20 000 lignes) ont été résolus
Configuration des jobs d’export de commande par Connecteur API
Désormais, via le Back-Office, il est possible de configurer les jobs d’export sur une API
Nouvelle fonctionnalité : Téléchargement du rapport d’erreur pour les imports échoués
Désormais, lorsque qu’un job d’import passe au statut JOB_FAILED, il est possible de télécharger un rapport indiquant la raison précise de l’échec. Cette fonctionnalité vous permet d’identifier et de corriger rapidement les problèmes rencontrés.
Exports de commandes XML
L’Id DJUST de la commande est désormais renseigné dans la balise id dans le fichier XML lors d’un export de commande
Indexation / Search
Les visuels sont désormais gérés lors de l'indexation partielle. À chaque changement de visuel sur la plateforme Djust, l'indexation et la page de votre catalogue seront mises à jour automatiquement.
Connecteur Punchout cXML
Transcodage des catégories de classification
Lors de la génération du fichier cXML retour pour la solution d'eProcurement, certains clients ont besoin d’avoir la classification rattachée aux différents produits afin de gagner en lisibilité et pouvoir faire des statistiques.
Or la classification du client n’est pas celle du système eCommerce sur lequel est fait le panier.
Une transcodification des classifications du système eCommerce (Djust) vers le système du client est ainsi désormais assurée.
⚠️
Attention
La configuration de cette table de transcodification doit être effectuée par le CSM référent Djust.
API
🚀
NEW
Buying policies
Ajout de la possibilité de mettre à jour les validateurs d'une commande via la route d'administration :
PUT /v1/buying-policies/{id}/approvers
La liste des validateurs est passée en paramètre dans le body :
{
"approverIds" : ["0000002771", "0000004197"]
}
⚠️
Attention
Le mode par défaut est du REPLACE, c’est à dire que si l’on envoie un seul approver et qu’il en existait 3, ils seront remplacés intégralement par le nouvel approver donné.
👍
UPDATE
emails
Les routes d'administration des configurations des emails évolue pour prendre en compte l'email du sender ainsi que son nom :
PUT /v1/settings/mailer
PATCH /v1/settings/mailer
Les bodies sont complétés avec les attributs sender et senderName :
Le paramètre ids de la route GET /v1/shop/incidents ORDER-559 est désormais optionnel.
La route de récupération des incidents pour un ou plusieurs acompte(s) évolue pour être simplifiée et plus générique à l'utilisation. Elle permet ainsi de récupérer les incidents de plusieurs accounts en un seul appel grâce au nouvel paramètre d'appel customerAccountIds. GET /v1/shop/customer-accounts/{customerAccountId}/incidents ACCOUNT-551 devient GET /v1/shop/incidents/{incidentId} ORDER-503
