Commande client PDF modifiée : éviter de saisir deux versions dans l’ERP

Un client envoie un bon de commande PDF, puis une version corrigée. La première est déjà saisie dans l’ERP. La seconde arrive avec un nom de fichier différent et aucune indication claire de ce qu’elle remplace.

Extraire les deux documents ne résout pas le problème. Le flux doit reconnaître une révision, présenter ses différences et vérifier ce qui peut encore être modifié. L’objectif est de préparer une décision exploitable par l’équipe commerciale ou l’administration des ventes.

Identifiez la commande avant de comparer les fichiers

Le nom du fichier et l’ordre d’arrivée des emails ne suffisent pas. Recherchez la référence client, le compte client concerné, une éventuelle référence interne et l’identifiant de commande dans l’ERP.

Une date plus récente ne signifie pas nécessairement que tout le document annule la version précédente. Le message peut apporter une correction, une pièce complémentaire ou une nouvelle commande. Si l’intention reste ambiguë, le dossier doit demander une confirmation au lieu de choisir silencieusement.

Conservez les versions et leurs sources. Une nouvelle pièce ne doit pas effacer le document sur lequel une décision ou une livraison a déjà été fondée.

Comparez les lignes dans un vocabulaire commun

Avant de signaler une quantité différente, vérifiez que les lignes parlent du même article et de la même unité. Une référence client peut être différente de votre référence catalogue. Une ligne peut être exprimée en cartons plutôt qu’en unités.

La correspondance catalogue et les conversions autorisées doivent être définies avec l’équipe métier. Un libellé proche n’autorise pas une substitution. Si plusieurs articles restent possibles, présentez les candidats pour validation.

Une comparaison utile sépare les lignes ajoutées, retirées et modifiées. Elle présente les changements de quantité, prix, unité, adresse ou date demandée, avec la valeur précédente et la valeur reçue. Réduire toute la révision à un total différent masque la décision à prendre.

Une révision arrive parfois trop tard pour une simple mise à jour

Exemple fictif : la version A demande 20 unités d’un article. L’équipe en prépare 8. La version B demande 12 unités au total.

Il serait trompeur de remplacer simplement 20 par 12 sans consulter l’état opérationnel. Les 8 unités peuvent être réservées, préparées ou déjà expédiées. Ces états ne donnent pas la même marge d’action.

Le validateur doit consulter l’ERP et les informations de préparation disponibles. Il décide ensuite de la modification permise, de la confirmation à obtenir et du solde restant. Le document PDF propose une nouvelle demande ; il ne décrit pas à lui seul l’état réel de l’exécution.

Définissez qui accepte le changement

La réception d’une version corrigée et son acceptation sont deux étapes. Le flux doit indiquer qui peut approuver une modification, quels champs nécessitent une vérification et quand une demande doit être transmise à un autre responsable.

Préparez un brouillon de mise à jour plutôt qu’une écriture immédiate lorsque le changement touche un engagement déjà pris. Conservez l’auteur de la décision, la version retenue et le motif d’un refus ou d’une acceptation partielle.

Si le client doit confirmer une ambiguïté, le dossier peut préparer les différences à lui soumettre. L’envoi et la décision restent soumis au processus convenu.

Utilisez le mécanisme de modification de l’ERP

Avant un développement spécifique, vérifiez comment votre ERP gère les références externes, les révisions, les lignes déjà livrées et les modifications de commandes. Examinez aussi les imports CSV, portails ou échanges EDI existants.

L’intégration doit retrouver la commande concernée et utiliser le mécanisme supporté pour la modifier. Créer une deuxième commande à chaque PDF corrigé transforme une révision en doublon opérationnel.

Après transmission, conservez l’identifiant de destination et vérifiez le résultat. Une reprise après panne doit rechercher la modification déjà appliquée avant de tenter une nouvelle écriture.

Testez les révisions qui mettent le flux en difficulté

Le jeu d’essai doit inclure une quantité modifiée, une ligne retirée, un changement d’unité, une référence ambiguë et une révision reçue après une expédition. Ajoutez deux versions arrivées dans le désordre et un PDF renvoyé sans modification.

Pour chaque dossier, définissez avec le responsable métier ce qui devrait être retrouvé, signalé, bloqué ou soumis à confirmation. Mesurez les mauvaises associations, les modifications non détectées, le temps de revue et les doubles créations évitées ou manquées. N’assimilez pas une extraction correcte à une modification correctement acceptée.

Notre guide sur la préparation des commandes PDF pour l’ERP explique le flux d’entrée. Ce contrôle des révisions en précise une exception importante.

Demandez un diagnostic Kaliits avec des versions anonymisées et la description de votre circuit de modification. Nous pouvons alors cadrer un test autour de la décision que votre équipe doit réellement prendre.