Access and permissions in Payments
The Payments workspace requires the Payment module, a signed-in tenant session and the permission for each task. The service also checks access to the payment's business unit.
Permissions by task
| Task | Permission | Other requirement |
|---|---|---|
| Search/open receipts | payment.view | Payment capability and allowed unit |
| Open/create New customer receipt | payment.create | Valid customer, unit and usable currency setup |
| Post a customer receipt | payment.post | Draft customer payment with positive stored amounts |
| Cancel a customer receipt Draft | payment.cancel | Draft only in this workspace |
| Allocate to a sales invoice | payment.allocate | Posted/Partially allocated, positive Available |
| Populate business-unit selector | business-unit.view | Active units for the current tenant |
| Populate customer selector | customer.view | Customer lookup access |
| Find invoices for allocation | sales.invoice.view | Invoice lookup within allowed scope |
| Load ledger settings used by the create form | charity.finance.view and its required module context | Active configured settings; see below |
Creation and allocation are released in the current browser. Permissions and setup can still block an individual task; this is different from the unreleased credit-note write controls in Invoicing.
Ledger settings dependency in the current form
The Ledger base currency field is required and read-only. The browser fills it through the Charity finance settings reader when the user has charity.finance.view and the required Charity Finance, Charity, Party, Organization, Payment and Accounting capabilities, and the settings are active.
Consequently, payment.create alone may open the form but leave no usable base currency. Do not ask staff to guess or alter a read-only value. Have the application administrator review this setup dependency and the approved supported route for customer receipts.
This is an implementation dependency, not a requirement to treat a commercial receipt as a donation. Do not create a donation to work around it.
Example division of work
| Person | Example responsibilities |
|---|---|
| Farah, receipt clerk | View/create, customer/unit lookup; prepare Draft |
| Nadia, reviewer | View/post and invoice-view/allocate where authorised |
| Collections colleague | Invoice/payment view and approved reconciliation reports |
The current customer receipt workflow does not enforce a separate creator and poster or require two approval signatures. A role split is your organisation's procedure; it is not a hidden system approval step.
Business units and matching
You need access to the receipt's unit and the target invoice. The allocation workflow requires the same customer Partner, business unit and transaction currency in the browser. Having access to two units does not permit using one unit's receipt against another unit's invoice.
Example: Café Aroma's Main Shop invoice and another unit's Café Aroma invoice can have the same customer but are not interchangeable targets for the Main Shop receipt.
Missing controls
Check the active tenant, Payment capability, exact permission and current state. View permission does not imply post/allocate access. Allocation also needs invoice lookup permission.
The page Payments unavailable offers Refresh access and Dashboard. After access changes, refresh the session/context or sign in again. For a blank Ledger base currency, review the setup dependency rather than repeatedly pressing Save.