МойСклад отдаёт данные через документированный интерфейс, поэтому основная работа не в подключении, а в структуре: как сопоставлены товары и варианты, кто владеет каждым полем и что делать при расхождении. Мы начинаем с аудита данных и заканчиваем наблюдением за первыми циклами обмена.
Страница для малого и среднего бизнеса, который ведёт учёт в МоёмСкладе. Если узнаёте несколько пунктов, задача сформулирована верно.
Каталог заводится дважды: в сервисе учёта и на сайте.
Остатки на сайте отстают, поэтому приходят заказы на позиции, которых нет.
Статус заказа приходится сообщать покупателю вручную.
Варианты и характеристики в учёте и на сайте описаны по-разному, из-за этого путаются позиции.
Синхронизация настроена типовым модулем, но регулярно расходится, и причину найти нельзя.
Непонятно, какая система главная: правки вносятся то там, то там.
Если учёт ведётся в 1С с индивидуальными доработками, точнее подойдёт страница про интеграцию с 1С
Основная проблема
Проблема не в подключении, а в структуре данных
Подключиться к облачному сервису учёта технически несложно: интерфейс документирован, доступ выдаётся ключом. Поэтому кажется, что интеграция — это включить обмен и забыть. На практике расхождения начинаются в структуре: на сайте товар с размерами описан как один товар с вариантами, а в учёте — как несколько отдельных позиций, характеристики называются по-разному, единицы измерения не совпадают, часть позиций заведена без устойчивого идентификатора.
Второй источник расхождений — неопределённость владения полями. Если наименование и описание правит контент-менеджер на сайте, а обмен затем перезаписывает их значениями из учёта, работа теряется каждый цикл. Если наоборот, в учёте появляются тексты, которые ему не нужны. Пока не решено, кто владеет каждым полем, любая настройка обмена будет конфликтовать с чьей-то работой.
Третья часть — поведение при сбое. Облачный сервис имеет ограничения на частоту обращений, и обмен обязан их учитывать: очередь, повторные попытки, защита от повторной обработки одного заказа. Без этого при пиковой нагрузке часть операций теряется молча. Поэтому мы делаем не «включённую синхронизацию», а наблюдаемый обмен: с журналом, повторной отправкой и проверкой тестовыми заказами до запуска.
Что происходит без изменений
Что следует из отсутствия синхронизации
Только логические следствия. Мы не приводим выдуманных цифр потерь.
Двойной ввод каталога
Каждая новая позиция заводится в двух системах, и различия между ними накапливаются.
Заказы на отсутствующие позиции
Остатки на сайте не соответствуют учёту, что приводит к отменам и согласованиям замены.
Ручное информирование покупателя
Без обмена статусами о состоянии заказа сообщают вручную, и часть покупателей остаётся без ответа.
Путаница в вариантах
Разное описание характеристик приводит к отгрузке не того варианта товара.
Молчаливая потеря операций
Без очереди и повторных попыток часть обменов при пиковой нагрузке не доходит и остаётся незамеченной.
Потеря контентной работы
Обмен без правил владения полями перезаписывает описания и тексты, подготовленные для сайта.
Что создаётся
Что создаётся
Результат — предсказуемая синхронизация с понятными правилами и журналом.
Аудит структуры данных
Разбираем, как в учёте устроены товары, варианты, характеристики, единицы измерения и склады, и сопоставляем со структурой сайта.
Снимает: Расхождения выявляются до настройки обмена, а не после запуска.
Правила владения полями
Фиксируем, какая система владеет наименованием, описанием, ценой, остатком, изображениями и характеристиками.
Снимает: Обмен перестаёт перезаписывать чужую работу.
Сопоставление товаров и вариантов
Настраиваем связь по устойчивому идентификатору, обработку новых, изменённых и снятых позиций.
Снимает: Позиции не дублируются, вариант соответствует варианту.
Передача остатков
Реализуем обновление остатков по выбранным складам с согласованной частотой и правилами резерва.
Снимает: Сайт продаёт в пределах фактического наличия.
Обмен статусами заказов
Настраиваем передачу заказа в учёт и возврат статусов на сайт с сопоставлением названий.
Снимает: Покупатель и менеджер видят одинаковое состояние заказа.
Работа с документами
Организуем создание нужных документов в учёте и доступ к ним в тех пределах, которые допускает сервис.
Снимает: Оформление заказа не требует ручного дублирования в учёте.
Правила конфликта и частота обмена
Определяем интервалы обмена, приоритет значений при расхождении и поведение при ограничении частоты обращений.
Снимает: Обмен предсказуем и не упирается в лимиты сервиса.
Ошибки, повторы и журнал
Добавляем очередь, повторную отправку, защиту от повторной обработки и журнал операций.
Снимает: Сбой не приводит к потере заказа и виден по записям.
Схема работы
Где решение работает в цепочке продаж
Синхронизация отвечает за достоверность каталога и наличия, а также за передачу заказа в учёт и возврат статуса.
ТрафикНа привлечение обмен не влияет; он влияет на достоверность витрины.Общий контур
КаталогТовары, варианты и характеристики приходят из учёта.Зона этой услуги
Карточка товараНаличие и параметры варианта соответствуют учётным данным.Зона этой услуги
КорзинаПроверка наличия на момент оформления.Зона этой услуги
Аудит структуры данных и перечень расхождений с решениями по каждому.
Правила владения полями и приоритет значений при конфликте.
Сопоставление товаров, вариантов и характеристик.
Передача остатков, заказов, статусов и работа с документами.
Очередь, повторная отправка, журнал и уведомления о сбоях.
Тестовые заказы, запуск и наблюдение за первыми циклами.
Клиент
Доступ к учётной записи сервиса с необходимыми правами.
Решение о владельце каждого поля.
Качество данных: идентификаторы, характеристики, единицы измерения, склады.
Тариф сервиса, допускающий нужный объём операций.
Дисциплина работы со статусами и документами в учёте.
Договоры с платёжными сервисами и службами доставки.
Стоимость
Что влияет на оценку
Стоимость определяется состоянием данных и составом обмена, а не числом товаров.
Состояние данных в учёте
Отсутствие устойчивых идентификаторов, разнородные характеристики и дубли позиций добавляют работу по сопоставлению.
Структура вариантов
Товары с несколькими характеристиками вариантов требуют более сложного сопоставления, чем простые позиции.
Состав обмена
Каталог, остатки, заказы, статусы и документы оцениваются по фактическому перечню.
Требуемая частота обновления
Короткие интервалы требуют очереди и учёта ограничений сервиса.
Глубина работы с документами
Перечень документов и правила их формирования влияют на трудоёмкость.
Требования к наблюдаемости
Журнал, уведомления и сценарии повторной отправки влияют на объём работ.
Расчёт формируем после аудита данных: он показывает, сколько работы уйдёт на приведение структуры к единому виду. Ценовая лестница интернет-магазинов на интеграцию автоматически не переносится.
Вопросы и ответы
Вопросы о синхронизации с МоимСкладом
Типовой модуль решает подключение, но не структуру. Если в учёте вариант товара описан иначе, чем на сайте, а владелец описаний не определён, модуль будет исправно переносить данные и исправно ломать вашу работу каждый цикл. Мы делаем аудит и правила владения — именно это отличает работающий обмен от включённого.
Ничего, если закрепить их за сайтом в правилах владения полями. Тогда обмен передаёт из учёта наименование, цену, остаток и характеристики, а тексты и метаданные остаются под управлением сайта. Это стандартное решение для магазинов, которые вкладываются в поисковый трафик.
Интервал согласуем исходя из ваших процессов и ограничений сервиса на частоту обращений. Для многих магазинов достаточно обновления несколько раз в сутки, для товаров с быстрым оборотом нужны короткие интервалы и очередь. Полностью мгновенного соответствия не бывает ни у одной интеграции — важно, чтобы задержка была известной и приемлемой.
Операции становятся в очередь и отправляются повторно, а ответственный получает уведомление о сбое. Защита от повторной обработки не позволяет создать дубль заказа. Это проверяется искусственно вызванным сбоем на тестовых заказах до запуска.
В тех пределах, которые допускает сервис. Заказ и связанные с ним документы могут формироваться в учёте автоматически, но формирование бухгалтерских документов и электронный документооборот остаются в контуре клиента. Мы явно фиксируем, какие документы попадают в обмен, а какие нет.
Часто да, и это выясняется на аудите. Обмен переносит значения, а не исправляет их: дубли позиций, пустые характеристики и разные единицы измерения окажутся на сайте. Мы отдаём перечень таких мест с решениями, и часть работы по приведению данных обычно эффективнее выполнить на стороне учёта.
Ответственность разделена явно: мы отвечаем за корректность передачи и за поведение обмена при ошибках, клиент — за содержание данных в учёте. Поэтому в приёмке есть проверка передачи, а не проверка достоверности исходных значений: это разные вещи, и смешивать их некорректно.
Мы наблюдаем за первыми циклами обмена и корректируем интервалы и правила по фактическому поведению. Дальнейшее сопровождение обмена — предмет отдельной договорённости о поддержке, поскольку речь о постоянной работе, а не о разовой настройке.
Следующий шаг
Обсудим синхронизацию с МоимСкладом
Напишите, что нужно синхронизировать и как устроены варианты товаров. Предложим порядок аудита и состав обмена.