voucher_presence

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; ComplyEaze Bridge makes that count for every book that has held a voucher, however few, so a small book can read complete too. A nonempty window not counted is partial with reason nonempty_window_unqualified. An empty window is complete only when a read widened by a day on each side is also empty and the company has no vouchers (company_has_no_vouchers); it is otherwise partial, with empty_uncorroborated when the widened read is also empty but the company has vouchers, and empty_window_wider_read_nonempty when the widened read found rows on the neighbouring days, which cannot count the window. 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. A proposal comes back absent only when the window is proven complete, nothing in it resembles the proposal, a voucher type declared manual carries its voucher number, and the party was supplied and could be compared completely; a proposal with no party (a Journal has none), no manual number, or a party whose comparison was cut short comes back possibly_present with a reason such as party_not_supplied, manual_number_not_supplied or party_not_decidable, however complete the window is. 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. To list the vouchers of a date window, use vouchers instead. 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.