Import banque et fichier CSV

[superloupiot]

Bonjour,

J\'essaie d\'importer un fichier CSV dans le journal financier.
Ce fichier CSV est généré par la banque Dexia.

L\'import échoue, un message d\'erreur avec le contenu des champs apparaît.
Je pense que le format d\'import pour la banque dexia n\'est pas (ou plus?) compatible avec le fichier CVS importé.

@+

[Dany]

Oui, l\'import CSV est un cauchemar à maintenir : je n\'ai pas un compte dans chaque banque, donc je ne sait jamais si ce qui a été développé par qq\'un d\'autre fonctionne encore.

[superloupiot]

OK, et que comptes-tu faire?
Tu laisses tomber la fonction ou tu veux la maintenir?

Pourquoi ne pas demander à l\'utilisateur d\'associer la colonne du fichier CSV au champs que tu désires mettre dans la base de données plutôt que d\'essayer de prédéfinir un tas de format pour chaque banque?

[Dany]

Je pensais déplacer ça vers un plugin. Le problème avec les fichiers CSV, c\'est que chaque banque à sa propre conception du CSV, rarement il est standard, souvent il ajoute des + ou d\'autres signes, ou il faut transformer les virgules pas des points, les premières lignes sont souvent à ignorer...

Bref, on a du faire une procédure par banque, si on pouvait généraliser ça et le mettre en plugin, ce serait génial.

[superloupiot]

Je suis d\'accord avec toi pour la diversité des informations dans le fichier CSV.

Mais ici, j\'ai été voir le format attendu dans le fichier dexia_be.inc.php
J\'ai arrangé les colonnes dans l\'ordre attendu.
J\'ai également effacé tous les commentaires pour justement éviter les caractères spéciaux.
Donc je pense que le fichier CSV doit être propre maintenant.

Pourtant, j\'obtiens le message d\'erreur suivant:

insert into import_tmp (code, date_exec , date_valeur, montant, devise, compte_ordre, detail, num_compte, bq_account , jrn, status) values ( \'2\', to_date(\'05/05/2010\',\'DD/MM/YYYY\'), to_date(\'04/05/2010\' ,\'DD/MM/YYYY\'), -1000, \'EUR\', \'088-2573748-06\', \' \',\'063-0089547-67 \', \'BQ2\', 1, \'n\')latin1 SQL ERROR insert into import_tmp (code, date_exec , date_valeur, montant, devise, compte_ordre, detail, num_compte, bq_account , jrn, status) values ( \'2\', to_date(\'05/05/2010\',\'DD/MM/YYYY\'), to_date(\'04/05/2010\' ,\'DD/MM/YYYY\'), -1000, \'EUR\', \'088-2573748-06\', \' \',\'063-0089547-67 \', \'BQ2\', 1, \'n\') ArrayRollbacking : 2

0 operation(s) imported, 1 text or invalid line(s) skipped, 0 operation(s) skipped as already imported
Importation terminée

Il y a déja un problème avec la première ligne (SQL erreur).

La première ligne du fichier CSV contient ceci :
088-2573748-06;05/05/2010;2;063-0089547-67;;;;;04/05/2010;-1000;EUR

C\'est assez bizarre, j\'ai l\'impression que pour l\'instant le problème est ailleurs.

[superloupiot]

dany wrote:
[quote]Je pensais déplacer ça vers un plugin. Le problème avec les fichiers CSV, c\'est que chaque banque à sa propre conception du CSV, rarement il est standard, souvent il ajoute des + ou d\'autres signes, ou il faut transformer les virgules pas des points, les premières lignes sont souvent à ignorer...

Bref, on a du faire une procédure par banque, si on pouvait généraliser ça et le mettre en plugin, ce serait génial.[/quote]

Je pense que je ne passerais pas mon temps a essayer d\'être compatible avec plusieurs banques.
Je créerais plutôt une sorte de fonction d\'initialisation de la lecture du fichier CSV dans laquelle je demanderais à l\'utilisateur de faire le mapping entre les données attendues dans la base de données et le numéro des colonnes dans le fichier.

Par exemple demander à quelle colonne se trouve la date valeur, la date de comptabilisation de l\'opération, la valeur, la devise...

Plus quelques informations d\'ordre générales : nombre total de colonne, nombre de ligne d\'entête, valeur du séparateur de champs.

Avec possibilité de créer plusieurs profil : un profil par banque.

Je sauverais ces informations de mapping dans la base de données elle même.

Que cette procédure se trouve dans un plugin ou dans l\'onglet avancé, cela n\'est pas trop important.
Je pense que l\'important est que l\'utilisateur puisses lui même facilement renseigner la structure du fichier CSV.

[Dany]

Oui c\'est exactement le plugin que je voudrais faire, mais j\'ai pas mal de boulots pour l\'instant. Donc je ne promet pas de le faire ni quand.
L\'import de Banque vient d\'un utilisateur qui l\'avait développé pour lui, puis d\'autres ont ajouté leur banque... Et finalement personne n\'a eu envie de faire une procédure plus globale

[Dany]

Au fait, si je fais

Code : Tout sélectionner

demodossier16=# insert into import_tmp (code, date_exec , date_valeur, montant, devise, compte_ordre, detail, num_compte, bq_account , jrn, status) values ( \'2\', to_date(\'05/05/2010\',\'DD/MM/YYYY\'), to_date(\'04/05/2010\' ,\'DD/MM/YYYY\'), -1000, \'EUR\', \'088-2573748-06\', \' \',\'063-0089547-67 \', \'BQ2\', 1, \'n\') ;
INSERT 1569959 1

Cela fonctionne

[superloupiot]

Bon OK,

En attendant, j\'ai modifié le fichier dexia_be.inc.php pour pouvoir importer les fichier CSV.
Même si l\'import fonctionne, je n\'ai pas encore essayé le transfert.

Et j\'ai aussi remarqué que le bouton \"Effacer\" (je suppose pour effacer la ligne importée) supprime la ligne de l\'affichage, mais ne supprime pas la ligne de la base de données SQL. Cela posera problème plus tard parce que à chaque année, les numéros d\'extrait de compte sont réinitialisés et comme le filtre d\'import vérifie la présence de doublon, il y a certaines opérations qui ne seront plus importées.

Enfin, je pense que la fonction d\'import n\'est pas mature.

La création d\'un plugin ne me paraît pas facile car il faut interfacer les données importées avec les données de la base de données...

[Dany]

Oui effacer n\'efface que l\'opération du transfert, et donne un statut différent à la ligne. De cette façon, il suffit d\'ajouter une fonctionnalité \"purge\" pour effacer définitivement les lignes non transfèrables. Si la ligne reste c\'est pour éviter qu\'elle revienne lors d\'un second import. La clef primaire n\'est pas l\'extrait, chaque banque a sa propre recette donc les années ne comptent pas.

Un plugin serait plus simple, de plus tous les plugins utilisent la bases de données mais dans leur propre schema (voir doc -> extension)