Make Tally fit the details your team needs to record and review.

What needs a TDL change, and what can native configuration handle?

We inspect the required screen, saved record, report and output before writing TDL. A native setting or existing supported add-on may already solve the problem. Where customisation is needed, the brief identifies whether information belongs on a company, master, voucher, inventory entry or allocation. That placement determines how the value can be entered, printed, exported and reviewed later.

1. Define the working example

   Walk through a real job card, voucher, report or print with the operator and reviewer. Agree what must be captured and what decision it supports.

2. Specify fields and rules

   Map values to the correct object, define missing-value behaviour and confirm which entry and alteration paths need testing.

3. Build and test the change

   Implement the scoped report, layout or control against the installed release. Exercise representative fixtures alongside existing TDLs and add-ons.

4. Deploy with a recovery path

   Approve the sample outputs, retain a backup and known working package, and document installation, support and upgrade checks.

What happens when the normal path breaks?

Illustrative design: a job reference belongs to each inventory allocation because a voucher can contain work for two customer jobs. The custom screen captures the references at that level, and the MIS report groups the same saved allocations. A print with several jobs is tested alongside its export. One voucher-level field repeated against every line would misrepresent the underlying work, even if the screen looked complete.

Fields, reports and documents need one consistent record

A custom field must have a defined owner, unit and meaning. The brief explains what happens when an operator changes a voucher, renames a master, copies a document or leaves a value blank. A report should use the intended saved information rather than guess the job from a description.

For print work, we map every displayed value to its source and agree whether a reprint should use historical or current master information. Acceptance includes long descriptions, multiple pages, split allocations and corrected records. The approved sample is retained with the release and relevant output settings.

Test the paths your team actually uses

An entry-screen check should not be assumed to cover every import or integration. The acceptance pack exercises the routes used by the business: manual entry, alteration, approved imports, print and export where applicable. Reviewers compare expected behaviour with what the installed customisation actually does.

Tally releases can change default definitions. We record the release used for acceptance and the fixtures to rerun before an upgrade. Where a project replaces an older customisation, discovery checks source availability, existing packages and any limits on what can be modified or handed over.

Which implementation approach fits your team?

Swipe sideways to see all columns.

What should you prepare before a pilot?

• Provide the installed Tally release and loaded add-on list.
• Bring redacted vouchers, job cards, reports and desired print samples.
• Identify each required field and its business meaning.
• Agree who approves the report totals and document layout.
• List manual, alteration, import and export paths in use.
• Confirm package/source handover and upgrade support expectations.

Related implementation guides

• Factory job-card custom fields
• Voucher validation controls
• Factory MIS and job-work reporting
• TDL deployment and upgrade checks

Product documentation used during scoping

• User-defined fields and controls
• Objects and collections
• Release 7.1 customisation changes

Learn about The Night Marketer team and read its Shopify Partner Directory profile.