CeQuEstUnLogicielDeComptabilité

Les spécifications fonctionnelles d'un logiciel de comptabilité

Obligatoires

Quelles sont les principales fonctionnalités qu'on est en droit d'exiger pour des raisons légales, opérationnelles, pratiques...

• La comptabilité en partie double
• Le plan comptable général (implémenté ou implémentable facilement sous forme de "modèle")
• Validation par des experts du métier de la partie fonctionnelle : ordre des experts comptables
• Module de validation des comptes ( BCO nulle si comptabilité en partie double )
• Calcul des régularisations de la TVA
• Trésorerie
• Support des normes IFRS

Spécifications techniques d'un logiciel de comptabilité

Les qualités techniques applicables (ou non) à un logiciel de comptabilité

Obligatoires

• Multi-utilisateurs
  • Gestion des autorisations des utilisateurs
  • Gestion de l'authentification des utilisateurs
  • Single Sign On

• Multi-plateformes / portabilité
  • GNU/Linux & Linux
  • Mac OS X
  • Microsoft Windows
  • FreeBSD, NetBSD, OpenBSD

• Disponible sous forme de paquets installables ( RPM, DEB, PKG, MSI, ... )
  • installable facilement (idéalement en "un click")

• Modulaire, y compris la "logique métier" extensible par greffons ( plug-ins )

Souhaitables

• Compatibilité POSIX

• Format XML pour l'échange de données et les fichiers.

• Greffons de sécurité (SSL, certificats, PKI, biométrie, carte à puce ...)

• Possiblité d'être alimenté par des outils tiers

• Mono-poste ou multi-postes

• Architecture n-tiers de type : Client Web + Serveur Web + Serveur d'applications "métier" + Client & serveur SGBDR et/ou LDAP + identification sécurisée type Kerberos + Interface possible avec des clients non web

À étudier

• Couplage avec un système d'archivage sauvegarde
  • Réseau dédié AAN : Accounting Area Network
• AOM : Accounting Object Model

Le cas particulier des T.P.E.

Si l'on décrit rapidement une T.P.E., on trouve en général :

• un professionnel actif, désireux de « savoir où il en est » sur le plan de la santé de son entreprise mais pas forcément versé en comptabilité ;
• un expert-comptable (rendu nécessaire par l'adhésion à une association agréée), pour qui l'entreprise est un petit client ;
• des institutions (fisc, U.R.S.S.A.F.) auxquelles sont dues régulièrement des sommes parfois difficiles à anticiper.

Les fonctionnalités-types d'un logiciel comptable pour T.P.E. seraient donc notamment :

• une saisie simple en achats/ventes ;
• une imputation automatique de la T.V.A. (très gros manque des logiciels de tenue de compte) avec :
  • plusieurs taux de T.V.A.,
  • une saisie indifféremment en H.T. ou T.T.C. avec changement à la volée ;
• une affectation analytique par domaine de dépenses/recettes ;
• un import des principaux formats de relevés bancaires ;
• un rapprochement aussi automatique que possible pour le pointage des relevés ;
• un export dans les principaux formats utilisés par les logiciels comptables ;
• un tableau de bord mentionnant :
  • la trésorerie brute,
  • la T.V.A. due par taux,
  • les cotisations sociales prévisibles,
  • la trésorerie nette,
  • le résultat en cours,
  • le niveau d'impposition prévisible (en I.R.P.P. ou en I.S.),
  • le bénéfice annuel net en cours.

Les autres fonctionnalités souhaitables :

• un système de calcul de frais kilométriques (par exemple par simple saisie mensuelle des compteurs des véhicules) ;
• l'affichage parallèle de plusieurs modes de calcul pour les frais automobiles (réels ou forfait kilométrique) ;
• l'affichage parallèle de plusieurs modes de calcul pour les frais de repas (réels ou forfait kilométrique), avec la description de la semaine-type en nombre de repas pris par jour et le décompte des jours de congés/maladie ;
• le remplissage automatique de la déclaration trimestrielle de T.V.A. (selon le mode d'imputation) ;
• l'impression de chèques ;
• idéalement, une facturation très simple engendrant du format PDF (pour l'expédition aux clients par courriel) ;
• l'interfaçage avec Net-entreprises (oui, je sais :-(().

Considérations diverses autour de la comptabilité dans un contexte informatique

Généralités

• Une écriture est toujours tracée dans le journal comme un processus pour "syslog".

• Une écriture ne devrait pas pouvoir être annulée autrement qu'avec une autre écriture en sens inverse.

• Etudier la possibilité de faire une compta intelligente qui évite toute opération qui peut être faite à partir de la saisie initiale. Exemples : charges constatées d'avances; traitement des immobilisations, des contrats de crédit bail et de location financement et des contrats de location longue-durée avec leur traitement fiscal particulier (y compris taxe professionnelle).

• Etudier la possibilité du traitement de l'information de base sans préjuger de son traitement lors de la présentation des comptes afin de pouvoir garder intacte toute l'information utile à divers modèles comptables (IFRS, PCG, UK GAAP ...)

• Solder un compte revient à passer une écriture remettant la balance du compte à zéro comme le ferait un "logrotate".

• Faire la balance des comptes revient à calculer les montants à fournir pour solder tous les comptes comme le ferait un "logcheck" par analogie.

• La clôture d'un exercice revient à clore / fermer / terminer / poser-une-cloture-autour un exercice pour l'archiver (genre sauvegarde des archives syslog sur un CD-R, et dans notre cas l'ar(rêté comptable?) ).

• Le modèle relationnel est insuffisant pour opérer
• La sémantique SQL est inadaptée
• Une modélisation "objet pure" ( au travers d'une modélisation "sémantique" de la comptabilité ) est nécessaire pour éviter les catastrophes du code spaghetti.
• Le code doit être adaptable.
• Le code doit être optimisé uniquement pour la lisibilité et la stabilité, et non pour la vitesse

• Il ne faut travailler qu'en bigInt

Modèles applicatifs et autres guides spirituels ( à faire ou ne pas faire )

• Analogies
  • syslog/logrotate/logcheck
  • LDAP/SNMP

• Bonnes idées
  • Lire http://www.logreport.org/

De la modélisation

Avoir quelque chose d'exploitable tout de suite n'est pas une mauvaise idée mais présente le risque de l'usine à gaz faute de modelisation ( cf le noyau linux ).

Avoir quelque chose de super-modélisé et prendre son temps pour y arriver, c'est prendre le risque d'une usine à gaz de modélisation et rien de bien fonctionnel ( cf hurd ) dans un délai "informatique" habituel.

Un compromis est envisageable à travers le travail autour des fonctionnalités nécessaires pour les utilisateurs.

Spécifications

• Multi-utilisateurs : gestion des permissions + stockage ACID
• Multi-sociétés : consolidation/intégration pour les groupes
• multi-devises : gestion de la perte au change à l'instant
• Une lib/protocole : une interface uniforme et normée de manipulation
• Générateur d'état : cf BO/Cognos/CR/Excel
• Workflow métier : adapté/adaptable au fonctionnement de l'entreprise
  • pouvant supporter les processus qualité tel que défini par la norme ISO 9000
• à-la-LDAP : modèle d'arbre extensible/paramétrable
• à-la-syslogcheck : stockage de type moteur d'ajournement

De l'avantage de l'arbre de consolidation geré nativement par l'outil

• A la racine de l'arbre, la balance est toujours nulle.
• Les vues par pseudo-arbre donneront toujours : Dette + Situation - Actif = 0

• Coût de calcul d'une fermeture transitive beaucoup plus supportable que dans le modèle SQL (SGBDR)

• L'approche du stockage dans un arbre équilibré possède l'avantage suivant ( une des "killing features" ) :
  • pour le calcul du bilan, quand on évalue les capitaux propres ( solde des comptes 101 - 108 - 1013 - 104 - 105 - 107 - 1061 - 1063 - 1062 - 1064 - 1068 - 11 - 12 - 13 - 14 ), il suffit de lire 15 comptes tels quels, plutôt que de faire des SELECT SUM avec des contrôles opérationnels déficients (aka : foireux, à la mord...)