Aller au contenu

Vérifier les prix ERP par client, quantité et validité

Un exemple détaillé relie compte client, prix unitaire, palier et date d’expiration. Le contrôle avant commande aide à repérer les prix périmés.

Lena Fischer2 min de lecture
Fiche en papier avec symboles verts d’usine et de personne, trois lignes et un calendrier fixé par une pince.

Un prix propre à un client exige plus de contexte qu’une référence article. Odoo décrit des règles avec produit, quantité minimale et période de validité. L’emplacement d’entreprise dans Shopify B2B illustre que l’association autorisée à une entreprise détermine aussi le prix proposé. Une liaison ERP-boutique exige des correspondances claires.

Un prix avec changement de quantité et expiration

Un vendeur fictif de filtres prévoit cette liaison. L’exemple concerne le compte client K-58 et l’article FILTER-A, commandé à l’unité. Le prix standard est de 17 EUR hors taxes par unité ; une règle client temporaire propose 16 EUR hors taxes par unité à partir de 6 unités.

État de la règle

Quantité de la ligne

Prix unitaire hors taxes attendu

Règle client valide

5 unités

17 EUR

Règle client valide

6 unités

16 EUR

Règle client expirée

6 unités

17 EUR

Ces prix et résultats attendus sont fictifs, pour un essai prévu. Après expiration, une ancienne copie de la règle client ne doit pas continuer à fournir le prix inférieur.

Relier les champs nécessaires au prix

Conservez ensemble l’association client autorisée, la référence article, l’unité de commande, la quantité, la devise et la validité. Vérifiez que l’ERP et la boutique donnent le même sens à l’unité. Un prix par carton ne doit pas apparaître comme un prix à la pièce sans contrôle. La référence ERP et l’instant du prix calculé doivent rester traçables pour l’examen interne.

Revérifier lors des changements

Le parcours prévu recalcule le prix après un changement de quantité et vérifie à nouveau le contexte client actuel et la validité avant la finalisation. Un cache rapide peut aider l’affichage ; son entrée nécessite les attributs de contexte utiles et une gestion définie des changements. Une durée de conservation générale ne suffit pas à savoir si une règle a expiré entre-temps.

Si le prix change, l’interface doit afficher clairement le nouveau montant avant la finalisation. Pour cette boutique fictive, il est convenu de suspendre la finalisation sans prix confirmé de façon fiable et de proposer un nouveau contrôle.

Rendre la comparaison visible dans l’essai

Parcourez les cas du tableau avec une liaison de test adaptée. Comparez résultat ERP, affichage et prix de commande prévu. Ajoutez un changement de contexte client autorisé et une source de prix inaccessible. Le prix enregistré doit correspondre à l’opération ; un ancien prix non revérifié ne doit pas être enregistré comme prix de commande actuellement confirmé.

Sources

Écrit par

  • Lena FischerRédactrice e-commerceLena Fischer s’occupe des articles e-commerce d’ASES. Elle écrit sur les systèmes de boutique en ligne et leur intégration avec d’autres applications, et explique les processus techniques qui sous-tendent le commerce en ligne.

Suivre ASES

À lire aussi

Tous les articles

E-commerce avec ASES

Boutiques en ligne, marketplaces et portails B2B