Ormuz business model
A shared representation of companies, journeys, commercial documents, payments, credit decisions, and collections, designed to orchestrate B2B processes without depending on the vocabulary of a particular provider or source system.
The platform's common language
The business model connects APIs, processes, events, and integrations around the same objects. A invoice ou une company therefore keeps the same meaning whether it comes from an ERP, B2B portal, import, or operator action.
This stability enables reusable journeys: verify a customer, make a credit decision, track a buyer payment, reconcile a receipt, or trigger a reminder without rebuilding logic for each provider.
Main object families
Companies and relationships
Identify organizations, their contacts, and the relationships that structure their business roles.
companycontactcontact_rolecompany_groupJourneys
Carry the durable business context of a checkout or onboarding case independently from process execution.
checkout_sessiononboarding_caseChecks and decisions
Represent checks, scores, and approvals that produce reusable decision facts.
compliance_checkrisk_scoreapproval_requestapproval_assignmentSales and invoicing
Represent customer orders, invoicing, returns, disputes, due amounts, and receivable balances.
orderinvoiceinvoice_balancereturnreturn_itemdisputereceivablepayment_termdue_date_scheduleline_itemCredit
Define credit limits, measure exposure, and calculate available capacity at a point in time.
credit_limitcredit_exposureeffective_credit_limitcredit_availability_checkPayments and reconciliation
Track PSP payments, cash movements, payment allocations, and settlement commitments.
psp_paymentpaymentpayment_allocationPurchasing and suppliers
Represent purchase orders, supplier invoices, AP liabilities, and disbursements.
purchase_ordersupplier_invoicepayablesupplier_paymentA functional map, not a mandatory sequence
Objects combine according to the use case. Onboarding may precede checkout, an invoice may exist without checkout, and a bank receipt can be reconciled without a prior PSP payment. The following map shows the most common links, not a prescribed process.
Journeys select only the objects required for the desired business outcome.
Distinguish PSP payment, cash movement, and reconciliation
The financial chain separates three realities that are often confused. A psp_payment describes a payment tracked with a PSP. A payment represents a buyer-side cash movement observed by the merchant, including when no PSP is involved. A payment_allocation then explains how a financial source is allocated to the relevant business documents or operations.
| Objet | Business question | Nature |
|---|---|---|
psp_payment | What happened on the PSP payment rail? | Provider-neutral PSP payment resource. |
payment | What buyer-side cash movement does the merchant observe? | Independent resource, usable with or without a PSP. |
payment_allocation | How is this movement allocated to invoices, orders, or other targets? | Durable explanation of reconciliation. |
receivable | What balance does the buyer still owe the merchant? | Projection calculated from documents and allocations. |
Reading path
Core principles
Understand identifiers, relationships, sources of truth, and creation drafts.
Read the principlesObject catalog
Explore the main objects, their key fields, and functional relationships.
Explore objectsRelationships and lifecycles
Read status transitions, invariants, and sequencing between objects.
Understand lifecyclesFields and schemas
Review detailed public types, constraints, and contracts.
View schemas