Расхождения ERP и 1С в одном списке
Сверка счетов, платежей и закрывающих документов показывает только то, что требует разбора, с владельцем и причиной.
Сделал: Бизнес- и системный анализ, модель данных, требования и приёмка
ВопросОткуда берётся цифра в отчёте и где её проверяют?
Цифра проходит 3 проверки на пути от 2 источников до 3 отчётов
Расхождения, блокеры закрытия и владельцы исключений стали видны в одном управленческом контуре.
Источники
- ERP MariaDB
- операционные выгрузки
Загрузка и правила
- скрипты выгрузки
- VPN-маршрут
- плановые трансформации
Хранение и модель
- ClickHouse raw
- ClickHouse fact
- ClickHouse views
Отчёты и решения
- BI-витрины
- документация
- отчёты валидации
Контрольные точки
- Сверка количества строк и контрольных сумм после загрузки.
- Проверка переходов статусов на граничных датах.
- Документирование статуса синхронизации и известных ограничений.
В заявку попадёт тема Расхождения ERP и 1С в одном списке: откуда берётся цифра и где её проверяют
.
Ситуация
С чего всё начиналось
ERP-источник обслуживает управленческую отчётность, клиентские переходы, маржинальность и сверки.
Управленческие и финансовые показатели расходились между ERP, отчётами и ручными выгрузками.
Что изменено
Что я сделал
Структурировал модель, витрины, документы, статус синхронизации и правила контроля качества.
- Отчётные витрины строятся от ERP-событий и фиксированных правил статусов.
- Переходы жизненного цикла считаются по дневным состояниям клиента.
- Сверка связывает факт, бюджет, статусы и контрольные суммы управленческого учёта.
Что получилось
Результат
Расхождения, блокеры закрытия и владельцы исключений стали видны в одном управленческом контуре
- Ручные выгрузки заменены контуром, где расхождения и блокеры закрытия получают статус, причину и владельца.
- Финансовые расхождения стали видны как управляемая очередь исключений.
- Документация модели снизила риск повторного запуска и передачи проекта.
Как это проверено
Проверка и границы
- Сверка количества строк и контрольных сумм после загрузки.
- Проверка переходов статусов на граничных датах.
- Документирование статуса синхронизации и известных ограничений.
ERP-контур описан без закрытых сущностей и доступов. публично не раскрываются интеграционные контракты клиента и реальные идентификаторы.
Техническое приложение
Как устроено внутри
Для тех, кто проверяет решение по существу: источники, слои данных, правила расчёта и артефакты передачи.
Архитектура, данные и методология
Архитектура
| Источники | ERP MariaDB · операционные выгрузки |
|---|---|
| Загрузка | скрипты выгрузки · VPN-маршрут · плановые трансформации |
| Хранение | ClickHouse raw · ClickHouse fact · ClickHouse views |
| Представление | BI-витрины · документация · отчёты валидации |
Модель данных
| Объект | Слой | Назначение |
|---|---|---|
| raw.erp_* | raw | первичные ERP выгрузки |
| fact.erp_* | fact | событийные и агрегированные факты |
| mart.erp_* | mart | прикладные витрины для отчётности |
Методология и правила
- Разделил ERP-данные на слой первичных событий, слой фактов и прикладные витрины для управленческой отчётности.
- Описал жизненный цикл как допустимые переходы состояний, а не как набор разрозненных статусов.
- Добавил контроль строк, сумм и граничных дат, чтобы отчётность не зависела от ручной проверки выгрузки.
- Модель жизненного цикла проверяет разрешенные переходы from/to и фиксирует запрещенные состояния.
- Контрольные витрины сравнивают строки, суммы и финансовые показатели между источником и аналитическим слоем.
- Исключения группируются по процессу: закрытие, статус, документ, дубль, бюджет.
Артефакты и стек
BRD · Data Model · Architecture · Dashboard · UAT
Что бы сделал иначе
- Для ERP важно иметь модельный контекст рядом с кодом.
- Архивные материалы нужно отделять от рабочего контура.
- Runbook снижает риск при повторном запуске задач.
Похожая задача?
Расскажите, где у вас расходятся цифры или не хватает картины. Отвечу, чем это лечится и с чего начать.