DESCRIPTIF DES CORRECTIONS
LDCompta pour Windows Version 8.50 - Corrections 172 à 235
| MODIFICATION DATE COMPTABLE DES ECRITURES | Correction N° 172 du 27/01/06 |
Sur la modification de la date comptable d'une pièce, si le journalavait un contrôle d'unicité sur le numéro de pièce, ont obtenaitune erreur du type :"Ce n° de pièce existe déjà sur ce journal"Alors que l'on ne modifiait pas le numéro de la pièce mais la datecomptable.
| INVERSION ORIENTATION IMPRESSION PORTRAIT PAYSAGE | Correction N° 173 du 30/01/06 |
Lors de l'impression sans aperçu, les paramètres de l'imprimanteétaient prioritaires par rapport à celui de l'état.Le résultat était qu'un état en portrait pouvait sortir en paysage etqu'un état en paysage pouvait sortir en portrait.Explication : En windev 5,5 on utilisait une fonction iparametre pourinvoquer le choix de l'imprimante, mais les paramètres de l'étatrestaient prioritaires. Alors que pour les versions suivantes dewindev, si on utilise iparametre se sont les paramètres del'imprimante qui sont prioritaires.Il faut donc utiliser maintenant les fonctions iparametreEtat,iparametreApercu,iParametrePDF
| EDITION DU CHIFFRE D'AFFAIRES CLIENTS/FOURNISSEURS | Correction N° 174 du 01/02/06 |
La largeur de la colonne "Cumul" dans l'édition du chiffre d'affairesclients ou fournisseurs a été agrandie afin de pouvoir afficher unnombre ayant un masque "99 999 999".
| AFFICHAGE SESSIONS ACTIVES | Correction N° 175 du 06/02/06 |
Une nouvelle option est désormais disponible dans le menu Fichier :l'option "Sessions actives".Cette option permet d'afficher la liste de toutes les sessionsactives sur l'un des progiciels LD SYSTEME : LDNégoce, LDCompta ouLDPaye. Pour chaque session, le système affiche : - l'heure d'ouverture de la session - le nom du poste de travail - le code et le nom de l'utilisateur - le code et le libellé de la société - le nom de l'utilisateur Windows ayant ouvert la session Windows.Par défaut, la liste est affichée avec un filtre sur le progicielcourant, mais il est possible, en modifiant la combo figurant enhaut à droite de la fenêtre, d'afficher les sessions de tous lesprogiciels.Cette nouvelle option peut être mise à profit chaque fois qu'untraitement nécessitant un accès exclusif doit être lancé : uneclôture mensuelle dans LDPaye, une réindexation de fichier...Le système met d'ailleurs en évidence dans la liste affichée lessessions ouvertes dans la même société (ou le même environnement s'ils'agit de LDPaye) que la session courante. On peut donc facilementvérifier que l'on est le seul utilisateur pour une société donnéeavant de lancer le traitement en question. REMARQUE IMPORTANTE : pour que tout cela fonctionne, il est impératif que tous les progiciels sur tous les postes de travail référencent le même répertoire de mise à jour (appelé aussi Répertoire des mises à jour centralisées). C'est en effet dans ce répertoire que le système crée un fichier nommé LDSESTMP pour enregistrer les sessions actives. Ce fichier LDSESTMP est automatiquement supprimé lorsque plus aucune session n'est active.
| PB IMPRESSION EN COURS ESCOMPTE ET RECAPITULATIF | Correction N° 176 du 06/02/06 |
Avant ce correctif, l'entête de page de l'encours d'escompteapparaissait en double. Et le total du récapitulatif de l'en-coursd'escompte s'imprimait en bas de page laissant un grand espace blanc.NB: Ceci était encore une conséquence de la migration de Windev 5.5
| NE PAS PRECISER DE LETTRE RELANCE CLIENT | Correction N° 177 du 21/02/06 |
Ce correctif permet de ne pas préciser de numéro de lettre de relancepour un groupe et un niveau de relance client donné.Comme pour LDCompta 400, si on laisse un espace blanc à la place dunuméro de relance, la lettre de relance ne s'imprimera pas.
| BOUCLE INFINIE GRAND LIVRE ANALYTIQUE PAR SECTION | Correction N° 178 du 21/02/06 |
A l'impression d'un grand livre analytique par section,il arrivait quelquefois qu'en fin d'état, le système parte en boucleinfinie, ce qui provoquait au final un débordement de pile.
| ETIQUETTES - PB CHOIX IMPRIMANTE | Correction N° 179 du 22/02/06 |
Avant ce correctif, quelle que soit l'imprimante choisiepour l'impression des étiquettes, elle se faisait toujours surl'imprimante par défaut.Maintenant on prend bien en compte l'imprimante choisie.NB : la fonction iRAZ() est à l'origine de ce problème ; en effet,elle déselectionne l'imprimante courante et se met sur l'imprimantepar défaut.
| GRAND-LIVRE PAR COMPTE-BLOCAGE COMPTE NON AUTORISE | Correction N° 180 du 27/02/06 |
Lors d'une demande d'édition d'un grand-livre compte par compte, lecontrôle d'autorisation d'accès à la consultation de ce compten'était pas réalisé, contrairement à ce qui était dit dans ladocumentation du logiciel (chapitre 3.2).Désormais, le contrôle des autorisations est fait de la même façonqu'en interrogation de compte.
| CONTROLE PERIODE OUVERTE EN SAISIE ET DATE DU JOUR | Correction N° 181 du 27/02/06 |
Le contrôle des dates comptables des écritures, dans toutes lesprocédures de saisie, par rapport à la période ouverte en saisie aété légèrement revu, de telle sorte que le fonctionnement soittotalement identique à celui de LDCompta pour AS/400.Auparavant, la date comptable de toute écriture saisie devaitêtre inférieure ou égale au maxi de 2 dates : - la date limite indiquée dans la fiche Société (date facultative) - la date du jour augmentée du nombre de jours porté là aussi dans la période ouverte en saisie.Ainsi, si on indiquait une date limite inférieure à ladate du jour,le contrôle ne se faisait pas par rapport à cette date limite, maispar rapport à la date du jour + 0 jours, cette dernière date étantsupérieure à la date limite indiquée.Désormais, si on indique une date limite pour définir la périodeouverte en saisie, le contrôle se fait toujours par rapport à cettedate, et ne tient pas compte de la date du jour.
| MODIF RELANCES CLIENTS-BOUTON OK ANNULER | Correction N° 182 du 27/02/06 |
La gestion des boutons OK/Annuler a été revue dans la fenêtre demodification des relances clients :1) le bouton OK n'était pas toujours accessible par la touche ENTREE ; il fallait cliquer dessus à la souris pour valider.2) le bouton Annuler fermait systématiquement la fenêtre ; désormais, si une modification de relance est en cours, ce bouton a simplement pour effet d'abandonner la modification en cours, d'effacer tous les champs de la fenêtre, de façon à pouvoir appeler un autre client en modification. Si en revanche aucune modification n'est en cours, le bouton Annuler ferme la fenêtre.
| BALANCE POUR ETAFI | Correction N° 183 du 28/02/06 |
La récupération de la balance pour ETAFI permet de créer une balanceau format ETAFI en préçisant les codes journaux à nouveaux.Mode d'emploi :1) Editer une balance générale à la date d'arrêté souhaitée2) Préparer le fichier "balance" au format ETAFI type 4 en allantdans le menu général :-> Edition -> Balances -> Récupération balance pour ETAFIUne préparation du fichier avec un formatage différent est disponiblepour un contrôle avec un tableur.
| RECHERCHE DES CLIENTS A RELANCER - SEL. CODE COLL. | Correction N° 184 du 03/03/06 |
La sélection d'une racine de compte collectif dans la fenêtre derecherche des clients à relancer provoquait un plantage si le codesaisie était en minuscule ou non existant dans la liste des codescollectifs.
| RACINE COMPTE COLLECTIF - CONTRÔLE COMPTE UTILISÉ | Correction N° 185 du 24/03/06 |
Lors de la saisie d'une racine de compte collectif, le contrôlesur le compte collectif associé ne fonctionnait plus.
| CLOTURE ANNUELLE - TVA ENCAISSEMENT CODE OPERATION | Correction N° 186 du 12/04/06 |
Sur la clôture annuelle : les factures de TVA sur encaissement avecun code nature de pièce supérieur à 1 caractère n'étaient pas prisesen compte.Il pouvait donc manquer des factures sur l'Etat de TVA surencaissements après clôture annuelle.
| EDITION LISTE DE RELANCE - TRI PAR REPRESENTANT | Correction N° 187 du 21/04/06 |
Sur l'édition de la liste des clients à relancer, s'il y a unesélection des clients à traiter et un tri par code représentant,l'édition provoquait une erreur.
| SAISIE PIECE - AFFICHAGE SOLDE COMPTE MOUVEMENTE | Correction N° 188 du 26/04/06 |
En saisie d'écritures par pièce, le système affiche désormais lesolde du compte mouvementé. Ce solde apparait en bas à droite de lafenêtre, sous le total débit-crédit-solde de la pièce. Il s'agit dusolde du compte mouvementé sur la ligne en cours de saisie ; cesolde est toujours en devise de référence ; il inclut non seulementle solde du compte en question, mais aussi toutes les écritures de lapièce en cours de saisie mouvementant ce même compte.De plus, par la combinaison de touche Majuscule+F8, on peut alimenterle montant de la ligne en cours de saisie de telle sorte que lecompte soit soldé (même mécanisme que le bouton Contrepartie, quiest associé à la touche F8, et qui permet de solder la pièce).Enfin, cette nouvelle fonctionnalité est disponible immédiatementdès lors que cete correction 188 est installée. Cependant, il restepossible de la désactiver, via un paramètre programme (Alt+F1 sur lepremier écran de la saisie pièce). Cela peut s'avérer préférablenotamment en environnement Client/Serveur, si les performances sontmédiocres.
| LETTRES DE RELANCE - DETAIL DES LETTRAGES PARTIELS | Correction N° 189 du 27/04/06 |
Sur l'édition des lettres de relance clients, le détail des lettragespartiels n'apparaissait pas en mode "full windows".N.B : Il s'agit d'un problème de migration windev 5.5 à windev 8.L'ordre de construction de clé HConstruitValClé n'a pas été utilisésur l'ordre HLitRecherchePremier.
| SAISIE PAR FOLIO - IMPRIMER EN MODE CLIENT SERVEUR | Correction N° 190 du 28/04/06 |
L'impression d'un folio en mode client serveur ne fonctionnait pasN.B : Ce dysfonctionnement provient de la migration Windev 5.5 àWindev 8 ; la fonction iImprimeEtat a été améliorée.
| SAISIE DES CANEVAS - ERREUR CREATION NOUVEAU | Correction N° 191 du 28/04/06 |
Lors d'un démarrage de comptabilité, il arrive que l'on supprime tousles canevas existants. Ensuite on crée un nouveau canevas et celui ciposait problème.N.B : Lors de l'initialisation du nouveau canevas, la zone gardaitla dernière ligne lue, maintenant elle est réinitialisée.
| SUPPRESSION DANS UNE LISTE VIDE - ERREUR | Correction N° 192 du 28/04/06 |
Dans une liste vide, si l'on cliquait sur le bouton Supprimer, onobtenait un plantage.Par exemple : c'était le cas dans la liste des comptes collectifs.
| SAISIE EXTOURNE - ERREUR SUR TOUTES LES PIECES | Correction N° 193 du 28/04/06 |
L'extourne de toutes les pièces à une date donnée ne retournait aucune pièce (bien que plusieurs pièces existaient).
| JOURNAUX-NOUVEAUX CODES JOURNAUX A DEUX CARACTERES | Correction N° 194 du 28/04/06 |
En création d'un nouveau journal, on impose désormais que le codejournal comporte 2 caractères.
| GESTION BUDGETAIRE - DIFFERENCE ANALYTIQUE C/S | Correction N° 195 du 04/05/06 |
Lors de l'initialisation d'un tableau réalisé de budget sansanalytique, il pouvait y avoir des différences en mode client serveurAS 400.N.B : Pour faire un HSupprime sur un enregistrement en mode clientserveur AS400, il faut avoir bloqué l'enregistrement auparavant.
| COMPTE DIFFERENCE DE CHANGE - NB DE CARACTERES | Correction N° 196 du 01/06/06 |
Seul les 6 premiers caractères du compte de gain de la ventilation des
différences de change était utilisé dans le module devise.
| SAISIE EXTOURNE - BLOQUER EXTOURNE DATE CLOSE | Correction N° 197 du 01/06/06 |
L'extourne d'une pièce clôturée ou sur une période clôturée n'est pas
possible. Même fonctionnement que sur LDCompta AS400.
| LIMITER A 9 L'AJOUT DE BIBLIOTHEQUE SPECIFIQUE | Correction N° 198 du 09/06/06 |
Affichage d'un message d'erreur et retour à la fenêtre, à l'ajout
de la 10ème bibliothèque spécifique.
| LETTRES CHEQUES - MAUVAISE CONVERSION DES MONTANTS | Correction N° 199 du 12/06/06 |
Pour les chiffres 101000, 201000, 301000, 401000, 501000, 601000,
701000, 801000 ,901000... le un mille n'était pas converti en toutes lettres.
Par exemple :
101000 était converti en cent mille au lieu de cent un mille
| DECLARATION DES HONORAIRES - DIVISION PAR 0 | Correction N° 200 du 13/06/06 |
Si dans une pièce, le solde des écritures ne faisant partie ni des
comptes à envoyer en DAS2 (comptes fournisseurs), ni des comptes de TVA, était à 0,
alors le programme provoquait une erreur de W-Language "Division par 0".
Les pièces étant dans ce cas seront désormais ignorées.
| SUIVI TVA ENCAISSEMENT - MONTANT TVA CUMUL EXERCICE | Correction N° 201 du 27/06/06 |
Avant cette correction, le calcul du montant de tva due cumulée du
cumul exercice ne prenait pas en compte celui de l'exercice précédent.
| BALANCE ANALYTIQUE - EXPORT EXCEL DIRECT | Correction N° 202 du 03/07/06 |
L'export pour Excel est maintenant disponible pour la balance analytique et la balance par affaire.
| BALANCE BUDGETAIRE - EXPORT EXCEL DIRECT | Correction N° 203 du 06/07/06 |
L'export Excel est maintenant disponible directement pour la balance budgétaire.
| LETTRE DE RELANCE - SELECTION PAR REPRESENTANTS | Correction N° 204 du 06/07/06 |
La sélection des clients sur le code représentant ne sélectionnait pas
tout les clients appartenant aux codes demandés si le tri de l'édition
demandé était également par représentant
Ce problème a été constaté dans les états suivants :
- Etat des clients à relancer : seuls les clients appartenant au représentant
marqué dans la zone de début était sélectionnés.
- Lettres de relances : A partir du premier client sélectionné, le parcours
s'arrétait dès le premier client non sélectionné (dans l'ordre des n° de clients)
Exemple : le client 0001 a pour représentant R1
le client 0002 a pour représentant R2
le client 0003 a pour représentant R1
le client 0004 a pour représentant R2
Si on demandais tout les clients par représentant à partir du représentant R2, seul le client 0002 était sélectionné.
| MODIFICATION DONNEES PAR LOT - SUPPRIMER SCENARIO | Correction N° 205 du 12/07/06 |
La suppression d'un scénario de modification de données par lot ne fonctionnait pas.
| MODIF ECRITURE- CONTROLE DOUBLON ERRONE | Correction N° 206 du 20/07/06 |
En modification d'écritures, si on tentait de modifier la date
comptable d'une écriture, on pouvait dans certains cas obtenir
un message indiquant un doublon sur le N° de pièce, alors qu'il
n'existait aucune autre pièce portant ce N° sur le journal.
En fait, le contrôle de doublons sur le N° de pièce comme sur la
référence document se faisait sans ignorer la pièce en cours
de modification. Il détectait donc un doublon entre la pièce en
cours de modification et la même pièce avant modification.
Complément d'info : la correction N° 172 du 27/01/06 avait corrigé
une partie de ce problème, mais il restait des cas non traités.
Autre remarque : il semble que le même problème existe aussi dans
la version AS/400 native de LDCompta. Mais aucune correction n'a été
faite, s'agissant d'un blocage qui n'apparait que fort rarement.
| VIREMENTS COMMERCIAUX ET FICHIER ETEBAC POUR VIR. INTERNATIONAUX | Correction N° 207 du 25/09/06 |
1) Virements commerciaux
LDCompta permet désormais de gérer les virements commerciaux (appelés aussi VCOM).
Un virement commercial est un ordre de virement à exécution différée (120 jours maximum), contractuellement irrévocable, et enrichi de données commerciales (références des factures réglées). Par ce biais, vous pouvez donc émettre des virements par avance, même sur des échéances multiples, comme on le ferait pour des BO.
Vous n'avez pas à émettre de bordereau de paiement au fournisseur ; celui-ci est informé directement par votre banque de l'arrivée future de ces règlements.
La gestion de ces règlements dans LDCompta se compose de :
- la définition des paramètres propres à ces virements commerciaux, pour chaque banque pour laquelle vous
souhaitez émettre des virements commerciaux. Sachant que la norme VCOM 400 offre quelques souplesses que
les banques ont (largement) mis à profit, il vous faut donc renseigner ces paramètres en s'appuyant sur les documents
spécifiques émis par chaque banque, documents décrivant l'implémentation exacte de cette norme.
- l'émission des virements commerciaux dans la chaine de règlement automatique des fournisseurs,
avec comptabilisation entre le compte fournisseur et un compte de passage que l'on peut définir banque par banque ;
- préparation du fichier ETEBAC au format VCOM 400 (fichier dit "à plat")
- comptabilisation de ces virements à échéance (entre le compte de passage et le compte de banque).
Pour cela, un nouveau type de paiement Virement commercial est proposé dans les paramètres modes de paiement, et des paramètres spécifiques à ces virements commerciaux sont accessibles pour chaque journal de banque, par le bouton Vir. com. & int. sur l'onglet Règlements des paramètres d'un journal de banque.
Pour la gestion de ces virements commerciaux (préparation du fichier ETEBAC et comptabilisation à échéance), une nouvelle option est disponible dans le menu Traitement/Règlement automatique fournisseurs.
2) Virements internationaux - Préparation du fichier ETEBAC
Parallèlement à cela, il est aussi possible désormais de préparer le fichier ETEBAC pour des virements internationaux. Rappelons que depuis la version 8.50, LDCompta permet de gérer les virements internationaux (émission et comptabilisation), mais n'allait pas jusqu'à la préparation du fichier ETEBAC. Cette lacune est donc comblée.
Pour ce faire, là aussi, des paramètres supplémentaires doivent être renseignés, pour chaque banque émettrice de ces virements, paramètres accessibles par le bouton Vir. com. & int. sur l'onglet Règlements des paramètres d'un journal de banque.
Remarque importante : lors de la préparation de l'ordre de télétransmission à la norme ETEBAC, LDCompta ne prend pas en charge :
- les enregistrements de type 06 (Banques intermédiaires)
- la gestion des contrats de change dans les enregistrements de type 07
Pour ce qui est des enregistrements de type 07, le champ Motif du règlement est alimenté au choix avec la liste des N° de pièce des factures réglées ou des références document de ces factures, cette liste étant toutefois limitée à 140 caractères.
| EDITION BALANCE GENERALE - BULLE D'AIDE POUR MASQUE SUR COMPTE GENERAL | Correction N° 208 du 05/10/06 |
Lors d'une demande d'édition d'une balance générale, la bulle d'aide qui s'affiche lorsqu'on entre dans le champ Masque pour le compte général indiquait que le masque devait comporter 6 caractères.
Or, depuis la version 8 de LDCompta, ce masque doit en réalité comporter 8 caractères. La bulle d'aide a donc été corrigée en ce sens.
| EXTOURNE PIECE PLUS POSSIBLE SI PIECE A EXTOURNER SUR JOURNAL CLOS | Correction N° 209 du 05/10/06 |
Suite à la correction 197, il n'était plus possible d'extourner une pièce si celle-ci était passée sur un journal clos.
Or, ce qui importe, c'est de ne pas extourner sur un journal clos ; la pièce d'origine peut être sur un journal clos. C'est même le cas le plus fréquent.
| MOT "FRANC" ENCORE AFFICHE SUR CERTAINS ECRANS | Correction N° 210 du 05/10/06 |
Le mot Franc apparaissait encore sur 2 écrans, en lieu et place de Euro.
En saisie pièce, cela se produisait dans les bulles d'aide des colonnes Montant débit et Crédit, dans le cas d'une saisie sur un journal ne supportant pas la saisie en devises, alors que le module devises était actif !
| MEMORISATION JOURNAL SITUATION DANS UN FOLIO ET COMPTA ANALYTIQUE | Correction N° 211 du 05/10/06 |
Lorsqu'on mémorisait un journal de situation dans un folio, les écritures du journal ayant une ventilation analytique multiple étaient mal reprises. On trouvait bien la ventilation dans le détail du folio, mais il manquait le repère "*" dans la ligne principale du folio, repère signalant qu'il y a une ventilation analytique multiple.
De ce fait, lorsqu'on rappelait le folio de situation en modification, on ne voyait pas directement la ventilation analytique qui avait été mémorisée.
| SAISIE FOLIO - DYSFONCTIONNEMENT SI VENTILATION ANALYTIQUE MULTIPLE | Correction N° 212 du 05/10/06 |
En saise par folio, si on saisissait une ligne du folio avec une ventilation analytique multiple, lors du rappel en modification de cette ligne, le système signalait une erreur "Code affaire manquant".
Remarque : Attention : pour que le système de ventilation analytique multiple fonctionne dans cette procédure, il faut que la zone Section soit définie avec 7 caractères (pour accepter la valeur particulière "Ventilé"). Un contrôle spécial bloque toute valeur saisie à plus de 6 caractères si autre que la valeur spéciale "Ventilé".
| DATE ECHEANCE EN SAISIE REGLEMENT CLIENT | Correction N° 213 du 06/10/06 |
En saisie des règlements clients, si on ne saisit pas de date d'échéance (ce qui est possible si le mode de paiement ne l'y oblige pas), le règlement sera comptabilisé avec une date d'échéance égale à la date comptable.
Auparavant, le règlement était comptabilisé avec une date d'échéance égale à la date du jour de la saisie. Cela pouvait poser problème lorsqu'on saisissait les règlements avec quelques jours de retard en fin de mois, notamment pour le suivi de la TVA sur encaissements, suivi où c'est la date d'échéance du règlement qui prime pour déterminer dans quel mois la TVA est due.
| COMPTES NON AUTORISES EN CONSULTATION - APPELS DIRECTS POSSIBLES | Correction N° 214 du 11/10/06 |
Il est possible dans LDCompta d'interdire la consultation de certains comptes, et ce en définissant des autorisations particulières au niveau du plan comptable. Ces autorisations sont gérées dans tous les programmes de consultation, et bien entendu dans la consultation par compte.
Cependant, si le programme d'interrogation d'un compte était appelé depuis une autre fenêtre pour consulter un compte, en fournissant directement dans cet appel le N° du compte à visualiser, le contrôle des autorisations n'était pas réalisé. On accèdait ainsi à la consultation même si on n'était pas autorisé à consulter le compte.
Ce cas de figure pouvait par exemple se produire en saisie des écritures par pièce (bouton Consulter) ou en saisie des règlements clients.
Ce cas était cependant peu fréquent, car bien souvent, lorsqu'on met en place ce genre d'interdiction, c'est pour restreindre la consultation aux seuls comptes clients pour des utilisateurs de type Gestion commerciale, et ces utilisateurs n'ont pas non plus accès aux procédures de saisie.
| VISUALISATION DE L'EN-COURS CLIENT SI TRAITE A L'ACCEPTATION ET PAS DE SECONDE DEVISE | Correction N° 215 du 27/10/06 |
Le programme de visualisation de l'en-cours client provoquait une erreur "ligne 45 du traitement Méthode ConvertirDepuisDevisePivot" du type "Division par 0" si le module devise était actif sans seconde devise, et qu'il existait des traites à l'acceptation dans l'en-cours du client demandé.
| EDITION DES LETTRE CHEQUE A PARTIR D'UN COMPTE CLIENT - MANQUE 1ERE LIGNE ADRESSE | Correction N° 216 du 16/11/06 |
Si on éditait une lettre-chèque (ou autre lettre-règlement) à partir d'une fiche client, la 1ère ligne de l'adresse ne correspondait pas à celle du client, mais à la 1ère ligne d'adresse du dernier fournisseur lu dans le fichier.
| OUTIL: REPRISE LETTRAGE AYANT DATE LETTRAGE < COMPTABLE | Correction N° 217 du 01/12/06 |
Une procédure a été développée pour modifier en automatique les lettrages erronés pour ce qui est de la date de lettrage : erreur signalée par la procédure de vérification des lettrages avec le type d'anomalie : "Date lettrage < comptable".
Cette procédure ne doit être utilisée que si cette anomalie est la seule signalée par la procédure de vérification des lettrages.
Si des lettrages déséquilibrés sont signalés, il faut tout d'abord délettrer ceux-ci ; seules les anomalies concernant la date de
lettrage sont traitées par cette procédure.
PRINCIPE DE FONCTIONNEMENT :
Pour chaque lettrage identifié par (Compte général, compte auxiliaire, code lettrage, date lettrage),
la procédure recherche la date comptable la plus grande parmi toutes les écritures mises
en jeu. Si pour l'une des écritures concernées au moins, on a l'anomalie Date lettrage <
Date comptable, la procédure affecte cette date comptable la plus grande
comme date de lettrage sur toutes les écritures mises en jeu par le lettrage en question.
En fin de traitement, un message signale le nombre de lettrages corrigés,
ainsi que le nombre d'écritures concernées.
MODE OPERATOIRE :
Menu Outils/Autres outils/Lancer une fenêtre Windev
Ouvrez la fenêtre nommée CPRHISLT
Si on choisit l'option "Tous les lettrages" proposée dans cette fenêtre, tous les lettrages sont mis à jour (Date lettrage = Date comptable maxi), même s'ils ne sont pas en erreur. Ce mode peut être utilisé suite à une reprise d'un dossier comptable par exemple, s'il n'a pas été possible de reprendre une date de lettrage "intelligente" de l'ancien système comptable.
| BUDGET - PROBLEME CONTROLE PERIODE - INIT AVEC OD ANALYTIQUE | Correction N° 218 du 07/12/06 |
2 soucis ont été réglés dans le module Gestion budgétaire :
1) lors d'une demande d'initialisation d'un tableau de type Réalisé, en environnement AS/400, on avait des erreurs bloquantes sur la période choisie pour l'initialisation, lorsque le tableau en question avait été initialisé auparavant en environnement Client/Serveur. Cela était du à la façon dont les périodes étaient mémorisées dans le tableau. On ne saisit que Mois début et Mois fin de période à l'écran, mais le système enregistre une date début et une date de fin. En environnement AS/400, le système enregistrait toujours cette date avec le jour 01 pour le début de période, et le dernier jour de mois pour la fin de période. En environnement Windows, le système enregistrait toujours avec le jour 01. Cela n'avait pas d'incidence tant que l'on restait en environnement Windows ou Client/Serveur, car tous les tests étaient effectués sur les 6 caractères de gauche de la date (Année et mois), et donc sans tenir compte du jour. En environnement AS/400, les tests sur les périodes étant effectués sur les dates complètes à 8 caractères, le système signalait parfois une erreur indûment.
Pour corriger cela, en environnement Windows, on enregistre désormais les périodes comme en environnement AS/400, avec les jours 01 pour le début de période, et le dernier jour du mois en fin de période.
2) dans certains cas, les OD analytiques pouvait ne pas être prises en compte correctement lors de l'initialisation d'un tableau de type Réalisé, en environnement Client/Serveur. Il s'agissait d'un problème quelque peu aléatoire de lecture de fichier avec Easycom ; la lecture des ventilations analytiques d'une écriture de comptabilité générale ne se faisait pas toujours correctement. En réécrivant l'ordre de lecture avec une syntaxe différente, il semble que le problème ait disparu. Sous toute réserve, car s'agissant d'un bug aléatoire, rien ne ne dit que le problème ait tout à fait disparu. La seule chose certaine, c'est que nous n'avons pas pu reproduire le bug avec cette correction, alors qu'il survenait, apparemment de façon presque systématique, lors de la 2ème exécution du traitement d'initialisation d'un tableau budgétaire. Et uniquement la 2ème fois, si on relançait le traitement une 3ème fois, une 4ème fois..., cela fonctionnait bien ! Aucune explication à cela bien sûr ! Il doit y avoir un bug sous-jacent dans Windev 8 ou dans Easycom, mais il serait bien difficile à isoler... Ni PCSoft (éditeur de Windev), ni AURA (éditeur d'EASYCOM) ne voudront nous aider pour résoudre ce problème.
| LETTRAGE OD AUTOMATIQUE ET DIFFERENCE DE CHANGE | Correction N° 219 du 07/12/06 |
Une petite anomalie a été corrigée dans la procédure de lattrage automatique.
Lors de la comptabilisation d'une OD automatique lors d'un lettrage, pour savoir si l'OD est une différence de change ou pas, le système comparait les 6 positions de gauche du compte choisi pour l'OD automatique aux 6 positions de gauche des N° de compte indiqués dans la fiche société pour les pertes et gains de change.
Le code a été modifié le code pour que la comparaison se fasse désormais avec les 8 caractères.
| PROBLEMES BUDGET TRESO EN CLIENT SERVEUR | Correction N° 220 du 11/12/06 |
Des modifcations ont été apportées dans de très nombreuses fenêtres de LDCompta.
La modification a consisté à bloquer systématiquement les enregistrements lorsqu'il pouvait y avoir ensuite suppression de l'enregistrement. En effet, en environnement Client/serveur, la suppression fonctionne de façon aléatoire s'il n'y a pas eu blocage de l'enregistrement auparavant.
De plus, lorsqu'il y avait des boucles de recherche-suppression, en sortie de boucle, un ordre de libération du dernier enregistrement lu a été ajouté systématiquement. Même chose lorsque la suppression de l'enregistrement bloqué n'était pas systématique ; s'il n'y a pas suppression, on débloque l'enregistrement. Le principe est de ne jamais garder un enregistrement bloqué si cela n'est plus nécessaire.
Ces modifications ont pour la plupart étaient réalisées de façon préventive, car comme il a été dit plus haut, la suppression fonctionnait de façon aléatoire. Dans la plupart des cas, tout se passait très bien ; les problèmes étaient assez rarissimes.
Il est toutefois certrain que cette correction règle notamment des problèmes :
en saisie des paramètres pour un tableau de trésorerie
en saisie des paramètres pour un bilan ou un compte de résultat
en saisie de budget.
Nota : compte-tenu du très grand nombre de fenêtres modifiées, il n'a pas été possible de retester en détail chaque fenêtre modifiée. Seul un double contrôle visuel des sources modifiés a été réalisé.
| PROBLEMES EN SAISIE DES REGLEMENTS CLIENTS | Correction N° 221 du 15/12/06 |
Dans le package correctif diffusé au niveau 219, on rencontrait des problèmes en saisie de règlements :
- le compte transitoire n'était pas mouvementé ; quel que soit le paramétrage du journal de banque, le système mouvementait toujours directement le compte de banque.
- le libellé proposé sur le 2ème écran de saisie du règlement n'était pas correct.
Cela était dû à un dysfonctionnement Windev dans la gestion des bibliothèques correctives ; celle-ci ne contenait que la seconde fenêtre (celle où l'on saisit le libellé du règlement notamment) de saisie des règlements clients, la première n'ayant pas été modifiée. Or, la seconde fenêtre utilise certaines variables globales déclarées dans la première fenêtre. Et la liste des variables globales de cette fenêtre a changé au cours des différents correctifs de la version 8.50. De ce fait, le système n'arrivait pas à lire correctement ces variables dans la seconde fenêtre (lecture des données à une adresse mémoire erronée !).
Pour remédier à ce problème, la première fenêtre a été placée dans le même package correctif que la seconde.
| PLAN COMPTABLE - MODIF BULLE D'AIDE BOUTON LISTE DES DEVISES | Correction N° 222 du 15/12/06 |
Dans la fenêtre de saisie d'un compte général, le texte de la bulle d'aide sur le bouton "Liste des devises" a été corrigé.
| SUITE CORRECTIF 220 - ERREUR SUR HDEBLOQUENUMENR | Correction N° 223 du 15/12/06 |
Suite à la correction niveau 220, si le fichier débloqué était vide, on obtenait des erreurs du type :
Vous avez appelé la fonction HDébloqueNumEnr.
Le numéro d'enregistrement <-1> n'est pas un numéro d'enregistrement valide. Il doit être strictement positif ou égal à la constante de numéro d'enregistrement en cours hNumEnrEnCours
| APPEL CONSULTATION COMPTE BLOQUE PAR PROBLEME DE DROITS | Correction N° 224 du 27/12/06 |
Suite la correction 214, chaque fois que l'on appelait la fenêtre de consultation d'un compte sous un profil utilisateur ne disposant pas des droits Administrateur, le système signalait une erreur quelque soit le compte :
"Vous n'êtes pas autorisé à consulter ce compte".
En revanche, on pouvait consulter le compte si on ouvrait la fenêtre de consultation et que l'on saisissait ensuite le N° du compte en question.
| EDITION LETTRES CHEQUE - MONTANT EN LETTRES FAUX POUR LES CENTIMES | Correction N° 225 du 09/01/07 |
Suite à la correction N° 199, l'impression du montant en toutes lettres sur le chèque était fausse pour ce qui est des centimes, chaque fois que le nombre de centimes était un multiple exact de 10. On perdait le zéro de droite de la partie décimale, qui est ici significatif !
Exemple Montant imprimé faux Montant juste
100,40 cent euros et quatre centimes cent euros et quarante centimes
12,20 douze euros et deux centimes douze euros et vingt centimes
| INTERFACE TIERS TELEPHONES CONDENSES A 13 CARACTERES | Correction N° 226 du 12/01/07 |
Lors de l'interface, les numéros de type téléphonique étaient "condensés" à 13 caractères.
Exemples :
04.75.70.85.00 devenait 0475.70.85.00
04 75 70 85 00 devenait 0475 70 85 00
Depuis LDCompta Version 8.00, les numéros de téléphone, télex et télécopie sont passés de 13 à 20 caractères dans les fichiers clients, fournisseurs et vrp.
Il est aujourd'hui inutile de passer dans la procédure qui passait, lors de l'interface, les numéros de type téléphonique de 15 caractères possibles dans le fichier d'interface à 13 caractères dans les fichiers clients, fournisseurs et vrp, par suppression d'espaces et de séparateurs.
| AFFICHAGE RIB INCOMPLET DANS PORTEFEUILLE | Correction N° 227 du 23/01/07 |
La domiciliation et le RIB étaient tronqués sur certains écrans d'affichage du portefeuille.
| RELEVES CLIENTS MULTI-ECHEANCES | Correction N° 228 du 24/01/07 |
La chaine d'édition-comptabilisation des relevés clients a été améliorée, de façon à gérer des relevés multi-échéances.
Désormais, sur le 3ème onglet, après avoir indiqué la date du relevé, on peut choisir entre 3 options pour l'échéance du relevé :
- Recalculée à partir de la date du relevé, en appliquant le délai de paiement du client
- Egale à celle des factures (avec donc éventuellement plusieurs échéances)
- Saisie directement sur ce même écran
L'option nouvelle est donc la 2ème, celle qui consiste à tenir compte des échéances des différentes écritures reprises sur le relevé.
Si on choisit cette option, le système effectue pour chaque relevé des sous-totaux par échéance des écritures portées sur le relevé. Puis il élimine les échéances ayant un total négatif ou inférieur au montant minimum en les reportant sur d'autres échéances. Ces échéances négatives sont reportées dans un premier temps vers des échéances postéreiures. Puis, si cela ne suffit pas, on report les échéances restant encore négatives sur des échéances antérieures.
Si suite à cela, il reste plusieurs échéances ayant un montant supérieur au montant minimum, le relevé sera effectivement multi-échéances. Et dans ce cas :
- à l'édition du relevé, on fait apparaître, dans le corps du relevé, un récapitulatif par échéance
- la comptabilisation du relevé (lettrage partiel, émission de traite à l'acceptation ou en portefeuille)
se fait pour chaque échéance. Le N° de pièce est alors constitué du N° de relevé, suivi du N° de l'échéance.
- à l'édition, on imprime les différentes traites, suite au relevé en cas d'édition de type "Relevé+Traite",
ou en à la suite en cas d'édition "Traite séparée".
Remarque : 2 autres modifications ont été faites au passage dans cette chaine :
1) on renseigne systématiquement la référence tiré des traites, tant sur le règlement qui est comptabilisé, que sur les traites imprimées. La référence tiré est prise égale au N° de pièce : N° de relevé sur 7 chiffres, suivi en cas de multi-échéances, du N° de traite (Exemple : 0000788/01).
2 ) sur les traites imprimées, on a ajouté le code client, en haut à droite du cadre où figure l'adresse du client.
| LISTE DES TRAITES A RELANCER - RIB INCOMPLET | Correction N° 229 du 24/01/07 |
Sur la liste de relance des traites émises à l'aceptation, le 11ème chiffre du N° de compte RIB ne s'imprimait pas.
| EDITION DU PORTEFEUILLE - MANQUE DATE DERNIERE ECHEANCE | Correction N° 230 du 24/01/07 |
Sur les éditions récapitulatives du portefeuille (récap par mode paiement et échéance, ou récap par échéance), la date d'échéance ne s'imprimait pas sur la dernière ligne de chaque page.
| INTERFACE SAGE - CORRECTIONS | Correction N° 231 du 05/02/07 |
La fenêtre d'interface avec SAGE Ligne 100 livrée en standard ne fonctionnait pas.
Pour plus d'informations sur cette fonctionnalité, consultez le document IntSAGE100.doc qui décrit dans le détail cette interface.
| TABLEAUX DE BORD ANALYTIQUES - MEME CONTROLE QUE COMPTE RESULTAT | Correction N° 232 du 16/02/07 |
Lors d'une demande d'impression d'un tableau de bord analytique, on effectue désormais les mêmes contrôles de cohérence que pour un compte de résultat.
Pour un compte de résultat, on vérifie que chaque compte présentant un solde à la date d'arrêté demandée (ou la date choisie pour le comparatif) est pris une et une seule fois dans le compte de résultat.
Pour un tableau de bord analytique, on vérifie donc désormais que chaque couple (Compte général, Section analytique) présentant un solde à la date d'arrêté demandée (ou la date choisie pour le comparatif) est pris une et une seule fois dans le tableau de bord demandé.
ATTENTION : ce contrôle analytique est plus "fin" que celui effectué sur le compte de résultat, même si on utilise le même tableau dans les 2 cas. Pour le compte de résultat, on teste seulement le solde global du compte. Pour le tableau de bord analytique, on teste tous les couples (Compte, Section).
Ainsi, on peut avoir un compte dont le solde est débiteur, mais ce solde étant réparti entre une section débitrice et une autre section créditrice. Si dans le paramétrage du compte de résultat, on a placé ce compte avec l'option Solde si débiteur, l'impression de ce tableau en tant que Compte de résultat ne signalera pas d'erreur. Mais si ce même tableau est utilisé pour une édition de Tableau de bord analytique, le système signalera une erreur car il ne saura pas que faire du solde créditeur de la seconde section.
Il en résulte que les tableaux utilisés pour l'impression en tant que Tableau de bord analytiques doivent être construits en évitant d'utiliser les options Total débits, Total crédits, Solde si débiteur, Solde si créditeur. Il faut utiliser de préférence l'option Solde algébrique.
| PROBLEME SELECTION TIERS EN ENVIRONNEMENT CLIENT/SERVEUR | Correction N° 233 du 14/03/07 |
Dans certains traitements, les sélections sur un intervalle de N° clients ou fournisseurs ne fonctionnaient pas correctement, en environnement Client/Serveur. Le problème se produisait essentiellement si on utilisait des cotisations tiers mélangeant des chiffres et des lettres.
Exemple : sélection des clients ayant un N° compris entre AAAAAA et ZZZZZZ. S'il existait des clients ayant un N° commençant par un chiffre (comme 000001 par exemple), ces clients apparaissaient également sur la liste demandée malgré la sélection.
Le problème était dû aux différences d'encodage des caractères entre Windows et l'AS/400.
Sur Windows, on a une codification ASCII ; sur AS/400, une codification EBCDIC.
En ASCII, l'ordre alphanumérique donne d'abord les chiffres, puis les majuscules, puis les minuscules.
En EBCDIC, l'ordre alphanumérique donne d'abord les minuscules, puis les majuscules, puis les chiffres.
Selon la façon dont la sélection était réalisée dans le programme, cela fonctionnait ou pas. En effet, si la sélection était opérée au niveau base de donnés (SQL ou Filtre Windev), c'est l'AS/400 qui opérait la sélection (donc en EBCDIC) et cela fonctionnait. Si au contraire la sélection était faite par le programme Windev, par une comparaison directe du N° de tiers par rapport à une borne de fin, la comparaison ne donnait pas les résultats attendus car la comparaison était faite ici en ASCII.
Dans l'exemple décrit ci-dessus d'une sélection de AAAAA à ZZZZZ, on commence à lire à partir de AAAAA. Puis on lit en séquence tant que le N° de tiers reste inférieur à ZZZZZ. Or, de par la séquence de tri EBCDIC de l'AS/400, on va lire le compte 000001 après le compte ZZZZZZZ. Mais la comparaison 000001 < ZZZZZZ reste vrai lorsqu'elle est faite en ASCII ! Et donc, ce compte 00001 (et tous les suivants) étaient sélectionnés à tort.
Pour éviter cela, lorsqu'on est en environnement Client/Serveur, la comparaison entre le N° de tiers courant et la borne de fin de l'intervalle de sélection se fait désormais en ayant pris le soin au préalable de convertir les 2 valeurs en EBCDIC.
De même, toujours en environnement Client/Serveur, chaque fois que l'on peut spécifier un intervalle de N° de tiers, le contrôle de cohérence de l'intervalle demandé (N° borne fin >= N° borne début) est fait en ayant traduit les bornes en EBCDIC.
Ainsi, un intervalle AAAAAA - 5000000 est désormais accepté si on est en environnement Client/Serveur, alors qu'il est refusé en environnement Windows.
Dernière précision : dans certains traitements, bien que la sélection soit basée sur la codification EBCDIC, la liste qui en résulte est triée en se basant sur la codification ASCII. Cela se produit chaque fois que le système utilise une zone (ou un fichier) de travail intermédiaire, avec un tri de cette zone (ou de ce fichier). La zone (ou le fichier) étant construit sous Windows, c'est la codification ASCII qui est utilisée.
Ainsi, pour une balance client par exemple, on peut désormais sélectionner du N° AAAAAA au N° 500000. Mais sur la balance ainsi produite, les clients ayant un N° compris entre 0 et 500000 seront présentés avant ceux ayant un N° compris entre A et ZZZZZZZ.
Remarque complémentaire : dans la liste des traitements modifiés, la plupart donnait déjà des résultats corrects ; ce n'est que le contrôle de cohérence de l'intervalle de sélection qui a été amélioré. Le problème "critique" de sélection se posait principalement pour les balances et grands-livres auxiliaires (et encore, pas systématiquement, car cela dépendait vraiment de l'intervalle demandé par rapport à la plage totale des N° de comptes existants, et de ceux présentant des écritures).
| RELEVES CLIENTS - ERREUR SUR COMPTE PORTEFEUILLE | Correction N° 234 du 14/03/07 |
Dans la chaine d'émission des relevés clients, en cas de comptabilisation de traites en portefeuille, et si le compte de portefeuille était géré par mois d'échéance, le compte mouvementé était incorrect.
Si le compte de portefeuille était un compte général par mois d'échéance, le système constituait le compte à mouvementer à ajoutant les 2 chiffres du mois d'échéance au N° de compte indiqué dans le journal de portefeuille (et donc à 6 chiffres, 413000) au lieu de prendre celui porté dans la fiche Société (qui est normalement à 4 chiffres, 4130).
Si le compte de portefeuille était un auxiliaire par mois d'échéance, le système recherchait le compte de portefeuille en comparant les collectifs définis dans la table des comptes collectifs au N° de compte indiqué sur le journal de portefeuille là aussi, plutôt qu'au N° de compte porté dans la fiche Société. Et cela pouvait donc aussi provoquer une anomalie, si le compte indiqué sur le journal de portefeuille n'était pas égal à celui indiqué dans la fiche Société.
| CONTROLE BIBLIO COURANTE EN ENVIRONNEMENT CLIENT/SERVEUR | Correction N° 235 du 15/03/07 |
Pour éviter des erreurs en cas de défaillance sur le serveur AS/400, lors de l'ouverture d'un dossier en en environnement Client/Serveur, on vérifie désormais que la commande CHGCURLIB CPTxLIB s'exécute correctement.
En cas d'erreur sur cette commande, l'ouverture du dossier comptable est abandonnée est l'erreur rencontrée est signalée.
Cela permet de bien gérer le cas où une bibliothèque de données a été supprimée par erreur sur l'AS/400, ou rebaptisée, alors qu'elle était référencée pour un accès en environnement Client/Serveur.