statement_tie_out

Tie the bank ledger in Tally to the bank statement already parsed by parse_bank_statement, at the start and at the end of the statement's own dates, or of the whole calendar months it was parsed for. Read-only: it writes nothing to Tally and never posts. Its check of the import journal takes the shared import-admission lock for a moment, so a build or post at the same time can be refused as lock-busy, and it can be refused by theirs; call again. It reads the proposals file named by proposals_id and proposals_sha256 (as build_import_xml does) and the book's ledger list three times: at the window's first date, at the day after its last date, and at the first date again, which catches a change dated before the window or an edit to the ledger itself (its opening balance, name or removal) made during the read (a voucher dated inside the window and posted during the read moves only the end figure and is not caught). No ledger is read when the file alone answers (window_not_recorded, window_narrower_than_statement, window_not_whole_calendar_months, window_beyond_statement_rows) or the window starts before the company's books begin (window_precedes_books_from). It reads no vouchers, and each ledger-list read has the same deadline and size limits as ledger_movement's. The proposals file is not bound to a company: pass the company_guid of the company the statement belongs to, because a different company that has a ledger of the same name is read just as readily. The window is the whole statement, from its first to its last row date, at the balances you supplied. A file parsed with from or to that left rows out is compared over those dates only if they are whole calendar months (from the 1st to a month's last day) within the statement's rows; the opening and closing are then worked out from the statement's own rows, so a gap together with the book's figure gives the statement's balance at the month edge. Any other window is not_established: window_not_whole_calendar_months, or window_beyond_statement_rows when a month starts before the statement's first row or ends after its last. So is a narrowed file written before parse_bank_statement recorded a window's balances (window_narrower_than_statement), and one written before it recorded the statement's dates (window_not_recorded); parse the statement again. The result carries the stage, the two dates, rows_without_voucher, three figures, a fixed reading and the company block. opening_gap is the book at the start of the window's first date less the statement's balance then; closing_gap is the book at the end of its last date less the statement's balance then, where stage before_build adds what this file's vouchers would put into the bank ledger (where the book would stand once the file is imported) and stage after_post is the book as it stands now; change_in_window is closing_gap less opening_gap. All three are in the statement's sign: positive means the book shows more money in the bank than the statement does. The book's own balances are not returned, but a gap plus the statement's balance at that date (for the whole statement, the balance you supplied) gives the book's balance, so they are derivable from the result. For whole calendar months the reverse also holds: the book's figure less a gap gives the statement's balance at the month edge, and change_in_window with the book's movement gives the statement's net over those months. These are totals per calendar month, never a part of a month except the part-months at the statement's own start and end, whose net a month edge's balance gives together with the opening and closing you supplied; but a month in which every other row's amount is already known (one row alone, or one row beside open cash lines, whose amounts parse_bank_statement returns) gives that row's amount. Each figure has a state: tied (exactly zero), differs, or not_established with a reason (window_not_recorded, window_narrower_than_statement, window_not_whole_calendar_months, window_beyond_statement_rows, window_precedes_books_from, bank_ledger_not_in_book, book_changed_during_read; for before_build also rows_without_voucher, when some rows of the statement have no voucher in the file because a cash line is unanswered or a row is skipped, and file_already_partly_posted, when the import journal already holds a row of this file, either of which leaves closing_gap and change_in_window not established). A gap does not say why: uncleared cheques and deposits in transit, a missing entry, a repeated entry and the wrong bank ledger look alike here, and the reading says so and prescribes no remedy. It checks the bank ledger only; a wrong party or expense ledger is not caught. Use it after parse_bank_statement and before build_import_xml with stage before_build, and again with stage after_post after a post or an import by hand. Requires one observed INR currency master, as ledger_movement does. Not yet proved against a live book. 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.