list_chart_rebaselines

com.datavrn/schedule-iii · Verify this server

List the uploads Datavrn is NOT counting as evidence of which entity a file belongs to. This happens when an entity’s chart of accounts grew or changed faster than Datavrn can vouch for from what it already holds — typically an acquisition, a migration, or a year-end restructure. NOTHING WAS REJECTED, BLOCKED OR CHANGED: the figures in those uploads are landed and live. What has not advanced is the evidence Datavrn compares FUTURE uploads against, so wrong-entity detection for this entity is working from a smaller picture than the entity’s real chart. Each row reports how many distinctive ledger names Datavrn already held (trusted_considered), how many the upload carries (incoming_considered), how many are on both sides (matched), and the two coverage ratios. Show your user those numbers in their own terms. `shortfall` names WHICH direction fell short, and it is the part to say out loud, because the three cases are different situations to an accountant: "incoming" means most of the file is ledger names Datavrn does not already treat as evidence — the chart in the file is much larger than what Datavrn holds; "trusted" means much of what Datavrn holds is missing from the file; "both" means the two charts barely overlap either way. It is null when there was nothing to compare against at all, which the row reports as reason "empty_trust_recovery". This call only lists. To confirm one of these uploads, call preview_chart_rebaseline for that upload — it re-reads the figures and issues the approval confirm_complete_chart needs. An empty list means nothing is waiting: for almost every entity that is the normal state.