Putting this workflow into practice? Explore GST & Tally Automation for Delhi NCR Businesses for implementation scope, controls, and next steps.
A dispatch team can save the correct transaction and still send an unusable document. The customer's job reference may be missing, a long item description may cover the quantity, or a reprint may show information that changed after the vehicle left. These are document design and record ownership problems before they are formatting problems.
Tally TDL dispatch print customisation should connect each displayed value to a defined saved field and a clear business meaning. The goal is a document that stores, dispatch and the customer can reconcile to the same movement. The examples below describe work to scope, rather than a ready-made TDL package.
Start with a document field map
Collect the current delivery note, packing list, customer acknowledgement and any accompanying internal job sheet. Mark the fields that teams actually use to identify an order or accept goods. For each field, record its source, level, owner and behaviour when no value exists.
A customer order reference may belong to the voucher. A batch or package reference may belong to an inventory allocation. Printing one voucher-level value against every item can imply that all lines share a reference when they do not. Resolve this before changing the layout.
Tally's documentation on reports and printing in TDL is the starting point for report structure. Its guidance on user-defined fields and controls matters when a required reference is not stored in the standard record. Confirm the actual object context in the customer's version and configuration.
Decide which values are snapshots
A live master description and a dispatch-time description serve different purposes. If an item master changes tomorrow, should a reprint of yesterday's document show the old wording? That is a business decision with an implementation consequence.
Where the requirement is historical reproduction, define the saved snapshot and its retention. Where the requirement is current master information, label it accordingly. Do not promise that a custom print automatically preserves every historical display value. Test both alteration and reprinting with the chosen data design.
The same question applies to addresses, customer part numbers and packaging instructions. A blank value should be visible to the person preparing the document; silently borrowing a value from the previous voucher creates a plausible but incorrect print.
Give every document a defined job
| Document element | Source to agree | Acceptance check |
|---|---|---|
| Customer job reference | Voucher or approved order allocation | Matches the dispatch instruction |
| Item and customer part code | Saved item mapping | Both identify the intended material |
| Quantity and unit | Actual dispatch allocation | Totals reconcile to the saved movement |
| Package detail | Defined package record | No invented package-to-item relationship |
| Revision and reprint marker | Document control rule | Reader can identify the authorised issue |
Do not use a single layout for incompatible purposes simply because it fits on one page. An internal loading sheet may show instructions that should not appear on the customer copy. Specify the intended audience and required fields for each output.
Treat partial deliveries as normal cases
Consider an illustrative order for 500 components dispatched in three lots. Each document needs the quantity in that movement. If the business also wants ordered, previously supplied and balance quantities, define the cutoff and allocations used to calculate them.
A balance printed from today's live order state may differ from the balance that existed when the document was first issued. Label the interpretation and decide whether a historical snapshot is needed. Test a cancelled delivery and a corrected quantity, not just three successful shipments.
For jobs involving multiple customer references, confirm how references are allocated to lines. A header containing several references without an allocation can leave the receiver unable to book the delivery correctly.
Make corrections and reprints understandable
Define who can alter a saved transaction, who can issue a corrected document and how dispatch knows which copy to use. A print button should not itself be treated as approval to change commercial or stock information.
Keep a record of the authorised document revision where the workflow requires it. If an old PDF has already been emailed or printed, changing the source does not recall that copy. The process needs an explicit replacement instruction and an owner for notifying the receiving team through its normal communication channel.
Avoid presenting an internal revision identifier as a substitute for any statutory numbering requirement. Confirm such requirements separately for the document involved. This implementation concerns consistent operational information.
Test the output people will actually use
Use a fixture set containing a long customer name, several item descriptions, a missing optional reference, multiple units and enough lines to force a second page. Inspect the actual PDF and the factory printer output. A screen preview alone will not expose every page-break or margin problem.
Reconcile saved quantities with printed quantities and any export used by the warehouse. Confirm that the last line, totals and acknowledgements remain visible on a multipage document. Test reprinting after a master change and after a permitted voucher correction.
Record the Tally release, loaded customisations, paper size and printer settings alongside the approved sample. That makes a later layout regression reproducible.
Implementation work to scope
- Map every printed field to its saved object and responsible owner.
- Agree historical snapshot, missing-value and partial-delivery behaviour.
- Build the layouts and define correction and reprint instructions.
- Run the document fixture pack through PDF, printer and export outputs.
- Approve representative samples and retain the configuration used to produce them.
The related guide to factory job-card custom fields covers choosing the underlying record. The TDL deployment checklist covers release testing. For a document workflow linked to actual factory records, review Tally and finance automation or share the current document set.
Frequently asked questions
Which record should a dispatch print layout use?
Use the approved transaction and its maintained references for the required document. Agree which company, party, item, quantity and unit each field represents. A print-only calculation should not create a second unsupported version of the transaction.
How should corrected dispatch documents be handled?
Follow an approved correction and reprint process that identifies the document version and the responsible person. Check the underlying record and any downstream references before issuing replacement paperwork. Keep the explanation needed to distinguish the correction from a second dispatch.
Founder, The Night Marketer (Shopify Select Partner). 12+ years of experience and 450+ brands served since 2015.
GST & Tally Automation for Delhi NCR Businesses
I build GST and Tally automation workflows for businesses in Delhi NCR and across India. The work can connect Shopify, marketplaces, billing tools, spreadsheets, CRM, Tally or TallyPrime, and finance review queues with explicit controls for approvals and exceptions.