From 687f3a3b85463b860ee26fd03ae912f5017e27c0 Mon Sep 17 00:00:00 2001 From: t Date: Thu, 17 Sep 2026 03:16:55 +0530 Subject: [PATCH 1/3] Record that bank vouchers return EFFECTIVEDATE but not the written party One live verification read with EFFECTIVEDATE and PARTYLEDGERNAME added to FETCH, over three Bridge-built bank vouchers in the synthetic lab: the effective date comes back equal to DATE, while PARTYLEDGERNAME comes back as a bank ledger rather than the counterparty Bridge wrote, so it must not be compared with the written value. Co-Authored-By: Claude Opus 5 --- docs/tally/TALLY_PROTOCOL_REFERENCE.md | 27 ++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/docs/tally/TALLY_PROTOCOL_REFERENCE.md b/docs/tally/TALLY_PROTOCOL_REFERENCE.md index e1179448..24ef659d 100644 --- a/docs/tally/TALLY_PROTOCOL_REFERENCE.md +++ b/docs/tally/TALLY_PROTOCOL_REFERENCE.md @@ -1821,6 +1821,33 @@ the one it guards — the same trap as comparing `REMOTEID` above, where the fie carrying Tally's value rather than the client's. Both close with one live read that adds them to the `FETCH` list and looks at what arrives. +> **Scoped correction, 2026-09-17 — both were read back, and they differ.** The table above +> predates this read. Licensed TallyPrime 7.1 Silver, synthetic `BRIDGE SHAPE LAB`: the §9.8 +> verification collection's request, with `EFFECTIVEDATE` and `PARTYLEDGERNAME` appended to its +> `FETCH`, sent once over the window holding three vouchers. The Receipt and Payment were built by +> `bridge_mcp`, imported from its file and amended from a Bridge-built file; the Payment was last +> re-imported from a copy of that file with only its amount edited. The Contra was built by +> `bridge_mcp` and imported from its file. Every file wrote the `PARTYLEDGERNAME` and +> `EFFECTIVEDATE` shown here: +> +> | voucher | written `DATE` / `EFFECTIVEDATE` | returned `EFFECTIVEDATE` | written `PARTYLEDGERNAME` | returned `PARTYLEDGERNAME` | +> | --- | --- | --- | --- | --- | +> | Receipt | `20250422` / `20250422` | `20250422`, `TYPE="Date"` | the counterparty (`Shape Buyer 5`) | **the bank ledger** (`Bank of Baroda CA`) | +> | Payment | `20250422` / `20250422` | `20250422`, `TYPE="Date"` | the counterparty (`Power Charges`) | **the bank ledger** (`Bank of Baroda CA`) | +> | Contra | `20250423` / `20250423` | `20250423`, `TYPE="Date"` | none written | the debit bank ledger (`HDFC CC`) | +> +> - **`EFFECTIVEDATE` is returned, equal to `DATE`**, on all three types. Comparing it is now +> possible. `verify_import` still does not fetch it, so the limit above still holds for the code. +> - **`PARTYLEDGERNAME` is returned but does not echo what was written.** On these vouchers it held +> a cash or bank ledger that was on the voucher, not the counterparty Bridge wrote. **Do not +> compare it with the written value:** that comparison would refuse every one of these legitimate +> vouchers, which is the `REMOTEID` trap again. Whether a readback can detect a silently dropped +> counterparty is still open. The entries comparison already requires the counterparty's ledger +> among the signed entries. +> +> One read, one company, one release, three vouchers dated within one window. It does not establish +> what a Tally UI edit to either field returns. + ### 9.9 Bulk import throughput **VERIFIED.** One import request may carry many `` elements; the counters aggregate. From 889ca1fd61e8ba8b4d414c54cd0c013533507b88 Mon Sep 17 00:00:00 2001 From: t Date: Thu, 17 Sep 2026 03:21:31 +0530 Subject: [PATCH 2/3] State that the read window held six vouchers, three of them Bridge-built Co-Authored-By: Claude Opus 5 --- docs/tally/TALLY_PROTOCOL_REFERENCE.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/tally/TALLY_PROTOCOL_REFERENCE.md b/docs/tally/TALLY_PROTOCOL_REFERENCE.md index 24ef659d..abf452b9 100644 --- a/docs/tally/TALLY_PROTOCOL_REFERENCE.md +++ b/docs/tally/TALLY_PROTOCOL_REFERENCE.md @@ -1824,7 +1824,11 @@ the `FETCH` list and looks at what arrives. > **Scoped correction, 2026-09-17 — both were read back, and they differ.** The table above > predates this read. Licensed TallyPrime 7.1 Silver, synthetic `BRIDGE SHAPE LAB`: the §9.8 > verification collection's request, with `EFFECTIVEDATE` and `PARTYLEDGERNAME` appended to its -> `FETCH`, sent once over the window holding three vouchers. The Receipt and Payment were built by +> `FETCH`, sent once over `20250422..20250423`. The window held six vouchers. Three were written by +> earlier lab runs with narrations of their own (a Contra, a Journal and a Sales voucher). Their +> written values were not recorded here, so they are not tabulated, but each also returned +> `EFFECTIVEDATE` equal to `DATE`. The three Bridge-built vouchers, found by their `[BRIDGE:…]` +> markers, are the rows below. The Receipt and Payment were built by > `bridge_mcp`, imported from its file and amended from a Bridge-built file; the Payment was last > re-imported from a copy of that file with only its amount edited. The Contra was built by > `bridge_mcp` and imported from its file. Every file wrote the `PARTYLEDGERNAME` and @@ -1845,7 +1849,7 @@ the `FETCH` list and looks at what arrives. > counterparty is still open. The entries comparison already requires the counterparty's ledger > among the signed entries. > -> One read, one company, one release, three vouchers dated within one window. It does not establish +> One read, one company, one release, three Bridge-built vouchers in a six-voucher window. It does not establish > what a Tally UI edit to either field returns. ### 9.9 Bulk import throughput From 944898fd07d2b21dc395fb8faf14bcf82580e500 Mon Sep 17 00:00:00 2001 From: t Date: Thu, 17 Sep 2026 05:44:05 +0530 Subject: [PATCH 3/3] Reseal after rebasing onto master Co-Authored-By: Claude Opus 5 --- docs/tally/compatibility/compatibility-matrix.json | 2 +- docs/tally/compatibility/compatibility-surface.json | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/tally/compatibility/compatibility-matrix.json b/docs/tally/compatibility/compatibility-matrix.json index 4e3c288d..ba29c95e 100644 --- a/docs/tally/compatibility/compatibility-matrix.json +++ b/docs/tally/compatibility/compatibility-matrix.json @@ -1,7 +1,7 @@ { "schema_version": 1, "bridge_commit_sha": "be1c20cc3fd66fa1ece196505c69f26e555e4b8e", - "compatibility_surface_sha256": "f642e8e85535417377004fe997b0e98a7a6b3fa3d811a1b96bc82b35b9a07839", + "compatibility_surface_sha256": "dc243b693d451540ef0567aa5351216a084917952dc91648943679fab2947915", "claims": [ { "claim_id": "erp9-6-6-3-windows-education-xml-one-company", diff --git a/docs/tally/compatibility/compatibility-surface.json b/docs/tally/compatibility/compatibility-surface.json index f148d1e4..916d635b 100644 --- a/docs/tally/compatibility/compatibility-surface.json +++ b/docs/tally/compatibility/compatibility-surface.json @@ -39,7 +39,7 @@ }, { "path": "docs/tally/TALLY_PROTOCOL_REFERENCE.md", - "sha256": "d6fceb1a2495390f6f20f93a365f40ec13507320fce6ea458d0639178d991b06" + "sha256": "e0b65e7530f876f351b4a1a970ded87dca5d0a757e53c8a03823add0a5d84874" }, { "path": "docs/tally/compatibility/README.md", @@ -998,5 +998,5 @@ "sha256": "0ab5bfbe6d81b1e10530744c338fb91efa57fe5a66fb4bc0cfd382495eaf02a4" } ], - "manifest_sha256": "f642e8e85535417377004fe997b0e98a7a6b3fa3d811a1b96bc82b35b9a07839" + "manifest_sha256": "dc243b693d451540ef0567aa5351216a084917952dc91648943679fab2947915" } \ No newline at end of file