Everything Bridge knows about Tally's behaviour was measured on TallyPrime Edit Log EDU (Education mode), on one machine, one build. This issue collects what cannot be settled without a licensed installation, so it can be worked in one pass when a licence exists rather than rediscovered piecemeal.
A one-month licence is sufficient for all of it.
1. Is the day-01/02/31 restriction really Education-only?
Bridge encodes it as DateBoundaryProfile::EducationRestricted, with I12 (compare returned span to requested) as the mode-agnostic guarantee. The belief that licensed Tally permits arbitrary boundaries is inherited, not verified — no licensed instance has ever been contacted.
If it turns out licensed builds restrict dates differently, the partitioning logic changes shape.
Test: request a window with boundaries on days 7 and 23, and compare the returned span to the requested one.
2. Intermediate window sizes, to fit the density curve
The live session established that payload is linear at ~21.7 KB/voucher and time at ~13 ms/voucher, and that a cheap pre-flight count (minimal FETCH) returns the exact voucher count at ~1/17th the cost of the wildcard.
What could not be measured is the middle of the curve. Education permits boundaries only on days 01, 02 and 31, so legal window lengths are ~1, 2, 29, 30, 31 — nothing between. Sizing experiments in the 5–20 day range are impossible there.
Test: sweep window sizes 2, 5, 10, 15, 20, 25, 31 days on a dense book, recording payload, elapsed time and voucher count for each. Confirm linearity holds across the range or find where it breaks.
3. Does the crash reproduce, and is it volume-related at all?
A wildcard partition on a dense book once produced a Tally memory access violation; an identical repeat did not, returning 101.5 MiB in 81.3 s. The owner's hypothesis — that a UI keypress during generation caused it — is at least as plausible as a volume threshold, and would mean there is no volume threshold to find.
Details are in the private brain repo (restricted); do not restate the trigger here.
Test: repeat the same shape several times on a licensed dense book, deliberately without touching the Tally UI, then again while navigating. If the crash only occurs in the second case, the volume story dissolves.
4. Does the unloaded-company behaviour differ?
On Education, TYPE=Collection silently returns the loaded company's data when the requested company is not loaded, while TYPE=Data fails closed with Could not set 'SVCurrentCompany'. This asymmetry is load-bearing for Bridge's identity binding.
Believed licence-independent — it looks architectural, and Tally's own sync guidance says to open the company on the server — but unverified.
Test: same probe pair on a licensed instance with a company deliberately unloaded.
5. Does the native report behave identically?
<TYPE>Data</TYPE><ID>Bills Receivable</ID> returns per-bill rows in ~0.10 s regardless of book size. Field names, the STATUS-only-on-failure convention, and the BILLOVERDUE as-of (Tally's period date, not ours) were all measured on Education.
Test: confirm the same field set and conventions on a licensed build, ideally on more than one TallyPrime version.
Why this matters beyond curiosity
No store-facing or user-facing claim about Tally compatibility can be made from Education-mode evidence alone. This is the gate on saying Bridge works with Tally, as opposed to Bridge works with the Education build we tested against.
Related: the roadmap thread and the Tally behaviour entries in the private brain repo.
Everything Bridge knows about Tally's behaviour was measured on TallyPrime Edit Log EDU (Education mode), on one machine, one build. This issue collects what cannot be settled without a licensed installation, so it can be worked in one pass when a licence exists rather than rediscovered piecemeal.
A one-month licence is sufficient for all of it.
1. Is the day-01/02/31 restriction really Education-only?
Bridge encodes it as
DateBoundaryProfile::EducationRestricted, with I12 (compare returned span to requested) as the mode-agnostic guarantee. The belief that licensed Tally permits arbitrary boundaries is inherited, not verified — no licensed instance has ever been contacted.If it turns out licensed builds restrict dates differently, the partitioning logic changes shape.
Test: request a window with boundaries on days 7 and 23, and compare the returned span to the requested one.
2. Intermediate window sizes, to fit the density curve
The live session established that payload is linear at ~21.7 KB/voucher and time at ~13 ms/voucher, and that a cheap pre-flight count (minimal
FETCH) returns the exact voucher count at ~1/17th the cost of the wildcard.What could not be measured is the middle of the curve. Education permits boundaries only on days 01, 02 and 31, so legal window lengths are ~1, 2, 29, 30, 31 — nothing between. Sizing experiments in the 5–20 day range are impossible there.
Test: sweep window sizes 2, 5, 10, 15, 20, 25, 31 days on a dense book, recording payload, elapsed time and voucher count for each. Confirm linearity holds across the range or find where it breaks.
3. Does the crash reproduce, and is it volume-related at all?
A wildcard partition on a dense book once produced a Tally memory access violation; an identical repeat did not, returning 101.5 MiB in 81.3 s. The owner's hypothesis — that a UI keypress during generation caused it — is at least as plausible as a volume threshold, and would mean there is no volume threshold to find.
Details are in the private brain repo (restricted); do not restate the trigger here.
Test: repeat the same shape several times on a licensed dense book, deliberately without touching the Tally UI, then again while navigating. If the crash only occurs in the second case, the volume story dissolves.
4. Does the unloaded-company behaviour differ?
On Education,
TYPE=Collectionsilently returns the loaded company's data when the requested company is not loaded, whileTYPE=Datafails closed withCould not set 'SVCurrentCompany'. This asymmetry is load-bearing for Bridge's identity binding.Believed licence-independent — it looks architectural, and Tally's own sync guidance says to open the company on the server — but unverified.
Test: same probe pair on a licensed instance with a company deliberately unloaded.
5. Does the native report behave identically?
<TYPE>Data</TYPE><ID>Bills Receivable</ID>returns per-bill rows in ~0.10 s regardless of book size. Field names, theSTATUS-only-on-failure convention, and theBILLOVERDUEas-of (Tally's period date, not ours) were all measured on Education.Test: confirm the same field set and conventions on a licensed build, ideally on more than one TallyPrime version.
Why this matters beyond curiosity
No store-facing or user-facing claim about Tally compatibility can be made from Education-mode evidence alone. This is the gate on saying Bridge works with Tally, as opposed to Bridge works with the Education build we tested against.
Related: the roadmap thread and the Tally behaviour entries in the private brain repo.