# Approved replacement loans

Run `php yii migrate`. Give PHP private write access to `common/uploads/reloan-agreements` and include this directory in protected backups.

1. Record and CEO-verify the partial repayment against the existing loan.
2. Open that loan and choose **Request reloan**. Resolve any pending repayments first.
3. Specify the agreed replacement start date, new term and payment frequency, reason, and signed agreement/amendment (PDF/JPG/PNG up to 10 MB).
4. Review the proposal's principal, interest and late-fee components, new principal, new term interest, repayment dates and amounts. The request snapshots current lending settings and the original debt at the agreed start date.
5. The CEO downloads the agreement and approves or rejects with a reason. The preparer cannot approve their own request.

Approval transfers all remaining debt into a linked replacement loan. The old loan becomes Replaced, its remaining balance becomes zero through an explicit component transfer, and its verified cash history stays intact. No loan-disbursement or repayment row is created for the transfer. The replacement's start date is the agreement's effective date, not a new cash payout date. New interest is calculated on the explicitly capitalised principal using the snapshotted new-term rate.

Collateral remains at the same branch and storage location. Its pledge is copied into the successor agreement without recording a physical release. Loan pages link predecessor and successor records, and the approved reloan retains its component amounts, agreement, preparer and CEO decision.

If debt or verified payment history changes after proposal submission, approval fails. Reject the stale proposal and prepare a fresh one. Approval also fails for pending repayments, missing custody/evidence, inactive branch, unapplied credit or an existing successor. Retries cannot create another successor. Repayment decisions and reloan approvals acquire the loan lock before reading financial state.

Payments against replaced loans and reversals of their historic payments are blocked. Resolve the replacement chain through a separately authorised workflow before changing predecessor cash history. This phase does not provide a reloan reversal or refinance with additional new cash.

Index table rows now highlight on hover. Click and Enter navigation remain unchanged; no reverted filters or detail styles are restored.

## Verification

Database checks cover updated/stale quotes, self/role approval restrictions, debt component reconciliation, schedule totals, collateral continuity, missing agreements, duplicate approvals, original-payment reversal guards and unchanged cash-disbursement/collection totals. HTTP checks cover queue availability, methods, permissions and predecessor/successor links. Local Python compilation and diff checks are available; PHP runtime checks run in repository CI once published.