Version 3.39

Pour les documents de type <Chèque cadeau (fidélité) = *.097> ou <Chèque cadeau (vente) = *.039>, les composants de type <Code à barres> basés sur le nouveau champ d'identification GUID_CHRONO étaient systématiquement imprimés en mode Alpha39 sans tenir compte du paramétrage effectué dans le document.

En vente directe, les chèques restaurant millésime 2020 émis par EDENRED étaient refusés car le code à barres contient 20 caractères au lieu de 24. Il semble que EDENRED soit revenu au format de 2010 !!

En vente directe, lorsque le plan de salle était appelé depuis la liste des tables, un message d'erreur <Impossible de focaliser une fenêtre désactivée ou invisible> était affiché à chaque minute.

Suite aux améliorations appliquées à l'ensemble des éditions en 06/2019, les états d'inventaires ne tenaient plus compte des présélections effectuées avec les zones <Statut des article>, <Période du>, <Période au> et <N° Préparation>.

Dans la fiche client, la position de l'onglet <RGPD> n'était pas mémorisée.

Détecté lors des tests effectués. Dans WKW_MCOMM, lorsque l'appel à une fonction échouait suite à une erreur du serveur, la feuille XML de débuggage (qui aurait dû être vide) renvoyait en fait le contenu de la réponse au dernier appel réussi. Le contenu des messages renvoyés en cas d'échec avec l'interface MAGENTO a été aligné à ce qui existait déjà pour les autres interfaces.

Lors de l'envoi d'emails générés à partir d'un document générateur QRD, un fichier temporaire Current_Email_xxx.html (avec xxx=numéro de poste) était crée à la racine du disque dur hébergeant le logiciel ce qui pouvait poser problème dans le cas d'un disque non partagé.

Lors de l'envoi d'emails multiples depuis <Clients>, <Impressions>, <Courriers, Fiches, Etiquettes> à l'aide du bouton <Envoyer par Email>, la gauge d'avancement ne renvoyait aucune information.

Dans WKW_MCOMM en mode WooCommerce, lors de l'export des articles, si le tarif exporté était le tarif n°1, une erreur d'affectation du champ CODETVA était affichée.

En vente directe, lorsque la liste des tables était affichée, la valeur du totalisateur de la colonne « TABLE » qui était censé indiquer le nombre de table était minoré systématiquement de 1.

Lors de l'export des données articles vers les balances data-collect de type EXA, un message <Création des données d'export effectuée avec succès> était affiché même lorsque l'opération était effectuée depuis l'automate -A180.

Dans certains cas, l'utilisation de claviers tactiles dont la capacité lignes x colonnes dépassait la limite de 150 touches, pouvait provoquer des violations d'accès. (détecté avec un dossier utilisant une dalle de 10 lignes x 16 colonnes).

Appliqué le correctif, aux claviers tactiles auto-remplissable qui étaient concernés de la même façon.

Dans le paramétrage des claviers tactiles, les zones <Espacement> prévues pour indiquer le nombre de pixels horizontaux et verticaux laissés entre les boutons acceptaient la valeur 0 mais l'interprétaient comme 1. Dorénavant, la valeur 0 peut être appliquée et les boutons sont alors collés les uns aux autres.

En vente directe, suite à la modification concernant l'affichage des claviers tactiles, lorsque le paramètre -CT était affecté à une touche d'appel PLU, le clavier appelé s'affichait systématiquement sur le clavier appelant. Dorénavant, les paramètres -CTC et -CTN disponibles pour les chainages de claviers sont également disponibles pour les appels PLU. Par compatibilité, le paramètre obsolète -CT est toujours interprété.

Lors de la saisie d'un prélèvement ou d'un décompte à l'extérieur du module de vente directe, (depuis <Vente directe>, <Procédures>), l'entête du ticket n'était pas imprimé. Provoquait une violation d'accès.

TPV Balance Precia CS1100 : lors de la saisie d'un prélèvement ou d'un décompte à l'extérieur du module de vente directe, (depuis <Vente directe>, <Procédures>), l'impression provoquait une violation d'accès.

Lors de l'utilisation de concentration de dossiers avec l'automate de concentration -A150, l'intégration de tickets contenant des versements sur compte qui avaient été réaffectés à un document de gestion, déclenchait une erreur de doublon.

Llors de l'utilisation de concentration de dossiers avec l'automate de concentration -A150, si le fichier de configuration CONCENTRATEUR.INI ne contenait pas toutes les sections DOSSIERxx, les indicateurs étaient positionnés à True par défaut et la concentration avait lieu pour les sections manquantes. Ajouté également un item IMPORT_TICKETS permettant d'activer/désactiver l'import des tickets.

En vente directe, lors de la mise en attente d'un ticket avec réaffectation forcée d'un vendeur à l'aide du paramètre -VD, le fichier .BIN d'origine n'était pas effacé et un message d'erreur d'intégrité était affiché.suite à la modification, lorsqu'un article pesable faisait l'objet d'un tarif par quantité, la différence de prix était transformée automatiquement en rabais afin de ne pas interférer avec les informations légales renvoyées par la balance. Mais si le produit pesé faisait l'objet d'une tare automatique, le rabais était également appliqué à la ligne de tare.

En vente directe, le changement de vendeur par lecture de code à barres était refusé après le total du ticket alors qu'il était permis depuis un appel de touche classique.

Sur Interface Ecommerce WOO-Commerce : lors de l'export des produits, les prix étaient transmis HT sans tenir compte de la configuration via l'item <Envoyer les prix TTC>.

Dans la fenêtre de configuration des listes, onglet <Avancée>, la zone <Autoriser le filtrage/colonnes> n'était pas grisée dans le cas des listes qui ne prévoient pas cette possibilité. On pouvait cocher ou décocher la case mais cela n'était pas mémorisé et n'avait donc aucune conséquence.

Sur Interface Ecommerce WOO-Commerce : lors de la lecture d'un bloc de commandes, si une commande déclenchait une erreur lors de l'interprétation de la feuille XML, le résultat global de la fonction était toujours True ce qui conduisait à avoir une intégration partielle dans KWISATZ sans connaître la cause de l'erreur.

Sur Interface Ecommerce WOO-Commerce : lors de l'intégration d'une commande, une commande pouvait être importée sans que son règlement associé ne soit généré.

Les nouveaux champs de la table DOSSIER (EMAIL ou RESPONSABLE_RGPD par exemple) n'étaient pas visibles dans la liste des champs du générateur d'état. En fait, pour les documents de nouvelle génération (FastReport), les nouveaux champs étaient disponibles mais pour les documents d'ancienne génération (QuickReport), ils étaient masqués par défaut et il fallait aller dans <Etat>, <Ensemble de données>, sélectionner la table <DOSSIER>, cliquer sur le bouton <Champs> puis <Ajouter> et sélectionner les champs à ajouter. Dorénavant pour les nouveaux documents, ils sont immédiatement visibles par contre, pour les documents QRD existants, la manip précédente reste nécessaire pour les faire apparaitre.

TPV Balance Precia CS1100 : en vente directe, si un ticket totalisé était mis en attente, le bandeau métrologique restait en mode « message fixe » avec la mention du total du ticket mis en attente. Le ticket vierge était affiché mais aucune pesée n'était plus possible.

Lors de la facturation des tickets en compte, un message de violation d' accès était affiché lorsque la facture générée excédait la limite de 3999 lignes. Réglé en affichant un message d'avertissement et en interrompant la génération de la facture.

Suite au changement de hauteur de la fenêtre de saisie de l'email du 27/01/2020, la case à cocher <Utiliser cet émail comme modèle pour les suivants> n'était plus visible.

Dans l'interface avec la plateforme ADELYA, lors de la transmission de ticket contenant des articles dont le libellé contenait des caractères spéciaux comme le % par exemple, l'intégration par ADELYA échouait.

Lors de la facturation des tickets en compte, le champ CODE_CLIENT appliqué à FAV_ENTETE n'était pas répercuté dans les lignes de ventes de FAV_DETAIL. Découvert pendant le développement des factures de rétrocession des producteurs.

Interface ADELYA : suite à la modification effectuée le 12/03/2020, la fenêtre simplifiée de création d'un client ADELYA prévoyait une zone <EMAIL> mais l'information n'était pas transmise à la plateforme.