Интеграции

    Интеграция магазина с МоимСкладом

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

    • Аудит структуры данных
    • Товары и варианты
    • Остатки и статусы
    • Правила конфликта
    • Повторная отправка

    Быстрая диагностика

    Быстрая диагностика: это ваша ситуация?

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

    Каталог заводится дважды: в сервисе учёта и на сайте.

    Остатки на сайте отстают, поэтому приходят заказы на позиции, которых нет.

    Статус заказа приходится сообщать покупателю вручную.

    Варианты и характеристики в учёте и на сайте описаны по-разному, из-за этого путаются позиции.

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

    Непонятно, какая система главная: правки вносятся то там, то там.

    Если учёт ведётся в 1С с индивидуальными доработками, точнее подойдёт страница про интеграцию с 1С

    Основная проблема

    Проблема не в подключении, а в структуре данных

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

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

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

    Иллюстрация несовпадения структуры данных между сайтом и облачным сервисом учёта

    Что происходит без изменений

    Что следует из отсутствия синхронизации

    Только логические следствия. Мы не приводим выдуманных цифр потерь.

    Двойной ввод каталога

    Каждая новая позиция заводится в двух системах, и различия между ними накапливаются.

    Заказы на отсутствующие позиции

    Остатки на сайте не соответствуют учёту, что приводит к отменам и согласованиям замены.

    Ручное информирование покупателя

    Без обмена статусами о состоянии заказа сообщают вручную, и часть покупателей остаётся без ответа.

    Путаница в вариантах

    Разное описание характеристик приводит к отгрузке не того варианта товара.

    Молчаливая потеря операций

    Без очереди и повторных попыток часть обменов при пиковой нагрузке не доходит и остаётся незамеченной.

    Потеря контентной работы

    Обмен без правил владения полями перезаписывает описания и тексты, подготовленные для сайта.

    Что создаётся

    Что создаётся

    Результат — предсказуемая синхронизация с понятными правилами и журналом.

    Аудит структуры данных

    Разбираем, как в учёте устроены товары, варианты, характеристики, единицы измерения и склады, и сопоставляем со структурой сайта.

    Снимает: Расхождения выявляются до настройки обмена, а не после запуска.

    Правила владения полями

    Фиксируем, какая система владеет наименованием, описанием, ценой, остатком, изображениями и характеристиками.

    Снимает: Обмен перестаёт перезаписывать чужую работу.

    Сопоставление товаров и вариантов

    Настраиваем связь по устойчивому идентификатору, обработку новых, изменённых и снятых позиций.

    Снимает: Позиции не дублируются, вариант соответствует варианту.

    Передача остатков

    Реализуем обновление остатков по выбранным складам с согласованной частотой и правилами резерва.

    Снимает: Сайт продаёт в пределах фактического наличия.

    Обмен статусами заказов

    Настраиваем передачу заказа в учёт и возврат статусов на сайт с сопоставлением названий.

    Снимает: Покупатель и менеджер видят одинаковое состояние заказа.

    Работа с документами

    Организуем создание нужных документов в учёте и доступ к ним в тех пределах, которые допускает сервис.

    Снимает: Оформление заказа не требует ручного дублирования в учёте.

    Правила конфликта и частота обмена

    Определяем интервалы обмена, приоритет значений при расхождении и поведение при ограничении частоты обращений.

    Снимает: Обмен предсказуем и не упирается в лимиты сервиса.

    Ошибки, повторы и журнал

    Добавляем очередь, повторную отправку, защиту от повторной обработки и журнал операций.

    Снимает: Сбой не приводит к потере заказа и виден по записям.

    Схема работы

    Где решение работает в цепочке продаж

    Синхронизация отвечает за достоверность каталога и наличия, а также за передачу заказа в учёт и возврат статуса.

    1. ТрафикНа привлечение обмен не влияет; он влияет на достоверность витрины.Общий контур
    2. КаталогТовары, варианты и характеристики приходят из учёта.Зона этой услуги
    3. Карточка товараНаличие и параметры варианта соответствуют учётным данным.Зона этой услуги
    4. КорзинаПроверка наличия на момент оформления.Зона этой услуги
    5. ОплатаПлатёжный сценарий настраивается отдельно.Зависимость
    6. СкладОстатки по складам — основной предмет обмена.Зона этой услуги
    7. ДоставкаСлужбы доставки подключаются отдельными интеграциями.Зависимость
    8. CRMРабота менеджеров со сделками — отдельная интеграция.Зависимость
    9. Повторная продажаИстория заказов в учёте делает повторную покупку возможной.Общий контур

    Обмен обеспечивает данные; продажи обеспечивает магазин целиком — его контур описан на странице раздела.

    Состав решения

    Состав решения

    Сначала данные и правила, затем обмен, затем проверка тестовыми заказами.

    Аудит структуры данных

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

    Правила владения полями и конфликта

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

    Сопоставление товаров, вариантов и характеристик

    Входные данные
    Устойчивые идентификаторы позиций, структура вариантов, перечень характеристик.
    Работа
    Настраиваем связь позиций и вариантов, обработку новых и снятых товаров, перенос характеристик.
    Результат в системе
    Каталог сайта соответствует учёту без дублей.
    Зависимость
    Наличие идентификаторов и заполненных характеристик в учёте.
    Проверка готовности
    Контрольная выборка товаров с вариантами сопоставлена верно.

    Остатки и резервы

    Входные данные
    Перечень складов, участвующих в продажах, правила резерва под заказ.
    Работа
    Реализуем обновление остатков, учёт резервов и поведение при нулевом наличии.
    Результат в системе
    Наличие на сайте соответствует фактическому.
    Зависимость
    Актуальность остатков в учёте.
    Проверка готовности
    Изменение остатка в учёте доходит до сайта в согласованный интервал.

    Заказы, статусы и документы

    Входные данные
    Состав полей заказа, соответствие статусов, перечень нужных документов.
    Работа
    Настраиваем создание заказа в учёте, возврат статусов, формирование документов в допустимых сервисом пределах.
    Результат в системе
    Заказ и его состояние живут в одной системе истины.
    Зависимость
    Дисциплина работы со статусами в учёте.
    Проверка готовности
    Тестовый заказ создаётся один раз, статус доходит до сайта, документы формируются.

    Частота обмена и лимиты

    Входные данные
    Требования к скорости обновления, ожидаемый объём операций.
    Работа
    Подбираем интервалы, реализуем очередь и учёт ограничений на частоту обращений к сервису.
    Результат в системе
    Обмен работает стабильно и не упирается в лимиты.
    Зависимость
    Тарифные и технические ограничения сервиса учёта.
    Проверка готовности
    При повышенной нагрузке операции не теряются, а становятся в очередь.

    Ошибки, повторная отправка, журнал

    Входные данные
    Требования к уведомлениям и ответственные.
    Работа
    Добавляем контроль ошибок, повторную отправку, защиту от повторной обработки, журнал и уведомления.
    Результат в системе
    Сбой обнаруживается сразу и разбирается по записям.
    Зависимость
    Наличие адресата уведомлений.
    Проверка готовности
    Искусственный сбой попадает в журнал, порождает уведомление, заказ не теряется.

    Тестовые заказы, запуск и наблюдение

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

    Сценарии использования

    Типовые исходные ситуации

    Обезличенные схемы. Аудитория страницы — малый и средний бизнес.

    Каталог ведётся в учёте, сайт заполняется вручную

    Начинаем с сопоставления позиций и передачи остатков — это снимает большую часть расхождений.

    Много товаров с размерами и цветами

    Приоритет — структура вариантов и характеристик: без неё обмен будет путать позиции.

    Синхронизация работает через типовой модуль и расходится

    Разбираем правила владения полями и точки отказа, добавляем журнал и повторную отправку.

    Несколько складов и точек выдачи

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

    Контент готовится отдельно под SEO

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

    Интеграции и зависимости

    Что участвует и где границы

    Возможности обмена ограничены тем, что предоставляет сервис учёта и ваш тариф.

    МойСклад

    Источник товаров, вариантов, остатков, документов и статусов.

    Граница: Состав доступных операций и ограничения на частоту обращений задаёт сервис; мы работаем в этих пределах.

    Тариф и доступы

    Права доступа и допустимая нагрузка на обмен.

    Граница: Оплата тарифа и выдача доступов — зона клиента.

    Интернет-магазин

    Каталог, корзина, оформление заказа, отображение наличия.

    Граница: Сайт отображает данные учёта и не исправляет ошибки в них.

    Платёжный сервис

    Факт оплаты, который может отражаться в учёте.

    Граница: Договор с оператором и касса — зона клиента.

    Службы доставки

    Расчёт стоимости и создание отправлений.

    Граница: Подключаются отдельными интеграциями.

    CRM

    Работа менеджеров с обращениями и сделками.

    Граница: Передача данных в CRM — отдельная задача.

    Этапы работы

    Этапы работы

    Аудит идёт первым: он определяет, какую часть работы займёт приведение данных в порядок.

    1. Аудит данных

      Сопоставляем структуру товаров, вариантов, характеристик и складов с сайтом.

    2. Правила владения

      Фиксируем владельца каждого поля и приоритет при расхождении.

    3. Технические договорённости

      Согласуем состав обмена, интервалы и поведение при ограничении частоты обращений.

    4. Сопоставление

      Настраиваем связь позиций и вариантов, обработку новых и снятых товаров.

    5. Обмен

      Реализуем передачу остатков, заказов, статусов и работу с документами.

    6. Наблюдаемость

      Добавляем очередь, повторную отправку, журнал и уведомления о сбоях.

    7. Тестовые заказы

      Проверяем сценарии, включая ошибки, отмены и повторную отправку.

    8. Запуск и наблюдение

      Включаем обмен и наблюдаем за первыми циклами, корректируя интервалы и правила.

    Сроки заранее не фиксируем: они зависят от состояния данных в учёте, структуры вариантов, состава обмена и требуемой частоты обновления.

    Что проверяется при сдаче

    Что проверяется при сдаче

    Проверка идёт по данным и по поведению при сбое.

    • Правила владения полями согласованы письменно и соответствуют настройкам обмена.
    • Правка поля на стороне владельца сохраняется после цикла обмена.
    • Контрольная выборка товаров с вариантами и характеристиками сопоставлена верно.
    • Изменение остатка в учёте доходит до сайта в согласованный интервал.
    • Заказ с сайта создаётся в учёте один раз, без дублей, с полным составом.
    • Изменение статуса в учёте отражается на сайте.
    • Нужные документы формируются в учёте по заказу.
    • При повышенной нагрузке операции не теряются, а обрабатываются очередью.
    • Ошибка обмена фиксируется в журнале и порождает уведомление ответственному.
    • Повторная отправка не создаёт дубль заказа.
    • Изображения в формате WebP, имеют alt и заданные размеры, сдвига вёрстки при загрузке нет.
    • Нет горизонтальной прокрутки на 1440, 1280, 1024, 768, 390 и 360 px.

    Кому подходит

    Кому подходит

    Малый и средний бизнес с учётом в МоёмСкладе

    Решение имеет смысл при таких исходных данных

    • Учёт товаров и остатков реально ведётся в сервисе, а не в таблицах рядом с ним.
    • Есть возможность выдать доступ к учётной записи с нужными правами.
    • Есть готовность решить, какая система владеет каждым полем.
    • Структура вариантов и характеристик может быть приведена к единому виду.
    • Тариф сервиса допускает нужный объём операций обмена.
    • Нужна наблюдаемая синхронизация с журналом, а не разовая выгрузка.

    Когда нужен другой формат

    Когда точнее подойдёт другая страница

    Мы указываем это прямо, чтобы вы не платили за более широкий объём работ, чем нужно.

    Учёт ведётся в 1С, особенно с доработками.

    Интеграция с 1С

    Главная задача — заявки и работа отдела продаж.

    Интеграция с CRM

    Нужны расчёт доставки, ПВЗ и самовывоз.

    Доставка, ПВЗ и самовывоз

    Основной запрос — единый остаток и правила отгрузки со своего склада.

    Магазин со складом

    Зоны ответственности

    Зоны ответственности

    Like Sites

    • Аудит структуры данных и перечень расхождений с решениями по каждому.
    • Правила владения полями и приоритет значений при конфликте.
    • Сопоставление товаров, вариантов и характеристик.
    • Передача остатков, заказов, статусов и работа с документами.
    • Очередь, повторная отправка, журнал и уведомления о сбоях.
    • Тестовые заказы, запуск и наблюдение за первыми циклами.

    Клиент

    • Доступ к учётной записи сервиса с необходимыми правами.
    • Решение о владельце каждого поля.
    • Качество данных: идентификаторы, характеристики, единицы измерения, склады.
    • Тариф сервиса, допускающий нужный объём операций.
    • Дисциплина работы со статусами и документами в учёте.
    • Договоры с платёжными сервисами и службами доставки.

    Стоимость

    Что влияет на оценку

    Стоимость определяется состоянием данных и составом обмена, а не числом товаров.

    Состояние данных в учёте

    Отсутствие устойчивых идентификаторов, разнородные характеристики и дубли позиций добавляют работу по сопоставлению.

    Структура вариантов

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

    Состав обмена

    Каталог, остатки, заказы, статусы и документы оцениваются по фактическому перечню.

    Требуемая частота обновления

    Короткие интервалы требуют очереди и учёта ограничений сервиса.

    Глубина работы с документами

    Перечень документов и правила их формирования влияют на трудоёмкость.

    Требования к наблюдаемости

    Журнал, уведомления и сценарии повторной отправки влияют на объём работ.

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

    Вопросы и ответы

    Вопросы о синхронизации с МоимСкладом

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

    Следующий шаг

    Обсудим синхронизацию с МоимСкладом

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

    Телефон +7 (495) 201-25-26, почта like-sites@mail.ru.

    ИЛИ
    Заполнить бриф в Telegram (быстрее)