К содержанию

Разбор6 мин чтения

Синхронизация сайта со складом — как остатки и цены обновляются сами

Какая система главная, что передавать на сайт, как часто обновлять и что делать, если у учётной системы нет API. На примере магазина, где цены и остатки приходят из UMAG каждые пять минут.

Нуралы КопбосынДизайнер и разработчик цифровых продуктов · 8 лет, 80+ проектов
Содержание6 разделов
  1. Какая система главная
  2. Что передавать на сайт, а что — нет
  3. Как часто обновлять остатки
  4. В одну сторону или в обе
  5. Если у учётной системы нет API
  6. Чтобы обмен не ломался молча

Чтобы остатки и цены на сайте обновлялись сами, сайт должен брать их из учётной системы — 1С, UMAG или другой — по расписанию, а не из рук менеджера. Техническая часть здесь не самая сложная. Сложнее договориться о правилах: какая система главная, что именно передавать, как часто обновлять и что делать, когда обмен сломался. Если эти правила не записаны, синхронизация быстро превращается в два учёта, которые спорят между собой.

Какая система главная

Первое решение — кто отвечает за каждое поле. Для цен и остатков главной почти всегда должна быть учётная система: там их меняют продавцы и бухгалтер, там проходят продажи в рознице. Сайт их только показывает.

Для описаний, фотографий, характеристик и SEO-текстов — наоборот. В складской программе их обычно нет, а если есть, то в виде, который покупателю не покажешь. Их ведут в админке сайта.

Отсюда простое правило: поле, которое приходит из учёта, на сайте руками не правят. Иначе получается знакомая сцена: менеджер поменял цену в админке, через несколько минут обмен вернул старую, и все уверены, что «сайт глючит». Поэтому такие поля в админке лучше делать только для чтения — с подписью, откуда они пришли.

Что передавать на сайт, а что — нет

Минимальный набор — артикул, цена и остаток. Артикул — это связка: по нему сайт понимает, что товар в учёте и карточка на сайте — одно и то же. Если артикулы в учёте ведутся небрежно — дубли, пробелы, разные форматы, — начинать придётся с них.

Дальше — правила, которые лучше зашить в обмен, чем держать в голове у сотрудников:

  • Новый товар. Появился в учёте — создаётся на сайте скрытым, пока у него нет фото и описания. Пустая карточка в каталоге хуже, чем её отсутствие.
  • Типы цен. В учёте их обычно несколько: розничная, оптовая, закупочная. На сайт уходят только те, которые можно показывать покупателю. Закупочную не стоит передавать даже в скрытом поле — скрытое поле видно любому, кто откроет код страницы.
  • Нулевой остаток. Скрывать товар или показывать «нет в наличии» — решение маркетинга, а не программиста. Если товар регулярно возвращается в продажу, страницу лучше оставить: она уже собирает поисковый трафик.
  • Товары, которые нельзя показывать. В табачном магазине Wigwam аксессуары, цены и остатки приходят на сайт из складской системы UMAG, а табак не попадает на сайт никогда — этого требует закон о рекламе. Правило работает на уровне обмена, а не на внимательности сотрудника.
  • Несколько складов или точек. Показывать общий остаток или наличие по каждой точке — зависит от того, как вы выдаёте заказы: доставкой со склада или самовывозом из магазина.

Как часто обновлять остатки

В Wigwam обмен со складом идёт каждые пять минут: продали аксессуар в магазине — вскоре его нет и на сайте. Для розничного магазина такого интервала достаточно.

Мгновенная синхронизация звучит лучше, но стоит дороже и нужна реже, чем кажется. Важнее понимать, что происходит в промежутке между обменами. Если последний товар купили в зале, а через минуту его же заказали на сайте, такой заказ не должен подтверждаться автоматически: менеджер видит, что остаток уже нулевой, и предлагает замену. Когда таких случаев становится много, это сигнал сокращать интервал или резервировать товар под заказ.

Если вы продаёте ещё и на маркетплейсах, остатки туда нужно отдавать из того же источника. Иначе та же проблема просто переедет на другую площадку.

В одну сторону или в обе

Обмен бывает односторонним — учёт отдаёт сайту цены и остатки — и двусторонним, когда заказ с сайта сразу попадает в учёт и резервирует товар. Односторонний проще и надёжнее, и небольшому магазину его часто хватает: менеджер подтверждает каждый заказ и сам проводит продажу в учёте.

Двусторонний нужен, когда заказов много или товар уходит быстро. Без резерва один и тот же последний экземпляр продают дважды — на сайте и в зале. Но и требований к обмену больше: заказ должен попасть в учёт ровно один раз, с правильными товарами и ценами, а отмена на сайте — снять резерв. Каждый такой случай проверяется до запуска, а не после первой ошибки.

Если у учётной системы нет API

Так было с Wigwam: когда я делал сайт, у UMAG не было API для интернет-магазина, и магазин уже присматривал другой учёт. Я добился, чтобы UMAG открыл API, и переезд не понадобился. Эту историю я подробно рассказывал в заметке «Задачи, у которых нет готового решения», а здесь — общий порядок, в котором я перебираю варианты:

  1. Выгрузка файлом. Почти любая учётная система умеет выгружать Excel, CSV или XML. Файл можно забирать по расписанию. Это медленнее и хрупче API, но работает.
  2. Разговор с разработчиком системы. Вендоры учётных программ чаще идут навстречу, когда к ним приходят с конкретной задачей, а не с жалобой.
  3. Смена учёта — в самом конце. Переезд — это перенос базы, переобучение продавцов и период, когда всё ведётся в двух местах. Ради сайта менять учёт стоит только тогда, когда других путей нет.

С 1С ситуация обычно другая: способы обмена с сайтом у неё есть. Но в каждой базе свои склады, поля и доработки, поэтому обмен приходится настраивать под конкретную конфигурацию, а не включать одной кнопкой. До начала работ стоит выяснить, кто обслуживает вашу 1С: доработки на её стороне почти всегда нужны, и без этого человека проект встанет.

Чтобы обмен не ломался молча

Самая неприятная поломка синхронизации — тихая. Обмен перестал работать в пятницу вечером, а в понедельник выясняется, что все выходные сайт продавал товар, которого нет. Поэтому в любой интеграции со складом я закладываю четыре вещи:

  • журнал — когда был обмен, сколько товаров обновлено, что не прошло и почему;
  • оповещение об ошибке — тому, кто отвечает за сайт, а не в общий чат, где его никто не прочитает;
  • кнопку ручного запуска в админке — чтобы после переоценки не ждать следующего обмена;
  • проверку на реальных выгрузках — не на примерах из документации, а на ваших данных, с их опечатками и дублями.

Синхронизация со складом убирает две вещи, которые дорого обходятся магазину: отменённые заказы и ручной перенос цен, который никто не любит и все делают с ошибками. Если остатки на вашем сайте расходятся с учётом, посмотрите, как я делаю синхронизацию остатков. Для конкретных систем есть отдельные страницы — UMAG и 1С.

Есть задача — напишите, разберём.

Опишите в двух словах, что нужно, — отвечу сам, без менеджеров и брифов на десять страниц.