Statutory Data — Forms
Statutory Data — Forms & Input Specification
Reference technical blueprint: statutory.md 7 sub-modules · 13 forms · the legal-records vault of the Trust — every form here carries legal weight and most edits route through two-key cosign.
The Statutory module is where the institution's paper-and-PDF facts are captured: the Trust Deed, every tax registration, every safety/food/professional certificate, the chain of physical custody for originals, secured loans, and the chain-of-title for land and other assets. Forms are deliberately rich in metadata (custody, hashes, link-document chain) and intentionally narrow in workflow — Statutory stores and surfaces; it does not transact.
Every legal-weight edit form in this module presents a mandatory Reason textarea at the bottom. On submit the service layer routes the change through submit_two_key_change; the user receives a "Submitted for cosign" confirmation linking to the pending queue. Direct (non-two-key) writes still emit an AuditEvent automatically via the audit bridge.
Sub-module 1: Trust Registration Profile
Form 1.1 — Trust Registration Profile (the Deed)
Purpose: Captures the founding Trust Deed metadata — the single anchor record that establishes the legal personality of the institution. Exactly one row is normally is_active=true per tenant; older deeds remain queryable as superseded history.
Who fills: Tenant-admin, once at onboarding. Edits are rare (deed amendment, court-ordered correction) and are always two-key.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Registered Trust Name | Text (255) | Yes | Free text; min 3 chars | — | As it appears in the Trust Deed (e.g. Sri Datta Gnana Bodha Sabha) |
| Deed Number | Text (127) | Yes | Free text; alphanumeric + slashes | — | Document/Deed/Registration number assigned by the Sub-Registrar |
| Registration Date | Date | Yes | Past date only; not after today | — | Date the deed was registered |
| Registering Authority | Text (255) | No | — | — | e.g. Sub-Registrar, Mysuru District |
| Place of Registration | Text (127) | No | — | — | City / district where registration was effected |
| Sub-Registrar Office | Text (255) | No | — | — | Specific SRO branch — useful for record retrieval |
| Trust Type | Dropdown | Yes | Public Charitable / Religious / Public Religious / Section 8 Company / Specific Endowment / Other | Public Religious | Statutory classification — drives downstream compliance defaults |
| Parampara | Text (127) | No | — | inherited from organisations.parampara |
Lineage tradition (e.g. Sringeri Sharada) |
| Sampradaya | Text (127) | No | — | inherited from organisations.sampradaya |
Doctrinal school (e.g. Smarta, Sri Vaishnava) |
| Custody Pointer | FK (Document Custody) | No | Link to existing custody record holding the original | — | Where the physical original is kept |
| Notes | Textarea | No | — | — | Any context — e.g. "founding trustees deceased; new board sworn 2018" |
| Reason | Textarea | Yes (on edit) | min 20 chars | — | Required for every edit; visible to cosigner |
Submit action: Creates trust_registrations row with is_active=true. On edit, routes through two-key (audit coverage marks update and delete as two-key for this entity). A successful cosign deactivates the prior row by setting superseded_by_id and superseded_reason.
Related forms: Document Custody Locator (1.2 of Sub-module 4) is usually created first so the deed can point to it; Tax Registration entries (Sub-module 2) follow.
(Workflow note: First-time tenant onboarding goes Custody first → Trust Registration → Tax Registrations → Certificates → Loans → Acquisitions. Once active, the Trust Registration card sits read-only on the module landing page; the only edit path is via a deed amendment, which creates a new row referencing the prior via superseded_by_id.)
Sub-module 2: Tax Registrations
Form 2.1 — Tax Registration Entry (12A · 80G · FCRA · PAN · TAN · GSTIN · PT)
Purpose: Records each tax-side statutory registration the trust holds. One unified form with a kind selector that progressively reveals kind-specific extras (FCRA bank fields, GSTIN state code, etc.).
Who fills: Tenant-admin. Once per registration; renewal goes via Form 2.2.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Kind | Dropdown | Yes | 12A / 80G / FCRA / PAN / TAN / GSTIN / PT (Professional Tax) / Other | — | Drives validation and which extra fields appear |
| Certificate Number | Text (127) | Yes | Format-checked per kind: PAN = [A-Z]{5}\d{4}[A-Z]; TAN = [A-Z]{4}\d{5}[A-Z]; GSTIN = 15-char regex; FCRA = 9 digits |
— | The number printed on the certificate |
| Issued On | Date | No | Past date only | — | Date of issue. Leave blank for perpetual registrations where unknown |
| Expires On | Date | No | After Issued On if both set | — | Leave blank for perpetual (PAN, TAN). 12A/80G/FCRA = 5 years; FSSAI tied here too if PT renewable |
| Issuing Authority | Text (255) | No | — | — | e.g. Commissioner of Income Tax (Exemption), Bengaluru |
| Jurisdiction | Text (127) | No | — | central for FCRA/PAN/TAN; state for PT/GSTIN | Helps filtering reports |
| Is Active | Toggle | Yes | true / false | true | Set false only when explicitly superseded |
| (if FCRA) FCRA Bank Account Number | Text (40) | Yes when kind=FCRA | Numeric; FCRA mandates SBI Main Branch, New Delhi from 2020 | — | The dedicated FCRA bank account |
| (if FCRA) FCRA Bank Name | Text (127) | Yes when kind=FCRA | — | State Bank of India | Should always be SBI Main NDMB post-2020 |
| (if FCRA) FCRA Branch Address | Text (511) | No | — | New Delhi Main Branch, Sansad Marg | Full branch address as on the FCRA portal |
| (if GSTIN) GST State Code | Text (4) | Yes when kind=GSTIN | First two digits of GSTIN; numeric 01-37 | — | Auto-extracted from GSTIN if possible |
| (if GSTIN) GST Filing Frequency | Dropdown | Yes when kind=GSTIN | monthly / quarterly | monthly | Determines whether GSTR-1/3B obligations materialise monthly or quarterly |
| Custody Pointer | FK (Document Custody) | No | — | — | Where the original certificate is held |
| Notes | Textarea | No | — | — | Any quirks — e.g. "renewal in process; ack number XYZ" |
| Reason | Textarea | Yes on edit | min 20 chars | — | For two-key cosign |
Submit action: Creates tax_registrations row. Tenant-scoped uniqueness on (kind, certificate_number). On creation, the Compliance module's materialise_obligations_for_tenant is invoked so applicable obligations (e.g. FC-4 for new FCRA, GSTR-3B for new GSTIN) get seeded automatically.
Related forms: Form 2.2 (Renewal) creates a successor row; Compliance Renewal Calendar Entry (compliance Form 3.1) auto-materialises if expires_on is set.
Form 2.2 — Tax Registration Renewal
Purpose: Captures a renewed certificate (typically 12A / 80G / FCRA on 5-year cycles) without losing the prior row's history. Who fills: Tenant-admin, when a renewal is issued.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Replaces (Old Registration) | FK (Tax Registration) | Yes | Must be an existing is_active=true row of same kind |
auto-selected from context | The certificate being renewed |
| New Certificate Number | Text (127) | Yes | Format per kind | — | The new number on the renewed certificate |
| New Issued On | Date | Yes | Past or today; not before old issued_on |
today | Date of renewal issuance |
| New Expires On | Date | Yes for renewable kinds | After New Issued On | New Issued On + 5 years | Auto-suggested per kind cycle |
| New Issuing Authority | Text (255) | No | — | copied from old row | Often unchanged across renewals |
| New Custody Pointer | FK (Document Custody) | No | — | — | Where the new original is held; usually the same custody record gets updated |
| Reason | Textarea | Yes | min 20 chars | "Renewal of [kind] for [period]" | Cosign-visible |
Submit action: Creates a new tax_registrations row with replaces_id linking back to old row; flips old row to is_active=false. Closes the corresponding RenewalCalendar entry if one exists. Two-key.
Related forms: Closes Compliance Renewal Calendar Entry (Form 3.x).
Sub-module 3: Statutory Certificates
Form 3.1 — Certificate Entry (Fire-Safety · FSSAI · PT · Lift · Pollution · Building Plan)
Purpose: Captures non-tax statutory certificates that authorise the institution to operate. Often per-branch (fire safety per ashrama building, FSSAI per kitchen). Who fills: Tenant-admin or branch-admin (only for own branch). Each certificate, once.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Kind | Dropdown | Yes | fire-safety / fssai / professional-tax / pollution-noc / environmental / building-plan / lift-safety / lightning-arrester / noc / other | — | What kind of certificate |
| Title | Text (255) | Yes | min 5 chars | — | Free-text label e.g. Fire NOC — Mysuru Ashrama Main Block |
| Certificate Number | Text (127) | No | — | — | Some certificates (Pollution NOC) lack numbers; allow blank |
| Issuing Authority | Text (255) | No | — | — | e.g. Karnataka State Fire & Emergency Services |
| Issued On | Date | No | Past or today | — | Date of issue |
| Expires On | Date | Yes for renewable kinds | After Issued On | Issued On + 1 year (FSSAI: 1y/3y/5y per slab) | Most certs are annual; FSSAI varies |
| Branch | FK (Branches) | No | Tenant's branches | inherited from logged-in branch context | Leave blank only for tenant-level certs |
| Custody Pointer | FK (Document Custody) | No | — | — | Where the original is held |
| Is Active | Toggle | Yes | true / false | true | — |
| Notes | Textarea | No | — | — | e.g. "conditional NOC — fire-extinguisher inspection due Q3" |
| Reason | Textarea | Yes on delete | min 20 chars | — | Two-key on delete only |
Submit action: Creates certificates row. Triggers compliance.plan_renewals if expires_on is set, materialising a RenewalCalendar entry. Audit-logged on every change; two-key only on delete (the assumption being that a certificate edit is correcting a typo, while a delete is removing a legal record).
Related forms: Renewal flow mirrors Tax Registration Renewal (Form 2.2) but at /api/statutory/certificates/{id}/renew. Custody (4.1) usually pre-exists.
Form 3.2 — Certificate Renewal
Purpose: Records a renewed certificate, preserving the chain. Who fills: Tenant-admin or branch-admin (own branch).
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Replaces (Old Certificate) | FK (Certificate) | Yes | Existing is_active=true of same kind & branch |
auto-selected | The one being renewed |
| New Certificate Number | Text (127) | No | — | — | New number if any |
| New Issued On | Date | Yes | Past or today | today | — |
| New Expires On | Date | Yes | After New Issued On | per kind | — |
| New Custody Pointer | FK (Document Custody) | No | — | inherits from old row | — |
| Inspection Conditions | Textarea | No | — | — | Any conditional clauses (common in fire NOC) |
| Reason | Textarea | Yes | min 10 chars | "Annual renewal" | — |
Submit action: Creates successor with replaces_id; deactivates old. Closes the matching RenewalCalendar entry.
Related forms: Compliance Renewal Calendar Entry closes.
Sub-module 4: Document Custody
Form 4.1 — Document Custody Locator
Purpose: Records where the physical original of a legal document lives: which branch, which building, which room, which locker, which shelf. One custody record may anchor multiple legal documents (locker holds Trust Deed + 12A + 80G together). Who fills: Tenant-admin during onboarding; tenant-admin or designated archivist on changes.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Title | Text (255) | Yes | min 5 chars | — | Free-text label e.g. Trust Deed Original (1985) or Mysuru Ashrama Main Locker |
| Branch | FK (Branches) | No | — | logged-in branch | Where the locker physically is |
| Building Code | Text (20) | No | Asset Mgmt building masters: RSK / GK / BK / NM / OFC | — | Soft-validates against Asset Mgmt; warns if unknown but does not block |
| Room or Office | Text (127) | No | — | — | e.g. Trustee Office, Strong Room |
| Locker ID | Text (64) | No | — | — | e.g. SBI Locker A-117, Internal Safe-3 |
| Shelf or Drawer | Text (64) | No | — | — | Granular within the locker |
| Physical Location (free text) | Text (511) | No | — | — | Fallback narrative if structured fields don't cover it |
| Custodian (User) | FK (Users) | No | Active tenant users | — | Pick if the custodian has an Aayojana login |
| Custodian (Free Text Name) | Text (255) | No | Required if Custodian (User) blank | — | For custodians not yet in Aayojana — e.g. Sri Ramanatha Bhattaru, Trustee |
| Is PII-Bearing | Checkbox | No | — | unchecked | Tick if scan contains Aadhaar, bank account, signatures — triggers stricter download audit |
| Verification Cadence (months) | Number | No | 1–60 | 12 | How often a sight-verification is required |
| Last Verified On | Date | No | Past or today | — | Auto-set by Verify-Now action |
| Next Verification Due | Date | No | Auto-computed = Last Verified + Cadence | auto | Read-only when cadence and last-verified are set |
| Notes | Textarea | No | — | — | Access instructions, locker keyholders, etc. |
| Reason | Textarea | Yes on locker / custodian change | min 20 chars | — | Two-key triggers when locker_id or custodian_user_id changes |
Submit action: Creates document_custody row. On edit, two-key only triggers if the changed columns include locker_id, custodian_user_id, or physical_location — moving an original is a legally significant event. Other field edits log passively.
Related forms: Used as a custody pointer by Trust Registration (1.1), Tax Registration (2.1), Certificate (3.1), Bank Loan (5.1), Asset Acquisition (6.1), and Compliance Filing acknowledgement scans.
Form 4.2 — Custody Verification (Verify-Now)
Purpose: Record a periodic sight-check that the physical original is still where the custody record says it is. Who fills: Custodian, archivist, or tenant-admin — typically annually.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Custody Record | FK (Document Custody) | Yes | — | from page context | — |
| Verifier (User) | FK (Users) | Yes | Logged-in user (locked) | current user | Cannot verify on behalf of another |
| Verified On | Date | Yes | Today only | today | Cannot back-date a verification |
| Cadence Months | Number | No | 1–60 | inherits from custody row | Bumps next-due |
| Sight-Check Outcome | Dropdown | Yes | Original sighted intact / Original sighted with damage / Original NOT found | Original sighted intact | If "NOT found", flags suspicious activity for audit review |
| Notes | Textarea | No | — | — | Damage description, missing-item context |
Submit action: Updates custody row's last_verified_on=today, last_verified_by_user_id=verifier, next_verification_due=today + cadence. If outcome is "NOT found", emits a high-priority AuditEvent and dispatches an alert to all tenant-admins.
Related forms: Surfaces back into the Custody-Verification-Overdue dashboard.
Form 4.3 — Document Scan Upload
Purpose: Attach a soft-copy PDF/image to a custody record, with content hash for tamper detection. Who fills: Tenant-admin; sometimes module-admin with explicit grant.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Custody Record | FK (Document Custody) | Yes | — | from page context | — |
| File | File upload | Yes | PDF, JPG, PNG, TIFF; max 25 MB; multi-page must be merged into single PDF | — | Hard cap at 25 MB |
| Document Type Hint | Dropdown | No | Trust Deed / Tax Cert / Renewal Ack / Sale Deed / Certificate / Other | — | Used for filename templating in GCS |
| Page Count | Number | No | Auto-extracted | auto | Read-only after upload |
| Is PII-Bearing | Checkbox | No | — | inherits from custody row | If new scan reveals PII not previously marked, tick to upgrade |
| Notes | Textarea | No | — | — | e.g. "scan post-restoration; original water-damaged" |
| Reason (if replacing existing scan) | Textarea | Conditional | min 20 chars when replacing | — | Two-key when overwriting an existing scan |
Submit action: Streams file to GCS at gs://aayojana-statutory/{tenant_id}/{custody_id}/{sha256}.{ext}. Computes SHA-256, stores scan_gcs_path, scan_sha256, scan_uploaded_at, scan_size_bytes on the custody row. Audit-logs the upload.
Related forms: Available from any Statutory detail page that has a custody pointer.
Sub-module 5: Bank Loans
Form 5.1 — Bank Loan Record
Purpose: Captures the legal record of a loan agreement — distinct from Vitta's payable ledger which tracks balance and EMI postings. This form holds the deed-level facts: lender, principal, security pledged. Who fills: Tenant-admin only. Always two-key (create, update, and delete).
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Lender Name | Text (255) | Yes | — | — | e.g. State Bank of India |
| Lender Branch | Text (255) | No | — | — | Specific branch that holds the agreement |
| Loan Account Number | Text (64) | Yes | — | — | As assigned by the lender |
| Loan Kind | Dropdown | Yes | building / vehicle / working-capital / equipment / mortgage / other | — | Drives downstream reporting |
| Purpose | Textarea | No | — | — | What the funds are for — e.g. Construction of Annadana Hall, Mysuru Ashrama |
| Principal Amount (INR) | Decimal | Yes | > 0; up to 18 digits with 2 decimals | — | Sanctioned principal |
| Interest Rate (%) | Decimal | No | 0 – 100; 4 decimals | — | Annualised rate |
| Interest Type | Dropdown | No | fixed / floating | fixed | — |
| Tenure (months) | Number | No | 1 – 360 | — | — |
| EMI Amount (INR) | Decimal | No | ≥ 0 | auto-calc if principal/rate/tenure all set | — |
| EMI Due Day | Number | No | 1–31 | — | Day of month EMI is debited |
| Sanctioned On | Date | No | Past or today | — | — |
| Disbursed On | Date | No | After Sanctioned On | — | — |
| First EMI On | Date | No | After Disbursed On | — | — |
| Status | Dropdown | Yes | sanctioned / active / restructured / closed / defaulted | active | — |
| Security Kind | Dropdown | No | mortgage-property / hypothecation / pledge / unsecured / guarantee | — | What backs the loan |
| Security Description | Textarea | No | — | — | Free-text: which property, what value, etc. |
| Linked Asset Acquisition | FK (Asset Acquisition Records) | No | — | — | If a specific land/building is the mortgaged security |
| Custody Pointer | FK (Document Custody) | No | — | — | Where the loan agreement original is filed |
| Notes | Textarea | No | — | — | — |
| Reason | Textarea | Yes | min 20 chars | — | Two-key on every create/update/delete |
Submit action: Routes through submit_two_key_change; creates PendingWrite. On cosign, the bank_loans row is created. Vitta is notified via service-layer hook so it can pre-populate the loan ledger.
Related forms: Bank Loan Closure (5.2); Asset Acquisition Record (6.1) is often referenced for security.
Form 5.2 — Bank Loan Closure
Purpose: Records that a loan has been fully repaid and the mortgage/hypothecation released. Who fills: Tenant-admin. Two-key.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Loan Record | FK (Bank Loan) | Yes | Loans with status='active' |
from page context | — |
| Closed On | Date | Yes | Past or today; ≥ first EMI date | today | Date of final payment / closure letter |
| Closure Letter Custody | FK (Document Custody) | No | — | — | Where the no-dues letter is filed |
| Security Released | Checkbox | Yes | — | unchecked | Confirm mortgage discharge / lien release |
| Closure Reason | Textarea | Yes | min 30 chars | — | "Loan fully repaid" / "Restructured into new account #X" / etc. |
Submit action: Two-key. On cosign, sets status='closed', closed_on. Audit-logs the closure with the reason text.
Related forms: None downstream; Vitta updates its own loan ledger separately.
Sub-module 6: Asset Acquisitions (Chain of Title)
Form 6.1 — Asset Acquisition Record
Purpose: Captures the legal record of how an asset entered the trust — sale deed, gift deed, dedication, court order, allotment. Distinct from the operational asset register: this table is the chain-of-title. Who fills: Tenant-admin only. Always two-key (create, update, delete).
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Asset Kind | Dropdown | Yes | land / building / vehicle / movable / mixed | land | Drives which extra fields appear |
| Title | Text (255) | Yes | min 5 chars | — | Human label — e.g. Sy. No. 234/2 Mysuru — 2.5 acres |
| Acquisition Mode | Dropdown | Yes | purchase / gift / dedication / inheritance / court-order / lease / allotment / exchange | purchase | How the asset was acquired |
| Acquired On | Date | No | Past only | — | Date of transfer |
| Transferor Name | Text (255) | No | — | — | Vendor / donor / dedicator name |
| Transferor Address | Textarea | No | — | — | — |
| (if land) Survey Number | Text (127) | Yes when asset_kind=land | Free-text (state-specific format) | — | e.g. 234/2A (Karnataka), S.F. No. 234/2 (Tamil Nadu) |
| (if land) Extent (Acres) | Decimal | No | > 0; 6 decimals | — | Numeric area |
| (if land) Extent Description | Text (255) | No | — | — | e.g. Wet 2.10 ac + Dry 1.50 ac |
| (if land) Nature of Land | Dropdown | No | Agricultural / Converted Non-Agri / Garden (Thota) / Wet / Dry / Inam / Devasthanam | Agricultural | — |
| (if land) Village or Locality | Text (255) | No | — | — | — |
| (if land) Taluk | Text (127) | No | — | — | — |
| (if land) District | Text (127) | No | — | — | — |
| (if land) State | Text (127) | No | — | — | — |
| Consideration Amount (INR) | Decimal | No | ≥ 0 | — | Sale price; 0 for gifts/dedications |
| Stamp Duty Paid (INR) | Decimal | No | ≥ 0 | — | — |
| Registration Fee Paid (INR) | Decimal | No | ≥ 0 | — | — |
| Registration Office (SRO) | Text (255) | No | — | — | Sub-Registrar Office |
| Deed Book Number | Text (64) | No | — | — | — |
| Deed Volume | Text (40) | No | — | — | — |
| Deed Page | Text (40) | No | — | — | — |
| Deed Serial Number | Text (40) | No | — | — | — |
| Deed Date | Date | No | Past only | — | Date of registration |
| (if land) Mutation Status | Dropdown | No | pending / in-process / mutated / objection / na | mutated | RTC / khata mutation status |
| (if land) Mutation Date | Date | No | After Acquired On | — | — |
| (if land) Last EC On | Date | No | Past or today | — | Encumbrance Certificate last fetched |
| (if land) Next EC Due | Date | No | After Last EC | Last EC + 12 months | — |
| Operational Asset Ref | Text (64) | No | — | — | Soft FK to Asset Mgmt module's lands/buildings/vehicles record |
| Custody Pointer | FK (Document Custody) | No | — | — | Where the deed original is held |
| Notes | Textarea | No | — | — | — |
| Reason | Textarea | Yes | min 30 chars | — | Two-key on every create/update/delete |
Submit action: Two-key. On cosign, creates asset_acquisition_records row. If operational_asset_ref is set, the Asset Management module gets a notification to link back. Compliance auto-schedules an EC-renewal entry if next_ec_due is set.
Related forms: Link Document Append (6.2) for adding prior 30-year deeds; Bank Loan (5.1) may reference this as security.
Form 6.2 — Append Link Document (30-Year Chain)
Purpose: Adds an entry to the chain of prior deeds for a land record — typically required to demonstrate clear title back 30 years for due-diligence purposes. Who fills: Tenant-admin or designated land-records officer. Audit-logged but NOT two-key (it's an append; the parent acquisition record is the legal anchor).
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Acquisition Record | FK (Asset Acquisition) | Yes | Land-kind only | from page context | The parent acquisition |
| Deed Reference | Text (127) | Yes | — | — | e.g. SRO Mysuru Doc 1234/1995 |
| Year | Number | Yes | 1900 – current year | — | — |
| Counterparties (free text) | Text (511) | No | — | — | "From X to Y" narrative |
| Custody Pointer | FK (Document Custody) | No | — | — | Where this prior deed copy is filed |
| Notes | Textarea | No | — | — | — |
Submit action: Appends a JSON object to the parent's link_document_chain array. Audit-logged.
Related forms: Surfaces in the 30-year link-document timeline UI on the Acquisition detail page.
Sub-module 7: Cross-cutting Dashboards & Bulk Tools
Form 7.1 — Expiring-Soon Watchlist Filter
Purpose: Configures the cross-table "what's expiring" dashboard — a read-only filter form, but worth specifying because it's the daily entry point for compliance work. Who fills: Anyone with module-admin or higher. Used continuously.
| Field | Type | Required | Options / Validation | Default | Help |
|---|---|---|---|---|---|
| Within (days) | Number | Yes | 7 / 30 / 60 / 90 / 180 / 365 | 90 | How far ahead to look |
| Include Tax Registrations | Checkbox | No | — | checked | — |
| Include Certificates | Checkbox | No | — | checked | — |
| Include Custody Verifications Overdue | Checkbox | No | — | checked | — |
| Filter by Branch | FK (Branches) | No | Multi-select | all | — |
| Filter by Kind | Multi-select | No | All kinds across tax + certificate domains | all | — |
| Sort By | Dropdown | Yes | Soonest first / Latest first / By kind / By branch | Soonest first | — |
Submit action: Reloads the dashboard with filtered rows (no DB write). Related forms: Each row deep-links to the relevant entity's detail page.
(Module-wide workflow note: Statutory forms cluster around three life-events — onboarding (1.1 → 4.1 → all the way through 6.1), recurring upkeep (4.2, 7.1 daily checks; 2.2 / 3.2 on renewals), and exception handling (5.2 closures, 6.2 historical link-doc append). Every legal-weight write produces a PendingWrite that surfaces in the Audit Trail's /audit/pending queue — see audit forms for the cosigner-side flow. Statutory feeds Compliance: every expires_on on a tax registration or certificate is what generates Compliance's renewal calendar entries via the daily cron_plan job.)