Caisse v 2.10.N

Version 2.10

Carte fidélité multi-magasins sur internet.

Version 2.10.3

Faire clignoter le nom du client s’il s’agit d’une carte fidélité.

Case à cocher dans le paramétrage du magasin pour autoriser ou non la vente à perte

Version 2.10.4

Avec le monnayeur, possibilité d’inter blocage sur la fonction d’enregistrement du ticket entre:

• le thread des  « events » qui valide l’acceptation de la demande du ChangeRequest
• et le thread de fin d’encaissement lorsque le client a fini de payer

Ce cas de figure apparait lors d’une transaction très courte, exemple :

• La caissière a typé la baguette à 1€
• Le client a inséré 1€
• La caissière clique que le bouton « Espèce glory »
• Le ticket est donc enregistré une première fois à l’état « en attente » par le thread des event puis parallèlement une 2^ème fois par le thread de fin d’encaissement à l’état « encaissé »

Solution :

• Mise en place d’un lock sur la fonction ControleurEncaissement.enregistrerUnTicket
• Création d’une 3^ème connexion à Postgres pour modifier le fichier « historique_etat_ticket » indiquant que le ticket a été exporté vers Pervasive. Fonction impactée enregistrer
• ControleurEncaissement.exporterTicket, la mise en file d’attente du ticket à exporter vers Magic ne concerne pas les tickets dont l’état est « en attente ». Ceci évite les inter-blocages. Sinon lors du 2^ème enregistrement du ticket à l’état « encaissé », le Thread d’export vers Pervasive veut mettre à jour le fichier « historique état ticket » pour l’état « en attente ». Sauf qu’il ne peut pas car les enregistrements de Postgres sont verrouillés par la transaction de ré-enregistrement du ticket à l’état « encaissé ».
• Dans classe ControleurCaisseEnregistreuse.enregistrer 2^ème connexion à Pervasive et 4^ème connexion à Postgres pour enregistrer les données en la table « historique_glory »

Version 2.10.5

 

• Un compte client peut être dédié à un seul magasin. Ainsi si la zone « numero_magasin_dedie » de la table « client » est renseignée. Les clients ne pourront être affectés à un ticket de caisse que par le magasin désigné.
• Dans écran « Recherche ticket » du menu « Opération de caisse », le bouton « supprimer » a été retiré.
• Lors d’un encaissement avec le mode de règlement « Carte fidélité », si le solde de la carte est insuffisant, le montant même partiel n’est pas affecté au ticket et l’encaissement du ticket est refusé. Il faut donc recharger la carte fidélité pour payer dans un autre mode de règlement.
• Lorsqu’un ticket est lié à une carte fidélité si le solde est insuffisant pour payer le montant du ticket le nom du client cligne en rouge, sinon en vert. Si le solde est insuffisant et que le vendeur clique sur le bouton paiement par Carte fidélité, un seul message d’avertissement apparait au lieu des 3 successifs.
• Lors de l’enregistrement d’un ticket lié à une carte fidélité, le solde initial du crédit et des points de la CF est enregistré dans la table « ticket ».
• Modification de l’édition Crystal Report, afin d’afficher le solde initial et le solde final sur chaque ticket de caisse avec le détail (rechargement, transfert point, cumul point ou transfert)

 

Version 2.10.6

 

• Correctif carte fidélité du cas suivant :
  • Etape 1 : Si encaissement d’un ticket en carte fidélité alors que le solde est insuffisant
  • Etape 2 : Le caissier recharge la carte du client
  • Etape 3 : Le ticket en attente est rappelé pour être encaissé en CFI. A ce moment-là si le ticket qui était en attente possédait un règlement partiel en CFI (due à l’étape 1) ce montant est rajouté au solde de la carte fidélité.
  • Cause: Ceci vient du traitement qui gère le changement d’un mode de règlement d’un ticket encaissé en carte fidélité pour être ré-encaissé dans un autre mode de règlement.
  • Résolution: Re-créditer une carte fidélité lors d’un changement d’un mode de règlement (ex : CFI à ESP) de fait uniquement si l’état du ticket précédent était déjà encaissé, et qu’il est ré-encaissé.
• Un ticket mis en attente n’enregistre plus la ventilation des modes de règlement ça sert à rien.
• Lors de l’impression de la TVA sur le Z, ne pas tenir compte des articles dédié au rechargement et au transfert de point des cartes fidélité.

 

Version 2.10.7

• Lecture des codes-barres Poids/Prix Euro
• Modification du Z et du calcul du C.A. (menu « Opération Caisse ») :

Modification des calculs comme suit :

Le C.A. par  « famille » et par « taxe » ainsi que le « nombre de client » et « panier moyen » : ne prendre que les tickets encaissés avec un mode règlement « PLUS », et ceux qui ne concerne pas les articles CFI (recharge carte), ni CFITRANSPOINT (transfert de point CF)

Le C.A. par règlement : prendre tous les tickets, mais à l’impression ne pas additionner ceux réglés avec un mode de règlement NULL ou en CREDIT_REPRIS.

• Dans la section « ventilation règlement », afficher le montant total des règlements sauf ceux qui ont une *. C’est-à-dire, ceux qui ne représentent pas du C.A. ne sont pas additionnés au total. Il s’agit des :
  • Pertes
  • Ventes manquées
  • Transfert de point sur carte fidélité
  • Les crédits repris : en effet c’est le crédit émis qui a généré du C.A.. Quant au crédit repris, il s’agit d’un apport de trésorerie.
• Dans la section « C.A. par TVA » ajout du montant total ttc.
• Dans la section « Statistiques » modification du calcul du nombre de client.
• Ajout d’une section « Ecart entre règlements et tva » pour justifier l’écart du montant entre le « total règlement » et le « montant total tva » :

Total reglement – rechargement carte fidélité – règlement trop perçu sur ticket = total C.A. qui peut être comparé au « montant total tva ».

 

• Carte fidélité :
  • Impossible de recharger une CF en cheque terme ou crédit émis. Seuls les modes de règlements comptant sont autorisés
  • Sur l’écran de rechargement, vérifier que le montant du rechargement CF ou du transfert de point soit > 0. Ainsi le cas d’un ticket avec une ligne ticket dont le montant est à 0 et le règlement > 0 est évité.
  • N’appliquer aucune remise sur les articles CFI et CFITRANSPOINT