ФИНАНСОВАЯ ОБЛАСТЬP0L3

Версии соответствий счетов статьям отчётности

Как проверить покрытие счетов правилами отчётности, исключить размножение сумм и сохранить версию классификации для пересчёта.

12 мин чтения·База знаний

Задача и границы#

Один счёт может относиться к разным статьям отчётности в разные периоды или в разных формах отчёта. Нужно классифицировать каждую выбранную строку проводки ровно один раз в пределах одной формы и версии правил, сохранив сумму и возможность воспроизвести ранее выпущенный результат.

Это инженерный контракт для витрины движений по статьям, а не требование бухгалтерского стандарта и не описание опыта автора. Он предполагает однозначное соответствие без распределения по весам. Общая история справочников разобрана в моделировании и семантике времени; здесь рассматриваются покрытие, кардинальность соединения и версии классификации. Остатки, консолидационные исключения и правила признания финансовых показателей требуют отдельных контрактов.

Зерно, ключи и сумма#

Входное зерно - выбранная версия строки проводки. Ключ включает систему-источник, юридическое лицо, регистр, документ и номер строки; идентификатор версии хранится отдельно. До классификации набор должен содержать только одну выбранную версию каждой логической строки. Валюта и масштаб суммы обязательны. В синтетическом примере сумма выражена целыми копейками RUB: дебет положительный, кредит отрицательный. Правило отображения знака статьи задаётся отдельно от распределения по статьям.

Зерно правила - один интервал соответствия счёта одной конечной статье внутри неизменяемого набора правил. Контекст поиска включает источник, юридическое лицо, регистр, план счетов и его версию, счёт, форму отчёта и rule_set_id. Если классификация зависит от подразделения или типа операции, эти признаки становятся частью контекста; соединение только по номеру счёта недостаточно.

Поле	Смысл в предлагаемой модели
`rule_set_id`, `rule_id`	Идентификаторы набора правил и отдельного правила
`report_item_id`	Конечная статья в закреплённой версии структуры отчёта
`valid_from`, `valid_to`	Начало включительно и конец исключительно: `[valid_from, valid_to)`
`business_date`	Дата строки, используемая для выбора интервала; здесь это дата проводки
`observed_at`	Когда EDWH впервые получил версию строки
`approved_at`	Когда набор правил был утверждён ответственным процессом

Дата действия правила не равна времени его утверждения. Исправление, утверждённое в феврале с действием с января, создаёт новый набор правил. Старый набор не переписывается. Имена полей и выбор даты проводки - соглашения этой модели. При специальных финансовых периодах вместо календарного интервала может потребоваться ключ периода регистра.

Покрытие до агрегации#

Для каждой входной строки определяют число подходящих правил внутри выбранного набора и контекста. Ноль означает отсутствующее соответствие, единица - допустимое, больше единицы - неоднозначное. Две одинаковые записи с одной статьёй тоже являются ошибкой: обычное соединение всё равно удвоит сумму.

Следующий алгоритм - псевдокод, не исполняемый SQL или Python:

Закрепить входной набор версий строк и rule_set_id для одной формы отчёта.
Проверить уникальность входных ключей и идентификаторов правил, полноту контекста.
Для каждой строки найти правила по полному контексту и интервалу даты.
Сохранить ключ строки, число совпадений и идентификаторы кандидатов.
Если число совпадений не равно одному, остановить окончательный выпуск.
Соединить допустимые строки с единственным правилом.
Сохранить связь строки с rule_id, rule_set_id и конечной статьёй.
Сверить набор ключей, число строк и суммы по валюте и масштабу.
Агрегировать по форме, статье, периоду, валюте и масштабу.

Проверка покрытия выполняется от всех входных строк, включая строки без кандидатов. Внутреннее соединение теряет такие строки. Выбор первой записи или DISTINCT после соединения скрывает нарушение контракта. Если разрешены общие правила и частные исключения, сначала задают явный приоритет и проверяют единственность победителя; порядок хранения строк приоритетом не является.

Политика временной статьи «Не классифицировано» допустима для явно предварительной витрины: сохраняются исходные ключи, суммы и причина. Она не доказывает готовность окончательного отчёта. Проверять только счета с ненулевым итогом нельзя: взаимно погашающиеся строки также требуют соответствий.

Синтетический пример и инварианты#

Две январские строки одного счёта имеют суммы +10000 и -2000 копеек RUB. Набор R1 относит обе к статье A. Новый набор R2, утверждённый в феврале, относит этот счёт с 1 января к статье B. Это вымышленная переклассификация без изменения проводок.

Расчёт	Статья A, копейки RUB	Статья B, копейки RUB	Общий итог
Старый выпуск, R1	8000	0	8000
Пересчёт того же входа, R2	0	8000	8000

Мост изменений показывает -8000 по A и +8000 по B. Равенство общего итога не означает неизменности отчёта. Если оба правила ошибочно попали в один выбранный набор с пересекающимися интервалами, каждая строка получит два соответствия и итог станет 16000. Нельзя соединять факты со всеми версиями правил одновременно.

Основной инвариант - ровно одна выходная строка на каждую входную строку в каждой выбранной форме. Проверяют равенство наборов ключей и суммы до изменения знаков представления, отдельно по валюте и масштабу. Контроль общей суммы дополняют суммами положительных и отрицательных строк: ошибки могут взаимно погаситься. Денежные суммы разных валют не складывают.

При построении иерархических итогов строка относится к конечной статье, а затем участвует в итогах предков. Нельзя суммировать конечные статьи вместе с их промежуточными итогами. Несколько форм отчёта также образуют разные представления одних фактов и не складываются между собой.

Версия выпуска и альтернативы#

Выпуск закрепляет входные версии строк или воспроизводимый снимок, набор правил, версию структуры отчёта, календарь и правила знаков. Сохраняются результаты покрытия, связи с правилами и версия расчётного алгоритма. Одного observed_at недостаточно, если данные или правила впоследствии перезаписываются; время доступности входа определяется контрактом закрытия периода.

Пересчёт старого периода новыми правилами создаёт новый выпуск со ссылкой на предыдущий. Для объяснения разницы сначала классифицируют одинаковый вход двумя наборами правил, затем отдельно оценивают изменение входных данных. Так изменение правил не смешивается с поздними проводками. Хеш набора помогает обнаружить изменение, но не заменяет сохранение содержимого и зависимостей.

Альтернатива - хранить соответствия с деловым и системным временем вместо полных снимков наборов. Это уменьшает копирование, но требует корректного выбора обеих временных координат и сохранения всей истории. Полные неизменяемые наборы проще закреплять в выпуске, однако занимают больше места. Обе стратегии должны давать однозначный результат.

Распределение одной строки между несколькими статьями - другая модель: нужны веса, контроль их суммы и остатка округления в минимальных единицах валюты. Нельзя вводить его как случайный результат неоднозначного соединения.

Ограничения СУБД и граничные случаи#

В PostgreSQL 18 типы диапазонов представляют интервалы, а exclusion constraints позволяют запрещать пересечения. Это средство контроля неоднозначности. Для составного контекста нужны подходящие операторы и индексная поддержка; готового DDL и утверждения о тестировании PostgreSQL здесь нет. Непересечение не гарантирует отсутствие пробелов в покрытии.

Согласно документации ограничений PostgreSQL 18, обычный CHECK не поддерживает проверку других строк таблицы. Поэтому строковые проверки границ и внешние ключи не заменяют контроль покрытия фактов выбранным набором правил. Эти свойства конкретной СУБД не следует автоматически переносить на SQLite или Greenplum. Модель соответствий не выводится из требований SQL или бухгалтерского стандарта.

Перед выпуском проверяют дату ровно на границе соседних интервалов, пробел между ними, повтор правила, неизвестный счёт, повторное использование номера в другой версии плана счетов и отсутствующую конечную статью. Открытый конец интервала должен иметь одно согласованное представление. Пустой интервал запрещён. Поздняя строка за пределами проверенного периода требует новой проверки покрытия. Проверка текущих фактов не доказывает покрытие будущих счетов: для него отдельно согласуют ожидаемый каталог и горизонт действия правил.

Исправление справочника: основание и новый basis#

Ошибка реализации соответствия и новая политика классификации требуют разных оснований. Если утверждённое правило относило счёт к B, а справочник ошибочно содержал A, исправляют реализацию с документированным интервалом ошибки. Если принято новое правило, фиксируют решение, дату действия и область применения; дата загрузки справочника не определяет начало его действия. Ответственный за отчётность отдельно решает, какие сравнительные периоды представить заново. Изменение справочника само по себе не доказывает ошибку бухгалтерской отчётности.

Обзор IAS 8 IFRS Foundation различает изменения политики, оценки и ошибки. Он описывает ретроспективное применение изменений политики с исключениями и исправление существенных ошибок прошлых периодов с оговоркой о практической осуществимости. Поэтому новая политика не означает автоматически «только вперёд». Применимую редакцию, переходные положения и существенность определяет учётный процесс; полный текст может требовать доступа. Эти положения не задают алгоритм EDWH ниже.

Для изолированной оценки влияния закрепляют прежний входной снимок, cutoff, валюту, масштаб, календарь, курсы и алгоритм, меняя только версию исправленного справочника. Это новый basis и кандидат нового выпуска. Если одновременно включают поздние события или меняют курсы, перечисляют эти изменения отдельно: разница уже не объясняется одним справочником. Прежний выпуск и его манифест сохраняют без перезаписи.

Поиск затронутых строк, периодов и выпусков#

Зерно оценки влияния - версия исходной строки в конкретном входном снимке выпуска. Реестр кандидатов хранит release_id, полный ключ строки, старую и новую версии справочника, интервал изменения, прямую причину и зависимые результаты. observed_at исправления определяет момент доступности новой версии, а не период финансового влияния.

Сначала сравнивают старое и новое содержимое правил по полному контексту. Разбивают объединение старых и новых интервалов по всем границам и находят участки, где различается результат выбора, покрытие или неоднозначность. Удаление правила, изменение ключа, приоритета либо конечной статьи тоже являются изменением. При смене ключа проверяют старый и новый контекст. Нельзя отбирать только строки, ранее связанные с изменённым rule_id: добавленное правило может затронуть ранее непокрытые строки.

Затем ищут строки в сохранённых входных снимках потенциально затронутых выпусков по этим контекстам и датам [valid_from, valid_to). Для движения дата относится к периоду по закреплённому календарю регистра, включая корректировочные периоды. Регистрируют также выпуски с нулевым итогом и предварительные выпуски с отсутствующим соответствием. Текущая таблица фактов не заменяет исторические входы. Индекс lineage ускоряет отбор, но его полноту нужно подтвердить снимками и манифестами.

От прямых строк проходят по зависимостям: конечные статьи, итоги и сравнительные колонки, производные показатели и остатки. Для остатка горизонт зависит от формулы: если классифицируют накопленные движения, январское исправление может изменить последующие остатки; если независимо классифицируют снимок на каждую отчётную дату, проверяют правила на эти даты. Граница интервала правила сама по себе не обрывает зависимость накопленного результата. Сохраняют путь влияния и основание остановки для каждого потребителя. Неполный граф или утраченный вход означает неизвестную границу, а не отсутствие влияния; применяют более широкий пересчёт либо блокируют заключение о полноте.

Выбор пересчёта и контроль полноты влияния#

Разделяют технически затронутые выпуски и выпуски, выбранные для нового представления. Для каждого кандидата сохраняют решение: пересчитать, сохранить только исторический результат или отложить с причиной и ответственным. Неизменный общий итог не исключает изменения статей. Старый ID не получает новые ячейки; управление заменой описано в закрытии периода, объяснение различий - в финансовой lineage.

Синтетический пример расширяет R1/R2 выше: изменение действует в январе [2026-01-01, 2026-02-01), а февральские движения классифицируются как прежде. Прямое влияние на январские A и B составляет соответственно -8000 и +8000 копеек RUB. Если февральский остаток по статье рассчитывается накоплением движений, в него переходят те же изменения; февральский оборот от этого не меняется. Если отчёт использует независимый снимок, такой перенос нельзя предполагать. Это разные контракты, а не два результата одного алгоритма.

Приёмка оценки требует покрытия всех изменённых контекстов и участков интервала, уникальности ключей кандидатов внутри выпуска и решения по каждому зависимому результату. Проводят проверки на начале включительно и конце исключительно, на удалённом правиле, новом ключе, нулевом сальдо при ненулевых строках и пересечении финансового года. Подтверждают, что исключённые выпуски действительно вне области влияния, а не отсутствуют в индексе. После пересчёта повторяют контроль покрытия и сумм по валюте и масштабу; прежние версии должны оставаться воспроизводимыми.

Узкая оценка дешевле полного пересчёта, но требует полного графа и архивных входов. Консервативный широкий пересчёт уменьшает риск пропущенной зависимости, однако не заменяет учётное разрешение на новое представление. Здесь описаны критерии решения, нет планировщика или исполняемого SQL/Python; оценка и пересчёт не выполнялись. Представление интервалов в PostgreSQL 18 не доказывает полноту этого процесса.

Вопросы для подготовки: почему связи с прежним правилом недостаточно после добавления нового? Когда январское исправление меняет февральский остаток, но не оборот? Как обосновать непересчёт исторического выпуска при неполном графе зависимостей?

Связанные темы и вопросы#

Независимые проверки полноты рассматриваются в сверке данных. История входных событий и история правил являются разными зависимостями одного выпуска.

Почему два правила одной статьи нельзя считать одним допустимым соответствием?
Как объяснить изменение статей при неизменном общем итоге и входном наборе?
Что потребуется сохранить, чтобы повторить январский выпуск после февральской переклассификации?

Problem and scope#

An account may map to different reporting line items in different periods or report forms. Each selected journal line must be classified exactly once within a single form and rule version, preserving its amount and allowing an earlier release to be reproduced.

This is an engineering contract for a reporting movement mart, not an accounting standard requirement or a description of the author's experience. It assumes an unambiguous mapping without weighted allocation. General reference-data history is covered in modeling and time semantics; this article addresses coverage, join cardinality, and classification versions. Balances, consolidation eliminations, and financial recognition rules require separate contracts.

Grain, keys, and amounts#

The input grain is a selected journal-line version. Its key includes source system, legal entity, ledger, document, and line number; retain the version identifier separately. Before classification, the input must contain only one selected version of each logical line. Currency and amount scale are mandatory. The synthetic example uses integer RUB kopecks, with debit positive and credit negative. A line item's presentation sign is defined separately from its classification.

The rule grain is one interval mapping an account to one leaf reporting item within an immutable rule set. The lookup context includes source, legal entity, ledger, chart of accounts and its version, account, report form, and rule_set_id. If classification depends on department or operation type, those attributes become part of the context; joining only on account number is insufficient.

Field	Meaning in the proposed model
`rule_set_id`, `rule_id`	Identifiers of the rule set and individual rule
`report_item_id`	Leaf item in a pinned report-structure version
`valid_from`, `valid_to`	Inclusive start and exclusive end: `[valid_from, valid_to)`
`business_date`	Line date used to select the interval; here, the posting date
`observed_at`	When the EDWH first received the line version
`approved_at`	When the responsible process approved the rule set

A rule's effective date differs from its approval time. A correction approved in February but effective from January creates a new rule set. The old set is not overwritten. Field names and the choice of posting date are conventions of this model. Special financial periods may require a ledger-period key instead of a calendar interval.

Coverage before aggregation#

For every input line, count matching rules within the selected set and context. Zero means a missing mapping, one is valid, and more than one means ambiguity. Two identical records pointing to the same item are also an error: a regular join still doubles the amount.

The following algorithm is pseudocode, not executable SQL or Python:

Pin the input set of line versions and rule_set_id for one report form.
Validate uniqueness of input keys, context completeness, and rule identifiers.
For each line, find rules by the full context and date interval.
Retain the line key, match count, and candidate identifiers.
If any match count differs from one, stop the final release.
Join valid lines to their single matching rule.
Retain the link from each line to rule_id, rule_set_id, and leaf item.
Reconcile key sets, row counts, and amounts by currency and scale.
Aggregate by form, item, period, currency, and scale.

Coverage starts from all input lines, including those with no candidates. An inner join loses such lines. Selecting the first record or applying DISTINCT after the join conceals a contract violation. If general rules and specific exceptions are allowed, define explicit precedence first and check that there is a single winner; storage order is not precedence.

A temporary "Unclassified" item can be allowed in an explicitly preliminary mart: retain source keys, amounts, and the reason. It does not establish readiness for a final report. Checking only accounts with a nonzero total is insufficient: offsetting lines also need mappings.

Synthetic example and invariants#

Two January lines for one account have amounts of +10000 and -2000 RUB kopecks. Set R1 maps both to item A. New set R2, approved in February, maps the account to item B from January 1. This is a fictional reclassification with unchanged journal entries.

Calculation	Item A, RUB kopecks	Item B, RUB kopecks	Total
Previous release, R1	8000	0	8000
Same input recalculated, R2	0	8000	8000

The change bridge shows -8000 for A and +8000 for B. An unchanged total does not mean an unchanged report. If both rules accidentally enter one selected set with overlapping intervals, each line gets two matches and the total becomes 16000. Facts must not be joined to all rule versions at once.

The main invariant is exactly one output line for each input line in each selected form. Check equality of key sets and amounts before applying presentation signs, separately by currency and scale. Supplement the overall sum with sums of positive and negative lines: errors can offset each other. Do not add monetary amounts in different currencies.

For hierarchical totals, a line maps to a leaf item and then contributes to ancestor totals. Do not sum leaf items together with their subtotals. Multiple report forms are also different views of the same facts and must not be added together.

Release version and alternatives#

A release pins input line versions or a reproducible snapshot, the rule set, report-structure version, calendar, and sign rules. Retain coverage results, links to rules, and the calculation-algorithm version. An observed_at cutoff alone is insufficient if data or rules are later overwritten; input availability follows the period-close contract.

Recalculating an old period with new rules creates a new release linked to its predecessor. To explain the difference, first classify identical input with both rule sets, then assess input changes separately. This separates rule changes from late journal entries. A set hash helps detect changes but does not replace retaining its contents and dependencies.

An alternative is to store mappings with business and system time rather than complete rule-set snapshots. This reduces copying but requires correct selection of both time coordinates and retention of the full history. Complete immutable sets are easier to pin in a release but require more storage. Both strategies must produce an unambiguous result.

Allocating one line across several items is a different model: it needs weights, checks on their sum, and treatment of rounding residuals in minor currency units. It must not arise accidentally from an ambiguous join.

Database constraints and boundary cases#

In PostgreSQL 18, range types represent intervals, and exclusion constraints can prohibit overlap. This helps control ambiguity. A composite context requires suitable operators and index support; this article provides no ready-to-run DDL or claim of PostgreSQL testing. Non-overlap does not guarantee gap-free coverage.

According to the PostgreSQL 18 constraint documentation, an ordinary CHECK does not support checking other table rows. Row-level boundary checks and foreign keys therefore do not replace checking that the chosen rule set covers the facts. These database-specific properties must not automatically be assumed for SQLite or Greenplum. The mapping model is not derived from SQL or accounting standard requirements.

Before release, check a date exactly at adjacent interval boundaries, a gap between intervals, a repeated rule, an unknown account, reuse of an account number in another chart version, and a missing leaf item. An open interval end must have one agreed representation. Empty intervals are prohibited. A late line outside the checked period requires another coverage check. Checking current facts does not prove coverage of future accounts: agree the expected catalog and rule horizon separately.

Reference-data correction: rationale and a new basis#

A mapping implementation error and a new classification policy require different grounds. If the approved rule assigned an account to B but the reference data incorrectly contained A, correct the implementation and document the error interval. For a new rule, record the decision, effective date, and scope; the reference-data load date does not determine when it takes effect. The reporting owner separately decides which comparative periods to present again. A reference-data change alone does not establish a financial-statement error.

The IFRS Foundation overview of IAS 8 distinguishes policy changes, estimate changes, and errors. It describes retrospective policy application with exceptions and correction of material prior-period errors subject to practicability. A new policy therefore does not automatically mean prospective application only. The accounting process determines the applicable edition, transitional provisions, and materiality; full text may require access. These provisions do not specify the EDWH algorithm below.

To isolate the impact, fix the previous input snapshot, cutoff, currency, scale, calendar, exchange rates, and algorithm, changing only the corrected reference-data version. This defines a new basis and a candidate release. If late events or different rates are also included, list those changes separately: the difference no longer comes from reference data alone. Preserve the previous release and its manifest without overwriting them.

Finding affected rows, periods, and releases#

The impact-assessment grain is an input row version within a particular release input snapshot. The candidate register records release_id, the full row key, old and new reference-data versions, the changed interval, direct cause, and dependent results. The correction's observed_at determines when the new version became available, not the period of financial impact.

First compare old and new rule contents using the full context. Split the union of their intervals at every boundary and identify segments where the selected mapping, coverage, or ambiguity differs. Deleting a rule or changing a key, priority, or target item also counts as a change. For a key change, check both contexts. Do not select only rows previously linked to the changed rule_id: an added rule may affect previously uncovered rows.

Next find rows in the preserved input snapshots of potentially affected releases using these contexts and dates in [valid_from, valid_to). For movements, assign dates to periods using the pinned ledger calendar, including adjustment periods. Include releases with zero totals and provisional releases with missing mappings. The current fact table cannot replace historical inputs. A lineage index speeds selection, but snapshots and manifests must establish its completeness.

Follow dependencies from direct rows to leaf items, totals and comparative columns, derived measures, and balances. For balances, the horizon depends on the formula: classifying accumulated movements means a January correction may change later balances; independently classifying a snapshot at each reporting date requires checking rules on those dates. A rule interval's boundary does not itself terminate an accumulated-result dependency. Record the impact path and stopping rationale for each consumer. An incomplete graph or lost input means an unknown boundary, not no impact; use a broader recalculation or block the completeness conclusion.

Selecting recalculations and checking impact completeness#

Separate technically affected releases from releases selected for a new presentation. For each candidate, record the decision: recalculate, retain only the historical result, or defer with a reason and an accountable owner. An unchanged overall total does not rule out changed report items. Never put new cells under an old ID; replacement management is covered in period close, and difference explanation in financial lineage.

A synthetic example extends R1/R2 above: the change applies in January [2026-01-01, 2026-02-01), while February movements retain their previous classification. The direct January impact on A and B is respectively -8000 and +8000 RUB kopecks. If February's item balance accumulates movements, the same changes carry into it; February turnover does not change for that reason. For an independent snapshot report, do not assume this carry-forward. These are different contracts, not two outcomes of one algorithm.

Assessment acceptance requires coverage of every changed context and interval segment, unique candidate keys within each release, and a decision for every dependent result. Check the inclusive start and exclusive end, a deleted rule, a new key, a zero net balance with nonzero rows, and a financial-year boundary. Establish that excluded releases are genuinely outside the impact scope rather than missing from the index. After recalculation, repeat mapping coverage and amount controls by currency and scale; previous versions must remain reproducible.

A narrow assessment costs less than a full recalculation but requires a complete graph and archived inputs. A conservative broad recalculation reduces the risk of missed dependencies, but does not replace accounting approval for a new presentation. This section specifies decision criteria; it has no scheduler or executable SQL/Python, and no assessment or recalculation was performed. PostgreSQL 18 interval representation does not establish this process's completeness.

Preparation questions: why are previous rule links insufficient after a new rule is added? When does a January correction change February's balance but not its turnover? How can a decision not to recalculate a historical release be justified with an incomplete dependency graph?

Источники и документация

Источники нужны для самостоятельной проверки. Примеры и интерпретации на сайте могут быть учебными упрощениями.