CeQuEstUnLogicielDeComptabilité

De April MediaWiki
Révision datée du 8 avril 2014 à 18:52 par Nathael (discussion | contributions) (→‎Le cas particulier des T.P.E.)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Aller à la navigationAller à la recherche

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), 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 :-(().

Il est à noter ici que le multi-postes n'est sans doute pas une priorité d'un tel logiciel.

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

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