Understand the Delivery Note database tables
Pixie CRM guidance. Follow the route for your workspace, check your role and enabled modules, and verify the result before moving on.
Map the module-owned records and fields used by every controller workflow.
Where to goServer database administration → Pixie CRM database → Delivery Note tables
What this guide helps you do
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
- 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 and limits
- 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.
Check 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.
Related guides
Was this guide useful?Your response is stored only in this browser.