Version 3.42

Interface MCOMM – Prestashop : ajouté une balise <unite_gestion> qui contient désormais le champ Article.Unite_Gestion. La balise existante <unity> contient toujours le champ Article.Unite qui correspond à l'unité de mesure.

Suite aux modifications effectuées sur l'aspect visuel, la fonction de visualisation de l'arbre des catégories disponible depuis le module MCOMM ne fonctionnait plus.

En vente directe, les chèques restaurants millésimes 2021 ne peuvent pas être utilisés à cause d'un calcul erroné sur la date limite de validité.

Lors d'une opération de collecte avec un monnayeur CI5 terminée en erreur 12 parce que le COFT était plein, le statut de l'appareil passe en 026 (Waiting Removal COFT). Dans ce cas, le mouvement financier de correction automatique suite à l'erreur 12 était enregistré et un mouvement financier de collecte était également généré.

La largeur minimale des fenêtres de saisie des documents de gestion était incorrecte (trop faible).

En vente directe, lorsqu'un ticket était soldé avec une contrainte vendeur stricte, la fenêtre de sélection des vendeurs était affiché mais l'afficheur client continuait à afficher les totaux du dernier ticket indéfiniment. Dorénavant, un timer est engagé selon la valeur prévue dans le centre d'encaissement, onglet <Message/Impressions>, section <Afficher client – Message d'attente>, <Délai avant message ou RAZ>.

Lorsque le système d'impression des étiquettes de frais était activé en mode automatique sur un TPV balance de type PRECIA CS1100/1200, lorsqu'une série de pesée était terminée par le bouton <Abandonner la transaction> afin de passer sur un autre numéro de lot par exemple, si le produit suivant pesé était le même que celui de la série précédente, la fenêtre de saisie des informations de fraîcheur n'était pas affichée.

Lorsque le système d'impression des étiquettes de frais était activé en mode automatique sur un TPV balance de type PRECIA CS1100/1200, lorsqu'un produit était pesé avec une tare prédéfinie configurée dans la fiche produit, la pesée initiale était correcte mais lorsqu'une série de pesées étaient effectuées ensuite sur le même produit, les pesées suivantes ne tenaient plus compte de la tare prédéfinie.

Lorsque la nouvelle option <Outils> - <Recalculs/Contrôle>, <Articles – Contrôle des fiches> était appelée, les champs contenant les informations tarifaires n'étaient pas calculés (pahtnet, prht, etc)

Lors des transmissions par des modules FCOMM/BCOMM de tickets saisis en mode ECOLE, si le ticket reçu était déjà flagé en __Ticket_Origine_Ticket_DISTANT_ECOLE (ticket_entete.origine_ticket=11), comme dans le cas d'un ticket saisi en mode école sur une caisse, réceptionné par un module BCOMM et réémis vers un Super-Serveur par exemple, le ticket se retrouvait à nouveau flagé en __Ticket_Origine_Ticket_DISTANT (ticket_entete.origine_ticket = 1) et il était donc pris à nouveau en compte dans les différents documents statistiques. Ce bug concerne les modules BCOMM et BMDCOMM.

Dans le calendrier affiché en popup sur les zones de saisies de dates, la numérotation des semaines ne respectait pas la norme ISO 8601.

Un message d'erreur du type « (2019,53,3) n'est pas un triplet DateWeek correct » était affiché lorsqu'une stat générale de caisse était effectuée sur la période allant du 28/12/2020 au 03/01/2021 avec l'option de calcul comparatif activée sur l'item <Même période – Année N-1>. En effet, pour effectuer une comparaison, KWISATZ cherche le même jour de la même semaine (exemple le jeudi 5 novembre 2020 appartient à la semaine 45 de 2020 et il sera donc comparé au 07/11/2019 qui correspond au jeudi de la semaine 45 pour 2019) mais dans le cas des journées du 28/12/2020 au 03/01/2021 qui appartiennent à la semaine 53 de 2020, cet algorithme échouait d'où l'erreur. Dorénavant, un message d'avertissement indique qu'il faut utiliser la comparaison de type <Période personnalisée>.

Le message d'erreur précédent était également affiché lors d'une clôture journalière sur la période qui pose problème.

Clôture de journée : dans le cas de la toute première clôture journalière effectuée sur un dossier, ajouté un test pour forcer la saisie d'une date de début de mois (le jour doit être systématiquement égal à 1). En effet, toutes les dates étaient autorisées lors de la première opération de clôture mais si elle n'était pas alignée sur un début de mois, alors les clôtures mensuelles et donc annuelles ne pouvaient pas être effectuées.

Après la clôture journalière d'une journée J-1 sur un dossier utilisant une heure de fin de journée différente de minuit, les fonctions de corrections administratives ou de correction des moyens de paiements étaient refusées sur les ticket de la journée J non clôturée.

Lors de l'utilisation d'un TPV balance de type PRECIA CS1100 pour effectuer de l’étiquetage de produits frais, l'effacement de la première pesée d'une série avait pour conséquence, l'effacement de toutes les pesées de la série et l'effacement d'une pesée quelconque de la série était rejeté avec un message incohérent du type <Annulation refusée - Cette ligne a fait l''objet d''un partage de note>.

Lors de l'impression des étiquettes de frais depuis un TPV balance de type PRECIA CS1100, après l'impression d'une série d'étiquettes sur un produit configuré avec une tare prédéfinie, cette tare était appliquée à la série suivante, même lorsque l'article suivant pesé était configuré sans aucune tare.

En vente directe, lors de l'appel d'un produit depuis un centre d'encaissement paramétré en mode <Borne d'interrogation de prix> ou <Balance self service>, les traitements liés à la présence d'une consigne, d'une tare prédéfinie, la gestion des Kit1 ou Kit2, ou la détection des opérations spéciales étaient malgré tout effectuées alors que ces modes ne déclenchent aucune ligne de vente.

En vente directe, lorsque le libellé d'un produit contenait un caractère &, celui-ci était considéré comme un marqueur de touche d'accélérateur et l'affichage du produit dans le buffer de la caisse était donc incorrect.

En vente directe, l'amélioration apportée le 21/10/2020 dans le cadre des systèmes destinés au dépôt/vente (groupements de producteurs) pour la fonction REMISE fonctionnait au niveau de l'article mais ne fonctionnait pas si la remise était appliquée à l'ensemble du ticket.

Lors de l'export de produits vers PRESTASHOP, le code interne transmis dans le champ EAN pouvait provoquer des erreurs d'intégration s'il était alphanumérique ou dépassait la taille limite de 13 caractères.

Vente directe – Edition du journal des réservations : si on appliquait une condition sur les articles (code_rayon=xxx, code_famille=xxx, par exemple) dans la zone Filtre, dans le cas de commentaires associés aux articles, la procédure d'association ne fonctionnait pas et les articles apparaissaient dans le journal des réservations sans aucun commentaire.

Vente directe – Gestion des réservations : lorsqu'on rappelait un ticket de réservation avec la fonction <149 - Ticket de réservation – Corriger>, après la sauvegarde du ticket corrigé, si une contrainte vendeur stricte était présente, un message du type < Lecture du ticket impossible - Ce ticket est déjà ouvert par l'utilisateur ...> était affiché.

Vente directe – Gestion des réservations : lorsqu'on rappelait un ticket de réservation avec la fonction <149 - Ticket de réservation – Corriger>, il n'était pas possible d'associer un commentaire article à une vente, seul les commentaires tickets étaient autorisés.

Vente directe – Gestion des réservations : lorsqu'on rappelait un ticket de réservation avec la fonction <149 - Ticket de réservation – Corriger>, lors de la sauvegarde du ticket corrigé, si le ticket contenait des lignes de commentaires, ceux-ci étaient mémorisées comme des lignes de ventes et apparaissaient ainsi lors de l'impression du ticket ou dans le journal de réservation.

Lors de l'exécution de KWISATZ en mode tactile (option -T), le clavier alphanumérique était affiché systématiquement au dessus de la barre de statuts de la fenêtre principale, que cette barre soit visible ou non.

PRECIA – Balance TPV CS1100/CS1200 : suite aux anomalies détectées sur les modèles CS1200 équipé du processeur I3, ajouté dans la fenêtre de configuration des périphériques, une case à cocher <PRECIA – Utiliser le jeu de fonctions étendues CS1200>. Lorsque cette case est cochée les 2 nouvelles commandes disponibles sont utilisées à la place des anciennes.

Sur les TPV Aurès Yuno ou les TPV PRECIA CS1200 équipés d'un double écran, lorsque KWISATZ était lancé en mode automate -A2000 ou -A250, l'écran de caisse apparaissait sur le second écran.

En vente directe, les contrôles effectués pour empêcher l'ouverture d'un même ticket simultanément depuis plusieurs postes, comportaient certaines failles qui ont été corrigées :

1. Si le même vendeur cherchait à entrer simultanément depuis P1 et P2, il était rejeté sur P2 mais s'il quittait la caisse et entrait à nouveau, le contrôle n'était plus présent.

2. Le même ticket en attente mis en attente précédemment pouvait être rappelé simultanément depuis P1 et P2.

3. Lorsqu'un vendeur ouvrait un ticket « normal » depuis un centre en mode ouverture <Table> en cliquant sur le bouton <Annuler> de la fenêtre de sélection des tables, le contrôle était carrément inopérant.

4. Anomalie : lorsqu'un vendeur commençait à saisir un ticket depuis un centre sans aucune contrainte vendeur, s'il cliquait à nouveau sur son propre bouton vendeur ou s'il utilisait la fonction <Sélection vendeur> pour s'appeler à nouveau, le message de contrôle était affiché.

5. Après la mise en attente d'un ticket sur P1, le ticket mis en attente disparaît et le nouveau ticket reste engagé sur le vendeur actif mais il n'est pas protégé, ce qui permet au même vendeur de se logger sur P2 et de saisir un autre ticket.