Customer and Transaction Management
This domain covers the customer party model and the manual transaction lifecycle: how parties, accounts, and sites relate, how profile classes supply defaults, and how invoices, credit memos, adjustments, and chargebacks behave once completed.
Party model
A party is the person or organization. A customer account represents the commercial relationship and carries the profile class. Account sites provide bill-to and ship-to addresses and must be assigned to the business units that will transact with them. Contacts and relationships hang off the party, not the account.
Profile classes and transactions
A profile class supplies defaults such as payment terms, credit limit, statement cycle, dunning, and collector. Values are copied to the account, and account-level overrides take precedence, so changing the class later does not rewrite every field on every account. Manual invoices inherit numbering and accounting from the transaction source; completing a transaction makes it open and creates accounting. Adjustments are governed by approval limits, and a chargeback creates a new transaction rather than modifying the original invoice.
Worked example
An invoice cannot be saved for a customer in a newly configured business unit. The party and account exist, but no account site has been assigned to that business unit. Add the business unit to the bill-to site, then re-enter the invoice; the site becomes selectable and the transaction saves.
Traps
- Confusing party with account: credit and statements sit on the account, addresses on sites.
- Forgetting the business unit assignment on the site, which hides the customer from transactions.
- Using a credit memo when an adjustment, with its approval workflow, is the correct control.
- Assuming an incomplete transaction creates accounting; only completion does.