ERREUR de 10+ ans: Processus Transfert TFP a TFP - matricule mal saisie

EXEMPLE CI-JOINT CONTIENT DES INFO CONFIDENTIELLE - POUR GRICS SEULEMENT.

Tous les numéros de matricule comportent 18 chiffres + le code de la ville de 5 = 23 chiffres.

Le CSS a donc des dossiers avec des matricules à 23 chiffres. Pour une raison quelconque, le processus de transfert des informations relatives au certificat et au dépôt dans TFP ne saisit que 22 chiffres (voir les fichiers du bloc-notes). (Le fichier ETAL correspondant saisie les 23 chiffres.)

Lorsqu'il est téléchargé dans TFP de la SWL (ou de n'importe quel CS), TFP ajoute automatiquement un <0> au numéro de matricule pour qu'il soit composé de 23 chiffres.

Le numéro de matricule est donc modifié et le CS TFP ne peut pas reconnaître qu'il s'agit d'un de nos fichiers. Il crée donc un nouveau dossier.

Nous devons alors désactiver le nouveau fichier et apporter manuellement toutes les modifications au fichier approprié. Cela se produit CHAQUE fois qu'un dépôt ou un certificat affecte le fichier.

C'est un problème qui existe depuis au moins 10 ans, mais qui n'a jamais été aussi fréquent. En effet, les 8 derniers chiffres d'un matricule (annexe) sont souvent des 0. Cependant, maintenant qu'il y a de plus en plus de condominiums, etc., ces 8 derniers chiffres comprennent les numéros des condominiums/unités.

Voir l'exemple ci-joint.

Grande merci a Nancy Raby pour me donner une solution en attente que ca soit corriger car ca fait une bordelle de notre BD et BEAUCOUP de travail pour les CS.

N'hesites pas de me dire si je devrais mettre au section des billets.