Page 1 of 1

Bug en Impression du plan comptable

Posted: 25 Dec 2021, 19:37
by jmpacquet
J'ai repris mes essais mais cette fois avec la version de développement 1.6 puisque maintenant l'initialisation de la base de données se passe bien et que l'importation du plan comptable est possible.
J'ai augmenté la largeur de la colonne Name de la table Accounts (256 au lieu de 50) et j'ai pu importer la totalité de mon plan comptable.
J'ai ensuite défini manuellement les journaux puis j'ai bricolé le fichier FEC exporté par OpenConcerto pour l'adapter aux contraintes d'importation d'écritures par Gestinux (le bricolage a consisté à mettre les colonnes dans l'ordre attendu, ajouter une colonne signe initialisée à 1 entre la colonne Débit et la colonne Crédit et à supprimer toutes les colonnes qui ne sont pas prises en compte par Gestinux).
J'ai pu importer la totalité des écritures après avoir défini l'exercice. Je peux visualiser les écritures dans le menu Ecritures et tout semble correct.

Quand j'ai essayé de visualiser les écritures d'un journal, ou une balance ou le grand livre, j'ai eu une erreur:

Une erreur imprévue est survenue.
Merci de la signaler en cliquant sur le bouton "Aide".

SQL Error: Unknown column 'CY.CountryCode' in 'on clause'

J'ai alors défini le pays (France) dans le menu Société mais ça n'a rien changé, j'ai toujours l'erreur.

RE: Bug en Impression du plan comptable

Posted: 25 Dec 2021, 23:30
by antoineL
jmpacquet wrote: 25 Dec 2021, 19:37 SQL Error: Unknown column 'CY.CountryCode' in 'on clause'
J'avais remarqué le même problème de temps en temps mais je pensais que c'était à cause de mes erreurs de construction de base. Il semble donc qu'il y ait un problème distinct.

CountryCode est un vieux champ de la version 1.4.
Dans la version 1.5, il a été remplacé par la table CountryCodes, et par un nouveau champ CountryId dans les autres tables.
Pour la version 1.6, conformément aux règles d'évolution de la structure de la base, le champ CountryCode a été supprimé de toutes les tables (c'est pour cela que cela marche en version 1.5).
Sauf que...
Sauf qu'il semble qu'une relation dans unitcompany.lfm continue à utiliser (dans object Query: TGQuery[2], objet parent de toutes les QueryXxx, pour la propriété SQL) le vieux champ :(

A priori la solution est simple comme remplacer (dernière ligne)

Code: Select all

LEFT OUTER JOIN Countries CT ON CT.CountryCode = CY.CountryCode AND...
par

Code: Select all

LEFT OUTER JOIN Countries CT ON CT.Id = CY.CountryId AND...
mais c'est juste en regardant le code, sans tester (trop loin de ma machine de développement).

Note: il faudra aussi rajouter une instruction dans _downgrade.sql pour peupler ce champ au moment de revenir en version 1.5.

RE: Bug en Impression du plan comptable

Posted: 26 Dec 2021, 11:14
by jmpacquet
Merci Antoine,
J'ai modifié la ligne 694 de unitcompany.lfm comme suit:
'LEFT OUTER JOIN Countries CT ON CT.CountryCodeId = CY.CountryId AND UserLanguage = :UserLanguage '
et je n'ai plus de message d'erreur.

Re: Bug en Impression du plan comptable

Posted: 26 Dec 2021, 18:09
by tintinux
antoineL wrote:Note: il faudra aussi rajouter une instruction dans _downgrade.sql pour peupler ce champ au moment de revenir en version 1.5
[réponse trop hâtive modifiée]
On doit utiliser _downgrade.sql seulement dans des cas particuliers qui pour l'instant ne surviennent pas avec la version trunk (exemple: modification d'index primaire).
Normalement, un champ inutilisé dans une version N est supprimé seulement dans la N+1 et on continue à le mettre à jour dans la version N même si il n'y est pas fait référence pour assurer la compatibilité descendante vers la N-1, sans avoir besoin du script.
Mais dans le cas de CountryCode, j'ai dû oublier dans la 1.5 (et cela vient d'être fait dans la trunk) de ne plus y faire référence dans UnitCompany.lfm.
Il faut donc le conserver et le mettre à jour encore pendant la version trunk.


Avec la calamiteux changement dans MySql qui oblige à spécifier tous les champs dans les INSERT, on va devoir supprimer explicitement les champs obsolètes (dans le DataModule ET dans le UnitCheckDatabase.DropOld de la N+1, comme indiqué ci-dessus). Cela empêche de les laisser mourir et de ne les supprimer sous SQL que pour vérifier qu'ils ne sont plus référencés. Cela rend plus difficile les évolutions.

Re: Bug en Impression du plan comptable

Posted: 26 Dec 2021, 18:22
by tintinux
jmpaquet wrote:j'ai bricolé le fichier FEC exporté par OpenConcerto pour l'adapter aux contraintes d'importation d'écritures par Gestinux (le bricolage a consisté à mettre les colonnes dans l'ordre attendu, ajouter une colonne signe initialisée à 1 entre la colonne Débit et la colonne Crédit et à supprimer toutes les colonnes qui ne sont pas prises en compte par Gestinux).
Normalement, le module d'importation permet d'éviter ce bricolage et les contraintes dont tu parles n'existent pas . On peut spécifier l'ordre des colonnes à importer (drag & drop), les colonnes à initialiser de manière fixe, (clic droit) et les colonnes à ignorer.

L'objectif est de pouvoir tout définir dans un fichier de paramètrage d'importation propre à chaque logiciel importé. Tu devrais pouvoir le faire pour OpenConcerto, comme c'est déjà fait pour plusieurs autres progiciels et disponible sur SourceForge, et on pourra téléverser ce paramétrage et un exemple. Ou sinon, envoie un exemple de FEC OpenConcerto anonymisé et je tâcherai de le faire moi même.

Re: Bug en Impression du plan comptable

Posted: 26 Dec 2021, 18:37
by tintinux
jmpaquet wrote:J'ai modifié la ligne 694 de unitcompany.lfm comme suit:
'LEFT OUTER JOIN Countries CT ON CT.CountryCodeId = CY.CountryId AND UserLanguage = :UserLanguage '
Merci ! La modification a été remontée dans SVN !

Re: Bug en Impression du plan comptable

Posted: 26 Dec 2021, 22:36
by jmpacquet
Le fichier FEC est normalisé, les colonnes sont imposées:
https://www.legifrance.gouv.fr/codes/ar ... 027804775/
donc ça devrait être le même ordre pour les colonnes, quel que soit le logiciel de compta.
Comme tous les logiciels de compta doivent pouvoir exporter les écritures au format FEC, il me semble que c'est maintenant le seul format dont on a besoin (en France) en importation d'écritures.

Re: Bug en Impression du plan comptable

Posted: 27 Dec 2021, 14:56
by tintinux
Ah oui, évidemment, je n'avais pas lu que c'était un fichier FEC.
Il faut donc faire un paramétrage pour lire ce format (qui est aussi produit par Gestinux)

Quant à espérer que ce format suffira, ça je ne sais pas...
Il y a sûrement des vieux logiciels qui ne produisent pas ce format, et c'est surtout ceux-là qui sont susceptibles de migrer...