Il s’agit d’une régression de la version 7.1 de BeDesk 12.

Lorsqu’on crée un document qui doit affecter le stock à partir de la transformation d’un autre document, le stock n’est pas mis à jour en conséquence.

Plus de détails: http://www.bedesk.be/bug/index.php?do=details&task_id=9&project=2

Passage définitif à Java 7 minimum sur tous les systèmes d'exploitation

Le problème du Java pour Mac OS X de Apple

Migration complète et définitive de Java 6 vers Java 7

Impact de ce changement pour les utilisateurs sous Mac OS X

Avantages qui résultent du passage à Java 7

Liens supplémentaires

Implémentation des spécifications de Java 7

Il est nécessaire d’adapter le programme et même de réécrire des portions de celui-ci pour assurer un support complet de Java 7 (spécifications JSR336).

Cela inclut:

• La correction de plus de 718 warnings dans le module principal et 49 dans le BeDesk Starter.
• Des centaines d’optimisations mineures.

Avec la maintenance 2013, BeDesk dispose d’un nouveau système qui permet à l’utilisateur qui souhaite transférer sa licence d’un ordinateur vers un autre de pouvoir le faire sans avoir besoin de demander la prestation d’un service de reconfiguration de son compte/licence à l’assistance personnalisée.

Ceci est rendu possible par la mise en oeuvre d’une méthode hautement sécurisée où la certification de l’utilisateur est particulièrement forte.

Un dispositif automatique ne peut générer lui-même les codes nécessaires pour réaliser une telle opération. Elle se base en effet sur des informations confidentielles que seul l’utilisateur peut connaître et qu’aucun dispositif numérique ne peut prédire par un algorithme quelconque.

En outre, pour accéder à la procédure de reconfiguration, l’utilisateur doit disposer d’informations obtenue au travers de sources différentes non prévisibles. Il est donc très difficile de contourner le dispositif de protection du système de reconfiguration.

A moins que l’utilisateur ne confie ses informations personnelles confidentielles à un tiers, seul l’utilisateur est en mesure de disposer de toutes les informations nécessaires pour pouvoir réaliser la reconfiguration de son compte/licence. Cette procédure est donc une des plus sûr que l’on puisse envisager pour ce genre d’opération.

Cela dit, la procédure de reconfiguration d’un compte/licence de BeDesk 13 est donc totalement gratuite lorsqu’elle est réalisée par l’utilisateur.

Bien sûr, en cas de problème ou de perte de codes, l’utilisateur pourra toujours contacter le support technique pour recevoir l’assistance qui convient.

Lorsqu’on modifie par exemple le format des nombres dans une base de données, il faut redémarrer le programme pour s’assurer de la propagation du changement dans toute l’application.

Si la base est synchronisée pendant ce changement, l’arrêt du programme peut produire un arrêt inopiné.

Il est facile de rétablir les choses en choisissant les bonnes pratiques lors du démarrage suivant: Ne pas restaurer les données de synchronisation qui sont plus ancienne que celle qui sont locale. Et puis, quitter le programme pour synchroniser à nouveau.

Ce n’est pas difficile, mais l’utilisateur peu averti peut aggraver le problème s’il ne fait pas le bon choix lorsque cela lui est proposé.

La correction de ce Bug est planifié pour la maintenance 2013.

Il y a des changements de législation en cours au niveau de la TVA sur le plan européen.

Ces changements ont déjà une répercussion importante sur les mode TVA cocontractant et intra-communautaire en Belgique.

Procédure de mise à jour automatique intégrée

source : Changements en vue des règles de facturation - Démarrez à temps !

Extension de l’application de la directive de l’UE 2010/45/UE à tous les profils des pays appartenant à l’Union Européenne.

La mise en application de cette directive impose notamment l’ajout de la note «auto-liquidation» dans la mention légale de la TVA lorsque le principe de l’auto-liquidation de la TVA est applicable.

Dans certains pays, si cette note n’est pas présente sur les factures, l’émetteur de la facture risque une amende et le client qui reçoit la facture peut se voir refuser l’auto-liquidation de la TVA dans son pays.

De plus il est important de rappeler, qu’à compter du 1er janvier 2013, après l’entrée en vigueur de la directive 2010/45/UE, la TVA devient exigible lors de l’émission de la facture ou à l’expiration du délai visé à l’article 222 de cette directive si aucune facture n’a été émise avant cette date.

Cette directive est applicable dans toute l’Union.

Extension de l’application de la directive de l’UE 2010/45/UE à tous les profils des pays appartenant à l’Union Européenne.

La mise en application de cette directive impose notamment l’ajout de la note «auto-liquidation» dans la mention légale de la TVA lorsque le principe de l’auto-liquidation de la TVA est applicable.

Dans certains pays, si cette note n’est pas présente sur les factures, l’émetteur de la facture risque une amende et le client qui reçoit la facture peut se voir refuser l’auto-liquidation de la TVA dans son pays.

De plus il est important de rappeler, qu’à compter du 1er janvier 2013, après l’entrée en vigueur de la directive 2010/45/UE, la TVA devient exigible lors de l’émission de la facture ou à l’expiration du délai visé à l’article 222 de cette directive si aucune facture n’a été émise avant cette date.

Cette directive est applicable dans toute l’Union.

Déploiement de la mise à jour 8.1.

Test de certification du programme pour Windows 8.

Il semble qu’une régression s’est introduite suite aux modifications apportées par la version 8.2.

Les zones de saisie des commentaires ainsi que des notes des documents n’entre pas en mode d’édition lorsqu’on double-clics dessus.

Il n’y a pas non plus de réaction sur le clique droit pour accéder à l’éditeur via le menu contextuel.

La maintenance 2014 doit prendre en compte des changements importants au niveau de la gestion des modes TVA. Ces changements sont liés à des modifications de taux prévues dès le début de l’année 2014.

Ces modifications toucheront plus particulièrement le profil “France” / “TVA normaux”:

• 19,60% → 20,00%
• 7,00% → 10,00%
• 5,50% → 5,00%

Des modifications seront aussi applicables à la Corse:

• 8,00% → 10,00%

Le taux 2,10% restera inchangé s’il est applicable.

Cette tâche comporte donc un ensemble de sous-tâches importantes. Toutes doivent être appliquées ou résolues avant la publication de la maintenance majeure 2014.

Pour assurer une meilleure prise en compte des contraintes liées aux éventuels changement de taux de TVA, il est nécessaire de réécrire un nouveau gestionnaire interne des modes TVA.

La maintenance 2014 permettra d’introduire ce nouveau gestionnaire.

Les dernières mises à jour de la version 2013 autorisent le changement des taux de TVA, toutefois, les correctifs mineurs apportés ne peuvent que reporter les changements que dans la table de contacts.

Les changements ne s’appliquent pas aux documents.

D’un certain point de vue, il ne faut effectivement pas reporter les changements de TVA aux documents. Ceux-ci sont en effet archivés avec les modes courants au moment de leur création respective. Cependant, l’interface du logiciel (en version 2013) doit être profondément modifiée pour verrouiller les modes lorsque les TVA courantes ne sont plus les mêmes que lorsque le document a été créé. Cette modification est apportée par la maintenance 2014 (qui est donc plus sûre que la version 2013).

L’objet de cette tâche est donc l’implémentation du nouveau gestionnaire interne des modes TVA.

Le logiciel prend en charge jusque 4 modes non nuls et 3 modes “exonération/auto-liquidation”.

Tout changement de taux s’applique automatiquement aux fiches de contacts mais pas aux documents.

Le nouveau gestionnaire interne des modes TVA implémenté par la maintenance 2014 attribue une clé unique à chaque mode TVA. Ceci permet de reporter d’une manière très rigoureuse les modes dans les fiches de contacts.

Cependant, les versions précédentes (2013 et antérieures) ne procédaient pas de cette manière.

Il est donc nécessaire de prévoir un module de rétro-compatibilité pour l’importation des données des versions 8.x, 7.x et 6.x (BeDesk 2013, 2012 et 2011).

Ce module doit reconnaître les modes des anciennes versions et les convertir dans le nouveau format.

Lorsque la conversion a été réalisée, les données sont enregistrées dans le nouveau format. Il n’est donc pas nécessaire de réitérer l’opération ultérieurement.

Cette amélioration permet en outre de réduire légèrement la taille du fichier des contacts.

Lorsqu’un changement de mode TVA se produit, il est important de pouvoir verrouiller les modes déjà appliqués sur des documents archivés.

Ceci rend plus sûre l’utilisation du programme.

La maintenance 2014 apporte donc des améliorations à ce niveau.

Cependant, il peut s’avérer nécessaire de pouvoir actualiser un mode TVA sur un document qui aurait été saisi avec un mode TVA erroné (bien entendu, en tenant compte des aspects légaux).

Aussi, l’interface utilisateur doit proposer la possibilité de déverrouiller un document dans l’éventualité où le mode TVA appliqué à certains articles devrait être rectifié.

Par là, l’utilisateur confirme son souhait de modifier effectivement les modes TVA appliqués à un document. Il ne peut donc pas s’agir d’une modification réalisée par inadvertance.

Révision du problème

Lorsqu’on utilise un modèle de document pour créer un nouveau document où TOUTES les conditions suivantes sont réunies:

1. Le modèle à plusieurs mode TVA et dont le premier est un mode spécial.
2. La fiche du client destinataire ne contient pas d’adresse (rue, cp, ville et surtout pays).
3. Le mode TVA indiqué sur la fiche du client est un mode normal alors que dans le modèle, le premier mode est un mode spécial.

Le document créé est affecté par le mode TVA normal imposé par celui choisi sur la fiche du client et ce même s’il y a plusieurs volets d’articles.

A priori, ceci est tout à fait normal.

Illustrons cela par un exemple.

Imaginons que nous créons un document modèle pour un client assujetti à la TVA normale. Si nous utilisons ce modèle pour créer un document à l’attention d’un client intra-communautaire, le mode normal doit être remplacé par le mode adéquat, c-à-d le mode “Livraisons intracom - auto-liquidation”.

Le raisonnement est également le même dans l’autre sens, si nous créons un modèle de document pour un client à l’origine exonéré de TVA, les documents résultant devront être affecté de la TVA normal si le client ne rempli pas les conditions requises pour bénéficier de l’auto-liquidation.

Ce qui est gênant dans le cas de figure qui nous intéresse, c’est que le modèle commence non pas par un mode normal (généralement le cas en vertu des normes actuelles) mais par un mode spécial qui ne peut être appliqué que par exception. D’où l’importance du mode TVA sélectionné sur la fiche du client. Ce mode force la sélection du mode TVA prioritaire lors de la création d’un document.

Notez que ce mode est aussi choisi par défaut lorsqu’on crée un document sans modèle.

Donc, changer le premier mode sélectionné sur un document modèle n’est pas une erreur.

Cependant, lorsqu’un des autres modes du modèle est identique au mode par défaut, on se retrouve avec un document où le même mode TVA s’applique plusieurs fois. Ceci est un problème qu’il faut éviter.

Suite à l’analyse ci-dessus, il convient de prévoir un garde-fou qui signale un problème lorsqu’un document contient plusieurs fois le même mode TVA.

Notez que l’utilisateur ne peut pas saisir directement plusieurs fois le même mode TVA sur un document en utilisant l’interface du programme.

Le problème se présente par une manière détournée. C’est le générateur de documents à partir d’un modèle (donc l’automation) qui est à l’origine du problème. Une vérification supplémentaire doit être implémentée (ou vérifiée si elle est déjà implémentée, elle ne fonctionne pas correctement - ceci est à voir).

Lors de la vérification d’usage, le générateur de document pourrait essayer de reconnaître si le mode par défaut du client n’est pas déjà présent dans le modèle. Si c’est le cas, aucune adaptation du document ne serait nécessaire.

En fait, ce que nous cherchons, c’est bien une exception pour exclure des cas qui ne doivent pas être adaptés.

Effectivement, il suffit de vérifier si le mode est déjà présent ou non dans l’ensemble des volets de TVA pour résoudre ce souci.

Tests en cours.

Ce garde-fou est une répercussion du correctif  FS#180  appliqué à BeDesk 2013 version 8.4.

Celui-ci est bien entendu adapté en fonction des nouvelles spécifications du gestionnaire de modes TVA de BeDesk 14.

Garde-fou ajouté.

Celui-ci est toutefois légèrement différent de celui inclus dans BeDesk 13.

En effet, dans BeDesk 13 le garde-fou est limité par les spécifications de la version et les caractéristique du gestionnaire de modes TVA. La recherche des modes est obtenu par corrélation. Toutefois, il n’est pas permis de tester des modes normaux nuls.

Dans la version 2014, le garde-fou supporte le cas où un mode normal serait nul. Dans ce cas, ce mode est pénalisé et donc rejeté automatiquement. Il s’en suit que le correctif est nettement plus robuste dans la version 2014 par rapport à celui de la version 2013.

Applique aussi en supplément un garde-fou au niveau de l’import de MDOCX où le mode TVA peut être différent car provenant d’une autre base de données. Le garde-fou retrouve la corrélation entre le mode proposé par le MDOCX et le mode équivalent local.

Description

Comment résoudre le problème ?

Comment appliquer la maintenance majeure conseillée ?

Liste non exhaustive des problèmes qui peuvent être rencontrés :

Déploiement du site web BeDesk-Infinity.com.

Ce site est la plateforme du support technique exclusif des utilisateurs qui disposent d’une licence BeDesk Infinity.

Le site web BeDesk-Express.com est totalement relooké et présente une plateforme d’achats en ligne nettement plus clair et agréable.

L’ergonomie générale du site est aussi très améliorées.

Suite à la révision précédente, une régression a été constatée dans la vérification des formats de numérotation des documents.

Cette régression n’affectent que les formats ajoutés lors de la dernière révision.

Ce correctif corrige le problème.

Il est prévu un changement de TVA au Luxembourg soit pour l’automne 2014 ou pour le début de l’année 2015.

Ce changement sera pris en compte par le logiciel via une mise à jour gratuite.

Nous attendons d’en savoir plus pour établir un calendrier.

Changements prévus :

• Le taux à 15% passe à 17%.
• Le taux à 6% passe à 8%.
• Le taux à 12% passe à 14%.

Par contre le taux super-réduit de 3% reste inchangé.

Notre support technique exclusif a obtenu des informations de la part d’un utilisateur (que nous saluons au passage : “Les Nettoyeurs”).

De là, nous pouvons dégager un garde-fou pour prémunir le logiciel contre l’erreur “Le dossier de l’utilisateur est protégé contre l’écriture”...

Le garde-fou est confirmé : Sévérité critique et priorité flash.

Lorsqu’on importe une base de données BeDesk 12 dans BeDesk 14, et que l’utilisateur n’a pas respecté scrupuleusement les règles habituelles qui s’appliquent aux codes (usage d’espaces, de caractères minuscules, d’accents ou de ponctuation), les codes sont bien filtrés au niveau du gestionnaire de stock, mais pas au niveau des documents. Il s’en suit que les codes utilisés dans les documents peuvent ne plus correspondre à ceux utilisés dans le gestionnaire de stock.

Le garde-fou suggéré consisterait à filtrer également les références dans les documents en utilisant le même filtre que celui de la gestion du stock.

Le problème se manifeste entre autre parce que l’utilisateur n’a pas appliqué les maintenances intermédiaires entre sa version du logiciel et celle disponible maintenant.

Les spécifications considérées comme acquises dans la version actuelle ne sont pas respectées dans la version des fichiers importés. Il est donc nécessaire de définir le niveau de révision à partir de laquelle la filtration des références n’est plus nécessaire et appliquer cette filtration à toutes révisions antérieures (ceci pour éviter d’alourdir le chargement des fichiers au moment du démarrage du programme).

Le garde-fou a été implémenté. Il sera déployé lors de la prochaine mise à jour.

Quelques optimisations mineures ont aussi été ajoutées au passage. Ainsi, le filtrage des références est centralisé de manière à limiter le nombre d’appels successifs de la fonction de filtration.

Jusqu’à présent, le lanceur du programme BeDesk réservait systématiquement 512Mo de mémoire vive pour permettre l’utilisation du programme dans un espace de mémoire vive suffisant (en tenant compte des petites configurations sur lesquelles le programme pouvait être démarré).

Toutefois, ce garde-fou n’a plus de raison d’être car, même une configuration très légère comporte au minimum 1Go de mémoire vive.

L’allocation au démarrage peut donc être supprimée au profit d’une méthode directement déduite des capacités de l’ordinateur sur lequel le programme est démarré.

Les options pas défaut de Java 7 préconise une allocation maximum de 75% de la mémoire vive disponible. Toutefois, seulement un espace de 384Mo est réservé au départ. Si le programme nécessite plus de mémoire vive par la suite, celle-ci peut être allouée à condition de na pas dépasser 75% de la quantité de mémoire vive disponible.

Ce changement implique donc que le logiciel nécessite un ordinateur équipé d’au moins 1Go de RAM (ce qui est plus que largement le cas).

De plus, ce changement peut aussi être considéré comme une optimisation (moins de ressources allouées au départ et possibilité de requérir plus de mémoire au fur et à mesure de l’utilisation).

Cette optimisation pose plusieurs problèmes difficiles à résoudre dans l’immédiat sur Windows et Mac OS X.

En effet, par défaut c’est l’OpenJDK qui est installé sur Linux. L’option du lanceur Java « -server » est donc accessible sans souci.

Par contre, sur Windows et Mac OS X, c’est la JRE qui est installée et non le JDK. De ce fait, la mise en œuvre de cette optimisation nécessite l’ajout d’un Bundle du JRE associé au JDK des systèmes mentionnés.

Il convient donc de différer la mise en œuvre de cette optimisation à une révision ultérieure dans le but de ne pas bloquer la publication des mises à jour courantes et attendues.

Rectificatif : Seul la version Windows souffre du souci. En effet, la version de Java 7 installée sur Mac OS X est la version 64 bits. En réalité, seule la version 32 bits entraîne une limitation. Les versions de BeDesk pour OS X et Linux sont donc publiées avec l’option « -server » alors que la version pour Windows continue d’utiliser la réservation fixe : « -Xms256m -Xmx1024m » (augmenté toutefois à 1Go). Un correctif ultérieur rectifiera ce souci sur Windows uniquement.

Lors des essais visant à corriger le problème  FS#228 , on s’est rendu compte d’un autre souci lié.

Ce problème concerne le positionnement, et plus précisément le centrage de la couleur de fond des cellules ainsi que le placement des bordures horizontales.

Selon tout apparence, le système sous-jacent ne fournit pas les mesures correctes du contenu des cellule lorsque celles-ci applique un centrage vertical du contenu.

Un patch a été ajouté et est actuellement en cours de tests.

A partir de BeDesk 15, la spécification de base pour le protocole de communication avec serveurs SMTP passe définitivement à l’ESMTP.

Cela signifie que BeDesk 15 pourra ne plus être compatible avec certains serveurs SMTP de conception très ancienne. La rétro-compatibilité n’a dès lors plus de raison d’être avec des systèmes aussi anciens (malgré le fait que nous conservons quelques garde-fous dans ce but). Nous adoptons l’ESMTP comme protocole de base.

Lorsqu’on n’applique pas une largeur cumulative de 100% de la largeur, la couleur de fond n’est pas dessinée sur le surface totale.

Par contre, si on applique une largeur cumulée de 100%, les cellules élargies “écrase” le contenu des cellules de taille fixe.

Ceci est un bug qui n’affecte que la version OS X. En outre, ce bug trouve son origine dans la bibliothèque javax.swing.text.html de Java 8 pour Mac OS X.

Il n’y a pas de bug à corriger dans le programme BeDesk lui-même. Par contre, on peut certainement trouver un “workaround”.

On peut penser par exemple à surcharger un painter pour forcer le dessin de la couleur de fond sur l’ensemble du composant tout en déchargeant celui-ci de cette tâche (fond transparent dans ce cas).

Touche également l’outil “Objectifs” et “Plafonds”.

BeDesk 15 utilise et intègre directement un paquet Java 8.

Or, Oracle (l’éditeur de Java) vient de retirer Mac OS X 10.7 de la liste des systèmes compatibles avec Java 8.

Ce changement est donc répercuté très logiquement en conséquence sur le paquet BeDesk 15 par “upstream”.

De ce fait, BeDesk 15 ne peut être compatible avec Mac OS X 10.7. Pour utiliser BeDesk 15, il faut disposer au minimum de Mac OS X 10.8.

Référence : http://docs.oracle.com/javase/8/docs/technotes/guides/install/mac_jdk.html

Le forgeur de paquet doit tenir compte de ce changement important.

Déployer la maintenance.

Utilisation de la signature EV (Extended Validation) pour signer les fichiers d’installation pour Windows.

Cette signature EV élimine le message d’alerte du SmartScreen de Windows 8 et 8.1. Le paquet d’installation est donc directement prêt pour l’installation. Il ne suffit plus que de valider comme si on installait ce paquet sans l’avoir téléchargé d’internet.

Il s’agit d’une amélioration considérable pour faciliter la maintenance du programme sur Microsoft Windows.

Disponible immédiatement.

La réglementation régissant ces services sera modifiée le 1er janvier 2015.

À partir du 1er janvier 2015, les services de télécommunications, de radiodiffusion et de télévision et les services électroniques seront toujours taxés dans le pays du client

1. indépendamment du fait que le client soit une entreprise ou un particulier
2. indépendamment du fait que le prestataire soit établi dans ou hors de l’UE

• Pour une entreprise (personne assujettie à la TVA) = soit le pays où elle est immatriculée, soit le pays où elle a un établissement stable bénéficiaire du service.
• Pour un particulier (personne non assujettie à la TVA) = le pays où il est établi, ou a son domicile ou sa résidence habituelle.

Références

Il semblerait que certains utilisateurs expérimentent le bug JDK-8060036 du compilateur JIT du Java 8 (update 45).

Lien externe: https://bugs.openjdk.java.net/browse/JDK-8060036

Ce bug ne provient pas du logiciel BeDesk lui-même. Toutefois, BeDesk a besoin de Java pour fonctionner correctement.

Messages d’erreur redondants relevés dans la console de sortie:

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at javax.swing.text.GlyphView.getBreakSpot(GlyphView.java:799)
	at javax.swing.text.GlyphView.getBreakWeight(GlyphView.java:724)
	at javax.swing.text.html.InlineView.getBreakWeight(InlineView.java:150)
	at javax.swing.text.FlowView$LogicalView.getPreferredSpan(FlowView.java:733)
	at javax.swing.text.FlowView.calculateMinorAxisRequirements(FlowView.java:233)
	at javax.swing.text.ParagraphView.calculateMinorAxisRequirements(ParagraphView.java:717)
	at javax.swing.text.html.ParagraphView.calculateMinorAxisRequirements(ParagraphView.java:157)
	at javax.swing.text.BoxView.checkRequests(BoxView.java:935)
	at javax.swing.text.BoxView.getMinimumSpan(BoxView.java:568)
	at javax.swing.text.html.ParagraphView.getMinimumSpan(ParagraphView.java:270)
	at javax.swing.text.BoxView.calculateMinorAxisRequirements(BoxView.java:903)
	at javax.swing.text.html.BlockView.calculateMinorAxisRequirements(BlockView.java:146)
	at javax.swing.text.html.TableView$CellView.calculateMinorAxisRequirements(TableView.java:1786)
	at javax.swing.text.BoxView.checkRequests(BoxView.java:935)
	at javax.swing.text.BoxView.getMinimumSpan(BoxView.java:568)
	at javax.swing.text.html.BlockView.getMinimumSpan(BlockView.java:378)
	at javax.swing.text.html.TableView.checkSingleColumnCell(TableView.java:461)
	at javax.swing.text.html.TableView.calculateColumnRequirements(TableView.java:424)
	at javax.swing.text.html.TableView.calculateMinorAxisRequirements(TableView.java:546)
	at javax.swing.text.BoxView.checkRequests(BoxView.java:935)
	at javax.swing.text.BoxView.getMinimumSpan(BoxView.java:568)
	at javax.swing.text.BoxView.calculateMinorAxisRequirements(BoxView.java:903)
	at javax.swing.text.html.BlockView.calculateMinorAxisRequirements(BlockView.java:146)
	at javax.swing.text.BoxView.checkRequests(BoxView.java:935)
	at javax.swing.text.BoxView.getMinimumSpan(BoxView.java:568)
	at javax.swing.text.html.BlockView.getMinimumSpan(BlockView.java:378)
	at javax.swing.text.BoxView.calculateMinorAxisRequirements(BoxView.java:903)
	at javax.swing.text.html.BlockView.calculateMinorAxisRequirements(BlockView.java:146)
	at javax.swing.text.BoxView.checkRequests(BoxView.java:935)
	at javax.swing.text.BoxView.setSpanOnAxis(BoxView.java:343)
	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.getPreferredSize(BasicTextUI.java:912)
	at javax.swing.JComponent.getPreferredSize(JComponent.java:1662)
	at javax.swing.JEditorPane.getPreferredSize(JEditorPane.java:1332)
	at bedesk.ui.SmallAssist.b(Unknown Source)
	at bedesk.ui.SmallAssist$1.actionPerformed(Unknown Source)
	at javax.swing.Timer.fireActionPerformed(Timer.java:313)
	at javax.swing.Timer$DoPostEvent.run(Timer.java:245)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

Concerne la méthode javax.swing.text.GlyphView.getBreakSpot dans le fichier GlyphView.java à la ligne 799...

Un workaround consiste à désactiver la compilation JIT pour cette méthode.

Pour cela, ajouter le paramètre suivant dans la commande de démarrage du Java:

-XX:CompileCommand=exclude,javax/swing/text/GlyphView,getBreakSpot

Nous sommes en contact avec quelques utilisateurs où nous supposons avoir détecter le problème et des tests sont en cours.

Le workaround fonctionne. Reste plus qu’à l’intégré dans la prochaine mise à jour.

Publication BeDesk version 16.0 - rev:54

Publication BeDesk version 16.0 - rev:55

Mise à jour mineur : Révision 56

Mise à jour ‘Flash’ : BeDesk 16, version 16.0 - révision 62.

Nous constatons que le garde-fou de protection destiné à résoudre le problème découvert sur la plate-forme OVH et ajouté dans le révision 62 provoque des soucis pour ceux qui utilisent GMail.

On étudie le problème pour essayer de mieux comprendre ce qui se passe exactement.

De nombreux essais ont permis de déterminer comment contourner le problème tout en conservant la compatibilité entre les plate-formes.

Les modifications apportées devraient permettre l’utilisation plus large tout en éliminant un plus grand nombre de causes de soucis.

BeDesk Express 2016 ver:16.0 - rev:63

On constate la perte de focus lors de l’édition au clavier des cellules dans le tableau des articles du gestionnaire de stock.

Solution de contournement : double-cliquer pour pouvoir reprendre la saisie.

Le souci est due à l’application du dernier champ de la dernière ligne testée à l’ensemble de la colonne.

Généralement, la colonne de la dernière ligne est vide et cela ne pose pas de souci car l’édition est autorisée. Cependant, si le contenu arrive en bas du tableau, c’est l’état de la dernière cellule testée qui fait foi.

Nous avons donc déprécié la méthode interne isEditable() par isCellEditable(table, row, col).

Le souci affecte donc toutes les révisions antérieures. Ce correctif est très important.

Le moteur de base de données BeDesk utilise des tableaux dynamique en mémoire vive. Pour s’assurer que l’utilisation de la mémoire soit progressive en fonction de la quantité de données réelle, on utilise SparseArray.

Ce correctif évite des erreurs internes lorsqu’un SparseArray est vidé puis réutilisé.

Ce correctif élimine donc des causes d’erreurs internes que l’on peut connaître sur toutes les versions précédentes à partir de la version 9.0.

Toutefois, la vidange d’un SparseArray est très rare et ne se produit que dans quelques cas particuliers. Le souci n’a pas été signalé par des utilisateurs. Cependant, il a été détecté avec l’implémentation de la gestion dynamique des tableaux de l’interface utilisateur.

Ce correctif renforce donc la stabilité générale du programme.

Avec la gestion dynamique des tableaux de détails et d’articles, on peut supprimer les options de gestion statique de la mémoire.

Outre cela, ce changement constitue une véritable amélioration.

En effet, les paramètres de configuration supprimés étaient jugés critiques depuis longtemps.

Tout changement nécessitaient le redémarrage du programme pour pouvoir être appliqué.

De plus, si l’utilisateur établissait des limites trop importantes (par inadvertance ou par erreur), des mauvaises valeurs pouvaient empêcher le programme de démarrer correctement, vois même pas du tout.

Avec cette amélioration, le logiciel est plus stable et présente moins de risques pour l’utilisateur distrait.

De plus, cela signifie aussi qu’il n’y a plus de limites à la longueur des documents.

Enfin, si un utilisateur souhaite réaliser un document contenant 1000 ou 10000 articles, il n’est plus nécessaire d’adapter la configuration du logiciel. La taille est adaptée au niveau du document pour chaque mode TVA individuellement et non plus au niveau de l’ensemble des documents de la base de données.

Ce dernier point implique également une économie de mémoire qui peut être considérable en fonction des situation.

Il arrive parfois que certains utilisateurs signalent la désactivation intempestive de leur accès. Parfois, on constate également des pertes de données ou l’apparition non expliquées de fichiers endommagés dans les bases de données de certains utilisateurs.

Les recherches du support technique ainsi que l’analyse anonymisée de l’utilisation de l’application fait apparaître une cause possible : l’ouverture simultanée de plusieurs instances du moteur de bases de données sur une même base de données.

Le logiciel est normalement protégé contre cela via le système d’exploitation de l’ordinateur, particulièrement sur Mac OS X. Cependant, il est assez facile de contourner cette protection (il suffit de faire une copie de l’application pour la démarrer une nouvelle plusieurs fois).

La concurrence au niveau des modifications des fichiers peut avoir des effets indésirables allant du simple écrasement de données à la destruction complète de la base de données.

Il est donc nécessaire d’ajouter un garde-fou supplémentaire qui bloque le démarrage de nouvelles instances du programme lorsqu’il est déjà ouvert sur une base de données.

On peut pour cela reprendre la même méthode de verrouillage que ce que nous utilisons déjà pour garantir la synchronisation.

Pour éviter un blocage définitif, il faut aussi ajouter un TTL. De cette manière, si le programme venait à s’arrêter d’une façon inopinée, lorsque le TTL serait écoulé, on pourrait à nouveau ouvrir la base de données. Cela signifie que le verrou doit être renouvelé périodiquement. S’il n’a plus été renouvelé après un délai donné, c’est que l’application a été arrêtée. On peut donc l’écraser et reprendre.

On utilise un Shutdown Hook pour s’assurer au mieux de l’élimination du verrou. Ainsi, lorsqu’on quitte le programme ou qu’il se ferme normalement, le verrou est toujours supprimé.

Si le programme plante ou rencontre un problème tel qu’il doit être arrêter brutalement, le verrou à une durée de vie (TTL) de 5 minutes. Ainsi, si on relance le programme après 10 minutes d’attente, il doit être possible de redémarrer.

Régression:

Une régression a été signalée dans la révision 72.

Lorsqu’on insère une référence dans la colonne “REF” des détails d’un document, le logiciel ne recherche pas l’article.

Problème confirmé.

Toutefois, il ne se produit uniquement que sur la dernière ligne du tableau.

Si on insère des lignes entre de manière à ne plus éditer la toute dernière ligne du tableau, les références sont traitées correctement.

Idem si on édite d’abord la colonne “Date” avant la colonne “Ref” (et ce même si on est sur la dernière ligne).

Une mise à jour ‘Flash’ doit être réalisée d’urgence.

Correctif disponible.

Mise à jour ‘Flash’ :

Protection contre l’arrêt de l’application par l’utilisateur en cours de démarrage.

On a constater via le “Proactive Customer Care” que certains utilisateurs fermait parfois aussitôt leur application tout juste après l’avoir démarrée.

Ceci est fortement déconseillé car l’application se ferme effectivement alors que le moteur de bases de données est toujours en train de charger les données en mémoire vive. La fermeture force alors de déchargement du moteur alors que la procédure initiale n’est pas encore terminée.

Le garde-fou consisterait donc à interdire la fermeture de la fenêtre de l’application tant que la procédure de démarrage du moteur de bases de données n’est pas terminé.

Implémenté.

Tests en cours.

Lors de la réutilisation du port 587 avec le protocole STARTTLS pour l’envoi de mail, la connexion est établie en SSL.

Ceci ne se produit pas lors du premier envoi, mais lors du deuxième, lorsque le port est réutilisé.

Au lieu de démarrer la connexion non cryptée, puis de passer en mode crypté avec STARTTLS, la nouvelle connexion passe directement en SSL.

On obtient alors le message suivant:

javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
	at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
	at sun.security.ssl.InputRecord.read(InputRecord.java:527)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)

Voici un échantillon du journal:

     > SMTP->Response:[220 xxxxx ESMTP xxxxx Network Relay Mail Servers; Wed, 4 May 2016 10:16:49 +0200]
     > SMTP->Send:[EHLO xxxxx]
     > SMTP->Response:[250-xxxxx Hello xxxxx [xx.xx.xx.xx], pleased to meet you]
     > SMTP->Response:[250-ENHANCEDSTATUSCODES]
     > SMTP->Response:[250-PIPELINING]
     > SMTP->Response:[250-8BITMIME]
     > SMTP->Response:[250-SIZE]
     > SMTP->Response:[250-DSN]
     > SMTP->Response:[250-AUTH LOGIN PLAIN]
     > SMTP->Response:[250-STARTTLS]
     > SMTP->Response:[250-DELIVERBY]
     > SMTP->Response:[250 HELP]
     > SMTP->Send:[NOOP]
     > SMTP->Response:[250 2.0.0 OK]
     > SMTP->Send:[STARTTLS]
     > SMTP->Response:[220 2.0.0 Ready to start TLS]
     > UPGRADE TO TSL SOCKET:[xx.xx.xx.xx:587]
     > Secure-SMTP->Send:[EHLO xxxxx]
     > Secure-SMTP->Response:[250-xxxxx Hello xxxxx [xx.xx.xx.xx], pleased to meet you]
     > Secure-SMTP->Response:[250-ENHANCEDSTATUSCODES]
     > Secure-SMTP->Response:[250-PIPELINING]
     > Secure-SMTP->Response:[250-8BITMIME]
     > Secure-SMTP->Response:[250-SIZE]
     > Secure-SMTP->Response:[250-DSN]
     > Secure-SMTP->Response:[250-AUTH LOGIN PLAIN]
     > Secure-SMTP->Response:[250-DELIVERBY]
     > Secure-SMTP->Response:[250 HELP]
     > Secure-SMTP->Send:[NOOP]
     > Secure-SMTP->Response:[250 2.0.0 OK]
     > USE AUTH LOGIN...
     > Secure-SMTP->Send:[AUTH LOGIN]
     > Secure-SMTP->Response:[334 xxxxx]
     > Secure-SMTP->Send:[xxxxx]
     > Secure-SMTP->Response:[334 xxxxx]
     > Secure-SMTP->Send:[xxxxx]
     > Secure-SMTP->Response:[235 2.0.0 OK Authenticated]
     > Secure-SMTP->Send:[MAIL FROM: <xxx@xxx.xx>]
     > Secure-SMTP->Response:[250 2.1.0 <xxx@xxx.xx>... Sender ok]
     > Secure-SMTP->Send:[RCPT TO: <xxx@xxx.xx>]
     > Secure-SMTP->Response:[250 2.1.5 <xxx@xxx.xx>... Recipient ok]
     > Secure-SMTP->Send:[RCPT TO: <xxx@xxx.xx>]
     > Secure-SMTP->Response:[250 2.1.5 <xxxx@xxx.xx>... Recipient ok]
     > Secure-SMTP->Send:[DATA]
     > Secure-SMTP->Response:[354 Enter mail, end with "." on a line by itself]
     > Secure-SMTP->Send:[.]
     > Secure-SMTP->Response:[250 2.0.0 xxxxx Message accepted for delivery]
     > USE SSL SOCKET:[xxxxx:587]
     > ERREUR> TRANSMISSION EMAIL IMPOSSIBLE...
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?

Le deuxième envoi ne devrait pas commencer directement avec SSL.

Ce problème affecte aussi toutes les révisions de la version 16.1 : C-à-d, les révisions 80, 74 et 72, avec l’ajout du support STARTTLS.

Par défaut, la connexion était du type “KeepAlive” pour de meilleures performances. Cependant, comme la couche STARTTLS s’ajoute sur une connexion en clair, il faut fermer et réinitialiser complètement la connexion avant de pouvoir envoyer un autre message.

Le composant Java 8 rev 92 inclus avec le paquetage BeDesk 16.2 rev:86 ne démarre pas sur Windows 32 bits.

Problème confirmé sur Windows Vista 32 bits.

Confirmé également sur Windows 10 32 bits.

Aucun souci à signalé sur la version 34 bits.

Si on essaye de démarrer le programme à partir de la console MSDOS, on obtient effectivement:

jre1.8.0_92\java.exe n'est pas compatible avec la version de Windows actuellement exécutée.
Vérifiez dans les informations système de votre ordinateur si une version x86 (32 bits) ou
x64 (64 bits) du programme est requise, puis contactez l'éditeur de logiciel.

RÉSOLUTION DU PROBLÈME

Mise à jour ‘flash’ BeDesk Express 2016 ver:16.2 - rev:87