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

A étudier

• Couplage avec un système d'archivage sauvegarde

  • Réseau dédié AAN : Accounting Area Network
• AOM : Accounting Object Model

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

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