Разбор6 мин чтения
Синхронизация сайта со складом — как остатки и цены обновляются сами
Какая система главная, что передавать на сайт, как часто обновлять и что делать, если у учётной системы нет API. На примере магазина, где цены и остатки приходят из UMAG каждые пять минут.
Нуралы КопбосынДизайнер и разработчик цифровых продуктов · 8 лет, 80+ проектовСодержание6 разделов
Чтобы остатки и цены на сайте обновлялись сами, сайт должен брать их из учётной системы — 1С, UMAG или другой — по расписанию, а не из рук менеджера. Техническая часть здесь не самая сложная. Сложнее договориться о правилах: какая система главная, что именно передавать, как часто обновлять и что делать, когда обмен сломался. Если эти правила не записаны, синхронизация быстро превращается в два учёта, которые спорят между собой.
Какая система главная
Первое решение — кто отвечает за каждое поле. Для цен и остатков главной почти всегда должна быть учётная система: там их меняют продавцы и бухгалтер, там проходят продажи в рознице. Сайт их только показывает.
Для описаний, фотографий, характеристик и SEO-текстов — наоборот. В складской программе их обычно нет, а если есть, то в виде, который покупателю не покажешь. Их ведут в админке сайта.
Отсюда простое правило: поле, которое приходит из учёта, на сайте руками не правят. Иначе получается знакомая сцена: менеджер поменял цену в админке, через несколько минут обмен вернул старую, и все уверены, что «сайт глючит». Поэтому такие поля в админке лучше делать только для чтения — с подписью, откуда они пришли.
Что передавать на сайт, а что — нет
Минимальный набор — артикул, цена и остаток. Артикул — это связка: по нему сайт понимает, что товар в учёте и карточка на сайте — одно и то же. Если артикулы в учёте ведутся небрежно — дубли, пробелы, разные форматы, — начинать придётся с них.
Дальше — правила, которые лучше зашить в обмен, чем держать в голове у сотрудников:
- Новый товар. Появился в учёте — создаётся на сайте скрытым, пока у него нет фото и описания. Пустая карточка в каталоге хуже, чем её отсутствие.
- Типы цен. В учёте их обычно несколько: розничная, оптовая, закупочная. На сайт уходят только те, которые можно показывать покупателю. Закупочную не стоит передавать даже в скрытом поле — скрытое поле видно любому, кто откроет код страницы.
- Нулевой остаток. Скрывать товар или показывать «нет в наличии» — решение маркетинга, а не программиста. Если товар регулярно возвращается в продажу, страницу лучше оставить: она уже собирает поисковый трафик.
- Товары, которые нельзя показывать. В табачном магазине Wigwam аксессуары, цены и остатки приходят на сайт из складской системы UMAG, а табак не попадает на сайт никогда — этого требует закон о рекламе. Правило работает на уровне обмена, а не на внимательности сотрудника.
- Несколько складов или точек. Показывать общий остаток или наличие по каждой точке — зависит от того, как вы выдаёте заказы: доставкой со склада или самовывозом из магазина.
Как часто обновлять остатки
В Wigwam обмен со складом идёт каждые пять минут: продали аксессуар в магазине — вскоре его нет и на сайте. Для розничного магазина такого интервала достаточно.
Мгновенная синхронизация звучит лучше, но стоит дороже и нужна реже, чем кажется. Важнее понимать, что происходит в промежутке между обменами. Если последний товар купили в зале, а через минуту его же заказали на сайте, такой заказ не должен подтверждаться автоматически: менеджер видит, что остаток уже нулевой, и предлагает замену. Когда таких случаев становится много, это сигнал сокращать интервал или резервировать товар под заказ.
Если вы продаёте ещё и на маркетплейсах, остатки туда нужно отдавать из того же источника. Иначе та же проблема просто переедет на другую площадку.
В одну сторону или в обе
Обмен бывает односторонним — учёт отдаёт сайту цены и остатки — и двусторонним, когда заказ с сайта сразу попадает в учёт и резервирует товар. Односторонний проще и надёжнее, и небольшому магазину его часто хватает: менеджер подтверждает каждый заказ и сам проводит продажу в учёте.
Двусторонний нужен, когда заказов много или товар уходит быстро. Без резерва один и тот же последний экземпляр продают дважды — на сайте и в зале. Но и требований к обмену больше: заказ должен попасть в учёт ровно один раз, с правильными товарами и ценами, а отмена на сайте — снять резерв. Каждый такой случай проверяется до запуска, а не после первой ошибки.
Если у учётной системы нет API
Так было с Wigwam: когда я делал сайт, у UMAG не было API для интернет-магазина, и магазин уже присматривал другой учёт. Я добился, чтобы UMAG открыл API, и переезд не понадобился. Эту историю я подробно рассказывал в заметке «Задачи, у которых нет готового решения», а здесь — общий порядок, в котором я перебираю варианты:
- Выгрузка файлом. Почти любая учётная система умеет выгружать Excel, CSV или XML. Файл можно забирать по расписанию. Это медленнее и хрупче API, но работает.
- Разговор с разработчиком системы. Вендоры учётных программ чаще идут навстречу, когда к ним приходят с конкретной задачей, а не с жалобой.
- Смена учёта — в самом конце. Переезд — это перенос базы, переобучение продавцов и период, когда всё ведётся в двух местах. Ради сайта менять учёт стоит только тогда, когда других путей нет.
С 1С ситуация обычно другая: способы обмена с сайтом у неё есть. Но в каждой базе свои склады, поля и доработки, поэтому обмен приходится настраивать под конкретную конфигурацию, а не включать одной кнопкой. До начала работ стоит выяснить, кто обслуживает вашу 1С: доработки на её стороне почти всегда нужны, и без этого человека проект встанет.
Чтобы обмен не ломался молча
Самая неприятная поломка синхронизации — тихая. Обмен перестал работать в пятницу вечером, а в понедельник выясняется, что все выходные сайт продавал товар, которого нет. Поэтому в любой интеграции со складом я закладываю четыре вещи:
- журнал — когда был обмен, сколько товаров обновлено, что не прошло и почему;
- оповещение об ошибке — тому, кто отвечает за сайт, а не в общий чат, где его никто не прочитает;
- кнопку ручного запуска в админке — чтобы после переоценки не ждать следующего обмена;
- проверку на реальных выгрузках — не на примерах из документации, а на ваших данных, с их опечатками и дублями.
Синхронизация со складом убирает две вещи, которые дорого обходятся магазину: отменённые заказы и ручной перенос цен, который никто не любит и все делают с ошибками. Если остатки на вашем сайте расходятся с учётом, посмотрите, как я делаю синхронизацию остатков. Для конкретных систем есть отдельные страницы — UMAG и 1С.