verify_import
Checks a saved Tally import batch against the company's books and records proof files, showing which vouchers posted, duplicates, and unverified entries.
Instructions
Read back a manually imported local batch and write Proof-of-Post files. This never dispatches import XML to Tally. The result gives verification_status, counts, every voucher that is not posted_verified (unverified_vouchers; for a native post a voucher may be bound_not_in_window, book_rolled_back or sent_not_attributed, never absence, with post_span_binding naming how the post was attributed and a plain summary to give the person first; a book restored from a backup and then keyed past the post's voucher mark before this check is not seen as rolled back, and Tally then gives vouchers keyed again the post's MasterIDs, GUIDs and numbers, so a bound voucher can read posted_verified while being one keyed by hand with the same content: measured once, bridge#1050. In plain words: after a restore, a native voucher keyed again with the same content before any check can read verified, and no identifier a read returns tells the two apart (measured once on TallyPrime 7.1 Silver, with Tally's security off), so after restoring a backup over a company, check its posted vouchers in Tally), duplicates, unrelated_duplicates_in_window and ambiguous_within_batch in full, never cut to fit. Only the posted_verified vouchers are paged, as items from offset out of verified_total; when the response cap shortens them it sets truncated and next_offset. To read further pages, call again with proof_sha256 set to the returned proof.sha256 and offset set to next_offset: those pages come from the persisted proof and never read Tally again. The call is refused with verification_proof_changed if a newer verification has since become the batch's current proof, with verification_proof_altered if the saved proof no longer matches its recorded SHA-256, and with verification_too_large_to_report if the parts never cut do not fit the response cap. The first page also carries a transfers section for the company, in the shape build_import_xml returns: the bank rows skipped as carried by another account's Contra that are not yet paired with a verified Contra, by bridge_txn_id and date. It is computed after the verdict is saved and changes no verdict; transfers.state not_established means it could not be computed (for example another process holds the import folder) or was cut to fit the response, not that nothing is open. A later page never carries it. Every verification's full proof is kept on disk; none is replaced. Reads the batch's date window from Tally, then adds new proof files for the batch beside every earlier one and a status record naming them current, and may also add a verified baseline, a masters-check record and, for a native post, the binding of its vouchers to the Tally vouchers its post created, in ComplyEaze Bridge's local folder on this computer, replacing and deleting nothing there (paging an existing proof only reads it); writes nothing to Tally.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | How many rows to skip before this page: 0, the default, is the first page. | |
| batch_id | Yes | The batch_id build_import_xml returned for the saved batch. | |
| company_guid | Yes | The company's company_guid, as list_companies returns it. | |
| proof_sha256 | No | On a later page only: the proof.sha256 the first page returned, so the page is served from that saved proof without reading Tally again. |