How Payments connects to other modules
Which workspace should I use?
| Work | Workspace | Reason |
|---|---|---|
| Customer receipt, advance or allocation | Payments | Current customer-payment workflow |
| Customer invoice creation/posting | Invoicing | Bill and current outstanding amount |
| Invoice-specific Record Payment | Sales order → Invoice Payment | Combined receipt recording/allocation against that bill |
| Supplier payment | Purchasing | Vendor payment and purchase-invoice allocation are separate documents |
| Company-paid expense | Expense | Expense owns its lifecycle and linked vendor reference |
| Donation receipt | Charity | Charity financial commands and controls |
| Bank/receivables journals | Accounting | Accounting owns those documents/views |
The shared data model recognises other payment types, but the current generic customer API excludes/rejects non-customer workflow records. Do not move a donation or expense payment into the customer flow because a page description mentions it.
The Sales order shortcut
The existing Sales order invoice page has Record Payment or a payment-count button. It leads to Invoice Payment, where Record Payment records the actual amount, method, date, reference and notes against that specific bill.
This route combines invoice-specific receipt processing and allocation. By contrast, the generic Payments workspace uses Save draft receipt → Post receipt → Allocate to invoice. Both affect the same customer invoice.
Example: if Farah records 200 through the Sales shortcut, she should inspect that receipt/allocation in Payments rather than create another generic 200 for the same bank transfer.
Customer, Party and Partner identifiers
Customer is the customer profile and lookup; Party is the underlying identity; Partner is the trading relationship used by invoice/payment matching. Use the selector rather than substituting a Party ID into Customer partner ID.
An older Expense record may reuse the shared customer-reference field internally for a vendor reference. That does not turn the vendor into a customer or make it an eligible invoice allocation. Such records belong to Expense and are not normal results of the current customer API.
Current ledger-settings dependency
The generic receipt form's Ledger base currency is loaded through active Charity finance settings with the required access/module context. This is a current form integration, not a request to create donation records. See Access if the field is empty.
Invoices, credits and stock
Invoice Paid / credited includes allocations and effective credits. A fully settled bill does not establish that every unit of settlement came from cash. The current Invoicing browser disables new credit writes but can show existing credit effects.
Payment recording/allocation does not dispatch stock. Sales still owns dispatch eligibility and physical dispatch. Likewise, a return/credit classification is not evidence of a stock return or customer refund executed by Payments.