Answer the Tally mapping queue

Your Tally ledgers and Finocket’s do not automatically mean the same thing. When a sync run meets a Tally ledger it has no Finocket counterpart for, it parks the whole voucher and asks you — once. Ledger mapping is where you answer, and the answer is remembered for that Tally connection from then on.

What is actually in the queue

Not a placeholder list — every row is a real Tally ledger the waiting run could not resolve, shown with the number of vouchers held up by it. The list comes from the run’s own plan, worked out on the server by the same code the commit uses, so this screen can neither show you a ledger the planner is happy with nor miss one it parked.

There is a second table underneath: voucher types waiting. When Finocket cannot work out what a Tally voucher type is — a “Counter Slip”, a “Sales Adjustment Journal” — every voucher using it is held back too. You say what it is, choosing between things that go into your books and things that are counted, never posted, and the sync remembers.

Answering

1. 1

   Pick the Tally company

   If you have paired more than one, choose which one you are answering for. Switching throws any half-typed answers away on purpose — the same ledger name means something else over there.
2. 2

   Choose a Finocket ledger for each row

   Rows are listed with the voucher count behind them, so you can clear the expensive ones first.
3. 3

   Save

   The rule is written against that Tally connection. It changes nothing in your books — it is a memory, not an accounting entry.
4. 4

   Go back and commit the waiting run

   You do not re-upload anything and you do not wait for another sync. The run that was waiting keeps its own copy of the payload, and its plan is worked out again when you open it — so the vouchers you just released are already accounted for.

One answer per question

Rules are scoped to a connection, not to a company: two Tally companies syncing into one Finocket company may legitimately use the same ledger name for different things. And there is one answer per question — re-answering the same Tally value replaces your previous answer rather than adding a second one, because two answers would make a plan depend on which was read first.

Everything you have already decided is listed at the bottom of the screen, so a rule you regret is easy to find and change.

Why a voucher can wait even with every ledger mapped

Mapping is not the only reason a voucher goes to review, and clearing the queue will not always empty the run. The other common ones:

• Tax that cannot be attributed line by line. A voucher mixing GST rates through a single tax ledger, or one carrying two revenue ledgers with tax on top, always goes to a person — a blended rate can look exactly like a real one.
• A foreign-currency voucher. Detected, reviewed, and never converted for you.
• A voucher whose ledgers do not fit its type. It is recorded as a journal instead, and the run says which ledger caused it.
• Anything dated on or before your cut-over. That is refused outright, not queued — see Two-way Tally sync for why.

Missing ledgers on the way out

The same idea runs in the other direction. When Finocket prepares a push into Tally, ledgers and other master records are sent first — a voucher naming a ledger Tally does not have would import as an orphan, so if the masters are refused no voucher is sent at all. (That direction is not carrying anything yet; see Two-way Tally sync.)

Related: Two-way Tally sync, When a Tally sync will not run, Undo a Tally sync, Coming from Tally?