Jusqu'alors, la création des rubriques numériques non obligatoires dont la valeur était nulle ne se faisait pas. Mais il y avait deux cas de figure où le système créait quand même des rubriques numériques avec valeur nulle :

1) lorsque la valeur numérique était non nulle, mais le devenait après application de l'arrondi (arrondi à l'entier le plus proche dans le cas général, à l'entier inférieur dans le cas des rubriques fiscales)

2) dans le cas des groupes, comme les S40.G28.10, S40.G28.15, S40.30.15... Le groupe n'était pas créé si la valeur numérique de la rubrique "principale" à déclarer dans le groupe était nulle. Mais il était créé quand même pour les valeurs inférieures à 0,50, alors que suite à l'application de l'arrondi, la valeur numérique était nulle. Cela était dû au fait que ces rubriques sont définies, dans le cahier technique, comme étant obligatoires dans le groupe. Elles étaient donc inscrites même avec une valeur nulle. En fait, dans ce cas précis, c'est le groupe tout entier qu'il ne faut pas créer.

Lors de la saisie d'une nouvelle entrée pour un salarié donné, la date initiale de fin de CDD n'est plus copiée depuis la situation précédente, comme c'était le cas jusqu'alors. On fait comme pour les dates d'entrée et d'ancienneté : ces 3 dates sont à blanc et sont en saisie. Cela évite que cette date soit conservée par erreur d'un contrat précédent. Ainsi, s'il s'agit d'un CDD, elle devra être resaisie, la zone étant obligatoire dans ce cas.

Dans le cahier technique N4DS, la rubrique S40.G25.00.029-Nombre d'heures travaillées pour la période n'est pas déclarée comme étant obligatoire, alors qu'en fait, elle l'est dès lors que le code unité indiqué dans la rubrique S40.G15.00.001 est 10-Heure, ce qui est le cas général.

Du coup, lorsqu'un salarié dont le code unité de temps de travail effectué est 10-Heure n'a pas travaillé du tout sur une période donnée, le système ne renseigne pas la rubrique S40.G25.00.029 (la rubrique étant déclarée facultative dans le cahier technique), alors qu'il faut le faire avec la valeur 0, sous peine d'avoir un message de rejet de la déclaration.

Cette rubrique S40.G25.00.029 a donc été rendue obligatoire dans le fichier de description de la norme livré au sein de LDPaye (fichier DUGROU). De ce fait, cette rubrique est toujours inscrite dans la déclaration, même si sa valeur est nulle.

Il a été vérifié par ailleurs que le fait de renseigner cette rubrique à la valeur 0 pour un salarié ayant un code unité autre que 10-Heure ne provoque aucune anomalie sur la déclaration.

Lors de l'import d'honoraires dans une DADS-U, si le code pays est renseigné avec une valeur autre que FR, le système porte le code postal dans la rubrique  S70.G10.00.004.016-Code de distribution à l'étranger au lieu de la rubrique S70.G10.00.004.010-Code postal.

Les salariés qui n'ont pas été déclarés et dont le numéro de matricule se retrouve dans le numéro de matricule d'un salarié qui a été déclaré (par exemple, matricule 001 non déclaré et matricule 0001 déclaré) n'étaient pas proposés lors de la création d'une S30 avec choix du salarié.

Auparavant, dans le cas du tableau récapitulatif URSSAF (TR), lorsqu'on créait le fichier DUCS-EDI à transmettre, si la régularisation était négative (c'est à dire, l'URSSAF doit rembourser quelque chose), une ligne PAI avec un montant positif (qui indique donc que l'on va payer l'URSSAF) était générée à tort.

Dorénavant, si la régularisation est négative, le montant de la zone PAI est à zéro et la ligne correspondante n'est donc plus générée dans le fichier à transmettre. Si c'est le cas, un libellé indiquant qu'il n'y a rien à payer s'affiche à côté de la zone montant.

Les valeurs proposées par défaut lors de la création d'un lien entre un élément de paye (rubrique ou cotisation) et un profil (rubrique ou cotisation) sont désormais celles du dernier lien validé (que ce se soit en ajout de lien ou en modification d'un lien déjà présent antérieurement) dans la fenêtre présentant les liens.

Dans le cas où aucun lien n'a été encore créé ou modifié depuis l'affichage de la fenêtre des liens, si tous les liens existants ont les mêmes valeurs (type de lien et comptes associés), ce sont ces valeurs qui sont proposées par défaut.

Lors de la création d'une déclaration N4DS, si le code pays est renseigné dans une adresse salarié et fait référence à un pays autre que la France, le système porte le code postal dans la rubrique S30.G01.00.008.016-Code de distribution à l'étranger au lieu de la rubrique S30.G01.00.008.010-Code postal.

Suite au correctif 133 qui corrigeait un problème sur les salariés qui n'apparaissaient pas dans la liste des salariés à ajouter, le salarié, bien que sélectionné n'était toujours pas créé.

Dorénavant, le salarié est bel et bien créé.

Une nouvelle procédure a été développée pour convertir les écritures comptables issues de LDPaye au format attendu par la comptabilité X3.

Pour plus d'information, consultez le document intitulé IntComptaX3.doc qui se trouve dans le répertoire des documentations de LDPaye suite à l'installation de ce correctif.

Les déclarations DNAC-AE n'apparaissaient plus dans la partie droite de la fenêtre de gestion de ces déclarations lorsqu'on était en base de données HyperFile Client/Serveur dès qu'on sortait de la fenêtre.

On pouvait donc créer, imprimer, créer le fichier final pour une ou plusieurs déclarations. Tout fonctionnait bien tant qu'on ne sortait pas de la fenêtre principale de gestion de ces déclarations. Mais si l'on fermait la fenêtre principale et qu'on la réouvrait immédiatement ensuite, la ou les déclarations DNAC créées antérieurement n'étaient pas affichées, et on ne pouvait donc plus les "retravailler".

Deux choses ont été corrigées sur les sommes isolées :

1) le groupe S44.G40.05 n'était pas créé automatiquement, même si le paramètre S44.G40.05.003.001 était renseigné

2) la rubrique S44.G40.05.002-Année de rattachement de la somme isolée est déclarée dans le cahier technique comme étant de type Date, avec une longueur de 4. De ce fait, le système présentait en saisie une zone Date, et portait dans le fichier final uniquement la partie Jour et Mois (JJMM) de cette date. Or, ici c'est l'année qui est attendue. Pour régler ce problème, le type de cette rubrique a été passée à Numérique sur 4 de long. On doit donc saisir désormais uniquement l'année sur 4 chiffres.

ATTENTION : pour les déclarations où des sommes isolées avaient été saisies avec des dates dans cette rubrique S44.G40.05.002, il faudra corriger les valeurs de rubriques pour ne conserver que l'année.

Lors de la création d'un nouveau dossier de paye dans un nouveau répertoire, certains fichiers étaient copiés à tort depuis le répertoire utilisé comme modèle pour la création du plan de paye. Il s'agissait des fichiers :

- Données de fin de contrat : PEFCTR
- contrats de prévoyance : PECPRE, PECPRS, PECPRA
- N° de rattachement IRC : PMRATC

Toutes ces données sont liées aux établissements ou aux salariés, et comme les établissements et les salariés ne sont pas repris, il ne faut pas reprendre non plus ces données.

La procédure de reprise de données (Salariés, Situations, Constantes, Cumuls...) à partir d'un fichier Excel a été améliorée. On peut notamment inclure des portions de code compilé dynamiquement, ce qui facilite grandement la reprise et évite de réaliser trop de manipulations avec Excel.

La documentation de cette procédure Reprise de données depuis Excel.doc a fait l'objet d'une révision 2 pour décrire ces nouveautés.

Sur les bulletins de paye, le nom du pays s'imprime désormais dans le cadre adresse du salarié, dès lors que celui-ci est autre que la France.

Pour ce faire, les différentes lignes de l'adresse sont légèrement resserrées pour libérer la place de faire figurer le nom du pays destinataire sur une 6ème ligne d'adresse, après le code postal et la ville.

Le calcul d'une cotisation basée UNIQUEMENT sur sommes isolées était erroné dans le cas où il n'y avait aucune autre cotisation T1 ou T2 "classique" entre cette cotisation et une précédente cotisation également basée uniquement sur sommes isolées.

Lors de l'établissement d'une déclaration DNAC-AE (Attestation Pôle Emploi), le système se basait sur l'option Reprise cumuls période précédente pour reconstituer toutes les situations successives concourant au contrat qui se termine, et ce sans limite de date. Cela pouvait donc poser problème si cette option était mal renseignée.

Un contrôle supplémentaire a été ajouté pour arrêter le parcours des situations antérieures dès lors qu'on trouve une situation dont la date de fin est antérieure à la date de début du contrat pour lequel on établit la déclaration.

Les dates saisies dans la fenêtre des informations relatives à la fin de contrat doivent être comprises entre la date de début et de fin de contrat.

Le contrôle de la date d'engagement de la procédure de licenciement a été amélioré. La date doit être inférieure à la plus petite date de début de la période de préavis (si au moins une période de préavis a été renseignée).

On peut désormais imprimer un second cadre comportant des cumuls en pied de bulletin. Ce second cadre vient en lieu et place des 3 lignes de libellé provenant de la fiche Société ou Etablissement, en bas à droite du bulletin. Et dans ce cas, les informations relatives aux congés payés sont redisposées en partie droite du pied de bulletin.

Ce nouveau cadre comporte jusqu'à 9 cumuls, disposés en 3 lignes et 3 colonnes. Chaque ligne et chaque colonne peut comporter sus un intitulé paramétrable. L'objectif principal de ce second cadre est de présenter des données telles que les congés ancienneté ou les repos compensateur, où l'on a traditionnellement une valeur acquise, une valeur prise et un solde. Ces 3 valeurs pourront être ainsi disposées dans les 3 colonnes de ce cadre, avec les intitulés proposés par défaut : Acquis, Pris, Solde.

Le contenu de ce second cadre de cumuls se paramètre dans la fenêtre Plan de paye/Paramètres généraux, sur le nouvel onglet intitulé Bulletin 2. Si aucune case parmi les 9 cumuls disponibles ici n'est renseignée, ce cadre n'apparait pas en pied de bulletin ; on conserve alors l'ancienne disposition, avec les 3 lignes de texte. De même, si pour une des 3 lignes données, les 3 colonnes sont à zéro, le système masque également l'intitulé de la ligne.

Notez que dans la 3ème colonne, celle censée faire apparaitre le solde, on peut indiquer la valeur "*" en lieu et place d'un nom de cumul ; le système fera apparaitre alors à cet emplacement la différence entre la valeur apparaissant en colonne 1 (acquis) et celle apparaissant en colonne 2 (pris).

Enfin, ce second cadre de cumul, lorsqu'il est paramétré, apparait aussi en visualisation de bulletin, sur l'onglet Cumuls.

ATTENTION : pour que cela fonctionne, il faut disposer de l'impression du bulletin standard. Si vous avez opté pour un bulletin spécifique (ou une adaptation du bulletin standard via Etats et Requêtes Utilisateur), il faut reprendre votre état spécifique pour bénéficier de cette nouveauté.

Lors de la préparation des paiements, le système s'assure qu'il ne pourra y avoir, au sein d'un même lot de virements, des virements ne pouvant être émis qu'en CFONB (salariés ayant un RIB renseigné, mais pas d'IBAN) et des virements ne pouvant être émis qu'en SEPA (salariés domiciliés en dehors de la France).

Pour réaliser ce contrôle, le système balayait l'ensemble du fichier salariés, y compris les salariés partis. Désormais, le système ne s'intéresse, dans le cadre de ce contrôle, qu'aux salariés pour lesquels on va réellement émettre un virement : ceux qui ont un net à payer dans le cas du paiement mensuel, ou ceux pour lesquels on a saisi un élément à payer en cas de paiement partiel.

Les informations de paiement et de congés payés apparaissant en pied de bulletin se trouvaient mal positionnées lorsqu'on avait paramétré l'impression du second cadre de cumuls (voir correction N° 151), dans le cas où :

- en visualisation de bulletin, on utilisait les boutons pour passer au salarié suivant/précédent ou au mois suivant/précédent, c'est à dire que l'on affichait un nouveau bulletin sans sortir de la fenêtre ;

- en impression de bulletin, lorsqu'on imprimait plusieurs bulletins en un seul état.

Deux champs ont été rajoutés dans le module bureautique :
- Le champ LPNT qui représente le libellé du pays de nationalité.
- Le champ LPAY qui représente le libellé du pays de résidence.

Si vous souhaitez utiliser ces champs, il faut les rajouter dans le fichier source de données accessible par les paramètres de la bureautique.

Exemple de données à ajouter dans le fichier :
LPNT=Pays de nationalité;PEPERS.LPNT
LPAY=Pays de résidence;PEPERS.LPAY

Lors de la saisie des informations de fin de contrat pour la DNAC-AE, le système examine les bulletins du salariés pour déterminer les codes IRC à utiliser. Cette recherche ne fonctionnait pas pour les salariés ayant un matricule composé de moins de 4 caractères.

L'outil de reprise de données depuis un fichier Excel ne fonctionnait pas pour effectuer une mise à jour de données, ou un ajout d'éléments autres que les données présentes dans la fiche salarié (constantes générales, cumuls...) dans le cas des salariés n'ayant pas de période d'activité portant le N° 000.

Après vérification, il s'avère que la première période d'activité d'un salarié porte le N° 001 si la fiche salarié a été saisie, le N° 000 si la fiche salarié a été créé par une procédure de reprise de  données telle que la fenêtre OUTIREPS. De ce fait, la reprise de données salariés complémentaires par cette procédure OUTIREPS n'était possible que pour les fiches salariés ayant été elles-mêmes créées par cette procédure.

Pour éviter ce problème, les données complémentaires sont désormais ajoutées sur la dernière période d'activité trouvée pour chaque salarié, quel que soit le N° de cette période d'activité.

Un mode de calcul des effectifs un peu particulier a été introduit dans la DUCS-EDI, pour le cas du tableau récapitulatif URSSAF où il faut inscrire, sur les lignes GEN et EN, l'effectif de l'entreprise au dernier jour de la période déclarée.

Cet effectif est habituellement calculé en prenant tous les salariés de la société concernée, en se basant sur le code société inscrit dans les fiches salariés. Une méthode de calcul plus détaillée permet de tenir compte en  sus des N° SIREN portés dans les paramètres Tiers DUCS. Ainsi, comme cela existait déjà en DADS-U, si on gère en tant qu'établissement dans LDPaye ce qui est au sens juridique des sociétés, le calcul des effectifs reste exact.

Pour activer cette nouvelle méthode de calcul, il faut qu'un paramètre programme DADUETAB existe, et qu'il comporte la lettre O (Oui) en position 1 (même principe que pour la DADS-U).

Avec cette nouvelle méthode de calcul, ne sont décomptés dans l'effectif entreprise au dernier jour de la période, que les salariés présents dans la société, et inscrits à cette date dans un établissement dont le SIREN (celui inscrit dans la fiche Tiers DUCS) est égal à celui porté dans la ligne DT-Entreprise déclarante de la DUCS-EDI. L'entreprise déclarante de l'enregistrement DT est celle définie dans la fiche tiers DUCS-EDI de l'établissement concerné, au travers de la zone SIRET du siège.

On rencontrait des problèmes de positionnement dans certaines fenêtres, si on ouvrait plusieurs fenêtres simultanément avec la fenêtre de calcul des bulletins. Cela se produisait notamment :
- si on demandait par exemple l'impression d'un journal de paye alors que la fenêtre de calcul des bulletins était ouverte, au retour dans celle-ci, si on demandait à saisir des éléments variables, cette saisie ne se faisait pas pour le salarié courant dans la fenêtre de calcul, mais pour le dernier salarié apparu sur le journal de paye
- si une fenêtre de liste des rubriques, cotisations, cumuls ou fonctions personnalisée était ouverte pendant un calcul de bulletin ou une saisie d'éléments variables faite depuis la fenêtre de calcul des bulletins, au retour dans l'une des 4 fenêtres citées plus haut, un double clic sur une ligne de la table n'ouvrait pas la bonne fiche en modification.

Les règles de remplissage automatique du formulaire DUE depuis LDPaye ont été modifiées. Désormais, le remplissage se fait à partir de la situation "courante" dans la fenêtre où se trouve le bouton Déclaration DUE. En règle générale, on établit la DUE suite à la création d'une fiche Salarié, et il n'y a donc qu'une seule situation ; cette correction n'a donc aucun effet dans le cas général. Mais si on a saisi successivement plusieurs situations correspondant à plusieurs entrées/sorties, on peut ainsi établir une DUE pour n'importe laquelle des situations saisies.

D'autre part, la date prévisible d'embauche est désormais prise égale à la date d'entrée du salarié, et non plus à la date de début de situation (là aussi, dans le cas d'une entrée, ces deux dates sont en principe égales, et cette correction n'a pas d'effet).

Enfin, la date de fin de CDD est prise égale à la date initiale de fin de CDD portée dans la situation, et non plus à la date de fin de situation (cette dernière n'étant pas toujours renseignée d'avance, lors de la création de la fiche).

La procédure de calcul des bulletins a été revue en profondeur pour diminuer le temps de calcul, notamment sur les dossiers volumineux.

Cette optimisation a portée principalement sur la façon dont sont gérés les cumuls (cumuls salariés et cumuls cotisation) : plutôt que de reporter directement dans la base de données toutes les mises à jour de ces cumuls faites au cours du calcul, ces cumuls sont désormais gérés dans des tableaux uniquement dans la mémoire vive du poste de travail, et ne sont reportés dans la base de données qu'une seule fois à la fin du calcul. On diminue ainsi grandement les accès à la base de données au cours du calcul, ce qui améliore très sensiblement les performances surtout lorsque la base de données est en réseau.

Une seconde optimisation a été faite, dans le cas du recalcul d'un bulletin : elle consiste, en fin de calcul, lorsqu'on doit inscrire les valeurs des cumuls dans la base de données, à procéder par différence : plutôt que de supprimer tous les cumuls en début de calcul pour les recréer en fin de calcul (car ce sont bien souvent les mêmes), on réalise une mise à jour des valeurs des cumuls. Si le résultat final est le même, cette nouvelle façon de procéder est beaucoup plus rapide particulièrement sur les bases ayant de gros volumes, car les temps de traitement nécessaires aux ajouts et suppressions dans les bases de données vont croissants avec la taille des fichiers.

Grâce à ces deux optimisations, tout le monde pourra observer une amélioration notable du temps nécessaire aux calculs des bulletins : entre 20 et 50% de gain selon la configuration (base locale ou réseau, taille des fichiers, premier calcul ou recalcul...). Et cette amélioration est encore plus nette quand il y a plusieurs postes qui effectuent des calculs en parallèle sur un même dossier de paye. 

Seul petit bémol : ces optimisations ont nécessité la réécriture d'une bonne part du programme de calcul des bulletins, avec tous les risques inhérents à cela. Malgré des batteries de tests menés dans différents environnements, sur des plans de paye très variés, nous ne sommes pas à l'abri de petites surprises. Alors, si vous constatez une anomalie suite à la diffusion de ce correctif, faites nous en part au plus vite.

Deux améliorations ont été apportées quant à la gestion des paramètres N4DS :

1) lors de la copie d'une rubrique ou cotisation pour laquelle il existe au moins un paramètre N4DS référençant la rubrique ou cotisation copiée, l'utilisateur est désormais systématiquement informé que la copie a aussi dupliqué le ou les paramètres N4DS liés. Et dans la fenêtre d'avertissement, on a la possibilité d'accéder directement à la fenêtre de gestion des paramètres N4DS pour vérifier/modifier/supprimer les paramètres N4DS issus de cette copie.

2) lors de suppression d'une rubrique ou cotisation, le ou les paramètres N4DS référençant la rubrique ou cotisation supprimée sont eux aussi supprimés. Cela évite de conserver des paramètres qui n'ont plus aucun effet lors de la création d'une déclaration, si ce n'est ralentir la constitution de cette déclaration.

Des améliorations ont été apportées à la procédure de sauvegarde, pour ce qui concerne la sauvegarde des sous-répertoires :

1) seule la partie indispensable du répertoire Etats et Requêtes est désormais sauvegardée. Les sous-répertoires de compilation présents dans ce répertoire Etats et Requêtes sont désormais ignorés (sous-répertoires dont le nom se termine par .cpl). De même, les sous-répertoires nommés Sauvegarde (qui ne contient que des fichiers .bke, .bke, .tke, .tkr) et Historique au sein de ce répertoire Etats et Requêtes sont ignorés.

2) on a la possibilité d'ignorer le sous-répertoire Documents contenant toute l'arborescence des documents GED. En effet, la place nécessaire à la sauvegarde de ce sous-répertoire peut être très importante, et pose problème lorsqu'on réalise des sauvegarde sur clé USB. Notez toutefois que si ce sous-répertoire n'est pas sauvegardé par la procédure de sauvegarde de LDPaye, il faut qu'il le soit par ailleurs, quelle que soit la méthode employée (recopie disque à disque, logiciel de sauvegarde sur un serveur...).

3) la gestion de la jauge qui figure l'avancement des sauvegardes a été simplifiée, car c'est l'affichage de cette jauge qui pénalisait fortement le temps nécessaire à la sauvegarde des sous-répertoires.

Diverses petites corrections ont été apportées dans les procédures de sauvegarde et restauration de LDPaye.
On peut notamment désormais sauvegarder les sous-répertoires même si on est en environnement HF Client/Serveur.

Dans les fenêtres de saisie de l'imputation comptable des rubriques et des cotisations, le compte de contrepartie n'était pas toujours enregistré quand on le modifiait.
En fait, la modification du compte de contrepartie faite sur la première ligne "profil" de la rubrique ou cotisation était perdue si on passait ensuite sur d'autres lignes "profils" de la même rubrique ou cotisation. Pour que la modification soit "conservée", il fallait soit sortir de la fenêtre après avoir validé la première ligne où l'on avait fait la modification, soit aller (par un clic de souris par exemple) sur une ligne d'une autre rubrique ou cotisation.

Dans le calcul d'un bulletin de paye, les éléments déclarés comme étant automatiques en cas de départ sont désormais créés même si la fiche rubrique de l'élément comporte un mois de calcul, et que ce mois de calcul n'est pas égal au mois de paye en cours de calcul, dans la mesure toutefois où la rubrique en question comporte également une période de rattachement.

Ainsi, on peut créer une rubrique type 13ème mois, que l'on déclenche uniquement en cas de départ, mais en renseignant quand même le mois de calcul à la valeur 12-Décembre par exemple, de façon à ce que la période de rattachement soit bien calculée en relatif par rapport au mois de décembre, et non pas par rapport au mois du départ.
Sans cette modification, dans cette configuration, la rubrique ayant un mois de calcul renseignée, elle n'était reprise sur le bulletin que si le départ se faisait en décembre.

ATTENTION aux effets induits : si vous aviez créé 12 rubriques automatiques en cas de départ, une pour chaque mois, avec période de rattachement, ces douze rubriques vont être reprises sur les bulletins en cas de départ, quel que soit le mois du départ !

Autre remarque importante : si on paramètre une telle rubrique 13ème mois automatique en cas de départ, il faut que la méthode de calcul de cette rubrique prenne en charge la proratisation du montant de la prime en fonction de la période de rattachement (et donc de la date du départ notamment).

4 nouvelles fonctions personnalisées sont livrées en tant que modèle, et donc accessibles depuis la fenêtre de gestion des fonctions personnalisées, par le bouton Modèles.

Les 3 premières s'appliquent uniquement à des rubriques de type datées. Elles permettent de calculer le nombre de jours entre les 2 dates début et fin saisies sur l'élément variable en question, avec les variantes suivantes :

Fonction NBJOCA : Nombre de jours calendaires de la période
Fonction NBJOVA : Nombre de jours ouvrables de la période, c'est à dire hors dimanches et jours fériés
Fonction NBJOVR : Nombre de jours ouvrés de la période, c'est à dire hors samedis, dimanches et jours fériés

La 4ème fonction NBJABS est plus complexe. Elle permet de sommer le nombre de jours ouvrés (c'est à dire hors samedis, dimanches et jours fériés), pour une période donnée, de toutes les lignes de bulletins du salarié portant des N° de de rubrique donnés.
La période et la liste des rubriques traitées sont définies directement dans le code source de la fonction.
La période par défaut correspond aux 12 mois qui précédent le mois du bulletin en cours de calcul ;
Les rubriques traitées par défaut sont les 3 rubriques d'absence maladie 1061, 1062 et 1063.

Cette dernière fonction est livré principalement à but didactique ; elle devra systématiquement être adaptée en fonction de ce que l'on cherche à sommer exactement.

Dans certains cas (assez rares), sur des bulletins ayant un net à payer nul (souvent, ce sont des bulletins d'intéressement où tout est placé et non versé au salarié), les zones relatives au mode de paiement et au compte destinataire du virement étaient quand même renseignées.
Autre problème corrigé simultanément : parfois, le montant nul était imprimé sous la forme -0,00 (avec un signe négatif).

La correction a été faite tant en visualisation de bulletin qu'en impression de bulletin.
Attention : si le bulletin a été adapté en spécifique (par Etats et Requêtes Utilisateur), il faut reporter cette correction dans l'état adapté en spécifique. La correction a été faite ligne 37 de la procédure xTraiterBasPage :
La ligne            NET=xLireCumul("NETPAY")
doit être remplacée par  NET=Arrondi(xLireCumul("NETPAY"),2)

La cause de tout cela est une fois de plus la gestion des zones numériques faite par Windows : les zones enregistrées en format "réel" n'ont pas une précision suffisante pour enregistrer toutes les valeurs réelles possibles. Et comme on ne fait pas systématiquement un arrondi quand on additionne les valeurs dans les cumuls, on peut avoir des valeurs de cumuls enregistrées avec plus de 4 décimales.
Exemple :
Val1 est un réel = 1070.44
Val2 est un réel = 85.64
Val3 est un réel = 984.80
Val4 est un réel = Val1 - Val2 - Val3
Val4 vaut ici non pas 0.00 comme on pourrait s'y attendre, mais 0.0000000000001136868377216 !

Suite à la correction N° 190, si on perdait temporairement la licence à un moment donné, on avait une fenêtre qui signalait cet état, avec une temporisation de 5 secondes. Et tout rentrait normalement dans l'ordre au bout de ces 5 secondes.
Seul bémol : cette temporisation de 5 secondes était ensuite active sur toutes les fenêtres de confirmation qui suivaient (fenêtres de type Oui/Non, OK/Annuler...).

Lors du calcul d'un bulletin d'intéressement, on ajoutait un plafond mensuel supplémentaire pour toutes les cotisations calculées sur ce bulletin. Cela n'avait pas d'incidence jusqu'ici, car les seules cotisations calculées sur les bulletins d'intéressement, forfait social, CSG et CRDS, n'avaient pas de plafond.
Mais depuis 2011, l'abattement pour les cotisations CSG et CRDS est plafonné. Et on mémorise donc des cumuls de plafonds pour ces cotisations, de façon à savoir gérer le plafond d'abattement en cumul annuel.
Il ne faut donc pas que le calcul d'un bulletin d'intéressement en cours d'année, en sus des bulletins de paye, quel que soit le moment où on le calcule et même si le bulletin d'intéressement est le premier bulletin de l'année, majore le plafond d'abattement de la CSG.
C'est ce qui est fait désormais : les bulletins d'intéressement sont toujours calculés sans majoration des cumuls de plafond pour toutes les cotisations calculées sur ceux-ci. 

Remarque : si vous avez calculé des bulletins d'intéressement en 2012 antérieurement à cette correction, aucun "rattrapage" des cumuls n'est prévu en automatique. Cela devrait être sans incidence pour la plupart des salariés, le plafond d'abattement de la CSG, à 4 fois le plafond Sécurité Sociale, étant rarement atteint en fin d'année (cela fait quand même 145488€). Si cela était le cas toutefois pour certains salariés (en cas de départ en cours d'année avec de grosses indemnités de départ par exemple), il convient de corriger les cumuls de plafond du dernier bulletin précédent le bulletin en cours de calcul, en minorant la valeur Cumul plafond de 12124 (3031 x 4).

Suite à la correction N° 176 qui a modifié en profondeur la méthode de calcul et surtout de recalcul des bulletins, si on recalculait un bulletin déjà marqué comme ayant fait l'objet d'un virement, le bulletin après recalcul était lui aussi marqué comme étant viré.

Par souci de compatibilité avec ce qui était fait antérieurement à la correction N° 176, le bulletin après recalcul est désormais marqué comme non viré.

Dans la fenêtre d'édition des bulletins, on avait des problèmes si la sélection des bulletins à imprimer comportait à la fois des bulletins de paye et des bulletins d'intéressement. Le problème venait du fait que les cumuls à faire apparaître en pied de bulletin ne sont pas toujours les mêmes selon qu'il s'agit d'un bulletin de paye ou d'un bulletin d'intéressement. On avait donc dans certains cas des cumuls qui n'étaient pas remis à zéro.
Pour éviter cela, deux choses ont été faites :

1) lorsqu'on demande l'impression de tous les bulletins calculés pour un mois donné, depuis la fenêtre de calcul des bulletins de paye ou directement depuis le menu, le système n'imprime que les bulletins de paye, mais pas les bulletins d'intéressement. A l'inverse, quand on fait ce choix depuis la fenêtre de calcul des bulletins d'intéressement, seuls les bulletins d'intéressement du mois demandé sont imprimés.
On revient ainsi au mode de fonctionnement qui était celui proposé en version 6, et qui avait été modifié incidemment en version 7 suite à la mise en place des possibilités d'envoi des bulletins par mail et/ou dans la GED.

2) lorsqu'on demande l'impression de tous les bulletins calculés pour un salarié donné sur une période donnée, il peut y avoir au cours de cette période des bulletins de paye et des bulletins d'intéressement. La procédure d'impression des bulletins a donc été revue pour gérer correctement ce cas de figure : toutes les cases de cumuls figurant en pied de bulletin sont systématiquement remises à zéro pour chaque bulletin, quel que soit son type : paye ou intéressement. Ainsi, même si une case de cumul n'est pas gérée pour un type de bulletin donné, on est certain qu'aucune valeur ne figurera par erreur dans la case.

Complément technique : si la procédure d'impression du bulletin a été adaptée en spécifique (par Etats et Requête Utilisateur), cette seconde partie de la correction ne sera pas opérationnelle. Il faut reporter la correction dans la version "spécifique" de la procédure d'impression. Cela concerne la procédure locale xTraiterBasPage, lignes 25 et 27 (le code ajouté figure en orange ci-dessous) :
//  2) Lecture des valeurs
NomCumul = ExtraitChaîne(PACUBU:ValeurAlpha[[j A j+63]],2,";")
SI PAS NomCumul ~= "" ALORS {"CUMM"+i,indChamp} = xLireCumul(NomCumul) SINON {"CUMM"+i,indChamp} = 0
NomCumul = ExtraitChaîne(PACUBU:ValeurAlpha[[j A j+63]],3,";")
SI PAS NomCumul ~= "" ALORS {"CUMA"+i,indChamp} = xLireCumul(NomCumul) SINON {"CUMA"+i,indChamp} = 0

Des modifications ont été apportées courant mai 2012 dans le cahier des charges de la déclaration MSA, et s'appliquent à la déclaration du 2ème trimestre 2012.

Les modifications ne concernent que du paramétrage ; rien n'a été modifié dans les programmes proprement dit. Suite à l'installation de cette nouvelle version du module MSA, il faut vérifier les paramètres suivants :

PE41-Zone 33 code type 53 : Assiette CSG-RDS
Jusqu'alors, cette assiette incluait l'épargne salariale. A partir du 2ème trimestre 2012, cette épargne salariale doit être isolée dans le nouveau code type de rémunération 77. Cela concerne la CSG due sur la participation, sur l'intéressement et sur les abondements aux PEE, PEI ou PERCO.
Cela suppose que dans LDPaye, les cotisations CSG-CRDS sur cette épargne salariale (notamment sur les bulletins d'intéressement) ait été isolée sur une cotisation distincte de la CSG-CRDS "normale" due sur les salaires. Si ce sont les mêmes cotisations qui sont utilisées dans les deux cas, une régularisation manuelle (par saisie salarié par salarié) devra être opérée directement sur la déclaration MSA.
Si les cotisations sont distinctes, il faut modifier vos paramètres MSA pour faire en sorte que les cotisations CSG-RDS sur l'épargne salariale soient référencées par le nouveau paramètre PE41-3377, et ne le soient plus dans le paramètre PE41-3353.

PE31-Zone 29 - Nouveaux codes types 20 et 21
Cela concerne la monétisation de droits Compte Epargne Temps (CET) ou de jours de repos non pris. Pour plus de détail, voir cahier technique MSA page 30. Il faudra créer de nouveaux paramètres MSA avec ces codes PE31-2920 et/ou PE31-2921 si vous êtes concernés.

Pour plus d'informations, et avant d'établir votre déclaration MSA du 2ème trimestre 2012, il est vivement conseillé de prendre connaissance du cahier des charges MSA du 2ème trimestre 2012, où toutes les nouveautés sont listées en page 1.

Nota : toutes les remarques ajoutées dans ce cahier technique concernant le fait que le montant du SMIC retenu pour la réduction Fillon (zone 54 de l'enregistrement PE31) doit être déclaré avec 2 décimales avaient déjà été prises en compte dans la version 3.12 de ce module MSA, diffusée le 6 avril 2012 (diffusion ciblée aux seuls clients MSA, hors LDUpdate). Rien de plus n'a donc été fait à ce sujet dans cette version 3.13, qui reprend bien entendu les corrections apportées dans la version 3.12.

La correction N° 169 avait réglé des problèmes de positionnement dans certaines fenêtres, si on ouvrait plusieurs fenêtres simultanément avec la fenêtre de calcul des bulletins. Cela se produisait par exemple si une fenêtre de liste des rubriques, cotisations, cumuls ou fonctions personnalisées était ouverte pendant un calcul de bulletin : au retour dans l'une des 4 fenêtres citées plus haut, un double clic sur une ligne de la table n'ouvrait pas la bonne fiche en modification.

Cette correction avait cependant engendré un autre problème lors de la copie d'une rubrique, cotisation, cumul ou fonction personnalisée. Si au cours de la copie de l'élément, au lieu de valider la copie directement par le bouton OK, on basculait sur un autre écran par l'un des boutons situés à droite (Profils, Cumuls, Conditions...), on se retrouvait à modifier non pas l'élément créé par copie, mais l'élément à l'origine de la copie.

Il est désormais possible de réindexer les fichiers DADSU et DNAC via l'utilitaire de réindexation dans le menu Outils / Réindexation des fichiers.

La liste des paiements est désormais propre à chaque société du même répertoire de paye. Auparavant, la préparation d'une liste de paiement écrasait systématiquement la dernière préparation, ce qui empêchait de préparer la liste de paiements pour deux sociétés en même temps.
Cela corrige aussi le risque d'obtenir, lorqu'on demandait la réimpression de la dernière liste de paiements, une liste de paiement d'une société autre que la société en cours.

Dans la procédure de saisie des éléments variables, une nouvelle option de duplication d'un élément variable est offerte, via un nouveau bouton Dupliquer. L'objectif est de reproduire un élément variable existant sur un grand nombre d'autres salariés, salariés qui peuvent être choisis selon différents critères. Cela peut être particulièrement utile pour saisir :
- les congés lors de la fermeture d'une entreprise
- une prime dont le montant serait uniforme pour certaines catégories de salariés.

Cette nouvelle procédure de duplication d'un élément variable est décrite en détail dans la note d'information qui suit (correction N° 201).

Dans les déclarations DUCS-EDI, le code qualifiant du montant de chaque cotisation (lignes COT de la DUCS-EDI, position 68) est initialisé à la valeur 941 pour une cotisation, 951 en cas de remboursement de cotisation.
Mais lorsque le montant de la cotisation était nul, en raison d'un taux faible appliqué sur une base elle même assez faible (ce qui peut se produire dans un établissement ayant très peu de salariés, sur les cotisations prévoyance par exemple), ce code n'était pas initialisé, entrainant le rejet de la déclaration.
Désormais, lorsque le montant de la ligne de cotisation est nul, et qu'il s'agit d'une cotisation de type Taux (ne concerne donc pas les cotisations forfaitaires), le code qualifiant est initialisé en tenant compte de la base de la cotosation portée en position 95 : si cette base est supérieure à zéro, code 941, si cette base est négative, code qualifiant 951.

Dans l'état des cotisations, s'il y avait assez de place sur la première page pour afficher plusieurs établissements, la rupture sur le deuxième établissement ne se faisait pas correctement. Il était imprimé aussi sur la première page (au lieu de faire un saut de page) et le code et libellé de l'établissement correspondait au premier (mais les montants correspondaient au second).

Désormais, la rupture se fait correctement. Il y a un établissement par page et le code et libellé sont corrects.

Lorsque LDPaye tient une licence, le logiciel de la MSA ne consomme plus un nouveau jeton de licence (pour un même poste).

Les zones de saisie du code BIC (le code venant en complément d'un IBAN) ont été élargies afin d'afficher l'ensemble des 11 caractères possibles pour ce code. Cela concernait la fiche salarié, la fiche des comptes bancaires de la société, et certains écrans du module DUCS-EDI.
Le code BIC a également été ajouté sur l'impression de la fiche individuelle, suite à l'IBAN.

Pour un virement SEPA, la liste des caractères acceptés pour les données constituant le virement (nom du bénéficiaire, domiciliation bancaire...) est beaucoup plus restrictive que pour un virement domestique. Seules les lettres A-Z, a-z, les chiffres et quelques caractères spéciaux sont acceptés : /-?:().,+

Or, en saisie des coordonnées bancaires par exemple, LDPaye accepte d'autres caractères que ceux-ci. Pour éviter d'avoir un rejet du virement SEPA, LDPaye remplace désormais les caractères non acceptés dans un virement SEPA lors de la constitution du fichier SEPA, avec les règles suivantes :
- les voyelles accentuées (minuscules ou majuscules) sont remplacées par leur équivalent sans accent ;
- le C cédille (majuscule ou minuscule) est remplacé par un C sans cédille
- certains caractères spéciaux sont remplacés en tenant compte des règles édictées dans le document intitulé SEPA Requirements for an Extended Character Set (UNICODE Subset) - Best Practices : € par E, @ par (at), & par +, _ par -.
- les autres caractères non reconnus sont remplacés par un espace.

Dans toutes les fenêtres de pointage (celles qui présentent des coches vertes, sur lesquelles ont peut cliquer pour sélectionner ou désélectionner un élément), l'appui sur la touche Espace (Barre d'espacement) avait le même effet qu'un clic dans la colonne de pointage.
Or, cela posait problème quand on utilisait les zones de filtrage située en tête de table, zones accessibles par F2. En effet, dans ces zones de recherche (les recherches sur libellé notamment), on pouvait être amené à frapper un espace. Et dans ce cas, l'espace était intercepté par le système et provoquait un pointage ou dépointage de la ligne courante de la table, en plus d'être pris en compte dans la zone de recherche. On modifiait donc le plan de paye sans qu'on s'en rende compte vraiment : très dangereux !

Pour éviter cet effet de bord, la touche Espace n'est plus interceptée par le système dès lors que le focus se trouve dans l'une des zones de recherche en tête de table.
Parallèlement à cela, la touche de fonction F9 joue désormais dans toutes ces fenêtres le même rôle que la touche Espace, mais elle a l'avantage de fonctionner même quand le focus se trouve placé sur un champ de recherche. Ainsi, lors de la frappe d'un critère de recherche, dès que la première ligne affichée dans la table est celle que l'on recherche, on peut utiliser la touche F9 pour la sélectionner ou la désélectionner.

Dans le même esprit, dans les quelques fenêtres où il y a 2 colonnes pointables (par exemple, dans la fenêtre de choix des reports d'une cotisation sur un cumul, la 1ère colonne correspond au report de la part salariale, la seconde au report de la part patronale), la touche F11 joue désormais pour la seconde colonne le même rôle que la touche F9 sur la première colonne.

Enfin, tous les messages d'aide figurant au bas de ces fenêtres de pointage ont été révisés, pour indiquer l'usage possible de la touche F9 (et F11 lorsque cela est disponible).

Le parcours des cumuls dans la fenêtre d'affichage des utilisations du cumul (clic sur Utilisation dans un type de cumul, puis clic sur les boutons de parcours en bas à droite de la fenêtre) provoquait une erreur :

Erreur à la ligne 3 du traitement Procédure locale xTraiterBoutonParcours.
Les paramètres d'appel du code 'Méthode Parcourir' sont incorrects : on attendait 1 paramètres et on en a reçu 2.

Dans certains cas, le remboursement d'un prêt pouvait continuer à être déclenché, à 0, malgré le remboursement total déjà obtenu, ce qui pouvait empécher le déclenchement d'un autre prêt sur le salarié sur la même rubrique de prêt.

Il y avait un dysfonctionnement dans les procédures d'export/import des journaux standards, lorsqu'un autre journal existait dans la liste des journaux (au moment de l'export) avec un nom commençant par le même nom que celui du journal exporté.
Exemple : on exporte le journal JNALPAYE, alors qu'il existe un journal JNALPAYE2. On pouvait se retrouver alors, dans le nouveau journal importé, avec les colonnes de JNALPAYE2 (en partie ou en totalité) au lieu de celles de JNALPAYE.

Ajout de l'option d'installation simplifiée des programmes de la version 7.10 de LDPaye.

Pour l'installation, se référer à la documentation des nouveautés de la version 7.10