Le camion passe deux fois sur le pont-bascule, mais le service administratif reçoit une quantité nette calculée avec la tare de sa visite précédente. Les deux tickets existent et le numéro du véhicule paraît cohérent. L'erreur ne vient pas nécessairement de la mesure : le logiciel a associé deux passages qui ne décrivent pas le même transport.
Dans une carrière, une centrale ou un site de réception de matières, cette confusion peut déplacer une quantité dans le stock et créer une correction de facturation. Le risque augmente lorsqu'un camion revient plusieurs fois, que les tickets circulent par fichiers et que l'ERP reçoit une ligne sans les références permettant de reconstituer la visite.
En pratique, le dossier transmis doit relier une visite, ses deux pesées qualifiées et le sens du mouvement de matière. La plaque seule ne sélectionne pas la bonne tare. Nous allons reconstruire un chargement fictif de 17,28 tonnes, comparer huit décisions de rapprochement et définir ce que l'application doit montrer au poste de pesée comme au bureau.
Dawap intervient en développement web sur mesure pour ces parcours entre exploitation et gestion. Une application métier raccordée à votre ERP peut prolonger le logiciel de pesage existant lorsque vos contrôles de visite, vos référentiels ou vos décisions administratives nécessitent un traitement spécifique.
Anatomie d'une visite : le passage du camion ne suffit pas
Le dossier commence avant le calcul du net. Il rassemble le site, le véhicule attendu, le transport concerné, le client ou fournisseur et la matière. Les événements de pesée viennent compléter cette visite. Sans identité de visite, la recherche du dernier ticket du camion peut rapprocher un départ de l'après-midi avec une entrée du matin.
Conserver les identités de passage et de transport
Notre modèle proposé attribue une référence à la visite et conserve les identifiants fournis par le système de pesage pour les événements ou tickets disponibles. Une référence de véhicule permet de rechercher ses visites ; elle ne remplace pas leurs identités. Le connecteur garde aussi le site source, car deux installations peuvent utiliser la même numérotation locale.
Le transporteur peut effectuer deux chargements avec un véhicule identique dans la même journée. L'application doit montrer deux dossiers séparés, chacun avec les passages attendus et leur état. La personne au poste de pesée ne devrait pas devoir modifier la plaque pour contourner une règle qui interdit à tort la seconde visite.
Nommer le mouvement avant de choisir le calcul
Dans un chargement sortant, le camion entre vide et repart chargé. Dans une réception avec déchargement, il arrive chargé et repart vide. La différence entre les deux masses peut être identique ; le mouvement de matière ne l'est pas. Le dossier qualifie donc le sens prévu avant de préparer une écriture de stock.
Ces deux parcours sont les seuls simulés dans notre exercice. Pesées multiples, échanges de remorque, tare mémorisée autorisée et opérations combinées demandent d'autres règles. Les retenir pour revue au premier pilote évite de présenter un simple calcul de différence comme une procédure universelle de gestion du pont-bascule.
Pour qui adapter le logiciel de pesage à l'ERP
Les outils de pesage proposent déjà des parcours structurés. Avant de développer un écran supplémentaire, l'équipe vérifie si le logiciel installé sait conserver les visites, éditer les tickets et transmettre les données nécessaires à l'ERP retenu. Le besoin peut être résolu par paramétrage, module existant ou interface disponible.
Examiner les offres qui associent pesée et gestion
ADCI présente PESÉES pour les carrières, centrales et centres de recyclage, avec récupération des poids d'entrée et de sortie et liaison avec son ERP Solutions BTP. Le périmètre commercial annoncé constitue une piste d'équipement ; il ne démontre pas une interface générique avec tous les ERP.
Okapia décrit un module de pont-bascule qui associe double pesée, calcul du net et tickets à des références de client, chantier, transporteur et matière. Ces fonctions déclarées doivent être examinées sur le contexte de l'entreprise, sans déduire d'une page de présentation les modalités d'accès à ses données.
Développer la décision manquante sans recréer le pesage
Le sur mesure se justifie si une difficulté qualifiée demeure entre les outils accessibles : rapprochement multisite, référentiel ERP spécifique, file de dossiers à corriger ou approbation administrative particulière. Le dossier de cadrage nomme cette difficulté et les interfaces vérifiées. Une connexion qui n'est pas documentée reste une dépendance à lever avec le fournisseur.
Le logiciel de mesure conserve son rôle, ses documents et les contraintes qui lui sont propres. Le frontend proposé rend consultables les visites et leurs décisions ; le backend prépare les échanges de gestion autorisés. Le projet vérifie avec le fournisseur de pesage les limites de cette intervention, sans revendiquer une homologation de l'instrument ou du ticket.
Relier le ticket source à une donnée utilisable par l'ERP
Une image du ticket peut aider l'opérateur à comprendre un dossier, mais elle ne suffit pas à construire une donnée fiable. Le système de pesage peut proposer un export, un échange réseau, une API ou une interface particulière. La première vérification porte sur le moyen effectivement disponible, sa licence, sa documentation et les informations qu'il expose.
Lire le contrat de sortie au lieu de supposer un protocole
Un indicateur qui affiche une valeur ne garantit pas qu'il expose les visites et les tickets complets. L'inventaire distingue la mesure, sa qualification dans le logiciel de pesage et le document validé. Le contrat précise lequel de ces objets entre dans l'application, ainsi que son unité, son identifiant, son horodatage et son état accessible.
Le middleware conserve une référence vers la preuve source et une représentation normalisée pour les traitements métier. Un export remplaçant un fichier précédent nécessite une politique différente d'une suite d'événements identifiés. La capacité de relire les tickets manquants, de détecter une correction et de retrouver un lot doit être qualifiée séparément.
Conserver les valeurs reçues avant les conversions
Notre application proposée stocke la valeur source avec son unité, puis la conversion utilisée pour la commande ou la réception ERP. Le mapping relie également matière locale, article de gestion et site destinataire. Un nom ressemblant à un produit connu ne suffit pas à choisir une référence dans un autre catalogue.
Une ligne sans unité ou sans correspondance n'est pas rendue exploitable par une valeur par défaut. Elle rejoint une file de revue avec sa source et son motif. L'opérateur peut ainsi corriger le dossier attendu, tandis que le gestionnaire du référentiel décide de la correspondance, sans modifier les masses pour faire passer l'import.
Exemple concret : 17 280 kilogrammes ne représentent pas 17 280 tonnes
Les valeurs suivantes sont fictives et déjà qualifiées comme entrées de notre modèle. La masse du camion vide vaut 11 200 kilogrammes ; celle du camion chargé vaut 28 480 kilogrammes. La quantité nette calculée est donc 28 480 − 11 200 = 17 280 kilogrammes, soit 17,28 tonnes.
Séparer le poids net de son usage commercial
Pour un prix net fictif de 86,50 euros par tonne, le calcul donne 17,28 × 86,50 = 1 494,72 euros. Le modèle ne calcule ni taxes, ni remises, ni humidité, ni réfaction de qualité, ni frais de transport. Ces composants restent à définir avec les équipes qui portent les règles commerciales et la gestion.
Par exemple, transmettre la valeur 17 280 dans un champ ERP interprété en tonnes produit un résultat mille fois trop élevé. Le contrôle compare donc la dimension de la quantité, l'unité cible et la conversion, puis le montant. Un arrondi monétaire correct ne répare pas une quantité exprimée dans la mauvaise unité.
Le même net peut conduire à deux mouvements opposés
Pour le chargement sortant, le modèle propose une sortie de 17 280 kilogrammes. Pour le déchargement entrant, il propose une entrée de la même quantité. Le signe interne retenu dans notre exemple sert à distinguer les deux décisions ; il n'est pas annoncé comme le format natif d'une écriture dans un ERP particulier.
Paradoxalement, la soustraction peut être juste alors que la décision de stock est inversée. Utiliser systématiquement la valeur absolue des deux masses supprime l'information qui permet de détecter un parcours incohérent. Le contrat vérifie le sens de la visite et les phases attendues avant de sélectionner le calcul applicable.
Exercice de rapprochement : huit visites proposées au bureau
Les huit cas du tableau sont exécutés hors connexion sur des événements normalisés et un reçu local fictif. Ils éprouvent une politique de rapprochement, sans lire un indicateur, qualifier une mesure physique ou créer un mouvement dans un ERP réel. Aucun compte transporteur ni document client n'est utilisé.
| Cas | Visite proposée | Contrôle du dossier | Décision du modèle |
|---|---|---|---|
| A | Réception, 28 480 puis 11 200 kg | Même visite, deux phases qualifiées | Préparer une entrée de 17 280 kg |
| B | Chargement, 11 200 puis 28 480 kg | Sens sortant documenté | Préparer une sortie de 17 280 kg |
| C | Même camion, visites différentes | Identités de visite incompatibles | Retenir le rapprochement |
| D | Deux entrées sans départ | Phase de sortie absente | Attendre le second passage utile |
| E | Masse reçue sans unité | Conversion non qualifiable | Demander la donnée manquante |
| F | Ticket transmis une seconde fois | Contenu identique au reçu local | Rattacher le résultat déjà connu |
| G | Ticket corrigé après transmission | Masse différente du contenu reçu | Faire examiner la correction |
| H | Matière sans référence ERP | Aucune correspondance autorisée | Retenir pour revue du catalogue |
Les scénarios C et D empêchent une soustraction trompeuse
Le scénario C conserve une référence de véhicule identique, mais les pesées appartiennent à deux visites. Le rapprochement doit être refusé avant de calculer un net. Le scénario D fournit deux événements de la même phase ; choisir le dernier comme départ ferait disparaître une information manquante au lieu de résoudre le dossier.
Le bureau a donc besoin d'une décision par visite, avec le motif de retenue et la personne attendue. L'interface permet de rechercher le transport ou la pièce source, puis d'enregistrer une correction autorisée. Un bouton « forcer l'import » qui enlève les contrôles pour toute la population déplacerait la difficulté vers le stock ou la facture.
Les scénarios F et G séparent renvoi et rectification
Dans F, le registre fictif retrouve le contenu déjà reçu et sa référence de résultat. Aucun nouvel effet n'est proposé. Dans G, une masse a changé sous l'identité déjà traitée : la décision est retenue pour déterminer le traitement correctif. Le calcul d'un nouvel écart n'autorise pas, à lui seul, une seconde écriture.
Le modèle suppose ici que les preuves locales existent. Il ne démontre pas une création unique malgré des appels concurrents, ni une recherche aval disponible par référence externe. Ces garanties doivent être établies sur les interfaces du projet ; un résultat inconnu reste visible tant que l'effet ERP n'est pas retrouvé.
Décision : quelle retenue traiter au poste de pesée ou au bureau
Le poste de pesée doit permettre de poursuivre l'exploitation sans demander à l'opérateur de comprendre les formats ERP. Le bureau doit retrouver les visites qui nécessitent une décision. Les deux interfaces lisent le même dossier, avec des actions adaptées à leurs responsabilités et des états qui ne promettent pas un effet encore absent.
Montrer le passage attendu à l'opérateur
L'écran proposé distingue visite ouverte, première pesée qualifiée, second passage attendu et dossier transmis à la revue. Il montre le site, le transport et la matière assez clairement pour éviter la sélection d'un camion revenu avec une autre mission. Un événement reçu ne devient pas « commande ERP créée » sur cet écran.
Une procédure de secours doit être discutée avec le fournisseur et l'exploitation. Si une saisie manuelle est autorisée dans le parcours retenu, elle conserve son origine, son auteur et le contrôle exigé. La panne d'une liaison ne transforme pas une valeur tapée au clavier en mesure qualifiée par l'appareil.
Donner au bureau une action pour chaque retenue
La file administrative rassemble le motif, les références de tickets, les masses source, la conversion et la correspondance ERP recherchée. Le back-office permet d'affecter une responsabilité et de consulter la décision précédente. Les droits séparent la qualification d'une visite, la maintenance du catalogue et l'autorisation d'une correction après transmission.
- Visite incompatible : l'exploitation vérifie le transport auquel chaque passage appartient avant de refaire le rapprochement.
- Unité absente : le responsable de l'interface retrouve le contrat ou l'export source, sans supposer une tonne par défaut.
- Ticket déjà engagé : l'administration retrouve le reçu et l'état ERP avant de décider une correction ou un renvoi.
Conserver les tickets pendant une interruption de liaison
Le pont-bascule, le logiciel local, l'application et l'ERP peuvent connaître des interruptions différentes. Le dossier doit conserver ce qui est connu à chaque étape. Une visite achevée localement peut attendre son transfert ; une tentative envoyée peut attendre la preuve de son résultat aval.
Qualifier la rétention disponible sur le site
L'équipe vérifie où les données sont conservées, pendant combien de temps et comment elles peuvent être relues. Une architecture avec une queue de transfert n'établit pas à elle seule la durabilité du logiciel de pesage. Le contrat du pilote documente les dépendances entre le poste local, le stockage source et l'application serveur.
Le traitement garde l'identité des lots et des dossiers, avec les refus séparés des tentatives à reprendre. Une visite retenue pour mauvaise unité n'est pas un simple échec réseau. La journalisation doit permettre de retrouver l'entrée concernée, la sortie préparée et la responsabilité de résolution sans exposer inutilement les autres transports du site.
Retrouver les effets connus avant la remise en route
Lorsqu'une réponse manque après envoi, le registre conserve l'incertitude. Le monitoring distingue les dossiers jamais envoyés, ceux dont un résultat est connu et ceux qui exigent un rapprochement. La stratégie d'idempotence est vérifiée avec l'équipe ERP ; elle ne se résume pas au réemploi d'un numéro de ticket local.
La reprise commence sur une population définie et consultable. L'application peut préparer un relevé d'écarts, puis autoriser les transmissions qualifiées selon le seuil convenu. Rejouer tous les tickets depuis le début de la journée risquerait de reproduire des effets déjà réalisés et d'encombrer la file des corrections.
Plan d'action : éprouver une voie de pesée avant la généralisation
Le premier périmètre comporte un site, une famille de matières et un parcours de visite défini. L'exploitation décrit les passages ; le fournisseur précise les données disponibles ; l'administration qualifie les mouvements attendus. Dawap conçoit l'application et ses échanges, tandis que le partenaire ERP vérifie les objets cibles et les effets de gestion.
Observer les rapprochements sans créer de mouvements
Une première passe lit des données autorisées et prépare les résultats sans écriture ERP. Les dossiers sont comparés avec les visites contrôlées par l'exploitation. Le pilote inclut un camion revenu plusieurs fois, une pesée manquante, deux sites avec le même numéro local, une correction et une interruption de transfert.
Le contrat de recette exige une décision explicable pour chaque cas : dossier retenu, net préparé ou résultat déjà connu. La comparaison porte sur les références de visite, les unités et le sens du mouvement avant les montants. Une seule association entre deux visites incompatibles doit suspendre la transmission du périmètre concerné jusqu'au diagnostic.
Mesurer la charge de recherche au bureau
Dans une hypothèse illustrative, quinze dossiers demandent chacun huit minutes de recherche de tickets et six minutes de vérification avec le poste. La charge vaut 15 × (8 + 6) = 210 minutes, soit trois heures et demie. Cet exemple constitue une manière de chiffrer le coût caché, sans annoncer un gain mesuré chez un client.
Le suivi réel sépare temps de recherche, revue du catalogue, correction de visite et résolution d'un résultat ERP inconnu. La priorité est de réduire les dossiers impossibles à expliquer. La performance du backend et le confort du frontend comptent ensuite dans l'architecture, lorsque les contrôles permettent déjà de transmettre les bonnes quantités.
Erreurs fréquentes : rapprocher par camion, contrôler par total
Confondre une visite ouverte avec la dernière tare disponible
Un premier signal faible apparaît lorsque les corrections se concentrent sur les véhicules qui reviennent souvent. Le calcul peut réutiliser une tare précédente sans conserver la décision qui autorise cet usage. Le diagnostic examine les visites sélectionnées et la règle de tare, plutôt que conclure immédiatement à une dérive du pont-bascule.
Un second signal apparaît lorsque les masses sont cohérentes sur le ticket, mais les quantités ERP changent d'ordre de grandeur. L'unité, le facteur de conversion et le champ destinataire doivent être rapprochés. La correction porte sur le mapping qualifié ; modifier la masse source effacerait une partie de la preuve nécessaire à l'enquête.
Présenter une importation réussie comme une visite acceptée
Un fichier reçu ou une requête HTTP acceptée ne démontre ni le bon rapprochement des passages ni l'effet dans la gestion. L'écran doit distinguer ces étapes. Le seuil de disponibilité du service ne remplace pas le contrôle du dossier, et un résultat calculé en mémoire n'établit pas la persistance de la décision.
Enfin, la réimpression d'un ticket ne signifie pas nécessairement une nouvelle visite. Le système conserve l'identité et le contenu reçu pour déterminer s'il s'agit d'une copie, d'une correction ou d'un autre transport. Le support peut ainsi expliquer la retenue sans demander à l'utilisateur de changer artificiellement la référence pour recommencer.
Guides complémentaires : mode observé, données reprises et travail local
Le dossier de pesée traverse des décisions de migration, de rétention et d'exploitation qui dépassent la soustraction des masses. Les ressources suivantes approfondissent ces contrats, en gardant la visite et les tickets comme preuves spécifiques du parcours étudié.
Comparer la nouvelle décision sans répéter les effets
La méthode du shadow traffic sans effet de bord aide à cadrer une comparaison entre un système existant et sa cible. Pour une visite de pesée, les deux décisions doivent lire les mêmes passages qualifiés, sans créer deux mouvements pendant la recette.
Le relevé de comparaison conserve les écarts d'identité, d'unité et de mouvement séparément. Deux résultats donnant le même net ne sont pas déclarés équivalents si l'un associe le mauvais transport. L'observation doit préparer une décision de mise en service, avec ses conditions d'arrêt.
Reprendre l'historique sans réengager tous les tickets
La reprise des données d'un logiciel métier distingue les populations, les transformations et leurs contrôles. L'historique de pesée peut servir à consulter une ancienne visite sans devoir créer à nouveau ses effets ERP.
Le périmètre importé doit donc préciser quels dossiers sont purement documentaires et lesquels restent réellement à transmettre. La présence d'un ticket ancien dans la nouvelle application ne constitue pas une instruction de stock ou de facturation à exécuter.
Suivre ce qui reste local après une coupure
Le parcours du compte rendu d'intervention hors ligne relié à l'ERP sépare sauvegarde locale, réception au serveur et acceptation par la gestion. Cette distinction aide à définir les états visibles d'un ticket en attente, sans transposer les capacités d'une application mobile au logiciel du pont-bascule.
Le stockage et la reprise du site doivent être vérifiés avec leurs propres interfaces. Un poste qui continue de produire des tickets pendant l'interruption nécessite une preuve de rétention et une procédure de rapprochement adaptée à ces documents.
Conclusion : une quantité nette doit raconter la bonne visite
Le bon résultat commence par les passages qui appartiennent au même transport. La différence des masses, leur unité et le sens de la matière donnent ensuite une décision utilisable par la gestion. Le camion reste une référence de recherche ; il ne remplace pas la visite qui justifie le ticket.
L'application doit conserver les données source et les effets connus pour que l'exploitation et l'administration puissent expliquer les retenues. Une pesée manquante, une matière inconnue et une réponse ERP perdue n'appellent pas la même action, même lorsqu'elles empêchent toutes le transfert du dossier.
La conception d'une application métier pour vos visites de pesée part du logiciel installé, de ses interfaces et de vos règles de gestion. Le premier pilote doit prouver le rapprochement d'une visite complète avant de multiplier les sites ou les parcours.
Dawap accompagne votre développement web sur mesure pour construire les écrans, les contrôles et les échanges avec l'ERP qui prolongent ce fonctionnement. Avec votre fournisseur de pesage et votre partenaire de gestion, nous cadrons les données disponibles et la décision que chaque équipe doit pouvoir retrouver.
