Як можна доопрацювати Odoo під себе?

Maryana Zelinska, співзасновниця OdoMate

Odoo покриває стандартним функціоналом більшість того, що потрібно бізнесу. Систему все одно треба налаштувати — розгорнути й одразу почати працювати не вийде. Але налаштування це ще не доопрацювання, і саме воно проходить більшу частину шляху. Далі ви впираєтесь у те, що не збігається з тим, як працює ваша команда:

• у вашій команді є крок, якого немає ні в кого іншого в цьому процесі;
• замовлення потребує погодження, про яке Odoo не запитує;
• бухгалтерка хоче звіт саме в тому вигляді, в якому звикла, а стандартний шаблон Odoo їй не підходить.

Саме на цьому розриві зникають гроші й починаються суперечки.

Хтось каже, що це зміна на п'ять хвилин. Хтось інший — що без розробника не обійтись. Третій присилає посилання на сторонній застосунок, безкоштовний чи платний, який це вже вміє робити. І всі троє можуть мати рацію щодо однієї й тієї самої задачі. Саме тому розмова ходить по колу: бракує не думок, а спільного критерію, за яким їх можна порівняти.

Змінити поведінку Odoo можна п'ятьма способами, і вибір між ними визначають три речі:

• чи здатні візуальні інструменти, без написання коду, взагалі виразити вашу вимогу;
• хто виправлятиме цю зміну, коли вийде наступна версія Odoo;
• чи можна перенести цю зміну в іншу базу Odoo — тестову копію, другу компанію, новий хостинг — чи вона залишиться лише в тій базі, де її зробили.

Далі — кожен спосіб простими словами, скільки він насправді коштує і як зрозуміти, що він вам підходить.

Ось усе рішення на одному екрані, ще до деталей.

Один рядок, який варто прочитати двічі: Odoo Online не приймає жодних модулів. Документація Odoo каже прямо — Odoo Online «is incompatible with custom modules or modules from the Odoo Apps Store». Це відкидає варіанти 2 і 5 разом, а не лише той, який ви пишете самі: модуль постачальника з Apps Store для хостингу Odoo такий самий сторонній, як і ваш власний. Якщо ви на Odoo Online і відповідь — модуль будь-якого походження, першою зміною буде хостинг: Odoo.sh або власний сервер.

Варіант 1: змінити налаштування (конфігурація)

Що це. Жодного доопрацювання — це перемикач, який уже існує у налаштуваннях або на самому документі. Напрочуд часто «нам потрібне доопрацювання» виявляється налаштуванням в Odoo, про яке ніхто не знав. Odoo 19, наприклад, сама створить і проведе рахунок, коли пройде онлайн-оплата: це Automatic Invoice у налаштуваннях електронної комерції — тобто галочка, а не окрема розробка.

Скільки коштує. Часу на пошук і людини, яка знає, де шукати, бо цього може не бути описано в документації Odoo.

Хто відповідає за оновлення. Це повністю бере на себе компанія Odoo S.A.: налаштування — частина продукту, тому вони переносяться між версіями автоматично.

Чого не вміє. Нічого понад те, що вже вміє сам перемикач. І перемикач один на всіх: якщо поведінка потрібна для одного складу й не потрібна для іншого, спершу перевірте, чи налаштування взагалі задається окремо для кожного складу.

Коли обирати. Починайте завжди звідси — ще до того, як замовляти будь-яку роботу. Жоден інший варіант у списку не обходиться без витрат на підтримку.

Як швидко перевірити. Помічник у довідці Odoo добре справляється саме з цим: опишіть звичайними словами потрібну поведінку, і він покаже налаштування — зокрема ті, які ви б ніколи не знайшли, гортаючи меню. П'ять хвилин такої перевірки часом економлять п'ять днів оплаченої роботи.

Варіант 2: узяти готовий застосунок

Що це. Хтось уже це зробив і продає або постачає безкоштовно, зазвичай на Odoo Apps Store. Ви встановлюєте його й користуєтесь як є, точно в тому вигляді, в якому його зробив постачальник. Таких модулів тисячі, і для поширених задач — додаткові погодження, звітність, галузева специфіка — шанс, що вашу вимогу вже хтось реалізував, доволі високий.

Скільки коштує. Ліцензія оплачується на кожну версію Odoo, а не один раз назавжди. Плюс найменш помітна витрата в цьому списку: час на те, щоб зрозуміти три речі: чи модуль якісно зроблений — популярність не те саме, що надійність, і кількість завантажень тут підказує менше, ніж здається, — чи він сумісний саме з вашою версією та редакцією Odoo — чимало модулів вимагають Enterprise — і чи планує постачальник випускати оновлення наступного року. Тут допомагає проста перевірка: подивіться, під скільки версій Odoo модуль уже випущено і які ще модулі має цей постачальник. Довгий перелік версій означає, що він підтримує свої модулі роками, а не покинув їх після першого релізу. І навіть з оплатою за кожну версію готовий модуль зазвичай обходиться значно дешевше, ніж замовити ту саму функціональність з нуля — тому шукати готове рішення варто перш, ніж замовляти розробку.

Хто відповідає за оновлення. Роботу робить постачальник — але платите за неї ви, щоразу знову. Насправді ви купуєте чужу обіцянку підтримувати модуль актуальним, і діє вона рівно доти, доки цей модуль лишається в планах постачальника. Його графік релізів стає вашим: якщо він повільно підтримує найновішу версію Odoo — ви чекаєте і не можете оновлювати свою базу. Якщо припинить підтримку взагалі — у вас на руках код, якого ви не писали, але який треба підтримувати.

Чого не вміє. Працювати на Odoo Online — хостинг Odoo не приймає ні власних модулів, ні модулів з Apps Store, тож цей варіант і п'ятий стоять або падають разом. Далі: точно вписатись у ваш процес. Модуль постачальника зроблено під середнього покупця, тож підлаштовуватись зазвичай доводиться вам. Друге: модуль має вжитися з усім, що у вас уже встановлено. Два модулі можуть змінювати той самий екран чи те саме поле — і конфліктувати. А код, написаний під чисту базу, іноді поводиться інакше на ваших даних за кілька років. Тому закладайте дві речі, про які забувають:

• перевірку на копії вашої бази перед встановленням у робочу;
• ймовірність, що готовий модуль усе одно доведеться допрацьовувати під ваші потреби.

Перевірити це до встановлення дешевше, ніж після.

Коли обирати. Вимога поширена, ви готові працювати так, як задумав постачальник, і волієте платити за супровід, а не відповідати за нього самі.

Найпередбачуваніша гілка цього варіанта: OCA. Odoo Community Association — неприбуткова організація, учасники якої підтримують кілька тисяч безкоштовних модулів з відкритим кодом; кожен рядок можна прочитати в її публічних репозиторіях. Головне тут не те, що модулі безкоштовні, а те, що вони передбачувані: код рецензують публічно, а не всередині однієї компанії, і перенесення на кожну нову версію Odoo робить спільнота — тож рішення одного постачальника згорнути роботу саме по собі не залишить вас ні з чим. Але ризик знижується, а не зникає: темп підтримки й перенесення різниться від модуля до модуля, тож перевірте, коли востаннє оновлювали потрібний репозиторій і чи є гілка під вашу версію. Для Community версії це особливо важливо: саме OCA закриває чимало прогалин, яких у безкоштовній редакції немає. Ліцензію також не треба купувати знову на кожну версію Odoo: наступне оновлення коштує вашого часу на перевірку, а не ще одного рахунку. Що ви віддаєте натомість: немає постачальника, якому можна подзвонити, і немає обіцяної дати оновлення. Модуль перенесуть на нову версію Odoo тоді, коли за це візьметься хтось зі спільноти — іноді раніше за комерційного постачальника, іноді пізніше.

Варіант 3: візуальне налаштування зі Studio

Що це. Застосунок Odoo Enterprise, який змінює систему візуально: додати поле, пересунути його на екрані, намалювати звіт, налаштувати правило, що спрацьовує на подію. Studio не іграшка — це потужний інструмент, який створює цілі моделі й правила доступу, а її правила автоматизації вміють виконувати Python код.

Скільки коштує. Studio потребує Enterprise на тарифі Custom. На тарифі Standard встановлення Studio автоматично переводить вас на Custom — на річному контракті вам виставлять доплату, на місячному тариф зміниться сам. Йдеться про зміну вашої підписки, а не про безкоштовну галочку.

Хто відповідає за оновлення. Odoo. І це справжня перевага Studio перед іншими варіантами, окрім стандартних налаштувань. Угода про рівень обслуговування щодо оновлення покриває доопрацювання, зроблені в Studio, без доплати — за двох умов: Studio лишається встановленою, а підписка — активною. Зникне будь-що з двох, і покриття піде разом із ним, а поля залишаться у вашій базі.

Чого не вміє. Studio записує зміни у вашу базу як записи, а не як файли. Немає що рецензувати, немає автотестів, немає історії, хто що змінив. На практиці ризик у трьох речах: ніхто не перевірить зміну до того, як вона потрапить у робочу базу; ніщо не попередить, якщо наступна зміна зламає попередню; а коли через рік хтось спитає, чому поле поводиться саме так, відповіді не буде — лишиться саме поле й нічого більше. Робота переноситься: Studio збирає ваші зміни в автоматично створений модуль, який можна вивантажити як ZIP і встановити в іншій базі. Чого ви не отримуєте — це процесу навколо: рецензії до того, як зміна потрапить у базу, тестів, що впадуть, коли хтось щось зламає, і історії, яку можна прочитати через рік. Переносне не означає кероване. І захист закінчується рівно там, де Studio стає потужною: щойно правило використовує дію Execute Code, документація Odoo прямо каже, що супровід цього коду не входить у тарифи Standard чи Custom і оплачується окремо.

Коли обирати. Ви на Enterprise, зміна обмежена за обсягом, і вона живе в одній базі, яку ви не плануєте клонувати.

Варіант 4: візуальне налаштування без Studio

Що це. В Odoo Community немає Studio — порівняння редакцій від Odoo позначає її як доступну лише в Enterprise — але й у Community можливості на цьому не закінчуються. Увімкніть режим розробника, і ви зможете додавати власні поля й моделі, редагувати екран напряму та будувати правила, що спрацьовують на події. Ці правила є в Community як застосунок base_automation, а серверні дії вміють виконувати Python код. Усе, що ви додаєте в такий спосіб, Odoo вимагає називати з префіксом x_, і це закладено в її власному коді.

Скільки коштує. Не потребує ліцензії, працює в безкоштовній Community редакції. Витрата тут не грошова, а кадрова: потрібна людина, якій комфортно працювати в режимі розробника, бо тут немає зрозумілого та інтуїтивного інтерфейсу.

Хто відповідає за оновлення. Ви. Підписки Enterprise немає, тож немає й SLA від Odoo на цю роботу. А оскільки це записи в базі, точно як у Studio, з ними та сама проблема, коли знадобиться друга база. І ніхто не гарантує, що після оновлення версії ці поля та правила працюватимуть так само, як до нього.

Чого не вміє. Немає візуального конструктора звітів. Документувати такі зміни теж ніхто не зобов'язує — і поле, яке два роки тому додав хтось, хто вже не працює в компанії, доводиться розкопувати, як археологічну знахідку.

Коли обирати. Ви на Community, зміна обмежена за обсягом, у вас є достатньо технічна людина — і ви приймаєте, що кожне оновлення Odoo означає, що хтось перевірятиме ці зміни руками, бо немає іншого варіанту контролю.

Варіант 5: власний модуль

Що це. Справжній код, у файлах, у вашому власному репозиторії. З модулів складається сама Odoo, тож власний модуль — повноцінна частина системи, а не «латка» згори. Такий модуль може написати розробник — або його можна згенерувати з готової специфікації за допомогою ШІ, а потім відрецензувати.

Скільки коштує. Часу на створення і, що зазвичай недооцінюють, підтримки на весь час, поки ви модулем користуєтесь. Кожен новий реліз Odoo додає роботи, а отже й витрат.

Хто відповідає за оновлення. Ви. SLA Odoo щодо цього прямолінійна: вона не покриває оновлення модулів, створених власними силами або третіми сторонами, включно з партнерами Odoo, якщо у вас немає контракту на супровід доопрацювань. Хто саме написав модуль — значення не має: модуль золотого партнера так само не покритий, як і написаний вашою командою.

Чого не вміє. Працювати на Odoo Online. Odoo Online — хостинг від самої компанії — не дозволяє встановлювати власні модулі — знадобиться Odoo.sh або свій сервер.

Коли обирати. Зміну неможливо виразити візуальними інструментами, або вам потрібно, щоб її можна було рецензувати, тестувати й переносити між базами — тестовою копією, другою компанією, новим хостингом.

Де тут генерація за допомогою ШІ. Згенерований модуль — це власний модуль. Ті самі файли, та сама потреба в рецензії перед встановленням на робочу базу, та сама відповідальність під час оновлення. Генерація змінює вартість створення модуля, а не вартість володіння ним — і це важливо тоді, коли ви погодились на обхідний шлях саме тому, що замовити модуль було надто дорого. Такі модулі генерують спеціалізовані платформи — наша називається OdoMate. Щоб не вірити на слово, подивіться відкриті приклади: специфікація і модуль, який з неї вийшов, поруч.

Що насправді визначає вибір: спершу можливості, потім хто відповідає за оновлення

Почніть із простішого: чи здатні візуальні інструменти зробити це взагалі?

Для частини вимог питання оновлення навіть не постає: візуальні інструменти їх не реалізують, тож вибір зроблено вже на цьому кроці.

Найяскравіший випадок — усе, що має спілкуватися із системою поза Odoo. І межа тут проходить не там, де зазвичай думають. Studio вміє більше, ніж реагувати на події всередині вашої бази: вона створює webhooks в обидва боки — зовнішня система може запустити дію в Odoo, а зміна в Odoo може надіслати запит назовні. Без жодного модуля.

Закінчується це там, де починається все, що дозволяє інтеграції пережити реальну роботу: повторити спробу, коли інший бік недоступний; не обробити ту саму подію двічі; безпечно зберігати ключі; перетворити дані, які не лягають один в один; підключити зовнішню бібліотеку; повідомити живу людину, коли зламалось. Сама сторінка Odoo про webhooks не приховує цієї межі: радить залучити розробника, попереджає, що неправильно налаштований webhook може порушити роботу бази, і зазначає, що нестандартні дії потребують програмування.

Отже, чесне правило не «інтеграція означає модуль». Воно таке: webhook з'єднує дві системи, а модуль тримає їх з'єднаними. Далі за простий обмін ви вже пишете код у текстовому полі — без рецензії, без тестів, без історії. Витрати як на модуль, без жодного із захистів, заради яких модуль і роблять.

Отже, запитань два, саме в такому порядку. Чи здатні візуальні інструменти виразити вашу вимогу взагалі? Якщо ні — вам потрібен модуль, і решта цього розділу вас не стосується. Якщо здатні — тоді вирішує друге запитання: хто відповідатиме за оновлення.

Якщо прочитати SLA Odoo поруч зі списком винятків, проступає одне правило: покриття йде за кодом, а не за інструментом.

Візуальна робота в Studio — проблема Odoo. Усе, що приходить як модуль, — ваша проблема, незалежно від того, писали його ви, фрилансер, партнер чи ШІ генератор модулів. Один цей рядок пояснює майже всю таблицю нижче, і саме це запитання варто поставити тому, хто виставляє вам рахунок: коли вийде Odoo 20, хто це полагодить і чи є це в договорі?

Про дві умови зазвичай забувають. Перша: захист діє, лише поки Studio встановлена, а підписка оплачена — знизите тариф, і покриття зникне, а поля залишаться в базі. Друга: Odoo відповідає саме за роботу в інтерфейсі, а не за код, написаний усередині Studio — правило з дією Execute Code вважається власним кодом і оплачується окремо.

І ще одна пастка, поширена й дорога: власний модуль, який залежить від поля, створеного в Studio. Він працює на тій базі, де це поле є, і може не встановитись на чистій — тестовій копії, новій компанії, машині колеги, — бо поле це запис, який хтось створив руками, а не частина модуля. Власні рекомендації Odoo щодо оновлення — робити так, щоб власні модулі працювали в порожній базі, саме з цієї причини. Обирайте один підхід на одну задачу, а не половину кожного.

Який варіант вам підходить

Якщо ваш варіант досі не очевидний, завантажте файл із дев'ятьма запитаннями. Відповідаєте на кожне, обираючи зі списку, — і бачите, з чого починати саме вам. Дві хвилини, нічого встановлювати не треба.

А якщо ви дійшли до п'ятого варіанта й досі не замовили модуль саме через ціну — подайте заявку на ранній доступ. Ми розглядаємо заявки поступово й підключаємо невеликими групами.

FAQ

Де шукати документацію та поради, як налаштувати Odoo? Почніть із офіційної документації — вона розбита по застосунках і, що важливо, прив'язана до версії: переконайтесь, що читаєте розділ саме своєї. Якщо не знаєте, як називається потрібне налаштування, швидше спрацює помічник у довідці: опишіть звичайними словами, чого хочете. Коли документація мовчить, а вимога явно не унікальна, подивіться, чи хтось уже зробив це модулем — Apps Store і репозиторії OCA. І окремо: форум спільноти, де ту саму задачу, найімовірніше, вже обговорювали, а також безкоштовні курси Odoo, якщо розбиратись доводиться з нуля.

Чи доступна Odoo Studio в Odoo Community? Ні — порівняння редакцій від Odoo позначає її як доступну лише в Enterprise, а встановлення на тарифі Standard переводить вас на Custom. Найближчий шлях у Community — режим розробника: власні поля й моделі з префіксом x_, правила автоматизації та серверні дії. Це часткова заміна, а не відповідник: немає ні візуального конструктора звітів, ні супроводу з боку Odoo під час оновлення.

Чи переживають доопрацювання зі Studio оновлення версії? Так, і Odoo покриває їх без доплати — доки Studio лишається встановленою, а підписка активною. Виняток — правила автоматизації з дією Execute Code: це власний код, і його супровід оплачується окремо.

Чи може Studio замінити власний модуль? Для багатьох обмежених вимог — так. Studio створює моделі, поля, екрани, правила доступу й автоматизацію, і вона виконує Python. Зупиняється вона там, де потрібна поведінка під час встановлення, контроль над тим, що відбувається, коли крок обірвався на середині, або збережене обчислене значення, яке лишається правильним при переходах, що ніхто не налаштовував.

Чи гірші безкоштовні модулі OCA за платні? Як правило, ні. Модулі OCA рецензують публічно, а підтримує їх спільнота, а не один постачальник — тож ризик, що постачальник зникне, зникає теж. Натомість ви відмовляєтесь від контракту на підтримку й від гарантованої дати перенесення на нову версію.

Чи вважається згенерований ШІ модуль власним модулем? Так, у всьому, що має значення для цього вибору. Згенерований модуль лежить файлами у вашому каталозі addons, його треба відрецензувати перед продакшеном, він не працює на Odoo Online, а його оновлення не покрите SLA від Odoo. Генерація знижує вартість створення модуля, а не вартість володіння ним.

Про авторку. Maryana Zelinska — співзасновниця OdoMate. Вісімнадцять років в ІТ у доставці продукту та підтримці — керівниця продуктової команди, скрам-майстер, сервіс-менеджер, — останні три навколо кастомізації Odoo. Пише про якість специфікацій, прототипування і про те, що насправді видає генерація за допомогою ШІ, якщо перевірити результат.