gst_uncertain_vouchers

Return the vouchers of ONE voucher type (a Sales type is what was measured; the type's class is not checked) in a date window that Tally marks Uncertain in its GSTR-1, and the vouchers a person accepted as they stand (Accept As Is), read from the status flags Tally keeps on each voucher as gst_status reads them, with the party and the invoice total added. Each item says which list it is on: uncertain, or overridden (its acceptance flag reads Yes, with its gst_status as Tally reads it now; a voucher can be on both; that nothing but Accept As Is sets the flag to Yes is not measured), and holds the voucher number, date, party (the party ledger), amount (the invoice total without its sign, exact) with party_side (debit or credit, from Tally's sign), master_id and alter_id. pre_filing_line is the line a CA reads before filing, with the number of uncertain vouchers; it names the voucher type it covers (it does not say the type is a Sales type), and is withheld, with the result partial, when a voucher's flags or acceptance flag were not read or a listed voucher's party or amount was not, so its number is never short; it is also withheld, the result staying complete, when no voucher was read or none is uncertain. It adds nothing to Tally. The reason for uncertainty is not read, and bills missing an HSN/SAC are not split out: they need re-saving with the code, not Accept As Is. To confirm an acceptance after someone accepts vouchers in Tally, run it again and compare by master_id: the acceptance is confirmed only if an earlier run listed the voucher uncertain and this run lists it overridden and included with the same amount. That shows only that the acceptance flag was set and the voucher reads included with the same amount, not that the voucher is correct or complete; nothing is kept between runs. Unlike gst_status this answer carries party names and amounts: the party masking setting masks the names and not the amounts. Limits: one voucher type by its exact name, at most 93 days, a book whose voucher mark is above 25,000 is refused, and a window holding more than 1,000 vouchers is refused (gst_uncertain_window_too_large, provisional) before the amounts are read; rows above this server's row limit are refused with their counts; an answer is not paged, so one over this server's response byte cap is refused whole (agent_response_too_large): ask for a shorter window; a second read that returns fewer vouchers than the count read found is refused (gst_uncertain_wide_read_short). The party is the party ledger (a cash sale shows the cash ledger) and the amount is the invoice total on the party's entry, tax and round-off included, not the taxable value of the GSTR-1 tables. Measured on one synthetic book of TallyPrime 7.1 Silver, for the unregistered buyer of its Sales invoices, before and after one Accept As Is; not measured: item invoices, a registered buyer, credit notes or other Sales-class types, foreign currency, the amount of a post-dated voucher, an Accept As Is of several vouchers at once, Gold and other releases. Take company_guid from list_companies and the type name from masters. This reads the book's voucher mark, counts the window's vouchers with the status read, and then reads them with party and amount (about 7.5 KB a voucher). 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.