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