outstandings

Answer what is outstanding: receivable and payable totals from Tally's own paired bills reports, ageing, the top parties and the open bills, on a freshly observed supported product and mode and a date valid for the operation. as_of is optional: left out, it is this computer's date (tally_status today), and the date used is always returned as result.as_of, whatever the state. open_bills_total counts every open bill in the requested direction, all of which totals and the ageing cover, and open_bills_shown counts the bills on this page (limit is not lowered when the response size shortens the page): when shown is less than total, say so plainly, for example "showing 500 of 1,240 open bills; the totals and the ageing cover all 1,240" (on a later page, the bills from offset + 1; on a partial read, both counts and the sentence cover the base-currency ledgers only, so say so in it), and ask for the next bills with offset set to next_offset. receivable and payable follow the sign of each bill's balance, as Tally's own Bills Receivable and Bills Payable reports scope them, not the type of party: a customer's advance or a credit note raised to a customer appears under payable, and a supplier's advance or a debit note raised to a supplier under receivable, because those reports carry no bill type. That holds for an advance or a note kept as its own bill: an on-account advance goes to the unallocated figure instead, and a credit note set against an open invoice reduces that invoice. Measured on one synthetic book (TallyPrime Silver 7.1). Read a bill's kind as a direction, not as owed by a customer or owed to a supplier. An unallocated amount's direction is the sign of the party's net unallocated balance, so an on-account receipt and an on-account payment on one party net into one figure. A book with several Currency masters is read through the INR base Tally identifies. If it has ledgers kept in another currency (foreign_currency_ledgers_excluded, each with its currency) or base-currency ledgers whose balance Tally shows in another currency (base_currency_ledgers_mixed_excluded, each set aside with all its bills), the state is partial with partial_reason currency_ledgers_excluded and partial_reasons naming the lists that are not empty: figures cover its base-currency ledgers only, under base_currency_ledgers, never a total for the whole book, and both lists are always present, paged like the bills. Each unallocated party carries ledger_bill_wise, opening_balance (the ledger's opening as of the start of the books, with Tally's sign, so a debit opening is negative, never interpreted; absent when Tally sent none, which is unknown, not zero) and a composition: not_bill_wise_ledger (the ledger keeps no bills) or bill_wise_ledger_components_not_separated (what is left on a bill-wise ledger after its named bills: on-account entries, an unallocated opening, notes with no reference and anything else, not told apart). amount is a magnitude and direction says which side; unallocated.totals.by_composition splits the gross, receivable and payable apart, by those two over every party in the requested direction before paging (a row saved without one counts under composition_not_observed). No unallocated figure is labelled on-account. Party detail: with party (a ledger name) and detail, the result also carries a detail object for that party at the same as-of. The detail's ledger_match names the ledger read, how (matched: exact, or case_or_spacing, which the answer should mention by naming the ledger read) and any similar_ledgers that differ from it only in case or whitespace. Passing detail is the request to read the company's vouchers from the start of the books (or, for a named bill that Tally's bills reports list, from the earliest date they list for it) to as_of; nothing is read for a party detail without it. bill_trail (optionally one reference) lists every allocation of each bill in vouchers that are neither cancelled nor optional, oldest first, with state tied (the signed allocations equal Tally's own balance for that bill, or zero for a bill the report no longer lists), trail_does_not_tie (both numbers shown) or bill_identity_ambiguous (more than one native row or bill date for one reference, or a native row dated differently from the allocations; nothing is merged, and the native dates are shown). Naming a reference starts the read at the earliest date the reports list for it, so allocations dated earlier are not read, and a reference that carries two bill dates over the whole history, and is ambiguous there, can tie when named. The detail's own state is bills_listed, or for an empty list not_bill_wise_ledger or no_named_bill_for_party (no named bill in the vouchers or in Tally's list: a ledger that keeps no bills, one that is not a party's and a party with no bills are not told apart). The company's two change marks are read before the bills and again after the vouchers, and a detail whose marks moved is refused (voucher_window_changed_during_read); a change that moves neither mark is not seen (a letter-case-only rename of a ledger moved neither, in one book), and allocations that net to zero can still read tied. unadjusted lists the party's on-account, advance and pending note allocations and compares their on-account sum with the party's unallocated amount: tied means the two figures are equal, not that the composition is proven (components that net to zero are not seen); residual_not_explained_by_vouchers gives the difference and whether it equals the ledger's opening balance; no_residual_row_for_party (with residual null) means Tally lists no unallocated amount for the ledger (a zero residual, a ledger that is not a party's and a name that matched no row are not told apart), so nothing is tied; not_bill_wise_ledger lists no rows. Its rows are row_amounts: as_allocated: each amount is the allocation as made, never net of what later allocations adjusted against its reference, so an advance shows what was received, not what is left; what is still open on a reference is Tally's own native_balance beside the row, null when the reports do not list the reference or list it more than once (so no balance is chosen), told apart only by native_rows. Either detail is window_returned_no_vouchers, with nothing tied or listed, when the voucher read returned no voucher (that read is not corroborated). Cost and limits: the detail reads the whole company's vouchers (window.company_vouchers_read), costing a vouchers read over the same span, which is unmeasured on a large book, and any refusal of that read fails the whole outstandings call. Only when that read needs too many requests is the party read by its ledger alone (window_scope ledger_scoped, window.party_vouchers_read), and only for a ledger matched alone whose name its vouchers carry as stored, in single-spaced ASCII letters and digits with no operator word; otherwise the refusal stands and its window_scope says why. One foreign-currency composite voucher anywhere in the window fails it (voucher_amount_invalid, or bill_allocation_amount_invalid on an allocation). At most 128 data requests are sent (each sent twice, as every read is, with its census and the company marks besides), each holding at most 42 vouchers before anything is measured, so a window of more than 5,376 of the company's vouchers is refused unless the party is read by its ledger, and a smaller one may be. The refusals are trail_window_too_large (name a reference that open_bills lists for the party, and the read starts at that bill's date), named_bill_window_too_large (a reference was named already, so nothing narrows it further) and unadjusted_window_too_large (nothing narrows it, so it is not available for that party on that book), each with reads.needed_at_least against reads.allowed; a refusal comes before any data request when the count shows it, otherwise when a measured part does, with window listing any part already read. The detail needs a complete read (detail_requires_a_complete_read, with the read's own partial_reason) and refuses rather than cuts an answer of over 500 allocations: trail_too_large (name a reference) or unadjusted_detail_too_large (nothing narrows it). The limit counts allocations, not bills, so a party with very many opening bills can meet agent_response_too_large instead. For a ledger's master record (its group, opening balance and, with fields=compliance, GSTIN and party details), use ledger_masters 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.