Giving it vouchers

A run is created empty. Where its vouchers come from is the first question it asks, and there are two answers.

Reuse what the tax audit already fetched

If this client and year has a Tax Audit import, the run offers it. Nothing is copied and Tally is not involved: the run records which import it reads and counts what falls inside its period. Because it is read rather than copied, correcting the import corrects the run — and that import cannot be deleted while a run depends on it.

Fetch it from TallyConnector, Tally open on the bound company

Reads every voucher dated inside the run's period, a month at a time, together with the ledger and group list. A full year can take a few minutes on large books.

What the fetch checks before it starts

The client must be bound to a Tally company. The connector compares what Tally has open against that binding and refuses a mismatch by name, so a fetch cannot quietly read the wrong books. If the client is unbound, bind it on the client's page first.

Why the ledger list matters

The fetch reads the ledger and group tree alongside the vouchers, and the cash tests depend on it. It is what tells a till named "Counter Float" from a debtor named "Cash Traders", neither of which their names reveal.

If the ledger list fails to come back, the fetch is not thrown away — a year of vouchers is too dear for that. The vouchers are stored, the cash tests fall back to matching names, and the run says so at the top of the findings and in the report.

Re-fetching

A run holds one population. Fetching again replaces what was there rather than adding to it, and detaches any tax audit import the run was reading. Your answers to findings are not affected: they survive a re-fetch by design.