Understand the Delivery Note database tables
Map the module-owned records and fields used by every controller workflow. The guide then takes you through the correct route, the checks to complete before making changes, the workflow in order, and the evidence to review afterwards.
Where to goServer database administration → Britixo CRM database → Delivery Note tables
What you’ll accomplish
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.
Follow these steps
- Inspect the prefixed delivery_notes table.
- Identify the source invoice/client IDs and unique reference/token.
- Check snapshot JSON, delivery fields and status.
- Check signature evidence and timestamps.
- Inspect the prefixed delivery_note_events rows linked by delivery_note_id.
Fields and options to review
- 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
Rules the system enforces
- 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.
How to confirm it worked
- Technical teams can diagnose module behaviour without confusing module-owned data with core invoice data.
Safety checks 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.
Continue with related guidance
Was this guide useful?Your response is stored only in this browser.