Prévention des fraudes liées aux retours
Les opérations liées aux retours d'articles en magasin peuvent être susceptibles de générer des fraudes. Les fonctionnalités développées ci-dessous permettent de limiter ces cas.
Remboursement sur la carte bancaire utilisée lors de la vente
Paramétrage de la carte bancaire
Back-Office > Paramètres > Gestion > Modes de règlement
Ouvrez l'onglet Complément de la fiche Carte bancaire, et effectuez les opérations suivantes :
|
Champs |
Action |
|
N° d’autorisation |
Cochez cette option. |
|
Type de n° d’autorisation |
Sélectionnez Aucun. |
|
Envoi du montant au TPE |
Cochez cette option. |
Paramétrage de la caisse
Back-Office > Paramètres > Front Office > Caisse
Ouvrez la fiche Caisse de votre choix, et effectuez les opérations suivantes :
|
Dans la fiche Caisse |
Action |
|
Onglet Gestion |
Cochez le paramètre Vérification carte de remboursement. |
|
Paramétrage des périphériques : TPE |
Dans l'onglet Généralités, renseignez les champs suivants ainsi :
|
Cliquez sur ce bouton et sélectionnez Fonctionnement en caisse
Front-Office > Encaissement > Ventes > Saisie de ticket
La recherche de la transaction de paiement est réalisée en cas de retour, dans les cas suivants :
-
Retour partiel ou total d’un ticket réglé avec un seul règlement par Carte Bancaire.
-
Retour total d’un ticket réglé avec X modes de règlement dont 1 Carte Bancaire.
Ticket de vente
Lors de la saisie d’un ticket avec 1 article payé avec 1 Carte Bancaire, une demande d’autorisation au TPE est effectuée lors de la validation du ticket.
Les étapes de la transaction monétique sont les suivantes :
Demande de réponse du simulateur : Dans le simulateur, cliquez sur le bouton [Load response].
On simule l’acception du TPE en sélectionnant un fichier typé OK :
=>Sélectionnez le fichier OK_Reglement_CB.xml dans C:\Program Files (x86)\Cegid\Cegid Retail\Cegid Retail Y2 VXX.0\Front Office\CPOS_Pilotes\Data
Des identifiants de la transaction sont renvoyés et peuvent être visualisés dans l’onglet Response du simulateur :
On simule le renvoi de l’acception du TPE en cliquant sur le bouton [Send response]. Le ticket est édité.
Ticket de retour
Lors de la validation du ticket de retour, les contrôles sont effectués au niveau du montant et des identifiants de la transaction d’origine.
La fenêtre de demande d’autorisation au TPE s’ouvre.
Le montant doit correspondre au ticket précédent. Dans l’onglet Request du simulateur, on peut contrôler les identifiants de transaction :
-
ApprovedTransactionNumber,
-
ApprovedAuthNum,
-
Transaction Token.
Le message suivant est renvoyé à l’utilisateur :
=> "Les remboursements suivants ont été effectués : XX € remboursés avec la carte qui a servi à payer le ticket n° YY de la caisse XYZ".
Refus de la demande d’autorisation lors du retour
Si la demande d’autorisation est refusée lors du retour, un premier message en avertit l’utilisateur et un second message propose de recommencer la demande d’autorisation.
Si l’utilisateur ne souhaite pas refaire une demande d’autorisation, la sélection d’un autre mode de règlement (espèces, avoir) est attendue. Après avoir choisi le mode de remboursement, l'utilisateur peut valider le ticket.
Recherche de la transaction de paiement pour le remboursement d’un retour
Il est parfois difficile de retrouver la transaction de paiement d'un article retourné (vente réalisée dans un établissement équipé d’une monétique différente, vente réglée par plusieurs moyens de paiement, retour de plusieurs articles provenant de ventes différentes, retour d’un article appartenant à une vente pour laquelle un autre article a déjà été retourné et remboursé, etc.).
Un développement spécifique CBS peut alors permettre de sélectionner la transaction grâce à l’ouverture CBS CbrReceipt.BeforeEftAuthorizationRequest qui est appelée par Y2 avant l’envoi de la demande d’autorisation d’un règlement par carte à la monétique, donc avant l’appel du pilote CPOS. CBS peut alors obtenir la référence de la vente d’origine des lignes de retour du ticket en cours de traitement grâce à la dernière évolution de la fonction contextuelle ThisDocument.GetReceiptData.
En fonction des règles d’utilisation à définir avec le commerçant et son monéticien, et selon les possibilités du pilote CPOS utilisé, CBS pourra sélectionner la référence de la transaction de paiement d’origine et la retourner à Y2 pour transmission au pilote CPOS.
Si aucun code CBS n’est branché sur le user-exit, la demande de remboursement est envoyée à la monétique sans faire de lien avec la transaction de vente.
Identification du ticket d'origine
Depuis le multicritère des ventes
La façon dont a été saisie la ligne de retour est mémorisée dans le champ Mode de création de la ligne.
Le champ Mode de création peut être affiché dans les multicritères des ventes, via le bouton [Paramétrer la présentation]. Basculez le champ Mode de création (GL_CREERPAR) dans la liste des colonnes à afficher. Les valeurs possibles sont les suivantes :
-
Identifiant du retour scanné à partir d’un original,
-
Identifiant du retour scanné à partir d’un duplicata,
-
Identifiant du retour scanné,
-
Identifiant du retour saisi à partir d’un original,
-
Identifiant du retour saisi à partir d’un duplicata,
-
Identifiant du retour saisi,
-
Choix du retour depuis la liste de recherche,
-
Saisi.
Une ligne est enregistrée dans le journal des événements chaque fois qu’une ligne de retour est créée à partir du duplicata d’un ticket.
Paramétrage préalable et fonctionnement
Back-Office > Administration > Société > Paramètres société
Un paramètre société, disponible dans la branche Gestion commerciale > Front-Office, permet de différencier les tickets originaux des réimpressions (duplicatas). Cliquez ici pour en savoir plus.