Projet créé le 03/03/2009

Toutes les corrections jusqu'au niveau 331 de LDCompta V8.50 ont été reportées.

Le message d'aide sur l'écran de saisie des paramètres de la déclaration des honoraires, pour ce qui est des codes des journaux d'achat, était erroné.

Il est désormais possible d'effectuer un import de données venant de API.

Cependant, l'interface est limité au format XML, il faut donc impérativement choisir le format INTCPTV9_XML.fdf (ou un dérivé qui définit le format XML).

L'automate accepte désormais un nouveau paramètre dans les règles, permettant de spécifier le fichier de description du fichier à intégrer. On peut ainsi avoir différents formats de fichier en entrée, selon la règle utilisée.

Par exemple, une règle permettant d'interfacer un fichier de paye, qui sera au format standard LDCompta Version 9, et une autre règle permettant d'interfacer un fichier de factures, qui sera encore au format LDCompta Version 8.

Pour cela, dans la section définissant une règle, il suffit de préciser le nom du fichier de description (celui portant l'extension .fdf) au mot-clé FICHIER_DESCRIPTION.

Ce nouveau mot-clé FICHIER_DESCRIPTION est facultatif ; lorsqu'il n'est pas précisé, l'interface est exécutée avec le fichier de description par défaut spécifié dans la fenêtre d'interface, c'est à dire celui enregistré lors de la dernière interface lancé "manuellement" par l'option de menu Outils/Interface avec autres applications.

Si on renseigne ce mot-clé, on peut indiquer soit simplement un nom de fichier (par exemple : INTCPTV8.FDF), soit un nom complet avec le répertoire. Si le répertoire n'est pas précisé, le fichier indiqué doit être présent dans le répertoire des programmes de LDCompta Version 9.

Signalons également que LDCompta Version 9 est livré en standard avec 4 fichiers de description de format :

- intcpt.fdfFormat TXT Version 9

- intcptV8.fdfFormat TXT Version 8

- intcpt_CSV.fdfFormat CSV Version 9

- intcpt_XML.fdfFormat XML Version 9

Exemple de règle :

[REGLE001]

LIBELLE=Paye en XML

REPSOURCE=C:\Ldsystem\Fichiers\Compta\SOC_LDZ

NOMSOURCE=int*.xml

SOCCIBLE=LDZ

REPCIBLE=C:\Ldsystem\Fichiers\Compta\Interfaces\Fichiers traités

FILTRE_SOCIETE=LDZ

FILTRE_UTILISATEUR=

FILTRE_MOTSCLES=PAYE

AFFICHER_FENETRE=O

FICHIER_DESCRIPTION=Intcpt_Xml.fdf

TRAITEMENT=2

FENETRE_PRETRAITEMENT=

AFFICHER_ENREGISTREMENTS=O

IMPRIMER_LISTE_CONTROLE=N

La procédure permettant de soumettre l'interface standard en "batch" sur le serveur IBM AS/400 a été modifiée pour tenir compte à la fois de la présence d'enregistrements dans les fichiers CPTHIY et CPTRGY (fichiers de la version 8), mais aussi des fichiers CPTHIZ et CPTRGZ (fichiers de la version 9).

En cas d'utilisation de LDCompta avec l'option d'affichage "Grandes polices" de Windows, certaines zones étaient mal cadrées au bas des écrans de lettrage et délettrage, lors des repositionnements dynamiques de champs selon que les totaux en devise étaient affichés ou pas.

Une nouvelle colonne a été ajoutée à l'état présentant le détail des honoraires. Cette nouvelle colonne Lp indique que la facture en question a été lettrée partiellement. Ces factures lettrées partiellement sont ignorées sur la déclaration DAS2 ; seules les factures lettrées "entièrement" sont considérées comme réglées, et donc prises en compte sur la déclaration (compte tenu de la date du règlement bien sûr).

Cette nouvelle colonne met donc en évidence ces lettrages partiels, pour mieux se vérifier au moment de la déclaration.

En modification de pièce, l'ouverture de la fenêtre pouvait dans certains cas nécessiter plusieurs minutes, en raison des contrôles effectués en version 9 pour déterminer ce qui est modifiable dans la pièce. Ce traitement a été optimisé afin que la fenêtre s'affiche quasi instantanément.

Si des codes sections analytique étaient définis sur un seul caractère dans LDCompta V8.50, cela posait problème en version 9 après migration.

Un outil a été intégré dans la procédure de migration automatique des données de la version 8 à la version 9. Cet outil n'apparait que s'il détecte cette situation : présence d'un ou plusieurs codes à un seul caractère dans la table des sections analytiques. On doit alors indiquer, pour chacun des codes section concernés, un nouveau code à 2 caractères. Et l'outil répercute cette modification de code section au sein de toutes les tables concernées dans le dossier comptable, avant d'enchainer sur la migration Version 9 proprement dit.

Dans la procédure de rapprochement bancaire, le bouton "Créer écriture extra comptable" ne fonctionnait pas correctement si une sélection des écritures était active (par exemple, sélection des seules écritures non rapprochées).

La présentation des relevés clients a été légèrement revue pour pouvoir y faire figurer des N° de pièce à 10 caractères (la colonne où s'imprimait le N° de pièce était jusqu'ici limitée à 7 caractères).

De nombreuses fenêtres ont été modifiées dans LDCompta pour pouvoir s'adapter à un affichage avec grandes polices. Certains boutons n'étaient en effet pas adaptés à cet affichage et on pouvait constater des différences de tailles entre les différents libellés des boutons.

En interrogation d'un journal, lorsque le module Devises était inactif, il y avait un problème d'affichage des champs Libellé compte et Raison sociale figurant en partie haute, à droite des zones de sélection des comptes.

Si on imprimait une balance avant d'imprimer un grand livre, les tiers suspendus n'étaient pas indiqués comme tels. Ce problème se présentait sur les grands-livres au format vertical. Dorénavant, les tiers suspendus sont signalés correctement.

L'interrogation des exercices antérieurs au sein des procédures de consultation par compte, pièce, référence ou journal, ne fonctionnait pas en environnement Client/Serveur AS/400.

Lors de la fermeture de l'échéancier fournisseur, si le solde d'un compte n'est pas égale au solde de l'échéancier, un message d'avertissement s'affiche.

Ce message ne distinguait pas le type de tiers et affichait tout le temps le libellé fournisseur. De plus, pour les tiers qui n'étaient pas de type fournisseur, le nom n'était pas affiché.

Dorénavant, le libellé indique si c'est un client, un fournisseur ou un autre auxiliaire et dans ce dernier cas, précise aussi le nom du collectif.

Dans certains cas très rares, on pouvait rencontrer une erreur de doublon si l'on créait ou modifiait un mode de règlement à partir de la fenêtre de mise à jour d'un journal.

Quelques modifications d'ergonomie ont été apportées :

- sur les écrans de lettrage et de délettrage, de rapprochement bancaire, de l'échéancier fournisseur et de saisie des règlements fournisseur, toutes les dates sont désormais centrées dans leur colonne respective ;

- sur ces mêmes fenêtres, la disposition des colonnes est enregistrée systématiquement ;

- dans la fenêtre de rapprochement bancaire, une colonne a été ajoutée pour afficher le mode de paiement ;

- dans la fenêtre de l'échéancier fournisseur, un petit défaut d'affichage sur les libellés des totaux a été corrigé.

L'édition des balances de tiers avait un mauvais rendu. La ville n'était pas affichée correctement et si l'on mettait le curseur au dessus du n° de compte, on constatait que le champ chevauchait le libellé du compte.

Lors de l'édition d'une relance client, le dernier caractère du compte n'était pas visible (cela dépend du poste qui lance l'édition). La zone a été agrandie afin de permettre l'affichage de tous les caractères du compte.

La sélection sur section ne fonctionnait pas correctement dans la balance analytique. Si on faisait une sélection sur une même section, rien n'était listé dans l'état même si des données sur cette section existaient.

Des caractères carrés apparaissaient dans l'état grand livre analytique s'il ne contenait aucune donnée. Désormais, cet état est présenté vide, seul les entêtes de colonnes sont présents.

Si l'on valide un rapprochement à une date donnée mais qu'un précédent rapprochement avait déjà été validé à cette même date, une erreur de doublon était provoquée.

Dorénavant, l'erreur de doublon a été supprimée et le rapprochement validé prend la place du précédent rapprochement validé à la même date.

Dans les différentes procédures de consultation, lorsqu'on appliquait un filtre et que l'on revenait ensuite dessus pour le modifier, l'action et la valeur de comparaison étaient grisées.

Les zones étoilées de l'édition du chiffre d'affaire ne permettait pas la consultation des comptes clients lorsqu'on cliquait dessus.

Dorénavant, on peut consulter le compte :

- En mode multi collectif si les multi-collectifs sont gérés

- En mode simple collectif s'il existe un seul collectif client

- On ne peut pas dans les autres cas, on affiche un message d'erreur

Au lancement de la procédure d'intégration des relevés bancaires, le répertoire des sous-répertoires n'était pas initialisé.

De ce fait, le système ne retrouvait pas les fichiers de configuration (LDCPTRLB.INI et LDCPTRLB.LOG) utilisés antérieurement à la version 9. Et si on reparamétrait ceux-ci, ils étaient enregistrés sur la racine du disque C: (le disque où s'exécutait l'application). Ces fichiers de paramétrage n'étaient donc pas partagés entre tous les postes pouvant mettre en oeuvre l'intégration des relevés bancaires.

ATTENTION : si ce correctif est installé alors que les fichiers de paramétrage ont déjà été saisis en version 9, il faut déplacer les 2 fichiers de paramètres cités ci-dessus depuis la racine du disque C: vers le répertoire des sous-répertoires (par exemple, X:\Ldsystem\Fichiers\Compta, X figurant la lettre correspondant au lecteur réseau sur lequel les données de LDCompta sont enregistrées.)

Au cours d'une interface, si une modification effectuée sur une ligne n'était pas correcte et que l'on revenait sur la fenêtre de correction pour cette même ligne, toutes les lignes suivantes, bien que la correction soit proposée n'étaient pas corrigées et étaient intégrées en l'état dans LDCompta.

Dans la procédure de règlement automatique des fournisseurs, si on n'imprimait pas la liste "Factures et avoirs non traités" (au moins en aperçu avant impression), les avoirs n'étaient pas omis du traitement qui suivait. Et dans certains cas, le système déclenchait des paiements pour des échéances négatives.

Dans certaines tables, la ligne sélectionnée pouvait avoir une couleur de police noire sur un fond bleu, ce qui rendait difficile la lecture. Dorénavant, la couleur est conforme au standard, blanche sur fond bleu.

Plusieurs fenêtres ont été touchées par cette correction.

Le bandeau correspondant au début d'un nouveau compte ne s'imprimait pas correctement sur les grands-livres, mais uniquement dans le cas de l'impression en format horizontal.

Sur la balance générale, lorsqu'on demandait un arrêté à une date donnée plutôt qu'à une fin de mois, le solde calculé pour les comptes collectifs était faux.

Dans la procédure de consultation des comptes, la mise en évidence des factures fournisseurs qui sont en attente du bon à payer ne fonctionnait plus depuis la version 9.

Certaines fonctionnalités de l'interface via le serveur de message pouvaient provoquer une erreur dans l'application. Cela était dû notamment au lettrage automatique des règlements.

La recherche des factures à marquer dans les comptes clients ne fonctionnait plus en version 9 (problème avec les espaces contenus dans le N° de compte reçu dans le fichier texte, alors qu'en version 9, les N° de comptes sont désormais sans espaces dans les fichiers de LDCompta).

Dans la table de saisie des natures de pièce, il y avait un problème de positionnement sur la ligne courante. Quand on cliquait sur le bouton Modifier ou Supprimer, la ligne appelée en modification ou suppression n'était pas toujours la ligne courante, mais bien souvent la première ligne de la table.

En saisie des règlements clients, si on sélectionnait une nature de pièce en cliquant sur le bouton de sélection (plutôt qu'en utilisant la touche de raccourci F4=Liste), la nature de pièce sélectionnée n'était pas conservée quand on passait sur la 2ème fenêtre de saisie du règlement. Le système reprenait la nature de pièce par défaut correspondant au mode de paiement ou au journal de banque.

Sur la liste des clients à relancer triée par représentant, le total par représentant ne totalisait que ce qui se trouvait sur la dernière page imprimée pour ce représentant.

Les totaux de fin d'états étaient quant à eux exacts.

Lorsqu'on saisissait une écriture extra-comptable, elle n'était pas sauvegardée si on retournait sur l'onglet de pointage puis que l'on retournait dessus.

La présentation d'un grand nombre de fenêtres et d'états a été revue pour adapter la taille des champs Code section et Code affaire à la nouvelle longueur maximale possible (en nombre de caractères) en version 9 ( 5+5 pour le code section/sous-section, 9 pour le code affaire).

Notez que sur les fenêtres, il ne s'agit que d'un confort d'affichage : on pouvait déjà saisir des valeurs avec le nombre maximum de caractères autorisé en version 9, mais on ne voyait pas la totalité de ces valeurs (décalage automatique géré par Windows dans le champ de saisie). En revanche sur les états, les valeurs trop longues étaient tronquées.

Remarque : pour régler ce problème de place sur la plupart des états concernés, ce sont les marges qui ont été "rabotées" ; on avait la plupart du temps une marge gauche de 15mm, et une marge de droite de 10 ; on est passé à 10mm à gauche, et 8mm à droite.

Suite à la correction N° 53, il y avait encore un petit souci de présentation sur le grand-livre analytique, lorsqu'on choisissait un tri par Compte/Section. Le code sous-section apparaissant sur les lignes de totalisations intermédiaires était parfois tronqué.

Lorsque l'on effectuait le premier rapprochement bancaire sur un compte, le système ne proposait plus d'effectuer un pré-marquage des écritures. Dorénavant, le pré-marquage est de nouveau en place et est proposé si aucun rapprochement n'a été effectué.

La liste des litiges ne fonctionnait pas en environnement Client/Serveur AS/400.

Détail technique : il s'agissait d'un problème de syntaxe SQL non reconnue par DB/2. Pour concaténer 2 zones en SQL HyperFile, on peut écrire Zone1+Zone2. En SQL DB/2, il faut écrire Zone1 concat Zone2 ou Concat(Zone1, Zone2).

C'est cette dernière syntaxe qui a été retenue finalement, car elle est reconnue à la fois par HyperFile et DB/2.

Dans la fenêtre de saisie d'une différence de change, le compte perte ou profit ne pouvait pas être à plus de 6 caractères. Dorénavant, on peut saisir des comptes à 8 caractères.

Le traitement de transfert des créances douteuses posaient plusieurs problèmes :

- Le journal d'origine des écritures transférées était mouvementé à tord.

- Le numéro de pièce était tout le temps CD00001. Dorénavant, il est possible d'en saisir un sauf si la numérotation est automatique.

- Les XXX dans le libellé n'étaient pas remplacés

- Les informations utilisées dans le contrôle des écritures n'étaient pas correctement mise à jour.

- Le libellé par défaut vient du paramètre programme (idem LDCompta AS/400 Version 8)

- Un total des écritures pointées a été ajouté

- Il est possible d'attribuer un code nature de pièce, pour l'écriture passée au compte origine

- Dans le compte destinataire, le N° de pièce origine est basculé dans la référence document si celle-ci n'était pas renseignée.

...

La suppression d'un effet à payer entrainait une erreur d'équilibrage des lots car l'écriture d'annulation de l'effet n'était pas passée au compte fournisseur. Non seulement l'effet n'était pas supprimé, mais une erreur d'équilibrage était provoquée.

Deux boutons ont été rajoutés dans la fiche société afin de faciliter le contrôle des principaux compteurs de LDCompta. Si le compteur n'est pas valide, le système propose de corriger la valeur automatiquement.

La fenêtre de sélection d'une date ne fonctionnait pas sous Windows 2008 64 bits.

Le système vérifiait que l'on était en environnement 32 bits, mais ce contrôle permettait à l'origine de se protéger des environnements 16 bits ! Ce contrôle a donc été retiré.

De plus, l'objectif de l'appel aux DLL Windows était de récupérer la position de la souris lors du clic dans la fenêtre ; tout le code a donc été remplacé par des appels aux fonctions Windev SourisPosX() et SourisPosY() qui font désormais tout cela très bien et sans souci !

Ce même type de protection a été retiré dans 2 autres fenêtres.

Dans la procédure de lettrage manuel, il est désormais possible de lettrer une seule écriture de façon "isolée" lorsque cette écriture à un montant nul (même si rien dans LDCompta ne permet, en dehors d'une interface, de saisir une écriture avec un montant nul).

Cela permet de lettrer facilement ces factures à zéro pour qu'elles disparaissent lors d'une clôture d'exercice.

Jusqu'alors, pour lettrer celles-ci, il fallait disposer dans le compte d'au moins une autre écriture lettrable ; sans quoi, en ne pointant qu'une seule écriture, le bouton OK restait grisé même si le total lettrage était bien équilibré dans ce cas particulier d'une facture à zéro. On pouvait contourner le problème en cliquant sur les boutons Premier, Dernier, Suivant ou Précédent proposés au bas de la fenêtre, mais cela n'était pas très "naturel". Désormais, le bouton OK est disponible dès lors qu'on a pointé au moins une écriture.

Il restait encore quelques cas où le total Débit-Crédit de la pièce était incohérent par rapport aux lignes saisies pour la pièce.

Cela pouvait se produire en cas d'utilisation des boutons Contrepartie ou Rappeler, combiné avec des effacements de lignes ou de montants.

Pour éviter ces problèmes, après chaque modification de montant (débit, crédit, cours devise), le total de la pièce est désormais recalculé par addition de toutes les lignes de la pièce en cours de saisie.

Auparavant, ce total était mis à jour seulement à partir de la ligne en cours de modification, par soustraction de la valeur avant modification, puis ajout de la valeur après modification. Et l'on pouvait avoir des problèmes avec ces valeurs avant/après modifications selon la façon dont on entrait ou sortait d'un champ en saisie dans la table (touche Tabulation, Curseur vers le Haut ou le Bas, Clic dans un champ de la même ligne ou d'une autre ligne, clic sur un bouton en partie basse). Il y a tellement de façons de faire qu'il restait toujours une combinaison non prévue !

Sur le grand-livre imprimé au format vertical, en cas d'enregistrement au format PDF, la première colonne où figure la date était légèrement trop étroite, et de ce fait, le dernier chiffre de l'année était perdu.

Le mode de décalage des fenêtres, en saisie des règlements clients et dans le cas d'une saisie avec éclatement, a été revu.

Si on dispose d'une résolution écran supérieure à 800x600 (ce qui le cas à peu près partout aujourd'hui), la seconde fenêtre de saisie est remontée en haut à gauche, mais sans recouvrir les zones saisies sur la première fenêtre. On conserve donc, durant la saisie de l'éclatement,  la visibilité de ce qui a été saisi sur la première fenêtre.

Dans les fenêtres permettant de gérer les droits d'accès aux sociétés, les dossiers d'archives n'apparaissaient pas dans la liste de sélection des sociétés obtenue par le bouton F4 en regard du code société. On pouvait toutefois saisir directement le code d'un dossier d'archives.

Dans certains cas, dans un calcul d'échéance (en saisie par pièce), le système ne tenait pas compte du jour de paiement, pour les tiers qui n'avaient pas de report Fin de mois.

Suite à la correction N° 34, la possibilité de réimprimer un rapprochement bancaire n'était plus disponible. En effet, le dernier rapprochement bancaire définitif écrasait le rapprochement précédent. Dorénavant, les rapprochements sont conservés et on peut les imprimer ou les dépointer.

En version 9, la zone Référence fournisseur était mal cadrée dans le corps des lettres-BO.

Dans les procédures d'interrogation par pièce et par référence, si on tentait d'interroger directement (c'est à dire sans passer par un double clic depuis la consultation d'un compte) une pièce ou une référence d'un exercice antérieur (en indiquant une date antérieure à la date de début d'exercice), on pouvait rencontrer une erreur du type :

Il n'existe pas de rubrique <KHIS7> (ou KHIS8) dans le fichier <CPTHIS2>.

Ce problème ne survenait que sur les dossiers gérés en environnement Client/Serveur AS/400, et dans lesquels le module Devises était actif. De plus, si de par le mécanisme des "vues", on avait désactivé l'option Affichage en devise en fonction de la pièce (ou de la référence), le problème ne se manifestait pas non plus, car c'était lors du pré-parcours permettant de choisir le mode d'affichage (en devises ou en euros) que le problème survenait.

La procédure de clôture d'exercice lancée sur un dossier en environnement Client/Serveur AS/400 échouait si le profil utilisateur de la connexion AS/400 ne disposait pas des droits spéciaux *ALLOBJ. Rappelons que ce profil utilisateur AS/400 peut être :

- soit celui indiqué dans le fichier des paramètres LDCParam.INI, à l'invite AS400User

- soit celui saisi sur l'écran d'ouverture de session proposé par EASYCOM

- soit identique au code utilisateur de LDCompta Windows (si les codes utilisateurs et mots de passe sont identiques dans LDCompta Windows et sur l'AS/400.

Détail technique : lors de l'archivage du dossier avant clôture, le système duplique le dossier comptable. En environnement AS/400, cela est fait par une commande CRTDUPOBJ OBJ(*ALL) ... Or, pour passer une commande CRTDUPOBJ sur un objet quelconque, il faut disposer des droits *OBJMGT sur celui-ci, ce qui n'est pas le cas des profils "ordinaires" utilisé pour LDCompta. Les droits publics définis sur les fichiers d'un dossier comptable, de type *CHANGE, ne définissent sur l'objet lui même que le droit *OBJOPR (utilisation), pas le droit *OBJMGT (gestion).

ATTENTION : pour contourner ce problème de droits, les commandes permettant d'archiver le dossier comptable sont désormais exécutées sur l'AS/400 au travers du programme ASEXEC, qui appartient à l'utilisateur QSECOFR et dispose des privilèges d'exécution USRPRF(*OWNER). Ainsi, toute commande exécutée au travers de ce programme contourne tous les problèmes de sécurité, l'utilisateur QSECOFR disposant des droits spéciaux *ALLOBJ.

Mais ce programme ASEXEC a été créé spécifiquement pour cette correction. Il faut donc, simultanément à l'installation de cette correction, faire également une mise à jour de la partie "serveur AS/400" de LDCompta, de telle sorte que l'on soit au minimum au niveau 14 côté serveur.

La façon de gérer l'enregistrement de la taille et position des fenêtres a été revue, pour toutes les fenêtres où le mécanisme des vues est offert. En effet, le mécanisme standard de mémorisation de la taille et position des fenêtres interférait avec le mécanisme des vues, et on avait des effets de bord parfois curieux. Nous avons donc fait le choix de privilégier le mécanisme des vues (plus performant), et donc de désactiver le mécanisme standard (celui proposé sur toutes les autres fenêtres) pour ces quelques fenêtres concernées :

- Consultation compte, pièce, référence, journal, montant, banque

- Consultation section analytique, affaire

- Lettrage d'un compte

Désormais, pour les fenêtres listées ci-dessus :

- la possibilité d'activer ou désactiver l'enregistrement de la taille et position de la fenêtre (par un clic droit dans la barre de titre) a été retirée ; l'option n'apparait plus dans le menu contextuel ;

- pour ces mêmes fenêtres, si l'option d'enregistrement de la taille et position de ces fenêtres était auparavant activé, il est systématiquement désactivé à chaque lancement de l'application.

- enfin, l'option du menu contextuel Restaurer la taille et position par défaut fonctionne désormais correctement. Jusqu'ici, pour ces fenêtres, cela avait pour effet de faire disparaître la fenêtre de l'écran. En effet, ces fenêtres étaient configurées pour être hors-écran par défaut, le temps que la taille et position soit récupérée par le mécanisme des vues à l'ouverture de la fenêtre, tout cela afin d'éviter un effet visuel désagréable : on voyait la fenêtre se dessiner une première fois au centre de l'écran, puis redessiner à l'emplacement défini par la vue sélectionnée. Désormais, ces fenêtres sont configurées non visible et centrée par rapport à l'écran, et elles sont rendues visibles par programmation dès que la taille et position a été restituée par le mécanisme des vues.

Dans l'édition des grands-livres généraux et détaillés, et du bilan, certains comptes pouvaient être ignorés.

Le problème se produisait lorsqu'on avait des N° de compte à longueur variable (601100 et 60110001 par exemple), et uniquement dans le cas où le premier des 2 comptes (celui ayant le moins de chiffres dans son N°) contenait des écritures au delà de la date d'arrêté de l'édition demandée.

Dans certaines fenêtres, on pouvait accéder à une fenêtre de sélection par la touche F4, et même sélectionner une valeur dans cette fenêtre, alors que le champ de départ n'était pas en saisie (cas où le champ est en affichage seulement, mais avec l'attribut "sélection possible en affichage). Cela revenait à modifier une valeur qui était normalement en affichage seulement.

Les libellés des lettres de relance, qui peuvent être personnalisés sur l'onglet Libellé en modification d'une lettre de relance, n'étaient pas correctement mémorisés.

Deux problèmes ont été corrigés :

1) Lorsqu'on utilisait une table de ventilation analytique sur une ligne de folio, lors de la validation du folio, le montant était imputé en totalité sur la dernière section figurant dans la table de ventilation analytique.

2) Lors de la copie d'un folio, la ventilation analytique n'était pas (ou mal) copiée.

Les lettres de relance des traites à l'acceptation ne s'imprimaient pas ; seule la liste préparatoire de ces relances de traite fonctionnait normalement.

Dans la fenêtre de lancement d'une interface standard en entrée de LDCompta, si on cliquait sur le bouton Editer pour modifier un fichier d'interface au format Version 8.50 (en spécifiant donc, à l'invite Fichier de description, l'ancienne description IntCptV8.fdf, le programme partait en boucle infinie lors de la lecture du fichier d'interface.

Dans la fenêtre de consultation de la ventilation analytique d'une écriture (obtenue par exemple depuis la consultation d'un compte, par un double clic dans la colonne Section), les différentes colonnes de la table peuvent être déplacées à volonté (et cela est mémorisé), et il est possible de trier sur n'importe laquelle de ces colonnes.

On affiche désormais le code de la société courante, en plus du libellé, dans la barre de titre de la fenêtre principale de LDCompta.

Cela est surtout utile lorsqu'on a plusieurs fenêtres ouvertes avec LDCompta, pour mieux les distinguer dans la barre des tâches de Windows.

Le champ Code section a été agrandi dans fenêtre de saisie du plan comptable, afin d'améliorer l'affichage des codes sections alphanumérique de 10 caractères.

Suite à l'historisation des rapprochements bancaires, le système pouvait ne pas s'apercevoir qu'un compte de banque avait déjà été rapproché définitivement et affichait un message d'erreur lorsqu'on cochait Masquer les écritures rapprochées.

Ce problème se présentait aussi lors de l'édition d'un compte de banque.

Un nouveau mode de calcul des écarts en pourcentage est désormais offert sur les balances budgétaires.

On avait jusqu'ici 2 modes de calcul :

- l'écart en valeur absolue entre 2 colonnes a et b :  Formule :  a-b    

- l'écart en pourcentage entre 2 colonnes a et b :  Formule :  (a-b)/a*100

Le nouveau mode de calcul donne aussi un écart en pourcentage entre 2 colonnes a et b, mais par la formule (a-b)/b*100.

En consultation de compte d'un tiers, le fait d'imprimer un relevé (ou seulement afficher l'aperçu) provoquait un décalage d'enregistrement si on consultait par la suite la fiche tiers. On obtenait alors l'affichage du tiers suivant.

Lors de l'impression du tableau de bord analytique, les libellés de la section et de la sous-section n'étaient pas imprimés.

Le look de la barre d'icônes a été revu, avec des effets de dégradé dans les tons de vert, comme le fond d'écran.

1) Correction d'une petite anomalie dans le calcul de la durée restante à amortir, en cas de saisie d'une immobilisation ayant une date antérieure au 1er jour de l'exercice comptable

2) Correction des bulles d'aide affichées en saisie guidée

3) Numérotation automatique des Immos : ajout d'un mode de numérotation par Famille-N° d'ordre, et pour les numérotations automatiques par Année-N° d'ordre, Compte-N° d'ordre et Famille-N° d'ordre, on accepte désormais d'avoir un compteur à 3 chiffres (Attention toutefois pour ceux qui ont beaucoup d'immobilisations, la valeur conseillée est de 4 dans ce cas là).

4) Etat de situation : Ajout d'une colonne VNC au début de la période. La colonne reprise n'affiche que la reprise comptable lors d'une sortie (le libellé a été modifié). Un message d'erreur s'affiche si la période demandée ne commence pas au premier jour du mois ou ne se termine pas au dernier jour.

Dans la liste des champs proposée lors de la définition d'un filtre d'une fenêtre de consultation (compte, pièce...), on voyait s'intercaler des mentions correspondant aux textes des bulles d'aide de certains champs. Cela était dû au fait que certains champs ont désormais un texte "multilignes" affiché dans la bulle d'aide.

Pour corriger cela, seule la première ligne de la bulle d'aide de chaque champ est désormais utilisée comme nom de champ dans la liste déroulante proposant les différents champs utilisables pour appliquer un filtre.

A l'ouverture de session, le contrôle de l'existence du répertoire des données associé à la société sélectionnée (amené par la correction 96) posait problème dans le cas d'une base de données HyperFile Client/Serveur. Dans cet environnement, on n'a en effet pas d'accès "direct" au répertoire où sont stockées les données, puisqu'on passe par un "serveur" de données. Ce contrôle a donc été retiré lorsqu'on est dans cette configuration.

De plus, ce même contrôle posait problème en cas de tentative d'ouverture directe d'un dossier, en passant le code dossier en ligne de commande de l'exécutable. De ce fait, on se retrouvait toujours sur l'écran d'ouverture de session, même en ayant passé tous les paramètres nécessaires à une ouverture directe.

Dans les fichiers modèles servant à la création d'une nouvelle société, la date de clôture était pré renseignée au 31/12/2008.

Cette date doit être à blanc, pour forcer la saisie de cette date de dernière clôture à la première ouverture du dossier qui suit sa création.

En création de société, si la gestion des immobilisations était activée, une erreur bloquante de date invalide se produisait.

Une procédure de reprise des Immobilisations gérées par le logiciel P7IMMO sur IBM AS/400 a été développée.

Reportez vous à la documentation correspondante : Migration Immos PROGI7.doc

Lors de la reprise d'une immobilisation complètement amortie, le plan comptable était calculé mais ne tenait pas compte de la coche complètement amortie. De ce fait, la ligne cumulant les amortissements antérieurs n'était pas calculée.

Cependant, ce problème ne se posait qu'à l'affichage. En effet, le plan d'amortissement est recalculé lorsqu'on valide la fenêtre et la coche était prise en compte.

Dans la fenêtre de sélection d'une section analytique, le positionnement ne se faisait pas correctement lorsqu'on faisait F4 sur un code section déjà renseignée.

Cela faisait suite au fait qu'en version 9, le découpage entre les zones Section et Sous-section est désormais variable (fixé dans la Fiche Société).

Lors de l'ouverture d'une session sur un dossier Client/Serveur AS/400, dans le cas où l'utilisateur de connexion AS/400 n'était pas spécifié dans le fichier de configuration (mots-clés AS400User et AS400Password dans le fichier LDCParam.INI), et si l'utilisateur Windows indiqué sur l'écran d'ouverture de session de LDCompta n'était pas Administrateur de sécurité, la session EASYCOM ouverte sur l'AS/400 ne l'était pas avec le code de l'utilisateur indiqué sur l'écran d'ouverture de session de LDCompta, mais avec le code du dernier utilisateur présent dans la table des utilisateurs de LDCompta.

La zone "Heure de modification" du fichier des écritures comptables était mal renseignée en environnement Client/Serveur AS/400, lors de l'ajout d'une écriture. Plutôt que d'être initialisée à blanc (6 espaces), elle était initialisée avec des zéros binaires.

Complément technique : on a forcé l'initialisation avec 6 espaces, plutôt que de laisser la valeur par défaut qui était chaine vide dans Windev.

Dans la procédure d'interrogation par section analytique, en environnement Client/Serveur, il pouvait arriver que les écritures ayant une date égale au 1er jour de la période demandée n'apparaissent pas, ce qui faussait également le total de la section.

Des anomalies de fonctionnement avaient été signalées, dont entre autre le mauvais fonctionnement de la procédure de recalcul des collectifs. Et ce depuis le passage en version 12.0.16 d'EASYCOM (correctif N° 105).

La cause en était un dysfonctionnement d'EASYCOM, chaque fois que l'on avait une boucle de parcours de fichier incluant un ou plusieurs ajouts dans ce même fichier.

La correction consiste donc à remplacer la DLL d'EASYCOM (fichier eac1200as.dll, présent dans le répertoire des programmes). Le fichier doit désormais être en version 12.0.18 (normalement, via le processus habituel de LDUpdate, cette DLL devrait se mettre en place automatiquement).

Encore une correction sur les immobilisations, qui concerne ici le cas des cessions faites à une date postérieure à la fin de l'amortissement, mais dans le même exercice que la date de fin d'amortissement.

L'amortissement imputé à la cession était mal calculé : l'amortissement de l'exercice de cession était considéré comme faisant partie des amortissements antérieurs (à l'exercice de cession). Ce qui avait pour effet de fausser l'état des sorties.

D'autre part, en saisie d'une fiche immobilisation, il y a recalcul systématique du plan d'amortissement. Ce qui peut dans certains cas influer sur les montants portés sur une éventuelle sortie de l'immobilisation. Mais les nouveaux montants recalculés pour la sortie n'étaient pas mémorisés. Il fallait aller modifier la sortie pour que celle-ci tienne compte du plan d'amortissement recalculé.

Dans la procédure d'export de balance pour ETAFI, si on répond Non à l'option Préparer le fichier au format ETAFI, la dernière colonne a été supprimée du fichier produit en sortie (colonne Solde Exercice N-1, qui portait en fait un libellé erroné Compte général), sachant que de toute façon, cette colonne n'était jamais renseignée.

Sur la liste préparatoire des relances clients triée par code représentant, la gestion des sauts de page a été revue.

On tentait auparavant de limiter d'avoir un saut de page au milieu des écritures d'un client, ce qui peut entraîner, lorsque le nombre de factures relancées par client est important, des sauts de page beaucoup plus nombreux.

Ce mécanisme a été retiré ; de ce fait, les pages sont remplies au maximum, mais avec un risque beaucoup plus important d'avoir un client à cheval sur 2 pages.

De plus, un problème se posait parfois lorsqu'il y avait des écritures en litige ; cela pouvait provoquer une erreur bloquante sur l'état.

Dans la procédure de clôture mensuelle, on proposait de réaliser une sauvegarde du dossier même si on était en environnement AS/400. Or, dans cet environnement, la sauvegarde du dossier comptable ne peut être réalisée en mode "graphique" ; cette sauvegarde ne peut être lancée qu'en mode "caractère" sur AS/400.

Le contrôle du mot de passe passé au serveur de message (interfaces, en-cours, ...) tenait compte des minuscules/majuscules à tort (n'est pas pris en compte à l'ouverture de session standard).

Dans la procédure de migration des fichiers, il y avait une erreur dans l'appel de la procédure zFichierExiste.

Cela n'avait pas d'incidence directe, car tous les fichiers traités par cette procédure existaient effectivement. L'erreur ne se serait produite que s'il y avait eu un fichier décrit dans l'analyse n'existant pas en version antérieure de LDCompta.

La date d'arrêté ne s'imprimait pas en haut de page sur le relevé d'agios.

Ajout de nouveaux types de zones qui n'étaient pas gérés jusqu'alors dans la procédure de conversion de données en format texte (dont les zones de type Booléen, qui ont fait leur apparition dans les nouveaux fichiers Immobilisations).

Suite à une restauration ou une migration d'un dossier en environnement HF Client/Serveur, de nombreuses connexions étaient laissées ouvertes alors qu'elles n'étaient plus nécessaires. En fait, chaque accès au fichier CPTERR, qui trace les traitements "sensibles", laissait une connexion ouverte.

Une procédure a été ajoutée, dans la fenêtre de reprise des immobilisations API, pour renuméroter après coup tous les comptes figurant dans les fiches Immobilisations. Elle est accessible par le bouton Modifier comptes.

Il est préférable de lancer cette procédure une fois la reprise achevée et validée, car une fois les comptes modifiés, il est difficile de faire des états comparatifs entre les données API et celles de LDCompta.

La table de correspondance doit être enregistrée dans un fichier nommé TabCPT.txt, dans le répertoire des données LDCompta de la société concernée. Ce fichier doit être un fichier texte avec séparateur Tabulation (qui peut être créé facilement sous Excel), avec 4 colonnes :

- Ancien N° de compte d'immobilisation

- Nouveau N° de compte d'immobilisation

- Nouveau compte d'amortissement

- Nouveau compte de dotation

Les immobilisations dont le compte d'immobilisation ne figure pas dans cette table (en 1ère colonne) resteront inchangées.

Deux petites corrections ont été apportées dans le module Immobilisations :

1) lors de la création d'une immobilisation, la ventilation analytique n'était pas reprise depuis la famille, lorsqu'on en avait spécifié une sur la famille d'immobilisation. Désormais, elle l'est, sauf dans le cas d'une saisie de fiche Immobilisation liée à une facture (saisie de fiche intégrée à la saisie pièce, ou saisie "guidée"), si une ventilation analytique a été inscrite sur l'écriture mouvementant le compte de classe 20 ou 21. Dans ce dernier cas, c'est cette ventilation analytique qui est reprise dans la fiche Immobilisation.

2) la taille du compteur, en cas de numérotation automatique des immobilisations (quel que soit le mode de numérotation automatique) est désormais limitée à 6 positions. On permettait auparavant d'aller jusqu'à 9 positions, mais le compteur était mémorisé sur 6 positions seulement !

Le code pays est désormais ajouté dans l'export des honoraires. Il est en effet nécessaire à l'arrivée dans LDPaye pour préparer le fichier DADS-U car à partir de la version V8R9 de la DADS-U, le code pays est nécessaire pour les fournisseurs étrangers dans les structures Honoraires.

Lors de la modification d'une pièce correspondant à une facture d'achat, si on modifiait l'échéance par la modification globale de la pièce (bouton Modifier pièce) plutôt qu'en appelant en modification la ligne mouvementant le compte fournisseur, l'échéancier n'était pas présenté en fin de modification de la pièce, lorsqu'on cliquait sur le bouton Valider.

On ne pouvait donc pas corriger la date d'échéance dans l'échéancier.

Au passage, un petit souci dans l'affichage du titre de la fenêtre de modification d'une pièce, suite à l'appel de la fenêtre de modification globale de la pièce, a aussi été corrigé (le titre était partiellement effacé en retour de la fenêtre de modification globale ; on ne voyait plus l'identifiant de la pièce en cours de modification).

Ces deux problèmes existaient déjà dans LDCompta pour Windows Version 8.00 et 8.50. En revanche, cela fonctionnait correctement dans LDCompta pour AS/400 Version 8.00.

Lors de l'édition d'une lettre de relance avec décompte d'agios, on calculait des agios négatifs pour les écritures dont la date d'échéance était postérieure à la date d'arrêté des agios.

Désormais (comme cela était le cas dans LDCompta pour AS/400), on ne calcule aucun agio pour ces écritures.

Parallèlement à cette modification, quelques petites modifications d'ergonomie ont été faites dans la fenêtre de modification des relances client par client. La largeur de la fenêtre par défaut a été diminuée, et la colonne Echéance a été déplacée juste après le libellé pour qu'elle soit plus visible.

Si on définissait des droits d'accès sur les fenêtres PD8LST et PD8MAJ, on pouvait rencontrer une erreur dans la fenêtre de saisie des groupes et/ou familles de clients et/ou fournisseurs, lorsqu'un utilisateur ne disposant pas des droits d'accès en modification tentait d'ouvrir cette fenêtre en mode Affichage seulement.

Dans le source qui est compilé dynamiquement pour l'impression des relevés clients, la hauteur de page par défaut est désormais de 2970 (A4) plutôt que 3048 (12 pouces).

En environnement Client/Serveur, dans la fenêtre de consultation de l'historique des modifications de pièce, on voyait la pièce avant et après modification dans les deux cadres haut et bas de la partie droite, avec en sus une ligne blanche en premier.

Désormais, comme cela était prévu, on a la pièce avant modification en haut, et la pièce après modification en bas.

Lors de l'émission des relevés clients, si vous faites le choix, sur le dernier onglet, d'une comptabilisation de type Traite en portefeuille, le système s'assure au préalable que tous les clients (dans la tranche de N° demandée) ayant le mode de paiement choisi aient effectivement un RIB renseigné dans leur fiche. Cela évite de comptabiliser des traites en portefeuille sans RIB, sachant qu'il n'est plus possible, une fois le règlement passé en portefeuille, de modifier le RIB.

Lorsqu'on lance depuis LDCompta l'outil WDSql, les paramètres de connexion de ce dernier sont automatiquement renseignés.

Attention : il faut que la version 12 de WDSql soit installée sur le poste.

Il est désormais possible de spécifier un jour pour la date d'arrêté des balances âgées client et fournisseur.

La correction 148 a entrainé un problème de date lors de l'édition. Ce problème n'apparaissait que si on lançait l'impression après l'ouverture de la fenêtre. La zone Mois de départ colonne 1 n'était pas initialisée.

Dorénavant, si elle n'est pas initialisée au lancement de l'impression, elle est remplie en fonction de la date d'arrêté.

Plusieurs problèmes de mise en forme des lettres de relance ont été corrigés :

1) suite à un saut de page, l'en-tête de colonne n'était pas réimprimé en début de page suivante ;

2) l'en-tête de colonne, et le total de la lettre sont désormais imprimés avec quelques millimètres d'espacement avant et après, ce qui facilite la lecture

3) un espace de 40 millimètres est toujours réservé en base de page ; cela permet d'imprimer les lettres de relance sur du papier où il y a un bas de page préimprimé sans que le texte imprimé ne morde sur la bas de page préimprimé ;

4) il y avait parfois, lorsqu'on avait une lettre de relance pour un client nécessitant plusieurs pages, et que cette lettre était englobée au milieu d'autres lettres, des sauts de page un peu aléatoires.

5) les mêmes problèmes ont aussi été réglés sur le décompte d'agios qui suit éventuellement la lettre de relance.

Lorsqu'on imprimait l'état des situations du module Immobilisation, si l'on imprimait avec une rupture sur les sections analytiques et si l'on spécifiait une sélection, le système provoquait une erreur.

En saisie des OD analytiques, les montants comptabilisés étaient faux à partir de la seconde ligne de l'OD analytique faisant appel à une table de ventilation.

D'autre part, un petit effet de bord a été corrigé en saisie analytique (OD purement analytique, ou ventilation analytique d'une écriture de comptabilité générale). Quand on retournait corriger le code section d'une ligne précédemment saisie, le 1er caractère du code section était "perdu" ; il était remplacé par le second caractère frappé.

Quelques codes pays nouveaux ont été ajoutés dans la table des pays :

ME MONTENEGRO

RS SERBIE

BL SAINT BARTHELEMY

GG GUERNESEY

IM ILE DE MAN

JE JERSEY

AX ILES ALAND

MF SAINT MARTIN

Pour récupérer ces codes pays dans un dossier comptable pré-existant à ce correctif, il faut appeler le dossier comptable en question en modification, depuis le menu Fichier/Sociétés.

Le séparateur décimal utilisé pour l'export de l'état de situation des immobilisations était toujours la virgule. Il ne tenait pas compte du séparateur défini dans la Fiche Société, sur l'onglet Modules.

Suite à une correction faite en septembre 2009, les fenêtres standard de type "Liste" (liste des clients, des fournisseurs, du plan comptable...) n'avaient plus de titre.

La copie d'un canevas ayant un code à 2 caractères ne fonctionnait pas.

En saisie de la sortie d'une immobilisation, en cas de vente, on peut indiquer le N° du compte client à qui la vente a été faite (ou un compte général 467-Débiteurs divers).

Or, le champ de saisie était limité à 8 caractères, au lieu des 10 nécessaires pour un compte de tiers (Code racine sur 2 caractères, suivi du N° de tiers sur 8 caractères). On ne pouvait donc pas saisir le N° du tiers s'il excédait 6 caractères.

Dans la procédure d'interface standard en entrée de LDCompta, certaines erreurs détectées sur le N° de compte étaient signalées avec un message d'erreur sans rapport avec la véritable erreur.

La correction N° 146 avait permis de mettre en place un contrôle supplémentaire de présence d'un RIB, lors de l'émission des relevés clients, lorsqu'on faisait le choix, sur le dernier onglet, d'une comptabilisation de type Traite en portefeuille.

Ce contrôle tenait compte de la tranche de N° de client demandée, mais seulement dans le cas où l'on faisait une sélection sur le mode de paiement indiqué dans la Fiche Client (première case à cocher sur l'écran de lancement).  Si on faisait une sélection en se basant sur le mode de paiement des écritures (deuxième case à cocher sur l'écran de lancement), le contrôle de présence du RIB se faisait sans tenir compte de la tranche de N° clients demandée.

Le système signalait donc des erreurs superflues.

Lorsqu'on fait une demande d'édition d'un grand-livre analytique par section, et que de par les sélections demandées, aucune écriture analytique n'est sélectionnée, le système imprime une page avec seulement un en-tête de page et les bandeaux de rupture début et fin de section et sous-section.

Lorsqu'on était dans ce cas de figure, si le fichier des écritures analytiques avait été ouvert auparavant (pour une consultation analytique par exemple, ou même par une autre demande d'édition de grand-livre analytique avec une sélection différente ayant retourné des écritures), on voyait apparaître sur ces bandeaux de rupture les codes et libellés section et sous-section de la dernière écriture lue dans le fichier des écritures analytiques, alors même que cette section et/ou sous-section ne faisait peut-être même pas partie de la dernière sélection demandée.

Désormais, dans ce cas de figure, aucun code ou libellé section et sous-section n'apparait sur les bandeaux de rupture.

En saisie d'une pièce d'achat mouvementant un compte de type "autre auxiliaire", sur le dernier écran où l'on renseigne comment alimenter l'échéancier fournisseur, le système interdisait le choix d'un mode de paiement de type Virement, même si un RIB avait été indiqué dans la fiche du compte Autre auxiliaire.

En version 8.50, l'interface Notilus utilisait un fichier de paramètres (contenant des tables de correspondances pour les codes journaux, les natures de pièce et les comptes de banque) qui était placé dans le répertoire nommé jRepDataSoc, ce qui donnait au final :

X:\Ldsystem\Fichiers\Compta\SOC_XXX\iNotilus.ini

Suite à la migration en version 9, et compte tenu du fait que dans le cas d'une base HyperFile Client/Serveur, le répertoire des données Société n'existe pas, le fichier était attendu dans le répertoire jRepSousRep, sous répertoire Interfaces, ce qui donnait :

X:\Ldsystem\Fichiers\Compta\Interfaces\iNotilus.ini

Mais cela ne peut fonctionner ainsi, car il faut qu'on ait un fichier de paramètres par société, les tables de correspondance pouvant contenir des valeurs différentes d'une société à l'autre. Le fichier est donc désormais attendu dans le répertoire jRepSousRep, sous répertoire Notilus, avec un nom de fichier contenant en partie droite le code société, ce qui donne :

X:\Ldsystem\Fichiers\Compta\Notilus\iNotilusXXX.ini

Dans un contexte de reprise de données, la comptabilisation des données pouvait être faussée. Des cas non prévus pouvaient apparaître et engendrer des erreurs sur les montants comptabilisés.

De même, dans l'état de situation, des immobilisations pouvaient ne pas apparaître.

Enfin, pour rendre plus compréhensible l'état de situation, une colonne VNC cédée a été ajoutée pour les sorties.

Sur les listes de clients et fournisseurs (liste simple et liste détaillée), la première colonne où figure le N° du tiers a été agrandie.

Elle était en effet trop étroite dans le cas où le N° du tiers était alphanumérique (avec des lettres), et composé de plus de 6 caractères.

Sur l'écran où l'on demande la validation définitive d'un rapprochement, on pouvait rencontrer un problème si on mémorisait la valeur de la case à cocher Validation définitive (par le mécanisme de mémorisation FAA, activable par un clic droit sur cette coche).

Par la suite, il y avait alors validation systématiquement, même si on sortait avec un rapprochement incomplet.

Ce mécanisme de mémorisation a été désactivé sur les 2 coches disponibles au bas de cet écran.

Depuis le passage en version 9, le fichier ETEBAC créé par LDCompta pour les remises de LCR n'était pas conforme si le N° SIRET n'était pas renseigné intégralement (14 caractères) dans la Fiche Société.

Dans les différentes procédures de consultation, les filtres placés sur le code devise provoquaient une erreur.

La fenêtre présentant le contenu des données interfacées était mal cadrée sur l'écran.

Si on modifiait le fichier en entrée d'une interface (par le bouton Editer fichier), alors que ce fichier était reçu avec des montants en devises, on perdait le sens Débit-Crédit des écritures. Toutes les écritures se retrouvaient ensuite au débit dans le fichier d'interface après validation de la modification.

La procédure de reprise des immobilisations API a été revue sur 3 points :

1) dans le cas des sorties, les montants Amortissement relatifs à la sortie étaient faux ;

2) toujours pour les sorties, mais plus particulièrement pour celles effectuées au 1er jour de l'exercice courant, une spécificité a été introduite pour ignorer le montant de l'amortissement que l'on trouve dans le fichier des cessions d'API. En effet, pour ces sorties faites au 1er jour de l'exercice, API calcule un montant amortissement dans le fichier des cessions, mais on ne trouve pas ce montant dans le plan d'amortissement. Les deux fichiers sont donc incohérents. Pour obtenir dans LDCompta le même état de situation que celui issu d'API, le choix a été fait d'ignorer ce montant amortissement lu dans le fichier d'API, et pour rester cohérent, de répercuter ce montant (en plus ou en moins selon le cas) dans le cumul amortissement de la sortie, et dans la valeur nette des éléments cédés.

Attention : pour mettre en oeuvre cette spécificité, il faut indiquer la date du 1er jour de l'exercice courant, en regard de la case à cocher permettant la reprise du fichier des cessions, sur le 3ème onglet de la fenêtre de reprise.

3) la procédure de reprise récupère aussi désormais la date de reprise, si celle-ci est renseignée dans la base API. Cela correspond au cas où les immobilisations ont saisies dans la base API avec une VNC à une date donnée. Le système recalcule automatiquement la durée restante par différence entre la durée d'amortissement totale et la durée écoulée entre la date d'acquisition et la date de reprise trouvée dans la base API. La valeur booléenne "Entièrement amortie à la date de reprise" est également positionnée en conséquence.

Attention : dans le texte ci-dessus, la date de reprise correspond à celle lue dans la base API, pas à la date de la reprise dans LDCompta.

Lors de la suppression d'un domaine d'activité (en liaison avec l'édition des chiffres d'affaires clients et fournisseurs), les liens entre le code du domaine d'activité et les comptes de charges ou produits associés n'étaient pas supprimés.

Dans la fenêtre principale de gestion des immobilisations, on a ajouté une colonne donnant la quantité sortie de chaque immobilisation. De plus, les immobilisations entièrement sorties figurent désormais en gris dans cette liste. On distingue ici plus facilement les immobilisations entièrement sorties des immobilisations toujours présentes.

On pouvait rencontrer dans certains cas une division par zéro lors du recalcul du plan d'amortissement, suite à une reprise d'un fichier Immobilisations API.

Sur les relances adressées par mail, on peut désormais faire figurer, soit dans l'objet du mail, soit dans le corps de ce mail (dans le cas où l'on a choisi de porter la lettre de relance en pièce jointe du mail), l'identification du client.

3 zones sont possibles :

- le N° de client

- le nom abrégé

- la raison sociale du client

Cela permet de mieux suivre les lettres ayant été envoyées, dans le cas où l'on adresse systématiquement une copie dans une boite "maison". Et cela permet aussi de mieux identifier les retours à ces mails, retours résultant d'une véritable réponse utilisateur, ou réponse automatique en cas d'erreur (boite mail pleine, destinataire inconnu...).

L'ajout de ces données dans le mail se fait par le bouton Insérer, lors de la saisie de la lettre de relance, sur l'onglet Mail. Il s'agit du même principe que celui utilisé pour insérer le mode de paiement ou le solde de la relance dans le corps de la lettre de relance.

Les comptes sont désormais obligatoires dans la fiche d'une immobilisation si cette dernière est amortie.

Modification des messages de log lors de la comptabilisation. Ils deviennent plus pertinents.

Ajout d'un sablier lors du traitement de comptabilisation et d'un message indiquant l'état du traitement.

Dans la fiche de mise à jour d'une famille d'immobilisation, si l'analytique n'était pas actif, c'est l'onglet des zones supplémentaires qui était masqué en lieu et place de l'onglet de l'analytique.

La zone suspendue était plus grande que l'image. En cliquant sur la zone vide à droite, on pouvait donc suspendre un client. Si l'on n'y prêtait pas garde, les clients étaient suspendus sans raison apparente.

Un nouveau paramètre permet de regrouper, lors de la préparation du fichier ETEBAC de remise des LCR, les traites non acceptées (code acceptation = 0), à RIB client et date d'échéance égaux.

En cas de rejet, cela permet de diminuer les frais d'impayé. On a des frais sur une seule traite et non sur plusieurs.

Le regroupement est effectué en dernier ressort, une fois le fichier ETEBAC déjà constitué. Ce fichier est relu, trié par code enregistrement (2 premiers caractères du fichier), RIB client, Date échéance, Code acceptation. Puis on réécrit le fichier ETEBAC, en regroupant toutes les traites ayant code acceptation 0, même RIB et même échéance (notez qu'en cas de regroupement, la référence tiré est perdue).

Un état de contrôle permettant de voir quelles traites ont été regroupées peut être imprimé.

Pour activer ce regroupement, il faut aller modifier explicitement le paramètre programme CPEDRG (menu Fichier/Paramètres Programmes), et inscrire la valeur "O" (O=Oui) en position 4 de ce paramètre.

Lorsqu'on appelait l'option de saisie des paramètres programmes, depuis le menu Fichier, la zone de positionnement, en haut à gauche de la fenêtre, était prérenseignée avec une valeur "FM" qui n'avait rien à faire là (il s'agissait des lettres raccourcis de l'option Fichier/Programmes).

Lors de la création d'un nouveau dossier, les autorisations publiques sont désormais définies par défaut sur toutes les classes de comptes. Ainsi, un utilisateur ne disposant pas de droits de niveau Administrateur sur le dossier comptable a quand même accès par défaut à tous les comptes en consultation. Si on veut bloquer certains comptes en consultation, il faut aller modifier la table qui gère ces droits, depuis la gestion du plan comptable (Fichier/PLan comptable), par le bouton Autorisations.

Plusieurs corrections ont été apportées dans le module Immobilisations :

Etat de situation

- Ajout d'un libellé indiquant si les immobilisations totalement sorties/amorties sont exclues ou pas

- Les pourcentages du taux d'amortissement ne s'affichaient pas correctement

Saisie des immobilisations

- Le libellé est désormais renseigné en saisie guidée à partir du libellé de la facture

- Pour les saisies de fiches avec reprise à une date donnée, la VNC est dupliquée dans la VNF

 si les données comptables sont égales aux données fiscales, et si la VNF n'est pas renseignée

- La famille est sélectionnée automatiquement en saisie guidée si on trouve une et une seule famille

 ayant un compte d'immobilisation égal au compte sur lequel on a saisi la facture

- Correction d'une anomalie sur le montant TTC lorsqu'on passe par la saisie guidée pour ajouter une immobilisation

 à partir d'une pièce ne mouvementant aucun compte de tiers (pièce de banque).

Familles d'immobilisation

- La durée d'amortissement n'est plus obligatoire dans la fiche famille

Orthographe

- Un mot manquait dans le Oui/Non avant comptabilisation des immobilisations.

Les quelques spécificités qui avaient été faites pour CHALAVAN en spécifique ont été ici adaptées pour fonctionner en version 9.

Pour plus d'information, se reporter aux documents :

Interface spécifique.doc

Documentation Interfaces Tréso XRT.doc

dans le dossier U:\Applications\Chalavan et Duc\Compta.

Les modifications réalisées pour la version 9 sont repérées en bleu.

Sur les lettres de relance imprimées dans le cas où l'on met en oeuvre les relances "nouveau mode" (relances basées sur le retard de paiement en nombre de jours), si on avait demandé à ce que le solde soit inséré quelque part dans le texte de début ou de fin de la lettre, ce solde apparaissait toujours à zéro.

Dans le module de relance clients, on pouvait faire partout (recherche et édition liste des clients à relancer, édition des lettres, relance des traites à l'acceptation) une sélection des clients sur un groupe de relance donné.

On peut désormais aussi faire une sélection sur ce groupe de relance du type : jusqu'à un groupe donné.

Parallèlement à cette correction, certains petits défauts d'ergonomie ont été corrigés, dans le "nouveau" module de relance (celui basé sur le retard de paiement en nombre de jours).

Le calcul des cessions ne se faisait pas correctement. Dans le cas où une immobilisation n'était pas amortissable, les cessions n'étaient pas calculées.

L'état de situation n'affichait pas le montant des sorties dans le cas des immobilisations non amortissables. Les totaux de fins étaient donc faussés si de telles immobilisations étaient présentes.

Dans la procédure de saisie des écritures par pièce, il existait un chemin détourné permettant de valider une pièce invalide, comportant par exemple un N° de compte invalide ou non même non renseigné.

Le cheminement était le suivant :

- saisir une pièce avec plusieurs lignes, de telle sorte qu'elle soit équilibrée,

  mais avec une des lignes comportant un N° de compte non renseigné ou invalide

- faire alors Echap (ou clic sur bouton Annuler) pour abandonner la pièce

- dans la fenêtre de confirmation d'abandon de la pièce, faire Annuler pour revenir en saisie pièce

- une fois revenu en saisie pièce, faire 2 fois Entrée pour valider la pièce

Dans la procédure de modification d'une pièce, en cas de renumérotation automatique de la pièce suite à un changement de date par exemple sur une pièce figurant sur un journal à numérotation automatique, le nouveau N° attribué à la pièce est affiché lors de la validation de la modification.

Or, ce N° affiché était tronqué à 7 caractères, même lorsque le véritable N° de pièce attribué comportait plus de 7 caractères.

Plusieurs corrections ont été apportées dans la procédure de modification de pièce :

1) si on modifiait une ligne rapprochée sur une pièce de banque (modification du libellé par exemple) alors que le compte de banque mouvementé comportait une date de début et/ou de fin de validité telle que le compte en question ne pouvait pas être mouvementé à la date comptable de la pièce en cours de modification (ajout des dates de validité sur le compte postérieurement à la saisie de la pièce par exemple), cela avait pour effet, lors de la validation de la modification, de modifier le compte général. La ligne qui se trouvait initialement sur le compte de banque se retrouvait soit sur le compte de la ligne modifiée juste avant la ligne du compte de banque, soit avec un N° de compte à blanc si on n'avait modifié que la ligne sur le compte de banque.

2) dans le cas du rappel en modification d'une pièce comportant une écriture lettrée ou rapprochée, le système ne signalait pas que la modification de la pièce était limitée, comme c'est le cas lorsqu'on rappelle une pièce sur un journal déjà clos par exemple.

3) dans le cas d'une pièce comportant une écriture rapprochée, la modification de la date comptable de la pièce, sur l'écran de modification globale de la pièce, était impossible, mais on pouvait modifier le code journal. Cela est désormais impossible. La modification du code journal reste toutefois possible dans le cas d'une pièce comportant une écriture lettrée, car cela ne remet pas en cause le lettrage.

Dans le plan comptable, lorsqu'on saisissait le montant annuel d'un abonnement, les montants étaient divisés par 12 sans arrondi. On pouvait donc se retrouver avec des montants ayant plus de 2 décimales, ce qui pouvait produire des incohérences et des erreurs de centimes dans le reste du logiciel.

Dorénavant, le montant est divisé par 12 et arrondi à deux chiffres après la virgule et les quelques centimes restants sont ajoutés (ou retirés) au dernier mois.

Sur l'écran de gestion des virements fournisseurs et prélèvements clients, il y avait un souci sur la largeur de la 1ère colonne. Cette largeur augmentait à chaque ouverture de la fenêtre de gestion des prélèvements clients.

Il y avait un problème dans le retraitement du compte de TVA déductible, lors de l'intégration des factures d'achats. Le compte de TVA n'était pas remplacé pour les fournisseurs qui sont en TVA sur les débits.

Sur l'état de rapprochement, en fonction du nombre de lignes restant non rapprochées, il arrivait que le total de l'état ne s'imprime pas (en fait, il s'imprimait trop bas sur la page).

Désormais, le saut de page est provoqué plus tôt, pour toujours conserver en bas de page la place nécessaire à l'impression des totaux.

Depuis avril 2007 (V8.50 N242 ou V9), dans la procédure d'interface standard en entrée de LDCompta, des paramètres ont été ajoutés pour gérer une ventilation analytique par défaut.

Ces paramètres permettent de compléter la ventilation analytique, pour les écritures mouvementant un compte général supportant une ventilation analytique seulement, avec une valeur qui peut provenir soit du plan comptable pour le compte concerné, soit directement des paramètres de l'interface.

On peut également procéder au remplacement systématique d'une valeur particulière portée dans le fichier d'interface pour le code section ou le code affaire, valeur à remplacer définie dans les paramètres de l'interface, par une valeur provenant là aussi soit du plan comptable, soit de la valeur de remplacement définie dans ces paramètres de l'interface.

Ces paramètres existent tant pour la section analytique que pour le code affaire, de façon dissociée. On peut ainsi par exemple conserver le fonctionnement ordinaire pour la section analytique, et compléter seulement le code affaire s'il est manquant dans le fichier d'interface.

Mais jusqu'alors, ces paramètres ne concernaient que la ventilation analytique des écritures comptabilité générale (écritures de type E dans le fichier d'interface), que ce soit avec une ventilation analytique simple ou multiple (c'est à dire avec plusieurs séquences analytiques pour une écriture de comptabilité générale).

Avec ce nouveau correctif, cette gestion est également réalisées pour les écritures purement analytiques (écritures de type A dans le fichier d'interface).

La documentation de l'interface a été révisée pour tenir compte de cette correction ;

 voir document IntCPTW9 révision 1.2 Juin 2010.

Dans la procédure de consultation d'un compte, une nouvelle option permet d'ignorer les écritures d'abonnement et de situation, comme cela était déjà possible lors de l'édition des balances et grands-livres.

La valeur choisie pour cette option est mémorisée dans les vues.

On peut désormais définir des codes sections ou sous-sections analytique par défaut avec le caractère "%" qui sera utilisé comme joker.

Ces codes sections ou sous-sections sont ceux qui sont définis :

- soit dans des canevas

- soit dans le plan comptable (section par défaut).

Lors de l'utilisation en saisie de ces valeurs par défaut (saisie par pièce, saisie par folio, modification de pièce), si le code section ramené par défaut du plan comptable ou du canevas comporte un ou plusieurs caractères "%", seuls ceux-ci seront pré-sélectionnés (en bleu). Ainsi, on peut frapper directement la valeur de remplacement pour ces caractères "%", le reste de la valeur par défaut qui était préaffichée n'étant pas impactée.

Remarque : les codes sections définis dans le plan comptable comportant un ou plusieurs caractères "%" (caractère joker) sont ignorés dans les traitements entièrement automatiques. En effet, ces codes doivent impérativement être traités en saisie, pour remplacer les caractères joker par des caractères autres, de telle sorte que le code corresponde au final à une section existant réellement.

C'est le cas des traitements suivants :

- Génération des écritures d'abonnement

- Comptabilisation des OD automatique de différence de lettrage

- Comptabilisation des OD automatique de différence de change

- Interface standard (lorsque la section n'est pas renseignée dans le fichier d'écritures reçu, et que l'on a demandé à compléter les codes sections à partir du plan comptable).

En conséquence, il est déconseillé d'utiliser des caractères joker pour définir une section par défaut sur les comptes utilisés pour les abonnements, les OD de différence de lettrage (comptes définis dans la Fiche Société, onglet Lettrage) ou de change (Fiche Société, onglet Devise).

En saisie d'une fiche Immobilisations, si on allait modifier la quantité sur une immobilisation issue d'une procédure de reprise, par exemple passer la quantité de 1 à 2 (dans le cas où la quantité a été reprise systématiquement à 1, et qu'on souhaite ensuite corriger celle-ci pour se rapprocher de la réalité), le plan d'amortissement recalculé suite à la modification de la quantité était faux.

Cela était dû au fait que dans le fichier des Immobilisations, on dispose de 2 zones Quantités : la quantité que l'on voit sur l'écran de saisie, et celle qui a été reprise (renseignée uniquement en cas de reprise). Le fait de modifier l'une sans toucher l'autre provoquait un effet de bord (un peu comme une cession négative) ; le plan d'amortissement se voyait allongé d'autant. Par exemple, si la quantité passait de 1 à 2, la durée totale d'amortissement était doublée.

Pour éviter cela, le système reporte la différence saisie sur la quantité (celle apparaissant à l'écran) aussi sur la quantité reprise (zone masquée n'apparaissant pas à l'écran), mais uniquement si cette quantité reprise est renseignée initialement.

La nouvelle zone ajoutée en haut de l'écran de consultation d'un compte par la correction 219, permettant d'ignorer les écritures d'abonnement et de situation, était mal ancrée dans le cas d'un dossier où le module Devises n'était pas activé.

Deux boutons Tout pointer et Tout dépointer ont été ajoutés au bas de la fenêtre. Ceux-ci permettent respectivement de pointer ou dépointer toutes les écritures affichées sur l'écran de lettrage.

Suite à la correction N° 221, il n'était plus possible de saisir un code section analytique par défaut dans le plan comptable ; seuls les codes sections comportant un caractère joker (le caractère "%") étaient acceptés.

Il est désormais possible de s'identifier sur un port SMTP et de passer par un port autre que celui par défaut (25) lors de l'envoi des relances par mail.

Dans le paramétrage des données SMTP, il est possible de spécifier un nom, un mot de passe et le port.

Dans le menu de gauche de la fenêtre principale, le menu fournisseur affichait la liste des menus clients.

Lorsqu'on n'effectuait pas la comptabilisation des immobilisations avec la procédure automatique de LDCompta (Menu Traitement / Immobilisations / Comptabilisation), on ne pouvait pas effectuer la clôture des immobilisations.

Dorénavant, un double message demande confirmation avant de clôturer si la comptabilisation n'a pas été faîte.

Les sociétés archivées n'apparaissent plus dans la liste des sociétés pour lesquelles on souhaite intégrer les relevés bancaires.

Suite à un problème de compilation, le correctif 229 était défaillant.

Lors de l'édition d'un relevé de compte client, les écritures étaient triées par date, mais à date égale, il n'y avait pas de tri par ordre d'arrivée.

Désormais, un tri complémentaire par N° d'écriture est réalisé ; ainsi, à date égale, on trouve en premier lieu les écritures les plus anciennes (en date de saisie). C'est le même ordre que celui présenté en consultation de compte par exemple.

Une modification du même ordre a été faite dans la procédure de modification des relances client par client.

Suite à la correction 216, il y avait encore un problème d'impression lorsque l'on avait des lettres de relance avec relevé séparé.

Ce problème était du au fait que l'on n'avait pas réintégré la bonne version des sources de programme.

L'édition d'un journal très volumineux (plus de 1000 pages) provoquait un plantage (débordement de zone mémoire).

Cela était du à un problème sur les zones de tri du journal ; celles-ci s'étaient multipliées lors de la migration de l'état de Windev 8 à Windev 12 (passage de LDCompta V8.50 à V9.00). Les 3 critères de tri étaient répétés un grand nombre de fois, ce qui donnait plus d'une centaine de critères de tri.

En remettant les critères de tri corrects, tout est rentré dans l'ordre (si l'on peut dire !).

Suite à la migration V8 à V9, l'export Trésorerie du flux CHQ (Chèques) ne fonctionnait plus (la zone CNTA du fichier de suivi des chèques CPTSCH a été renommée en CNT2 en version 9).

De plus, l'option permettant de lancer l'automate d'export vers la trésorerie a été ajoutée dans le menu Outils. Mais cette option n'apparait dans le menu que si le fichier des paramètres de l'export existe (fichier EXPAUT.INI dans le sous-répertoire Interfaces du répertoire des sous-répertoires de LDCompta).

Un bouton permettant de recalculer les plans d'amortissement de toutes les immobilisations a été ajouté, dans la fenêtre de gestion des immobilisations. Ce bouton Tout recalculer n'est nécessaire que suite à la modification de la durée de l'exercice comptable courant, pour que tous les plans d'amortissement soient réajustés en conséquence.

Bien entendu, les lignes des plans déjà clôturées ne sont pas recalculées. Seules les lignes de l'exercice comptable courant et celles postérieures à cet exercice sont effectivement recalculées pour tenir compte de la nouvelle durée de l'exercice comptable courant.

En sus de cet ajout, une petite correction a été faite dans le calcul d'un plan d'amortissement. Cela concerne le cas où une immobilisation est cédée dans l'année où son amortissement prend fin (par exemple, fin d'amortissement en avril, cession en juin), que l'année en question est clôturée, et que l'on cherche à recalculer l'immobilisation après cette clôture.

Lorsque l'on comptabilisait les immobilisations sur un journal de situation sur une période ne correspondant pas à un exercice, la dotation des immobilisations amorties en dégressif était à 0.

Sur l'état Grand-livre analytique par affaire, les colonnes où apparaissent les zones supplémentaires analytiques Zone 1, Zone 2 (quantité) et Zone 4 ont été élargies.

On peut désormais faire figurer dans la colonne Zone 2 des quantités pouvant aller jusqu'à 999999,999.

Dans une configuration multi-postes, il arrive parfois que tous les postes de travail ne soient pas au même niveau de programmes ; les mises à jour du logiciel LDCompta ont été installées sur un poste et  par sur les autres par exemple. Ce type de situation peut parfois avoir des conséquences néfastes ; il est donc vivement conseillé que tous les postes de travail travaillant sur un même dossier comptable soient dans la même version et au même niveau de programmes. Cela est normalement le cas si on utilise LDUpdate régulièrement pour télécharger les mises à jour du logiciel LDCompta, et que tous les postes de travail sont configurés avec le même répertoire de mise à jour centralisée.

Pour éviter à l'avenir ce type de situation, un contrôle a été ajouté à chaque ouverture d'un dossier comptable. Le système compare la version et le niveau des programmes sur le poste courant par rapport au niveau le plus récent avec lequel le dossier comptable a été ouvert antérieurement. Et si on tente d'ouvrir avec un niveau de programmes plus ancien, un message d'avertissement est émis, décrivant cette situation anormale et demandant à ce qu'une mise à jour du poste de travail soit faite pour y remédier.

Pour réaliser ce contrôle, le système enregistre désormais, à chaque ouverture de dossier, la version et le niveau maximum des programmes utilisés pour ouvrir le dossier, dans le fichier FICINI, mot-clé PGMLastLevel.

Notez que ce nouveau contrôle peut être désactivé en ajoutant la ligne PGMLastLevel=NO dans le fichier LDCParam.INI, section [Données]. Mais cela ne devrait être fait que dans des environnements de test, où l'on utilise en parallèle plusieurs versions/niveaux de programmes.

Notez également que si on a ouvert par erreur un dossier comptable avec un niveau de programmes plus récent que l'on ne souhaite pas conserver, on peut enregistrer l'ancien niveau de programmes (celui que l'on utilise effectivement sur tous les postes) comme niveau le plus récent en tenant la touche Majuscule ou Control enfoncée quand on clique sur OK dans la fenêtre d'avertissement.

Un contrôle supplémentaire a été ajouté en toute fin de la saisie par pièce, juste avant de valider celle-ci.

Ce contrôle consiste à s'assurer qu'un N° de compte est effectivement renseigné sur chaque ligne saisie.

De plus, on recalcule le total des montants Débit-Crédit portés sur les différentes lignes, et on s'assure que ce total est nul (pièce correctement équilibrée), indépendamment des totaux de la pièce figurant déjà sur l'écran, totaux Débit-Crédit qui étaient déjà contrôlés et qui représentent normalement la somme des lignes.

Ces contrôles sont redondants avec ce qui était déjà fait au fur et à mesure de la saisie des lignes ; ils ne devraient donc jamais signaler d'anomalie. Mais ils ont pour fonction de tenter de résoudre un problème récurent depuis de nombreux mois : l'apparition chez certains clients de quelques pièces (extrêmement rares cependant) pour lesquelles le N° de compte n'est pas renseigné, voire  de pièces déséquilibrées (encore plus rare).

Dans la procédure de reprise des immobilisations, il y avait une erreur bloquante empêchant la reprise des immobilisations pour lesquelles il restait un tout petit quelque chose à amortir, pour une durée restante inférieure à 1 mois.

C'est le cas par exemple des immobilisations acquises en janvier (mais par le 1er janvier), lorsqu'on a un exercice commençant en janvier. Si l'immobilisation est acquise le 10/01/2007, a une durée d'amortissement de 3 ans en linéaire, et qu'on fait une reprise au 01/01/2010, on a déjà amorti 36 mois. La durée restant à amortir est donc de 0 mois, bien qu'il reste une base à amortir.

Le contrôle qui signalait dans ce cas une incohérence entre le montant restant à amortir et la durée restant à amortir (qui était nulle) a été assoupli. On vérifie désormais si il reste ou pas quelques jours à amortir.

Dans la saisie de l'échéancier fournisseur, on a accès désormais au bouton Consulter même si la ligne en cours de saisie est incomplète (par exemple, seul le N° de compte est renseigné).

Il n'était pas possible de supprimer un bordereau de remise en banque pour les banques ayant un n° de compte transitoire.

Le programme envoyait systématiquement une erreur :

Le lot d'écritures correspondant à ce bordereau ne peut être identifié.

La suppression du bordereau est donc impossible.

Diverse améliorations ont été apportées à la fenêtre d'intégration des relevés bancaires.

L'objectif principal était d'améliorer les traces de ce qui est fait par cet automate.

Et de tenter de corriger un problème de mise en sommeil de celui-ci lorsque cet automate reste actif sur un PC plusieurs jours sans que le PC ne soit redémarré. Pour cela, le mécanisme de gestion  des timers a été revu : là où on utilisait avant 2 timers (un pour l'attente entre 2 plages d'activation du serveur, l'autre pour déclencher le traitement d'intégration à la fréquence demandée au sein d'une plage horaire où le serveur est "actif"), on n'utilise plus qu'un seul timer qui joue les deux rôles alternativement.

La correction N° 242 avait introduit un contrôle supplémentaire en toute fin de la saisie par pièce, juste avant de valider celle-ci.

Le système recalcule à ce stade le total des montants Débit-Crédit portés sur les différentes lignes, et s'assure que ce total est nul (pièce correctement équilibrée), indépendamment des totaux de la pièce figurant déjà sur l'écran, totaux Débit-Crédit qui étaient déjà contrôlés et qui représentent normalement la somme des lignes.

Toutefois, ce nouveau contrôle, redondant avec ce qui était déjà fait au fur et à mesure de la saisie des lignes, posait problème dans le cas des pièces saisies en multi-devises.

Ce nouveau contrôle a donc été aménagé pour fonctionner correctement même en cas de pièce multi-devises.

Dans l'état de situation, si l'on demande d'ignorer les immobilisations complètement amorties sur une période close, toutes les immobilisations complètement amorties dans l'exercice courant étaient masquées.

Dorénavant, on vérifie si l'immobilisation a une ligne d'amortissement comprise dans la période demandée. Si ce n'est pas le cas, elle est ignorée.

En environnement Client/Serveur AS/400, le blocage des enregistrements ne fonctionnait pas correctement. On pouvait par exemple ouvrir simultanément en modification la même fiche client depuis deux postes différents.

Ce problème était dû à Easycom Version 12 ; suite à une optimisation, la gestion des erreurs de blocage se faisait mal sur un ordre de lecture effectué par N° d'enregistrement et non par clé (HLit et non pas HLitPremierRecherche).

Pour corriger cela, il faut réinstaller une version plus récente d'Easycom : Version 12.0.0.22 en lieu et place de la version 12.0.0.19 utilisée jusqu'alors. Cette version est installée automatiquement dans le répertoire des programmes via ce correctif.

Parallèlement à cela, une petite modification a été faite pour diminuer le temps d'attente en cas de verrouillage d'un enregistrement, en environnement AS/400. Sachant que le délai d'attente d'un enregistrement bloqué est de 30 secondes par défaut sur AS/400, LDCompta effectue désormais une seule tentative (au lieu de 10 auparavant) avant d'afficher le message signalant que l'enregistrement est verrouillé, et demandant si l'on veut refaire une tentative.

Dans la procédure de consultation d'un compte, dès lors qu'on utilise une vue (vue publique ou privée, autre que la vue standard), la colonne Date échéance reste positionnée à l'endroit prévu dans la vue, et ne change donc plus de place en fonction du mode d'affichage Devises ou Euros comme c'était le cas auparavant.

Seules les colonnes Code lettrage, Montants, Code devise et Cours devise ont un positionnement qui dépend de ce mode d'affichage, et qui ne tient donc pas compte de ce qui est fixé par la vue.

Lors de la création d'une société avec copie des paramètres d'une autre société, si la dernière société apparaissant dans la liste des sociétés était un dossier d'archives, la société créée était elle aussi créée en tant que dossier d'archives, avec les mêmes valeurs (Code société archivée et Exercice archivé) que la dernière société apparaissant dans la liste.

Les lignes de CA n'ayant pas de tiers (pièce comptable mouvementant uniquement un compte de classe 6 ou 7 d'une part, et la banque en contrepartie par exemple) apparaissent sur les états de chiffres d'affaire avec un code tiers "********".

Jusqu'alors, en regard de ce code tiers, on trouvait le libellé du premier client ou fournisseur. On aura désormais un libellé plus explicite : <Pièces sans tiers>

Sur les lettres BO fournisseurs, la police de caractères utilisée pour la partie haute du bordereau (nom et adresse des sociétés émettrice et destinataire du paiement notamment) n'était pas la bonne, sauf sur la première page. Sur les pages suivantes, le système reprenait la police utilisée pour imprimer le titre de paiement, en bas de page (police en gras).

Cette modification concerne  le fichier RFABO.txt, qui contient le source de la procédure d'impression qui est compilée dynamiquement. Si ce source a été adapté en spécifique, il faut reporter la correction dans le source "spécifique" ; pour cela, il suffit d'ajouter la ligne suivante (celle qui est en rouge) , au début de la procédure d'impression de l'en-tête :

[Impr_Entete]

PROCEDURE Impr_Entete ()

CompteImprimé est une chaine

TexteImprimé est une chaine

iPolice(1)// Ajouté le 28/10/2010 - Correction V9 N267

// Adresse société

iPosY(17-MargeV)

Dans la fenêtre permettant de gérer les sociétés, on fait apparaître désormais le nom de la bibliothèque contenant les données sur AS/400, dans le cas des dossiers gérés en environnement Client/Serveur AS/400.

En effet, depuis la version 9, le nom de la bibliothèque est totalement libre ; il peut donc s'avérer utile de le retrouver facilement sur cet écran.

Sur certains écrans de saisie ou d'affichage, ainsi que sur certains états, le masque de saisie/affichage du cours devise n'était pas correct : soit on était limité à 2 chiffres pour la partie entière (insuffisant pour le Yen), soit on n'affichait qu'une partie des 7 décimales possibles.

Dans le mode de relance client version dite NEW, où le niveau de relance se calcule en fonction d'un nombre de jours de retard, on peut désormais indiquer un nombre de jours de retard en négatif.

Cela permet de déclencher une "pré-relance", avant même que la date d'échéance ne soit atteinte.

La correction 266 a rendu possible l'envoi des bordereaux de paiement par mail.

Cette correction 271 apporte deux choses :

1) les informations "nominatives" (nom  et adresse du fournisseur, banque de paiement, ou même montant du virement) que l'on faisait apparaître dans l'objet ou le corps du mail étaient désynchronisées par rapport à celles contenues dans la pièce jointe. Dans le corps du mail, les informations qui apparaissaient étaient celles du bordereau précédent. Et sur le premier bordereau, c'étaient celles du dernier bordereau ayant été affiché auparavant dans l'aperçu avant impression.

2) des messages spécifiques sont présentés lorsqu'on est dans des situations particulières :

- il n'y a aucun bordereau de paiement répondant aux critères de sélection indiqués (mauvaise sélection)

- il y a aucun fournisseur ayant une adresse mail parmi tous les bordereaux répondant aux critères de sélection

Lors de la création d'une société sans copie depuis une autre société, LDCompta utilise un jeu de valeurs par défaut qui est fourni dans le répertoire des programmes (fichiers INIXXX).

Certaines valeurs fournies dans ces fichiers étaient décalées depuis le passage en version 9 (en raison de la gestion différente des espaces au sein des rubriques de fichiers entre LDCompta V8.50 et LDCompta V9.00).

Cela posait problème notamment pour activer le module Devises : on ne pouvait choisir le code de la devise de référence !

3 paramètres programmes ont été corrigés :

- CPDEVI : paramètres du module Devises

- CPSECP : Paramètres par défaut de la saisie par pièce

- CPBREL : Paramètres par défaut de recherche des clients à relancer

Sur les balances auxiliaires imprimées en format horizontal, certains cadres étaient incomplets : le trait de bas de page et certains cadres en fin d'état ne s'étalaient pas sur toute la largeur de l'état.

La sélection d'un intervalle de comptes clients ne fonctionnait pas dans ce module en environnement Client/Serveur AS/400.

L'édition des lettres de relance dans le mode Une lettre par niveau ne fonctionnait pas en environnement Client/Serveur AS/400.

Depuis la version 9.00, sur l'état de l'en-cours financier, la présence de traites à l'acceptation pouvait provoquer des erreurs de calcul de l'en-cours. On retrouvait dans certains cas le montant de la traite à l'acceptation apparaissant 2 fois : une fois au crédit (juste) et une fois au débit (fausse).

Dans les fenêtres de liste (pour gestion) et de sélection des clients et fournisseurs, lorsqu'on demande un tri par code postal ou ville, il y a un filtre complémentaire qui est possible sur la raison sociale.

Il y avait une toute petite anomalie : le libellé qui apparaissait en regard de cette zone de filtre était Nom et non pas Raison sociale, alors que le filtre s'appliquait bien sur la raison sociale. Ce libellé a été modifié.

Pour les modes de paiement indiqués dans la liste complémentaire des autres modes de paiement entrainant une comptabilisation tous journaux confondus (bouton + sur onglet Règlements des Paramètres journaux), il n'y avait plus d'impression suite à la correction 266 (envoi des bordereaux par mail).

Dans la fenêtre présentant en aperçus les documents (lettres de relance ou bordereaux de paiement fournisseur) qui vont être envoyés par mail, on a désormais la possibilité de demander aussi une impression, de façon à conserver une copie papier de ce qui va être transmis par mail. Pour cela, les 2 boutons d'impression sont à nouveau accessibles en haut à gauche de la fenêtre d'aperçu.

Les autres boutons (Word, Excel, PDF, Email PDF...) restent masqués dans cette fenêtre d'aperçu pour éviter toute confusion : l'envoi du mail avec document PDF en pièce jointe est entièrement piloté par le programme, sans qu'il n'y ait rien de particulier à faire dans cette fenêtre d'aperçu.

En création d'une fiche Immobilisations, dans le mode "Saisie guidée" ou "Saisie à la volée" depuis la saisie pièce, le libellé de l'immobilisation est préaffiché à partir du libellé de l'écriture comptable sous-jacente.

Dans ce cas, ce libellé s'affichait bien sur le 1er onglet de la fiche, mais pas sur les autres onglets.

2 choses ont été modifiées concernant la saisie des observations dans les fiches Immobilisations :

1) dans la fiche Immobilisation elle même, le champ de saisie Observations sur le dernier onglet était mal ancré ;

2) en saisie d'une cession, le champ Observations ne proposait pas la barre d'outils permettant une mise en forme (RTF).

Le code BIC est désormais contrôlé :

- il est obligatoire si l'on a renseigné un IBAN

- il est interdit dans les autres cas

L'affichage a été revu pour les différentes fenêtres.

Si l'on affiche un RIB, le masque utilisé sera : XXXXX XXXXX XXXXXXXXXX XX

Si l'on affiche un IBAN, le masque sera : XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX etc...

Différentes petites modifications de formes ont été faites sur la balance analytique, concernant l'édition triée par compte/section :

1) un bloc de rupture à chaque nouveau compte est désormais imprimé, ce qui facilite la lecture

2) les clics sur les champs Compte et Section sont correctement gérés

3) dans l'en-tête de page, les mentions Compte et Section sont inversées pour bien refléter le critère de tri qui a été choisi

4) la hauteur du bloc de totalisation par section a été réduite de 2mm.

Dans un grand livre analytique par section, les montants de certaines lignes pouvaient être totalisées dans un autre compte ayant les 6 premiers caractères identiques.

Par exemple, un compte 70680000 était totalisé avec le compte 70680007.

La migration des données de la V9.00b à V9.00c ne contenait pas certains fichiers nécessaires à un module en cours d'écriture. Ce module n'étant pas disponible à ce jour, les migrations ayant été faites sans cette correction ne poseront toutefois aucun soucis et ne nécessitent pas d'être re-migrés.

Sur l'état de situation des immobilisations, les N° de comptes comportant 8 chiffres étaient tronqués (seuls les 7 premiers chiffres étaient imprimés) sur le bandeau de totalisation par compte.

Dans le cas où un document était numérisé ou déplacé depuis un autre répertoire, si le répertoire de destination n'existait pas, le document se trouvait référencé dans la GED mais inaccessible car le répertoire associé au tiers n'était pas créé.

Lorsqu'on supprimait une cession, le plan d'amortissement de l'immobilisation n'était pas recalculé. On conservait le plan d'amortissement qui avait été calculé avec la cession, alors que la cession avait bien disparu du fichier des cessions (IMOCES), et que la quantité cédée avait été effacée de la fiche immobilisation (IMOIMO).

Dans l'état du chiffre d'affaire, le pourcentage affiché en dessous de chaque montant correspondait au pourcentage du total cumulé de la ligne et non pas au pourcentage du montant.

Deux problèmes ont été corrigés dans la procédure de comptabilisation des immobilisations. Cela concernait dans les deux cas la proratisation du montant de l'amortissement, lorsqu'on demandait une comptabilisation pour une partie de l'exercice seulement.

Avec les deux corrections qui ont été faites, on a désormais égalité parfaite entre les montants comptabilisés et ceux figurant sur l'état de situation, à période égale.

Dans la procédure d'export des données en format texte, les fichiers d'environnement ne sont désormais accessibles qu'aux profils  de type Administrateur (tous les utilisateurs cochés Administrateur de sécurité dans la fiche Utilisateur ont ce profil).

De plus, même si un administrateur exporte le fichier des utilisateurs (fichier CPTUTI), le mot de passe n'est pas exporté en clair ; la valeur est remplacée par des *.

Dans certains cas, en environnement Client/Serveur, certains rapprochements bancaires anciens, bien qu'ils aient été réalisés en version 9, n'étaient pas proposés dans la fenêtre de liste des rapprochements pouvant être réimprimés.

Dans la fiche client, le contrôle d'existence du code TVA n'était effectué qu'à la seule condition que le module devise soit actif. Un code invalide était donc accepté.

Au niveau de l'interface, ce code n'était tout simplement pas contrôlé et n'importe quelle valeur pouvait être intégrée.

Dans certains cas, le plan d'amortissement pouvait intégrer une cession qui n'avait pas lieu d'être, faussant ainsi le calcul ou le recalcul.

Le texte du corps du mail généré a été modifié en cas de relevé négatif.

De plus, il est désormais possible de choisir d'envoyer la lettre de paiement en pièce jointe du mail ou de l'imprimer.

Certains fichiers peuvent avoir un caractère spécial SUB situé tout en fin de fichier. De ce fait, la taille en octets du fichier n'est pas un multiple de 120, 121 ou 122 caractères.

Ces fichiers sont désormais gérés par l'outil d'intégration des relevés bancaires. Auparavant, pour de tels fichiers, l'outil indiquait qu'ils étaient encore en cours de création, la taille du fichier ne correspondant pas à ce qui était attendu.

On remplace par un espace toutes les tabulations présentes à tort dans le libellé, le n° de pièce ou la référence d'une écriture. Cette protection est désormais en place pour toutes les écritures ajoutées quel que soit le mode de saisie (saisie pièce, folio, règlements, interface...), ainsi que lors de la modification de pièce.

Dans l'outil de correction des écritures, (outil accessible par le bouton Edition dans la fenêtre d'interface avec d'autres applications), on ne pouvait pas valider une écriture dans les conditions suivantes :

- l'écriture a une ventilation analytique sur plusieurs sections (n° de séquence renseigné à 1)

- le compte a une section et un code affaire par défaut.

En modification, il fallait que la section et le code affaire ne soit pas renseigné car elle avait le n° de séquence 1. Cependant, la validation ou la correction du code section et du code affaire remettait la valeur par défaut du compte.

Dorénavant, on ne peut pas saisir de section ou de code affaire pour une écriture ayant un n° de séquence à 1 et le remplissage ce des zones par les valeurs par défaut a été désactivé pour ces écritures.

De plus, le contrôles des dates comptables par rapport aux comptes pouvaient ne pas fonctionner.

Normalement, si la clé d'un RIB n'est pas renseignée, le système doit laisser passer ce RIB dans les fiches clients et fournisseurs, ainsi que dans l'interface. Cependant, cela ne se faisait pas et LDCompta affichait un message d'erreur pour tous les RIB sans clé.

Une procédure de reprise des Immobilisations gérées par le logiciel P7IMMO Windows a été développée. Elle est conçue sur le même modèle que la reprise faite pour le logiciel; P7IMMO AS/400. Mais là, on lit directement la base HyperFile utilisée par P7Immos Windows. Et comme la structure de cette base est assez différence de celle de P7IMMO AS/400, la procédure de reprise a été pas mal revue pour ce qui est des données "chiffrées".

La fenêtre à lancer pour effectuer cette reprise est iP7RepIMOw.

Reportez vous à la documentation Migration Immos PROGI7.doc pour les grandes lignes de l'utilisation de cette fenêtre, sachant que cette documentation décrit la reprise depuis P7Immos AS/400 ; la documentation n'a pas été revue pour P7Immos Windows, et ne correspond donc pas exactement à ce cas de figure.

Le n° de chèque était demandé pour chaque relevé imprimé et non une seule fois en début de traitement.

De plus, suite à la modification de niveau 309, le programme créait un virement pour chaque règlement par chèque au lieu de ceux par virement.

Un bouton Contrepartie a été ajouté sur l'écran de saisie de la ventilation analytique d'une écriture de comptabilité générale.

Dans la procédure de saisie des règlements fournisseurs, en cas d'escompte automatique, le montant de la TVA qui était calculé était faux. Le montant TVA était calculé en appliquant le taux de TVA sur le montant TTC de l'escompte ; il était donc trop fort.

Cette erreur, bien que très ancienne (2003) n'avait jamais été signalée car la différence due à la formule de calcul ne devient significative que sur des montants réglés importants, et/ou des taux d'escompte importants.

Lors de la préparation du fichier au format SEPA (virement SCT), le total de contrôle était inscrit sans décimales. Le fichier était donc bloqué par la banque à l'arrivée, car ce total était différent de la somme des virements unitaires portés dans le fichier.

Dans le fichier des sections et sous-sections analytiques (fichier CPASEC), pour les dossiers créés en environnement AS/400 "caractère", la présence d'un enregistrement correspondant à la section n'était pas obligatoire (mais possible quand même). On pouvait ne créer que les enregistrements correspondant aux sous-sections.

Cela posait problème lorsqu'on basculait d'un environnement AS/400 "caractère" à un environnement Client/Serveur ou même "full Windows". En effet, la procédure de saisie des sections et sous-sections analytiques de l'environnement Windows ne peut fonctionner que si ces enregistrements "Section" existent effectivement dans le fichier CPASEC. Ces enregistrements sont considérés comme des lignes de "titre" et sont indispensables.

Pour éviter d'avoir à régler ce problème au cas par cas, cette correction a pour effet, à chaque première ouverture de dossier comptable faisant suite à l'installation de ce correctif, de contrôler la présence de ces enregistrements "Section" dans le fichier CPASEC, et de créer ceux qui seraient manquants.

Lorsqu'on cédait une immobilisation en plusieurs fois, on pouvait rencontrer un problème en raison de différences d'arrondi sur la somme des quantités cédées antérieurement.

L'envoi des relevés provoquait un message et était interrompu (avant l'envoi réel des relevés par mail) si on n'imprimait pas les lettres de paiement ou si l'ensemble des relevés à imprimer étaient négatifs.

En environnement Client/Serveur AS/400, il y avait un problème avec le filtre sur la date de début. Les écritures passées à cette date de début n'étaient pas sélectionnées.

En cas d'erreur lors de l'envoi d'une lettre de relance ou d'un bordereau de virement par mail, le système affiche désormais davantage d'informations, et notamment le N° et le nom du tiers sur lequel se produit l'erreur, ainsi qu'un message d'erreur plus détaillé (sachant que la cause la plus fréquente est une adresse mail mal formatée).

Le bordereau de virement a été modifié. Désormais, il indique :

- si le virement utilise la norme SEPA (SCT)

- l'IBAN complet ainsi que le BIC si ces informations sont renseignées

Lorsqu'on édite un ordre de virement fournisseur, on affiche désormais l'IBAN et le BIC complet du fournisseur si ces informations sont renseignées.

En modification d'écritures par pièce, le bouton Contrepartie est désormais grisé si le montant de l'écriture n'est pas modifiable (cas d'une écriture lettrée ou rapprochée par exemple). Jusqu'alors, ce bouton était actif, et permettait donc indirectement de modifier le montant.

On ne tenait pas compte du sens débit/crédit des échéances. Du coup, les écritures au crédit du compte client étaient considérées comme des écritures au débit.

Une amélioration a été apportée dans la procédure permettant d'intégrer des écritures comptables au format PNM.

Cela concerne le N° de tiers. On peut désormais :

- ajouter un préfixe et/ou un suffixe au N° reçu dans le fichier PNM

- pour les N° comportant moins de caractères, on peut désormais indiquer un caractère qui est utilisé en complément, à droite, pour obtenir les 5 caractères minimum obligatoires pour un N° de tiers dans LDCompta (jusqu'alors, LDCompta ajoutait un ou plusieurs 0 à gauche).

De plus, les comptes généraux sont automatiquement tronqués à 7 ou 6 caractères, en fonction de ce qui est défini dans le Plan comptable. Ainsi, si le compte reçu dans le fichier d'interface et 70710000, et que dans LDCompta, les comptes 70710000 et 7071000 n'existent pas et que le compte 707100 existe, c'est ce dernier qui sera utilisé.

Pour mettre en oeuvre ces nouvelles possibilités, il faut renseigner des choses supplémentaires dans la définition des comptes collectifs.

Consultez la documentation de l'interface au format PNM, document IntPNM.doc, révision 2.1 d'avril 2011.

Suite à la correction 329, un champ contenant l'IBAN du premier virement de la liste était affiché au niveau de l'entête.

Ce champ a été supprimé.

Il est désormais possible de numériser un document constitué de plusieurs pages.

Après la numérisation de chaque page, LDCompta demande s'il faut oui ou non ajouter une nouvelle page.

Sur les différents écrans de consultation (compte, pièce, référence, journal), lorsque le module Devises était inactif et que l'on avait sélectionné l'option Grandes polices de Windows, certains champs étaient mal disposés en partie haute et pouvaient même dans certains cas se superposer.

Deux améliorations ont été apportées dans les procédures d'édition des bordereaux de règlement :

1) pour les différents bordereaux de paiement proposés en standard, on peut désormais paramétrer l'impression de l'en-tête société sans avoir à modifier le source du bordereau d'impression. On peut également faire apparaître, en sus de l'adresse la société émettrice du bordereau, faire apparaître le N° de téléphone, le N° de télécopie et l'adresse mail qui figurent dans la Fiche Société. Ces données apparaissent juste sous l'adresse, dans une police de caractères un peu plus petite. Cela se paramètre, pour chaque bordereau, dans la Fiche Société, onglet Formulaires.

Bien entendu, ces deux options ne sont disponibles que si vous utilisez les formulaires "standard". Si vous avez réalisé une adaptation spécifique de ceux-ci, en copiant ceux livrés en standard dans un autre répertoire, cette amélioration sera sans effet. C'est toujours le bordereau "adapté" en spécifique qui s'imprimera.

2) pour les bordereaux de règlement par virement (bordereau RFAVI.txt), une nouvelle option permet de faire apparaître la date d'exécution du virement. Cela peut être pratique quand on prépare des virements plusieurs jours à l'avance. On peut ainsi adresser le bordereau le jour où on l'a préparé, même si le virement sera exécuté plus tard. En effet, en choisissant cette option dans la Fiche société, onglet Formulaires, pour le mode de règlement correspondant aux virements, le bordereau imprimé portera toujours la date du jour de l'impression en partie haute (sous l'adresse du destinataire), et la date comptable du règlement (ou la date de réédition en cas de réédition) avec la mention "en date d'exécution au JJ/MM/AAAA" dans le corps du bordereau, après la domiciliation du bénéficiaire.

La aussi, si vous avez réalisé une adaptation spécifique du bordereau Lettre-Virement, cette amélioration sera sans effet. C'est toujours le bordereau "adapté" en spécifique qui s'imprimera.

Lorsqu'on imprime la liste des virements nationaux, si un IBAN est renseigné pour le compte de la banque concernée, il est correctement formaté, c'est à dire par bloc de 4 caractères et le code BIC n'est plus collé. Il est séparé par un tiret (-). Si seul le RIB est renseigné, il est formaté par des blocs de tailles 5 - 5 - 11 - 2.

Les IBAN de plus de 23 caractères (limite des IBAN pour les comptes bancaires français) n'étaient pas enregistrés correctement dans leurs fiches respectives (client, fournisseur, banque, ...)

En gestion du portefeuille de règlements clients, il est possible de modifier l'échéance d'un règlement. Dans ce cas, la nouvelle échéance du règlement est répercutée sur l'écriture comptable dans le compte client. Et depuis la version 9, cette nouvelle échéance est aussi répercutée sur la contrepartie de ce règlement, qui se trouve dans le compte de portefeuille (413000 par exemple).

Pour cela, on s'appuie sur le N° de lot trouvé pour l'écriture de règlement au compte client. Mais cela pose problème si le règlement qui se trouve toujours en portefeuille a une date comptable antérieure à la date de dernière clôture. En effet, dans ce cas, l'écriture au compte client a été basculée sur le journal des à nouveaux par le traitement de clôture, et le N° de lot que l'on observe sur cette écriture correspond au lot des à nouveaux. Il ne faut donc pas dans ce cas répercuter la date d'échéance sur toutes les écritures du lot.

C'est donc ce qui est fait suite à cette correction : le report de la nouvelle date d'échéance se fait toujours sur l'écriture au compte client, mais la ou les écritures de contrepartie ne sont modifiées que si le code journal de l'écriture est autre que celui des à nouveaux.

Remarque : le problème évoqué était assez rare : les règlements en portefeuille ont en principe une durée de vie maximale de 90 jours (échéance du règlement). Et comme il s'écoule toujours au moins 3 mois entre la date d'arrêté de l'exercice et la date à laquelle on effectue réellement la clôture, il ne reste en principe au moment de la clôture plus aucun règlement en portefeuille ayant une date comptable antérieure à la date d'arrêté de l'exercice.

Lors d'une interface de données vers LDCompta, une erreur pouvait se produire si :

- on a indiqué dans la fiche société que l'on peut utiliser des comptes ayant plus de 6 caractères

- que les deux premiers caractères de l'un des comptes interfacés correspondent à un code racine existant dans le dossier

En lieu et place de cette erreur devait s'afficher un avertissement indiquant que le compte général ne serait pas accessible s'il existait un compte de tiers ayant le même numéro de compte (Racine du collectif + numéro du tiers).

Dorénavant, l'avertissement s'affiche correctement.

Sur les balances âgées, lors d'une demande d'impression sans sélection d'un compte collectif particulier, et lorsqu'on avait plus de deux comptes collectifs et que l'ordre alphanumérique des codes racines utilisées ne correspondait pas à l'ordre des comptes collectifs associés à ces racines, certains comptes collectifs pouvaient être omis de la balance.

La copie d'une lettre de relance en environnement Client/Serveur AS/400 fonctionnait mal : certains champs de la lettre de relance n'étaient pas copiés.

Détail technique : en fait, tous les champs déclarés comme étant de type "Mémo texte" n'étaient pas copiés. Il semble que ces champs ne soient lus par Easycom que lorsqu'il y a accès explicite à ceux-ci. Pour contourner ce problème, on a ajouté une lecture explicite (transfert de la valeur rubrique dans une variable de programme) des 4 champs de type "Mémo" de ce fichier entre la lecture de la lettre à copier et l'écriture de la nouvelle lettre copiée. Et là, ça marche.

Le dernier répertoire utilisé pour l'acquisition d'un fichier dans la GED est désormais mémorisé dans la base de registre du poste de travail, et non plus dans les paramètres du dossier comptable courant.

En effet, ce chemin d'acquisition n'a de sens que pour un poste de travail donné (chemins réseaux notamment), et pouvait poser problème si on tentait d'accéder à ce chemin depuis un autre poste de travail.

Détail technique : le chemin est mémorisé via la fonction Windev SauveParamètre ; la donnée est enregistrée dans la clé HKEY_CURRENT_USER\Software\LD SYSTEME\LDCPTV9\GED\RepAcquisition.

Un nouveau mode de calcul des échéances est désormais possible. Il permet de faire un calcul en nombre de jours net même lorsque le nombre de jours demandés est un multiple de 30. En effet, jusqu'alors, si on spécifiait un délai de 30, 60 ou 90 jours, le système additionnait 1,2 ou 3 mois calendaires à la date de départ, et non pas 30, 60 ou 90 jours calendaires.

Exemples de calcul :

Date de départ       30 jours       30 jours Net

15/07/2011            15/08/2011   14/08/2011

31/07/2011            31/08/2011   30/08/2011

15/09/2011            15/10/2011   15/10/2011

Cette correction avait déjà été faite dans LDNégoce, en version 4.00 Niveau 56.

Pour indiquer que l'on souhaite un calcul en nombre de jours Net, il faut spécifier la valeur Nombre de jours net dans la zone Type de décalage.

Remarque : la différence entre le le type de décalage Aucun et Nombre de jours net ne se fait que lorsque le nombre de jours indiqué dans le délai de paiement est un multiple de 30, et que le délai de paiement couvre une période comportant au moins un mois n'ayant pas exactement 30 jours. Dans tous les autres cas, ces deux codes décalages donnent le même résultat (exemple 3 ci-dessus).

Suite à la correction N° 351, le jour de paiement ne pouvait être supérieur au 15 si l'on choisissait un délai de paiement avec report Fin de mois. Le jour de paiement maxi autorisé était aussi erroné en cas de report Fin de quinzaine, Fin de décade, ou sur un jour de semaine précis. Mais ces 3 cas sont beaucoup plus rares.

Les IBAN étrangers ne pouvaient pas être interfacés. Le système détectait une erreur de RIB.

Dans le commentaire de 140 caractères transmis à chaque destinataire d'un ordre de virement SEPA, LDCompta inscrit la liste des factures réglées par le virement. Cette liste de N° de factures était constituée avec un séparateur ";" (point virgule).

Exemples : "Factures F1253;F1895;F1905"

Or, il s'avère à l'usage que le point virgule ne fait pas partie du jeu de caractères Latin de base préconisé pour les échanges SEPA. Ce caractère n'est pas interdit, mais il se peut que certains systèmes d'information traitant les virements SEPA ne sachent pas traiter ce caractère : celui-ci peut alors être remplacé par un autre caractère faisant partie du jeu de base (la virgule si le système en question respecte les règles de bonne pratique édictées par la norme, par un point ou un espace sinon).

Pour éviter toute difficulté éventuelle, ce point virgule a été remplacé par une virgule, caractère qui lui figure bien dans le jeu de caractères Latin de base recommandé par la norme.

La liste des factures sera donc désormais présentée ainsi : "Factures F1253,F1895,F1905"

En consultation de compte, si l'on demandait une période antérieure à l'exercice courant et que l'on affichait le contenu des exercices antérieurs, il n'était pas possible d'accéder directement aux documents de la GED associés à une écriture appartenant à un dossier d'archive.

Si on tentait de modifier, par la procédure de modification d'une pièce, une écriture passée initialement en saisie des règlements clients, en devise, et avec une différence de règlement ou une différence de change, on était bloqué lors de la validation de la modification, avec un message :

Erreur irrémédiable ; le N° de règlement client 0 n'a pas été trouvé.

Dans le format CFONB des relevés bancaires, le montant de la ligne de relevé est formaté par un caractère spécifique sur la dernière position décimale, ce caractère étant représentatif à la fois du dernier chiffre décimal et du signe.

Une correction a été faite pour accepter, sur cette position, les voyelles accentuées "é" et "è" ; bien que ces deux caractères ne soient pas décrits dans la norme CFONB, ils sont parfois reçus dans les fichiers de relevés, en raison de problèmes de conversion de jeux de caractères entre différents systèmes informatiques (grands systèmes IBM qui codifient en EBCDIC, systèmes UNIX et systèmes Windows en ASCII ANSI).

Les caractères "é" et "è" sont donc désormais acceptés, et sont traités respectivement comme les caractères "{" et "}".

Lors de la visualisation ou de l'impression d'un relevé bancaire, depuis la correction 344, on a accès aux informations complémentaires de chaque ligne de relevé (celles qui sont transmises sur les lignes code 05 du relevé bancaire norme CFONB).

Ces informations complémentaires sont assorties d'un qualifiant, que LDCompta restitue également. Toutefois, afin de ne pas surcharger les affichages, si ce qualifiant est simplement LIB, aucune mention de ce qualifiant n'est faite (auparavant, on portait la mention Libellé complémentaire).

Le formatage des zones Référence et Libellé lors de la génération des fichiers de virement ou prélèvement norme CFONB a été revu.

Cas des virements fournisseurs

La référence (maxi 12 caractères) reçoit :

- soit le n° de la facture réglée par le virement, si celui-ci ne règle qu'une seule facture, sous la forme "FAC.12345678", ou "FA.123456789", ou "F.1234567890" (selon le nb de caractère du n° de facture, NB : si le n° de facture commence par "F", le numéro n'est pas préfixé),

-  soit sous la forme "REL. NNNNNN", où NNNNNN est le n° du bordereau de paiement (N° de relevé), si le virement règle plusieurs factures.

Le libellé de 31 caractères est désormais de la forme "VIR. DE XXXXXX", où XXXXXX est la raison sociale de la société émettrice (celle qui est inscrite dans la Fiche Société).

Cas des prélèvements clients

La référence est la forme "REL. NNNNNNN", où NNNNNNN est le n° d'ordre de prélèvement.

Le libellé est de la forme "PRLV. DE XXXXXX", où XXXXXX est la raison sociale de la société émettrice du prélèvement.

Lors de la constitution du fichier de virements fournisseurs à transmettre à la banque, on a dans certains cas le choix du format du fichier généré : CFONB  ou SEPA.

Un contrôle supplémentaire a été ajouté afin d'éviter des erreurs : si le choix a été fait d'un format SEPA, tous les destinataires doivent avoir un IBAN et un code BIC renseigné. A l'inverse, dans le cas du format CFONB, il ne doit y avoir aucun destinataire ayant un IBAN. Ce contrôle est quelque peu redondant : de part tous les mécanismes qui ont été mis en place en amont de cette procédure, un fichier de virements ne devrait jamais comporter à la fois un fournisseur sans IBAN et un fournisseur avec IBAN étranger. Il s'agit toutefois d'une sécurité supplémentaire qui permet en dernier ressort de ne jamais transmettre à une banque un fichier qui serait invalide.

Dans certaines éditions, notamment au l'édition d'un journal format horizontal, une erreur pouvait survenir si un grand nombre d'enregistrements était imprimé (cas testé sur un journal contenant environ 300 000 écritures à imprimer).

L'erreur provoquée est du type "Access violation" sur le module MSVCRT.dll. Il s'agit d'une erreur liée au trop grand nombre de valeurs en mémoire vive.

Dans le cas où les fichiers ont été créés à partir d'un autre nom logique que le nom défini dans l'analyse (c'était notamment le cas dans la migration des dossiers comptables AS400 en Windows, fenêtre OutiF400), si le premier accès à un fichier est fait à partir de son abréviation, l'abréviation ne fait plus référence au bon fichier physique, mais fait référence au fichier logique utilisé lors de la création du fichier.

Une première correction dans ce sens avait déjà été réalisée le 10/02/2010 (seuls les dossiers migrés entre le 24/09/2009 et ce correctif semblent concernés) ; cette correction permet de s'assurer qu'aucun fichier de l'analyse ne puisse plus être accédé en premier par son abréviation.

Les zones "Fournisseur à payer", "Domiciliation bancaire", et "Devise du fournisseur" n'étaient pas remises à blanc dans l'édition de la liste des fournisseurs, si leur valeur n'était pas renseignée pour un tiers. Les valeurs imprimées étaient donc celles du tiers précédent.

Sur l'édition des clients, seule la zone "Devise du client" était concernée par ce problème.

Une modification de l'interface des honoraires (DAS2) a été réalisée afin qu'elle soit conforme à la nouvelle norme N4DS pour les déclarations annuelle de paye (nouvelle version 7.00 de LDPaye disponible au second semestre 2011).

Suite à une différence d'interprétation d'un ordre SQL entre DB2/400 et HyperFile/SQL, le module de Compensation Clients/Fournisseurs ne fonctionnait pas. On avait une erreur au lancement de la fenêtre principale.

Suite à la correction 362 qui a modifié le libellé affecté à chaque prélèvement dans l'ordre transmis à la banque, le fichier CFONB qui était préparé ne respectait plus cette norme CFONB. Le code guichet de l'établissement bancaire était décalé à droite.

Suite à la correction N° 340, il y avait un problème lors de l'impression des bordereaux de paiement liés à un relevé de compensation, si on utilisait les nouveaux bordereaux de paiement sur lesquels l'impression de l'en-tête société est conditionnée par les paramètres de la Fiche Société, onglet Formulaires.

Suite à la correction N° 365, la migration d'un dossier de la version 8.50 à la version 9.00 ne fonctionnait plus, que ce soit à l'ouverture du dossier ou suite à une restauration.

Suite à la modification niveau 362, la référence du virement, s'il ne réglait qu'une seule facture, correspondait soit à la référence document de la facture, soit au n° de pièce de la facture. Mais si aucune de ces 2 zones n'était renseignée, la référence du virement restait à blanc. Or, cette référence est obligatoire dans le cas d'un virement SEPA (zone EndToEndId).

Désormais, la référence du virement, dans ce cas là, sera le n° de bordereau de paiement, comme pour un virement réglant plusieurs factures.

Le fichier des virements internationaux pouvait être refusé par certaines banques, car la date d'exécution du virement et son code devise étaient systématiquement inscrits dans l'enregistrement d'en-tête et dans l'enregistrement de détail.

Or, la norme CFONB, si on l'applique au sens strict, prévoit que ces zones soient renseignées au niveau en-tête ou ligne selon le type de remise effectué (mono ou multi date, et mono ou multi devise). C'est donc ce qui est fait désormais par LDCompta.

D'autre part, si l'IBAN du bénéficiaire n'est pas reconnu comme un "réel" IBAN (code pays différent des 2 premiers caractères de l'IBAN), on remplace les 4 premiers caractères de l'IBAN par 4 espaces, comme indiqué dans la norme.

En validation d'une saisie pièce, si la ligne correspondant au fournisseur avait été supprimée ou modifiée (lors de la saisie), l'échéance générée dans l'échéancier pouvait ne pas correspondre à la pièce saisie au final.

Certains contrôles ont été ajoutés afin de ne pas pouvoir ajouter une immobilisation sans code, ou sans base d'amortissement (si un amortissement est défini).

Dans les fenêtres de gestion (liste des clients, liste des fournisseurs, listes des journaux, ...), le fait d'utiliser la touche Suppr ou Del après avoir sélectionné une ligne de la liste provoque la suppression de l'enregistrement, comme si on avait cliqué sur le bouton Supprimer.

Dans certaines fenêtres, ce fonctionnement provoquait une erreur du type L'élément 'xxxxxx.gBD' est inconnu. (où xxxxxx correspond à un nom de fenêtre).

De plus, sur le plan technique, cette touche Suppr provoquait 2 clics sur le bouton Supprimer successifs (au lieu d'un seul) dans la fenêtre de gestion des fournisseurs, ce qui pouvait conduire à des erreurs.

L'édition des lettres de relance basée sur le nombre de jours de retard (paramètre programme RELANCENEW activé) ignorait complètement le cas où l'on a demandé à avoir un décompte d'agios suite à la lettre de relance, comme cela est possible dans le système de relance "classique".

Suite au précédent correctif, la saisie d'un règlement fournisseur était impossible car la fenêtre de choix des factures à régler s'affiche et se referme aussitôt.

Sur l'impression des lettres de relances, il était possible d'imprimer la référence de la pièce en lieu et place du n° de pièce. Il est désormais possible d'imprimer le N° de pièce ET la référence.

Remarque : cette modification ne concerne que l'impression des lettres de relance avec "relevé inclus". L'état préparatoire des relances n'a pas été modifié (difficile de trouver de la place pour inscrire N° de pièce et référence document sur chaque ligne, sauf à revoir toute la présentation de l'état), de même que les relevés de compte, même lorsque ces relevés sont utilisés en tant que relance (problème de place là aussi, cela obligerait à revoir toute la présentation de l'état).

Dans le cas de l'utilisation du module de relance dit "new" (celui dans lequel le niveau de relance d'une écriture est basé sur le retard en nombre de jours de chaque écriture, et non sur le nombre de fois où une écriture a été relancée), il y avait un problème si on avait choisi d'imprimer une lettre par niveau de relance plutôt qu'une lettre tous niveaux confondus, comme on le fait habituellement. Avec une lettre par niveau, le système faisait apparaître à tort sur chaque lettre les écritures des niveaux précédents.

La génération du règlement issue de la saisie pièce d'achat, fonctionnalité ajoutée dans un précédent correctif, désynchronisait le journal choisi dans la 1ère fenêtre de la saisie pièce avec le journal utilisé pour le règlement. Cela avait pour conséquence, si un seul de ces 2 journaux était à numérotation automatique, en fin de saisie de la facture, de ne pas voir le N° de pièce attribué à la facture d'achat, ou à l'inverse de ne pas pouvoir saisir un n° de pièce pour la deuxième facture saisie, alors que le journal d'achat était à numérotation manuelle.

Le champ contenant le n° de compte auxiliaire a été légèrement agrandi sur l'édition des balances client, fournisseur, et autre auxiliaire, au format "Portrait", au détriment de la ville. Ainsi, ce N° de tiers apparait intégralement, même lorsqu'il composé de 8 caractères alphabétiques.

La nouvelle option permettant d'inclure le décompte d'agios dans le corps de la lettre de relance (voir correction 386) ne pouvait pas, dans certains cas, être activée sur les dossiers n'ayant pas le module devise actif.

Lorsqu'on supprimait un effet à payer (menu Saisie / Gestion des effets à payer, onglet Gestion des effets, bouton Supprimer) et que l'on indiquait Oui à la question de délettrage, une erreur de lettrage venait s'inscrire sur l'écriture de règlement : la date de lettrage était renseignée mais pas le code lettrage.

De plus, si le règlement n'était pas lettré à la base, le lettrage de l'écriture d'annulation avec le règlement ne se faisait pas.

Dorénavant, on se retrouve avec les cas suivants :

- Une ou plusieurs factures sont lettrées mais on ne souhaite pas les délettrer, une ou plusieurs écritures d'annulation non lettrées sont créées.

- Une ou plusieurs factures sont lettrées mais on souhaite les délettrer, une ou plusieurs écritures d'annulation lettrées avec le règlement sont créées, et la ou les factures sont délettrées.

- Aucune facture n'est lettrée. On se retrouve avec une écriture d'annulation lettrée avec le règlement.

L'impression des bilans et comptes de résultat fait appel à un fichier de travail CPTBIR, ou CPTBIRA pour les tableaux de bord analytiques. Ce fichier de travail doit être effacé en début de traitement. Or, dans le cas d'une base HyperFile Client/Serveur, on rencontrait parfois un problème pour effacer ce fichier : un verrou "persistant" interdisait la recréation du fichier, même si ce fichier n'était plus ouvert par aucun poste de travail.

Faute de trouver une explication "logique" à ce problème, celui-ci a été contourné. Désormais, si l'ordre HCréation utilisé pour récréer ce fichier à blanc échoue, on passe une commande SQL delete from CPTBIR pour effacer la totalité des enregistrements dans ce fichier de travail.

Le nom de la fenêtre à appeler en spécifique préalablement à l'interface ne pouvait pas dépasser 10 caractères (nom à définir en position 11 à 20 du paramètre programme CPUIAA). La taille limite de ce nom est désormais de 20 caractères (positions 11 à 30).

Il est également désormais possible d'appeler une fenêtre spécifique une fois la validation de l'interface effectuée.

Le nom de la fenêtre à ouvrir doit être inscrit dans le paramètre programme CPUIAA, en position 41 à 64. La fenêtre reçoit en paramètre le n° de fichier, ouvert, qui vient d'être validé.

La fenêtre n'est appelée que si l'interface a été validée, et avant impression du compte rendu de l'interface.

Dans le cas de l'utilisation de l'automate d'interface, cette fenêtre à appeler après validation du fichier peut être spécifiée par le mot-clé FENETRE_POSTTRAITEMENT dans le fichier des règles, comme on peut le faire pour la fenêtre de prétraitement par le mot-clé FENETRE_PRETRAITEMENT.

Attention : cette correction, bien que portant le N° 396, a en fait été réalisée en deux fois, et n'est donc "complète" qu'avec le niveau 397.

Lorsqu'on exportait un grand-livre par échéance, fournisseurs ou clients, les montants n'étaient pas signés pour les avoirs.

De plus, il y avait une sélection implicite dans tous les cas (sortie papier ou Excel) qui faisait que les écritures sans date d'échéance étaient ignorées. Du coup, le total du grand livre ne pouvait pas être comparé avec celui d'une balance ou d'un grand-livre "classique".

Désormais, ces écritures apparaissent en début d'état, avec une date d'échéance à blanc.

Enfin, uniquement dans le cas de l'export vers Excel, on a ajouté une colonne contenant la banque de paiement habituelle du tiers, celle spécifiée dans la fiche du tiers sur l'onglet Paiement. Et le mode de paiement est complété par celui inscrit dans la fiche du tiers pour les écritures n'ayant pas de mode de paiement (rarissime en fonctionnement "normal" de LDCompta).

Dans la fenêtre permettant de consulter l'historique des modifications de pièce, il y avait une erreur système si on appuyait sur la touche ENTREE.

Lors de la demande de clôture d'exercice, le fait qu'il existait un ou plusieurs folios non validés sur l'exercice à clore empêchait jusqu'alors cette clôture. Désormais, un simple message d'avertissement signale ce fait, mais on peut passer outre.

Les folios ainsi conservés ne pourront bien sûr pas être validés par la suite, car ils vont se trouver sur des périodes closes. Mais ils pourront servir de "modèle" pour copie sur d'autres périodes.

Trois améliorations ont été apportées dans la gestion du portefeuille :

1) on peut effectuer une sélection sur une date d'échéance limite

2) un cumul progressif par échéance est affiché sur l'écran principal

3) un cumul progressif des échéances sélectionnées est affiché sur l'écran présentant le détail des effets à une échéance donnée.

Il était possible d'envoyer les relances client par fax, mais désormais, une nouvelle case à cocher Par fax, ignorer ceux ayant une adresse mail permet de ne pas les envoyer à des clients ayant une adresse mail renseignée.

Cette méthode permet d'effectuer la procédure suivant :

- Envoi des relances par mail aux clients ayant une adresse mail (ne pas imprimer les relances qui ne peuvent pas être envoyées)

- Envoi des relances par fax aux clients ayant un numéro de fax mais sans adresse mail

- Impression des relances pour les clients n'ayant ni adresse mail, ni numéro de fax.

Depuis l'ajout des IBAN dans LDCompta, il n'était plus possible d'enregistrer les domiciliations seules, sans N° de compte (RIB ou IBAN). Cette fonctionnalité est désormais de retour.

Suite à la correction N° 388, on peut faire apparaître, dans le corps d'une lettre de relance, le N° de pièce et la référence document de chaque écriture relancée.

Or, si ces deux identifiants étaient composés de 10 caractères chacun, il arrivait que la référence document soit tronquée à droite, faute de place.

La mise à page de ces identifiants a donc été légèrement revue pour faire en sorte qu'ils apparaissent toujours intégralement sur la lettre, même lors qu'ils sont composés de 10 lettres chacun.

Pour constituer un fichier de virements, on passait par le répertoire temporaire défini par Windows, ce qui pouvait poser des problèmes d'autorisations dans certaines configurations réseau (TSE notamment).

Dorénavant, le fichier des virements SEPA est constitué dans le répertoire temporaire défini dans LDCompta, avant d'être converti dans le répertoire demandé par l'utilisateur. Le fichier des virements CFONB est quant à lui créé directement dans le répertoire demandé.

Suite à la correction N° 399, le cours devise n'était affiché qu'avec 2 décimales en consultation de compte, au lieu de 7 auparavant.

Les 7 décimales ont été rétablies dans cette consultation.

Depuis la correction 344, on récupère les informations complémentaires (lignes de commentaires) lors de l'intégration des relevés bancaires dans LDCompta.

Mais ces informations complémentaires n'étaient pas supprimées en cas de suppression d'un relevé. Cela pouvait poser problème lorsqu'on supprimait le dernier relevé : les informations complémentaires étaient conservées et pouvaient donc se mélanger avec le prochain relevé intégré, voire même provoquer des clés en double.

Lorsqu'on utilisait le système d'escompte automatique en saisie d'écritures par pièce, sur une pièce comportant plusieurs lignes de TVA se compensant entre elles (TVA intracommunautaire, avec donc de la TVA au débit et au crédit), le système calculait mal le montant de l'escompte HT : toutes les lignes de TVA étaient prises dans le même sens, sans tenir compte du code débit-crédit.

Certains noms constitués de 3 caractères sont invalides en tant que nom de répertoire sous Windows. Il s'agit des codes : CON, PRN, AUX et NUL.

Or, dans l'arborescence de documents de la GED, le système crée automatiquement les répertoires Windows nécessaires en fonction des codes sociétés définis dans LDPaye.

Pour contourner ce problème, le système ajoute désormais le caractère "_" suite au code société si est égal à l'une des 4 valeurs interdites par Windows. Donc, si on une société de ayant le code AUX, les documents GED seront enregistrés dans <Documents>\AUX_

Lors du lancement du traitement de recherche des clients à relancer, il y avait une erreur lorsqu'on avait une base HyperFile Client/Serveur. Le fichier utilisé pour mémoriser les changements de code relance effectués écriture par écriture (fichier qui peut être utilisé par la suite pour "restaurer" les niveaux de relance, via la fenêtre de reprise CPRREL) n'était pas créé au bon emplacement.

Une petite correction a été faite également dans la fenêtre d'interface Notilus, toujours pour le cas d'une base HyperFile Client/Serveur.