Relations et cycles de vie
Le modèle distingue les faits durables, les décisions, les états financiers et l’exécution des processus. Un même objet peut exposer plusieurs axes de statut lorsque ces axes répondent à des questions métier différentes ; les projections, elles, décrivent un calcul à un instant donné et n’inventent pas de lifecycle autonome.
Vue d’ensemble
Les relations se lisent d’abord par famille fonctionnelle, puis par type d’objet.
| Famille | Objets | Rôle |
|---|---|---|
| Entreprises et relations | company, contact, contact_role, company_group | Identifier les organisations, leurs contacts et les relations qui structurent leurs rôles métier. |
| Parcours | checkout_session, onboarding_case | Porter le contexte métier durable d’un checkout ou d’un onboarding, indépendamment de l’exécution du processus. |
| Contrôles et décisions | compliance_check, risk_score, approval_request, approval_assignment | Représenter les vérifications, scores et approbations qui produisent des faits décisionnels réutilisables. |
| Vente et facturation | order, invoice, invoice_balance, return, return_item, dispute, receivable, payment_term, due_date_schedule, line_item | Représenter la commande client, la facturation, les retours, litiges, échéances et soldes à recevoir. |
| Crédit | credit_limit, credit_exposure, effective_credit_limit, credit_availability_check | Définir les limites de crédit, mesurer l’exposition et calculer la capacité disponible à un instant donné. |
| Paiements et rapprochement | psp_payment, payment, payment_allocation | Suivre paiements PSP, mouvements de trésorerie, allocations de paiement et engagements de règlement. |
| Achats et fournisseurs | purchase_order, supplier_invoice, payable, supplier_payment | Représenter commandes fournisseurs, factures fournisseurs, dette AP et décaissements. |
Ne pas confondre les axes de statut
Un champ status ne doit jamais devenir un résumé ambigu de réalités différentes. Lorsque le lifecycle administratif, la résolution commerciale, les faits physiques ou le règlement évoluent indépendamment, le modèle les expose sur des axes séparés.
| Axe | Question | Exemples |
|---|---|---|
| Lifecycle de la ressource | L’objet existe-t-il encore comme dossier ou document actif ? | return.status, dispute.status, invoice.status |
| Résolution métier | Quelle conclusion métier a été prise ? | return.resolution_status, dispute.resolution_status |
| Règlement | Quel est l’état financier d’un document ? | invoice.settlement_status, supplier_invoice.settlement_status |
| Faits physiques | Qu’est-ce qui s’est réellement produit ? | return.shipped_at, received_at, inspected_at |
| Exécution du processus | Où en est l’orchestration qui traite le dossier ? | process_status dérivé lorsque l’objet est process-owned |
| Projection calculée | Que vaut le solde ou la capacité à cet instant ? | receivable, payable, effective_credit_limit, credit_availability_check |
Objets process-owned
Certains dossiers métier possèdent une instance de processus canonique qui porte leur politique et leur orchestration. La ressource conserve ce qui doit rester vrai même si le processus est rejoué, remplacé ou échoue.
| Objet | Répartition des responsabilités |
|---|---|
checkout_session | La session conserve le contexte et le résultat durable du checkout ; le processus orchestre les étapes nécessaires. |
onboarding_case | Le dossier conserve les faits d’entrée en relation ; le processus porte collecte, contrôles et interactions. |
dispute | Le litige expose le fait contesté et sa résolution sans imposer la politique de suspension, relance ou remédiation. |
return | Le retour conserve demande, faits physiques et résolution ; le processus décide autorisation, inspection et remédiation. |
Le cas le plus explicite est le return : status décrit le dossier, resolution_status la conclusion commerciale, les milestones décrivent les faits logistiques et process_status reflète séparément l’exécution du processus propriétaire.
Chaînes financières AR et AP
Les chaînes client et fournisseur sont symétriques sur les principes, sans fusionner leurs objets. Le cash entrant côté acheteur reste un payment ; le décaissement fournisseur reste un supplier_payment.
Vente / comptes clients
order— porte la commande client et ses lignes.invoice— porte le document financier et son échéance.receivable— projette le solde dû par l’acheteur.psp_payment— suit un paiement ou remboursement côté PSP lorsqu’un PSP intervient.payment— constate un mouvement de trésorerie côté acheteur, avec ou sans PSP.payment_allocation— explique comment la source financière est affectée aux documents ou opérations.
Achats / comptes fournisseurs
purchase_order— porte la commande adressée au fournisseur.supplier_invoice— porte le document financier fournisseur.payable— projette le solde dû au fournisseur.supplier_payment— porte le décaissement fournisseur et son lifecycle.payment_allocation— explique l’affectation du mouvement aux cibles AP.
disputed, due et undisputed de receivable et payable exposent des faits analytiques. Un processus décide ensuite s’il faut relancer, suspendre, approuver ou payer ; la projection ne prend pas cette décision à sa place.Approbations : demande agrégée et décision humaine
Une approval_request porte la politique et le lifecycle agrégé. Sesapproval_assignment sont embarquées : chacune représente une sollicitation d’approbateur et devient une décision humaine uniquement lorsqu’elle atteint approved ou rejected.
Il n’existe donc pas de troisième objet approval_decision. Une expiration ou une annulation administrative peut résoudre la demande sans fabriquer de décision humaine.
Projections et objets embarqués
receivable, payable, effective_credit_limit et credit_availability_checksont des snapshots calculés. Ils n’ont pas d’identifiant autonome à faire progresser d’un statut à l’autre.
line_item, return_item et approval_assignment sont embarqués dans un contexte parent. Leur sémantique est documentée avec ce parent plutôt que comme ressource adressable indépendante.