why “InsuranceNumber” field in PaymentDetail (matching is via Contribution, not insuree…)?
in TZ, payment type “F” is related to funding (not contributions)… should we filter in this module (as we do filter the ‘funding’ --aka fake-- family)?
Business logic and data access layer
Main files in the legacy are:
PremiumDAL & PremiumBL
PaymentDAL & PaymentBL
Mostly CRUD logic, some easy validations, 3 calls to usp detailed below.
→ Will migrate “as-is”
Policy (status) update on contribution payment received
Once payment(s) is (are) received and cover the expected contribution(s) amount (and the policy value), policy status changes and become either (based on tblIMISDefaults.ActivationOption ‘legacy’ parameter):
Note: from the policy form/searcher, users also probably need to be able to ‘interactively’ switch from ‘Ready’ to ‘Active’ (missing mutation in policy module ?).
→ We’ll add into the policy module a listener on “savePayment” so that on payment save, if the payment match the contribution we’ll be able to update (if needed) the contribution status.
Logic in Stored Procedures
IN SCOPE as relative to contribution/payment and used
uspAddFund in PremiumDAL
+/- 200 lines of PSQL
Check if given product is valid
Get Product's details
Check if the Family with CHFID 999999999 exists in given district
Check if funding District,Ward and Village exists
Insert Insuree Policy
Insert Premium (Fund)
uspLastDateForPayment in PremiumDAL
+/- 40 lines of PSQL
uspMatchPayment in PaymentDAL
+/- 400 lines of PSQL
GET ALL UNMATCHED RECEIVED PAYMENTS
1. Insurance number is missing on tblPaymentDetails
2. Product code is missing on tblPaymentDetails
2. Insurance number is missing in tblinsuree
1. Policy/Prevous Policy not found
3. Invalid Product
4. Invalid Officer
4. Invalid Officer/Product Match
5. Premiums not available
DELETE ALL INVALID PAYMENTS
DISTRIBUTE PAYMENTS EVENLY
INSERT ONLY RENEWALS
Specific logic for SELF PAYER (stage R no office) or contribution without payment (Stage N status @ready with office)
Those are the only procedures in the scope. All others (concerning extracts and reports or standalone ones not used by the web servers) are going to be Out of scope.
We’re mostly following the existing structure with two divergences:
We introduce dedicated screens for payments (absent in the current system), including creation and matching to contribution. This allows to have a full loop working using the interface (up to payment and matching to contribution, and as such possibly policy status update).
We change the link from contribution list to contribution details, instead of the family one - this is very surprising when using. We’ll add a link toward the family screen to keep the current flow possible
Update: selecting a specific contribution will lead to contribution details (not to family screen as now). We’ll add a direct link to familiy (as exists already in other table) but it won’t be the “main” activity on click.