Интеграция интернет-магазина с учётной системой

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

Что именно нужно синхронизировать

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

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

Где должен жить «источник правды»

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

• Цены и остатки — почти всегда в учётной системе. Там их контролирует бухгалтерия и склад.
• Наименования и артикулы — тоже в учёте, на сайте их только отображают.
• Маркетинговые описания, фото, SEO-тексты — удобнее вести на сайте. В учётной системе для этого обычно нет нормальных инструментов, и контент-менеджеру проще работать в админке магазина.
• Структура каталога на сайте — часто отличается от групп номенклатуры в учёте, и это нормально. Нужна таблица соответствий.
• Данные покупателя — создаются на сайте, но при повторных заказах должны сопоставляться с существующим контрагентом.

Способы обмена данными

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

Обмен файлами по расписанию

Учётная система выгружает файл (XML, CSV, JSON) в определённое место, сайт его забирает и обрабатывает. Это самый простой и распространённый вариант. Минусы — задержка между изменением и его появлением на сайте и проблемы при больших объёмах: полная выгрузка каталога в сто тысяч позиций может обрабатываться долго.

Обмен через программный интерфейс

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

Промежуточный сервис

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

Какой бы способ ни выбрали, важно передавать не полные выгрузки каждый раз, а только изменения. Полная выгрузка раз в сутки как страховка — хорошая практика, но основной обмен должен быть инкрементальным.

Типичные проблемы, с которыми мы сталкиваемся

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

• Грязные данные в учёте. Дубли номенклатуры, товары без артикулов, характеристики записаны в названии через запятую. Сайт честно покажет всё это покупателю.
• Нет ответственного на стороне учёта. Программист учётной системы работает на аутсорсе, отвечает раз в неделю, и каждое изменение формата обмена растягивается на месяц.
• Характеристики не структурированы. Для фильтров на сайте нужны отдельные поля «Цвет», «Размер», «Материал», а в учёте всё это — свободный текст в поле «Описание».
• Резерв не учитывается. Сайт показывает остаток «5 штук», но три из них уже зарезервированы под оптовый заказ.
• Нет обработки ошибок. Обмен падает ночью, никто не замечает, и утром сайт работает со вчерашними остатками.
• Торговые предложения. Один товар в разных размерах и цветах в учёте заведён как десять отдельных позиций, а на сайте должен быть одной карточкой с выбором.

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

Как спланировать интеграцию

Чтобы интеграция не растянулась на полгода, мы выстраиваем работу в несколько этапов.

1. Аудит данных в учёте. Смотрим, в каком состоянии номенклатура, характеристики, цены. Часто первые недели уходят на наведение порядка, и это нормально.
2. Описание потоков. Для каждого типа данных: откуда, куда, как часто, какие поля, что делать при конфликте.
3. Согласование формата с программистом учётной системы. Желательно на одной встрече, с конкретными примерами файлов или запросов.
4. Тестовый контур. Обмен сначала запускается на копии сайта и тестовой базе учёта.
5. Пробная эксплуатация. Несколько недель обмен работает параллельно с ручной сверкой.
6. Мониторинг. Уведомления об ошибках обмена приходят ответственным, а в админке видно время последней успешной синхронизации.

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

Что ещё стоит подключить заодно

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

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

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

Вывод

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