✎ changes:fidelite:may-2023-v0.5.47 [cynod]

Vous affichez une ancienne révision du document ! Si vous l'enregistrez, vous créerez une nouvelle version avec ce contenu.

====== 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

===== Application web =====
  * [[changes:fidelite:may-2023-v0.5.47#Limiter le nombre de coupon généré pour un client| Pouvoir limiter le nombre de coupons générés pour un client sur une période (#94028)]] :!:
  * [[changes:fidelite:may-2023-v0.5.47#Définir les moyens de collecter les points de fidélité | Pouvoir définir/paramétrer les moyens de collecter les points de fidélité (#94023)]] :!:
  * [[changes:fidelite:may-2023-v0.5.47#Gestion des plafonds de collecte| 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)

==== Limiter le nombre de coupon généré pour un client ====

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:
  * 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
    - Par défaut, si pas renseigné, les coupons sont générés à la suite sans problème
    - 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

{{ :changes:fidelite:updatefidelite-gestionplafond.png?nolink |}}

==== Définir les moyens de collecter les points de fidélité ====

Il possible de déterminer par quel moyen/support les points de fidélité sont pris en compte lors des transactions. Depuis le menu de **Configuration** vous pourrez activer l'un des moyens/support de fidélité suivants :
  * carte cynod
  * badge fidélité
  * numéro de téléphone

**Remarque 1 :** Par défaut tous ces moyens/supports de fidélité sont activés

**Remarque 2 :** Le système de fidélité va rejeter systématiquement tout collecte de point non autorisé et garder l'information au niveau de la ''page des collectes de points rejetés'' disponible à partir de **Campagne->Collectes rejetées**

==== Gestion des plafonds de collecte ====

Sur la base des catégories de clients existants:
  - 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é).
    - plafond journalier = cumul des transactions réalisées du jour de 00:00:00 à 23:59:59
    - plafond max transaction = montant maximum d'une transaction
  - pouvoir consulter la liste des transactions rejetées (non collectées) **(nouvelle page de consultation)**
    - forcer la collecte d'une transaction ayant fait l'objet de rejet **(nouvelle fonctionnalité)**
    - consulter le détails de la transaction rejetée
  - disposer d'un reporting sur les transactions (s'inspirer du report existant transactions collectées) (nouveau reporting)
    - rejetées
    - forcées

**Règle de gestion**

- Par défaut la gestion des plafonds (booléen) est à FALSE, aucune restriction n'est faite:
    - si activée
      - à partir des catégories, je peux définir les montants des plafonds
      - à partir des campagnes (campagne/show), j'ai la liste des collectes rejetées qui est disponible depuis les onglets
    - si désactivée : RAS
  - 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.
  - 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.

Résumé

Note : En modifiant cette page, vous acceptez que le contenu soit placé sous les termes de la licence suivante : CC Attribution-Share Alike 4.0 International