Интеграция подарочных сертификатов из УТ 11.5 в формате json в Bitrix

API Проект «Интеграция данных подарочных сертификатов 1С — Битрикс»: обмен запущен и тестируется.

Связь учетной системы 1С (Управление торговлей 11) с сайтом на Битрикс через HTTP-сервис loyalvauchers. Теперь подарочные сертификаты — их номинал, статус, штрихкод и остаток — синхронно живут и в 1С, и на сайте.

Модули работы с данными:

1. запрос списка сертификатов со статусами (не активирован, активирован, частично погашен, полностью погашен, возвращён, аннулирован) и актуальным балансом;

2. продажа и активация сертификата по штрихкоду;

3. резервирование и снятие с резерва;

4. оплата заказов сертификатом с сайта — в 1С это отражается типовым механизмом взаимозачёта задолженности;

5. проверка полного цикла на сценариях: продажа сертификата → частичная оплата заказа → контроль остатка в «Ведомости расчётов с клиентами».

1. Запрос списка сертификатов

• Функция: выгрузка списка сертификатов со статусом не «Аннулирован» и не «ПолностьюПогашен» — для витрины и проверки доступных сертификатов на сайте.
• Метод и адрес: GET /loyalvauchers/vouchers/
• Входящие параметры: нет — фильтрация по статусам выполняется на стороне 1С.
• Возвращаемые данные: массив сертификатов с полями ID, KODS, NAME, BARCODE, MAGNATEDID, NOMINAL, InOrder (Да/Нет — в резерве), IDSTATUS (0–4), STATUS, BALANCE (остаток на момент запроса).
• Статусы: 1 — Не активирован, 2 — Активирован, 3 — Частично погашен, 4 — Полностью погашен.

2. Продажа и активация сертификата по штрихкоду

• Функция: продажа сертификата с сайта — в 1С создаётся документ реализации, сертификат активируется.
• Метод и адрес: GET /loyalvauchers/sell/{barcode}
• Входящие параметры: BARCODECODE — штрихкод карты (передаётся в пути запроса, например /sell/000003).
• Возвращаемые данные: данные сертификата (ID, KODS, NAME, BARCODECODE, NOMINAL, IDSTATUS, BALANCE) и поле Komment — комментарий операции, например «Продажа сертификата с сайта 07.07.2026 Сертификат 3 Сумма: 5 000».

3. Резервирование и снятие с резерва

• Функция: постановка сертификата в резерв при добавлении в заказ на сайте и освобождение при отмене/оплате. Признак резерва — реквизит InOrder.
• Метод и адрес: GET /loyalvauchers/inorder/{barcode} — поставить в резерв; GET /loyalvauchers/outorder/{barcode} — снять с резерва.
• Входящие параметры: barcode — штрихкод карты в пути запроса.
• Возвращаемые данные: актуальное состояние сертификата и Komment — «Резервирование с сайта …» или «Снят с резерва с сайта …» с датой и временем.

4. Оплата заказа сертификатом с сайта

• Функция: списание части или всей суммы заказа по сертификату; в 1С формируется типовой документ «Взаимозачёт задолженности» — оплата отражается через аванс по сертификату.
• Метод и адрес: GET /loyalvauchers/pay/{barcode}/{payment}/{orderNum}
• Входящие параметры: barcode — штрихкод сертификата, payment — сумма оплаты, orderNum — номер заказа клиента.
• Возвращаемые данные: состояние сертификата с новым BALANCE и IDSTATUS (при частичной оплате статус меняется на «Частично погашен», при полной — «Полностью погашен»), плюс Komment с деталями операции.

5. Проверка полного цикла

• Функция: не отдельный эндпоинт, а сквозной сценарий проверки на рабочей базе: продажа сертификата номиналом 5 000 → частичная оплата заказа сертификатом (например, на 2 728) → контроль остатка 2 272 в «Ведомости расчётов с клиентами» по объекту расчётов «сертификат» и реквизиту BALANCE.

Также в API есть вспомогательный метод запрос сертификата по штрихкоду — GET /loyalvauchers/voucher/{barcode}: возвращает данные одного сертификата без изменения состояния; на сайте используется перед продажей или оплатой.

Эндпоинты HTTP-сервиса loyalvauchers

Коды статусов IDSTATUS (как их формирует запрос на стороне 1С):

• 0 — нет записи об активации в истории (сертификат ещё не активирован);
• 1 — НеАктивирован (нет остатка в регистре);
• 2 — Активирован (остаток равен номиналу);
• 3 — ЧастичноПогашен (остаток меньше номинала);
• 4 — ПолностьюПогашен (остаток равен нулю).

Признак резерва — отдельный реквизит InOrder (Да/Нет), он живёт независимо от статуса.

Разграничение ответственности при повторной оплате — на стороне Битрикса: перед оплатой проверить, что сертификат в резерве → снять с резерва → провести оплату → обработать ошибку повторной операции.