Skip to main content

7 docs tagged with "fap"

View all tags

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.

Financials – Accounts Payable (FAP)

Raytio's Financials – Accounts Payable (FAP) module manages supplier accounts, supplier transactions, and payment obligations. It tracks who your suppliers are, what you owe them, and how payment schedules are generated.

Payment Schedules

Once a supplier transaction is validated, FAP generates Payment Schedules to track exactly when and how much is owed. Each schedule row represents one instalment defined by the transaction's payment terms. This gives accounts payable a clear view of upcoming obligations.

Supplier Sites and Site Uses

Suppliers often operate at multiple locations, and each location may serve a different business purpose — one site for purchase orders, another for receiving payments. FAP handles this with a two-level hierarchy: supplier sites and supplier site uses.

Supplier Transactions

Supplier transactions are the financial documents at the heart of accounts payable — invoices, credit memos, debit memos, and prepayments received from suppliers. FAP models these using a header/line pattern: a transaction header carries document-level details, while transaction lines hold the individual line items. This mirrors the header/line pattern used for customer transactions in FAR.

Suppliers

A Supplier is the central entity in the FAP module. It represents a financial relationship with a party — the entity you receive invoices from, owe payment obligations to, and manage payables for. Every supplier references a party in the PRM (Party Relationship Management) module, linking the accounts-payable record to the broader party identity.

Transaction Holds

Transaction holds are a mechanism for blocking payment of a supplier transaction when a problem is identified — for example, a pricing discrepancy, a quantity mismatch, or a manual review requirement. FAP records each hold separately, so multiple issues can be tracked independently on a single transaction.