Company
- name · slug
- timezone
- 1—n User
- 1—n SaleOrder
- 1—n AccountMove
Solution ERP Laravel pour opérations, inventaire et productivité.
Odoo a fixé un modèle pour les ERP : des modules qu’on installe selon ses besoins, des règles d’accès enregistrement par enregistrement et plusieurs sociétés dans la même instance. Mais il impose Python et son propre framework. Laroo pose la question : peut-on retrouver cette logique modulaire dans l’écosystème Laravel ?
Livrer des modules ERP légers (stock, facturation, CRM) sur Laravel.
Un monolithe Laravel 12 découpé en 24 modules de style Odoo, chacun avec son manifeste module.json, ses dépendances et son service provider. Un gestionnaire installe les modules dans l’ordre de leurs dépendances. La logique métier vit dans une centaine de services reliés par des événements, et le multi-société passe par l’URL /app/{société}/… et des scopes Eloquent globaux.
Un ERP en ligne avec back-office, portail client et API REST : CRM, ventes et achats, stock valorisé, comptabilité, RH, fabrication et qualité, marketing, et un Studio pour ajouter champs et vues sans code. Les écarts avec Odoo sont documentés module par module.
Développeur lead
Utilisateurs
Application
Services externes
La requête /app/{société}/… vérifie que l’utilisateur y a accès, puis fixe la société courante.
La confirmation d’une commande client émet l’événement SaleOrderConfirmed.
Un listener met en file l’e-mail de confirmation au client.
La validation du mouvement de stock calcule le coût en FIFO ou en coût moyen et met à jour les quantités, dans une seule transaction.
Des listeners créent les écritures de valorisation et, si besoin, les contrôles qualité.
La comptabilisation vérifie l’équilibre débit-crédit à un centime près, puis passe l’écriture en « comptabilisée ».
Les entités principales, leurs champs clés et leurs relations.
Pipeline kanban, scoring des prospects et règles d’affectation.
Commandes, réceptions, commandes-cadres et listes de prix.
Mouvements, lots, réapprovisionnement, valorisation FIFO ou au coût moyen.
Écritures, rapprochement bancaire, avoirs, écritures récurrentes, relances.
Congés, présences, paie ; nomenclatures, ordres de fabrication, contrôles qualité.
Champs personnalisés, vues et actions automatisées sans code.
ProblèmeChaque requête doit ne voir que les données de la société courante, sauf ce qui est explicitement partagé.
SolutionUn scope global qui accepte aussi les enregistrements partagés via une table dédiée.
ProblèmeDeux factures créées en même temps pouvaient recevoir le même numéro.
SolutionVerrou de ligne (lockForUpdate) sur la séquence.
ProblèmeUn mouvement validé à moitié laissait les quantités et la valorisation divergentes.
SolutionConsommation des couches de coût et mise à jour des quantités dans une seule transaction.
ProblèmeLa société courante vivait seulement en session, ce qui rendait les liens ambigus.
SolutionRefonte du routage : la société passe dans l’URL et dans les valeurs par défaut des routes.
ProblèmeDes contrôleurs sensibles ne vérifiaient pas toujours les droits.
SolutionAutorisation systématique, Form Requests et vérification des signatures de webhooks.
Relevé dans le code source et l’historique Git du projet le 8 octobre 2026. Aucun chiffre d’usage ou de revenu n’est publié.
Disponible pour missions PHP / Laravel / WordPress / Silverstripe en Belgique et remote EU.