Tally¶
Applies to: e-Invoice · e-Way Bill · Which modules do I have?
Purpose¶
Connect Tally to Complifly, either through a scheduled export and upload or through a connector calling the ingest API, and set out the traps specific to Tally's data model.
Audience¶
Tally partners, implementation consultants and integration developers.
Prerequisites¶
- The Integration Pattern — read first
- Access to the Tally installation
- Sandbox credentials
- A raw export sample per voucher type
Verify: Whether Complifly supplies a Tally connector or this is a pattern a partner implements is not established here. Recorded as assumption F1 in the Assumptions Register.
Steps¶
1. Choose the approach¶
| Approach | Suits | Trade-off |
|---|---|---|
| Connector to mapped ingest | Ongoing, higher volume | Development effort; needs Tally to be reachable or to call out |
| Scheduled export and upload | Lower volume, minimal change | A manual or scheduled step; rejections found later |
| Manual export and upload | Very low volume, or a pilot | Entirely manual; not sustainable at volume |
Tally installations are frequently on-premises, single-machine and not continuously connected. Choose realistically: a connector requiring constant connectivity is a poor fit for a machine that is switched off at night.
2. Handle Tally's data model¶
Tally differs from larger systems in ways that shape the mapping:
| Characteristic | Consequence |
|---|---|
| Vouchers, not typed documents | The voucher type determines the document type — a lookup rule, and its default matters |
| Registration on the company or ledger | Establish which carries it in this installation before mapping |
| Ledger-driven tax | Tax amounts derive from ledger allocations rather than explicit fields |
| Flexible field usage | Customers use fields in idiosyncratic ways; the mapping must reflect this installation |
| Multiple companies in one installation | Each may be a different registration |
The fourth row is the important one. A Tally mapping built for one customer rarely transfers to another without change, because two installations rarely use the same fields the same way. Budget for per-customer mapping work.
3. Source the required fields¶
| Complifly needs | Typically from |
|---|---|
| Document number and date | Voucher number and date |
| Document type | Voucher type, through a lookup |
| Supplier registration | Company or ledger registration details |
| Buyer registration and address | Party ledger master |
| Place of supply | Determined in Tally; a tax position |
| Values | Voucher totals |
| Line details | Inventory entries |
| Classification codes | Stock item master |
Once you know where each value lives, build the translation in the product rather than in ERP code: Build a Mapping Template walks through creating the template, loading these fields from a sample, and dragging them onto their NIC counterparts with the right direct, date or lookup rule.
4. Handle the Tally traps¶
| Trap | Symptom | Fix |
|---|---|---|
| Voucher type variety | Documents route wrongly | Enumerate every voucher type in use and map each explicitly. A permissive default misclassifies |
| Date format | Dates transposed | Declare the export's exact format; test with an unambiguous date |
| Voucher numbering resets | Duplicate rejections | Confirm numbering is unique per registration per financial year. Tally numbering commonly restarts |
| Optional and cancelled vouchers | Sending something not final | Exclude them from the export |
| Tax derived from ledgers | Tax amounts absent or wrong | Map from the ledger allocations, with the customer's accountant confirming which |
| Multi-company installations | Wrong registration | One template per company where they differ |
| Character encoding | Names mangled | Confirm the export encoding is UTF-8 |
The numbering trap is the most common and the most expensive: once a number is registered it is permanently consumed, so a restarted series collides forever.
5. Return the outcome¶
Tally's ability to accept an inbound update varies by installation. Options, in order of preference:
| Option | Note |
|---|---|
| Connector writes back into Tally | Best, where the connector supports it |
| A report the customer reconciles against | Practical and common |
| Complifly as the compliance record of record | Acceptable where Tally does not need the reference number |
Decide this explicitly during implementation. Assuming write-back into Tally and discovering late that it is not feasible is a common late surprise.
6. Handle rejections visibly¶
Where uploads are scheduled, someone must review the results. Assign a person and a daily time. A scheduled upload nobody checks is a scheduled way to accumulate failures.
Validation¶
| Check | Method | Pass condition |
|---|---|---|
| Every voucher type mapped | Export one of each | Each routes correctly |
| Numbering is safe | Review the series across years and companies | No possibility of collision |
| Dates correct | Export a voucher dated the fifth of March | Stored as intended |
| Tax amounts correct | Compare the mapped payload against the voucher | Exact match |
| Cancelled and optional vouchers excluded | Create one of each | Not sent |
| Multi-company handled | Export from each company | Correct registration each time |
| Encoding correct | Export a name with non-ASCII characters | Renders correctly |
| Multi-line correct | Export a voucher with several items | Every line present |
| Outcome path agreed | Confirm with the customer | Documented and working |
| Rejections reviewed | Force one | A person sees it the same day |
Troubleshooting¶
| Symptom | Cause | Action |
|---|---|---|
| Documents route to the wrong pipeline | Voucher type not mapped, and the default guessed | Map every type explicitly |
| Duplicate rejections | Voucher numbering restarted | Fix the series. Registered numbers are permanently consumed |
| Tax amounts missing | Derived from ledgers, not mapped | Map the ledger allocations, confirmed by the accountant |
| Names show wrong characters | Encoding mismatch | Export as UTF-8 |
| Dates transposed | Format not declared correctly | Correct and re-test with an unambiguous date |
| Cancelled vouchers registered | Not excluded | Exclude. A registered document cannot be un-registered |
| Wrong registration | Multi-company installation with one template | One template per company |
| Uploads stop and nobody notices | Scheduled task failed silently | Monitor the schedule and alert on failure |
| Mapping from another customer does not work | Field usage differs per installation | Build the mapping against this installation's export |
Related Articles¶
- Build a Mapping Template — the field mapping, screen by screen
- The Integration Pattern — everything common
- Mapping Templates API
- Custom ERP — where the connector route applies
- Ingest Failures