Expertise 07 / 07

ERP & gestion

La comptabilité SYSCOHADA, la paie et le budget dans un seul système.

Prouvé sur :Sytium ERP

Depuis juillet 2024

  • SYSCOHADA
  • 277 modèles Eloquent
  • 139 migrations
  • RBAC
  • multi-organisations
  • partie double
  • piste d'audit

Les modules du système

277 modèles Eloquent, 139 migrations. Tous classés — la somme des modules tombe juste.

Entités du module

Comptabilité & finance

  • Account
  • AccountMovement
  • AccountingEntry
  • AccountingEntryLine
  • AccountingJournal
  • Charge
  • ChargePayment
  • CreditRequest
  • CreditRequestDocument
  • DividendForecast

et 21 autres

Simulateur d'écriture SYSCOHADA

Opération
TVA 18 %
180 000 F
Toutes taxes comprises
1 180 000 F

JournalACH · Journal des achats

Débit = Crédit
CompteLibelléDébitCrédit
601Achats de marchandises1 000 000
4452TVA récupérable sur achats180 000
401Fournisseurs, dettes en compte1 180 000
Total1 180 0001 180 000

Le contrôle d'équilibre a lieu à l'enregistrement, pas à la clôture : une écriture fausse se propagerait sinon dans tous les états financiers.

Plan d'amortissement

Durée d'utilité
Méthode
AnnéeTauxAnnuitéCumulValeur nette
120,0 %720 000720 0002 880 000
220,0 %720 0001 440 0002 160 000
320,0 %720 0002 160 0001 440 000
420,0 %720 0002 880 000720 000
520,0 %720 0003 600 0000

Le plan s'épuise exactement : la valeur nette finale est nulle.

Écriture de dotation, première annuité

CompteLibelléDébitCrédit
6813Dotations aux amortissements des immobilisations corporelles720 000
2841Amortissements du matériel de bureau720 000
Total720 000720 000
277
Modèles Eloquent
139
Migrations

Le mécanisme

Comment ça marche.

Organisation

discriminant sur chaque table

Pièce

facture · règlement · immobilisation

Journal

ACH · VTE · BQ · OD

Écriture

lignes en partie double

Contrôle

débit = crédit à l'enregistrement

États financiers

balance · grand livre · bilan

Piste d'audit

avant / après sur chaque mutation

Le cloisonnement se joue sur chaque requête.

Sur 277 modèles, une seule requête écrite hors du filtre global suffit à faire fuiter les données d'une organisation vers une autre. Le discriminant d'organisation est donc appliqué globalement, pas table par table, et couvert par des tests dédiés au cloisonnement — c'est le genre de faute qui ne se voit pas en recette et se découvre chez le client.

Une écriture fausse ne doit jamais être enregistrée.

Le contrôle d'équilibre a lieu à l'enregistrement de chaque écriture, pas à la clôture : sinon l'erreur se propage silencieusement dans la balance, le grand livre et le bilan, et se découvre des semaines plus tard. La contrepartie est assumée : une saisie partielle est impossible, l'écriture doit être complète pour exister.

Les arbitrages

Ce que j'ai écarté, et pourquoi.

Un choix technique sans son coût n'est pas un choix, c'est une préférence.

01

Comment garantir le cloisonnement entre organisations ?

Le problème

Un ERP qui sert plusieurs organisations doit garantir qu'aucune ne voit les données d'une autre — y compris par erreur de requête.

Les options

Une base par organisation · un discriminant sur chaque table · un schéma par organisation.

Ce que j'ai choisi

Discriminant d'organisation sur chaque table, appliqué par un filtre global, plus un RBAC formalisé.

Le coût

Toute requête écrite hors du filtre global est une fuite potentielle — d'où des tests dédiés au cloisonnement.

02

Contrôler l'équilibre à la clôture ou à l'écriture ?

Le problème

Une écriture comptable fausse se propage silencieusement dans tous les états financiers.

Les options

Contrôle à la clôture · contrôle à l'enregistrement de chaque écriture.

Ce que j'ai choisi

Contrôle d'équilibre débit/crédit à chaque écriture, refus de l'enregistrement sinon.

Le coût

Les saisies partielles sont impossibles : l'écriture doit être complète pour être enregistrée.

Preuves dans le code

Deux extraits réels.

app/Models/AccountingEntry.php

Extrait à fournir

app/Models/CompteSyscohada.php

Extrait à fournir

Code Mes Rêves

Alexis Kouakou