feat: update kyc tab, branch day register, and dormancy reports

src/app/clients/client-stepper/client-general-step/client-general-step.component.ts

@@ -2432,6 +2432,17 @@ export class ClientGeneralStepComponent implements OnInit, OnDestroy, OnChanges
     { upTo: null, category: 3, label: 'above ₹10 crore' }
   ];
 
+  /**
+   * A numeric rule bound counts as configured only when it is present and above zero.
+   *
+   * Migration 0448 replaced every unset income/turnover NULL with 0.0, so "absent" now arrives as
+   * either. Every comparison in calculatedRisk already pairs its check with `> 0` for that reason;
+   * this keeps the criteria-less test reading the columns the same way.
+   */
+  private static isConfigured(bound: number | string | null | undefined): boolean {
+    return bound != null && parseFloat(String(bound)) > 0;
+  }
+
   /** "Low Risk" / "Medium Risk" / "High Risk" for a category id. */
   riskCategoryLabel(category: number): string {
     if (category === 3) {
@@ -2518,17 +2529,32 @@ export class ClientGeneralStepComponent implements OnInit, OnDestroy, OnChanges
     // Evaluate rules from DB (ordered by orderPosition ASC)
     if (this.riskRules && this.riskRules.length > 0) {
       for (const rule of this.riskRules) {
-        // Skip transaction/AML rules that have no KYC criteria
+        // Only KYC profile rules categorise a customer at onboarding. The same table also holds
+        // ~221 AML transaction-monitoring scenarios ("Large cash transaction", "Additional RFIs
+        // Rule - 91", ...) which describe behaviour and may only fire against posted transactions,
+        // as AML alerts — RBI Master Direction on KYC separates risk categorisation (Section 12)
+        // from transaction monitoring (Section 13). ruleKind, set on the row, is what tells them
+        // apart; it replaced an inference from "this rule has no criteria set", which migration
+        // 0448 silently broke by writing 0.0 over those NULLs. That let rule 91 match a salaried
+        // client on an income band it was never meant to carry and pre-flag them for AML.
+        if (rule.ruleKind === 'AML') {
+          continue;
+        }
+
+        // Backstop for a rule row predating rule_kind: a rule naming no occupation, no legal form
+        // and no income or turnover band constrains nothing, so it would match every customer.
+        // Treat 0 as unset — that is how the comparisons below read it, and what 0448 left behind.
         if (
+          rule.ruleKind == null &&
           rule.legalFormId == null &&
           rule.occupationCategoryCvId == null &&
           rule.occupationCvId == null &&
-          rule.minMonthlyIncome == null &&
-          rule.maxMonthlyIncome == null &&
-          rule.minAnnualIncome == null &&
-          rule.maxAnnualIncome == null &&
-          rule.minAnnualTurnover == null &&
-          rule.maxAnnualTurnover == null
+          !ClientGeneralStepComponent.isConfigured(rule.minMonthlyIncome) &&
+          !ClientGeneralStepComponent.isConfigured(rule.maxMonthlyIncome) &&
+          !ClientGeneralStepComponent.isConfigured(rule.minAnnualIncome) &&
+          !ClientGeneralStepComponent.isConfigured(rule.maxAnnualIncome) &&
+          !ClientGeneralStepComponent.isConfigured(rule.minAnnualTurnover) &&
+          !ClientGeneralStepComponent.isConfigured(rule.maxAnnualTurnover)
         ) {
           continue;
         }
@@ -2576,7 +2602,12 @@ export class ClientGeneralStepComponent implements OnInit, OnDestroy, OnChanges
         return {
           category: rule.riskCategory,
           reason: rule.reason,
-          amlCheckStatus: rule.amlCheckStatus || (rule.riskCategory === 3 ? 'FLAGGED' : 'CLEAR'),
+          // A profile rule sets the risk category; it does not raise an AML flag. High Risk means
+          // enhanced due diligence and a 2-yearly KYC refresh (RBI MD Sections 12 and 38), not
+          // suspicion — an alert belongs to observed transaction behaviour (Section 13), so a
+          // customer who has transacted nothing yet stays CLEAR. A bank that genuinely wants a
+          // rule to flag on match can still say so explicitly via the rule's own amlCheckStatus.
+          amlCheckStatus: rule.amlCheckStatus || 'CLEAR',
           bannedEntityMatch: rule.bannedEntityMatch || 'NO',
           willfulDefaulter: rule.willfulDefaulter || 'NO',
           ecgcSalFlag: rule.ecgcSalFlag || 'NO',