Understand the Delivery Note database tables
Map the module-owned records and fields used by every controller workflow.
Exact navigationServer database administration → Britixo CRM database → Delivery Note tables
What this guide covers
Map the module-owned records and fields used by every controller workflow. This guide follows the supplied Delivery Note module’s live hooks, controller actions, model rules, views and stored side effects.
Exact step-by-step process
- Inspect the prefixed delivery_notes table.
- Identify the source invoice/client IDs and unique reference/token.
- Review snapshot JSON, delivery fields and status.
- Review signature evidence and timestamps.
- Inspect the prefixed delivery_note_events rows linked by delivery_note_id.
Fields, choices and supported possibilities
- delivery_notes: identifiers, token/reference, status, delivery data, snapshots, signature evidence, audit timestamps
- delivery_note_events: event name/message, IP, user agent, JSON metadata, actor and time
Code-backed validations and workflow rules
- The module does not modify the core invoices table.
- Reference and token are unique; invoice/client/status are indexed.
- Status default is open.
- Events are dependent evidence but no database foreign-key cascade is declared in the installer.
Expected result and verification
- Technical teams can diagnose module behaviour without confusing module-owned data with core invoice data.
Checks, security and troubleshooting
- Read-only inspection is preferred; direct edits can break signing and audit consistency.
Stay within the supported flowDo not force database values, expose secure tokens, bypass permission checks, replace a stored signature or invent a status or interface that the supplied code does not implement.