Importation du plan comptable

[jmpacquet]

Impossible d'importer un plan comptable ne comportant que deux colonnes (le numéro de compte et le nom du compte)

compte non valide à la ligne 1. Une contrainte n'est pas vérifiée :
SQL Error: Column 'ANouveau' cannot be null
Voulez-vous ignorer et continuer ?

[jmpacquet]

Après avoir modifié la colonne ANouveau dans la table Accounts pour qu'elle puisse être nulle, j'ai repris l'importation.

Autre problème à la ligne 15:
(1064,Réserves réglementées)

compte non valide à la ligne 15. Une contrainte n'est pas vérifiée :
SQL Error: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '' at line 1
Voulez-vous ignorer et continuer ?

[tintinux]

Après avoir modifié la colonne ANouveau dans la table Accounts pour qu'elle puisse être nulle, j'ai repris l'importation.

Même si ça débloque ici la situation, il faut éviter de modifier la structure de la base de données.
Si le champ reste NULL, ça risque de donner des comportements imprévisibles ensuite...

Il est exact que la page de documentation à ce sujet est erronée, ce champ n'est pas optionnel dans une importation.

• Soit on fournit une valeur pour le champ "a nouveau", égale à la valeur vraie pour les comptes de bilan et à la valeur fausse pour les autres.
• Soit on définit la valeur par défaut 0 pour tous les comptes dans les règles d'importation (par clic droit sur la colonne), et ensuite on utilise le script fourni pour mettre à 1 les comptes de bilan de classe 1,2,3,4,5.

[tintinux]

Pour le second souci, ça ressemble fortement aux bugs lors de la création des pays et des reports.
C'est la même erreur pas du tout explicite qui est retournée.
Est-ce qu'il n'y aurait pas des caractères parasites dans le fichier en entrée ?

[jmpacquet]

Non je ne crois pas qu'il y ait des caractères parasites mais je vais chercher pourquoi ça coince précisément à cet endroit.

Une question bête: pourquoi n'y-a-t-il pas de plan comptable défini par défaut? C'est le 4e logiciel de compta que je teste, c'est le premier sans.

[tintinux]

En général, les nouveaux utilisateurs ont déjà une comptabilité existante, avec un plan comptable existant et propre à leur(s) société(s).
Les comptes de tiers, par exemple sont spécifiques, et souvent il y a des usages particuliers de certains comptes qui ne conviennent pas à tous.

Pour une nouvelle société, il faut tenir compte du pays et dans certains pays on a le choix entre différents plans comptables de base.

Il existe cependant des fichiers prêts à importer sur SourceForge permettant d'obtenir un plan et des journaux arbitraires, qui peuvent servir à certaines sociétés françaises. Ils s'importent en quelques clics, et cela ne semble pas difficile.

Personne n'a développé la possibilité que cet import soit davantage automatisé.
Il faudrait se connecter en ftp à SourceForge après avoir choisi le plan à importer.
Mais si tu veux le faire, tu es le bienvenu !

[antoineL]

Une question bête: pourquoi n'y-a-t-il pas de plan comptable défini par défaut? C'est le 4e logiciel de compta que je teste, c'est le premier sans.

En France il y a trois plans comptables (officiels) qui peuvent être utilisés. Je passe sur le plus complet, le plan développé, qui n'est pas adapté aux entreprises susceptibles d'utiliser Gestinux. Reste donc le plan de base et le simplifié. Le premier comporte 486 comptes, classes et regroupements, le second 104 comptes et 8 classes. Il y a comme un écart... À partir de là, il y a deux stratégies possibles pour monter son plan comptable:

• On part du plan de base tel quel, et on essaie de mettre les opérations dans les bons comptes; avec autant de comptes, les non-spécialistes passent beaucoup de temps à parcourir la liste (le web que j'ai lié au-dessus est ÀMHA un des moyens les plus pratiques que j'ai trouvé pour ce faire). De plus, naviguer une liste de plusieurs centaines de comptes n'est pas très ergonomique, même (surtout?) si dans la pratique on se sert occasionnellement d'une vingtaine ou une trentaine d'entre eux.
• On part du deuxième, et en conformité avec l'esprit et la lettre du PCG, on ouvre des comptes supplémentaires quand le besoin se fait sentir; par exemple, avoir plusieurs banques, différencier les charges dans la classification classique à trois chiffres 61x ou 62x, vouloir différencier entre plusieurs canaux de ventes différents, différencier certains fournisseurs en fonction de la manière de les payer, ou ouvrir deux comptes pour chaque immobilisation sont les options les plus évidentes qui me viennent à l'esprit, dépendantes évidemment beaucoup des nécessités de chacun. Évidemment (et ce n'est pas intuitif), cette option nécessite d'avoir plus de connaissances en comptabilité que la première.

Les logiciels que j'ai vu jusqu'à maintenant, et pour le peu que je connaisse de cette profession, aussi les experts-comptables, ne considèrent que la première option. Les premiers probablement pour faciliter la courbe d'apprentissage, les seconds pour se faciliter le travail (car eux connaissent bien la liste de 486 comptes). Je trouve que la direction qu'a prise Tintinux est plus intéressante, car elle offre le choix entre les deux options. De plus, elle oblige dès le début à se frotter à l'interface des importations, qui va servir plus tard de façon récurrente pour les rapprochements bancaires (il y a peut-être d'autres raisons).

Cela étant, si c'est juste pour un problème de disponibilité des informations, j'ai les listes des comptes de deux systèmes (et aussi du plan espagnol, qui a aussi différentes versions, même si l'écart est beaucoup plus réduit) que je pense pouvoir organiser pour créer des packages à distribuer, et il ne devrait pas être difficile de prévoir un système pour distribuer les plans de comptes avec le logiciel (dans un répertoire imports/). Je dois cependant vérifier qu'il n'existe plus de limitations légales de droits pour redistribuer ces listes.

Au sujet des comptes, j'ai aussi une requête à faire : la liste légale des libellés de comptes français (qui sont plus ou moins obligatoires) comprend parfois plus de 100 caractères (exemple au hasard, 781, «Reprises sur amortissements, dépréciations et provisions (à inscrire dans les produits d'exploitation)», qui est dans le plan abrégé; ou 205, «Concessions et droits similaires, brevets, licences, marques, procédés, logiciels, droits et valeurs similaires», 112 caractères avant codage UTF-8). Clairement, les 50 caractères (octets?) prévus par Gestinux sont un peu courts.

[jmpacquet]

Ce qui me paraîtrait bien, c'est d'avoir le choix, quand on paramètre le logiciel, entre le plan de base, le plan simplifié et l'importation. Et pas question d'aller chercher les plans par ftp sur Sourceforge, les plans doivent faire partie du package.
Sinon je plussoie Antoine: les libellés de compte devraient pouvoir dépasser 50 caractères. Dans le plan que j'essaie d'importer j'en ai qui dépassent!

[jmpacquet]

Il y a définitivement un problème de caractères dans cette erreur: il bloque sur "1064,Réserves réglementées". Si je supprime le "é" de la fin et donc que j'ai "1064,Réserves réglementes", cette ligne passe sans problème et il bloque alors sur "142,Provisions réglementées relatives aux immobilisations". On dirait que le mot "réglementées" ne passe pas!
J'ai vérifié qu'il n'y avait pas de caractères parasites avec un hexdump.

[antoineL]

Et pas question d'aller chercher les plans par ftp sur Sourceforge, les plans doivent faire partie du package.

@Tintinux: est-ce que si on distribue avec Gestinux un répertoire imports/ qui contienne

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

alors 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 ?

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 ?
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.