Кейсы

Комплексная интеграция интернет-магазина с товароучетной системой «Бизнес.ру»

Комплексная интеграция интернет-магазина с товароучетной системой «Бизнес.ру»

1. Контекст / Проблема

Интернет-магазин столкнулся с критическим разрывом между данными на сайте и фактическим состоянием складских остатков в учетной системе «Бизнес.ру».

Основные бизнес-проблемы:

  • Несоответствие остатков: Сайт показывал остатки только по одному (основному) складу, тогда как компания ведет торговлю с двух складов (собственный + склад представительства завода). В итоге клиенты не видели реально доступный товар (например, на сайте 5 шт., а по факту 55 шт.) и уходили к конкурентам.
  • Рассогласование номеров: Номер заказа на сайте не совпадал с номером счета в «Бизнес.ру» и банковских документах, что создавало хаос в учете и трудности у бухгалтерии.
  • Отсутствие резервирования: Заказы создавались, но автоматическое резервирование товара под клиента не формировалось, что вело к продаже одного и того же товара разным покупателям, пока менеджеры вручную не обрабатывали заказ.
  • Неинформативные статусы: Товары, снятые с производства, показывались как «нет в наличии», а позиции «под заказ» — как обычный товар, что вводило клиентов в заблуждение.
  • Долгая выгрузка: Обмен данными происходил раз в час, из-за чего после оформления заказа клиенту приходилось ждать счет до 60 минут, что снижало конверсию.

Требование заказчика: Организовать двухстороннюю синхронизацию «сайт (WordPress) ↔ Бизнес.ру» с частотой 30 минут, суммированием остатков по двум складам, сквозной нумерацией документов и статусными метками («В наличии», «Под заказ», «Снято с производства»).

2. Процесс решения (Ход работ)

Этап 1. Базовое подключение и выявление «подводных камней»

  • Действие: Команда подключила штатный модуль интеграции «Бизнес.ру» к боевому сайту.
  • Сложность: Обнаружено, что стандартная интеграция не гибкая: невозможно переименовать категории, фильтровать услуги/архивные товары.
  • Решение: Принято решение о разработке кастомного конвертера через API «Бизнес.ру» вместо использования готового плагина (оценка трудоемкости — до 100 часов).

Этап 2. Очистка данных и настройка выгрузки товаров

  • Проблема: При тестовой выгрузке API возвращал ошибки из-за дублей артикулов в учетной системе заказчика.
  • Действие: Аналитик выгрузил список дублей в CSV и передал клиенту. После ручной очистки каталога (удаление дублей) синхронизация товаров заработала корректно.
  • SEO-ограничение: По рекомендации SEO-специалиста, наполнение сайта товарами производилось постепенно (частями, по 25% каталога), чтобы избежать санкций поисковиков за «неестественное быстрое наполнение».

Этап 3. Суммирование остатков по двум складам (Ключевая доработка)

  • Задача: Показывать на сайте остаток = Склад_Основной + Склад_ТД_ФиФ - Зарезервированное.
  • Нюанс: В учетной системе по некоторым товарам фактический остаток был ниже «неснижаемого остатка» (например, -6 vs 15). Стандартная формула amount — reserved — remains_min давала отрицательные числа.
  • Согласование: После обсуждения с заказчиком утверждена новая формула: (Остаток на складе 1 + Остаток на складе 2) — Зарезервировано (неснижаемый остаток исключен из расчета для сайта, так как является лишь ориентиром для закупщиков).

Этап 4. Управление заказами и нумерация

  • Сценарий: Нужно, чтобы номер заказа на сайте (например, 7827) совпадал с номером документа в «Бизнес.ру» и счете, но не ломал внутреннюю нумерацию УТ.
  • Реализация: Разработчик внедрил префиксацию. Заказу на сайте присваивается префикс EA_ → в УТ создается заказ покупателя и резервирование с номером EA_7827. Клиент видит в счете этот же номер.
  • Резервирование: Автоматически создается документ «Резервирование» на основании заказа покупателя с обязательной галочкой «Обновлять резерв при изменении заказа покупателя».

Этап 5. Оптимизация частоты и UX

  • Исходно: Выгрузка товаров и заказов — раз в час. Клиент ждал счет «около часа».
  • Доработка: Частота выгрузки остатков и товаров увеличена до 30 минут. Выгрузка заказов в «Бизнес.ру» переведена в режим реального времени (моментально при нажатии кнопки «Оформить заказ»). Счет становится доступен для скачивания сразу после создания заказа.

Этап 6. Статусы товаров

  • Внедрено: В «Бизнес.ру» создано пользовательское поле «Статус товара». В зависимости от его значения на сайте выводится:
  • >0 → «В наличии»
  • =0 → «Под заказ»
  • Флаг «Снят с производства» → «Не поставляется» + предложение аналога (из вкладки «Аналоги» в УТ).

3. Результат

✅ Статус задачи: Успешно завершена и внедрена в production

✅ Ключевые бизнес-показатели:

  • Актуальность остатков: Сайт показывает сумму остатков по двум складам в реальном времени (обновление каждые 30 минут). Исключены ситуации, когда клиент видел 5 шт., а мог купить 55 шт.
  • Скорость обработки заказа: Счет формируется и доступен клиенту мгновенно после оформления, а не через час. Время реакции на заявку сократилось на 90%.
  • Прозрачность учета: Сквозная нумерация (с префиксом EA_) позволила бухгалтерии и менеджерам идентифицировать заказ на всех этапах: сайт → счет → резервирование → банк.
  • Автоматизация: Резервирование товара под клиента создается автоматически, исключая двойные продажи и необходимость ручного бронирования.
  • Клиентский опыт: Покупатель видит реальный статус: «В наличии», «Под заказ» или «Снято с производства» с предложением аналога.

4. Вывод

Данная задача наглядно показала, что «базовая» интеграция через стандартный плагин часто не покрывает реальные бизнес-процессы (суммирование складов, кастомная нумерация, статусы «под заказ»). Ключевыми факторами успеха стали:

1. Глубокая предварительная аналитика: Выявление дублей артикулов и некорректной логики «неснижаемого остатка» до полноценной разработки.

2. Итеративное согласование: Каждый шаг (формула остатков, префикс, частота) обсуждался с заказчиком по факту тестирования, а не умозрительно.

3. Кастомная разработка через API: Только написание собственного конвертера позволило реализовать требование «сумма по двум складам», которое штатное решение не поддерживало.

Итог: Проект превратил сайт из «витрины» в полноценный операционный инструмент, интегрированный с учетом, что позволило компании увеличить число подтвержденных заказов за счет актуальных данных о наличии.