Міграція на Odoo: як переносити дані з 1С, Excel та інших систем

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

Звідки зазвичай мігрують

• з 1С — найчастіший випадок: там ведеться облік і лежать довідники, а компанії потрібна система, яку можна розвивати;
• з Excel — тут справжня робота не в перенесенні даних, а в тому, щоб вони взагалі стали придатними до використання;
• з QuickBooks та інших облікових систем;
• із власних саморобних систем — якість даних тут передбачити неможливо, тому дивимося на місці;
• зі старішої версії Odoo — окрема категорія, про неї нижче;
• з Odoo Online на Odoo.sh або власний сервер — коли впираєтесь в обмеження хмари й потрібен доступ до коду.

Найважливіше рішення: чого не переносити

У девʼяти випадках із десяти половина історії має лишитися позаду. Сім років історії продажів не робить ваш облік точнішим — вона робить базу важкою, міграцію довгою, а звірку неможливою.

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

Що варто переносити:

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

Етапи міграції

Порядок має значення — кожен крок спирається на попередній.

1. Інвентаризація даних

Що насправді є у старій системі, в якому обсязі та в якому стані. Саме на цьому кроці зазвичай зʼясовується, що товарів не 3 000, а 900 плюс 2 100 дублів.

2. Чищення й дедублікація

Робиться до перенесення, а не після. Обʼєднати двох однакових контрагентів у старій системі — рутина; зробити те саме в Odoo, коли до обох уже прикріплені документи, — окремий проєкт.

3. Мапінг

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

4. Пробний прогін на копії

Повне перенесення в тестову базу тими самими скриптами, які підуть у бій. Скрипти мають бути повторюваними: другий запуск не повинен створювати дублі.

5. Звірка

Контрольні цифри: кількість контрагентів і товарів, загальна вартість залишків у грошах, сальдо дебіторки й кредиторки, обороти по рахунках. Не «приблизно так» — точно, з поясненням кожного розходження.

6. Бойове перенесення

У погоджене вікно, з фіксованою датою переходу та забороною змін у старій системі після неї.

7. Паралельний період

Перший місяць-два стара система лишається доступною тільки для читання. Це дешева страховка, яка знімає більшість панічних питань.

Склад: кількість без оцінки — це не міграція

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

Правильно — завантажувати залишки разом з оцінкою, партіями (якщо ведеться партійний облік) і датами надходження. Для FIFO дата надходження вирішальна: саме вона визначає порядок списання, а не дата документа, яким ви створили вхідний залишок.

Дебіторка й кредиторка: у розрізі документів, а не однією сумою

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

Дата переходу

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

Оновлення версії Odoo — міграція окремого роду

Тут дані вже в Odoo, і робота зміщується в бік коду: кастомні модулі треба привести до нової версії, перевірити змінену механіку, а дані звірити після штатної процедури оновлення.

Порядок такий: спершу оновлення на копії, потім адаптація кастомних модулів, потім тестування бізнес-процесами , а не перевіркою, що сторінки відкриваються. І лише тоді бойове оновлення. Найбільший ризик — не сам Odoo, а модулі, написані без думки про оновлення; саме тому на них варто подивитися заздалегідь.

Типові помилки

• Переносити все. Головна причина, чому міграції виходять за строки.
• Чистити дані після перенесення. У кілька разів дорожче.
• Скрипти, які не можна запустити двічі. Будь-яка міграція запускається не один раз — це нормально, і до цього треба бути готовим.
• Відсутність контрольних цифр. Коли немає з чим звіряти, міграція вважається вдалою рівно до першого закриття періоду.
• Відсутність дати заморожування. Дані у старій системі змінюються, поки ви переносите, і цифри не збігаються ніколи.
• Відсутність власника даних з боку бізнесу. Підрядник може перенести дані, але рішення, який із двох дублів правильний, ухвалює лише ваша людина.

Скільки це триває

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

Працюю погодинно (T&M) і починаю з інвентаризації — після неї видно реальний обсяг, і подальші оцінки перестають бути ворожінням.

Наступні кроки

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

Часті питання

Чи можна перенести з 1С усю історію?

Технічно здебільшого так. На практиці це майже ніколи не варте того: вартість і строки зростають у рази, а користь від старої історії всередині нової системи мінімальна.

Чи можна якийсь час працювати у двох системах паралельно?

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

Що робити, якщо дані в старій системі погані?

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

Хто відповідає за коректність даних?

Технічну частину роблю я, але рішення, який запис правильний, ухвалює ваша людина — зазвичай бухгалтер або керівник напряму.

Чи можна перейти без простою?

Повністю без простою — ні, але вікно зазвичай вкладається у вихідні. Його планують заздалегідь разом із датою заморожування даних.