com.datavrn/schedule-iii

Show EXACTLY what undoing one automatic sync would do, counted at this moment, and get the approval restore_replacement needs. destroy_count is how many records undoing it would DESTROY — everything currently held for that period, whoever or whatever put it there, including data a colleague uploaded since. restore_count is how many records would be put back. READ BOTH NUMBERS TO YOUR USER IN THEIR OWN TERMS AND GET THEIR EXPLICIT GO-AHEAD BEFORE CALLING restore_replacement. Undoing a sync is itself a destructive act. If blocked_reason comes back non-null, the period is locked by a finalised statement or a sealed run: read that reason out, do not call restore_replacement, and no approval is issued. The approval is single-use, expires in 15 minutes, and is tied to this entity, this sync, this connection, the member you name AND the exact destroy_count returned here. Send that same number back as expected_destroy_count — never a number you adjusted. If the period’s data changes in between, the approval is spent and you start again from here.

Undo one automatic sync: destroy what is currently held for that period and put back the records the sync replaced, recorded as authorised by the member you name. THIS DESTROYS DATA. Everything currently held in that period goes — including anything uploaded or synced since — and is replaced by what was there before. Datavrn keeps a record of what this destroys, but it is NOT offered back on this surface; recovering from an undo is a support operation. Call preview_replacement_restore first, read both of its numbers to your user, get their explicit go-ahead, and send back the confirm_token it gave you with the EXACT destroy_count it returned as expected_destroy_count. Datavrn refuses and changes nothing if: the period’s data moved after you were shown those numbers, the period is locked by a finalised statement or a sealed run, someone already undid this sync, the 30-day window has closed, or the replacement was one a person previewed and confirmed themselves. On success it reports how many records were destroyed, how many were put back, and — under soft_reference_relink — how many links to the restored documents could not be re-established; tell your user that residual number rather than presenting the undo as complete.

Withdraw a recorded capture answer or review confirmation. What happens next depends on what answers the section: withdrawing a “nothing to record”/“does not apply” answer or a review confirmation makes Statement readiness show the section as UNANSWERED again; withdrawing a leftover earlier note from a section that is answered by its saved rows removes the record and the section STAYS answered. A version you have already generated is NOT affected — if you do not want that version finalised, answer the section again and generate a fresh version. Nothing is deleted: the withdrawn answer stays on the record with who recorded it and who withdrew it, and recording a new answer afterwards creates a new entry rather than overwriting the old one. One thing on this connection is affected immediately: if you already called get_finalise_readiness and hold an approval for that version, withdrawing an answer invalidates it, and the next finalise_statement will refuse and ask you to review the current state again.

Save the Significant Accounting Policies text (Note 2) your user has chosen, one policy per title. SEND THE COMPLETE SET EVERY TIME: this replaces all of Note 2, so any title you leave out of this call is removed — including one someone answered in the Datavrn app. Call list_statement_policy_choices first and send back every title. If your call would drop a saved policy, Datavrn saves nothing and returns an approval request naming how many would be dropped — show your user, and send the approval back only if they mean to drop them. A complete resend drops nothing and saves straight away. Use the exact policy headings this statement format carries; a heading Datavrn does not recognise is refused and nothing is saved. Resolving a bracketed template choice such as "[FIFO / weighted average]" is an ACCOUNTING POLICY DECISION SPECIFIC TO THIS ENTITY: get your user’s explicit choice, and never pick one because it is the common answer. If a policy was set this year and differs from last year’s answer, that is a CHANGE IN ACCOUNTING POLICY requiring disclosure under AS-5 / Ind AS 8 — tell your user before you save it. Check list_statement_policy_choices first: a row that differs from last year while its captured flag is false is NOT a change — last year’s wording has simply not been carried forward, and unless you send it again this note prints Datavrn’s generic template wording in its place. Saving here re-opens the disclosure review — after your last change, confirm the disclosure review again with confirm_capture_review before generating. Recorded as authorised by the member you name. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.

Save one balanced adjustment journal entry (debits = credits) as an atomic whole entry. Creating a new entry proceeds immediately. Replacing an existing entry first returns an approval request; nothing changes then. Review the existing entry in the Schedule III workspace, then resend the unchanged request with the approval details to proceed. Amounts are strings in rupees.

Save fixed-asset movements (additions, deletions, depreciation charge, depreciation on deletions) per gross-block line for the PPE schedule.

Save the notes/disclosures sections the user provides for the statement. Some of these sections IDENTIFY PEOPLE BY NAME — shareholders, promoters and related parties — so send only what your user has given you, exactly as they gave it. SECTIONS YOU DO NOT SEND ARE LEFT ALONE. Send only the sections you are changing; every other section keeps exactly what is saved. Within a section you DO send, the rows you send REPLACE every row saved for that section — there is no row-level merge, so always send that section complete. To CLEAR a section, send it explicitly with its own empty value: [] for corporateInfo, contingent, shareholders5pct, promoters, relatedParties and msmeAmounts; {} for ratioReasons; null for auditorPayments, csr, proposedDividend and the DSCR amounts. The three ageing sections take [] or null. Clearing removes saved content, so Datavrn saves nothing and returns an approval request naming the sections and how many rows each holds. Show your user exactly what would be cleared; only if they mean to, resend the identical call adding removal_token and removal_count from that response. The approval is single-use and lapses after five minutes — if it lapses, call again for a fresh one. Saving here re-opens the disclosure review — after your last change, confirm the disclosure review again with confirm_capture_review before generating. ratioReasons is keyed by the ratio IDENTIFIER, never its display label: current_ratio | debt_equity | dscr | roe | inv_turnover | tr_turnover | tp_turnover | ncap_turnover | net_profit | roce | roi. msmeAmounts is a POSITIONAL list of exactly five items, in this statutory order: 1. Principal amount and interest due thereon remaining unpaid at the year end (shown separately) | 2. Interest paid under section 16 of the MSMED Act, with the payment made beyond the appointed day | 3. Interest due and payable for delay in payment (paid beyond the appointed day), excluding MSMED-specified interest | 4. Interest accrued and remaining un…

Save the partner or owner capital schedule for an LLP or other non-corporate entity — Note 3a (capital account) or Note 3b (current account), one section per call. Send the COMPLETE schedule for the section you name: anyone you leave out is removed, and a renamed partner reads as one removal plus one addition. If your request would remove anyone, would change the figures of a partner who stays — including their profit-sharing ratio — or would repeat a person’s name that is not already repeated on file, this returns an approval request first and changes NOTHING; tell your user exactly what would change and get their go-ahead before resending with the approval. Two rows with the same person name are both kept: Datavrn never merges them, because two partners may genuinely share a name. A repeated name is therefore saved as a separate row each time it appears, and every one of those rows adds to that person’s balance on the note, so check with your user that there really are that many people before you send a schedule that repeats a name. Adding a partner with a new, different name needs no approval. share_pct is the profit-sharing ratio stated in the LLP or partnership agreement at the reporting date. A ratio that changed part-way through the year cannot be represented here, and a partner who joined or left mid-year cannot be dated — record the position at the reporting date and tell your user the note cannot explain a mid-year change. These figures come from the agreement; Datavrn does not verify them. Datavrn warns about ratios that do not total 100% only when at least TWO capital-account rows carry a ratio, so a partly-filled schedule gets no warning at all — check the total yourself with get_partner_capital. This is your user’s data about named people, recorded as authorised by them. After a successful save, read the section back with get_partner_capital and show your user the new closing balances — this replaces the whole section, and a schedule they cannot see a…

Upsert provision movements (additions, amounts utilised) per provision line. Omitted saved lines stay unchanged. To remove selected saved lines, pass remove_leaf_codes; to remove the entire saved set, pass clear_all (never both). An actual removal first returns an approval request; nothing changes then. Review current movements in the Schedule III workspace, then resend the unchanged request with the approval details to proceed.

Override the prior-year comparative for one or more statement lines with an audited figure. The prior-year column fills itself automatically from the previous year's Trial Balance read through the current groupings, so use this only when the audited financial statements differ from that figure (for example appropriations booked outside the ledger), or when there is no previous-year Trial Balance to derive from — ask your user for the audited figures in those cases.

Save the CARO / Other Regulatory Information affirmations your user has confirmed, one per title. SEND THE COMPLETE SET EVERY TIME: this replaces the whole Other Regulatory Information note, so any title you leave out of this call is removed — including one someone answered in the Datavrn app. Call list_statement_policy_choices first and send back every title. If your call would drop a saved affirmation, Datavrn saves nothing and returns an approval request naming how many would be dropped — show your user, and send the approval back only if they mean to drop them. A complete resend drops nothing and saves straight away. Use the exact affirmation headings this statement format carries; a heading Datavrn does not recognise is refused and nothing is saved. Some statement formats — the ICAI formats for LLPs and non-corporate entities — carry no Other Regulatory Information note at all, and this tool refuses for them. Each affirmation is a REGULATORY REPRESENTATION made in the entity’s name — for example whether any proceedings for benami property are pending, or whether the entity has been declared a wilful defaulter. Put each one to your user individually and record their answer. Never affirm one because it is the usual answer, never infer one from a template default, and never confirm a batch of them in one go. If an affirmation differs from last year’s answer, tell your user — call list_statement_policy_choices to see what was answered last year. Saving here re-opens the disclosure review — after your last change, confirm the disclosure review again with confirm_capture_review before generating. Recorded as authorised by the member you name. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.

Upsert reserves/equity movements (transfers in/out, dividends, other changes) per reserves line. Omitted saved lines stay unchanged. To remove selected saved lines, pass remove_leaf_codes; to remove the entire saved set, pass clear_all (never both). An actual removal first returns an approval request; nothing changes then. Review current movements in the Schedule III workspace, then resend the unchanged request with the approval details to proceed.

Save the share-capital reconciliation for the period: the opening share count, the shares issued and bought back during the year, and the amount issued and the amount bought back.

Save statement settings (rounding unit, signatory details, company information used on the statement face).

Correct the detected header row of a staged upload (1-based). Only needed when get_upload/upload_trial_balance shows the wrong row was detected.

Stage a Trial Balance spreadsheet (xlsx or csv, max 4 MB) for an entity by INLINING its bytes as base64. This path is ONLY for programmatic callers (a script, Claude Code, an automation) that already have the raw file on disk. If a HUMAN has the file — e.g. they attached it to this chat — do NOT use this tool and do NOT base64-encode the file: call create_upload_link instead and give them the link to upload it in their browser. File size does not change this: even a small attached file goes through create_upload_link — inlining a human-supplied file is unreliable and its bytes routinely truncate. Even for a file you hold on disk, prefer create_upload_link once the file is larger than about 10 KB: base64 through a model context mutates a token often enough that the damage lands as a PLAUSIBLE trial balance, not as an obvious error. VERIFY THE HASH BEFORE YOU CONFIRM ANYTHING: this tool returns received_file_hash, the sha256 of the bytes the server actually received. Compute the sha256 of the file on your disk and compare the two. If they differ, the bytes changed in transit — do NOT call confirm_column_mapping on this session; re-send the file with create_upload_link instead. A mismatched file can still parse cleanly and still show sensible columns, so the hash is the only reliable check. Returns the upload session with detected columns and mapping SUGGESTIONS — nothing is ingested yet. Next: verify received_file_hash, then review the suggested column mapping with your user, then call confirm_column_mapping.

Confirm the Datavrn connection is working and report what it can do. Call this first — or whenever the user asks whether Datavrn is connected — to get back the organization, the access profile (what this connection may see and do), and the next step. Running it successfully also marks the connection healthy in the user’s Datavrn settings.