Интеграция с 1С: обмен заказами, остатками, ценами и клиентами

Интеграция с 1С нужна, когда товары, цены и заказы ведутся в учётной системе, а продажи идут через сайт, бота или Mini App. Разбираем, какие данные обычно передают между системами, какими способами это делают, как часто синхронизировать, кто отвечает за сторону 1С и почему отлаживать обмен на рабочей базе — плохая идея.

Что обычно синхронизируют с 1С

В 1С живёт учёт: номенклатура, склады, цены, контрагенты, документы. Сайт или бот — витрина и канал продаж. Задача интеграции — чтобы витрина показывала актуальные данные, а заказы попадали в учёт без ручного переноса.

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

Три подхода к обмену

Типовой обмен с сайтом

Во многих типовых конфигурациях 1С есть встроенный обмен с сайтами в формате CommerceML: 1С выгружает каталог, цены и остатки в XML-файлы и забирает заказы. Плюс — на стороне 1С почти ничего не нужно программировать. Минус — формат рассчитан на классический интернет-магазин, и всё, что выходит за его рамки (сложные скидки, комплекты, индивидуальные условия), приходится достраивать.

HTTP-сервисы 1С

В 1С можно опубликовать собственные HTTP-сервисы — по сути, API самой учётной системы. Сайт запрашивает остаток конкретного товара или отправляет заказ, и 1С отвечает сразу. Подходит, когда нужна точность в реальном времени и нестандартная логика. Требует программиста 1С и публикации базы через веб-сервер, а значит — отдельного внимания к безопасности.

Промежуточная база или очередь

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

Как часто синхронизировать

Частота — компромисс между актуальностью и нагрузкой на 1С. Выгружать весь каталог каждые пять минут бессмысленно, а обновлять остатки раз в сутки — опасно: покупатели будут заказывать то, что уже продано.

• Остатки — часто и только изменения, а не вся база. Для дефицитных товаров можно дополнительно проверять наличие в момент оформления заказа.
• Цены — по факту изменения или по расписанию, например ночью, если они меняются редко.
• Каталог — когда добавили товары или поправили характеристики; полная выгрузка — по расписанию в нерабочее время.
• Заказы — сразу после оформления, через очередь, чтобы сбой обмена не мешал клиенту купить.
• Статусы — по событию в 1С или частым опросом, если события настроить нельзя.

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

Конфликты данных и источник правды

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

• товары, цены, остатки — главная 1С, сайт только читает;
• описания, фото, тексты для страниц — главный сайт, в 1С их не тянем;
• заказ после передачи в 1С меняется только там, сайт получает статус;
• контактные данные клиента — по договорённости, чаще главной остаётся 1С.

Второй источник проблем — идентификаторы. Связывать товары по названию или артикулу ненадёжно: названия правят, артикулы дублируются. Надёжнее хранить на сайте уникальный идентификатор объекта из 1С и сопоставлять по нему. С клиентами так же: телефон и email помогают найти контрагента в первый раз, но дальше опираться лучше на ID.

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

Кто делает сторону 1С

Интеграция — работа двух сторон. Мы отвечаем за сайт, бота, API и прослойку, а доработки внутри 1С обычно делает программист 1С: штатный, на аутсорсе или от партнёра, который обслуживает вашу базу. Иногда для типового обмена хватает настроек, и программист не нужен вовсе.

Чтобы работа не превратилась в перекладывание ответственности, до старта фиксируют:

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

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

Тестирование на копии базы

Обмен не отлаживают на рабочей базе. Одна ошибка в выгрузке заказов — и в учёте появляются сотни тестовых документов, которые бухгалтер потом удаляет руками. Поэтому для разработки делают копию базы 1С и тестовую версию сайта или бота. Что проверяем перед запуском:

1. Полная выгрузка каталога: все товары на месте, характеристики не перепутаны.
2. Изменение цены и остатка в 1С доходит до сайта за ожидаемое время.
3. Заказ с сайта создаёт документ в 1С с правильным контрагентом, товарами и суммой.
4. Повторная отправка того же заказа не создаёт дубль.
5. Заказ товара, который уже закончился, обрабатывается по согласованному правилу.
6. Смена статуса в 1С приходит на сайт и в бот.
7. Пока 1С недоступна, заказы копятся в очереди и уходят, когда она возвращается.

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

Сроки, стоимость и подготовка

Цена интеграции зависит от подхода, объёма данных, состояния конфигурации 1С и числа подключаемых каналов. Настройка типового обмена для нового магазина и двусторонняя синхронизация с персональными ценами и статусами в мессенджере — задачи разного масштаба. Если вы продаёте через Telegram, посмотрите статью про интернет-магазин в Mini App: обмен с 1С для него строится по тем же принципам.

Сократить сроки помогают подготовленные данные: понятная структура номенклатуры, заполненные артикулы, отсутствие дублей контрагентов. Если в базе беспорядок, интеграция его не исправит, а разнесёт по всем каналам. Требования к обмену стоит заранее включить в техническое задание, а если у вас есть ещё и CRM — продумать обе связки вместе, как описано в статье про интеграцию с amoCRM и Битрикс24. Бриф и предварительную оценку мы делаем бесплатно.

Частые вопросы

Обсудим проект

Нужна похожая разработка?

Расскажите о задаче — уточним детали, предложим формат запуска и подготовим предварительную оценку. Это бесплатно.

Ваше имя Способ связиTelegramVKMAXТелефонПочта

Контакт

Отправить заявкуНаписать напрямую

Опубликовано 12 октября 2026 г. · Обновлено 12 октября 2026 г.