Разработка кастомных модулей Odoo

Когда нужен отдельный модуль

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

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

Что можем разработать

• Реестры, карточки и связи между бизнес-объектами.
• Статусы, согласования, автоматические действия и контроль обязательных данных.
• Роли, группы и правила доступа для разных участников процесса.
• Расчёты, печатные формы, отчёты, дашборды и выгрузки.
• Коннекторы, очереди обмена, Telegram-боты и другие интерфейсы к данным Odoo.
• Расширения установленных модулей без изменения их исходного кода, когда архитектура и лицензия это позволяют.

Стандарт Odoo, OCA или собственная разработка

Не начинаем с написания кода. Сначала определяем, на каком уровне рационально решить задачу:

1. Стандартные возможности Odoo Community. Проверяем приложения, настройки, права, автоматические действия и допустимую адаптацию процесса.
2. Готовые модули. Рассматриваем решения сообщества, в том числе OCA, и проверяем их назначение, лицензию, поддержку нужной версии, зависимости и качество кода.
3. Кастомный модуль. Проектируем собственную реализацию, если готового решения нет, оно не покрывает ключевой сценарий или создаёт неоправданные зависимости.

Итоговое решение может сочетать эти уровни. Границу фиксируем до разработки, чтобы было понятно, какая часть относится к платформе, сторонним зависимостям и коду проекта.

Как проходит разработка

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

Качество и обновляемость

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

• Критерии приёмки и сценарии проверки для основной логики и прав доступа.
• Хранение кода и истории изменений в системе контроля версий; порядок проверки изменений, если над кодом работает несколько разработчиков.
• Проверка в отдельном контуре, а перед установкой в рабочую базу — согласованный порядок резервного копирования и возврата к предыдущей версии.
• Описание зависимостей, порядка установки и особенностей эксплуатации; передача согласованного кода и материалов клиенту.
• Логирование и понятный сценарий диагностики для фоновых заданий и интеграций, где это требуется.

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

Примеры задач в проектах

• Buildflow ERP — реестры смет, договоров и актов, роли и операционная логика на Odoo 17 Community.
• Проект SPL в Дубае — опыт Червякова Владислава в kt.team: двусторонняя синхронизация двух Odoo с очередями и контролем обмена.
• Buildflow в Telegram — отчёты по движению средств из Odoo в разрезах подрядчика, проекта и корпуса.
• Atkinternal — управление слотами и поиск свободных сотрудников через Telegram-бота с данными Odoo.

Частые вопросы