mfl lap docs

docs/MFL/LAP/Disbursement module/Deductions.md

@@ -0,0 +1,90 @@
+<h2>Deductions Logic</h2>
+
+<table border="1" cellpadding="8" cellspacing="0">
+  <thead>
+    <tr>
+      <th>Deduction Type</th>
+      <th>Deduction Amount (Value / Formula / Logic)</th>
+      <th>When Applicable</th>
+      <th>When Adjusted</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>Processing Fee</td>
+      <td>
+        PF Amount = {(Loan Amount × (PF % / 100)) × 1.18}<br/>
+        Amount inclusive of 18% GST<br/>
+        PF % entered by BCM in Loan Offer module
+      </td>
+      <td>All loans</td>
+      <td>At disbursal</td>
+    </tr>
+    <tr>
+      <td>E-stamp Charge</td>
+      <td>
+        ₹38 (if agreement signing done online)<br/>
+        ₹0 (if agreement signing done offline)
+      </td>
+      <td>Only when agreement signing done online</td>
+      <td>At disbursal</td>
+    </tr>
+    <tr>
+      <td>Insurance Charges</td>
+      <td>Total insurance premium (inclusive of 18% GST)</td>
+      <td>All loans</td>
+      <td>At disbursal</td>
+    </tr>
+    <tr>
+      <td>Stamp Duty</td>
+      <td>
+        State-based charge (refer state-wise stamp duty master)<br/>
+        ₹0 (if agreement signing done offline)<br/><br/>
+        <em>Note: State is derived from branch details of the RO who punched the case</em>
+      </td>
+      <td>Only when agreement signing done online</td>
+      <td>At disbursal</td>
+    </tr>
+    <tr>
+      <td>CERSAI Charge</td>
+      <td>
+        ₹118 (if sanctioned loan amount &gt; ₹5 lakhs)<br/>
+        ₹59 (if sanctioned loan amount ≤ ₹5 lakhs)
+      </td>
+      <td>All loans</td>
+      <td>At disbursal</td>
+    </tr>
+    <tr>
+      <td>Initial Login Fee</td>
+      <td>
+        ₹1,180 (IMD amount – currently constant)<br/>
+        Collected upfront during customer journey
+      </td>
+      <td>All loans</td>
+      <td>Not adjusted from disbursal</td>
+    </tr>
+    <tr>
+      <td>Login Fee Deductible</td>
+      <td>
+        ₹4,720 (if sanctioned loan amount &gt; ₹10 lakhs – constant)<br/>
+        ₹2,950 (if sanctioned loan amount ≤ ₹10 lakhs – constant)
+      </td>
+      <td>All loans</td>
+      <td>At disbursal</td>
+    </tr>
+  </tbody>
+</table>
+
+<p><strong>All amounts mentioned are in Indian Rupees (₹).</strong></p>
+
+<h3>Important Notes</h3>
+<ul>
+  <li>Broken Period Interest (BPI) is <strong>not</strong> treated as a deduction in LOS.</li>
+  <li>BPI is not shown in deduction summary and is excluded from Net Payment Amount calculation.</li>
+  <li>BPI is not sent to LMS createLoan API under disbursal charge details.</li>
+  <li>Deductions are not deducted from first tranche or first split payment.</li>
+  <li>Deductions are applied on <strong>Sanctioned Loan Amount</strong> to derive <strong>Net Payment Amount</strong>.</li>
+  <li>CO enters tranche amounts based on Net Payment Amount.</li>
+  <li>Sum of all tranche amounts must equal Net Payment Amount (logic change pending implementation).</li>
+  <li>Deduction charge details passed in LMS createLoan API are used by LMS to credit the total deduction amount to MFL bank account at disbursal.</li>
+</ul>

docs/MFL/LAP/Disbursement module/Disbursal ready stage: 1st tranche.md

@@ -0,0 +1,111 @@
+<h2>Disbursal Ready Stage: CO</h2>
+
+<ul>
+  <li>Application in <strong>Ready for Disbursal</strong> stage is auto-assigned to the same CO who forwards the case from <strong>Loan Sanctioned</strong> stage and reflects in that CO’s queue.</li>
+  <li><strong>Net Payment Amount</strong> = Sanctioned Loan Amount − Total Deductions (refer separate product note on deductions).</li>
+</ul>
+
+<h3>Disbursement Request Creation</h3>
+<ul>
+  <li>CO can create a disbursement request in the <strong>Ready for Disbursal</strong> stage based on Net Payment Amount.</li>
+  <li><strong>Single Tranche</strong>: Tranche amount is auto-populated and equals Net Payment Amount.</li>
+  <li><strong>Multi Tranche</strong>:
+    <ul>
+      <li>CO enters tranche amount.</li>
+      <li>Each tranche amount must be ≤ Net Payment Amount.</li>
+      <li>Sum of all tranche amounts must equal Net Payment Amount.</li>
+    </ul>
+  </li>
+  <li>CO can select only the <strong>current date</strong> as disbursement date. Past or future dates are not allowed.</li>
+</ul>
+
+<h3>Payment Details</h3>
+<ul>
+  <li>CO selects payment type:
+    <ul>
+      <li>Single Payment Advice</li>
+      <li>Multiple Payment Advice (Split Payments)</li>
+    </ul>
+  </li>
+  <li>For single payment advice, amount is auto-set as tranche amount.</li>
+  <li>For multiple payment advice, sum of all split payments must equal tranche amount.</li>
+  <li>Allowed payment modes:
+    <ul>
+      <li>Electronic Fund Transfer (NEFT / RTGS)</li>
+      <li>Cheque</li>
+    </ul>
+  </li>
+  <li>For EFT:
+    <ul>
+      <li>Payment &lt; 2 lakhs → NEFT only</li>
+      <li>Payment ≥ 2 lakhs → RTGS only</li>
+      <li>Sub-mode auto-selected based on amount</li>
+      <li>Ops selects one customer bank account (currently only penny-drop verified account available)</li>
+    </ul>
+  </li>
+  <li>For Cheque:
+    <ul>
+      <li>Ops enters “In Favour Of” details</li>
+      <li>No bank account details collected</li>
+      <li>Penny-drop account number is passed to LMS createLoan API</li>
+    </ul>
+  </li>
+  <li>Since penny drop is performed on only one account, the same account is used for all split payments and passed to LMS.</li>
+</ul>
+
+<ul>
+  <li>Disbursement request creates a disbursement task. Application stage remains <strong>Ready for Disbursal</strong> until tranche is disbursed.</li>
+  <li>After disbursement:
+    <ul>
+      <li>Single tranche → Application moves to <strong>Fully Disbursed</strong></li>
+      <li>Multi tranche → Application moves to <strong>Partially Disbursed</strong></li>
+    </ul>
+  </li>
+  <li>CO can edit or delete the disbursement request as long as the task is in CO’s queue.</li>
+  <li>CO cannot create another disbursement request if an active disbursement request exists.</li>
+  <li>CO can send the disbursement task to BPO.</li>
+</ul>
+
+<hr/>
+
+<h2>Disbursal Ready Stage: BPO</h2>
+
+<ul>
+  <li>Disbursement task appears in BPO pool.</li>
+  <li>BPO Manager can self-assign or assign the task to BPO child users.</li>
+  <li>BPO child users can only self-assign the task.</li>
+  <li>BPO completes checklist questionnaires under:
+    <ul>
+      <li>Primary Verifications tab</li>
+      <li>Checklist tab</li>
+    </ul>
+  </li>
+  <li>BPO can send the task to Ops. Hard stop applies if checklist is incomplete.</li>
+  <li>BPO can send the task back to CO.</li>
+</ul>
+
+<hr/>
+
+<h2>Disbursal Ready Stage: Ops</h2>
+
+<ul>
+  <li>Disbursement task appears in Ops pool and must be self-assigned.</li>
+  <li>Ops completes checklist questionnaires under:
+    <ul>
+      <li>Primary Verifications tab</li>
+      <li>Checklist tab</li>
+    </ul>
+  </li>
+  <li>Ops can edit disbursement date:
+    <ul>
+      <li>Allowed dates: T, T-1, T-2</li>
+      <li>If CO-selected date is older than T-2, Ops must reselect</li>
+    </ul>
+  </li>
+  <li>Selected disbursement date must be ≤ LMS business date. FinBox validates this.</li>
+  <li>If LMS date validation fails, disbursal reverts to un-initiated state with Ops access restored.</li>
+  <li>Ops approves the disbursement task to trigger LMS handoff.</li>
+  <li>Tranche is marked <strong>Disbursed</strong> once APIs up to Process Instrumentation succeed and LAN is generated.</li>
+  <li>Document upload failures do not block disbursement. Ops handles document upload later in LMS.</li>
+  <li>Ops can send the task back to CO or BPO.</li>
+</ul>

docs/MFL/LAP/Disbursement module/Fully disbursed.md

@@ -0,0 +1 @@
+<p><strong>Fully disbursed</strong> cases appear in the <strong>All cases</strong> tab for all users.</p>

docs/MFL/LAP/Disbursement module/LMSHandoff.md

@@ -0,0 +1,109 @@
+<h2>LMS Handoff</h2>
+
+<h3>First Tranche</h3>
+
+<ul>
+  <li>Ops user has to ‘approve disbursement’ for the active tranche to initiate the LMS handoff on disbursement tab</li>
+</ul>
+
+<h4>Pre-checks/validations</h4>
+<p>
+Pre-checks/validations run on LMS handoff initiation for the first tranche. If any pre-check fails, LMS handoff is blocked:
+</p>
+
+<ul>
+  <li>All sanction conditions should be approved by Ops</li>
+  <li>Ops checklist should be completed</li>
+  <li>Disbursement date should be less than or equal to the LMS business date</li>
+  <li>UCIC should be present for all applicant/co-applicants (fetched from PAN or mobile)</li>
+  <li>“isNPA” flag should be false for all applicant and co-applicants</li>
+  <li>IFSC code should be present in the Bank master</li>
+  <li>Pincode should be present in the Pincode master</li>
+</ul>
+
+<h4>LMS handoff APIs (First Tranche)</h4>
+<p>
+LMS handoff for first tranche initiates the below series of APIs in the following order:
+</p>
+
+<ol>
+  <li>Create Customer - for primary applicant and all co-applicants</li>
+  <li>Process Receipt - For IMD details - This will be moved to journey now just after IMD is paid and not in the disbursal workflow</li>
+  <li>Create Collateral</li>
+  <li>Book Loan</li>
+  <li>Process Instrumentation - For NACH details</li>
+  <li>Create Document - Series of 4 APIs</li>
+</ol>
+
+<h4>LMS Workflow Status</h4>
+<p>
+After LMS handoff is initiated, Ops user gets an option to “check status” of the LMS workflow. List of possible statuses:
+</p>
+
+<ul>
+  <li>“Payment initiated” - When LMS workflow initiated but status not fetched</li>
+  <li>“Failed” - When any any pre-checks fails or any API out of the following fail: createCustomerAPI, createCollateral, bookLoan</li>
+  <li>“Documents pending” - This is a substatus - When first 5 APIs are successful (till Process instrumentation) and Create Document API is in progress (this API might take some time, depends on number of documents)</li>
+  <li>“Document failure” - This is a substatus - When Create Document API fails</li>
+  <li>“Disbursed” - When createCustomer, createCollateral, bookLoan APIs are successful. System doesn't wait for the status of NACH API or createDocument API</li>
+</ul>
+
+<h4>Retrigger Logic</h4>
+
+<ul>
+  <li>Ops user gets an option to retrigger LMS handoff (“retrigger disbursement” button) if the status is “failed”</li>
+  <li>Retrigger option resumes the LMS workflow from the API which last failed</li>
+  <li>Currently there is no option to retrigger from UI if either of NACH/Document APIs fail i.e. after the status of tranche is "Disbursed. Functionality to be added</li>
+  <li>If Create Document API fails due to any document, rest other documents are uploaded</li>
+</ul>
+
+<p>
+If LMS handoff is re-triggered in failure scenarios, following pre-checks are re-run:
+</p>
+
+<ul>
+  <li>Disbursement date should be less than or equal to the LMS business date</li>
+  <li>UCIC should be present for all applicant/co-applicants (fetched from PAN or mobile)</li>
+  <li>“isNPA” flag should be false for all applicant and co-applicants</li>
+</ul>
+
+<hr />
+
+<h3>Second / Subsequent Tranche</h3>
+
+<h4>Pre-checks/validations</h4>
+<p>
+Pre-checks/validations run on initiating LMS handoff for second/subsequent tranches:
+</p>
+
+<ul>
+  <li>Disbursement date should be less than or equal to the LMS business date</li>
+</ul>
+
+<h4>LMS handoff APIs (Second / Subsequent Tranche)</h4>
+<ul>
+  <li>Disbursal API</li>
+</ul>
+
+<h4>LMS Workflow Status</h4>
+<p>
+List of the possible statuses of the LMS handoff for second/subsequent tranches:
+</p>
+
+<ul>
+  <li>Failed</li>
+  <li>Disbursed</li>
+</ul>
+
+<h4>Retrigger Logic</h4>
+<ul>
+  <li>Ops user gets an option to retrigger LMS handoff for second/subsequent tranches if the status is “failed”</li>
+</ul>
+
+<p>
+If LMS handoff is re-triggered in case of failure for second/subsequent tranches, following pre-checks are re-run:
+</p>
+
+<ul>
+  <li>Disbursement date should be less than or equal to the LMS business date</li>
+</ul>

docs/MFL/LAP/Disbursement module/artially Disbursed: Subsequent Tranches.md

@@ -0,0 +1,34 @@
+<h2>Partially Disbursed: Subsequent Tranches</h2>
+
+<h3>Partially Disbursed Stage: CO</h3>
+<ul>
+  <li>CO can locate a partially disbursed case from the <strong>All cases</strong> tab.</li>
+  <li>CO can create a new disbursement request directly from <strong>All cases</strong>. No case or task assignment is required.</li>
+  <li>
+    <strong>Pending Balance</strong> =
+    {Net Payment Amount − Sum of all previously disbursed tranche amounts}
+  </li>
+  <li>CO creates the disbursement request based on the pending balance.</li>
+  <li>Tranche amount cannot exceed the pending balance.</li>
+  <li>Disbursement date, payment mode, and split payment logic are the same as the <strong>Ready for Disbursal</strong> stage.</li>
+  <li>Tranche editing, deletion, and movement are allowed only for the active tranche.</li>
+  <li>These actions are permitted only while the disbursement task is in the CO’s queue.</li>
+</ul>
+
+<h3>Partially Disbursed Stage: BPO</h3>
+<ul>
+  <li>BPO receives a new <strong>BPO checklist questionnaire</strong> on the <strong>Primary Verifications</strong> tab for the active tranche.</li>
+  <li>BPO checklist questionnaires for previous tranches remain in <strong>Completed</strong> state and are non-editable.</li>
+  <li>BPO receives a new <strong>BPO checklist</strong> on the <strong>Checklist</strong> tab for the active tranche.</li>
+  <li>Checklists for previous tranches remain completed and non-editable.</li>
+  <li>Disbursement task movement to Ops or send-back to CO follows the same logic as the <strong>Ready for Disbursal</strong> stage.</li>
+</ul>
+
+<h3>Partially Disbursed Stage: Ops</h3>
+<ul>
+  <li>Ops receives a new <strong>Ops checklist questionnaire</strong> on the <strong>Primary Verifications</strong> tab for the active tranche.</li>
+  <li>Checklist questionnaires for previous tranches remain completed and non-editable.</li>
+  <li>Ops receives a new <strong>Ops checklist</strong> on the <strong>Checklist</strong> tab for the active tranche.</li>
+  <li>Ops checklists for previous tranches remain completed and non-editable.</li>
+  <li>Disbursement date editing rules, LMS handoff trigger logic, and send-back flow to CO or BPO are the same as the <strong>Ready for Disbursal</strong> stage.</li>
+</ul>