Settlement v3 - Create a settlement report

[tselit]

Goal:

As a hub administrator

I want to be able to specify a group of transfers by their characteristics, in order to view their contents

so that I can understand the state of settlement obligations in the scheme.

When creating a settlement report, the output that gets generated is defined in this related ticket: Settlement v3 - View a settlement report

Additional context

• Settlement functionality assigns transfers to settlement batches based on a deterministic rule that gets specified as part of the settlement model to which the transfer belongs.
• Each settlement batch must have a status associated with it. The status of a settlement batch may be set to one of the following values: -- OPEN: transfers may be added to the settlement batch. The batch may be settled. -- CLOSED: transfers may not be added to the settlement batch. The batch may be settled. -- IN_DISPUTE: transfers may not be added to the settlement batch. The batch may not be settled. -- AWAITING_SETTLEMENT: transfers may not be added to the settlement batch. The batch may be settled, but only via confirmation of the settlement request which changed its status to AWAITING_SETTLEMENT. -- SETTLED: transfers may not be added to the settlement batch. The batch may not be settled.

Acceptance Criteria: A hub administrator must be able to specify the following criteria, to indicate transfers that must be included in the settlement report:

• [x] 1. Optional: A status value for the batches to which the transfers belong. For instance, it should be possible to request a report which contains all of the batches whose status is IN_DISPUTE.
• [x] 2. A settlement model to which the transfers belong.
• [x] 3. Mandatory: The time (or date range) at which the transfer completed. The ability to specify the time, with the maximum granularity defined in the settlement model’s batch definition, but not below that. Note: Specifying a time granularity which is below that supported by the settlement model should result in an error.
• [x] 3.1 The time segmentation levels are: (i) Year (ii) Month (iii) Day of month (iv) Hour (v) Minute (vi) Second
• [x] 3.2 At any level of time segmentation, I want to be able to specify a start and end point.
• [x] 3.3 If a start and end point is specified at a particular level (for instance, day of month,) then all higher levels (for instance, year and month) should have a single specification (for instance, February 2023).
• [x] 4. Optional: The ability to select one or more settlement batch currency.
• [x] 5. Optional: Any other characteristics which form part of the settlement model selected. Examples might be a sub-scenario (where, for instance, remittance transfers are identified by their sub-scenario).

Complexity: High > Due to the possible number of selection/filter criteria, and the ways in which they could impact one another. Uncertainty: Low > The acceptance criteria are clearly defined and understood.

---

Dependencies:

• none highlighted, at this stage

Tasks:

• [x] TBD [ @? ]

Done

• [x] Acceptance Criteria pass
• [x] Designs are up-to date
• [x] Unit Tests pass
• [x] Integration Tests pass
• [x] Code Style & Coverage meets standards
• [x] Changes made to config (default.json) are broadcast to team and follow-up tasks added to update helm charts and other deployment config.
• [x] TBD

Pull Requests:

• [x] TBD

Follow-up:

• N/A

Accountability:

• Owner: TBC
• QA/Review: TBC

[koekiebox]

Example of Settlement batch allocation, lookup and matrix view. All required criteria met.

Transfer deterministically allocated in settlements to a batch:

Settlement Batch allocated to settlement model:

Currency associated with the batch. The matrix itself could reference multiple currencies.

Test cases:

https://github.com/mojaloop/settlements-bc/blob/7c55c3cc4bc483e9145a5052afe85d2661709fb2/packages/domain-lib/test/unit/index.test.ts#L1015