Règles métier et contrôle

Le principe

AVIA ERP refuse avant d'écrire. Une réception qui dépasse la tolérance autorisée, un document fermé sur une période en clôture, un montant qui dépasse la limite de crédit d'un client : le portail bloque l'opération avant qu'elle touche la base, jamais après coup.

Chaque refus porte un code stable, un message dans la langue de l'utilisateur qui dit le problème et ce qu'il faut faire, et des paramètres exploitables (le seuil dépassé, le champ manquant, la période visée…). La forme exacte est détaillée plus bas sur cette page.

Le consultant qui déploie AVIA ERP paramètre des seuils et des portées — jamais de logique métier écrite en dur. Chaque type de règle reste du code testé ; ce qui change d'un client à l'autre, ce sont les valeurs. Avant d'activer une règle, on la simule sur les documents réels des 90 derniers jours : combien auraient été évalués, combien auraient été bloqués.

En chiffres : 16 types de règles plus le type des seuils de risque, 10 packs prêts à l'emploi (4 par métier, 4 normatifs, plus un pack contrôle de gestion et un pack contrôle interne), des dimensions analytiques (affaire / département / centre de coût) avec dimension exigée et combinaison interdite, et une traçabilité lot/série de la réception jusqu'à la fiche série.

Paramètres › Règles métier

L’écran Règles métier

L'écran se trouve dans Paramètres → Système → Règles métier. Il liste les règles actives avec leur type, leur portée, leur cible, leurs paramètres, le moment où elles s'appliquent, leur date de création et leur statut.

La liste des règles actives : type, portée, cible, paramètres, moment d’application et statut.

Créer une règle

Le formulaire de création est généré depuis le catalogue des types disponibles (GET /api/v1/rules/types) : choisir un type affiche automatiquement ses portées possibles (locataire, fournisseur, article ou client selon le type) et ses paramètres propres.

Simuler avant d’activer

Le bouton Simuler sur les 90 derniers jours rejoue les paramètres saisis contre les documents réels de la période, sans rien modifier, et affiche le nombre de documents évalués et combien auraient été bloqués.

Avant d’activer une règle, on la simule sur les documents réels des 90 derniers jours.

Désactiver, jamais supprimer

Le bouton bascule appelle un simple PUT qui passe le champ active à faux : la règle disparaît du contrôle mais reste dans l'historique, réversible à tout moment. Une règle n'est jamais supprimée.

Un filtre ?module= restreint la liste à un module ; c'est ce que suit le lien Règles de ce module depuis Paramètres → Achats.

Packs par métier

Des packs de règles prêtes à l'emploi existent par métier (textile, mécanique de précision, câblage et métallerie, transport et logistique) via GET /api/v1/rules/packs. On peut les simuler puis les appliquer : les règles sont insérées désactivées, à activer une par une après vérification. Appliquer un pack déjà appliqué ne duplique rien.

Simuler un pack avant de l’appliquer : évalués / bloqués par règle, sur les 90 derniers jours.

Les types disponibles

Catalogue des types de règles

Six types de règles couvrent les points de contrôle courants. Pour chacun, ce tableau donne la portée possible, le moment où la règle s'applique et surtout le comportement quand aucune règle n'est paramétrée pour ce type — le comportement par défaut, celui d'un tenant qui n'a encore rien configuré.

Pour l'approbation par montant, les paliers se déclarent en seuil:rôle, par exemple 5000:achat, 50000:directeur_achat. Sans règle paramétrée, c'est la grille historique des demandes d'achat qui continue de s'appliquer : 5 000 déclenche une approbation achat, 50 000 une approbation direction achat. La période close dépend des périodes fiscales paramétrées en Finance ; le workflow requis ne se déclenche que si un workflow d'approbation est réellement actif pour le document — sans workflow actif, le ferme n'est pas affecté.

Historique des modifications

Ce qui est journalisé

Chaque changement sur un champ déclaré sensible est journalisé : champ, ancienne valeur, nouvelle valeur, auteur et date. Le mécanisme s'appuie sur une table de déclaration (sensitive_fields) et une table de journal (field_changes), alimentées par un déclencheur générique — un champ nouvellement déclaré est journalisé sans code applicatif supplémentaire.

Déclarer un champ supplémentaire

Un consultant déclare un champ additionnel à journaliser via la ressource sensitive-fields, sur la page sœur Champs journalisés (à côté de Règles métier dans Paramètres → Système) : choisir la table (fournisseurs, clients, articles, employés, profils, droits utilisateur) et le champ. Un champ déclaré peut aussi être désactivé sans perdre l'historique déjà écrit.

Écran Champs journalisés : une ligne par champ déclaré, table par table, avec son bouton et sa date de déclaration.

La lecture se fait dans l'onglet Historique de la fiche fournisseur, client ou article.

Chaque changement de champ sensible garde l’ancienne valeur, la nouvelle valeur, l’auteur et la date.

Les valeurs bancaires (RIB, IBAN) restent masquées sauf les 4 derniers caractères. Une valeur vide et une valeur absente (NULL) sont traitées comme équivalentes pour ne pas journaliser un faux changement, et l'auteur est posé sur tous les chemins d'écriture, y compris les imports et l'API.

Flux du document

Le panneau Flux du document

« D'où vient cette facture ? » Le panneau Flux du document répond en remontant la chaîne des conversions : devis, commande de vente, commande d'achat, réception, facture. Chaque conversion (devis → commande, devis → facture, commande → ordre de fabrication, demande d'achat → commande, réception → facture fournisseur…) ajoute un maillon dans la table document_links, exposée par GET /api/v1/document-flow/{type}/{id}.

Le flux remonte du devis à la facture ; chaque conversion ajoute un maillon.

Le même flux apparaît en aperçu (factbox) sur les listes de factures, de fournisseurs et de commandes d'achat quand une ligne est sélectionnée.

Droits par action et par lecture

Armer les droits sans surprise

Deux réglages contrôlent l'application des droits : AUTH_GUARD_MODE pour les actions d'écriture et AUTH_GUARD_READ_MODE pour la lecture, chacun sur trois valeurs : off (aucun contrôle), observe (le refus est journalisé mais laissé passer) et enforce (le refus bloque réellement). Les deux valent off par défaut.

L'armement se fait module par module via AUTH_GUARD_ENFORCE_MODULES, une liste partagée entre écriture et lecture. Le volume de lecture observée est échantillonné (AUTH_GUARD_READ_LOG_SAMPLE, 100 par défaut) pour ne pas saturer les journaux.

Observer, corriger, armer

GET /api/v1/admin/auth-guard/observations renvoie le mode courant, le mode lecture, les modules déjà armés, et le compte des refus qui seraient survenus par module et par action. La procédure recommandée : observer une période représentative, corriger les rôles qui manquent d'un droit légitime, puis armer le module.

Un refus de droit, une fois armé, répond 403 avec le code droit_insuffisant — actionnable, contrairement à une simple erreur générique. Un module hors abonnement répond 404 : l'utilisateur ne sait même pas qu'il existe.

Ce que dit un refus

La forme d’un refus

Tout refus prend la même forme : { code, params, message }. Le message est déjà traduit dans la langue de l'utilisateur (français, anglais ou arabe) ; params porte les valeurs utiles à l'affichage ou à un correctif (seuil, champ, période…).

{
  "code": "limite_credit_depassee",
  "params": { "client": "CL-00042", "limite": 15000, "encours": 15820 },
  "message": "Le client CL-00042 dépasse sa limite de crédit de 15 000 TND (encours 15 820 TND)."
}

Le copilote lit ce même refus structuré pour l'expliquer en langage courant et guider l'utilisateur vers la correction — changer la quantité reçue, choisir une autre période, demander une approbation.

Sept pages sœurs vont plus loin : le catalogue complet des types (une fiche par type — paramètres, refus, simulation, référence normative), les packs par métier (composition règle par règle et checklist consultant par pack), la procédure de mise en service sur un nouveau locataire (droits, condition et gravité, champs sensibles, signaux de risque, le copilote), des exemples par secteur (six parcours avec les clients réels nommés dans les packs — textile, mécanique de précision, câblage/métallerie, transport et logistique, contrôle de gestion, contrôle interne), le pilotage (centres de rôle, factbox, centre d'actions, signaux de risque, rapport d'affaire, copilote), le copilote (expliquer un refus, procédures guidées, actions confirmées, ce qu'il ne fait jamais), et les profils de statuts (restreindre sans élargir, un rôle par transition, simulation).

Consultez Administration pour les rôles utilisateur et API & Intégrations pour l'authentification.