Verify the Delivery Note database installation
Confirm the two module tables, indexes and installed options required by the code.
Exact navigationServer database administration → Britixo CRM database → Inspect module-owned tables
What this guide covers
Confirm the two module tables, indexes and installed options required by the code. 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
- Confirm the prefixed `delivery_notes` table exists.
- Confirm the prefixed `delivery_note_events` table exists.
- Verify unique indexes on `reference` and `secure_token`.
- Verify invoice, client and status indexes.
- Check the installed Delivery Note options before functional testing.
Fields, choices and supported possibilities
- Delivery notes table stores invoice/client IDs, reference, token, statuses, snapshots, delivery details and signing evidence.
- Events table stores event type/message, IP, user agent, JSON metadata, actor and time.
- Options include enabled, reference prefix, routes, route mode, schema version, invoice UI flag and PDF footer text.
Code-backed validations and workflow rules
- Table names use the CRM database prefix.
- The installer is idempotent for existing tables/options.
- `signed_by_name`, `signed_by_email` and `locked_at` exist in the schema but are not populated by the supplied signing flow.
Expected result and verification
- Activation has produced the complete portable schema expected by the controllers and model.
Checks, security and troubleshooting
- Do not document or use migration scaffolding as a user workflow; this module installs through `install.php`.
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.
