Skip to content
MirrorFirm

What tables and link fields could a generated allocation schema include?

A schema could use linked tables for payments, obligations, accounts, remittances, policies, allocations, exceptions and reversals, with foreign keys a reseller can validate at ingest.

A release could describe allocation with a small set of linked tables. The field names below show the intended shape; the exact schema is agreed in scoping.

- `payments`: `payment_id` (such as `PAY-5521`), `received_at`, `amount`, `currency`, `channel`, `raw_reference`, `payer_hint`, `status` - `obligations`: `obligation_id`, `account_id`, `due_date`, `amount_due`, `amount_open`, `status` - `accounts`: `account_id`, `payer_id`, `domain_type`, `parent_account_id` - `remittances`: `remittance_id`, `payer_id`, `listed_obligation_ids`, `document_text` - `policies`: `policy_id`, `version`, `effective_from`, `rule_text` - `allocations`: `allocation_id`, `payment_id`, `obligation_id`, `amount_applied`, `policy_id`, `policy_version`, `decided_by_role`, `decided_at` - `exceptions`: `exception_id`, `payment_id`, `type`, `queue`, `handover_note` - `reversals`: `reversal_id`, `original_payment_id`, `reason`

Links to check: every `allocations.payment_id` resolves to `payments`; the applied amounts for a payment do not exceed `payments.amount`; each `policy_version` was effective at `decided_at`; a reversal references a payment that was already applied.

A payment may map to many allocation rows, so keep `allocation_id` separate from `payment_id`. Ask for a foreign-key report with each release so your ingest can reject broken links.

Ask for a foreign-key report with each release so your ingest can reject broken links before they reach customers.

Audience:
Licensed resellers
Content type:
Integration
Buyer question:
What can be generated

Content release: r-a220eb6e099b243b

More on Payment allocation