Mai 2023 (version 0.5.47)

Mise à jour 0.5.47 : la mise à jour résout les tickets de la période janvier - mai 2023

• Pouvoir limiter le nombre de coupons générés pour un client sur une période (#94028)
• Pouvoir définir/paramétrer les moyens de collecter les points de fidélité (#94023)
• Mise en place de plafond de transaction pour les catégories de client (#69132)
• Nouveaux reports
  • client inactifs - liste tous les clients n'ayant pas réalisé de transactions sur la période
  • les coupons de fidélité - liste tous les coupons de fidélité sur une période
• correction bugs/incidents
  • la génération de coupon affiche les participants qui sont supprimés de la campagne (#94022)
  • anomalie sur la fonctionnalité d'enrôlement d'un client ayant déjà participé à une campagne de fidélité ultérieure (#96285)
  • anomalie sur l'historique d'enrôlement d'un client (#96237)

Désormais le système permet de limiter le nombre de coupons de fidélité à générer pour un même client de façon successive. Les implémentations suivantes ont été effectuées:

1. Possibilité de définir un timer qui empêche la génération d'un coupon à la suite avec le champs intervalle génération coupon à renseigner depuis la page d'édition d'un lot à gagner
   1. Par défaut, si pas renseigné, les coupons sont générés à la suite sans problème
   2. Si la valeur est renseignée, à la génération du coupon, le système vérifie si un autre coupon peut être généré pour le client ou non

La collecte des points de fidélité avec le numéro de téléphone cause des soucis au client, raison pour laquelle des améliorations furent apportées telles que :

• le client fidélité doit être présent pendant la collecte
• le numéro de téléphone ne puisse plus être considéré comme moyen/support de collecte

Pour se faire les implémentations suivantes ont été effectuées:

1. paramétrage des moyens de fidélité acceptés lors de la collecte
2. rejet systématiquement des transactions Cynod pour lesquelles la référence fidélité n'est pas acceptée. Ces informations seront sauvegardées dans la page de collectes rejetées avec le motif en respectant les principes établies pour cette page en terme de présentation et de règle de gestion.

Sur la base des catégories de clients existants:

1. pouvoir définir des plafonds journaliers et montant max de transaction. Cela va permettre de détecter des cas supposés de transaction frauduleuse (nouvelle fonctionnalité).
   1. plafond journalier = cumul des transactions réalisées du jour de 00:00:00 à 23:59:59
   2. plafond max transaction = montant maximum d'une transaction
2. pouvoir consulter la liste des transactions rejetées (non collectées) (nouvelle page de consultation)
   1. forcer la collecte d'une transaction ayant fait l'objet de rejet (nouvelle fonctionnalité)
   2. consulter le détails de la transaction rejetée
3. disposer d'un reporting sur les transactions (s'inspirer du report existant transactions collectées) (nouveau reporting)
   1. rejetées
   2. forcées

Règle de gestion

1. Par défaut la gestion des plafonds (booléen) est à FALSE, aucune restriction n'est faite:
   1. si activée
      1. à partir des catégories, je peux définir les montants des plafonds
      2. à partir des campagnes (campagne/show), j'ai la liste des collectes rejetées qui est disponible depuis les onglets
   2. si désactivée : RAS
2. Le principe de collecte des transactions de fidélité est toujours le même : une opération avec des références de fidélité sont remontées et bien inscrites avec toutes les informations dans le système - utile pour la table de rejet qui va garder les informations de collectes ainsi que les points de fidélité de la règle au moment du traitement.
3. Le forçage de la collecte va appliquer la règle définie pour la transaction en forçant un motif avant traitement. Les informations de l'utilisateur et la date de traitement seront enregistrées.