feat: add vendor optional fields and configuration hooks

- Implemented VendorOptionalFields component to handle optional vendor details (mobile, email, address) with validation.
- Created useCustomerConfig hook to load optional customer field settings from Sales configuration.
- Developed useProcurementConfig hook to manage Procurement configuration flags.
- Introduced accessConfigApi for managing access configuration settings.
- Added openingBalancesApi for handling opening balances operations.
- Created procurementConfigApi for managing procurement configuration settings.
- Implemented nav-routes for permission-based routing.
- Developed PDF generation for purchase orders with dynamic vendor and item details.
- Added purchase-order tax helpers for tax calculations and formatting.
- Defined types for opening balances and related operations.

docs/02-SECURITY.md

@@ -12,7 +12,7 @@ These are known, deliberately-accepted Phase-1 exposures. Each has a compensatin
 
 | ID | Risk | Why accepted | Compensating control | Revisit trigger |
 |---|---|---|---|---|
-| **AR-01** | **No authorization** — any authenticated user can call any endpoint (post adjustments, confirm GRN, cancel PO, write off stock). | RBAC deferred (FR-X-01), Phase-1 scope. | Authentication required; **immutable audit trail** attributes every action. | First post-Phase-1 hardening → enable RBAC. |
+| **AR-01** | **Authorization is mostly closed.** *(Updated 2026-10-18.)* Per-endpoint RBAC: `[Authorize(Policy = "Nav:…")]` on every controller that changes data or serves sensitive data, with `:Create/:Edit/:Delete/:Approve` action suffixes; the **role is owned by the ERP** (`users.RoleId` → `roles` → `role_permissions`, read per request; AuthHex only authenticates). HRM, sales returns, the audit log and reason-code changes are gated; global search returns only the kinds the role may open; the sidebar no longer bypasses any section; the dashboard has a route guard (`lib/nav-routes.ts`); every mutating cookie request needs the CSRF header; a signed-in non-admin with no branch sees no branch's data. A test (`PermissionCoverageTests`) fails the build if a data-changing endpoint has no Nav policy or names a permission that is not seeded. **Still open:** `View` is stored but not enforced anywhere, `Edit` is enforced on HRM and vendors only (other modules still gate on module access + Create/Delete/Approve, because existing grants would otherwise change meaning); read endpoints on masters are open to any role that can reach the module; `TrackingController`, `NotificationsController`, `SupportTicketsController` sit behind the login only (personal / service-scoped). | Retrofitting `Edit`/`View` on modules that already have grants could lock roles out; needs a grant review first. | Nav policies; **immutable audit trail**; inactive users refused; `PermissionCoverageTests`. | Review role grants, then enforce `Edit` on the older modules. |
 | **AR-02** | **Approvals auto-on** — no value gate on PO or adjustment. | Phase-1 decision (FR-PROC-04, FR-STK-07). | Audit + mandatory reason codes. | Enable adjustment approval first, then PO approval. |
 | **AR-03** | **IDOR** — sequential IDs + no RBAC → a user can access another's document by guessing the ID. | Consequence of AR-01. | Audit trail. | Closed with RBAC. |
 | **AR-04** | **GRN-without-PO** — receive (and value) goods with no order; a fraud vector. | Emergency/direct receipt is useful (FR-GRN-02). | Permission-gated (when RBAC on); flagged for review; audit; cost entered here gets extra scrutiny (see C.3). | With RBAC / policy on direct receipts. |
@@ -20,8 +20,8 @@ These are known, deliberately-accepted Phase-1 exposures. Each has a compensatin
 | **AR-06** | **Localhost dev secrets** in `appsettings.Development.json`. | Local-dev convenience, current phase. | `.gitignore` + localhost only. | Before any shared/staging/prod → User Secrets / env vars; rotate. |
 | **AR-07** | **`getUserDetails` / `LogoutUser` callable without a bearer token** — `GET /api/v1/auth/users/{userId}` and `POST /api/v1/auth/logout` resolve the target user from the URL/payload, not the caller's session, so any anonymous caller can fetch a profile or log out an arbitrary user's sessions by GUID. | Carried over verbatim from AuthHex's own dispatcher contract (API_REFERENCE.md §3) — ERPCore's `AuthController` proxies it as-is rather than silently tightening a contract it doesn't own. | GUIDs are not enumerable; every call is written to `AuthEventLogs` upstream in AuthHex. | Revisit once AuthHex exposes a token-scoped variant, or add ERPCore-side rate limiting / auth requirement ahead of AuthHex. |
 | **AR-08** | **No rate limiting on `AuthController`'s anonymous endpoints** (login, register, refresh, recovery, OTP send/verify) — brute-force and account-enumeration exposure. | Not built in this pass (docs/11 §2.0, added 2026-07-16); AuthHex may rate-limit server-side but ERPCore does not add its own layer yet. | AuthHex's own lockout/backoff (per docs/10 NFR-03), immutable audit trail. | Add ASP.NET Core rate limiting middleware to `AuthController` before any non-local deployment. |
-| **AR-09** | **HRM inherits AR-01 for salary/PII data** — any door-admitted authenticated user can currently view/download any employee's salary figures, payslip, or uploaded documents (NIC scans, contracts). This is a **explicit, flagged decision, not a silent inheritance**: salary/PII is categorically more sensitive than Phase-1 inventory data, and this was called out to the business owner before HRM build started (see `12-BACKEND-HRM.md` A.1). | RBAC still deferred repo-wide; a coarse HR-role door-gate was not made a blocking prerequisite for HRM go-live. | Immutable audit trail (as AR-01); sidebar-visibility hiding of Employees/Attendance/Payroll sections for non-HR roles via the existing `NavItem`/`RolePermission` mechanism (UI-level only, not a server-enforced gate). | **HRM should be the forcing function that enables per-endpoint RBAC ahead of the rest of the system** (see Part D) — salary-data exposure is a materially worse blast radius than inventory data. |
-| **AR-10** | **`AuditLogsController` exposes salary figures** — a `PayrollLine`/`EmployeeSalaryStructure` mutation's `ChangeSet` contains salary amounts; `AuditLogsController` is not RBAC-gated, so any authenticated user can read another employee's salary history via `GET /audit-logs?entityType=PayrollLine&entityId=X`. | Consequence of AR-01/AR-09, specific enough to name on its own rather than leaving implicit. | None beyond authentication today. | Closed with RBAC (Part D), or an interim HRM-specific audit-log access filter. |
+| **AR-09** | **HRM salary/PII data** — *(Closed in code 2026-10-18; effective once migration `PermissionCoverage` is applied.)* HRM now has its own permissions (`hrm`, `hrm.employees`, `hrm.attendance`, `hrm.leave`, `hrm.payroll`, `hrm.reports`, `hrm.settings`). Salary structures, loans, bank details, payslips, payroll runs and the payroll/salary-history reports need `hrm.payroll`; employee records and documents need `hrm.employees`; HR masters are readable by any HR role and changed only with `hrm.settings`. **Behaviour change:** HRM used to be open to every signed-in person; the migration grants the new permissions to administrator roles only, so every other role needs an explicit grant (Settings → Roles). | — | Server-enforced Nav policies; audit trail; tests. | Verify grants after deploy. |
+| **AR-10** | **`AuditLogsController` exposes salary figures** — *(Closed in code 2026-10-18.)* The audit log needs its own permission, `settings.audit-logs` (administrators only until granted), because a pay change's `ChangeSet` carries amounts. The Users screen's per-user activity list uses the same endpoint, so it shows an error for someone who can manage users but not read the audit log. | — | Server-enforced Nav policy. | None. |
 
 ---
 
@@ -128,7 +128,7 @@ Auto-post + no approval + direct write-off = the primary theft/fraud surface. Re
 - [ ] Payroll figures (Gross/Net/Tax/EPF/ETF) are computed **server-side only**; the client never supplies or overrides them
 - [ ] **Payroll Unlock is the highest-risk action in this module** (parallel to C.5's framing of Adjustments) — mandatory reason, heavy audit; treat as the first HRM candidate for real per-endpoint RBAC
 - [ ] Untrusted spreadsheet parsing (`ClosedXML`/`CsvHelper`): packages pinned to current versions, no macro/external-entity execution path enabled
-- [ ] Review note: **AR-01/AR-09/AR-10** apply to every HRM endpoint until RBAC lands
+- [x] HRM endpoints are behind `hrm.*` permissions (AR-09/AR-10 closed 2026-10-18); confirm role grants after the `PermissionCoverage` migration
 
 ---