Which record layers should a reseller name when asking what a release can contain?
A checklist of eight record layers, from schedule headers and instalment lines to calendars and task definitions, to confirm in a scoping conversation.
When asking what a release could contain, a reseller can use this list to confirm that each layer your customers expect has been named.
- **Schedule headers** with product type, frequency, term and governing policy reference. - **Instalment lines** split into principal, interest, fees and a status for each due date. - **Payment events**, including partial, late, duplicate and reversed payments, linked to instalment lines. - **Amendment requests** with requester role, reason code, effective date and the channel used. - **Approval decisions** naming the approver role, the policy clause applied and any conditions attached. - **Side-effect records** such as notices, arrears flags, fee postings and reconciliation tasks. - **Calendar tables** covering public holidays, cut-off times and month-end rules for the relevant region. - **Task definitions** with starting state, permitted actions and an expected end state for grading.
Naming each layer up front avoids a release that looks complete in a listing but lacks the records your customers need.
- Audience:
- Licensed resellers
- Content type:
- Checklist
- Buyer question:
- What can be generated
Content release: r-a220eb6e099b243b
Related questions
- Can a release include policies, exceptions and refusals, not just records?
- What file layout and keys would a schedule dataset use?
- Which record types should I request in a generated schedule pack?
- What would a simulated utility payment-plan environment hold?
- What can a generated schedule dataset or environment contain?
- Which entities should I ask for in a schedule dataset or environment?