Caisse V 3.0.x

Version 3.0.0

Evolution pour la réforme fiscale

Lectures des code-barres multiples

Gestion de plusieurs lecteurs code-barres

Gestion des promotions locales en plus de celles du siège social.

Lors d’un règlement CB, apparition d’une fenêtre avec l’image du TPE Ict220 invitant l’utilisateur à annuler le paiement sur le terminal bancaire.

 

Version 3.0.1

 

Création d’un exécutable « SauvegardeBdd » appelable depuis le planificateur de tâche afin de faire des sauvegardes de la base Postgres en automatique.

Problème : sur écran fin journée l’appui du bouton « Clôture » affiche une Exception .Net à propos d’un ArrayList modifié

Solution :

  • FormTacticash et FormCaisseEnregistreuse appelent respectivement leur event onClosing. (Traitement permettant d’interdire la fermeture de l’application si un ticket est en cours de saisi). Donc suppression de ce traitement redondant pour FormTacticash.
  • De plus FormTacticash appelle onClosed pour détruire l’écran Wpf d’attente de traitement des clôtures et archives fiscales.

 

Problème : un ticket encaissé au monnayeur peut rester avec le code état « En attente »

Cause : si le client a mis l’appoint dans le monnayeur et que l’hôtesse de caisse appuie sur la touche « Glory Espèce » la validation de la demande de paiement (EventStatusChange =2) et l’évènement « CashTransactionCompleted » arrivent simultanément. Le premier pour mettre le ticket en attente, l’autre pour l’encaisser. Ceci est d’autant plus vrai avec les FCC x86 qui sont plus rapide.

Solution :

  • La fonction « ControleurEncaissement.enregistrerTicket » est une méthode privée maintenant. Elle est uniquement appelée par la méthode « encaisserTicket » dont le nouveau paramètre « traitementEncaissement » permet de réaliser l’encaissement d’un ticket + afficher LCD + impression ticket … ou si ce paramètre à pour valeur « 0 » de procéder uniquement à l’appel de la méthode « enregistrerTicket ».
  • La fonction « ControleurEncaissement.encaisserTicket » dispose d’un lock sur l’ensemble des traitements de cette fonction afin de protéger de l’accès simultané par des threads du monnayeur.
  • La fonction « Ticket.setTicket » ne vérifie plus les minutes et secondes avant l’ajout d’un nouveau code état du ticket à son historique.

 

Version 3.0.2

 

L’événement de fermeture de caisse dans la piste d’audit ne s’enregistrait pas

La saisie de mot de passe ne fonctionnait pas, car le clavier visuel est passé en majuscule (plus de visibilité), mais les mots de passe sont en minuscule.

Sur le Z de fin de journée, impression de la liste des tickets restaurant scannés

Correction édition du C.A. / employé

Ecran de sauvegarde ne se lançait pas

 

Version 3.0.3

Dans le menu « Traitements à Recherche ticket » ajout d’une édition pour imprimer la liste des tickets (entête + ligne)

Dans le menu  » Traitements à Historique cartes fidélité » ajout en fin d’édition du total global des rechargement et transfert de point en fin d’édition

Version 3.0.4

La création des archives fiscales ne s’effectuait pas à partir d’un chemin réseau. Correctif sur la vérification du chemin : ControleurArchive. private bool dossierExportExiste(string cheminExport, out string messageErreur)

Version 3.0.5

  • Problème ticket balance Précia avec la fonctionnalité multi-codebarre.

Lorsqu’un ticket de la balance (mode ticket) est scanné en caisse, un autre article est ajouté au ticket de Tacticash. Ceci vient du fait que rien ne distingue un code barre d’un ticket balance d’un code barre article.

Ex :         code barre du ticket balance precia 0100160003153

Article trouvé par la caisse lors du scan du code barre Precia

Ref : SL64267 La Salamandre Junior (magazine) code barre : 378065460590100160

Rappel : Lors du scannage du Cb, la caisse vérifie si les 13 caractères du Cb correspondent à un article, puis les 7, et si rien n’est trouvé on vérifie les tickets balance sur le lecteur réseau

Recherche avant modif par le programme

where code_barre_multiple like ‘%codeBarre|%’

Problème de cette version dès qu’on recherche un code barre il peut être n’importe où dans la string du Cb

Recherche après modif

where (code_barre_multiple like ‘codeBarre|%’ or code_barre_multiple like E’%\r\ncodeBarre|%’) »

Avec cette version on recherche que les Cb complet et non un morceau de chaîne de caractères

 

  • Quand on annule un ticket Glory et qu’on le recharge, si on ajoute un article au poids, la fenêtre de saisi de la qté ne s’affiche pas. Par contre sur un nouveau ticket suivant ça fonctionne.

 

  • Ecran recherche « historique carte fidélité » limité la sélection aux clients qui appartiennent au magasin.

 

  • Ecran recherche ticket, remplacement de la liste déroulante des clients, par un bouton permettant de rechercher un client selon son nom ou prénom. Cette Recherche client est limité aux clients appartenant uniquement au magasin.

 

  • Le nombre de couverts imprimé sur le Z de caisse ne tient pas compte des tickets supprimés (Cantine bio).

 

  • Le nombre de ticket imprimé sur le Z ne tient pas compte des tickets supprimés

Version 3.0.6

 

Correctif : Ne plus afficher l’écran d’attente d’encaissement lorsqu’un ticket est mis en attente dû au ChangeRequest accepté (ControleurEncaissement.encaisserTicket). L’écran apparait et disparait tellement vite qu’il ne sert à rien de l’afficher.

Correctif : NullReferenceException lors de la sélection d’une ligne dans la nouvelle grille. Suppression du bloc System.Windows.Application.Current.Dispatcher.BeginInvoke dans EnteteTicketVM.pLigneTicketASelectionner

Correctif : Entre l’appui de la touche « Glory ESP » et l’acceptation du ChangeRequest qui enregistre « En Attente » le ticket, l’utilisateur continue de typer des articles qu’il pense appartenir au nouveau ticket suivant, alors que ces articles continuent de s’ajouter au ticket en cours d’acceptation par le monnayeur. Exemple : ainsi un ticket contenant un croissant à 1€ envoyé au monnayeur, mais pas encore accepté, l’utilisateur appuie sur la touche baguette 0.95€. La baguette est ajoutée avec le croissant, le client paye 1€ tout va bien côté monnayeur, cependant le montant du ticket est passé à 1.95€ donc la caisse affiche un message indiquant que le ticket ne sera pas encaissé (car pas assez payé). Le ticket reste en attente et sera supprimé automatiquement le soir lors du clic sur le bouton « fin journée ».

Solution : Dès l’appui de la touche « Glory ESP » il faut verrouiller le ticket afin qu’aucun autre article ne soit ajouté sauf si le demande de paiement est refusée par le monnayeur.

 

Nouvelle variable

Ticket.changeRequestMonnayeurEnvoyeVerrouillerTicket=false;

Affectée à true juste avant l’envoie du ChangeRequest au monnayeur

FormMultiReglementGlory.btValider_Click()

ControleurEncaissement.encaisserTicketViaGlory()

Nouvelle variable utilisée

Ticket.peutModifierTicket()

Impossible de modifier un ticket qui été envoyé au monnayeur. Sauf si le ChangeRequest n’a pas été accepté.

 

ControleurCaisseEnregistreuse.monnayeurGlory_onCashTransactionTerminee()

Si ChangeRequest refusé ticket.changeRequestMonnayeurEnvoyeVerrouillerTicket repasse à la valeur false afin de permettre la modification du ticket qui est resté à l’écran (non mis en attente)

 

FormCaisseEnregistreuse.pGloryCashDrawer_onCashTransactionTerminee

Proposer de recharger ou supprimer le ticket uniquement si l’état ticket n’est pas resté à NOUVEAU (ChangeRequest refusé par le monnayeur) donc le ticket est resté à l’écran

 

EnteteTicketVM.pModeReglementUtilise

Afficher que le ticket a été envoyé au monnayeur

 

 

LibrairieGloryFcc v3.1

 

GloryCashChangeRequest.changeOperationResponseCompleted()

Lors du fireCashTransactionTerminee envoyer soit le ticketEnCours d’encaissement (comme avant) soit le ticket qui a fait l’objet du ChangeRequest (nouveau)

 

Si Exclusive Error (11) (demande de Change refusée) la variable pRequeteHttpEnCours passe à false. Afin de rafraichir les boutons ESP Glory du POS

 

Version 3.0.7

 

Modification de la lecture de l’historique glory. Car Certains opérations retournent un différentiel à 0. Plus modification de la requête sql pour prendre également les différentiels sur RESET

ControleurCaisseEnregistreuse.getHistoriqueMonnayeur

ControleurZ.calculDetailHistoriqueMonnayeur

 

Version 3.0.8

Correctif : Sur le Z de caisse, la ligne « Dont Espèce Manuel » ne tient pas compte du cas suivant :

  • Ticket réalisé, puis appui sur la touche « ESP Glory »
  • Annulation de la transaction monnayeur
  • Lorsque le message en bas de l’écran demande de recharger ou supprimer le ticket, l’utilisateur recharge le ticket
  • L’utilisateur appui sur la touche « ESP » manuel

Correctif : Connexion à eboo Serveur

 

Version 3.0.9

Correctif du problème suivant : Sur carte fidélité, possibilité d’avoir un multi-règlement :

  • Règlement en CF
  • Transfert de point

Puis annulation sur l’écran de rechargement de la carte fidélité. Le ticket est alors encaissé puis supprimé (encaissé en négatif). Le calcul du solde des points CF est alors faux et devient négatif

  • ajouterReglement(ModeReglement modeReglement, decimal montant, Reglement.TypeReglement typeReglement)

Supprimer tous les règlements avant l’ajout de celui demandé uniquement s’il s’agit d’un rechargement carte fidélité ou transfert point

 

 

  • appelFonctionCaisse case CARTE_FIDELITE_RECHARGEMENT :

Avant ouverture de l’écran de rechargement appel de Caisse.caissePrincipale.getTicket().supprimerReglement(); afin de supprimer tous les règlements

 

 

  • btAnnuler_Click()

Sur fermeture de l’écran ne plus annuler le ticket, mais annuler les lignes de rechargement et ou de transfert points.

 

Correctif du problème suivant : Possibilité d’effectuer un rechargement de carte fidélité d’un compte client qui n’en est pas un. Le compte était un client facturable à terme

  • caissePrincipale_onTicketModifier

Fonction appelée lors du scan du code-barre de la carte client, vérifier que le compte client est bien une carte fidélité et non un client facturable à terme.

 

Correctif mot de passe client : Le bouton client situé en dessous en haut à gauche de l’écran (sous la grille des lignes ticket typés) ne demandait pas le mot de passe si celui-ci était paramétré sur le fonction « CLIENT ».

Ecran Magasin : masquage des mots de passe :

  • mdp générale demandé avec le même écran que celui de la caisse.
  • Dans la liste des fonctionnalités, affichage des caractères « x »
  • idem pour la changement du mot de passe pour les fonctionnalités

 

Version 3.1

 

Correctif du cas suivant :

  • Si on règle un ticket en CB avec la liaison TPE.
  • On annule la transaction TPE
  • Et on paye via le monnayeur
  • Le ticket contient 2 règlements un en CB et un en ESP pour le même montant

Dans ControleurEncaissement.encaisserTicketViaTPE ne pas ajouter le règlement CB lors de l’envoie du montant au TPE. C’est trop tôt car la transaction bancaire peut être refusée par la banque ou annulée par l’utilisateur.

Dans ControleurCaisseEnregistreuse.terminalCb_onFinTransactionBancaire ajouter le règlement en CB ou CHQ uniquement si le terminal à valider la transaction

Correctif du cas suivant :

Ticket encaissé en CB, rappelé puis modification du mode de règlement en Crédit émis. Le ticket n’apparait pas dans la liste des crédits à reprendre.

Nouvelle fonctionnalité liée au ticket restaurant :

Impression sur le ticket de caisse des articles éligibles au paiement par ticket resto + sous-total uniquement si le ticket a été réglé avec des titres restaurant.

Refus des tickets resto le Dimanche

Règlement autorisé en ticket restaurant dans la limite des articles éligibles mais plafonné à 19€. Ces données apparaissent dans l’écran multi-règlement.

 

 

Version 3.2

 

Si caisse connectée au monnayeur :

  • Sur l’écran d’ouverture, le bouton « Ouvrir caisse » reste désactivé jusqu’à la réception du fond de caisse du monnayeur. Le temps d’attente est de 10 secondes maximum au cas où le monnayeur soit inaccessible ou en panne.
  • S’il existe des tickets encaissés en espèce manuel, obliger l’utilisateur à recharger cette somme dans le monnayeur. Cette opération est déclenchée lors du clic du bouton « Collecte » et « Rechargement » du menu Administration du monnayeur. Cette option activable par la case à cocher  » Sur la Collecte, recharger les espèces manuelle dans le monnayeur » dans le menu « Fichier à Tiers à Magasin » de la caisse.

Lors de l’impression du Z sur la Caisse N°1 et si le magasin dispose de plusieurs caisses :

  • 2ème Z s’imprime automatiquement: il s’agit du Z globale du jour du magasin.
  • 3ème Z s’imprime automatiquement : il s’agit du Z globale du mois du magasin, uniquement si on est le dernier jour du mois.

Cette option activable par les cases à cocher « Imprimer le Z multi-caisses global du jour » et « Imprimer le Z multi-caisses global du mois » dans le menu « Fichier à Tiers à Magasin » de la caisse.

  • Sur le Z, imprimer les totaux sans tenir compte des Chèques termes (CHT) pour le total du C.A. par famille et son détail pour chaque famille principale, ainsi que le TVA et son détail par taxe

Z avec détail des Opérations monnayeur :

  • Pour une caisse (déjà existant dans les anciennes versions du programme)
  • Par ouverture de caisse ou jour : détail des opérations par heure
  • Par mois : détail des opérations pour chaque jour et par heure
  • Pour toutes les caisses (nouveauté)
  • Par jour ou mois : cumule des opérations, sans affichage des fonds de caisse début et fin.

Titre restaurant

Mise à jour de la détection des titres restaurant lors du scannage du code à barres. Les titres des services sont détectés.

CB sans contact

Gestion du protocole « E+ », permettant de distinguer un règlement « CB » d’un « CB sans contact ».

Correctif :

Si l’utilisateur clique sur le menu caisse à ouvrir alors que le caisse est déjà ouverte la reconnexion aux périphériques de caisse est de nouveau réalisée. Ainsi lors du scan d’un code barre, l’article est ajouté 2 fois au ticket.

 

 

Version 3.3

 

Ajout de la fonctionnalité Ticket 5 à 8 en plus des ticket 1 à 4. Ainsi 8 vendeurs différent peuvent utiliser la caisse.

Dépense de caisse : saisi de l’employé obligatoire, si le motif de la dépense exige de saisir la ventilation des espèces, un écran s’ouvre automatiquement permettant de saisir les quantités par dénomination. Après validation, un ticket s’imprime en double exemplaire.

 

Version 3.4

 

Le montant des règlements en ticket resto (scanné ou non) peut dépasser la valeur du montant éligible et le plafond maxi de 19€. Le supplément pourra donc donner lieu à un crédit émis sur TR (imprimer sur le ticket de caisse). L’écran multi-règlement affiche donc maintenant le total des titres scannés, le montant du règlement retenu par la législation (< 19€ et < au mnt des produits éligibles) ainsi que le trop-perçu pour la génération de l’avoir.

 

L’enregistrement des titres resto scannés s’effectue sur l’enregistrement des règlements et non sur l’entête des tickets. Ainsi suit à un rappel ticket il est possible de compléter les règlements par d’autres titre scannable (TRE, ATR, BOA). Attention, tout titre scanné et encaissé n’est pas supprimable.

Sur le Z, le montant des nouveaux avoirs sur Titre restaurant ne tenait pas compte de ceux créez et utilisé partiellement dans la même journée.

Ajout d’une heure début et fin (facultatif) pour les promotions.

 

Version 3.5

Intégration des Terminaux bancaires de la marque : Vérifone

Possibilité de procéder à un crédit repris via monnayeur alors que le ticket a été encaissé partiellement en crédit émis.

 

Version 3.6

 

Correctif de la librairie Glory, afin de lire la version du Fcc (ex : Ver.9.10R0) car certaine version du Fcc ont un numéro de révision.

Correctif de la librairie pour la piste d’audit : Si rappel ou duplicata d’un ticket d’une autre caisse, possibilité d’affichage d’une clé dupliquée. Car le numéro de la piste d’audit concerne la caisse qui effectue l’opération, alors que le numéro de caisse pris pour « insert » était celui qui a créé le ticket.

Intégration de la mise à jour automatique de la bdd suit à un changement de version du programme.

 

Si scanner en mode clavier les titre restaurant scannés apparaissent en double sur le Z. Donc retirer les doublons.

Supprimer du menu Bordereau CRT puisqu’il existe dans Gc5

Correctif : Archive fiscale dans DropBox la suppression des dossier pour le zip ne s’effectue pas correctement à cause de la synchronisation automatique de dropbox.

Version 3.6.1

Lors d’un scan d’un titre resto, si l’émetteur n’est pas trouvé affecté « Inconnu » au titre restaurant.

Version 3.6.2

Correctif : Sur mode administration fonctionnalité « Nouveau bouton article » :

  • Ne pas afficher les articles supprimés
  • Ne pas afficher la fiche article sur double clic, car elle apparaissait derrière l’écran de recherche, l’utilisateur se retrouvait alors bloqué

Correctifs liés au monnayeur

  • Crédit repris en multi-règlement : (ex : on reprend un crédit avec une partie en CB et le reste en ESP via monnayeur). Erreur sur l’enregistrement du règlement (sql existe déjà). Car la CB est déjà enregistrée lors de la mise en attente du ticket pour reprendre le reste en ESP via le monnayeur.

ControleurEncaissement.ajouterReglementPourSolderCredit()

Si l’encaissement du crédit repris se fait via le monnayeur prendre uniquement le mode de règlement espèce. Car celui en CB est déjà enregistré

  • Crédit repris en multi-règlement non autorisé : l’utilisateur souhaite reprendre un crédit avec une partie en CB et le reste en ESP via monnayeur. Sauf que cette opération n’est pas autorisée (autoriserMultiCreditRepris = false). L’écran FormMultiReglementGlory permettait de faire une partie en CB le reste via le monnayeur. Sauf que lors de la validation du paiement par le monnayeur, le ticket ne pouvait s’enregistrer car 2 modes de règlement en crédit repris n’était pas autorisé. Maintenant, la vérification s’effectue au moment du clic du bouton d’encaissement de l’écran FormMultiReglementGlory.btValider_Click()

 

  • Lors d’un crédit repris au monnayeur qu’il soit en multi-règlement ou non : il n’était pas indiqué au ticket que la monnaie était passée par le monnayeur. Ainsi la somme était ajoutée à la ligne « Dont Espèce manuel »

ChaineSqlGc.updateResteAPayer()

Si crédit repris au monnayeur enregistrer le résultat de la transaction monnayeur

  • Sur le Z le montant « Dont espèce manuel » potentiellement erroné : Cas identique à la version 3.0.6. Entre l’appui de la touche « Glory ESP » et l’acceptation du ChangeRequest qui enregistre « En Attente » le ticket. L’utilisateur appuie sur la touche ESP. Le ticket est donc enregistré en espèce manuel alors que l’argent est bien encaissé par le monnayeur.

Donc autoriser l’appel des fonctions de caisse (annuler ticket, annuler ligne, ticket 1 …) et l’appel des encaissements (bouton ESP, CB, CHQ …) uniquement si

ticketEnCours.changeRequestMonnayeurEnvoyeVerrouillerTicket == false

PanelControlVisuel.appelModeReglement()

PanelControlVisuel.appelFonctionCaisse()

Liaison avec l’évènement du monnayeur « onFccConnexionStatusChanged ». Si déconnexion du FCC, libérer le ticket :

ticketEnCours.changeRequestMonnayeurEnvoyeVerrouillerTicket = false

 

 

Version 3.6.3

 

Erreur de manière aléatoire, le client a inséré sa monnaie pour payer, mais impossible d’encaisser le ticket. Les touches de la caisses (article, ESP, CB …) ne répondent plus. Le fenêtre d’encaissement ne s’ouvre pas en bas à gauche. Pourtant à droite de l’inventaire, on visualise bien le montant total inséré (icône avec la main)

Cause : erreur introduite dans la 3.0.6. Avant d’envoyer un « Change request » au monnayeur la variable « changeRequestMonnayeurEnvoyeVerrouillerTicket » qui bloque le ticket en lecture seule est positionné à true de manière trop optimiste. En effet, avant d’envoyer le « Change request » je vérifie les codes état du monnayeur. Ainsi lors du clic sur la touche « ESP GLORY » le requête peut ne pas être envoyée alors que le ticket est bloqué en lecture seule. Erreur aggravée par la 3.6.2 . Comme cette variable bloque également l’accès aux touches de fonctionnalités de la caisse (article, ESP, CB, annuler ligne ou ticket …) l’utilisateur se retrouve bloqué.

 

Version 3.6.4

 

Si ticket encaissé en CB puis rappelé pour être ré-encaissé via le monnayeur, le ticket est détecté comme « espèce manuel » sur le Z. En effet un ticket encaissé est signé numériquement (réforme 2018). Donc l’entête du ticket n’était pas mis à jour des données provenant du monnayeur.

 

Version 3.6.5

 

Sur le Z par jour de l’ensemble des caisses, ajouter le cumul de toutes les opérations monnayeur (même les différentiels), ainsi que le cumul des fonds de caisse :

  • Fond de caisse début : 1er fond de caisse de toutes les caisses
  • Fond de caisse fin : dernier fond de caisse de toutes les caisses

 

Si Erreur N°13 (STATUS_RESPONSE.AUTO_RECOVERY_FAILURE) lors d’un encaissement, le ticket est tout de même encaissé. Donc ne pas l’intégrer dans les espèces manuelles

 

Version 3.6.6

Sur Z globale multi-caisse, trier les opérations monnayeur

Si Erreur N°10 (STATUS_RESPONSE.CHANGE_SHORTAGE) lors d’un encaissement, le ticket est tout de même encaissé. Donc ne pas l’intégrer dans les espèces manuelles

 

Version 3.6.7

Dans écran multi-règlement, si des titres restaurant sont scannés, il est impossible de modifier manuellement le montant globale des TRE.