Разработка ETL-платформы для автоматической консолидации данных из 1С, Zoho и Kingdee в единый DWH

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

2. Исходные системы
2.1. 1С (Комплексная Автоматизация)
Используется российским юридическим лицом, в краткосрочной перспективе появится аналогичная база 1С в Казахстане. 
Содержит: продажи; закупки; складской учет; контрагентов; товары; бухгалтерские документы; счета; платежи.
Способ получения данных необходимо определить совместно с исполнителем. Возможные варианты: REST API; HTTP-сервисы 1С; OData; SQL; COM; выгрузки; иной технически обоснованный способ.

2.2. Zoho Books
Используется компанией в ОАЭ, в краткосрочной перспективе появится аналогичная база Zoho Books в Саудовской Аравии. 
Содержит: продажи; закупки; складской учет; контрагентов; товары; бухгалтерские документы; счета; платежи. Доступен официальный API. 

2.3. Kingdee Cloud Stellar
Используется китайской компанией.
Содержит: продажи; закупки; контрагентов; товары; бухгалтерские документы; счета; платежи.
Способ подключения определяется после изучения имеющейся версии Kingdee, доступен API.

3. Общие требования
Необходимо реализовать систему, которая:
• автоматически получает данные;
• автоматически обновляет изменения;
• не требует ручного запуска;
• не требует ручной обработки файлов;
• предусматривает резервное копирование данных;
• имеет журнал ошибок;
• может быть перезапущена после сбоя без потери данных.

4. Архитектурные требования
Исполнитель самостоятельно предлагает архитектуру решения. Допускается использование любых технологий, включая:
• n8n;
• Airbyte;
• Apache NiFi;
• Python;
• собственные ETL;
• Docker;
• PostgreSQL;
• другие современные инструменты.
Главное требование — надежность, масштабируемость и возможность дальнейшей обработки собранных данных, в первую очередь для составления консолидированной финансовой отчетности по группе компаний.

5. Хранилище данных
Необходимо организовать единое хранилище данных.
Предпочтительно PostgreSQL.
Исполнитель может предложить альтернативу при наличии аргументации.
Хранилище должно обеспечивать:
• хранение истории;
• возможность повторной обработки данных;
• возможность последующего подключения BI и AI.

6. Структура хранения
Необходимо обеспечить максимально полное сохранение данных из источников. Желательно разделение данных на уровни (сырые/нормализованные).

7. Обновление данных
Необходимо обеспечить:
• первоначальную полную загрузку;
• последующие инкрементальные обновления;
• защиту от появления дубликатов;
• повторную загрузку после ошибок.

8. Логирование
Система должна вести журнал:
• времени запуска;
• времени окончания;
• количества обработанных объектов;
• ошибок;
• предупреждений.

9. Мониторинг
При возникновении ошибки система должна уведомлять администратора.

10. Масштабируемость
Архитектура должна предусматривать возможность последующего подключения:
• новых компаний;
• новых ERP;
• CRM;
• банков;
• BI;
• AI.

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

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

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

14. Требования к качеству архитектуры
Исполнитель должен не просто реализовать интеграцию, но и обосновать выбранную архитектуру. В частности, необходимо описать:
• причины выбора конкретного ETL-инструмента;
• причины выбора способа подключения к каждой ERP;
• принципы организации хранилища данных;
• стратегию инкрементальной загрузки;
• стратегию обработки изменений и удалений;
• стратегию резервного копирования;
• стратегию восстановления после сбоя;
• оценку производительности и возможности масштабирования.
Все архитектурные решения должны быть согласованы до начала разработки.