Интеграция приложения с 1С: как избежать расхождений цен, остатков и заказов
Как распределить источники истины, настроить резервирование товара и не потерять заказы на повторных попытках
Приложение показывает одну цену, 1С хранит другую, а заказ из приложения не доходит до склада. Разберём, как распределить источники истины между системами, где поставить резервирование товара и по каким метрикам видно, что обмен данными сломался.
Что такое интеграция приложения с 1С
Интеграция приложения с 1С — это регламент обмена данными: что передаётся, в какую сторону, с каким интервалом и что происходит при сбое. В такой схеме «1С:Предприятие» работает как бэк-офис — ведёт номенклатуру, цены, склад и документы, управляет исполнением заказов, — а приложение как витрина и канал приёма заказов.
Для бизнеса это договорённость о том, какая система отвечает за каждое число на экране покупателя и через сколько времени изменение в учёте до него доезжает. Без неё расхождение обнаруживает покупатель, а не сотрудник.
Состав обмена в обе стороны
Обмен интернет-магазина делится на четыре потока:
- Каталог — номенклатура, характеристики, единицы измерения.
- Цены — типы цен, цены по соглашениям, скидки.
- Остатки — количество по складам, сводно и с разбивкой.
- Заказы — передача в учётную систему и обратная синхронизация статусов.
Инициатор обмена
В штатном протоколе обмена с сайтом обмен инициирует сама «1С:Предприятие» — и при выгрузке каталога, и при обмене заказами. Приложение не может по своей инициативе запросить свежую цену: оно работает с тем, что учётная система отдала в последний раз. Здесь и начинаются расхождения — их источник в устройстве обмена.
Последствия расхождений для продаж и склада
У каждого расхождения есть операционное продолжение, которое доходит до покупателя и склада.
- Цена ниже учётной. Отгрузка с потерей в наценке либо отмена с объяснением покупателю.
- Цена выше учётной. Одна сумма в приложении, другая в счёте — повод для претензии.
- Остаток завышен. Заказ принят, товара нет: сборщик возвращает позицию, доставка сдвигается.
- Остаток занижен. Товар на складе есть, но помечен недоступным, и продажа не происходит.
- Заказ не доехал. Документа нет, сборка не началась, покупатель ждёт со статусом «принят».
- Заказ продублировался. Два документа, два резерва и ручная отмена одного из них.
Источник истины для каждого типа данных
Основа интеграции — распределение владения: у каждого типа данных одна система-владелец, остальные только читают, а запись идёт через владельца.
Распределение владения данными
| Данные | Источник истины | Как попадает в приложение |
|---|---|---|
| Номенклатура и характеристики | Учётная система | Пакетно по расписанию |
| Цены и типы цен | Учётная система | Пакетно плюс пересчёт на оформлении |
| Остатки по складам | Учёт или складская система | Пакетно плюс запрос на карточке |
| Доступно к продаже | Бэкенд приложения (расчёт) | Считается на каждый запрос |
| Заказ-документ и его статус | Учётная система | По событию изменения статуса |
| Корзина, избранное, адреса, токены | Бэкенд приложения | Без обмена с учётом |
| Персональные скидки и бонусы | Система лояльности или учёт | Запрос в момент оформления |
Правило одного владельца
Если у данных два владельца, расхождение становится вопросом времени. Пример — статус заказа: приложение ставит «собран» по данным курьерского сервиса, а учётная система держит «в сборке», потому что сборщик не закрыл документ. Корректное распределение одно: статус пишет только учётная система, остальные передают ей события.
Данные с разделённым владением
Доступное к продаже — производная величина: остаток минус резервы минус запас по категории. Исходные числа принадлежат учётной системе, а расчёт живёт в бэкенде, потому что меняется чаще правил учёта. Опасность — в двойном вычитании: если резерв уменьшает остаток и в учёте, и в расчёте бэкенда, товар исчезает с витрины дважды.
Схема обмена: четыре слоя между 1С и приложением
Схема раскладывается на четыре слоя:
- Учётный слой. «1С:Предприятие»: номенклатура, цены, склад, документы заказов.
- Слой обмена. Очередь и адаптер формата: раскладывает пакеты на сообщения по позициям, передаёт заказы обратно, ведёт журнал.
- Бэкенд приложения. Витринный каталог, расчёт доступного к продаже, приём заказов по ключу операции.
- Клиент. Приложение на устройстве: кэш каталога, корзина, оформление.
Ограничения прямого обращения в 1С
Платформа «1С:Предприятие» умеет отдавать данные наружу: она автоматически формирует REST-интерфейс для всего прикладного решения, а разработчик при необходимости пишет собственные HTTP-сервисы. По документации платформы они дают меньший объём данных и меньшую нагрузку, чем web-сервисы на SOAP, что особенно важно для мобильных приложений.
Тем не менее прямое обращение оставляет три слабых места:
- Конкуренция за базу. Выборки каталога идут в рабочую базу и конкурируют с работой сотрудников.
- Остановки на обслуживании. Обновление конфигурации и закрытие периода останавливают витрину вместе с учётной системой.
- Неудобный клиенту формат. Приложению нужен каталог с фильтрами и поиском, а структуры справочников и регистров к этому не приспособлены.
Сравнение механизмов обмена
Механизмы обмена с «1С:Предприятием» и их ограничения
| Механизм | Для чего подходит | Ограничение |
|---|---|---|
| Протокол обмена с сайтом (CommerceML 2) | Каталог, цены, остатки, заказы и их статусы | Пакетный обмен, инициирует его учётная система |
| Формат EnterpriseData | Документы и справочники внутри компании | Рассчитан на обмен внутри компании, пакетный режим |
| Автоматический REST-интерфейс | Чтение и запись без доработки конфигурации | Нагрузка идёт в рабочую базу учётной системы |
| Собственные HTTP-сервисы | Операции под сценарий приложения | Требуют разработки на стороне учётной системы |
| Web-сервисы на SOAP | Операции со строгим контрактом | Выше объём данных и нагрузка, чем у HTTP-сервисов |
Обмен ценами и остатками: три режима обновления
Один интервал обновления на весь каталог не работает: описание товара переживает сутки без изменений, а остаток штучной позиции устаревает за минуты. Режим выбирают под тип данных и скорость движения.
Режимы обновления данных
| Режим | Где уместен | Чем ограничен |
|---|---|---|
| Пакетное обновление по расписанию | Каталог, описания, базовые цены | Данные устаревают на интервал обмена |
| Обновление по запросу | Карточка товара, корзина | Нагружает слой обмена, нужен кэш с коротким сроком жизни |
| Блокирующая проверка | Оформление заказа и оплата | Добавляет ожидание, нужно правило поведения при сбое |
Цена фиксируется в момент оформления
Перед созданием заказа бэкенд пересчитывает корзину и сравнивает итог с ценой на экране покупателя. При расхождении корректное поведение — показать новую цену и запросить подтверждение, а не пересчитать сумму молча. В заказ записывают цену, тип цены и момент расчёта: претензию тогда разбирают по журналу.
Остаток и запас по категории
Интервал обмена задаёт окно устаревания, и свести его к нулю не получится ни на одном механизме. Расхождение в одну-две единицы закрывают запасом: для быстро уходящих позиций витрина показывает признак малого остатка вместо числа, для штучных на оформлении включается блокирующая проверка. Запас задают по категориям.
Склады и регионы
Типичный сценарий для сети со складами в нескольких регионах: остаток приходит отдельной строкой по каждому складу, а приложение показывает доступность для выбранного города. Сводный остаток на всю сеть здесь ломает продажу — покупатель увидит товар другого региона, заказ примут, а собрать его на месте не получится. Поэтому доступность считают по складам, привязанным к адресу доставки или к точке выдачи; протокол обмена с сайтом передаёт остатки и сводно, и с разбивкой.
Резервирование товара и защита от продажи сверх остатка
Резервирование делится на два механизма с разным сроком жизни, и путаница между ними — частая причина расхождений в остатках.
Мягкий резерв на время оформления
Мягкий резерв живёт в бэкенде приложения столько, сколько отведено на оформление и оплату. Он уменьшает доступное к продаже, но не создаёт документов в учётной системе. Заказ не оплачен — резерв снимается по таймеру, товар возвращается на витрину.
Резерв в учётной системе
После подтверждения заказа резерв переносится в учётную систему документом: там он привязан к складу и попадает в отчёты о доступности. Живёт такой резерв до отгрузки или отмены заказа и управляется правилами учёта, а не таймером приложения.
Двойной учёт на переходе между резервами
Переход между резервами — самое узкое место схемы. Если мягкий резерв не снят в момент появления документа, позиция вычитается из доступного к продаже дважды, и товар пропадает с витрины при полном складе. Снятие резерва и появление документа связывают одним идентификатором заказа и обрабатывают как одну операцию: либо оба события произошли, либо ни одного.
Поведение при недоступности учётной системы
Если учётная система недоступна в момент подтверждения, заказ всё равно принимается: сохраняется в бэкенде, получает номер и встаёт в очередь, а мягкий резерв продлевается до подтверждения склада. Покупатель видит статус ожидания вместо ошибки.
Идемпотентность заказа: один заказ при любом числе повторов
Идемпотентность — свойство операции: повторное обращение с теми же данными даёт тот же результат и не создаёт второй заказ. Повторы в мобильном канале неизбежны и приходят из трёх источников:
- Покупатель. Кнопка «Оформить» нажата дважды — ответ пришёл не мгновенно.
- Приложение. Ответ потерян по таймауту, запрос отправлен заново.
- Очередь обмена. Доставка «не менее одного раза» допускает повторное сообщение.
Устройство ключа операции
Приложение формирует уникальный ключ операции при первом нажатии кнопки оформления и передаёт его в заголовке запроса; при повторе ключ тот же. Бэкенд хранит ключ с результатом и на повторное обращение возвращает тот же ответ и тот же номер заказа. Подход описан в черновике стандарта IETF для заголовка Idempotency-Key: на 7 октября 2026 года это Internet-Draft редакции 07.
В учётной системе действует зеркальное правило: перед созданием документа заказ ищут по внешнему идентификатору. Нашёлся — обновляют, не нашёлся — создают. Без проверки повторная доставка сообщения даёт второй документ со своим резервом.
Границы одной операции
Ключ привязывают не только к покупателю, но и к составу корзины. Изменился состав — это новая операция и новый ключ, иначе повтор вернёт прежний заказ, и покупатель получит не то, что заказал. Срок жизни ключа ограничивают периодом возможных повторов.
Повторные попытки, очереди и мониторинг обмена
Обмен между системами ломается регулярно, поэтому проектировать нужно поведение после сбоя. Политику повторов описывают по классам ошибок: единое правило на все случаи либо не восстанавливает передачу, либо нагружает учёт в худший момент.
Классы ошибок и политика повторов
Повторные попытки по классам ошибок
| Что произошло | Повторять | Как обрабатывается |
|---|---|---|
| Сеть недоступна, таймаут, ошибка сервера | Да | Повтор с увеличивающейся паузой и случайной добавкой, с лимитом попыток |
| Учётная система на обслуживании | Да | Пауза до конца регламентных работ, сообщения ждут в очереди |
| Ошибка данных: нет номенклатуры или склада | Нет | Уходит в очередь разбора, ответственный получает уведомление |
| Отказ по правилу учёта: нет остатка | Нет | Решение возвращается покупателю как статус заказа |
В книге Google о надёжности сервисов сказано прямо: повторы планируют с экспоненциальной задержкой и случайной составляющей, а число повторов на запрос ограничивают — иначе клиенты синхронизируются и бьют по серверу одной волной. Для учётной системы это чувствительно особенно: она обслуживает ещё и сотрудников.
Очередь и порядок сообщений
Сообщения по одной номенклатурной позиции обрабатывают в порядке появления, иначе старое значение остатка перезапишет новое. Порядок обеспечивают двумя приёмами сразу: сообщения по одной позиции идут в один обработчик, а в каждом передаётся момент изменения на стороне источника — более старое обработчик отбрасывает.
Очередь разбора
Сообщения, не обработанные после всех повторов, уходят в отдельную очередь разбора. Без неё ошибочное сообщение либо блокирует обработку остальных, либо теряется без следа. У очереди должен быть назначенный читатель — сотрудник, разбирающий её по регламенту.
Метрики, по которым видно расхождение
Метрики обмена и сигналы
| Метрика | Что показывает | Сигнал к вмешательству |
|---|---|---|
| Число необработанных сообщений | Обмен не успевает за изменениями | Рост несколько интервалов обмена подряд |
| Возраст самого старого сообщения | Насколько устарели данные витрины | Превышение согласованного окна устаревания |
| Число сообщений в очереди разбора | Ошибки данных и правил | Любое ненулевое значение |
| Заказы без документа в учёте | Заказы теряются по пути | Больше нуля спустя интервал обмена |
| Расхождения цены по суточной сверке | Витрина разошлась с учётом | Рост от сверки к сверке |
Регулярная сверка данных
Очередь показывает только то, что через неё прошло. Поэтому поверх мониторинга ставят суточную сверку: полная выгрузка цен и остатков сравнивается с витриной, а расхождения уходят отчётом ответственному. Сверка ловит то, что очередь пропускает: потерянные сообщения, ручные правки в учёте и ошибки в правилах соответствия.
Типичные ошибки интеграции
Эти решения выглядят экономией на старте и возвращаются переделкой после запуска:
- Прямое обращение в учётную систему. Витрина останавливается на каждом обновлении конфигурации.
- Один сводный остаток на все склады. Покупатель видит товар другого региона, заказ отменяется на сборке.
- Цена не перепроверяется при оформлении. Расхождение всплывает в счёте, и разбирают его вручную.
- Повторная отправка без ключа операции. Дубли заказов с отдельными резервами.
- Мягкий резерв не снимается при появлении документа. Товар вычитается дважды.
- Статус заказа пишут две системы. Покупатель и кладовщик видят разные статусы одного заказа.
- Обмен работает без журнала. Историю передач восстановить нечем, разбор идёт по переписке.
- Нет очереди разбора и назначенного читателя. Ошибочные сообщения блокируют обработку или теряются молча.
Вопросы подрядчику перед стартом работ
Ответы показывают, спроектирован обмен или будет дописываться по ходу.
- Какая система назначена источником истины по ценам, остаткам и статусам заказа и есть ли таблица владения данными?
- Какой механизм обмена выбран и почему: протокол обмена с сайтом, EnterpriseData, REST-интерфейс или собственные HTTP-сервисы?
- Кто инициирует обмен, с каким интервалом и какое окно устаревания данных считается допустимым?
- Как считается доступное к продаже и что защищает от двойного вычитания резервов?
- Как устроен ключ операции при оформлении заказа, где он хранится и сколько живёт?
- Что происходит с заказом, если учётная система недоступна в момент подтверждения?
- Какие ошибки повторяются автоматически, какие уходят в очередь разбора, кто её читает?
- Какие метрики обмена выводятся на панель и кто получает уведомление при превышении порога?
- Есть ли суточная сверка цен и остатков и в каком виде приходит отчёт о расхождениях?
- Как обмен проверяется до запуска: на каком объёме каталога, числе складов и сценариях оформления?
Итог
Расхождения цен, остатков и заказов вырастают из устройства обмена: из того, какая система владеет данными, как часто они передаются и что происходит при сбое. Оптимальный порядок работ — сначала таблица владения данными, затем слой обмена с очередью, журналом и очередью разбора, и только после этого режимы обновления под разделы каталога.
Такая последовательность закрывает все шесть случаев из начала разбора: дубли снимает ключ операции, продажу сверх остатка — расчёт доступного к продаже, устаревшие цены — пересчёт корзины на оформлении, потерянные заказы — очередь с повторами и суточная сверка. Если интеграция уже работает, начинать выгодно с мониторинга.
Частые вопросы
Можно ли подключить мобильное приложение напрямую к 1С?
Технически можно: платформа «1С:Предприятие» публикует REST-интерфейс и позволяет писать собственные HTTP-сервисы. На практике между приложением и учётной системой ставят бэкенд с подготовленным каталогом. Чтение идёт в рабочую базу, и выборки каталога конкурируют с работой сотрудников, а обновление конфигурации или закрытие периода останавливает витрину вместе с учётной системой. Отдельный слой такие паузы переживает: каталог продолжает отдаваться, заказы ждут в очереди.
Как часто нужно обновлять остатки в мобильном приложении?
Единого интервала на весь каталог не бывает — его выбирают по скорости движения товара. Позиции с большим запасом переживают пакетное обновление по расписанию, а штучный товар требует проверки остатка при открытии карточки и блокирующей проверки на оформлении. Интервал обмена задаёт окно устаревания данных, и свести его к нулю не получится ни на одном механизме. Поэтому вместе с интервалом задают поведение на случай расхождения.
Почему в приложении цена отличается от цены в 1С?
Причин обычно три: цена пришла пакетом по расписанию и уже изменилась в учётной системе; в приложение передан не тот тип цены, например розничная вместо цены по соглашению с покупателем; персональная скидка считается в системе лояльности и не доезжает до витрины. Лечится это не ускорением обмена, а пересчётом корзины перед созданием заказа: бэкенд запрашивает актуальную цену, сравнивает с той, которую видел покупатель, и при расхождении просит подтвердить заказ.
Что делать, если заказ из приложения не попал в 1С?
Заказ не должен зависеть от доступности учётной системы в момент оформления. Корректная схема: бэкенд принимает заказ, сохраняет его у себя, присваивает номер и ставит сообщение в очередь на передачу. До доставки заказ живёт со статусом ожидания подтверждения склада, и покупатель видит этот статус. Если передача не прошла после всех повторов, сообщение уходит в очередь разбора, а ответственный сотрудник получает уведомление.
Какой формат обмена выбрать для интеграции с 1С?
Выбор зависит от того, что передаётся и кто инициирует обмен. Каталог, цены, остатки и заказы закрывает открытый протокол обмена с сайтом на базе стандарта CommerceML 2. Для документов и справочников между системами компании используют формат EnterpriseData. Под конкретный сценарий приложения — проверка остатка по одной позиции, создание заказа по внешнему идентификатору — пишут собственные HTTP-сервисы. Автоматический REST-интерфейс подходит для чтения и записи объектов без доработки конфигурации.
Как избежать продажи товара, которого нет на складе?
Нужны три механизма вместе. Доступное к продаже считается как остаток минус резервы, а не берётся из остатка напрямую. На время оформления и оплаты ставится мягкий резерв с ограниченным сроком жизни, после подтверждения он заменяется резервом в учётной системе. Доступность считается по складам, привязанным к адресу доставки или к точке выдачи, а не по сводному остатку сети. Для быстро уходящих позиций вместо точного числа показывают признак малого остатка.
Сколько времени занимает интеграция приложения с 1С?
Срок определяют четыре величины, и оценить их стоит до старта работ. Первая — состояние учётной системы: типовая конфигурация обменивается данными штатными средствами, сильно доработанная требует разбора правил. Вторая — размер и структура каталога: характеристики, комплекты, единицы измерения и типы цен усложняют соответствие данных. Третья — число складов и правила доступности по регионам. Четвёртая — объём собственных HTTP-сервисов на стороне учётной системы.
Источники
Доступность всех адресов проверена 7 октября 2026 года.
- Протокол обмена с сайтом — состав обмена, инициатор, передача остатков с разбивкой по складам.
- Стандарты CommerceML — назначение стандарта.
- Формат EnterpriseData — область применения формата.
- REST-интерфейс «1С:Предприятия» — автоматическая публикация и типичные операции.
- HTTP-сервисы «1С:Предприятия» — сравнение с web-сервисами по объёму данных и нагрузке.
- Обмен данными с интернет-магазином — роль учётной системы как бэк-офиса.
- The Idempotency-Key HTTP Header Field — Internet-Draft IETF, редакция 07.
- Addressing Cascading Failures, Google SRE Book — экспоненциальная задержка со случайной составляющей и лимит повторов.
