Послуги розробки Odoo ERP

Стандартний партнер Odoo налаштовує модулі та організовує робочі процеси, використовуючи існуючий функціонал Odoo. Компанія з розробки Odoo ERP пише кастомні Python-модулі, розширює ORM, створює API-інтеграції та змінює або замінює фронтенд-компоненти з використанням OWL. Результатом є виробничий код, а не експорти конфігурацій.

Фокусований модуль з однією моделлю, CRUD-представленнями, правилами доступу та базовою логікою робочого процесу займає 40–80 годин. Модуль, що інтегрує зовнішній API, містить планові дії та вимагає кастомної звітності, зазвичай потребує 120–200 годин. Термін залежить від повноти специфікації на старті — недостатньо прописані проєкти додають 30–50% до оцінки.

Так. Ми створюємо REST і JSON-RPC конектори для зовнішніх платформ, включно з SAP, Salesforce, HubSpot, Shopify, WooCommerce та кастомними внутрішніми системами. Архітектура інтеграції залежить від того, чи підтримує зовнішня система вебхуки, опитувальні API або обмін файлами у пакетному режимі — ми оцінюємо це на етапі визначення обсягу та документуємо контракт потоку даних перед початком розробки.

Ми активно підтримуємо Odoo 17, 18 та 19 — як Community, так і Enterprise. Для клієнтів на старіших версіях (v14, v15, v16) ми виконуємо скопінг міграцій та можемо поетапно оновити. Версія 19 внесла додаткові зміни до життєвого циклу компонентів OWL і шару диспетчеризації дій; наші розробники відстежують changelog по всіх активних версіях і пишуть код, сумісний із поточними патернами.

Ми починаємо з профілювання запитів PostgreSQL за допомогою pg_stat_statements та EXPLAIN ANALYZE. Типові виправлення включають додавання цільових індексів на поля з фільтрацією, перепис N+1 запитів ORM із використанням prefetch-патернів та перенесення важких агрегацій у матеріалізовані уявлення, що оновлюються через ir.cron. На наборах даних понад 5M записів ми оцінюємо, чи певні звіти повинні обходити ORM Odoo і опитувати PostgreSQL напряму.

Community Edition не містить кількох модулів Enterprise: повна бухгалтерія, розширене MRP, Helpdesk, Sign та мобільний додаток. Для компаній, які потребують повноцінної подвійної бухгалтерії, MRP із робочими центрами або електронного підпису, потрібен Enterprise. Для гуртової дистрибуції, базового виробництва та B2B-продажів Community справляється з більшістю випадків — особливо в поєднанні з розробниками Odoo, які можуть додати відсутні функції як кастомні модулі.

Ми строго дотримуємося рекомендацій щодо структури модулів Odoo: усі кастомізації використовують _inherit замість модифікації основних файлів, XML ID мають неймспейс, а застарілі API-виклики позначаються під час розробки з використанням фреймворку попереджень міграції Odoo. Ми ведемо журнал змін по кожному клієнту, документуючи, які моделі та уявлення ядра торкаються модулі, що скорочує час оцінки оновлення з тижнів до годин.

Як мінімум: поточна версія Odoo (або цільова версія), бізнес-процес, який потрібно автоматизувати або змінити, будь-які зовнішні системи для підключення та приблизна кількість користувачів. Карта процесу або письмовий опис випадків винятків (що відбувається, коли щось йде не так) — найцінніший вхід для точної оцінки — більшість недооцінок походить від недокументованих крайніх випадків.

Так. Ми пропонуємо щомісячні ретейнери на обслуговування, які покривають виправлення багів, невеликі покращення та перевірки сумісності з виправленнями безпеки Odoo. Обсяг ретейнера визначається як фіксована кількість годин розробника на місяць, що розподіляються за зареєстрованим беклогом. Ми не стягуємо плату за баги, ініційовані Odoo у основних модулях — їх ескалують безпосередньо в Odoo S.A. на планах Enterprise.

Найбільше впроваджень у нас у дискретному виробництві, гуртовій дистрибуції та професійних послугах (консалтинг, IT-послуги, інжинірингові фірми). Ми також реалізували впровадження у харчовій промисловості (відстеження партій, строк придатності), будівництві (калькуляція проєктів, оплата субпідрядників) та роздрібній торгівлі (інтеграція POS з модулем point_of_sale). Кожна вертикаль має свої шаблони розширення моделей, які ми документуємо і повторно використовуємо у схожих проєктах.

Якщо робочий процес вже існує в Odoo і ваша команда просто неправильно його використовує — це проблема навчання. Якщо процес не існує — або існує, але не може обробляти винятки без ручних обхідних шляхів — це проблема розробки. Чіткий сигнал: якщо ваша команда добре знає Odoo і все одно не може змусити його виконувати необхідні бізнес-вимоги, жодне навчання цю прогалину не закриє. Декілька конкретних індикаторів, що потрібен розробник: ви експортуєте дані в Excel для виконання розрахунків, яких Odoo не видає; у вас є логіка затверджень або маршрутизації, яка не відповідає жодному стандартному модулю Odoo; або вам потрібно автоматично обмінюватися даними з зовнішньою системою. Це структурні прогалини — їх вирішує код, а не конфігурація.