Продажа подарочных сертификатов (купонов)

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

Что есть и чего нет в коробке

Многие ожидают найти в админке магазина раздел «Подарочные сертификаты» — по аналогии с CMS вроде Shopify или отдельными плагинами. В 1С-Битрикс такого штатного функционала нет: модуль sale оперирует заказами, скидками и купонами, но не хранит понятия «сертификат с номиналом и остатком».

Поэтому сертификат в Битриксе — это всегда сборка из готовых кубиков:

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

Сертификат как товар каталога

Первый шаг — оформить сам сертификат товаром, который можно купить. Заводите инфоблок каталога (или используете существующий) и создаёте элемент «Подарочный сертификат». Практично сделать торговые предложения (SKU) по номиналам: 1000, 3000, 5000 ₽ — тогда цена сертификата равна его номиналу, а покупатель выбирает вариант в одном элементе.

Ключевые настройки товара:

• цена совпадает с номиналом (если продаёте «за сколько написано»);
• тип товара — обычно услуга или товар без списания со склада: физического остатка у сертификата нет, ограничивать продажи по складу не нужно;
• не облагать доставкой, если сертификат электронный — уместно исключить его из расчёта веса и служб доставки.

Для электронного сертификата логично сразу продумать шаблон письма/PDF с кодом и красивым оформлением. Для пластиковой карты — наоборот, оставить доставку и печать кода на физическом носителе.

Генерация уникального купона на номинал

Смысловое ядро сертификата — уникальный купон, которым получатель расплатится. В штатной механике купон создаётся в правиле корзины (модуль sale, раздел Маркетинг → Правила работы с корзиной) со скидкой типа «фиксированная сумма».

Ручное создание купона на каждую продажу нереалистично, поэтому нужна автоматика. Практичная точка подключения — обработчик события оплаты заказа OnSaleOrderPaid (или статуса) модуля продаж. По событию код:

1. проверяет, что в заказе есть товар-сертификат и определяет номинал по SKU/цене;
2. программно создаёт купон через API — \Bitrix\Sale\Internals\DiscountCouponTable, привязанный к правилу корзины с фиксированной скидкой на нужную сумму;
3. задаёт тип купона одноразовый (TYPE_ONE_ORDER) — сертификат должен «сгорать» после применения;
4. отправляет код покупателю (письмо, PDF, вывод в кабинете).

Списание номинала и проблема остатка

Здесь кроется главное ограничение штатных купонов. Купон правила корзины с фиксированной скидкой применяется целиком: если номинал 5000 ₽, а заказ на 3200 ₽, скидка «схлопнется» до суммы заказа, но оставшиеся 1800 ₽ штатно не сохранятся — одноразовый купон после заказа погашается.

Есть три подхода, выбор зависит от бюджета и ожиданий бизнеса:

Полноценный «кошелёк с остатком» — это уже не купон, а собственная сущность: отдельная таблица (highload-блок или своя таблица через ORM) с полями «код», «номинал», «остаток», «статус», и обработчик, который при оформлении заказа частично списывает баланс и создаёт новый купон на оставшуюся сумму. Это правильная, но заметно более трудоёмкая архитектура.

Учёт, возвраты и бухгалтерия

Продажа сертификата — это не выручка от товара, а по сути предоплата/аванс: деньги получены, обязательство отгрузить исполнится позже, когда сертификатом расплатятся. Это влияет и на фискализацию, и на обмен с 1С.

• Онлайн-касса. Продажа сертификата и его погашение — разные кассовые операции; согласуйте с бухгалтерией предмет расчёта и признак способа расчёта (аванс/зачёт аванса), чтобы чеки формировались корректно.
• Обмен с 1С. Стандартный протокол CommerceML передаёт заказы и товары, но не «понимает» баланс сертификата. Логику зачёта и остатков придётся согласовать отдельно — либо на стороне сайта, либо доработкой обмена.
• Возвраты. Заранее опишите правила: возвращается ли сам сертификат, что делать с частично использованным номиналом, есть ли срок действия.

Публичная часть и применение сертификата

Получатель применяет сертификат так же, как обычный промокод — в корзине или на шаге оформления. За ввод отвечает компонент sale.basket.basket (поле купона) и sale.order.ajax. Технически для покупателя это неотличимо от купона на скидку, и это удобно: не нужно строить отдельный интерфейс погашения.

На что обратить внимание в вёрстке и UX:

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

Для отправки красивого сертификата покупателю пригодятся почтовые шаблоны (Настройки → Настройки продукта → Почтовые события) с кодом, номиналом и инструкцией по применению.

Итог

Подарочные сертификаты в 1С-Битрикс — это не готовая кнопка, а осознанная сборка: товар-номинал в каталоге, уникальный купон правила корзины и доработка, которая рождает код после оплаты. Самое honest-ограничение — остаток номинала: штатный купон сгорает целиком, а «кошелёк с балансом» требует собственной сущности и учёта. Отдельно продумываются касса, обмен с 1С и возвраты.

Мы в B2Bsite не раз собирали такие механики — от простой «сгорающей» схемы до полноценного баланса с частичным списанием, историей и синхронизацией с 1С. Поможем спроектировать логику под ваши процессы, аккуратно вписать её в существующий магазин и не сломать обмен и фискализацию.