Understand Delivery Note data retention and uninstall risk
Plan retention around invoices, signed evidence, events, public links and module removal. 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 goOrganisation retention process → Admin Area → Delivery Note
What you’ll accomplish
Plan retention around invoices, signed evidence, events, public links and module removal. This guide follows the supplied Delivery Note module’s live hooks, controller actions, model rules, views and stored side effects.
Follow these steps
- Identify open, signed and void records subject to retention.
- Export or retain approved PDFs and related invoice evidence.
- Protect public tokens and signature data during storage or transfer.
- Decide whether deactivation or uninstall is appropriate.
- Document the approval and verification outcome.
Fields and options to review
- Delivery note row and snapshots
- Signature image/hash/IP/user agent/time
- Event timeline
- Related core invoice
- Generated PDFs are streamed, not stored as module file records
Rules the system enforces
- Deactivation preserves tables; uninstall drops them.
- The module has no built-in retention schedule, legal hold, archive or anonymisation workflow.
- Voiding does not erase data.
- Core invoices remain after uninstall but module evidence does not.
How to confirm it worked
- Retention decisions are made explicitly before any destructive module lifecycle action.
Safety checks and troubleshooting
- Apply legal and organisational retention requirements; this guide does not replace professional advice.
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.