Как правильно настроить обмен между 1С:Управление торговлей 10.3 и 1С-Битрикс: автоматизация, заказы и онлайн-резервирование?

← На главную

Интеграция старых нетиповых конфигураций, таких как 1С:Управление торговлей 10.3, с современными CMS (например, 1С-Битрикс) часто превращается в головную боль для разработчика. Когда стандартные механизмы обмена кажутся сложными или «ломаются» из-за кастомных доработок конфигурации, возникает соблазн создать собственную схему обмена через выгрузку XML-файлов на FTP-сервер и последующий ручной или полуавтоматический импорт скриптами. Однако такой подход порождает множество проблем: задержки в обновлении остатков, отсутствие оперативного резервирования, ручную работу менеджеров и потенциальные ошибки при транзакциях.

В этой статье мы подробно разберем, как уйти от «костыльных» решений с FTP-серверами, правильно настроить автоматический двусторонний обмен, организовать работу с заказами и кассой, а также решить критически важную проблему мгновенного резервирования остатков в режиме реального времени.

Почему ручные скрипты и FTP-обмен — это тупиковый путь?

Рассмотрим стандартную ситуацию: разработчик выгружает файлы offers.xml, import.xml, prices.xml и rests.xml на FTP, а затем запускает скрипт импорта (например, 1c_import_lite.php) на стороне сайта. Проанализируем минусы этой схемы:

Отсутствие оперативности: Данные на сайте всегда будут отставать от реальных остатков в 1С. Если запускать обмен редко — покупатели увидят неактуальные остатки. Если запускать часто — сервер будет испытывать колоссальную нагрузку.
Сложность обратной связи: Передать заказы с сайта обратно в 1С по такой схеме крайне затруднительно. Приходится писать встречные скрипты выгрузки заказов с сайта в XML/JSON и их парсинг в 1С.
Человеческий фактор: Любой сбой в цепочке (недоступность FTP, ошибка выполнения PHP-скрипта на хостинге, ручной пропуск запуска) приводит к рассинхронизации данных.

Выясним причину, почему предыдущие разработчики отказались от готового решения. Чаще всего это связано с тем, что встроенный в старую конфигурацию УТ 10.3 механизм обмена использует устаревший формат CommerceML 2.05, структура которого не совпадает с ожиданиями современного Битрикса. Но это не повод писать велосипеды. Решение лежит в использовании официальных инструментов.

Шаг 1. Переход на официальный модуль обмена от 1С-Битрикс

Вместо встроенного в 1С механизма обмена необходимо использовать официальный бесплатный модуль интеграции, который компания «1С-Битрикс» регулярно обновляет и выпускает в том числе для старых конфигураций, включая УТ 10.3. Этот модуль устанавливается как внешняя обработка или внедряется в саму конфигурацию.

Переход на официальный модуль решает следующие задачи:

Поддержка современных стандартов CommerceML 2.07 / 2.10.
Корректное разделение данных по файлам остатков, цен и описаний товаров.
Возможность тонкой настройки фильтрации выгружаемых данных (какие склады, типы цен, группы номенклатуры выгружать).
Автоматическое создание и обновление Highload-блоков на стороне Битрикса для хранения свойств товаров.

Чтобы запустить автоматизацию, достаточно настроить регламентное задание в 1С, которое будет вызывать обработку обмена по расписанию (например, каждые 10–15 минут). Обмен при этом происходит не через FTP, а напрямую по протоколу HTTP/HTTPS: 1С обращается к скрипту /bitrix/admin/1c_exchange.php на сайте, передавая данные пакетами.

Шаг 2. Настройка двустороннего обмена (заказы и контрагенты)

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

Покупатель оформляет заказ на сайте. Сайт генерирует уникальный идентификатор заказа (GUID).
При очередном сеансе связи 1С запрашивает с сайта новые заказы.
В 1С автоматически создается документ ЗаказПокупателя. Если контрагент новый, система создает его карточку на основе данных из XML (ФИО, телефон, email, ИНН).
Если в 1С менеджер меняет статус заказа (например, «Согласован», «Отгружен»), при следующем обмене статус обновляется и на сайте, о чем покупатель получает уведомление.

Если конфигурация УТ 10.3 сильно переписана и типовой модуль Битрикс интегрировать сложно, альтернативным решением является написание собственного обмена через REST API или HTTP-сервисы. В этом случае 1С отправляет JSON-пакеты напрямую на веб-хуки сайта при проведении документов.

Шаг 3. Интеграция с облачной кассой и оформление розничных продаж

В условиях задачи упоминается облачная касса Терминал-ФА, которая автоматически фискализирует чеки при оплате на сайте. Как правильно отразить эти операции в 1С УТ 10.3, чтобы не возникло двоения выручки и остатки списывались корректно? Разберем по шагам рабочую схему:

Важное правило: Физически пробивать чек на кассовом аппарате в магазине для интернет-заказов, оплаченных на сайте, НЕЛЬЗЯ. Облачная касса «Терминал-ФА» уже отправила электронный чек в ОФД и налоговую. Повторное пробитие приведет к двоению налогооблагаемой базы.

Для корректного учета в 1С мы должны отразить безналичную оплату и списание товара:

При получении заказа с сайта, который уже оплачен эквайрингом, в 1С создается документ ЗаказПокупателя.
На основании заказа создается документ ОплатаОтПокупателяПлатежнойКартой (эквайринговая операция). Этот документ фиксирует поступление денежных средств на расчетный счет (за вычетом комиссии банка-эквайера) и закрывает задолженность покупателя, не задействуя физическую кассу магазина.
Для списания остатков со склада на основании заказа создается документ РеализацияТоваровУслуг.
В конце дня для сверки данных можно использовать API облачной кассы «Терминал-ФА». Напишем небольшую обработку в 1С, которая будет запрашивать реестр пробитых за день чеков из облака и сверять их с созданными в 1С документами оплаты, исключая расхождения.

Шаг 4. Решение проблемы Race Condition (онлайн-резервирование)

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

Обычный периодический обмен (даже раз в 5 минут) не решает эту проблему, так как существует временной лаг. Единственный надежный способ избежать этого — внедрение синхронного онлайн-резервирования через Web-сервисы.

Схема работы выглядит следующим образом:

На стороне 1С УТ 10.3 создается и публикуется на веб-сервере (IIS или Apache) Web-сервис или HTTP-сервис.
В момент, когда покупатель на сайте нажимает кнопку «Оформить заказ» (или переходит к оплате), сайт не просто создает заказ у себя, а делает мгновенный POST-запрос к веб-сервису 1С.
1С принимает запрос, в режиме реального времени проверяет свободный остаток товара на складе.
Если товар есть, 1С тут же программно создает документ ЗаказПокупателя и ставит товар в резерв (например, на 30 минут — время, дающееся покупателю на завершение оплаты).
1С возвращает сайту ответ: «Успешно зарезервировано». Сайт разрешает оплату. Если оплата не поступила в течение 30 минут, сайт отправляет повторный запрос на отмену резерва, и 1С снимает бронь, делая товар снова доступным для продажи.

Посмотрим на пример реализации метода HTTP-сервиса в 1С для проверки и резервирования номенклатуры:


Функция РезервироватьТоварНаСкладе(КодТовара, Количество, НомерЗаказаСайта) Экспорт
    
    // Поиск номенклатуры по коду
    СсылкаНоменклатуры = Справочники.Номенклатура.НайтиПоКоду(КодТовара);
    Если СсылкаНоменклатуры.Пустая() Тогда
        Возврат "Ошибка: Товар не найден";
    КонецЕсли;
    
    // Проверка текущего свободного остатка (с учетом резервов)
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |	ТоварыНаСкладахОстатки.ВНаличииОстаток - ТоварыВРезервеНаСкладахОстатки.КоличествоОстаток КАК СвободныйОстаток
        |ИЗ
        |	РегистрНакопления.ТоварыНаСкладах.Остатки(, Номенклатура = &Номенклатура) КАК ТоварыНаСкладахОстатки
        |	ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыВРезервеНаСкладах.Остатки(, Номенклатура = &Номенклатура) КАК ТоварыВРезервеНаСкладахОстатки
        |	ПО ТоварыНаСкладахОстатки.Номенклатура = ТоварыВРезервеНаСкладахОстатки.Номенклатура";
    
    Запрос.УстановитьПараметр("Номенклатура", СсылкаНоменклатуры);
    РезультатЗапроса = Запрос.Выполнить();
    
    СвободныйОстаток = 0;
    Если Не РезультатЗапроса.Пустой() Тогда
        Выборка = РезультатЗапроса.Выбрать();
        Выборка.Следующий();
        СвободныйОстаток = Выборка.СвободныйОстаток;
    КонецЕсли;
    
    Если СвободныйОстаток < Количество Тогда
        Возврат "Ошибка: Недостаточно свободного остатка. Доступно: " + Строка(СвободныйОстаток);
    КонецЕсли;
    
    // Создание Заказа покупателя для резервирования товара
    НовыйЗаказ = Документы.ЗаказПокупателя.СоздатьДокумент();
    НовыйЗаказ.Дата = ТекущаяДата();
    НовыйЗаказ.Организация = Справочники.Организации.НайтиПоРеквизиту("ИНН", "7700000000"); // Пример заполнения
    НовыйЗаказ.Контрагент = Справочники.Контрагенты.НайтиПоНаименованию("Розничный покупатель (сайт)");
    НовыйЗаказ.ДоговорКонтрагента = НовыйЗаказ.Контрагент.ОсновнойДоговорКонтрагента;
    НовыйЗаказ.Комментарий = "Авторезерв с сайта. Заказ № " + НомерЗаказаСайта;
    
    // Заполнение табличной части
    НоваяСтрока = НовыйЗаказ.Товары.Добавить();
    НоваяСтрока.Номенклатура = СсылкаНоменклатуры;
    НоваяСтрока.Количество = Количество;
    НоваяСтрока.Размещение = Справочники.Склады.НайтиПоНаименованию("Основной склад"); // Склад резервирования
    
    Попытка
        НовыйЗаказ.Записать(РежимЗаписиДокумента.Проведение);
        Возврат "Успешно зарезервировано. Номер документа 1С: " + НовыйЗаказ.Номер;
    Исключение
        Возврат "Ошибка при проведении документа: " + ОписаниеОшибки();
    КонецПопытки;

КонецФункции

Такой подход полностью исключает человеческий фактор (не нужно ждать, пока менеджер обработает заказ) и гарантирует абсолютную точность остатков в розничной точке и на интернет-витрине в режиме 24/7.