Importation du plan comptable

[tintinux]

Est-ce que si on distribue avec Gestinux un répertoire imports/ qui contienne

plusieurs fichiers FR_PCG officiel_TOTO.ini chacun avec une section [Accounts] correctement documentée
les fichiers toto.csv correspondants extraits du dit Plan comptable général

Oui ça pourrait être une bonne solution.

l'importation du plan de compte sera-t-elle capable de gérer correctement la paramétrisation et de se comporter correctement le jour où l'utilisateur lambda, par erreur ou ignorance, tente de réincorporer de nouveau le plan de compte, voire d'en incorporer un autre ?

Les comptes doivent être uniques, donc on aura rapidement une erreur en important un compte déjà existant.
Mais si on importe 2 plans avec des comptes de longueur différente, ça va passer sans erreur et ça sera le bazard.
D'une manière générale je pense que les imports sont des opérations qui ne peuvent pas être laissées à un utilisateur lambda et requièrent de savoir ce qu'on fait et des sauvegardes préalables.

Alternativement, pourrait-on envisager un mécanisme générique dans les importations pour demander de façon lourdingue confirmation quand une importation doive se faire à destination d'une table qui ne soit pas préalablement vide ?

Il y a bien longtemps j'ai eu un utilisateur qu'on baptisait "OUI OUI", il répondait toujours OUI aux demandes de confirmation et faisait des dégâts régulièrement...

Ou peut-être une autre contrainte sous forme d'instruction SQL, par exemple au hasard aucun registre avec une date de valeur ultérieure à la date de clôture du journal, j'espère que vous voyez l'idée.

Oui ça serait bien, et atténuerait les risques, mais c'est du boulot à mettre au point...

[antoineL]

Mais si on importe 2 plans avec des comptes de longueur différente, ça va passer sans erreur et ça sera le [bazar].

Très bon point, auquel je n'avais pas pensé.

Les plans de comptes officiels ne sont pas formattés à X chiffres (du moins ni en France, ni en Espagne).
Ce n'est certes pas obligatoire d'utiliser un plan comptable systématiquement aligné à 6 ou 8 chiffres, mais c'est très commun et je suis sûr que certains cabinets comptables (ou peut-être leurs logiciels) vont insister là-dessus au point d'y obliger les utilisateurs Gestinux.

Je ne pense pas que ce soit facile de programmer une complémentation par programme à 6 ou 8 chiffres (au choix de l'utilisateur, et optionnellement) des comptes du PCG, le tout pour une utilisation one shot ; même si en fait c'est un UPTABLE SQL post-importation assez simple, et analogue à ceux pour ANouveau ou Reconciliation ; peut-être une piste à creuser..
Donc l'alternative serait d'avoir 6 modèles de plans FR (base ou abrégés, avec comptes hors en-têtes de longueur normale ou fixée à 6 ou 8 chiffres), autant pour l'Espagne etc. Cela ne me paraît pas vraiment raisonnable.

Il y a bien longtemps j'ai eu un utilisateur qu'on baptisait "OUI OUI", il répondait toujours OUI aux demandes de confirmation et faisait des dégâts régulièrement...

Code: Select all

REVOKE INSERT ON TABLE Accounts FROM "OUI OUI"

?
Plus généralement, cela pose le problème de faire des groupes d'utilisateurs, et le faire de manière ouverte à différents SGDB. Ok je sors

[jmpacquet]

J'ai réduit le fichier à importer à la seule ligne de 30 octets en utf-8 sans BOM:
1064,Réserves réglementées

en hexa:
~$ hexdump -C compteerreur.csv
00000000 31 30 36 34 2c 52 c3 a9 73 65 72 76 65 73 20 72 |1064,R..serves r|
00000010 c3 a9 67 6c 65 6d 65 6e 74 c3 a9 65 73 0a |..glement..es.|

et ça plante!

J'ai mis un stop à la ligne 452 de GDbConnectionBase ( Query.Sql.Add(aSql); ) pour examiner la requête SQL. Elle est tout à fait correcte:

INSERT INTO Accounts(Account,Name,Reconciliation,ANouveau,Header) VALUES ("1064","Réserves réglementées",NULL,NULL,NULL)

D'ailleurs si je la copie dans une requête SQL de phpMyAdmin, elle s'éxécute correctement et le compte est bien inséré dans Accounts.
Par contre si je laisse le programme poursuivre, j'obtiens le sempiternel message d'erreur.

Je laisse aux experts le soin de trouver l'explication, ça me dépasse!

Je rappelle que je n'ai fait que 2 modifications à la version 1.5 que je teste:
1. ligne 186 de unitimports.pas:
TabSheetSQL.TabVisible := true; // Datamodule1.Db.IsAdmin;
2. Changement de la colonne ANouveau de la table Accounts pour qu'elle puisse être NULL

[antoineL]

J'ai réduit le fichier à importer à la seule ligne de 30 octets en utf-8 sans BOM:
1064,Réserves réglementées

et ça plante!

J'ai mis un stop à la ligne 452 de GDbConnectionBase ( Query.Sql.Add(aSql); ) pour examiner la requête SQL. Elle est tout à fait correcte:

INSERT INTO Accounts(Account,Name,Reconciliation,ANouveau,Header) VALUES ("1064","Réserves réglementées",NULL,NULL,NULL)

D'ailleurs si je la copie dans une requête SQL de phpMyAdmin, elle s'éxécute correctement et le compte est bien inséré dans Accounts.
Par contre si je laisse le programme poursuivre, j'obtiens le sempiternel message d'erreur.

Je laisse aux experts le soin de trouver l'explication, ça me dépasse!

Pour essayer de coller au mieux à ta configuration, peux-tu indiquer:

• Version du client MySQL ou MariaDB
• Version de la base
• Version de ZeosDBO
• les variables $LC_ALL, $LANG ou peut-être $LC_CHARSET qui sont utilisées, tant par le processus gestinux comme par le processus serveur
• Tout contenu de /etc/my.cnf ou ~/my.cnf ou peut-être /etc/mysql/my.cnf et compagnie qui pourrait avoir un rapport quelconque avec les jeux de caractères

[antoineL]

[...] requête SQL. Elle est tout à fait correcte:

INSERT INTO Accounts(Account,Name,Reconciliation,ANouveau,Header) VALUES ("1064","Réserves réglementées",NULL,NULL,NULL)
[...]
2. Changement de la colonne ANouveau de la table Accounts pour qu'elle puisse être NULL

Comme tu le vois, il faut modifier l'importation pour arriver à ce que la requête soit

Code: Select all

INSERT INTO Accounts(Account,Name,Reconciliation,ANouveau,Header) VALUES ("1064","Réserves réglementées",NULL, 0, NULL)

Cela se fait dans la fenêtre d'importation, en forçant la valeur 0 pour la colonne ANouveau, c'est-à-dire le champ Bilan. Cela s'obtient en cliquant sur le champ Bilan, et en entrant la valeur 0. Tu verras alors s'afficher «Bilan [0]». Et la requête sera celle qu'attend la structure de la base de données.

[tintinux]

Tu peux attacher le fichier importé d'une ligne qui pose problème, et le fichier .ini dans lequel ont été sauvegardés les paramètres d'importation ?

Pour éviter des problèmes potentiels dans le futur, il serait aussi préférable que tu remettes le champ ANouveau en NOT NULL.

[jmpacquet]

Voilà les fichiers.

J'ai remis la colonne ANouveau comme elle était et j'ai fait un nouvel essai, avec le zéro là où il faut... avec toujours le même résultat d'erreur.

[jmpacquet]

Pour essayer de coller au mieux à ta configuration, peux-tu indiquer:

• Version du client MySQL ou MariaDB
• Version de la base
• Version de ZeosDBO
• les variables $LC_ALL, $LANG ou peut-être $LC_CHARSET qui sont utilisées, tant par le processus gestinux comme par le processus serveur
• Tout contenu de /etc/my.cnf ou ~/my.cnf ou peut-être /etc/mysql/my.cnf et compagnie qui pourrait avoir un rapport quelconque avec les jeux de caractères

Server version: 10.3.11-MariaDB MariaDB Server

ZComponent 7.2.14

/etc/my.cnf est vide!

Ce n'est pas un problème de character set: j'ai essayé avec un fichier en ISO-8859-15 avec le même résultat.

[tintinux]

Bonjour

Je reproduis bien le problème avec le ficher téléversé qui est pourtant apparemment parfaitement correct.
Les paramètres aussi sont bons, à part les champs booléens qui devraient avoir une valeur fixe ou être dans l'import, mais ça ne crée un souci que dans un second temps.

Mes variables système de configuration sont celles qui sont attendues (fr_FR.UTF8), et de toutes façons je ne vois pas en quoi elles pourraient avoir une influence puisque la base a été créée par Gestinux avec les propriétés qu'il faut indépendamment d'elles.

Pour moi, le souci est avec ZeosLib, puisque la requête générée fonctionne bien dans un autre client SQL sur les mêmes client et serveur.
Je suspecte un mauvais décodage/encodage de la requête ait été passée et qui ne se produit que rarement, avec certaines séquences de caractères.

Je vais essayer de recompiler avec d'autres versions de ZeosLib.

[jmpacquet]

Au cas où ça pourrait servir, je mets les fichiers iso-8859-15 qui plantent aussi