Bonjour Stéphane,

Bon cela faisait une paye que je n'avais pas eu un souci avec Skrooge
Actuellement, je n'arrive plus à importer mon fichier au format OFX.
J'étais sous Kubuntu 20.04 et j'ai upgradé en 22.04.1 à la fin du mois d'août.
Automatiquement ma version de Skrooge est passée en 2.27 et sans soucis apparent de migration.
Au début de septembre, comme à chaque début de mois, je télécharge mon fichier OFX depuis ma banque (CA) et je lance l'import.
Skrooge me retourne l'erreur 5. J'ai essayé plusieurs fois, dont notamment en ne sélectionnant qu'un seul compte au lieu de tous, mais cela échoue à chaque fois.
J'ai vu que sur ton ppa il y avait une version 2.28. J'ai donc désinstallé la 2.27 et je suis passé à la 2.28 mais même punition.
J'ai contacté l'assistance de ma banque (ayant déjà eu ce type de pb avec des fichiers corrompus générés mais c'était avec une autre banque), mais l'assistante me rétorque que cela ne vient pas d'eux.
As-tu des remontées de bug sur l'import de fichier OFX en ce moment ?
As-tu une piste de solution ?
Merci.
Christophe

Bon même si je n'ai pas eu de réponse du fofo, j'ai effectué quelques tests.
Dans une machine virtuelle j'ai réinstallé à neuf un système Kubuntu 22.04.1 et Skrooge 2.27.0
Si je fais un import OFX de mes comptes dont les opérations sont datées avant le mois d'août tout fonctionne. A partir du moment où je fais une importation courant du 1er août au 31 août, l'importation échoue.
Pour récapituler les tests :
Importation OFX : 01/05/2022 - 31/05/2022 : succès (et avant cette date).
Importation OFX : 01/06/2022 - 30/06/2022 : succès
Importation OFX : 01/07/2022 - 31/07/2022 : succès
Importation OFX : 01/08/2022 - 31/08/2022 : échec
Importation OFX : 01/09/2022 - 28/09/2022 : échec
J'ai donc demandé à nouveau à ma banque de vérifier si le script de génération des fichiers OFX n'a pas subi une modification depuis le 1er août ou si avec la refonte de leur site à cette période un hiatus ne s'est pas glissé dans leurs variables.
A titre d'information cette mésaventure m'était déjà arrivée par 2x avec une autre banque (la Banque Postale pour ne pas la citer) et ils avaient résolue le problème rapidement. J'espère que cela sera le cas avec le CA...
J'attends leur nouvelle réponse, la 1ère fois ils m'avaient simplement expliqué qu'ils n'avaient pas eu de remontées de leurs clients à ce sujet et que donc cela venait de Skrooge...

Du nouveau et j'ai trouvé le problème du code OFX !!!
Donc je reprends :
Ma banque m'a informé que le blème ne venait pas d'eux mais de Skrooge.
Donc j'ai pris ma casquette de Sherlock Holmes et je me suis mis à la recherche du hiatus. Voilà méthodiquement comment j'ai procédé :
1) Sachant que seul les imports d'août et de septembre génèrent une erreur, j'ai décidé de saucissonner ces deux mois par tranche de 7 jours pour voir si j'arrivais à restreindre le champ d'investigation, et si la réponse est positive, je re-saucissonne dans cette tranche hebdomadaire en tranche quotidienne.
2) BINGO ! Effectivement, en agissant de la sorte j'ai dégagé 2 dates (1 en août et 1 en septembre). Mais ces dates contiennent malheureusement à chaque fois plusieurs opérations.
3) J'ai donc décidé d'aller regarder de plus près le code de ces 2 fichiers OFX (je n'y connais rien dans ce domaine). J'ai constaté que chaque opération était encapsulée entre les balises <STMTTRN> et </STMTTRN>. J'ai donc supprimé une par une les opérations de chez 2 fichiers puis procédé à chaque fois à un import sur Skrooge jusqu'à déterminer quelles opérations généraient l'erreur.
4) BINGO : Je retrouve 2 fois la même opération qui génèrent l'erreur 5. Sachant que cette opération bancaire avait été aussi effectuée en juillet et que cela ne suscitait pas d'erreur d'import, j'ai donc essayé de comparer les 3 opérations. Je me suis aperçu que le nom contenu dans la balise <NAME> et la suivante <MEMO> sont passés de la casse MAJUSCULE à la casse minuscule, soit initialement en juillet (et les mois précédant) :

Code: Select all

<NAME>WEB DURAND BOB taxe fon
<MEMO>VIREMENT EMIS WEB DURAND BOB OU taxe fon taxe fonciere

à (à partir d'août 2022 et suivant) :

Code: Select all

<NAME>WEB Durand Bob taxe fon
<MEMO>VIREMENT EMIS WEB Durant Bob OU taxe fon taxe fonciere

5) J'ai donc modifié la casse du fichier d'août en le remettant en majuscule et j'ai procédé à un import du fichier OFX ainsi modifié dans Skrooge et là Ô miracle cela fonctionne
Maintenant je ne sais pas si le changement typographique que j'ai détecté dans le code des fichiers OFX devrait être quand même normalement lu par Skrooge ou si c'est la banque qui ne respecte pas les conventions. Si Stéphane pouvait m'éclairer ?
Merci !

Bonjour,

L’interprétation de fichier OFX est faite par la librairie libofx https://github.com/libofx/libofx.
Vous pouvez vérifier si cette librairie fonctionne correctement sur votre fichier en utilisant ofxdump (il est normalement packagé sur toutes les distributions).
Si vous avez un problème avec libofx, il faudra ouvrir un bug sur cette librairie mais il me semble qu'il y déjà des tickets à ce sujets.
Cordialement.

Merci Stéphane et désolé pour ma réponse tardive.
Le package ofxdump n'est pas disponible sur ma distribution. Impossible à installer (Kubuntu 22.04.1 / Kernel 5.15.0-56) depuis le gestionnaire de paquets.
Pour info, mon problème est rentré dans l'ordre il y a peu car étonnamment le package OFX n'était pas installé !? (Je pensais que l'installation de Skrooge activait cette dépendance). Après l'installation (libofx (1:0.10.3-1)), je n'avais plus besoin de faire ma manip manuelle. Sauf que maintenant, si la casse ne pose plus de problème, l'accentuation des caractères oui ! Bref si le fichier OFX contient des "é", "à"... il faut les remplacer manuellement par son équivalent sans accent. On sauvegarde et on importe dans Skrooge.
Je donne l'info pour ceux qui seraient dans le même cas que moi...en espérant une nouvelle mise à jour prochaine