FAP Data Model Overview
The FAP data model is built around three core areas — Suppliers, Transactions, and Payment Schedules — with supporting entities for supplier sites, site uses, and transaction holds. Understanding how these relate is the key to understanding how Raytio tracks accounts payable.
The big picture
Suppliers
A Supplier is the central FAP entity. Each supplier references a party in the PRM (Party Relationship Management) module, linking the payables relationship to the broader party record. A party can be both a customer (in FAR) and a supplier (in FAP) — the same party record is shared.
Suppliers carry classification attributes — type, class, status, and approval status — along with a default payment term and an optional default transaction currency.
For full detail, see Suppliers.
Supplier sites and site uses
Suppliers can operate at multiple locations. A Supplier Site links a FAP supplier to a PRM party site, while a Supplier Site Use defines the business purpose of that site (PURCHASING, PAY, or RFQ) and can override the supplier-level payment term.
Each supplier site can optionally carry a remittance bank account (from CMM), which must belong to the supplier's party.
See Supplier Sites and Site Uses for the full explanation.
Payment terms
Payment Terms define when and how payments are due. Each payment term has one or more Payment Term Lines that specify relative amounts, due dates, and due-day calculations. Payment terms are shared with FAR (Accounts Receivable) — the same term definitions are used on both the customer and supplier side.
The defaulting chain for transactions is: site use → supplier. If no payment term is found at either level, an error is raised.
Transactions
Transactions follow a header/line pattern, the same as customer transactions in FAR. A Transaction Header represents a single financial document — an invoice, credit memo, debit memo, or prepayment — with references to the supplier, supplier site, transaction date, currency, and payment terms. Transaction Lines hold the individual line items.
See Supplier Transactions for the full lifecycle.
Transaction holds
Transaction Holds can be placed on a transaction to prevent it from being paid. Each hold records a hold code, reason, who placed the hold, and when. Holds are released by recording a release code, releasing user, and release date.
A transaction is payable only when it is VALIDATED, APPROVED, and has no open holds.
See Transaction Holds for the complete model.
Payment schedules
Payment Schedules are generated automatically when a transaction reaches VALIDATED status. The transaction amount is expanded across the payment term lines, creating one schedule entry per instalment. Each schedule tracks original amount, remaining amount, applied amount, and adjustments.
See Payment Schedules for the complete model.
Entity summary
| Entity | Purpose |
|---|---|
| Supplier | Central supplier account linking to a PRM party |
| Supplier Site | Links a supplier to a PRM party site |
| Supplier Site Use | Defines business purpose (PURCHASING, PAY, RFQ) with optional payment term override |
| Transaction Header | Financial document header (invoice, credit memo, debit memo, prepayment) |
| Transaction Line | Line item on a transaction with quantity and pricing |
| Transaction Hold | Hold record preventing payment of a transaction |
| Payment Schedule | Instalment record generated from payment term lines on validation |
| Payment Term | Named payment term (shared with FAR) |
| Payment Term Line | Instalment definition within a payment term |
Multi-tenancy
The entire FAP model is tenant-scoped. Every supplier belongs to a tenant and an organisation, and access controls ensure that users only see data belonging to their own tenant. Within a tenant, authorisation is managed through the platform's permissions system, with object-level permissions flowing from supplier records down to related entities.