Create a replacement Delivery Note after voiding
Follow this guide to use the supported replacement branch when an unsigned note must no longer be used. 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 goAdmin Area → Delivery Note → Void authorised note → Invoices → Open invoice → Create Delivery Note
What you’ll accomplish
Use the supported replacement branch when an unsigned note must no longer be used. This guide follows the supplied Delivery Note module’s live hooks, controller actions, model rules, views and stored side effects.
Follow these steps
- Check the existing note is not signed.
- Invoke the permission-protected void action through the authorised operational method.
- Verify the register shows status Void.
- Go to the source invoice.
- Select Create Delivery Note.
- Enter corrected details and save.
- Retain the void record and its event history for traceability.
Fields and options to review
- Original note remains stored with status void
- Replacement receives a new reference and token
- Source invoice can have historical void records plus one active note
Rules the system enforces
- Signed notes cannot be voided.
- The supplied detail view does not display a Void button, so do not invent one in user instructions; the endpoint/action must be exposed only through an authorised implementation.
- Public access to the void note is blocked.
How to confirm it worked
- A new open note becomes the current invoice-linked note while the voided history remains auditable.
Safety checks and troubleshooting
- Do not delete or overwrite the original record to hide a correction.
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.