Приложения

• Допустимые отклонения при регистрации покупок
  • Отклонение суммы чека и сумм позиций
  • Отклонение ставки скидки
  • Виды запросов
• Возвраты покупки или её части
  • Возврат без ссылки на чек покупки
    •  Корректировка начислений баллов
    • Корректировка списаний баллов
    • Платежи по чеку и расширенные атрибуты
  • Возврат со ссылкой на чек покупки
    • Корректировка начислений баллов
    • Корректировка списаний баллов
    • Корректировка порций начисления при возвратах чеков с признаком интернет-заказа
    • Корректировка параметров
    • Возврат в случае наличия распределения по платежам
    • Обратная активация купонов при возврате
    • Возврат по артикулу и количеству
    • Расширенные атрибуты
    • Ограничения на коррекцию баллов
    • Возврат со ссылкой на позицию чека
    • Онлайн гашение баллов
    • Корректировка количественных лимитов
  • Жёсткий и нежёсткий возврат
  • Продажа незарегистрированных товаров
  • Обмен товаров
  • Отмена операций возврата и обмена
  • Ограничения по возвратам
• Возврат значений расширенных атрибутов в ответ на запросы
  • Возврат расширенных атрибутов контакта и карты в ответе на запрос баланса
  • Возврат расширенных атрибутов с информацией по применённым дисконтным правилам в ответе на запрос мягкого чека
    • Включение функциональности
    • Обработка дисконтного правила
      • Формирование ключей расширенных атрибутов
      • Формирование значений расширенных атрибутов
      • Ограничения при агрегации и наличии МРЦ
  • Возврат расширенных атрибутов с информацией по начислениям/списаниям баллов в ответе на запрос мягкого и фискального заказа
• Технические расширенные атрибуты карты
  • Среднее время между покупками по карте за период
  • Максимальный чек за период
  • Максимальная сумма месячных покупок за период
  • Количество покупок свыше определённой суммы за период
  • Расширенные атрибуты для уровней карты и контакта
  • Фильтрация по значениям технических атрибутов
• Округление количества баллов
  • Параметр приведения для баллов
  • Параметр приведения для ставки скидки по чеку
  • Параметр приведения для значения счётчика
  • Округление баллов списания
• Безакцептное списание
  • Принцип безакцептного списания
  • Настройка безакцептного списания
  • Возвраты при безакцептном списании
  • Ограничение
• Установка сроков действия баллов при регистрации запроса активации
• Продление действия баллов
  • Алгоритм продления до даты действия порции
  • Алгоритм продления на период к дате последней покупки
  • Настройки алгоритмов продления
  • Параметры для коммуникации
  • Алгоритм продления баллов в специальных кампаниях
• Выбор: скидка или оплата покупки баллами
• Холдирование баллов
  • Запрос холдирования
  • Запрос отмены холдирования
  • Списание холдированных баллов
• Мгновенное начисление бонусов при регистрации
  • Дата сгорания мгновенно начисленных приветственных бонусов и алгоритм ее вычисления
• Промо-новости

Допустимые отклонения при регистрации покупок

Запрос чека покупки содержит суммовые показатели каждой позиции. Это:

• Сумма по позиции
• Ставка скидки по позиции
• Сумма скидки по позиции

Аналогичные параметры предусмотрены и для чека в целом.

Внутри себя параметры чека должны быть самосогласованы. То есть по каждой позиции чека Сумма со скидкой должна в точности совпадать с суммой позиции, к которой применена указанная ставка скидки (аналогично и для параметров чека в целом). Сумма чека в целом должна строго равняться суммарному значению по всем позициям чека значений суммы позиции. Сумма со скидкой чека в целом должна строго равняться суммарному значению по всем позициям чека значений суммы со скидкой позиции.

На практике точного соответствия достичь не всегда получается по различным причинам, например, по причине того, что суммовые показатели всегда учитываются до копеек и поэтому математически округляются до второго десятичного знака.

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

Параметры, в которых указываются допустимые отклонения – партнёрские. В текущей версии предусмотрено три параметра:

Loyalty.Processing.Sale.SummPositionsChequeToleranceLevel - допустимое отклонение суммы между суммой чека и суммами по позициям.

Loyalty.Processing.Sale.СalculatedAndFact.ChequeDiscountToleranceLevel - допустимое отклонение переданной фактической и расчётной ставкой скидки для чека в целом.

Loyalty.Processing.Sale.СalculatedAndFact.PositionDiscountToleranceLevel - допустимое отклонение переданной фактической и расчётной ставкой скидки для отдельной позиции чека.

Отклонение суммы чека и сумм позиций

Если параметр суммы чека отклоняется от суммарного значения сумм всех позиций по модулю на величину большую, чем значение Loyalty.Processing.Sale.SummPositionsChequeToleranceLevel – такой запрос считается не самосогласованным и его нельзя зарегистрировать. Аналогично для суммы со скидкой чека и суммами со скидкой всех позиций. Следует иметь в виду, что данное отклонение регулируется законодательством и не может на текущий момент превышать 1 рубля, но в силу того, что отклонение может быть как в большую сторону, так и в меньшую, устанавливать величину настройки более чем 0.5 – нецелесообразно и критично для регистрации чеков в налоговых базах данных.

Отклонение ставки скидки

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

Запрос не будет зарегистрирован, если хотя бы по одной позиции расчётная скидка отличается от фактической скидки в запросе по модулю более чем на значение параметра Loyalty.Processing.Sale.СalculatedAndFact.PositionDiscountToleranceLevel.

Также запрос не будет зарегистрирован, если по чеку расчётная скидка отличается от фактической скидки в запросе по модулю более чем на значение параметра Loyalty.Processing.Sale.СalculatedAndFact.ChequeDiscountToleranceLevel.

Дисконтные отклонения также регулируются законодательно. Для позиции указанная ставка должна быть такой, чтобы отклонение суммы со скидкой, которое получилось в результате применения ставки скидки к сумме позиции, было не более 1 копейки, то есть сотой части рубля. Для минимального чека в 1 рубль – это даст 1 процентный пункт. Поскольку отклонение может быть как в большую, так и в меньшую стороны, нецелесообразно устанавливать значение параметра Loyalty.Processing.Sale.СalculatedAndFact.PositionDiscountToleranceLevel больше, чем 0.5.

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

Виды запросов

Проверка на самосогласованность запросов по суммовым показателям предусмотрена для мягких, фискальных и запросов возвратов покупки.

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

Возвраты покупки или её части

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

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

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

Если операция покупки была зафиксирована с какими-то скидками, то чек возврата должен быть передан в систему с теми же самыми скидками, которые были предоставлены при покупке. При возврате не происходит перерасчёта предоставленных скидок. Для операции возврата не предусмотрено предварительного запроса (мягкого чека): возврат сразу фиксируется как фискальная операция.

Операция отмены возврата возможна, она регистрируется штатными запросом отмены (роллбэка).

Например, совершена покупка, в результате сформирован чек:

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

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

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

Системные и партнерские настройки возврата:

Loyalty.Processing.Avoid.PaidByBonusNegativeBalance: настройка, запрещающая оплачивать баллами покупку, если активный баланс отрицательный. Бывают случаи, когда отрицательные баллы ещё не погашены (не отработал ночной джоб). Например, делается покупка, потом быстро возврат, в результате образовались непогашенные баллы, но активный баланс нулевой, потом делается покупка с оплатой баллами. Поскольку баллы не погашены, то можно произвести оплату баллами. Во избежание таких случаев, необходимо включить данную настройку, то есть установить её в значение 1, y или Y, при прочих значениях, в том числе и пустом – настройка выключена.

Loyalty.Processing.Return.WriteoffOrder: настройка "Порядок сортировки списанных баллов при возврате". Допустимые значения: FIFO, LIFO, FEFO, LEFO Значение по умолчанию: FIFO. В текущей реализации не используется.

Loyalty.Processing.Return.PaymentPriority: настройка "Порядок сортировки". Относится к возвращаемым баллам, наличным деньгам и т.п. Значение указывается через точку с запятой (;) Значение по умолчанию: Bonus;Cash. Означает в какой очерёдности будут использоваться возвращаемые оплаты, в виде начисления бонусов, денег, переводов на карту и т.п. В текущей реализации не используется.

Loyalty.Processing.Return.BonusAggregationInAnswer  - Агрегация бонусов в ответе по чеку возврата. Если настройка 0, то в ответе чека возврата по ChargedBonus будут выводиться все положительные баллы; по ChargeStatusBonus - все положительные статусные баллы, а в WriteoffBonus будут выводиться все отрицательные баллы; в WriteoffStatusBonus - отрицательные статусные баллы. Если настройка 1, то в ответе чека возврата по ChargedBonus будет выводиться сумма баллов дебета; по ChargedStatusBonus - сумма статусных баллов дебета, а в WriteoffBonus будет выводиться сумма баллов кредита; в WriteoffStatusBonus - сумма статусных баллов кредита. Если настройка не заполнена или значение отличается от 0 и 1, то считается, что её значение равно 0.

В системе реализовано два основных алгоритма возврата: возврат без ссылки на чек покупки и возврат со ссылкой на чек покупки.

Возврат без ссылки на чек покупки

Алгоритм возврата без ссылки на чек покупки – это такой алгоритм, при котором не проверяется, была ли совершена покупка. В этом случае можно вернуть также товар, который не был продан.

При возврате корректируются накопления по карте и контакту: суммы покупок и суммы покупок со скидкой соответственно уменьшатся на сумму и сумму со скидкой чека возврата, однако количество покупок не корректируется.

При данном алгоритме происходит корректировка начисленных бонусных баллов и корректировка списанных баллов. Корректировка значений счётчиков и корректировка уровня скидки карты лояльности не производится.

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

Для того, чтобы система совершала возврат по алгоритму без ссылки на чек покупки необходимо системную настройку Loyalty.Processing.Refund.Bonus.AlgorithmRefund установить в значение 0.

Правила начисления баллов могут иметь ограничения по фильтрации: к чекам возврата без ссылки ограничения применяются исходя из текущего состояния параметров карты, контакта, чека возврата, позиционного состава чека возврата и времени чека возврата.

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

Системные и партнерские настройки

Loyalty.Processing.Refund.Checking.Purchase.Cheque - блокировка регистрации чеков возврата без ссылки на чек покупки через алгоритм ручных чеков. 

Loyalty.Processing.Refund.Bonus.Mode: настройка "Оплачено баллами при возврате". 

 Корректировка начислений баллов

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

Время начала действия отрицательных порций коррекции начислений при регистрации чека возврата без ссылки всегда совпадает со временем чека возврата, даже если само правило начисляет баллы отложенного действия. Баллы коррекции всегда создаются активными, то есть с остатком, равным величине порции начисления, знак остатка также отрицательный (баллы активны, даже если время чека больше серверного времени системы).

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

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

Настройка начислений не требует установки какого-либо значения системной настройки. Автоматически учитываются те правила начисления, которые действуют на момент регистрации чека возврата по серверному времени.

Коррекции начислений при возврате (отрицательные порции баллов) записываются с признаком дебета, поэтому не увеличивают оборотов баллов при возврате.

Корректировка списаний баллов

Корректировка ранее списанных баллов, которыми был оплачен чек покупки, производится не расчётным образом, а на основании параметров, переданных в запросе чека возврата. При формировании чека возврата без ссылки на чек покупки оператор POS-терминала вводит в запрос чека количество баллов, которые необходимо вернуть на карту, причём это необходимо сделать отдельно для бонусных и статусных баллов. Это количество оператор берёт из чека покупки самостоятельно на основании распечатанного распределения по позициям чека.

При этом в системе есть возможность скорректировать возвращаемые баллы на специальный коэффициент. Например, при возврате необходимо восстановить только 50% бонусных баллов, которыми была оплачена покупка. Данный коэффициент устанавливается значением системной настройки Loyalty.Processing.Refund.Bonus.Rate. По умолчанию, данная системная настройка выставлена в единицу. При необходимости её значение можно поменять. Следует обратить внимание, что в эту настройку записывается число; если настройка пуста или заполнена какими-то знаками, не отвечающие числовому значению, то коэффициент будет равен нулю, и бонусные баллы не будут возвращаться на карту лояльности. Также следует обратить внимание, что в качестве десятичного разделителя должна использоваться точка.

Корректировка баллов списания при возврате – это начисление бонусных баллов, поэтому системе необходима действующая кампания, в рамках которой будут произведены эти начисления. Таким образом, для правильного оформления возвратов в системе должна быть действующая кампания, внешний идентификатор которой записан в системной настройке Loyalty.Processing.Refund.Bonus.Campaign. Лучше всего, для целей возврата без ссылки завести отдельную бессрочную кампанию и не связывать её ни с какими правилами в системе. Эта кампания будет использоваться только для возвратов. Следует иметь в виду, если в настройке указан не существующий внешний идентификатор или настройка имеет пустое значение, то запрос возврата без ссылки на чек будет невозможно зарегистрировать.

Коррекции списаний при возврате (положительные порции баллов) записываются с признаком кредита, поэтому не увеличивают оборотов баллов при возврате.

Настройка срока действия возвращаемых баллов

Поскольку корректировка баллов списания – это начисление, а всякая начисленная порция баллов имеет свои сроки действия, то необходимо корректно настроить срок начала действия баллов возврата и срок окончания действия баллов возврата.

Дата начала действия возвращаемых бонусных баллов может быть установлена тремя различными способами. Первый способ – дата и время регистрации чека возврата, второй способ – фиксированная дата, третий способ – отложенное действие.

1. Первый способ – дата и время регистрации чека возврата. Возвращаемые баллы начинают действовать с момента регистрации чека возврата по времени сервера. Для этого необходимо установить системную настройку Loyalty.Processing.Refund.Bonus.StartDateCalculationType в значение 1.
2. Второй способ – фиксированная дата. Если необходимо, чтобы возвращаемые баллы начинали действовать в какую-то определённую дату, например, 1 января 2021 года, то системную настройку Loyalty.Processing.Refund.Bonus.StartDateCalculationType необходимо установить в значение 3, а саму эту определённую дату начала действия возвращаемых баллов записать в системную настройку Loyalty.Processing.Refund.Bonus.StartDate. Следует иметь в виду, что дата должна быть записана в формате ггггммдд. Время начала действия бонусных баллов будет устанавливаться как 00:00. Например, для того чтобы возвращаемые баллы начали действовать с ноля часов 1 января 2021 года, дата в системной настройке должна быть записана следующим образом: 20210101. Если система не может идентифицировать введённое значение как дату или значение пусто, то в качестве начала действия будет установлена дата: 1 января 2000 года.
3. Третий способ – отложенное действие. Если необходимо, чтобы возвращаемые баллы начинали действовать через какой-то период времени после регистрации чека возврата, то системную настройку Loyalty.Processing.Refund.Bonus.StartDateCalculationType необходимо выставить в значение 2, а в настройке Loyalty.Processing.Refund.Bonus.InactivePeriod задать период в днях, по истечении которого баллы начнут действовать. Время начала действия возвращаемой порции баллов будет равно времени регистрации чека возврата по времени сервера.

Наиболее адекватно использованию системы – установка начала действия возвращаемых баллов как отложенное действие.

Время окончания действия возвращаемых баллов определяется двумя способами: фиксированная дата и установка периода действия.

1. Первый способ – фиксированная дата. Срок окончания действия возвращаемых баллов устанавливается как фиксированная дата. Для этого необходимо системную настройку Loyalty.Processing.Refund.Bonus.ExpirationDateCalculationType установить в значение 3, а фиксированную дату окончания действия бонусных баллов записать в системной настройке Loyalty.Processing.Refund.Bonus.ExpirationDate. Следует иметь в виду, что дата должна быть записана в формате ггггммдд. Время окончания действия бонусных баллов будет устанавливаться как 00:00. Например, для того чтобы возвращаемые баллы заканчивали действие 01 января 2025 года в 00:00 часов, дата в системной настройке должна быть записана следующим образом: 20250101. Если система не может идентифицировать введённое значение как дату или значение пусто, то в качестве начала действия будет установлена дата: 1 января 3000 года.
2. Второй способ – установка периода действия. Срок окончания действия бонусных баллов устанавливается периодом действия. В этом случае необходимо системную настройку Loyalty.Processing.Refund.Bonus.ExpirationDateCalculationType установить в значение 2, а сам период действия в днях записать в настройку Loyalty.Processing.Refund.Bonus.ValidityPeriod. В этом случае дата окончания действия баллов будет установлена как дата регистрации чека возврата, к которой добавится количество дней, которое указано в системной настройке Loyalty.Processing.Refund.Bonus.InactivePeriod и количество дней, которое указано в системной настройке Loyalty.Processing.Refund.Bonus.ValidityPeriod. Время окончания действия возвращаемых бонусных баллов будет равно времени регистрации чека возврата по времени сервера.

Наиболее адекватно использованию системы – установка окончания действия возвращаемых баллов согласно установке периода действия.

Платежи по чеку и расширенные атрибуты

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

Возврат со ссылкой на чек покупки

Возврат со ссылкой на чек покупки – это возврат, при котором в чеке возврата проставляется номер чека покупки. На основании этого номера алгоритмы системы корректируют начисленные и списанные баллы: ранее начисленные бонусные/статусные баллы; ранее списанные бонусные/статусные баллы, которыми была оплачена покупка.

Номер чека в системе не является уникальным. Данный номер уникален в рамках одной карты, одного POS-терминала и одного дня. В другой день по одной карте вполне допустимо зарегистрировать чек с номером, который уже был ранее зарегистрирован. Поэтому в чеке возврата со ссылкой необходимо передавать номер чека покупки, внешний идентификатор терминала, на котором была совершена покупка, внешний идентификатор магазина и партнёра. Также необходимо указать дату (достаточно только даты, без времени чека покупки). Если в системе организована строгая иерархичность между партнёрами, магазинами и терминалами, то в ссылке достаточно указывать идентификатор терминала, в противном случае необходимы и идентификаторы партнёра, и магазина.

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

При возврате по чеку со ссылкой корректируются накопления по карте и контакту: суммы покупок и суммы покупок со скидкой соответственно уменьшатся на сумму и сумму со скидкой чека, но количество покупок не корректируется.

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

Для того чтобы система совершала возврат по алгоритму со ссылкой на чек покупки необходимо системную настройку Loyalty.Processing.Refund.Bonus.AlgorithmRefund установить в значение 2.

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

 Корректировка начислений баллов

При корректировке начислений формируется дифференциальный чек. Это такой чек, товарный состав которого определяется вычитанием из товарного состава чека покупки товарного состава чека возврата.

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

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

Следует иметь в виду, что при возврате могут получаться положительные порции начисления. Это происходит в следующих случаях:

1. Корректировка чекового правила начисления в виде значения. Например, есть правило начисления, которое начисляет 100 баллов на покупку. Совершается покупка на 1000 рублей, при этом начислено 100 баллов. Далее происходит возврат половины покупки, то есть 500 рублей. Порции коррекции будут +100 баллов и -100 баллов, что в совокупности даёт нулевую коррекцию. Нулевая совокупная коррекция будет происходить для чекового правила и в случае полного возврата.
2. Корректировка чекового процентного правила начисления. Например, есть правило начисления 100% баллов на сумму чека. Совершается покупка чека из двух позиций: 500 и 500 рублей. Соответственно, при покупке будет создана положительная порция коррекции баллов + 1000 баллов. Далее происходит возврат первой позиции, при возврате будет создано две порции баллов: -1000 и +500. И так происходит всегда, когда меняется позиционный состав дифференциального чека. В случае примера покупка была из 2-х позиций, а дифференциальный чек состоит уже из одной позиции. В случае, если позиционный состав дифференциального чека не изменяется, то положительных порций коррекции не происходит, формируемая отрицательная порция соответствует разнице между покупкой и дифференциальным чеком.

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

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

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

В системе есть возможность сократить подобные положительные начисления, возникающие при использовании фильтрации по исторически накопленным параметрам: такая возможность описана в пункте Ограничения на коррекцию баллов.

Срок окончания любой отрицательной порции устанавливается как 1.1.3000. Срок начала действия отрицательной порции по умолчанию соответствует дате/времени регистрации возврата. В случае, когда начисление отложенное, то есть начисляемые при покупке баллы начинают действовать через какое-то количество времени после покупки, возможно появление отрицательного активного баланса. Это происходит, если возврат регистрируется между покупкой и началом действия баллов этой покупки. Во избежание таких случаев, в системе есть возможность отложенного начала действия отрицательных баллов при возврате.

Например, если, скажем, покупка совершена 1 февраля, по ней было начислено 100 баллов, которые начинают действовать с 03:00 часов 1 марта. 15 февраля был совершён возврат половины покупки, произведена корректировка баллов – 50. По умолчанию, отрицательные баллы начинают действовать с 15 февраля и сразу же гасятся (при наличии положительных баллов). В данном случае гашения не происходит, поскольку других положительных баллов на карте нет. Также в этом случае с 15 февраля активный баланс баллов будет -50. С 1 марта вступят в действие положительные баллы, произойдёт гашение и активный баланс будет корректным, равным 50 баллам. Однако если перед возвратом включить системную настройку Loyalty.Processing.Refund.NegativeBonusDelayed, то при возврате отрицательные баллы будут начинать действовать ровно в то время, в которое начинают действовать положительные баллы, которые как раз корректируют сформированные отрицательные баллы. В рассмотренном выше примере, отрицательные баллы будут действовать с 03:00 часов 1 марта, в какое бы время от 1 февраля до 1 марта не был бы произведен возврат.

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

Отрицательные порции коррекции начисления, возникающие при регистрации чеков возврата, имеют признак дебета.

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

Корректировка списаний баллов

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

Количество возвращаемых баллов определяется системой на основании тех баллов списания, которые были распределены на возвращаемую позицию в чеке покупки. Сколько именно необходимо баллов вернуть обратно на баланс вычисляется пропорционально количеству товара в позиции. Например, при покупке на позицию было списано 9 баллов, в позиции было продано 2 товара. Если возвращается одна штука товара, то будет возвращено на баланс 4.5 балла.

Следует иметь в виду, что распределение баллов по позициям в чеке покупки регулируется системной настройкой. Если системная настройка Loyalty.Processing.Writeoff.CalcFromFullSum установлена в значение 0, то распределение списанных баллов по позициям в чеке покупки производится пропорционально сумме со скидкой позиции; если же системная настройка Loyalty.Processing.Writeoff.CalcFromFullSum установлена в значение 1, то распределение по позициям производится согласно сумме позиции без скидки. Эти распределения могут различаться, но при возврате со ссылкой на чек покупки возвращаются именно распределённые баллы. Это относится к чекам с позициями; для чеков без позиций возвращаются баллы пропорционально возвращаемой сумме со скидкой.

В случае возврата со ссылкой на чек покупки значение возвращаемых баллов зависит от коэффициента, указанного в записи кампании балла (поля «Коэффициент возврата оплаченных баллов» и «Коэффициент возврата оплаченных статусных баллов»). Если в записи кампании не заполнен коэффициент, то берется коэффициент в записи партнёра, в магазине которого регистрируется возврат (аналогичные поля в партнере, как в кампании). Если же в записи партнера не заполнен коэффициент, то берется коэффициент из системных настроек Loyalty.Processing.Refund.ChequeReference.Bonus.Rate и Loyalty.Processing.Refund.ChequeReference.StatusBonus.Rate Подобные коэффициенты могут использоваться, если необходимо в некоторых случаях запретить коррекцию баллов списания (тогда следует поставить значение коэффициента равным 0).

Алгоритм возврата со ссылкой на чек не требует заполнения системной настройки Loyalty.Processing.Refund.Bonus.Campaign (кампания корректировки ранее списанных баллов). Ранее начисленные бонусные баллы буду возвращаться в рамках той кампании, по которой они были начислены. Однако, по причине того, что алгоритм возврата может быть задан не жёстко, всё-таки, рекомендуется эту настройку заполнять актуальным значением внешнего идентификатора какой-то действующей кампании. Что такое жёсткий и нежёсткий алгоритм возврата описано в пункте «Жёсткий и нежёсткий возврат».

Все положительные коррекции баллов списания имеют признак по кредиту.

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

Ограничение на возврат списанных при покупке баллов: если правила списания таковы, что списывать можно только баллы по позициям, например, каких-то конкретных номеров, при этом одинаковые товары находятся в разных позициях, в том числе и по которым допустимо списание и по которым недопустимо списание баллов, то в общем случае возврат таких товаров будет сопровождаться некорректным начислением ранее списанных баллов.

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

Корректировка порций начисления при возвратах чеков с признаком интернет-заказа

При регистрации чека с признаком интернет-заказа (InternetOrder = 1) все порции баллов сдвигаются на 100 лет в будущее. Возврат таких чеков возможен, как и в период пока баллы по чеку не активированы, так и в период после регистрации по чеку запроса активации баллов. Возможны также частичные возвраты, при чём по одному и тому же чеку частичные возвраты могут быть зарегистрированы некоторые в период, когда баллы не активированы, а некоторые после активации баллов.

Но при использовании функциональности чеков с признаком InternetOrder возможны только возвраты со ссылкой на чек покупки. Алгоритм возврата без ссылки на чек использовать нельзя. Также обязательно должен быть выбран режим, при котором баллы коррекции начислений по началу действия совпадают с началом действия баллов начисления при покупке, то есть системная настройка Loyalty.Processing.Refund.NegativeBonusDelayed установлена в одно из значений: 1, y или Y.

Пока чек находится в состоянии с InternetOrder = 1 и по нему регистрируется возврат, то даты действия и положительных и отрицательных порций коррекции также сдвинуты в будущее на 100 лет.

Если после возврата по чеку покупки регистрируется запрос активации баллов, то на 100 лет в прошлое (к настоящему времени) сдвигаются как баллы начисления, связанные с самим чеком покупки, так и баллы коррекций начисления, связанные со всеми чеками возврата данной покупки.

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

Корректировка параметров

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

Количество покупок (по карте, по контакту, по мастер-счёту) при любых возвратах не корректируется, даже если это полный возврат.

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

Возврат в случае наличия распределения по платежам

Если какое-то правило начисления учитывает коэффициенты по типам оплат, то соответствующие начисления по данному правилу учитывают коэффициенты типов платежей. Например, есть правило, которое начисляет 70% от суммы чека в виде бонусных баллов. Правило применилось к чеку на сумму 400 рублей. Соответственно, по правилу будет начислено 280 баллов. Предположим в системе есть типы платежей, и эти типы имеют коэффициенты: Платёж1 – 100%, Платёж2 – 50%, Платёж3 – 30%; при этом сумма чека в 400 рублей оплачена так: Платёж1 – 200 рублей, Платёж2 – 150 рублей, Платёж3 – 50 рублей. Тоже правило, но учитывающее платежи, даст начисление баллов: 70%*[200*(100%/100) + 150*(50%/100) + 50*(30%/100)], что в итоге составит 203 балла.

Чек возврата со ссылкой на чек покупки не содержит информации о том, каким образом будет перечислена клиенту сумма возврата. Однако, коэффициенты распределения по платежам в случае возврата со ссылкой берутся из чека покупки, поэтому бонусные баллы будут скорректированы с учётом этих коэффициентов.

Обратная активация купонов при возврате

Если какое-то правило начисления купонное, и при фискальном чеке произошло гашение какого-то купона (только номерного), то обратная активация купона производится только при первом полном возврате чека, при частичном – никогда погашенный купон не активируется.

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

Возврат по артикулу и количеству

При возврате со ссылкой допускается не передавать ценовые и суммовые значения в чеке возврата. В этом случае, данные значения будут взяты из чека покупки, на который ссылается чек возврата. Обязательными значениями являются артикулы товара (внешние идентификаторы) и количество товара данного артикула. В этом случае не допустимо передавать какие-то суммовые значения в чеках и позициях, в том числе и нулевые. Однако есть возможность включить игнорирование передаваемых суммовых показателей в чеке возврата со ссылкой на чек покупки: для этого необходимо в записи партнера в поле «Игнорировать значения сумм в чеке возврата» установить значение «Да».

Расширенные атрибуты

При возврате со ссылкой на чек покупки не учитываются расширенные атрибуты чека и позиции. Дифференциальный чек рассматривается системой без расширенных атрибутов.

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

Ограничения на коррекцию баллов

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

В системе есть возможность ограничения коррекций баллов. Это делается с помощью установки специального значения системной настройки Loyalty.Processing.Refund.Bonus.CorrectionType. Данная настройка определяет тип коррекции баллов начисления. Если значение настройки равно 0, то при возврате разрешены любые коррекции баллов начисления.

• Если значение равно 1, то при коррекции баллов не будут начислены положительные баллы более того, чем было начислено в первоначальном чеке покупки по конкретному правилу.
• Если значение равно 2, то при коррекции баллов начисления не будут начислены отрицательные баллы, уменьшающие начисленные при покупке баллы.
• Если значение равно 3, то запрещены все коррекции баллов начисления по конкретному правилу, как увеличивающие начисления, так и уменьшающие начисления.

Возврат со ссылкой на позицию чека

Как уже отмечалось, если в чеке есть расширенные атрибуты или списание настроено на конкретные позиции чека, то в общем случае начисление и списание баллов будут проведены некорректно. Однако существует алгоритм, позволяющий учесть данные особенности и произвести коррекции верным образом. Данный алгоритм возврата включается по системной настройке Loyalty.Processing.Refund.PositionReference.

По умолчанию данный алгоритм отключен. Помимо включения данной настройки, необходимо включить данный алгоритм для каждого из партнёров программы лояльности отдельно. Для включения алгоритма для каждого партнёра необходимо обратиться к системному администратору (разработчику базы данных), поскольку включение алгоритма для отдельных партнёров в текущей версии настраивается непосредственно в базе данных. Для этого необходимо отредактировать данные в таблице [configure].[registry_int]. Поле Key должно быть заполнено внешним идентификатором необходимого партнёра, а поле VInt значением 1.

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

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

В текущей версии существует ограничение на возврат разных товаров с одинаковой ценой. Если в кассовом ПО произойдёт сбой и каким-то образом будет поставлен не тот артикул у возвращаемого товара, а номер позиции будет корректный, то такой чек возврата будет зарегистрирован безошибочно.

Онлайн гашение баллов

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

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

Корректировка количественных лимитов

В случае возвратов со ссылкой реализован пересчёт количественных товарных лимитов, настроенных в дисконтных правилах, а также в дисконтных персональных и товарных акций. При этом есть системная настройка Loyalty.Processing.ReturnMethodRecalculatingQuantitativeLimits.ClientBenefit, позволяющая учитывать пересчёт лимитов либо в пользу покупателя, либо в пользу продавца.

Пример: по карте с персональной акцией при значении лимита, равным 3, проведён чек с количеством товара по акции в позиции, равным 5. Скидка по персональной акции применилась на 3 единицы товара из 5. Затем был произведён возврат 3-х единиц товаров. Лимит по персональной акции будет пересчитан и, в случае настройки в пользу покупателя, после возврата покупатель сможет купить по акции со скидкой снова 3 единицы товара. В случае же настройки в пользу продавца, после возврата покупатель сможет купить по акции со скидкой 1 единицу товара.

Жёсткий и нежёсткий возврат

Системные настройки устанавливают глобальное действие алгоритмов. Их значения однозначно выбирают какую-то ветвь кода, и именно по этой ветви будет идти обработка всех чеков, которые регистрируются в системе.

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

В системе есть возможность выбора, будет ли алгоритм возврата жёстким или не жёстким. Если системная настройка Loyalty.Processing.Refund.Bonus.Algorithm.NonFlexible установлена в значение 1, то алгоритм возврата жёсткий, то есть такой, номер которого указан в системной настройке Loyalty.Processing.Refund.Bonus.AlgorithmRefund. Это либо возврат без ссылки на чек покупки, либо возврат со ссылкой на чек покупки – и никак иначе.

Если же системная настройка Loyalty.Processing.Refund.Bonus.Algorithm.NonFlexible установлена в значение 0, то алгоритм возврата используется не жёсткий. В случае, когда основным принят для возврата алгоритм со ссылкой на чек покупки (т.е. системная настройка Loyalty.Processing.Refund.Bonus.AlgorithmRefund установлена в значение 2), то чеки, в которых указана ссылка чек покупки, будут записаны в систему, и все данные о продажах корректируются. Однако, чек возврата без ссылки на чек покупки также будет зарегистрирован и по нему будет оформлен возврат.

Однако, если в качестве основного выбран алгоритм возврата без ссылки на чек покупки (т.е. системная настройка Loyalty.Processing.Refund.Bonus.AlgorithmRefund установлена в значение 0), то в этом случае также возможно зарегистрировать чек возврата со ссылкой на чек покупки. Для корректной работы системы в данном случае необходимо системную настройку Loyalty.Processing.Refund.Bonus.AlgorithmRefund.RefCheque установить в значение 2.

Продажа незарегистрированных товаров

Важно! Следует иметь в виду, что система позволяет записывать позиционные чеки с товарами, артикулы которых не зарегистрированы в системе. За возможность продажи таким образом отвечает системная настройка Loyalty.Processing.Validation.Item.ArticleRequired. Если её значение равно 1 или Y и если в чеке есть хотя бы один товар, артикул которого не зарегистрирован в системе, то будет возвращена ошибка. Любое иное значение данной системной настройки позволяет продавать товары с произвольными артикулами.

В случае, если позволяется продажа товара с произвольным артикулом, в общем случае, не будет работать алгоритм возврата со ссылкой на чек покупки. В этом случае возможны возвраты только без ссылки на чек покупки.

Обмен товаров

Возможны ситуации, когда клиент не желает возвращать товар совсем, отказываясь от владения им, но намерен вместо этого товара приобрести какой-то другой товар (или вместо нескольких товаров приобрести несколько других товаров), или поменять товар одного артикула на товар этого же артикула.

Такую операцию в ML можно зарегистрировать двумя запросами: вначале зарегистрировать возврат на тот товар, который подлежит замене; затем зарегистрировать тот товар, который является замещающим.

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

Чтобы не снижать уровень лояльности клиента и позволить ему обязательно воспользоваться поощрением, которым он имел право воспользоваться при первой покупке – лучше регистрировать обмены не в две операции: возврат и новая покупка, а в одну операцию – регистрацией запроса обмена. Для регистрации такой операции предназначен отдельный вид запроса – Запрос обмена товаров.

Общая схема обмена

Будучи одним запросом, обмен товаров регистрируется в базе данных как две операции: результатом первой – является возврат товаров, а результатом второй – покупка замещающих товаров.

Запрос обмена состоит из трёх частей:

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

Вторая часть представляет собой ссылку на чек покупки, по которой происходит обмен. Третья часть – это количественный состав товаров, подлежащих обмену. Суммовой состав формируется на основании зарегистрированного ранее чека покупки.

Также, как и возврат – запрос обмена может быть только фискального типа. В связи с этим никакие дисконтные правила к запросу обмена не применяются. Если необходимо учесть действующие на текущий момент скидки, нужно дополнительным запросом мягкого чека (без оплаты баллами) на товарный и суммовой состав замещающих товаров получить эти скидки и уже запрос обмена в части суммовых показателей замещающих товаров сформировать на основании ответа мягкого чека.

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

Оплата замещающих товаров баллами

При формировании чека возврата заменяемых товаров определяется какая часть их стоимости была оплачена бонусными и/или статусными баллами, а также в каком количестве на эту часть были списаны соответствующие баллы.

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

При обмене для оплаты новой покупки можно воспользоваться только тем баллами, которые были списаны на товары, подлежащие обмену. Доплатить за покупку дополнительными баллами в текущей функциональности версии нельзя, даже если какое-то их количество присутствует в активном балансе покупателя.

Зачёт оплаченной стоимости производится по максимально возможной сумме к оплате, вплоть до 100% оплаты новой покупки баллами. Значения МРЦ в текущей функциональности игнорируется. Если получилось так, что сумма оплаты баллами новой покупки меньше, чем сумма оплаты баллами замещающих товаров – разница в количестве баллов возвращается на бонусный счёт участника в виде дополнительных положительных порций. Сроки действия этих возвращаемых порций определяются на основании настроек, определяющих сроки действия коррекций списаний баллов при возвратах.

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

Начисления по замещающим товарам

Для определения начислений по чеку обмена, ссылка и позиции, определяющие возврат – игнорируются. Оставшаяся часть подвергается воздействию действующих на момент обмена правил начисления баллов (с их алгоритмами фильтрации). Результаты применения этих правил к товарному и суммовому составу новой покупки и составляют начисления при обмене.

Ответ на запрос обмена

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

Количественный и суммовой состав заменяемых товаров, а также коррекции баллов начисления и списания при возврате – не входят в состав ответа на запрос обмена.

Обмен покупок и заказов

Запрос обмена может быть осуществлён только в отношении чеков покупки и чеков, зарегистрированных в результате оплаты заказов. По неоплаченной части заказа в текущей версии обмен не предусмотрен. Обмен оплаченной части заказа и покупки происходит с использованием одно алгоритма.

Отмена операций возврата и обмена

В текущей версии стали возможны операции отмены транзакций возвратов и обменов: как технические (например, возникающие при возникновении таймаутов сервиса), так и используемые в каких-то бизнес-целях.

Ограничения по возвратам

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

В запросах возвратов со ссылкой недопустимо передавать позиционные и чековые расширенные атрибуты. Также нельзя передавать номера (выпуски, типы) купонов.

При возврате чека без ссылки, если баллы завершили своё действие, создаются баллы корректировки, также завершившие действие.

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

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

При возврате со ссылкой на чек и ссылкой на позицию, если происходят коррекции позиционных правил начисления, то порции баллов создаются без ссылки на позицию чека.

При возврате без ссылки на чек покупки, если есть правила, основанием расчёта которых будут накопления по карте, например, сумма покупок, то сумма текущего чека возврата добавляется к накопленным ранее значениям с положительным знаком.

Исключать из запросов возврата суммовые параметры (кроме артикула и количества) допустимо для чека возврата со ссылкой на чек покупки. Для возврата без ссылки, для возврата со ссылкой на позиции чека – такое не допускается.

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

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

По чекам возврата не предусмотрено транзакционных коммуникаций.

Операции возвратов не учитываются при пересчёте накоплений для функциональности уровней.

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

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

Возврат значений расширенных атрибутов в ответ на запросы

Возврат расширенных атрибутов контакта и карты в ответе на запрос баланса

Есть возможность в ответ на запрос баланса выводить значения расширенных атрибутов контакта и карты (для этого необходимо включить системные настройки Loyalty.Processing.BalanceRequest.ContactEAShow, Loyalty.Processing.BalanceRequest.CardEAShow). При этом будут выводиться значения атрибутов, в определениях которых установлен соответствующий признак («Показывать в ответах» = Да).

Возврат расширенных атрибутов с информацией по применённым дисконтным правилам в ответе на запрос мягкого чека

Для получения скидки необходимо обязательно посылать с POS-терминала запрос мягкого чека. По запросу мягкого чека определяется: какие именно дисконтные правила применяются к данному чеку в данный момент времени, на основании этой информации формируется результирующая скидка по позициям и по всему чеку, эта скидка возвращается в ответе на мягкий чек на POS-терминал. На основании данного ответа POS-терминал формирует и передаёт в систему фискальный чек с результирующими скидками. В общем случае, когда действуют несколько дисконтных правил и при особых условиях их агрегации – информация о применившихся дисконтных правилах теряется.

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

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

Далее в систему передается запрос фискального чека с этими расширенными атрибутами. В итоге, в системе посредством расширенных атрибутов сохранена информация, что в таком-то чеке были применены такие-то дисконтные правила.

Включение функциональности

По умолчанию функциональность передачи расширенных атрибутов в ответе мягкого чека отключена.

Для её включения необходимо установить системную настройку: Loyalty.Processing.Soft.DiscountRuleRuturnAsAttribute.TurnOn в значение 1, y или Y. При прочих значениях функциональность будет отключена.

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

Обработка дисконтного правила

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

При применении товарной акции – в ответ на мягкий чек формируется два расширенных атрибута: один для правила товарной акции, второй для записи значения товарной акции.

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

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

Формирование ключей расширенных атрибутов

Расширенный атрибут стандартно представляет собой ключ и значение, в запросе выглядит так:

Для дисконтного правила значение ключа формируется из префикса и внешнего идентификатора правила (без пробела). Префикс задаётся значением системной настройки Loyalty.Processing.Soft.DiscountRuleRuturnAsAttribute.Prefix.

Для дисконтной товарной акции значение ключа также формируется из префикса и внешнего идентификатора уже товарной акции (без пробела). Префикс задаётся значением партнерской настройки Loyalty.Processing.Soft.DiscountCommodityCampaignValueRuturnAsAttribute.Prefix.

Для дисконтной персональной акции значение ключа также формируется из префикса и внешнего идентификатора уже персональной акции (без пробела). Префикс задаётся значением системной настройки Loyalty.Processing.Soft.DiscountPersonalCampaignValueRuturnAsAttribute.Prefix.

Для лимитированного по суточному количеству товара дисконтного правила дополнительно формируется второй расширенный атрибут, в случае, если включена функциональность формирования значений в виде json. Ключ также формируется из префикса и внешнего идентификатора правила (без пробела). Префикс в этом случае задаётся значением системной настройки: Loyalty.Processing.Soft.DiscountLimitedRuleRuturnAsAttribute.Prefix.

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

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

Формирование значений расширенных атрибутов

Если выключена системная настройка Loyalty.Processing.Soft.DiscountRuleRuturnAsAttribute.ReturnJson, значение расширенного атрибута представляет собой только десятичное число, которое представляет собой величину скидки по данному правилу или товарной (персональной) акции, которые применились к позиции, для которой эти атрибуты и созданы.

В зависимости от значения настройки: Loyalty.Processing.Soft.DiscountRuleRuturnAsAttribute.DiscountType, величина скидки может представлять собой или процентную ставку (значение настройки 0) или значение скидки в денежных единицах (значение настройки 1).

Если величина скидки формируется в виде процентной ставки, можно отдельным образом задать количество десятичных знаков, которое указывается в значении партнерской настройки: Loyalty.Processing.Answer.DiscountDetailAsAttribute.DecimalScale.

Если включена системная настройка Loyalty.Processing.Soft.DiscountRuleRuturnAsAttribute.ReturnJson, значение расширенного атрибута формируется в текстовом виде, как набор параметров по формату, совпадающим с json.

Непосредственно для правила это значение состоит из следующих параметров:

{"N":"ZZ":,"D":YYY.YYY}

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

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

Для товарной акции, персональной акции, а также для лимитированного правила по суточному количеству товара, значение расширенного атрибута состоит из следующих параметров:

{"N":"ZZ":,"Q":XXX.XX}

, где N – также уникальный номер расширенного атрибута в рамках чека.

Q – это количество товара в позиции чека, на которое применилось правило, товарная или персональная акция.

Примерный вид сформированных атрибутов в ответе запроса:

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

Важно! Если кассовое ПО настроено так, что одна позиция чека может быть разбита на две (как правило, в случае корректного вычисления величины скидки в рамках допущений федерального законодательства) – также необходимо использовать формат величин в виде json.

Ограничения при агрегации и наличии МРЦ

Если к кампании относится несколько дисконтных правил, а в качестве агрегации в кампании указано геометрическое сложение, то возвращённое значение результирующей скидки (в теге Discount) может не совпадать с суммой возвращённых значений по расширенным атрибутам. Совпадение будет иметь место, если в качестве метода агрегации скидок кампании используется арифметическое сложение скидок и общая скидка не превосходит 100%.

Если результирующая скидка превосходит 100%, то возвращённая скидка по чеку также будет отличаться от возвращённой скидки по расширенным атрибутам. Например, есть два правила: одно на скидку в 60%, второе на скидку в 70%, правила относятся к кампании, метод агрегации которой «Арифметическая сумма». В этом случае возвращённая в ответе скидка будет 100%, а значения возвращённых атрибутов будут 60 и 70, что в сумме даёт 130.

Для методов агрегации «Максимум» и «Приоритет» в любом случае будут корректные значения, так как расширенные атрибуты с внешними идентификаторами правил возвращаются только в случае, если правило применилось в чеке.

При формировании величины скидки также не будет учтено значение МРЦ или минимальных актуальных оплат, в случае если скидки по акциям не укладываются в эти значения.

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

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

Возврат расширенных атрибутов с информацией по начислениям/списаниям баллов в ответе на запрос мягкого и фискального заказа

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

В случае включенной настройки Loyalty.Processing.Answer.BonusDetailAsAttribute.TurnOn в ответ на запрос формирования корзины заказа (мягкого заказа) и запрос создания заказа (фискального заказа) будут возвращаться расширенные атрибуты с информацией по начисленным и списанным баллам.

Префикс ключа позиционного расширенного атрибута с детализацией по начисленным баллам регулируется системной настройкой Loyalty.Processing.Answer.BonusDetailAsAttribute.Charge.Prefix. К префиксу добавляется внешний идентификатор бонусного правила начисления. В качестве значения расширенного атрибута будет подставлено значение начисленных баллов по данному правилу.

Префикс ключа позиционного расширенного атрибута с детализацией по списанным баллам регулируется системной настройкой Loyalty.Processing.Answer.BonusDetailAsAttribute.WriteOff.Prefix. К префиксу добавляется внешний идентификатор правила списания. В качестве значения расширенного атрибута будет подставлено значение списанных баллов по данному правилу.

В системной настройке Loyalty.Processing.Answer.BonusDetailAsAttribute.DecimalScale можно указать количество десятичных знаков, с точностью до которых формируются значения расширенных атрибутов позиционной детализации начисления/списания баллов.

Технические расширенные атрибуты карты

Расширенные атрибуты карты – это дополнительные параметры, которые связаны с записью карты. 

Рис. Параметр карты «Инициатор создания мастер-счёта»

Расширенные атрибуты заводятся в систему вручную или внешним импортом. Редактирование атрибутов также производится вручную или импортом значений из какой-то внешней системы.

Тем не менее, в системе есть возможность автоматического создания и редактирования некоторых расширенных атрибутов, связанных с картой.

Среднее время между покупками по карте за период

За включение автоматического создания и обновления расширенного атрибута для среднего времени между покупками отвечает значение системной настройки: Loyalty.ExtendedAttribute.Card.AverageDayNumDividePurchaseQuantity2Month.Recalc. Если её значение 1, y или Y – функциональность будет включена, при прочих значениях отключена.

Название расширенного атрибута карты определяется системной настройкой: Loyalty.ExtendedAttribute.Card.AverageDayNumDividePurchaseQuantity2Month. Её значение как раз есть ключ расширенного атрибута, который будет связан с каждой зарегистрированной картой.

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

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

Важно! Если поменять значение системной настройки, определяющей значение ключа данного атрибута, то по всем картам будет создан расширенный атрибут с новым названием; обновление расширенного атрибута со старым названием производиться не будет.

Максимальный чек за период

За включение автоматического создания и обновления расширенного атрибута для максимального чека за период отвечает значение системной настройки: Loyalty.ExtendedAttribute.Card.MaxChequeSum2Month.Recalc. Если её значение 1, y или Y – функциональность будет включена, при прочих значениях отключена.

Название расширенного атрибута карты определяется системной настройкой: Loyalty.ExtendedAttribute.Card.MaxChequeSum2Month. Её значение как раз есть ключ расширенного атрибута, который будет связан с каждой зарегистрированной картой.

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

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

Важно! Если поменять значение системной настройки, определяющей значение ключа данного атрибута, то по всем картам будет создан расширенный атрибут с новым названием; обновление расширенного атрибута со старым названием производиться не будет.

Максимальная сумма месячных покупок за период

За включение автоматического создания и обновления расширенного атрибута для максимальной месячной суммы покупок за период отвечает значение системной настройки: Loyalty.ExtendedAttribute.Card.MaxMonthSumAmong6Month.Recalc. Если её значение 1, y или Y – функциональность будет включена, при прочих значениях отключена.

Название расширенного атрибута карты определяется системной настройкой: Loyalty.ExtendedAttribute.Card.MaxMonthSumAmong6Month. Её значение как раз есть ключ расширенного атрибута, который будет связан с каждой зарегистрированной картой.

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

Само значение данного атрибута рассчитывается автоматически. Берётся учётный период – шесть последних календарных месяцев без учёта текущего. За данный период подсчитывается сумма покупок каждого месяца, получается шесть значений. Из этих шести значений выбирается максимальная сумма. Данная сумма записывается в значение расширенного атрибута.

Важно! Если поменять значение системной настройки, определяющей значение ключа данного атрибута, то по всем картам будет создан расширенный атрибут с новым названием; обновление расширенного атрибута со старым названием производиться не будет.

Количество покупок свыше определённой суммы за период

За включение автоматического создания и обновления расширенного атрибута для количества покупок свыше определённой суммы за период отвечает значение партнёрской настройки Loyalty.ExtendedAttribute.Card.AmountPurchPeriod.FirstDate (партнёрская настройка указывается через расширенный атрибут партнера). В значении настройки указывается дата начала расчёта количества покупок (в формате yyyymmdd). По умолчанию значение - пусто (значит функциональность отключена).

Название расширенного атрибута карты определяется партнёрской настройкой: Loyalty.ExtendedAttribute.Card.AmountPurchPeriod.EAKey. Её значение как раз есть ключ расширенного атрибута, который будет связан с каждой зарегистрированной картой.

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

Само значение данного атрибута рассчитывается автоматически. Берётся учётный период, как количество недель из партнёрской настройки Loyalty.ExtendedAttribute.Card.AmountPurchPeriod.PeriodLength относительно начальной даты расчёта. Начальная дата расчёта периода определяется сдвигом в зависимости от даты в партнёрской настройке Loyalty.ExtendedAttribute.Card.AmountPurchPeriod.FirstDate, количества недель в партнёрской настройке Loyalty.ExtendedAttribute.Card.AmountPurchPeriod.PeriodLength и текущей даты. Например, Loyalty.ExtendedAttribute.Card.AmountPurchPeriod.FirstDate = 20200616, Loyalty.ExtendedAttribute.Card.AmountPurchPeriod.PeriodLength = 2: тогда с 16.06.2020 до 30.06.2020 начальной датой расчёта периода будет 16.06.2020, с 30.06.2020 до 14.07.2020 начальной датой расчёта периода будет 30.06.2020, с 14.07.2020 до 28.07.2020 начальной датой расчёта периода будет 14.07.2020 и т.д. За учётный период подсчитывается количество покупок, которые имеют сумму чека свыше значения из партнёрской настройки Loyalty.ExtendedAttribute.Card.AmountPurchPeriod.ChequeSum. Полученное количество записывается в значение расширенного атрибута.

Расчёт такого расширенного атрибута карты позволяет, например, реализовать следующую механику: если в течение двух недель в интервал со среды по вторник было совершено 3 покупки на сумму от 1000 рублей, то на такую карту начислить 500 баллов. Для реализации такой механики потребуется заполнить партнёрские настройки следующим образом: Loyalty.ExtendedAttribute.Card.AmountPurchPeriod.FirstDate = начальная дата акции (среда), Loyalty.ExtendedAttribute.Card.AmountPurchPeriod.PeriodLength = 2, Loyalty.ExtendedAttribute.Card.AmountPurchPeriod.ChequeSum = 1000, Loyalty.ExtendedAttribute.Card.AmountPurchPeriod.EAKey = заполнить некоторым значением ключа расширенного атрибута карты. Далее необходимо создать задание по расписанию на начисление 500 баллов с ежедневным расписанием выполнения и фильтром по картам с соответствующим расширенным атрибутом, значение которого больше 3. Поскольку начисление баллов должно быть однократно в двухнедельный период, то в задании должен быть включён признак разового выполнения. Однако для того, чтобы по окончании учётного периода происходил сброс факта выполнения задания для карт, то требуется в партнёрской настройке Loyalty.ExtendedAttribute.Card.AmountPurchPeriod.STExID (партнерская настройка указывается через расширенный атрибут партнера) указать внешний идентификатор данного задания по расписания. Для расчёта расширенного атрибута карты должны быть заполнены все упомянутые в этом пункте партнерские настройки.

Важно! Если поменять значение партнёрской настройки, определяющей значение ключа данного атрибута, то по всем картам будет создан расширенный атрибут с новым названием; обновление расширенного атрибута со старым названием производиться не будет.

Важно! Учитывается только факт продажи (возвраты покупок не учитываются в значении расширенного атрибута). Также не учитываются роллбэки (отмены чеков), совершённых позже даты проведения чека покупки.

Расширенные атрибуты для уровней карты и контакта

На основании истории продаж рассчитываются расширенные атрибуты участника программы лояльности: текущие накопления, накопления для перехода на следующий уровень, накопления для сохранения текущего уровня, дата начала действия текущего уровня, дата окончания действия текущего уровня. Расширенные атрибуты для уровней контакта отображаются на форме контакта на вкладке «Связанные записи» в пункте «Технические РА». Исходя из пересчитанных значений атрибутов (агрегатов уровней) может происходить: сохранение уровня, повышение уровня или понижение уровня.

Фильтрация по значениям технических атрибутов

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

Округление количества баллов

В системе для каждого правила начисления можно указать параметр приведения (см. 4.2.3.6). Используя параметр приведения, можно организовать округление начисленного поощрения. Такое округление будет работать, когда нет учёта коэффициентов оплаты. При использовании коэффициентов оплат (см. 4.2.1.6.1), в общем случае, значение поощрения будет дробным. Однако в системе есть возможность приведения количественного значения поощрения после применения коэффициентов оплат. Для этого в системе есть три системных настройки.

Параметр приведения для баллов

Есть партнерская/системная настройка: Loyalty.Processing.Bonus.Round (партнерская настройка указывается через расширенный атрибут партнера).

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

В качестве значений настройки допустимы только целые неотрицательные числа.

Если в настройке поставить значение 1, то таким образом будет происходить округление начисленных баллов до целого (в меньшую сторону).

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

Параметр приведения для ставки скидки по чеку

Есть системная настройка: Loyalty.Processing.Discount.Round.

Значение данной настройки является параметром приведения для ставки скидки по правилу. После расчёта значения ставки скидки, с учётом оплат, коэффициентов от типов или уровней, рассчитанная ставка делится на данный параметр приведения, дробная часть отбрасывается, и полученное значение используется как ставка скидки по чеку или по позиции чека.

В качестве значений настройки допустимы только целые неотрицательные числа.

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

Параметр приведения для значения счётчика

Есть системная настройка: Loyalty.Processing.Counter.Round.

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

В качестве значений настройки допустимы только целые неотрицательные числа.

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

Округление баллов списания

Существует возможность округления для списываемых при оплате покупок баллов. При списании баллов в чеке процессинг распределяет списанные баллы по позициям чека пропорционально сумме со скидкой каждой позиции. Даже если было передано в систему целое число баллов для оплаты, то после распределения по позициям может получиться дробное значение по какой-то позиции. Чтобы избежать распределения нецелого количества списываемых по позициям баллов, необходимо изменить значение партнерской/системной настройки Loyalty.Processing.Writeoff.RoundLength (партнерская настройка указывается через расширенный атрибут партнера). Данная настройка задаёт количество значащих цифр после запятой, с точностью до которых будет произведено данное распределение. Если значение равно 0, то будет произведено распределение до целых значений. Остаток баллов, который неизбежно возникнет в этом случае, будет распределен на позицию, по которой списывается больше всего баллов.

Следует учитывать, что и в этом случае возможно появление в значении баланса клиента нецелого количества баллов. Например, в случае, когда на позицию чётного количества товаров будет распределено нечётное количество баллов. При возврате одной единицы такого товара, в балансе будет образовано с неизбежностью нецелое число. Для возможности округления сумм списания для каждой позиции с учётом количества товара в позиции необходимо включить партнерскую/системную настройку Loyalty.Processing.Writeoff.RoundBySingleItem (партнерская настройка указывается через расширенный атрибут партнера).

Округление баллов списания до целого числа в меньшую сторону

Округление части суммы, доступной для оплаты баллами, по настройке Loyalty.Processing.Writeoff.RoundLength происходит в большую сторону. Например,  к оплате баллами доступна сумма  - 99.8 рублей, при включенной настройке со значением «0» на кассу передается, что для оплаты баллами доступно 100 рублей. С баланса клиента при этом списывается 99,8 бонусов (при условии соответствующего коэффициента конвертации). Таким образом клиент получает дополнительную выгоду (0,2 руб.), не предусмотренную правилами программы лояльности.

Если по настройке оставить 2 знака после запятой, касса будет показывать точную сумму —  99,8 рублей. Но есть ограничения в некоторых кассовых ПО и приложениях, при которых они не смогут списать такую сумму, потому что работают только с целыми числами. Клиент увидит «можно списать 99,8 баллов», попытается оплатить — и получит ошибку.

Чтобы округлить бонусы списания до целого числа в меньшую сторону необходимо воспользоваться настройкой   Loyalty.Processing.Writeoff.RoundDown, которая при формировании ответов на запросы со списанием баллов, округляет значение в <AvailablePayment> с точностью до знаков, указанных в настройке   Loyalty.Processing.Writeoff.RoundLength в меньшую сторону, а также проверяет, что активного баланса баллов больше или равно (с учётом возможной конвертации баллов) значению в передаваемом теге PaidByBonus.

Если в чеке/заказе несколько позиций, то сумма, доступная к оплате баллами, распределяется по позициям без остатка, т.е. значение в теге <AvailablePayment> будет равняться сумме значений в тегах <AvailablePayment> по всем позициям чека/заказа. Значения в позиционных тегах <AvailablePayment> округляется на то же количество знаков, что и в основном теге <AvailablePayment>.

Пример ответа на софт чек с запросом на списание баллов при включенной настройке Loyalty.Processing.Writeoff.RoundDown и настройке Loyalty.Processing.Writeoff.RoundLength в значении 0 смотрите в документации API (обновление документации в работе).

Безакцептное списание

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

В системе безакцептное списание устанавливается глобально, то есть нельзя сделать так, чтобы для каких-то карт была разрешена оплата баллами, даже если не позволяет активный баланс, а для каких-то нет. Либо безакцептное списание разрешено для всех карт, либо запрещено для всех карт.

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

Разрешение безакцептного списания означает, что покупка будет оплачена баллами, даже если нет правила списания.

Принцип безакцептного списания

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

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

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

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

Настройка безакцептного списания

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

Loyalty.Processing.WriteOff.Non-acceptanceAlgorithm – системная настройка, разрешающая безакцептное списание. Если данная настройка установлена в значение 1 или Y, то безакцептное списание разрешено.

Loyalty.Processing.WriteOff.Non-acceptance.Campaign.ExternalID – внешний идентификатор кампании, в рамках которых будут списываться безакцептные баллы.

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

Loyalty.Processing.WriteOff.Non-acceptance.ConversationRate – коэффициент конвертации безакцептно списываемых баллов. Если покупка совершается на сумму 100 денежных единиц, при этом 50 оплачиваются безакцептно, настройка установлена в значение 3, то по такой покупке будет списано 150 (50*3) безакцептных баллов. По умолчанию настройка имеет значение коэффициента 1.

Следует иметь в виду, что безакцептное списание игнорирует запрет списания начисленных в рамках текущей покупки баллов. То есть даже если системная настройка Loyalty.Processing.Writeoff.UseCurrentCharge не установлена в значение 1 или Y, то начисленные в рамках той же самой покупки, что и оплачивается, бонусные баллы будут списываться для оплаты.

Возвраты при безакцептном списании

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

Если используется возврат со ссылкой на чек покупки, то будут возвращены корректным образом баллы, которые были списаны при оплате покупки согласно правилам списания. Баллы, которые были списаны безакцептно со счетов балансов карты, контакта, мастер-счёта вернутся на эти счета пропорционально сумме без скидки относительно чека покупки и чека возврата, с учётом коэффициента конвертации безакцептного списания (системная настройка Loyalty.Processing.WriteOff.Non-acceptance.ConversationRate).

Например, совершена покупка на сумму со скидкой 1000 рублей, при этом 200 рублей оплачено безакцептно; далее осуществляется возврат на сумму 500 рублей. В этом случае на общий баланс будет возвращено (500/1000)*200, то есть 100 баллов, если при этом коэффициент конвертации безакцептного списания равен 1.

Следует очень аккуратно настраивать алгоритмы возврата в случае использования безакцептного списания. Количество возвращаемых ранее безакцептно списанных баллов можно уменьшить, изменив настройку Loyalty.Processing.WriteOff.Non-acceptance.ConversationRate. Например, если она выставлена в ноль, то безакцептно списанные баллы вообще не будут возвращаться на бонусный счёт.

Ограничение

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

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

Безакцептно можно списать только бонусные баллы. Для статусных баллов безакцептное списание не предусмотрено.

Если совершённая покупка оплачена безакцептными баллами, то при возврате эти баллы не будут возвращены по карте.

​​​​​Установка сроков действия баллов при регистрации запроса активации

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

Для того чтобы вернуть баллы в настоящее время используется специальный запрос: BonusActivateRequest (запрос на POS-сервисе). Он выполняется в отношении отдельного чека, ссылка на который указана в самом запросе. При корректной регистрации данного запроса связанные с чеком покупки баллы возвращаются на 100 лет назад: и дата начала действия, и дата окончания.

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

При возвращении баллов в настоящее время можно также учесть разницу во времени между регистрацией чека и регистрацией запроса активации. Учёт разницы времени между запросами включается установкой партнёрской настройки Loyalty.Processing.BonusActivate.ConsiderTimeInterval.TurnOn в одно из значений: 1, y или Y.

Также можно задать, какой именно период будет учитываться: если партнёрская настройка Loyalty.Processing.BonusActivate.ConsiderTimeInterval.RegistrationType установлена в значении 0 – то учитывается временной интервал между датой/временем чека и датой/временем запроса активации. Если же эта настройка установлена в значении 1, то учитывается интервал между событиями записи запросов в базу данных.

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

При активации баллов учитывается округление правил по срокам действия, которое регламентируется параметрами правила начисления. Если правило начисления требует округления баллов, и активируются порции баллов, связанные с таким правилом, то время действия порций баллов сдвигается дополнительно до 0 часов следующих суток.

Продление действия баллов

Любая порция баллов имеет сроки действия. После создания записи сроки фиксируются и уже не могут быть изменены на основании какого-то внешнего события. Тем не менее, существует возможность продления действия порций баллов внутри системы. Можно включить режим, который позволяет раз в сутки изменить срок окончания действия некоторых порций баллов. Процедура выполняется в ночное время, около полуночи по серверному времени. Включение алгоритмов продления осуществляется изменением значения партнёрской настройки: Loyalty.SystemJob.ProlongingBonus.TurnOn. Если значение есть 1, у или Y – то баллы участников будут продлеваться, при иных значениях – не будут.

В текущей версии предусмотрено несколько алгоритмов продления: на период к дате последней оплаченной покупки и до даты действия порции баллов с максимальным сроком окончания действия. Какой именно из этих алгоритмов будет действовать задаётся значением партнёрской настройки: Loyalty.SystemJob.ProlongingBonus.AlgorithmProlongingType. Если значение есть 1 – то будет работать алгоритм продления до даты действия порции с максимальным сроком окончания, если значения есть 2 – на фиксированный период к дате последней оплаченной покупки.

Алгоритм продления до даты действия порции

В этом случае, среди всех порций баллов участника, созданных за прошедшие сутки, находится порция с самым большим сроком окончания действия. Всем остальным порциям баллов этого участника, дата/время окончания которых меньше даты времени окончания найденной порции – проставляется дата/время окончания действия найденной порции.

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

Алгоритм продления на период к дате последней покупки

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

Настройки алгоритмов продления

Баллы для каких участников будут продлеваться задаётся партнёрской настройкой Loyalty.SystemJob.ProlongingBonus.RelationshipPoints. Если значение задано как 1 – будут продлеваться баллы в рамках каждой отдельной карты. Если значение задано как 2 – будут продлеваться баллы в рамках отдельного контакта. В случае продления баллов по контактам, покупка или порция баллов, являющиеся основанием для продления, могут и не принадлежать карте, для которой применилось продление. Также следует иметь в виду: отключение какой-либо карты от контакта – не является основанием для возвращения сроков действия баллов к первоначальным значениям, если продление уже случилось.

Какой именно вид баллов подлежит продлению – задаётся значением партнёрской настройки: Loyalty.SystemJob.ProlongingBonus.PointsKind. Если значение 0 или отсутствует, то подлежат продлению все порции баллов участника (карты или контакта), независимо от вида (бонусные или статусные). Если значение 1 – продлеваются только бонусные баллы на основании порции бонусного балла с максимальным сроком окончания. Если значение 2 – продлеваются только статусные баллы на основании порции статусного балла с максимальным сроком окончания.

В случае, если необходимо продлевать баллы относительно даты последней покупки, то срок, на который следует продлить необходимо задать как значение партнёрской настройки: Loyalty.SystemJob.ProlongingBonus.PeriodTo.LastPaidPurchaseDate. В качестве значений допустимы только целые значения. Если значение не может быть интерпретировано как целое число (или содержит посторонние символы, в том числе и пробелы) – алгоритм продления работать не будет.

Порции баллов могут быть ещё не начавшими действие, то есть неактивными на момент продления. Если существует необходимость продления и этих порций – это можно включить, установкой в 1, y или Y значения партнёрской настройки Loyalty.SystemJob.ProlongingBonus.ConsiderInactivePortions.

Баллы могут иметь разный источник происхождения. Если значение партнёрской настройки Loyalty.SystemJob.ProlongingBonus.AccrualTypePortions есть 0, то продлению подлежат баллы любого происхождения. Если значение есть 1 – продлению подлежат баллы, начисленные в результате покупок; баллы, созданные иным способом: заданием, запросами, ручным начислением – не подлежат продлению.

Возможно также подравнять сроки окончания действия, если какие-то порции баллов, появившиеся ранее включения алгоритма. Если значение Loyalty.SystemJob.ProlongingBonus.Set 1, у или Y, то те порции баллов, которые заканчивают действие после срока продления – будут уравниваться по сроку окончания действия с датой, до которой следует продлить порции. При иных значениях, порции, имеющие дату окончания больше необходимой – сохраняют свой срок действия.

Параметры для коммуникации

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

Создание параметров коммуникаций включаемое. Параметры будут создаваться/обновляться в случае, если партнёрская настройка Loyalty.SystemJob.ProlongingBonus.CommunicationParameters.TurnOn установлена в одно из значений: 1, y или Y.

Если продляются баллы контактов:

• Список, в который будут вноситься контакты, по которым случилось продление баллов, задаётся указанием внешнего идентификатора в значении партнёрской настройки: Loyalty.SystemJob.ProlongingBonus.CommunicationParameters.MarketingList.ExternalID.
• Расширенный атрибут контакта, в числовое значение которого будет записано общее количество продлённых баллов контакта – определяется указанием ключа атрибута в значении партнёрской настройки: Loyalty.SystemJob.ProlongingBonus.CommunicationParameters.ContactAttributeKey.PointsAmount.
• Расширенный атрибут контакта, в значение даты/времени которого будет записана дата/время, до которой продлены баллы - определяется указанием ключа атрибута в значении партнёрской настройки: Loyalty.SystemJob.ProlongingBonus.CommunicationParameters.ContactAttributeKey.EndDate.

Если продлеваются баллы карт:

• Список, в который будут вноситься карты, по которым случилось продление баллов, задаётся указанием внешнего идентификатора в значении партнёрской настройки: Loyalty.SystemJob.ProlongingBonus.CommunicationParameters.CardList.ExternalID.
• Расширенный атрибут карты, в числовое значение которого будет записано общее количество продлённых баллов карты – определяется указанием ключа атрибута в значении партнёрской настройки: Loyalty.SystemJob.ProlongingBonus.CommunicationParameters.CardAttributeKey.PointsAmount.
• Расширенный атрибут карты, в значение даты/времени которого будет записана дата/время, до которой продлены баллы - определяется указанием ключа атрибута в значении партнёрской настройки: Loyalty.SystemJob.ProlongingBonus.CommunicationParameters.CardAttributeKey.EndDate.

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

Значения расширенных атрибутов можно использовать в шаблонах сообщений в соответствующих метапеременных.

Алгоритм продления баллов в специальных кампаниях

Для специальных кампаний (у тех, в которых параметр "Вид кампании"="Специальная") предусмотрена возможность продлевать срок действия бонусов и указывать срок их продлениях в настройках кампании. При этом бонусы в таких кампаниях будут продляться только в случае, если у контакта появится новая порция бонусов по продляемой кампании, т.е. будет совершена новая покупка. Такой алгоритм продления применим для кампании с типом механики -  "покупай постоянно, чтобы бонусы не сгорели".

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

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

Если порция баллов, начисленная по правилу специальной кампании с продлением бонусов, имеет срок окончания действия больший, чем тот, который будет с учетом периода пролонгации,  у этой порции срок действия не сокращается.

Если покупка/заказ, по которой были продлены бонусы, отменяется, то дата окончания действия бонусов становится прежней, как была до совершения отмененной покупки.

Рис. Специальная кампания с параметрами пролонгации бонусов

Если у партнера включена настройка Loyalty.SystemJob.ProlongingBonusClass.TurnOn в значении 2,  то бонусы по этой кампании продлеваются на указанный тип и период пролонгации.

Начисления по акциям, по правилам которых дата окончания действия бонусов не должна меняться и продлеваться, например Персональные акции, можно исключить из функциональности продления с помощью настройки Loyalty.SystemJob.ProlongingBonus.TurnOffRulesPersonalCampaign

Выбор: скидка или оплата покупки баллами

Система позволяет режим работы, когда в качестве поощрения можно предоставить либо скидку, либо разрешить оплачивать покупку (или её часть) ранее накопленными баллами.

Переключение в данный режим осуществляется включением партнёрской/системной настройки Loyalty.Processing.WriteOffPercentageLimitFromSum.TurnOn в одно из значений 1, y или Y. В случае партнёрской настройки, необходимо выбрать текстовое значение расширенного атрибута партнёра даже для значения 1.

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

В ответ на запрос мягкого чека возвращается доступная для оплаты баллами часть суммы чека и рассчитанная внутренняя скидка. Следует иметь в виду, что суммарное поощрение (и скидка и оплата баллами) в этом случае может превосходить сумму позиции или даже сумму чека в целом.

По согласованию с клиентом кассир должен указать, какое поощрение будет предоставлено по чеку. Если клиент выбрал скидку – то чек необходимо освободить от оплаты баллами, если клиент выбрал оплату баллами, то чек необходимо освободить от всех скидок. Далее такой чек должен быть зарегистрирован как фискальный.

Если в фискальном чеке будет сохранена и скидка, и оплата баллами – регистрировать такой чек будет запрещено.

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

Холдирование баллов

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

Партнерские параметры, которые отвечают за работу функционала (партнерская настройка указывается через расширенный атрибут партнера):

Loyalty.Processing.CheckHolding.TurnOn - Включает обработку запросов с учётом необходимости холдирования.

Loyalty.SystemJob.HoldRequests.RetentionPeriod - Количество дней хранения запросов холдирования

Запрос холдирования

Запрос холдирования обрабатывается только если его обработка разрешена настройкой Loyalty.Processing.CheckHolding.TurnOn, если обработка запрещена, то процессинг запроса останавливается и в ответ на запрос возвращается ошибка. При успешной обработке запроса холдирования, бонусы списываются согласно правилу списания, применившегося к запросу и отражаются на отдельном балансовом счету карты, контакта и мастер-счета.

Рис. Поля Холдировано (баллы и статусные баллы) в карточке карты.

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

Рис. Чеки холдирования в карточке контакта

В карточке чека холдирования отображаются связанные записи в табах «Позиции чека» и «Баллы списания».

Значения полей чек, номер позиции и товар в «Позиции чека» представлены в виде ссылки на соответствующие сущности.

Рис. Позиция чека холдирования

Аналогично ссылки присутствуют в представлении баллов списания в полях "Чек холдирования" и "Позиция чека холдирования".

 Рис. Баллы списания в чеке холдирования

Запрос отмены холдирования

Запрос отмены холдирования обрабатывается только если функционал холдирования разрешен настройкой Loyalty.Processing.CheckHolding.TurnOn, если обработка запрещена, то процессинг запроса останавливается и в ответ на запрос возвращается ошибка. При успешной обработке запроса отменяемый запрос холдирования удаляется и бонусы холдированые по нему возвращаются на бонусный счет.

Если балы по запросу холдирования не списаны и не возвращены на счет запросом отмены холдирования в течении срока, определенного в настройке Loyalty.SystemJob.HoldRequests.RetentionPeriod, то по истечению этого срока автоматически отменяется запрос холдирования и баллы возвращаются на бонусный счет.

Списание холдированных баллов

При успешной обработке запроса фискального чека по запросу холдирования, порция холдированых по нему бонусов списывается, а сам запрос холдирования убирается из связанного представления. В случае если функционал холдирования разрешен настройкой Loyalty.Processing.CheckHolding.TurnOn и фискальный чек будет отменен, запрос холдирования и баллы холдирования будут возвращены.

Для успешной отработки фискального чека необходимо чтобы его товарный и суммовой состав не отличался от чека холдирования.

Мгновенное начисление бонусов при регистрации

Для новых участников ПЛ есть возможность начислять приветственные бонусы, которыми можно оплатить покупки сразу после регистрации. Например, клиент, зарегистрировавшийся в МП в магазине, получает бонусы на счет и может списать полученные бонусы на товары по специальным предложениям для участников ПЛ. Это мотивирует клиентов не откладывать покупку на неопределенное время.

Функционал начисления приветственных бонусов сразу после регистрации контакта включается партнерской настройкой Loyalty.WelcomeBonuses.TurnOn. Сделать начисление возможно только для контактов с определенными значениями параметра «Источник анкеты» в карточке Контакта.

Рис. Параметр «Источник анкеты» в карточке Контакта

Значения для источников анкеты задаются партнерской настройкой Loyalty.WelcomeBonuses.Source. Если настройки активны, имеют допустимые значения, и у контакта есть активная карта, то происходит начисление бонусов по самой старшей активной карте контакта. Начисление бонусов производится в соответствии с партнерскими настройками:

• Loyalty.WelcomeBonuses.Campaign,
• Loyalty.WelcomeBonuses.Quantity,
• Loyalty.WelcomeBonuses.ValidityPeriodDay.

Партнерской настройкой Loyalty.WelcomeBonuses.WaitintPeriodHour устанавливается промежуток времени в часах, в течение которого контакт может получить приветственные бонусы. Если с момента регистрации контакта прошло более часов, чем указано в настройке, контакту бонусы не начисляются.

Дата сгорания мгновенно начисленных приветственных бонусов и алгоритм ее вычисления

Партнерской настройкой Loyalty.WelcomeBonuses.Deadline устанавливается дата сгорания приветственных бонусов. В зависимости от даты регистрации клиента и назначенного периода действия приветственных бонусов в настройке  Loyalty.WelcomeBonuses.ValidityPeriodDay, дата сгорания может варьироваться, но будет ограничена датой, которая зафиксирована в настройке.

Дата сгорания бонусов рассчитывается по формуле (Дата регистрации клиента + Loyalty.WellcomeBonuses.ValidityPeriodDay) и может быть 2 варианта ее вычисления.

Вариант 1. Если после расчета итоговая дата сгорания меньше, чем дата в атрибуте Loyalty.WellcomeBonuses.Deadline, то дата остается без изменений.                  

Рассмотрим такой пример расчета:

Дата регистрации клиента = 10.07.2024

В системе Manzana Loyalty заполнены все атрибуты для мгновенного начисления бонусов при регистрации, при этом:

Loyalty.WellcomeBonuses.Deadline=31.12.2024,

Loyalty.WellcomeBonuses.ValidityPeriodDay=14.

Дата сгорания = Дата регистрации клиента (10.07.2024) + Loyalty.WellcomeBonuses.ValidityPeriodDay (14) = 24.07.2024.

Так как 24.07.2024 < Loyalty.WellcomeBonuses.Deadline (31.12.2024), то дата сгорания будет равна   24.07.2024

Вариант 2. Если итоговая дата сгорания больше, чем дата в атрибуте Loyalty.WellcomeBonuses.Deadline, то дата берется из  Loyalty.WellcomeBonuses.Deadline.

Рассмотрим другой пример расчета:

Дата регистрации клиента = 25.12.2024

В системе Manzana Loyalty заполнены все атрибуты для мгновенного начисления бонусов при регистрации, при этом:

Loyalty.WellcomeBonuses.Deadline=31.12.2024,

Loyalty.WellcomeBonuses.ValidityPeriodDay=14.

Дата сгорания = Дата регистрации клиента (25.12.2024) + Loyalty.WellcomeBonuses.ValidityPeriodDay (14) = 08.01.2025.

Так как 08.01.2025 > Loyalty.WellcomeBonuses.Deadline (31.12.2024), то  дата сгорания будет равна дате, указанной в настройке - 31.12.2024.

Расширенный атрибут Loyalty.WellcomeBonuses.Deadline не является обязательным для заполнения.