Modèle métier Ormuz
Une représentation commune des entreprises, parcours, documents commerciaux, paiements, décisions de crédit et encaissements, conçue pour orchestrer un processus B2B sans dépendre du vocabulaire d'un provider ou d'un système source particulier.
Le langage commun de la plateforme
Le modèle métier relie les APIs, les process, les événements et les intégrations autour des mêmes objets. Une invoice ou une company conserve ainsi la même signification qu'elle provienne d'un ERP, d'un portail B2B, d'un import ou d'une action opérateur.
Cette stabilité permet de composer des parcours réutilisables : vérifier un client, décider d'un crédit, suivre un paiement acheteur, rapprocher un encaissement ou déclencher une relance sans reconstruire la logique pour chaque provider.
Les grandes familles d'objets
Entreprises et relations
Identifier les organisations, leurs contacts et les relations qui structurent leurs rôles métier.
companycontactcontact_rolecompany_groupParcours
Porter le contexte métier durable d’un checkout ou d’un onboarding, indépendamment de l’exécution du processus.
checkout_sessiononboarding_caseContrôles et décisions
Représenter les vérifications, scores et approbations qui produisent des faits décisionnels réutilisables.
compliance_checkrisk_scoreapproval_requestapproval_assignmentVente et facturation
Représenter la commande client, la facturation, les retours, litiges, échéances et soldes à recevoir.
orderinvoiceinvoice_balancereturnreturn_itemdisputereceivablepayment_termdue_date_scheduleline_itemCrédit
Définir les limites de crédit, mesurer l’exposition et calculer la capacité disponible à un instant donné.
credit_limitcredit_exposureeffective_credit_limitcredit_availability_checkPaiements et rapprochement
Suivre paiements PSP, mouvements de trésorerie, allocations de paiement et engagements de règlement.
psp_paymentpaymentpayment_allocationAchats et fournisseurs
Représenter commandes fournisseurs, factures fournisseurs, dette AP et décaissements.
purchase_ordersupplier_invoicepayablesupplier_paymentUne carte fonctionnelle, pas une séquence obligatoire
Les objets se combinent selon le cas d'usage. Un onboarding peut précéder un checkout, une facture peut exister sans checkout, et un encaissement bancaire peut être rapproché sans paiement PSP préalable. La carte suivante montre les liens les plus fréquents, pas un processus imposé.
Les parcours sélectionnent uniquement les objets nécessaires au résultat métier recherché.
Distinguer paiement PSP, tr ésorerie et rapprochement
La chaîne financière sépare trois réalités souvent confondues. Un psp_payment décrit le paiement suivi chez un PSP. Un payment représente un mouvement de trésorerie côté acheteur constaté par le marchand, y compris lorsqu’aucun PSP n’intervient. Une payment_allocation explique ensuite comment une source financière est affectée aux documents ou opérations métier concernés.
| Objet | Question métier | Nature |
|---|---|---|
psp_payment | Que s’est-il passé sur le rail de paiement du PSP ? | Ressource provider-neutral du paiement PSP. |
payment | Quel mouvement de trésorerie côté acheteur le marchand constate-t-il ? | Ressource autonome, utilisable avec ou sans PSP. |
payment_allocation | Comment ce mouvement est-il affecté aux factures, commandes ou autres cibles ? | Explication durable du rapprochement. |
receivable | Quel solde l’acheteur doit-il encore au marchand ? | Projection calculée à partir des documents et applications. |
Parcours de lecture
Principes fondamentaux
Comprendre les identités publiques, les relations, les sources de vérité et les brouillons de création.
Lire les principesCatalogue des objets
Explorer les principaux objets, leurs champs saillants et leurs relations fonctionnelles.
Explorer les objetsRelations et cycles de vie
Lire les transitions de statut, invariants et enchaînements entre objets.
Comprendre les cyclesChamps et schémas
Consulter les types, contraintes et contrats publics détaillés.
Consulter les schémas