Field 07 of 07

ERP & business systems

SYSCOHADA accounting, payroll and budgeting in a single system.

Proven on :Sytium ERP

Since July 2024

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

The system's modules

277 Eloquent models, 139 migrations. All classified — the module counts add up exactly.

Module entities

Comptabilité & finance

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

and 21 more

SYSCOHADA posting simulator

Operation
VAT 18%
180 000 F
Including tax
1 180 000 F

JournalACH · Journal des achats

Debit = Credit
AccountDescriptionDebitCredit
601Achats de marchandises1 000 000
4452TVA récupérable sur achats180 000
401Fournisseurs, dettes en compte1 180 000
Total1 180 0001 180 000

The balance check happens on posting, not at closing: otherwise a wrong entry would propagate through every financial statement.

Depreciation schedule

Useful life
Method
YearRateChargeAccumulatedNet book value
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

The schedule exhausts exactly: the final net book value is zero.

Depreciation posting, first year

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

The mechanism

How it works.

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.

The trade-offs

What I ruled out, and why.

A technical choice without its cost is not a choice, it is a preference.

01

Comment garantir le cloisonnement entre organisations ?

The problem

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.

The options

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

What I chose

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

The cost

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 ?

The problem

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

The options

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

What I chose

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

The cost

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

Proof in the code

Two real extracts.

app/Models/AccountingEntry.php

Extract to be supplied

app/Models/CompteSyscohada.php

Extract to be supplied

Code Mes Rêves

Alexis Kouakou