Подарочные сертификаты в Битрикс: номинал, остаток и погашение

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

Подарочные сертификаты в Битрикс: какую задачу закрываем и где границы

Подарочный сертификат — это предоплаченное право получить товар или услугу на определённую сумму. Для магазина это инструмент привлечения и удержания покупателей, для получателя — удобный подарок, который не требует угадывать конкретную вещь. Технически задача распадается на три части: выпуск (создание кода и номинала), учёт (остаток, срок, статус) и погашение (списание суммы в заказе). Каждая часть влияет на остальные, поэтому требования удобнее собирать целиком, а не по кускам.

В официальном курсе по Битрикс тема продажи подарочных сертификатов рассматривается в разделе товарного маркетинга, рядом с купонами и правилами работы с корзиной. Это подсказывает, на какие механизмы опирается реализация: купоны, правила корзины, скидки. Но сертификат не равен промокоду. У промокода обычно нет денежного номинала и остатка, он даёт скидку по условию акции. Сертификат же «стоит» денег, часто переносится на другой заказ и должен сохранять остаток между покупками. Поэтому при проектировании важно не подменить одно другим.

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

Какие исходные данные и правила согласовать до настройки

До начала работ полезно собрать письменный перечень решений. Если хотя бы один пункт не согласован, команда будет додумывать, и на приёмке всплывут расхождения. Минимальный набор входных данных выглядит так:

• Номинал и валюта: одна сумма или несколько вариантов, возможны ли нестандартные значения.
• Способ выпуска: продажа сертификата как товара каталога, ручная выдача менеджером, начисление как бонус за покупку.
• Код: длина, используемые символы, требование уникальности, удобство ввода вручную и защиты от опечаток.
• Срок действия: есть ли он, что происходит с неиспользованным остатком после истечения.
• Частичное использование: разрешено ли списывать часть номинала и хранить остаток.
• Комбинация с другими способами оплаты: можно ли доплатить картой или другим сертификатом.
• Комбинация нескольких сертификатов в одном заказе: разрешена или нет.
• Возврат: что происходит с сертификатом, если заказ отменён или возвращён.
• Ответственный: кто владеет правилами, кто отвечает за спорные ситуации с покупателем.

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

Отдельно стоит договориться о терминах внутри проекта. «Сертификат», «купон», «подарочная карта», «промокод» в разных командах означают разное. Если в требованиях эти слова смешаны, разработчик и маркетолог будут понимать задачу по-разному. Зафиксируйте одно название для сущности с номиналом и остатком и используйте его во всех документах.

Как выбрать сценарий выпуска и погашения

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

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

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

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

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

Ручная выдача

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

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

Номинал, остаток и частичное использование

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

Для каждого состояния нужно описать поведение. Что видит покупатель в личном кабинете? Можно ли объединить остатки двух сертификатов? Что происходит с остатком при отмене заказа — возвращается ли он на сертификат или превращается в другой инструмент? Ответы на эти вопросы определяют объём работ, поэтому их лучше дать письменно, а не «по ситуации».

Отдельно продумайте округление. Если номинал и цены в одной валюте, вопрос кажется простым, но при скидках и правилах корзины сумма к списанию может получиться дробной. Договоритесь, в какую сторону округляется остаток и как это отражается в документах покупателя. Это тот случай, когда мелкая деталь на приёмке превращается в спор.

Комбинация сертификата с другими способами оплаты

Сертификат редко покрывает заказ полностью. Чаще он закрывает часть суммы, а остаток покупатель доплачивает картой, через онлайн-оплату или другим сертификатом. Здесь важно, как это сочетается с частичными оплатами заказа: если магазин умеет принимать оплату частями, сертификат становится ещё одним источником платежа, и порядок применения нужно описать.

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

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

Защита кода и предотвращение повторного использования

Код сертификата — это фактически деньги, поэтому к нему предъявляются те же требования, что к платёжным данным. Код должен быть уникальным, его не должно быть возможно угадать перебором, а попытки ввода стоит ограничивать. Если код короткий и состоит из простых символов, его легко подобрать; если слишком длинный и со сложными символами, покупатель ошибётся при вводе. Баланс подбирается под аудиторию и канал выдачи.

Второе требование — однократность списания. Даже при повторной отправке формы или обновлении страницы сумма не должна списываться дважды. Это проверяется на тестовом магазине отдельным сценарием. Третье — журнал операций: кто и когда выпустил сертификат, когда и в каком заказе он был погашен, какой остаток остался. Без журнала разбор спорной ситуации превращается в поиск по переписке.

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

Таблица сценариев и ожидаемых результатов

Таблица помогает согласовать поведение до разработки и потом использовать её как основу для проверки. Строки можно дополнять под конкретный магазин.

Порядок настройки и ответственность команды

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

Ответственность распределяется так. Заказчик или руководитель проекта отвечает за правила: номинал, срок, частичное использование, комбинации. Разработчик отвечает за реализацию и за то, что поведение совпадает с требованиями. Маркетолог — за то, как сертификат представлен покупателю и как он сочетается с акциями. Бухгалтер и юрист — за правовой режим, налоги и чек. Менеджер поддержки — за порядок действий в спорных ситуациях.

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

Учебный пример: сертификат на 5000 рублей

Учебный пример. Данные условные и не описывают реальный проект.

Входные условия. Магазин подарков продаёт сертификаты номиналом 5000 рублей. Срок действия — один год. Частичное использование разрешено, остаток хранится. Комбинация с онлайн-оплатой разрешена. Два сертификата в одном заказе не суммируются. Возврат заказа возвращает остаток на сертификат. Сертификат продаётся как товар каталога, код выдаётся после оплаты.

Действия. Покупатель приобретает сертификат и оплачивает его. После оплаты получает код. Позже оформляет заказ на 3200 рублей и применяет сертификат. Система списывает 3200 рублей, остаток становится 1800 рублей. Через месяц покупатель оформляет второй заказ на 2500 рублей, применяет тот же сертификат и доплачивает 700 рублей онлайн. Остаток становится нулевым, сертификат переходит в статус исчерпанного.

Проверка. Смотрим, что после первого заказа остаток равен 1800 рублям и виден покупателю. Что после второго заказа остаток нулевой и повторное применение невозможно. Что доплата 700 рублей корректно отражена в заказе. Что в журнале есть обе операции с датами и номерами заказов. Что при отмене второго заказа остаток возвращается к 1800 рублям, а не к 5000. Последний пункт — самый частый источник расхождений, его проверяют отдельно.

Как проверить результат на тестовом магазине

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

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

Ошибки, ограничения и дальнейшие действия

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

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

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