Lignes de détails dans une soumission#
💡 Acomba n’impose pas de validation stricte sur la présence d’un produit (sku) dans chaque ligne de détail.
Cela permet — ou plutôt exige — que toute information affichée dans une soumission, y compris les simples
commentaires ou notes, soit représentée sous forme de ligne d’item.
⚠️ Ce qu’il faut savoir :1.
Chaque ligne, qu’elle contienne un produit ou non, doit être envoyée comme une entrée dans le tableau details.
2.
Le champ description est limité à 90 caractères par ligne. Pour afficher un long commentaire, vous devez le fragmenter en plusieurs lignes distinctes.
3.
Les notes, instructions ou séparateurs visuels doivent être envoyés sans sku mais avec une description.
Exemple d’utilisation mixte (produits + commentaires) :{
...
"details": [
{
"line_number": 1,
"sku": "EscTrans",
"ordered_qty": 2.0
},
{
"line_number": 2,
"sku": "INSTALLATION",
"description": "Temps d'installation",
"ordered_qty": 8.25,
"unit_price": 125
},
{
"line_number": 4,
"sku": "",
"description": "NOTE : Livraison avant 7h AM."
},
{
"line_number": 5,
"sku": "",
"description": "Accès limité côté cour."
}
]
}
🛠️ Ce comportement est hérité du fonctionnement du SDK Acomba. ExoConnect s’occupe de l’encodage technique,
mais il revient à l’utilisateur de structurer ses commentaires selon ces règles.
Comportement de l’API#
L’API de création de soumissions est conçue pour simplifier la vie des utilisateurs en préremplissant automatiquement
certains champs lorsque l’information est partiellement fournie.Récupération automatique des données#
Lorsque certains champs sont omis, voici quelques examples du comportement par défaut de l’API :| Champ | Comportement si omis |
|---|
| term_code | Utilise le terme de paiement associé au client |
| sales_rep_code | Utilise le vendeur associé au client |
| territory_code | Utilise le territoire du client |
| date | Si omis, la date du jour sera utilisé |
| reference.invoice_to_id | Si omis, mais invoice_to_number est fourni, une tentative de résolution est effectuée |
| details[].product_group | Si le sku existe, le groupe de produit sera récupéré automatiquement |
| details[].description | Sera extrait du produit si le sku correspond à un produit existant |
| details[].unit_price | Même chose : sera extrait du produit si sku connu |
| details[].tax_amount_1/2 | Calculé automatiquement à partir des taxes du client et du groupe de taxes assigné |
🛠️ L’API utilise le numéro de produit (sku) comme point de départ pour enrichir les lignes de détails si l’information est absente.
⚠️ Recommandation#
Pour éviter toute ambiguïté et garantir une soumission complète et fidèle :Fournir toutes les informations est fortement recommandé, même si le système peut les compléter automatiquement.
Cela assure un comportement prévisible, surtout lorsque des règles spéciales s’appliquent à certains produits ou clients.
Exemple minimaliste accepté :#
{
"customer_number": "CUST001",
"details": [
{
"sku": "PROD123",
"ordered_qty": 10
},
{
"sku": "",
"description": "Livraison spéciale avant 7h"
}
]
}
Dans cet exemple, la ligne PROD123 sera complétée automatiquement avec sa description, son prix, son groupe de produit
et ses taxes, tandis que la ligne sans sku sera traitée comme un commentaire libre.⚠️ Limitation connue — Modification du vendeur (sales_rep_code)#
Lors d’une mise à jour d’une fiche de transaction (soumission, commande, facture, etc.), les champs
sales_rep_code (numéro du vendeur) et reference.sales_rep_id (identifiant du vendeur) ne sont pas mis à jour correctementtransaction.InSalesRepCP = X suivi d’un ModifyOrder(...) ou ModifyCard(...) ne conserve pas la valeur.
Après modification, les champs reviennent à leur valeur précédente.
Toutes les autres propriétés (description, dates, client, etc.) sont modifiées correctement.
Aucun contournement n'est disponible pour le moment. Une mise à jour sera déployé dès le correctif mis en place.Modified at 2025-05-21 12:30:15