Dans la procédure de migration des fichiers de la version 9 à la version 10, une ré indexation systématique de tous les fichiers ayant plus de 1000 enregistrements a été ajoutée. En effet, du fait du processus de migration (qui procède par ajout un à un des enregistrements dans les fichiers au format V10), la taille des index était considérablement augmentée (multipliée par 2,5).
La ré indexation permet de ramener ces index à la bonne taille, ce qui aura un effet sur les performances futures : taille du fichier d'index plus petite donc aisément chargée en cash par Windows, et taux de remplissage de l'index uniformément égal à 80%, ce qui accélère les ajouts ultérieurs d'enregistrements.

Trois problèmes sont résolus dans la saisie au km :
- Si l'on était sur une pièce où au moins 2 écritures devaient être lettrées, alors, seule la première était lettrée. Les autres étaient ignorés.
- La fenêtre de saisie au km provoquait une erreur si l'on allait en modification de pièce et que l'on cliquait sur le bouton Annuler. La moindre modification sur la nouvelle ligne faisait planter le programme.
- Le libellé du compte de la dernière écriture sélectionnée restait affiché si on était sur une nouvelle écriture.

La date de première échéance ne s'initialisait pas. De ce fait, il n'était pas possible de comptabiliser l'écriture périodique sans revenir en modification sur cette date (accessible seulement en modification).

Dorénavant, cette date s'initialise correctement. Il est toujours possible de la modifier en retournant sur la fiche.

Dans la fenêtre d'édition ou ré-édition des règlements fournisseurs, certains champs étaient mal disposés lorsque le module Devises n'était pas actif.
Au passage, l'icone associé à l'option Traitement/Règlement automatique fournisseurs/Gestion de l'échéancier a été remplacé, pour être identique à celui de l'option Saisie/Gestion de l'échéancier fournisseur.

La procédure d'export des données pour la DGI, accessible depuis le menu Outils/Autres export/Export de données comptables pour la DGI a été une nouvelle fois modifiée, suite à la publication d'un document Questions/Réponses de la DgFip.
Ce document est disponible à l'adresse ci-dessous :
http://www.impots.gouv.fr/portal/dgi/public/popup?espId=2&typePage=cpr02&docOid=documentstandard_6796&temNvlPopUp=true

Dans la fenêtre de gestion présentant la liste des utilisateurs, une 3ème colonne a été ajoutée pour signaler quels sont les utilisateurs qui sont Administrateurs. Un filtrage est possible sur cette colonne.

Sur la liste préparatoire des relance, la sélection effectuée sur le niveau apparait désormais en tête de page, avec la mention précisant si cette sélection a été faite sur le niveau de chaque écriture ou sur le niveau final du client.

Ces modifications concernent tant le mode de relance "standard" que le module dit "NEW".

Pour optimiser les performances lorsque le fichier Clients ou Fournisseurs est volumineux, les tables affichant ces 2 fichiers (liste pour gestion et liste pour sélection) peuvent désormais être basées sur des requêtes SQL. Cet accès par SQL est conseillé particulièrement si on est en environnement C/S AS/400 ; on tire alors partie de la puissance du SQL sur AS/400. Il peut aussi être mis en oeuvre avec profit si on est en environnement HFCS. Mais il doit être évité dans le cas d'une base HF "Classic", où là les performances sont plutôt dégradées par un accès SQL.
Ce choix s'opère dans la Fiche Société, sur l'onglet Tiers. Par défaut, l'accès se fait comme auparavant, c'est à dire par lecture séquentielle directement sur le fichier.
Dès lors que l'accès SQL est activé, les recherches de tiers doivent être faites en utilisant les zones de recherche de la partie haute de l'écran. D'ailleurs, la touche de fonction F2 a dans ce cas un comportement différent : plutôt que d'ouvrir la zone de recherche sur la colonne N° ou Nom du tiers, elle positionne simplement le curseur sur le premier critère de filtrage (recherche par N° ou Nom). Les "loupes" (FAA Windev) sur les différentes colonnes ne doivent être utilisées que pour affiner la recherche principale faite avec les critères en partie haute.

Lorsqu'on active un accès par requête SQL, on peut aussi spécifier le nombre d'enregistrements maximum qui sera extrait par chaque requête SQL. Par défaut, ce nombre est de 1000. Cette limitation est importante pour éviter qu'à l'ouverture initiale de la table pour gestion, où aucun critère de filtrage n'est proposé par défaut, on ne charge la totalité des clients ou fournisseurs par une requête SQL.
Toutefois, si on veut rechercher la totalité des tiers sans tenir compte de cette limitation, il faut tenir la touche Majuscule (Shift) enfoncée au lancement de la recherche.

En version 10, les fenêtres présentant les clients et fournisseurs disposent de deux zones de recherche (filtrage) en partie haute. Chacune de ces zones peut être renseignée d'un ou plusieurs mots, le système n'affichant alors que les tiers pour lesquels tous les mots recherchés ont été trouvés.
Jusqu'ici, la recherche pour chaque mot était de type "contient". Désormais, elle est de type "contient" sauf si le mot se termine par le caractère *. Dans ce dernier cas, la recherche est de type "commence par".
Ainsi, pour rechercher un tiers dont le nom contient VAL, on frappera simplement VAL dans le premier critère de recherche. Mais si on recherche un tiers dont le nom commence par VAL, on frappera VAL*. De même, pour une recherche de tous les tiers d'un département donné (par exemple, 26), on frappera 26* dans le deuxième critère de recherche (ce qui revient à chercher les tiers dont le code postal commence par 26).

Lors de la création d'un bordereau de remise en banque, dans la dernière fenêtre qui s'affiche où l'on voit les lignes qui vont être comptabilisées sur le compte de banque pour ce bordereau, on n'était pas toujours positionné sur la première ligne (cela dépendait de l'ordre de saisie des différents règlements par rapport aux types et aux dates d'échéance de ceux-ci). Or, cela pouvait poser problème si on était positionné sur une ligne qui n'était pas affichée, lorsque la fenêtre avait une petite taille et que l'on avait un grand nombre de lignes (beaucoup d'échéances remises à l'encaissement). Dans ce cas de figure, il y avait un effet d'affichage bizarre : en agrandissant la fenêtre, on voyait la ligne sur laquelle on était positionné, mais avec en surimpression une partie de l'ascenseur du bas de la fenêtre. De plus, dans tous les cas de figure, le libellé de cette ligne était effacé, ce qui provoquait une erreur (avec affichage de type bulle) "Saisie obligatoire" dès qu'on cliquait sur un autre champ de la fenêtre.
Pour contourner ce curieux problème d'affichage dû à Windev, le système positionne désormais systématiquement le focus sur la première ligne de la table.

L'impression d'un compte en mode multi-exercices (possible depuis la version 10 depuis la consultation d'un compte, si cette consultation est elle-même opérée en mode multi-exercices) donnait parfois des résultats erronés : il y avait des soucis quant au traitement des écritures d'à nouveaux.
De plus, pour éviter des résultats incompréhensibles, dès lors que la consultation du compte est opérée en mode multi-exercices, la date de début d'impression du détail des écritures affichée dans la fenêtre d'impression du grand-livre compte par compte est pré chargée avec la date de début de consultation du compte et n'est pas modifiable. L'impression ainsi obtenue est ainsi en phase avec la consultation sous-jacente.

Plusieurs corrections ont été apportées dans la procédure de modification d'une pièce : 
1) lors du rappel en modification d'une pièce multidevises, si on ajoutait une ligne à la pièce par le bouton Nouveau, on avait ensuite un plantage quand on sortait d'un des champs Montant (Débit, Crédit ou Montant en devises) car le système tentait de convertir le montant saisi de la devise de référence dans la devise de la ligne (ou inversement) alors que le code devise de la ligne n'était pas encore renseigné (le cours ne pouvait donc être déterminé, ce qui provoquait une division par zéro).
2) lors de l'utilisation du bouton Rappel, le système ramène désormais le code et le cours devise de la dernière ligne modifiée. Auparavant, le code et le cours devise étaient préchargés quand on cliquait sur le bouton Nouveau, mais uniquement dans le cas d'une pièce en devise et monodevise.
3) de même, lors du rappel en modification d'une pièce en devise de référence, le code devise n'était pas initialisé quand on cliquait sur le bouton Nouveau ou Rappel. Désormais, ce code devise est préchargé avec le code de la devise de référence.
4) quand on cliquait sur le bouton Contrepartie, le montant (débit ou crédit) en devise de référence était initialisé correctement. Mais quand on sortait de ce champ Montant, le montant en devise de référence n'était pas recalculé en conséquence.

Lorsqu'on voulait saisir un règlement client avec lettrage "direct" par N° de pièce (c'est à dire sans passer par la fenêtre de lettrage du compte), il y avait un plantage lors de la validation du règlement. Malgré ce plantage, le règlement était enregistré correctement, mais le lettrage n'était pas fait.
Complément technique : il semble que ce problème était dû à une différence de comportement entre Windev 12 et Windev 18 sur les ordres ChargeProcédure et DéchargeProcédure, car rien n'avait été modifié entre les versions 9 et 10 sur ce point précis du lettrage en saisie des règlements clients.

L'outil permettant de transférer des données d'un dossier en environnement Windows vers un dossier en environnement AS/400 a été amélioré. Jusqu'alors, on ne disposait que de 2 options :
  - Copie depuis l'AS/400 dans le dossier Windows courant
  - Copie du dossier Windows courant vers l'AS/400
Une troisième option a été ajoutée :
  - Copie du dossier courant AS/400 vers un dossier Windows
Cette troisième option permet donc de transférer un dossier comptable en environnement AS/400 vers un répertoire Windows dont le nom est choisi au lancement du transfert. Il n'est plus nécessaire d'être dans un dossier en environnement Windows pour pouvoir effectuer un transfert. Ainsi, quand on dispose d'une licence ne permettant d'ouvrir que des dossiers en environnement AS/400, on peut quand même avec cette nouvelle option transférer un  dossier AS/400 sous forme d'un dossier Windows (dossier Windows qu'on ne pourra pas ouvrir sur ce poste de travail, mais qu'on pourra ensuite déplacer facilement sur un autre poste de travail disposant d'une licence permettant d'ouvrir ce dossier).

L'ajout de document dans la GED via l'interface n'avait pas le comportement attendu. L'interface indiquait que le chemin et le lien n'étaient pas valides. En effet, les balises standards étaient ignorées car on attendait un nom de balise avec une lettre majuscule et le reste en minuscule au lieu du standard où tout est en majuscule.
Désormais, le nom des balises des documents GED doit être en majuscule.

Le mode d'affichage des avertissements en cas de présence d'une mise à jour de logiciel à télécharger a été revu.
Désormais, à l'ouverture de la fenêtre principale de LDCompta, on est prévenu, via une fenêtre "surgissante" en bas à droite de l'écran, uniquement de la présence d'une mise à jour plus récente à version égale. La présence d'une version plus récente n'est pas signalée ici.

Dans la fenêtre A propos, on est prévenu de la même façon de la présence d'une mise à jour à version égale, avec en sus un message en rouge au bas de cette fenêtre A propos :
Une mise à jour est actuellement disponible sur Internet.
Utilisez LDUpdate pour la télécharger et l'installer.
De plus, dans cette fenêtre A propos, et si aucune mise à jour plus récente n'existe à version égale, mais qu'il existe une version plus récente, un message s'affiche au bas de cette fenêtre A propos (pas de fenêtre surgissante dans ce cas) :
Une nouvelle version NN.NN est disponible. Contactez votre
prestataire de services habituel pour en disposer.

Suite à un problème de lettrage aléatoire mais récurrent en saisie de règlement, il a fallu revoir les procédures de validation d'un lettrage.
Jusqu'alors, celles-ci étaient toutes dans une seule fenêtre, et on y faisait appel via un ordre Windev ChargeProcédure, ordre qui n'est en principe plus supporté par Windev depuis quelques années. Cela ne posait pas de problème dans LDCompta V9 sous Windev 12, mais il semble que cela en pose dans LDCompta V10 sous Windev 18.
Et ce malgré la correction N° 35 qui avait résolu en grande partie le problème : avant la correction 35, le plantage était systématique ; avec la correction 35, il est totalement aléatoire !
Pour remédier à ce problème difficilement explicable, les procédures de validation d'un lettrage sont désormais regroupées dans une nouvelle collection de procédure nommé Lettrage. Ainsi, il n'y a plus à faire appel à l'ordre ChargeProcédure.
Toutes les fenêtres de LDCompta qui pouvaient effectuer un lettrage ou délettrage ont été revues pour éliminer les ordres ChargeProcédure, et pour remplacer l'appel des procédures de la fenêtre de lettrage (Letmaj01) par l'appel de procédures globales de la collection Lettrage.

Lorsqu'on lançait Etats et Requêtes depuis LDCompta V10, on avait systématiquement un problème de compilation :
Les informations de compilation de l'application LDCPTV10 ne sont pas complètes (CPL0003).
Et cette erreur initiale entrainait ensuite des erreurs de compilation dans certains états, car tous les éléments du projet n'avaient pas été compilés correctement. Par exemple, l'appel d'une procédure globale au sein d'un état provoquait une erreur, les procédures globales n'étant pas trouvées par le compilateur.

Cela était dû à l'utilisation de types Enumération au sein du projet LDCompta V10, type Enumération qui n'est pas supporté par le compilateur de E&R version 18.
Pour remédier à ce problème, les variables de type Enumération ont été supprimées ; on est revenu à des déclarations plus classiques de constantes.
Remarque : le seul endroit où l'on avait des variables de type Enumération était la nouvelle procédure de saisie des écritures au Km. Seule cette saisie est donc impactée par cette correction.

En saisie des écritures par pièce, on rencontrat parfois l'erreur suivante :
Erreur à la ligne 49 du traitement Méthode LireCours.
Vous avez appelé la fonction MemRecherche.
La zone mémoire n'a pas été créée (utilisez la fonction MemCrée).

Cela venait du fait qu'on utilise, pour contrôler les informations liées à la devise, une zone mémoire qui est créée systématiquement à l'entrée dans chaque procédure de saisie (la première fenêtre de chacune de ces saisies). Mais cette zone mémoire était supprimée à la fermeture de ces procédures (fermeture de la première fenêtre de la saisie). Or, il peut y avoir parfois des appels imbriqués entre celles-ci : par exemple, depuis la saisie des écritures par pièce, on appelle la consultation d'un compte, et depuis cette consultation, on demande la modification d'une pièce. Au retour en saisie de la pièce, la zone mémoire était supprimée et si on ajoutait une ligne à la pièce, cela provoquait l'erreur décrite ci-dessus.
Pour contourner ce problème, la zone mémoire n'est plus jamais supprimée. Et elle est donc simplement rafraichie, et non créée, à chaque début de procédure de saisie. 

Le traitement de migration V9 à V10 d'un dossier comptable  ne s'effectuait pas correctement si on en enchainait plusieurs successivement, sans avoir fermé LDCompta entre temps.
Cela concernait 3 parties de ce traitement de migration :
 - la conversion du fichier des affaires CPACHT en CPAAFF
 - la conversion des tables de répartition analytique CPTBUA en CPATAS
 - la récupération des liens entre écritures et règlements clients du fichier CPTNER dans la zone NRGC du fichier CPTHIS.
Sur les dossiers migrés autre que le premier depuis l'ouverture de LDCompta, on ne récupérait donc aucune affaire analytique, aucune table de ventilation et aucun lien entre règlements clients et écritures comptables.

Dans toutes les procédures de consultation, l'affichage de la ventilation analytique sur les écritures des exercices antérieurs (celles issues des dossiers d'archives) est désormais réalisé.
Cette fonctionnalité était annoncée dans la documentation de la version 10, mais elle n'avait pas été mise en oeuvre jusqu'ici.
L'affichage se fait :

• d'une part directement dans la table présentant les écritures, en consultation compte, pièce, référence, journal ou montant (avec la même règle que pour les écritures du dossier courant : sur chaque axe analytique, on présente la valeur si elle est unique, la mention ++ sinon)
• d'autre part dans la fenêtre présentant le détail de la ventilation analytique d'une écriture, fenêtre accessible soit par un double-clic sur l'une des colonnes présentant la ventilation analytique, soit par l'option Afficher ventilation analytique du menu contextuel.

Dans la saisie au kilomètre, si l'on naviguait d'un champ à l'autre en utilisant la touche Tabulation et qu'on n'utilisait pas la touche Entrée, les champs ne s'initialisaient pas. On perdait le canevas et les automatismes de saisie.
Dorénavant, les champs s'initialisent correctement quelle que soit la touche utilisée entre Tabulation et Entrée.

Un nouveau problème a été découvert concernant l'environnement Client/Serveur AS400 uniquement, lié au fait qu'on utilise en version 10 davantage de requêtes SQL pour accéder aux données (ce qui n'était pas le cas en version 9).
Pour ces requêtes SQL, le système AS400 optimise les performances en conservant "ouverte" toute requête exécutée plus d'une fois. Techniquement, il reste un Open Data Path (ODP) dans le job AS400 pour chacune de ces requêtes. Et il n'existe aucun moyen de fermer cet ODP sauf à fermer le job lui-même, ce qui, quand il s'agit d'un job correspondant à une connexion Easycom, ne peut être fait que par un ordre HFermeConnexion.
Jusque là, ce n'est qu'une question d'optimisation qui ne devrait nullement interférer avec le fonctionnement de LDCompta. Mais le problème vient que, sur un OS/400 en V5R3 (et peut-être aussi en V5R4, cela n'a pas été testé), le système réutilise ces ODP même si on a changé de dossier comptable entre temps (c'est à dire de bibliothèque courante dans le job AS400). Et en conséquence, bien qu'on ait changé de dossier comptable, les données lues dans LDCompta au travers de requêtes SQL présentent toujours les données du dossier ouvert au moment où la requête SQL a été exécutée pour la seconde fois, et pas les données du dossier courant.
Concrètement, cela se manifestait ainsi : pour une recherche client ou fournisseur (F4 en consultation compte par exemple), si la fenêtre de recherche avait été ouverte plus d'une fois dans un dossier comptable AS400, puis qu'on basculait sur un autre dossier comptable géré lui-aussi en environnement AS400, la fenêtre de recherche présentait les clients ou les fournisseurs du premier dossier.
Après des échanges avec AURA Equipement, le fournisseur du logiciel EASYCOM, il est apparu que ce logiciel EASYCOM n'était pas du tout en cause. Il s'agit d'un "bug" de l'OS/400 en V5R3. Mais comme cette version de l'OS/400 n'est plus maintenue par IBM depuis fort longtemps, impossible d'espérer une correction de ce côté là.
Une solution de contournement a donc été mise en place. Désormais, lorsqu'on bascule d'un dossier comptable AS4000 à un autre, plutôt que de conserver la connexion EASYCOM ouverte en changeant simplement la bibliothèque courante, on ferme et rouvre une nouvelle connexion EASYCOM. Ainsi, le job AS400 correspondant à la première connexion est fermé, tous les ODP ouverts dans ce job sont fermés eux aussi et donc en aucun cas réutilisés dans la nouvelle connexion.
Mais le fait de fermer-rouvrir la connexion présente un inconvénient dans le cas où le code utilisateur et le mot de passe nécessaires à la connexion AS400 ne sont pas enregistrés dans le fichier de configuration (LDCParam.INI) et ne sont pas identiques à ceux définis dans LDCompta. Il faut en effet dans ce cas saisir les identifiants de connexion à chaque ouverture ou réouverture de connexion.
Pour régler ce problème, le processus d'ouverture de connexion AS400 a été légèrement revu : dès lors que le mot de passe de connexion à l'AS400 n'est pas connu (pas défini dans le fichier de configuration, pas de mot de passe pour l'utilisateur courant dans LDCompta, ou indicateur AS400User=* ou AS400Password=* dans le fichier de configuration, indicateur permettant de forcer le passage par une fenêtre de saisie des identifiants de connexion sans réutiliser le code utilisateur et le mot de passe de l'utilisateur LDCompta), ce n'est plus la fenêtre standard d'ouverture de session EASYCOM qui est proposée, mais une fenêtre d'ouverture de connexion AS400 propre à LDCompta. On y saisit le code utilisateur AS400 et le mot de passe comme auparavant, mais cette fenêtre intercepte ces identifiants de connexion et peut ainsi les réutiliser lors des changements de société ultérieurs (tant qu'on ne ferme pas complètement LDCompta).
Cette nouvelle fenêtre de connexion est également proposée chaque fois que la connexion AS400 échoue, souvent en raison d'un code utilisateur ou d'un mot de passe invalide. Ainsi, si les données de connexion enregistrées dans le fichier de configuration sont erronées, on peut les modifier dans cette fenêtre (alors qu'avant, l'ouverture de connexion échouait sans qu'on ait possibilité de corriger le code utilisateur ou le mot de passe).
Ce nouveau processus de connexion présente aussi un avantage : auparavant, quand on basculait d'un dossier AS400 à un dossier Windows, puis qu'on revenait sur un dossier AS400 (pour les utilisateurs ayant une configuration "mixte"), il fallait à nouveau saisir le mot de passe. Désormais, ce n'est plus le cas : les identifiants de connexion sont mémorisés à la première ouverture d'un dossier AS400 et seront automatiquement réutilisés pour toute autre ouverture de dossier AS400 faite dans la session LDCompta, tant que cette session n'est pas fermée.

Dans la gestion des clients et fournisseurs, si on triait la table sur une ou plusieurs colonnes, puis qu'on modifiait une fiche tiers, en retour sur la table après modification, on n'était pas positionné sur la ligne qu'on venait de modifiait.
Le problème se produisait quel que soit le mode gestion des fichiers tiers : par accès "fichier" classique ou par requête SQL (choix dans la Fiche Société, onglet Tiers).
En fait, le problème pouvait aussi se produire avec d'autres fichiers que les clients et fournisseurs, mais c'est principalement sur ces deux tables que la possibilité de trier sur diverses colonnes a vraiment du sens et est donc souvent utilisée.

Dans la saisie des écritures au kilomètre, diverses petites choses ont été corrigées :

• quand on frappait, dans le N° de compte, un nom de tiers en lieu et place d'un libellé, et que ce nom de tiers permettait d'identifier un tiers de façon unique, ce nom était remplacé par le N° si on sortait du champ par la touche Tabulation, mais pas si on sortait par la touche Entrée ;
• quand on appuyait sur la touche Entrée en étant dans le champ N° de compte, le système appliquait directement le contrôle de la ligne entière et signalait donc une erreur si le montant n'était pas encore renseigné. Désormais, aucune erreur n'est signalée, et le focus est position sur le champ Montant (Débit ou Crédit selon le type de pièce).
• en cas de saisie avec un canevas, le positionnement sur un caractère précis au sein du champ Libellé ou Code affaire ne fonctionnait pas
• quand le focus revenait sur le N° de compte, par exemple en appuyant sur Majuscule+Tabulation depuis le champ Libellé, la valeur éventuellement déjà saisie n'était pas automatiquement sélectionnée (en bleu). Même chose pour ce qui est des 3 zones analytiques (Section, Affaire, Destination).
• en cas d'utilisation d'un canevas, le positionnement sur la colonne Débit ou Crédit sur la dernière ligne d'un canevas, celle où l'on a choisi le type Contrepartie globale, ne se faisait pas correctement. Le focus arrivait toujours sur la colonne Débit.
• le contrôle de validité d'un compte général par rapport à la date de l'écriture ne s'effectuait pas correctement.
   

Dans la fenêtre de comptabilisation des règlements automatique fournisseurs, si on utilisait le bouton Echéancier fournisseur pour accéder à l'échéancier, et que depuis cette fenêtre de gestion de l'échéancier, on modifiait certaines échéances sur l'onglet Paiement ou sur l'onglet Report Echéances, sans rien modifier sur le premier onglet Echéances, au retour dans la fenêtre de comptabilisation, les données affichées n'étaient pas rafraichies. Celles-ci ne tenaient pas compte des modifications effectuées : affectation bon à payer et/ou code banque, regroupement ou report d'échéances.
Si on lançait la comptabilisation, le traitement était toutefois juste car il tenait bien compte des données qui avaient été modifiées dans la base de données. Ce n'était qu'un problème de rafraichissement d'écran.

Dans la procédure de lettrage d'un compte, lorsqu'on utilisait les boutons Tout pointer ou Tout dépointer, il y avait une anomalie d'affichage. Les écritures étaient bien toutes sélectionnées ou désélectionnées (les totaux de lettrage en bas de l'écran en attestaient), mais la coche verte sur les différentes lignes pointées ou dépointées n'apparaissait pas toujours à bon escient, de même que la couleur de fond en bleu sur les montants pointés. En revanche, en promenant le focus sur les différentes lignes de la table, l'affichage se faisait correctement sur les lignes parcourues. Ce n'était effectivement qu'un problème d'affichage dans la table, dû à une différence de comportement entre Windev 12 et Windev 18.
Complément technique : pour corriger ce problème, le parcours de toutes les lignes de table a été programmé avec un ordre POUR i=1 à Table0..occurrence en lieu et place de POUR TOUTE LIGNE DE Table0.

Depuis la fenêtre de gestion des clients (liste et modification), il est désormais possible d'accéder à la fenêtre de gestion des actions de relance du client courant, via un nouveau bouton Actions. 
Remarque : la fenêtre de gestion des actions de relance ne peut sélectionner les actions que sur un N° de compte précis, c'est à dire un compte collectif + un compte client. Du coup, lors de l'appel de cette fenêtre depuis la gestion d'un client, le choix du compte collectif passé à la fenêtre de gestion des actions de relance se fait ainsi :
- s'il existe déjà des actions de relance pour ce client, on choisit le collectif pour lequel il y a le plus d'actions déjà connues ;
- s'il n'en existe aucune pour ce client, on choisit le collectif indiqué dans la fiche du client, s'il y en a un ;
- à défaut de tout cela, on prend le premier compte collectif client défini dans la table des comptes collectifs (premier dans l'ordre des codes "racine").

Note : au passage, le titre de la fenêtre de gestion des actions de relance a été modifié : Actions de relance au lieu de Actions auparavant.

Les enregistrements des autres auxiliaires n'ayant pas de sous-type était dupliqués à tort avec des codes racines ne correspondant pas à des collectifs de type "autres auxiliaires".
Cela n'avait pour autant aucun impact sur le fonctionnement du progiciel, si ce n'est d'augmenter la taille du fichier inutilement.

Quelques petites corrections ont été apportées sur le bloc-notes, concernant le style de la fenêtre d'affichage du bloc-notes, et le repositionnement de cette fenêtre quand on réduit la taille de la fenêtre principale (le bloc-notes est en effet repositionné de telle sorte qu'il reste à l'intérieur de la fenêtre principale, et ce repositionnement n'était pas toujours correct).
Une petite correction a aussi été apportée, quand à un problème survenant lorsque la barre d'outils était positionnée en vertical et que le domaine EUR-Etats et Requêtes Utilisateur n'était pas activé: l'icone LDVision était mal positionné.

Notez cependant que ces totaux Quantité n'ont pas forcément de sens, car d'un compte à un autre ou d'une section à une autre, les quantités ne sont pas toujours exprimées dans la même unité.
Notez également que la somme des quantités tient compte implicitement du sens : + pour les débits, - pour les crédits.

On rencontrait parfois, dans la saisie au kilomètre (KM), l'erreur ci-dessous à l'entrée dans le champ N° de compte :
Erreur à la ligne 19 du traitement Procédure locale xEffacementAuto.
L'opérateur d'indirection { } est interdit avec une chaîne vide comme paramètre.

Dans les fenêtres de gestion et de recherche des clients et fournisseurs, les règles de recherche générique ont été légèrement modifiées.
Jusqu'alors, si la chaine de recherche frappée sur la première ligne Numéro, Nom, Libellé, Raison sociale comportait plusieurs mots séparés par un espace, le système n'affichait que les tiers comportant tous les mots demandés dans l'un des champs Numéro, Nom, Libellé, Raison sociale. De plus, si l'un des mots se terminait par le caractère *, le système recherchait les tiers dont le Numéro, le nom, le libellé ou la raison sociale commençait par ce mot.
Problème : cela interdisait de fait la recherche d'un tiers dont le nom commençait par une chaine composée de 2 mots, dans le cas des noms composés (par exemple, un nom comme DE BEAUMONT). Si on recherchait en frappant DE BE*, le système recherchait les tiers dont le nom commençait par BE et contenait DE, ce qui n'est pas le cas du tiers dont le nom est DE BEAUMONT.
Pour régler ce problème, la règle de recherche a été adaptée. Désormais, si la chaine de recherche se termine par le caractère *, cette chaine est traitée comme un seul mot (on ne la découpe pas en plusieurs mots en fonction des espaces qui la compose). En revanche, si le caractère * n'est pas le dernier caractère de la chaine de recherche indiquée, cela fonctionne comme auparavant.
Conséquence : si l'on veut faire une recherche de type commence par, il faut l'indiquer sur le premier mot, puis compléter éventuellement par d'autres mots qui seront utilisés avec le critère contient.
Exemple :
 - si l'on recherche DE BE*, le système recherche désormais les tiers dont le numéro, le nom, le libellé ou la raison sociale commence par DE BE.
 - si l'on recherche BE* DE, le système recherche les tiers dont le numéro, le nom, le libellé ou la raison sociale commence par BE et dont le numéro, le nom, le libellé ou la raison sociale contient DE.
Remarque : ce principe fonctionne quelque soit le mode d'accès aux tiers, Accès SQL ou Accès classique, ce mode étant défini dans la Fiche Société sur l'onglet Tiers. Rappelons que si on a choisi le mode d'accès SQL, quand on effectue une recherche de tiers (en saisie d'écriture ou en consultation de compte par exemple) en frappant un code racine suivi du début d'un N° ou nom de tiers et qu'on appuie sur F4 pour lancer la recherche, la recherche est automatiquement de type commence par. Cela est mis en évidence par le caractère * qui apparait dans la première zone de recherche en partie haute de l'écran de sélection du tiers.

Lors de la demande d'édition d'un compte de résultat avec comparatif par rapport à un tableau budgétaire, on avait une erreur si le tableau budgétaire choisi ne comportait pas de ventilation analytique. Le message d'erreur était :
Le tableau budgétaire de la colonne 2 n'est pas ventilé en analytique. Vous ne pouvez pas le sélectionner dans un tableau de bord analytique.
Or, ce message ne doit être émis que lors de la demande d'impression d'un tableau de bord analytique. Il ne concerne pas le cas de l'édition du compte de résultat de la comptabilité générale.

En version 10, la liste de contrôle des écritures tient compte des autorisations d'affichage des comptes. Ainsi, les écritures mouvementant des comptes auxquels on n'a pas accès en consultation sont masquées sur cette liste.
Pour opérer ce masquage, pour ce qui est des écritures auxiliaires, le système tenait compte du N° de compte "saisi", c'est à dire Code racine + N° du tiers, alors qu'il faut tenir compte uniquement du compte collectif, le système d'autorisation des comptes en consultation étant conçu pour fonctionner uniquement avec les comptes généraux.

Note : une modification de même nature a été faite dans la procédure de saisie des écritures par pièce, pour déterminer si on doit afficher ou pas le solde du compte "à la volée" pour chaque ligne de la pièce.

Une modification a été apportée au système de gestion des licences Copyminder afin de mieux gérer les options de traçage du contrôle de licence.

Lorsqu'on lançait l'impression d'un compte depuis la consultation de compte, l'édition se plantait et affichait un message d'erreur. Cela se produisait si un commentaire devait être imprimé.
Désormais, les commentaires s'impriment correctement et il n'y a plus de message d'erreur.

Le diffuseur d'information a été revu et propose une nouvelle interface.
Les informations sont désormais listées en partie haute et elles sont classées par statut de lecture : Non lues en premier, Lues ensuite
La sélection d'une information affiche en partie basse son contenu.
Pour indiquer qu'une information est lue, il suffit de cocher / décocher la colonne Lu.

Lorsqu'on utilisait l'utilitaire LDCptRlb en ligne de commande (avec le paramètre /AUTO), l'application plantait car elle ne pouvait pas accéder au système de licence.
Désormais, l'application prend en compte le nouveau système de licence simple (sans prise de jeton en cas de clé Copyminder de type "réseau") et ne provoque plus de plantage.

Lorsqu'on on souhaitait ajouter un document via un scanner, l'utilisation de l'option Acquisition depuis un scanner via le clic-droit lançait la FAA Choisir une raccourci clavier qui bloquait la fenêtre d'acquisition qui s'ouvrait par la suite.
Désormais, toutes les FAA sont désactivées sur le bouton GED.

Les virements fournisseurs à la norme SEPA peuvent être enrichis grâce à un nouveau paramètre programme.
Pour cela, il faut créer le paramètre programme SEPAPLUS et le renseigner ainsi :
- 1 à 64 : Personnalisation de la balise MsgId. On peut utiliser les caractères suivants pour personnaliser la valeur :
     - % : Code société
     - $$ : Code journal
     - £££££ : Code banque
     - JJ, MM, AA, AAAA : Partie de la date du jour
     - ° (1 ou plusieurs) : N° de l'ordre de virement. Le nombre de symboles correspond à la taille du nombre,
          complété si besoin avec des 0 à gauche.
- 65 : Ajout de l'adresse des fournisseurs (O pour activer)
- 66 : Ajout de l'adresse de l'émetteur (O pour activer). L'adresse est celle indiquée dans la fiche société.
- 129 à 192 : Valeur de la balise Bei

De plus, le nom de fichier final peut être personnalisé avec le caractère ° pour rajouter le numéro d'ordre de virement. Pour rappel, les options possibles dans ce nom de fichier sont :
     - % : Code société
     - $$ : Code journal
     - £££££ : Code banque
     - JJ, MM, AA, AAAA : Partie de la date du jour
     - ° (1 ou plusieurs) : N° de l'ordre de virement. Le nombre de symboles correspond à la taille du nombre,
         complété si besoin avec des 0 à gauche.

2 problèmes ont été corrigés dans la procédure d'édition d'un grand-livre compte.
D'une part, le programme plantait sur un débordement de pile lorsqu'on imprimait un compte ayant un très grand nombre d’écritures sur le journal des à nouveaux.
D'autre part, les écritures d'à nouveaux était ignorées lorsque cette procédure était appelée "en direct" depuis le menu d'édition des grands-livres, mais pas en cas d'appel depuis la procédure de consultation d'un compte.
Cela était dû au fait que cette procédure d’impression « compte par compte » peut gérer le multi-exercice en version 10. Et dans ce cas, il faut ignorer les à nouveaux qui sont postérieurs à la date de début d’affichage. Cela était bien géré en appel depuis la visualisation d'un compte (où on peut éventuellement être multi-exercices) mais pas en appel direct depuis le menu (où là, le multi-exercice n’est pas possible. Du coup, la date de début pour les à nouveaux était reçue  à blanc et tous les à nouveaux étaient ignorés car ayant une date postérieure à cette date de début !).

Dans la procédure d'interface standard en entrée de LDCompta, pour ce qui est de l'intégration de fiches clients et fournisseurs, il y avait une erreur pour ce qui est de l'intégration des RIB et IBAN. Les RIB et IBAN ayant une domiciliation comportant plus de 24 caractères dans le fichier d'interface (ou cette zone est prévue à 25 caractères) étaient systématiquement ajoutés dans LDCompta, même s'ils existaient déjà dans le fichier des RIB. Cela venait du fait que pour détecter leur existence, on comparait la domiciliation reçue dans le fichier d'interface (à 25 caractères donc) à celle présente dans LDCompta (limitée elle à 24 caractères). Il n'y avait donc pas égalité entre ces deux zones, et le RIB ou IBAN était donc ajouté comme s'il s'agissait d'une nouvelle domiciliation bancaire.
Information complémentaire : si votre fichier clients comporte de nombreux RIB ou IBAN en double suite à de nombreuses interfaces successives, il existe un scénario de modification des données par lot permettant d'effacer les RIB ou IBAN en double. Contactez pour cela votre prestataire de services habituel.

Ce nouvel outil permet de renuméroter les immobilisations suite à un changement des paramètres de numérotation des immobilisations. Il permet d'ajuster le nombre de chiffres dans le numéro de chaque immobilisation pour correspondre au paramétrage. Si deux immobilisations ont la même valeur (doublons), celle avec le plus grand nombre de caractères dans son numéro se verra attribuer un nouveau numéro.
Il est possible de filtrer les immobilisations à renuméroter.
Une option permet de combler les trous entre 2 numéros lorsqu'il y a des doublons.
Cet outil est disponible via le menu Outils / Autres outils / Lancer un autre outil / Ouvrir une fenêtre Windev. Il faut alors indiquer l'outil OutiNumImo.

Sur l'onglet Report échéances de la fenêtre de gestion de l'échéancier fournisseur, le système affiche désormais le montant total des échéances qui vont être reportées en regard de chaque date, en sus du nombre d'échéances concernées que l'on avait déjà.
Toutefois, si le module Devises est activé, ces totaux n'apparaissent que si l'ensemble des échéances concernées sont dans la même devise. Dans le cas contraire, et si on veut voir ces totaux, il faut effectuer au préalable une sélection sur un code devise précis (en plus de la sélection sur une date d'échéance limite).

Suite à la refonte en version 10 de l'édition de l'échéancier (critères de tri de l'état entièrement paramétrables), l'escompte sur règlement était mal calculé et mal présenté sur cet échéancier : 
 - sur les lignes "échéances", le repère E marquant les échéances escomptables était superposé avec le montant Bon à payer
 - le montant Bon à payer au niveau du tiers (et aux niveaux de totalisation supérieurs) ne tenait pas compte de l'escompte quand il y en avait
 - le montant de l'escompte calculé pour chaque tiers n'était pas remis à zéro au changement de tiers. On avait donc un montant croissant au fil de l'état.

Tout cela a été corrigé. Désormais, l'escompte est toujours calculé et présenté au niveau de rupture correspondant au tiers, puis sommé aux niveaux de totalisations supérieurs. Toutefois, il faut savoir que le montant de l'escompte calculé ainsi ne correspondra véritablement à celui calculé lors de l'émission des règlements que si les critères de tri de l'échéancier correspondent à ceux utilisés lors d'émission des règlements. Il faut donc que le critère de tri Tiers soit le critère choisi au niveau 4 de totalisation, et que l'on trouve bien aux niveaux 1 à 3 les autres critères (dans un ordre quelconque) : Mode de paiement, Banque, Echéance. Si le tiers est utilisé en tant que critère de tri de niveau 3 par exemple, et l'échéance au niveau 4, le montant de l'escompte sera calculé toutes échéances confondues pour chaque tiers (à mode de paiement et banque de paiement équivalents), ce qui peut provoquer des différences d'arrondi sur le montant de l'escompte.

Dans la saisie au kilomètre (KM), si l'on devait effectuer un lettrage avec une différence de lettrage, les écritures de lettrage étaient créées avec des données incorrectes et on se retrouvait avec le code journal dans le n° de pièce et une date comptable vide.

Jusqu'alors, dans la procédure d'export des écritures pour Quadratus, si on avait dans LDCompta plusieurs collectifs clients ou fournisseurs, tout se retrouvait dans le fichier à destination de Quadra dans un collectif unique (le fichier d'export au format Quadra ne permettant pas de gérer plusieurs collectifs clients ou fournisseurs).
Pour éviter cela, on indique désormais dans cette fenêtre d'export quel est le compte collectif "principal", tant client que fournisseur. Et seules les écritures attachées à ces collectifs "principaux" sont transférées dans Quadra en comptabilité auxiliaire, c'est à dire en conservant leur N° de tiers. Les autres sont reprises en comptabilité générale uniquement, dans le compte général correspondant dans LDCompta au compte collectif de départ, le N° de tiers étant perdu en tant que N° de compte et simplement ajouté en début de libellé.
Exemple : si on a 2 comptes collectifs 411000 et 416000, qu'on indique que le collectif client "principal" est le 411000, les écritures auxiliaires du collectif 411000 seront transférées dans Quadratus en tant qu'écritures auxiliaires, les écritures auxiliaires du collectif 416000 seront transférées dans Quadratus dans le compte général 416000, sans distinction par client (si ce n'est que le N° de client d'origine se retrouve en début de libellé).

Dans la procédure de modification d'une pièce, lors de l'enregistrement final de la modification, la ventilation analytique des différentes écritures était systématiquement "recalculée". Du coup, si cette ventilation analytique se faisait via une ou plusieurs tables de ventilations, c'était le contenu de ces tables de ventilation connu au moment de la modification qui était pris en compte pour calculer la ventilation finale, contenu qui pouvait être différent de celui que l'on avait lors de la saisie initiale de la pièce. De ce fait, la ventilation analytique finale de l'écriture était modifiée, même si on n'avait rien modifié sur l'écriture en question.
Pour éviter cela, on ne recalcule plus la ventilation analytique finale de l'écriture si la ventilation saisie n'a pas été modifiée.
Notez toutefois que si le montant de l'écriture est modifié, cela modifie implicitement la ventilation analytique finale, même si on n'avait qu'une seule ligne de ventilation saisie et qu'on n'est donc pas passé par l'écran de saisie de la ventilation détaillée.
Remarque : au passage, une petite anomalie a été corrigée : la ventilation analytique saisie était mémorisée, pour ce qui est de la quantité, parfois avec 2 décimales et parfois avec 3 décimales. De ce fait, on pouvait perdre la 3ème décimale saisie sur une quantité lors du rappel d'une pièce en modification.

Lors de la recherche des clients à relancer, l'état faisait disparaître les codes postaux et le nom des villes si la valeur ne changeait pas d'un client à l'autre. Désormais, on affiche tout le temps le code postal et la ville. 

Dans la procédure d'export des données pour DGFiP, 2 améliorations ont été apportées :

1. on a désormais le choix du jeu de caractères dans lequel les fichiers sont produits, avec 4 options :

• ANSI Windows (ce qui était fait implicitement jusqu'alors, et qui correspond au jeu de caractères CP-1252)
• ISO-8859-15
• UNICODE UTF-8
• UNICODE UTF-16

2. on a désormais le choix de l'extension des fichiers : .csv (comme auparavant) ou .txt.

Au passage, le titre de la fenêtre et le libellé de l'option de menu permettant d'ouvrir cette fenêtre ont été modifiés : on a remplacé l'acronyme DGI par DGFiP.

Désormais, quand on modifie l'IBAN principal (ou la domiciliation ou le code BIC associé à l'IBAN principal), et qu'l existe une ou plusieurs échéances en attente de paiement par virement référençant l'ancien IBAN principal, le système ouvre une fenêtre proposant 3 choix :
 - Remplacer l'ancien IBAN et/ou code BIC par les nouvelles coordonnées bancaires sur toutes les échéances en attente de
    paiement par virement sur l'ancien IBAN,
 - Conserver les coordonnées bancaires inchangées sur ces échéances en attente de paiement,
 - Gérer l'échéancier pour voir et modifier une à une ces échéances.

Suite à la correction N° 120, dans la procédure de modification d'une pièce, si on modifiait une des zones N° de compte général, Code journal, Date comptable ou Date de pièce, Nature de pièce ou N° de pièce, Libellé écriture, les nouvelles valeurs saisies ne se reportaient pas dans le fichier des écritures analytiques, sauf sur les écritures pour lesquelles on avait aussi modifié le montant, le sens ou la ventilation analytique.
Rappelons que l'objet de la correction N° 120 était d'éviter de recalculer la ventilation analytique finale de l'écriture si la ventilation saisie n'avait pas été modifiée, pour éviter l'impact éventuel d'une modification des tables de ventilation analytique entre le moment de la saisie initiale de la pièce et le moment de la modification de celle-ci. Et pour ce faire, on ne touchait plus du tout aux écritures de ventilation analytique si cette ventilation analytique n'avait pas été touchée en saisie. On avait toutefois oublié le cas de figure où la ventilation analytique n'est pas modifiée, mais où l'on a modifié l'une des 7 zones de comptabilité générale qui sont reprises dans le fichier des écritures analytiques.

Procédure de reprise : si vous avez modifié des pièces durant la période où vous disposiez déjà de la correction N° 120 mais pas encore de cette correction N° 131, et que vous utilisez la comptabilité analytique, il est souhaitable de passer le scénario de modification de données ci-dessous pour rétablir les bonnes valeurs sur toutes les écritures de ventilation analytique.
Pour cela, il faut créer (avec NotePad par exemple) un fichier nommé Modif CPAHIS suite correction 131.scm, dans le répertoire des scénarios (répertoire qui se trouve dans le répertoire des sous-répertoires, de la forme X:\Ldsystem\Fichiers\Compta\Scénario).
Le contenu de ce fichier doit être le suivant :
[PARCOURS]
FICHIER=CPAHIS
CLE=KHIA
DEPUIS=1
JUSQU'A=1
TYPE_MAJ=1
PREPARCOURS=0
[TRAITEMENT_AVANT_MAJ]
SI HLitRecherchePremier("CPTHIS","NECR",HA.NECR) _et_ ...
 (HI.CPTG<>HA.CPTG ou HI.DATE<>HA.DATE ou HI.JNAL<>HA.JNAL ou ...
  HI.NPIE<>HA.NPIE ou HI.DATP<>HA.DATP ou HI.CNPI<>HA.CNPI ou ...
  HI.LIBE<>HA.LIBE) alors
 HA.CPTG=HI.CPTG
 HA.DATE=HI.DATE
 HA.JNAL=HI.JNAL
 HA.NPIE=HI.NPIE
 HA.DATP=HI.DATP
 HA.CNPI=HI.CNPI
 HA.LIBE=HI.LIBE
 HModifie(CPAHIS)
SINON
 iTrt--
FIN
Une fois ce fichier créé, allez dans LDCompta pour exécuter ce scénario depuis l'option de menu Outils/Gestion des fichiers/Modification de données par lot. Sélectionnez l'option Exécuter un scénario existant puis cliquez sur Suivant, sur l'écran suivant sélectionnez le scénario Modif CPAHIS suite correction 131 et cliquez sur Suivant, sur le 3ème écran, cliquez sur Terminer pour lancer l'exécution.
Suite à celle-ci, le système affiche le nombre d'écritures analytiques ayant été modifiées (celles qui présentaient une différence entre écriture de comptabilité générale et écriture de comptabilité analytique sur l'une au moins des 7 zones communes).
Ceci est à répéter pour chaque dossier comptable concerné.

Lors de la comptabilisation d'une écriture périodique, le fait de sortir de la zone montant entrainait l'augmentation du montant de la première ligne d'un euro en trop. 

Jusqu'alors, on avait 2 options de tri possibles pour le bordereau : par montant décroissant ou par N° de règlement.
Il manquait une option "par ordre de saisie".
En effet, habituellement, les chèques sont saisis sur un journal qui est en numérotation automatique. Le N° de chèque est alors saisi dans la référence document. Du coup, quand on imprime le bordereau trié par N° de règlement, le N° de règlement étant toujours égal au N° de pièce, et le N° de pièce ayant été attribué automatiquement dans l'ordre de saisie, on a bien un bordereau trié par ordre de saisie. Mais si on saisit sur un journal qui n'est pas en numérotation automatique, le N° de pièce saisi n'est pas forcément croissant, surtout si on saisit le N° du chèque du client en tant que N° de pièce. Et dans ce cas, on n'avait aucun moyen d'avoir un bordereau présenté par ordre de saisie.

Suite à la correction 123, le message d'erreur 641 indiquant qu'il n'y a plus de licence disponible était remplacé par un message d'erreur disant que la licence n'était pas autorisée pour cette version du programme.

L'option Assistance en ligne, accessible depuis le menu ? du menu principal a été revue afin de proposer le logiciel TeamViewer, logiciel désormais utilisé par l'équipe de Support de LD SYSTEME en lieu et place de NetViewer. Ce logiciel, s'il est trouvé dans le répertoire de mise à jour centralisée (on recherche dans le répertoire des mises à jour centralisées l'exécutable le plus récent dont le nom commence par TeamViever), sera lancé en priorité. A défaut (ou si la touche Control est enfoncée), le programme lance l'ancien logiciel NetViewer (nvclient.exe).
Remarque : le logiciel TeamViever est automatiquement téléchargé dans le répertoire des mises à jour centralisées à chaque vérification de la présence de mises à jour par LDUpdate, si LDUpdate est en version 2.53 ou supérieure.

En saisie des écritures par pièce (principalement, mais d'autres saisies étaient aussi concernées), si on appelait "à la volée" la procédure de modification de pièce en passant par la consultation d'un compte, au retour en saisie, on avait un plantage avec l'erreur :
La procédure yControlerVentilaAna est inconnue
Complément technique : ce problème était du à la gestion des procédures partagées (dont la procédure yControlerVentilAna) entre les différentes fenêtres de saisie des écritures et la fenêtre HIAVEN01 de saisie d'une ventilation analytique. La gestion de ces procédures partagées a été améliorée pour éviter cela, au travers de nouvelles procédures globales zChargeProcédure et zDéchargeProcédure.

Un problème a été détecté dans la gestion des RIB fournisseurs. Pour quelques fournisseurs, le RIB principal observé dans la fiche du tiers ne se retrouvait pas dans le nouveau fichier des RIB fournisseurs CPTRIF, celui assurant la gestion multi-RIB fournisseurs apparue en version 10. Mais dans ce fichier CPTRIF, on trouvait comme RIB principal (c'est à dire celui portant le N° de ligne 1) le RIB d'un autre fournisseur. Le problème est apparu dans plusieurs sociétés, pour quelques fournisseurs, de façon semble t'il assez aléatoire.
Aucune explication n'a été trouvée pour ce phénomène. Toutefois, pour tenter d'y mettre fin, 4 actions correctives ont été menées :

Le code BIC associé à un IBAN est désormais contrôlé. Seuls les codes BIC à 8 ou 11 caractères sont autorisés. Ils doivent être composés uniquement de chiffres et de lettres en majuscules.
D'autre part, des paramètres d'envoi ont été ajoutés dans un nouvel onglet de la fenêtre de préparation du fichier de télétransmission des virements. Ils permettent de paramétrer le format et le contenu du fichier SEPA généré par cette procédure.

Suite aux corrections 120 et 131, dans la procédure de modification d'une pièce en devise, si on modifiait uniquement le cours (ou le code) de la devise mais sans modifier les montants en devise, la ventilation analytique n'était pas impactée par la modification alors qu'elle doit l'être étant donné que cette ventilation est en euros et que les montants en euros doivent être recalculés en fonction du nouveau cours de la devise.
Rappelons que l'objet de la correction N° 120 était d'éviter de recalculer la ventilation analytique finale de l'écriture si la ventilation saisie n'avait pas été modifiée, pour éviter l'impact éventuel d'une modification des tables de ventilation analytique entre le moment de la saisie initiale de la pièce et le moment de la modification de celle-ci. Et pour ce faire, on ne touchait plus du tout aux écritures de ventilation analytique si cette ventilation analytique n'avait pas été touchée en saisie.

Procédure de reprise : si vous avez modifié des pièces en devises durant la période où vous disposiez déjà de la correction N° 120 mais pas encore de cette correction N° 145, il faut dans un premier temps lancer un état de contrôle analytique (menu Editions/Etats analytiques/Etats de contrôle analytique, en prenant le premier des 3 états : Différences de ventilation entre compta géné et compta analytique. Cet état mettra en évidence toutes les pièces concernées. Il faut ensuite rappeler ces pièces en modification une à une et modifier une nouvelle fois le cours (éventuellement sur la 7ème décimale pour que l'incidence soit minime voire même nulle sur le montant en euros) sur les différentes lignes de la pièce, puis valider la modification de la pièce. Cela rétablira une ventilation analytique en euros cohérente avec le montant de l'écriture en devise et le cours de la devise.

Suite au correctif 143, les investigations ont permis d'identifier un cas où le problème était dû à un index corrompu sur le fichier des RIB fournisseurs. De ce fait, les RIB fournisseurs lus n'étaient pas ceux attendus. Il a donc été ajouté 2 nouvelles actions de prévention :

• d'une part, une réindexation systématique du fichier concerné (CPTRIF) a donc été ajoutée lors du contrôle quotidien initié suite au correctif 143.
• d'autre part, un contrôle supplémentaire a été ajouté sur toutes les lectures du fichier des RIB Fournisseurs dans les programmes, pour s'assurer que les RIB qui sont lus sont bien ceux rattachés au fournisseur "courant".

Une explication au souci des RIB fournisseurs a été trouvée. En saisie d'un nouveau fournisseur, si le n° saisi existait déjà dans le fichier des fournisseurs (erreur de doublon), les fichiers des RIB fournisseurs et des RIB internationaux pouvaient tout de même être mis à jour avec le n° erroné.
Les contrôles mis en place par les précédents correctifs ont été maintenus. 

Lors du contrôle effectué à l'ouverture de session, le programme détectait des fournisseurs ayant un RIB principal dans leur fiche, mais n'ayant aucun RIB dans le fichier des RIB. L'outil de recherche et correction des RIB fournisseur, quand à lui, ne faisait pas remonter ce cas de figure.
Par ailleurs, le contrôle des RIB fournisseur a été modifié pour ne plus s'exécuter à l'ouverture des dossiers d'archives ou des dossiers fermés.

De la même manière que les fournisseurs, les RIB clients pouvaient être enregistrés sous un n° de client erroné si, en création de client, le n° saisi existait déjà dans le fichier client. Une erreur de doublon était alors déclenchée, mais les RIB étaient à ce moment là déjà enregistrés avec le n° erroné. La modification effectuée sur les RIB fournisseurs a été reportée dans le programme de saisie des clients.

Plusieurs améliorations ont été apportées dans la procédure permettant de convertir un fichier reçu au format SAGE 100 natif, procédure pouvant être appelée en amont de la procédure standard d'interface en entrée de LDCompta.
Pour plus d'information, consultez la note IntSAGE100.doc qui a fait l'objet d'une révision 4 pour cela.
Remarque : Aucune modification n'a été faite pour proposer le format LDCompta V10 en sortie de cette procédure. C'est donc toujours le format LDCompta V9 "texte" qui est fourni en sortie de cette procédure.

Lors de la validation de la fiche client, depuis le correctif niveau 153, le RIB principal du client n'était pas enregistré correctement. Si ce RIB contenait une domiciliation, celle-ci était correctement enregistrée dans le fichier des RIB, mais pas dans la fiche client. A la réouverture de la fiche client, le programme affichait alors 2 RIB, le principal sans domiciliation, et le second avec domiciliation.

Les fiches client sont parcourues à la première ouverture du dossier, avec ce niveau, afin de rétablir les RIB concernés.

Ce correctif fait suite au correctif 97 (NORME SEPA : ENRICHISSEMENT DES VIREMENTS FOURNISSEURS POUR GESTION AVEC TRAX).

Il ajoute au fichier SEPA standard les éléments suivants :
- la balise PmtInfId prend la même valeur que la balise MsgId
- l'adresse de l'émetteur est ajoutée dans la balise PmtInf.Dbtr à l'instar de la balise GrpHdr.initgPty
- La balise CmbndId contenant le pays et le code BIC de la banque est ajoutée aux balise PmtInf.CdtTrfTxInf.CdtrAgt.FinInstnId et PmtInf.DbtrAgt.FinInstnId
- Si des balises vides sont présentes dans le fichier des virements, LDCompta propose de supprimer ces balises avant d'envoyer le fichier.

Le paramètre programme SEPAPLUS permet de mettre en place ces nouveaux points (voir le correctif 97 pour plus de détails)
- 1 à 64 : Personnalisation de la balise MsgId et PmtInfId. On peut utiliser les caractères suivants pour personnaliser la valeur :
     - % : Code société
     - $$ : Code journal
     - £££££ : Code banque
     - JJ, MM, AA, AAAA : Partie de la date du jour
     - ° (1 ou plusieurs) : N° de l'ordre de virement. Le nombre de symboles correspond à la taille du nombre,
          complété si besoin avec des 0 à gauche.
- 65 : Ajout de l'adresse des fournisseurs (O pour activer)
- 66 : Ajout de l'adresse de l'émetteur (O pour activer) dans les balises GrpHdr.initgPty et PmtInf.Dbtr. L'adresse est celle indiquée dans la fiche société.
- 67 : Ajout de la balise CmbnId (O pour activer)
- 68 : Suppression des balises vides avec un message de confirmation (O pour activer) 
- 129 à 192 : Valeur de la balise Bei

Il est désormais possible d'épurer l'historique de modification des écritures depuis le menu Outils / Gestion des fichiers / Epuration des fichiers.
L'épuration est également proposée lors de la clôture annuelle.

Le contrôle entre la date de comptabilisation demandée pour un règlement automatique et la date de dernière clôture mensuelle du journal de banque concerné ne fonctionnait pas toujours correctement (dans le cas où l'on avait des échéances bonnes à payer sur plusieurs journaux de banque, le contrôle ne se faisait que sur le premier journal de banque, qu'il soit sélectionné pour paiement ou pas, et non pas sur l'ensemble des journaux pour lesquels on demandait une comptabilisation.

D'autre part, pour les paiements par virement, si on demande une comptabilisation en date d'échéance, un contrôle supplémentaire a été ajouté pour s'assurer qu'il n'existe aucune échéance à comptabiliser qui serait antérieure à la date de dernière clôture du journal de banque concerné.

L'état présentant les délais de paiement (demandé par la plupart des contrôleurs de gestion) a été amélioré :

• On présente désormais le détail des délais de paiement en distinguant sur 2 lignes distinctes Ecritures échues et Ecritures non échues. Cette distinction se fait sur la date d'échéance des écritures : antérieure ou pas à la date d'arrêtée demandée.
• L'utilisation des 5 colonnes de l'état est un peu différente de ce qui se faisait auparavant. Pour chacune des 3 premières colonnes, on peut choisir le nombre de jours correspondant au délai de paiement maximum des écritures sommées dans la colonne (par exemple, jusqu'à 30 jours en colonne 1, 60 jours en colonne 2, 90 jours en colonne 3). La colonne 4 reçoit toutes les écritures ayant un délai au delà de celui indiqué pour la 3ème colonne. La colonne 5 présente toujours le total des colonnes 1 à 4.
• On a désormais le nombre d'écritures correspondant à chaque montant apparaissant au croisement d'une ligne (Echues ou Non échues) et d'une colonne (Délai de paiement). Par défaut, toutes les écritures sont décomptées. Si on veut ne décompter que les écritures correspondant à des factures ou avoirs, il faut indiquer la liste des journaux d'achat et de vente sur le 2ème onglet de la fenêtre permettant de lancer cet état. 

Il est désormais possible d'utiliser un compte de TVA mensuel dans les écritures périodiques, sur le même principe que ce qui existait déjà en saisie des écritures par pièce.
Pour que cela fonctionne, il faut :

• qu'il existe un code TVA défini avec l'option Un compte par mois
• lors de la création de l'écriture périodique, référencer sur la ligne correspondant à la TVA, le préfixe du compte de TVA à l'identique de celui qui est défini pour le code TVA souhaité.

Avec ceci, lors de la comptabilisation, le compte retenu sera choisi en fonction de la date d'échéance si elle est renseignée, en fonction de la date de comptabilisation sinon.

Lors de l'émission des règlements automatiques fournisseurs, si le total d'un bordereau de paiement est nul (une facture et un avoir de même montant à la même échéance par exemple), il n'y a aucune comptabilisation du bordereau, mais les échéances sont tout de même marquées dans l'échéancier avec un N° de bordereau de façon à les faire disparaitre de l'échéancier.
Du coup, en cas de paiement par effet à payer, on retrouve ce bordereau ayant un montant nul dans la gestion des effets à payer. Et lorsqu'on pointait ce bordereau comme étant "payé", il y avait une écriture de montant nulle passée au débit compte 403, écriture que l'on ne pouvait pas lettrer puisque l'écriture constatant le bordereau au crédit du 403 n'avait pas été passée.
Désormais, dans le cas d'un bordereau de montant nul, il n'y a pas d'écriture passée au débit du compte 403 dans la saisie des effets à payer. Le bordereau est simplement "marqué" de façon à ne plus apparaitre ultérieurement dans cette gestion des effets à payer.

Remarque : sur l'écran permettant de lancer la comptabilisation des règlements automatiques fournisseurs, les bordereaux de paiement ayant un montant nul n'étaient pas décomptés dans la colonne Nombre (et pas affichés si on cliquait sur le bouton Détail des règlements) alors que ces bordereaux sont quand même traités (même s'ils ne donnent lieu à aucune comptabilisation et édition). Désormais, ces bordereaux de montant nul sont décomptés et sont affichés quand on clique sur le bouton Détail des règlements.

Les modifications apportées aux IBAN des tiers sont désormais historisées.
Depuis la fiche d'un tiers (fournisseur, client ou autre auxiliaire), un nouveau bouton Historique se situant au niveau de la saisie des IBAN permet d'accéder à l'historique des modifications. Dans cet historique, on peut afficher les modifications par type et N° de tiers et par date. Cet historique est également consultable depuis la nouvelle option de menu Outils/Historique des modifications d'IBAN.

Les éléments historisés sont les suivants :
- Date de la modification
- Code utilisateur
- Programme utilisé pour effectuer la modification (saisie dans une fiche ou interface standard)
- Création ou suppression d'un IBAN (si un IBAN est modifié, cela correspond à une suppression puis une création)
- Changement de l'IBAN principal

Une nouveauté : depuis la procédure de rapprochement bancaire, il est désormais possible d'appeler la procédure de saisie des écritures par pièce sans sortir du rapprochement en cours. On dispose pour cela d'un bouton Saisie pièce au bas de la fenêtre du rapprochement bancaire. Quand on clique sur ce bouton, on bascule dans la procédure de saisie des écritures par pièce. Sur le premier écran de cette saisie, le code journal est pré renseigné avec le code du journal de la banque en cours de rapprochement, la date d'écriture est pré renseignée par la date de l'écriture sur laquelle on se trouve au moment du clic sur le bouton Saisie pièce. Au retour de la saisie pièce, la ou les écritures ayant été ajoutées par cette saisie pièce (à condition qu'elles soient antérieures à la date d'arrêté du rapprochement bien sûr) sont présentées dans le rapprochement et peuvent donc être pointées. On est d'ailleurs positionné par défaut sur la première écriture ayant été ajoutée.
On peut ainsi plus facilement achever un rapprochement bancaire lorsqu'on s'aperçoit qu'il manque une écriture que la banque a constatée : plus besoin de valider provisoirement le rapprochement en cours pour aller en saisie pièce, puis rappeler le rapprochement pour le terminer. Tout peut se faire "à la volée".

Précisions :

Au retour de la saisie par pièce, le système relit toutes les écritures du compte de banque antérieures à la date du rapprochement en cours. Et il ajoute dans ce rapprochement toute écriture qui n'y était pas déjà antérieurement. Cela signifie que l'on peut légèrement "détourner" ce processus si la pièce manquante doit être saisie non pas en saisie "pièce", mais en saisie "règlement client", "règlement fournisseur" ou encore "écriture périodique". Il suffit, alors qu'on est en cours de rapprochement sur une première session de LDCompta, d'aller réaliser la saisie souhaitée dans une autre session de LDCompta, puis une fois cette saisie réalisée, de revenir à la première session de LDCompta, de cliquer sur le bouton Saisie pièce et de refermer immédiatement la saisie pièce sans rien saisir. Le système va quand même relire toutes les écritures du compte de banque et trouvera donc les nouvelles écritures saisies, même si elles l'ont été dans une autre session LDCompta.
Seule limitation quand même : le système tient compte uniquement des écritures ajoutées, pas des éventuelles modifications ou suppressions de pièces qui auraient pu être faites depuis une autre session LDCompta entre le début du rapprochement et le moment où l'on revient dans ce rapprochement après avoir cliqué sur le bouton Saisie pièce. La seule façon de prendre en compte d'éventuelles modifications ou suppressions de pièces est comme auparavant de valider le rapprochement en provisoire, puis de revenir sur celui-ci.

Au passage, 2 améliorations mineures ont également été apportées dans ce rapprochement bancaire :

• dans le champ de recherche par montant, on dispose désormais du champ de saisie "formule" comme dans la plupart des autres champs de saisie d'un montant de LDCompta, dès qu'on frappe une touche = + - * / ou F4 alors que le focus est dans ce champ.
• dans la fenêtre de saisie des critères de filtrage, on dispose d'un bouton Tout effacer permettant en un seul clic d'effacer tous les critères de recherche présentés dans la fenêtre.

Afin de corriger une erreur aléatoire qui plante la saisie au kilomètre (KM), des modifications ont été apportées au programme.
Information technique : c'est la fonction MémoireVersFichier qui plante. Précédemment, c'était un objet dynamique qui était utilisé. Dorénavant, c'est un objet non dynamique créé par copie de l'objet dynamique.

Lors de la suppression d'un compte de type Autre auxiliaires, et dans le cas où l'on a plusieurs collectifs de même sous-type, on pouvait avoir un message indiquant que la suppression du compte demandée pour un collectif X ne pouvait être répercutée dans le collectif Y car il existait des écritures pour ce compte autre auxiliaire dans le collectif Y.
Or, dans les deux derniers paragraphes de ce message, il y avait une inversion des comptes collectifs X et Y et des codes racines associés, rendant difficile la compréhension du message. 

Message erroné :
ATTENTION : il existe des écritures dans ce compte XXXXXXXX pour le
pour le collectif COL222 (code racine C2), qui est de même sous-type que le
collectif  COL111 (code racine C1).
La suppression du compte XXXXXXXX, si vous la confirmez, ne sera donc
pas répercutée dans le collectif COL111 (code racine C1)."
Etes-vous sûr(e) de vouloir quand même supprimer le compte XXXXXXXX
pour le collectif COL222 (code racine C2) ?"

Message corrigé :
ATTENTION : il existe des écritures dans ce compte XXXXXXXX pour le
pour le collectif COL222 (code racine C2), qui est de même sous-type que le
collectif  COL111 (code racine C1).
La suppression du compte XXXXXXXX, si vous la confirmez, ne sera donc
pas répercutée dans le collectif COL222 (code racine C2)."
Etes-vous sûr(e) de vouloir quand même supprimer le compte XXXXXXXX
pour le collectif COL111 (code racine C1) ?"

Mise à disposition de la fenêtre iFactoNATIXIS permettant d'envoyer le détail des écritures au format NATIXIS Factor.
Fichier OCA : Ouverture des comptes clients automatique conforme au cahier des charge V6.2 (voir U:\Documentations\LDCompta\NATIXIS Factor fichier OCA_v6 2.pdf)
Fichier GRL  : Grand Livre Client conforme au cahier des charge V7 (voir U:\Documentations\LDCompta\NATIXIS Factor fichier GRL_v7.pdf)

Le mode d'emploi (U:\Documentations\LDCompta\Documentation Export Natixis Factor.doc) va se copier automatiquement dans le répertoire doc de la compta.

Les virements non lettrés était envoyés comme OD au crédit, ils sont maintenant en RNI  (règlement non échu).

Dans le cas d'une demande de mailing des lettres de relance, si cette demande concerne un seul client (un même numéro de client en début et fin de la sélection des clients à relancer), le programme intercale désormais une fenêtre permettant la modification du mail à envoyer, en lieu et place de la confirmation de l'envoi des mails. Cette fenêtre permet entre autres d'ajouter des pièces jointes au mail.
Remarque : à ce stade, la lettre de relance elle-même est déjà attachée en tant que fichier PDF joint au mail.

Il est désormais possible, directement depuis la fenêtre de modification des relances client par client, de modifier le libellé d'une écriture, de saisir des commentaires ou d'ouvrir la fenêtre de modification d'une pièce.

Une nouvelle option dans les paramètres de comptabilisation d'un relevé client permet de demander la génération d'une traite à l'acceptation sans qu'il y ait pour autant de lettrage partiel des écritures reprises sur la traite émise.

Deux petites améliorations et une correction ont été apportées dans la procédure d'émission des relevés clients :

1. Un contrôle a été ajouté lorsque de l'émission d'un relevé client en mode manuel : le client sélectionné doit avoir un RIB s'il on demande l'émission d'une traite en portefeuille dans les paramètres de lancement.
2. Un mode de règlement doit désormais être indiqué lorsqu'on demande l'émission d'une traite (à l'acceptation ou en portefeuille). Ce mode de paiement est utilisé en lieu et place du mode de paiement client pour la comptabilisation de la traite.
3. La génération d'un relevé client sans aucune édition (ni relevé ni traite) ne pouvait aboutir car le programme demandait à l'utilisateur de valider la fenêtre de lancement de l'édition alors que celle-ci ne pouvait se valider de par le fait qu'on avait justement demandé de ne faire "aucune édition".

Dans la saisie au km, si un compte nécessite une ventilation analytique mais qu'on ne saisit pas celle-ci avant de valider la ligne, une fenêtre demandant de saisir l'analytique s'ouvre. Si on saisissait une ventilation analytique, l'écriture était marquée avec une section "VENTILÉ". Lorsqu'on revenait sur la ligne en modification, la validation de cette ligne affichait le message "Le code section VENTILÉ n'existe pas".  Par contre, à l'utilisation avec le bouton F7, tout fonctionnait correctement. Désormais, ce message ne s'affiche plus.

Une seconde anomalie, similaire à la première, se produisait si le compte général contenait une destination (axe 3) par défaut. Si une ventilation analytique était saisie, le simple fait de naviguer d'un champ à l'autre ré-initialisait le code destination avec le code destination par défaut. De ce fait, l'écriture n'était plus considérée comme "ventilée" et cela provoquait le message d'erreur. Désormais, le code destination n'est plus réinitialisé en naviguant de champ en champ.

Une troisième anomalie beaucoup plus subtile a aussi été corrigée. Le fait d'utiliser le bouton F7 faisait penser au programme que la ligne était ventilée dans tous les cas. Dans ce cas, un message indiquant qu'on allait perdre la ventilation s'affichait dès lors qu'on essayait de modifier l'un des axes. Ce message n'avait aucune incidence mais n'avait pas de raison d'être. Désormais, il s'affiche seulement si la ligne est réellement ventilée (elle doit afficher VENTILÉ).

Lorsqu'on demandait l'édition d'un compte de résultat en forme "12 mois", il y avait une erreur systématique (erreur de doublon dans le fichier CPTBIS12) si on avait des comptes auxiliarisés en classe 6 ou 7.

La saisie des bordereaux de banques accessible depuis le menu SAISIE ne fonctionnait plus. L'appel du menu provoquait un plantage de l'application.

Des optimisations ont été apportées sur différents traitements lorsqu'une base de données est en HyperFile Client/Serveur.

- A l'ouverture de l'application, après le contrôle de licence, il y avait un temps d'attente proportionnel au nombre de sociétés sur le serveur HyperFile avant l'affichage de la fenêtre de choix des sociétés.

- Ce temps d'attente était aussi présent au niveau de la création ou de la suppression d'une société;

Dans les différentes procédures de consultation (compte, pièce...), on peut accéder à la GED pour chacune des pièces affichées. Le lien entre une écriture comptable et les documents enregistrés dans la GED se fait toujours sur le triplet (Code journal, Date, N° de pièce).
Problème : quand une pièce est reprise en à nouveau lors d'une clôture d'exercice, ce lien est rompu car la pièce reprise en à nouveau l'est sur un journal d'à nouveau et au 1er jour de l'exercice. On n'a donc plus accès, depuis toutes ces procédures de consultation, aux documents GED liés aux pièces reprises en à nouveau.
Désormais, ce lien est conservé. Pour cela, on exploite les 2 nouveaux champs présents sur les écritures comptables (JNAC et DTAC), champs qui mémorisent le code journal d'origine et la date comptable d'origine de toute pièce reprise en à nouveau.

Le principe désormais mis en oeuvre dans toutes ces procédures de consultation est le suivant : pour les pièces d'à nouveau, le lien ne se fait pas sur le triplet (Journal d'à nouveau, date de l'à nouveau, N° de pièce) mais sur le triplet (Journal d'origine, Date d'origine, N° de pièce). Et on retrouve ainsi les documents GED qui avaient été reliés avant la clôture d'exercice.

Remarques

• le seul cas où le lien se fait encore, pour des pièces d'à nouveaux, sur le triplet (Journal d'à nouveau, date de l'à nouveau, N° de pièce) est celui où des documents GED ont été associés à la pièce alors que celle-ci était déjà en à nouveau, et que cette association a été faite antérieurement à la mise en place de cette correction.
• cette amélioration concerne toutes les procédures de consultation donnant accès à la GED (consultation d'un compte, d'une pièce, d'une référence, d'un journal, recherche par montant), mais aussi la procédure de modification des relances, la GED ayant été ajoutée dans cette procédure par la correction N° 186.

Il est désormais possible d'intégrer des images dans le corps du mail adressé pour les relances clients, pour un logo ou une signature par exemple. Il faut pour cela saisir, dans le corps du mail, une chaine de caractères ayant la syntaxe suivante :
   #IMG=Chemin\De\L'image#
où Chemin\De\L'image permet de récupérer l'image :
 - soit sur un disque local ou réseau accessible au moment où l'on envoie les mails de relance
   Exemple : S:\Ldsystem\Fichiers\Compta\SignatureRelance.jpg
 - soit sur un chemin UNC
   Exemple : \\Serveur-LD\E\Ldsystem\Fichiers\Compta\SignatureRelance.jpg
 - soit sur un site WEB
   Exemple : http://www.ldsysteme.fr/fileadmin/SignatureRelance.jpg.

Information technique :
Il était déjà possible d'ajouter une image dans le corps du mail par Copier-Coller directement dans le texte du message qui est saisi en format RTF. Cependant, cela n'était pas possible en environnement client/serveur AS400 car la limite de taille du corps de l'email est de 4096 caractères au maximum (soit 5ko environ). Une image faisant facilement plus de 5ko, elle n'était pas enregistrée correctement et tout le texte après cette image était lui aussi perdu.

Un nouvel outil permettant de renuméroter un ou plusieurs comptes de tiers est désormais disponible dans LDCompta, via le menu Outils/Autres outils/Lancer un autre outil.

Informations techniques :

La totalité des enregistrements des fichiers sont balayés pour renuméroter les tiers, à l'exception de certains fichiers pour lesquels on doit indiquer à partir de quelle date on traite les enregistrements à modifier. Ces fichiers sont les suivants :
- CPTBIS - Bilan et CR-Soldes des comptes
- CPTBUD - Budget - Montants budgétés
- CPTHIM - Trace des modifications de pièces

Les fichiers suivants sont tout simplement ignorés du processus de renumérotation :
- CPTFOD - Détail folio
- CPTPCA - Canevas de saisie
- CPTHCA - Historique C.A. clients/fournisseurs
- CPTFAC - Factures clients - Suivi TVA sur encaissements
- CPTFAF - Factures fournisseurs - Suivi TVA sur décaissement
Les deux premiers fichiers listés ci-dessus doivent être révisés manuellement. Les trois derniers peuvent être régénérés par les traitements appropriés.

Le traitement des factures de l'exercice comptable précédent n'était pas possible dans l'interface DAS2 (Honoraires) si le dossier courant ne comptait qu'une et une seule archive.

Lorsque la fenêtre principale reprend le focus, elle rafraichit la liste des relances clients et des écritures périodiques si elles sont affichées sur le bureau de LDCompta. Ce rafraichissement provoquait la perte du contexte HyperFile SQL.
De ce fait, par exemple, en consultation d'un compte client, le clic sur le bouton Fiche du compte pouvait afficher la fiche d'un autre compte que celui affiché dans cette fenêtre de consultation si on avait, au cours de la consultation de ce compte, basculé dans la fenêtre principale (simplement en cliquant dans celle-ci ou en appelant une autre option de menu depuis cette fenêtre principale).

Dans les deux fenêtres de gestion des clients (la liste pour gestion et la fenêtre de mise à jour proprement dite), on dispose d'un bouton Actions pour accéder aux actions de relance du client courant.
Désormais, le libellé de ce bouton apparait en rouge et en gras s'il existe, parmi toutes les actions de relance concernant le client courant, au moins une action ayant une date de rappel et n'étant pas marquée comme Terminée (et ce quel que soit le compte collectif auquel l'action est attachée, si vous gérez plusieurs collectifs clients).

Complément technique : au passage, un problème de contexte HyperFile a été réglé, problème qui se manifestait si l'on appelait la fenêtre de gestion des actions de relance depuis l'une des fenêtres de gestion des clients et qu'on demandait à afficher les actions de relance d'un autre client en modifiant le critère de sélection en partie haute de l'écran. Au retour dans la fenêtre de gestion des clients, on n'était plus positionné sur le bon client, avec donc des résultats curieux.

Un bouton Vers GED a été ajouté dans la fenêtre d'édition (ou réédition) des relevés clients afin de les envoyer dans le module GED.
Par défaut, le relevé est enregistré dans la GED du client, sous le nom Relevé AAAAMMJJ.pdf, AAAAMMJJ étant la date du relevé.
En créant un paramètre programme nommé RLCETAGED, on peut choisir d'enregistrer le fichier PDF dans un autre répertoire et éventuellement sous un autre nom de fichier. La valeur alphanumérique de ce paramètre RLCETAGED peut contenir des variables de remplacement qui sont remplacées lors de la génération. Chaque variable de remplacement est définie avec la syntaxe <XXXX> où XXXX est le code d'une des rubriques du fichier client, ou égale à DATR pour récupérer la date du relevé.
Exemple : S:\Fichiers\Compta\Relevés\Relevé_<NOCL>_<DATR>.pdf  
Si ce chemin est défini en commençant par "<GED>", le relevé est inclus dans la GED (seul le nom du fichier est donc pris en compte). Sinon, s'il s'agit d'un chemin différent, le relevé est enregistré en pdf dans le répertoire et sous le nom défini mais ne sera pas enregistré dans la GED.

Au passage, une petite modification a été faite : lorsque cette fenêtre est appelée depuis la gestion des traites à l'acceptation pour imprimer une traite seulement, les boutons Vers GED, E-Mailing et Fax-Mailing sont désormais masqués.

Une amélioration a été apportée sur la liste des sorties d'immobilisations. Cela concerne le cas des sorties partielles. On a désormais 4 quantités affichées en regard de chaque sortie, pour être plus clair dans le cas de ces sorties partielles :
 - la quantité initiale (celle du moment de l'acquisition)
 - la quantité restant avant la sortie "courante"
 - la quantité sortie
 - la quantité restante après la sortie "courante"
De plus, la valeur "origine" est désormais celle correspondant à la quantité restant avant la sortie courante, et non celle correspondant à la quantité initiale. Ainsi, cette quantité origine est la même que celle que l'on retrouve sur l'état de situation dans la colonne Base amortissement.

Par ailleurs, cette liste des sorties est désormais accessible par le bouton Imprimer depuis la fenêtre de consultation des sorties.

L'impression des bordereaux de remise en banque a subi quelques modifications de mise en forme :

• le tri des règlements est désormais opéré par Type de remise (escompte ou encaissement), mode de paiement, type place (pour les chèques uniquement) ou date échéance (pour les règlements autre que les chèques), avec saut de page en rupture sur l'un ou l'autre des 2 premiers critères. Auparavant, le bordereau était trié par mode de paiement (avec saut de page), puis par type de remise, type place ou échéance. Le critère Type de remise (escompte ou encaissement) a donc été remonté en critère de tri majeur et provoque un saut de page, comme le mode de paiement. Ainsi, on a des pages différentes si on a sur un même bordereau des effets remis à l'escompte et d'autres à l'encaissement (même si ce cas de figure est rarissime).
• le titre de l'état figurant en haut de page est différent dans le cas d'une remise à l'escompte. Au lieu d'avoir BORDEREAU DE REMISE EN BANQUE, on a ACTE DE CESSION DE CREANCES PROFESSIONNELLES avec la mention en dessous soumis aux dispositions des articles L. 313-23 à L. 313-34 du code monétaire et financier.
• d'autres modifications mineures ont été apportées, sur les libellés figurant en regard des totaux et sur la gestion des sauts de page notamment.

Plusieurs traitements concernant les tiers ne fonctionnaient pas si le code du tiers en question contenait une apostrophe. Ces traitements ont été revus et corrigés :
- Recherche par code client dans la liste des clients
- Sauvegarde d'un IBAN dans les fiches client et fournisseur
- Modification de l'IBAN principal dans la fiche d'un fournisseur
- Renumérotation des n° de tiers clients et fournisseurs (outil : OutiChgAux)

Les aperçus avant impression affichaient un avertissement toutes les 1000 pages, en proposant de mettre fin à l'aperçu afin de prévenir la saturation de la mémoire. Cette limite à 1000 pages est souvent atteinte lors de l'édition des grands-livres par exemple. Or, la quantité de mémoire nécessaire pour un aperçu de 1000 pages (plus de 1,5 Go) était trop grande sur les postes de travail les plus modestes, ce qui pouvait provoquer un plantage avant même que cet avertissement ne soit proposé.
Cette limite a donc été descendue par défaut à 500 pages. Il est cependant possible de fixer une autre valeur pour cette limite en nombre de pages via le paramètre programme ETANBP. Il suffit de créer ce paramètre et d'indiquer dans la valeur numérique le nombre de pages que l'on souhaite avoir dans l'aperçu avant affichage du message d'avertissement.
Remarque : lorsqu'on répond Non au message d'avertissement pour limiter le nombre de pages de l'aperçu avant impression et éviter ainsi un "débordement" mémoire, on peut tout à fait, depuis cette fenêtre d'aperçu avant impression, demander l'impression "physique" ou l'export au format PDF. Et dans ce cas, c'est l'état entier qui sera imprimé ou exporté en PDF, et non pas seulement la partie affichée dans l'aperçu.
Autre remarque : une autre façon de réduire la quantité de mémoire nécessaire à l'impression, pour les grands-livres, est de demander l'impression sans les cadres. Cela réduit la consommation mémoire de 30% environ (alors que le fait d'imprimer sans les trames grisées n'a pas d'effet significatif).

Lorsqu'on sauvegarde un dossier comptable géré en base HyperFile Client/Serveur (HFCS), les éventuels sous-dossiers contenus dans le dossier sauvegardé et contenant des fichiers HyperFile sont désormais ignorés (ce qui était déjà le cas en cas de sauvegarde d'un dossier en base HF Classic).
Rappelons que normalement, il ne devrait pas y avoir de sous-dossiers au sein d'un dossier comptable. Mais dans certains, en base HFCS, on peut trouver des sous-dossiers tels que _Backup, avec des fichiers .FIC à l'intérieur. Et cela pouvait aboutir à une erreur de sauvegarde en raison de noms de fichier en double dans la sauvegarde, compte-tenu que la sauvegarde dans le fichier ZIP se fait sans tenir compte du nom du répertoire d'origine.

Plusieurs améliorations ont été apportées pour faciliter l'accès aux actions de relance clients :

1. dans la fenêtre de gestion des actions de relance, on peut désormais en partie haute faire une sélection d'un compte client tous collectifs confondus, en utilisant la racine multi-collectifs clients définie dans la Fiche Société.
   Au passage, un contrôle a été ajouté dans cette fenêtre pour n'autoriser que des comptes de nature "clients", et autoriser aussi la sélection directe d'un groupe ou d'une famille de clients (sans passer par la fenêtre de filtre des groupes et familles). Et de plus, la sélection par groupe et famille "standard" (par le bouton Sélection par groupe et familles de tiers) ne fonctionnait pas antérieurement ; cela a été corrigé.
2. quand cette fenêtre de gestion des actions de relance clients est appelée pour un client, depuis la fenêtre de liste des clients ou de mise à jour d'un client en particulier, la fenêtre est désormais ouverte en priorité en mode multi-collectifs clients, dès lors que le code racine multi-collectifs clients a été défini dans la Fiche Société. A défaut, comme auparavant, c'est le code racine pour lequel il existe le plus d'actions de relance pour ce client qui est sélectionné, ou à défaut celui défini dans la fiche du client, ou à défaut le premier collectif client.
3. enfin, dans la fenêtre de consultation d'un compte, un bouton Actions de relance est présenté en lieu de place du bouton Echéancier fournisseur, dès qu'on affiche un compte client. Comme dans la fenêtre de gestion d'un client, le libellé de ce bouton figure en rouge s'il existe au moins une action de relance pour le client en question.
   Remarque : en tenant la touche Majuscule enfoncée lors du clic sur ce bouton Actions de relance, on peut quand même accéder à l'échéancier fournisseur depuis un compte client.

Un paramètre supplémentaire, à renseigner en position 385 du paramètre programme IPNMFAC, permet de choisir le format des dates inscrites dans le fichier d'interface : JJMMAA ou AAMMJJ. En l'absence de ce paramètre, c'est le format JJMMAA qui est utilisé, comme c'était le cas antérieurement à cette correction.
La documentation de l'interface au format PNM a fait l'objet d'une révision 2.2 pour décrire cette nouveauté.

2 procédures spécifiques de prétraitement d'un fichier d'interface ont été réalisées à la demande d'un client. Elles permettent d'intégrer chaque mois des écritures comptables au format LDCompta V10 "texte" à partir de feuilles Excel :
 - la première exploite un fichier de provisions CP et charges sur CP issu d'un logiciel de paye
 - la seconde exploite un fichier contenant la sommes de mouvements comptables intra-groupe,
   à extourner dans un dossier de consolidation.
Dans les 2 cas, le volume d'écritures à comptabiliser est assez important du fait de l'utilisation d'une ventilation analytique sur 3 axes.

Une correction a été apportée dans le programme de comptabilisation automatique des règlements fournisseurs. Cela concerne les paiements par BO (effet à payer). Désormais, lorsque la date de règlement demandée est postérieure à l'échéance des factures réglées, le BO correspondant est émis avec une date d'échéance égale à la date de règlement, en lieu et place de l'échéance des factures réglées. De plus, si le compte Effets à payer (403000) est géré par mois d'échéance, c'est bien le compte du mois correspondant à cette date de règlement qui est mouvementé, et non celui correspondant à l'échéance d'origine.
Enfin, lors de l'édition du BO, dans le cadre Echéance du titre de paiement lui-même, on fait apparaître la mention A VUE en lieu et place de la date d'échéance.
Complément technique
Si vous utilisez un formulaire "spécifique" pour l'édition des lettres-BO (c'est à dire un formulaire autre que celui nommé RfaBO.txt livré dans le répertoire des programmes de LDCompta), ce formulaire devra être adapté. La modification a consisté à remplacer, ligne 246,
iImprime(iPosY(PosY+30)+iPosX(PosX+65)+DateVersChaine(EchéanceRGF,"JJ/MM/AA"))
par
iImprime(iPosY(PosY+30)+iPosX(PosX+65)+(EcheanceRGF > DateRGF ? DateVersChaine(EchéanceRGF,"JJ/MM/AA") sinon " A VUE"))

Dans la saisie de l'échéancier fournisseur, la colonne permettant de saisir le code devise n'est censée être affichée que si l'on est dans un dossier sur lequel le module Devises a été activé.
Il y avait un problème lorsqu'on passait d'un dossier où ce module n'était pas activé (donc colonne devise masquée) à un dossier où ce module était activé : la colonne Code devise restait masquée. Pour la voir réapparaitre, il fallait aller la sélectionner explicitement en cliquant dans le coin haut supérieur droit de la table, par l'option Sélectionner les colonnes du menu contextuel.
Mais dès qu'on revenait sur un dossier où le module Devises n'était pas activé, cette colonne était à nouveau masquée.

Dans la fenêtre d'interrogation analytique, quel que soit l'axe utilisé (section, affaire, destination), il est désormais possible d'interroger sur un niveau de regroupement et non plus seulement sur un code « final ».
Par exemple, si on a 3 codes section 0101, 0102 et 0103 et un niveau de regroupement 01, si on interroge sur le niveau de regroupement 01, on verra toutes les écritures de ces 3 sections 0101, 0102 et 0103.
Lorsqu'on interroge de la sorte sur un niveau de regroupement (niveau qui doit bien entendu être défini dans la table analytique correspondante), une colonne supplémentaire apparait dans la table pour y faire figurer les valeurs de cet axe écriture par écriture, du fait que ces valeurs peuvent différer ligne par ligne, alors que cette colonne est masquée si on interroge sur un code « final ».
On peut aussi opérer par niveau de regroupement sur les axes de sélection complémentaire : par exemple, si on interroge par section, on pouvait ajouter une sélection sur une affaire donnée. On peut désormais ajouter une sélection sur un niveau de regroupement d'affaires.
Et de la même façon, là où l'on pouvait ajouter une sélection sur un compte général, on peut ajouter une sélection sur n'importe quelle classe de compte (par exemple, les comptes commençant par 607).

Le contrôle de longueur des comptes clients et fournisseurs était trop court par rapport à ce qui peut être exporté (7 au lieu de 8).

La procédure de conversion d'un fichier au format SAGE au format LDCompta inscrivait le code section dans toutes les écritures générées, avec la valeur inscrite dans la zone "Section" de l'onglet Analytique, au lieu de ne l'alimenter qu'à bon escient.

Lors de la suppression d'un effet dans l'onglet En-cours d'escompte du portefeuille de règlement, une erreur survenait lorsqu'on essayait de masquer le bouton Retrait effet. Pour éviter cela, ce bouton n'est plus masqué mais grisé.

Dans la fenêtre de modification des relances clients, de nouvelles options permettent de protéger l'utilisateur d'un pointage ou d'un dépointage accidentel. Ces options sont accessibles dans la fenêtre de paramétrage de la fenêtre (Alt F1 ou bouton Paramètres programmes dans l'angle haut gauche).
La première option permet de choisir les colonnes pointables via la souris : soit la colonne Coche uniquement, soit les colonnes Coche, Débit, Crédit et Niveau de relance. La seconde option permet d'empêcher le pointage / dépointage si la touche Control n'est pas enfoncée, que l'on utilise la souris ou le clavier (barre espacement et chiffres).

Une nouvelle édition est désormais possible dans le module Immobilisations.
Cette édition permet d'imprimer une fiche immobilisation avec les informations suivantes :
- Information d'acquisition (facture, montant, date d'acquisition, etc...)
- Comptes associés
- Ventilation comptable
- Cessions
- Plan d'amortissement
- Observation
Cette nouvelle édition est accessible depuis le menu Traitements/Immobilisations/Edition/Fiches immobilisations ainsi que dans la fenêtre de gestion des immobilisations via le bouton Imprimer et ses dérivés.

Dans les différentes procédures de consultation où l'on peut voir les quantités saisies en analytique, ainsi que sur le grand-livre analytique, le signe de cette quantité était inversé dès lors que l'écriture analytique associée était au crédit.
Or, ce n'est pas la logique avec laquelle on saisit ces quantités. En effet, en saisie d'une ventilation analytique, la quantité est enregistrée telle qu'elle est saisie, avec le signe qui lui a été affecté en saisie donc, sans aucune interaction avec le sens de l'écriture Débit ou Crédit.
1er exemple : on ventile une écriture de comptabilité générale saisie pour un montant de 100 au débit. La ventilation comporte 2 lignes : une 1ère ligne avec un montant de 120 et une quantité de 12, la 2ème avec un montant de -20 et une quantité de -2.
Dans le fichier CPAHIS, on obtient 2 écritures, la 1ère avec un montant de 120, quantité 12, sens D, la 2ème avec un montant 20, quantité -2, sens C.
On voit que le montant de l'écriture analytique est toujours positif, le signe étant géré au travers du code Débit-Crédit. En revanche, la quantité est enregistrée avec le signe qui a été saisi.
2ème exemple : on ventile une écriture de comptabilité générale d'un montant de 100 au crédit. Même ventilation que dans l'exemple ci-dessus.
Dans le fichier, on obtient 2 écritures, la 1ère avec un montant de 120, quantité 12, sens C, la 2ème avec un montant 20, quantité -2, sens D.

La quantité est donc toujours enregistrée telle que saisie. Il ne faut donc pas inverser le sens de celle-ci sur les écritures passées au crédit lors des restitutions (consultations et éditions), ce qu'on faisait jusque-là à tort.

Remarques complémentaires
A chacun de savoir comment il veut gérer les sens dans les comptes de classe 6 et 7. Par exemple, dans un compte Achat Carburant (de classe 6), une facture devra normalement être saisie avec une quantité positive, un avoir devra lui être saisi avec une quantité négative.
Dans un compte de vente où l'on gérerait la quantité, on préconise d'adopter la même règle : les factures sont saisies avec des quantités positives, les avoirs avec des quantités négatives.
Inconvénient : on ne peut pas sommer "directement" les quantités entre différents comptes, ou à tout le moins entre comptes de classe 6 et 7. Mais comme bien souvent, les unités ne sont pas les mêmes entre ces différents comptes, la somme des quantités n'a de toute façon pas de signification en dehors d'un même compte ou d'une même classe de comptes.

La procédure permettant de reprendre des immobilisations depuis une feuille Excel a été améliorée. On peut désormais (un peu comme cela est fait dans la reprise des salariés de LDPaye) utilisé un fichier à colonage « libre », le colonage étant décrit en ligne 2 de la feuille Excel. Ainsi, plus besoin de respecter absolument le colonage standard proposé auparavant.
Ces améliorations sont décrites dans la documentation intitulée Reprise Immos depuis un fichier Excel qui a fait l'objet d'une révision 2 pour cela. 

De plus, pour le code fournisseur, si le code repris n'existe pas en tant que N° fournisseur dans LDCompta, on fait une recherche successivement sur le nom condensé et le libellé interne. Si on trouve un et un seul fournisseur dont le nom ou le libellé correspondent exactement au code repris, on récupère le code de ce fournisseur (même principe que la complétion automatique d'un N° de compte en saisie).

Dans la saisie des virements reçus, si on avait fait le choix, dans la procédure d'affichage des relevés bancaires, d'utiliser une présentation des montants dans le sens Compte comptable plutôt que Banque, l'écriture était passée en sens inverse de celui souhaité.
Note :
 - dans le fichier des relevés bancaires, le sens Débit-Crédit qui est enregistré est celui qui correspond dans LDCompta
   à l'écriture équivalente dans le compte de banque (Débit pour un virement reçu, Crédit pour un virement émis).
   Cela correspond au sens d'affichage Compte comptable.
 - dans la fenêtre principale de saisie des virements reçus, on affiche les écritures dans le même sens que celui choisi
   pour l'affichage des relevés. On inverse donc le sens lu dans le fichier CPTRLM si le sens d'affichage souhaité est Compte comptable. 
 - dans la fenêtre de comptabilisation d'un virement reçu, on affiche le sens de l'écriture qui sera passé au compte de contrepartie (le client),
   donc C=Crédit pour un virement reçu d'un client.
L'erreur venait du fait que le sens affiché dans cette fenêtre de comptabilisation ne tient pas compte du sens d'affichage de la fenêtre principale, mais que lors de la comptabilisation, on inversait le sens affiché à l'écran si le sens d'affichage de la fenêtre principale était C=Compte.

1) Suite à la correction N° 254, les N° de comptes portés sur chaque immobilisation, lorsqu'ils ne sont pas renseignés au niveau de la fiche reprise, étaient mal repris depuis la famille d'immobilisations. On prenait toujours le compte d'immobilisation de la famille, au lieu de prendre, selon le cas, le compte d'immobilisation, d'amortissement, de dotation...

2) 2 options ont été ajoutées pour créer les lieux et les groupes à la volée

3) On gère la ventilation analytique sur les 3 axes. Dans la description du fichier Excel repris, la colonne SECT a été remplacée par CSEC et on a inséré juste après les colonnes CAFF et CDES. L'utilisation de ces 3 axes dépend bien sûr du nombre d'axes analytiques actifs dans le dossier où l'on effectue la reprise.

Dans la procédure de calcul du plan d'amortissement d'une immobilisation, en cas de reprise de donnée, la durée initiale enregistrée sur la première ligne du plan d'amortissement peut, moyennant un nouveau paramètre, être à zéro et non pas égale à la durée initiale connue dans la fiche Immobilisation. Ainsi, sur la première ligne calculée qui suit dans le plan d'amortissement, le système recalcule le taux d'amortissement compte tenu de la base restant à amortir et de la durée restante.
Avec ce nouveau principe, on est plus juste s'il y a eu prorogation de la durée d'amortissement au cours de la période reprise.
Attention : on ne fait cela qu'en cas d'amortissement linéaire. Dans le cas d'un amortissement dégressif, le taux utilisé pour la période restant à amortir est toujours le taux correspondant à la durée initiale (celle qu'on a dans la fiche au moment de la reprise). 
Pour mettre en place cette méthode quelque peu spécifique lors d'une reprise, il faut indiquer la valeur O (Oui) en position 193 du paramètre programme IMOPAR.

En création de société, il est désormais possible de copier le paramétrage du module Immobilisations lorsqu'on initialise la société depuis les données d'une autre société. Les données copiées sont :
 - coefficients des amortissements dégressifs et paramètres des amortissements exceptionnels
 - paramètres des zones supplémentaires
 - groupes et lieux
 - famille d'immobilisations, y compris ventilation analytique de ces familles si on copie aussi le plan analytique.

Un nouveau paramètre dans la fenêtre d'interface iApiFac8 permet de définir si l'on tronque ou complète les numéros de compte.
Un message d'erreur apparaissait lorsqu'on essayait d'utiliser ce convertisseur indiquant que le fichier INTCPT_XML.fdf n'existe pas. Le convertisseur utilise désormais le fichier INTCPTV10_XML.fdf qui est le fichier fournit par défaut avec LDCompta.

Une nouvelle fenêtre spécifique (prcreta01) permet d'effectuer un suivi du risque client.

Pour en savoir plus, merci de vous rapprocher de votre prestataire. 

4 améliorations ont été faites dans le module Immobilisations :

• Dans la fenêtre principale de gestion des immobilisations, une colonne a été ajoutée dans la table présentant la liste des immobilisations pour afficher la ventilation analytique de chaque immobilisation (sauf dans le cas où cette ventilation comporte plusieurs lignes, auquel cas il figurera des +++).
• Toujours dans cette fenêtre, on présente désormais les libellés associés aux codes lieu et groupe de chaque fiche, ainsi que le libellé du fournisseur en regard de son code. Pour ces 3 colonnes Lieu, Groupe et Fournisseur, un filtre de type Contient est proposé en standard via le petit icone figurant à droite de l'en-tête de chacune de ces colonnes, permettant ainsi une recherche rapide par libellé.
• Il est désormais possible de saisir des comptes incomplets dans une famille d'immobilisation. Rappelons que ces comptes indiqués au niveau d'une famille sont ceux qui sont proposés lors de la création d'une fiche immobilisation dès lors que l'immobilisation est assignée dans une famille. On peut ainsi utiliser une même famille pour plusieurs comptes. Lors de la saisie de la fiche, le ou les comptes en question devront bien sûr être complétés.
• En saisie guidée, s'il y a des commentaires sur l'une des écritures de la pièce à partir de laquelle on crée une fiche immobilisation, ceux-ci sont automatiquement repris dans la zone Observations de la fiche immobilisation.

Extrait du site de PC SOFT :
Le 11 avril 2017 Microsoft a débuté le déploiement d'une nouvelle version majeure de Windows 10. Il s'agit de la version "Creators Update" (redstone 2), dont le numéro de version initiale est le 1703 (build 15063.138). Un changement apporté dans cette version de Windows peut provoquer une interaction avec le mécanisme d'aperçu avant impression des applications WINDEV. Dans certains cas l'application peut ne pas répondre aux actions de l'utilisateur après l'aperçu d'un état.
Afin de restaurer le fonctionnement normal de l'aperçu, il a été nécessaire d'adapter le framework de WINDEV à cette particularité de Windows 10 Creators Update.

L'option de menu Outils/Autres outils/Lancer l'interpréteur SQL lance désormais LDSQL si cet outil a pu être localisé, WDSQL (comme auparavant) sinon.
Pour qu'il soit localisé, il faut que LDSQL soit installé sur le poste de travail dans la même arborescence de répertoire que LDCompta. Ainsi, si LDCompta est installé sur C:\Ldsystem\Program\Compta, LDSQL doit être installé sur C:\Ldsystem\Program\LDSQL.
Si c'est LDSQL qui est lancé, on arrive directement sur le dossier courant de LDCompta, avec impossibilité de changer de dossier, sauf si l'on dispose d'une « clé » permanente pour LDSQL (les clés qui permettent de faire des mises à jour de données, voir Aide en ligne de LDSQL au chapitre Sécurités).

De plus, pour lancer l'interpréteur SQL depuis LDCompta, que ce soit LDSQL ou WDSQL, il faut désormais que l'utilisateur courant soit Administrateur de sécurité ou dispose d'un niveau d'accès Administrateur sur le domaine de sécurité SQL pour la société courante.

Il est désormais possible de préparer un fichier de virements internationaux au format SEPA (XML ISO 20022).
Le choix du format se fait au moment de la création du fichier de virements. On a le choix entre le format CFONB utilisé jusqu'à présent (Virement international 320 caractères) et le format SEPA (Virement international ou non SEPA en XML ISO 20022). Un onglet Paramètres permet de gérer certaines options du format SEPA.

La saisie guidée des immobilisations a fait l'objet de 2 améliorations pour mieux gérer le cas où une facture est découpée en plusieurs lignes en classe 2 dans le but de saisir plusieurs fiches immobilisations :
 1) lorsqu'on crée une fiche immobilisation en saisie guidée en pointant une ligne, seul le commentaire présent sur cette ligne est désormais repris
     dans la zone Observation de la fiche Immobilisation. Auparavant, on reprenait les commentaires saisis sur toutes les lignes de la pièce.
     Toutefois, s'il n'existe aucun commentaire sur la ligne pointée, mais qu'il en existe sur d'autres lignes de la même pièce, on reprend comme
     auparavant l'ensemble des commentaires de la facture.
 2) pour faire l'association entre les lignes (les écritures) affichées en saisie guidée et les fiches immobilisations déjà saisies, on tient compte
    désormais du montant HT ou TTC de l'immobilisation. Chaque fiche Immobilisation est placée en regard de l'écriture ayant même N° de facture,
    même mois  (Mois d'acquisition de l'immo par rapport au mois comptable de l'écriture ou mois de la pièce) et même montant
    (montant HT si on est sur un compte de classe 2, montant TTC si on est sur un compte de tiers).
    Ainsi, si une facture a été partagée en 2 lignes en classe 2 et qu'on saisit deux fiches Immobilisation distinctes dont le montant correspond à
    chacune de ces 2 lignes, les associations sont faites intelligemment et les 2 lignes apparaissent ensuite en bleu (affectation correcte) dans
    cette saisie guidée. Auparavant, comme on ne tenait pas compte du montant, les deux fiches Immobilisations étaient affectées toutes deux
    sur les 2 lignes de classe 2, et ces deux lignes étaient donc affichées en rouge car le montant de la ligne ne correspondait pas à la somme
    des 2 fiches mises en regard.

L'état de situation des immobilisations a été amélioré. Jusqu'ici, il se basait implicitement sur les amortissements comptables. Désormais, on peut choisir de sortir cet état sur la base des amortissements comptables, fiscaux ou dérogatoires.
Dans le cas du plan dérogatoire, calculé par différence entre les plans d'amortissement comptables et fiscaux, la présentation des colonnes a été un peu aménagée :
 - les deux colonnes de droite VNC début et VNC fin sont remplacées par VNC Fin et VNF Fin. On peut ainsi comparer facilement
   les valeurs nettes comptables et fiscales à la date d'arrêté de l'état.
 - dans la colonne présentant le type d'amortissement avec les 3 informations Mode, Durée, Taux, on présente les 2 types d'amortissement
   comptable et fiscal, en ne mettant (faute de place) que le mode et la durée.
 - Enfin, sur les bandeaux de totalisation, le cumul des dotations de la période est présenté en 2 colonnes : Dotation d'un côté, Reprise de l'autre,
   la différence entre Dotation et Reprise se faisant en tenant compte, immobilisation par immobilisation, du sens de la différence entre
   amortissement comptable et amortissement fiscal : si le fiscal est supérieur au comptable, c'est un amortissement dérogatoire, sinon
   c'est une reprise d'amortissement dérogatoire.

D'autre part, l'option Exclure les immobilisations entièrement amorties est désormais complétée par une seconde option pour préciser si cette exclusion se fait sur l'amortissement comptable, fiscal ou les deux. Cette seconde option est positionnée automatiquement en fonction du plan d'amortissement sélectionné pour l'impression de l'état. Ainsi, si on choisit l'option par défaut d'impression sur le plan comptable, les immobilisations entièrement amorties sur le plan comptable n'apparaissent pas, même si fiscalement elles ne sont pas encore totalement amorties. On obtient ainsi le même état que ce que l'on avait auparavant.
Mais si on veut comparer plus facilement les 3 états comptable, fiscal et dérogatoire, il est préférable de demander ces 3 états avec exclusion des immobilisations entièrement amorties sur les deux plans. Ainsi, on a exactement les mêmes immobilisations sur les 3 états.

Enfin, par souci de compatibilité, cette sous-option permettant de mieux qualifier l'exclusion des immobilisations entièrement amorties a aussi été ajoutée sur les autres états où l'option Exclure les immobilisations entièrement amorties était déjà présente :
 - Liste des immobilisations
 - Fiches immobilisations
 - Plans d'amortissement (avec dans ce dernier cas un lien entre le plan d'amortissement demandé en impression et celui utilisé pour cette exclusion).

Remarque complémentaire : sur l'état de situation, la notion d'immobilisation entièrement amortie est appréciée au 1er jour de la période demandée.
Sur les 3 autres états, n'ayant pas de date de début de période, cette notion est appréciée par rapport à la clôture annuelle des immobilisations. Une immobilisation est considérée comme entièrement amortie dès lors qu'il n'existe plus aucune ligne dans le plan d'amortissement ayant une date de début de période (comptable ou fiscale selon le cas) renseignée et non close.

Grace à ces nouvelles options, on dispose de tous les outils pour suivre ces amortissements dérogatoires et pour contrôler la comptabilisation de ceux-ci, y compris en analytique puisque l'état de situation peut être imprimé selon de nombreux critères de tri dont le ou les axes analytiques.

Suite au correctif 282, les champs Remise à l'escompte et Remise à l'encaissement étaient grisés, mais dans le mauvais sens.

Une amélioration a été apportée sur les états de suivi de TVA : on peut désormais prendre en compte la TVA passée directement sur un journal de banque. Cela sera surtout utilisé pour la TVA déductible, dans le cas où l'on passe les écritures pour les frais de déplacement directement sur le journal de banque, en détaillant la TVA. Jusqu'alors, ces mouvements de TVA étaient ignorés ; on ne traitait que la TVA portées sur des journaux d'achat ou de vente.
Pour mettre en oeuvre cette nouvelle possibilité, il faut cocher l'option Prendre en compte la TVA sur les journaux de banque dans la fenêtre des paramètres de cet état, option qui apparait juste après la liste des journaux d'achat (ou de vente) à traiter.
Lorsque cette option est cochée, après avoir analysé tous les journaux d'achat (ou de vente) demandé, le système ajoute les pièces portées sur un journal de banque et mouvementant l'un des comptes de TVA déductible (ou collectée) identifié en tant que tel dans la table des codes TVA. Toutes ces pièces sont donc ajoutées sur l'état de TVA et sont considérées comme réglées (il n'y a pas de lettrage, mais s'agissant de pièces sur un journal de banque, c'est un règlement) et donc la TVA est systématiquement due, même si le compte de TVA mouvementé est un compte de TVA sur décaissements.
Pour ces pièces de banque, il n'y a aucun contrôle entre le montant TVA d'une part, les bases HT reconstituées à partir des montants TVA et les autres montants de la pièce. Ainsi, même si la pièce saisie correspond à des frais partiellement soumis à TVA, cela fonctionne correctement. On n'incorpore sur l'état que la base HT reconstituée à partir du montant TVA (et du compte de TVA mouvementé, pour connaitre le taux TVA), sans tenir compte du montant passé en classe 6 et en banque. On peut même avoir, pour une même pièce de banque, plusieurs comptes de TVA, dans le cas où pour les frais saisis, une partie est soumise au taux normal et une partie au taux réduit.
Ces pièces de banque n'apparaissent pas par défaut sur l'état détaillé de TVA car elles sont toujours réglées, sauf si on demande à voir le détail de toutes les factures, y compris celles réglées, pour une période donnée. Dans ce cas, ces pièces de banque vont apparaître à la fin de l'état, dans le compte de banque qui a été mouvementé par chaque pièce, faute de pouvoir être rattachées à un tiers précis.

Remarque : au passage, quelques ajustements ont été faits sur les états où le code racine du collectif était parfois tronqué.

Les améliorations suivantes ont été apportées dans ce module Bilan et CR :
 1) Le libellé proposé par défaut pour la 2ème colonne est désormais "Exerc. précédent" et non plus "Exercice précédent"
     qui était tronqué sur la plupart des imprimantes, faute de place, faisant croire à une faute d'orthographe.
 2) Les listes de contrôle des paramètres du bilan et CR ont été légèrement modifiées pour les rendre plus lisibles.
 3) Depuis la première fenêtre de saisie des paramètres du bilan et CR, on peut désormais demander l'impression des listes de contrôle.
 4) Lorsque la fenêtre de lancement de l'impression de ces listes de contrôle est appelée alors qu'on est en cours de saisie de ces paramètres,
     seule l'impression du tableau en cours de saisie est proposée (et non plus l'impression de tous les tableaux).

En saisie au kilomètre (KM), une pièce d'achat ne pouvait pas être validée si elle n'alimentait pas l'échéancier fournisseur à cause de son mode de règlement.

Dans la saisie au kilomètre, le fait de sélectionner une ligne depuis la table ne déclenchait pas le contrôle des données de la ligne en cours. Désormais, si une ligne n'a pas été contrôlée lorsqu'on valide la pièce, on effectue le contrôle de celle-ci. En cas d'erreur, la saisie reprend sur la ligne.

Le module de gestion des relevés de compensation a été revu afin de permettre de générer des relevés de compensation pour un groupe de tiers. Plutôt que de définir une liste des comptes clients venant en compensation d'un fournisseur, on travaille par groupe de tiers. Tous les tiers appartenant à un même groupe se compensent entre eux, dès lors que le code groupe a été référencé dans la liste des groupes de tiers à compenser. Et pour chacun de ces groupes, on indique le N° du fournisseur « principal », celui à qui le relevé de compensation est émis.
Une correction a également été apportée sur la lettre de règlement qui peut être imprimée lors de la comptabilisation du relevé de compensation car celle-ci pouvait être imprimée à tort à l'adresse d'un des clients compensés au lieu du fournisseur lié.

Suite au correctif 299, un message d'erreur lors de la validation de la pièce s'affichait. Cela était dû au fait que l'on forçait le contrôle de toutes les écritures, y compris la dernière ligne qui est vide et qui n'est pas prise en compte dans la pièce. Désormais, on ne recontrôle plus une écriture qui n'a pas de montant. 

Si des virements ont été enregistrés sur un journal qui n'est plus un journal de banque, alors la fenêtre se figeait et l'application plantait au bout de quelques minutes. Désormais, les virements liés à un tel journal sont chargés correctement, mais on ne voit pas le libellé de la banque.

Une nouvelle procédure permet de gérer l'affacturage (Factoring) avec la BNP.
Cela est décrit dans la note Evernote Export LDCompta pour Factoring BNP

Dans la saisie des règlements clients, un processus d'import de fichier de règlements existait déjà, pour accélérer la saisie des règlements « complexes », payant un grand nombre de factures réparties dans plusieurs comptes de tiers.
Sur le même principe, un processus d'import d'un relevé de compensation a été réalisé. Cela s'initie à partir du nouveau bouton Importer un relevé de compensation qui figure sur le premier écran de la saisie des règlements clients, dès lors que le fichier des relevés de compensation (CPTCFR) n'est pas vide.

En cliquant sur ce bouton, après avoir renseigné toutes les autres données du règlement, une fenêtre permet de saisir le N° du relevé, sachant qu'un N° est proposé par défaut : celui du relevé de compensation (non déjà comptabilisé) le plus ancien correspondant au tiers payeur (celui indiqué dans cette fenêtre de saisie d'un règlement client, tiers qui sera dans ce cas un fournisseur).
Lorsqu'on valide ce N° de relevé de compensation, le système analyse le contenu du relevé, c'est à dire la liste des factures et avoirs composant celui-ci. Pour chaque écriture référencée sur ce relevé, il vérifie que l'écriture d'origine est toujours présente et non déjà lettrée. Si Oui, cette ligne est mise de côté, car elle pourra être traitée entièrement en automatique. Sinon, elle sera reprise en détail en tant que ligne de l'éclatement.
Lorsqu'on valide le 1er écran de cette saisie du règlement client après avoir importé un relevé de compensation, un message d'avertissement apparait si le total du relevé ne correspond pas au montant du règlement, mais c'est un simple avertissement. Si le montant diffère, il suffira d'expliquer la différence en ajoutant une ou plusieurs lignes dans la fenêtre de saisie de l'éclatement du règlement qui va suivre.
Après avoir complété le 2ème écran, on arrive sur l'écran de saisie de l'éclatement du règlement. Le système présente en partie haute le total des factures réglées qui peuvent être gérées automatiquement, et le total des autres lignes importées. Bien souvent, la totalité des factures et avoirs référencés sur le relevé est repris dans le premier total. Il n'y a que les écritures ayant été lettrées entre le moment où le relevé a été préparé et le moment où l'on saisit le règlement qui sont reprises dans le 2ème total, et qui apparaissent de ce fait en détail dans l'éclatement.
Notez que si le montant du règlement diffère du montant du relevé, il faut ajouter la ou les lignes expliquant la différence. Puis on peut valider l'éclatement, ce qui permet d'enchainer sur les écrans de lettrage. Ce lettrage n'est à faire que pour les lignes en anomalie, celles qui sont présentées en détail sur l'écran de l'éclatement. Toutes les factures mises de côté sur l'écran 1 n'ont pas à être lettrées manuellement : elles le seront automatiquement.

La comptabilisation du règlement se fait ainsi :

• une écriture au compte de banque (ou portefeuille), pour le total réglé
• pour les lignes en anomalie, figurant en détail sur l'écran de l'éclatement, une écriture pour chaque ligne figurant dans cet éclatement, dans le compte choisi sur l'écran de saisie de l'éclatement, éventuellement lettrée si vous avez lettré manuellement cette ligne suite à l'éclatement
• pour toutes les factures mises de côté sur le 1er écran car pouvant être traitées en automatique, le système les regroupe par compte réglé et ne passe qu'une écriture par compte réglé, lettrant toutes les factures concernant ce compte réglé.

Dans la foulée, le relevé de compensation est marqué comme ayant été comptabilisé. Et l'échéancier fournisseur est nettoyé de toutes les factures et avoirs qui étaient référencées par ce relevé de compensation et qui existaient dans cet échéancier, à N° de facture et date d'échéance égales.

Ce correctif fait suite aux correctifs 170 et 182 pour tenter de corriger une erreur GPF qui apparaît de manière aléatoire sur certains postes. La procédure Trie de WinDev a été remplacée par un tri « manuel ».

Dans la saisie au km, lors de la validation d'une pièce d'achat, suivant les opérations effectuées par l'utilisateur, l'échéancier fournisseur n'était pas affiché.

La préparation d'un bon de compensation pour un seul fournisseur n'était plus possible depuis la dernière correction. Le programme provoquait l'erreur "Ce fournisseur n'est pas compensable" à tort.

Il est désormais possible de consulter CMViewer depuis LDCompta sans forcément avoir accès au serveur où est installé CMServer.
Pour cela, il faut aller dans la fenêtre de paramétrage des chemins d'accès (Alt F1 sur l'écran d'ouverture de session), cliquer sur le bouton Clés, basculer sur l'onglet Clé réseau (Copyminder) et cliquer sur le bouton Lancer CMViewer.
Il est aussi possible d'afficher le viewer lors de l'apparition du message disant que la licence ne permet pas d'utiliser une version supplémentaire de LDCompta. Cela peut se produire lors d'une migration à une nouvelle version. En maintenant la touche Control enfoncée lors de la validation du message, le viewer s'ouvre, ce qui permet d'essayer de rafraîchir la licence.

Plusieurs améliorations ont été apportées à cet état des délais de paiement des tiers, afin de satisfaire aux demandes des contrôleurs de gestion :

• Ajout du choix Factures échues uniquement ou Echues et non échues sur le premier onglet.
  Lorsqu'on demande Factures échues uniquement, la présentation de l'état s'adapte en conséquence. 
• Modification du titre de l'état : pour les clients, c'est désormais FACTURES EMISES NON REGLEES AU JJ/MM/AAAA, complété de la mention DONT LE TERME EST ECHU si on a choisi l'option Factures échues uniquement.
  Pour les fournisseurs, même chose avec FACTURES RECUES au lieu de FACTURES EMISES.
• Ajout du choix de la méthode de calcul du nombre de jours pour le classement en colonnes, avec 3 options : 
  • Date arrêté - Date échéance (Retard sur délai contractuel)
  • Date arrêté - Date pièce (Retard total)
  • Date échéance - Date pièce (Délai contractuel)
• Ajout d'un Export vers Excel direct

Notez que pour que l'état donne les chiffres attendus pour remplir le tableau décrit au I de l'article D441-4 du code du commerce, il faut lancer cet état avec l'option Factures échues uniquement et choisir le mode de calcul du nombre de jours Date arrêté - Date échéance (Retard sur délai contractuel).

Les exports Excel de la balance analytique et du grand-livre analytique étaient décalés sur les lignes pour lesquelles un ou plusieurs des axes définis n'étaient pas renseignés.

La racine des comptes compensés a été ajoutée dans les sous-titres de rupture du relevé de compensation. Cela implique que les écritures sont désormais regroupées par racine, en plus du compte auxiliaire.
Le code du fournisseur principal n'ayant pas forcement d'écriture, le code affiché dans l'entête du document affiche désormais la racine indiquée dans la fiche de ce fournisseur (si renseignée)
Un sous-total par regroupement a également été ajouté.

Un outil a été ajouté permettant de créer automatiquement les classes de comptes (1 à 3 caractères) dans le plan comptable afin d'afficher des totaux dans la balance générale. Pour lancer cet outil, dans le menu "Outils - Autres outils - Lancer un autre outil", choisir "Lancer une fenêtre Windev", et taper le nom de fenêtre "CPRTOTPLA". Ce programme a 2 options, le fait de ne créer les classes de comptes que s'il existe un compte comptable dans cette classe (ou créer toutes les classes de compte), et le nombre de niveaux à générer (1 à 3, soit 1 à 3 caractères).

Sur les états de trésorerie prévisionnelle, en plus du choix de l'unité d'affichage (Euros, dizaines, centaines ou milliers d'euros), on peut désormais choisir la taille de la police (entre 5 et 7) et le fait que l'on imprime ou pas les séparateurs de milliers.
Ainsi, là où l'on ne pouvait imprimer que des montants comportant 5 chiffres (variable selon les imprimantes), on peut aller jusqu'à 6, 7 ou même 8 chiffres (avec un plus le signe moins le cas échéant). On peut du coup rester avec un affichage en euros même sur des montants conséquents.

2 améliorations ont été apportées dans la fenêtre d'affichage des sessions actives (menu Fichier/Sessions actives) :

• un bouton CMViewer permet de lancer le gestionnaire de licence CMServer en mode Viewer, pour voir qui détient des licences (dans le cas où l'on utilise des licences de type « réseau »).
• dans la colonne Poste de travail, dans le cas d'un poste travaillant en environnement TSE ou Citrix, on voit désormais le nom du poste client et le nom du serveur TSE, par exemple PCJocelyn sur SERVEURLD. 

Dans la fenêtre de saisie d'une ventilation analytique détaillée pour une écriture de comptabilité générale, on peut saisir désormais directement le pourcentage par rapport au montant total à ventiler (le montant de l'écriture en comptabilité générale) plutôt qu'une valeur « brute ».
Cela se fait au travers du champ de saisie Calculette disponible pour tous les champs de type Montant mais qui dans cette fenêtre particulière propose 2 modes complémentaires :

• Si dans le champ de saisie du montant, on appuie directement sur la touche % (même si le clavier n'est pas en majuscule), la petite fenêtre de saisie de la formule de calcul apparait et celle-ci est pré-renseignée par <Montant total à ventiler> * %, le curseur étant placé juste avant le caractère %. Il n'y a donc plus qu'à saisir le pourcentage souhaité et à frapper sur la touche Entrée ou Tabulation pour calculer l'expression. La valeur résultante est alors retournée dans la zone Montant de départ où l'on avait frappé la touche %.
  On peut aussi saisir une valeur dans la zone Montant avant de frapper la touche %. La formule de calcul sera alors pré-renseignée par <Montant total à ventiler> * <Valeur saisie>%, <Valeur saisie> étant sélectionné (en bleu) au cas où l'on veuille la modifier. Mais à ce stade, il n'y a en principe plus qu'à appuyer sur Entrée ou Tabulation pour calculer l'expression et retourner le résultat.
• Autre méthode alternative qui fonctionne : dans le champ de saisie du montant, on frappe la touche = pour ouvrir la petite fenêtre de saisie d'une formule. Et dans cette fenêtre, on saisit directement le pourcentage souhaité suivi du caractère % avant d'appuyer sur Entrée ou Tabulation pour calculer l'expression et retourner le résultat. Dans ce cas de figure, le système applique le pourcentage souhaité sur le montant total à ventiler même si celui-ci n'a pas été explicitement indiqué dans la formule.
  Attention : cette méthode ne fonctionne que si on saisit une valeur numérique (avec éventuellement une partie décimale) suivie du caractère %, sans aucun autre opérateur ou espace.

Lorsque l'on passait sur le 3ème onglet de la fenêtre, le bouton Générer pouvait devenir actif par erreur.
Maintenant le bouton Générer n'est actif que si on a préalablement cliqué sur le bouton Calculer et qu'il y a des écritures à transmettre. 

Diverses corrections ont été apportées à l'outil LDCPTRLB :
- le montant de l'ancien solde pouvait être tronqué et se retrouver sans partie décimale ;
- on accepte n'importe quel identifiant de compte dans la balise :25: ;
- s'il n'y avait pas de détail dans le relevé, le fichier ne pouvait pas être intégré.
- la zone Funds Code est prise en compte. C'est une zone qui n'apparait pas dans tous les formats MT940.

Suite à des disparités de format dans les différentes versions du format MT940, de nombreuses modifications ont été apportées :
- gestion des compléments ;
- gestion de mots clés spécifiques à un format MT940 en particulier (mots clés de la forme /xxx/ : /ORDP/, /REMI/, /BENM/ /NAME/) ;
- prise en charge de la zone Funds Code dans les lignes :61:. Cette zone n'est pas présente dans tous les formats ;
- gestion des sens de montants RD et RC (Reverse debit et Reverse credit).

On rencontrait un crash inexplicable dans la fenêtre permettant de changer de dossier, lors du clic dans la liste des sociétés.
Ce problème ne se produisait que si on était en environnement HFCS (HyperFile Client/Serveur), avec une certaine taille du fichier des sociétés (plus de 1000 enregistrements ; en diminuant le nombre d'enregistrements dans le fichier des sociétés, le problème disparait). 

Complément technique : le problème se posait sur un ordre de lecture HLitDernier sur le fichier des sociétés, mais ne se produisait qu'au deuxième passage sur cet ordre, c'est à dire après avoir lu la totalité du fichier des sociétés dans l'ordre inverse des codes sociétés, de la dernière à la première (ce qui est fait à l'affichage initial de la fenêtre). Faute de trouver une explication « logique » à ce crash, on a trouvé un moyen de contournement : avant l'ordre HLitDernier, on a intercalé un ordre HLitPremier pour se repositionner au début du fichier. Et ça fonctionne !

Depuis la fenêtre de modification d'une action de relance, un nouveau bouton permet d'accéder en un clic à la fiche du client avec, comme en consultation d'un compte, un accès en affichage par défaut ou en modification si la touche Majuscule est enfoncée lors du clic sur le bouton.

Complément d'information : des protections ont été ajoutées pur éviter des effets de bord en cas d'appels récursifs. En effet, on peut accéder aux actions de relance depuis les fenêtres de gestion des fiches clients, et on peut désormais accéder aux fiches clients depuis les fenêtres de gestion des actions de relance. On peut donc boucler ainsi à l'infini. Toutefois, la protection évite des appels en mode Modification. S'il y a un appel récursif, c'est uniquement en mode Consultation.

4 petites améliorations ont été apportées dans la saisie des virements reçus :

• Si on sélectionne le client par le bouton Chercher, ce qui ouvre une fenêtre de recherche par montant ou N° de facture, le N° de la facture sélectionnée dans cette fenêtre est automatiquement mémorisé (seulement si la ligne sélectionnée est au débit) pour que lorsqu'on arrive dans la fenêtre de lettrage du compte client, en fin de saisie du virement, cette facture soit pré sélectionnée.
• Pour la recherche du nom du tiers, on prend désormais en priorité le nom apparaissant sur la ligne Nom du payeur dans les informations complémentaires reçues pour le virement, si ce nom du payeur y figure effectivement (libellé complémentaire identifié par le type NPY). A défaut, on prend comme avant le libellé du virement. Ce comportement est adopté automatiquement suite à la mise en place de cette correction. Toutefois, sur l'écran des paramètres de cette saisie, une case à cocher permet de revenir au comportement antérieur si on le souhaite.
• Pour la détermination du numéro du tiers à partir du libellé du virement ou du nom du payeur, on peut désormais spécifier une série de suffixes à éliminer, de la même façon qu'on pouvait éliminer certains préfixes. Ainsi, si le nom du payeur reçu sur le virement est MA SOCIETE SA et qu'on a demandé à éliminer le suffixe SA, le nom du tiers utilisé pour rechercher le numéro sera simplement MA SOCIETE. Rappelons que la recherche du numéro du tiers se fait ensuite, dans le fichier client et avec ce nom de tiers une fois les préfixes et suffixes retirés, en priorité sur la clé Libellé interne, puis dans un second temps sur la clé Nom condensé si la recherche par libellé interne n'a pas abouti.
• Quand on effectue une recherche, depuis cette saisie des virements reçus, du client émetteur du virement par le bouton Chercher, recherche qui est faite alors sur le montant du virement, on présente aussi les éventuels règlements présents en portefeuille qui auraient le montant en question. Ainsi, si le virement que l'on cherche à saisir à partir du relevé bancaire a déjà été saisi par avance dans le portefeuille (car on ne connaissait pas son échéance précise), le système va retrouver le client concerné alors que sans cette correction, le compte client étant lettré, aucune écriture n'était présentée pour ce client, sauf à demander à voir toutes les écritures y compris les écritures lettrées. Mais même dans ce cas, on ne voyait par le virement en portefeuille si celui-ci avait été saisi avec éclatement sur plusieurs comptes, car les montants passés dans les différents comptes clients de l'éclatement ne correspondent pas au montant global du virement trouvé sur le relevé bancaire.
  Note : une correction prochaine va améliorer encore ce cas de figure, avec signalement de la présence d'un virement en portefeuille et possibilité de se débrancher, depuis la saisie des virements reçus, sur la gestion du portefeuille pour comptabiliser la remise en banque du virement en question.

Deux modifications majeures ont été apportées dans la saisie des virements reçus :

1) Possibilité d'éclater un virement reçu sur plusieurs comptes ou même d'importer un fichier de règlements clients

Sur l'écran de comptabilisation d'un virement reçu, on a ajouté une case à cocher Eclatement sur plusieurs clients et le bouton Importer un fichier de règlements, à l'identique de ce qu'il y a sur le 1er écran de saisie d'un règlement client. Quand on clique sur le bouton OK de cette fenêtre, si la case Eclatement sur plusieurs clients est cochée, au lieu d’enchaîner sur le lettrage du compte client, il y a un appel automatique au programme de saisie des règlements clients dans un mode particulier : les 2 premiers écrans de la saisie d'un règlement client (rgcmaj01 et rgcmaj02) sont renseignés et validés automatiquement sans que ces écrans apparaissent (sauf si une erreur est provoquée lors de la validation de l'écran, mais c'est fort peu probable puisque tous les champs utilisés pour l'initialisation ont déjà été vérifiés sur l'écran de saisie du virement reçu). On arrive ainsi directement sur l'écran de saisie de l'éclatement, celui-ci étant éventuellement initialisé à partir du fichier d'import de règlements clients utilisé sur l'écran de saisie du virement reçu. Lors de la validation de l'éclatement, la comptabilisation est faite "normalement" (avec éclatement, lettrage des différents comptes de l'éclatement...) par le programme de saisie des règlements clients, puis lorsqu'on revient sur l'écran du virement reçu, celui-ci est marqué comme étant comptabilisé comme dans le cas d'une saisie "classique" de virement reçu (sans éclatement).

2) Pont avec la gestion du portefeuille de règlements clients

Lors de la validation du 1er écran de la saisie du virement reçu, après avoir identifié le client et juste avant de passer au lettrage, s'il existe un virement en portefeuille pour le client en question du montant du virement reçu (avec le même mode de paiement), le système propose de se débrancher sur la gestion du portefeuille pour sortir ce virement du portefeuille via une remise en banque. Si on répond Oui à cette invite, quand on arrive dans la gestion du portefeuille, le virement concerné est déjà présélectionné pour remise en banque ; on arrive directement sur l'écran de comptabilisation de la remise où les différents champs (journal de banque, date, date de valeur...) sont déjà pré-renseignés à partir des valeurs indiquées sur l'écran de saisie du virement reçu. Il n'y a donc plus qu'à valider cette remise en cliquant sur le bouton OK.
Lorsque la comptabilisation du virement se fait ainsi via une remise depuis le portefeuille, la ligne du relevé correspondante est marquée non pas avec la valeur C=Comptabilisée, mais P=Portefeuille.
De plus, si dans la saisie des virements reçus, on est passé par le bouton Comptabiliser en automatique et que le virement est déjà en portefeuille, tout ce processus est réalisé automatiquement sans aucune intervention de l'utilisateur : le virement concerné est basculé du portefeuille au compte de banque et la ligne du relevé bancaire est marquée avec le code P=Portefeuille.

4 petites modifications ont été faites dans la saisie des remises en banque en sortie de portefeuille :

• Pour les règlements qui ne font l'objet d'aucun « suivi de règlement » (option Mouvementer compte transitoire et Imprimer sur bordereau de remise non cochées pour le mode de paiement correspondant), on inscrit automatiquement un N° de bordereau à 999999 sur le règlement lors de la sortie de portefeuille. Ainsi, ce règlement ne sera pas « vu » dans le suivi des bordereaux de remises en banque. C'est la même logique que celle qui était déjà mise en œuvre lors de la saisie d'un règlement client ne passant pas par le portefeuille.
  Remarque : cette modification a peu de conséquences, car il est assez rare de passer en portefeuille des règlements ne faisant l'objet d'aucun suivi (les virements notamment).
• Lorsque la remise en banque se fait sur un journal de banque ayant un compte transitoire et que l'on a demandé (Fiche société, onglet Trésorerie) à ce que le compte transitoire ne soit pas mouvementé en sortie de portefeuille, les informations relatives à la pièce comptabilisée, (hormis la date comptable, c'est à dire la date de valeur, la référence document, le code nature de pièce et éventuellement le N° de pièce) ne sont pas saisissables (zones grisées). Or, depuis la correction N° 272, cela n'était plus vrai pour certains de ces champs.
• Pour déterminer si les informations relatives à la pièce étaient saisissables ou pas, on ne tenait compte que du fait que le journal de banque avait un compte transitoire et que l'option Mouvementer compte transitoire en sorte de portefeuille n'était pas cochée. Or, il faut tenir compte aussi du fait que tout ou partie des règlements à sortir du portefeuille ne doivent pas mouvementer le compte transitoire (option Mouvementer compte transitoire non cochée sur le mode de paiement) car dans ce cas, il y a quand même comptabilisation de la sortie du portefeuille, pour ces règlements uniquement, directement sur le compte de banque.
  Ce cas de figure est donc désormais géré correctement.
• De la même façon, dès lors que la remise en banque se faisait sur un journal de banque ayant un compte transitoire, on interdisait la saisie d'une date de valeur. Là aussi, il faut tenir compte du fait que tout ou partie des règlements à sortir du portefeuille ne doivent pas mouvementer le compte transitoire car dans ce cas, il y a quand même comptabilisation de la sortie du portefeuille, directement sur le compte de banque, et on peut donc vouloir inscrire une date de valeur sur ce compte de banque. Ce cas de figure est lui-aussi géré correctement désormais.

La fenêtre de reprise d'une comptabilité depuis un fichier au format standard DGFiP (fenêtre iImpDGI) a subi quelques corrections :

• on ne reprend désormais en tant que compte auxiliaire que les écritures mouvementant un compte général apparaissant dans une liste définie explicitement sur l'écran de lancement (même principe que pour les clients ou fournisseurs). Auparavant, toute écriture où le N° de tiers était renseigné et pour laquelle le compte général ne correspondait pas à un compte collectif client ou fournisseur était reprise dans un compte « autre auxiliaire ».
• si dans le dossier comptable où l'on effectue la reprise, le module devise n'est pas activé, les zones « Devises » (montant et code devise) du FEC sont ignorées.
• pour toutes les zones numériques, on remplace le séparateur décimal "," présent dans le FEC par le séparateur décimal "." pour le fichier d'interface au format LDCompta.

Suite à une reprise de données, il arrive que certaines immobilisations provoquent un plantage lors du calcul. Désormais, l'erreur est interceptée et ne met plus fin au programme. Ainsi, si on demande le calcul de plusieurs immobilisations, elles sont toutes calculées et les immobilisations en erreur sont affichées dans une trace.

Toutes les fenêtres d'impression ont été revues afin de permettre l'export en PDF direct, via un nouveau bouton PDF venant en lieu et place du bouton Options d'impression. Le nom de fichier et l'emplacement des fichiers générés, que ce soit depuis ce nouveau bouton PDF, ou depuis le bouton d'export PDF dans la fenêtre d'aperçu avant impression sont configurables dans une nouvelle fenêtre Paramètres pour les fichiers PDF, fenêtre accessible par un clic droit sur le bouton PDF de la fenêtre d'impression.
Notez si la touche Majuscule est enfoncée lors du clic sur le bouton PDF, le sélecteur de fichiers Windows sera proposé pour choisir le nom et l'emplacement du fichier PDF.
La fonction de paramétrage de l'impression, accessible par l'ancien bouton Options d'impression ayant été remplacé par le bouton PDF, est désormais accessible par un clic droit sur le bouton Impression directe (bouton de gauche).

Une nouvelle option Editions de clôture a été ajoutée au menu Edition. Cette option permet de lancer en une seule opération toutes les éditions nécessaires avant la clôture d'exercice : journaux, contrôle des journaux, balances (générale, clients, fournisseurs, et autres auxiliaires) et grands-livres. Il est possible, depuis cette fenêtre :

• soit de lancer les éditions « directement » sur une imprimante, en aperçu avant impression, ou en pdf (cette dernière option étant certainement la plus appropriée avant une clôture d'exercice), et ce via les 3 boutons habituels figurant en haut à droite de la fenêtre
• soit via le bouton Lancer... de passer successivement sur chacune des fenêtres de lancement des éditions sélectionnées afin de pouvoir modifier certains paramètres propres à l'édition.

Deux corrections ont été apportées dans la saisie des virements reçus, faisant suite aux améliorations décrites dans la fiche N° 351 :

• Le pont avec la gestion du portefeuille ne fonctionnait pas à tous les coups, en environnement AS/400 uniquement. La recherche du virement dans le portefeuille, avec un filtrage par montant, fonctionnait une fois sur 2 en moyenne, sans qu'on sache bien pourquoi. Pour contourner ce problème technique (lié à Easycom), au lieu d'effectuer le filtrage par montant directement par un ordre HFiltre, on parcourt désormais tous les règlements du client concerné et l'on teste le montant de ces règlements un à un jusqu'à trouver celui qui est recherché. 
• Lors de la recherche du tiers concerné par un virement reçu, recherche qui est faite sur le nom du tiers payeur observé sur le virement, on ne tient compte désormais que des tiers (clients, fournisseurs, autres auxiliaires) actifs : les tiers suspendus sont ignorés.

En parallèle, une amélioration a été apportée : si en saisie des virements reçus, on passe par le bouton Comptabiliser en automatique, pour les virements pour lesquels le système arrive à identifier le compte de tiers concerné et détecte que le virement en question est déjà présent en portefeuille, il y a désormais automatiquement comptabilisation de la sortie de portefeuille de ce virement sans aucune autre interaction avec l'utilisateur (pas de message d'avertissement, pas d'affichage des fenêtres de gestion du portefeuille).

La mise en page des grands livres (généraux, clients, fournisseurs, autres auxiliaires), pour ce qui est du format vertical (portrait) uniquement, a été revue afin de ne pas tronquer le libellé de l'écriture s'il est trop long. Trois modifications ont été apportées pour cela :

• La colonne N° de ligne (présentant le N° interne d'écriture de LDCompta) a été déplacée à droite du libellé, les colonnes N° de pièce, Echéance et Libellé écriture ont été décalées sur la gauche en conséquence. Et par défaut, cette colonne n'est désormais plus imprimée, ce qui permet d'étendre le libellé sur la place ainsi rendue disponible. Pour retrouver ce N° de ligne sur l'état comme auparavant, il faut inscrire la lettre O (O=Oui) en position 1 de la valeur alphanumérique du paramètre programme GLGETAV (à créer si inexistant).
• La référence document peut ne pas être affichée. Pour cela, il faut inscrire la lettre N (N=Non) en position 2 de la valeur alphanumérique du paramètre programme GLGETAV (à créer si inexistant).
• Le champ présentant la référence document (si imprimée) et le libellé écriture est désormais multilignes et auto-extensible en hauteur. Ainsi, si le contenu de ce champ excède la largeur de la colonne disponible sur l'état, il y a retour automatiquement à la ligne. Ces informations ne sont donc jamais tronquées.

Les valeurs inscrites dans le paramètre programme GLGETAV sont valables pour l'ensemble du dossier comptable, quel que soit le grand livre (au format vertical) et quel que soit l'utilisateur.

Suite au correctif niveau 358, qui introduit la possibilité d'imprimer directement en PDF depuis la fenêtre de lancement de l'impression, certaines fenêtres pouvaient provoquer une erreur du type "Le champ 'xxxeta' est inconnu." (où "xxxeta" correspond au nom d'un état). L'ensemble des appels a donc été repris pour éviter cette erreur.

Lorsqu'on valide une immobilisation, un contrôle a été ajouté pour vérifier que le montant HT a bien été saisi. S'il n'est pas saisi lorsqu'on revient sur une immobilisation, la zone peut être saisie. De même un contrôle avec avertissement a été ajouté lorsque la base amortissable (comptable ou fiscale) est supérieure au montant HT net. 

Deux modifications ont été apportées sur le grand-livre (clients ou fournisseurs) par échéance :

• La date d'échéance (Colonne 1) est désormais imprimée au format JJ/MM/AA et non plus JJ/MM/AAAA, car elle était parfois tronquée faute de place suffisante ;
• Dans la colonne Date de facture, c'est la date de pièce qui est imprimée et non plus la date d'écriture (plus utile sur les à nouveaux notamment).

La version 3.1 du composant LD_XML, géré par la société CPI, a été intégrée dans LDCompta. Cette version 3.1 apporte deux corrections :

• Elle gère mieux la date d'exécution du virement SEPA, quand on demande une date d'exécution dans une année autre que l'année en cours. Il pouvait dans certains cas y avoir un problème lié à la conversion de la date d'exécution, du format JJMMA (année sur un seul chiffre) utilisé dans le fichier intermédiaire au format CFONB transmis à ce composant pour traduction, vers le format AAAA-MM-JJ utilisé dans le fichier final au format XML SEPA fourni par le composant.
• Dans le cas de la conversion d'un fichier de virement internationaux du format CFONB au format XML ISO 20022, elle traite le cas des montants en devises sans décimales (comme dans le cas du yen, code devise JPY).

Lors de la création d'un dossier comptable en mode Client/Serveur AS/400, il pouvait y avoir une erreur lors de la validation. L'erreur se produisait au moment du contrôle d'existence de la bibliothèque AS/400 dont le nom avait été spécifié sur l'écran de création du dossier. L'erreur était du type :
Une erreur inattendue est survenue lors de la vérification d'existence de la bibliothèque XXXXXXXXXX sur l'AS/400 :
...
Full message : Le profil SSO a expiré (ré-authentification requise).

Ce message se produisait lorsqu'on avait indiqué, dans le fichier de configuration LDCParam.INI, la valeur * pour le mot-clé AS400Password sans avoir indiqué de valeur pour le mot-clé AS400Name.

Dans les différentes procédures de consultation (compte, journal, pièce...) et dans l'impression d'un compte demandée depuis la consultation compte, il y avait des problèmes lorsqu'on appliquait un filtre sur la colonne Libellé écriture, dès lors que la valeur utilisée pour le filtrage contenait un espace :

• Si le filtre était appliqué par un double clic sur un libellé directement dans la table de la procédure de consultation d'un compte, en impression dudit compte, plus rien ne s'imprimait.
• Si on saisissait, dans la fenêtre de gestion des filtres, un filtre s'appliquant sur la colonne Libellé écriture, avec une valeur contenant un espace, plus rien ne s'affichait en consultation.

Ces deux problèmes avaient la même origine : dans toutes les fenêtres de consultation, le libellé écriture qui est affiché est chargé en remplaçant systématiquement tout caractère Espace (20 en ASCII) par un caractère Espace insécable (160 en ASCII) (voir correction N° 106 qui justifie la présence des caractères Espace insécable).

Il n'est plus possible de générer une remise LCR si l'IBAN (ou le RIB) de la banque n'est pas renseigné dans le journal de banque.

Trois corrections et optimisations ont été faites dans la GED (Gestion Electronique des Documents) :

• Quand, dans une fiche Compte général, Client, Fournisseur, Immobilisation..., on ajoutait un document en cliquant sur le bouton GED situé à droite de la fiche, au retour sur la fiche, l'état du bouton (image et bulle d'aide associées) ne tenait pas compte du fait qu'on avait ajouté un document. Le bouton GED se présentait toujours comme si on avait aucun document lié à la fiche.
• Dans la fenêtre présentant les documents liés à une entité (un client, un fournisseur, un compte général, une immobilisation......), on affiche d'une part les documents effectivement liés à l'entité (via un parcours des liens présents dans le fichier GEDLIE), mais aussi les fichiers présents dans le répertoire correspondant à l'entité, même s'ils ne sont pas liés.
  Désormais, les fichiers ayant l'attribut Système (comme par exemple le fichier Thumbs.db qui contient les miniatures des images présentes dans le répertoire) ne sont plus affichés dans cette fenêtre car ils n'ont aucun intérêt (ils sont d'ailleurs masqués par défaut dans l'explorateur Windows).
• Pour l'affichage du bouton GED en partie droite d'un fiche Compte général, Client, Fournisseur, Immobilisation..., où l'image associée au bouton est fonction du fait qu'il existe dans la GED un document associé à la fiche, et où la bulle d'aide précise le nombre de documents associés dans la GED à cette fiche, plutôt que d'identifier précisément tous les documents associés dans la GED, on se contente de les compter. Et on ne parcourt plus les répertoires Windows de la GED à la recherche d'éventuels documents présents mais non référencés dans la GED. On ne compte donc que les documents effectivement référencés dans la GED (mais il est exceptionnel d'avoir des documents présents dans les répertoires Windows de la GED et non référencés dans celle-ci).

Quand on rappelait pour modification une OD analytique ayant plus de 200 lignes, si on tentait d'ajouter une ligne à l'OD, il y avait une erreur :
Erreur à la ligne 24 du traitement Procédure locale xModifierEtatZones
La dimension 1 du tableau possède 200 éléments et ...

Dans la fenêtre d'affichage du détail d'un ordre de virements ou prélèvements, un nouveau bouton permet de supprimer un des virements ou prélèvements contenus dans l'ordre.
Attention : lorsqu'on en est là, l'ordre de virement ou prélèvement a déjà été comptabilisé. La suppression d'un des virements ou prélèvements ne donne pas lieu à comptabilisation. L'utilisateur doit donc contre-passer lui-même (en saisie par pièce) le règlement ayant été supprimé de l'ordre.
Le seul intérêt de la suppression faite ainsi est de pouvoir transmettre à la banque le reste de l'ordre de paiement, une fois le virement ou prélèvement erroné retiré de l'ordre.
Notez que cette suppression ne peut être faite que par un utilisateur ayant un niveau d'accès Administrateur sur le dossier comptable concerné.

Complément d'information : en même temps que cette modification, une faute d'orthographe a été corrigée dans le message d'erreur Cette fonction est réservée aux utilisateurs ayant un niveau d'accès <Administrateur>, et ce dans toutes les fenêtres où il apparaissait (5 autres fenêtres).

Il est désormais possible de saisir un montant HT à zéro, mais si et seulement si la base amortissable est elle-aussi à zéro.
Il est aussi désormais possible de saisir une base amortissable quand il n'y a pas d'amortissement (Type d'amortissement = Aucun). 

Une fenêtre d'export de l'en-cours client, dans un format pouvant être lu par le logiciel Adonix G5, avait été développée en 2014 (voir correction N° 75).
Une correction a été faite ici : il manquait le retour ligne (CR LF) sur la dernière ligne inscrite dans le fichier d'export.

La fenêtre IaaCvt (à lancer depuis le menu Outils/Autres outils/Lancer un autre outil) permet de convertir un fichier d 'interface entre les différents formats « standard » LDCompta, TXT (texte à colonage fixe), CSV et XML des différentes versions.
Cette fenêtre a été revue pour prendre en charge les formats de la version 10, car cela n'avait pas encore été fait.
On sait donc désormais convertir entre eux les 3 formats TXT, CSV, XML de la version 10.
On sait aussi convertir un fichier au format TXT V9 ou V8.50 vers l'un des 3 formats de la V10.
Et enfin, on sait convertir un fichier au format TXT V10 vers un format TXT V9, CSV V9 ou TXT V8.50.

Remarque : cet outil peut être utilisé par exemple pour convertir un fichier d'interface au format TXT vers un format CSV, ce dernier pouvant alors beaucoup plus facilement être ouvert dans Excel pour analyse du contenu.

L'automate d'interface avec les autres applications (menu Outils/Automate d'interface avec autres applications) a été amélioré pour pouvoir être utilisé pour des imports de données AS/400.
En effet, les différentes règles que l'on peut mettre en œuvre sont toutes basées sur la présence d'un fichier Windows, fichier qu'on identifie dans chaque règle par un répertoire source et un nom générique. Dans le cas où l'on veut importer des données qui sont sur un serveur AS/400, cela ne peut pas fonctionner ainsi.
Pour cela, on peut désormais indiquer la valeur spéciale *AS400 dans le mot-clé REPSOURCE d'une règle. On indique alors un libellé dans le mot-clé NOMSOURCE de cette même règle.
Une règle configurée ainsi est appelée systématiquement quand on clique sur le bouton Intégrer maintenant (ou quand la règle est déclenchée en mode automatique), sans tester la présence d'un fichier particulier. C'est la fenêtre de prétraitement (indiquée au mot-clé FENETRE_PRETRAITEMENT de la règle) qui doit prendre en charge la recherche des données sur le serveur AS/400 et la gestion éventuelle des erreurs si le fichier attendu n'existe pas.
Note : le libellé indiqué dans le mot-clé NOMSOURCE sera utilisé pour créer le fichier Log correspondant. Par exemple, si on indique Interface Paie pour ce mot-clé, le fichier historique de ce traitement d'interface sera créé dans le sous-répertoire Interfaces du répertoire des sous-répertoires (en principe, X:\Ldsystem\Fichiers\Compta\Interfaces), sous le nom Interface Paie_AAAAMMJJ_HHMMSS.txt, où AAAAMMJJ_HHMMSS correspond à la date et l'heure du traitement.

D'autres modifications (mineures) ont été apportées à cette procédure :

• un séparateur horizontal a été ajouté dans la fenêtre, pour une personnalisation accrue de l'agrandissement de la fenêtre entre la partie haute (la table des règles) et la partie basse (la trace des traitements réalisés).
• deux boutons permettant de sélectionner toutes ou aucune des règles affichées ont été ajoutés
• la remontée des erreurs a été améliorée, notamment dans le cas où l'on abandonne un traitement explicitement en cliquant sur le bouton Annuler dans la fenêtre d'interface appelée pour une règle donnée (quand on a spécifié la valeur O (Oui) au mot-clé AFFICHER_FENETRE, ce qui permet de voir passer la fenêtre d'interface et donc de l'annuler si besoin est).

La correction 404 a provoqué une erreur dans la fenêtre d'affectation automatique des règlements fournisseurs lorsque la base de données est sur AS400. Le message de l'erreur est "Elément syntaxique OU n'est pas correct".

La fenêtre de conversion du fichier d'interface au format PNM, dans le format LDCompta, ne lisait pas correctement la zone Montant des fichiers PNM. Cette zone était lue de la position 94 à 104 de la ligne, au lieu de la position 85 à 104. Cela ne fonctionnait donc pas lorsque les montants étaient cadrés à gauche (la norme prévoit toutefois que ce montant doit être cadré à droite).

On peut désormais ajouter, dans la GED de LDCompta, des documents accessibles via un lien HTTP (lien hypertexte, dit aussi URL Web). Les documents GED ne sont pas stockés dans ce cas en local ; on ne conserve que le lien (l'URL) dans la base de données de LDCompta.
Pour ajouter des documents de ce type, une nouvelle option Ajouter un lien HTTP (URL) a été ajoutée à tous les menus contextuels permettant d'ajouter un document dans la GED, en sus des deux options que l'on avait déjà : Acquisition depuis un scanner et Ajouter un fichier. Lorsqu'on sélectionne cette option de menu Ajouter un lien HTTP (URL), une petite fenêtre s'ouvre dans laquelle on peut saisir (ou plus certainement copier) le lien HTTP. La validité de ce lien est contrôlée (le système lance une requête HTTP sur cette URL et vérifie qu'il obtient en retour un code HTTP 200 OK), sauf si on décoche l'option Vérifier que ce lien http est valide.
De plus, dans la procédure d'interface standard, on accepte désormais des URL en guise de chemin d'accès à un document. Mais dans cette interface, pour des questions de performance (on peut avoir un grand nombre d'URL distinctes dans un fichier d'interface), aucun contrôle de validité des URL n'est réalisé.

Remarque : partout dans la GED de LDCompta, les liens HTTP sont distingués des chemins d'accès « classiques » par le fait que le chemin est de la forme <protocole>://<reste du chemin>, où <protocole> est une suite de lettres alphabétiques (majuscules ou minuscules) et <reste du chemin> est une chaine de caractères quelconque non vide.

Une nouvelle option (cachée) permet de constituer, lors de chaque préparation d'un fichier de virements SEPA, un second fichier CSV contenant la liste des factures réglées par les virements SEPA. Ce fichier peut être exploité par un logiciel de communication bancaire pour présenter à la personne qui signe l'ordre de virement toutes les informations lui permettant de contrôler la pertinence des virements, y compris l'accès à l'image des factures en PDF si celle-ci a été enregistrée dans la GED de LDCompta.
Le fichier CSV est placé dans le même répertoire que le fichier SEPA, avec le même nom auquel on ajoute .csv à droite.
Ce fichier est composé de :
 - Référence du paiement (contenu de la balise EndToEndId du fichier SEPA, qui permet de mettre les informations présentes dans ce fichier
  en regard des différents virements portés dans le fichier SEPA)
 - N° de facture (N° de pièce ou Référence document selon le paramètre décrit plus bas)
 - Date de facture (format paramétrable, voir plus bas)
 - Montant signé (positif pour les factures, négatif pour les avoirs)
 - Libellé écriture (celui indiqué dans l'échéancier fournisseur)
 - Lien GED (Lien vers le premier document référencé dans la GED LDCompta pour la facture réglée), soit une UNC dans le cas d'un fichier enregistré sur le réseau local,
   soit une URL si le fichier est enregistré dans une GED accessible par le Web.
Pour déclencher ce traitement complémentaire suite à la création d'un fichier de virements SEPA, il faut aller corriger manuellement le paramètre programme CPEVIR :
 - Position 65, indiquer O pour Oui
 - Position 66 : Séparateur du fichier CSV :  ,  ;  ou  T=Tabulation
 - Position 67 : Séparateur décimal :  .  ou  ,
 - Position 68 : R si on veut que les N° de facture exportés correspondent aux références document (zone REFD)
   Dans tous les autres cas, on prend le N° de pièce (zone NPIE) en tant que N° de facture
 - Position 75 à 84 : format des dates : JJ/MM/AAAA par défaut. On doit indiquer ici un format de date reconnu par Windev (ordre DateVersChaine). 

Dans la procédure d'interface permettant d'intégrer des écritures au format PNM (fenêtre de pré-traitement d'interface nommée IPNMFAC), on peut désormais intégrer des écritures ayant une ventilation analytique. On le fait en s'appuyant sur la ventilation analytique portée en colonne 26 à 35 (format PNM 142 caractères), sur les lignes ayant un code A en colonne 25 (les ventilations analytiques multi-axes prévues dans le format PNM 199 caractères ne sont pas supportées).
La gestion de ces ventilations analytiques présentes dans le fichier PNM est toutefois facultative : un nouveau paramètre de lancement permet de stipuler si on souhaite comptabiliser avec ou sans les ventilations analytiques.

Remarque : le format du fichier de sortie de cette procédure est toujours le format XML V10.

La documentation propre à cette procédure a été mise à jour (fichier IntPNM.fdf, révision 3 de septembre 2019).

• dans la fenêtre de saisie pour ajout manuel d'un lien HTTP dans la GED, le masque de saisie Adresse WEB (URL) qui avait été placé sur le champ de saisie de l'URL a été retiré. En effet, celui empêchait l'utilisation de certains caractères spéciaux ( {}&? ) dans l'URL.
• dans la procédure d'interface, le contrôle d'existence de la pièce effectué dans le cas d'un document GED relié à une pièce elle-même interfacée dans le même fichier que le lien GED était fait sur la date de pièce et non sur la comptable de l'écriture.

Dans la fenêtre de gestion des droits accessible par le bouton Droits depuis la gestion des utilisateurs ou des sociétés, on pouvait rencontrer une erreur quand on cliquait sur le bouton Répéter. L'erreur est la suivante : Erreur à la ligne 25 du traitement Méthode Activer. L'élément 'NIVS' est inconnu.

Pour corriger cette erreur, on a implémenté un petit complément de code. Mais on n'a pas de véritable explication : le même code exécuté dans LDPaye V9.60, sous Windev 24, fonctionne parfaitement. Il semble qu'il y ait un souci dû au clonage de cette colonne NIVS quand on a de nombreux domaines de sécurité (donc beaucoup de colonnes clonées à droite de cette colonne NIVS).
  

Pour aligner ce traitement sur ce qui a été fait dans la nouvelle procédures d'export des factures d'achat réglées, 2 améliorations ont été apportées :
 - Ce traitement fait désormais l'objet d'une mise à jour dans l'historique commun (comme les clôtures d'exercice par exemple,
   historique qu'on retrouve dans le fichier \Historiques\Historique Société XXX.log.
   C'est notamment intéressant quand ce traitement est automatisé via une tâche planifiée.
 - Dans le cas d'un export en format CSV, on peut choisir le délimiteur des zones textes. Par défaut, c'est le guillemet, comme auparavant.
   Mais on peut choisir un autre délimiteur, via le mot-clé TxtSep dans le fichier de définition du format d'export.
   Si on ne veut aucun délimiteur pour les zones textes, il faut indiquer TxtSep=NULL.

La procédure de retraitement des écritures analytiques (menu Outils/Vérification des données) présente désormais un 3ème onglet Importation. A partir de celui-ci, on peut corriger des ventilations analytiques d'écritures de comptabilité générale déjà présentes dans LDCompta, écritures ayant été comptabilisés dans un premier temps avec une ventilation provisoire ou « par défaut ».
Les nouvelles ventilations analytiques doivent être fournies dans un fichier Excel comportant 5 colonnes :
 -  N° écriture en comptabilité générale
 - Code analytique Axe 1 (Section)
 - Code analytique Axe2 (Affaire) - A blanc si axe 2 non utilisé
 - Code analytique Axe 3 (Destination)- A blanc si axe 3 non utilisé
 - Montant ventilé (éventuellement signé si la ligne de ventilation doit avoir un signe débit-crédit inverse de l'écriture de compta générale).
 - Quantité - A zéro si Quantité non utilisée
On peut avoir bien entendu plusieurs lignes successives pour une même écriture, pour traiter le cas des ventilations multiples. Chaque code analytique peut également être celui d'une table de ventilation.
La feuille Excel doit impérativement être triée par N° écriture. Elle doit comporter une première ligne d'en-têtes de colonnes (ligne qui est ignorée). La feuille à traiter doit être la première feuille du classeur, qui peut être au format .xls ou .xlsx.

Le traitement commence par contrôler que les données reçues sont cohérentes :
 - le N° écriture doit exister dans LDCompta
 - Les codes analytiques indiqués doivent être cohérents : renseignées ou pas selon les classes de comptes et de codes analytiques, et si renseignés,
   doivent exister dans les tables de codes analytiques correspondantes
 - le montant de cette écriture en comptabilité générale doit être égal à la somme des ventilations trouvées pour ce N° écriture dans la feuille Excel
  (Attention : la feuille Excel doit impérativement être triée par N° écriture).

Les écritures pour lesquelles la ventilation indiquée ne présente aucune erreur sont effectivement reventilées (effacement de la ventilation antérieure, puis création de la nouvelle ventilation demandée). Pour les autres, une liste des erreurs rencontrées est produite dans un fichier texte portant le même nom que le fichier Excel importé, avec l'extension .txt, au même emplacement que le fichier Excel.

Remarque : si on souhaite préparer la feuille Excel des écritures qui doivent être reventilées, on peut le faire par une extraction par SQL du fichier des écritures analytiques CPAHIS.
Exemple 1 : extraction de toutes les écritures analytiques du journal d'achat sur une période donnée
SELECT cpahis.necr,csec,caff,cdes,
 CASE WHEN cpahis.codc=cpthis.codc THEN cpahis.mont ELSE cpahis.mont*-1 END AS mont, qtue
 FROM cpahis JOIN cpthis ON cpahis.necr=cpthis.necr
 WHERE cpahis.jnal='AC' AND cpahis.date LIKE '201901%' AND nect=0 ORDER BY necr,neca
Exemple 2 : extraction de toutes les écritures analytiques présentes dans une section d'attente avant reventilation
SELECT cpahis.necr,csec,caff,cdes,
 CASE WHEN cpahis.codc=cpthis.codc THEN cpahis.mont ELSE cpahis.mont*-1 END AS mont, qtue
 FROM cpahis JOIN cpthis ON cpahis.necr=cpthis.necr 
 WHERE csec='ATTENTE' AND nect=0 ORDER BY necr,neca
On peut alors corriger les ventilations dans la feuille Excel, puis importer ensuite ce fichier Excel pour reventilation.

L'ouverture d'un dossier fermé provoquait l'ajout partiel des éléments qui servent au blocage des ouvertures de session, ce qui provoquait une erreur de date invalide lorsque d'autres utilisateurs tentaient d'ouvrir une session.

Cela est fait désormais dans les méthodes :
 - Session:Ouvrir, Session:Fermer, Session:Rebloquer
 - Session:InterdictionOuvertureEnCours  :  cela risque de laisser ouvrir une session malgré un blocage d'ouverture de session en cours,
   mais on a fait le choix de privilégier l'ouverture de session dans tous les cas).
 - Session:SuisJeSeul. Cette méthode n'est pas utilisée dans LDCompta (contrairement à LDPaye).

En revanche, aucune interception d'erreur n'est faite lorsqu'on demande explicitement la liste de toutes les sessions ouvertes (fonction appelée depuis le menu Fichier/Sessions ouvertes) ou lorsqu'on veut ajouter un blocage d'ouverture de session.

Lors de l'export Quadra, si aucun préfixe n'est défini pour le libellé (N° de pièce ou référence, en position 117), le libellé des écritures était renseigné, pour toutes les écritures, avec le libellé de la 1ère ligne exportée.

Correction d'une erreur lors de la réédition des règlements fournisseurs envoyés par mail : lors de l'impression d'un ensemble de règlements fournisseurs, si à un moment donné, il y a une erreur d'impression (quelle qu'en soit la cause), aucune erreur n'était remontée et les documents suivants se retrouvaient décalés. On envoyait alors par mail à certains fournisseurs un bordereau de règlement PDF qui ne les concernait pas.
Pour éviter cela, le nom du fichier PDF créé pour chaque bordereau de paiement fournisseur inclue désormais le numéro de bordereau en question. De plus, en cas d'erreur d'impression, un message d'erreur est affiché à l'utilisateur lui signalant l'anomalie. Le fichier PDF est supprimé si l'envoi du mail aboutit sans erreur.

Il y avait un bug quelque peu aléatoire qui survenait lors de l'impression des états de rapprochement bancaire, si entre deux rapprochements on changeait une écriture d'un compte de banque à un autre. Pour éviter ce problème, on efface désormais systématiquement, après chaque état de rapprochement, l'ensemble des écritures non rapprochées du fichier de travail concerné (fichier CPTRBD, écritures de type C=Comptable).

Lors de l'impression des lettres de relance, si l'on a choisi de ne pas imprimer les N° de téléphone, fax et mail du client, on comble désormais les lignes laissées vides en remontant les champs situés en dessous de ces informations. On peut ainsi imprimer potentiellement 2 lignes supplémentaires dans le corps de la lettre ou du relevé.
Cela est fait tant sur les lettres de relance que sur les relevés de compte client.

Une nouvelle procédure de pré-traitement d'interface a été développée, afin de pouvoir intégrer des règlements clients reçus au format CSV depuis la plateforme de paiement PAYBOX (fichier provenant d'un site commerce électronique).
Cette procédure convertit ces fichiers CSV PAYBOX au format standard « texte à colonage fixe » de LDCompta. Cette procédure est décrite en détail dans la documentation intitulée IntPAYBOX.doc.

Dans la fenêtre de préparation du fichier de remises de LCR au format CFONB, de nouvelles options de remplacement au sein du nom de fichier ont été ajoutées, de telle sorte que celles-ci soient les mêmes que lors de la préparation du fichier de virements fournisseurs.
On dispose donc désormais des options suivantes pour personnaliser le nom du fichier :
     - % : Code société
     - $$ : Code journal
     - £££££ : Code banque
     - JJ, MM, AA, AAAA : Partie de la date du jour (Nouveau)
     - ° (caractère « degré », à droite du zéro sur le clavier) : N° du bordereau de remise en banque. (Nouveau)
        Le nombre de caractères ° indiqué fixe la taille du nombre, qui est donc complété si besoin avec des 0 à gauche.

Après création d'une nouvelle société, les modes de paiement de type Virement SEPA étaient marqués à tort en type Autre. Cela était dû à la correction V9.00 niveau 309 qui a implémenté le nouveau type Virement SEPA : une modification du type s'exécutait à tort à la première ouverture de la nouvelle société.
Conséquence : en cas de migration d'un dossier comptable sauvegardé en version 9.00 avec un niveau antérieur au niveau 309 (donc antérieur à février 2011), cette modification ne sera pas faite.

Cette nouvelle correction fait suite à la correction 449 relative à l'optimisation des lignes vides dans l'entête des relances client. Désormais, il n'y a plus ce problème de chevauchement des écritures lors de l'impression de plusieurs pages successives.

Cette nouvelle correction fait suite aux corrections 439, 441 et 444 relatives à la gestion des sessions ouvertes, qui n'avaient pas complètement réglé le problème.
Désormais, dans la méthode Session:Ouvrir, en cas d'erreur survenant lors de l'ajout de l'enregistrement dans le fichier LDSESTMP, on teste explicitement s'il s'agit d'une erreur de blocage.
En effet, en l'absence de ce test explicite, on a un plantage lors du prochain ordre HyperFile exécuté. Le fait d'avoir intercepté l'erreur sur l'ajout d'enregistrement ne suffit pas à éviter cela.
Complément technique : en théorie, le fichier LDSESTMP n'étant jamais bloqué en totalité, on ne devrait pas avoir d'erreur de blocage sur un ajout d'enregistrement. Mais cela semble arriver toutefois, sans doute quand ce fichier contient un grand nombre d'enregistrements verrouillés (plus d'une centaine).

La fenêtre de pré-traitement des fichiers d'exports DGI pour les convertir en fichier d'interface lisait le fichier en ANSI. Il est désormais possible de le lire en UTF8.
Egalement, les paramètres de la fenêtre ont été rendus optionnels pour qu'elle puisse être appelée directement, sans passer par la procédure d'interface.

La mention SOLDE DU qui apparaît en bas du relevé de compte (bouton Imprimer compte depuis la fenêtre d'interrogation du compte) est désormais remplacé par SOLDE (sans la mention DU donc) si le solde imprimé est nul, ou par SOLDE (Créditeur) si le solde est créditeur. 

La lecture du fichier à intégrer, au format MT940, pouvait être interrompue si les informations enregistrées sur les lignes (commentaires, etc.) contiennent des éléments du type ":99:", ou ":99X:" (où 99 correspond à 2 chiffres, et X correspond à une lettre, le tout entre des ":") sans être en début de ligne.

Il est désormais possible de définir une répartition du code analytique reçu dans le fichier PNM, dans 1, 2, ou 3 axes analytiques parmi ceux attendu dans le fichier au format LDCompta. Cette répartition est à définir sur l'onglet Analytique de la fenêtre de pré-traitement IPNMFAC. Si le mode de répartition n'est pas défini, la valeur analytique est envoyée entièrement dans le 1er axe (comme avant).

La zone correspondant au 3ème axe analytique était manquante dans la procédure qui permet de gérer certains (pré-)traitements d'interface. Cela pouvait problème notamment lors de l'enregistrement d'une écriture en XML, au format d'interface standard.

Dans la procédure permettant d'importer des données depuis un fichier au format FEC DGFiP, deux modifications ont été apportées :
 1) la possibilité de conserver les codes lettrage reçus dans le FEC
      (par défaut jusqu'alors, ils étaient systématiquement réattribués)
 2) Le N° de pièce, lorsqu'il est reçu à la valeur NonDispo, est remplacé par la date de l'écriture au format AAAAMMJJ.

La procédure de reprise de données depuis une comptabilité Quadra, qui existait déjà, a été améliorée, notamment sur les points suivants :
 - Reprise des comptes de tiers : là où l'on ne reprenait qu'un libellé, on reprend désormais aussi les adresses, N° téléphone, SIRET,
   mode et délai de paiement, IBAN...
 - Pour les comptes généraux, on peut choisir de tronquer les N° de compte à 6 ou 7 chiffres.
 - Pour les comptes de tiers, on peut paramétrer quelle partie du N° de tiers est reprise dans LDCompta, avec éventuellement
   ajout d'un préfixe ou suffixe.
 - Certains comptes généraux peuvent être repris en tant que comptes auxiliaires
 - Pour les écritures, il est désormais possible de reprendre les ventilations analytiques, sur 2 axes (Centre et Nature de Quadra).
Remarque : cette procédure se base sur l'export au format ASCII qui est proposé dans Quadra Compta (menu Utilitaires/Suivi des dossiers).
Lors de cet export, il faut prendre garde à ne pas cocher l'option Remise à zéro des lettrages, et ne faire aucune sélection de date de façon à ce que toutes les écritures présentes dans le dossier comptable soient exportées, y compris les à nouveaux sur les comptes de tiers qui ont une date antérieure au début de l'exercice.

Lors de la saisie d'un règlement fournisseur, il y a systématiquement ajout d'une ou plusieurs échéances dans l'échéancier fournisseurs, correspondant :
 - soit aux différentes factures lettrées dans le compte, auquel cas les échéances sont créées avec un état "déjà réglé"
 - soit, en l'absence de lettrage ou en présence d'un lettrage partiel, pour le montant du règlement ou du solde du lettrage partiel,
   avec dans ce cas un état "à payer". L'objectif est que le règlement saisi ici (ou le solde laissé par ce règlement) soit déduit d'un prochain règlement automatique.
Dans ces deux cas, l'échéance ajoutée dans l'échéancier est en tout point identique au règlement saisi (journal, date, N° facture, Libellé, Montant...).
Sauf pour la référence du règlement (le N° de chèque bien souvent, dans le cas d'un règlement par chèque), qui n'était pas inscrite dans l'échéancier.
Et cette absence de référence posait problème ensuite, quand on allait apporter une modification à l'échéance en question dans l'échéancier (et même d'ailleurs si sortait de la ligne sans avoir rien modifié). Il y a en effet à ce moment-là un report automatique des données de l'échéancier dans le compte du fournisseur. Et ce report concerne 4 zones : la date d'échéance (c'est l'objet principal de ce report, pour que la date d'échéance figurant dans le compte fournisseur soit en phase avec celle de l'échéancier), mais aussi la date de facture, la référence, et le code trésorerie.
Et comme la référence n'était pas renseignée lors de la création de l'échéancier, la modification de l'échéance reportait la valeur "blanc" dans le compte fournisseur, effaçant la référence qu'il y avait bien initialement, suite à la saisie du règlement.
Désormais, l'échéance est créée dès la saisie du règlement avec la bonne référence, évitant ainsi ce problème.

La procédure de pré-traitement d'interface développée récemment (voir correction 450) pour intégrer des règlements clients reçus au format CSV depuis la plateforme de paiement PAYBOX (fichier provenant d'un site commerce électronique) a fait l'objet d'une correction : jusqu'alors, la date était prise en colonne G. Elle est désormais prise en colonne J.
Au passage, on a rendu possible le paramétrage des colonnes extraites pour les informations Site, Marque, Date, Libellé, Sens, Montant, pour le cas où le fichier CSV évoluerait quant à son colonage. Par défaut, ces informations sont extraites respectivement en colonne C, E, J, M, O et R. Mais on peut spécifier d'autres colonnes, en allant indiquer une chaine de 6 caractères en position 101 à 106 du paramètre programme PAYBOX, chacune de ces 6 positions donnant la lettre de la colonne à extraire. Si on n'a rien indiqué sur ces positions 101 à 106, tout se passe comme si on avait renseigné les lettres CEJMOR. 

Ajout des tables de conversion sur les natures de pièce et les modes de paiement. Et possibilité de reprise des journaux inexistants.

Un contrôle de la validité du nom de fichier choisi lors de la numérisation d'un document a été ajouté (validité au sens Windows, c'est à dire qu'on interdit certains caractères spéciaux).
De plus, lors de l'ajout d'un document dans la GED, on vérifie que le fichier à ajouter existe, preuve que la numérisation a été à son terme, afin d'éviter de créer un document GED qui pointe sur un fichier inexistant.

Dans la Fiche société, une option permet de créer une action de relance pour chaque lettre de relance imprimée, et dans ce cas, la lettre de relance est également placée dans la GED pour être accessible soit depuis l'action de relance, soit depuis la fiche du client.
Dans ce processus de création de l'action de relance, on commençait pas constituer la lettre de relance en PDF dans le répertoire des sous-répertoires (en principe, X:\Ldsystem\Fichiers\Compta), puis on ajoutait ce fichier PDF dans la GED. Et à ce moment-là, plutôt que de déplacer le fichier PDF venant d'être créé dans le sous-répertoire GED correspondant (X:\Ldsystem\Fichiers\Compta\Documents\Clients\...), on en faisait une copie. De ce fait, on conservait à tort toutes les lettres de relances en PDF dans le répertoire des sous-répertoires, alors qu'on les avait par ailleurs dans les sous-répertoires de la GED.

La procédure spécifique de prétraitement d'un fichier d'interface pour les besoins de la consolidation a été légèrement modifiée, pour se caler sur un nouveau format de fichier Excel en entrée :
 - une seule ligne d'en-tête au lieu de 2 auparavant
 - plus de colonne B (colonne 2) à ignorer : elle a été supprimée.

Dans les différentes procédures de consultation (compte, journal...), quand on exportait le contenu de la table affichée vers Excel, les montants apparaissant dans certaines colonnes (toutes les colonnes où l'on a fait le choix de ne pas afficher les valeurs nulles, dont entre autres les colonnes Débit et Crédit) ne pouvaient pas être référencés par une formule de calcul. La formule renvoyait #VALEUR.
Pour que ça fonctionne, il fallait sélectionner toutes les cellules vides dans ces colonnes, puis les effacer. Tout se passait comme si ces cellules pourtant vides contenaient quand même un caractère spécial qu'on ne pouvait voir, mais qui empêchait les calculs de fonctionner normalement.
Pour régler ce souci, dans les fenêtres de consultation de LDCompta, on a ajouté l'option Null si vide pour toutes les colonnes ayant l'option Mise à blanc si zéro. Et curieusement, avec ça, ça fonctionne !
Petite différence notable : pour LDCompta V10 qui est en Windev 18, dans la feuille Excel exportée, les valeurs à zéro apparaissent. Alors qu'à partir de Windev 22 (LDPaye V9.60, LDCompta V11...), les valeurs à zéro n'apparaissent pas : les cellules sont effectivement vides dans ce cas.

A l'ouverture de session, la fenêtre de confirmation qui s'affiche lorsque les journaux ne sont pas clôturés depuis X mois pouvait s'afficher derrière la fenêtre d'ouverture de session. Ce qui fait qu'elle n'apparaissait pas à l'utilisateur, qui croyait alors que l'application était figée. Désormais, la fenêtre d'ouverture de session n'est plus placée devant les autres applications, et se comporte donc comme les autres fenêtres.

Lorsqu'on interroge un compte en mode multi-collectifs, c'est à dire en utilisant le code racine dédié au multi-collectif client ou fournisseur, le système affiche toutes les écritures du tiers, tous collectifs confondus.
Dans ce mode, l'accès au lettrage du compte, mais aussi à l'échéancier fournisseur, à l'impression du grand-livre ou du relevé n'étaient pas possibles, car toutes ces fonctions n'admettent pas de travailler en mode multi-collectifs.
Désormais, on a accès à ces fonctions, pour le tiers courant bien sûr, et pour le collectif correspondant à l'écriture courante sur l'écran de consultation du compte.

Dans certaines configurations, la gestion des sessions ouvertes peut provoquer des crashs aléatoires.
Sachant que ce mécanisme de gestion des sessions ouvertes n'est pas indispensable au bon fonctionnement du logiciel, on a ajouté, pour un usage transitoire dans l'attente d'une solution pérenne, la possibilité de désactiver complètement tout ce mécanisme.
Pour cela, il faut créer un fichier nommé LDSESTMP.INI dans le répertoire des mises à jour centralisées (là où se trouve déjà le fichier LDSESTMP.FIC) et renseigner les 2 lignes ci-dessous :
[LDCompta]
Désactivé=1

Dès lors que le mécanisme est désactivé, on n'a plus accès à l'option de menu Fichier/Sessions actives. Et de ce fait, on ne peut plus bloquer des ouvertures de session dans une plage horaire donnée.

Quand on modifie une date de facture, une date d'échéance, un code trésorerie ou une référence document dans l'échéancier fournisseur, le système tente de reporter ces modifications sur l'écriture comptable correspondante dans le compte fournisseur.
Pour ce faire, il recherche une écriture dans le compte fournisseur concerné ayant le même N° de facture (N° de pièce dans le compte),
le même montant et sens, la même échéance. Et il reporte les modifications sur la dernière écriture trouvée correspondant à ces critères, sachant qu'en principe, il n'en trouve qu'une.
Ce mode de report posait problème quand il n'y a pas unicité des factures sur le N° de facture (N° de pièce). Dans ce cas, si on a deux factures distinctes (ou plus) dans le même compte fournisseur, portant le même N° de pièce, le même montant et sens et la même date d'échéance, les modifications apportées dans l'échéancier ne se reportaient pas sur la bonne écriture dans le compte fournisseur.
Pour y remédier, les règles de report ont été ajustées :
 - pour rechercher l'écriture sur laquelle il faut reporter les modifications, on a ajouté un critère de recherche supplémentaire :
   la référence document. Ainsi, parmi toutes les écritures correspondant aux critères de recherches déjà évoqués plus haut,
   on retient en priorité celle ayant la référence document que l'on avait dans l'échéancier avant modification. 
   Sachant que cette référence document contient en principe le N° de facture du fournisseur, il y a de bonnes chances d'avoir
   unicité de l'écriture en ajoutant ce critère de filtrage.
 - enfin, la référence document présente dans l'échéancier après modification de la ligne n'est reportée dans le compte fournisseur
   que si on a trouvé une écriture correspondant à la référence avant modification. Si l'écriture trouvée ne correspond pas à cette
   référence, la nouvelle référence présente dans l'échéancier n'est pas reportée dans le compte fournisseur. Seuls les autres champs
   Date de facture, Date d'échéance, Code trésorerie le sont.

Lors d'un lettrage à la volée (depuis la saisie par pièce ou la saisie d'un règlement client par exemple), pour une pièce saisie en Euros, avec lettrage en contrepartie d'une ou plusieurs écritures en devises, il y avait passation d'une différence de change injustifiée. Les écritures lettrées en devises étaient converties en euros au cours du jour (dernier cours défini dans la table des devises) alors qu'il fallait prendre leur montant en euros tel qu'il était déjà enregistré, c'est à dire au cours utilisé lors de leur saisie.
Et au final, s'il y a une différence entre la somme des contre-valeurs en euros des écritures lettrées et le montant du règlement en euros, il s'agit d'une différence de règlement et non d'une différence de change, que l'on traite alors de façon classique (OD automatique de différence).

Une modification de même nature a été faite lors d'un lettrage à la volée pour une pièce en devise, avec lettrage en contrepartie d'écritures dans une devise autre que celle de la pièce saisie et autre que la devise de référence (l'Euro) (il s'agit d'un cas d'usage rarissime). Dans ce cas, les écritures lettrées en contrepartie sont désormais converties dans la devise de référence à partir de leur montant déjà enregistré en devise de référence, en utilisant le cours de la pièce en cours de saisie. Auparavant, on repartait du montant devise de la pièce déjà enregistrée en le convertissant dans un premier temps en euros (via le cours indiqué dans une fenêtre qui était proposée à la volée en saisie d'un règlement client ou fournisseur, via le dernier cours connu dans la table des devises en saisie par pièce), puis dans un second temps en convertissant ce montant Euros dans la devise de la pièce en cours de saisie. Cette double conversion pouvait provoquer là-aussi une différence de change inappropriée.

Deux corrections ont été apportées dans la gestion des immobilisations :

1. Quand on cliquait sur le bouton Consulter les sorties, donnant accès à la gestion des sorties d'immobilisations, au retour de cette fenêtre de gestion des sorties, on ne rechargeait pas la liste des immobilisations sur l'écran principal. Or, dans la fenêtre de gestion des sorties, on peut avoir par exemple supprimé une sortie d'immobilisation, ce qui doit être répercuté sur l'écran principal où les immobilisations sorties apparaissent grisées.
   De plus, le fait de ne pas avoir rechargé cette liste pouvait provoquer une erreur plus grave, avec une discordance entre la quantité sortie enregistrée dans la Fiche immobilisation (fichier IMOIMO, rubrique QCES) et les sorties réellement liées à cette immobilisation dans le fichier des sorties (fichier IMOCES).
2. Lié à ce non rechargement, un autre problème pouvait se poser également ensuite. L'enregistrement courant dans le fichier des Immobilisations correspondait à celui affiché dans la fenêtre de gestion de sorties et non plus à celui affiché dans la table de la fenêtre principale de gestion des immobilisations. Du coup, si on cliquait sur le bouton Enregistrer une sortie, le système tentait de saisir une sortie sur l'enregistrement courant du fichier, et non celui affiché dans la table.

Quand on ajoutait une échéance depuis l'écran de consultation d'un compte fournisseur, via le menu contextuel obtenu par un clic droit sur une facture, l'échéance était toujours ajoutée au débit dans l'échéancier, sans tenir compte du sens Débit-Crédit de l'écriture de départ.
Ce problème se produisait depuis début septembre 2020, faisant suite à la correction 485, qui modifiait la façon dont étaient gérées les valeurs à zéro dans les colonnes Débit-Crédit de la procédure de consultation de compte, pour régler un souci en cas d'export vers Excel (Valeurs Zéro remplacées par Null).

Pour pouvoir traiter le cas de l'export des factures d'achat réglées pour Yooz, qui attend cela dans un format XML propriétaire, on a ajouté la possibilité d'exécuter une procédure compilée dynamiquement tout à la fin du traitement d'export des factures d'achat réglées.
Le nom du fichier contenant le source de la procédure doit être indiqué en position 385 à 512 du paramètre programme IEXPFAAC.
La procédure reçoit en paramètre le nom du fichier d'export. Elle peut ainsi modifier le contenu de ce fichier à loisir.
En parallèle, on a écrit le code de la procédure permettant de passer d'un format CSV au format XML attendu par Yooz. Cela se trouve dans le dossier ...\LD SYSTEME\Clients - Documents\SADEL\Export LDCompta pour Yooz.

Au passage, on a corrigé une anomalie dans cette procédure d'export des factures d'achat réglées, ainsi que dans la procédure d'export des factures de ventes réglées. On traite désormais correctement le cas des fichiers de type « texte avec séparateur Tabulation ». Auparavant, le séparateur TAB, lorsqu'il était porté dans le fichier de description .FDF en tant que séparateur de colonne, n'était pas traité correctement. On se retrouvait avec un fichier d'export ayant le caractère T comme séparateur de colonne !

Une nouvelle procédure de pré-traitement d'interface, pouvant donc être intercalée juste en amont de la procédure d'interface standard, a été développée. Elle est conçue pour corriger un fichier contenant les factures d'achat provenant de Yooz.
La modification consiste simplement à permuter les colonnes NPIE et TXTL (colonnes 4 et 34) et à compléter la zone N° de pièce à 7 chiffres.
Le fichier à traiter doit être au format standard CSV séparateur Point-virgule de LDCompta V10.

Une fenêtre de prétraitement a été conçue pour convertir « à la volée » un fichier d'interface reçu au format ADP Decidium (format CSV) dans le format natif LDCompta (format texte à colonage fixe V10 ou  CSV V10, selon l'extension choisie pour le fichier en sortie).
Deux options présentes dans la fenêtre de lancement permettent d'indiquer si on doit ignorer la première ligne du fichier CSV (ligne d'en-têtes de colonnes) et ce que l'on doit faire quand dans le fichier d'origine, une ligne comporte à la fois un montant au débit et un montant au crédit : comptabilisation de 2 écritures, l'une au débit et l'autre au crédit, ou comptabilisation d'une seule écriture pour le solde Débit-Crédit.
Dans le paramètre programme nommé ADP-DECID, on doit renseigner le mode de découpage à réaliser de la colonne H-Numéro d'imputation présente dans le fichier d'origine en 1, 2 ou 3 axes analytiques Section, Affaire, Destination de LDCompta :
 - en position 1-2 et 3-4, on indique les positions début et fin pour le code section
 - en position 5-6 et 7-8, on indique les positions début et fin pour le code affaire
 - en position 9-10 et 11-12, on indique les positions début et fin pour le code destination
Ainsi, si on reçoit une ventilation de la forme SSSSAA (code section sur 4 caractères, code affaire sur 2 caractères, pas de code destination), on indiquera 010405060000.
Dans ce même paramètre programme, en position 13 à 18, on peut indiquer une chaine de caractère qui sera utilisée comme préfixe pour le N° de pièce attribué automatique à l'écriture de paye. Le N° de pièce sera constitué de ce préfixe, en y ajoutant l'année et le mois issu de la date (format AAMM) et du code établissement (information fournie en colonne 1).
On peut aussi forcer l'utilisation du format de sortie : CSV ou « texte à colonage fixe », en indiquant CSV ou TXT en position 19 à 21 de ce paramètre. Pour toute autre valeur renseignée en position 19 à 21, le système se base sur l'extension indiquée dans le nom du fichier en sortie : CSV si extension .csv, texte à colonage fixe pour toutes les autres extensions de fichier.

Une fenêtre de pré-traitement a été conçue pour extraire les données du logiciel de gestion commerciale en ligne Evoliz.com, via l'API du site. Le fichier généré est au format V10 en XML. Les clés publique et secrète à utiliser pour l'API, ainsi que les tables de correspondance (facultative) des comptes généraux et des journaux sont à renseigner dans le paramètre programme EVOLIZ.
Attention : pour fonctionner en V10, une conversion des valeurs JSON en XML est nécessaire, et se fait par le biais de l'outil JSONVersXML.exe qui doit être présent dans le répertoire de l'exécutable de LDCompta.

Une nouvelle procédure de prétraitement d'interface a été créée, pour retraiter un fichier provenant de la paye SYLAE.
Le prétraitement consiste juste à remplacer certains numéros de comptes généraux, en s'appuyant sur une table de correspondance.
Le fichier à traiter est supposé être au format standard « texte à colonage fixe » de LDCompta Version 9.
Pour définir la table de correspondance des comptes, il faut créer un paramètre programme nommé ISYLAE ainsi :
 - Position 1 : définit le type d'écritures pour lequel on désire appliquer le changement des numéros de comptes généraux
   On peut renseigner la valeur E, la valeur A ou laisser cette position à blanc. Dans ce dernier cas, le changement sera opéré
   à la fois sur les écritures de comptabilité générale (type E) et les OD de ventilations analytiques (type A).
 - Positions 11 à 64 : liste des sections analytiques pour lesquelles il ne faut pas opérer de conversion du N° de compte général
   (ajouté via la correction 515)
 - à partir de la position 16 et jusqu'à la fin de la valeur alphanumérique du paramètre programme, on renseigne la table de correspondance
   sous la forme XXX:YYY;XXX:YYY;... où XXX est le N° de compte à remplacer et YYY est le N° de compte de remplacement.

Suite à la correction 510, il y avait un dysfonctionnement de la procédure d'interface, lorsqu'on avait une fenêtre de prétraitement.
Au retour de la fenêtre de prétraitement, il n'y avait pas enchaînement automatique sur le traitement de contrôle et validation. Et si on cliquait à nouveau sur le bouton OK, cela relançait le prétraitement.
Pour corriger cela, il a fallu forcer un code retour égal à OK dans toutes les fenêtres de prétraitement qui ne retournaient pas explicitement une valeur quand tout se passait bien, ce qui retournait implicitement une valeur Annuler, comme si on avait cliqué sur le bouton Annuler de la fenêtre de prétraitement. Auparavant, le fait que la fenêtre de prétraitement ne retournait rien n'était pas gênant car on revenait sur la fenêtre de traitement qu'on devait valider par OK. Désormais, on passe une première fois par la fenêtre d'interface, on valide par OK, ce qui ouvre la fenêtre de prétraitement. Et au retour de la fenêtre de prétraitement, on est donc censé enchaîner automatiquement le contrôle et la validation du fichier d'interface, si le prétraitement s'est bien passé. 

D'autre part, on a revu aussi l'ergonomie de la fenêtre de lancement de l'interface, car on était tenté, en cas de prétraitement, de sélectionner dès cette première fenêtre le fichier « original » à importer, alors que s'il y a un prétraitement, le fichier affiché ici est le fichier résultant du prétraitement. Il ne faut donc pas le toucher : c'est dans la fenêtre de prétraitement qu'on choisit le fichier « original » à importer et le fichier final, celui résultant du prétraitement qui va ensuite être contrôlé et validé.
Désormais, s'il y a une fenêtre de prétraitement, le fichier à importer ne peut donc pas être modifié dans la première fenêtre d'interface : le champ est grisé.

Ajout de la possibilité de ne pas convertir le N° de compte des écritures dont le code section analytique est dans une liste de valeurs données.
Cette liste doit être portée dans le paramètre programme ISYLAE, entre le caractère 11 et le caractère 64.

Sur des dossiers comptables comportant un grand nombre d'écritures avec de très gros montants (plus de 1 milliard), notamment sur les à nouveaux, il pouvait arriver que la procédure de contrôle de l'équilibre des lots signale un déséquilibre alors qu'il n'y en avait pas.
Complément d'information technique : quand le système additionne les écritures lot par lot, il y avait un problème de précision (à cause de l’éternel problème de précision des variables déclarées en « réel » sous Windows), et ce bien que les zones de totalisation soient déclarées en type « monétaire » (donc un type offrant une plus grande précision) plutôt qu’en type « réel ». Mais cela ne suffisait pas, même si la documentation de Windev dit que lorsqu’on a une opération entre un type monétaire et un type réel, la variable déclarée en réel est automatiquement convertie en monétaire.
Pour faire disparaître ce problème, on a donc chargé explicitement le montant de l’écriture dans une variable intermédiaire déclarée en type monétaire avant d'additionner cette variable monétaire dans le total déclaré lui-aussi en monétaire. Et ainsi, on n’a pas de perte de précision, et le total du lot se retrouve bien à zéro.

Dans la fenêtre qui présente le détail d'un lot de virements fournisseurs, on visualise désormais en partie basse la liste des factures réglées pour le virement sélectionné en partie haute de l'écran. Pour chaque facture réglée, on retrouve les informations telles qu'on les voit dans l'échéancier avant paiement : Journal, Date, N° de pièce, Référence, Libellé, Montant. On peut également accéder à la facture présente dans la GED le cas échéant (comme cela est possible en consultation du compte fournisseur par exemple).

Lors de la création d'une nouvelle société avec demande de copie d'une partie du paramétrage depuis une autre société, si le fichier client et/ou le fichier fournisseur étaient copiés, les données « Coordonnées bancaires internationales » de ces clients et/ou fournisseurs n'étaient pas copiées.