Resolve business account identity into global address book parties with customer and vendor roles, separate commercial grouping from posting behaviour, and normalise source document flows into the target's explicit business events.
Trade is where the decisions taken in the previous modules become visible to people outside the programme. Customers, vendors, orders, prices and charges are what the business sees, and they are also where three earlier decisions have to hold together: the legal-entity design, the class decomposition, and the posting crosswalk.
The target's address book is one of the structural differences that repays attention early.
The Posting Engine module established the decomposition. Here is the commercial view of it.
The target separates commercial, logistics and accounting events. The source may or may not have done the same, and the difference has to be resolved before open orders are touched.
Every open order is a partial state, and the carry-forward policy is a business decision with a data consequence.
The target offers trade agreements — price and discount journals with validity by customer, group, item, group and quantity — and, in more recent releases, a unified pricing management capability with a rule-based engine.
Freight, handling, duty, insurance and miscellaneous fees translate reasonably well onto the target's charge codes with automatic charge rules. The mapping work is mostly clerical.
Where branches became separate legal entities, movements between them become intercompany trade: an intercompany sales order in one entity generating a purchase order in the other, with matched documents and elimination at consolidation.
Identity comes first: the target holds a party once and attaches customer and vendor roles to it, so role overlap, shared contacts and cross-tenant duplication have to be resolved before the master load rather than merged afterwards.