DGP — Document Generation Platform

Веб-приложение для генерации документов по шаблонам: акты, отчёты, служебные формы и другие типовые документы.

Что это за проект

DGP (Document Generation Platform) — это проект по автоматизации подготовки документов на основе шаблонов и структурированных данных.

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

Проект задуман как MVP веб-приложения с дальнейшим развитием до более зрелой системы:

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

---

Зачем нужен DGP

Во многих реальных рабочих процессах документы составляются по похожему шаблону:

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

Обычно это выглядит так:

1. специалист открывает старый файл;
2. копирует его;
3. вручную правит реквизиты и текст;
4. рискует забыть обновить дату, адрес, номер объекта или формулировку;
5. печатает или сохраняет PDF.

DGP решает эту задачу через единый поток:

данные → шаблон → готовый документ.

---

Для кого проект

Проект особенно полезен там, где документы создаются регулярно и по повторяющемуся шаблону:

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

ECM / EDMS
ECM — Enterprise Content Management — «управление корпоративным контентом».
EDMS — Electronic Document Management System — «система электронного документооборота».
DGP не пытается сразу стать тяжёлой корпоративной системой. На старте это прикладной инструмент для быстрого и понятного выпуска документов.

---

Текущий статус

Проект находится в стадии раннего MVP.

Что уже зафиксировано по направлению проекта:

• выбран вектор на веб-интерфейс;
• проект пишется на Python;
• рассматривается и используется Flask как лёгкая и понятная база для MVP;
• есть базовый старт приложения и начальный HTTP-маршрут;
• проект движется в сторону слоистой архитектуры;
• используется uv для управления Python-окружением и запуском проекта.

План развиния: Итоговый набор модулей, сущностей БД и полный UI ещё формируется по мере развития MVP.

---

Ключевая идея

Не хранить логику подготовки документов в хаотичном наборе Word-файлов, а собрать её в приложение, где есть:

• шаблоны;
• данные по объектам;
• данные по исполнителям;
• история генерации;
• единые правила формирования текста;
• подготовка печатной формы и PDF.

---

Основные возможности

Уже есть или закладывается в ближайший MVP

• запуск веб-приложения;
• базовая маршрутизация;
• HTML-страницы;
• подготовка структуры проекта под рост;
• разделение кода по ответственности.

Планируется дальше

• список объектов;
• карточка объекта;
• шаблоны актов и отчётов;
• форма заполнения документа;
• генерация документа на основе шаблона;
• сохранение сформированного документа в истории;
• печатная версия;
• экспорт в PDF;
• фильтрация документов по объекту, дате, типу документа;
• авторизация пользователей;
• логирование: кто и когда сформировал документ.

---

Почему веб, а не сразу desktop

Для MVP веб-подход выглядит практичнее:

Плюсы

• проще доступ с разных рабочих мест;
• интерфейс можно быстро менять;
• удобнее развивать в сторону многопользовательской работы;
• проще делать печатные HTML-шаблоны;
• проще прийти к API и интеграциям.

Минусы

• нужно думать о серверной части и маршрутах;
• появляется тема браузерной печати и PDF;
• нужна аккуратная работа с шаблонами и валидацией данных.

На текущем этапе это выглядит оправданным компромиссом: сначала сделать понятный MVP, потом усиливать архитектуру.

---

Технологический стек

На текущий момент или в ближайшем направлении проекта используются / рассматриваются:

• Python
• Flask
• Jinja2 для HTML-шаблонов
• uv для управления окружением и запуском
• SQLite как простой стартовый вариант БД
• PostgreSQL как следующий шаг для более серьёзного сценария
• HTML → PDF как направление для печатной формы

ПРЕДПОЛАГАЮ: конкретный PDF-движок пока не зафиксирован окончательно.
Поэтому в README не заявляется конкретная библиотека как уже утверждённая часть проекта.

---

Архитектурный подход

Проект ориентирован не на «один файл на всё», а на слоистую архитектуру с разделением ответственности.

Это означает, что по мере роста приложения код обычно раскладывается на отдельные части:

• маршруты / контроллеры;
• бизнес-логика;
• модели данных;
• шаблоны;
• инфраструктурный слой;
• конфигурация приложения.

Такой подход важен, потому что проект целится не в учебный hello world, а в боевое приложение, которое можно:

• показывать в портфолио;
• расширять без постоянной боли;
• сопровождать;
• тестировать;
• постепенно переводить на более серьёзную БД и более сложные сценарии.

---

Пример сценария использования

Сценарий 1. Акт по объекту

1. Пользователь открывает приложение.
2. Выбирает объект.
3. Выбирает тип документа: например, акт.
4. Заполняет переменные поля.
5. Система подставляет данные в шаблон.
6. Пользователь получает готовую печатную форму.
7. Документ сохраняется в истории.

Сценарий 2. Повторный выпуск документа

1. Пользователь открывает историю документов.
2. Находит документ по объекту.
3. Берёт его как основу.
4. Обновляет дату, замечания или статус.
5. Генерирует новый экземпляр без ручного копирования старого файла.

---

Почему этот проект полезен как инженерный и портфельный

DGP — это не просто «форма на Flask».
Это проект, в котором пересекаются сразу несколько практических тем:

• проектирование структуры приложения;
• работа с шаблонами;
• хранение данных;
• генерация документов;
• печать и PDF;
• эволюция от MVP к более зрелой архитектуре;
• прикладная автоматизация реального документооборота.

Такой проект хорошо показывает не только умение писать код, но и умение:

• формализовать реальную бизнес-задачу;
• сокращать ручной труд;
• проектировать систему постепенно;
• не переусложнять MVP раньше времени.

---

Быстрый старт

Ниже приведён базовый сценарий старта.
Он отражает текущее направление проекта, где используется uv и Flask.

1. Клонировать репозиторий

git clone <repo-url>
cd <repo-folder>

2. Установить зависимости

uv sync

3. Запустить приложение

uv run flask --app src/run.py run --debug

4. Открыть в браузере

http://127.0.0.1:5000

Важно: Путь src/run.py актуален для текущего варианта запуска проекта.
Если структура позже изменится, эта команда будет обновлена.

---

Принципы разработки

Проект развивается по подходу:

1. Сначала MVP

Сначала нужен минимально рабочий контур:

• приложение запускается;
• есть базовые страницы;
• можно выбрать шаблон;
• можно ввести данные;
• можно получить документ.

2. Потом усиление

После этого добавляется:

• нормальная модель данных;
• история документов;
• роли пользователей;
• PDF;
• тесты;
• миграции;
• более строгая архитектура.

3. Не переусложнять раньше времени

На старте не обязательно:

• тащить тяжёлый frontend-фреймворк;
• строить микросервисы;
• проектировать всё как highload-платформу;
• внедрять сложную RBAC-систему до первого реального сценария.

RBAC — Role-Based Access Control — «разграничение доступа по ролям».

---

Roadmap

MVP

• Инициализация проекта
• Базовый запуск Flask-приложения
• Первый маршрут
• Начальные HTML-шаблоны
• Структура шаблонов документов
• Формы ввода данных
• Модель сущностей: объект / документ / шаблон
• Сохранение данных в БД
• Генерация печатной версии

Ближайшее развитие

• Экспорт PDF
• История созданных документов
• Фильтрация и поиск
• Аутентификация пользователей
• Логирование действий пользователя
• Подготовка к PostgreSQL

Дальше

• Версионирование шаблонов
• Набор разных типов документов
• API для интеграций
• Многопользовательский режим
• Импорт данных из внешних систем
• Более гибкий конструктор шаблонов

---