# Grants, budgets, finance, and procurement

For step-by-step staff instructions, see [Procurement operator guide](../guides/procurement-operator-guide.md).

This product treats the **grant** as the hub for funded programmes. **Budget lines** sit under grants; **finance** consumes budget through controlled postings; **procurement** (purchase requests, orders, RFQs, goods receipts, supplier invoices) ties spend back to grants where configured.

## Conceptual data flow

```mermaid
flowchart LR
  G[Grant]
  BL[Budget lines]
  GT[Grant transactions / ledger]
  PR[Purchase request]
  PO[Purchase order]
  RFQ[Procurement RFQ]
  GR[Goods receipt]
  SI[Supplier invoice]

  G --> BL
  BL --> GT
  G --> PR
  PR --> PO
  PO --> GR
  PO --> SI
  RFQ --> PO
```

## Simplified ER (core relationships)

```mermaid
erDiagram
  ORGANIZATIONS ||--o{ GRANTS : owns
  GRANTS ||--o{ GRANT_BUDGET_LINES : contains
  GRANTS ||--o{ PURCHASE_REQUESTS : funds
  GRANTS ||--o{ PROCUREMENT_RFQS : optional
  PURCHASE_REQUESTS ||--o{ PURCHASE_ORDERS : becomes
  PURCHASE_ORDERS ||--o{ GOODS_RECEIPTS : receives
  PURCHASE_ORDERS ||--o{ SUPPLIER_INVOICES : billed
  VENDORS ||--o{ PURCHASE_ORDERS : supplies

  GRANTS {
    uuid uuid
    string code
    string status
  }
  GRANT_BUDGET_LINES {
    uuid uuid
    decimal amount
  }
  PROCUREMENT_RFQS {
    uuid uuid
    string status
  }
```

## Procurement RFQ lifecycle (states)

```mermaid
stateDiagram-v2
  [*] --> draft
  draft --> published: staff publishes
  published --> closed: manual close or process
  published --> awarded: bid awarded
  closed --> [*]
  awarded --> [*]
```

## Purchase flow (happy path)

```mermaid
sequenceDiagram
  participant S as Staff
  participant API as Laravel
  participant DB as DB

  S->>API: Create PR on grant line
  API->>DB: insert PR
  S->>API: Approve / convert to PO
  API->>DB: PO + lines
  S->>API: Record goods receipt
  API->>DB: GR
  S->>API: Register supplier invoice
  API->>DB: SI + link to grant txn where applicable
```

## Operational no-backdating (when enabled)

When `organizations.settings.disallow_operational_backdating` is true, several **operational** date fields are validated against **organisation “today”** in `hr_default_timezone` (fallback `app.timezone`). See `App\Support\OperationalDatePolicy`.

```mermaid
flowchart TD
  O[Organisation settings]
  O -->|disallow flag| P[OperationalDatePolicy]
  O -->|timezone| T[Org today Y-m-d]
  P --> V[ValidationException if date in past]
```

For deeper narrative and file index, see [Grant Management System (GMS)](../architecture/gms.md).
