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

Закрытие периода и поздние проводки

Как разделить даты и доступность данных, управлять выпуском периода и определить комплект и критерии его восстановления.

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

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

Закрытие должно фиксировать, какие данные и правила использованы для результата периода. Поздняя доставка не должна незаметно менять утверждённый отчёт. При этом EDWH должен принимать и сохранять новые данные, чтобы объяснять расхождения и поддерживать разрешённый пересчёт.

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

Зерно, ключи и даты#

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

Поле	Значение в предлагаемом контракте
`operation_date`	Дата экономической операции по данным источника
`posting_date`	Учётная дата, определяющая период проводки в данной книге
`source_posted_at`	Момент регистрации проводки источником, если доступен
`observed_at`	Момент первого получения версии EDWH
`available_at`	Момент успешной публикации версии для расчётов после проверок
`loaded_at`	Техническое время записи в слой хранения

Названия полей не являются стандартом. В этой модели business_date соответствует posting_date; переносить это соответствие на любой источник нельзя. Дата документа тоже может отличаться от даты операции. Пропущенное время источника остаётся неизвестным, его не заменяют временем загрузки.

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

Три вида позднего поступления#

Синтетический пример: расход по операции 28 января составляет 10000 копеек RUB. Документ содержит дебет расхода +10000 и кредит расчётов -10000. Январский результат зафиксирован 2 февраля с отсечкой доступности 2026-02-02T12:00:00Z.

Ситуация	Учётная дата	Доступность EDWH	Следствие
Проводка существовала в источнике к отсечке, но доставка задержалась	31 января	3 февраля	Январский выпуск не содержал документ; нужна оценка полноты и новая версия при разрешённом пересчёте
Новая проводка внесена в январь после разрешённого открытия периода	31 января	4 февраля	Это изменение учётных данных после закрытия; нужны основание и версия состояния периода
Январская операция отражена в феврале по принятому учётному решению	3 февраля	4 февраля	По учётной дате это февральский оборот; дата операции не переносит его в январь

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

Контракт закрытия и выпуска#

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

Рабочая последовательность ниже является псевдокодом, не исполняемым SQL или Python:

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

Отсечка сама по себе не доказывает полноту. Нужны подтверждения источников по согласованному объёму данных: например, завершённые выгрузки и сверка ожидаемых документов. Партия, полученная до отсечки, но опубликованная после неё, не входит в этот выпуск по выбранному определению available_at. Это правило должно совпадать с фактически сохранённым набором входов.

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

Жизненный цикл выпуска витрины#

Закрытие задаёт готовность периода, а выпуск закрепляет конкретный результат. Ниже предложен проектный контракт состояний для корпоративной витрины. Он не является требованием IAS 10 и не реализован на этом статическом сайте или в лаборатории. Выпуск EDWH не равнозначен разрешению выпуска финансовой отчётности.

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

Состояние	Допустимое действие и условие
`preparing`	Подготовить полный набор ячеек и происхождение; после фиксации манифеста новые входы требуют нового ID
`checked`	Зафиксировать успешный контроль именно этого манифеста; отсутствие обязательных данных блокирует переход
`approved`	Уполномоченный процесс утвердил проверенный выпуск; сохранены решение, основание и время
`rejected`	Контроль или утверждение отклонили кандидата; повторная подготовка создаёт новый ID
`withdrawn`	Выпуск отозван с причиной; его нельзя выбирать как действующий
`superseded`	Ранее действовавший выпуск заменён утверждённым новым; старые ячейки сохранены

Утверждение и активация различаются: утверждённый кандидат может ожидать переключения. В этом контракте отклонённый, отозванный или заменённый ID не активируют повторно. Возврат к прежним значениям оформляют новым кандидатом с повторным контролем и утверждением. Это выбранная политика управления, а не универсальное правило учёта.

Действующий выпуск и согласованное чтение#

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

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

Зафиксировать новый выпуск B и проверить все его ячейки и связи.
Сохранить утверждение B и основание замены A.
В одной согласованной операции:
  проверить ожидаемые active_release = A и версию ссылки;
  проверить, что B утверждён, не отозван и имеет тот же периметр;
  перевести ссылку на B, отметить A как заменённый, записать переход.
Если ожидание не совпало, ничего не переключать и разобрать конфликт.

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

Отзыв действующего B одновременно убирает активную ссылку и записывает причину либо переключает её на отдельно утверждённую замену. Автоматический возврат к A недопустим по выбранной политике. Сохранённые суммы и журнал переходов остаются доступны для разрешённого исторического просмотра с явным статусом.

Читатель разрешает активную ссылку один раз и закрепляет ID на весь отчёт, пагинацию, drill-back и выгрузку. Ключ кеша содержит ID; отсутствие ячейки даёт ошибку полноты, а не подстановку из другого выпуска. Старый читатель может завершить просмотр заменённого A с его статусом. Если политика запрещает чтение отозванного результата, запрос прекращают; незаметно продолжать его данными B нельзя. Права доступа проверяют по текущей политике.

Контроли включают двух одновременных утверждающих, отзыв между утверждением и активацией, повтор после потери ответа, неполный комплект ячеек и переключение между страницами выгрузки. Инварианты: активный ID утверждён и не отозван, переход имеет основание, все ячейки одного ответа принадлежат одному ID, прежний выпуск не изменён. Транзакция СУБД сама по себе не доказывает эти деловые условия. Происхождение отдельной ячейки и мост между выпусками разобраны в финансовой lineage; здесь задаётся только управление состоянием и выбором результата.

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

Восстановимость выпуска: комплект и приёмка#

Неизменяемость release_id не доказывает, что выпуск переживёт утрату хранилища. Для корпоративного контура предлагается отдельный контракт восстановления одного закреплённого выпуска. Это инженерные критерии, не требования IAS 10. Настройка резервного копирования, сроки хранения, обещания RPO/RTO и восстановление всей платформы здесь не рассматриваются.

Различают два результата: восстановление сохранённых ячеек для исторического чтения и повторный расчёт из архивных входов. Первое не доказывает второе. Зерно ячейки, валюта, масштаб, знаки, период и basis остаются заданными манифестом; нельзя подменить RUB в копейках текущей валютой представления или использовать новые курсы. Время восстановления фиксируют отдельно от исходных business_date, cutoff и времени утверждения.

Минимальный комплект зависит от заявленной цели:

Часть архива	Что сохранять и зачем
Манифест и опись	Исходный ID, периметр, период, basis, ключи и ожидаемые объекты, их версии, формат, количество записей и контрольные суммы
Зафиксированный результат	Полный набор ячеек с деловыми ключами, валютой, масштабом и знаками; нужен для восстановления чтения и как эталон пересчёта
Входные снимки	Все реально использованные версии строк и зависимые справочники, включая курсы и отображения; нужны для повторного расчёта, ссылки на текущие таблицы недостаточны
Правила и среда	Версии преобразований, параметры, календарь, политика округления, порядок операций и существенные версии СУБД/исполняющей среды; один номер версии без доступного содержимого не даёт воспроизводимости
Контроли и решения	Исходные результаты проверок полноты и баланса, исключения, утверждение, отзыв и замена; помогают сравнить восстановление и не активировать отозванный результат

Для исторического drill-back дополнительно нужны сохранённые связи с версиями строк из контракта lineage. Если есть только ячейки, доступна сумма, но не доказано происхождение до события. Архив хранится в защищённом корпоративном контуре; на публичный сайт не выгружают его данные, секреты или полномочия пользователей.

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

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

Синтетический пример: эталон содержит две ячейки +10000 и -10000 копеек RUB. Замена их на +9000 и -9000 сохраняет нулевой итог, но не проходит сравнение по ключам. Потерянная версия курса блокирует пересчёт зависимой ячейки, хотя сохранённое число остаётся читаемым. Новое время исполнения допустимо; новая учётная дата или версия курса меняет расчёт и требует другого выпуска.

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

Документация PostgreSQL 18 описывает согласованный снимок одной базы при pg_dump; снимки разных баз при pg_dumpall не синхронизированы. Это свойство конкретного средства, а не доказательство согласованности EDWH-выпуска с файлами, внешними правилами и другими базами. Успешная загрузка дампа не заменяет предметную приёмку выше. Здесь нет исполняемого SQL/Python, восстановление и пересчёт не выполнялись.

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

Учётный стандарт и поведение СУБД#

IAS 10 различает события между концом отчётного периода и разрешением выпуска отчётности: подтверждающие существовавшие на конец периода условия и свидетельствующие о новых условиях. Первые требуют корректировки признанных сумм; для существенных некорректирующих событий требуются раскрытия. Задержка доставки в DWH сама по себе не определяет эту классификацию. Стандарт не задаёт поля и состояния EDWH; учётное решение требует применимой редакции и оценки обстоятельств.

В PostgreSQL 18 при Read Committed последовательные запросы одной транзакции могут видеть разные зафиксированные данные. Repeatable Read даёт стабильный снимок относительно начала первого оператора, не управляющего транзакцией. Это поведение конкретной СУБД. Снимок не доказывает полноту источников и не сохраняет исторический выпуск после завершения транзакции. Для нескольких систем или расчётов вне одной транзакции нужен закреплённый набор входов. Здесь нет исполняемого примера и заявления о проверке PostgreSQL.

Контроли и пересчёт зависимостей#

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

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

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

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

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

Контракт строки описан в финансовых событиях, алгебра остатка - в оборотах и остатках, независимые проверки полноты - в сверках.

Как отличить задержку доставки от новой проводки в переоткрытый период?
Какие свидетельства полноты нужны помимо временной отсечки?
Какие последующие остатки затронет поздняя январская проводка и как сохранить старый выпуск?

Problem and scope#

A period close must record which data and rules produced the period's result. Late delivery must not silently alter an approved report. Meanwhile, the EDWH must accept and retain new data to explain differences and support authorized recalculation.

This article proposes an engineering contract for closing general-ledger periods. It has knowledge status and describes neither the author's experience nor a lab implementation. General historization is covered in history and time; the focus here is period readiness and result version management. Closing a month in an ERP, completing an EDWH load, and authorizing financial statements for issue are distinct events.

Grain, keys, and dates#

The input grain is a journal-line version. Its key includes source system, legal entity, ledger, document, and line number; retain the version identifier separately. Store each amount with its currency and scale. The synthetic example uses integer RUB kopecks, with debit positive and credit negative. Do not sum different currencies together.

Field	Meaning in the proposed contract
`operation_date`	Date of the economic operation according to the source
`posting_date`	Accounting date determining the journal entry's period in this ledger
`source_posted_at`	Time the source registered the journal entry, if available
`observed_at`	Time the EDWH first received this version
`available_at`	Time the version was successfully published for calculations after validation
`loaded_at`	Technical time of writing to a storage layer

These field names are not a standard. In this model, business_date corresponds to posting_date; that mapping cannot be assumed for every source. The document date may also differ from the operation date. A missing source timestamp remains unknown and must not be replaced with load time.

The ledger calendar determines the period, rather than the month number of the operation date. The period key includes the ledger and calendar; close state also includes the legal entity. Special adjustment periods require an explicit source identifier if a date alone is insufficient. Normalize timestamps to UTC and interpret business dates using the agreed calendar and time zone.

Three types of late arrival#

Synthetic example: an expense from an operation on January 28 amounts to 10000 RUB kopecks. The document contains an expense debit of +10000 and a payable credit of -10000. The January result is frozen on February 2 with an availability cutoff of 2026-02-02T12:00:00Z.

Situation	Accounting date	EDWH availability	Consequence
The journal entry already existed in the source at the cutoff, but delivery was delayed	January 31	February 3	The January release omitted the document; assess completeness and create a new version if recalculation is authorized
A new journal entry was posted to January after an authorized reopening	January 31	February 4	Accounting data changed after close; retain the reason and period-state version
A January operation was recognized in February under an accounting decision	February 3	February 4	It belongs to February movement by accounting date; the operation date does not move it into January

All three cases retain a January operation date but have different consequences. A transport delay must not automatically be classified as a new accounting adjustment. In the last case, a January analytical view by operation date is possible as a separate metric with a different name and reconciliation rules.

Close and release contract#

The proposed grain of a close record is legal entity, ledger, period, and close version. Retain source status and its receipt time, the availability cutoff, completed batch identifiers or change-log positions, rule versions, reconciliation results, approval evidence, and a release identifier. Preserve the history of state transitions.

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

Define the legal entity, ledger, period, and readiness criteria.
Record source states and agreed extraction boundaries.
Wait for required batches to finish and exceptions to be resolved.
Pin the versions available by the cutoff and the rule versions.
Check completeness, document balance, and balance reconciliation.
Calculate the result and retain lineage to input lines.
After successful checks and approval, create an immutable release.
Retain late data and register its impact separately.
Record authorized recalculation as a new release linked to the previous one.

A cutoff alone does not prove completeness. Source evidence must cover the agreed scope, such as completed extracts and reconciliation of expected documents. Under the chosen definition of available_at, a batch received before the cutoff but published afterward is excluded from that release. This rule must agree with the input set actually retained.

The responsible accounting process authorizes reopening an accounting period. The EDWH does not change accounting dates on its own. Late delivery of an already posted document may not require reopening the ERP, although the EDWH release may need revision. Alternatives include a frozen release alongside a separate current recalculation, or replacing the active release with an approved new version. The former requires explicit selection of the view; the latter requires retaining the previous release and explaining the changes.

Mart release lifecycle#

Period close establishes readiness; a release fixes a specific result. The following is a proposed state contract for a corporate mart. It is neither an IAS 10 requirement nor an implementation on this static site or in the lab. An EDWH release is distinct from authorization of financial statements for issue.

The manifest grain is one immutable release_id for a defined report and its version, legal-entity perimeter, ledger, period, and currency basis. The manifest pins the input snapshot, rule versions, amount units, and control evidence. A cell key includes release_id and its business dimensions. Release state and decision history are stored separately from immutable cells: a status change does not rewrite amounts. The RUB example retains integer kopecks and the sign convention defined earlier; changing currency or scale requires a separate basis.

State	Permitted action and condition
`preparing`	Prepare the complete cell set and provenance; after pinning the manifest, new inputs require a new ID
`checked`	Record successful controls for this exact manifest; missing mandatory data blocks the transition
`approved`	An authorized process approves the checked release; retain the decision, rationale, and time
`rejected`	Controls or approval reject the candidate; another preparation attempt creates a new ID
`withdrawn`	Withdraw the release with a reason; it cannot be selected as current
`superseded`	Replace a previously current release with an approved new one; preserve the old cells

Approval and activation are separate: an approved candidate can await the switch. Under this contract, a rejected, withdrawn, or superseded ID cannot be activated again. Returning to earlier values requires a new candidate with fresh controls and approval. This is a chosen governance policy, not a universal accounting rule.

Current release and consistent reading#

The active_release reference has the grain of an agreed reporting perimeter: report, version, ledger, period, and basis. At most one current ID is allowed for that perimeter. If a report includes multiple legal entities, switch the entire agreed package; replacing each entity independently can produce a mixed report. Explicitly show when no active release exists.

The following sequence is contract pseudocode, not SQL or Python:

Pin new release B and check all its cells and links.
Record approval of B and the reason for replacing A.
In one consistent operation:
  check the expected active_release = A and reference version;
  check that B is approved, not withdrawn, and has the same perimeter;
  switch the reference to B, mark A superseded, and record the transition.
If the expectation does not match, make no switch and resolve the conflict.

The reference version matters even if the same value reappears: comparing the ID alone may miss an intervening change. Initial activation expects an empty reference. Retrying a request with the same operation identifier returns the recorded decision; reusing that identifier for another candidate is a conflict. A failure before commit leaves A current; after commit, a retry does not create a second transition. Multiple stores require a separate consistency protocol, which is not implemented here.

Withdrawing current release B simultaneously clears the active reference and records the reason, or switches it to a separately approved replacement. Automatic fallback to A is disallowed by the chosen policy. Retained amounts and the transition log remain available for authorized historical viewing with an explicit status.

A reader resolves the active reference once and pins its ID for the whole report, pagination, drill-back, and export. Cache keys include the ID; a missing cell causes a completeness error rather than substitution from another release. An existing reader may finish viewing superseded A with its status shown. If policy prohibits reading a withdrawn result, stop the request; silently continuing with B's data is not allowed. Check permissions against the current policy.

Controls cover two concurrent approvers, withdrawal between approval and activation, a retry after a lost response, an incomplete cell package, and a switch between export pages. Invariants: the active ID is approved and not withdrawn, each transition has a rationale, all cells in one response belong to one ID, and the previous release is unchanged. A database transaction alone does not prove these business conditions. Cell provenance and the bridge between releases are covered in financial lineage; this section defines only state management and result selection.

Preparation questions: how does approval differ from activation? How can a competing switch be detected? What should an export do if its pinned release is withdrawn?

Release recoverability: package and acceptance#

An immutable release_id does not prove that a release will survive loss of its storage. For a corporate environment, the following proposes a separate recovery contract for one pinned release. These are engineering criteria, not IAS 10 requirements. Backup configuration, retention periods, RPO/RTO promises, and recovery of the entire platform are outside its scope.

Distinguish two outcomes: restoring saved cells for historical reading and recalculating from archived inputs. The former does not prove the latter. Cell grain, currency, scale, signs, period, and basis remain those fixed in the manifest; RUB kopecks cannot be replaced with the current presentation currency, nor can new rates be used. Record recovery time separately from the original business_date, cutoff, and approval time.

The minimum package depends on the stated objective:

Archive component	What to retain and why
Manifest and inventory	Original ID, scope, period, basis, keys and expected objects, their versions, formats, record counts, and checksums
Frozen result	The complete set of cells with business keys, currency, scale, and signs; needed to restore reading and as the recalculation reference
Input snapshots	Every row version and dependent reference dataset actually used, including rates and mappings; needed for recalculation, with links to current tables being insufficient
Rules and environment	Transformation versions, parameters, calendar, rounding policy, operation order, and relevant DBMS/runtime versions; a version number without accessible contents does not provide reproducibility
Controls and decisions	Original completeness and balance results, exceptions, approval, withdrawal, and replacement; support comparison and prevent activation of a withdrawn result

Historical drill-back additionally requires saved links to row versions under the lineage contract. If only cells remain, the amount is available, but provenance back to the event is unproven. Keep the archive in a protected corporate environment; do not export its data, secrets, or user permissions to the public site.

Acceptance starts in a separate environment without consulting current sources. First check that every required object exists, formats are readable, checksums agree, and references are consistent with the manifest. A hash detects changes relative to a trusted inventory, but does not by itself prove package completeness or authenticity; the inventory and its provenance also need protection. A missing rule, damaged snapshot, or unknown environment version explicitly prevents acceptance of recalculation, even if the cells can be read.

Next compare the complete set of business keys, absence of duplicates, and every cell value in the original basis. Integer kopecks require exact equality; a grand total cannot replace comparison by key. Repeat the original domain controls by document and currency and compare their results with the archived protocol. Matching cells without a complete input package permits acceptance only of restored reading, not calculation reproducibility. If the calculation used approximate arithmetic, any permitted deviation and its rationale must have been fixed in advance; a new tolerance cannot be introduced after a discrepancy is found.

A synthetic example: the reference contains two cells of +10000 and -10000 RUB kopecks. Replacing them with +9000 and -9000 preserves the zero total but fails comparison by key. A lost rate version blocks recalculation of a dependent cell, even though its saved number remains readable. A new execution time is acceptable; a new accounting date or rate version changes the calculation and requires a different release.

The attempt protocol retains a separate recovery_run_id, the original release_id, package inventory, environment, differences, and a conclusion for each objective. Successful recovery neither approves the release again nor switches active_release; reconcile its status with the current authoritative decision log. If that log is unavailable, activation is blocked. Apply the current access policy rather than automatically restoring permissions from an old archive.

PostgreSQL 18 documentation describes a consistent snapshot of one database with pg_dump; snapshots of different databases taken by pg_dumpall are not synchronized. This is a property of a particular tool, not proof that an EDWH release is consistent with files, external rules, and other databases. Successfully loading a dump does not replace the domain acceptance process above. There is no executable SQL/Python here; recovery and recalculation were not performed.

Self-study questions: what can be accepted if cells remain but an input snapshot is lost? Why do an archive checksum and a zero total fail to prove recoverability? How can activation of a recovered but previously withdrawn release be prevented?

Accounting standard and database behavior#

IAS 10 distinguishes events between period end and authorization of financial statements: those evidencing conditions existing at period end and those indicating new conditions. The former require adjustment of recognized amounts; material non-adjusting events require disclosures. A DWH delivery delay alone does not determine this classification. The standard does not prescribe EDWH fields or states; accounting decisions require the applicable edition and an assessment of circumstances.

In PostgreSQL 18, successive queries in one Read Committed transaction can see different committed data. Repeatable Read provides a stable snapshot from the beginning of the first non-transaction-control statement. This is behavior of a specific database. A snapshot neither proves source completeness nor preserves a historical release after the transaction ends. Calculations spanning systems or multiple transactions require a pinned input set. No executable example or claim of PostgreSQL testing is provided here.

Controls and dependency recalculation#

Before release, check version-key uniqueness and the absence of row multiplication, document completeness by source, balance by document and currency, and opening balance + movement = closing balance by account, ledger, and currency. A zero overall sum does not replace completeness controls. An unresolved version conflict or missing required batch blocks release or results in an explicitly marked preliminary result.

If a late line changes January movement, it may change January closing balances and subsequent opening balances. Propagate recalculation through the dependency graph to the last affected result; updating only the January mart is insufficient. If the accounting date changes, check both periods. An unchanged total still needs explanation if the line set changed.

For each pair of releases, retain a change bridge covering added, excluded, and changed versions, their amounts by currency, rule changes, and reasons. Repeating the calculation with the same inputs and rules must reproduce the result. Technical rerun time may differ. The previously approved release remains available.

Boundary checks include a line exactly at the cutoff (included here), an unfinished batch, unknown source time, a repeated message, and reopening without new journal entries. Test year boundaries and adjustment periods for the financial calendar. Full treatment of prior-year errors, materiality, and special regulatory rules lies outside this model.

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

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