La fenêtre d'impression de la liste des événements offre désormais un bouton pour exporter la liste au format Excel (comme les journaux).

• on peut traiter en une seule opération tous les cumuls d'une période donnée, et non pas seulement un mois et un N° de bulletin précis comme auparavant. Le système recalcule les cumuls de chaque bulletin existant sur la période demandée.
• la période à sommer (au bas de l'écran) n'est pas "figée" comme auparavant. On peut choisir entre 3 options :
  • Celle du bulletin sur lequel le cumul est créé ou modifié   (cas d'un cumul mensuel).
  • Du début de l'exercice (ou du contrat) au bulletin traité (cas d'un cumul annuel). Le système tient compte dans ce cas de l'indicateur Reprise des cumuls antérieurs sur chaque en-tête bulletin pour cumuler selon le cas soit depuis le début de l'exercice, soit depuis le bulletin antérieur le plus ancien calculé dans l'exercice avec reprise des cumuls antérieurs 
  • Une période indiquée explicitement (pour retomber sur ce qui se faisait auparavant, même si cette option est moins utile).
• on a plus de choix pour le calcul à opérer sur les valeurs après calcul et après clôture. En sus des options Ne pas modifier, Ajout et Remplacement que l'on avait déjà, on dispose des options Nulle (pour forcer une valeur à zéro) et surtout Recalculée en fonction des reports de rubriques et cotisations, option bien pratique car elle permet de reconstituer un cumul après coup en tenant compte du paramétrage actuel de ce cumul. Pour la valeur après clôture, on dispose en sus de l'option Egale à la valeur après calcul.
• Si on choisit une des options Ajout ou Remplacement, au lieu de sommer un seul élément de paye (rubrique ou cotisation) comme auparavant, on peut en indiquer plusieurs sous forme de liste. La liste est de la forme RRR1:X;RRR2:X;RRR3:X ou RRRn est un N° de rubrique ou cotisation et X est égal à  N, M, P, C selon que l'on veut sommer le nombre, le montant, le montant patronal, le montant salarial et patronal. Le N° de rubrique ou cotisation peut être précédé du signe - pour inverser le sens de l'élément à sommer. 

Sur l'écran de saisie des paramètres DSN relatifs aux contrats de prévoyance, 2 choses ont été corrigées :

• dans la liste déroulante de choix des contrats, certains contrats n'apparaissaient pas. C'était le cas lorsque deux contrats avaient un identifiant commençant par la même séquence, par exemple GAN-M et GAN-M2. Selon l'ordre dans lequel ces contrats avaient été créés, le contrat GAN-M pouvait être "masqué" par le contrat GAN-M2.
• en partie haute de l'écran de saisie, le libellé apparaissant dans la première colonne de la table, libellé présentant le code et le libellé du contrat de prévoyance auquel chaque paramètre DS est rattaché, s'affichait mal : on voyait le code, mais le début du libellé était tronqué.

Plusieurs petites corrections ont été apportées dans les recherches de codes à partir des nomenclatures disponibles sur le site DSN-INFO :

• on voyait parfois, dans la fenêtre de sélection d'un code de nomenclature, une ligne avec code à blanc et libellé contenant un caractère bizarre (EOT). Cela provenait du fait que certaines tables de nomenclatures fournies par DSN-INFO comportent une ligne vide en fin de table. Ces lignes vides sont désormais masquées.
• dans certaines tables, certains codes étaient doublés voire triplés. Cela était le cas notamment quand on recherchait un code délégataire de gestion pour un contrat de prévoyance. Cela était dû au fait que pour ces codes délégataires de gestion, on "cumule" 4 nomenclatures différentes, selon que le délégataire est un organisme de prévoyance, une société d'assurance, une mutuelle ou un organisme "isolé". Et certains organismes apparaissent dans plus d'une de ces nomenclatures. Désormais, lors du chargement de la liste affichée à l'écran, on masque les doublons.
• les organismes de type "OC isolé" (tables de nomenclature nommées OCI et DLGOCI sur DSN-INFO) n'apparaissaient pas dans la fenêtre de sélection d'un code OC ou d'un code délégataire de gestion. Cela était dû au fait que l'on n'avait pas le bon code de table de nomenclature (OC au lieu de OCI et DLGOC au lieu de DLGOCI).
• enfin, dans la fenêtre de sélection d'un code à partir d'une nomenclature, la loupe proposée dans la colonne Libellé est de type Contient et non pas Commence par.

Lorsqu'on utilisait les boutons de parcours proposés en bas à droite de la fenêtre de saisie d'un contrat de prévoyance, le parcours se faisait dans un ordre quelque peu aléatoire, qui bien souvent n'était pas l'ordre dans lequel les contrats étaient présentés dans la fenêtre principale des contrats (par identifiant interne croissant et date de début contrat décroissante).
Au passage, quelques modifications ergonomiques ont été réalisées dans la fenêtre de saisie des contrats : ordre de tabulation des champs, agrandissement du champ Identifiant interne, déplacement du champ Type de contrat sur la gauche pour qu'il soit plus visible.

La documentation des nouveautés Version 9 a été entièrement regénérée avec une licence HelpNDoc en bonne et due forme pour ne plus avoir de bannière publicitaire en pied de page. Cette documentation est désormais en version 1.02.
Les mises à jour de cette documentation seront désormais diffusées au travers du fichier ZIP NouvV9.zip placé dans le répertoire des documentations, sachant que le contenu de ce fichier ZIP est automatiquement décompressé lors de la demande d'ouverture de cette documentation depuis LDPaye dans le sous-dossier NouvV9 du répertoire des documentations.

L'écran de saisie permettant d'affilier des salariés à un contrat de prévoyance a été revu pour pouvoir être effectué entièrement au clavier. La table garde le focus lorsqu'on affilie un salarié au lieu de renvoyer sur la saisie de la date d'affiliation.
L'ordre des tabulations a été modifié. La date d'affiliation vient directement après la table, suivi des autres champs de la saisie. Les champs permettant de filtrer la table arrivent en dernier.

Dans la saisie des contrats de prévoyance, 2 corrections ont été apportées :

• le contrôle opéré au sortir de la fenêtre sur l'alignement des paramètres DSN 81-059 et 79-04 + 79-05 fonctionnait mal. On ne tenait compte que des paramètres 81-059 associés aux contrats de prévoyance de la société courante, et comme les paramètres 79-04 et 79-05 ne sont pas associés à un contrat de prévoyance, on les lit tous même ceux qui sont rattachés à des cotisations ne concernant pas la société courante. On signalait donc des discordances qui n'étaient pas des erreurs de paramétrage. Désormais, ce contrôle est fait en tenant compte de tous les contrats de prévoyance, même ceux ne concernant pas la société courante. Le message d'erreur signalé en cas de discordance a également été repris pour qu'il soit plus explicite.
• les taux de cotisations présentés sur l'onglet Cotisations étaient à 2 décimales, alors que bien souvent ces taux ont plus de 2 décimales. On les a passés à 4 décimales comme dans le fichier des cotisations. On a aussi ajouté le taux global (salarial+patronal) car c'est celui là dont a besoin bien souvent pour contrôler par rapport à ce que l'on trouve sur les fiches de paramétrage.

Lors de la duplication d'un salarié, une nouvelle option Reporter l'ancien SIRET d'affectation et l'ancien n° de contrat a été ajoutée. Cette option est effective si l'on copie un salarié vers une autre société en conservant ses données personnelles (le salarié change de société).

Il y avait un problème lors de la création de la DSN qui faisait que tous les arrêts de travail émis antérieurement en DSN événementielle étaient transmis dans la DSN mensuelle, même s'ils l'avaient déjà été dans une DSN mensuelle précédente. L'erreur était due à une mauvaise lecture des DSN antérieures, suite à la disparition du fichier DNRUBR (les données de DNRUBR ont été remontées dans DNBLOC en version 9). Le système pensait que les dates de l'arrêt avaient été modifiées depuis la transmission précédente et renvoyait donc l'arrêt une nouvelle fois.

Dans les DSN Phase 3, on peut transmettre la liste des ayants-droit d'un contrat de prévoyance, sous forme de blocs 73 (comme on le fait en DADS-U dans les groupes S45.G10.00). Ce bloc 73 comporte deux rubriques pour le N° SS de l'ayant-droit et/ou celui de la personne à laquelle l'ayant-droit est rattaché. Ces deux N° SS sont saisis avec la clé du N° SS, soit 15 chiffres au total. Mais dans la DSN, il ne faut pas transmettre cette clé, seulement les 13 chiffres du N° SS sans la clé.
Le problème a aussi été corrigé pour la création des DADS-U, groupe S45.G10.00 : l'erreur était bien présente depuis l'origine, mais n'avait jamais été signalée (on peut supposer que personne n'a jamais déclaré les N° SS des éventuels ayants-droit des salariés).

Au sein de chaque DSN Phase 3, on créait un bloc 15 pour chaque contrat de prévoyance défini dans LDPaye, c'est à dire chaque identifiant interne de contrat. Or, il faut en fait créer un bloc 15 pour chaque triplet (Code IP, code délégataire de gestion, Référence de contrat).
Le problème se posait pour les contrats présentant plusieurs codes option et/ou population : selon les institutions de prévoyance, on peut avoir la même référence de contrat ou pas. Dans le cas où la référence de contrat est la même, on aura donc désormais un seul bloc 15 définissant le code IP, le code délégataire de gestion, la référence de contrat. Et tous les blocs 71 (au niveau salarié) sont rattachés à ce bloc 15, ces blocs 71 portant les codes option et population.
Avant cette correction, on créait dans ce cas autant de blocs 15 qu'il y avait de codes option ou population, ayant chacun leur propre identifiant technique d'adhésion, auquel étaient rattachés les blocs 71. Mais ces blocs 15 étaient rejetés par l'outil de contrôle DSN-VAL car on ne peut avoir plusieurs blocs 15 au sein d'une DSN ayant  même code IP, même code délégataire de gestion, même référence de contrat.
Remarque : du fait de cette correction, le libellé associé aux blocs 15 a changé : avant, on avait le libellé du contrat de prévoyance. Désormais, on a la concaténation des code IP, code délégataire, référence de contrat. C'est moins clair, mais on ne peut pas faire autrement, chaque bloc pouvant couvrir plusieurs contrats de prévoyance, on ne peut pas utiliser le libellé de ces contrats.
En revanche, le libellé des blocs 71 est bien le libellé du contrat de prévoyance (au passage, on a enlevé la date de début du contrat  de ce libellé qui n'était pas vraiment utile).

Lors de la création d'une DSN Phase 2, seuls les bordereaux de versement concernant l'URSSAF sont sélectionnés par défaut pour être inclus dans la déclaration. Ainsi, si on a créé et validé des bordereaux pour d'autres organismes, en prévision d'une future déclaration Phase 3 (en « pilote » notamment), ceux-ci ne sont pas incorporés dans la déclaration (ils seraient rejetés en Phase 2).

Un avertissement a été ajouté lors de la création d'une DSN afin d'alerter l'utilisateur lorsque celui-ci établi une déclaration dans une norme DSN différente de la dernière déclaration générée (et active).

Deux corrections ergonomiques ont été apportées :

Une précision a été apportée récemment dans le cahier technique d'aide à la codification AGIRC-ARROC. Cela concerne le rattachement des cotisations retraites déclarées sur les blocs 81 de code 063 pour l'ARRCO, 064 pour l'AGIRC. Ces blocs 81 doivent être rattachés aux bases assujetties plafonnées pour ce qui est des cotisations ARRCO, aux bases assujetties déplafonnées pour les cotisations AGIRC.
Conséquence : dans le fichier PAYTAB qui contient la liste des paramètres DSN avec leur bases de rattachement, le paramètre 81.063/03 a été remplacé par 81.063/02, les paramètres 81.063/22, 81.063/23, 81.064/24 et 81.064/43 ont été supprimés;
Au passage, on a également ajouté le paramètre 81.063/25-RETA - Montant de cotisation Arrco sur Assiette de contribution libératoire qui est évoqué dans le cahier technique AGIRC-ARRCO.
A la première ouverture d'un dossier de paye V9 avec ce niveau de correction 29, la table des paramètres DSN (DNPARA) est migrée automatiquement en conséquence.

Le fichier des Pays (PEPAYS) a été supprimé au profit des fichiers de nomenclatures externes définis par la norme NEODeS (DSN). Les codes pays saisis dans LDPaye le sont désormais partout en codification ISO 3166-1-A2 (codes pays à 2 lettres au lieu de 3 chiffres antérieurement).
Les pays des adresses des fiches salarié, établissement, société, lieu de travail, et bénéficiaire des honoraires sont désormais issus du fichier de nomenclature PAY.
Les pays de naissance et nationalité de la fiche salarié sont quant à eux issus du fichier de nomenclature PAYS. La distinction réside dans le fait que dans les adresses, le pays FR (FRANCE), et ceux représentant les DOM/TOM (ex : la réunion, Guadeloupe, Saint-Barthélémy, ...) sont exclus. Dans ces cas, le code pays doit rester vide.

A la première ouverture du dossier en version 9, les codes pays sont migrés pour être remplacés par les codes ISO qui existaient dans le fichier PEPAYS. De ce fait, cette migration sera refusée dès lors qu'un pays existait dans ce fichier PEPAYS sans code ISO, et que le code de ce fichier a été utilisé dans au moins un enregistrement.

Cette nouvelle correction porte sur la façon dont la période de rattachement est renseignée sur les blocs 78 :
Cas d'une DSN Phase 2
 - la période de rattachement n'est pas renseignée sur les blocs 78 du mois courant (le mois principal déclaré)
   (comme c'était le cas en version 8)
 - elle ne l'est que sur les blocs 78 correspondant à des régularisations de mois antérieurs
   (régularisations qui n'étaient pas gérées en version 8).
Cas d'une DSN Phase 3
 - la période rattachement est toujours renseignée sur les blocs 78, soit avec le mois courant (le mois principal déclaré)
   soit avec la période régularisée pour les blocs 78 correspondant à des régularisations de mois antérieurs.

De plus, dans tous les cas (Phase 2 et Phase 3, période courante ou régularisation), la période de rattachement est décalée d'un mois si l'option Décalage de la période de rattachement a été cochée sur le plan Bordereaux de versement de la fenêtre de création de la DSN. Ainsi, cette période de rattachement est en phase avec celle que l'on porte sur les blocs 20 et 22.

Particularité pour les OC : il n'y a jamais de décalage. On ne décale donc pas la période de rattachement sur les blocs 20 concernant les OC et sur les blocs 78 de code 31 (Prévoyance).

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.

Les notions d'entité d'affectation des opérations, et de SIRET payeur ont été revues pour correspondre aux prérogatives du cahier des charges de la DSN Phase 3.
De ce fait, en création d'une DSN mensuelle, un bordereau DSN pourra être sélectionné par défaut dès lors que l'établissement déclarant OU que l'établissement payeur sont sélectionnés. 2 colonnes ont été ajoutées dans la liste de choix des bordereaux DSN afin d'afficher le code et le SIRET de l'établissement payeur des bordereaux.
Egalement, le code mode de paiement "06", qui apparaît dans la fenêtre de gestion du lien entre l'OPS et l'établissement, n'est pas sélectionnable (car est réservé au programme). Ce code sera inscrit par défaut dans la DSN de l'établissement déclarant (qui ne correspond pas à l'établissement payeur), pour les blocs "versement" (bloc 20) des OPS de type OC, MSA, ou Retraite.

Lors de la création des bordereaux de versement, pour les OC principalement, on gère le cas des bordereaux ayant une périodicité trimestrielle, semestrielle ou annuelle.
Le cas de la régularisation sur des périodes antérieures est également traité en cas de périodicité autre que mensuelle. Par exemple, si on effectue une régularisation de cotisation prévoyance sur le mois de juillet au titre de juin, lors de la création du bordereau de versement du 3ème trimestre, il y aura automatiquement création d'un bordereau de versement de régularisation sur le 2ème trimestre.

IMPORTANT : de manière générale, pour tout ce qui touche aux OC, pour que tout fonctionne correctement tant en calcul des bulletins (déclenchement des cotisations prévoyance qui sont implicitement conditionnées par le ou les contrats de prévoyance auxquels le salarié est affilié), en création des DSN mensuelles (qui portent le détail des contrats de prévoyance de chaque salarié mois par mois) qu'en création des bordereaux de versement (qui s'appuient, pour calculer les montants à verser pour chaque OC, sur des DSN mensuelles "temporaires" créées implicitement pour chaque mois de la période couverte par le bordereau, chacune de ces DSN portant les données prévoyance de chaque salarié pour le mois concerné), il est primordial de conserver l'historique des affiliations prévoyance de chaque salarié. De ce fait, quand un salarié change de contrat (par exemple suite à un changement de statut catégoriel : le salarié passe Cadre), il ne faut pas se contenter de décocher l'ancien contrat et cocher le nouveau contrat. Il faut laisser l'ancien contrat "coché" mais ajouter une date de radiation sur celui-ci, puis cocher le nouveau contrat et indiquer une date d'affiliation sur celui-ci.

Cas des régularisations antérieures de prévoyance : le système de régularisation sur des mois antérieurs ne peut fonctionner en cas de changement de contrat entre la période que l'on souhaite régulariser et le mois de paye sur lequel on veut régulariser. Par exemple, si un salarié est passé Cadre en juillet, on ne peut pas régulariser sur ce bulletin de juillet ou tout bulletin postérieur des cotisations prévoyance attachées à un contrat de prévoyance qui ne s'applique plus suite au changement de statut : le salarié n'étant plus affilié au contrat, les cotisations de prévoyance des anciens contrats ne se déclenchent pas sur le bulletin et donc ne se régularisent pas.

Lors de la création d'un contrat de prévoyance, dès qu'on sort du premier champ Identifiant interne du contrat, le tableau des paramètres figurant sur l'onglet Cotisations est rechargé en tenant compte de ce nouvel identifiant. Ainsi, s'il existe déjà des paramètres DSN pour cet identifiant interne, du fait que cet identifiant de contrat avait déjà été paramétré antérieurement pour une ou plusieurs sociétés du même environnement, on voit immédiatement les cotisations liées au contrat.

Pour une bonne gestion des contrats de prévoyance en DSN, il est important que lorsqu'un salarié n'est plus affilié à un contrat (abandon d'une mutuelle par exemple, ou changement de contrat suite à un changement d'option d'une mutuelle), on conserve une trace du fait que le salarié été affilié antérieurement. Et pour cela, plutôt que de décocher l'affiliation, il faut simplement saisir une date de radiation.
Afin d'inciter l'utilisateur à ne pas supprimer cette affiliation, une fenêtre apparaît désormais lors du clic sur la coche d'affiliation du salarié. Cet assistant propose la saisie de la date de radiation et du motif de radiation. De la même manière, une fenêtre apparaît lors du clic pour l'affiliation afin de saisir la date d'affiliation éventuelle.
La couleur de la coche a également été gérée : si l'affiliation n'est pas en-cours sur le mois de paye courant, la coche apparaît désormais en gris, alors si au moins un jour de la période d'affiliation est commun avec le mois de paye courant, la coche est verte.

Dans le cas où un contrat de prévoyance avait un code qui correspondait au début d'un autre (ex : PREV-NC et PREV-NC2), alors le programme de création de la DSN créait une affiliation avec les données du second contrat au lieu de la créer avec celles du contrat "court".

Au démarrage, le contrôle de licence affichait une fenêtre de connexion au serveur. Désormais, cette fenêtre ne s'affiche plus et ne perturbe plus la saisie des identifiants lors du choix des sociétés

Le mot de passe de l'identifiant DSN stocké et utilisé pour la récupération des retours depuis l'API est désormais modifié automatiquement lorsque les conditions suivantes sont réunies :

- Le mot de passe a été changé sur le site DSN
- L'utilisateur doit obligatoirement saisir le mot de passe pour envoyer une DSN via l'API.
- Le mot de passe stocké est différent du mot de passe saisi.

Si l'envoi via l'API aboutit, alors, le mot de passe est modifié. Un message complémentaire prévient l'utilisateur du changement.

La gestion des blocs 91-Individu Agirc-Arrco et 92-Bases spécifiques Agirc-Arrco a été ajoutée dans le menu Autres données DSN, là où l'on trouvait déjà la saisie des actions gratuites, stocks options, BSPCE.
Comme ces dernières, les données saisies seront inscrites dans la DSN si le véhicule technique a été coché dans l'assistant de création d'une DSN.

Les libellés des codes issus des fichiers de nomenclature externes n'étaient pas exportés correctement via les différentes fonctions d'exports (Bureautique, export Excel des journaux, ...).
Egalement, les libellés des codes pays de naissance et de nationalité n'étaient pas affichés correctement dans certaines fenêtres.

Dans la correction N° 33, qui a renforcé les contrôles appliqués sur le N° Sécurité Sociale, on disait à propos de la création des 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.
Or, cette correction, initialement faite en version 8, avait mal été reportée en version 9. Et cela ne fonctionnait donc pas comme il est dit ci-dessus. C'est donc le cas désormais.

Suite à la réponse reçue par mail le 01/07/2016 à la question posée à DSN-INFO sur la façon dont il faut renseigner l'identifiant de l'OPS dans le bloc 81 en phase 3 (le cahier technique n'étant pas très clair sur ce sujet), une modification a été faite dans la façon de renseigner cet identifiant en DSN Phase 3.
Désormais, on indique dans la rubrique 81.002 l'identifiant de l'organisme de base qui collecte les cotisations pour le salarié en question, c'est à dire l'URSSAF, la MSA, ou le CCVRP. L'organisme de base est connu dans la situation de chaque salarié. L'identifiant de l'organisme est lu dans le fichier des OPS : SIRET dans le cas de l'URSSAF ou la CCVRP, code de la forme DMSAnn pour la MSA. 
Attention : pour les blocs 81 destinés uniquement aux caisses de retraite (codes 063 et 064) ou aux OC (code 059), cet identifiant OPS n'est pas renseigné, comme précisé dans le cahier technique.

Autre correction faite simultanément : si on crée une DSN Phase 2, les blocs 81 ne sont pas créés si l'organisme de base du salarié est autre que 1-URSSAF. Auparavant, ces blocs 81 n'étaient pas créés si le code régime de base du salarié maladie était 300-Régime agricole. De ce fait, ces blocs 81 étaient créés à tort pour les VRP dont l'organisme de base est la CCVRP, ce qui entrainait un rejet de la DSN car l'identifiant de l'OPS sur les blocs 81, en phase 2, ne peut être qu'un SIRET URSSAF, pas le SIRET de la CCVRP.

Report des corrections 288 et 293 de la version 8 :
Correction N° 288
Lors de la création du bordereau DSN URSSAF, on rencontrait une erreur de doublon si au sein du bordereau, on avait des assiettes négatives à déclarer sur plus d'un des codes CTP 430, 432 et 434 (qui correspondent aux différents codes possibles pour le complément Allocations Familiales). En effet, lorsque les assiettes de complément AF sont négatives, elles doivent être déclarées en code 437, et ce quel que soit le code d'origine, 430, 432 ou 434.
Le fait d'avoir des assiettes négatives à déclarer dont le CTP origine était (par exemple) 430 et 432 provoquait une erreur de doublon. Désormais, tout est bien sommé sur une seule ligne de CTP 437, même si les CTP origine sont multiples.
Correction N° 293
Lors de la création du bordereau DSN URSSAF, lorsqu'on avait des assiettes négatives à déclarer sur plus d'un des codes CTP 430, 432 et 434 (qui correspondent aux différents codes possibles pour le complément Allocations Familiales), et malgré la correction N° 288, il restait encore un souci. On cumulait en effet sur une même ligne de code 437 toutes ces assiettes négatives, cumul sur lequel on appliquait un taux (le taux de la première ligne ayant engendré la création de la ligne de code 437). Mais comme les 3 codes d'origine 430, 432 et 434 ont des taux différents, cela donnait un résultat erroné et un peu aléatoire, selon que la première ligne ayant une assiette négative était rattachée au code 430, 432 ou 434.
En fait, la ligne 437 est une ligne de type Réduction de cotisation et à ce titre, ce n'est pas une assiette qu'il faut déclarer, mais seulement un montant. Désormais, pour ces lignes 437, on ne somme plus les assiettes, mais seulement les montants charges patronales apparaissant sur les bulletins. Et si l'on va en modification du bordereau DSN URSSAF, on voit bien que la ligne 437 a été créée avec le type Réduction de cotisation.
Note : auparavant, sur le bordereau DSN URSSAF, la ligne 437 était encore de type Cotisation proportionnelle comme les lignes de code 430, 432 ou 434. Ce n'était que lors de la création de la DSN que l'on transformait cette ligne 437 en ligne de type Réduction de cotisation pour ne transmettre que le montant et non pas l'assiette que l'on voyait sur le bordereau.

La rubrique Embauche, nouvelle en V9.00, a été rendue obligatoire sur l'écran de saisie d'une situation d'un salarié, onglet Poste, cadre Dates et ancienneté. Cette zone permet d'indiquer si le salarié est en situation de cumul emploi-retraite.
La valeur 02 de cette zone, ayant disparu entre les versions 4 et 5 du cahier technique DSN Phase 3, a été supprimée de la liste des valeurs autorisées pour ce champ.
De plus, pour satisfaire aux consignes données pour le remplissage de cette zone en DSN, la valeur indiquée pour chaque salarié est envoyée en DSN non pas chaque mois, mais seulement lors de la première DSN suivant un nouveau contrat, ou en cas de changement de la valeur portée dans la situation du salarié entre DSN mensuelle (cas d'une correction).
Enfin, suite à la mise en place de cette correction, une initialisation de la valeur a lieu à la première ouverture du dossier : la valeur 02 est remplacée par la valeur 03, la valeur blanc est remplacée par 01.

En prévision de la gestion des cotisations Pénibilité, qui ne doivent pas être calculées en décalage de paye pour les sociétés qui pratiquent ce décalage, une nouvelle notion a été ajoutée dans les fiches Cotisation : le mois de remise à zéro des cumuls cotisations. Ce mois de remise à zéro s'entend toujours, comme pour un cumul salarié, en fin de mois (clôture du mois). Par exemple, pour une cotisation dont le mois de remise à zéro est octobre, cela signifie que les cumuls repartent à zéro lors du calcul des bulletins de novembre.
Ainsi, pour les cotisations Pénibilité, on pourra indiquer comme mois de remise à zéro la valeur 12-Décembre au lieu de la valeur par défaut qui est 99-Dernier mois de l'exercice. Pour les sociétés qui clôturent à fin décembre, cela revient au même. Mais pour les sociétés qui pratiquent le décalage de paye, avec donc clôture de l'exercice à fin novembre, cela permettra de gérer les cotisations pénibilité avec des cumuls en année civile, de janvier à décembre, alors que les autres cotisations resteront gérées sur l'exercice paye, de décembre à novembre.
A la première ouverture d'un dossier de paye suite à la mise en place de cette correction, toutes les cotisations reçoivent la valeur 99-Dernier mois de l'exercice comme Mois de RAZ, sauf les cotisations qui étaient définies avec un mois de remise à zéro spécifique (ce qui était possible via un pseudo-spécifique qui existait pour certaines cotisations de Monaco. Ce pseudo-spécifique a de ce fait été supprimé puisque le choix du mois de remise à zéro est désormais possible pour toutes les cotisations).

Des modifications (mineures) ont été apportées pour la conformité avec le cahier technique NEODeS 2016.P3.1 Release 6 du 15/07/2016.

Lors de la création d'une DSN en version 9, que ce soit une DSN Phase 2 ou Phase 3, on rencontrait une erreur si la DSN précédente de l'établissement concerné était fractionnée.
Détail de l'erreur rencontrée :
Traitement de 'Méthode RechercherBlocDansDéclarationPrécédente' (dsnFabrique.RechercherBlocDansDéclarationPrécédente), ligne 45, thread 0 : Le passage du paramètre 1 a provoqué une erreur.
Dans le cas d'un passage de paramètre par adresse, un élément de type 'entier sans signe sur 4 octets' ne peut pas être converti vers le type 'entier'. Utilisez un paramètre local dans la procédure appelée ou passez un paramètre de type 'entier'.

Lors de la migration des paramètres N4DS en DSN, pour ce qui est des nouveaux paramètres nécessaires en phase 3, il y avait une erreur lors de la migration du paramètre N4DS S40.G40.00.067.001 en paramètre DSN du bloc 81 code 901. Cela concerne le montant des cotisations épargne retraite supplémentaire ou PERCO.
La récupération qui était faite faisait que le montant de ces cotisations épargne retraite était transmis en DSN dans la rubrique 003-Montant d'assiette et non dans la rubrique 004-Montant de cotisation.

De plus, ce paramètre 81.901 est désormais classé dans le type Retraite et non plus Autres éléments. Et sa nature d'alimentation est passée de RM à RM ou CM, de façon à pouvoir alimenter ce paramètre à partir d'une cotisation. 
Et enfin, on a fait en sorte que ce paramètre soit proposé quand on est sur une fiche Cotisation rattachée (de par la famille cotisation) à un OC, même si ce paramètre ne concerne pas les OC, mais la DgFIP. Cela permet de saisir ce paramètre directement sur une fiche cotisation lorsqu'il s'agit d'une cotisation de retraite supplémentaire.

Suite aux précisions données dans le document Guide Acoss : comment déclarer les cotisations Urssaf en DSN, il apparait que sur le bloc 81 code 226, où l'on doit renseigner l'assiette du versement transport, il faut indiquer le code INSEE de la commune concernée par ce versement (comme on le fait déjà sur la cotisation agrégée). Et ce tant en DSN Phase 2 que Phase 3.
En version 9, ce code commune n'était géré que pour les paramètres 81.081-Montant du versement transport et 81.082-Montant du versement transport additionnel, paramètres qui concernent uniquement la MSA. Le système a donc été étendu au paramètre 81.226 concernant l'URSSAF.
Le code INSEE de la commune doit donc être saisi pour ces 3 paramètres, que ce soit dans la saisie des paramètres DSN proprement dit ou dans la saisie d'une fiche cotisation, sur l'onglet Déclaration.

Au passage, différentes petites imperfections d'ergonomie ont été corrigées dans la saisie de ces paramètres DSN, notamment en cas d'utilisation des boutons de parcours en partie basse de l'écran.

Lorsqu'on utilisait les nouvelles possibilités de régularisation du brut abattu, et si cette régularisation se faisait sur le moins courant (c'est à dire avec le repère @A00 dans le libellé), suite au calcul du bulletin, on avait des cumuls cotisations créés en double pour toutes les cotisations sur lesquelles cette régularisation du brut abattu était opérée. Pour le mois de paye courant, pour chaque cotisation régularisée, le système créait un cumul cotisation "normal", et un cumul cotisation pour la régularisation, mais dont le mois de rattachement était le mois de paye (à cause du @A00). Du coup, on avait 2 cumuls portant sur le même bulletin, la même cotisation, le même mois de paye et le même mois de rattachement (doublon sur la totalité de la clé composée). Et si on recalculait le bulletin plusieurs fois, ces cumuls en double se multipliaient, car du fait de cette clé en double, la méthode de mise à jour des cumuls cotisations en fin de calcul d'un bulletin faisait un peu n'importe quoi. Seule façon de revenir à quelque chose de correct : supprimer le bulletin (pour que tous les cumuls cotisations du mois soient effacés, puis le recalculer avec ce correctif.
Complément d'information : la correction a consisté à ne pas créer ces cumuls "spécifiques" de régularisation de brut abattu lorsqu'ils portent sur le mois de paye courant, où de toute façon ils n'ont aucune utilité, le mois de rattachement étant égal au mois de paye.
Notez que ce problème ne concernait que les régularisations de brut abattu ; pour les régularisations de base, on ne peut pas en faire sur le mois courant. Et pour les régularisations de plafond, cela fonctionne d'une autre manière et cela avait été bien géré dès l'origine.

Dans certains cas, l'ouverture de la fenêtre de conditionnement d'une cotisation provoquait un plantage.

Information technique :
Ce plantage se provoquait après l'ouverture de la fenêtre de conditionnement des rubriques. Si entre ces deux fenêtres, cette dernière était la première à être ouverte dans la session, cela plantait la fenêtre.

Ce plantage était du car un lien subsistait entre les deux fenêtres. Peut-être que la procédure impliquée était une copie de la procédure de l'autre fenêtre.

Certaines cotisations agrégées vont toujours de pair sur le bordereau URSSAF en DSN, c'est à dire qu'on ne peut pas déclarer une base déplafonnée (920) sans déclarer aussi une base plafonnée (921), quitte à la déclarer à zéro.
Mais dans certains cas (assez rares), cette base plafonnée n'existe pas. C'est le cas par exemple d'une personne ayant 2 bulletins, l'un en tant que salarié, l'autre en tant que mandataire. Si la totalité du plafond est absorbée sur le premier bulletin, on ne trouve que des cotisations déplafonnées sur le second. Sur le bordereau URSSAF, pour le CTP 863 correspondant au mandataire, on ne trouvera alors que la ligne de code qualifiant 920-Autre assiette (Déplafonné) ; la ligne de code qualifiant 921-Assiette plafonnée ne sera pas créée puisqu'il n'y a aucune ligne plafonnée sur le bulletin. Et cela, bien que ne bloquant pas l'émission de la DSN, entraine une anomalie dans le bilan métier URSSAF.
Pour éviter cela, lors de la création du bordereau URSSAF DSN, pour toutes les lignes qui sont définies dans le paramétrage du bordereau URSSAF à la fois en code qualifiant d'assiette 920 et 921, on crée une ligne à zéro pour le qualifiant d'assiette 921 s'il existe sur ce bordereau une ligne de qualifiant d'assiette 920 sans ligne associée (même CTP, même taux AT) de qualifiant d'assiette 921.

Dans la fenêtre principale de gestion des salariés ainsi que dans la fenêtre de calcul des bulletins, une colonne supplémentaire a été ajoutée pour la nouvelle rubrique Embauche en cumul emploi retraite.
D'autre part, la mention N° situation a été ajoutée dans la seconde fenêtre de saisie d'un code pénibilité, celle qui présente la liste des salariés, dans la 7ème colonne où l'en-tête de colonne avait été oublié.
Enfin, un bouton de "déroulement" de combo était affiché à tort sur la ligne courante dans la colonne Mois de bascule CP de la fenêtre de calcul des bulletins (à tort, car cette donnée étant en affichage seulement, on ne peut pas dérouler la combo).

Afin de gérer les changements de codes risques dans le temps (pour la DSN), un historique du code section, risque, et bureau, ainsi que du taux, a été intégré dans la gestion du code AT. Cet historique est initialisé en date du 01/01/1900 pour les codes existants (et de la date de prochain taux, pour ceux étant renseignés avec 2 taux). Désormais, l'historique des valeurs du plan de paye n'historisera plus le taux des cotisations AT (qui était simulé) et le calcul de ces cotisation (même en cas de recalcul ou de régularisation) sera effectué en utilisant uniquement ce nouvel historique du code AT.
Egalement, une modification a été réalisée dans la déclaration du code risque en DSN, car le code bureau n'était pas déclaré alors qu'il est attendu.

La période de référence de la CVAE doit être renseignée dans toutes les DSN des établissements assujettis à la CVAE. De plus, cette période peut être différente de l'année civile.
Aussi, les dates des exercices CVAE doivent désormais être inscrites, par exercice, dans la fiche société, onglet Détail. Le renseignement de ces dates est vérifié à chaque création d'une DSN Mensuelle pour les établissements assujettis à la CVAE (défini dans la fiche établissement).

Un dépositionnement des fichiers salariés et situation (périodes d'activités) avait lieu lors de la création ou modification des codes pénibilités. Cela pouvait avoir des conséquences lorsque la fenêtre de gestion de ces codes étaient appelées "à la volée" en cliquant sur le bouton "Gérer" dans la fenêtre de sélection du code pénibilité, en saisie d'une période d'activité.

Le guide d'implémentation de l'API DSN indiquait depuis toujours une limitation qui vient d'être mise en place récemment : une seule déclaration par envoi (soit un S20 pour une enveloppe S10).
Cette limitation ne s'applique qu'au niveau de l'envoi via l'API mais pas pour les dépôts manuels. De ce fait, le processus de création du fichier et du contrôle est toujours identique. Cependant, lorsqu'on procède au dépôt via l'API, le fichier généré est découpé en autant de fichiers qu'il y a de déclarations. Chaque fichier conserve la même enveloppe S10.
Les conséquences de ce découpage sont qu'il y autant de flux DSN qu'il y a d'envoi, et pour chacun de ces flux, il y a des retours. La récupération des retours via l'API a donc été revue pour gérer ce découpage.

Suite au correctif 99, la stratégie de récupération des retours a été revue.

Auparavant, il fallait demander manuellement le rafraichissement d'un envoi pour récupérer les nouveaux retours. Désormais, les retours sont récupérés par polling. Cela signifie que l'API est régulièrement interrogée pour récupérer les derniers retours.
Cette méthode est plus "économique" en termes de bande passante car les échanges sont minimes s'il n'y a aucun nouveau retour (soit la majorité des cas). Elle est aussi plus efficace car on récupère tous les retours au fur et à mesure de leur mise à disposition. L'utilisateur n'a plus de raison d'utiliser la fonction Rafraichir (bien qu'elle soit toujours présente) car il ne peut plus louper un retour.

La récupération des retours, exécutée en tache de fond invisible, se déclenche 15 secondes après l'ouverture de la fenêtre principale de gestion des Déclarations DSN et se répète ensuite toutes les 5 minutes tant que cette fenêtre reste ouverte. Un message en bas de la fenêtre indique la durée restant avant la prochaine récupération. Il est possible de désactiver ou de forcer la récupération en cliquant sur ce message.

Parallèlement à cela, la présentation des retours a été revue.
Tout d'abord, l'affichage au niveau de chaque envoi et de chaque déclaration a été revu pour indiquer si le retour a été déposé via l'API DSN et indiquer si le SI DSN indique une anomalie. La notion de "conformité" a disparu car LDPaye n'est pas en mesure d'interpréter les différents retours.
Pour accéder à la fenêtre de bilan, il faut désormais cliquer sur le statut de la déclaration (sans menu contextuel). Cette fenêtre a été revue pour ne présenter que les retours de la déclaration. Si plusieurs envois successifs dans le temps ont été faits, et qu'on a donc plusieurs flux associés à cette déclaration, la liste en haut de la fenêtre permet de naviguer parmi ceux-ci. Par défaut, c'est le plus récent qui est affiché.

Dans l'édition de la taxe sur les salaires, il est possible de créer automatiquement les assujettissements fiscaux pour la DSN. Dans certaines conditions, les assujettissements étaient créés mais sans mois de déclaration.

Lors de la récupération des retours, certaines erreurs renvoyées par le SI DSN peuvent ne pas être gérées par LDPaye. La récupération de ces erreurs provoquait un plantage. Désormais, un message générique avec le code de l'erreur est affiché et l'application ne plante plus.

Un plantage survenait lors de l'utilisation d'une condition sur une date (entrée ou ancienneté) en opérande 1 et une valeur en opérande 2. Cette erreur se produisait pour les rubriques, les cotisations et les lignes de bordereau DSN.

Les retours récupérés via l'API DSN sont en règle générale au format XML. Ce format permet aux retours DSN d'être évolutifs et enrichis au fil du temps. Cependant, si des nouvelles données apparaissent et qu'elles ne sont pas reconnues par LDPaye, une trace était affichée pour indiquer l'anomalie.
Désormais, il n'y a plus de trace qui s'affiche. Les éléments sont affichés dans un groupe DONNEES INCONNUES. Il est possible de contacter ensuite votre prestataire pour demander la gestion de cette nouvelle information.

Lorsqu'on modifiait la configuration d'un journal standard ou détaillé et que ce dernier avait un export excel personnalisé, un plantage pouvait se produire si l'une des colonnes supplémentaires pour Excel avait disparu lors d'un changement de structure de la base de données de LDPaye.
Désormais, l'existence des colonnes sont contrôlées à l'ouverture. Si une colonne n'existe plus, un message indique laquelle. Enfin, lors du paramétrage ou de l'édition, le libellé de la colonne est remplacé par un message indiquant son inexistence.

Lors d'une migration V9.0* à V9.00 (toutes les migrations de V8.00 à V9.00 sont donc exclues), la date de début d'arrêt (PEARRE.DADA) était initialisée au lendemain du dernier jour travaillé. Cependant, si cette migration avait déjà été effectuée, la date de début était initialisée de la même manière, même si elle avait été modifiée. Désormais, la date est initialisée seulement si elle n'est pas encore renseignée.

Le libellé du code RETA, dans le cas d'une retraite complémentaire des non-cadres était marqué "(AGIRC)" au lieu de "(ARRCO)".

Toutes les adresses (société, établissement, lieu de travail, salarié, honoraires) ont été revues pour être alignées sur les descriptions fournies par la DSN :
 - toutes les lignes de l'adresse acceptent désormais jusqu'à 50 caractères (au lieu de 32 auparavant)
 - le code postal accepte jusqu'à 10 caractères (la norme DSN prévoit 50, mais on a volontairement limité à 10)
 - le code pays a été ajouté dans l'en-tête bulletin (où l'on avait déjà les autres champs de l'adresse)
 - la liste des caractères autorisés dans les champs de l'adresse a été revue pour s'aligner sur les normes DSN et N4DS :
   lettres majuscules et minuscules, chiffres, voyelles accentuées majuscule et minuscules, espace, apostrophe, point et tiret.
Toutefois, dès lors que l'adresse saisie est en France (code pays non renseigné ou égal à FR), les limitations propres à la France s'appliquent en saisie : les 3 premières lignes ne peuvent excéder 38 caractères, le code postal doit être composé exactement de 5 chiffres, la ville ne doit comporter que des lettres majuscules ou minuscules ou des chiffres (pas de voyelle accentuée, pas de caractères spéciaux autre que l'espace, même l'apostrophe n'est pas admise).

De même, pour tous les champs composant l'identité d'un salarié (Nom, Prénom, Nom de famille...), la liste des caractères autorisés en saisie a été réalignée sur ce qui est permis par les normes DSN et N4DS : lettres majuscules et minuscules, voyelles accentuées majuscule et minuscules, espace, apostrophe et tiret.

Enfin, que ce soit pour un champ Adresse ou Identité, certaines limitations s'appliquent quant à l'usage des caractères spéciaux :
 - ceux-ci ne sont pas admis en premier ou dernier caractère, sauf l'apostrophe qui est acceptée en premier caractère d'un nom,
 - deux caractères spéciaux identiques ne peuvent se suivrent, sauf cas particulier du tiret qui peut être doublé dans le nom,
 - un espace ne peut précéder ou suivre un caractère spécial.

Remarque : sur l'édition des bulletins de paye, la présentation de l'adresse a été légèrement revue : le code postal et la ville sont désormais présentés concaténés dans un seul champ, séparés par 2 espaces, au lieu de deux champs distincts auparavant. Cela permet de gérer plus facilement la longueur variable de ce code postal, qui peut excéder 5 caractères pour les adresses à l'étranger.

Suite à la migration d'une version intermédiaire 9.0*, en version 9.00, certains codes de la situation pouvaient avoir été réinitialisés à tort. Ce problème ne se manifestait que lors d'une migration V9.0* à une V9 niveau 110.

La recherche dans les DSN précédentes lors de la constitution d'une nouvelle DSN pouvait dans certains cas ne pas donner le résultat escompté. Le fichier DNBLOC sera vérifié à la 1ère ouverture du dossier avec ce niveau afin de s'assurer du bon enregistrement des clés utilisées pour ces recherches dans les DSN précédentes.

Il arrive que des fichiers HyperFile SQL n'appartenant pas à LDPaye puissent se trouver dans le répertoire des données. Ces fichiers peuvent poser problème si LDPaye n'est pas capable de les ouvrir (parce qu'ils sont protégés par mot de passe).

Désormais, LDPaye ignore ces fichiers lors de la réindexation.

Deux corrections ont été apportées au niveau de la consultation des retours et du statut des envois.

Lors de la consultation des retours DSN, certains retours n'apparaissaient pas dans la liste, alors qu'ils avaient été récupérés depuis le service Net Entreprise. 

Lors de l'affichage du statut d'un envoi DSN, celui-ci prenait en compte le statut de toutes les déclarations de l'envoi, même si celles-ci ont pu être envoyées plusieurs fois. De ce fait, si au moins une déclaration avait rencontré un problème, quand bien même ce n'est pas la dernière, l'envoi était marqué en anomalie. Désormais, l'envoi est en anomalie seulement si le dernier dépôt présentait une anomalie.

Deux choses ont été faites pour améliorer l'ergonomie lors de la définition des contrats de prévoyance :

Les périodes d'inactivités étaient envoyées dès lors que la période d'inactivité était dans le mois déclaré, et répétées s'il y avait plusieurs contrats à déclarer.
Ces périodes ne sont désormais envoyées que si au moins un jour est commun entre la période d'inactivité et la période du contrat déclarée sur le mois (en tenant compte de l'entrée ou de la sortie éventuelle dans le mois).

Pour toute action gratuite, stock option ou bon de souscripteur déclaré dans la DSN (blocs 87, 88, 89), le salarié concerné doit exister dans cette même DSN en bloc 30. Les salariés partis sont donc également ajoutés en DSN s'ils sont concernés pour l'un de ces blocs (le mois de la déclaration de ces blocs).

Les retours suivants sont consultables depuis la fenêtre d'affichage des retours DSN :

- 22 : Contrôles A6M (arrêt de plus de 6 mois) sur DSN Mensuelle
- 30 : Accusé de réception (ARL OK)
- 32 : Accusé de réception A6M
- 50 : CR de distribution à l’OC
- 60 : Accusé de réception par l'URSSAF
- 70 : Accusé de réception par l'AGIRC-ARRCO

Dans la fenêtre des bilans, les retours sont désormais organisés par organismes destinataires.

Toujours dans la fenêtre des bilans, on affiche le code nature du retour en haut à droite du bandeau de titre du retour.

Il est désormais possible de créer les contrats de prévoyance à partir des fiches de paramétrage fournies par les OC au format XML.
Cette fonctionnalité est disponible depuis la liste des contrats de prévoyance. Il est possible :
 - de traiter des fiches de paramétrage déjà présentes sur un disque local ou réseau
   (fiches téléchargées manuellement depuis le site Net-Entreprises au format XML)
 - d'importer ces fiches de paramétrage via l'API-DSN afin de pouvoir les traiter ensuite par cette procédure.
   Note : à ce jour, tous les OC ne sont pas encore en mesure de fournir les fiches de paramétrage au format XML. Et même
   pour ceux qui mettent en disposition ces fiches au format XML, tous ne les proposent pas au travers de l'API-DSN.

Dans le cas d'un environnement contenant un grand nombre d'établissements, le programme pouvait dans certains cas poser un problème lors de la sélection du type de collecte des cotisations retraite (AGIRC, ARRCO, ou les 2) pour un OPS de type retraite (liste des établissements déclarants, depuis la liste des OPS en DSN). Dans ce cas, lors de la sélection de la valeur souhaitée, la valeur apparait dans la table des établissement, mais ne reste pas sélectionnée dans la liste qui vient d'être modifiée.
Ce phénomène pouvait être contourné soit en faisant un filtre dans la liste des établissements au-dessus pour avoir moins d'établissements affichés, soit en recliquant sur la ligne de l'établissement juste après avoir choisi la valeur souhaitée (ce qui recharge la zone avec la valeur affichée dans la table, qui elle est bonne).

Dans la fenêtre d'édition d'un journal détaillé, lorsqu'on appelait la configuration d'un journal (bouton Configurer), la validation de la fenêtre de configuration pouvait provoquer le plantage de l'application.

Dans LDPaye, il existe un mécanisme de verrouillage permettant d'éviter qu'il y ait 2 calculs de bulletins simultanés dans le même environnement de paye. Pour cela, avant chaque calcul de bulletin on tente de verrouiller le fichier des en-têtes de bulletins. Si ce verrouillage n'est pas possible (ce qui ne peut être dû qu'au fait qu'un autre calcul de bulletin est en cours depuis une autre session LDPaye), il y a une mise en attente, jusqu'à ce que ce fichier des en-tête bulletins puisse être verrouillé (c'est à dire que l'autre calcul de bulletin soit achevé). Cette attente est visible : un message s'affiche, disant :
  Calcul en attente pour XXXXXXXXXXXXX
Durant cette mise en attente, le système retente périodiquement de verrouiller le fichier, et ce un certain nombre de fois.
Jusqu'alors, le système retentait tous les 2/10èmes de secondes, et 100 fois successivement au maximum, ce qui représente une durée d'attente maximale de 20 secondes, largement suffisante dans la plupart des cas pour laisser le temps de terminer un autre calcul de bulletin.
Cependant, dans certains configurations "lourdes", où l'on peut avoir plus de 2 personnes qui tentent d'effectuer des bulletins simultanément, et pour peu que chaque calcul de bulletin nécessite plusieurs secondes, cette durée de 20 secondes pouvait s'avérer trop faible. On obtenait dans ce cas le message :
Verrouillage impossible des fichiers pour le calcul du bulletin du salarié XXXX.
Un calcul est déjà probablement en cours par ailleurs ; il devra être relancé ultérieurement.

A l'avenir, si on souhaite éviter ce message, on peut jouer avec le nombre maximum de tentatives de verrouillage et la fréquence de celles-ci. Cela se fait en renseignant un paramètre programme nommé CALC_TEMPO, paramètre dans lequel on doit indiquer, en position 1 à 64, le nombre d'essais maximal et la durée d'attente (en centièmes de secondes) entre 2 tentatives, sous la forme de 2 nombres compris chacun entre 10 et 1000, séparés par un point-virgule.
Exemple :
200;30; 200 essais espacés de 0,3 secondes, soit 60 secondes

Dans la fenêtre où l'on peut affecter les salariés à un contrat de prévoyance, suite à la correction N° 131, on dispose de boutons Tous et Aucun pour affilier (ou retirer l'affiliation) en bloc à l'ensemble des salariés sélectionnés sur l'écran.
Cette fonction Tous/Aucun ne s'appliquait pas à l'ensemble des salariés répondant aux critères de filtrage mis en place, mais seulement à ceux affichés visuellement dans la table, compte-tenu de la taille de la fenêtre.

Depuis la mise en place d'un historique dans le code AT (dans un précédent correctif), le taux AT déclaré dans le bloc 40-Contrat, rubrique 043, était le taux appliqué à la date de début de la situation du salarié, qui peut donc être différent du taux correspondant au mois déclaré de la DSN.

La date et le motif de reprise des arrêts, dès lors qu'ils étaient saisis pour un arrêt de travail, étaient systématiquement repris en DSN mensuelle, même lorsque la date de reprise était postérieure à la date de fin du mois déclaré en DSN, ce qui provoquait une anomalie bloquante.

La modification d'un bloc DSN n'était pas enregistrée sur les blocs créés manuellement, directement après sa création. Pour contourner ce problème et pouvoir enregistrer la saisie sur ce bloc, il fallait avoir fermé la fenêtre de la DSN entre l'ajout et la modification du bloc.

L'outil permettant de recalculer un cumul cotisation a été amélioré. Il permet désormais d'initialiser les cumuls d'une cotisation à partir de ceux d'une autre cotisation pour lesquels les coefficients plancher et plafond sont différents. Et dans ce cas, il propose automatiquement de recalculer les cumuls de planchers, plafonds et bases en conséquence.
Ainsi, par exemple, si on a une cotisation modèle en tranche A, on peut initialiser une cotisation définie en tranche B. Cela est bien pratique quand on doit par exemple "éclater" une cotisation paramétrée initialement et TA+TB en 2 cotisations TA d'une part, TB d'autre part.
Cet outil sait traiter les cas suivants :
 - T1 vers T2
 - T1/TA vers TB
 - T1/TA vers TC
 - TB vers TA
 - TB vers TC
 - TA+TB vers TA
 - TA+TB vers TB
 - TA+TB vers TC
 - TA+TB+TC vers TA
 - TA+TB+TC vers TB
 - TA+TB+TC vers TC
Au passage, une petite modification d'ergonomie a été faite : la fenêtre n'est plus refermée automatiquement à la fin de l'initialisation d'un cumul. On peut donc relancer la procédure pour initialiser une autre cotisation ou une autre société si nécessaire.

Une note d'information a été publiée récemment par les Organismes Complémentaires (OC), indiquant que tous les codes des blocs 79 inscrits dans les fiches de paramétrage DSN doivent obligatoirement être envoyés, même à zéro.
De ce fait, suite à ce correctif, lors de la création d'une DSN mensuelle, il y a création d'un bloc 79 pour chaque code paramétré (par exemple 11-TA et 13-TB) de chaque contrat auquel le salarié est affilié, même si la valeur calculée par le paramètre DSN retourne une valeur nulle (pas de TB par exemple). De la même manière, un bloc 81 code 59 sera créé pour chaque contrat lié au salarié, même s'il est à zéro.

Dans la fenêtre permettant de choisir quelles sont les cotisations liées à un contrat de prévoyance, la sélection des cotisations actives ou suspendues est ignorée dès lors qu'on affiche uniquement les cotisations liées. De cette manière, cela permet de visualiser toutes les cotisations qui génèreront des blocs 79 ou 81 (éventuellement à zéro, suite à la correction N° 153), même si la cotisation est suspendue.

Le rattachement des blocs 79 et 81, sur les blocs 78 a été revu suite à la fiche consigne du 05/10/2016, disponible ici : http://www.dsn-info.fr/documentation/fiche-consigne-blocs-78-79-81.pdf
Les modifications effectuées sont les suivantes :
- le bloc 79, code 02 (SMIC CICE), sera désormais automatiquement rattaché au bloc 78 code 12 (assiette CICE)
- le bloc 81, codes 001, 002, et 003 (exonérations apprentis) seront rattachés automatiquement au bloc 78 code 11 (base forfaitaire SS)
- Le bloc 81, code 063 (retraite ARRCO) peut désormais être rattaché au bloc 78 code 11 (base forfaitaire SS, dans le cas des apprentis notamment) ou code 45 (Base plafonnée ICP Agirc-Arrco)
- Le bloc 81, code 226 (Assiette du Versement Transport) peut désormais être rattaché au bloc 78 code 03 (Assiette brute déplafonnée), ou code 11 (base forfaitaire SS, dans le cas des apprentis notamment).
Suite à la mise en place de ce correctif, les paramètres existants de code 81.063/02 restent inchangés et ceux de code 81.226 sont basculées en 81.226/03.
Pour les apprentis, il convient donc de modifier les paramètres DSN des cotisations retraite (81.063/02) et éventuellement versement transport (81.226/03) pour les basculer sur les codes 81.063/11 et 81.226/11 respectivement.

Les contrôles présents dans le CT DSN pour le bloc 62-Fin de contrat, rubrique 002, ont été appliqués dans la fenêtre de saisie des informations de fin de contrat. Cela consiste à ne permettre que certains codes motifs de fin de contrat, selon la nature du contrat.

Lors de la création d'une fiche salarié par duplication d'une fiche existante, 2 améliorations ont été apportées :

• le motif d'entrée sur la première situation de la nouvelle fiche n'est plus systématiquement pris égal à la valeur EM-Embauche comme c'était le cas auparavant. Il est désormais égal au motif d'entrée à l'origine de la situation copiée (en remontant dans le temps, à partir de la dernière situation copiée, jusqu'à trouver celle ayant un motif de début de type Entrée). Ainsi, si on copie une situation qui été créée avec à l'origine un motif d'entrée CDD, ce motif d'entrée se retrouve sur la nouvelle fiche créée par copie.
• dans la fenêtre de choix des options de copie, on dispose d'une nouvelle option pour réinitialiser les dates de début de situation, d'entrée et d'ancienneté à une valeur donnée.
  Si on demande à forcer ainsi une nouvelle date d'entrée, la date de renouvellement de CDD est automatiquement effacée sur la nouvelle fiche. La date initiale de fin de CDD est quant à elle calculée de telle sorte que durée du CDD créé par copie soit identique à celle de la situation copiée, si la situation sur laquelle on a copié le motif de début de situation portait une date initiale de fin de CDD.

• pour un arrêt de travail, les arrêts de travail saisis avec le motif 08-temps partiel thérapeutique ne seront pas repris en DSN mensuelle
• une suspension du contrat de travail saisie avec le code 637-congé pour événement familial sera transmis en DSN Phase 3, mais pas en DSN Phase 2.

La norme utilisée (Phase 2 ou Phase 3, rubrique DSN 00.006) et le type d'envoi (réel ou test, rubrique DSN 00.005) ont été ajoutés dans l'entête de l'édition DSN.
Le type de déclaration (normal, néant, ... rubrique DSN 05.002) a également été ajouté au niveau de l'entête de la déclaration.

LDPaye propose désormais la génération du formulaire PDU1 qui n'était disponible qu'en paye V8.00 à partir du niveau 295.

Dans le cas d'un bloc 51-Rémunération de type 011-Heures supplémentaires ou complémentaires, 012-Heures d’équivalence, 013-Heures d’habillage, déshabillage, pause ou 014-Heures correspondant à du chômage sans rupture de contrat ou du chômage intempéries, le nombre d'heures doit obligatoirement être envoyé dans le fichier, même s'il est à 0.

Deux corrections ont été apportées sur le bordereau de cotisations (pas le bordereau de versement DSN, l'ancien bordereau de cotisations, utilisé principalement pour l'URSSAF) :

• à l'ouverture de la fenêtre, en cas de décalage de paye, la période proposée par défaut était erronée.
• s'il y avait des régularisations de cotisations au titre de mois antérieurs, les lignes du bordereau sur lesquelles il y avait des régularisations avaient un taux erroné. Par exemple, si on avait une régularisation pour un salarié sur le forfait social à 8% (donc 2 lignes forfait social sur le bulletin de ce salarié, l'une pour la base du mois, l'autre pour la base antérieure que l'on régularise), sur le bordereau de cotisations URSSAF, on avait une ligne forfait social à 16% (8+8) avec l'assiette de ce salarié (base du mois + base antérieure) et une autre ligne avec un taux à 8% reprenant l'assiette de tous les autres salariés.

La table des codes types URSSAF (livrée sous la même forme que les nomenclatures DSN, mais qui ne peut se mettre à jour automatiquement car pas disponible sur le site DSN-INFO) a été rafraichie manuellement. 
Par rapport à l'ancienne version livrée en version 9 qui datait de septembre 2015, voici les différences :

Codes ajoutés
265 SERVICE CIVIQUE VOLONTARIAT AT/MP OM
285 S.CIVIQUE VOLONTARIAT AV AF MAL OM
385 SERVICE CIVIQUE VOLONTARIAT CSG-CRDS OM
438 EXONERATION GREVE SNCM
447 AT-BENEF MISE EN SITUATION PROF ESAT
478 REGULARISATION FORFAIT SOCIAL
480 FORFAIT SOCIAL TAUX 16%
551 CONTRIB ATTRIB ACTIONS GRATUITES

Codes supprimés
237 FNAL DEGR. ANNEE 4 MEDECINS
322 FNAL DEGR. ANNEE 4 JOURNALISTES
324 FNAL JOURNALISTES -DE 20 SALARIES
326 FNAL JOURNALISTES (20 SALARIES OU +)
570 REGUL. REDUCTION GENERALE MAJOREE
580 REDUCTION GENERALE MAJOREE
678 EPARGNE SALARIALE
806 FNAL MEDECINS +DE 20 SALARIES
818 FNAL DEGRE ANNEE 6 MEDECINS
840 EMPLOIS CONSOLIDES APRES CES(EDF)

Les bulletins, liés à une situation n'ayant aucun jour en commun avec le mois courant, des salariés ayant une situation sur le mois courant, n'étaient pas déclarés en DSN.
Désormais, tous les bulletins calculés sur le mois sont envoyés en DSN, avec le contrat lié, même si ce dernier fait référence à une période antérieure au mois déclaré.

L'interface de la fenêtre de création des bordereaux de versement DSN a été entièrement revue.
On peut désormais créer en une seule opération tous les bordereaux arrêtés à une fin de mois donnée, qu'il s'agisse de bordereaux mensuels ou trimestriels. On minore ainsi le risque d'oublier les bordereaux trimestriels.
En parallèle, une autre modification a été faite pour pouvoir gérer le cas des bordereaux de versement des OC, pour lesquels il n'y a en principe pas de décalage (contrairement aux caisses de retraite qui suivent le décalage adopté pour l'URSSAF). Le fait qu'on gère un OC en décalage ou pas se détermine donc désormais au niveau du lien entre un OC et un établissement (si l'environnement de paye est lui-même en décalage bien entendu).
Enfin, dans la fenêtre de création des bordereaux de versement, on dispose d'un second mode de travail dit "avancé", accessible par le bouton Avancé en bas à gauche de la fenêtre. Dans ce mode, on peut aller au-delà de ce qui est proposé ordinairement, pour ce qui est de la correspondance entre la période de rattachement du bordereau (la période déclarée) et la période extraite du point de vue de la paye (bulletins de paye pris en compte). Cela permet de traiter les situations particulières que l'on peut avoir en cas d'entrée ou de sortie du décalage de paye, pour les bordereaux trimestriels : on peut être amené dans certains cas à établir un bordereau "trimestriel" couvrant 2 mois ou 4 mois de paye. Cela peut aussi être le cas pour ceux qui pratiquent le "faux" décalage, c'est à dire le décalage tout au long de l'année sauf en décembre. Si cette situation est prévue par l'URSSAF qui a donné des consignes précises quant à la façon de déclarer cela en DSN, rien n'est vraiment clair pour les caisses de retraite notamment, surtout si celles-ci sont payés au trimestre. Ce mode Avancé devrait donc permettre de se sortir de ces situations plus ou moins délicates.

Le n° de versement déclaré en DSN dans le bloc 50-Versement (rubrique n° 003), et correspondant jusqu'ici au n° de bulletin, a été remplacé par un n° incrémentiel afin de gérer les cas des salariés ayant plusieurs matricules, qui sont donc rassemblés en DSN dans un même bloc 30-Salarié. En effet, ces salariés pouvaient potentiellement avoir plusieurs blocs 50-Versement avec le même n° de versement (01) pour la même date de versement, ce qui est interdit par le cahier des charges DSN.

Lors de la création d'une DSN, sur le 3ème plan, on sélectionne le ou les bordereaux de versement à inclure dans la DSN. Par défaut, tous les bordereaux ayant comme mois d'émission celui choisi pour la DSN à créer sont présélectionnés. Sauf si on a demandé à créer une DSN Phase 2, car dans ce cas il n'y a que les bordereaux destinés à l'URSSAF qui sont présélectionnés.
C'est cette présélection qui fonctionnait mal : seuls les bordereaux URSSAF affichés sur la première page de la table présentant tous ces bordereaux étaient présélectionnés par défaut. Ceux des pages suivantes ne l'étaient pas. 

Les conditions de génération d'une DSN mensuelle dite "à zéro" ont été revues afin de ne pas en créer lorsque l'événement générateur est trop ancien.
Rappel : une DSN mensuelle "à zéro" est créée lorsqu'on prépare une DSN événementielle (Arrêt de travail ou Fin de contrat) et que cet événement a une date postérieure au mois suivant la dernière DSN mensuelle générée. Par exemple, préparation d'une DSN Arrêt de travail ayant une date de dernier jour travaillé sur mars, alors que la DSN mensuelle de février n'a pas encore été faite). Une DSN mensuelle "à zéro" contient l'ensemble des salariés, avec des valeurs nulles sur tous les blocs 51, 78, 79 et 81 obligatoires, hormis pour le(s) salarié(s) concerné(s) par la DSN événementielle en cours de création (ou par une DSN événementielle préparée antérieurement et elle aussi postérieure à la dernière DSN mensuelle).
Désormais, seuls les événements intervenant dans les 3 mois précédant le mois de paye courant généreront éventuellement une DSN "à zéro". Et de plus, si une DSN d'un mois postérieur au mois M-1 recherché existe, il n'y a pas non plus création d'une DSN Mensuelle "à zéro".
Enfin, si les conditions de génération d'une DSN mensuelle "à zéro" sont remplies, une confirmation est désormais demandée à l'utilisateur afin qu'il confirme ou infirme la création de cette DSN mensuelle "à zéro", avec possibilité d'annuler simplement la création DSN en cours pour attendre par exemple la préparation de la DSN mensuelle manquante afin d'éviter l'émission d'une DSN "à zéro".

Lors de la création d'une DSN, les blocs 79 ou 81 pour lesquels aucun bloc 78 "père" n'avaient été ajoutés n'étaient pas eux même ajoutés. Cela avait donc pour effet, par exemple, de ne pas ajouter de bloc 79 code 02 (Montant du SMIC pour le calcul du CICE), dès lors que le bloc 78 code 12 (Assiette du CICE) était absent (cas d'un salarié ayant une rémunération au-delà de 2,5 SMIC). Désormais, les blocs 78 sont dans ce cas créés avec une valeur nulle afin de pouvoir y rattacher les blocs 79 ou 81 qui en dépendent.
Cette modification a nécessité une modification assez importante de la méthode de calcul et ajout des différents blocs d'une DSN. Aussi, l'ancienne méthode de calcul a été conservée afin de pouvoir éventuellement faire des DSN avec cette ancienne méthode. Pour cela, il suffit de tenir enfoncée la touche Alt Gr (ou Ctrl + Alt) lors du clic sur le bouton d'appel de l'assistant de création d'un nouvelle DSN. Un message demandera alors quelle méthode il faut utiliser. L'ancienne méthode ne sera désormais plus maintenue, il ne faut donc l'utiliser que sur demande explicite du prestataire en charge de la maintenance du progiciel.

L'édition de contrôle de la DSN a été détaillée par rapport aux blocs 79 ou 81 pouvant être rattachés à différents types de blocs 78.

Lors de la création d'une DSN, le code retraite complémentaire porté sur le bloc 71 (RETA ou RETC) est déterminé automatiquement en fonction du code statut catégoriel retraite complémentaire :
 - RETC si le code statut catégoriel retraite est 01-cadre (article 4 et 4bis) ou 02-extension cadre pour retraite
 - RETA si le code statut catégoriel retraite est 04-non cadre
Or, il y a certains VRP non cadres qui cotisent à l'AGIRC. Cette règle a donc été aménagée ainsi :
 - RETC si le code statut est 01-cadre (article 4 et 4bis) ou 02-extension cadre pour retraite
   ou (Statut catégoriel retraite est 04-non cadre et Statut conventionnel est 04-autres cadres et
        Code complément PCS-ESE est 06-Représentant exclusif ou 07-représentant multicartes)
 - sinon RETA si le code statut catégoriel retraite est 04-non cadre

Le regroupement des cotisations dans les lignes du bordereau de versement DSN a été détaillé afin de préciser, s'il y a lieu de le faire, la base de cotisation (Bloc 78) pour laquelle la cotisation (Bloc 81) a été calculée dans la DSN temporaire servant à créer le bordereau de versement.

Si l'on sélectionne un établissement concerné par l'OPS, la zone Collecte les cotisations est initialisée. Lors du défilement de la table des établissements, si l'un des établissements affichés n'est pas concerné par l'OPS, alors, cette zone est remise à blanc mais l'établissement sélectionné reste toujours le même.

Les arrêts qui ont été préalablement envoyés en DSN événementielle, sont envoyés dans les DSN mensuelles suivantes, jusqu'à la reprise du salarié. Désormais, en cas de nouveau contrat, avec une date d'entrée postérieure donc au dernier jour travaillé indiqué dans l'arrêt, celui-ci n'est plus reporté dans la DSN Mensuelle. C'est la fin du contrat précédent qui a mis fin implictement à l'arrêt sans qu'aucune date de reprise n'ait été indiquée.

La valeur V01X11 ne s'affichait pas dans la rubrique S10.G01.00.011 des déclarations N4DS faites avec cette norme (DADS-U, DNAC-AE). Cela pouvait également provoquer la suppression de cette valeur du fichier final si on modifiait une autre valeur de cette structure.

Une optimisation a été effectuée sur l'initialisation des salariés à traiter dans la déclaration afin de n'initialiser que les salariés des sociétés à traiter.
De plus, l'ordre de parcours de ces salariés a été modifié. Désormais les salariés sont initialisés dans l'ordre des matricules, ce qui a pour effet, pour les salariés ayant plusieurs contrats (plusieurs matricules avec un même n° SS) de toujours initialiser les informations du bloc 30-Individu à partir du même matricule, le premier lu (dans l'ordre des matricules donc).

Depuis la version 9, la zone Code Risque du code accident du travail peut être alimentée à partir d'une nomenclature externe. Or, les codes risques disponibles dans cette nomenclature externe incluent le code bureau : on a un seul code constitué de 5 ou 6 caractères, le 6ème étant la lettre B dans le cas d'un code risque spécifique "Bureau".
Dans LDPaye, les deux zones dont on disposait jusqu'alors, Code risque et Code bureau ont donc été fusionnées en une seule.
Une migration des codes risques existants est effectuée à la 1ère ouverture du dossier faisant suite à l'installation de cette correction.

Sur l'état de contrôle de la DSN, la zone intitulée Cot P Ret faisait apparaitre jusque-là les montants déclarés en bloc 79 sous le code 03-Contributions patronales à des régimes complémentaires de retraite. Or, cette zone n'était quasiment jamais renseignée, car elle correspond à la fraction des cotisations patronales de retraite complémentaire qui excède la part patronale prévue par la convention collective nationale du 14/03/1947 et l'accord du 08/12/1961.
Du coup, il a été décidé de la remplacer par la zone intitulée Cot P Ret S qui fait apparaître les montants déclarés en bloc 79 sous le code 05-Contributions patronales destinées au financement des prestations de retraite supplémentaire (code utilisé dès lors qu'un contrat de prévoyance est marqué comme étant de type Retraite supplémentaire).
Les éventuels montants déclarés en bloc 79 sous le code 03 apparaissent le cas échéant en dessous du tableau (comme apparaissait jusque-là ceux déclarés en bloc 79 sous le code 05).

Sur l'écran de saisie des informations de fin de contrat, les contrôles appliqués sur les dates du préavis ont été allégés. Ils correspondent désormais exactement à ce qui est décrit dans le cahier technique N4DS V01X11 (CCH-11 à CCH-16 sur la date de début de rpéavis, CCH-11 à CCH-15 sur la date de fin de préavis, CCH-11 sur la date de notification de la rupture du contrat, CCH-13 sur la date d'engagement de la procédure de licenciement).
Les différences par rapport à ce qui été fait auparavant sont :

• le contrôle CCH-16 : Pour le code type réalisation et paiement du préavis (S48.G55.05.001) '03' (préavis non effectué et non payé), la valeur de cette rubrique doit être inférieure ou égale à la date de fin de contrat de travail (S48.G55.00.002.002), sauf si le Code motif de la rupture contrat de travail (S48.G55.00.001) est égal à '91' (licenciement pour inaptitude physique d'origine non professionnelle) ou '92' (licenciement pour inaptitude physique d'origine professionnelle). étgait opéré à tort sur la date de fin de préavis alors que dans le cahier technique, il porte sur la date de début de préavis.
• le contrôle CCH-15 : Pour les types de préavis 01 et 02, une des dates de fin de préavis S48.G55.05.002.002 doit correspondre à la date de fin de contrat de travail S48.G55.00.002.002 opéré sur la date de fin de préavis était mal réalisé. On effectuait ce contrôle sur toutes les dates de fin de préavis sans se limiter aux types 01 et 02. De plus, ce contrôle n'était fait que sur les 2 premières lignes de préavis : la 3ème ligne (rarement utilisée) était ignorée.

Suite au correctif V9.00 niveau 200, les contrats de prévoyance étaient créé sans code société. Ces contrats n'apparaissent donc pas dans la liste des contrats.
Pour récupérer ces contrats sans code société, il faut charger la zone COSO du fichier PECPRE avec la valeur correspondant au code interne de la société (entre guillements), via un scénario de modification de données par lot, avec la sélection PECPRE.COSO="". Tous les contrats ainsi créés seront ainsi affectés à la société en question.

Le fichier des nomenclatures externe des pays contient des libellés de pays qui peuvent être composés de plus de 38 caractères, 38 étant la taille maximale autorisée en DADS-U. Ceux-ci sont donc désormais tronqués dans la DADS-U (exemple : "GB - ROYAUME-UNI DE GRANDE-BRETAGNE ET D'IRLANDE DU NORD").

Afin de permettre de créer des bordereaux de versement pour l'AGIRC-ARRCO sans qu'ils ne génèrent de prélèvement SEPA, le contrôle sur les modes de paiement a été assoupli. Pour les organismes de retraite, il est donc désormais possible d'inscrire un autre mode de paiement que le seul autorisé pour ce type d'OPS (05-Prélèvement SEPA). Un avertissement signale alors que le mode de paiement n'est toutefois pas attendu par l'organisme.
Note : les blocs 20-Versement seront tout de même créés dans la DSN pour les caisses de retraite avec les modes de paiement Chèque ou Virement, mais l'AGIRC-ARRCO les ignore (voir remarque page 42 du cahier d'aide à la codification AGIRC ARRCO V4.3).

Dans DSN-VAL, un contrôle interdit de déclarer un code risque AT égal à 999ZZ avec un taux AT différent de 0. Cependant, pour que le calcul du bulletin soit correct, ce taux AT doit être défini. Dans le cas d'un code risque à 999ZZ, le taux AT n'est donc désormais plus déclaré, quelle que soit la valeur de taux inscrite dans la table des codes AT.

Lors de la migration d'une paye V8.00 vers une V9.00, la rubrique spécialisée pour le prorata du plafond SS (indiquée dans la constante générale *PR26E) était récupérée sans les zéros à gauche si cette rubrique était sur 3 caractères ou moins.
Désormais, la rubrique est complétée avec des zéros à gauche pour faire 4 caractères.

Suite aux changements opérés sur la page des référentiels externes du site Net-entreprises, la fonction de téléchargement des nomenclatures ne fonctionnait plus.
Désormais, la fonction de téléchargement se base sur le fichier ZIP contenant l'ensemble des référentiels. Il est possible (au cas où la page venait à nouveau à être modifiée) d'appeler la procédure de décompresssion (et de renommage) manuellement en exécutant la procédure zDécompresserZipNomenclature depuis un MCU par exemple. Cette fonction demandera alors le chemin du fichier ZIP, qu'il aura fallu télécharger manuellement), pour qu'il soit décompressé dans le répertoire Nomenclature.

Plusieurs corrections ont été apportées pour ce qui est de la rubrique 06.009-Effectif moyen de l'entreprise au 31 décembre :

• Cet effectif n'était pas calculé dans une DSN Néant. Or, même sur un établissement déclaré comme Néant (donc sans salarié), il faut déclarer l'effectif de l'entreprise.
• Lorsque l'effectif calculé était nul, on ne renseignait pas cette rubrique 06.009. Or, pour une DSN mensuelle de décembre, cette rubrique est obligatoire. Il faut la fournir même si sa valeur est nulle.
• Plus important : le calcul de l'effectif qui était effectué n'était pas le bon. Expliquons-nous : l'an dernier, il avait été demandé de renseigner les champs Effectifs de la DSN selon les mêmes règles que ce qui était fait en DUCS, de façon à ne pas provoquer d'écarts entre ces données déclarées en DSN et celles envoyées au travers du tableau récapitulatif URSSAF (TR). Du coup, ce qui avait été envoyé comme effectif était l'effectif calculé au 31/12/2015, et non l'effectif moyen sur l'année 2015.
  Cette année, suite à cette correction, c'est bien l'effectif moyen 2016 qui va être calculé, selon des règles qui sont très proches de celles édictées sur le site de l'URSSAF (voir détail ci-après).

Enfin, au passage, une petite modification a été faite sur l'état de contrôle d'une DSN car cet effectif entreprise, qui est présenté au niveau du total établissement, au bas de la première colonne à gauche, était surchargé par le SIRET de l'établissement (mauvais cadrage des champs). Ce cadrage a été revu, et l'effectif a été mis en gras pour qu'il soit davantage visible.

Règle de calcul de l'effectif moyen de l'entreprise au 31/12

On commence par calculer l'effectif au dernier jour de chaque mois de l'année. Pour cela, on ne prend que les salariés présents au dernier jour, mais en excluant :
 - Les salariés en fonction de leur type de contrat :
   à partir de la situation de présence au dernier jour du mois, on prend l'option Inclus dans l'effectif URSSAF  et le code type de contrat
   Si l'option Inclus dans l'effectif URSSAF est à la valeur 01-Selon le type de contrat
     Le salarié est exclu si son type de contrat correspond à une nature de contrat DSN 29, 80, 81, 89, 90
     ou un dispositif politique DSN 21, 41, 42, 50, 51, 61, 64, 65, 71, 81,
   Si l'option Inclus dans l'effectif URSSAF est à 04-Inclus sur BRC uniquement ou 05-Exclu sur BRC et TR, le salarié est exclu
 - Les salariés en CDD qui remplacement un autre salarié (Motif de recours à un CDD égal à 01) 
A partir de là, chaque salarié est décompté pour une valeur de 1 s'il est à temps plein, au prorata de son taux temps partiel s'il est à temps partiel.
Pour les salariés en CDD, on décompte chaque mois une valeur qui est fonction du nombre de mois de présence parmi les 12 mois qui précédent
le mois pour lequel on effectue le calcul. Un salarié entré en juillet 2016 est décompté 0 sur juillet, 1/12 sur août, 2/12ème sur septembre...
Cette règle peut se cumuler avec le taux de temps partiel.
Une fois l'effectif calculé mensuellement de la sorte pour chacun des 12 mois de l'année, on divise la somme de ces 12 valeurs par le nombre de mois où l'on a un effectif non nul. Le résultat est arrondi à l'entier inférieur.

Informations complémentaires : si l'on veut comprendre le calcul exact qui est réalisé, on peut tenir la touche Control enfoncée durant toute la phase de création de la DSN. Une fenêtre de trace (avec fond jaune) affiche alors le détail, salarié par salarié et mois par mois, de ce calcul d'effectif. On peut ensuite copier le contenu de cette fenêtre de trace dans une feuille Excel pour vérifier les calculs effectués.

Afin de faire face aux problèmes rencontrés par le site Net-entreprises lors des trop grosses montées en charge, les modifications suivantes ont été apportées :
- Mise en place d'un ping-timeout de 1 minute (au lieu de 3 auparavant). Cela permet d'afficher plus rapidement un message d'erreur lorsque le site n'est pas opérationnel.
- Arrêt du polling (récupération des retours) lorsqu'une erreur 500 (erreur interne au site) est renvoyée par le site de Net-entreprises.

D'autre part, il est désormais possible d'associer un identifiant de flux DSN à une déclaration. Cela est utile lorsqu'on a déposé une déclaration sans passer par l'API ou si le dépôt via l'API n'a pas permis de récupérer un identifiant de flux.
Pour indiquer l'identifiant de flux, il faut sélectionner la déclaration et cliquer sur le bouton Modifier en maintenant la touche Alt Gr enfoncée (ou les touches Ctrl + Alt). Une nouvelle fenêtre s'ouvre. Il faut indiquer l'identifiant de flux ainsi que l'identifiant DSN utilisé pour déposer la déclaration.

Enfin, un indicateur permet de savoir lorsqu'un nouveau retour a été récupéré pour une déclaration. Le statut de la déclaration est suffixé d'une étoile. Lorsque tous les retours ont été consultés, cette étoile disparait. 

Lorsqu'on copiait une cotisation avec des paramètres DSN, le fait d'afficher la fenêtre des paramètres DSN avant de changer d'écran (par exemple, l'écran des cumuls) dépositionnait la cotisation courante. On se retrouvait alors à modifier dans le second écran la première cotisation de la liste.

Le calcul des bordereaux DSN (hors bordereaux mensuels) omettait les bulletins liés à un contrat s'étant terminé dans la période du bordereau (trimestre, semestre, année), avec une fin de contrat antérieure au mois de paye du bulletin. Exemple : Le bulletin de Février, lié au contrat qui s'est terminé en Janvier, n'était pas cumulé dans le bordereau DSN du 1er Trimestre.

Pour optimiser les temps de calcul dans les configurations où l'on a des fichiers très volumineux du fait d'un grand nombre de bulletins, LDPaye est censé refermer systématiquement les 4 plus gros fichiers (Eléments variables, Lignes de bulletins, Cumuls, Cumuls cotisation) après chaque utilisation.
Or, des tests ont montré que certains fichiers restaient ouverts :
 - après la création d'une DSN, les fichiers Eléments variables et Lignes de bulletin restaient ouverts
  (c'était un oubli pour les éléments variables, du fait de l'utilisation d'une requête SQL pour les lignes de bulletins)
 - après un calcul de bulletin, le fichier des lignes de bulletins restait ouvert là aussi.
   Cela était dû à la suppression des éléments variables en début de calcul : le contrôle d'intégrité faisait que le fichier des lignes de bulletins était 
   ouvert implicitement, sans que l'on puisse forcer cette fermeture. On a donc débranché le contrôle d'intégrité référentielle lors de la suppression
   des éléments variables, en gérant manuellement la suppression des commentaires éventuellement liés à l'élément supprimé.
Avec ces 2 optimisations, on devrait avoir une amélioration sensible des performances lors de calculs en simultané sur de grosses bases de données.

Si un ou plusieurs paramètres de code 81.024 existent (paramètre 81.024 qui était défini en Phase 2, mais qui a disparu du cahier technique Phase 3), cela provoque une erreur lors de la création de la DSN mensuelle avec le message Erreur à la ligne 91 du traitement Méthode GénérerBlocsParamétrés. Elément inexistant dans le tableau associatif.
De plus ces paramétrages 81.024 n'étaient pas visibles dans la liste des paramètres DSN ; on ne pouvait donc pas les supprimer.

Le code Option et code population du contrat de prévoyance n'apparaissait pas dans l'édition de contrôle de la DADSU, ce qui pouvait rendre difficile le contrôle du total qui sommait les valeurs uniquement à référence égale.

La zone "établissement payeur" n'était pas accessible dans la fenêtre de lien entre les OPS de type MSA et les établissements. Cela empêchait donc d'établir directement un bordereau MSA payé par un autre établissement. La modification de l'établissement payeur était toutefois possible, après création, en modifiant le bordereau.

La création d'un bordereau DSN ne propose désormais plus par défaut les établissements suspendus avant le début de la période à déclarer (mois courant si déclaration mensuelle, 1er mois du trimestre pour une déclaration trimestrielle...).

Lors du calcul du SMIC pour la réduction Fillon, ou pour le CICE, si le paramétrage porte sur un cumul en heures, celui-ci est multiplié par le taux du SMIC. Ce taux du SMIC ne tenait pas compte de l'historique des valeurs du plan de paye. Désormais la valeur retenue sera celle éventuellement historisée pour le mois de fin de la période déclarée (Rappel : les déclinaisons par société ou établissement étaient et sont toujours ignorées dans ce calcul).

L'installation et la mise à jour de DSN-VAL est désormais plus simple grâce à un nouvel assistant.
Cet assistant est disponible via la fenêtre de création du fichier DSN.
Il permet d'installer automatiquement la bonne version de l'outil de contrôle en fonction de la norme du fichier utilisé et de la version de Java installée sur le poste.
Il permet aussi d'installer manuellement l'outil de contrôle depuis une URL ou depuis un fichier ZIP.

L'option "Paiement par virement hors DSN" (historiquement utilisée en phase 2, avant l'ajout du mode de règlement dans le bloc 20, en phase 3) n'avait pas été supprimé de la liste des banques pouvant être sélectionnées dans la fenêtre de modification du bordereau DSN.

La rubrique DSN 30.023 - Cumul emploi retraite était créé à tort dans les DSN événementielles.

Lors de l'extraction des rubriques de rappel d'activité (code rappel d'activité renseigné sur la rubrique et dates saisies en élément variable sans aucun jour commun avec la période de la déclaration), si la rubrique est de type Retenue, le nombre extrait était inversé par rapport à celui de la ligne bulletin, alors que ce nombre avait déjà été inversé dans la ligne bulletin en question de par son sens Retenue.

Dans certains cas, la valeur "-1" était enregistrée à tort dans la zone Prime ou rappel d'activité des rubriques, ce qui pouvait générer des rappels d'activités en DSN si des dates antérieures au mois de paye courant étaient saisies sur l'élément variable avec ces rubriques.
Un outil est exécuté automatiquement à la première ouverture du dossier pour corriger les fiches rubriques concernées.

Dans une société qui peut effectuer des déclarations au régime général et au régime agricole, LDPaye filtre automatiquement les identifiants DSN et ne propose que ceux qui correspondent au point de dépôt de la déclaration.
Pour un point de dépôt 01 (Net-entreprise), on ne liste que les identifiants ayant un code service 25 (DSN régime général).
Pour un point de dépôt 02 (MSA), on ne liste que les identifiants ayant un code service 26 (DSN régime agricole).

Dans la fenêtre de gestion des paramètres DSN, les éventuels paramètres non reconnus (c'est à dire associés à bloc inconnu en DSN ou à un type inconnu pour le bloc en question) sont désormais affichés, tout au bas de la liste, en rouge. Avec en sus un message d'avertissement à l'ouverture de la fenêtre signalant la présence de paramètres non reconnus et invitant à les supprimer.

Remarque complémentaire : ce cas de figure est très improbable. Pour que le paramètre existe dans la table, c'est qu'il fait référence à un bloc ou un type qui ont existé à un moment donné dans la norme DSN, et donc dans les fichiers de définition de la norme utilisés par LDPaye (DNGROU et PAYTAB notamment). Or, en principe, dans ces fichiers, on ne supprime jamais aucun enregistrement ; on se contente de marquer les enregistrements comme Supprimé en cas de disparition d'un élément lors d'une évolution de la norme, justement pour continuer à avoir accès à tous les éléments dans la saisie des paramètres.

Dans les bilans DSN, les boutons de parcours permettaient de naviguer dans la table des déclarations mais n'affichaient pas les retours de la déclaration sélectionnée. On affichait tout le temps les retours de la déclaration initiale.

La rubrique S48.G55.15.001 attend les codes RETC, RETA, ou 9000, alors qu'y était toujours inscrit les codes IRC (c'était toléré jusqu'à fin 2016, norme V01X10, mais plus en norme V01X11).
De ce fait, ces codes IRC ont été supprimés de la fenêtre de saisie des informations de fin de contrat, car ils ne sont plus du tout utilisés.

D'après le paragraphe 5.2 du cahier technique DSN (version 2017.1), il n'est plus nécessaire d'envoyer tous les salariés (à 0) dans les DSN mensuelles créées automatiquement sur le mois précédent une DSN événementielle (si la DSN événementielle intervient avant la DSN mensuelle du mois précédent). Il ne faut indiquer dans cette DSN que les informations pour les salariés concernés. Désormais donc, seuls ce(s) salarié(s) est(sont) envoyé(s) dans cette DSN mensuelle.

Sur l'édition de la déclaration DSN, le nombre de blocs 30-Salarié et 50-Versement (correspondant à un bulletin) est désormais affiché en dessous des totaux établissement et généraux.

D'après les directives de déclaration DSN, il ne faut pas déclarer en DSN événementielle, les arrêts de type 08-Temps partiel thérapeutique.
Ces arrêts sont donc toujours à créer, mais ne peuvent plus générer de DSN événementielle. Ils sont par contre systématiquement ajoutés dans la 1ère DSN mensuelle qui suit leur ajout ou leur modification, ou si l'arrêt a au moins un jour en commun avec le mois déclaré dans la DSN mensuelle.

L'ajout d'un bloc dans une DSN provoque le rechargement des blocs dans la partie gauche de l'écran. Cela avait pour effet de se repositionner au début de l'envoi. Désormais le bloc sélectionné après rechargement correspond à celui qui vient d'être ajouté.

Ce correctif fait suite au correctif n°246 - API DSN - LES IDENTIFIANTS DSN SONT FILTRES EN FONCTION DU POINT DE DEPOT.
Dans certaines fenêtres, aucun identifiant n'était affiché. Désormais, soit tous les identifiants sont affichés, soit seulement ceux liés au dépôt.

Lorsqu'un retour de nature 21 avait le statut KO, pour indiquer par exemple la mise en attente de la déclaration, celle-ci était signalée en anomalie. La réception d'un nouveau retour de nature 21 avec un statut OK ne faisait pas disparaitre cette anomalie, même si aucun autre retour n'était en erreur.
Cela était dû au fait que le retour 21 avec le statut OK ne remplaçait pas le retour 21 ayant le statut KO, et c'est donc le premier retour 21, celui ayant le statut KO, qui était pris en compte dans le statut de la déclaration. Désormais, on prend en compte le dernier retour reçu de nature 21 (KO ou OK) pour chaque déclaration. Quant aux nouveaux envois, on ne conserve que le dernier retour de nature 21.

Le paiement des cotisations URSSAF par un moyen de paiement autre que le prélèvement SEPA reste possible hors DSN. Pour cette raison, et aussi par compatibilité avec les anciennes versions de la norme, il est toujours possible de choisir un autre moyen de paiement que 05-Prélèvement SEPA (seul mode de paiement autorisé pour les URSSAF en DSN).
Dans ce cas, un message d'avertissement indique cette exception lors de la saisie du lien OPS/Etablissement ou lors de la modification du mode de paiement d'un bordereau, et le bloc de versement (bloc 20) correspondant n'est pas créé en DSN.

Les Attestations Employeur Rematérialisées (AER), émises par Pôle Emploi en retour d'une Attestation Employeur Dématérialisée (AED) sont désormais récupérées automatiquement au format PDF lorsque l'AED a été transmise par cet API-DSN. Il est ainsi possible de les consulter depuis la fenêtre de bilan des retours DSN.
Il est aussi possible de les voir depuis la GED du salarié, si l'option de récupération automatique des AER dans la GED a été activée dans la nouvelle fenêtre de paramètres accessible depuis la fenêtre d'envoi des DSN.

Lors de l'installation de l'outil DSN-VAL, un message d'erreur indique désormais si une valeur est mal renseignée (norme, version de java, URL de téléchargement ou chemin du fichier ZIP). De plus, si la version de Java n'est pas connue, on n'indique plus de message disant que la version est ?? bits.

Nous avons appris récemment du GIP-MDS que le bloc 78 code 10-Base brute fiscale n'était utile que pour la caisse de prévoyance-retraite du personnel de la SNCF. En conséquence, cette base n'est plus nécessaire pour les entreprises utilisant LDPaye, et cette base a donc été désactivée au sein des paramètres nécessaires à l'établissement de la DSN. Ces paramètres, même si vous ne les supprimez pas, sont désormais systématiquement ignorés.
L'édition de contrôle a également été adaptée pour ne plus afficher cette valeur dans la partie principale de l'état.

Dans la fenêtre principale de gestion des salariés ainsi que dans la fenêtre de calcul des bulletins, 2 colonnes ont été ajoutées dans la table pour le département et la commune de naissance, après les pays de naissance et de nationalité.

Les contrôles sur le mode de paiement du bordereau de versement DSN n'étaient pas les mêmes que ceux réalisés lors de l'établissement du lien entre l'établissement et l'OPS.

Dans la DSN Mensuelle, il ne doit pas y avoir plusieurs blocs de versements pour un même salarié, avec la même date de versement. Le bulletin d'intéressement, qui a une date de versement généralement à la fin du mois, comme le bulletin mensuel, a donc été cumulé en DSN avec le 1er bulletin du mois.
Toutefois, dans la procédure de visualisation d'un bulletin, sur l'onglet DSN, on n'affiche, même dans ce cas de figure, que le seul bulletin courant et non pas le cumul (Bulletin paye + bulletin intéressement émis dans le même mois).

Des améliorations ont été apportées :
 - d'une part dans la procédure d'export d'une DSN au format Excel
 - d'autre part dans la procédure de reprise de données depuis Excel.
L'objectif est de pouvoir facilement importer dans LDPaye des données salariés et situations à partir d'un fichier DSN Phase 3.
Cela est décrit en détail dans la note intitulée Reprise de données salariés depuis une DSN Phase 3 présente dans le carnet Documentation partagée.
La documentation Reprise de données depuis Excel a également fait l'objet d'une révision 4 à cette occasion.

Des blocs changements de contrats étaient générés en trop lors de la déclaration d'un nouveau contrat, si le contrat précédent (même salarié, mais n° de contrat ou date d'entrée différente) avait été déclaré en DSN (postérieur à la première déclaration DSN).

Les blocs "51 - Rémunération" de type "014 - Heures correspondant à du chômage sans rupture de contrat ou du chômage intempéries" ou "015 - Salaire moyen BTP" étaient imprimés avec de mauvais libellés.

Les cotisations liées à des conditions précédentes (historique) du contrat de prévoyance étaient ignorées si le changement de condition intervenait durant la période du bordereau (exemple : sur un bordereau au trimestre, une nouvelle condition du contrat de prévoyance est appliquée au 01/02, les cotisations de Janvier étaient ignorées lors de la création du bordereau du 1er trimestre).

Depuis la version 8, il est possible de personnaliser l'impression des bulletins de paye via des « points d'entrée » où l'on peut insérer du code Windev compilé dynamiquement.
Jusqu'alors, les points d'entrée proposés étaient les suivants : Ouverture de l'état,  Avant impression du haut de page, Avant impression d'une ligne rubrique ou cotisation, Avant impression d'une ligne commentaire, Avant impression du bas de page, Avant impression du complément de corps.
On a ajouté les points d'entrée :
- après impression d'une ligne rubrique ou cotisation,
- après impression d'une ligne commentaire,
- avant et après impression d'une ligne cotisation simplifiée (nouveau bloc en V9).

De plus, on peut désormais, dans tous les codes compilés dynamiquement, utiliser un tableau associatif nommé ftCH qui a été déclaré à cette fin dans l'état en tant que variable globale. Cela permet par exemple de charger des données dans le code d'ouverture de l'état, puis de réutiliser ces données dans les autres codes compilés, évitant ainsi de multiples relectures.

Une nouvelle option permet, lors de l'envoi des bulletins dans la GED, d'avoir 2 impressions successives de chaque bulletin, chacune avec une configuration d'impression différente, les 2 impressions étant fusionnées en 1 seul PDF de 2 pages donc.
On peut ainsi, par exemple, avoir une impression en français et une anglais (moyennant un fichier .WDES qui gère la traduction en anglais), ou une impression simplifiée et une impression détaillée.
Pour faire cela, il faut indiquer, en position 257-258, le code (à 2 chiffres) de la configuration de bulletin souhaitée pour la 2ème impression. Si ce code n'est pas renseigné, on a une seule impression comme auparavant.
Notez que la première impression se fait toujours avec la configuration choisie à l'écran au moment du lancement de l'impression vers la GED.
Si ce code est à la valeur **, on a une double impression, mais la 2ème impression se fait avec la même configuration que la première, celle choisie à l'écran. L'objectif est alors d'avoir une impression détaillée et une autre simplifiée, comme indiqué ci-après.
Pour le choix entre impression détaillée et simplifiée, on peut indiquer la lettre D=Détaillée ou S=Simplifiée
 - en position 259 pour la première impression
 - en position 260 pour la deuxième impression
Si dans ces deux positions 259 et 260, on trouve autre chose qu'une lettre D ou S, c'est la forme d'impression choisie à l'écran qui est utilisée.

Les retours URSSAF ayant des anomalies non-bloquantes sont récupérés avec le statut OK depuis Net-Entreprise.

Afin de mettre en valeur ces retours, LDPaye modifie le statut à KO s'il y a au moins une anomalie non-bloquante.

Lors de la restauration d'un dossier de paye ayant été sauvegardé en version 9 avec un niveau inférieur à 269, on avait une erreur de réindexation sur le fichier PEAFFI. Cette erreur était toutefois sans conséquence ; on pouvait poursuivre et la mini-migration V9.0*a à V9.00 se déroulait normalement dans la foulée.
Avec cette correction, il n'y a plus le message d'erreur lors de la réindexation faisant suite à la restauration.

Dans le cas d'un changement de contrat suite à la saisie d'un ancien n° de contrat dans la situation, le programme pouvait dans certains cas générer un changement de contrat chaque mois. A la suite de ce correctif, la première DSN calculée provoquera une dernière fois ce changement, il ne sera plus généré à partir du mois suivant.

LDPaye permet désormais de récupérer les retours 51 des organismes complémentaires.

Certains blocs 81-cotisation individuelle ayant une base renseignée, mais un montant de cotisation à zéro, n'étaient pas affichés individuellement, et la base n'était donc pas sommée.

Il est désormais possible de suspendre un identifiant DSN.
Le fait de suspendre désactive la récupération des retours automatiques via cet identifiant, mais n'empêche pas le dépôt de données via celui-ci. Visuellement, un identifiant suspendu apparaît en grisé et en italique.
Autre modification : pour la récupération des retours, LDPaye demande à récupérer, via l'API-DSN, tous les nouveaux retours disponibles depuis la date du dernier retour récupéré via l'identifiant. Désormais, si ce dernier retour a été récupéré depuis plus de trois mois, on demande seulement tous les retours ayant moins de trois mois.

Améliorations :

• L'analytique n'est désormais plus obligatoire. Si besoin, un code vide est créé.
• L'état Récapitulatif par salarié a été revu pour mettre en évidence les heures saisies des heures prévues ainsi que les jours fériés.
• Lorsqu'on est dans une fenêtre à choix multiple d'imputation, on peut désormais annuler la sélection.
• Dans la fenêtre d'initialisation des fiches, on peut désormais sélectionner une période de saisie ou une période de date à date.

Ce correctif fait suite à la correction 286 qui permet désormais de récupérer les retours 51 (Compte-rendu OC). A l'instar des retours de nature 50 (Accusé de réception OC), on peut avoir plusieurs retours de cette nature pour un même envoi. De ce fait, les retours 51 s'écrasaient mutuellement puisqu'on ne pouvait en stocker qu'un seul.
Désormais, on peut stocker plusieurs retours de nature 51 sans perdre les existants.

Plusieurs corrections et améliorations ont été faites concernant la déclaration des effectifs pour la CVAE, déclaration que l'on va faire pour la première fois sur la DSN d'avril 2017 :

• La période de référence proposée par défaut, quand on renseigne l'année pour laquelle on veut initialiser les effectifs, est bien la période de référence CVAE qui a été saisie dans la fiche Société. Ce n'est que si cette période n'a pas encore été saisie que la période est proposée égale à l'année civile, comme cela était le cas auparavant.
• La méthode de calcul des effectifs (bouton Initialiser) a été revue sur plusieurs points. Le principal est qu'auparavant, on ignorait les CDD de moins de 3 mois alors que ce ne sont que les CDD de moins d'un mois qu'il faut ignorer.
• Toujours pour ce calcul des effectifs, il est désormais possible d'obtenir une trace en tenant la touche Majuscule enfoncée lorsqu'on clique sur le bouton Initialiser. Cette trace donne la liste des salariés (Matricule et Nom) qui ont été décomptés dans chaque établissement, avec la durée en jours retenue dans chaque établissement, utile quand un même salarié a exercé une activité dans plusieurs établissements au cours de la période de référence pour affecter ce salarié sur l'établissement où cette durée est la plus grande. Cette trace liste aussi tous les contrats ayant été ignorés en raison d'une durée inférieure à 1 mois ou en raison d'un type de contrat devant être exclu (contrats de professionnalisation, d'apprentissage...).
• Dans la fenêtre de création d'une DSN, sur le plan Déclarations annexes, des messages d'avertissement ont été ajoutés si on oublie de cocher l'option Affectations fiscales alors qu'au moins l'un des établissements inclus dans la DSN est assujetti à la CVAE, ou si les effectifs d'un des établissements assujettis à la CVAE n'ont pas été saisis au préalable.

Dans certains cas rarissimes, il peut être utile de relancer l'outil de vérification des clés internes du fichier mémorisant le contenu des DSN, outil qui a pourtant été lancé à la première ouverture des dossiers suite à l'installation du niveau 113. Cet outil a donc été mis à disposition de manière invisible depuis la fenêtre de gestion des DSN. Pour le lancer, il suffit d'appuyer sur le raccourci clavier Alt-Gr F. Une confirmation est alors demandée à l'utilisateur avant de lancer véritablement l'outil.

2 corrections ont été apportées au niveau de la gestion des changements de contrats, toutes dans le cas où le changement a lieu sur la première situation du salarié (ou sur la situation en cours au démarrage de la DSN pour la société) :
- si la date d'entrée était antérieure à la date de début de la situation (cas d'une reprise de salarié par exemple), le changement n'était pas déclenché.
- la valeur indiquée dans le bloc changement était celle après modification, au lieu de celle avant modification.

2 boutons ont été ajoutés dans la fenêtre de gestion des constantes d'un salarié :
- le premier pour accéder à l'historique des valeurs du plan de paye, afin de faciliter la compréhension de la valeur utilisée dans un calcul de bulletin.
- le second permet désormais de réinitialiser l'historique des valeurs du plan de paye, pour le salarié, soit uniquement pour la constante sélectionnée, soit pour toutes les constantes, en choisissant le mois à partir duquel l'historique est impacté.
Cette nouvelle procédure permet donc d'initialiser les valeurs des constantes qui n'auraient pas été saisies avant l'historisation du mois en question (cas d'une reprise d'un salarié, avec recalcul des bulletins précédents par exemple).

Les constantes (salariés et générales) utilisées dans le code des fonctions personnalisées (sous la forme CS.XXXXXX ou CG.XXXXXX, où XXXXXX correspond au nom de la constante) tiennent désormais compte, lorsque la fonction personnalisée est appelée dans le calcul d'un bulletin, de la valeur éventuellement historisée pour le mois de calcul du bulletin.

Une erreur de doublon survenait en création de DSN si un ancien établissement ou un ancien n° de contrat avaient été saisis sur une situation, et que l'une des deux conditions ci-dessous était vérifiée :
 - saisie d'un n° de contrat postérieurement à une DSN d'un mois précédent,
 - création d'une nouvelle situation pour un changement d'établissement.

Correction :
- Si un pointage est modifié via le paramétrage de la tolérance et que ce paramétrage est à cheval sur deux jours, la date du pointage était mal interprétée.
- Il n'était plus possible d'ignorer un pointage.

LDPaye permet désormais de récupérer, via l'API-DSN, les retours de nature 20-Bilan d'identification des salariés ainsi que les retours de nature 80-Contrôles métier MSA issus de la MSA. 

De plus, les retours 51 sont mis en évidence s'ils contiennent des anomalies. Petit détail technique, on compte les anomalies du retour car le retour est récupéré comme étant toujours correct (OK).

Certains bilans en erreur n'étaient pas considérés comme lus après leur visualisation dans la fenêtre des bilans DSN.

Les rubriques 21 et 22 du bloc 30 de la DSN (respectivement Nombre d'enfants à charge et Statut à l'étranger au sens fiscal) pouvaient être renseignées sur des DSN événementielles alors qu'elles ne sont attendues que dans des DSN Mensuelles.

Depuis le niveau 294, il est possible d'inclure les cotisations retraites des salariés du régime général dans les bordereaux DSN à destination de la MSA, dans le cadre du rapprochement des adhésions AGIRC-ARRCO des entreprises. Il s'avère que dans certains cas, seules une partie des cotisations de ces salariés, l'ARRCO, est à réintégrer au bordereau MSA, les cotisations AGIRC continuant à être collectées par un autre organisme.
La case à cocher prévue au niveau 294 a donc été remplacée par une liste de choix permettant toutes les possibilités (à l'instar d'un OPS retraite).

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

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

 Corrections :
- LDPointage a été revu pour mieux gérer l'intégration des pointages dans un environnement multi-société. Les pointages issus de badges inconnus sont désormais associés à la bonne société si on fait un lien entre pointeuse et société. 

Jusqu'alors, quand on supprimait une société en demandant l'effacement des données de cette société au sein du répertoire, seule une partie de ces données était effacée. Grosso modo, toutes les données des salariés de cette société étaient effectivement effacées, mais une partie des données non liées aux salariés restaient présentes.
Désormais, un nettoyage beaucoup plus complet est réalisé, y compris dans les DSN (mais seuls les envois DSN composés uniquement de déclarations relatives à des sociétés supprimées sont effectivement supprimés ; les envois DSN composés de plusieurs déclarations, dont une au moins est relative à une société qui existe encore, ne sont pas supprimés).
Ne sont pas effacés (car trop complexe à réaliser) : les données du module DUCS-EDI, les fichiers TDS (en principe plus utilisés depuis longtemps), les données de la N4DS (DADS-U et AED).

D'autre part, cet effacement des données d'une société est désormais réalisé par des commandes SQL fichier par fichier alors qu'auparavant on supprimait les données salarié par salarié. Avec pour conséquence une suppression beaucoup plus rapide dès lors que le nombre de salariés est conséquent.

A la suite de l'introduction de la date de profondeur du calcul de paye dans le bloc 41-Changement de contrat (norme DSN Phase 3 Release 2017.1), depuis laquelle un bloc changement doit être créé pour chaque modification, même si plusieurs modifications interviennent à la même date, il a été précisé, dans les notes explicatives sur le site dsn-info.fr (et cela a été inclus au cahier technique de la norme DSN applicable en 2018), que cela ne s'applique pas aux changements des zones identifiantes, soit le n° de SIRET, le n° de contrat et la date de début du contrat. De plus, le bloc changement incluant ces modifications ne doit pas contenir de date de profondeur du calcul de paye. Les changements de ces zones, intervenant à la même date, ne sont donc plus désormais déclarés individuellement, mais dans un seul et même bloc, sans date de profondeur du calcul de paye.
Egalement, même si cela n'est pas très clair dans les documentations, il semblerait que l'ancien n° de contrat doit obligatoirement être renseigné lors d'un changement de SIRET, même si le n° de contrat reste inchangé. C'est ce qui est donc fait désormais.

Une erreur pouvait survenir à l'ouverture de la fenêtre de lien entre les OPS et les établissements (message de l'erreur : "Erreur à la ligne 14 du traitement Affichage d'une ligne de Table0. Vous avez appelé l'opérateur [] sur le champ TRET. L'indice spécifié [255] est invalide.") car une valeur 255 pouvait avoir été enregistrée à tort dans le fichier DNOPSL. Cette valeur survenait dans certains cas, après validation d'un lien entre un OPS autre que MSA ou retraite. Le souci a été identifié et corrigé.
Une modification automatique du fichier est réalisée à la première ouverture du dossier avec ce niveau de correctif pour corriger le fichier.

Corrections :
- Une version en cours de développement de LDTemps a été publiée avec le précédent correctif LDPaye. Celle-ci intégrait des fonctionnalités non achevées (mais fonctionnelles) au niveau de la fenêtre des journées types et des plages de pointages.
- Dans certains cas, les totaux de l'édition des fiches de présence étaient vides.

Amélioration :
- L'édition des fiches de présence a été revue. Elle permet désormais de sélectionner une période autre que la période de saisie. Des options de sélection des salariés ont été rajoutées.
- L'édition des fiches de présence depuis la liste des fiches de saisie passe désormais par la fenêtre de paramétrage de l'édition. Les paramètres de l'impression modifiés en passant par ce biais ne sont pas sauvegardés. Par contre, ils sont mémorisés le temps que la liste des fiches de saisie reste ouverte.

Corrections :
- Dans l'édition des pointages réels, le filtre sur les affectations ne fonctionnait plus.
- Dans l'édition des fiches de présence depuis la liste des fiches de saisie, l'ordre des cumuls en bas de page était modifié à partir de la seconde impression.
- Dans l'édition des fiches de présence, des journées pouvaient être affichées en doublon.

Il existe depuis longtemps une possibilité d'ouverture de session automatique dans LDPaye, permettant de court-circuiter la fenêtre initiale où l'on doit renseigner un code utilisateur et son mot de passe, et choisir le code de la société dans laquelle on veut ouvrir la session.
Pour cela, il faut utiliser en ligne de commande la syntaxe suivante :
   C:\Ldsystem\Program\Paye\LDPayV9.exe  XXX /U=Utilisateur:MotDePasse
où XXX est le code société à ouvrir, Utilisateur est le code utilisateur, MotDePasse est le mot de passe associé à cet utilisateur, le cas échéant.

L'inconvénient est que le mot de passe figurait donc en clair dans la ligne de commande. Si l'objectif était de programmer une tâche planifiée pour déclencher un scénario automatique quotidien dans LDPaye par exemple (en combinant la syntaxe ci-dessus avec l'option Fen permettant d'ouvrir LDPaye sur une fenêtre précise qui peut être celle exécutant un scénario d'export ou de mise à jour automatique de données), toute personne disposant des droits de gestion des tâches planifiées pouvait voir ce mot de passe.

Pour améliorer cela, une nouvelle option permet désormais d'inscrire le mot de passe sous une forme cryptée. Il faut pour cela spécifier le mot de passe entre accolades : { et }. Le cryptage à utiliser est le même que celui utilisé pour encoder le mot de passe de l'utilisateur de connexion à la base HFCS de LDPaye. Ce mot de passe sous sa forme cryptée peut être obtenu via la fenêtre de gestion des clés de nos applications internes, bouton Cryptage.
On peut aussi connaitre cette forme cryptée depuis la fenêtre de gestion des utilisateurs, en utilisant le raccourci clavier Ctrl K lorsqu'on est en modification d'une fiche utilisateur. Le mot de passe crypté est alors copié dans le presse-papier.

Nouvelle syntaxe :
   C:\Ldsystem\Program\Paye\LDPayV9.exe  XXX /U=Utilisateur:{MotDePasseCrypté}

Exemple :
   C:\Ldsystem\Program\Paye\LDPayV9.exe  LDZ /U=PAYE:{pQIuxg} /FEN="OUTICHG1(Nom de mon scenario)"

Une nouvelle fenêtre nommée OutiCodDyn permet d'exécuter du code source Windev présent dans un fichier texte. L'intérêt principal de cette fenêtre est de pouvoir déclencher un traitement quelconque dans LDPaye à partir d'une tâche planifiée.
Deux modes d'utilisation sont possibles pour cette fenêtre :
1) Appel sans aucun paramètre, pour tester un code source par exemple
   On doit alors indiquer, dans la fenêtre qui s'ouvre, le nom du fichier contenant le code source à exécuter, puis cliquer sur le bouton Exécuter.
   Les éventuelles erreurs s'affichent directement à l'écran. Si aucune erreur n'a été rencontrée, un message signale la fin d'exécution du source.
2) Appel en passant en 1er paramètre le nom complet du fichier contenant le code source à exécuter
  Dans ce mode, aucune interface graphique n'est proposée, sauf si on passe en 3ème paramètre la valeur Vrai.
  Pour connaitre le résultat de l'exécution, il faut aller consulter le fichier de trace qui est constitué. Ce fichier de trace se nomme par défaut
  Trace OutiCodeDyn AAAAMMJJ.log (où AAAAMMJJ est la date d'exécution) et il est enregistré dans le répertoire temporaire de LDPaye.
  Mais on peut aussi spécifier, en 2ème paramètre, le nom et l'emplacement du fichier trace désiré.
  La valeur spéciale "*SRC" de ce 2ème paramètre permet d'indiquer que le fichier de trace doit être créé au même emplacement et sous le même nom
  que le fichier contenant le code source à exécuter, en ne changeant que l'extension : .log.

Exemple d'appel pour une tâche planifiée:
   C:\Ldsystem\Program\Paye\LDPayV9.exe  LDZ /U=PAYE:{pQIuxg} /FEN="OUTICODDYN(C:\Ldsystem\Fichiers\Paye\Scenario\MonFichierSource.WDES, *SRC)"

Information complémentaire : dans le code source, il est possible de tracer certaines informations en faisant appel à la procédure xTracer qui attend 2 paramètres : le type d'information (chaine pouvant prendre les valeurs ERR, AVT ou INFO pour respectivement Erreur, Avertissement ou Information) et le message à tracer.

Corrections
- Dans l'édition des fiches de présence, les coches indiquant si une fiche était validée au niveau 1, au niveau 2 ou interfacée en paye affichaient une mauvaise valeur.
- Toujours dans l'édition des fiches de présence, si on affiche une période qui ne correspond pas à une période de saisie, on masque les coches de validation.
- On ne pouvait pas modifier le cycle type d'un cycle à cheval sur eux périodes de saisie (Saisie sur le mois complet).

Certains retours contiennent des informations qui ne sont pas gérées dans la fenêtre d'affichage des bilans. Cela peut être dû à une spécificité de l'organisme qui produit le retour ou suite à une évolution de la norme.
Dans certains cas, ces informations peuvent être importantes. On affiche donc désormais toutes les valeurs non gérées en fin de table, sous la rupture Inconnu.
Dans le même temps, les informations complémentaires issues des OC sont désormais affichées.

Correction :
- Il était impossible de valider une fiche au niveau 1 ou 2 si la fiche de la période suivante (pour le même salarié) existait et qu'un cycle était à cheval sur ses deux fiches.

Lors de l'ajout d'un document dans la GED, si le répertoire de destination contenait déjà un fichier ayant un nom identique, le déplacement ou la copie du fichier ne se faisait pas correctement. De plus, aucun message d'erreur ne prévenait l'utilisateur. Et pourtant, on considérait que le document était bien dans la GED.

De plus, lorsqu'un fichier a été affiché lors du survol, il n'était plus possible de supprimer le fichier. En effet, ce dernier était tenu par la zone d'affichage en survol et bloquait la suppression.

Lors de la saisie d'un code complément PCS-ESE à "07-représentant multicarte" ou "08-autre représentant", le programme basculait automatiquement l'organisme de base du salarié à la valeur "MSA" au lieu de "CCVRP".

Correction :
- Lors de l'initialisation depuis le pointage et du planning, les données du planning étaient forcément ignorées, qu'il y ait un pointage ou non. Désormais, on ignore les données du planning seulement s'il y a un pointage valide.

La déclaration CCSS a évolué et a changé de format.

L'option de menu permettant l'installation de la nouvelle version, livrée par les correctifs, a été conditionnée au fait que l'utilisateur soit "Administrateur de sécurité". Cela afin que seul un administrateur de sécurité lance ce processus d'installation. En revanche, l'installation de cette version lors de l'ouverture de session sur un dossier déjà migré dans cette nouvelle version reste possible par tous les utilisateurs (seul le lancement du processus a été conditionné).

Suite à l'installation de ce correctif, les utilisateurs auront la possibilité d'installer la version 9.50 dans leur répertoire des programmes.