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