Check the native options first.
Review your release, existing add-ons and redacted vouchers. Agree whether the reference belongs to the voucher or an individual line.
Tally TDL Development & Customisation
I scope and deliver Tally Definition Language customisations around the way your accounts and factory teams actually work. That can include a job reference on a voucher, an entry check, a job-work report or a dispatch print. We start by checking native configuration, define the saved record behind each field, and test the change alongside existing add-ons before rollout.
Scope, cost and delivery
Check native TallyPrime settings first, then define one TDL customisation and its saved data, test fixtures and rollback plan.
Installed release; existing add-ons; object and field design; report calculations; print variants; upgrade compatibility and support.
The proposal separates discovery, implementation and ongoing support. Software licences, hosting and usage charges are identified separately. We confirm the price against your samples and acceptance criteria before implementation starts.
Indicative planning ranges for the focused scope above, starting once access and samples are ready. These are estimates; the proposal confirms dates and dependencies.
Bring a redacted voucher, the desired output and your installed release. We define how each displayed number ties to the source. The pilot checklist provides a review framework rather than a claim of client performance.
TDL pilot preparation checklist →Before you commit, agree which sample records, screens or reports the pilot must demonstrate and who will accept them. Any before-and-after result needs an agreed baseline and measurement period.
Describe the field, voucher check, report or print format you need, including your Tally release.
Discuss my TDL requirement →Agree a small deliverable, fee and acceptance checks in writing. Review the work, pay after acceptance and decide whether to continue. Remote delivery in English, led by Raghav with The Night Marketer.
TDL report specification example
This is an annotated report design using fictional records, not a screenshot of a deployed TDL add-on. It makes the required behaviour reviewable before coding. No Tally release compatibility is claimed for this example.
Scroll the example table sideways to read every column.
| Report element | Example value | Acceptance check |
|---|---|---|
| Job reference | JOB-DEMO-41 | The same saved reference must appear after entry, alteration, reopening, printing and export. |
| Material sent / received / approved process loss | 100 kg / 72 kg / 3 kg | Use one agreed unit and trace each quantity to a source movement. Do not subtract an unapproved loss. |
| Outstanding material | 25 kg = 100 − 72 − 3 | Show physical receipt separately from quality acceptance. Material on a quality hold is still physically received. |
| Alteration check | Receipt corrected from 72 kg to 70 kg | Outstanding becomes 27 kg in both the report and export. Retain who approved the correction. |
Before deployment, test the implementation against your exact TallyPrime release and existing add-ons. Verify saved field scope, multiple job lines, print overflow, export totals, disabled add-on behaviour and rollback. This fixture verifies the arithmetic only.
To reproduce the offline checks, extract the complete pack and run python3 verify_examples.py in that folder. Python 3 is required; the checker uses no network connection.
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.
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.
Map values to the correct object, define missing-value behaviour and confirm which entry and alteration paths need testing.
Implement the scoped report, layout or control against the installed release. Exercise representative fixtures alongside existing TDLs and add-ons.
Approve the sample outputs, retain a backup and known working package, and document installation, support and upgrade checks.
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.
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.
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.
A redesigned invoice print still has to carry the GST details your invoices need: GSTINs, HSN or SAC codes, the tax breakup and, for e-invoices, the IRN and QR code that TallyPrime prints after generation. Each custom format is checked against those fields on your installed release before it replaces the default print.
| Approach | Good fit | Check before committing |
|---|---|---|
| Native configuration | The required field, filter or print setting is already supported. | Demonstrate the configuration in the actual company before commissioning development. |
| Maintained add-on | An existing solution covers the requirement with suitable support. | Check data ownership, release compatibility, licence scope and how conflicts are resolved. |
| Custom TDL | A specific saved field, validation, report or document remains missing. | Approve the object model, fixture pack, source/package handover and maintenance terms. |
Swipe sideways to see all columns.
Learn about The Night Marketer team and read its Shopify Partner Directory profile.
The pattern behind the request
Adapt the work inside TallyPrime with scoped TDL fields, validations, reports and document layouts, tested against your installed release.
A clear path, not a black box
Define the saved data and the expected output together. A print layout alone cannot resolve an ambiguous reference or a report with no traceable source.
Review your release, existing add-ons and redacted vouchers. Agree whether the reference belongs to the voucher or an individual line.
Develop the field, validation, report or print against approved examples. Check entry, alteration, reopening and export together.
Accounts signs off source totals and document layouts. Record the tested release and repeat the agreed checks before future upgrades.
What gets built
A customisation is accepted when its saved records and output agree across the screens, reports and documents your team uses.
Confirm the gap cannot be handled through an existing configuration option.
Specify record scope, validation and behaviour when the add-on is disabled.
Build the agreed output without expanding the pilot into unrelated customisations.
Compare fresh entries and alterations against the same source fixtures.
Record the tested release, dependencies and a rehearsed recovery procedure.
Direct access, execution depth
I diagnose the problem and stay responsible for the path to delivery. When the work needs design, engineering, SEO, automation, or specialist support, The Night Marketer team adds depth without making you coordinate the room.
Common questions
Custom fields, voucher controls, job and management reports, invoice or dispatch formats, and related workflow changes. The first step is a native-feature review and an example showing what the current system cannot record or display.
We first review the available source, package, ownership and developer support. A compiled package alone may not provide the source needed for a change. Discovery establishes whether to maintain, replace or work alongside the existing customisation.
Compatibility needs testing against the intended release. We retain representative fixtures and define upgrade checks, support responsibility and the procedure for returning to the known working setup.
Yes. External data exchange is covered by the TallyPrime integration service. A project can combine that connection with scoped TDL fields or reports where both are required.
Keep exploring
These are practical reads for understanding the job, asking better questions, and spotting the risks that are easy to miss in a first call.