Синхронизация цен и остатков помогает избежать продаж несуществующих товаров и неверных цен. Разберём схемы обмена и покажем, как автоматизировать процесс.
Почему синхронизация цен и остатков важна
Интернет-магазин работает с несколькими источниками данных. На сайте хранится каталог. На складе ведётся учёт товаров. Отдельно может работать CRM, ERP или система управления заказами.
Проблема возникает, когда эти системы не обмениваются данными вовремя.
Представим обычную ситуацию:
- на складе осталось 2 единицы товара;
- сайт показывает 5 единиц;
- клиент оформляет заказ на 4 штуки;
- менеджер обнаруживает нехватку товара;
- магазин вынужден отменить заказ.
Другой сценарий связан с ценой. Менеджер изменил стоимость в учётной системе. Сайт получил старую цену. Клиент оформил заказ по неверной стоимости.
Такие ошибки влияют не только на продажи. Они увеличивают нагрузку на менеджеров. Они создают проблемы с клиентским сервисом. Они также искажают отчётность.
Поэтому синхронизация цен и остатков должна быть частью архитектуры интернет-магазина.
Какие данные нужно синхронизировать
Обычно обмен включает несколько групп данных:
| Данные | Источник | Направление обмена |
|---|---|---|
| Цена | ERP, складская система | На сайт |
| Остаток | Склад | На сайт |
| Артикул | ERP | В обе стороны |
| Название | ERP или сайт | Зависит от проекта |
| Характеристики | ERP или сайт | Зависит от проекта |
| Заказы | Сайт | В ERP |
| Статусы заказов | ERP | На сайт |
Главное правило простое: для каждого поля нужно определить главный источник.
Если цену одновременно меняют в двух системах, конфликт почти неизбежен.
Синхронизация цен и остатков: как выбрать схему обмена
Есть несколько распространённых вариантов. Выбор зависит от масштаба магазина и используемых систем.
Обмен по расписанию
Сайт регулярно запрашивает данные у складской системы.
Например, обмен запускается каждые 5 минут.
Плюсы:
- относительно простая реализация;
- легко контролировать расписание;
- подходит небольшим каталогам;
- не требует сложной событийной архитектуры.
Минус очевиден. Данные могут устареть между обменами.
Если товар купили на складе после последнего запуска, сайт ещё покажет старый остаток.
Обмен через API
Системы взаимодействуют напрямую через API.
Например, складская программа отправляет изменения на сайт. Сайт получает новые цены и остатки почти сразу.
Преимущества:
- высокая скорость обновления;
- меньше ручной работы;
- можно передавать только изменившиеся товары;
- проще масштабировать интеграцию.
Но API требует правильной обработки ошибок. Нужно учитывать авторизацию, лимиты запросов и недоступность сервиса.
Обмен через файлы
Некоторые системы используют CSV, XML или CommerceML.
Склад формирует файл. Сайт принимает его и обновляет каталог.
Этот вариант часто встречается в проектах на WordPress и WooCommerce. Он может быть удобен при интеграции с готовыми решениями.
Но здесь особенно важно контролировать структуру файла. Ошибка в одном поле способна изменить сотни товаров.
Webhook и событийная синхронизация
Более современный подход — передавать изменение сразу после события.
Например, склад изменил остаток. Система отправила webhook на сайт.
Сайт получил событие и обновил конкретный товар.
Такая схема хорошо подходит магазинам с большим количеством операций.
Где чаще всего возникают расхождения
Даже готовая интеграция не гарантирует идеальную синхронизацию. Основные ошибки обычно связаны с бизнес-логикой.
1. Разные идентификаторы товаров
В ERP товар имеет артикул A-125. На сайте тот же товар имеет ID 3487.
Без таблицы соответствий система может обновить не тот объект.
Надёжнее использовать единый внешний идентификатор. Например:
external_id = A-125
Сайт хранит этот идентификатор вместе с товаром.
При обмене система ищет товар по external_id, а не по названию.
2. Остаток меняется в нескольких местах
Товар может находиться:
- на основном складе;
- в пункте выдачи;
- у поставщика;
- в резерве;
- в пути.
Если сайт получает только физический остаток, он может показать неверную доступность.
Например:
Физический остаток: 10
Резерв: 7
Доступно к продаже: 3
Для интернет-магазина важнее третий показатель.
3. Цена зависит от условий
Один товар может иметь несколько цен:
- розничную;
- оптовую;
- акционную;
- специальную;
- региональную.
Если интеграция не учитывает тип цены, сайт получит неправильное значение.
4. Ошибка во время обмена
Допустим, сайт обновляет 10 000 товаров. На 6 500-м запросе API склада перестал отвечать.
Плохая интеграция просто завершит процесс.
Хорошая система:
- фиксирует ошибку;
- сохраняет позицию;
- повторяет запрос;
- записывает результат в журнал;
- уведомляет ответственного сотрудника.
Именно такие детали определяют надёжность интеграции.
Как построить надёжную синхронизацию
Перед разработкой нужно определить архитектуру обмена.
Мы рекомендуем двигаться по пяти шагам.
Шаг 1. Определить главный источник данных
Для каждого поля назначается система-владелец.
Например:
| Поле | Главный источник |
|---|---|
| Цена | ERP |
| Остаток | Склад |
| Описание | WordPress |
| Фото | WordPress |
| Заказы | Сайт |
| Статус заказа | ERP |
Это исключает большую часть конфликтов.
Шаг 2. Определить частоту обновления
Не всем данным нужна одинаковая скорость.
Остатки могут обновляться каждую минуту. Описания можно передавать раз в час.
Например:
Остатки → каждые 1–5 минут
Цены → каждые 5–15 минут
Каталог → по расписанию
Заказы → сразу после оформления
Конкретные интервалы зависят от нагрузки.
Шаг 3. Передавать только изменения
Не всегда нужно синхронизировать весь каталог.
Допустим, в базе 50 000 товаров. За час изменились только 300.
Нет смысла передавать все 50 000 записей.
Система может использовать признак изменения:
{
"external_id": "A-125",
"price": 12990,
"stock": 4,
"updated_at": "2026-09-06T12:30:00"
}
Сайт обновляет только изменившийся товар.
Это снижает нагрузку на сервер и ускоряет обмен.
Шаг 4. Добавить журнал синхронизации
Без журнала сложно понять причину ошибки.
В логе полезно хранить:
- дату операции;
- внешний ID товара;
- тип изменения;
- старое значение;
- новое значение;
- статус операции;
- текст ошибки.
Например:
06.09.2026 12:31
SKU: A-125
Поле: stock
Было: 5
Стало: 4
Статус: success
Если обмен завершился ошибкой, менеджер должен видеть причину.
Шаг 5. Настроить повторные попытки
Временный сбой API не должен останавливать весь обмен.
Можно использовать несколько повторных попыток:
Попытка 1 → ошибка
Ожидание 30 секунд
Попытка 2 → ошибка
Ожидание 2 минуты
Попытка 3 → успех
Если попытки закончились, система отправляет уведомление.
Пример синхронизации через API
Рассмотрим упрощённую схему на PHP.
Предположим, склад отдаёт остаток товара по API.
$response = wp_remote_get(
'https://warehouse.example/api/products/A-125'
);
if (is_wp_error($response)) {
error_log('Ошибка API склада');
return;
}
$data = json_decode(
wp_remote_retrieve_body($response),
true
);
$stock = (int) ($data['stock'] ?? 0);
$product_id = wc_get_product_id_by_sku('A-125');
if ($product_id) {
$product = wc_get_product($product_id);
$product->set_stock_quantity($stock);
$product->set_manage_stock(true);
$product->save();
}
В реальном проекте потребуется больше проверок.
Например:
- авторизация API;
- проверка формата ответа;
- логирование;
- повторные запросы;
- ограничение частоты запросов;
- обработка блокировок;
- контроль отрицательных остатков.
Сам код — только часть решения. Важнее правильно построить процесс обмена.
Как мы решаем проблему расхождений
Представим интернет-магазин, где менеджеры регулярно получали жалобы.
Проблема: сайт показывал товары, которых уже не было на складе.
Причина: остатки обновлялись раз в сутки. Склад работал в течение всего дня.
Решение: мы подключили обмен с учётной системой через API. Сайт стал получать изменения по товарам чаще. Для критичных операций добавили обработку событий.
Также мы настроили журнал обмена. Ошибки стали видны менеджеру без проверки базы вручную.
Результат: сайт стал показывать актуальные остатки. Количество ручных проверок снизилось. Менеджеры перестали тратить время на поиск причин расхождений.
Это типичный пример. Каждому магазину нужна своя схема интеграции.
Сколько ошибок можно избежать с автоматизацией
Даже небольшое сокращение ручных операций заметно влияет на бизнес.
Например, если менеджер тратит 3 минуты на проверку одного проблемного заказа, 100 таких случаев занимают около 5 часов работы.
При автоматической проверке остатка эта операция становится частью системы.
Важно понимать: автоматизация не просто экономит время. Она снижает вероятность человеческой ошибки.
Особенно это важно при большом каталоге.
Чек-лист надёжной интеграции
Перед запуском синхронизации проверьте следующие пункты:
- Для каждого поля определён главный источник.
- У товаров есть стабильный внешний идентификатор.
- Остаток учитывает резерв.
- Цена передаётся с нужным типом.
- Система передаёт только необходимые изменения.
- Есть журнал обмена.
- Есть повторные попытки.
- Ошибки не останавливают весь импорт.
- Настроены уведомления.
- Есть тестовый контур.
- Выполняется контрольное сравнение данных.
- Менеджер может быстро найти причину ошибки.
Если несколько пунктов отсутствуют, интеграцию стоит проверить до масштабирования магазина.
Почему WordPress требует отдельного подхода
WordPress часто используют вместе с WooCommerce. Платформа хорошо подходит для интернет-магазинов. Но сложный обмен требует грамотной настройки.
Особое внимание нужно уделить:
- структуре товаров;
- вариативным товарам;
- SKU;
- остаткам по складам;
- cron-задачам;
- REST API;
- кэшированию;
- производительности базы данных.
Нельзя просто запустить импорт и забыть о нём.
При большом каталоге неудачная синхронизация способна создать нагрузку на сервер. Это замедлит сайт и ухудшит работу пользователей.
Поэтому интеграцию нужно проектировать вместе с архитектурой магазина.
Когда нужна индивидуальная интеграция
Готовый плагин подходит не каждому проекту.
Индивидуальная разработка нужна, если:
- используется нестандартная ERP;
- несколько складов имеют разные правила;
- цены зависят от региона;
- есть сложная система резервов;
- нужен обмен в реальном времени;
- каталог содержит десятки тысяч товаров;
- стандартный импорт создаёт ошибки.
В таких проектах мы сначала анализируем бизнес-процессы. Затем определяем источники данных. После этого проектируем API или другой канал обмена.
Такой подход позволяет избежать ситуации, когда техническое решение не соответствует процессам компании.
Как понять, что синхронизация работает правильно
Надёжность нужно проверять не визуально.
Недостаточно открыть карточку товара и увидеть правильную цену.
Нужно провести тесты:
- Изменить цену в ERP.
- Проверить обновление на сайте.
- Изменить остаток.
- Создать заказ.
- Проверить резерв.
- Изменить статус заказа.
- Отключить API.
- Проверить повторную отправку.
- Сравнить данные после восстановления соединения.
Отдельно стоит проводить регулярную сверку.
Например, раз в сутки система может сравнивать данные сайта и склада. Если найдено расхождение, создаётся уведомление.
Такой контроль работает как дополнительный уровень защиты.
Итог: синхронизация цен и остатков должна работать автоматически
Синхронизация цен и остатков — не просто техническая функция сайта. Это важная часть бизнес-процесса интернет-магазина.
Правильная интеграция должна:
- получать актуальные данные;
- учитывать резервы;
- корректно определять товар;
- обрабатывать ошибки;
- повторять неудачные операции;
- вести журнал;
- уведомлять о критических сбоях.
Вы столкнулись с расхождениями между сайтом и складом? В «Компьюти» мы анализируем текущую схему обмена, находим узкие места и настраиваем автоматическую синхронизацию цен и остатков. Это помогает сократить ручную работу и снизить количество ошибок в заказах.
