У клиента параллельно жили две рабочие системы: старая Odoo 8 с историей 2014–2018 годов и текущий прод на Odoo 10. Свести всё нужно было в одну актуальную базу на Odoo 17, не потеряв ни контрагентов, ни номенклатуру, ни историю заказов и счетов.
Проблема
Две базы пересекались: контрагенты, товары и заказы были и в старой системе, и в новой. Если менеджеру нужна история по клиенту старше определённого года, он переключался в другую систему; одинаковые справочники правились в двух местах и постепенно расходились.
Оставлять как есть было нельзя: обе версии платформы устарели, поддержка и обновления по ним закрыты.
Перенос руками не рассматривался: речь шла о десятках тысяч документов, а проверить такую операцию можно только выборочно — потерянные записи и разошедшиеся суммы всплыли бы уже в работе.
Формальный путь обновления Odoo — цепочка последовательных миграций через каждую промежуточную версию, от 8 к 17. Любое звено такой цепочки может сломаться, а на каждой версии висело около 200 кастомных и сторонних модулей, которые пришлось бы тащить через весь путь и чинить на каждом шаге. От этого варианта отказались.
Решение
Собрали перенос напрямую: чистая Odoo 17 плюс два независимых потока данных. Odoo 10 — основной источник, текущий прод с актуальными справочниками и документами. Odoo 8 — только для истории до 2019 года, которой в десятке уже не было.
Идемпотентность: почему повторный прогон не создаёт дублей
Каждая перенесённая запись получает технический внешний идентификатор, собранный из источника и исходного ID: «этот контрагент — из версии 10, запись такая-то». Если скрипт переноса упал на середине и его запустили заново, Odoo по этому идентификатору видит, что запись уже перенесена, и обновляет её вместо создания копии. Без этого сбой посреди прогона означал бы ручной разбор дублей.
Что перенесли из Odoo 10
Порядок был не произвольным: сначала справочники, потом документы, которые на них опираются.
- Контрагенты — около 33 800 записей, с сохранением иерархии: компании и их контактные лица.
- Номенклатура товаров — категории, единицы измерения, себестоимость, вес и объём, атрибуты и варианты.
- Прайс-листы — 232 штуки, более 2 200 позиций в них.
- Заказы на продажу — 31 984 из 31 984. Заказы на закупку — 2 315 из 2 315.
- Счета — 21 162 созданы, пропущен всего один: у него не было ни контрагента, ни строк. Ошибок при переносе — ноль.
После переноса суммы по каждому документу сверяли с оригиналом. Расхождения — в пределах долей процента, и объясняются они не потерями: Odoo 17 пересчитывает НДС на уровне строки заново, а не переносит готовую сумму как есть.
Что добавили из Odoo 8
Старый архив шёл отдельным проходом: 12 523 контрагента, 1 944 товара, 9 698 заказов на продажу и 8 390 счетов — тоже без единой ошибки.
Здесь была своя сложность. Часть контрагентов — новые исторические записи, которых в десятке никогда не было, а часть пришлось сопоставлять с уже перенесёнными по нормализованному имени: ИНН в старой системе почти нигде не был заполнен. Отдельная деталь — в Odoo 8 ставка НДС была 18%. Чтобы суммы старых документов остались такими же, как в оригинале, и не пересчитались задним числом по нынешней ставке, под них завели отдельные налоговые ставки.
Осторожность на каждом шаге
Счета переносили в статусе черновика — сознательно. Перевод в проведённое состояние требует дополнительных проверок — нумерация, закрытые периоды, — поэтому его вынесли в отдельный контролируемый шаг уже после полной сверки данных. Так же и весь перенос сначала прогонялся на песочнице и только после проверки количества записей и сумм повторялся в рабочей базе.
Результат
- Две системы — многолетний прод на Odoo 10 и архив на Odoo 8 — сведены в одну базу на Odoo 17.
- Ни одной ошибки на десятках тысяч перенесённых документов: количество записей и суммы сверены с источниками.
- Повторный запуск переноса не создаёт дублей — у каждой записи есть внешний идентификатор.
- История операций за все годы лежит в одной системе: за старыми данными не нужно переключаться в другую базу.
- Налоговые ставки прошлых лет сохранены, суммы старых документов не изменились.
- Единая база стала фундаментом для дальнейших работ: на неё позже легли перенесённые кастомные модули, в том числе телефония в CRM.
С чего начать
Если учёт годами ведётся в двух системах, начинать стоит не с выбора версии, а с разбора данных: какие справочники пересекаются, какая история где реально нужна. На таком разборе обычно и выясняется, что часть данных переносится одним проходом, а часть требует отдельного сопоставления — как это было с контрагентами без ИНН.
Отдельно решается техническая часть: переносить напрямую в чистую актуальную версию или идти цепочкой апгрейдов. Выбор зависит от числа кастомных модулей и объёма данных; точную оценку даём после аудита баз-источников.
Подробнее — в материале про консолидацию Odoo 8 и Odoo 10: контрагенты, товары, заказы и счета.
Свяжитесь с нами: +7 913 916-61-17, info@erpha.ru