On ne peut pas supprimer de référence dans le stock.

Cela peut créer un problème de cohérence référentielle dans la base de données (problème lié à l’OCCL).

De plus, la suppression des références supprime également l’historique lié à la référence.

—

Dans les révisions ultérieures, nous ajouterons une méthode qui permet de désactiver et de mieux gérer les références au niveau de l’UI.

Une série de boites de dialogue d’avertissements sont ajoutées pour prévenir les problème de cohérence de données (lorsqu’on modifie des données alors que d’autres données sont déjà en cours d’édition).

Contrairement aux autres types de données, les documents s’éditent directement sans passer par un dialogue modale.

Il faut donc prémunir l’utilisateur contre toute autre modifications alors qu’un document est en cours d’édition.

Sur certains mac, à la fin du chargement de l’UI de l’application principale, le simple fait de cliquer dans le menu principal déclenche des effets de bords.

Il semble que cela soit lié au thread de contrôle de la piste d’audit qui se réalise en tâche de fond.

Il arrive de manière totalement aléatoire que la liste des tâches de la procédure de démarrage ne se lance pas à l’ouverture de l’UI de l’application principale.

Aucune exception n’est envoyée. On ne sait donc pas pourquoi elle ne démarre pas.

Si on utilise une police embarquée avec le logiciel, il n’y a jamais de souci lors de l’impression PDF.

Cependant, il peut arriver qu’une version d’une des polices embarquées soit aussi installée sur le système.

Le système d’impression et de rendu utilise donc la version du système plutôt que celle qui est embarquée avec le programme.

Le souci, c’est que la version de la police qui est installée sur le système n’a peut-être pas la même licence que celle que nous fournissons avec le logiciel.

Si celle-ci dispose d’une licence qui empêche son intégration dans les PDF, elle peut être protégée par DRM.
Celui-ci agit comme une sorte de contre-mesure qui pénalise le processus de rendu qui a essayé de l’utiliser d’une manière inappropriée.

Cela occasionne des erreurs de rendu ici et là.

Aussi, au moment du démarrage, le logiciel BeDesk teste toutes les polices du système, il détermine si une police peut être ou non utilisée.

Il le fait dans un autre processus qui est indépendant du système de rendu et d’impression. Un processus qui est sacrifié de toute façon, donc sans répercussion.

Le souci, c’est que lorsqu’une police est validée, jusqu’ici, c’est son nom qui est la clé.

La version de la police incompatible peut donc passer pour compatible. Ainsi, dès lors que l’on utilise une seule fois cette police (pour un aperçu ou un rendu PDF, par exemple), cela entraîne des erreurs dans l’affichage de l’application et bloque le système d’impression PDF.

—

Il faut donc également comparer le contenu du fichier source de la police.

Si le cache de polices contient des fichiers altérés, on doit les remplacer.

On doit tester non seulement la police, mais aussi son fichier avant de l’utiliser.

Lorsqu’on envoie une facture par e-mail (volet de fonction “Communiquer” à droite du panneau Synthèse), l’évènement IMPRIME n’est pas ajouté au journal.

Lorsqu’on envoie un lot de factures par e-mail via une opération par lot, l’évènement IMPRIME n’est pas enregistré dans le journal.

Lorsqu’un document est exporté en PDF, son état d’impression est modifié vers TRUE.

La méthode effectue bien ce changement. Toutefois, c’est la référence de l’ancienne révision du document qui est enregistré et non la nouvelle.

—

Ce bug a des répercussion sur plus autres signalement et sa résolution les corrige également par effet de bord.

—

Corrigé.

On a constaté que certains problèmes d’OCCL ne proviennent pas d’un conflit de version au moment d’ajouter un nouvel enregistrement. Le leader devrait disposer de toutes les données pour pouvoir enregistrer une nouvelle données supplémentaire. Il a donc forcément contrôlé l’OCCL avant d’enregistrer dans le flux de réplication.

Cependant, on constate que certains utilisateurs rencontre un souci d’OCCL alors qu’ils sont seuls à travailler sur la base de données.

Après vérification, il s’avère que la base du problème n’est pas un souci d’OCCL, mais d’une erreur de CAS.

Pour une raison inconnue, le numéro de ligne de lecture du Track repart à zéro. Ce qui a pour conséquence de faire repartir la lecture du Track à partir du début avec des données qui sont plus récente et donc qui n’ont pas l’OCCL attendu. D’où l’erreur d’OCCL.

Le système fonctionne quant même en protégeant les données locale. Les fichiers locaux restent inchangés.

Cependant, l’erreur annoncée n’est pas correcte.

De plus, on ne sait pas pourquoi le numéro de suivi de la ligne de Track repart à zéro intempestivement.

Il y a peut-être un souci sur le disque de l’utilisateur.

Le problème résulte peut-être du nombre de compaction très fréquent le LogView _Meta qui n’à que très peu d’enregistrements.

—

On peut sans doute remplacer l’enregistrement “replication-agent:follower” de _Meta par un simple fichier mappé qui supportera nettement mieux les ré-écritures.

—

Implémenté sous la forme d’un VMemEngine sur la page “zero” du réplicateur. Nécessite beaucoup moins d’accès disque et est sécurisé par un journal.

Jusqu’à présent la ligne de lecture du Track était post-incrémentée.

Le numéro était donc incrémenté après consume. Cependant, le callback du gestionnaire d’évènement ne peut pas savoir si la dernière ligne est atteinte. S’il relance la resynchronisation, on peut entrer dans une boucle.

En pré-incrémentant la ligne de lecture, on est sûr de ne pas lire plusieurs fois la même ligne de Track lors du following de réplication.

Suite à une régression la méthode resync revient à un consume_once.

Il faut boucler tant que qu’il y a d’éléments dans le track avec resync.

Une méthode resync_once est ajoutée pour l’ajout en ligne via callback event.

Remplacement de la stratégie de post-incrémentation du numéro de ligne dans le Track (donc après répercussion) par une stratégie de pré-incrémentation du numéro de ligne (avant propagation par _callbackListeners().

Ceci permet de facilité la gestion des boucles de lecture pour les followers.

Sans ce correctif, un follower peut soit ne pas récupérer toutes les données du Track, ou alors tourner indéfiniment sur la dernière ligne.

Les fonctions internes de l’implémentation de Java 9 pour Windows utilise les instructions AVX2 du processeur pour le calcul des clés de hashage SHA2 (SHA-512). Ceci permet de multiplier les performances par 2.

Cependant, l’implémentation de Java 9 essaye d’exécuter des instructions AVX2 même sur un processeur qui ne supporte pas ces instructions.

Il peut donc y avoir divers problèmes ainsi que des plantage de Java dès lors que le serveur de base de données est ouvert et commence à lire la blockchain de la piste d’audit qui nécessite l’usage de clés SHA2 pour le chaînage des blocs.

Ce bug n’est pas un bug du logiciel BeDesk, il s’agit d’un bug de Java.

Il revient donc à Oracle l’éditeur de Java de le résoudre.

Voici le lien vers le descriptif du bug sur le site de développement de l’OpenJDK:https://bugs.openjdk.java.net/browse/JDK-8194494.

Il n’y a malheureusement rien que l’on puisse faire au niveau du logiciel BeDesk pour contourner ce problème. La solution doit être publiée par Oracle avec une mise à jour de Java.

—

Un correctif est prévu par Oracle dans Java 10.

Nous utiliserons donc Java 10 en remplacement de Java 9 dès qu’il sera disponible.

RAPPORTS DE BUG : JDK-8200214

• https://bugs.openjdk.java.net/browse/JDK-8200214.
• https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8200214.

ORACLE A MARQUÉ CLAIREMENT QUE CE PROBLÈME NE SERA PAS RÉSOLU! : Aucune solution ne sera donc apportée.

On a constaté que les applications empaquetées avec le javapackager du JDK-10 (Java 10) ne démarre pas sur Mac OS X 10.10.

Lorsque l’application est lancée, une erreur “/Applications/BeDesk-Express.app/Contents/MacOS/libpackager.dylib not found”.

Or, le fichier est bien présent dans le paquetage.

Il y a donc un problème de compatibilité entre Java 10 et Mac OS X 10.10.

En outre, cette erreur ne se produit que sur Mac OS X 10.10.

Si vous utilisez une version plus récente de Mac OS X, l’erreur ne se produit pas.

Un rapport de bug a été envoyé à Oracle l’éditeur de Java et nous attendons que celui-ci soit pris en compte.

En attendant, on a constaté que si l’on installe directement le JDK-10 sur la machine, on peut démarrer l’application BeDesk via une ligne de commande.

On a donc créé un Automate Apple qui permet de lancer l’application plus aisément.

Le moteur d’impression utilisé jusqu’à présent date de quelques années et a atteint ses limites quant à la vitesse de rendu et à l’utilisation des ressources.

Le développement d’un nouveau moteur d’impression (générateur de rapports) doit être sérieusement envisagé.

Le nouveau moteur doit être plus rapide, plus puissant et moins gourmand en terme de ressources.

Ceci peut être planifié pour la version 19.

Etant donné le retrait de la fonction de suppression des références, il est nécessaire d’améliorer la qualité de la gestion des articles.

La raison du retrait de la fonction “supprimer” consiste à répondre à la contrainte logique qu’il est nécessaire de maintenir pour préserver la cohérence référentielle des données (les jointures logiques entre les articles des documents et le stock).

On peut toutefois améliorer considérablement la gestion en appliquant des masques qui ne laissent visibles à l’utilisateur que les données pertinentes en fonction des actions qu’il entreprend.

On obtient ainsi des vues plus faciles à utiliser.

Ainsi par exemple, on peut supprimer de la vue courante toutes les références “périmées” ou inactives. Cela ne laisse plus à la vue de l’utilisateur que les références actives.

Les éléments n’étant que masqués, et non supprimés, la cohérence est préservée.

Lorsque l’application démarre et en arrive à la phase de resynchronisation des données, le logiciel se fige au moment de l’affichage de la boite de dialogue de progression.

Le souci n’apparaît que sur Mac OS X. Aucun signalement sur Windows ni sur Linux. Il s’agit donc d’un souci lié à la plateforme OS X.

Il existe en effet de nombreux problèmes liés à la plateforme Mac OS X et qui sont répertoriés au niveau de Java pour OS X par Oracle:

• https://bugs.openjdk.java.net/browse/JDK-8194635
• https://bugs.openjdk.java.net/browse/JDK-8179209
• https://bugs.openjdk.java.net/browse/JDK-8068222
• https://bugs.openjdk.java.net/browse/JDK-8059608
• https://bugs.openjdk.java.net/browse/JDK-8198684
• etc...

Ces signalements sont souvent liés à des problèmes de concurrence du type dead-lock qui ne se présentent que sur OS X et non sur Windows ni Linux.

En outre, dans le cas qui nous occupe, le souci ne se manifeste pas systématiquement. Le problème est intermittent. Ce qui complique nettement sa détection, son analyse et par conséquent sa résolution.

Lorsque le souci se produit, il n’existe qu’une solution : Forcer à quitter le logiciel (voir comment procéder : https://wiki.bedesk-express.com/osx:force_exit).

—

Analyse en cours...

—

On a réussit à reproduire le souci sur un poste d’essais après des dizaines de démarrages successifs. Le souci semble se produire plus fréquemment juste après une mise à jour des fichiers exécutables du programme. Par la suite l’application semble se stabiliser. Bien sûr, il n’y a aucune raison particulière pour que le souci soit plus fréquent à ce moment, à moins que OS X ou une autre application tiers accéderait aux fichiers au même moment.

• Interaction indésirable avec un logiciel tiers comme un antivirus par exemple ?
• Effet de bord indésirable dû au GateKeeper de mac OS X ?

A défaut de trouver l’origine exacte du problème, envisager une solution de contournement de manière à éviter d’utiliser les fonctions défectueuses de OS X.

—

Recherche en cours...

—

Solution de contournement des fonctions défectueuses en cours de développement...

On a constaté des erreurs de conversion lors de l’usage intensif en mode multi-thread du composant Java NumberFormat.

Une solution consiste à créer une nouvelle instance de NumberFormat pour chaque conversion. Cependant, cela nécessite un usage très intense du GC.

On peut raisonnablement réutiliser la même instance pour éviter de devoir la reconfigurer à chaque appel.

Cependant, il faut synchroniser l’objet.

On a donc créé un adaptateur qui synchronise l’accès aux méthode de l’instance NumberFormat.

Le souci ne se présente plus.

Attention, le souci peut affecter toutes les révisions antérieures dés lors que l’usage des méthodes parse() et format() est intensif et multi-threadé.

—

Le garde-fou fonctionne correctement.

Lorsqu’on crée une note de crédit automatique sur base d’une facture où un montant a été indiqué dans la case “Acompte”, ce montant d’acompte s’ajoute au total à payer.

Le montant final ne correspond pas alors à celui de la facture d’origine.

—

Problème confirmé.

—

Contournement du problème : Corriger le montant d’acompte à zéro.

Comment procéder ?

Vous ne pouvez pas corriger l’acompte directement en remplaçant son montant par zéro.

Le logiciel dispose d’un garde-fou qui empêche la saisie d’un montant d’acompte supérieur à celui du document. or, votre document à un montant total négatif. Zéro est donc plus grand que le montant du document.

Pour cela, ouvrez la table des articles du document et remplacez la quantité ‘-1’ par ‘1’ de manière à faire passer le montant négatif en positif.

Après cela, rectifiez le montant dans la case “Acompte” par ‘0’.

Validez.

Ensuite, revenez sur la table des articles et remettez la quantité correcte ‘-1’ à la place de ‘1’.

Enregistrez le document.

—

Il faut rectifier le module de création automatique de notes de crédit en conséquence.

—

Prévoir aussi une amélioration du contrôle de l’acompte :

Nouvelle formule:

( |ACOMPTE| <= |TOTAL| ) AND ( SGN(ACOMPTE)==0 OR SGN(ACOMPTE)==SGN(TOTAL) )

Introduction du support de Java 11 LTS en remplacement définitif de Java 9 et 10 sur l’ensemble des modules.

Il convient d’appliquer l’implémentation Rx à la génération des documents.

Quelques petites différences inévitables pourront apparaître.

Toutefois, la résolution des problèmes d’alignement et de césure seront éliminés.

—

A NOTER:

La mise en forme des documents sera simplifiée et uniformisée. Certains paramètres n’ayant que très peu d’utilité, ceux-ci seront supprimés au profit d’une mise en forme plus cohérente même si l’utilisateur à introduit des paramètres qui ne sont pas idéaux.

1. Taille de la police des zones “Commentaires” et “Conditions” seront héritées directement du modèle de base et non plus fixés séparément.
   • Suppression de la taille et du choix de la police spécifique aux commentaires (c’est la même que celle du document).
2. Suppression de la taille de police moyenne dans les documents (il reste uniquement la “grande” et la “petite” taille).
3. Décalage minimum à partir de l’en-tête dans les paramètres de grille → Hauteur minimum du cartouche.
4. Nombre de positions du cartouche réduit. Il ne reste que ces 3 positions:
   1. Verticale
   2. Horizontale en haut.
   3. Horizontale en bas.
5. Tous les montants significatifs sont alignés à droite dans une colonne dont la largeur est uniformisée à 12% de la largeur de la zone d’impression.
6. La marge interne des cellules passe de 4pt à 3pt pour un meilleur usage de l’espace disponible.
7. Ajout de la prise en charge de la marge interne de l’en-tête et du pied de page.
8. “Sur-magination” → “Espace de séparation par rapport au corps” (du document).

Le niveau minimum de rétro-compatibilité est fixé à la version 18.0-250, c-à-d la première version certifiée du logiciel.

Les utilisateurs qui utilisent toujours une révision antérieures peuvent faire appel au support technique pour bénéficier d’un service de conversion et de certification des fichiers.

Le nouveau système de protection de macOS bloque par défaut les services d’accessibilité.

Pour en bénéficier, il faut absolument autoriser ces services pour l’application dan les préférences système / Sécurité / Accessibilité de macOS.

Il n’existe aucun moyen d’établir ce paramètre via le logiciel BeDesk lui-même.

Les services d’accessibilité concernés sont :

1. La classe Robot de Java.

(1) La classe Robot est utilisée par le service d’arrière plan “StayAwakeDaemon”. Ce service empêche l’ordinateur d’entrer en mode veuille par lui-même.

La mise en veille peut entraîner des problèmes dus au fait que certains utilisateurs laisse la session de leur logiciel ouverte de façon indéfinie. Cela bloque le système de sauvegarde de sécurité et empêche la maintenance des fichiers.

S’il y a une ligne vide dans le texte de l’adresse du contact, une erreur interne se produit.

Il semble que la visionneuse Adobe Reader éprouve des problème à ouvrir certains fichiers PDFs.

Il est difficile de dire exactement pourquoi car le message d’erreur ne fourni aucune explication du problème.

Nous investiguons.

Si on ouvre un fichier pour lequel Adobe Reader pose problème avec une autre visionneuse, le fichier s’ouvre parfaitement et ne pose absolument aucun souci.

Vous pouvez ainsi ouvrir sans souci les fichiers PDF avec Chrome, Firefox ou même Edge. Aucune visionneuse ne signale de souci.

Il n’y a que Adobe Reader qui pose problème. En outre, aucune description de l’erreur n’est fournie. Il est donc difficile de savoir exactement ce qui est à l’origine du problème, mis à part le fait que Adobe Reader en particulier rencontre un souci.

Documentation qui pourrait éventuellement être liée:

• https://issues.apache.org/jira/browse/PDFBOX-1423
• https://forums.adobe.com/thread/464841

L’origine du problème a été isolé dans le composant pdfbox-graphics2d (Graphics2D Bridge for Apache PDFBox).

En attendant qu’une solution soit trouvée au niveau de ce composant, nous avons réintroduit le composant iText uniquement pour le rendu des documents. Une fois rendu, le contenu est ajouté via PDFBox pour fournir un fichier conforme à la norme PDF/A-3.

Nombreux essais : tout semble ok.

Application intempestive du mode TVA 20% dans une base de données autoentrepreneur.

—

Confirmé.

—

Établissement d2 garde-fous:

• Forçage du mode saisie TTC des prix des articles (le prix TTC est le prix sans TVA dans ce cas)
• Forçage du taux de TVA à zéro quelque soit les informations de TVA introduites dans la fiche du client.

—

Résolu.

Apple exige à présent d’enregistrer de façon notariale les paquets d’installation des applications en vue de permettre leur installation et leur utilisation sur macOS 10.14.6 et plus récent (donc Catalina y compris).

Cela nous oblige à allonger la procédure de création des paquets pour macOS et nécessite une plus grande charge de travail.

Cette obligation supplémentaire imposée par Apple implique, qu’en plus de l’obligation d’être enregistré comme développeur et l’achat d’un certificat dédié auprès d’Apple, il faut à présent passer par une procédure de “notarization” à défaut de laquelle les applications ne peuvent plus s’ouvrir sur les postes des utilisateurs (tout du moins sans désactiver Gatekeeper).

La procédure est relativement complexe et peu documentée.

Nous nous efforçons donc d’assurer tant bien que mal la pérennité de la diffusion des paquets de l’application pour macOS en tenant compte de ces changements imposés.

Toutefois, il semble évident qu’Apple s’évertue à rendre l’usage de sa plateforme payante AppStore incontournable. S’il devait advenir que l’application BeDesk express pour macOS devait finalement n’être disponible que via la plateforme AppStore, la continuité du support pour macOS serait du même coup remise en question. Cela impliquerait très probablement un changement de prix à l’attention des utilisateurs sur macOS.

Le calcul de la position de l’adresse du client est décalé par rapport au bord de la feuille et non plus de la marge.

Il faut un garde-fou dans l’import d’anciennes base de données pour replacer l’adresse à la position correcte.

—

Solution de résolution temporaire du souci:

Simplement ajouter les mesures de la marge haute à la position verticale et la mesure de la marge de gauche à la position horizontale.

—

L’intitulé dans la configuration doit aussi changer.

• Garde-fou : ok...
• Intitulé des paramètres : ok...

—

Plus besoin de corriger à la main la position à partir de la révision 492.

Par exemple, CANON MX495, mauvaise interprétation des options:

• Choix du bac d’alimentation papier : L’option est masquée lors du choix de l’imprimante.
• Choix du mode couleur : L’option est masqué lors du choix de l’imprimante (verrouillage par macOS).
• L’orientation de la page : étiquette ‘portrait’ non reconnue. A la place, utiliser code numérique 3 et ça fonctionne à nouveau.

—

Confirmé.

—

Correctif: ok

Passage à OpenJDK 11.0.9.1:

https://www.oracle.com/java/technologies/javase/11-0-7-bugfixes.html https://www.oracle.com/java/technologies/javase/11-0-8-bugfixes.html https://www.oracle.com/java/technologies/javase/11-0-9-bugfixes.html

Cumulant en tout, plus de 425 correctifs.

Lors de la création de l’aperçu d’un document ou de son impression, le contenu doit être ajusté à la taille de la feuille.

Nous constatons une régression au travers de laquelle, dans certains cas, les réajustements sont incessants. Le document ne sort alors jamais.

—

Confirmé.
Niveau : Critique.
Priorité : Très haute.

—

En cours...

—

Corrigé.
Déploiement en urgence.

Sur certains mac, on constate que des polices de caractères ne sont plus accessibles suite à de nouvelles restrictions au sein de macOS.

Or, le générateur de fichiers PDF de BeDesk Express doit pouvoir accéder aux fichiers source de ces polices pour pouvoir les intégrer dans les fichiers PDF (les rendant ainsi 100% portables dans le respect de la norme PDF/A3).

Ne pouvant accéder au contenu des fichiers des polices incriminées, le rendu des documents ne peut pas se terminer. Une boucle d’attente se poursuit donc indéfiniment.

—

Confirmé.
Sévérité: Critique.
Priorité: Très haute.

—

Implémentation d’un garde-fou qui remplace les éventuelles polices inaccessibles par une police par défaut incluse directement avec l’installation du logiciel BeDesk-Express.

Nous conseillons la police ‘Open Sans’ qui est compatible de-facto avec l’embarquement PDF.

—

Implémentation: Ok.

—

Tests en cours ... Ok.

—

Nécessite un déploiement...

Les taux de TVA luxembourgeois diminuent de 1% le 1ier janvier 2023.

Prise en charge du code ISO-3166 en vue des prochaines améliorations.

—

Déduction et correction automatique lors du chargement du fichier client sur base des nom de pays et des n° de TVA déjà présent.

—

Ajout du code ISO-3166 dans le formulaire d’édition des fiches de contacts :

• Dans l’adresse principale (adresse de facturation).
• Dans l’adresse de livraison personnalisée (si elle est définie).

—

Enregistrement des codes ISO-3166 pour chaque nouvelle fiche de contact (clients / fournisseurs).

Disposer d’un paquet de déploiement pour chaque système d’exploitation incluant l’OpenJDK 17.

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

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.

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.

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.

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.

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.

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.

—

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.

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.