Février 2022 (version 3.6.1)

Mise à jour 3.6.1 : la mise à jour résout les tickets de la période mi-décembre 2021 à mi-février 2022.

A noter les hotfix Janvier 2022 (version 3.5.3_7), Janvier 2022 (version 3.5.3_5), Janvier 2022 (version 3.6.0_6) déployées après les versions Janvier 2022 (version 3.6) et Décembre 2021 (version 3.5.3)

• Historisation des opérations (#73599)
• Transactions en FULL ONLINE
• Optimisation de la synchronisation des transactions offline
• Mise en place d'un module de contrôle et correction des écarts identifiés par cynod (#73982)
• Nouvelles colonnes motif et solde progressif au niveau du relevé de transactions pour le portail client (#61781, #71576)
• Harmonisation des méthodes de transmission des notifications sms/mail de cynod vers apicom (#74056)
• Optimisation sur les opérations d'annulation au niveau de la page historique (#74936)
• Optimisation de la gestion des exceptions durant le processus d'historisation des transactions (#75215)
• correction bugs/incidents
  • Incident sur la synchronisation des données entre deux établissements partenaires (#73857) - ne concerne que les clients en interopérabilité
  • Anomalie lors de la consultation de la liste noire des cartes (#71706)
  • Erreur lors de la mise en opposition de ticket carburant (#71326)
  • Lors de l'envoi de code PIN par lot les messages ne sont pas transmis (#73484)
  • Anomalie qui rend valide un ticket carburant durant un processus de génération qui ne s'est pas bien terminé (#62907)
  • Incident rare durant le processus de synchronisation d'un enrôlement de la fidélité (#74465) - ne concerne que les clients disposant du module de la fidélité
  • Anomalie lors de la consultation de la liste d'un groupe de diffusion durant l'envoi de notifications (#74290)
  • Le report suivi consommation ticket n'affiche pas les transactions historisées (#75129)

• Transactions en FULL ONLINE
• Optimisation de la synchronisation des transactions offline
• Amélioration des informations du solde de la carte lors d'une consultation en mode déconnecté (offline) (#73828)
• Optimisation du temps de lecture et d'écriture des TPE i9100, i9100/W et i9000S (#74036)
• Amélioration de la gestion et interprétation des exceptions sur les TPE (#72973)
• Implémentation de la librairie Volley à la place de la librairie RestClient pour le job de confirmation de synchronisation des transactions (#73989)
• Gestion des callback sur un appel et traitement de la librairie Volley (#75364)
• correction bugs/incidents
  • Fatal Exception: android.database.sqlite.SQLiteDatabaseLockedException crash qui survient lorsque plusieurs processus ouvrent simultanément une opération sur la base de données provoquant des verrouillages (#74046)
  • Fatal Exception: java.lang.RuntimeException Unable to start activity ComponentInfo crash qui survient après la lecture de la carte où la récupération des informations n'a pas été bien stockée (#74043)
  • Fatal Exception: java.lang.RuntimeException Can't create handler inside thread that has not called Looper.prepare() crash qui survient pendant l'exécution d'un processus qui engendre un second processus (#74297)
  • Fatal Exception: java.lang.RuntimeException Unable to start activity ComponentInfo incident qui survient après la lecture de la carte où la récupération du nom du client ne s'est pas bien déroulée (#74298)
  • Anomalie qui survient après la consommation d'un ticket carburant en saisie où la redirection vers le résumé de la transaction ne se fait pas (#73478)
  • Anomalie qui survient après la consommation d'un code de transaction où la redirection vers le résumé de la transaction ne se fait pas (#73991)
  • Incident sur l'encodage de carte pour les modèles i9100, i9100/W et i9000S (#75385)
  • Incident qui survient pendant une transaction offline avec le message Clés introuvables (#74896)
  • Le kilométrage n'est pas renseigné sur le reçu de la transaction (#74445)
  • Après avoir effectué une transaction cash (en espèce) le montant de la transaction est affiché 2 fois sur le reçu imprimé (#74561)

L'historique des transactions permet de visualiser les opérations réalisées au delà des 24 dernières heures (ou prise en compte par le processus d'historisation). Vous pouvez filtrer les transactions à afficher de la même manière que la page de consultation des opérations à la seule conditions que la date de début ne pourra pas être celle du jour. Vous pouvez ensuite télécharger dans un fichier Excel une vue filtrée des transactions sur lesquels réaliser un audit.

Pour accéder à la page des historiques, cliquez sur Historique depuis la page transaction carte ou ticket ou cash (en espèce)

Dans Historique des transaction, vous pouvez filtrer les transactions à afficher. Les filtres suivants sont disponibles :

• Période (Date début et Date de fin) : sélectionnez une période pour laquelle la date du jour n'est pas incluse. L'historisation ne considère pas les 24 dernières heures ou les transactions pour lesquelles le processus d'historisation n'a pas été complété
• Type de transaction : sélectionnez un type de transaction. Par défaut ce filtre n'est pas obligatoire
• Point de service : sélectionnez un point de service spécifique. Par défaut tous les points de service sont inclus
• Client : sélectionnez un client et même un porteur. Par défaut tous les clients sont inclus

Voici les pages qui sont impactées par ces changements :

• Plateforme d'administration
  • Relevé de compte
  • Exportation du relevé de compte
  • Opérations carte
  • Opérations ticket
  • Opérations cash (en espèce)
  • Exportation de la liste des opérations
• Portail client
  • Activités récentes
  • Activités d'une carte
  • Relevé des transactions

Les transactions offline sont réalisables sous certaines conditions et permettent de pouvoir servir le client tout en mesurant le risque lié à ce procédé. Toutefois cette fonctionnalité bien qu'avantageuse d'un point de vue commercial, comporte une condition qui si elle n'est pas suivie peut devenir inconvénient : un solde carte sur TPE différent de celui en ligne. Voici une liste qui présente les différents supports de paiement à ce jour avec leur moyen de communication :

Avec l'introduction du paramétrage en full online, les supports de type carte et ticket éligibles au mode offline seront plus autorisés à être servis sans connexion internet. Ce paramétrage peut se faire à deux niveaux :

1. au niveau de l'établissement : les tickets et cartes ne peuvent plus être servis sans connexion internet
2. au niveau des profils de carte : uniquement les profils de carte choisis pourront être servis sans connexion internet. Il faudra au préalable activé le mode full online établissement pour cette action soit possible

Remarque : en activant cette option les TPE ne serviront plus les supports de paiement éligibles sans connexion à internet. Charge au point de service de se doter des moyens de disposer d'une connectivité à internet suffisante pour que les TPE puissent servir les clients.

Pour rappel la synchronisation d'une transaction offline est tâche automatique réalisée par le TPE à une fréquence définie à condition qu'une connectivité à internet soit disponible. Les utilisateurs peuvent aussi à tout moment réaliser cette action en cliquant sur Remontée Offline depuis le menu Divers du TPE.

Durant le processus synchronisation d'une transaction offline, le TPE n'est acquitté que si la transaction soumise peut être traitée par le serveur. Au cas échéant, la transaction reste sur le TPE jusqu'à ce que le point de blocage soit levé pour que le synchronisation puisse se faire.

Désormais, ce processus est simplifié au niveau du TPE qui ne se chargera que de communiquer les informations de la transaction réalisée. Le serveur fera tout son traitement depuis la plateforme web. De cette manière la seule raison pouvant empêcher une transaction sur le TPE de synchroniser sera un défaut de connexion internet.

Une fois le traitement fait par le serveur, l'administrateur pourra depuis le module Transaction

• consulter les transactions non encore comptabilisées qui seront traitées par le système au moment de l'exécution de processus de comptabilisation à une fréquence régulière
• consulter les transactions qui ont été rejetées par le système ainsi que le motif de rejet pour prise en charge par l'administration si une correction est possible
• réaliser des forçages sur les transactions non comptabilisées

Ces pages et actions dans le module Transaction sont protégées par le rôle ROLE_COMPTA_TRANSAC. Il faudra l'assigner à l'utilisateur pour qu'il soit autorisé.

Toujours dans le cadre d'amélioration des outils permettant une meilleure prise en charge des incidents reportés sur les cas présumés d'écart de solde entre celui du TPE et celui de la carte depuis le BO, cynod va collecter et lister les récentes opérations carte qui ferait l'objet d'écart pour analyse par les utilisateurs habilités. A la suite de l'analyse la mise à jour du cumul pourra être réalisée. Cet ensemble de nouvelles fonctionnalités est régi et protégé par le rôle ROLE_CHECK_CARTE. Il faudra l'assigné à l'utilisateur pour que le module Contrôle lui soit accessible.

Très régulièrement le système va lister toutes les cartes supposées présenter une incohérence au niveau du cumul de transaction sur la base de la dernière situation normale souvent égale à 0. L'administrateur pourra analyser l'historique de transaction de la carte et vérifier ces informations avant de procéder à une démarche corrective.

En renseignant une carte ainsi que la période choisie, le système va lister pour toutes les transactions connues le détail de l'évolution du solde et des différents cumuls.

La mise à jour du cumul de la carte peut permettre de corriger de rares cas d'écart de solde en terme d'interprétation pour le TPE et la back-office. A chaque utilisation de la fonctionnalité, le système crée une alerte envoyée à une liste de diffusion et enregistre les actions réalisées pour des besoins d'audit.

• motif : affiche le motif saisie lors de l'opération pour les cas de transfert ou code électronique. le nombre de caractère à afficher sera tronqué s'il dépasse 50 caractères.
• solde progressif : affiche pour chaque ligne solde après chaque opération

Ces informations feront partie du contenu exporté au format excel (xlsx).

Lors de la consultation du solde de la carte depuis le TPE, le système affiche les informations selon que la carte dispose d'un cumul de transaction offline et de la disponibilité d'internet pour contacter le serveur. Dans le cas où le serveur est disponible, le solde qui est affiché prend en compte le cumul de transaction de la carte si cette dernière en dispose. Au cas échéant (mode offline) , seules les informations du solde disponible sur la carte est affiché.

Le cumul de transaction offline signifie le total d'opérations réalisées par la carte sur des TPE ne disposant pas de connexion internet au moment de la transaction. Cette information est stockée sur la carte jusqu'à ce que le TPE synchronise ses informations et que ces opérations soient comptabilisées. A la prochaine transaction online de la carte, le cumul sera rafraîchit.

Désormais pour faciliter la lecture du solde TPE, l'information du total de transactions en attente de comptabilisation sera affichée lorsque le système le détecte.

Lorsque le TPE parvient à contacter le serveur et qu'un cumul est détecté : le solde disponible est affiché ainsi que celui en attente de comptabilisation

Lorsque le TPE ne parvient pas à contacter le serveur et qu'un cumul est détecté : le solde de la carte sera affiché