Financial EDWH Lab - самостоятельный небольшой стенд на Python и SQLite. Он показывает предметную и алгоритмическую логику финансового хранилища без зависимости от внешней базы, секретов или закрытых данных.
Вход - синтетические финансовые события, каждое с учётной датой business_date и моментом известности observed_at. Загрузка создаёт строки журнала по соглашению debit = +amount, credit = −amount.
Ограничение модели: одно событие порождает ровно две строки проводки; суммы хранятся в копейках (целые числа), валюта в первом примере только RUB. Для промышленной финансовой системы нужно расширять контракт документов, валют, учётных книг, синтетических/аналитических счетов и многолинейных проводок.
Сначала загружается расход 200,00 RUB, учтённый в январе. В феврале поступают два события с январской учётной датой: сторно первоначального расхода и исправленный расход 180,00 RUB.
Это вымышленный расход учебной организации. Исправление добавляет сторно −200,00 RUB и новую запись +180,00 RUB. Пересчитанный итог: 200 − 200 + 180 = 180,00 RUB. Исходная запись остаётся в истории.
Замена не может иметь момент известности раньше сторно. Между отдельно поступившими сторно и заменой возможен промежуточный срез с отменённым расходом; это следует отличать от завершённого исправления.
Оба среза считаются по одной истории с разными границами observed_at:
Срез знаний
Чистый расход по счёту
31 января 2026
200,00 RUB
4 февраля 2026
180,00 RUB
Эти значения специально заложены в синтетический тестовый сценарий. Они не являются реальными финансовыми данными.
Financial EDWH Lab is a small, standalone environment built with Python and SQLite. It demonstrates financial-domain and algorithmic logic without an external database, secrets, or private data.
The input consists of synthetic financial events, each with an accounting date business_date and knowledge time observed_at. Loading creates journal lines using debit = +amount and credit = −amount.
Model limitation: each event creates exactly two journal lines; amounts are whole kopecks (integers), and the first example uses RUB only. A production financial system needs a wider contract for documents, currencies, ledgers, synthetic/analytical accounts, and multi-line entries.
First, an expense of 200.00 RUB is loaded with a January accounting date. In February, two events arrive with January accounting dates: a reversal of the original expense and a corrected expense of 180.00 RUB.
This is a fictional expense for an educational organization. The correction adds a reversal of −200.00 RUB and a new entry of +180.00 RUB. The recalculated total is 200 − 200 + 180 = 180.00 RUB. The original event remains in history.
The replacement cannot be known earlier than the reversal. If the reversal and replacement arrive separately, an intermediate snapshot may show the cancelled expense; distinguish it from a completed correction.
Both snapshots use the same event history with different observed_at cutoffs:
Knowledge snapshot
Net expense by account
January 31, 2026
200.00 RUB
February 4, 2026
180.00 RUB
These values are deliberately defined in a synthetic test scenario. They are not real financial data.