Bug: inventory-entry fields accumulate whitespace fragments and unit names double when parsing batch-allocated vouchers

[lamemustafa]

Summary

Inventory-entry fields are corrupted when parsed from Tally XML for vouchers carrying inventory entries with batch allocations. This was found with an unreleased inventory reader that sits on the shared voucher-parsing path, while investigating the vouchers failure on inventory books (see #378).

Observed (read-only, TallyPrime 7.1 licensed, real inventory book, 2026-09-14)

• Per-voucher inventory_entries[].amount and .billed_qty come back as the real value followed by roughly 40–60 repeated "\r\n " fragments. For example, "-8000.00\r\n \r\n …" on a single-line Purchase voucher.
• This affects 10 of 10 inventory-bearing vouchers in a one-week test window. It is systematic, not intermittent.
• Unit master names come back doubled ("KGSKGS", "nosnos").
• A full-month window fails with agent_response_too_large.
• Stock-item master opening qty/rate/value fields were not affected.
• A direct XML Export (ALLINVENTORYENTRIES.LIST) for the same vouchers parses cleanly: plain numeric amounts, no duplication.

Likely cause (hypothesis)

Whitespace or text events between nested elements (inventory entry → batch allocations → accounting allocations) are appended to the preceding scalar field instead of being dropped. The same accumulation would also double a repeated name element. This would inflate response size and explain the related vouchers protocol failures.

Acceptance

• Synthetic fixture with nested inventory entries, batch allocations and a unit master (no client data).
• Parsed amount, qty and unit names equal the fixture values exactly; response size scales with voucher count.
• Regression test covers indented (pretty-printed) and compact Tally responses.

[lamemustafa]

The shipped voucher read path is not affected — scanned, not assumed

While fixing #378 I captured twelve monthly and thirty-one single-day windows from the same real trading book and replayed them through the production parse_agent_rows. Scanning every parsed string value:

• 41,796 values scanned
• 0 whitespace-fragment accumulations
• 0 doubled values

Four candidates surfaced and all four are false positives: "BANK OF INDIA JAIPUR BRANCH\r\n APR 2025" is a genuine multi-line master name with one embedded break, not the ~40–60 repeated "\r\n " fragments this issue describes; "1414", "1515", "1616" are real four-digit numeric values that a naive even-length self-repeat heuristic flags.

Why, mechanically

The shipped parser clears current_tag in its Event::End arm. Inter-element whitespace after a closing tag therefore accumulates under an empty key that nothing reads, instead of appending to the scalar that just closed. The reader in this issue does not do that.

What this does and does not establish

It establishes that the voucher read path does not corrupt the fields it returns, on this book.

It does not clear the inventory reader. The fields this issue reports corrupted — inventory_entries[].amount, .billed_qty, and unit master names — are not returned by the voucher path at all, so this scan never exercised them. The defect and its acceptance criteria stand as written.

Fixture material is captured

Three single-day windows fetched with ALLINVENTORYENTRIES.* (13, 28 and 5 inventory entries; 7, 7 and 3 batch allocations; accounting allocations nested under each), plus the unit masters, with request/response SHA-256 manifests. That is enough to build the synthetic nested inventory → batch → accounting fixture the acceptance asks for without further live access — which matters, because the lab licence expires 21 September.

Captures contain customer data and are retained privately with the maintainer.

Related: #378