Différences
Ci-dessous, les différences entre deux révisions de la page.
| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
|
changes:fidelite:may-2023-v0.5.47 [2023/05/04 13:55] nenesokhna.fall |
changes:fidelite:may-2023-v0.5.47 [2023/05/04 22:36] (Version actuelle) nenesokhna.fall |
||
|---|---|---|---|
| Ligne 16: | Ligne 16: | ||
| ==== Limiter le nombre de coupon généré pour un client ==== | ==== Limiter le nombre de coupon généré pour un client ==== | ||
| - | Pour remédier à l'abus des points de génération, le système ne génère plus pour le même client plusieurs coupons. Les implémentations suivantes ont été effectuées: | + | 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: |
| - | - Paramétrage d'un timer qui empêche la génération d'un coupon à la suite. | + | * 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 |
| - | - Ajout de l'élément de paramétrage "intervalle génération coupon" à saisir sur une durée en jour au niveau de la configuration d'un lot à gagner | + | - Par défaut, si pas renseigné, les coupons sont générés à la suite sans problème |
| - | - 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 |
| - | - 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 participant | + | |
| - | - Le message suivant est affiché lorsque la génération de coupon n'est pas possible: "Le coupon de fidélité ne peut être générée avant le DateExpirationBlocus". | + | |
| + | {{ :changes:fidelite:updatefidelite-gestionplafond.png?nolink |}} | ||
| ==== Définir les moyens de collecter les points de fidélité ==== | ==== Définir les moyens de collecter les points de fidélité ==== | ||
| - | 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 : | + | Il est 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 : |
| - | * le client fidélité doit être présent pendant la collecte | + | * carte cynod |
| - | * le numéro de téléphone ne puisse plus être considéré comme moyen/support de collecte | + | * badge fidélité |
| + | * numéro de téléphone | ||
| - | Pour se faire les implémentations suivantes ont été effectuées: | + | **Remarque 1 :** Par défaut tous ces moyens/supports de fidélité sont activés |
| - | - paramétrage des moyens de fidélité acceptés lors de la collecte | + | **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** |
| - | - 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. | + | |
| + | {{ :changes:fidelite:points_collectes_rejete_es.png?nolink |}} | ||
| - | ==== Gestion des plafonds de collecte ==== | ||
| - | Sur la base des catégories de clients existants: | + | ==== Gestion des plafonds de collecte ==== |
| - | - 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** | + | Cette fonctionnalité va permettre de |
| + | - définir des plafonds journaliers et montant max de transaction pour chaque catégorie de client de la fidélité. Cela va permettre de détecter des cas supposés de transactions frauduleuses ou non habituelles {{ :changes:fidelite:updatefidelite-gestionplafond.png?nolink |}} | ||
| + | - identifier les collectes de points à comptabiliser et ceux à ignorer qui seront disponible au niveau de la page de rejet {{ :changes:fidelite:updatefidelite-gestionplafond-listrejet.png?nolink |}} | ||
| + | - forcer une collecte qui a été rejetée par le système {{ :changes:fidelite:updatefidelite-gestionplafond-listrejetdetail.png?nolink |}} | ||
| - | - Par défaut la gestion des plafonds (booléen) est à FALSE, aucune restriction n'est faite: | + | **Remarques** |
| - | - si activée | + | - Par défaut la gestion des plafonds est à désactivée, aucune restriction n'est faite |
| - | - à partir des catégories, je peux définir les montants des plafonds | + | - 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 |
| - | - à 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. | - 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. | ||