Key takeaways
- Define the rejected condition and recovery action for each rule.
- Distinguish a warning from a blocking validation and an approval decision.
- Verify ordinary entry, copied records, alterations and imports separately.
- Keep rule ownership and exception handling visible after deployment.
Putting this workflow into practice? Explore Tally TDL Development & Customisation for implementation scope, controls, and next steps.
Tally TDL validations are most useful when they catch a specific data problem at the moment an operator can fix it. A generic “invalid entry” message or a mandatory field with no available value creates workarounds. The aim is a small set of explainable checks tied to the factory's actual recording process.
This guide scopes custom entry controls around manufacturing records. It does not assume that a field-level check is a complete approval or security system. The developer and process owner need to verify every relevant path, including alterations and imported transactions.
Start with observed recording mistakes
Use a small sample of real errors supplied by the business, with confidential details removed. Useful candidates include a missing job reference, an operation outside the permitted list or a quantity entered in the wrong unit. Write the business effect of each mistake before requesting code.
Avoid validating a value the operator cannot know. If a reference is assigned only after another team acts, blocking initial entry until it exists may interrupt the entire process. The better design might capture a pending state and create a follow-up task for the responsible team.
Specify the rule in plain language
A rule brief should identify the relevant voucher or object, condition, user message, permitted recovery and owner. Include valid examples and near misses. The developer needs to know whether the rule applies to all companies or only those configured for the process.
| Proposed check | Behaviour to agree | Recovery path |
|---|---|---|
| Missing factory job reference | Block only in the agreed job-related entry flow | Select a valid job or route an unmatched case |
| Unknown operation | Reject or warn according to the process | Request a maintained master value |
| Quantity outside reviewed range | Raise an exception with the source context | Reviewer confirms a reason or correction |
| Unavailable reference source | Display verification failure | Use the agreed controlled fallback |
| Historical blank on alteration | Apply the documented legacy policy | Capture evidence or retain an explicit exception |
The table is an illustrative rule catalogue. It is not a claim that these checks are supplied by default.
- Identify an entry error
- Express the validation rule
- Test all entry routes
- Record authorised overrides
A visual map of this article’s approach. The detailed requirements and exceptions are explained in the surrounding sections.
Choose the right TDL control
Tally's validation and controls reference describes different controls with distinct behaviour. For example, a field validation can prevent progression when its condition fails. Select the mechanism that matches the intended operator journey instead of assuming all controls produce the same message or enforcement point.
Use the definitions and attributes reference when specifying the relevant screen and field context. Ask for a small working example in the target Tally release, because a correct business condition in the wrong context can still behave incorrectly.
Make errors actionable
A useful message identifies the field, the issue and the next step. “Choose the job reference for this material issue” is more useful than a technical formula failure. If the system cannot verify the reference, describe that state accurately rather than telling the operator the value is definitely wrong.
Keep repeated messages under control. An operator who sees the same warning on every valid transaction will stop distinguishing meaningful exceptions. Review warning frequency and false positives during the pilot and adjust the rule with the process owner.
Treat overrides as a separate design
Some business exceptions are legitimate, but an override should have an authorised role, reason and evidence. Define the scope and duration of an exception. A permanent “ignore validations” switch is a different level of control from permitting one documented transaction.
Do not equate hiding a button with preventing every possible action. Confirm the relevant permission model and test how the control behaves for the actual user roles. Keep the approval record linked to the business event so later reviewers can understand what was allowed.
Test every route that can create the data
Create a test matrix covering ordinary entry, voucher copying, alteration, import and any connected application. A check triggered during one screen journey may not behave identically in another path. The acceptance test must demonstrate the intended result for each supported route.
Include the case where a record was valid when created but the reference master later changed. The system should apply a documented rule for historical records rather than silently rewriting them or making legitimate corrections impossible.
Track these separately. Evidence for one does not automatically confirm the others; use the article’s review and ownership checks.
Implementation work to scope
- Select a small rule set from observed errors and document the recovery action.
- Agree warning, blocking and authorised-exception behaviour.
- Implement the controls in the correct TDL object and screen contexts.
- Test roles, legacy records, copies, imports and unavailable dependencies.
- Publish a rule register with version, owner, effective date and support procedure.
For transaction identity and repeated imports, use the Tally duplicate-prevention guide. Validation and duplicate control solve related but different problems; neither should be assumed to replace the other.
Pilot with the people who enter and review vouchers
Give operators a normal record, an incomplete record and a permitted exception. Confirm they can understand the messages and complete the appropriate recovery without assistance from the developer. Ask finance to inspect the resulting data and exception evidence.
Measure rejected errors, false positives and time spent resolving exceptions. Keep the test cases for future upgrades, because a rule that worked once still needs verification after the surrounding configuration changes. To scope the controls around your factory, explore GST and Tally automation or share the recurring entry problems.
Frequently asked questions
When should a TDL validation warn rather than block entry?
Base the behaviour on the business consequence and evidence needed for correction. Specify the rule, message, authorised override and owner instead of treating every exception as the same error.
Does a voucher-screen check also protect every import path?
Do not assume so. Test each relevant entry, alteration and integration route in the installed setup, and document where an equivalent control must run outside the screen.
Related implementation guides
Founder, The Night Marketer (Shopify Select Partner). The agency has served 450+ brands since 2015.
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.
