Обычное обращение — необычный масштаб
Клиент пришёл через сайт с запросом на автоматизацию с помощью Odoo. После первых разговоров стало понятно: перед нами не просто интернет-магазин, а международная торговая структура. Компании группы закупали товары, передавали и перепродавали их друг другу, пополняли склады и продавали продукцию конечным покупателям через Amazon и Shopify.
Название клиента и подробности о продукте я не раскрываю: мы подписали соглашение о конфиденциальности. Но устройство проекта позволяет рассказать, почему рост бизнеса превращает настройку ERP в серьёзную работу с процессами.
Количество компаний — только начало
Один логистический оператор мог хранить товары нескольких юридических лиц. Один и тот же товар находился в разных странах, принадлежал одной компании, перепродавался другой и затем уходил покупателю. Часть заказов выполнялась через Amazon FBA — хранение и отгрузку силами Amazon, часть через другие схемы, часть через Shopify.
Для каждого движения нужно было согласовать компанию, склад, товар, владельца, канал продаж и способ пополнения. В сезон эта матрица менялась особенно быстро. Небольшая ошибка в маршрутизации или синхронизации при большом потоке заказов могла повториться в сотнях операций.
Сначала разобрались, как работает бизнес
До серьёзной разработки нам пришлось восстановить путь товара, заказа и денег от начала до конца. Закупки знали свою часть, сотрудники Amazon — свою, склады — свою, финансовый отдел видел отдельный слой. Целостная картина не всегда существовала у одного человека.
Для быстрорастущей компании это понятная ситуация. Процессы появляются в ответ на текущую задачу, новый сотрудник добавляет свой способ работы, бизнес выходит на следующий рынок. Через несколько лет компания работает, но объяснить всю цепочку уже непросто.
Мы разбирали реальные операции, сопоставляли ответы сотрудников и собирали общую модель. Иногда одно действие затрагивало три компании и два склада. Стало ясно, что речь идёт о наведении порядка в бизнес-процессах, а не только о настройке программы.
Как проходит аудит бизнес-процессов →
Почему автоматизацию начинают с описания процессов →
- Какая компания покупает товар и становится его владельцем?
- Куда он поступает и как определяется необходимость пополнения?
- Что происходит, когда продажу выполняет другое юридическое лицо?
- Какие документы и финансовые операции сопровождают перемещение?
Юридические лица и внутригрупповая торговля
Следующий блок — работа нескольких компаний в одной базе Odoo и операции между ними. Недостаточно создать пять карточек компаний: одна организация закупает товар, другая получает или покупает его внутри группы, третья продаёт конечному покупателю.
Мы настроили закупки и внутригрупповые процессы, чтобы эти операции отражались в остатках, себестоимости и учёте. Пользователю важно видеть понятную последовательность, а финансовой команде — экономический смысл каждой операции.
Ошибка во внутригрупповой продаже может исказить стоимость запаса, затем себестоимость реализованных товаров — COGS, а вместе с ней и отчёт о прибыльности. Именно здесь ERP становится инструментом управления, а не только складской программой.
Около семи 3PL — и разные правила у каждого
3PL — внешний оператор, который хранит и отгружает товары клиента. Нам нужно было подключить около семи таких операторов. На словах это выглядело как задача «подключить семь API», но большую часть времени занимало выяснение реального поведения каждой системы.
У одного оператора была хорошая документация, у другого API работал не совсем так, как описано. Иногда нужных сведений не было, и приходилось разговаривать с сотрудниками провайдера, чтобы понять, как получить статус отправления.
В итоге мы сделали коннекторы ко всем необходимым операторам. Такие задачи редко попадают в презентации ERP-проектов, хотя именно они определяют, будет ли интеграция работать в ежедневных операциях.
Один процесс от заказа до подтверждения отгрузки
Заказ из Shopify поступает в Odoo. Система определяет склад отгрузки, выбирает соответствующий коннектор и передаёт логистическому оператору данные покупателя, адрес, товары, количество и параметры доставки.
После выполнения заказа мы получаем электронный статус. Проверяем, существует ли заказ и не был ли ответ уже обработан, проводим складскую операцию в Odoo и передаём статус обратно в канал продаж.
Чтобы не создавать семь независимых способов работы, мы сделали общий слой маршрутизации. Odoo определяет бизнес-факт: какой заказ должен быть отгружен с какого склада. Маршрутизатор выбирает коннектор, формат сообщения и правила обработки ответа. Разные логистические системы становятся участниками одного процесса.
Amazon и Shopify: подключить мало, нужно правильно сопоставить
В нашей схеме было несколько юридических лиц, аккаунтов, складов и способов исполнения заказов. Требовалось точно сопоставить компании, товары и склады между Odoo и каналами продаж.
Неверное сопоставление компании ведёт к неправильной операции в учёте. Ошибка в выборе склада отправляет заказ не туда. Ошибка в товаре лишает доверия к остаткам.
Мы проходили несколько циклов настройки, тестирования и исправлений. После подготовки к рабочему запуску находились дополнительные исключения. Сложный ERP-проект нельзя проверить только на удобном демонстрационном сценарии: реальные операции показывают сочетания условий, которые легко пропустить.
Операционный контур сложился. Финансовый потребовал отдельной работы
Постепенно Odoo начал связывать компании, склады, принадлежность товара, источники заказов, пополнение, внутригрупповую торговлю и себестоимость. Это стало важным результатом: операционная схема приобрела общую логику.
Но знать, что сто единиц товара переехали со склада A на склад B, недостаточно. Финансовому директору нужно понимать владельца, стоимость, наличие внутригрупповой продажи, выручку и итоговую прибыльность.
Нам требовалась согласованная финансовая модель для компаний группы: структура счетов, отражение выручки и COGS, аналитика по каналам продаж и внутригрупповым операциям. Для этого пришлось отдельно работать с финансовой командой и связывать физические движения товара с их финансовым смыслом.
Xero: готовый коннектор превратился в отдельную разработку
Исторически бухгалтерия клиента велась в Xero. Odoo становился источником операционных данных, но без счетов поставщиков, банковских операций и бухгалтерских транзакций финансовая картина оставалась неполной.
Сначала мы выбрали готовый коннектор из Odoo Apps. Он не покрывал значительную часть сценариев нашего клиента: несколько юридических лиц, сложную структуру счетов и большой поток данных.
Интеграцию пришлось серьёзно дорабатывать, затем исправлять её поведение под нагрузкой. Для этого проекта покупка готового решения не избавила от отдельной разработки. Это вывод о нашем сценарии, а не оценка всех коннекторов Xero.
Практический урок: при выборе интеграции нужно проверять собственные операции, объём данных и архитектуру компаний. Наличие красивого интерфейса и демонстрации не подтверждает готовность к вашей рабочей среде.
Проект не был бесшовным
Некоторые задачи мы недооценили. Часть работ заняла больше времени, чем обещали. Интеграции приходилось переделывать, а решения, казавшиеся правильными при анализе, после тестирования оказывались неудобными. Мы тоже ошибались.
Я не хочу превращать этот опыт в кейс, где всё получилось с первой попытки. Ценность проекта в том, что сложная система постепенно стала понятнее: вопрос, который раньше требовал собирать информацию в нескольких местах, теперь можно было разобрать внутри одной модели.
Такой опыт полезно сохранять не только в памяти команды. Причины доработок и ошибки должны влиять на оценку, проверку интеграций и план следующего проекта.
Что получилось и что остаётся впереди
В проекте использовались привычные механизмы Odoo: компании, склады, маршруты, закупки, продажи, запасы, бухгалтерский и аналитический учёт. Сложность создавал реальный бизнес, где все эти элементы требовалось связать между собой и с внешними сервисами.
По итогам описанного этапа Odoo постепенно становится центральной информационной системой бизнеса. Цель — уменьшать число мест, где существует своя версия данных, и строить работу каналов продаж, складов и аналитики вокруг общей операционной модели.
При этом часть финансового учёта остаётся в Xero. Перенос большего числа бухгалтерских операций непосредственно в Odoo — возможный следующий отдельный проект. Он ещё не является завершённым результатом этой работы.
Я благодарен клиенту за доверие и возможность разобраться в таком бизнесе. Проект оказался тяжёлым, но дал ценный опыт. Взялся бы я за подобную задачу снова? Да — с лучшим пониманием того, где находятся основные сложности.