Кейс впровадження

ІСКРА-Чисто на Odoo 19

Дистрибутор, який працював на «1С», паперових видаткових і памʼяті водія, тепер веде весь торговий день в Odoo 19 — від планшетного каталогу торгового представника до планшета у водія і до українських первинних документів для бухгалтерії.

Побудовано на стандартному Odoo, українській бухгалтерській збірці та 50 власних модулях, розроблених і підтримуваних ЕУРП.

Клієнт: ТОВ «ІСКРА-Чисто» — український дистрибутор побутової хімії та товарів FMCG
Партнер із впровадження: ТОВ «ЕУРП»
Платформа: Odoo 19 Enterprise на odoo.sh
Період: квітень – серпень 2026 · робота в системі з першого місяця, розробка триває

Коротко в цифрах

50власних модулів розроблено ЕУРП

386модулів встановлено на продакшені

36стандартних застосунків Odoo у роботі

2 500+клієнтів в обліку

~2 000активних товарних позицій

5 200+підтверджених замовлень

7 000+проведених рахунків клієнтам

6 400+завершених складських переміщень

130+виконаних маршрутів доставки

540+завдань у беклозі, з них 250 уже на продакшені

~40 · 130+користувачів: внутрішніх · портальних (клієнти)

9сторонніх модулів вендоровано й підтримується

Дані з живої продакшн-бази, округлені, серпень 2026. Вендоровані модулі — українська бухгалтерська збірка l10n_ua, переглянута та інтегрована, а не встановлена наосліп.

Початкова точка

ІСКРА-Чисто дистрибʼює побутову хімію та товари для прибирання по західній і центральній Україні — Львів, Тернопіль, Івано-Франківськ, Волинь, Рівне, Закарпаття, Житомир, Київ — під брендами Chante Clair, Coccolino, Balu, Grunwald, HOZZI, Elfi та іншими. Бізнес працював на «1С» (конфігурація БАФ), а комерційна реальність жила поза нею.

01 Замовлення — телефоном або в обмеженому додатку Торговий представник не мав надійного способу показати клієнту актуальну акційну ціну на місці.

02 Документи на відвантаження готували руками Українська торгівля вимагає конкретного набору первинних документів — видаткова накладна, ТТН, акт приймання-передачі — і багато з них оформляли вручну.

03 Системою був водій Що фактично відвантажено, що повернулося, скільки готівки зібрано і в кого — усе це існувало лише в голові водія до кінця дня, а потім ще кілька днів вносилось у базу.

04 Дебіторка була щомісячною здогадкою Ніхто не міг відповісти «скільки цей клієнт винен нам зараз» без ручної звірки.

05 Акції неможливо було втримати Умови акцій контролювались тільки торговими представниками, без автоматичного контролю.

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

Як була влаштована робота

специфікаційно-керована розробка з AI-агентами

Проєкт побудовано за процесом специфікаційно-керованої розробки, який виконує команда спеціалізованих AI-агентів під контролем людини. Принципова відмінність: агенти працюють не з чат-промпту й надії, а з письмової версійованої специфікації — і зобовʼязані надавати докази, а не запевнення.

Одиниця роботи — специфікація, а не тікет Ще до першого рядка коду кожне завдання отримує BRD і SRS із пронумерованими вимогами та критеріями приймання, прив'язаними до конкретних моделей, полів, представлень, ACL і record rules Odoo. Репозиторій містить 117 тек специфікацій — 90 BRD, 96 SRS і 88 самоперевірок аналітика, усі під контролем версій поруч із кодом.

Сім агентів, у кожного одна роль Аналітик досліджує живу систему й пише специфікацію. Розробник її реалізує. Тестувальник будує тест-план із критеріїв приймання. Агент з безпеки перевіряє на кожному gate. Поряд — DevOps, функціональний консультант Odoo і технічний письменник.

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

Докази замість тверджень Саме це робить згенерований AI код безпечним для продакшену. Заява агента, що «все працює», не варта нічого: gate вимагає зафіксованого виводу реального прогону тестів на встановленому модулі та негативного контролю, який доказово падає на коді до виправлення.

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

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

Релізна механіка

Gate 1 Вимоги Кожна функціональна вимога прив'язана до конкретних моделей, полів, представлень і правил безпеки Odoo ще до першого рядка коду.

Gate 2 Реалізація Цілісність маніфесту, повнота моделей і представлень, ACL та record rules, перевірка на антипатерни, двостороння простежуваність і реальний доказ виконання тестів — зафіксований запуск «0 failed, 0 error», а не «зелений білд».

Gate 3 Приймання Повна матриця покриття критеріїв приймання, жодного відкритого критичного чи високого дефекту, вимоги описують рішення таким, яким воно реально розгорнуте.

Odoo 19 Enterprise на odoo.sh із потоком dev → stage → main через pull request; stage працює на знеособленій повній копії продакшн-даних. Безпековий аудит на кожному gate — OWASP плюс набір Odoo-специфічних антипатернів; нуль відкритих критичних і високих знахідок є жорсткою умовою просування.

Хронологія

Квітень 2026 Фундамент Розгорнуто Odoo 19 Enterprise на odoo.sh. Україна та uk_UA як типові значення. Завантажено перші дані з «1С»/БАФ.

Травень 2026 Власний проєкт і правда про дебіторку Масовий імпорт із «1С»/БАФ: контрагенти, продажі, закупівлі, платежі, початкові залишки. Програма FIFO-звірки перетворила 1 000+ імпортованих рахунків і платежів на баланси по кожному клієнту, що сходяться до гривні.

Червень 2026 Замовлення та склад в Odoo Ціни з ПДВ на екрані замовлення. Канбан рахунків із заборгованістю та станом оплати. Приймання готівки в торговій точці в один клік. Перші українські друковані форми.

Липень 2026 Маршрути, документи, акції Підключено українську бухгалтерську збірку. Виставлення рахунку за фактично підібраною кількістю. Повний набір із чотирьох українських первинних документів. 24 липня випущено мобільний застосунок водія.

Серпень 2026 Контроль у полі та вітрина Ліміти боргу, що перевіряються на телефоні водія перед передачею товару. Місячні прайс-листи, за якими рахує B2B-сайт. Складний механізм акцій на вітрині. Каса водія. Прийом підписаних документів сканером штрихкодів.

Шість речей, на які варто подивитися

Телефон водія став документом на відвантаження Mobile-first PWA: водій відкриває маршрут дня, проходить точки по порядку, передає товар, реєструє готівку й повідомляє про проблему, не телефонуючи в офіс. За цим — ті самі записи, які бачить бухгалтер. Складність була не в екранах: кнопка, яка щось змінює, мусить підтвердити водієві, що спрацювала — тихий успіх провокує другий дотик, а другий дотик це друга операція.

Одиниця роботи — маршрут, а не замовлення Денний маршрут змодельовано як обʼєкт: упорядковані точки клієнтів, карта й геокодування Mapbox, дії «готівка / КП / доставка / повернення» на кожній точці. Ранок диспетчера згортається в одну дію — створити й провести всі рахунки маршруту та надрукувати всі українські документи одним зведеним PDF.

Автоматизація складу на застосунку Odoo Barcode Зона комплектації залишалася останнім місцем, де працювали за рукописними списками. Відповідь здебільшого стандартна: Barcode веде приймання, переміщення й відвантаження зі сканерів, а власна розробка знадобилася лише там, де Odoo не дає готового — адресні етикетки місць зберігання (165 зі 175 локацій) та аркуш збирання, перебудований під маршрут комплектувальника складом. За 2 місяці через цей шлях пройшло близько 6 500 переміщень і 43 000 рядків руху товару.

Рушій акцій, який мислить асортиментними групами Пороги кількості mix-and-match на рівні групи, пропозиції n+m з накопиченням будь-яким міксом, датовані місячні прайс-листи — усі три механізми однаково розвʼязуються в бекенді, планшетному каталозі й на вітрині. Комерційно все сходиться в одній дії, яка застосовує винагороди, перегруповує замовлення під чотирма розділами й розбиває його на окремі рахунки — бо ці розділи оплачуються по-різному.

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

«1С» — це міст, а не пункт призначення Замість того щоб заблокувати весь запуск на міграції фінансів, ми тримали «1С» наповненою даними, поки торгова частина переїжджала в Odoo, і від початку розглядали інтеграцію як тимчасовий міст із відомим терміном служби. Саме цей міст дав час зробити справжню роботу під ним: українська збірка вже інтегрована, план рахунків класифіковано за П(С)БО, дебіторка є джерелом правди в Odoo ще з травня.

Що отримав клієнт

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

Дебіторка, на яку є відповідь в одному екрані Заборгованість клієнта видно в канбані рахунків, на телефоні водія ще до передачі товару і в трьох окремих звітах для офісу.

Акції, які тримаються Групові пороги й пропозиції n+m застосовує система, а не переговори по рядках — і вони видно з картки товару, друкованого каталогу, планшета й вітрини.

«1С» і далі отримує дані Замовлення, рахунки клієнтам і накладні постачальників експортуються у форматі, який споживає наявна система фінансового відділу.

Кодова база, що може рухатися далі 50 модулів під контролем версій, кожен реліз — рецензований pull request через середовище на копії продакшену, із записаним виконанням тестів і безпековим проходом на кожному gate.

Стек

Odoo 19 Enterprise odoo.sh PostgreSQL Python OWL QWeb XML-RPC PWA / service worker Mapbox xlsxwriter l10n_ua обмін CSV із «1С:Підприємство» (БАФ)

Кейс підготовлено ТОВ «ЕУРП». Дані взято з живої продакшн-бази та округлено. Опубліковано за згодою клієнта.

Замовити Discovery На головну