Comment PawnCounter lit n'importe quel export de caisse de prêteur sur gage
Les données d'un prêteur sur gage arrivent sous forme de fichier LeadsOnline, de table Visual FoxPro, de déclaration XML californienne ou de CSV que personne n'a jamais vu. Voici comment un seul lecteur les traite tous.
La partie difficile de l'analyse pour les prêteurs sur gage n'est pas l'analyse elle-même. C'est que chaque boutique vous remet un fichier différent, et la plupart des gérants ne savent pas dire lequel. La première règle que nous avons fixée pour le lecteur de PawnCountera été qu'il ne doit jamais demander à la boutique ce qu'est le fichier. Il le déduit à partir des octets.
Reconnaître le format
La détection s'effectue sur les 64 premiers Ko du fichier, avant toute analyse complète. Quelques vérifications suffisent dans la plupart des cas :
- Un en-tête DBF signale une table Visual FoxPro, c'est ainsi que WinPawn stocke ses données. Le nom de la table, ou à défaut ses noms de colonnes, indique laquelle c'est : reconnaissances de gage, marchandises, historique, achats à crédit.
- Une racine XML identifie CAPSS, le format de déclaration de la Californie, à part le service web de billets de LeadsOnline.
- Un CSV dont l'en-tête ne contient que les noms de colonnes LeadsOnline utilise (type de billet, numéro de billet, champs du nom du client, marque de l'article) est un export LeadsOnline, quelle que soit la caisse qui l'a produit.
- Un fichier texte à séparateur barre verticale dont Pawn Trackerla structure est celle de Pawn Tracker.
- Un registre d'armes à feu, un CSV d'acquisitions et de cessions, a sa propre signature et son propre lecteur.
Chacune de ces règles est une signature que nous avons vérifiée sur un échantillon réel de ce système ; la détection est donc déterministe et chaque branche dispose d'un test. Lorsqu'aucune ne correspond, le fichier est transmis au lecteur générique.
Le CSV que personne n'a jamais vu
Pawn Wizard, PawnSnap et une douzaine de systèmes plus petits exportent en CSV, et aucun ne nomme ses colonnes de la même façon. Plutôt qu'un adaptateur par éditeur, le lecteur générique fait correspondre les colonnes selon leur sens : une longue liste d'alias, comparés sans tenir compte de la casse et en ignorant espaces, tirets bas et tirets, détermine quelle colonne est le coût, laquelle le prix demandé, laquelle la date d'entrée et laquelle la description. Un fichier qui décrit des articles et des coûts est un inventaire ; un fichier qui décrit des reconnaissances de gage est un journal de transactions ; certains sont les deux, et dans ce cas les deux sont produits. Les colonnes qu'il ne peut pas placer sont ignorées plutôt que de faire échouer l'import, et tout ce qu'il a dû deviner remonte sous forme d'avertissement visible par la boutique. Il n'a pas besoin de connaître le système à l'avance, c'est pourquoi le guide « Tout autre POS » est une voie réelle et non un refus poli.
Un modèle d'article unique
Quelle que soit la source, chaque enregistrement est normalisé dans la même structure : un article avec une catégorie, une description, un coût, un prix demandé, des dates d'entrée et de sortie, et le prêt ou la vente auquel il appartient. Des règles complètent ce qu'un format laisse implicite, et une étape de réconciliation joint les tables qui décrivent différemment un même article. WinPawn est la raison de cette étape : sa table d'historique, la seule à contenir un prix de vente réel, enregistre une catégorie mais aucune description ; chaque article vendu arriverait donc sous « Armes à feu » ou « Outils », alors que le même numéro d'article dans la table des marchandises indique « Fusil à pompe Remington 870 ». La jointure sur le numéro d'article rend à la vente sa description, et avec elle la possibilité de comparer des éléments comparables. Les analyses ne voient jamais que ce modèle : une correction de la logique de décote s'applique donc aussi bien à une boutique WinPawn qu'à une boutique LeadsOnline.
Ce qu'il ne peut pas lire, dit clairement
Bravo, qui ne propose pas d'export en masse, est lu à partir des rapports qu'une boutique enregistre depuis ses écrans Report Preview ou Ad Hoc au format CSV ou Excel, en utilisant les intitulés de colonnes propres à Bravo (ajouté en septembre 2026). PawnMaster ne fournit pas aujourd'hui à une boutique d'export exploitable par nos soins. Plutôt que de faire semblant, le guide PawnMaster l'indique, explique quoi exporter avant tout passage à Bravo, et conserve ces fichiers pour le jour où un lecteur existera.
Le résultat correspond à ce que le produit promet sur sa page ici: gardez le POS que vous avez, envoyez le fichier qu'il produit déjà et récupérez le Profit X-Ray .