|
689 | 574 | Core | Bug | Critique | Très haute | N'importe pas automatiquement une base de données BeDes ... | Fermée | 16.4 (fork) | 17.0 | |
2016-12-08 |
Description de la tâche
Après mise à jour de OS X, BeDesk 15 ne fonctionne plus.
Si on installe BeDesk 16, celui-ci détecte qu’une anomalie est présente sur la base de données BeDesk 15 et ne l’importe pas automatiquement.
Contournement du problème :
Restaurer manuellement le dernier fichier de sauvegarde que vous aurez réalisé avant la mise à jours de Mac OS X (en l’occurrence Sierra).
Complications :
Si l’utilisateur n’a pas effectué de sauvegarde de sécurité récente avant la mise à jour, et comme le BeDesk 15 ne démarre plus, il n’est plus possible de créer un fichier de sauvegarde à restaurer dans Bedesk 16.
Il fallait faire la mise à jour BeDesk 15 → BeDesk 16 avant de passer à Sierra.
Problème résolu dans BeDesk Express v 17.0
|
|
708 | 574 | Application | Garde-fou | Critique | Très haute | Vérifier le format des noms de base de données avant im ... | Fermée | 16.4 (fork) | 17.0 | |
2016-12-15 |
Description de la tâche
Certains utilisateurs accèdent aux fichiers de travail sur le disque dur via l’explorateur de fichier ou un autre logiciel et modifie les noms des bases de données.
Cela entraîne de nombreux problèmes.
Pour éliminer ces problème, il faut vérifier les noms de base de données avant restauration, avant importation et même avant d’ajouter les bases de données dans la liste proposée par la BeDesk-Starter.
|
|
710 | | Application | Bug | Critique | Très haute | Problème de création des numéros de dossier des nouveau ... | Fermée | | 17.0 | |
2016-12-19 |
Description de la tâche
Problème de création des numéros de dossier des nouveau documents:
Lorsqu’on crée un nouveau document, il prend le numéro de dossier du dernier document précédent.
Problème!...
Confirmé.
Correctif via l’ajout d’un garde-fou (pre-store).
|
|
728 | | Base de données | Bug | Critique | Très haute | Mise à jour upstream KeylistDB : Correctif OpenDDN (err ... | Fermée | | 17.0 | |
2016-12-23 |
Description de la tâche
Mise à jour upstream KeylistDB : Correctif OpenDDN (erreur de déduplication).
|
|
735 | | Application | Bug | Critique | Très haute | Ouverture de rapports sans aperçu visible | Fermée | 17.0 | 17.1 | |
2017-01-09 |
Description de la tâche
Ouverture de rapports sans aperçu visible.
Lorsqu’on ouvre l’outil “Rapports” la vue apparaît sans aperçu du rapport visible. On observe le fond gris uniquement (pas même de roulette de progression).
Toutefois, si on lance une impression, le rapport est bien imprimé.
Le souci se situe probablement dans la pile de tâches du rendu pour afficher l’aperçu.
NOTE : LORSQU’ON MODIFIE LA TAILLE DE LA FENÊTRE, L’APERÇU APPARAÎT.
L’aperçu est donc bien généré en arrière plan, même s’il n’apparaît pas.
Le problème se situe bien dans la pile de tâches de rafraîchissement de l’affichage lors de la création de l’aperçu.
Cette procédure est assez complexe et la dernière phase doit absolument être bloquante afin d’attendre la fin du rendu d’arrière plan.
Corrections réalisées...
Tests nécessaires.
|
|
750 | | Core | Bug | Critique | Très haute | Effet de bord : Référence non dupliquée lors de la mise ... | Fermée | 17.0 | 17.1 | |
2017-01-17 |
Description de la tâche
Lorsqu’on met à jour l’inventaire à partir d’une facture par exemple, la référence des articles n’est pas dupliquée.
Ceci entraîne un effet de bord indirect difficile à repérer car la mise à jour est basée sur la présence ou non de la modification d’une des valeurs de l’enregistrement. Utilisant malheureusement la même référence, l’article est comparé à lui-même. Il apparaît donc actualisé dans l’interface du logiciel, mais la modification (basée sur le différentiel) n’est pas réalisée. La modification n’est donc pas enregistrée. On peut donc constater que la valeur du stock initial est restituée lors du démarrage suivant.
Pour rectifier ce problème, une nouvelle référence doit être créée de manière à dupliquer le contenu de l’article pour pouvoir le comparer ses valeurs précédentes et établir un différentiel.
Ce souci touche aussi la mise à jour des quantités à recevoir (bons de commande d’achat et de réception).
Urgent!...
|
|
760 | 761 | Application | Suivi | Critique | Très haute | FRANCE : Conformité lois des finances 2018 | Fermée | 17.0 | 18.0 | |
2018-01-10 |
Description de la tâche
L’administration a commenté l’obligation pour les assujettis à la TVA en France qui enregistrent les règlements de leurs clients au moyen d’un logiciel de comptabilité ou de gestion ou d’un système de caisse, d’utiliser à partir du 1er janvier 2018, des logiciels ou des systèmes satisfaisant à des conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données.
MISE A JOUR : Novembre 2017
1. Qu'est-ce qu'un logiciel ou système de caisse ?
Éléments de réponse: Un logiciel ou un système de caisse est un système informatisé dans lequel un assujetti enregistre les livraisons de biens et les prestations de services ne donnant pas lieu à facturation au sens du BOI-TVA DECLA-30-20-10. Autrement dit, un logiciel ou un système de caisse est un système informatisé dans lequel un assujetti enregistre les opérations effectuées avec ses clients non assujettis.
Ainsi, les logiciels ou systèmes de caisse dans lesquels sont enregistrées les opérations effectuées avec des clients assujettis à la TVA (clients professionnels) ne relèvent pas du champ d’application du dispositif.
En revanche, ceux dans lesquels sont enregistrées les opérations effectuées avec des clients qui ne sont pas assujettis à la TVA (clients particuliers) relèvent du champ d’application du dispositif.
De la même façon, ceux dans lesquels sont enregistrées à la fois les opérations effectuées avec des clients assujettis à la TVA (clients professionnels) et des non assujettis (clients particuliers) relèvent du champ d’application du dispositif.
Il convient de ne pas tenir compte de la qualification du logiciel (de caisse, comptable ou de gestion) en question, mais de retenir sa fonctionnalité de caisse. Ainsi, un logiciel de gestion qui permet l’enregistrement des opérations de ventes ou de prestations de services qui concernent les non assujettis à la TVA (clients particuliers) doit être considéré comme un logiciel ou un système de caisse visé par le dispositif.
2. Tous les logiciels de gestion commerciale incluant une fonctionnalité de caisse enregistreuse/d'encaissement sont-ils toujours à certifier par leurs éditeurs pour le 1er janvier 2018 ?
Éléments de réponse:
Depuis le 15 juin 2017, seuls les logiciels et systèmes de caisse sont concernés par la mesure, principaux vecteurs des fraudes constatées à la TVA.
Concernant les logiciels multi fonctions (comptabilité/gestion/caisse), seules les fonctions caisse enregistreuse/encaissement, et non l’ensemble du logiciel, devront être certifiées.
Partie II – Éclairage sur les aspects techniques
I Référentiel technique
Éléments de réponse: La loi instaure une obligation de résultat concernant la conformité des logiciels (respect des quatre conditions de la loi : inaltérabilité, sécurisation, conservation, archivage) et non de moyen: elle ne définit pas de cahier des charges, ni de solution technique, contrairement à d’autres dispositifs fiscaux.
L’élaboration de référentiels est donc du ressort des seuls acteurs privés.
II Condition d'inaltérabilité
Éléments de réponse:
L’administration fiscale n’impose aucune solution technique (empreinte électronique, chaînage des opérations...), dès lors qu’aucune norme fiscale a été prévue par le législateur.
Concernant les systèmes de caisse, la garantie d’inaltérabilité peut être obtenue par plusieurs techniques permettant d’une part d’empêcher l’accès de l’utilisateur à des fonctionnalités de modification des données validées et d’autre part de détecter tout accès/modification des données de règlement. Toute modification ou correction doit être détectable.
Le certificat est associé à la capacité de pouvoir démontrer que les données de règlement n’ont pas été modifiées depuis leur enregistrement initial et doit fournir un système de preuve en ce sens.
20. Qu’entend-on par « données permettant d’assurer la traçabilité des données de transaction » ?
Éléments de réponse:
Le logiciel de caisse doit enregistrer toutes les données d’origine relatives à la transaction de règlements (notes et tickets de caisse).
Les données initialement validées devant rester inaltérables, si des corrections sont ultérieurement apportées à des opérations de règlements, ces corrections (modifications ou annulations) s’effectuent par l’enregistrement de nouvelles opérations de «plus» et de «moins» et non par modification directe des données d’origine enregistrées. Ces opérations de correction donnent également lieu à enregistrement et leur inaltérabilité doit également être garantie.
Techniquement, la solution doit garantir l’inaltérabilité de toutes les données élémentaires (enregistrement initial et correction(s)) et fournir une fonctionnalité de suivi des modifications.
21. Qu’entend-on par « rendre inaltérables les données » ?
Éléments de réponse:
Pour les systèmes de caisse, la condition d’inaltérabilité des enregistrements de règlement (quantité, montant, TVA, mode de règlement...) s’obtient par plusieurs moyens techniques garantissant:
Une inaltérabilité logique de haut niveau, en privant l’utilisateur de toute fonctionnalité du logiciel lui permettant de modifier les données élémentaires de règlement. Ce moyen s’assortit d’une solution technique permettant de détecter et démontrer que l’utilisateur n’a pas contourné cette impossibilité fonctionnelle intégrée au logiciel de l’éditeur.
Une inaltérabilité de bas niveau qui garantit l’intégrité des données enregistrées sur le disque sous forme de fichier ou de base de données. L’accès à une donnée élémentaire par un homme de l’art ne pouvant jamais être empêché, cette inaltérabilité est garantie par la preuve que la donnée élémentaire n’a pas été modifiée depuis son enregistrement (empreinte numérique à clé privée, chaînage...).
22. Qu’entend-on par les données d’origine « enregistrées initialement » ? À partir de quel moment doit-on les rendre inaltérables ?
Éléments de réponse:
Les données de l’opération doivent être inaltérables de la prise de commande jusqu’à l’enregistrement du règlement.
Cette inaltérabilité est garantie par:
III Condition de sécurisation
23. Qu’entend-on par «sécurisation» des données ? En quoi cette notion se différencie des trois autres (inaltérabilité, conservation, archivage) et quels sont les critères à respecter pour garantir la «sécurisation» des données? Doit-on le comprendre comme la faculté d’un assujetti de pouvoir justifier qui peut accéder aux données, qui a accédé aux données sur une période définie, et d’un suivi de ces accès?
Éléments de réponse:
La condition de sécurisation des données a fait l’objet de précisions dans la doctrine administrative à laquelle il convient de se reporter : BOI-TVA-DECLA-30-10-30 § 130 à 150. La condition de sécurisation ne vise pas à limiter les droits d’accès au logiciel ou système de caisse mais à assurer que les enregistrements des encaissements réalisés par toute personne qui accède au logiciel ou système soient tracés, de même que les éventuelles modifications apportées à ces enregistrements initiaux.
En cas d’emploi d’une fonction «école» ou «test», le § 150 de la doctrine administrative précitée prévoit par ailleurs l’identification de l’opérateur sous la responsabilité duquel le personnel en formation enregistre les données.
La sécurisation des données vise à s’assurer que les données enregistrées ne peuvent plus être modifiables, sans traces. Il ne s’agit pas seulement de protéger les données contre les modifications par des tiers, ce qui constitue un délit en application des articles 323-1 à 323-3 du code pénal, mais aussi contre des modifications non tracées effectuées par le propriétaire et détenteur des données lui-même.
IV Conditions de conservation et d'archivage
24. Quelle est la différence entre conservation et archivage des données ?
Éléments de réponse: Il convient de distinguer la condition de conservation des données de la condition d’archivage des données.
La conservation des données détaillées de transaction doivent être conservées «en ligne» dans le système de caisse. Ces données peuvent faire l’objet de purge, ce qui consiste à les sortir du système de caisse et à les stocker dans un support externe d’archivage (clé USB, disque optique ou disque dur externe).
L’ensemble des données doivent être conservées (dans le système de caisse) et archivées (sur support externe et leur inaltérabilité et leur traçabilité doivent être garanties pendant six ans. Elles doivent être archivées au moins une fois à la fin de chaque exercice comptable au moyen d’un processus obligatoirement prévu par le logiciel. Elles sont toujours archivées avant un processus de purge. Comme précisé par le BOI-TVA-DECLA-30-10-30 (§ 160 et suivants), pour chaque clôture (selon le cas journalière, mensuelle et/ou annuelle ou par exercice), toutes les données doivent être conservées: «cette obligation de conservation porte sur toutes les données enregistrées ligne par ligne, ainsi que pour les systèmes de caisse, sur les données cumulatives et récapitulatives calculées par le système» (cumul du grand total de la période et total perpétuel).
La condition d’archivage a, quant à elle, pour «objet de figer les données et de donner date certaine aux documents archivés». Pour plus de précisions, se reporter au BOI-TVA-DECLA-30-10-30-20160803 § 220 et suivants.
S’agissant du cas de changement de matériel ou de logiciel, il est rappelé que le délai général de conservation de six ans, mentionné au premier alinéa de l’article L. 102B du livre des procédures fiscales, s’applique aux livres, registres, documents ou pièces auxquels l’administration a accès pour procéder au contrôle des déclarations et des comptabilités des contribuables astreints à tenir et à présenter des documents comptables.
25. Quelles sont les données de caisses à conserver et doit-on le faire tous les jours ou tous les mois? Uniquement le Z ou le détail?
Éléments de réponse:
Toutes les données élémentaires doivent être conservées par le logiciel ou le système de caisse et non pas seulement le Z. Un assujetti qui ne conserve que les Z ne respecte pas les obligations de conservation prévues à l’article L. 102-B du livre des procédures fiscales. Cette définition répond à la nécessité légale de justifier les résultats produits par un système informatisé avec les données élémentaires ayant servi à leur élaboration, prises en compte dès leur origine, et non par des données agrégées résultant de traitements automatisés. Les données de détail d’une transaction de règlement comprennent le numéro du ticket, la date (heure-minute-seconde), le numéro de la caisse, le total TTC, les totaux HT par taux de TVA, le détail des articles ou prestations (libellé, quantité, prix unitaire, total HT de la ligne, taux de TVA associé) et les traces de modifications et corrections apportées.
Ainsi, avant la purge des données élémentaires conservées dans le système de caisse, l’ensemble des données précitées et enregistrées depuis la dernière opération d’archivage doivent être conservées. Après la purge, opération d’archivage qui a pour objet de transférer les données conservées vers un support externe, seuls les totaux de contrôles produits par les procédures de clôtures (soit les grands totaux journaliers, mensuels, annuels et de l’exercice et le total perpétuel) doivent être conservés dans le logiciel de caisse et continuer d’être protégés par la garantie d’inaltérabilité. Les données de traçabilité de la procédure de purge/archivage doivent être conservées.
26. Faut-il conserver les données directement dans le logiciel ou dans un système d’archivage ?
Éléments de réponse:
L’inaltérabilité des données permet de garantir que les enregistrements de règlement ne sont plus modifiés ou n’ont pas été modifiés après leur validation.
Les garanties de conservation et d’archivage permettent de garantir que ces données inaltérables restent durablement accessibles dans le cadre d’un contrôle pendant le délai légal de contrôle.
Pour les logiciels de caisse, on distingue la conservation des données « en ligne » dans le système de caisse, de l’archivage des données sur un support externe.
Les données conservées (en ligne dans le logiciel de caisse) doivent faire l’objet de clôtures journalières, mensuelles et annuelles (ou par exercice). Les données sont archivées au moins une fois à la fin de chaque exercice comptable au moyen d’un processus obligatoirement prévu par le logiciel. Elles sont toujours archivées avant un processus de purge. Les données de détail de règlement sont enregistrées sur un support externe et effacées de la sauvegarde « en ligne » présente dans le logiciel de caisse. En revanche, les totaux de contrôles produits par les procédures de clôtures doivent être conservés dans le logiciel de caisse et continuer d’être protégés par la garantie d’inaltérabilité. La solution logicielle doit permettre de maintenir la traçabilité des procédures d’archivage et de garantir l’inaltérabilité des données archivées.
27. Qu’est-ce qu’un «support physique externe sécurisé» ?
Éléments de réponse: Il est possible de citer comme support physique externe: une clé USB, un disque optique ou un disque dur externe. Ce support physique externe doit être sécurisé. Aucune solution technique n’est imposée pour assurer cette sécurisation.
Le support physique externe sécurisé n’est exigé qu’en présence de purges, tel que l’indique le § 250 du BOI-TVA-DECLA-30-10-30: Au-delà de la périodicité choisie et au maximum annuelle ou par exercice, le logiciel ou le système peut prévoir une procédure de purge des données de règlement.
Avant la mise en œuvre de cette procédure de purge, le logiciel ou le système doit garantir la production d’une archive complète des données de règlement (données d’origine et éventuelles modifications), avec la date de l’opération de règlement (année – mois – jour), sur un support physique externe sécurisé.
La décision de purger les données est liée à la nécessité de libérer de l’espace sur le disque dur.
L’archivage des données est donc dans ce cas logiquement réalisé en dehors du système de caisse. La sécurisation du support d’archivage doit permettre de garantir l’intégrité des données archivées et leur disponibilité en cas de contrôle.
La disponibilité des données doit être effective en cas de contrôle. Les éditeurs doivent prévoir des procédures d’archivage obligatoires pour les utilisateurs. Pour plus de sécurité plusieurs supports de stockage différents pour une même archive peuvent être proposés comme le prévoit la norme Z 42 013. Les utilisateurs ont en effet l’obligation de conserver les données archivées pendant six ans.
L’obligation d’archivage prévue par le certificat ne doit pas être confondue avec une solution de sauvegarde des données présentes dans le système de caisse. Ces sauvegardes sont entendues comme une copie des données toujours présentes sur la caisse. Les sauvegardes permettent la reprise technique des données en cas de panne de la caisse et constituent une solution, parmi d’autres, de sécurisation des données justificatives de règlement.
28. Qu’entend-on par « grand total de la période et le total perpétuel » ?
Éléments de réponse:
Le § 170 du BOI-TVA-DECLA-30-10-30 précise que: «Pour chaque clôture -journalière, mensuelle et annuelle (ou par exercice)- des données cumulatives et récapitulatives, intègres et inaltérables, doivent être calculées par le système de caisse».
On entend par «cumul du grand total de la période» le cumul de chiffre d’affaires décompté depuis l’ouverture de la période comptable en cours.
On entend par «total perpétuel» le cumul de chiffre d’affaires décompté depuis le début de l’utilisation du système.
Le Total perpétuel est en effet un compteur qui cumule le chiffre d’affaires total enregistré depuis le début de l’utilisation du système et ne se remettant jamais à zéro. Il n’est pas lié à une période contrairement au Grand Total qui lui est le compteur qui cumule le chiffre d’affaires total pour la période comptable.
En cas de changement de matériel ou de logiciel, tous les compteurs repartent de zéro. Les compteurs de l’ancien matériel ou logiciel doivent être archivés et sécurisés. Dans le cas d’un simple changement de version d’un logiciel tous les compteurs doivent continuer à être incrémentés sans être remis à zéro.
29. Quelles sont les attentes pour la clôture mensuelle obligatoire dans un système de caisse par rapport à la clôture journalière ?
Éléments de réponse:
Des précisions ont été apportées sur ce point aux § n° 160 et suivants du BOI-TVA-DECLA-30-10-30.
Pour les systèmes de caisse, l’obligation de clôture est: journalière, mensuelle et annuelle (ou par exercice).
La doctrine administrative précise par ailleurs que: «Pour chaque clôture -journalière, mensuelle et annuelle (ou par exercice)- des données cumulatives et récapitulatives, intègres et inaltérables, doivent être calculées par le système de caisse».
Parmi ces données figurent le grand total pour la période comptable, le total période et le total perpétuel.
Toutes les données enregistrées doivent être conservées. «Cette obligation de conservation porte sur toutes les données enregistrées ligne par ligne, ainsi que pour les systèmes de caisse, sur les données cumulatives et récapitulatives calculées par le système».
La clôture mensuelle permet aussi la totalisation du chiffre d’affaires ventilé par taux de TVA.
Éléments de réponse: La doctrine administrative prévoit que la clôture doit intervenir à l’issue d’une période au minimum annuelle (ou par exercice si celui-ci n’est pas calé sur l’année civile). Pour les systèmes de caisse, il faut en plus une clôture journalière et mensuelle. Ensuite, le § 220 du BOI-TVA-DECLA-30-10-30 prévoit la possibilité d’archiver les données selon une périodicité choisie qui est au maximum annuelle ou par exercice.
S’agissant de la condition de conservation des données, il est précisé pour les systèmes de caisse, aux §160 et 170 de la doctrine précitée, que ces systèmes doivent prévoir obligatoirement une clôture journalière, une clôture mensuelle et une clôture annuelle (ou par exercice lorsque l’exercice n’est pas calé sur l’année civile). Pour les systèmes de caisse, ces trois échéances de clôtures sont cumulatives et impératives.
S’agissant du respect de la condition d’archivage, il est prévu que les systèmes de caisse comme les logiciels de comptabilité ou de gestion doivent permettre d’archiver les données enregistrées selon une périodicité au maximum annuelle ou par exercice. Cette périodicité est donc la même que la périodicité annuelle ou par exercice prévue pour le respect de la condition de conservation.
V Partage des responsabilités
31. Définition de «l’éditeur» :
Éléments de réponse: On entend par « éditeur » du logiciel ou du système de caisse la personne qui détient le code source du logiciel ou système et qui a la maîtrise de la modification des paramètres de ce produit.
Une attestation délivrée par un éditeur engage sa responsabilité sous réserve que les dispositifs techniques garantissant sécurisation, inaltérabilité, conservation et archivage ne sont pas modifiés.
Logiciel standard d’un éditeur fourni sous forme d’un exécutable et de ses bibliothèques logicielles non modifiables et dont un éventuel paramétrage ne concerne pas les fonctions assurant la sécurisation, l’inaltérabilité, la conservation et l’archivage. L’éditeur de ce logiciel est soumis à une obligation de sécurisation justifiée par un certificat délivré par un organisme accrédité ou une attestation établie par l’éditeur lui-même.
35. Les archives doivent être lues aisément par l’administration en cas de contrôle: quels sont les moyens considérés comme aisés par l’administration pour lire les données ? En cas de cryptage des archives quels sont les outils de décryptage acceptés?
Éléments de réponse:
Les archives doivent pouvoir être lues aisément par l’administration. Aucun format d’archive n’est toutefois imposé. De la même manière, en cas de cryptage de l’archive, aucun format de cryptage n’est imposé. Les archives seront dans ce cas considérées comme pouvant être aisément lues par l’administration (les données numériques par exemple apparaissant en clair et non sous forme codée), dès lors qu’en cas de contrôle, l’assujetti à la TVA concerné présentera à l’administration des archives décryptées.
A titre d’exemple, les formats de fichiers de type TXT ou CSV peuvent être utilisés pour l’archivage (cf. BOI-BIC-DECLA-30-10-20-40 § 550).
II Attestation
Éléments de réponse:
L’attestation doit être individuelle, c’est-à-dire délivrée nominativement à l’assujetti à la TVA qui la produit.
L’attestation doit être établie par l’éditeur du logiciel ou du système de caisse ou par son représentant légal lorsqu’il s’agit d’une société.
Elle doit explicitement mentionner que le logiciel ou le système de caisse respecte les conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données. Elle doit indiquer précisément:
le nom et les références de ce logiciel (y compris la version du logiciel concernée et le numéro de licence quand il existe une licence) ou de ce système;
la date d’acquisition du logiciel ou système par l’assujetti à la TVA.
L’attestation peut être délivrée sur un support physique ou de manière dématérialisée (par exemple, par téléchargement en ligne d’une attestation à compléter par l’assujetti pour y mentionner notamment son identité complète). Pour plus de précision, il convient de se reporter à la doctrine administrative.
L’attestation doit être conforme au modèle fourni en BOI-LETTRE-000242.
44. Que faire si mon éditeur de logiciel ne m'a pas encore envoyé d'attestation?
Éléments de réponse:
La loi n’impose pas aux éditeurs cette délivrance spontanée.
Si l’éditeur n’adresse pas d’attestation à l’utilisateur, il appartient à ce dernier de la lui réclamer.
Des consignes seront données aux agents de l’administration fiscale pour prendre en compte les circonstances particulières si l’assujetti apporte la preuve des diligences qu’il a faites pour obtenir cette attestation.
47. L'attestation de mon éditeur peut-elle être limitée dans le temps?
Éléments de réponse:
Le renouvellement de l’attestation est fondé sur les notions d’évolutions mineures ou majeures du logiciel, et non sur une durée calendaire. Dans les faits, l’attestation n’a pas à être renouvelée annuellement, mais elle le sera en fonction des changements mineurs ou majeurs apportées au logiciel.
Il est admis que l’attestation demeure valable pour attester du respect des conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données par les versions mineures ultérieures du logiciel ou système (cf. I-C-1 § 340 du BOI-TVA-DECLA-30-10-30 pour la définition d’une version majeure et d’une version mineure) :
Dans le cas où les fonctionnalités techniques du certificat ne sont pas modifiées par une nouvelle version du logiciel, on parlera d’une version mineure ne faisant pas naître une nouvelle obligation de certification.
Dans le cas où la modification du logiciel est telle que les fonctionnalités techniques assurant la sécurisation, l’inaltérabilité, la sauvegarde et l’archivage des données sont altérées, on parlera d’une version majeure qui doit faire l’objet d’une nouvelle certification. Toute nouvelle version majeure du logiciel ou système doit donner lieu à l’établissement d’une nouvelle attestation visant expressément cette version
MISE A JOUR : Communiqué de presse du 15 juin 2017
Suite au communiqué de presse du cabinet du ministère du 15 juin 2017 (http://proxy-pubminefi.diffusion.finances.gouv.fr/pub/document/18/22503.pdf), seuls les logiciels de caisse seraient à présent concernés.
Etant donné que BeDesk fait partie des logiciels de gestion et non de caisse, l’obligation de mise en conformité dont il est question dans ce ticket ne serait donc plus avérée.
Cependant, tant que la loi n’est pas effectivement révisée, nous continuerons de mettre en application les points ci-dessous à toutes fins utiles.
Un gros travail a déjà été effectué et, considérant que cela améliore également d’une certaine manière la qualité du logiciel, nous le finirons.
MISE A JOUR : FAQ l'administration publiée le 28 juillet 2017
Question n°1
Qu’est-ce qu’un logiciel ou système de caisse ?
Un logiciel ou un système de caisse est un système informatisé dans lequel un assujetti enregistre les livraisons de biens et les prestations de services ne donnant pas lieu à facturation au sens du BOI-TVA DECLA-30-20-10.
NOTES
Ceci exclut de-facto le logiciel BeDesk car il s’agit d’un logiciel de facturation et non de caisse.
Question n°2
Tous les logiciels de gestion commerciale incluant une fonctionnalité de caisse enregistreuse/d’encaissement sont-ils toujours à certifier par leurs éditeurs pour le 1er janvier 2018 ?
Depuis le 15 juin 2017, seuls les logiciels et systèmes de caisse sont concernés par la mesure, principaux vecteurs des fraudes constatées à la TVA. Concernant les logiciels multi fonctions (comptabilité/gestion/caisse), seules les fonctions caisse enregistreuse/encaissement, et non l’ensemble du logiciel, devront être certifiées.
NOTES
La note “fonctions caisse enregistreuse/encaissement” est quelque peu ambigüe.
En effet, le suivi de l’apurement des factures pourrait-il être considéré comme une “fonction d’encaissement” ?
CHAMP D'APPLICATION DE LA LOI PAR RAPPORT À NOTRE LOGICIEL
Ce qui ne concerne pas BeDesk-Express :
Ce qui concerne BeDesk-Express :
|
|
761 | | Application | Suivi | Critique | Très haute | Suivi des aspects légaux relatifs aux adapations de la ... | Fermée | 17.0 | x-dev | |
2020-12-31 |
Description de la tâche
Les obligations qui découlent des changements légaux prévus :
2018 : terminé.
2019 : terminé.
2020 : suivi.
|
|
787 | 761 | Services | Spécification | Critique | Très haute | La libération des codes via la page d'admin ne doit pas ... | Fermée | 17.0 | | |
2017-02-08 |
Description de la tâche
On a constaté que certains utilisateurs se servaient de la fonction de libération des codes présente sur la page d’administration de compte en ligne pour échanger l’activation sur plusieurs bases de données.
Outre le fait que cela n’est pas autorisé par le contrat de licence:
Art.9 ) Chaque code d’activation est unique et ne peut être lié qu’à une seule licence dont l’usage est strictement limité à une seule session d’utilisation de BEDESK-EXPRESS et d’accès à une seule base de données.
Cette pratique entraîne d’autres complications d’ordre légal:
La législation impose d’assurer la continuité de la piste d’audit des opérations réalisées. Or, le fait de changer de base de données brise cette continuité et compromet gravement la traçabilité des opérations.
L’éditeur du logiciel est tenu par la loi de s’assurer que les données saisies ne peuvent pas être effacées. Ceci inclut également l’effacement par écrasement lors de la restauration d’une sauvegarde de sécurité.
Les utilisateurs qui ont recours à la libération de code pour échanger un même code d’activation sur plus d’une seule base de données perturbe le fonctionnement du service VB4B. Ils occasionnent notamment un surcroît de l’utilisation de la bande passante et introduisent des données de plusieurs bases de données différentes dans la même file chronologique des versions des sauvegardes. Cela augmente fortement le besoin d’espace de stockage car plusieurs bases de données sont ainsi sauvegardées dans une même archive.
—
En principe, la fonction de libération n’est pas prévue pour utiliser, avec une seule et même licence, plusieurs bases de données différentes.
Cette fonction est prévue pour faciliter, le cas échéant, le changement d’ordinateur dans le cadre d’une changement définitif du matériel ou à caractère purement exceptionnel dans le cadre d’un dépannage par exemple.
Cette fonction est manifestement abusée. Le souci c’est que cela va plus loin que simplement permettre l’usage d’un même code sur plus qu’une seule base de données. Cela place le logiciel en porta-faut par rapport à la législation.
—
Il faut donc revoir les modalités de la fonction de libération en réduisant sa porté de manière à empêcher le changement de base de données.
—
Modification de la politique de libération réalisée sur l’API de validation.
Adaptation du site https://www.bedesk-express.com nécessaire.
—
Page d’administration de compte sur BeDesk-Express.com adaptée en conséquence.
Le cas échéant, s’il faut absolument libérer l’activation de manière à permettre le changement de base de données associée, l’utilisateur peut prendre contact avec le support technique qui prendra note de l’évènement dans le journal d’opérations techniques du compte à toute fins utiles (conformément aux exigences légales).
|
|
903 | | UI | Régression | Critique | Très haute | Bloquage de l'application lorsque la boîte de dilogue a ... | Fermée | 17.3 | | |
2017-03-09 |
Description de la tâche
Dans la procédure de démarrage, lorsque la boîte de dialogue annonçant la fin imminente d’un contrat apparaît, l’interface graphique de l’application se fige.
Il y a un deadlock entre l’attente de la fin de la procédure de démarrage et l’attente de la boîte de dialogue.
Confirmé.
Idem avec les autres boîtes de dialogue sur Windows.
Tests à réaliser.
|
|
906 | | Core | Régression | Critique | Très haute | Lors de l'exportation PDF d'un book ou d'un rapport, on ... | Fermée | 17.3 | | |
2017-03-09 |
Description de la tâche
Ce phénomène est lié au contexte d’exécution des fonctions d’impression.
Il y a manifestement un conflit entre le processus qui gère l’interface graphique et le rendu des documents en tâche de fond.
Confirmé.
Suppression d’un synchroniseur obsolète.
tests en cours...
|
|
936 | 942 | Core | Spécification | Critique | Très haute | Dépréciation du système de sauveagrde de sécurité local | Fermée | 17.0 | 17.9 | |
2017-09-29 |
Description de la tâche
Le système de sauvegarde de sécurité local est malheureusement très mal utilisé par certains utilisateurs.
Certains en effet essayent de restaurer une sauvegarde antérieure sans ce soucier de l’impact sur la suppression éventuelle des dernière données saisies.
Le système de sauvegarde ne sert bien entendu pas à supprimer des données. Mais si on n’y prend pas garde, il pourrait permettre une telle suppression par écrasement.
De plus, chaque base de données est signée. Chaque signature est unique et attachée à une seule base de données.
Lorsqu’on effectue une sauvegarde de sécurité, on sauve également la signature. Lorsqu’on restaure une sauvegarde, on restaure donc une version de la même base de données que celle d’origine et non un duplicata.
Le seul système de sauvegarde fiable devrait être le service VB4B car il effectue toutes les vérifications nécessaires.
Seul devrait resté la fonction de restauration pour permettre la restauration de fichiers de sauvegarde fournis par le support technique.
—
|
|
942 | | Core | Spécification | Critique | Très haute | Renforcement de la sécurisation de l'identité des bases ... | Fermée | 17.3 | 18.0 | |
2017-12-24 |
Description de la tâche
Mauvaise utilisation du système de sauvegarde de sécurité local
Nous constatons que malheureusement certains utilisateurs font un mauvais usage du système de sauvegarde/restauration.
Un des cas de figure de mauvaise utilisation consiste par exemple à essayer de créer une nouvelle base de données “indépendante” en utilisant le système de sauvegarde/restauration local.
Or, on ne peut pas obtenir une nouvelle base de données “indépendante” avec le système de sauvegarde/restauration.
La signature de la base de données d’origine est conservée à l’identique. De cette manière, quelque soit le poste sur lequel la base de données est restaurée, on peut s’assurer d’utiliser toujours la version la plus récente et comportant l’intégralité des données.
Si on essaye de restaurer une version antérieure de la base de données, celle-ci ne pourra pas être activée et on ne pourra pas ajouter des données à la suite d’une chronologie tronquée ou ramenée à un état antérieur 1).
—
Pour créer une nouvelle base de données indépendante, il faut cliquer sur le bouton “créer une nouvelle base de données” et non sur “sauvegarder” puis “restaurer”. Cette dernière procédure restitue la base de données d’origine et ne crée pas une nouvelle base de données distincte.
—
En outre, lors de la restauration d’un fichier de sauvegarde, le nom de la base de données est également conservé. Si on effectue la sauvegarde de sécurité de la base de données appelée “Tests”, le nom de la base de données est également enregistré dans le fichier de sauvegarde. Ainsi, lorsqu’on restitue ce fichier, quelque soit le nom qu’on lui aurait donné, ce sera toujours la base de données “Tests” qui sera restaurée.
Cela pose donc un autre problème, si l’utilisateur a essayé de créer une nouvelle base de données “indépendante” par sauvegarde/restauration. En effet, si on restaure par erreur une sauvegarde secondaire sur le poste d’origine, il y aura conflit non seulement d’identité mais de nom également.
—
Pour résoudre ces multiples problèmes, il faut modifier l’implémentation de sécurisation des bases de données en s’assurant qu’une identité correspondent bien au nom de la base de données. Les 2 éléments constituant en soit une clé composée.
Tout changement de nom de la base de données devrait donc dès lors altérer l’identité de la base de données. Cela aura notamment pour conséquence une invalidation immédiate de la licence. Mais, dans le même temps, cela interdira :
l’utilisation de copies invalides ou conflictuelles d’une base de données originale,
et la réutilisation des codes d’activation sur plus d’une seule et unique identité.
Il faut aussi permettre au support technique de créer des nouvelles identités pour éviter la perte des données des utilisateurs qui auraient utiliser le système de sauvegarde/restauration dans l’espoir de créer une nouvelle base de données “indépendante” par inadvertance.
Le problème de l'activation multi-comptes
Nous constatons également que quelques utilisateurs ont créés plusieurs comptes à partir desquels ils ont acquis plusieurs licences. Ce n’est pas un problème en soit. Cependant, ils utilisent aussi ces codes émanant de plusieurs comptes distincts pour activer une même base de données.
Parfois même les coordonnées associées à ces comptes distincts ne sont pas les mêmes (changement de statuts).
Le service des licences doit être attentifs à cet aspect et organiser le regroupement des codes d’activation sur un seul et même compte pour une même base de données.
|
|
945 | 942 | Core | Implementation | Critique | Très haute | Invalidation automatique de la signature de base de don ... | Fermée | 17.3 | | |
2017-03-17 |
Description de la tâche
Si l’utilisateur effectue une copie à la main des fichiers d’une base de données pour les placer dans un autre dossier, ou forger une nouvelle base de données locale sous un autre nom mais en essayant de conserver la même identité, la signature de la base de données doit être révoquée automatiquement.
|
|
948 | 942 | Services | Service en ligne | Critique | Très haute | Outils pour le support technqiue : capacité à forger de ... | Fermée | 17.3 | | |
2017-03-17 |
Description de la tâche
Le support technique doit pouvoir forger une identité “indépendantes” de manière à permettre la dissociation d’une base de données de son identité d’origine sans entraîner la suppression du contenu antérieur.
De cette manière la conservation des données d’origine peut être maintenue tout en dissociant le contenu d’une identité d’origine.
Objectif : Aucune perte de données.
|
|
960 | 760 | UI | Implementation | Critique | Très haute | Saisie des paiements reçus sous forme d'une liste d'opé ... | Fermée | 17.3 | 18.0 | |
2017-12-24 |
Description de la tâche
La législation impose une modification dans la méthode de saisie des paiements reçus.
|
|
966 | 574 | Core | Lié à un autre bug | Critique | Très haute | Désactivations aléatoires et intempestives | Fermée | 16.4 (fork) | 17.3 | |
2017-03-17 |
Description de la tâche
Le logiciel semble se désactiver intempestivement à chaque redémarrage ou de manière plus aléatoire au bout d’un certain temps.
Ce problème touche les versions suivantes:
Est résolu avec la révision 17.3.160.
—
Solution confirmée avec 17.3.160.
|
|
1017 | | Application | Spécification | Critique | Très haute | Intégration de Java 9 | Fermée | 17.0 | 17.9 | |
2017-09-29 |
Description de la tâche
L’intégration de Java 9 en remplacement de Java 8 est planifiée pour BeDesk-Express v17.
Ce remplacement apportera de nombreuses améliorations et corrections de bugs dans le composant Java nécessaire à l’exécution du programme BeDesk-Express.
—
Nombre de jours avant disponibilité : http://www.java9countdown.xyz/
—
Bien que la sortie officielle de java 9 est prévue le 27/07/2017, nous ne le proposerons pas avant début septembre, pour pouvoir assurer un meilleur support du basculement.
—
Date de sortie repoussée par Oracle au 21 septembre 2017.
Cela va certainement retarder légèrement la sortie de la version 17.9 du logiciel de manière à disposer de cette intégration (si possible avant la fin du mois).
|
|
1032 | 942 | Services | Spécification | Critique | Haute | Une base de données ne peut appartenir qu'à un seul com ... | Fermée | 17.3 | 17.4 | |
2017-04-13 |
Description de la tâche
Chaque base de données est liée à un seul et unique compte principal.
Cela évite les éventuelles “collisions” de clés en réduisant le domaine.
|
|
1038 | 1032 | Services | Suivi | Critique | Haute | Le service des licences organise le regroupement des li ... | Fermée | 17.3 | 17.4 | |
2017-04-13 |
Description de la tâche
Certains utilisateurs utilisent des codes d’activation émanant de plusieurs comptes distincts sur la même base de données.
Le service des licences prend contact avec chaque utilisateur pour organiser le regroupement des licences sur un seul et unique compte.
Les comptes inutilisés sont supprimés.
—
Regroupement terminé.
On continue la veille pour s’assurer qu’il n’y a pas de duplications à nouveau.
En attente de résolution tiers.
|
|
1062 | | Infrastructure | Suivi | Critique | Très haute | Vérifiaction de contrôle de la gestion de TOKEN sur che ... | Fermée | 17.0 | 17.5 | |
2017-05-26 |
Description de la tâche
Vérification de la plateforme de gestion des activations (partie TOKEN).
On constate que certains utilisateurs voient leur logiciel se désactiver (selon les utilisateurs “intempestivement”).
De notre coté, en écartant les cas où le contenu d’une base de données à changé entre la dernière session et la nouvelle, il reste quelques cas où le TOKEN ne correspond pas.
Nous étudions donc le problème pour en trouver l’origine.
—
Travaux sur l’infrastructure : Contrairement à ce qui était signalé au départ, certains accès dont le TOKEN était périmé arrivaient à passer. Ceci suite à un bug dans d’anciennes versions du logiciel. Suite à ce constat, nous avons modifier légèrement la procédure de renouvellement du TOKEN de manière à résorber cette faille.
—
TOKEN issu d’une restauration de fichier externe : L’utilisateur peut en effet utiliser un système de sauvegarde externe indépendant du logiciel BeDesk et restaurer des fichiers dans un état antérieur. Bien entendu, le TOKEN ainsi restauré ne correspond pas à celui attendu par le système de vérification. Ceci n’est donc pas un bug, mais la preuve que le système de protection fonctionne correctement.
—
|
|
1076 | 764 | Application | Spécification | Critique | Très haute | Configuration des paramètres locaux et d'arrondi unique ... | Fermée | 17.5 | 17.6 | |
2017-07-11 |
Description de la tâche
Jusqu’à présent, l’utilisateur pouvait modifier certains paramètres “critiques” comme le nombre de décimales à prendre en compte dans les calculs des totaux.
La loi exige à présent de placer les montants dans une blockchain (liste de hashes chaînés) ce qui impose l’obligation de figer définitivement l’arrondi et les caractéristiques des calculs de l’application en fonction de la monnaie utilisée.
Ainsi, il faut supprimer les paramètres de configuration de la devise, ainsi que les caractéristiques du calcul de l’arrondi.
L’utilisateur choisi le signe de la monnaie ainsi que les caractéristiques du calcul de l’arrondi liée à la monnaie en choisissant sont pays.
Il peut personnaliser le nombre de décimale et les caractéristiques locales une fois pour toute lors du tout premier démarrage de l’application à l’aide de l’assistant de configuration.
Il n’est plus possible de modifier ces paramètres par la suite car cela impliquerait de briser la blockchain des montants (en recalculant ceux-ci, le logiciel doit arriver exactement aux mêmes valeurs que celles archivées dans la blockchain - bien entendu, si l’arrondi est modifié, les résultats sont forcément différents -il n’est donc plus possible de les modifier ultérieurement).
C’est pour accorder le logiciel aux contraintes légales que cette restriction est appliquée.
|
|
1079 | 764 | Application | Spécification | Critique | Très haute | Configuration de la numérotation des documents uniqueme ... | Fermée | 17.5 | 17.6 | |
2017-07-11 |
Description de la tâche
Jusqu’à présent, bien que la numérotation des documents ne peut être modifiée en interne, il était possible de personnaliser le mode de numérotation via le panneau de configuration de l’application.
Malheureusement, cette possibilité n’est plus conforme aux exigences légales qui impose d’archiver les documents de manière infalsifiables (c-à-d, inaltérables).
Or, en personnalisant le mode de numérotation, on peut changer la forme du numéro (sans toutefois changer de numéro à proprement parlé). Pour rencontrer les exigences légales, la personnalisation du format du numéro de série n’est plus acceptable, ce pour conserver les documents archivés absolument identiques aux originaux.
Le format du numéro de série des documents pourra donc être choisi au moment de la toute première configuration de la base de données, mais ne pourra plus être modifiée par la suite.
Ceci pour conformer le logiciel aux exigences légales.
|
|
1082 | 764 | Application | Spécification | Critique | Très haute | Dépréciation du numéro de dossier inclu dans le numéro ... | Fermée | 17.5 | 17.6 | |
2017-07-11 |
Description de la tâche
L’indication du numéro de dossier dans la formule de numérotation de série des documents peut prêter à confusion (il ne fait en effet pas partie du numéro de série à proprement dit - il est purement indicatif).
De plus, cette indication peut varier en fonction du dossier dans lequel on attache le document.
Aussi, pour conformer le logiciel aux nouvelles exigences légales, le numéro de dossier dans la numérotation de série est dépréciée.
Ce numéro peut être inséré dans le corps du document, toutefois, il ne pourra plus figurer dans le numéro de série.
Le format de numérotation pourra être sélectionné au lancement de l’assistant du premier démarrage, mais plus ensuite.
Il faut déterminer comment aider les utilisateurs qui ont inséré le numéro de dossier dans le format du numéro de série à le retirer.
On n’est pas obligé de supprimer les numéros de dossiers du format des numéros de série.
Le numéro de dossier est purement indicatif.
Cependant, dès lors qu’un document est validé, on ne devrait plus pouvoir changer son dossier d’origine.
|
|
1099 | 761 | Base de données | Spécification | Critique | Très haute | Validation des documents | Fermée | 17.5 | 18.0 | |
2017-12-24 |
Description de la tâche
Caractéristiques de validation des documents.
Lorsqu’un document est validé, un certain nombre d’informations ne peuvent plus être modifiées:
Date
Client
Numéro de série
Montants
Liste des articles
Numéro de dossier
cette stratégie n’est pas obligatoire à condition de faire apparaître toutes les modifications apportées à un document dans le journal d’audit sécurisé.
Le cas échéant, une correction tout à fait légitime peut être envisagée à condition de la justifier par une explication.
Le logiciel propose donc automatiquement de fournir un justificatif de toute modification apportée à un document qui a été imprimé ou exporté en Pdf.
Notez que la validation est obligatoire tant que le document n’a pas reçu de numéro. BeDesk valide donc systématiquement les documents dés lors qu’ils sont enregistrés.
La validation est donc implicite lors de l’enregistrement du document.
|
|
1108 | | Application | Implementation | Critique | Très haute | Implémentation de l'agent de réplication du moteur LogV ... | Fermée | 17.5 | x-dev | |
2019-12-06 |
Description de la tâche
Mise à jour ‘Upstream’ de keyListDB.
Intégration et implémentation de l’agent de réplication.
Nécessite des modifications importantes dans l’application.
|
|
1186 | 1180 | Core | Implementation | Critique | Très haute | Remplacement de TaskList par un nouveau paquet bedesk.w ... | Fermée | 17.5 | 17.6 | |
2017-07-11 |
Description de la tâche
Remplacement de l’ancienne TaskList par un nouveau paquetage interne bedesk.worker.
Le Worker étant un daemon qui tourne en tâche de fond et qui envoie des tâches bloquantes dans le Thread AWT-EventQueue.
Chaque tâche est exécutée une après l’autre.
Un délais peut être fixé avant le lancement d’une tâche, sinon elle est lancée immédiatement après la fin de le précédente.
Le worker permet de découper les tâches longues et d’ordonner l’enfilade des tâches de manière à pouvoir exécuter chacune dans le contexte du même thread AWT-EventQueue.
De cette manière, on évite les problèmes de concurrence et on permet à l’interface de s’actualiser durant les processus longs.
CARACTERISTIQUES:
Le nouveau Worker dispose de 5 niveau de priorité et permet donc l’insertion de tâches prioritaires dans la file d’attente.
On peut travailler ne libérant un peu de temps entre les tâches de manière à permettre le rafraîchissement de l’interface.
Combat les dead-locks en ordonnant les tâches successives par priorité.
|
|
1192 | 1129 | Application | Garde-fou | Critique | Haute | Terminer l'application alors que le worker est en cours ... | Fermée | 17.5 | 17.6 | |
2017-07-11 |
Description de la tâche
Si on termine l’application, le worker continue en arrière plan.
Il en résulte des erreurs dans les fichiers car les dernières modifications ne sont pas répercuté en ligne.
|
|
1195 | 1186 | Core | Implementation | Critique | Très haute | Planification de l'exécution des tâches par priorité av ... | Fermée | 17.5 | 17.6 | |
2017-07-11 |
Description de la tâche
Dans l’implémentation initiale, chaque tâche reçoit un délai d’attente en dehors de l’AWT-EventQueue.
Cela permet de libérer l’AWT-EventQueue pour d’autres tâches.
Cependant, si une tâche lance un délai d’attente, cette tâche bloque l’ensemble de la file d’attente.
Il faut donc ordonnancer les tâches en fonction de la priorité (une file d’attente par niveau de priorité).
Ensuite, en fonction de la file, on prévoit un délai d’attente hors EventQueue pour libérer l’UI.
|
|
1237 | 1234 | Application | Garde-fou | Critique | Très haute | URI des propriétés différentes sur Windows par rapport ... | Fermée | 16.4 (fork) | 17.6 | |
2017-07-11 |
Description de la tâche
Sur Windows l’URI des propriétés est héritée du système de fichier avec des ‘\’ au lieu de ‘/’ pour définir l’arborescence.
Un garde-fou a du être implémenté pour uniformiser cette stratégie en la fixant définitivement avec des séparateurs ‘/’.
|
|
1252 | | Application | Bug | Critique | Très haute | Problème lors du lancement de la base de données sur de ... | Fermée | 17.6 | | |
2017-07-12 |
Description de la tâche
Lorsqu’on a sélectionné une base de données et qu’on la lance sur un ordinateur lent, le BeDesk-Starter réitère le lancement si le précédent lancement a échoué (ou n’a pas répondu dans un temps imparti).
Or, sur un ordinateur plus lent, le délai de réponse peut être beaucoup plus long que prévu étant donné la nécessité de réaligner l’agent de réplication.
Un garde-fou est donc nécessaire pour interdire le redémarrage dès lors que l’application principale a été lancée sur une base de données.
|
|
1255 | 1108 | Core | Garde-fou | Critique | Très haute | Meilleure prise en charge des erreurs HTTP | Fermée | 17.6 | 17.7 | |
2017-07-26 |
Description de la tâche
De temps à autres, les requêtes REST peuvent recevoir une réponse du type 5xx :
500 Internal Server Error : Erreur interne du serveur.
501 Not Implemented : Fonctionnalité réclamée non supportée par le serveur.
502 Bad Gateway ou Proxy Error : Mauvaise réponse envoyée à un serveur intermédiaire par un autre serveur.
503 Service Unavailable : Service temporairement indisponible ou en maintenance.
504 Gateway Time-out : Temps d’attente d’une réponse d’un serveur à un serveur intermédiaire écoulé.
509 Bandwidth Limit Exceeded : Utilisé par de nombreux serveurs pour indiquer un dépassement de quota.
510 Not extended ( RFC 277415) : la requête ne respecte pas la politique d’accès aux ressources HTTP étendues.
511 Network authentication required ( RFC 65859) : Le client doit s’authentifier pour accéder au réseau. Utilisé par les portails captifs pour rediriger les clients vers la page d’authentification.
Une meilleur prise ne charge de ce type d’erreur doit être mis en place.
Une correction du client HTTPS lui permet à présent de valider le code de réponse HTTP.
Jusqu’à présent, tant qu’il y avait une réponse, même avec un code différent de “200 Ok”, celle-ci était prise ne considération comme une réponse valide.
A présent, on peut filtrer les réponses en fonction du code retourné. Ainsi, en cas d’erreur 504 par exemple, un autre chemin est testé. Ce qui n’était pas le cas (car une réponse http était quand même fournie).
Les nouveaux essais sont répété avec une adaptation automatique du délai entre chaque essai. Plus il y a d’erreurs et plus le délai s’allonge. S’il n’y a pas d’erreur le délai est réduit automatiquement.
De cette manière, si la connexion est de mauvaise qualité ou instable, le délai entre les essais sera plus long et s’adaptera aux besoins du poste local en fonction de la qualité de la connexion disponible.
L’utilisateur est informé des erreurs HTTP et peut suivre les nouvelles tentatives dans la barre de titre de l’application principale.
Prise en charge distincte de l’erreur 511 qui signale la nécessité de s’authentifier via le portail captif du fournisseur d’accès internet.
Les messages d’erreur affichés par le client TRK4B contiennent à présent le dernier code de réponse HTTP et le message associé pour faciliter le dépannage.
|
|
1280 | 1259 | Core | Bug | Critique | Très haute | Problème d'interprétation de date dans certains rapport ... | Fermée | 17.6 | 17.7 | |
2017-07-27 |
Description de la tâche
Lorsqu’on recherche un rapport mensuel, il calcule les dates sur le 1/01/1970.
Par contre lorsqu’on lance le même rapport entre 2 dates et qu’on fixe les dates correctement, il n’y absolument aucun problème.
Il s’agit d’un effet de bord lié au problème FS#1259 .
On a donc carrément éliminé et remplacé des fonctions les quelques occurrences où DateFormat.getDateInstance(DateFormat.SHORT, LOCALE) était utilisé.
On utilise à présent Calendar.getInstance() à la place en l’associant à un parser maison pour traiter directement le format de date EU/FR : dd/mm/yy, dd/mm/yyyy ; mm/yy, mm/yyyy et tt/yy, tt/yyyy.
En cas de problème, le système est résiliant et retourne la date par défaut 1/01/1970, si la date ne peut être interprétée. Il accepte cependant les ‘-’ et les ‘.’ comme séparateurs alternatifs (qui seront normalisés en ‘/’).
|
|
1285 | | Core | Bug | Critique | Très haute | Erreur interne lorsqu'il n'y a pas d'enregistrements et ... | Fermée | 17.0 | 17.7 | |
2017-07-27 |
Description de la tâche
La structure Java TreeMap permet de trouver facilement la première ou la dernière clé.
Cependant, contrairement aux autres méthodes du même genre dans la classe, au lieu de retourner null en cas d’absence d’enregistrement, ces méthodes (firstKey et lastKey) retournent une exception “NoSuchElementException”.
On a donc créé une nouvelle classe qui surcharge TreeMap pour intercepter ces exceptions et retourner null à la place.
|
|
1290 | | Application | Suivi | Critique | Très haute | Problème d'interprétation des dates dans la gestion des ... | Fermée | 17.6 | 17.7 | |
2017-07-31 |
Description de la tâche
Ce problème est un effet de bord du problème FS#1259 .
La date d’échéance des abonnements est mal interprétée.
Adaptations nécessaires.
|
|
1293 | 1290 | UI | Bug | Critique | Très haute | Liste des abonnements erronées, toutes les dates sont p ... | Fermée | 17.6 | 17.7 | |
2017-07-31 |
Description de la tâche
Mauvaise interprétation de la date d’échéance. Tous les documents avec abonnement sont inclus dans la liste.
|
|
1302 | | Services | Implementation | Critique | Très haute | Compatibilité sCurl pour le backend TRK4B | Fermée | 17.7 | | |
2017-08-01 |
Description de la tâche
Le backend TRK4B rencontre un problème avec les interrogations REST via CURL.
Curl ajoute l’en-tête “Expect: 100-continue” dés lors que le corps de la requête est plus volumineux.
Curl s’arrête d’envoyer les données tant que le serveur ne retourne pas “HTTP/1.1 100-continue\n\r\n\r”.
L’interface REST du serveur Track prend donc en considération cette en-tête et retourne “HTTP/1.1 100-continue” tant que la lecture du corps (basé sur la taille content-length prévue) n’est pas terminée.
|
|
1311 | | Core | Bug | Critique | Très haute | Erreur interne lors de l'export de certains rapport en ... | Fermée | 17.7 | 17.7 | |
2017-08-03 |
Description de la tâche
Lorsqu’on essaye d’exporter certains rapports en PDF, une erreur interne se produit et bloque la procédure.
Il est toutefois possible de quitter le logiciel proprement.
L’erreur ne se produit pas systématiquement, mais seulement à quelques reprise, pour finir par fonctionner correctement.
Détails de la fenêtre de débogage:
HTMLDOC *** AutoCheckFontSize patching font size 10 -> 11 ***
HTMLDOC *** AutoCheckFontSize patching font size 6 -> 7 ***
CREATE PageClassicHeaderImage : javax.swing.ImageIcon@1efe5d6a
Exception in thread "Thread-20" java.lang.NullPointerException
at javax.swing.text.FlowView$FlowStrategy.layoutRow(FlowView.java:563)
at javax.swing.text.TextLayoutStrategy.layoutRow(TextLayoutStrategy.java:127)
at javax.swing.text.FlowView$FlowStrategy.layout(FlowView.java:477)
at javax.swing.text.TextLayoutStrategy.layout(TextLayoutStrategy.java:110)
at javax.swing.text.FlowView.layout(FlowView.java:201)
at javax.swing.text.BoxView.setSize(BoxView.java:397)
at javax.swing.text.BoxView.updateChildSizes(BoxView.java:366)
at javax.swing.text.BoxView.setSpanOnAxis(BoxView.java:348)
at javax.swing.text.BoxView.layout(BoxView.java:708)
at javax.swing.text.BoxView.setSize(BoxView.java:397)
at javax.swing.text.BoxView.updateChildSizes(BoxView.java:366)
at javax.swing.text.BoxView.setSpanOnAxis(BoxView.java:348)
at javax.swing.text.BoxView.layout(BoxView.java:708)
at javax.swing.text.BoxView.setSize(BoxView.java:397)
at javax.swing.plaf.basic.BasicTextUI$RootView.setSize(BasicTextUI.java:1722)
at javax.swing.plaf.basic.BasicTextUI.modelToView(BasicTextUI.java:1046)
at bedesk.pageeditor.PrintableEditorPane.a(Unknown Source)
at bedesk.pageeditor.PrintableEditorPane.a(Unknown Source)
at bedesk.pageeditor.PrintableEditorPane.a(Unknown Source)
at bedesk.pageeditor.PrintableEditorPane.a(Unknown Source)
at bedesk.pageeditor.PrintableEditorPane.getNumberOfPages(Unknown Source)
at bedesk.pageeditor.PrintableEditorPane.b(Unknown Source)
at bedesk.printing.Imprimer$MetaContext.getBook(Unknown Source)
at bedesk.printing.Imprimer$MetaContext.c(Unknown Source)
at bedesk.printing.Imprimer.a(Unknown Source)
at bedesk.RepportSet$MyPrivatePDFThread.run(Unknown Source)
L’impression est lancée à partir d’un Thread indépendant et non à partir de l’AWTEventQueue:
WARNING : Task.invoke from Thread[Thread-11,6,main](bedesk.RepportSet$MyPrivatePDFThread)
Certaines données ne sont donc pas nécessairement disponibles au moment où le processus se poursuit (d’où l’erreur null pointer).
Solution : Remplacer le thread MyPrivatePDFThread par une structure Runnable que l’on exécute via le Worker.
Les méthodes compilToPrintableObject() et getBook() de Imprimer.MetaContext ont été également patchées pour s’exécuter uniquement dans le contexte de l’AWTEvenQueue.
|
|
1320 | 1017 | Core | Implementation | Critique | Très haute | Adaptation du paquetage Abstrasy qui utilise quelques i ... | Fermée | 16.4 (fork) | 17.9 | |
2017-09-25 |
Description de la tâche
Le paquetage sun.misc.unsafe n’est plus accessible à partir de Java 9.
Or, le paquetage Abstrasy utilise ce paquet pour les types array-of-*.
Il faut trouver une solution.
Pour le type array, on peut utiliser AtomicReferenceArray. Pour les types array-of-ints et array-of-longs, on peut utiliser AtomicIntegerArray et AtomicLongArray.
Le souci c’est pour les autres types. Il n’existe pas de classe Atomic[*]Array correspondante.
Ce référer à VarHandle du java 9 : http://openjdk.java.net/jeps/193
|
|
1352 | | Application | Bug | Critique | Très haute | Vérification "Registrable" échoue pour le module Logist ... | Fermée | 16.4 (fork) | 17.8 | |
2017-09-06 |
Description de la tâche
La vérification du type “Registrable” échoue lorsque l’on ouvre à nouveau la boîte d’activation des licences.
La requête est mal formatée et n’est donc pas acceptée pour revalidation.
La requête en cas de revalidation n’est pas traitée de la même manière qu’en cas de validation.
Ainsi, depuis la version 16.4, lorsqu’on ouvrait la boîte d’activation et qu’on avait un code Logistique déjà validé, la requête échouait.
Ce problème est résolu.
|
|
1357 | | UI | Bug | Critique | Très haute | Certaines boîtes de dialogue d'erreur fatale de réplica ... | Fermée | 17.8 | x-dev | |
2020-12-31 |
Description de la tâche
Dans certains cas, l’exécution des tâches de resynchronisation de la réplication s’exécute dans le processus EventQueue.
Cela pose un problème car lorsqu’on ouvre une boîte de dialogue modale, celle-ci bloque l’EventQueue.
Pour essayer de résoudre ce problème, on peut par exemple utiliser le Worker et lancer la tâche en arrière plan mais avec une forte priorité. Cela laisse l’EventQueue terminer la tâche en cours sans bloquer l’UI.
Nécessite plus de retour de la part des utilisateurs concernés.
|
|
1361 | 1108 | Serveur | Implementation | Critique | Très haute | Pseudo MerkleTrie pour calculer rapidement la signature ... | Fermée | 17.8 | 17.9 | |
2017-09-29 |
Description de la tâche
Mise à jour “upstream” KeyListDB:
Ajout d’une structure PseudoMerkleTrieSHA256 (voir:https://en.wikipedia.org/wiki/Merkle_tree) capable de calculer très rapidement la clé de hashage SHA-256 de l’ensemble du contenu d’une base de données.
Ceci permet d’améliorer l’agent de réplication qui ne teste plus la somme d’auto-contrôle de chaque bucket indépendamment les uns des autres, mais bien l’ensemble du contenu répliqué de la base de données.
De plus, la méthode utilisant un crypto-hash fiable, cela rend extrêmement difficile toute falsification des données du poste client sans que celle-ci ne puisse être décelée.
|
|
1367 | | Application | Suivi | Critique | Très haute | Mise à jour des outils de développement pour le support ... | Fermée | 17.8 | 17.9 | |
2017-09-25 |
Description de la tâche
Pour pouvoir fournir des paquet Java 9, il faut attendre la mise à niveau des outils de développement.
|
|
1369 | | Application | Spécification | Critique | Très haute | Prise en charge de la compatibilité avec le nouveau Mac ... | Fermée | 17.8 | 17.9 | |
2017-09-29 |
Description de la tâche
Mac OS X 10.13 “High Sierra” sera disponible normalement dès ce 25 septembre 2017.
Le profil de compatibilité du logiciel doit être adapté en conséquence.
La compatibilité sera assurée en même temps que la migration vers Java 9.
L’intégration est toujours en cours suite aux retards accumulés à la sortie du Java 9 par Oracle et la disponibilité des outils pour cette nouvelle version.
Cette tâche est en attente de la fin d’intégration Java 9.
Prise en charge à partir de macOS X10.10 minimum.
|
|
1370 | 1017 | Application | Implementation | Critique | Haute | Nouveau bundle pour macOS avec Java 9 intégré | Fermée | 17.8 | 17.9 | |
2017-09-29 |
Description de la tâche
Nécessité de créer un nouvel exécutable “.app” pour macOS intégrant Java 9 et compatible avec le nouveau macOS 10.13.
Version supportée minimum du système Mac OS X passe à 10.10.
—
|
|
1373 | 1108 | Serveur | Implementation | Critique | Haute | Prise en charge du chaînage de clés SHA-256 par le serv ... | Fermée | 17.8 | 17.9 | |
2017-09-29 |
Description de la tâche
Ajout de la commande append avec chaînage de clés SHA-256.
Un Track devient ainsi une “blockchain” dont la fiabilité est assurée au niveau cryptographique.
|
|
1381 | 1017 | Application | Spécification | Critique | Haute | Nouveau paquet d'installation uniquement pour Windows 6 ... | Fermée | 17.8 | 17.9 | |
2017-09-29 |
Description de la tâche
A partir de Java 9, Oracle ne fournit plus de bundle JRE pour Windows 32 bits.
Nous adaptons donc la distribution des paquets en nous focalisant donc exclusivement sur la version 64 bits.
|
|
1384 | | UI | Bug | Critique | Très haute | Perte de modalité de la fenêtre d'enregistrement des li ... | Fermée | 17.8 | 17.9 | |
2017-10-02 |
Description de la tâche
Lorsqu’on valide la saisie dans la fenêtre d’activation de la licence, on reçoit un message selon lequel aucun code d’activation n’a été saisi, puis la procédure semble se terminer correctement avec une activation.
Avec Java 9, lorsqu’une boîte de dialogue modale est masquée, elle perd la modalité et l’application reçoit la main alors que la fenêtre de dialogue n’a pas encore été détruite.
On utilise donc le worker pour effectuer les opérations différées dans le bon ordre et gérer la main.
|
|
1388 | | Application | Bug | Critique | Très haute | Bug Java 9 : java.lang.NullPointerException @ java.des ... | Fermée | 17.8 | 18.1 | |
2018-03-21 |
Description de la tâche
Nécessite un correctif de Java 9 et/ou du pilote d'impression
Contournement du problème
Descriptif du problème
Avec Java 9 et certains modèles d’imprimante, lorsqu’on essaye d’imprimer un document sur Windows, rien ne se passe.
Liste des modèles d'imprimante affectés par le souci que nous avons répertorié:
Brother MFC-8520DN (confirmé)
Brother MFC-9140CDN (confirmé)
Brother DCP-9055CDN (confirmé)
Brother MFC-9460 (confirmé)
Brother MFC-9330 (non confirmé)
Brother DCP-7055 (confirmé)
Brother HL-4150CDN (confirmé)
Journal de débogage
Lorsqu’on examine le journal de débogage, on trouve par exemple ceci:
AUTO-CONFIGURATION> RECHERCHE DE LA FILE D'IMPRESSION PAR DEFAUT... PATIENTEZ...
AUTO-CONFIGURATION> FILE D'IMPRESSION TROUVEE : Java Printing sur Brother MFC-8520DN Printer ACCUEIL1...
Before Attributes:
media-printable-area = (25.4,25.4)->(159.102,246.238)mm[javax.print.attribute.standard.MediaPrintableArea]
media = iso-a4[javax.print.attribute.standard.MediaSizeName]
Utilisation de l'ancien systeme d'impression... [ignorer le selecteur]
Service non trouve ... Tentative du 2ieme type... Avons-nous de la chance?...
MainWindow Activated...
Service d'impression disponible Brother MFC-8520DN Printer ACCUEIL1
setPrintService...
Print to:Brother MFC-8520DN Printer ACCUEIL1
Attributes:
media-printable-area = (25.4,25.4)->(159.102,246.238)mm[javax.print.attribute.standard.MediaPrintableArea]
media = iso-a4[javax.print.attribute.standard.MediaSizeName]
MyPrintServiceUI.getPaper - PrintableArea :(25.4,25.4)->(159.102,246.238)mm
:X,Y = (72.0,72.0) lpi
:W,H = (450.997802734375,697.9974975585938) lpi
MyPrintServiceUI.getPaper - Media Size :iso-a4
:210.0x297.0 mm
:595.2755737304688x841.8897705078125 lpi
MyPrintServiceUI.getPaper - PrintableArea :(25.4,25.4)->(159.102,246.238)mm
:X,Y = (72.0,72.0) lpi
:W,H = (450.997802734375,697.9974975585938) lpi
MyPrintServiceUI.getPaper - Media Size :iso-a4
:210.0x297.0 mm
:595.2755737304688x841.8897705078125 lpi
HTMLDOC *** AutoCheckFontSize patching font size 6 -> 7 ***
<#> Report length : 5130
<#> Report created in 292ms...
HTMLDOC *** AutoCheckFontSize patching font size 10 -> 11 ***
HTMLDOC *** AutoCheckFontSize patching font size 6 -> 7 ***
CREATE PageClassicHeaderImage : javax.swing.ImageIcon@74d65d9e
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at java.desktop/sun.print.RasterPrinterJob.setAttributes(Unknown Source)
at java.desktop/sun.awt.windows.WPrinterJob.setAttributes(Unknown Source)
at java.desktop/sun.print.RasterPrinterJob.print(Unknown Source)
at bedesk._MainApp.factIconsBar_imprimeFact_actionPerformed(_MainApp.java:2866)
at bedesk.AppAction.printDocument(AppAction.java:264)
at bedesk.ui.iconsbar.document.DocumentsIconsBar$3.actionPerformed(DocumentsIconsBar.java:106)
at java.desktop/javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at java.desktop/javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.desktop/java.awt.Component.processMouseEvent(Unknown Source)
at java.desktop/javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.desktop/java.awt.Component.processEvent(Unknown Source)
at java.desktop/java.awt.Container.processEvent(Unknown Source)
at java.desktop/java.awt.Component.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.Container.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.Component.dispatchEvent(Unknown Source)
at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.desktop/java.awt.Container.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.Window.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.Component.dispatchEvent(Unknown Source)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.EventQueue.access$500(Unknown Source)
at java.desktop/java.awt.EventQueue$3.run(Unknown Source)
at java.desktop/java.awt.EventQueue$3.run(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.run(Unknown Source)
La partie qui est la plus intéressante est celle-ci:
java.lang.NullPointerException
at java.desktop/sun.print.RasterPrinterJob.setAttributes(Unknown Source)
at java.desktop/sun.awt.windows.WPrinterJob.setAttributes(Unknown Source)
at java.desktop/sun.print.RasterPrinterJob.print(Unknown Source)
at bedesk._MainApp.factIconsBar_imprimeFact_actionPerformed(_MainApp.java:2866)
Le problème n’est pas directement dans le logiciel BeDesk. Il s’agit d’un bug de Java 9.
Description du bug JDK-8186987 : https://bugs.openjdk.java.net/browse/JDK-8186987
Ce problème a été rectifié dans l’OpenJDK le 21 septembre dernier, mais Oracle n’a pas encore reporté le correctif dans le Java 9 officiel.
Il semble que le pilote d’impression ne donne pas toujours les informations de résolution (la densité des points par pouce). Du coup, là où les informations devraient se trouver, il y a un pointeur NULL. D’où l’erreur.
Comme décrit par le BTS d’OpenJDK, il serait possible de contourner le souci en forçant la résolution de base (300dpi) en cas d’absence de l’objet PrinterResolution.
A rechercher et tester...
Tentative de contournement du problème à l’aide d’un wrapper qui enveloppe les PrintService retournés par le système. Ce wrapper PatchedPrintService détecte et corrige les attributs erronés ou manquant.
Tests nécessaires...
Malgré le Patch on continue avec :
CREATE PageClassicHeaderImage : javax.swing.ImageIcon@730a4a8c
log> PatchedPrintService.getDefaultAttributeValue(javax.print.attribute.standard.JobSheets)
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at java.desktop/sun.print.RasterPrinterJob.setAttributes(Unknown Source)
at java.desktop/sun.awt.windows.WPrinterJob.setAttributes(Unknown Source)
at java.desktop/sun.print.RasterPrinterJob.print(Unknown Source)
at java.desktop/sun.print.Win32PrintJob.pageableJob(Unknown Source)
at java.desktop/sun.print.Win32PrintJob.print(Unknown Source)
at java.desktop/sun.print.RasterPrinterJob.spoolToService(Unknown Source)
at java.desktop/sun.print.RasterPrinterJob.print(Unknown Source)
at bedesk._MainApp.factIconsBar_imprimeFact_actionPerformed(_MainApp.java:2866)
Or le patch fonctionne bien:
log> PatchedPrintService.getDefaultAttributeValue(javax.print.attribute.standard.PrinterResolution)
PatchedPrintService : NULL javax.print.attribute.standard.PrinterResolution
PatchedPrintService : PATCHING javax.print.attribute.standard.PrinterResolution = 30000x30000 dphi
- printer-resolution = 30000x30000 dphi [javax.print.attribute.standard.PrinterResolution]
Nouvel essai sur un poste affecté à l’aide du JDK:
CREATE PageClassicHeaderImage : javax.swing.ImageIcon@2ca36e49
log> PatchedPrintService.getDefaultAttributeValue(javax.print.attribute.standard.JobSheets)
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at java.desktop/sun.print.RasterPrinterJob.setAttributes(RasterPrinterJob.java:1240)
at java.desktop/sun.awt.windows.WPrinterJob.setAttributes(WPrinterJob.java:696)
at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1510)
at java.desktop/sun.print.Win32PrintJob.pageableJob(Win32PrintJob.java:573)
at java.desktop/sun.print.Win32PrintJob.print(Win32PrintJob.java:390)
at java.desktop/sun.print.RasterPrinterJob.spoolToService(RasterPrinterJob.java:1428)
at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1516)
at bedesk._MainApp.factIconsBar_imprimeFact_actionPerformed(_MainApp.java:2866)
at bedesk.AppAction.printDocument(AppAction.java:264)
at bedesk.ui.iconsbar.document.DocumentsIconsBar$3.actionPerformed(DocumentsIconsBar.java:106)
at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1967)
at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2308)
at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405)
at java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262)
at java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:269)
at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297)
at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297)
at java.desktop/java.awt.Component.processMouseEvent(Component.java:6578)
at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3343)
at java.desktop/java.awt.Component.processEvent(Component.java:6343)
at java.desktop/java.awt.Container.processEvent(Container.java:2259)
at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4961)
at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2317)
at java.desktop/java.awt.Component.dispatchEvent(Component.java:4793)
at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4904)
at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4539)
at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4480)
at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2303)
at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2758)
at java.desktop/java.awt.Component.dispatchEvent(Component.java:4793)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:766)
at java.desktop/java.awt.EventQueue.access$500(EventQueue.java:97)
at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:717)
at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:711)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:99)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:739)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:737)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:736)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:199)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
|
|
1390 | 1388 | Core | Workaround | Critique | Très haute | Correction des attributs des pilotes d'impression à l'a ... | Fermée | 17.8 | 17.9 | |
2017-10-04 |
Description de la tâche
Java 9, révision 9+181, introduit une régression qui empêche l’impression normale des documents.
Le problème se situe dans les attributs d’impression par défaut fournis par le PrintService de Windows pour certains modèles d’imprimantes où la recherche des données PrinterResolution par défaut retourne null alors que l’attribut est marqué comme supporté.
Dans ce cas, nous avons créé une classe de PrintService qui enveloppe le PrintService fourni par le système.
Lorsque le problème se manifeste, le wrapper corrige l’attribut manquant par une valeur par défaut qui devrait être supportée par la plupart des imprimantes.
ATTENTION!
Selon le mode de recherche du service d’impression, le PatchedPrintService initial peut être écrasé par le PrintService original défaillant.
Il faut donc s’assurer que c’est bien un PatchedPrintService qui est utiliser en finalité.
|