voucher_presence
Check which proposed vouchers already exist in TallyPrime, returning present, possibly_present, or absent per voucher to prevent duplicate entries.
Instructions
Answer which of 1–500 proposed vouchers are already in the book. presence is present, possibly_present or absent, and only present names a book voucher. A nonempty window is read as complete only when its rows were checked voucher for voucher against a count ComplyEaze Bridge made of the window first, as vouchers labels it; otherwise, as on a new or test company with a few dozen vouchers, it is partial with reason nonempty_window_unqualified. An empty window can still be corroborated complete. present and possibly_present never need a complete window and are produced either way, but absent means absent from the whole window and is only ever produced from one proven complete — a proposal that would otherwise be absent from a merely partial window instead comes back possibly_present with reason window_not_proven_complete. The conditional decision basis can use a voucher number on a voucher type you declare manual — unique on both sides, within an observed voucher type, and never onto a cancelled or optional voucher; or, for a voucher ComplyEaze Bridge wrote into a file a person imported by hand, the narration marker derived from the supplied batch_id and bridge_txn_id together. A native post (post_import) writes no marker, so this tool cannot identify its vouchers: one edited or re-dated in Tally can read absent here. Check a natively posted batch with verify_import, which finds its vouchers by the GUIDs its post created once its binding is made, before posting any of them again. It neither accepts nor reads client remote identifiers. Supplying only one narration identity component is an error. The marker reaches only the current writer identity scheme; older-scheme ComplyEaze Bridge writes stay unidentified rather than matched. Date, party and amount only ever produce candidates, with the rule that surfaced each and no ranking or score. Every voucher type a proposal names needs a declared numbering method; under automatic Tally discards the supplied number, so nothing can be decided from it. absent means absent from this window, so cover the dates the book could hold. Reads the full window before comparing; dense windows can fail source limits. Party names bind through the same rules as validate_masters. A reported difference on a present voucher is a finding for a person, not a work item: correcting a voucher by Alter or Cancel silently creates a duplicate instead (§9.7), and no ComplyEaze Bridge path can correct a voucher it did not write. This never dispatches import XML to Tally. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes | ||
| limit | No | ||
| offset | No | ||
| vouchers | Yes | ||
| numbering | Yes | ||
| company_guid | Yes |