Товары ведут в двух местах
Номенклатура есть и в учёте, и в админке магазина. Артикулы и названия расходятся, а сопоставлять их приходится вручную.
Маркетплейсы и e-commerce
Интеграция e-commerce платформ с учётом, складом и доставкой
Магазин, склад и учёт показывают одно и то же
Магазин — это витрина, а не второе место хранения данных. Связываем его с учётом, складом и логистикой так, что товары, цены и остатки приходят из учётной системы, заказы и оплаты уходят обратно, а резерв и отгрузка отражаются документами. Платформа магазина при этом может быть любой — от готового движка до самописной витрины.
Почему витрина расходится с учётом
Магазин и учётная система решают разные задачи, и без обмена они неизбежно описывают реальность по-разному. Первым это замечает покупатель.
Остатки на витрине не соответствуют складу
Магазин показывает товар, которого нет, или прячет тот, который лежит. Продажи теряются с обеих сторон.
Заказы переносят руками
Каждый заказ перебивается в учётную систему. Ошибки в позициях и суммах всплывают при отгрузке.
Доставка живёт отдельно от заказа
Стоимость и статус доставки не связаны с заказом, поэтому покупатель узнаёт о движении посылки только из письма службы.
Обмен между витриной и учётной системой
Обмен не симметричен: товары, цены и остатки идут из учёта на витрину, а заказы, оплаты и резервы — обратно. Источник правды для каждой сущности один.
Сущность
Направление
Что важно учесть
Номенклатура и характеристики
Учёт → магазин
Товары создаются в учётной системе и попадают на витрину вместе с характеристиками. Сопоставление идёт по артикулу, поэтому дубли не появляются при повторной выгрузке.
Цены и скидки
Учёт → магазин
Прайс ведётся в одном месте. Правила скидок магазина применяются поверх базовой цены, а ручные правки в админке попадают в отчёт о расхождениях.
Остатки и резервы
Склад ↔ магазин
Остаток приходит со склада, резерв уходит обратно при оформлении заказа. Резерв снимается при отгрузке или по сроку — иначе остаток «залипает».
Заказы
Магазин → учёт
Заказ создаётся в учёте с составом, адресом и способом получения. Повторная отправка того же заказа не создаёт второй документ.
Оплаты
Платёжный провайдер → заказ
Подтверждение оплаты меняет статус заказа и уходит в учёт. Возвраты и частичные отмены отражаются теми же документами.
Отгрузка и статусы доставки
Учёт → магазин и покупатель
Сборка и передача в доставку меняют состояние заказа, статус движения приходит от службы и уведомляет покупателя.
Разделение обязанностей фиксируется до разработки: витрина отвечает за показ и оформление, учёт — за данные и документы.
Что не зависит от платформы
Платформа определяет, как именно мы заберём и отдадим данные — через API, модуль обмена или файлы. Состав сущностей от неё не меняется.
Каталог и номенклатура
Неважно, на чём сделан магазин: товары, характеристики и категории должны совпадать с учётом. Это первое, что связывается, — иначе остальное теряет смысл.
Остатки и резервы
Остаток должен приходить со склада, а резерв — уходить обратно. Логика одинакова и для готовой платформы, и для самописной витрины.
Заказы и оплаты
Заказ создаётся один раз и живёт в учёте; оплата лишь меняет его состояние. Платформа магазина на это не влияет.
Доставка
Стоимость и статусы доставки связаны с заказом. Магазин показывает результат, но расчёт и трекинг ведёт служба доставки.
Резервы и отгрузка
Резерв — это место, где чаще всего теряются продажи: товар зарезервирован, но не отгружен, и витрина считает его проданным, а склад — лежащим.
- Резерв создаётся при оформлении и виден складу как обязательство отгрузить
- Неоплаченный резерв снимается по сроку, товар возвращается в свободный остаток
- Отгрузка закрывает резерв и создаёт документ реализации в учёте
- Отмена заказа снимает резерв без ручного вмешательства менеджера
- Остаток на витрине показывается за вычетом активных резервов
- Журнал по заказу: кто, когда и на каком основании изменил резерв
B2B-сценарии на витрине
Оптовый клиент покупает иначе, чем розничный: у него свои цены, условия оплаты и адреса доставки. Это тоже часть связки магазина с учётом.
Индивидуальные цены
Для B2B-клиента цена считается по его условиям, а не по розничному прайсу. Условия ведутся в учёте и попадают на витрину после авторизации клиента.
Условия оплаты
Оплата по счёту, частичная предоплата или отсрочка — сценарий задаётся для клиента. Заказ отражается в учёте так же, как обычный, и попадает в те же отчёты.
Несколько адресов доставки
Заказ может состоять из нескольких отгрузок по разным адресам. Это разбивается на отдельные задания складу и накладные.
Документы для клиента
Счёт, накладная и закрывающие документы формируются из заказа, а не готовятся отдельно в бухгалтерии.
Как мы связываем магазин с учётом
Сначала фиксируем, какие данные и куда ходят и что считается источником правды, затем описываем контракт и делаем обмен на части ассортимента. Полная выгрузка включается после проверки.
-
01
Аудит и схема
Разбираем системы, сущности и потоки. Фиксируем, что считается источником правды и где сейчас расходятся данные.
-
02
Контракт обмена
Описываем поля, форматы, частоту и правила сопоставления справочников. Согласуем до начала разработки.
-
03
Прототип
Проверяем обмен на реальных данных в ограниченном объёме: несколько десятков записей в обе стороны.
-
04
Внедрение
Включаем полный обмен с очередью, повторными попытками, журналом и защитой от дублей.
-
05
Эксплуатация
Мониторинг, сверка расхождений, обновление коннекторов при изменениях API на стороне сервиса.
Что делает витрину предсказуемой
Магазин работает круглосуточно, а учётная система может быть недоступна при обновлении. Витрина не должна показывать пустой каталог из-за этого.
Идемпотентность
Повторная доставка одного и того же события не создаёт вторую сделку, второй заказ или второй платёж.
Очередь и повторные попытки
Если внешняя система недоступна, операция ждёт и повторяется по расписанию, а не теряется.
Журнал обмена
Видно, что и когда ушло, что вернулось и что не прошло. Неудачную операцию можно повторить вручную.
Лимиты провайдера
Учитываем ограничения по частоте запросов, чтобы не получить блокировку со стороны сервиса.
Сверка расхождений
Регулярная сверка ключевых сущностей между системами: расхождение видно в отчёте, а не в конце квартала.
Мониторинг и оповещения
При остановке обмена приходит уведомление ответственным, а не выясняется из жалобы клиента.
Ещё в категории «Маркетплейсы и e-commerce»
Часто эти интеграции внедряются вместе — например, CRM и телефония, или магазин и маркетплейсы.
Wildberries
Остатки и цены совпадают с вашим складом
Интеграция с Wildberries: выгрузка карточек, синхронизация остатков и цен, сбор заказов и статусов поставок.
ПодробнееOzon
Заказы площадки попадают в учёт сразу
Интеграция с Ozon: товары, цены, остатки, заказы, отгрузки и отчёты по реализации.
ПодробнееЯндекс Маркет
Каталог и заказы в вашем контуре
Интеграция с Яндекс Маркет: каталог, цены, остатки, заказы и работа со схемами доставки.
ПодробнееAliExpress
Экспортные продажи без двойного учёта
Интеграция с AliExpress: выгрузка товаров, обработка заказов, логистика и статусы отправлений.
ПодробнееМультимаркетплейс
Один склад — несколько площадок
Интеграция с маркетплейсами: единая выгрузка товаров и остатков, сбор заказов с нескольких площадок.
ПодробнееВсе категории интеграций
Обмен редко ограничивается одной категорией: магазин обычно связан и со складом, и с платежами, и с маркетплейсами.
Частые вопросы об интеграции магазина
Если вашего вопроса здесь нет — задайте его в форме ниже.
Магазин у нас самописный — интеграция возможна?
Да. Если у магазина есть API или доступ к его базе данных, обмен строится так же, как для готовой платформы: описывается контракт, сопоставляются справочники, настраиваются очереди и журнал. Для самописного магазина обычно нужна небольшая доработка на его стороне — точку обмена мы согласуем заранее.
Придётся ли менять платформу магазина?
В большинстве случаев нет. Обмен строится поверх того, что уже работает: сайт остаётся витриной, а учёт — источником данных по товарам, ценам и остаткам. Смена платформы оправдана, только если она технически не позволяет отдавать и принимать данные.
Как работает резерв товара при оформлении заказа?
Резерв создаётся в момент оформления и снимается при отгрузке или по истечении срока резерва. Если резерв не подтверждён складом, заказ не уходит в сборку, а попадает менеджеру — так клиент не ждёт товар, которого нет.
Что происходит с ценами и скидками при обмене?
Цена приходит из учётной системы, скидки и акции применяются по правилам магазина. Если менеджер меняет цену прямо в админке магазина, расхождение фиксируется в отчёте: так прайс не расползается по двум системам.
Как в заказе отражаются оплата и доставка?
Оплата меняет статус заказа после подтверждения от платёжного провайдера, доставка добавляет стоимость и статусы движения. И то, и другое попадает в учёт вместе с заказом, поэтому сверка с бухгалтерией не требует выгрузок из нескольких кабинетов.
Расскажите о своём магазине и учёте
Напишите, на какой платформе работает магазин, какая учётная система используется и как сейчас передаются заказы. Предложим схему обмена и порядок работ.
Бесплатный аудит
Разбор технической части сайта: скорость, SSR, фильтры
Аудит текущей рекламы: где сливается бюджет
Анализ конкурентов в вашей нише
Прогноз CPL, ROAS и окупаемости
План действий на первый месяц
Получите бесплатный аудит интернет-магазина
За 3 рабочих дня разберём: где вы теряете заявки, какие каналы недооценены, и что даст рост в первые 30 дней.
За этот месяц
42 компании получили аудит
30 мин
реакция
3 дня
аудит
100%
доступ к кабинетам
Заявка на аудит
Без обязательств. С конкретными цифрами.