Première mise à disposition Version 8.00
pour les clients "pilote DSN" uniquement

Le taux d'une cotisation agrégée DSN était limité à 2 décimales, alors que partout ailleurs, les taux de cotisations acceptent jusqu'à 4 décimales.
Les modifications ont donc été faites pour accepter 4 décimales sur le taux d'une cotisation agrégée :
 - sur l'écran de définition d'une cotisation agrégée (paramétrage des bordereaux de cotisation DSN)
 - en impression d'un bordereau de cotisation DSN
 - en impression d'une DSN mensuelle

Lorsqu'on utilisait une date de règlement spécifique par société, la date n'était prise en compte qu'à la première modification. Les modifications suivantes étaient ignorées et on conservait donc cette première date saisie.

Dans certaines fenêtres où l'on avait une date en saisie, si on choisissait une date en faisant appel au calendrier (soit par le bouton Calendrier, soit par la touche F4), on avait un message : "Il n'existe pas de fenêtre de sélection pour le champ en cours." lors de la fermeture du calendrier.
Au passage, le positionnement en retour du calendrier a été amélioré : on se retrouve désormais toujours sur le champ Date pour lequel le calendrier a été ouvert, même si le champ en saisie au moment où l'on a cliqué sur le bouton d'ouverture du calendrier n'était pas le champ date situé en regard de ce bouton.

Les nouveaux champs de type Date, ajoutés en version 8, ne contrôlaient pas correctement les dates en sortie de champ. Ces champs ont tous été revus pour mettre en oeuvre le contrôle standard.

Une nouvelle possibilité de conditionnement dans le paramétrage des rubriques, cotisations et bordereaux de cotisations a été ajoutée.

Elle porte sur la nature de la caisse de congés payés qui est définie dans la situation du salarié, onglet Régime.

L'outil Comparaison des assiettes entre cotisations ne prenait pas en compte tous les reports de rubriques effectués sur la cotisation modèle. Seules les rubriques utilisées par les autres cotisations étaient prises en compte.

Dans LDPaye V7.20, lors de la saisie d'un N° de rubrique, on passait automatiquement au champ suivant après avoir frappé les 4 chiffres du N° de rubrique. Dans LDPaye Version 8, les N° de rubrique étant constitués de 4, 5 ou 6 caractères, ce comportement avait été perdu. Cette correction rétablit le comportement antérieur : la saisie complète d'une rubrique ou d'une cotisation ne permettant aucune ambigüité avec un autre élément de paye provoque la sortie automatique du champ.

Version 3.80.001
Mise à disposition

Version 3.80.002
Amélioration : ajout de compteurs calculés basés sur le système de compteurs issus de LDPaye
Correction : Dans l'état récapitulatif, si un salarié n'est pas présent dans la société, on indique que la journée n'est pas travaillée au lieu d'afficher la durée théorique de la journée.

Version 3.80.003
Correction : Les heures supplémentaires ne se calculaient pas pour un motif ayant un code à 2 caractères
Correction : Lorsqu'on quittait un champ de saisie d'heure, il prenait la valeur 00:00
Correction : Meilleure gestion des tabulations
Correction : Le motif totalisant les heures saisies sur la période ne prenait pas les heures d'un cycle à cheval sur 2 mois.

Version 3.80.004
Amélioration : il est désormais possible de ne plus ramener à l'heure de référence un pointage s'il se situe dans la période de tolérance.
Correction : lors de l'interface, les jours d'absence ne pouvaient pas avoir de chiffre après la virgule.
Amélioration : LDPointage peut fonctionner désormais en Hyperfile client / serveur.

Il est désormais possible de laisser ouverte la fenêtre de modification d'une déclaration DSN et/ou de contrôle d'une déclaration DSN, tout en pouvant visualiser d'autres éléments du dossier de paye (pour contrôler les paramètres ou le plan de paye par exemple).
Pour éviter tout souci de modification d'une déclaration par plusieurs personnes, il n'est pas possible d'ouvrir une même déclaration plusieurs fois (que ce soit sur le même poste ou non).

En modification d'une déclaration DSN, suite à la correction N° 31 qui permet pour les rubriques numériques d'avoir un masque d'affichage adapté à la taille de la rubrique et au fait qu'elle accepte ou pas une partie décimale, on ne pouvait plus saisir de valeur négative.
Cette nouvelle correction permet désormais de saisir des valeurs négatives pour les rubriques numériques où cela est autorisé (en fonction de l'expression régulière associée à la rubrique dans le cahier technique).

La gestion du cas particulier qu'est le code CTP 437 a été améliorée, d'une part dans l'impression des bordereaux de cotisations, d'autre part dans la gestion des bordereaux de cotisations DSN.
Jusqu'alors, le code CTP 437 (Déduction Allocation Familiale Taux réduit) ne venait en lieu et place d'un des codes CTP 430, 432 ou 434 (Complément Allocation Familiale) que si l'assiette cumulée pour tous les salariés d'un établissement était négative.
Avec cette correction, le système cumule d'une part sur les codes habituels 430, 432 et 434 les assiettes positives de la cotisation Complément Allocations Familiales, d'autre part sur le code 437 les assiettes négatives (celles des salariés qui repassent en cumul annuel en dessous du seuil de déclenchement du Complément AF, seuil qui est à 1,6 SMIC). On peut donc avoir sur un même bordereau des lignes de code 430, 432, 437 et 437.
Aucun paramétrage supplémentaire n'est requis pour bénéficier de cette nouveauté : c'est le système qui gère cela de manière transparente.
Note : au final, dans la déclaration DSN, les lignes de codes 437 sont portées en tant que "réduction", c'est à dire avec seulement le montant de la cotisation renseignée, sans assiette.
Complément d'information : cette modification n'a pas été faite dans le module DUCS-EDI qui va être remplacé courant 2015 par la DSN.

Il est désormais possible d'imprimer le registre du personnel à partir du menu Gestion / Imprimer / Registre du personnel.

Les sauts de ligne multiples, définis dans le paramètre programme BULLETAP4 ne fonctionnaient pas. Aucune ligne n'était sautée dans ce cas.
Pour rappel, les sauts de ligne multiples sont définies de la manière suivante : XXXX:y où XXXX correspond au n° de rubrique et y au nombre de lignes à sauter.

Plusieurs soucis ont été corrigés dans la création d'une DSN avec plusieurs arrêts de travail :

• s'il fallait déclarer en même temps une déclaration mensuelle "à zéro" pour le mois précédent, le programme créait autant de blocs de déclarations mensuelles que d'arrêts déclarés (mais un seul était rempli).
• l'éventuelle déclaration mensuelle du mois précédent n'était pas correctement remplie (seul 1 salarié concerné par les arrêts avait ses valeurs renseignées)
• par défaut, la référence de l'envoi créé finissait par "££££" pour signifier qu'il y avait plusieurs salariés concernés. Ces caractères n'étant pas bien reconnus lors de l'appel de l'outil de contrôle en ligne de commande, la référence se termine désormais dans ce cas par "XXXX". Cette modification a également été faite dans le cas d'une DSN fin de contrat avec plusieurs fins de contrat dans le même envoi.

Dans le module de gestion avancée des arrêts de travail, la méthode de calcul livrée par défaut pour calculer le salaire de référence pour l'indemnité journalière de Sécurité Sociale a été entièrement revue.
Elle est maintenant conforme aux nouveautés de janvier 2015, et traite les 3 cas de figure : arrêt maladie "ordinaire", arrêt maternité ou paternité, arrêt pour accident de travail, de trajet ou de service.
Remarque : dans le 3ème cas (accidents travail, trajet ou service), la règle qui dit que le gain journalier net ne peut être supérieur au salaire journalier de référence diminué de 21%. En effet, cette règle ne peut être mise en oeuvre que dans la période au delà du 28ème jour d'arrêt, où le salarié est indemnisé à 80% du salaire journalier de référence. Auparavant, l'indemnisation étant seulement de 60% du salaire journalier de référence, cette limite ne peut pas être atteinte. Telle que la mécanique est conçue dans LDPaye, on ne sait pas mettre en oeuvre ce plafonnement.

La méthode de calcul de la durée d'indemnisation a elle aussi été revue pour prendre en compte le cas des arrêts Maternité-Paternité, où l'indemnisation est de 100% du gain journalier net.

Les fonctions "modèle" correspondantes ont elles aussi été corrigées (fonctions SalaireJournalierPourIJSS et DuréeIndemnisationSS).

Lors de la création du fichier DSN, le système affiche désormais une alerte lorsqu'une nouvelle version de DSNVAL est disponible sur le portail de Net-entreprises.

Lors de la création d'une DSN, pour ce qui est des blocs 30-Individu, les N° de Sécurité Sociale composés du chiffre "1" ou "2" suivi de 12 "9" n'étaient pas remplacés par un N° technique temporaire, comme cela était annoncé dans la documentation.
Rappelons que ce N° technique temporaire n'est utilisé que dans le cas où le N° SS est composé uniquement de "9". Dans le cas d'un N° SS incomplet, où il manque par exemple le N° de commune et le rang de naissance dans cette commune, le N° est complété à droite par des "9" pour obtenir un nombre à 13 chiffres.

Nouveautés liées à la parution du cahier technique du 1er trimestre 2015

Gestion du code motif de rupture du contrat de travail dans les enregistrements PE21 : ce code est géré lors de l'initialisation d'une déclaration (création des enregistrements PE21), en modification de ces enregistrements PE21, sur la liste de contrôle et bien sûr lors de la création du fichier final.
Ce nouveau code motif de rupture du contrat, dont la codification est propre à la MSA (voir point (53) du cahier technique), est "calculé" lors de l'initialisation d'une déclaration trimestrielle, à partir du code motif de fin de contrat Pôle Emploi.
La correspondance entre les codifications MSA et Pôle Emploi est fournie dans un fichier Excel (fichier Motifs Rupture contrat MSA.xls). Compte-tenu que cette correspondance n'est pas évidente, cette table peut être ajustée par chaque entreprise, depuis le menu Fichier/Motifs de rupture de contrat.
D'autre part, le cahier technique 1er trimestre 2015 prévoit des enregistrements PE33 pour gérer les nouvelles données liées à la pénibilité.
LDPaye ne gèrera ces données pénibilité que dans la version 9, prévue pour septembre 2015. Ce n'est donc qu'à ce moment là que ces enregistrements PE33 seront supportés dans ce module MSA.

Une erreur a été corrigée dans la génération des journaux standards ayant un regroupement par code analytique. 
Le programme générait un cumul des pourcentages qui n'était pas toujours 100% par salarié : pour certains d'entre eux, il affectait à tort un écart sur le code analytique découlant du service, en sus de la ventilation saisie pour le salarié au mois le mois.

Dans la procédure de création d'une DSN mensuelle, en raison d'une "fuite mémoire" importante, le programme se plantait sur un débordement mémoire lors qu'on avait un grand nombre de salariés au sein de la déclaration (et qu'il existait au moins une DSN mensuelle antérieure pour ces salariés). Cette "fuite mémoire" a donc été colmatée.
Au passage, différentes jauges de progression ont été ajoutées dans cette procédure, permettant de mieux suivre l'avancement de celle-ci quand le nombre de salariés et/ou d'établissements à traiter est conséquent.
Une autre optimisation a été faite aussi, pour diminuer le temps d'attente à l'ouverture de la fenêtre de création d'une déclaration.

Dans la saisie des paramètres d'un bordereau de cotisation URSSAF en DSN, un contrôle avait été ajouté pour vérifier la cohérence entre le code de la cotisation agrégée (le code CTP URSSAF) et le fait que la cotisation doit être détaillée par code AT ou pas. Ce contrôle (un simple message d'avertissement) avait été mis en place pour une liste de codes CTP assez restreinte : 100, 161, 701, 863, 963.
Cette liste a été étendue à tous les codes CTP ayant le format A, soit à ce jour :
100;104;110;112;122;160;161;162;164;168;172;176;180;184;188;194;198;202;226;239;246;302;336;338;346;370;402;404;420;460;
626;701;703;705;707;734;755;789;790;803;805;815;817;830;832;834;863;926;948;952;963;964;968;984

Notez que ce contrôle était également effectué lors de la modification d'une ligne d'un bordereau créé pour un mois donné.
Et que cette liste de codes CTP était également utilisée lors de la création des paramètres du bordereau URSSAF DSN à partir d'un bordereau URSSAF "ancienne formule" (le bordereau DUCS).
C'est désormais la même liste "étendue" qui est utilisée pour ces 3 usages.

Les coches de gestion Prise en compte dans le calcul des effectifs sur BRC et sur TR, pour les contrats de type 21, 41, 61 étaient systématiquement recochées quand on rappelait le type de contrat en modification.

L'outil de renumérotation des rubriques et cotisations (pour passer des rubriques ou cotisations de 4 à 5 ou 6 chiffres) ne traitait pas le fichier des conditions sur ces rubriques ou cotisations (fichier PMCDEP). De ce fait, le lien entre une rubrique et une condition était perdu.

Depuis la fenêtre Gestion du personnel dans le planning (accessible par le menu Fichiers / Autres paramètres / Planning et Gestion des heures), il est possible d'accéder à une fenêtre de paramétrage accessible par la combinaison de touche Alt F1.
Les tables de correspondances des zones Groupes et Profils ne mémorisaient pas la valeur Aucune. A la place de cette valeur, c'est la valeur Code statistique 1 qui était prise en compte.

Les effectifs ne sont désormais plus calculés (blocs 06 et 11) dès lors que la DSN de l'établissement est créée avec la nature "Néant".

Le code calcul MC utilisé pour le calcul de la majoration des CDD ne fonctionnait pas en version 8 si le module DSN n'avait pas été activé.

Lors de la préparation d'un bordereau URSSAF en DSN, un contrôle supplémentaire est réalisé sur le total du bordereau, en plus des contrôles déjà opérés sur chaque cotisation agrégée.
Désormais, un avertissement est émis :

• si la différence entre le total calculé pour le bordereau et le total cotisations de toutes les lignes de bulletins rattachées à l'organisme URSSAF est supérieure au nombre de lignes du bordereau divisé par deux (la différence maximale liée aux arrondis est en effet égale au nombre de lignes x 0,50€ par ligne).
• si la différence entre le total cotisations de toutes les lignes de bulletins rattachées à l'organisme URSSAF et le total de toutes les cotisations prises en compte sur les différentes cotisations agrégées est supérieur à 1€ (sachant que si toutes les cotisations URSSAF ont été référencées sur une et une seule cotisation agrégée, cette différence devrait être nulle).

Parallèlement, sur l'état de contrôle d'un bordereau DSN, apparait maintenant au bas de l'état, en italique, le total cotisations de toutes les lignes de bulletin rattachées à l'URSSAF dès lors que ce total est différent du total de toutes les cotisations prises en compte sur les différentes cotisations agrégées (total de ce qui apparait dans la dernière colonne de l'état).

Dans les procédures de création d'une déclaration DADS-U ou DSN, lorsqu'il faut calculer le montant du SMIC à partir d'un cumul d'heures (le cumul RFHORR en général), le taux horaire du SMIC est recherché en priorité dans le cumul RFTAUX, puis à défaut dans la constante générale RFTAU1. En dernier recours, ce taux horaire est donné directement par le programme, grâce à des valeurs inscrites "en dur" dans celui-ci en fonction de la date à laquelle on recherche le SMIC.
Deux problèmes ont été corrigés dans ce mécanismes :
1) on faisait référence à la constante salarié RFTAU1 (qui n'existe pas) au lieu de la constante générale RFTAU1
2) le cas du SMIC 2015 (taux horaire = 9,61) n'était pas géré : la dernière valeur était celle de 2014 : 9,53.

Note : cela était sans conséquence la plupart du temps, car en DSN comme pour la DADS-U 2015 à venir, on est censé faire référence désormais au cumul MTSMIC qui contient directement la valeur mensuelle du SMIC en euros, et non plus au cumul RFHORR. On n'a donc plus besoin de connaitre le taux horaire du SMIC au mois le mois. Mais si on faisait encore référence au cumul RFHORR, ce cumul était multiplié par 9,53 et non 9,61.

Dans la dernière révision du guide utilisateur  Comment déclarer les cotisations URSSAF en DSN, le GIP-MDS nous a informé d'un traitement particulier du cas des remboursements de réduction Fillon dans les déclarations DSN. Dans ce document, il est dit qu'il faut déclarer le montant de remboursement dans la rubrique 004-Montant d'assiette du bloc 23-Cotisation agrégée (au lieu de la rubrique 005-Montant de cotisation utilisée habituellement, lorsqu'il s'agit bien d'une réduction et non du remboursement d'un excédent de réduction).
Afin d'être plus clair pour les utilisateurs, il a été décidé que cette particularité sera ignorée dans le module du bordereau DSN. Le montant de la réduction Fillon, quel que soit son signe (et donc son code CTP, 671 ou 801) est donc toujours affiché dans la zone Montant.
C'est uniquement lors de la création de la DSN que le montant sera affecté à la rubrique 004 pour le code CTP 801.
Toujours dans l'idée que cela reste compréhensible pour l'utilisateur, l'état de contrôle DSN affiche ce remboursement également dans la colonne Montant alors même qu'il est enregistré réellement dans la rubrique 004 correspondant à une assiette.

La gestion de l'activité par période, qui concerne les blocs 51-Rémunérations pour Pôle Emploi (celui ayant le code type 002-Salaire brut soumis à contributions d'Assurance chômage) et les blocs 53-Activité qui lui sont rattachés, a été revue, pour tout ce qui touche aux rappels d'activité.
Désormais, pour les lignes de bulletins attachées à des rubriques définies comme étant de type Rappel d'activité et saisies sur des dates hors de la période de référence, il y a :

• déduction du volume d'activité sur la période courante. La déduction s'opère en montant sur le bloc 51 et en nombre sur le bloc 53 de même type d'activité 01, 02 ou 03 que celui indiqué dans la rubrique.
• ajout de ce volume d'activité sur des blocs 51-53 pour la période correspondant aux dates de la ligne de bulletin. L'ajout s'opère là aussi en montant sur le bloc 51 et en nombre sur le bloc 53.

De plus, s'il s'agit d'éléments de type 02-Durée d'absence non rémunérée ou 03-Durée non travaillée rémunérée, le nombre (la durée de l'absence donc) est également réintégrée au bloc 53 de type 01-Travail rémunéré sur la période courante, et déduite du bloc 53 de type 01-Travail rémunéré de la période correspondant aux dates saisies (avec pour effet de passer ce nombre en négatif).

Remarques :

1. pour gérer ces rappels d'activité, les déductions et ajouts tiennent aussi compte du sens de la rubrique concernée.
2. les éléments saisis ayant au moins un jour en commun avec la période de référence sont considérés comme faisant partie intégrante de cette dernière et sont donc ignorées par le traitement décrit ci-dessus.
3. Enfin se posait le cas des absences avec maintien de salaire partiel ou des absences CP. Pour celles-ci, l'incidence du rappel d'activité en montant sur chaque période est fausse si on teint compte uniquement de la rubrique d'absence : il faut aussi y ajouter la rubrique de paiement associée. Pour cela, quand on a un jeu de 2 rubriques qui fonctionnent de pair (Absence CP et paiement CP par exemple) et que l'on souhaite pouvoir gérer le rappel d'activité sur ces rubriques conformément à ce qui est attendu en DSN par Pôle Emploi, les 2 rubriques Absence et Paiement doivent être définies comme étant de type Rappel d'activité .(dans notre exemple relatif aux CP, avec le type 03-Durée non travaillée rémunérée). Mais si on fait cela, cela neutralise le calcul de l'activité en heures ou en jours (par exemple, le nombre de jours de CP payés annule l'absence CP en jours). Pour contourner ce problème, on dispose désormais de 3 nouveaux codes à l'invite Prime ou Rappel d'activité dans la définition des rubriques. Ces 3 nouveaux codes permettent de mettre à jour le volume d'activité en montant sur les blocs 51 sans toucher pour autant le volume d'activité sur les blocs 53. Ainsi, dans l'exemple des congés, la rubrique d'absence CP sera définie avec le code 03-Durée non travaillée rémunérée et la rubrique de paiement CP sera définie avec le code 03-Durée non travaillée rémunérée (Montant uniquement). 

Quelques améliorations ont été apportées sur l'écran de définition des contrats de prévoyance, pour une caisse de prévoyance et un établissement donné :
 1) on peut désormais saisir jusqu'à 8 contrats différents pour une caisse et un établissement, au lieu de 5 auparavant
     (en prévision de la DSN, où l'on aura certainement plus de contrats à gérer) ;
 2) les ancrages des différents champs de la fenêtre ont été revus, pour que l'écran soit plus lisible quand on a plus de 4 à 5 contrats
     On a ajouté aussi des boutons pour faire "défiler" les onglets si la taille de la fenêtre ne permet pas de les afficher tous.
 3) le libellé des onglets correspondant aux différents contrats fait apparaître désormais le code identifiant interne de chaque contrat,
     en sus du libellé identifiant.

Enfin, une anomalie a été corrigée. Si on modifiait après coup le code identifiant interne d'un contrat, cette modification n'était pas répercutée sur les contrats définis pour chaque salarié. On perdait donc le lien entre le contrant défini au niveau de l'établissement et ceux définis au niveau des salariés.

Lors de la création d'une DSN mensuelle, les salariés ayant une date de fin de situation sur leur dernière situation (date de sortie) antérieure au mois de la DSN créée étaient ignorés, même s'ils avaient eu un bulletin dans le mois considéré (cas d'un bulletin d'intéressement par exemple).
De même, dans le cas d'une DSN de reprise d'historique, les salariés ayant une date de fin de situation antérieure au premier mois de la DSN Reprise d'historique étaient ignorés.

L'outil permettant de copier des rubriques et cotisations d'un plan de paye à un autre (fenêtre OUTIRELPA) a été amélioré :

• on peut copier en une seule opération une liste de rubriques et cotisations, en donnant une liste de N° séparée par des points-virgules
• les contrôles de cohérence (existence dans dossier origine et non existence dans dossier courant) ont été renforcés
• il est aussi possible de copier des cumuls (nouvel onglet pour cela)
• des outils de contrôle de la cohérence des reports (rubriques sur cumuls, cotisations sur cumuls, rubriques sur cotisations) sont proposés sur le 3ème onglet. Ils peuvent s'avérer utile pour contrôler le résultat final obtenu après les copies.

ATTENTION : cet outil ne doit être utilisé qu'avec beaucoup de précautions, pas un expert LDPaye. Les copies se font sans contrôle de l'intégrité référentielle. Un contrôle d'intégrité référentielle doit donc être fait une fois les copies achevées (outil disponible dans la fenêtre Outils/Autres outils). Et il faut même aller au delà, car le contrôle d'intégrité référentielle ne signale pas certains incohérences qui peuvent être "majeures" pour le calcul des bulletins :

• rubriques copiées dans la plan de paye, alors qu'elles sont alimentées par des constantes générales, constantes salariés, cumuls ou fonctions personnalisées qui n'existent pas dans le plan de paye courant ;
• conditions sur éléments de paye faisant appel à des constantes générales, constantes salariés, cumuls ou fonctions personnalisées qui n'existent pas dans le plan de paye courant.

Tout cela doit être contrôlé méticuleusement par des commandes SQL appropriées...

Deux modifications ont été apportées dans le processus de création d'une DSN pour éviter d'avoir des blocs "nuls" (nombre et montant à zéro) :

• Les blocs 51-Rémunération de code type 011, 012, ou 013 (Heures supplémentaires, heures d'équivalence...) ne sont désormais plus générés si le nombre d'heures et le montant à déclarer dans le bloc sont tous deux nuls.
• De la même manière, les blocs 53 ayant un volume d'activité à zéro ne sont désormais plus générés.

Ces cas de blocs 51-Rémunération ou 53-Activité à zéro pouvaient survenir notamment en cas de rappels d'activités (voir correction 79).

Modification du mode de calcul du montant du SMIC pour les cotisations ayant le code calcul AF (Complément Allocations Familiales) et rattrapage de la différence de ce montant SMIC depuis le début de l'exercice ou le début du contrat.
Pour plus de précisions, reportez vous à la fiche de correction N° 90.

Les adresses utilisées pour le service MSA n'étaient pas correctes ce qui empêchaient d'utiliser les API DSN pour l'envoi des déclarations MSA.

De plus, une erreur d'utilisateur lors de la connexion à l'API DSN n'était pas gérée (Erreur 403)

Nouveautés liées à la parution du cahier technique du 2ème trimestre 2015

La liste des motifs de rupture de contrat (nouvelle zone de l'enregistrement PE21 depuis début 2015) a été modifiée par la MSA. Et surtout, ces codes motifs ne sont plus livrés en 2 listes distinctes, l'une pour les CDD, l'autre pour les CDI (ce qui n'avait pas beaucoup de sens, il faut bien le dire).
Depuis la modification apportée en janvier 2015, les codes motifs de rupture de contrat de travail de la MSA, et surtout la correspondance entre les codes motifs de rupture de contrat de Pôle Emploi et ceux de la MSA, sont livrés dans une feuille Excel (fichier Motifs Rupture contrat MSA.xls).
Compte-tenu que cette correspondance n'est pas évidente, cette table peut être ajustée par chaque entreprise, depuis le menu Fichier/Motifs de rupture de contrat.
Pour tenir compte de l'évolution de cette liste des codes motifs MSA, le fichier Excel Motifs Rupture contrat MSA.xls livré au travers de cette correction contient la nouvelle liste des codes motifs de rupture et la nouvelle table de correspondance entre les codes motifs Pôle Emploi et MSA (avec toujours quelques flous dans cette correspondance). Ce nouveau fichier est pris en compte automatiquement, sauf si vous aviez "personnalisé" la table des motifs au 1er trimestre 2015. Dans ce dernier cas, le système va vous avertir (soit lors de la création de la prochaine déclaration, dès lors qu'au moins un salarié est parti dans le trimestre, soit quand vous demandez l'option de menu Fichier/Motifs de rupture de contrat ) que vous utilisez une table de correspondance plus ancienne que celle livrée aujourd'hui. Il vous propose alors soit de conserver votre table "personnalisée", soit de revenir à la table livrée en standard pour le 2ème trimestre, cette 2ème option étant conseillée.
Si vous choisissez cette seconde option (en répondant Non à la question qui vous est posée), votre table personnalisée est "archivée" sous un autre nom (Motifs Rupture contrat MSA Archive AAAAMMJJ.xls, ou AAAAMMJJ est la date de dernière modification de votre table personnalisée) et ne sera plus utilisée.
Si vous choisissez la première option (en répondant Oui), c'est bien votre table personnalisée qui sera utilisée. Il vous faut alors impérativement ajuster le contenu de votre table de correspondance, la liste des motifs de rupture de la MSA ayant été pas mal bouleversée entre le 1er et le 2ème trimestre 2015. Inspirez vous pour cela de la nouvelle table livrée en standard (fichier Motifs Rupture contrat MSA.xls présent dans le répertoire des programmes de LDPaye).

Jusqu'alors, la saisie d'un code INSEE de commune n'était autorisé que pour la cotisation agrégée de code 900-Versement Transport. Avec cette correction, elle devient possible aussi pour les codes :
 901-TAXE SYNDICAT MIXTE TRANSPORT
 911-TRANSPORT JOURNALISTES TX MINORE 20%
 921-TRANSPORT ARTISTES TX MINORE 30%

Une correction a également été faite sur le bordereau de cotisations "classique" (hors DSN) de façon à ce que les lignes ayant le code type 911 ou 921 soient traitées comme celles ayant le code type 900 ou 901.
En revanche, rien n'a été fait pour le module DUCS-EDI qui est en fin de vie.

En création de bordereau, pour un OPS pour lequel on déclare mensuellement, on proposait à tort de déclarer trimestriellement (voire annuellement) si l'on était sur le dernier mois d'un trimestre (Mars, Juin, Septembre et Décembre). Et cela ne se produisait que pour les sociétés en décalage de paye.

Dans la saisie des paramètres DSN, pour ce qui est du bloc 53-Mesure d'activité, la sélection d'un code unité (Heure, Jours...) est désormais facultative (comme elle l'était au tout début de la version 8).
En effet, ce code unité est facultatif dans le cahier technique. Lorsqu'il n'est pas renseigné, le système considère que l'unité utilisée est celle précisée dans le bloc 40-Contrat. Comme pour la plupart des salariés, la mesure de l'activité se fait à partir de rubrique ayant l'unité Heure que l'unité d'expression du temps de travail définie dans la situation des salariés est aussi par défaut Heure (unité qui sera reprise dans le bloc 40-Contrat), le fait de laisser ce code unité à blanc est sans conséquence, et cela facilite un peu le paramétrage.

Remarque : au passage, à chaque validation d'un paramètre suite à cette correction, on efface la valeur -1 éventuellement présente dans la zone TPD2 (mode d'alimentation du 2ème élément, quand le paramètre n'est pas concerné par ce 2ème élément).

Lorsqu'un salarié avait un matricule qui était le début du matricule d'un autre salarié (par exemple : Salarié 1 : 123 et salarié 2 : 1234), on affichait les documents du second dans la liste des documents du premier.

Un contrôle plus strict effectué par l'outil DSN-VAL à partir du 09/07/2015 nous oblige à déclarer différemment les salariés ayant le même n° de sécurité sociale. Rappelons tout d'abord que comme LDPaye ne peut pas gérer 2 contrats simultanés pour un salarié et une société donnés, lorsque cela se produit (cas par exemple d'un salarié ayant un contrat en tant que salarié et un autre en tant que mandataire), il faut créer le salarié 2 fois dans le fichier de salariés, avec donc 2 matricules différents.
Jusqu'alors, ces 2 salariés étaient déclarés de façon totalement distincte en DSN mensuelle : 2 blocs 30-Individu, chacun ayant un bloc 40-Contrat et un ou plusieurs blocs 50-Versement attaché à chaque contrat.
Désormais, dans ce même cas de figure, on aura un seul bloc 30-Individu auquel seront attachés 2 blocs 40-Contrat. Le regroupement des salariés sur les blocs 30-Individu se fait à N° de Sécurité Sociale identique. Les blocs 40-Contrat sont ajoutés au premier bloc 30-salarié créé (celui portant le plus petit numéro matricule parmi tous ceux ayant le même N° SS). Si parmi les valeurs déclarées au sein de ce bloc 30, des valeurs issues de la fiche salarié diffèrent (Nom, Prénom, Adresse, Date de naissance...), un message d'avertissement signale ce fait à l'utilisateur.
Remarque : les salariés ayant un N° SS incomplet, contenant des valeurs d'échappement "999", ne sont jamais regroupés.

Incidence : suite à cette nouvelle notion de regroupement des salariés, nous avons été obligés de revoir la gestion des N° de contrat. Jusqu'alors, le n° de contrat envoyé par défaut (lorsque celui-ci n'est pas renseigné dans la fiche Situation) était de la forme 00000-AAAAMMJJ, où AAAAMMJJ est la date d'entrée portée dans la situation. Suite au regroupement, on risquait d'avoir donc  2 contrats différents (issus de 2 fiches salariés différentes) regroupés sur un même bloc 30-Individu et portant le même identifiant, si les 2 contrats du salarié avaient la même date d'entrée. Pour éviter cela, le N° de contrat porté par défaut est désormais de la forme NNNN-AAAAMMJJ, où NNNN est le N° matricule du salarié et AAAAMMJJ est la date d'entrée.
Conséquence pratique : sur la première DSN émise pour chaque établissement suite à la mise en place de ce correctif, un bloc 41-Changements contrat va systématiquement être positionné pour chaque contrat (sauf ceux pour lesquels un N° de contrat avait été saisi explicitement dans le fiche Situation, mais cela est rarissime) pour signaler le changement de Numéro de contrat. Ce bloc 41 est indispensable pour que dans le système d'information DSN qui reçoit et stocke les DSN au fil des mois, ils puissent assurer la continuité des contrats malgré cette pseudo-renumérotation des contrats.
Ces blocs 41-Changements contrat seront présents également pour les salariés ayant plusieurs contrats simultanés (donc 2 matricules ou plus) déclarés auparavant sur des blocs 30 distincts et regroupés désormais sur un seul bloc 30.

Dans le même ordre d'idée, pour ce qui est du suivi des contrats et donc de l'émission automatique des blocs 41-Changement de contrat, le lien entre les contrats déclarés dans 2 DSN successives est fait soit sur le n° de contrat si et seulement si le N° de contrat est renseigné dans les 2 déclarations, avec une forme autre que 00000-AAAAMMJJ ou NNNN-AAAAMMJJ, AAAAMMJJ étant la date d'entrée et NNNN le N° matricule). Dans tous les autres cas, le lien se fait uniquement sur la date d'entrée.
A défaut de saisir des N° de contrat explicitement sur les fiches Situation, il faut donc bien comprendre que c'est la date d'entrée qui est l'identifiant unique d'un contrat dans LDPaye, identifiant unique utilisé pour l'émission des blocs 41-Changements contrat utilisés dans le SI DSN pour assurer une bonne historisation des contrats. Et qu'en conséquence, il ne faut plus modifier cette date d'entrée dès lors que le contrat a été transmis sur au moins une DSN.
En l'état actuel des choses, si on doit corriger une date d'entrée déjà transmise dans une DSN mensuelle, il y a 2 façons de faire :
 - Méthode 1 - Via 2 changements successifs dans la situation, à 1 mois d'intervalle
Tout d'abord, il faut saisir un véritable N° de contrat dans la fiche Situation concernée, puis attendre la prochaine DSN mensuelle au sein de laquelle il y aura un bloc 41 signalant ce changement de N° de contrat. Puis le mois suivant cette DSN mensuelle, changer la date d'entrée de la situation sans changer le N de contrat. Et dans la DSN mensuelle qui suit, on aura donc un nouveau bloc 41 signalant le changement de date d'entrée.
 - Méthode 2 - par saisie directe dans la DSN
On change la date d'entrée dans la situation du salarié. Dans la DSN mensuelle qui suit, on crée "manuellement" le bloc 41-Changements contrat pour le contrat concerné, en indiquant dans ce bloc 41 la date d'entrée qui avait été transmise dans la DSN mensuelle précédente.

Lors de l'affichage des situations d'un salarié, LDPaye pouvait indiquer à tort une incohérence entre les périodes d'un bulletin et celle d'une situation. L'incohérence qui était indiquée était en fait celle d'un autre salarié. Cela se produisait lorsque le matricule (sur 3 caractères ou moins) du salarié en question se retrouve dans le matricule du deuxième salarié (matricule sur 4 caractères).

- Dans certains cas, le protocole HTTPS et le certificat de sécurité provoquaient un plantage de l'application lors de l'envoi par l'API-DSN. Cette erreur est désormais gérée et une nouvelle tentative d'envoi (invisible) est effectuée avec des options différentes pour gérer l'erreur.

- L'application se bloquait lorsqu'on demandait l'ouverture de la fenêtre d'envoi juste après une demande de vérification d'une déclaration via l'API-DSN. Dans ce cas, l'application ne rendait jamais la main. Cela se produisait car l'API-DSN n'était pas disponible. Désormais, le blocage ne dure que le temps de la vérification (pour rappel, lorsqu'une vérification est en cours, l'API-DSN est utilisée un cours instant une fois toutes les minutes pendant 5 minutes). Dans des conditions normales, il est possible qu'il y ait un temps d'attente d'une ou deux secondes avant l'ouverture de la fenêtre d'envoi.

Le compte rendu URSSAF (retour 61) est désormais récupéré.

S'il est disponible, on peut le consulter au niveau de l'envoi en cliquant sur le statut de ce dernier. En survol, la bulle d'aide indique si l'accusé a été reçu et si le compte rendu est disponible.

Dans la fenêtre permettant de calculer ou recalculer tous les bulletins, si on demande le calcul pour tous les salariés de la sélection courante ou tous les salariés de la société, les salariés entrés après le mois de paie en cours (c'est à dire saisis par avance) et n'ayant pas encore de bulletin sur le mois de paie en cours sont ignorés.
Antérieurement à cette correction, on leur calculait un bulletin à tort.
Il reste toutefois possible (mais si cela n'a pas vraiment de sens) de calculer un bulletin pour un salarié qui serait dans cette situation : il faut faire en sorte qu'il soit affiché dans liste des salariés, en enlevant la sélection Salariés payables en haut de la fenêtre, puis en se positionnant sur le salarié en question et en cliquant sur le bouton Calculer.

Il est désormais possible de se connecter aux services MSA via les API-DSN en passant par le portail Net-Entreprise.

Pour cela, il faut choisir un utilisateur inscrit sur le portail Net-Entreprise et habilité à la MSA. Dans LDPaye, il faut donc créer de nouveaux identifiants de connexion avec cet utilisateur et indiquer 26 dans le code service DSN.

L'affichage du retour URSSAF (nature 61) a été aligné avec les retours de l'API-DSN.
Auparavant, on déterminait le statut du retour URSSAF en analysant le texte du retour. Désormais, on prend en compte l'indicateur STATUT qui est envoyé avec le retour.
Cela est visible lorsqu'on survole une déclaration pour laquelle on a reçu le retour URSSAF, la bulle d'aide indique Compte rendu URSSAF : Disponible, et si c'est le cas, la mention Statut KO est indiquée.

Lors du changement d'unité d'une rubrique, il n'y a plus d'effacement des reports sur cumuls présentant une incohérence entre l'unité de la rubrique et l'unité du cumul. Tous les reports de la rubrique sur les cumuls sont conservés en l'état.
On a simplement un message d'avertissement, suite à la validation de la fiche rubrique, qui dit :
Suite au changement d'unité de cette rubrique, il existe des incohérences entre l'unité de cette rubrique et celle de certains cumuls mis à jour par celle-ci.
Allez sur l'écran des reports Rubrique sur Cumuls et sélectionnez l'option ""Cumulé"" en haut à droite. Les reports incohérents apparaîtront sur cet écran avec la mention "Par défaut (Erreur)". 
Ce message d'avertissement comporte également la liste des cumuls concernés.
De plus, lors de la modification de l'unité de la rubrique, au lieu d'avoir une demande de confirmation systématique comme avant, la fenêtre de conformation n'est présentée que si le changement d'unité va provoquer au moins une incohérence dans les reports sur les cumuls.

Dans la fenêtre de création du fichier final d'une DSN apparait un libellé signifiant si la déclaration qui va être préparée est une déclaration en mode test ou en mode réel. Or, si depuis la fenêtre principale de gestion des déclarations, on appelait une déclaration en modification, on modifiait le type d'envoi (test en réel ou inversement), on appliquait cette modification puis on fermait la fenêtre de modification et enfin on appelait la fenêtre de création du fichier final, le libellé Envoi de test ou Envoi réel ne tenait pas compte de la modification.

Note : au passage, une autre petite correction a été faite : quand on appliquait une modification sur une DSN, le message Enregistrement de la déclaration en cours... restait affiché en bas d'écran une fois la déclaration enregistrée.

Dans la procédure de reprise de données à partir de données Excel (fenêtre OutiRepS), deux nouveaux points d'entrée permettent de modifier les valeurs d'une colonne.
Le premier s'exécute à la toute première lecture du contenu de la colonne, avant qu'une valeur par défaut soit mise en place. Pour l'utiliser, il faut créer un fichier de fonction nommé FonctionModifierAvantXXXXX.txt où XXXXX correspond au nom de la colonne.
Le second s'exécute après l'application des valeurs par défaut. Pour l'utiliser, il faut créer un fichier de fonction nommé FonctionModifierAprèsXXXXX.txt où XXXXX correspond au nom de la colonne.
Le code de la fonction doit prévoie l'utilisation d'un paramètre en entrée/sortie qui correspond à la valeur lue/retournée de la colonne concerné. Par exemple, pour récupérer seulement les 4 caractères de droite d'un matricule, le code de la fonction sera :
FONCTION ModifierAvantNPPE(pNPPE)
Renvoyer Droite(pNPPE, 4)

Auparavant, lorsqu'on rencontrait une erreur de certificat lors de l'envoi de données par l'API-DSN (qui se fait en HTTPS, donc avec échange automatique de certificats), on ignorait les erreurs. Cette méthode ne respectant pas les règles de sécurité, LDPaye bloque désormais à la première erreur de certificat. Pour retrouver le paramètre par défaut, il suffit de créer le paramètre programme APIDSN et d'indiquer la valeur O (pour Oui) dans la zone alphanumérique en première position.
De plus, certaines erreurs de certificats ne peuvent être contournées. Et cela pouvait provoquer le blocage de l'application qui essayait sans cesse d'ignorer les mêmes erreurs de certificats. Dorénavant, suite à une erreur de certificat, le système effectue une seule nouvelle tentative en ignorant l'erreur survenue la 1ère fois. Si la même erreur survient lors de cette seconde tentative, un message d'erreur est affiché à l'utilisateur. Il faut alors voir avec le prestataire informatique pour comprendre et corriger le problème de certificat.

Pour les deux procédures listées ci-dessous, il fallait disposer d'un niveau d'accès Administrateur "global" (celui indiqué dans la fiche de l'utilisateur). Désormais, un niveau d'accès Administrateur sur la société courante est suffisant.
Procédures concernées :
 - réactivation d'un arrêt de travail ayant été annulé
 - création du bordereau URSSAF en DSN à partir du bordereau de cotisations URSSAF.

En revanche, certaines procédures nécessitent toujours un niveau d'accès Administrateur "global" :
 - activation du module DSN (car celle-ci concerne toutes les sociétés au sein d'un même environnement)
 - choix des sociétés en simulation (car ce choix se situe en amont de la gestion des sociétés).

Les blocs activités n'ayant pas d'unité n'étaient pas affichés dans la partie gauche du contrat, mais en dessous (comme s'il s'agissait d'une unité différente au contrat). De plus, les totaux se cumulaient sans unité, et pouvaient donc cumuler des activités sans unité dont les contrats n'avaient pas la même unité.

La création des bordereaux de cotisations URSSAF a été facilitée. Et il est également possible de créer désormais un bordereau de régularisation couvrant l'année entière 2015.
Pour plus d'informations, reportez vous à la note à l'adresse :
http://www.evernote.com/l/AQ6YbYKo5MlLYr5k2ZAX0i4ocnqwCR1HASA/

Une fenêtre de sondage a été ajoutée dans LDPaye. Elle s'ouvre automatiquement à l'ouverture de LDPaye, juste à l'entrée dans la fenêtre principale, si l'utilisateur qui ouvre LDPaye dispose des droits Administrateur.
Si l'utilisateur ne souhaite pas répondre immédiatement, il peut différer sa réponse. Dans ce cas, la même fenêtre de sondage lui sera proposée le lendemain. On peut également aller répondre à ce sondage en ouvrant explicitement la fenêtre (menu Outils/Autres outils/Lancer un autre outil, puis Ouvrir une fenêtre Windev, avec le nom de fenêtre OutiSon1).
Dès lors qu'il a répondu, le sondage ne lui sera plus proposé. Si on "force" une nouvelle ouverture de cette fenêtre de sondage (comme indiqué ci-dessus) alors qu'une réponse a déjà été transmise, un message d'avertissement signale que les réponses ont déjà été transmises, mais on peut quand même poursuivre si on le souhaite. Une seconde réponse sera alors enregistrée et transmise par Internet.
Note : le sondage n'est proposé qu'une seule fois pour une configuration de LDPaye donnée, même si l'on gère plusieurs environnements de paye (en fait, on entend ici par "configuration" un répertoire de mise à jour centralisée, le fait que la réponse ait été faite s'enregistrant dans le fichier LDUpdate.INI de ce répertoire des mises à jour centralisées.

On avait, de façon très aléatoire, un blocage lors d'une restauration de dossier demandée juste après l'ouverture de LDPaye.
Après des recherches approfondies, il semble que le problème était du à un blocage lors de la lecture du fichier FICINI (lecture qui permet de déterminer la version du dossier en cours de restauration) alors que l'index de ce fichier n'existe encore pas. Si on s'en tient à la documentation de Windev, cet index est censé être créé automatiquement lors de cette lecture. Mais c'est cela qui bloquait tout, mais pas systématiquement. Probablement en raison d'une interaction entre le thread utilisé implicitement par Windev pour la réindexation et le thread de contrôle des licences (car si on désactive le contrôle de licences, le blocage n'intervient plus).
Pour éviter ce problème, on teste désormais l'existence du fichier d'index FICINI.NDX, et on force la réindexation s'il n'existe pas, avant de tenter la lecture de ce fichier FICINI. 

L'état de contrôle de la DADS-U a été amélioré pour ce qui est de façon dont les facteurs d'exposition à la pénibilité sont retranscrits.

Suite à cette correction, les CDD conclus pour un motif 03 - Emplois à caractère saisonnier ou 04 - Contrat vendanges ne supportent plus aucune majoration de cotisation chômage. Jusqu'alors, ceux-ci étaient considérés comme des CDD d'usage.
Or, au vu de différentes notes trouvées sur des sites d'information sur Internet, il s'avère que les contrats saisonniers sont exclus du dispositif de majoration des cotisations chômage sur les CDD (cf http://www.msa.fr/lfr/documents/11566/48459/Fiche+MSA+-+Modulation+des+contributions+d%E2%80%99assurance+ch%C3%B4mage.pdf).
Notez que les motifs 03 et 04 dont on parle ci-dessus ne peuvent être indiqués, dans la situation d'un salarié, que si le module DSN a été activé. Antérieurement, on ne disposait que de 3 motifs : 01 - Accroissement temporaire d'activité, 02 - CDD d'usage et 03 - Autres motifs de recours.

La société enregistrée au niveau des déclarations DSN fin de contrat (code société utilisé uniquement pour sélectionner les déclarations "de la société courante"), est celui du dernier arrêt de travail lu, et non celui du salarié parti (ou blanc si aucun arrêt de travail n'a encore été lu depuis l'ouverture de session). La société déclarée dans la DSN était, quand à elle, bien celle du salarié parti.

Lors de l'affichage d'un retour DSN, il est possible de l'imprimer ou d'imprimer tous les retours liés à l'envoi.
Les retours de nature 21 (Contrôle des signalements) sont désormais affichés dans la gestion des retours.
Dans la liste des DSN, la colonne Statut n'affichait pas forcément le bon statut de l'envoi.

Correction : L'application plantait lorsqu'on essayait d'imprimer une fiche de présence depuis la fenêtre de liste des fiches à saisir.
Correction : L'application plantait dans certain cas lorsqu'on survolait une imputation dans la fenêtre de saisie des heures.
Correction : Lors de l'édition du récapitulatif par salarié, si un jour férié est défini pour une société mais pas une autre, alors l'application plantait lors de l'impression de la fiche pour cette seconde société.

LDTemps
Correction : L'état récapitulatif par salarié plantait lors de l'envoi de l'impression vers une imprimante. Les causes de ces plantages étaient indéterminées mais récurrentes.
Amélioration : On peut désormais saisir des absences sur des journées non travaillées. Elles seront transférées en paye par l'interface. Cependant, ces absences ne peuvent pas générer d'heure supplémentaire et ne peuvent pas générer d'élément variable exprimé en heure.
Amélioration : Optimisation de la procédure permettant de lister les codes journées, cycles ou fiches types dans le menu de choix de la journée type.
Amélioration : De nouvelles impressions sont disponibles depuis la liste des fiches.
Correction : Lors du survol de certaines anomalies, l'application pouvait planter.

LDPointage
Nouveauté : LDPointage mémorise tous les pointages reçus et permet de les rejouer si une erreur a lieu. Les pointages sont stockés dans un répertoire Pointages à la racine de l'exécutable.

Amélioration : LDPointage peut désormais gérer plusieurs sociétés de manières distinctes. Voir la documentation de référence pour cela.

Correction : si la connexion à un dossier ne se faisait pas correctement, aucune indication n'était loggée.

Une nouvelle fenêtre Gestion des badges pour LDTemps permet désormais de gérer les badges de toutes les sociétés du même dossier de paye.

Cette fenêtre est accessible à partir du menu Fichier / Autres paramètres / Planning / Gestion des heures puis il faut utiliser le bouton Gestion des badges.

Dans la fenêtre d'affichage ou d'impression des retours de l'API-DSN, depuis la correction N° 183, on gère les retours de nature 21 qui correspondent :
 - soit au contrôle inter-déclarations dans le cas des déclarations mensuelles
 - soit au contrôle métier des arrêts de travail et reprises
 - soit au contrôle métier des fins de contrat de travail.
Cependant, dans les 2 derniers cas (AT/RT et FCT), le retour ne contient aucune information autre que le statut lui-même lorsque ce statut est OK.
Ce retour avec un statut OK était mal géré par LDPaye : on cherchait un contenu XML accompagnant le retour et faute de le trouver, on interprétait le retour comme ayant un statut KO.
Désormais, ces retours de statut OK sans contenu sont correctement interprétés.
Note : n'ayant pas de contenu propre, on ne sait pas rattacher ces retours à une déclaration particulière lorsque l'envoi comporte plusieurs déclarations. Ces retours sont donc affichés au même niveau que l'AEE, attaché à l'envoi et non pas à une déclaration. Cela étant, dans le cas des DSN arrêt de travail et fin de contrat envoyés au travers de l'API-DSN, il est vivement conseillé de faire un envoi par déclaration : cela facilite grandement la compréhension des retours de l'API-DSN.

La fonctionnalité de liaison entre un établissement et une banque a été étendue aux bordereaux DSN et aux arrêts de travail. Si cette fonctionnalité est activée, seule la banque liée à l'établissement sera présente dans la liste de sélection de la banque de paiement, dans les fenêtres de paramétrage des liens OPS/Etablissement/Bordereau, dans le bordereau DSN lui-même, ou dans la liste des banques pour la subrogation d'un arrêt de travail.
Cette fonctionnalité allant de pair avec celle qui permet de considérer chaque établissement comme une société à part entière dans les DADS-U et dans les DSN, si cette dernière est activée, il n'est pas possible de choisir, dans ces mêmes fenêtres, un autre établissement payeur que celui concerné par le bordereau DSN.

Les ventilations analytiques saisies au niveau bulletin (via la saisie des éléments variables) n'étaient pas prises en compte sur l'édition des journaux cumulés, dans le cas d'une rupture programmée sur l'un des axes analytique (section, affaire, destination).
Accessoirement, un petit souci de positionnement de la fenêtre de choix des rubriques à imprimer a également été réglé.

Au vu de ce qui est dit dans la documentation Guide Acoss : comment déclarer et régulariser les cotisations Urssaf en DSN Version 1.5, les dates de début et fin de la période rattachement ne sont désormais plus renseignées sur les blocs 78 et 79 lors de la création d'une DSN mensuelle.
Il est dit en effet dans cette documentation :

• d'une part page 48, « Il n’y a pas lieu de saisir de Date de début / fin de période de rattachement pour le bloc 79 Composant de base assujettie  puisque celui-ci est rattaché au bloc 78 Base assujettie au sein duquel sont déclarées les périodes de rattachement  ».
• d'autre part, pour l'ensemble des blocs 78 : « Les dates de début et de fin de période de rattachement ne sont à mentionner qu’en cas de régularisation ». Or, comme LDPaye Version 8 ne gère pas la régularisation des cotisations sur les mois antérieurs au niveau nominatif, ces dates ne sont pas à renseigner.

Cette correction permet de créer un bordereau de cotisation DSN "nul" pour le mois de paie suivant le mois de paie en cours. C'est le cas en fin d'année, quand le mois de paie est décembre, et que l'on veut créer par anticipation un bordereau de cotisation "nul" au titre de janvier.
Pour plus d'informations sur ce cas de figure, voir la note Evernote
Cas particulier du décalage de paie tout au long de l'année sauf en décembre

Ce correctif fait suite à la correction n°189. LDPaye ne pouvait gérer qu'un seul retour 21 (Compte-rendu Métier) par envoi, alors qu'il peut y en avoir plusieurs si l'envoi contient plusieurs déclarations.
Un retour 21 peut avoir un statut OK ou KO. Les retours 21 de statut OK étant vides (aucune donnée complémentaire), il est impossible de distinguer ces retours et de les associer à une déclaration précise au sein de l'envoi. Un seul retour 21 OK est donc créé. Dans la fenêtre d'affichage des retours, ce retour est affiché au niveau de l'envoi.
Par contre, les retours 21 de statut KO contiennent des données et ils peuvent donc être rattachés à la déclaration d'origine. Dans la fenêtre d'affichage des retours, chacun de ses retours 21 de statut KO apparait donc au niveau de la déclaration concernée par le retour.

Une nouvelle méthode de calcul de la régularisation au net est désormais possible, avec comme amélioration notable le fait que cette régularisation au net peut être entièrement automatisée : plus besoin de "forcer" un calcul "Avec net". 
Cette nouvelle méthode est décrite en détail dans la note accessible par le lien ci-dessous :
http://www.evernote.com/l/AQ5Os5Y2HZRGN4KEPzu5l7ynn4l6lSZE8ZU/

Des informations supplémentaires ont été ajoutées en partie haute de la fenêtre de gestion avancée des arrêts de travail :

• les dates d'entrée et d'ancienneté du salarié. Avec en sus, quand on survole la date d'ancienneté, l'affichage en bulle d'aide du nombre d'années d'ancienneté du salarié calculé au 1er jour de l'arrêt de travail. Ce nombre d'année d'ancienneté est calculé par la même fonction personnalisée que celle utilisée pour le calcul de l'indemnisation.
• le nombre de jours d'arrêts de travail au cours des 12 derniers mois et des 3 dernières années qui précédent le début de l'arrêt que l'on traite. Ces informations apparaissent en haut à gauche de l'écran en bleu (ou en rouge si le nombre de jours d'arrêt au cours des 3 dernières années est supérieur à 300, sachant que l'indemnisation par la Sécurité Sociale est limitée, dans le cas général, à 360 jours sur 3 ans. En cliquant sur celles-ci, on obtient la liste des arrêts de travail de ces 3 dernières années. Ces informations peuvent faciliter l'appréciation des limites, en terme d'indemnisation, liées au nombre de jours d'arrêts sur une période donnée. Rappelons toutefois qu'aucune limite de cette sorte n'est prise en compte dans le calcul des jours indemnisés par le système : il faut donc intervenir manuellement sur les nombres de jours si on souhaite limiter la période d'indemnisation en raison de trop nombreuses périodes d'arrêt antérieures.

Depuis le 18 Novembre, les comptes-rendus URSSAF (code 61) sont passés du format texte au format XML.

LDPaye gère désormais ces retours XML tout en assurant une compatibilité aux anciens retours qui restent au format texte.

LDTemps
Correction : Il est désormais possible de supprimer des éléments saisis sur une journée non travaillée.
Correction : Les jours fériés ne se déclenchent plus automatiquement lorsque le salarié n'est plus présent dans la société.

Une erreur survenait lors de la suppression d'un code pénibilité. L'erreur était du type (où "XXX" est le code à supprimer)  :
Erreur à la ligne 3 du traitement Clic sur SUPPRIM.
Vous avez appelé la fonction HLitRecherchePremier.
Il n'existe pas de rubrique <XXX> dans le fichier <PEPACT>.

Désormais, le bloc 51-Rémunération de code 001-Rémunération brute non plafonnée est calculé en tenant compte des périodes de rattachement : rappels d'heures ou de montant, primes avec période de rattachement.
On met en oeuvre le même principe que ce qui était déjà fait pour le bloc 51 de code 002-Salaire brut AC, à ceci près que dans le cas du bloc 002-Salaire but AC, on ne tenait pas compte des primes avec périodes de rattachement puisque ces primes étaient déjà exclues de ce bloc, alors que dans le bloc 51 de code 001, toutes les primes sont incluses. Et que dans le cas du bloc 51 de code 002, on doit aussi gérer le cas des blocs 53-Activité (blocs donnant le détail de l'activité en heures ou en jours) qui lui sont attachés, alors que le bloc 51 de code 001 n'a pas de blocs "fils".

Ce nouveau mécanisme est plus conforme à ce qui est décrit dans le cahier technique DSN et aux différentes informations que nous avons pu avoir sur ce sujet. Et surtout, cela évite des erreurs systématiques dès lors qu'on a un bulletin pour un salarié parti : le système DSN interdit en effet d'avoir un bloc 51 non nul sur la période courante portant le code 001 ou 002.
Le principe de la DSN est que les sommes versées sur un bulletin après un départ ne peuvent être que :

Un nouveau code calcul 24 est désormais disponible pour les rubriques. Il calcule un montant au prorata selon la règle suivante :
    Si Montant < 0 Alors
      Montant=0
    Sinon Si Taux > Montant Alors
      Montant=Nombre
    Sinon
      Montant = Nombre * Taux / Montant
    Fin

Par rapport au code calcul 21, dont le code est donné ci-après avec la différence en rouge, la différence ne porte que sur le cas où le taux est négatif. Avec le code calcul 21, on renvoie un montant nul alors qu'avec le code calcul 24 on renvoie un montant négatif.
Notez que si le montant de départ est négatif, on renvoie toujours zéro, que ce soit avec le code calcul 21 ou 24.
Ces codes calcul 21-24 sont principalement utilisés pour proratiser la valeur du SMIC en cas d'absence dans le mois, par le ratio (Rémunération brute perçue hors primes et indemnités ne variant pas en cas d'absence / Rémunération "normale" hors primes et indemnités ne variant pas en cas d'absence). Avec le code calcul 21, en cas de retenue pour absence importante débouchant sur une rémunération brute négative, on ne calculait pas de SMIC négatif, alors qu'avec le code calcul 24, ce SMIC peut passer en négatif, comme cela est accepté suite aux dernières précisions de l'ACOSS sur ce sujet.
    Si Taux < 0 ou Montant < 0 Alors
      Montant=0
    Sinon Si Taux > Montant Alors
      Montant=Nombre
    Sinon
      Montant = Nombre * Taux / Montant
    Fin
Pour bénéficier de cette possibilité de gérer le SMIC Fillon en négatif, il faut aller remplacer le code calcul 21 par le code calcul 24 sur les rubriques qui proratisent le SMIC (rubriques 5970 et 5971 dans le plan de paye standard).

Dans le cas d'un environnement multi-sociétés, dans la nouvelle fenêtre permettant d'affecter un code pénibilité à un ou plusieurs salariés, le code pénibilité pouvait être affecté à la situation d'un autre salarié que celui ayant été coché, salarié ayant le même code matricule mais dans une autre société.

Plusieurs corrections dans ce module de gestion des temps

• La duplication des imputations d'une journée à l'autre copie désormais aussi les imputations automatiques. Celles-ci sont converties en imputation saisie manuellement ou en imputation corrective suivant le cas.
• Dans l'état récapitulatif, une nouvelle option permet de se baser sur le type de fiche (horaire ou forfait) pour déterminer l'unité d'un cumul.
• Lorsqu'on se trompait sur une touche de fonction de la pointeuse pour un code non utilisé, une imputation analytique (la première de la liste) était ajoutée à la liste des imputations à tort.
• L'initialisation d'une journée depuis les horaires normaux faisait disparaître de l'affichage les données issues du planning.
• Lors du survol des données issues du planning, les heures affichées étaient fausses.
• Dans le paramétrage des motifs, on avait un masque de saisie numérique sur le n° de rubrique, empêchant donc la saisie d'un N° de rubrique alphanumérique.

Lors du calcul des blocs 51-Rémunération de type 001-Rémunération brute non plafonnée et 002-Salaire brut soumis à contribution d'Assurance chômage, les valeurs des rubriques de type Rappel d'activité sont déduites de la valeur déclarée dans le bloc 51 du mois courant et sont reportées sur des blocs 51 pour la période de rattachement spécifiée. De même, les valeurs déclarées dans les blocs 52-Primes et indemnités sont déduites des blocs 51 code 002-Salaire brut soumis à contribution d'Assurance chômage.
Désormais, pour ces deux cas de déduction, on tient compte du taux d'abattement du salarié. Ainsi, si le salarié a perçu une prime de 1000€ et qu'il bénéficie d'un abattement de 30%, on déduit seulement 700€ de la rémunération déclarée sur le bloc 51 code 002.
A la suite de ces déductions, si la valeur résiduelle du bloc 51 est comprise entre -5 et 1, la valeur est remise à 0. On considère en effet que cette valeur proche de zéro résulte d'un écart d'arrondi.
Plus d'informations dans la note d'actualités :
http://www.ldsysteme.fr/fileadmin/evernote/actu_dsn/Salaire_brut_Assurance_chomage_-_Parametrage_en_DSN.htm

Lorsqu'on exporte un journal standard ou détaillé dans Excel, on a la possibilité d'ajouter des données en regard de chaque salarié, données issues de la fiche salarié et surtout de la situation du salarié, en sus des données "chiffrées".
Jusqu'alors, les données ainsi ajoutées pour Excel étaient issues de la dernière situation du salarié correspondant à la période des données "chiffrées".
Problème : si pour une période donnée, un salarié avait eu plusieurs périodes d'activité, mais que le critère de tri retenu pour le journal demandé n'avait pas changé au travers de ces différentes périodes, les données étaient regroupées sans tenir compte de ces différentes situations. On n'avait donc pas toujours les bonnes valeurs pour les données ajoutées pour Excel, mais seulement les dernières valeurs connues issues de la dernière situation correspondant à chaque critère de tri.
Désormais, on détaille (uniquement en cas d'export pour Excel) les données en autant de lignes qu'il y a, pour chaque salarié, de valeurs différentes non seulement pour le critère de tri, mais aussi pour l'ensemble des données "supplémentaires" demandées pour l'export Excel.
Exemple : sur un journal trié par service pour lequel on demandé l'export dans Excel de la classification, si on exporte ce journal sur l'ensemble de l'année, pour un salarié n'ayant pas changé de service au cours de l'année, mais ayant eu 2 classifications différentes, on aura 2 lignes dans la feuille Excel, une pour chaque classification avec en regard de chacune de ces classification les données "chiffrées" des bulletins associés à chaque classification.

Au passage, le champ Code pénibilité a été ajouté dans la liste des champs pouvant être ajoutés en cas d'export Excel, tant pour un journal standard que pour un journal détaillé.

Grâce à ces deux modifications, on peut désormais exporter dans Excel, sur une période donnée qui peut par exemple être l'année civile, une base de cotisation Sécurité Sociale par exemple, avec sur chaque ligne correspondant à un salarié, le code pénibilité correspondant à la situation (donc au contrat) à laquelle les bulletins sont rattachés. Cela permet de reconstituer plus facilement, à posteriori, les assiettes des cotisations pénibilité mono-exposition et multi-expositions.

Lors d'une reprise de données salariés depuis un fichier Excel, la fenêtre se fermait sans information lorsqu'une constante salarié inexistante était intégrée. Désormais, l'erreur est affichée dans le fichier d'avertissement.
De plus, si un salarié est inexistant lors de la reprise, le message d'erreur affiché pouvait concerner un autre salarié.

2 colonnes ont été ajoutées dans les fenêtres présentant la liste des périodes d'inactivité pour un salarié ou un motif d'inactivité : la durée en heures et la durée en jours.

Depuis une reprise N4DS, la numérotation automatique par société ou toutes sociétés confondues ne fonctionnait pas. Le même matricule était calculé pour tous les salariés, soit 0000.
De plus, les erreurs de matricules (non renseigné ou doublon) sont désormais correctement signalées. S'il y avait plusieurs erreurs pour un même matricule calculé (tous dans le cas de la renumérotation automatique), une seule erreur était affichée.

La création des blocs pénibilité (S65.G40.00) n'était pas déclenchée pour les salariés ayant eu des contrats avant la date de début de la déclaration, mais n'étant pas présents à cette date.
Par ailleurs, ces groupes sont désormais créés dans l'ordre chronoligique des périodes d'expositions.

Différentes modifications sont en cours dans LDTemps :

• En saisie des temps, lorsqu'on utilisait les flèches de parcours pour passer d'un salarié à l'autre, les commentaires n'étaient pas sauvegardés si c'était la seule donnée modifiée dans la fenêtre.
• En saisie des temps, l'initialisation du cycle ou jusqu'à la fin depuis les horaires normaux, LDPlanning ou le pointage n'alimentait pas la dernière ligne de la table.
• Toujours en saisie des temps, le total des heures du cycle était mal affiché avec une police Windows de taille moyenne (125%)
• Dans l'état récapitulatif par salarié, si une journée contenait deux motifs d'absence différents, seul le premier était affiché. Désormais, les deux sont affichés l'un en dessous de l'autre.

Toutes ces modifications seront intégrées dans le prochain package correctif de LDTemps qui sera référencé 3.80.021.

La note Mesures d’activités et d’absences dans la DSN indique que le type d’activité 03 - Durée non travaillée rémunérée n’est pas géré en Phase 2 et fera l’objet de consignes en Phase 3. Il n’est donc pas à renseigner (§ 1.2).
Ce code a donc été marqué Supprimé dans la table des codes DSN (même s'il ne l'est pas réellement dans le cahier technique DSN). Les paramétrages existants sur ce code ne sont pour autant pas supprimés (au cas où il viendrait ultérieurement des consignes de remplissage différentes), mais seront traités comme un paramétrage sur le code 01 - Travail rémunéré.

Lorsqu'on exporte un journal standard ou détaillé dans Excel, on a la possibilité d'ajouter des données en regard de chaque salarié, données issues de la fiche salarié et surtout de la situation du salarié, en sus des données "chiffrées".
Suite à la correction N° 231, dans le cas d'un journal standard demandé sur une période comportant plusieurs mois et avec l'option Impression d'une ligne par mois, ces données supplémentaires n'étaient pas présentes sur les lignes de totalisation, mais seulement sur les lignes correspondant aux différents mois de la période. La correction 231 avait en effet pour objet d'exporter les valeurs "réelles" de ces données demandées dans l'export Excel, mois par mois, et non pas seulement les dernières valeurs connues issues de la dernière situation correspondant à chaque critère de tri comme auparavant. Les valeurs des données exportées pour un salarié donné pouvant être différentes au cours de la période demandée, il paraissait naturel de ne pas les porter au niveau des lignes de totalisation de la période de chaque salarié.

Avec cette nouvelle correction, on retrouve les données exportées sur les lignes de totalisation si l'état a été demandé, à l'invite Tenir compte, pour le tri et la sélection, de,  d'une des options la dernière situation connue ou la situation à la date d'arrêt de l'état. En effet, avec ces deux options, les données exportées sont forcément les mêmes sur toute la période demandée puisqu'on prend les dernières valeurs connues au moment de la constitution du journal ou connues à la date d'arrêté de l'état. Ce n'est donc qu'avec l'option la situation associée à chaque bulletin de paye qu'il n'y a plus de valeur exportée sur les lignes de totalisation.

Remarque : même dans ce dernier cas, celui avec l'option la situation associée à chaque bulletin de paye, on peut forcer la présence des données sur les lignes de totalisation en positionnant par un MCU la variable fForcerRubriquesExportSurTotaux à la valeur Vrai.
 

SI un contrôle de licence était en cours, une temporisation était affichée pour permettre à l'application de terminer correctement ce contrôle.

Désormais, cette temporisation a été retirée (mais le contrôle demeure) afin de ne pas perturber l'utilisation du logiciel.

Ce correctif fait suite à la correction LDPaye N° 245 et intègre les modifications qui n'avaient pas pu être intégrées.

• Le paramétrage des journées types a été revu afin d'améliorer la gestion des pointages. Jusqu'à présent, les plages de saisies et les plages de pointages étaient liées. Désormais, les deux sont dissociées. Deux nouveaux onglets ont été créés afin de faciliter la saisie et la visualisation de ces plages.
  Une migration invisible a été mise en place pour faciliter la mise en place de ce nouveau paramétrage. A la première ouverture de LDTemps dans la nouvelle version, les plages de pointages sont initialisées à partir des plages de saisie. La transition est donc transparente et l'utilisateur n'a rien à faire.
• Il est désormais possible d'ignorer les pointages d'un salarié si ce dernier pointe plusieurs fois d'affilées au cours d'un laps de temps défini. On évite ainsi de se retrouver avec plusieurs pointages qu'il faudrait ignorer manuellement.
  Pour mettre en place ce paramétrage, il suffit de définir une nouvelle section Pointage dans les paramètres généraux et de renseigner le mot clé DelaiAvantRepetition avec le délai en secondes dans lequel un pointage sera considéré comme une répétition et devra être ignoré.
  Exemple :
   [Pointage]
   DelaiAvantRepetition=5
• On peut désormais dupliquer une journée type via un nouveau bouton Dupliquer.
• En modification de cycle type, on ne bascule plus sur l'onglet Description. On reste sur l'onglet courant.
• Correction d'un plantage dans la fenêtre de saisie des temps à cause d'un indice qui faisait référence à une ligne inexistante de la table.
• Correction d'un bug sur les imputations automatiques. Le fait de réinitialiser une imputation automatique qui a été mise à zéro lui donnait le double de sa valeur initiale.
• Correction d'un libellé mentionnant le planning alors qu'on traite des pointages.

Rappel des modifications de la fiche 245

• En saisie des temps, lorsqu'on utilisait les flèches de parcours pour passer d'un salarié à l'autre, les commentaires n'étaient pas sauvegardés si c'était la seule donnée modifiée dans la fenêtre.
• En saisie des temps, lors de l'initialisation du cycle jusqu'à la fin depuis les horaires normaux, LDPlanning ou le pointage n'alimentait pas la dernière ligne de la table.
• Toujours en saisie des temps, le total des heures du cycle était mal affiché avec une police Windows de taille moyenne (125%).
• Dans l'état récapitulatif par salarié, si une journée contenait deux motifs d'absence différents, seul le premier était affiché. Désormais, les deux sont affichés l'un en dessous de l'autre.

Jusqu'alors, un arrêt de travail généré en DSN événementielle "arrêt" était repris dans la première DSN mensuelle qui suivait, ainsi que dans toutes les DSN mensuelles suivantes ayant au moins un jour d'arrêt dans le mois déclaré (période allant du dernier jour travaillé au jour de reprise réel).
Désormais, ces arrêts de travail seront également renvoyés dans la première DSN mensuelle qui suit dès lors qu'une des valeurs à transmettre en DSN mensuelle a été modifiée entre cette nouvelle DSN et la DSN mensuelle précédente.
Cela permet de gérer le cas où une date de reprise a été saisie avec un peu de retard : par exemple, reprise au 30/01 saisie le 06/02, c'est à dire après la transmission de la DSN de janvier effectuée le 05/02. Du coup, cette date de reprise n'était pas transmise avec la DSN de janvier (car pas saisie suffisamment tôt) et pas transmise avec la DSN de février (car l'arrêt de travail n'avait aucun jour en comme avec le mois de février). Désormais, cet arrêt sera transmis en février car le système va détecter que la date de reprise a changé entre la DSN transmise au titre de janvier et les données connues au moment de l'établissement de la DSN de février.

La cotisation Complément Allocations Familiales, mise en place début 2015, a un mode de calcul particulier : elle ne se déclenche que si le salaire brut abattu est supérieur à un seuil fixé à 1,6 SMIC.
A partir du 2ème trimestre 2016 (avril 2016 dans le cas général, mars 2016 pour les entreprises en décalage de paye), ce seuil est porté à 3,5 SMIC. Mais comme se seuil doit être apprécié en cumul annuel et que la valeur du seuil change en cours d'année, cela amène à faire des calculs un peu particuliers.
Ce nouveau mode de calcul est décrit plus en détail sur une note d'actualité dédiée à ce sujet.
Cette correction permet de prendre en charge ce nouveau mode de calcul de façon entièrement automatisée ; il n'y a aucune action requise de l'utilisateur dans le plan de paye. Le seuil de 1,6 SMIC qui passe à 3,5 SMIC n'apparait nulle part dans le plan de paye ; il est directement intégré dans le programme de calcul des bulletins.

Dans un environnement HFCS avec les dossiers de simulation activés (Mode SMU), l'affichage de la fenêtre de choix des sociétés pouvait mettre du temps à s'afficher. Ce temps d'affichage était proportionnel au nombre de sociétés dans l'environnement (presque une seconde de chargement supplémentaire par dossier).

Désormais, l'ouverture a été optimisée pour ne plus charger les dossiers de simulation à l'ouverture de la fenêtre, mais uniquement lorsqu'on bascule en mode simulation. Le chargement de la liste de ces dossiers de simulation a également été amélioré pour réduire drastiquement le temps de traitement d'un dossier.

Complément technique :
C'est l'utilisation de la fonction HListeBaseDeDonnées qui prend du temps. Auparavant, on utilisait cette fonction pour chaque dossier. Désormais, on l'utilise une fois pour tous les dossiers. En effet, cette fonction renvoie les informations de tous les dossiers.

Ce correctif corrige plusieurs points dans LDTemps :

• lorsqu'on initialisait une journée continue à partir du pointage, certains pointages n'étaient pas pris en compte ;
• lorsqu'on corrigeait une imputation automatique, dans certains cas, cette correction pouvait ne pas être visible dans la fiche de saisie ou lors de l'impression ;
• dans la fiche de saisie, les imputations liées à des chantiers n'étaient plus visibles.

En saisie d'une fiche Rubrique ou Cotisation, si on modifie le libellé de la rubrique ou cotisation, le nouveau libellé est reporté immédiatement sur les éléments variables déjà saisis sur le mois courant ou les mois ultérieurs.
Ce report pouvait être à l'origine d'un délai assez long lors de la validation de la fiche rubrique ou cotisation, lorsque le fichier des éléments variables était volumineux (par exemple, plus de 2 minutes pour un fichier de 6 millions d'éléments variables).
Ce report est désormais effectué via une commande SQL plutôt qu'un parcours séquentiel du fichier sur la clé N° de rubrique ou Cotisation. Et ainsi, le délai est bien plus court : moins de 1 seconde la plupart du temps.

Au passage, une autre optimisation a été faite à l'ouverture de la fenêtre présentant la liste des cotisations. Cette fenêtre s'ouvre désormais instantanément alors que cela pouvait prendre quelques secondes auparavant.

La cotisation Complément Allocations Familiales, mise en place début 2015, a un mode de calcul particulier : elle ne se déclenche que si le salaire brut abattu est supérieur à un seuil fixé à 1,6 SMIC.
A partir du 2ème trimestre 2016 (avril 2016 dans le cas général, mars 2016 pour les entreprises en décalage de paye), ce seuil est porté à 3,5 SMIC. Mais comme se seuil doit être apprécié en cumul annuel et que la valeur du seuil change en cours d'année, cela amène à faire des calculs un peu particuliers.
Cette correction permet de réaliser le calcul tel que décrit dans la circulaire DSS du 18/03/2016, mode de calcul qui est décrit plus en détail sur une note d'actualité dédiée à ce sujet.

Il est désormais possible de personnaliser le répertoire de destination des bulletins de paye lorsqu'on les envoie dans la GED. Il faut pour cela créer un paramètre programme GEDBUL et indiquer dans sa valeur alphanumérique le répertoire de destination. Ce répertoire peut être personnalisé avec les données d'un fichier sous la forme {NOMFICHIER.NOMRUBRIQUE}.
Exemple :
On souhaite avoir un répertoire contenant les bulletins par code salarié et par code société, la valeur à mettre dans GEDBUL est :
    C:\Ldsystem\Fichiers\Paye\Bulletins\{PEPERS.COSO}\{PEPERS.NPPE}.
Par défaut, le bulletin sera copié de ce répertoire vers le répertoire de la GED, mais en paramétrant les chemins d'acquisition (Menu Fichier / Autres paramètres / Chemins d'acquisition (GED) ), on peut modifier ce comportement.

Quand on réalise des sauvegardes de paye, le système choisit automatiquement le nom des fichiers de sauvegarde (.SAV et .WDZ), noms qui sont de la forme REPxxx99, où xxx est le code du répertoire sauvegardé, et 99 est un N° à suivre (le système prend le premier N° disponible à partir de 01 dans le répertoire cible de la sauvegarde).
Lorsqu'on dépasse les 99 sauvegardes pour un même répertoire (c'est à dire que tous les N° compris entre 01 et 99 sont déjà utilisés), LDPaye continue de la même façon avec un nom de la forme REPxxx999, donc avec un numéro à 3 chiffres : 100, 101, 102...
Problème rencontré lors de la restauration : lorsqu'on dépassait les 99 fichiers de sauvegarde pour un répertoire, le nom attribué aux fichiers de sauvegarde étaient donc composés de 9 caractères. De ce fait, en raison d'un problème Windows dans les recherches de fichiers avec nom générique (LDPaye recherchait tous les fichiers ayant un nom de la forme REP suivi de 5 ou 6 caractères avec l'extension .SAV), selon le nom "court" (celui à 8 caractères) attribué par Windows aux fichiers de sauvegardes ayant un nom long à plus de 8 caractères, le fichier était présenté ou pas par Windows.
Au final, en raison de ce bug Windows, LDPaye ne montrait donc qu'une partie des sauvegardes disponibles dans le répertoire choisi, celles dont les noms "courts" de fichier commençaient bien par REP (pour un fichier dont le nom long est de la forme REPxxx999, le nom court est parfois de la forme REPxxx~9, soit de la forme REhhhh~1, hhhh étant un code hexadécimal attribué par Windows selon une règle qui lui est propre).
Pour contourner ce problème Windows, LDPaye effectue désormais une recherche plus générique, de la forme REP*.SAV plutôt que REP?????.SAV. On récupère bien ainsi tous les fichiers de sauvegarde présents dans le répertoire. Puis LDPaye retraite cette liste pour ne conserver que ceux souhaités, c'est à dire ceux de la forme REPxxx99.SAV ou REPxxx999.SAV, xxx est une suite de 3 caractères quelconque et 99 ou 999 un nombre composé de 2 ou 3 chiffres.

Au passage, petite amélioration, la liste de sauvegardes présentée à l'utilisateur est triée par code répertoire et date de dernière modification du fichier .SAV, et non plus par code répertorie et numéro de fichier de sauvegarde, sachant que ce numéro n'est pas toujours significatif de l'ordre dans lequel les sauvegardes ont été effectuées, puisque LDPaye utilise au moment de la sauvegarde le premier numéro disponible dans le répertorie cible, en "bouchant les trous" éventuels.

Corrections :

• Correction au niveau de la saisie des chantiers. Les chantiers et les imputations associées n'étaient pas effacés quand on modifiait les motifs pour indiquer qu'il n'y a pas de chantier dans la journée
• Lorsqu'on supprime un chantier et que la liste des chantiers est vide, cela provoquait un plantage de l'application. Idem pour la suppression d'une imputation issue d'un chantier.
• Les tolérances de pointage sur les entrées et sorties étaient parfois mal interprétées et des anomalies étaient générées à tort.
• Dans l'état récapitulatif par salarié, les absences saisies sur une journée continue renvoyaient la même durée que des absences sur une demi-journée.
• Quelques corrections ergonomiques ont été apportées à différents endroits du logiciel.

Nouveauté :

• Il est désormais possible d'activer ou de désactiver explicitement les pointages. Il faut pour cela définir le paramètre général POINTAGE_ACTIF dans la section GENERAL avec les valeurs O (Oui, pointage actif) ou N (Non, pointage désactivé).

Corrections :

• Les pointages dont l'heure est strictement identique (à la seconde près) à l'heure de début de la plage autorisée de pointage provoquaient une anomalie. Ils étaient considérés comme en dehors de la plage de pointage.
• Dans l'édition des fiches de présence, les cumuls issus d'une absence prenaient la durée de référence à la place de la durée théorique (si la durée théorique était nécessaire).

Gestion des mises à jour :

• LDTemps récupère ses mises à jour depuis celle de LDPaye. Afin de distinguer la version 8.00 de la version 9.00, LDTemps récupère les mises à jour en fonction de la version de l'exécutable de LDPaye présent dans son répertoire.

En saisie d'une fiche salarié, un nouveau contrôle a été ajouté au niveau du numéro de sécurité sociale afin de signaler à l'utilisateur qu'un NTT (numéro technique temporaire) sera utilisé en DSN en lieu et place du N° saisi.
En parallèle, en création DSN, pour que le N° de sécurité sociale soit transmis en tant que N° d'inscription au répertoire (rubrique 30.001), il faut que toutes les règles ci-dessous soient vérifiées :
 - le N° commence par 1 ou par 2
 - le N° (en dehors de la clé) comporte exactement 13 chiffres
 - les 12 chiffres de droite (de dehors de la clé) ne sont pas tous renseignés à "9" (neuf)
 - les 6 chiffres de droite (en dehors de la clé) ne sont pas tous renseignés à "0" (zéro).
Si une au moins de ces règles n'est pas vérifiée, le N° d'inscription au répertoire n'est pas renseigné sur le bloc 30 et on renseigne un NTT en rubrique 30.020, NTT constitué du chiffre 1 ou 2 (sexe), des 9 chiffres du SIREN entreprise et des 4 caractères du matricule.

Dans la fenêtre de saisie des conditions d'une rubrique, d'une cotisation ou d'une ligne de bordereau, il n'était pas possible de saisir un nombre décimal avec des chiffres à droite de la virgule. Désormais, il est possible de saisir les décimales, mais pour des raisons techniques, le nombre de caractères du nombre, virgule comprise, ne peut pas dépasser 6 caractères. 

Dans la fenêtre principale de gestion des DSN, des optimisations ont été faites pour accélérer les temps de chargement de celle-ci, principalement dans le cas où l'on a des envois DSN comportant chacun de très nombreuses déclarations (plusieurs dizaines d'établissements au sein de chaque envoi).
La première optimisation a consisté à ne pas charger par défaut la table affichant l'ensemble des déclarations, table qui n'est visible qu'en cliquant sur le lien en haut à gauche de la fenêtre. Désormais, cette table n'est chargée que lorsqu'on clique sur le lien permettant de l'afficher. Et comme on clique rarement sur ce lien, l'affichage initial étant la plupart du temps préféré, on évite un  temps de chargement assez conséquent.
La seconde optimisation a été de mettre en cache les retours DSN pour éviter de les lire et analyser plusieurs fois. En effet, les retours correspondant à un envoi étaient lus et analysés autant de fois qu'il y avait de déclarations au sein de l'envoi. Et comme ces comptes-rendus sont reçus en format XML, leur lecture et analyse est assez gourmande en temps : quelques millisecondes par déclaration, mais multiplié par plusieurs centaines de déclarations au sein d'un envoi, cela finit par faire des secondes, voir des dizaines de secondes si on a aussi de nombreux envois).

Lors de la constitution d'une DSN mensuelle, pour ce qui est des cotisations agrégées pour l'URSSAF, quand on avait plusieurs taux AT, les lignes n'étaient pas inscrites dans le bon ordre. Par exemple, avec deux AT, on avait les blocs correspondant aux assiettes déplafonnées (code assiette 920) de ces deux taux, puis les blocs correspondant aux assiettes plafonnées (code assiette 921). Alors que ce qui est attendu, ce sont les blocs classés par taux et assiette : assiette déplafonnée du premier taux, assiette plafonnée du premier taux, puis assiette déplafonnée du deuxième taux, assiette plafonnée du deuxième taux.
Ce point a donc été corrigé. Cela a entrainé la modification de la zone clef des blocs 23 portant un taux AT, clef que l'on voit dans l'arborescence d'une DSN. Auparavant, la clé de ces blocs 23 était constituée du code cotisation agrégée et du code assiette (par exemple 100 920 et 100 921). Désormais, elle intègre aussi le taux AT ; et comme la clé est limitée à 10 caractères, le code assiette 920 ou 921 est abrégé sous la forme D=Déplafonnée ou P=Plafonnée, ce qui donne par exemple : 100 1,60%D et 100 1,60%P.
Au passage, une modification a aussi été faite pour que le taux AT, bien que présent sur le bordereau URSSAF, ne soit pas inscrit sur les blocs 23 de code 921, comme cela est précisé dans le Guide Acoss : comment déclarer et régulariser les cotisations Urssaf en DSN (Version 1.5, pages 7 à 9). Le taux AT n'est présent que sur les blocs 23 de code 920. Mais il faut bien une ligne 921 suivant chaque ligne 920, avec l'assiette plafonnée correspondant à l'assiette déplafonnée déclarée sur la ligne précédente de code 920.

LDPaye propose désormais une procédure permettant d'établir des formulaires PDU1 (attestation fournie au salarié pour une demande d'indemnisation chômage dans un autre pays européen), et ce au format PDF.
Pour cela, il suffit d'utiliser la fenêtre PDU1LST (Menu Outils/Autres outils/Ouvrir une fenêtre Windev).

Plusieurs corrections ont été apportées sur l'outil de remplissage du PDU1 :
- Dans certains cas, le sexe de la personne pouvait être faux.
- Si la page 2 ne contenait pas de période d'activité ou d'inactivité à déclarer, le motif de fin de contrat était faux.
- Il est désormais possible de modifier le revenu déclaré avec les mots clés TOTAL, TOTAL_MOYENNE et MOYENNE (voir la documentation pour plus de détail).
- L'interface a été retouchée pour corriger des problèmes mineurs.