Интеграция сайта с 1С и локальными CRM: как перестать вести склад вручную
Пока менеджер вручную переносит заказы с сайта в учётную систему, вы платите зарплату за работу, которую скрипт делает за секунду и без ошибок.
Что именно синхронизируют
Обмен раскладывается на четыре независимых потока: номенклатура с описаниями и характеристиками, цены с учётом типов и скидок, остатки по складам, заказы с сайта в учётную систему и статусы обратно.
Их частота разная и это принципиально. Номенклатура меняется редко и может выгружаться раз в сутки, цены — раз в несколько часов, остатки в живой рознице — каждые 10–15 минут, заказы должны уходить мгновенно.
Пытаться гонять всё одним тяжёлым обменом раз в сутки — типовая ошибка: остатки протухают, клиент оформляет отсутствующий товар, менеджер звонит извиняться. Разнесите потоки по расписаниям.
Три технических способа связи
Обмен файлами: учётная система выкладывает XML или CSV по расписанию, сайт забирает и разбирает. Способ примитивный, но надёжный и подходит, когда 1С стоит в локальной сети без внешнего доступа. Минус — задержка и отсутствие обратной связи об ошибке.
REST API на стороне сайта: 1С сама отправляет POST-запросы на защищённые эндпоинты, а сайт отвечает кодами 200, 400 или 409. Это самый прозрачный вариант: понятно, кто инициатор, есть логи, есть повторные попытки.
Промежуточная база или брокер очередей нужны при больших объёмах, когда прямые запросы не выдерживают нагрузки, либо когда систем больше двух. Для среднего бизнеса это обычно избыточно.
Ключ соответствия — самое важное решение
У каждой позиции должен быть стабильный идентификатор, общий для сайта и учётной системы: GUID из 1С или артикул, который никто не меняет. Сопоставление по названию товара разваливается на первой же опечатке.
Храните на стороне сайта поле external_id с уникальным индексом. Тогда повторная выгрузка одного и того же товара делает обновление, а не создаёт дубль, а операция становится идемпотентной.
Ту же логику применяйте к заказам: сайт передаёт свой номер, 1С возвращает свой, и оба хранятся в одной записи. Без этого сверка расхождений превращается в ручной поиск по датам и суммам.
Остатки, резервы и цены
Решите заранее, что показывать: точное число или градацию «в наличии / мало / под заказ». Второе честнее, потому что между двумя синхронизациями число всё равно неверно, и снимает споры с покупателем.
Резервирование обязано происходить в момент оформления заказа, а не при синхронизации. Иначе два клиента одновременно покупают последнюю единицу — на локальном рынке это регулярно случается по товарам, которые продаются и офлайн в магазине.
Цены в сумах храните в целых числах минимальной единицы и округляйте по одному согласованному правилу на обеих сторонах. Расхождение в округлении даёт разные суммы в чеке на сайте и в учётной системе, и разбирательство занимает дни.
Ошибки, повторы и наблюдаемость
Любой обмен обязан быть идемпотентным: повторная отправка того же заказа не создаёт второй. Проще всего — уникальный ключ запроса и проверка на его существование до записи.
Заведите таблицу лога обмена: время, направление, размер пакета, коды ответа, текст ошибки. При инциденте вопрос «дошёл ли заказ» должен решаться одним запросом, а не перепиской.
Настройте оповещение в Telegram при неудачном обмене — на локальном рынке это самый быстрый канал до ответственного. Тихий сбой обмена обнаруживается через неделю по жалобам клиентов, и это дорого.
Сроки и бюджет
Односторонняя выгрузка каталога и остатков — обычно 1–2 недели работы. Двусторонний обмен с заказами и статусами — от 3 недель. Сложные схемы с несколькими складами, типами цен и дилерскими условиями растягиваются дольше.
Ориентир по стоимости на локальном рынке: от 8 000 000 до 25 000 000 сум в зависимости от числа потоков и состояния учётной системы. Основная непредсказуемость — не код, а качество данных в 1С.
Заложите отдельный этап на чистку номенклатуры до старта разработки. Дубли позиций, пустые характеристики и товары без артикулов — причина большинства сорванных сроков интеграции.