Erreur de Toolkit

Erreur Toolkit — ReserveCardNumber / PK_Number pendant la création client

Contexte : Acomba classique, ODBC, insertion d’un client; fil de janvier 2011.
Niveau de preuve : Cause de la première erreur confirmée; seconde erreur exclue faute de solution.

Recherche et variantes : ReserveCardNumber, PK_Number, Valeur invalide, CuNumber, CuName.

Solution documentée. Le demandeur reconnaît que des champs ont disparu de sa requête lors d’un copier-coller, notamment le numéro client. Leur rétablissement élimine cette première erreur. Une autre erreur de fiche détruite apparaît ensuite et n’est pas résolue dans le fil : elle ne doit pas être présentée comme réparée par la même opération. [S310]

Parcours proposé — ajouts éditoriaux :

1. Relever la fonction et le champ indiqués dans le message, pas seulement le mot Toolkit.
2. Comparer la création client au schéma de l’interface : identifiant et champs requis doivent être transmis explicitement.
3. Corriger sur une société de test, puis traiter toute nouvelle erreur comme un diagnostic distinct.

Précautions. Ne pas inventer de numéro client ni réutiliser une clé existante. Les propositions de Remonte du même fil ne résolvent pas son second incident et ne sont pas retenues.

Contrôle attendu. Contrôler que la fiche attendue est créée une seule fois et que ses informations ne remplacent pas un autre client.

Procédures internes

• ODBC Acomba : « Cette fiche est détruite »
• SDK Acomba — transaction non balancée / erreur Toolkit

Toolkit — ModifyCard, CuFax, valeur invalide : valider le champ réellement transmis

Contexte : Acomba classique, création/modification Customer par intégration ODBC/ADODB; janvier 2011.

Validation : Résolution confirmée par le demandeur dans son intégration; non reproduite ici.

Solution documentée

Le demandeur identifie finalement un fax à neuf chiffres là où sa fiche attendait dix chiffres. Il précise que le CuFax du diagnostic correspondait à CuPhoneNumber2 dans son interface. Les autres hypothèses sur la description du téléphone ou le type de l’identifiant n’ont pas été confirmées comme cause de ce cas.

Procédure et diagnostic proposés par Uni-Action

1. Relever ensemble la fonction, le champ et l’erreur, sans se limiter au mot Toolkit.
2. Dans une copie de test, comparer la valeur d’origine à celle transmise après les transformations du programme. Préserver la forme de l’anomalie lors de l’anonymisation.
3. Faire contrôler par le développeur le mappage du champ et les règles du schéma installé; arrêter l’import de cette fiche si la donnée est invalide.
4. Corriger à partir d’une information métier vérifiée, puis réessayer uniquement la fiche test.

Précautions

Ne pas inventer un chiffre, vider tous les fax ni changer les numéros de l’ensemble des clients. Les dix chiffres décrivent ce cas historique, pas tous les pays ou toutes les versions. Sauvegarde avant toute reprise d’écriture.

Contrôle

Relire la bonne fiche et contrôler le fax, les autres coordonnées et l’absence de doublon. Si le libellé change, ouvrir un nouveau diagnostic.

Limites

Le message conserve le champ historique CuFax pour la recherche. Aucune règle de validation téléphonique universelle n’est déduite.

Procédures internes

• SDK Acomba — erreur 3 : cette fiche n’est pas réservée
• Sauvegarde Acomba classique avant intervention
• Erreur Général ODBC