Undo a Tally sync

There are two undos, and they point in opposite directions. Rolling back a sync run takes out what came into Finocket from Tally. Undoing a push cancels, inside Tally, what Finocket put there. They behave differently because the two sets of books belong to different systems, and neither one is a delete-everything button.

Rolling back a sync run

Open Sync runs, pick the run, and read the plan before the button will do anything. What it runs is the plan rehearsed when the run was committed — not one worked out now against books somebody may have edited since. A run with no rehearsed plan is told so plainly rather than being offered an undo nobody rehearsed.

Every record the run wrote falls into one of four buckets, and the screen counts each:

• Removed completely. Nothing outside this run had come to rely on it, so it simply goes.
• Reversed, not removed. A compensating entry unwinds the money and the original record stays visible in the daybook.
• Put back as it was. The row existed before the run and the run only edited it, so it is restored to the image saved at the time — deleting it would destroy something the sync never created.
• Kept, with a reason. Neither removed nor reversed, and the reason is named.

Kept, and why

A record the database refuses to give up is kept and reported, never forced. The reasons are shown in plain words: the ledger still carries postings from outside this sync, the customer still has invoices against them, the item still has stock movements, or something else still uses it. A ledger in that position is archived rather than deleted, so it stops appearing in pickers while its history stays intact.

Finocket’s own chart of accounts is never in a rollback plan at all — not as a step, not as a kept row. Only a count is reported.

One more check happens at the moment of undoing rather than at rehearsal: if your live books now say a row is relied on when the rehearsed plan expected to remove it, that step is downgraded on the spot and reported as kept. The rehearsal decides the shape; the live books get the last word on anything destructive.

Doing it

1. 1

   Pick the run

   On Sync runs, choose the one you want to undo.
2. 2

   Read the counts

   How many are removed, reversed, put back and kept — with the reason for every reversal and every kept row.
3. 3

   Tick the acknowledgement

   It names the numbers: I have read why N records are reversed and N are kept. A second tick confirms you want the rollback itself. Neither is pre-ticked, and both re-arm if the plan underneath them changes.
4. 4

   Roll back

   Safe to run again — anything already undone is skipped, and an interrupted rollback resumes exactly where it stopped.

A rollback will refuse rather than proceed if it cannot be sure of itself: if the stored plan does not belong to that run, if the run’s write log and the records that exist disagree, if the run was already rolled back, or if your books do not balance before it starts or would not balance after it. Those refusals are reported by name, and nothing is written.

The record of the run itself is never deleted. An undo stamps it, so the history of what was brought into your books — and what took it back out — stays.

Undoing a push into Tally

The Undo a push panel on Tally sync is the mirror image: it cancels, in your TallyPrime company, the vouchers Finocket sent there.

Cancelled, not deleted. Tally’s own guidance is not to delete vouchers after synchronising, so a cancelled voucher keeps its number and its place in the daybook with its amounts set to zero. It stays visible to your CA. Nothing here removes a row from anybody’s books.

Only what actually landed is cancelled. Everything else is listed with its reason:

• Already cancelled in Tally — doing it again would change nothing there.
• Never reached Tally — there is no voucher there to cancel.
• It is a ledger or an item, not a voucher — Tally has no cancel for a master record.
• Tally’s own record number for it was never recorded — a cancellation aimed on a guess would hit whatever holds that number now.
• The voucher it was raised from cannot be read here any more — widen the dates or restore the row and try again.

A voucher edited in Tally since it was sent is held back too, and needs a person: a cancellation would throw that edit away exactly as an update would.

Running the undo twice cancels once. A refused cancellation is reported by name with Tally’s own message word for word and is not recorded as cancelled, which is what makes running it again pick up exactly those and nothing else. Afterwards a voucher is recorded as cancelled, not as never sent, so a later push will not silently re-create it — sending it again is a decision a person makes.

Related: Two-way Tally sync, When a Tally sync will not run, Answer the Tally mapping queue, Move your Tally books across.