Overview
A release about the fields that were quietly going missing. Each of the three
looked like a working sync from this side and lost something on the way into or
out of Tally.
Bill-wise allocations. Receipts and payments were syncing with the right
ledger balances but no link to the invoices they settled, so Tally's Bills
Outstanding and ageing reports could not be reconstructed from a pulled voucher —
and a pushed receipt landed in Tally as one unallocated lump the user had to
allocate by hand.
The voucher reference. Accepted on every push and then dropped at the last
step, which on a purchase means the Supplier Invoice No. — the value GSTR-2B
reconciliation matches on — never reached the books.
Master aliases. The other names a ledger or item answers to were arriving in
every master pull and being discarded before anyone could use them.
Changes
- Bill allocations now travel in both directions. A ledger line can carry
bill_allocations — the bill-wise references Tally keeps under
BILLALLOCATIONS.LIST — naming which bills the money opens or settles, and
splitting one line across several of them (a ₹10,000 receipt clearing ₹5,000
of two different invoices).
- Push (Receipt, Payment, Contra, Journal): the named bills reach Tally
and its outstanding balances move by the allocated amounts. All four of
Tally's reference types work —
Agst Ref, New Ref, Advance,
On Account. Settling one bill in full needs no amount.
- Pull (every voucher kind): the breakdown comes back under the same field
name, so a pulled voucher pushes back unchanged. A sales or purchase that
opened a bill reports it as
New Ref; a receipt that cleared one as
Agst Ref.
- Known limitation — the bill's credit period is not carried. Tally accepts
a
BILLCREDITPERIOD on import without complaint and then ignores it, and its
Voucher Register exports the tag blank even for a bill that has a due date. The
field is therefore deliberately absent from the payload rather than offered as
a key that does nothing. Set due dates in Tally.
reference now reaches Tally. The field was accepted on every push and
then dropped at the last step: the builders emitted the whole voucher header
except REFERENCE, so a stored voucher exported from TallyPrime showed the
tag empty. On a purchase that value is the Supplier Invoice No., which
Tally matches against GSTR-2B when claiming input credit, so losing it was not
cosmetic. It now lands on invoices, purchases, credit and debit notes,
receipts, payments, contras and journals.
reference_date travels with it as Tally's REFERENCEDATE (the Supplier
Invoice date). Omit it and it follows the voucher date — what Tally itself
stores when a supplier invoice number is entered without changing the date.- Both tags are omitted entirely when the payload carries no reference, so
existing pushes produce byte-identical XML.
- The pull side now returns
reference_date beside reference, so the pair
round-trips instead of only the number surviving.
- Sales orders already sent
REFERENCE but never its date, and emitted an
empty tag when there was no reference; they now behave like every other
family.
- Master pulls carry
aliases. Every master type reports the other names it
answers to — payload.fields.aliases, a list, empty when there are none. A
customer who aliases Example Customer to EC and EXC can type either in
voucher entry, and both now come back, so a name your user gives you can be
resolved to the master it means. It is a list because a master can hold
several, so matching on only the first still misses some.
- Read from Tally's
LANGUAGENAME.LIST block, which already arrived with
every pull — the data was on the wire all along and only the parser was
missing it, so this costs no extra bytes. The TDL method $OnlyAlias is the
obvious alternative and is deliberately not used: it is a scalar and reports
only the first alias, dropping the rest.
GST returns, month by month
A fourth thing that was quietly going missing, reported after the above: a
developer granted GST on a client's company and read an empty result — HTTP 200,
no sections — for every month they asked for. The company had GST data in Tally
and the grant was live. Three separate causes:
- GST now builds a month-by-month history instead of only today's month.
Each cycle snapshots one calendar month: the current month first, so a freshly
granted report is useful immediately, then it fills in history oldest-first up
to
gst_backfill_months (default 12). Previously only the live month was ever
stored, so every past return period read as empty no matter what was in
Tally. Periods are whole months — period_key is "20260901:20260930".
- One month per cycle on purpose. A month is one chunked Voucher Register
request; asking for a year at once is the unbounded request that has taken
Tally down before.
- A closed month is stored once and not re-read. The live month keeps
refreshing until it closes, then gets one final pull — so late entries are
never stranded.
- GST no longer waits for the evening. It is the only report that keeps
running during office hours, on a slower cadence (one month an hour, against
one per 15 minutes off-hours). The heavy-report deferral assumes the machine
is on at night; on a client PC switched off at 7pm it never expires, so the
report produced nothing at all — indefinitely. Pausing sync still stops it, as
does the quiet window after Tally restarts.
pull_gst_office_hours_interval_seconds (default 3600) tunes the daytime
cadence and is remote-settable, so a client who feels it during invoicing
can be slowed down without a new build.- The other reports are unchanged, except that one report that has never
produced a snapshot may now seed once during the day rather than waiting for
an off-hours window that may never arrive.
period_key=current works. It was matched literally against stored
periods, and nothing is ever stored under that value, so the documented way to
ask for the latest return period always returned zero rows. It now resolves to
the newest period held.- Every GST read reports
available_periods. A period that was never
pulled, a period with nothing to report, and a mistyped period all returned
count: 0 and were indistinguishable. Read this list before guessing a period.