Lors de l'initialisation d'un nouvel environnement, le fichier des utilisateurs n'étant pas encore créé lors de l'affichage de la fenêtre d'initialisation de la sécurité de l'environnement, l'appel à la fenêtre de sélection des utilisateurs (F4 ou clic sur le bouton) provoquait une erreur. Ce bouton a été supprimé dans ce cas, l'utilisateur saisi étant créé à la validation de la fenêtre (le libellé du champ a été modifié en conséquence).

Si un bulletin d'intéressement est calculé, il est possible depuis "plus d'options" de réactiver et/ou clore un bulletin d'intéressement en étant positionné dans la fenêtre de calcul des bulletins mensuels (donc sans passer par la fenêtre des calculs des bulletins d'intéressement). Dans ce cas, le basculement des cumuls lors de la clôture du bulletin d'intéressement (depuis la fenêtre de calcul des bulletins mensuels) ne s'effectuait pas correctement, tous les cumuls étaient généralement remis à 0.

Mise à disposition des modifications relative à la publication de la norme N4DS V01X13 (pour les DADS-U éventuelles de 2018, ou les DNAC à partir de 2019).

Les connexions des fichiers LDPlanning ont été revues afin d'être compatibles à la version 3.90 de LDPlanning.
La connexion à une version antérieur de LDPlanning reste possible.

Suite à la parution de la fiche 1850, une modification a été faite dans le calcul du PAS : si l'assiette est négative, elle est ramenée à zéro de façon à ne jamais engendrer de remboursement de PAS (en dehors des régularisations de PAS qui sont gérées par des cotisations spécifiques, faisant appel à un code calcul autre que PS).

Par ailleurs, en cas d'avance sur paye, une modification a été faite pour gérer l'impact de cette avance sur paye sur le net à payer avant prélèvement. Auparavant, l'avance sur paye était ajoutée intégralement au net à payer avant prélèvement, de telle sorte que la différence (Net à payer avant prélèvement - Net à payer) reste toujours égale au montant du prélèvement. Désormais, ce n'est que la part de l'avance qui est supérieure au montant du prélèvement qui est ajoutée au net à payer avant prélèvement. On est ainsi plus « juste » (même si c'est difficilement compréhensible dans les deux cas).
Exemple 1 : Net à payer de -54,55 incluant un montant PAS de 64,39
Auparavant, on avait une avance sur paye de 54,55, un net à payer avant prélèvement de 64,39 et un net à payer à 0 (du fait de l'avance).
Désormais, on a une avance sur paye de 54,55, un net à payer avant prélèvement de 9,84 et un net à payer à 0. La valeur 9,84 correspond à 64,39-54-55 ; c'est la valeur qu'on aurait observée s'il n'y avait pas eu l'avance sur paye.
Exemple 2 : Net à payer de -154,55 incluant un montant PAS de 64,39
Auparavant, on avait une avance sur paye de 154,55, un net à payer avant prélèvement de 64,39 et un net à payer à 0 (du fait de l'avance).
Désormais, on a une avance sur paye de 154,55, un net à payer avant prélèvement de 0 et un net à payer à 0. En effet, en l'absence de PAS, le net à payer aurait quand même était négatif et donc ramené à zéro par l'avance.

Un conditionnement sur le numéro du bulletin a été ajouté dans la liste des conditionnements possibles sur les rubriques, cotisations, et lignes de bordereau. Ce type de conditionnement peut s'avérer utile pour différencier un calcul fait sur le bulletin d'intéressement (n° de bulletin = 0) d'un calcul fait sur un bulletin de salaire mensuel (n° de bulletin >= 1), ou pour ne pas calculer 2 fois le même élément dans le mois (en conditionnant l'élément uniquement sur le 1er bulletin).

Sur une installation en HyperFile C/S uniquement, à la suite de la migration de l'environnement de la version 9.50 sécurisée en version 9.60, le programme détectait à chaque lancement de l'application que les fichiers étaient encore en version 9.50. Cela était dû à un problème de suppression des fichiers PAYENVS.FIC et PAYENVS.NDX de la base des fichiers d'environnement. Si possible, Le fichier PAYENVS peut être supprimé manuellement depuis le centre de contrôle (cela supprimera également son index). Sinon, le fait de répondre Oui entraine une nouvelle migration du fichier PAYENVS en PAYENV (et donc une perte des éventuels changements de mots de passe de sauvegarde ou de paramètres de sécurité de l'environnement, qui ont pu être fait après la précédente migration), mais ne modifie pas les autres fichiers de l'environnement. Cela n'a donc pas d'impact sur la migration si elle vient d'être faite.
Une fois ce correctif installé, la migration sera proposée une dernière fois afin de supprimer finalement ces fichiers correctement.

Dans certains cas, les retours 31 contiennent des messages à l'attention de l'utilisateur dans les anomalies. La présence de ces messages était considérée comme une anomalie bloquante.
Désormais, le compte-rendu est considéré en anomalie, mais un bouton dans la fenêtre Bilan DSN permet d'indiquer que les anomalies non-bloquantes ont été lues. Dans ce cas, le retour n'est plus considéré en anomalie.
Une deuxième correction a été apportée sur les accusés de réception OC (nature 50). Dans certains cas, le statut du retour est EN COURS. Ce statut n'était pas géré par LDPaye et était donc présenté à tort comme une anomalie. Désormais, on considère ce statut comme un statut « valide » et on ne signale plus d'anomalie.

Dans certains cas, le calcul d'une DSN (que ce soit pour la DSN elle-même, ou pour la visualisation d'un bulletin ou le calcul d'un bordereau de versement DSN) pouvait provoquer une erreur du type
Erreur à la ligne 63 du traitement Méthode RechercherAjouterBloc78Prévoyance. L'objet dynamique 'MonBloc70' n'a pas encore été alloué.
Ce message semblait survenir notamment lorsqu'un salarié inclus dans une DSN avait plusieurs affiliations (en-cours ou radiées) à des contrats de prévoyances et que ces contrats étaient paramétrés sur une même cotisation (pour alimentation de la base par exemple).

Une date de sélection a été ajoutée dans la fenêtre de création des DSN fin de contrat, pour n'afficher que les salariés partis à partir de cette date là (pour limiter le nombre de salariés affichés). Par défaut, cette date est initialisée au 1er jour du 2ème mois qui précède le mois de paye en cours.
Exemple : mois de paye en cours est octobre 2018 : le système affiche par défaut toutes les fins de contrats survenues depuis le 01/08/2018.
Une nouvelle colonne a également été ajoutée afin de stipuler si une DSN fin de contrat existe (et non mise à la corbeille) pour chacune des fins de contrat affichées.

Une correction a été apportée dans la fenêtre de gestion des arrêts de travail, de telle sorte que la rubrique utilisée pour payer les IJ Maladie soit sélectionnée intelligemment du point de vue de son statut vis à vis du prélèvement à la source : si on est dans les 60 premiers jours de l'arrêt de travail, les IJ sont soumises au PAS alors qu'au-delà, elles ne le sont plus (compte-tenu des 3 jours de carence, ce sont donc les 57 premiers jours d'IJ qui sont soumis au PAS).
Pour ce faire, la fonction de calcul des arrêts nommé ListeRubriquesGénérées doit retourner un couple de 2 rubriques pour ce qui des rubriques d'IJ, avec un séparateur - (tiret du 6) entre les deux numéros : la première rubrique doit être celle correspondant aux IJ soumises au PAS, la 2ème aux IJ non soumises au PAS.
Suite à cette correction, lors de la génération des éléments variables découlant de l'arrêt de travail sur un mois donné, la période indemnisée est automatiquement générée :

• Soit en totalité sur le 1er N° de rubrique si la date de fin de l'indemnisation est inférieure à date arrêt + 60j
• Soit en totalité sur le 2ème N° de rubrique si la date de début de l'indemnisation est postérieure à date arrêt + 60j
• Soit éclatée en 2 périodes sur ces deux numéros de rubriques si la date arrêt + 60 jours est au sein de cette période indemnisée : première rubrique pour la période allant de la date de début d'indemnisation jusqu'à la date d'arrêt + 59 jours (soit 60 jours en incluant la date de l'arrêt), deuxième rubrique pour la période allant de la date de l'arrêt + 60 jours à la date de fin de l'indemnisation.

Le conditionnement sur le n° de bulletin qui a été initié dans le correctif V9.60 niveau13 ne s'enregistrait pas lorsque celui-ci était comparé à la valeur 0 (type du 2ème opérande Valeur, et nombre saisi égal à 0).
Une autre modification a été opérée afin que dans ce type de conditionnement, et dans le cas d'un conditionnement sur le nombre de facteurs de pénibilité, la valeur saisie soit sous la forme d'un entier (suppression des décimales dans le masque de saisie)

L'option Un établissement = Une société, option spécifique au cas des cabinets de gestion immobilière, a été enrichie :

• Ajout d'un champ dans la fiche Etablissement (un code « délégation » pour affichage d'une mention spécifique sur l'en-tête des bulletins)
• Lors de la création des bordereaux de versement DSN, enregistrement du détail de toutes les lignes de bordereau par salarié, pour retransmission ultérieure via l'API LDPAYAPI.

 2 petites corrections ont été faites sur l'affichage du taux PAS dans la fiche Salarié :

1. La valeur 0 est désormais affichée, quand on a reçu un taux PAS avec cette valeur zéro.
2. Le taux est affiché avec 2 décimales et non pas 4 (c'était le cas uniquement dans la saisie ou l'affichage d'une situation).

Lors du calcul du PAS, on traite désormais le cas où le flux financier (Rémunération versée au salarié - Cotisations sociales) est insuffisant pour absorber le montant du PAS.
Cette correction fait suite à une réponse de l'administration à une question posée sur ce sujet à DSN-INFO, réponse qui se terminait par :
Dans l'hypothèse où le salarié est rémunéré par l'entreprise et dispose d'un avantage en nature imposable (une part patronale Mutuelle est assimilable à un avantage en nature), mais du fait du faible montant de la rémunération, avec le montant des cotisations sociales et du PAS à imputer sur celle-ci, l'entreprise ne verse rien à son salarié, il n'y a alors pas de PAS à prélever.
Ce cas obéit aux règles prévues dans le cas d'avantages en nature sans complément de versement financier.
Voir aussi sur ce sujet la fiche consigne 1940.

En conséquence, le calcul du PAS effectué par LDPaye tient compte désormais de ce cas de figure : si le montant du prélèvement calculé est supérieur à la valeur du cumul NETAVP-Net à payer avant prélèvement, le taux et le montant du PAS sont forcés à zéro et le type de taux est forcé à la valeur 13-Barème mensuel métropole (13 étant une valeur d'échappement de la rubrique 50.007). Sur le bulletin, en lieu est place de la mention Taux personnalisé ou Taux non personnalisé, on voit apparaitre la mention Flux financier insuffisant.

Complément d'information : la comparaison entre le montant du prélèvement et le net à payer avant prélèvement est effectuée au moment du calcul du PAS. A ce stade, le net à payer avant prélèvement n'intègre pas tous les éléments influant sur le net à payer, comme les remboursements de frais professionnels par exemple. Nous avons considéré que le net à payer à ce stade correspond parfaitement à la notion de « rémunération versée moins cotisations sociales » à laquelle il est fait mention dans la réponse de DSN-INFO.
De ce fait, on peut très bien avoir un net imposable positif (du fait d'avantages en nature) sans prélèvement de PAS, avec quand même un net à payer positif, même conséquent (supérieur au montant théorique du PAS), et ce dès lors qu'il existe des éléments s'ajoutant au net à payer après le calcul du PAS.

La mise à jour des compteurs du planning provoquait, lors de la clôture mensuelle, une erreur du type
Erreur à la ligne 81 du traitement Procédure globale zMAJCumulsLDPlanning. L'élément 'wPERSONNE.CPTD01' est inconnu.
Dans ce cas, la clôture mensuelle s'est bien déroulée, seule cette dernière action ne s'est pas faite. On peut donc supprimer manuellement le fichier PAYERR sans souci.

Le déblocage du composant LDPayApi, lorsque le fichier PAYAPI n'est pas conforme, n'était pas compatible avec les dernières modifications du composant. Ce déblocage n'était pas fonctionnel.

Dans certains cas, l'impression des bulletins de plusieurs salariés pouvait imprimer de mauvaises informations sur l'entête du bulletin (mois de paye, nom du salarié, ...) à partir du 2ème bulletin. Ce cas se produisait si une valeur de pied de bulletin est paramétré à partir d'une ligne bulletin (nouveauté V9.60).

La réimpression des bulletins calculés avant la mise en place des paramétrages du Prélèvement à la source (PAS) affichait le libellé "NET A PAYER" en lieu et place du "NET A PAYER AVANT IMPOT SUR LE REVENU", mais le montant restait à 0. Dans ce cas, le montant affiché sera le même que celui affiché en dessous (dans la zone "Net payé en euros").

L'entête de colonne de la part employeur n'était pas affiché sur les bulletins simplifiés sur lesquels est affiché le 2ème tableau des cumuls en pied de bulletin.
Egalement, les entêtes "Gains" et "Retenues" du bulletin simplifié ont été décalés vers la droite pour être mieux alignés par rapport aux montants correspondant.

Une anomalie dans le contrôle du mot de passe a été corrigée. Cette anomalie concernait seulement les environnements avec mots de passe gérés en interne, pas ceux gérés via Active Directory.

De la même façon que l'accès à une DSN en modification, suppression ou impression est dépendant du niveau d'accès de l'utilisateur courant à la société contenue dans la déclaration, l'accès aux différents bilans et CRM d'une DSN reçus en retour par l'API-DSN est lui aussi protégé.

Lors du calcul d'un bulletin avec application de la régularisation au net automatique (déclenchée par la présence d'éléments variables sur des rubriques d'IJSS brutes et nettes), il y avait un dysfonctionnement s'il existait sur le bulletin plusieurs éléments variables correspondant à des rubriques d'IJSS brutes. Seul le 1er de ces éléments variables était ignoré lors du 1er calcul servant à déterminer le montant net à obtenir. Du coup, le net obtenu au final n'était pas le bon (celui que l'on aurait eu en l'absence de toute IJSS).
Or, comme le prélèvement à la source nous oblige à utiliser plusieurs rubriques (donc plusieurs éléments variables) en fonction de la nature de l'IJSS (IJSS Maladie avec ou sans maintien, IJSS AT, IJSS Maternité...), ce cas va devenir assez fréquent. Avec cette correction, il est désormais géré correctement.

Au passage, une autre correction a été faite : si les paramètres de calcul de la régularisation au net en mode automatique sont modifiés alors que la fenêtre de calcul des bulletins est ouverte, ces paramètres sont automatiquement relus quand la fenêtre de calcul des bulletins reprend le focus afin que la modification soit prise en compte dans les calculs ultérieurs.

Autre modification touchant cette fois le cas où l'on calcule un bulletin par le bouton Avec net : dans ce cas de figure, pour l'élément variable portant la régularisation au net (celui dont le montant est alimenté par la constante salarié à faire varier), le montant est systématiquement lu à partir de la valeur de la constante salarié même si un montant a été saisi auparavant sur l'élément variable en question. Le montant saisi est ignoré de telle sorte qu'il y ait effectivement plusieurs itérations du calcul de bulletin, avec chaque fois une valeur de constante salarié différente, et ce jusqu'à trouver le net demandé.

Des modifications ont été apportées sur le code calcul cotisation AF, l'objectif étant de traiter, en janvier 2019, le complément de cotisation Maladie à 6% avec ce code calcul, comme on le faisait pour le complément Allocations Familiales. La différence essentielle entre ces 2 cotisations porte sur le seuil plancher : 3,5 SMIC pour le complément AF, 2,5 pour le complément Maladie. Ce coefficient sera indiqué à l'avenir dans le coefficient plancher toute fiche cotisation portant le code calcul AF.

Cette correction traite aussi le cas du bordereau de versement DSN URSSAF et du bordereau de cotisations URSSAF (l'ancien) : on y traite désormais les spécificités du complément Maladie (CTP 635, 636 et 637) sur le principe des spécificités du complément AF (CTPH 430, 432, 434, 437).

Une actualité à venir détaillera ces modifications.

Dans les paramètres DSN, la cotisation du Régime Unifié Agirc-Arrco (bloc 81, code 105) n'était associée qu'à la base déplafonnée (bloc 78, code 03). Elle est désormais aussi associable aux bases 78 de code 11 (forfaitaire), 22 (spécifique) et 23 (exceptionnelle).

Certains contrôles appliqués sur les informations de fin de contrat, fonction du motif de la rupture, étaient appliqués à tort, ou au contraire n'étaient pas appliqués alors qu'il le fallait, car certains codes ne sont pas communs en N4DS et en DSN (par exemple, le code 100 en N4DS correspond au code 104 en DSN, alors qu'il existe également un code 100 en DSN). Ces contrôles ont été revus afin de les actualiser par rapport aux règles définis dans les normes N4DS et DSN.

Dans le cas de bulletins erronés, envoyés en DSN, pour lequel il n'est plus possible de faire de DSN annule et remplace, il peut être utile de créer un bulletin d'annulation, qui est la copie exacte et inversée du bulletin du salarié (puis un 3ème bulletin sera le bulletin rectifié). Pour cela, il est désormais possible de générer des bulletins d'annulation pour un salarié, depuis la fenêtre Plus d'option, en tenant appuyé les touches Majuscule et Ctrl lors du clic sur le bouton Supprimer. Pour que cela fonctionne, il faut que tous les bulletins existants du salarié pour le mois soient clos, mais pas mensuellement. Le programme va alors copier les bulletins existants (du dernier au premier), en inversant toutes les valeurs. Les bulletins ainsi créés seront clos également.

Le code 06 - Ancienneté dans le groupe, qui a été ajouté dans le bloc 86 - Ancienneté, dans la norme P19V01 (applicable à partir de janvier 2019) était envoyé à tort dans les DSN créés avec la norme P18V01. Désormais, le bloc 86 n'est créé (avec la 2ème date d'ancienneté) que si le type d'ancienneté existe dans la nomenclature de la norme (ou a un équivalent prévu au programme).

3 améliorations ont été apportées dans la procédure d'import dans une DSN de données venant d'une feuille Excel :

• Les éventuelles lignes blanches présentes dans la feuille Excel sont ignorées (une ligne est considérée comme « blanche » si les 2 premières colonnes ne sont pas renseignées).
• Le matricule, lorsqu'il est composé de moins de 4 caractères en colonne 2 de la feuille Excel, est éventuellement complété par des zéros à gauche, et ce jusqu'à trouver un salarié correspondant au matricule en question, dans la société correspondant au SIRET ou au code société porté en colonne 1 de la ligne courante (si la colonne 1 n'est pas renseignée pour cette ligne et qu'il n'y a qu'une seule société dans le dossier courant, on effectue la recherche dans la société courante).
• Pour les dates portées en colonne 11 et 12, le système accepte désormais indifféremment les 2 formats AAAAMMJJ ou JJ/MM/AAAA.

La suppression du fichier DSN suite à l'envoi par l'API-DSN ne se faisait pas lorsque celle-ci était demandée (case à cocher au bas de la fenêtre permettant l'envoi du fichier). Cela était dû au fait que le fichier n'était pas refermé suite à l'envoi ; il était donc toujours « tenu » par la fenêtre d'envoi lors de la tentative de suppression.
Au passage, un message d'erreur a été envoyé pour signaler le fait que la suppression du fichier a échoué lorsque cela est le cas (ce qui n'était pas fait auparavant ; on n'était pas informé en cas d'erreur lors de la suppression du fichier).

On avait un souci dans le cas d'un salarié ayant un salaire brut nul (ou très faible), mais un salaire net suffisant pour appliquer un prélèvement à la source, tout cela en raison du versement d'IJ nettes. Dans cette configuration, le prélèvement à la source était nul (ou inférieur à ce qu'il aurait dû être compte tenu de l'assiette) pour absence de flux financier suffisant, alors que ce flux financier était suffisant si on y intégrait le versement des IJ nettes.
Pour éviter cela, la rubrique de versement des IJSS nettes, initialement prévue en 7070NT ou 7700NT, est désormais placée en 7050PN (juste après la rubrique des IJ soumises au PAS). Elle vient ainsi avant le calcul du prélèvement à la source.
Cette correction a pour effet :

• De modifier la fenêtre OUTIPAS pour les entreprises qui n'auraient pas encore créé les paramètres PAS
• De modifier la documentation des nouveautés de la version 9.60 en conséquence (Révision 1.05)
• De renuméroter la rubrique concernée (7070NT ou 7700NT) en 7050PN pour les entreprises ayant déjà mis en place les paramètres PAS avec la fenêtre OUTIPAS. Cette renumérotation est faite automatiquement à la première ouverture de chaque dossier de paye faisant suite à l'installation de ce correctif.

Une actualité détaille tout cela.

Ce problème se produisait seulement à l'affichage (pas d'incidence sur le calcul des bulletins). Les taux PAS pouvaient être associés au mauvais salarié si ce dernier avait un matricule contenu dans le matricule d'autres salariés (par exemple, le matricule 100 est contenu dans les matricules 1001 et 1002). Ce salarié se voyait donc attribuer les taux des autres salariés concernés. Ce problème était visible dans la fenêtre de consultation de l'historique des taux PAS et dans la fiche du salarié. Désormais, on affiche seulement les taux du salarié concerné.

Plusieurs optimisations ont été faites à l'ouverture d'une fiche salarié afin de diminuer le temps d'attente, qui pouvait être assez long (parfois plus de 10 secondes) lorsque la GED contenant un grand nombre de documents (par exemple, 500 salariés x 12 mois x 10 ans = 60000 bulletins dans la GED) :

• Pour l'affichage du bouton GED en partie droite, où l'image associée au bouton est fonction du fait qu'il existe ans la GED un document associé pour ce salarié, et où la bulle d'aide précise le nombre de documents associés dans la GED à ce salarié, plutôt que d'identifier précisément tous les documents associés dans la GED, on se contente de les compter. Et on ne parcourt plus les répertoires Windows de la GED à la recherche d'éventuels documents présents mais non référencés dans la GED. On ne compte donc que les documents effectivement référencés dans la GED (mais il est exceptionnel d'avoir des documents présents dans les répertoires Windows de la GED et non référencés dans celle-ci).
• Pour l'affichage de la photo, la méthode de recherche dans la GED du document correspondant à la photo du salarié a été revue : plutôt que de passer par une requête SQL (avec jonction entre les deux fichiers GEDDOC et GEDLIE qui est coûteuse si les 2 fichiers contiennent des milliers d'enregistrements), on fait un parcours séquentiel de tous les documents de la GED pour le salarié affiché et on prend le premier qui est de type Photo. C'est bien plus rapide lorsque la base de données n'est pas de type HFCS. Et dans le cas d'une base HFCS, les temps de traitement des 2 méthodes sont sensiblement les mêmes. 
• Enfin, une dernière optimisation a été faite dans le chargement de la zone Code gestion des arrêts de travail, le chargement de la liste de toutes les valeurs possibles était fait systématiquement (via une requête SQL relativement complexe) alors que ce champ est toujours grisé (en affichage uniquement) dans cette fenêtre. Il n'est donc pas nécessaire de charger la liste déroulante, celle-ci ne pouvant jamais être déroulée. On ne charge que la valeur correspondant au salarié courant.

Dans le cahier technique DSN, le contrôle CCH-12 de la rubrique 62.002 indique que les codes 100 - Mutation au sein du même groupe sans rupture du contrat (n'entrainant pas droit à l'Assurance chômage), 998 - transfert du contrat de travail sans rupture du contrat vers un autre établissement n'effectuant pas encore de DSN et 999 - fin de relation avec l’employeur (autres que contrat de travail, convention ou mandat) sont interdits si la nature de la déclaration (rubrique S20.G00.05.001) est renseignée avec la valeur 02 - Signalement Fin du contrat de travail ou la valeur 07 – Signalement Fin du contrat de travail unique.
Les salariés sortis avec ces motifs ne sont donc désormais plus affichés lors de la création de la DSN Fin de contrat (les salariés sortis avec le motif 100 étaient déjà exclus). Un libellé indiquant cet état de fait est également affiché dans la fenêtre de saisie des informations de fin de contrat si un de ces codes motif est sélectionné.

Dans la fenêtre de sélection des salariés à porter sur la déclaration, en création de DSN par exemple (si demandé, ou autre exemple, en création bordereau de régularisation avancé), l'ajout de l'élément sélectionné (de type salarié ou le contrat de travail) provoquait également l'ajout de tous les éléments fils (notamment les bulletins) de l'élément sélectionné. L'ajout de l'élément seul (avec les éléments parents, si nécessaire, mais sans les fils) était possible en tenant la touche Ctrl enfoncée. Cette fonctionnalité a été inversée. Désormais, les éléments fils de l'élément sélectionné ne sont pas ajoutés par défaut, mais on peut le forcer en tenant la touche Ctrl enfoncée. Le cas le plus fréquent est en effet celui où l'on veut ajouter un salarié parti : on souhaite alors ajouter le salarié et son contrat (bloc 30 et 40) mais pas son dernier bulletin (bloc 50 et fils).
Une bulle d'aide a été ajoutée sur les boutons correspondants pour expliquer ce fonctionnement.

Une nouvelle fenêtre permet de convertir un fichier Excel résultant de l'export d'une DSN en un fichier Excel au format d'import DSN de LDPaye.
Cette fenêtre permet également de comparer les fichiers Excel résultant de deux exports DSN et de créer un nouveau fichier Excel au format d'import DSN ne contenant que les différences entre les valeurs contenues dans les 2 fichiers initiaux (différences portant sur les valeurs déclarées, mais aussi sur les éventuels codes OPS destinataires ou codes communes INSEE (versement transport).
Cette fenêtre est accessible par le bouton Convertir/Comparer depuis la fenêtre d'export d'une DSN dans Excel.

Pour les besoins de cette nouvelle fonctionnalité, la procédure d'export d'une DSN au format Excel a été améliorée. Elle permet désormais d'exporter, pour chacun des blocs 81 qui le prévoient, le code OPS destinataire (SIRET de l'URSSAF ou code DMSA99) et le code INSEE de la commune (Versement transport), et ce via des colonnes supplémentaires figurant à droite de chacune des valeurs de blocs 81 où l'un ou l'autre de ces codes est attendu. Par exemple, pour l'assiette du versement transport, suite à la colonne 81.226/03:A, on trouvera une colonne intitulée 81.226/03:OPS contenant le SIRET de l'URSSAF destinataire et une colonne 81.226/03.INSEE contenant le code de la commune INSEE concernée par ce versement transport. Ces valeurs sont en effet indispensables lors de l'import de données dans une DSN. Toutefois, pour éviter d'ajouter systématiquement ces données qui n'ont pas toujours d'intérêt, ces nouvelles colonnes ne sont insérées dans le fichier Excel que si l'on coche la nouvelle option Exporter les codes OPS et les codes communes INSEE des blocs 81.

De même, la procédure d'import de données dans une DSN depuis une feuille Excel a été améliorée sur les points suivants :

• Dans les 8 premières colonnes du fichier Excel, les éventuels caractères Espace insécable (code ASCII 160) sont éliminés. Cela permet, lors de l'export en format Excel, de préfixer les valeurs numériques (SIRET, matricule...) d'un espace insécable afin d'éviter la perte des zéros de gauche non significatifs.
• Dans la colonne 8 Id interne contrat, on peut désormais recevoir au choix l'identifiant interne d'un contrat de prévoyance (le code à 8 caractère identifiant un contrat de prévoyance dans LDPaye) ou les identifiants « externes » sous la forme <Code IP>##<Référence contrat>##<Code population>##<Code option> (les codes population et option étant facultatifs). En effet, quand le fichier d'import a été constitué à partir des fichiers d'export de DSN, on ne dispose que des identifiants externes de contrat (ceux inscrits dans le fichier final d'une DSN). C'est donc ces codes externes qui seront placés dans le fichier d'import. C'est alors à la procédure d'import à rechercher, au sein de la DSN où les données sont importées, le contrat de prévoyance correspondant à ces identifiants externes.

Pour plus d'informations, voir la note d'actualité intitulée Correction DSN à posteriori - Un nouvel outil.

Les blocs d'en-tête du bulletin simplifié (bandeaux intermédiaires avec fond bleu) n'étaient pas personnalisables par l'appel d'une procédure dans le fichier WDES. C'est le cas désormais, sur le même principe que pour les autres blocs de cet état : deux procédures peuvent être ajoutées dans les fichiers .wdes : BLOC_ENTETE() , appelé avant chaque impression du bloc d'entête du bulletin simplifié (les 3 lignes bleues), et BLOC_ENTETE_D(), appelé avant l'impression de l'entête du bulletin détaillé (les champs de ce bloc étaient dans BLOC_HAUT, en version 9.50).

Lors de la création du dossier, il n'était pas possible de modifier le mois de paye courant (copié du répertoire d'origine), notamment lorsqu'on souhaite le faire reculer (pour reprise des salaires depuis le début de l'année par exemple). Désormais, le bouton Modifier dans les paramètres généraux permet d'intervenir sur le mois de paye courant, si et seulement si aucun bulletin n'a encore été calculé dans les fichiers.
PS : pour faire avancer ce mois, l'autre solution est de clôturer mensuellement jusqu'à arriver au mois souhaité.

Une erreur du type La source de données <ReqPEPACT> n'est pas initialisée pouvait survenir lorsque plusieurs fenêtres contenant la liste des salariés avaient été ouvertes en parallèle (par exemple, la fenêtre de calcul des bulletins et la fenêtre de gestion des salariés). Cette erreur survenait lorsqu'on tentait de parcourir (via l'ascenseur vers le bas) la liste des salariés de l'une de ces fenêtres sans avoir demandé le rechargement de cette liste (pas de repositionnement ou recherche par les zones Matricule ou Nom par exemple) alors qu'une autre fenêtre affichant une liste de salariés avait été ouverte en parallèle puis refermée.

Les éventuelles régularisations de PAS étaient cumulées avec une erreur de sens dans le cumul mensuel du PAS figurant en bas à droite du bulletin simplifié. En revanche, ces régularisations étaient additionnées correctement dans le cumul annuel.

Plusieurs corrections ont été faites dans la gestion avancée des arrêts de travail :

• Lorsqu'on revenait en modification sur un arrêt de travail dont le délai de carence était nul, dans la fenêtre de gestion des droits liés à l'arrêt de travail, les 2 tables où sont affichés les jours de maintien de salaire et les jours indemnisés par la Sécurité sociale étaient mal chargées. On démarrait non pas au 1er jour de l'arrêt, mais au lendemain de celui-ci. De ce fait, si on regénérait les éléments variables qui en découlaient, on avait implicitement un jour de carence. Toutefois, si on cliquait sur les boutons de recalcul Maintien de salaire ou Indemnités journalières SS, ces tables étaient recalculées correctement.
  Cette anomalie était présente également dans la fenêtre de génération des éléments de travail découlant des arrêts de travail.
• Lorsqu'on demandait le recalcul des éléments variables découlant de l'arrêt de travail, seuls les éléments correspondant à la période de génération étaient effacés avant cette génération. S'il y avait des éléments variables sur un mois antérieur associés à un bulletin non clos, ces éléments n'étaient ni signalés, ni effacés. Cela est le cas quand les payes sont effectuées assez tôt (avant la fin du mois), puis qu'on saisit un arrêt de travail en fin de mois : si la paye du mois courant n'est pas clôturée, des éléments variables sont générés sur cette fin de mois. Or, si le bulletin est déjà calculé et qu'il n'est pas recalculé suite à la saisie de l'arrêt de travail, ces éléments variables ne seront jamais repris sur un bulletin de paye. Avec cette correction, quand on redemande la génération des éléments variables, en cas de présence d'éléments variables sur un mois antérieur, éléments attachés à un bulletin non clos, un message d'avertissement est émis et on peut demander la suppression de ces éléments antérieurs, qui seront alors repris sur le mois de paye courant.
  Notez toutefois que cela n'élimine pas totalement le problème de fond mentionné ci-dessus. Quand on saisit un arrêt de travail en toute fin de mois, alors que la paye du mois est achevée mais pas clôturée, dans la fenêtre de gestion des droits, il faut normalement intervenir sur la période de génération des éléments variables pour demander à générer ceux-ci sur le mois de paye suivant. Ou alors, il faudra demander la génération des éléments liés aux arrêts de travail, cette problématique étant alors gérée correctement au travers des deux premières options Supprimer les éléments variables antérieurs au mois de paye en cours repris sur un bulletin non clos et Supprimer les éléments variables antérieurs au mois de paye en cours non repris sur un bulletin.
• En saisie des éléments variables, si on clique sur le bouton Arrêts travail, au retour, il y a désormais rechargement systématique de la table des éléments variables du salarié. En effet, il est probable que depuis la fenêtre de gestion des arrêts de travail, on ait ajouté ou modifié un arrêt de travail. Et de ce fait, si on utilise la gestion avancée des arrêts de travail, cela a pu avoir un impact sur les éléments variables découlant des arrêts de travail. Il faut donc réafficher tous les éléments variables pour voir ces éventuelles modifications.

Les libellés du bulletin simplifié ont été revus afin de correspondre aux dispositions prévues par l'arrêté du 09 mai 2018, concernant le bulletin à compter de janvier 2019.

Deux nouveaux codes calculs ont été mis à disposition pour les rubriques :

• Code [49] Nombre / taux x 100 (résultat arrondi à 2 décimales).
• Code [50] Nombre / taux x 100 +Arr € le plus proche (même chose que le code 49, mais avec un arrondi sans décimales).

Un paramètre programmes a été ajouté pour d'activer des spécificités dans certains programmes afin de satisfaire à un besoin spécifique à un logiciel de gestion immobilière.

Le contrôle du type de préavis renseigné à "10-pas de clause de préavis applicable" si le motif de rupture est égal à "43-rupture conventionnelle" a été étendu au code motif "110-rupture conventionnelle collective".

Les rubriques 003 à 006 du bloc 56 de la DSN sont obligatoires selon le type de régularisation (rubrique 002). On les marque donc désormais "Obligatoire" selon le cas, pour que la génération du fichier DSN crée ces rubriques le cas échéant, même si à 0.

2 anomalies ont été détectées dans cet outil de conversion du format d'export DSN en format d'import DSN :

• Pour les blocs 81, il y avait inversion entre montant et assiette de cotisation. Il faut que le montant de cotisation soit porté dans la colonne Valeur du fichier d'import, l'assiette de cotisation étant elle inscrite dans la colonne Valeur 2.

• Dans le cas on l'on créait un fichier d'import à partir d'un fichier d'export (et non pas celui de la comparaison de deux fichiers d'export, où là le fichier d'import ne comporte que les différences), on retrouvait dans le fichier d'import autant de lignes qu'il y avait de lignes et de colonnes numériques dans le fichier d'export, même lorsque les valeurs portées dans le fichier d'export étaient nulles. Ainsi, par exemple, on retrouvait des lignes pour la réduction Fillon (bloc 81 code 018) pour tous les salariés, même ceux n'ayant pas eu de réduction, ce qui est tout à fait inutile.
  Désormais, les lignes dont les deux valeurs (Montant et Assiette de cotisation dans le cas d'un bloc 81) sont nulles ne sont pas inscrites dans le fichier d'import, sauf s'il s'agit de blocs « obligatoires » (blocs 51 code 001, 002, 003, 010 et blocs 53 code 01).

Plusieurs améliorations ont été apportées dans la gestion de la régularisation au net :

• Dans le cadre de la régularisation au net automatique, on peut désormais demander une régularisation au net dite « stricte », qui consiste à maintenir non pas le net initial sans les IJ, mais le net initial diminué de la CSG et du CRDS perçus sur les IJ. En clair, la CSG et la CRDS sur les IJ restent à la charge du salarié.
  Une nouvelle option Type de régul au net stricte est disponible dans les paramètres généraux, sur l'onglet Calcul, pour choisir ce mode de fonctionnement. Sachez là-aussi que tout est automatique : c'est le système qui calcule le montant de la CSG-CRDS sur les IJ (par différence entre l'IJ brute et l'IJ nette) et qui diminue le net à atteindre de cette différence.

• Le cas de la régularisation au net avec un net négatif et une avance sur paye ramenant ce net à zéro est désormais parfaitement géré. Auparavant, la régularisation au net ne fonctionnait pas dans ce cas de figure : on ne pouvait pas « viser » un net à payer négatif puisque celui-ci était systématiquement ramené à zéro par une avance sur paye. Désormais, lors d'un calcul de régularisation au net, que ce soit une régularisation au net automatique ou par un calcul à l'envers (bouton Avec net de la fenêtre de calcul des bulletins), le mécanisme de l'avance sur paye est débranché temporairement le temps du calcul du bulletin avec régularisation au net. Puis, une fois le montant de la régularisation au net déterminé, le système effectue un dernier calcul de bulletin en réactivant le mécanisme de l'avance.
  Si on est en régularisation au net automatique, tout est là-encore automatique. Si l'on est dans le mode Calcul à l'envers, il faut dans un premier temps calculer le bulletin sans les IJ, noter le net à payer négatif à atteindre (donc le montant de l'avance sur paye que l'on a obtenu sur ce 1er calcul), puis demander le calcul Avec net en visant le net à payer négatif que l'on a observé au 1er calcul. Au passage, notez que dans la fenêtre où l'on indique le net à payer recherché dans le calcul « à l'envers », le montant proposé est celui de l'avance sur paye lorsque le net visé est nul et qu'il y a eu effectivement une avance sur paye déclenchée automatiquement au 1er calcul. 
  Dans les deux cas, à la fin du calcul, le bulletin aura un net à payer nul, mais avec la même avance que celle observée sur le premier bulletin sans les IJSS, preuve que le net à payer a bien été conservé.
  
• Une dernière modification (mineure) a été faite. Elle concerne la régularisation au net automatique, dans le cas où l'on saisit le montant de l'IJ nette sur une rubrique de la famille 4100XX. Ce montant IJ nette est saisi dans la colonne Nombre et non pas dans la colonne Montant, comme lorsqu'on saisit le montant de l'IJ brute. De ce fait, quand on recalculait un bulletin déjà établi avec régularisation au net, le système ne détectait pas le montant de l'IJ brute en amont du 1er calcul et de ce fait, ne pouvait pas contrôler que le montant de la régularisation au net déjà présent (celui issu du calcul précédent) était cohérent avec le montant de l'IJ brute. Du coup, dans le doute, il ignorait ce montant et relançait le processus de la régularisation au net comme si celle-ci n'avait jamais été faite, ce qui nécessitait donc entre 4 et 6 calculs de bulletin successifs. Alors qu'en conservant le montant de la régularisation au net déjà connu, et dans la mesure où rien n'a été modifié sur le bulletin, le premier calcul effectué avec les IJ donne le bon résultat. On n'a donc que 2 calculs à faire : le premier sans les IJ, le second avec les IJ et qui donne directement le même net.

Suite à la correction 68, le thread de récupération des retours DSN (dont les CRM DGFiP contenant les taux PAS) n'était plus démarré à l'ouverture de la fenêtre principale de LDPaye. Ces CRM n'étaient donc récupérés que lorsque la fenêtre de gestion des DSN était ouverte (comme antérieurement à la version 9.60).

Le bloc 86, de type "01 - Ancienneté dans l'entreprise", n'était plus généré dans les DSN crées en norme P18V01 (ou antérieures) si un paramètre DSN existait pour une cotisation établissement (qu'une valeur soit trouvée ou non sur le salarié). Ce souci survenait également lorsqu'une cotisation établissement avait été saisi pour le mois pour un établissement précédent de l'établissement en cours de génération (cas des envois avec plusieurs établissements, seul le 1er établissement avait ces blocs anciennetés de créé).

Une nouvelle fonctionnalité a été ajoutée à la fenêtre d'historique des taux PAS (menu "Gestion"), la génération du fichier TOPAze qui pourra être uploadé sur net-entreprises (à partir de fin décembre 2018) afin d'obtenir un CRM nominatif des salariés. Par défaut la génération n'est faite que pour les salariés ne figurant sur aucun CRM nominatif valide (dans les 2 derniers mois). Une sélection des salariés est toutefois possible. La demande est faite sur le SIRET défini dans la fiche société. RAPPEL : Cela est stipulé sur la fenêtre, les salariés pour lesquels une "demande de taux réactif" (intitulé du service TOPAze) a été déposée sur Net-entreprises sont informés de cette demande sur leur espace privé du site des impôts.

Report de la correction 57 sur la fenêtre de saisie des paramètres. On rencontrait le problème ici aussi en utilisant le bouton "Test Mail".
En cas d'envoi des bulletins par mail, avec l'option de protocole de sécurité TLS ou SSL, la connexion sur certains serveurs de messagerie pouvait provoquer une erreur du type :
Erreur à la ligne 5 du traitement Procédure locale xImprimerBulletinDansMail.
Vous avez appelé la fonction EmailOuvreSessionSMTP.
Le passage du paramètre 5 a provoqué une erreur.
Un élément de type 'vide' ne peut pas être converti vers le type 'booléen'.

Lorsqu'un envoi DSN contient plusieurs sociétés, la récupération des retours associés peut prendre énormément de temps. En effet, il faut interroger l'API DSN pour chaque société. Cependant, à chaque retour récupéré, la table des envois était mise à jour pour indiquer le nouveau statut de l'envoi. Cette mise à jour se répétait pour chaque retour. Désormais, le traitement a été optimisé pour diminuer le nombre de mises à jour.

Lors de l'édition de l'état de cotisation ou du bordereau de cotisation, pour l'URSSAF, le programme affiche systématiquement la base du CICE à date de fin de la période demandée, cumulée depuis le début de l'exercice (quelle que soit la période de début demandée). Cela a pour conséquence d'avoir dans certains cas des regroupements (selon le critère de regroupement choisi) qui sont affichés alors qu'aucun salarié n'a eu de salaire pendant la période demandée sur ce critère de regroupement (cas des établissements suspendus, mais ayant eu des salariés précédemment dans l'année). Désormais, par défaut, seuls les regroupements ayant des valeurs autres que le CICE sont affichés. Une nouvelle option à l'écran Ne pas afficher les regroupements ne contenant que du CICE permet, si elle est décochée, d'obtenir l'édition telle qu'elle existait avant cette correction (utile uniquement si on souhaite faire des comparatifs entre divers critères de regroupement).

Le mode de paiement du fichier salarié était contrôlé par erreur, dans l'outil de reprise des salariés à partir d'un fichier .CSV, comme étant un champ codifié (alors qu'il n'accepte que les valeurs VB, CH ou ES, en dur dans les programmes).
Egalement, le contrôle des champs codifiés a été revu afin de gérer correctement le nombre de caractères à générer dans le champ intégré (la valeur était dans certains cas intégrée sur 1 seul caractère, alors qu'il en fallait 2 ou 3).

La génération du bloc 79, code 01-Montant du SMIC retenu pour le calcul de la Réduction générale des cotisations patronales de sécurité sociale et de retraite complémentaire et de la réduction de cotisation Allocations familiales est obligatoire s'il existe un bloc 81, code 018 ou 105 (réduction générale, respectivement pour l'URSSAF et l'AGIRC-ARRCO). Lorsque le montant SMIC était nul (dans le cas par exemple où le salarié n'a aucune heure payée dans le mois), le bloc 79 code 01 n'était pas généré, alors même qu'il pouvait y avoir une réduction de cotisations dans le mois (le calcul de la réduction étant effectué en cumul annuel). Désormais, ce bloc est généré pour tous les bulletins, même lorsque la valeur est nulle, et même en cas d'absence de réduction générale.

A la suite d'une erreur d'authentification lors d'un envoi DSN sans saisie du mot de passe (utilisation du mot de passe enregistré en mémoire pour l'identifiant DSN sélectionné), il est désormais possible de saisir un nouveau mot de passe et de tenter de renvoyer le fichier. Si ce nouvel envoi aboutit, le nouveau mot de passe est automatiquement enregistré comme étant le nouveau mot de passe associé à l'identifiant DSN, comme si on avait modifié ce mot de passe depuis la gestion des identifiants DSN.

Plusieurs améliorations ont été faites dans l'outil de comparaison des assiettes de référence. Signalons tout d'abord que cet outil avait été ajouté en version 9.00 de LDPaye, lorsque la notion d'assiette de référence avait été introduite dans LDPaye (voir chapitre D.3 de la documentation des Nouveautés de la version 8.00).
Cet outil est accessible par le menu Outils/Autres outils/Lancer un autre outil ; il se nomme Comparaison des assiettes entre cotisations.
Les améliorations ont porté sur les points suivants :

• Jusqu'alors, l'élément de référence pour la comparaison ne pouvait être qu'une cotisation. Désormais, cela peut être une cotisation ou un cumul. On peut ainsi facilement comparer que tout ce qui met à jour le cumul BRUFIM-Brut mensuel met à jour également les bases d'une série de cotisations et inversement.
• Pour sélectionner les cotisations dont on veut comparer les assiettes, de nouveaux critères de sélection apparaissent, en plus du code assiette de référence et de la famille de cotisations : le Code Type URSSAF (CTP) ainsi que le libellé de la cotisation (par exemple, on peut sélectionner toutes les cotisations dont le libellé contient le mot ASSEDIC ou FNAL).
• On peut désormais omettre certaines rubriques et/ou cotisations de cette comparaison, pour faciliter la lecture du résultat de la comparaison, quand on a des différences qui sont justifiées. Cette omission peut se faire soit en renseignant la liste des N° de rubriques et/ou cotisations à omettre, soit en renseignant une liste de mots « interdits » dans le libellé de ces rubriques ou cotisations. Ces deux listes doivent être saisie avec un séparateur « ; » (point-virgule). Par exemple, si on indique stagiaire;smic à l'invite Omettre les rubriques sur libellé, toutes les rubriques dont le libellé contient le mot stagiaire ou smic sont omises du traitement de comparaison.
  Remarque : la recherche du ou des mots indiqués au sein du libellé rubrique ou cotisation est faite sans tenir compte de la casse.
• Enfin, pour l'affichage du résultat de la comparaison, seules les différences de report de rubriques sur les cotisations traitées par rapport aux reports sur l'élément de référence (une cotisation ou un cumul) sont affichées, en plus ou en moins. Mais on peut demander à voir tous les reports, ou seulement ceux absents (en moins par rapport à l'élément de référence), ceux en sus (toujours par rapport à l'élément de référence) ou même seulement ceux identiques.
• Dernière chose : on peut aussi omettre les rubriques suspendues du résultat de la comparaison, sachant que par défaut, ces rubriques suspendues sont elles-aussi affichées, mais apparaissent en grisé et en italique.

Ce correctif reprend tout un ensemble de petites corrections permettant de prendre en compte la nouvelle réduction générale de cotisations (dite Fillon) à la sauce 2019, c'est à dire étendue aux cotisations patronales de retraite complémentaire et aux cotisations chômage.
Au passage, partout dans l'interface et dans les codes sources de LDPaye, les termes « Réduction Fillon » ont été abandonnés au profil des termes plus génériques « Réduction générale de cotisations patronales », avec des abréviations diverses selon la place dont on disposait. 

Des modifications mineures ont également été réalisées pour que les cotisations des VRP multicartes soient adressées à URSSAF à compter de janvier 2019 (nominativement et sur le bordereau de versement).

 Deux corrections ont été faites dans l'outil d’initialisation des nouvelles cotisations retraite RUAA en 2019 (fenêtre OUTIRETR) :

• La cotisation CET en T1, qui ne se déclenche que pour les salariés dont la rémunération dépasse le plafond SS, n'est plus créée pour les apprentis si on a laissé l'option Créer les cotisations Retraite Apprentis sur T2 non cochée. Cela étant, si l'outil a déjà été passé et que cette cotisation CET a été créée pour les apprentis, cela n'est pas bien grave. Vous pouvez laisser cela en état, ou vous pouvez la suspendre. Cette cotisation porte normalement le N° 62KA1A.
• Les paramètres DSN relatifs aux bases spécifiques retraite pour les salariés à temps partiel avec option de maintien des cotisations temps plein n'étaient pas créés : Base 78.22-Base brute spécifique et 78.24-Base plafonnée spécifique. C'est désormais le cas.
  Si l'outil a déjà été passé et que vous avez les cotisations propres à ce cas un peu particulier (cotisations dont le N° est de la forme 62AxxP, c'est à dire avec un P en position 6), il faut aller ajouter les paramètres manquants : 
  • Dans la fiche de la cotisation RETRAITE RUAA T1 Temps partiel, portant normalement le N° 62AA1P, il faut ajouter les paramètres DSN 78.22 et 78.24 (qui sont tous deux à chercher dans le type Retraite), en sus du paramètre 81.105/22 qui doit déjà être présent.
  • Dans la fiche de la cotisation RETRAITE RUAA T2 Temps partiel, portant normalement le N° 62AA2P, il faut ajouter uniquement le paramètre DSN 78.22, en sus du paramètre 81.105/22 qui doit déjà être présent.

Prise en compte des nouveaux CTP URSSAF en 2019, dans les différents contrôles et traitements « spécifiques » (Réduction générale de cotisations notamment) :
 - 726 et 727 pour les apprentis
 - 300 pour les VRP
 - 668 et 669 pour la réduction générale de cotisations en périmètre complet.

Pour ce qui est de la réduction générale de cotisations patronales, à compter de 2019, sur le bordereau de versement URSSAF en DSN, il faut utiliser le CTP 668 en lieu et place du CTP 671 dès lors que la réduction est calculée en périmètre complet, c'est à dire en incluant l'assurance chômage. De même, en cas de paiement d'un trop-déduit, il faut utiliser le CTP 669 en lieu et place du 801.
Ce remplacement 671/801 par 668/669 est traité directement dans le programme de création du bordereau de versement URSSAF. Le système va relire le coefficient de base de la réduction (paramètre T) ayant été utilisé sur chaque bulletin, dans la ligne de commentaire associée à la rubrique ayant calculé ce coefficient. Si le coefficient de base est supérieur à 0,30, c'est qu'il inclue l'assurance chômage. La réduction du bulletin en question est donc sommée sur le CTP 668 et non pas 671.
Conséquence : le CTP 668 ne doit pas être paramétré en 2019. On verra comment traiter cela en 2020 quand le CTP 671 n'aura plus cours dans le cas général (mais restera possible pour les salariés n'ayant pas de contribution d'assurance chômage.

Les paramètres DSN 81.001 et 81.002, correspondant aux exonérations des apprentis Loi 79 et 87, ne pouvaient être rattachées qu'à une assiette forfaitaire déclarée elle-même en 78.11. A partir de 2019, suite à la fin de l'exonération spécifique aux apprentis telle qu'on la connaissait (seule une exonération salariale limitée au SMIC perdure, complétée sur le plan patronal par la réduction générale de cotisations « étendue»), ces blocs 81.001 et 81.002 doivent être rattachés à l'assiette déplafonnée déclarée en 78.03.
On a donc doublé ces paramètres 81.001 et 81.002 qui deviennent 81.001/03 et 81.001/11 d'une part,  81.002/03 et 81.002/11 d'autre part.
Suite à l'installation de cette correction, à l'ouverture de chaque dossier de paye, tous les paramètres DSN existants qui étaient de type 81.001 ou 81.002 sont basculés en 81.001/11 et 81.002/11.
Les nouveaux paramètres 81.001/03 et 81.002/03 seront mis en place début janvier 2019, en s'appuyant sur la note décrivant le nouveau paramétrage requis pour les apprentis.
A noter également que ces paramétrages sur les apprentis (81.001, 81.002, et 81.003) ne sont désormais appliqués que si le type de contrat du salarié est défini avec un dispositif de type "apprenti" (respectivement "64", "65, ou "81").

Les paramètres DSN 78.12 et 79.02 (respectivement l'assiette du CICE et le montant du SMIC retenu pour le CICE) sont ignorés dans la phase de création d'une DSN pour les bulletins dont la date de règlement est postérieure au 31/12/2018.

Depuis le précédent correctif, l'erreur : Erreur à la ligne 6 du traitement Sélection d'une ligne de CB_IDENTIFIANT" pouvait se produire, dans la fenêtre d'envoi de la DSN par l'API, à l'ouverture de la fenêtre ou lors de la sélection d'un identifiant DSN.

Le code 907 - Complément de cotisation Assurance Maladie est prévu dans le cahier technique DSN pour 2020, pour la déclaration du nouveau complément de cotisation maladie qui est à créer pour 2019. Au 04/01/2019, il n'existe encore pas dans la norme pour 2019. Il a cependant été ajouté dans la liste des codes du bloc 81 dans LDPaye, en attendant qu'un journal de maintenance de la norme DSN pour 2019 officialise ce code, de manière à ce que les paramétrages à mettre en place pour 2019 puissent être faits, y compris sur ce code.
Le bloc 81 de code 907 ne sera toutefois pas créé dans les DSN générées, afin d'éviter un rejet par l'outil de contrôle DSN-VAL.
Ce code est toutefois calculé lors de la création des DSN pour les bordereaux de versements DSN (pour en tenir compte dans le bordereau de versement MSA), et lors de la visualisation du bulletin (onglet DSN) où cette ligne apparaît grisée et en italique pour signifier qu'elle ne sera pas envoyée.

En visualisation d'un bulletin, la norme utilisée par défaut sur l'onglet DSN est désormais choisie automatiquement en fonction du mois du bulletin et non plus de la norme utilisée dans la dernière DSN mensuelle : pour un bulletin de 2018, on prend la norme P18V01, pour un bulletin de 2019, on prend la norme P19V01.
Sauf si on sélectionne une norme explicitement dans la liste déroulante en haut à droite de cette fenêtre, auquel cas la norme choisie sera conservée lors de parcours de bulletins y compris de bulletins de mois antérieurs ou postérieurs, et ce tant que la fenêtre n'est fermée.

Cette correction fait suite à la correction 019 : RETOURS DE L'API DSN - ANOMALIES NON BLOQUANTE (NATURE 31) ET STATUT EN COURS.
Dans certains cas, le statut d'un retour est EN COURS. Ce statut n'était pas géré par LDPaye et était donc présenté à tort comme une anomalie. Désormais, on considère ce statut comme un statut « valide » et on ne signale plus d'anomalie.

Le tri et le filtre à partir des en-têtes de colonnes ne fonctionnait pas car certaines informations n'étaient pas initialisées tant qu'elles n'étaient pas affichées. 

Dans la circulaire AGIRC-ARRCO 2019-1-DRJ publiée mi-janvier, il est spécifié que les taux de cotisation retraite doivent être arrondis à 2 décimales. Or, l'outil d'initialisation des cotisations retraite RUAA a créé ces cotisations avec des taux à 3 décimales.
L'objet de ce correctif est donc de réaliser l'arrondi de ces taux à 2 décimales, selon la règle édictée par l'AGIRC-ARRCO, page 6 :
« Les taux résultant de la répartition entre l’employeur et le salarié sont arrondis au centième. Dans l’hypothèse où le troisième chiffre après la virgule est égal à 5, l’arrondi est réalisé au profit du salarié. »

Suite à la mise en place de ce correctif, l'arrondi des taux de cotisations retraite RUAA (toutes celles ayant un paramètre DSN 81.105, en dehors de l'APEC qui reste avec des taux à 3 décimales 0,0024 en part salariale, 0,0036 en part patronale), est réalisé à la première ouverture de chaque dossier de paye. Une trace des arrondis qui sont réalisés est enregistrée dans le sous-répertoire Log du répertorie des sous-répertoires (en principe de la forme X:\Ldsystem\Fichiers\Paye\Log), dans un fichier nommé Arrondis taux retraite dossier XXX AAAAMMJJ HHMMSSCC.log, XXX étant le code du répertoire traité, AAAAMMJJ HHMMSSCC étant la date et heure à laquelle l'opération a été réalisée.

D'autre part, l'outil d'initialisation des cotisations retraite RUAA (fenêtre OUTIRETR) a été modifié, pour le cas où il soit utilisé après la diffusion de ce correctif (peu probable, l'outil ne servant qu'une seule fois pour un plan de paye donné). A l'avenir, les taux des cotisations ne peuvent pas être saisies avec plus de 2 décimales.

Dans le cas où seuls des bordereaux de régularisation sont existants (pour un OPS et un établissement) lors de la création des bordereaux, le bordereau correspondant n'est pas considéré comme déjà préparé. Si la coche "Uniquement les bordereaux non préparés" est sélectionnée (elle l'est par défaut), le bordereau est donc désormais affiché mais n'est pas sélectionné par défaut (il faut le sélectionner manuellement si on veut tout de même le créer). Dans ce cas, un message d'avertissement est affiché lors du premier chargement de la liste des bordereaux à créer (ou en cas de changement de mois).

Le nouveau code 24-Tranche 2 Unifiée Prévoyance du bloc 79, initié par la norme P19V01, n'était pas disponible dans la liste des codes pouvant être associé aux cotisations dans le paramétrage du contrat de prévoyance.

Suite à la parution du décret donnant le taux de la réduction salariale sur les heures supplémentaires, nous avons été obligé de modifier notre méthode de calcul de ce taux.
Auparavant, ce taux était déterminé par le rapport entre les cumuls RSCOTI / RSBASA (ou à défaut de cumul RSBASA, RSCOTI / RSBASE), RSCOTI étant égal à la somme des cotisations salariales Vieillesse plafonnée, déplafonnée, Retraite et CEG T1, RSBASE et RSBASA étant égaux à l'assiette des cotisations de sécurité sociale, avant/après abattement.
L'inconvénient de cette méthode de calcul est qu'elle aboutit à un taux plus faible que 11,31% pour un salarié dépassant le plafond SS.
La nouvelle méthode que nous avons retenue est plus proche de ce que sous-entend le décret : on part du taux maxi porté dans la fiche de la cotisation concernée, qui sera à 11,31% dans le cas général, ou à une valeur moindre pour les salariés bénéficiant de taux réduits de cotisation Vieillesse (journalistes par exemple). Ce taux est ensuite ajusté à la baisse si le taux salarial de cotisation Retraite T1 observé sur le bulletin est inférieur au taux standard (3,15%). La valeur 3,15 est lue dans une constante générale nommée RSTRMX.
Notez que le cumul RSCOTI n'est plus utilisé dans cette nouvelle méthode. En revanche, les cumuls RSBASE et RSBASA le sont encore, mais uniquement pour les salariés bénéficiant d'un abattement. Le principe est que l'assiette de la réduction est minoré par le rapport RSBASA/RSBASE si ces deux cumuls ont une valeur non nulle et que le cumul RSBASA a une valeur plus petite que celle du cumul RSBASE. Cela permet de tenir compte du taux d'abattement « réel » appliqué sur le salaire brut du mois. On ne peut en effet appliquer directement le taux d'abattement présent dans la fiche du salarié, d'une part en raison du plafond annuel de l'abattement, d'autre part en raison de l'application éventuelle d'une assiette minimum.

Etant donné la profusion des barèmes de réduction applicable pour l'outre-mer, la limitation à 4 barèmes possibles pour calculer la réduction générale dans un plan de paye donné posait problème. Celle limitation est due au fait qu'on ne disposait que de 4 codes calcul 81 à 84 pour calculer le coefficient de la réduction, chacun de ces codes calcul renvoyant sur des constantes générales fixant la valeur des différents paramètres entrant en jeu dans le calcul du coefficient de la réduction : RFCOFn, RFLIMn, RFZFU, RFOMRn, RFOMSn. 
Or, depuis 2019, on a quantité de barèmes possibles :
 - 2 barèmes pour la réduction générale « classique » en métropole, selon le taux du FNAL : coefficient de base 0,2809 ou 0,2849
 - 2 barèmes pour la réduction générale « classique » en outre-mer, lorsque aucune réduction spécifique outre-mer n'est applicable (on inclue dans ce cas l'assurance chômage sans attendre octobre 2019), coefficient de base 0,3214 ou 0,3254
 - 3 barèmes pour la Guyane, Guadeloupe, Martinique, Réunion : compétitivité de droit commun, compétitivité renforcée, compétitivité spéciale.
 - 3 barèmes pour Saint-Barthélemy et Saint-Martin : compétitivité de droit commun, compétitivité de droit commun pour employeurs de moins de 11 salariés, compétitivité renforcée

Pour arriver à traiter davantage de cas dans un même plan de paye, les codes calcul rubrique 85 à 88 ont été créés. Ils fonctionnent exactement sur le même principe que les codes calcul 81 à 84.
On peut ainsi traiter jusqu'à 8 barèmes différents (parmi les 10 décrits ci-dessus) dans un même plan de paye.

Depuis 2011, le coefficient de la réduction générale de cotisations patronales se calcule en annuel, les autres types de réduction (ZFU, TODE et Outre-Mer) se calculaient toujours en mensuel.
A partir de janvier 2019, le coefficient de la réduction outre-mer se calcule en annuel dans le cas de la Guyane, Guadeloupe, Martinique, Réunion, mais reste en mensuel pour Saint-Barthélemy et Saint-Martin. Et il reste aussi en mensuel pour les réductions ZFU et TODE.
Pour faire la différence, dans le cas des réductions outre-mer, entre le cas annuel et le cas mensuel, le système fait désormais appel à une nouvelle constante générale RFANLn (n prenant une valeur comprise entre 1 et 8, en fonction du code calcul utilisé pour calculer le coefficient de la réduction, entre 81 et 88).
Si cette constante générale a une valeur différente de zéro, le calcul se fait en annuel, sinon il reste en mensuel.
Remarque : la valeur de cette constante générale n'est testée que lorsque la constante générale RFZFUn est renseignée et a une valeur autre que 1, signifiant que l'on est dans un cas autre que la réduction générale « classique », donc sur une réduction ZFU, TODE ou outre-mer.

De plus, pour traiter plus facilement le cas du calcul annuel, le plafonnement de la réduction outre-mer est désormais intégré dans le programme de calcul directement. Il n'est plus nécessaire de passer par une fonction personnalisée comme cela était indiqué dans la documentation RDFillon2015 pages 26 à 28.
Ce plafonnement joue désormais systématiquement pour toutes les réductions ZFU, TODE et outre-mer, en calcul mensuel ou annuel (le plafonnement est mensuel si la réduction est calculée en mensuel annuel sinon.
Ce plafonnement de la réduction se fait :
 - Lorsque la rémunération RMB est inférieure à SMIC * Constante générale RFZFUn, 
   Plafond réduction =  RMB * Coefficient maximal de la réduction
 - Lorsque la rémunération RMB est supérieure à SMIC * Constante générale RFZFUn et inférieure à SMIC * Constante générale RFOMSn, 
   Plafond réduction = SMIC * Constante générale RFZFUn * Coefficient maximal de la réduction

Avant ce correctif, le plafonnement de la réduction salariale Heures supplémentaires par la valeur du cumul RSPLAF n'était réalisé que si ce cumul RSPLAF avait une valeur strictement positive.
Cela ne fonctionnait pas dans le cas d'un apprenti réalisant des heures supplémentaires, si sa rémunération, même en incluant ces heures supplémentaires, n'atteignait pas 79% du SMIC.  En effet, en dessous de 79% du SMIC, l'apprenti n'a pas de cotisations salariale Vieillesse, donc le cumul RSPLAF était nul. La réduction salariale s'appliquait alors intégralement alors qu'il n'en faut pas : si pas de cotisations salariales, pas de réduction salariale bien sûr.

Avec ce correctif, le plafonnement se fait dans tous les cas, quelle que soit la valeur du cumul RSPLAF : positive, nulle, ou même négative. Dans ce dernier cas toutefois, très particulier admettons-le (l'assiette Sécurité sociale est négative), le montant de la réduction est plafonné à la valeur zéro (donc aucune réduction salariale), pas à la valeur négative du cumul RSPLFA.

En saisie des éléments variables, dès lors qu'on indiquait une période en dehors de l'exercice fiscale, on avait le message d'avertissement :
ATTENTION : une régularisation relative au prélèvement à la source sur l'exercice fiscal 2018 ne peut normalement pas être faite au-delà de fin 01/2019, sauf en cas d'indu.
Or, ce message n'aurait dû s'afficher que si l'élément saisi correspond à une régularisation de prélèvement à la source (Cotisation 7050RA ou 7050RT dans le plan de paye standard).

Dans le cas où 2 éléments, alimentant le même code (016, 017 ou 018) du bloc 51, s'annulent (par exemple, des heures structurelles annulées ensuite par une rubrique d'absence), un bloc 51 était créé à tort, avec nombre et montant à 0, ce qui n'est pas admis.

Le code 81.907 - Complément de cotisation Assurance Maladie a été ajouté dans la norme P20V01 (pour 2020), mais ne sera pas ajouté dans la norme P19V01. En attendant la mise en production de la norme P20V01, la MSA préconise d'alimenter le montant de cotisation dans le code 81.075. Du coup, lors de la constitution d'une DSN en norme P19V01, les valeurs paramétrées en bloc 81.907 sont donc basculées, pour le montant uniquement, sur le bloc 81.075 (l'assiette du bloc 81.907 est ignorée).
Remarque : cela ne se fait que dans le cas des salariés dont l'organisme de base est la MSA. Pour les salariés au régime général (organisme de base URSSAF), le bloc 81.075 n'existe pas, le complément maladie paramétré en bloc 91.907 n'est pas déclaré du tout en norme P19V01. Il ne le sera qu'à partir de la norme P20V01.

La correction 124, qui fait que la valeur paramétrée en DSN sur le bloc 81-907 est déclarée au final dans le bloc 81-075, ne s'appliquait pas que pour les salariés dépendant de la MSA, mais aussi pour les autres salariés (URSSAF ou CCVRP). Dans la DSN mensuelle, une valeur était alors inscrite à tort dans un bloc 81-075. Cela ne déclenchait toutefois pas d'anomalie, car le bloc n'étant pas attendu par l'URSSAF, il était ignoré.
Autre modification réalisée au passage : désormais, en visualisation de bulletin, sur l'onglet DSN, on présente les choses exactement comme elles seront déclarées dans le fichier DSN final. Pour les salariés dépendant de la MSA, le complément maladie est sommé sur bloc 81.075 (montant uniquement) ; pour les autres, il reste visible sur le bloc 81.907, la ligne étant en italique grisée car non transmise dans le fichier final, le code 907 ne figurant dans la norme DSN qu'à partir de la version P20V01.

Dans la version proposée initialement de la fonction PLFAPP, qui a pour objet de partager la rémunération mensuelle de l'apprenti en une part soumise aux cotisations spécifiques apprentis exonérées de la part salariale (part en dessous de 79% du SMIC) et une part soumise aux cotisations « standard » (au-dessus de 79% du SMIC), il y avait un bug qui faisait que cet éclatement fonctionnait mal à partir du 2ème mois de l'exercice (Février). Au-delà de janvier, même si la rémunération de l'apprenti excédait 79% du SMIC, on n'avait plus les cotisations classiques (6020, 6030, 62AA1, 62GA1, 6080) sur la part de rémunération excédant 79% du SMIC.
Ce correctif a pour effet de corriger directement le code source de la fonction personnalisée PLFAPP.

Code de la fonction avant correction :
// Dans tous les cas, il faut remettre à zéro les cumuls des cotisations qui sont alimentées par cette rubrique
// En effet, cette assiette composée de la seule part > supérieure au plafond
// se substitue à l'assiette par défaut, qui est le brut.
HLitRecherchePremier(ReqPMLIRC,"NORU",CAELVA.NORU)
TANTQUE HTrouve()
 SI PAS ReqPMLIRC.INVS _ET_ PAS tCumulsCotis[ReqPMLIRC.NOCO]..Vide ALORS
  tCumulsCotis[ReqPMLIRC.NOCO]:BRUT=0
  tCumulsCotis[ReqPMLIRC.NOCO]:BRAB=0
 FIN
 HlitSuivant()
FIN

// Calcul du plafond à 79% du SMIC mensuel, ramené au nombre d'heures de l'apprenti si inférieur à 151H67
PlafondSMIC est un réel = Arrondi(Min(CU.HORBAS, 151.67) * CG.THSMIC * 0.79, 2)

// et on renvoie la valeur supérieure au plafond
RENVOYER Max(CAELVA.NBRE-PlafondSMIC, 0)

Code de la fonction avant correction (correction en rouge) :
// Dans tous les cas, il faut soustraire des cumuls des cotisations qui sont alimentées par cette rubrique
// le salaire brut qui y a déjà été sommé
// En effet, cette assiette composée de la seule part > supérieure au plafond
// se substitue à l'assiette par défaut, qui est le brut.
HLitRecherchePremier(ReqPMLIRC,"NORU",CAELVA.NORU)
TANTQUE HTrouve()
 SI PAS ReqPMLIRC.INVS _ET_ PAS tCumulsCotis[ReqPMLIRC.NOCO]..Vide ALORS
  tCumulsCotis[ReqPMLIRC.NOCO]:BRUT-=CAELVA.NBRE
  tCumulsCotis[ReqPMLIRC.NOCO]:BRAB-=CAELVA.NBRE
 FIN
 HlitSuivant()
FIN

// Calcul du plafond à 79% du SMIC mensuel, ramené au nombre d'heures de l'apprenti si inférieur à 151H67
PlafondSMIC est un réel = Arrondi(Min(CU.HORBAS, 151.67) * CG.THSMIC * 0.79, 2)

// et on renvoie la valeur supérieure au plafond
RENVOYER Max(CAELVA.NBRE-PlafondSMIC, 0)

1. Lors de la création d'un bulletin d'annulation (voir correction 49), les éléments variables et les lignes de ce bulletin d'annulation étaient créées avec un code Déjà comptabilisé (rubrique DJCP) à la valeur Blanc au lieu de N=Non. Du coup, ces bulletins étaient ignorés durant la phase de comptabilisation de la paye.
On avait aussi potentiellement le même problème sur la zone Déjà viré sur les éléments variables (rubrique DJVR).
Toujours dans ce fichier des éléments variables, la zone Origine (rubrique C0ST, qui peut prendre les valeurs S=Elément saisi, A=Elément automatique...) était elle aussi remise à blanc ; on conserve désormais la même valeur que sur le bulletin d'origine qui est annulé.
Egalement, le N° de lot d'interface porté sur les éléments variables d'un bulletin d'annulation est désormais conservé à l'identique du bulletin d'origine (ils étaient eux aussi remis à blanc). 
2. Les éléments variables qui avaient éventuellement été saisis en vue du prochain bulletin (ou les éléments fixes) sont désormais décalés sur le n° de bulletin qui sera celui qui suit le bulletin d'annulation (pour ne pas les perdre).
3. Le mois de RAZ, défini dans les cotisations n'était pas pris en compte, aussi si le bulletin annulé était le 1er après RAZ du cumul cotisation, l'annulation affectait à tort dans les cumuls cotisations, les valeurs du dernier mois précédent la RAZ. Cela n'aura pas de conséquence sur le bulletin d'annulation, mais en aurait sur le bulletin suivant (calcul des tranches en annuel).

Dans LDPaye, il existait une procédure permettant d'imprimer les documents nécessaires aux élections des délégués du personnel (DP) et comité d'entreprise(CE) : Liste des électeurs, Liste des éligibles, Liste d'émargement, Etiquettes.
Cette procédure a été revue pour traiter désormais les élections au Comité Social et Economique(CSE), nouvelle instance qui fusionne les délégués du personnel et le Comité d'Etablissement. Elle est accessible par le menu Gestion/Imprimer/Elections au comité social et économique.
Au passage, le fait que l'impression soit classée par statut dans l'entreprise, en sus du collège électoral, est désormais optionnel (auparavant, dès lors que la table des statuts dans l'entreprise n'était pas vide, ces listes étaient automatiquement imprimées par collège et statut).

La saisie des données pour les blocs 92-Bases spécifiques individu non salarié a été revue pour permettre de saisir des blocs de type 05-Somme versée à un tiers avec des bases à zéro. En effet, dès lors que l'on doit déclarer, pour un individu, un bloc 92 avec le type 05, pour soumettre ces sommes au prélèvement à la source, il y a obligation de déclarer 4 blocs indissociables :
  50-Assiette brute déplafonnée
  51-Assiette brute plafonnée
  52-Assiette de la contribution libératoire
  53-Assiette de la contribution sociale généralisée
Or, on n'a pas forcément d'assiette à déclarer sur ces 4 blocs. Un montant nul est donc désormais accepté en saisie pour ces 4 blocs.

De plus, les contrôles sur les rubriques à renseigner pour le PAS sont désormais faits systématiquement, même si l'assiette du PAS est nulle. Ainsi, par exemple, le type de taux doit toujours être renseigné. En l'absence de PAS, on renseignera la valeur 13-Barème mensuel Métropole. De même, la date de versement doit toujours être renseignée, même en l'absence de PAS (c'est une rubrique obligatoire du bloc 92 en norme P19V01).

La saisie des affiliations et radiations de prévoyance a été revue afin de permettre d'enregistrer pour un même salarié, plusieurs affiliations successives à un même contrat de prévoyance. A la première ouverture du dossier avec ce correctif, un nouveau fichier sera créé (PECPRH) et une migration des données existantes est effectuée, de manière transparente (pas de message utilisateur). Pour accéder à ce nouveau fichier dans LDSQL, il est nécessaire de récupérer le fichier d'analyse (LDPayV96.wdd) qui a été mis à jour depuis le répertoire des programmes, et de le coller dans le répertoire "analyse" de LDSQL (en remplacement du précédent). Les requêtes et traitements (WDES, MCU, Fonctions personnalisées, LDSQL, ...) qui travaillaient sur les zones de PECPRS devront être revus en conséquence.

Pour éviter les erreurs de saisie, un contrôle empêchait la création d'une DADS-U pour une année qui n'était ni l'année courante (date système), ni l'année précédente. Ce contrôle a été remplacé par une simple confirmation.

Sur les bordereaux de versement des OC, si l'établissement payeur était différent de l'établissement déclarant, les blocs 20-Versement organisme de protection sociale des bordereaux payés n'étaient pas cumulés dans la DSN de l'établissement payeur dans un seul bloc comme cela est attendu. On avait autant de blocs 20 que d'établissements payé par l'établissement payeur.
Rappel : dans le cas d'un bordereau OC payé par un autre établissement, un bloc 20 est également créé dans la DSN de l'établissement déclarant, avec montant à zéro et mode de paiement 06-versement réalisé par un autre établissement.

Le correctif V9.00 niveau 268 avait pour objectif de cumuler le bulletin d'intéressement avec le bulletin suivant. Seulement, cela n'est plus compatible avec le paiement du PAS. Le fait d'avoir plusieurs blocs versements pour le même salarié et la même date de versement semble ne plus poser de souci, cette modification a donc été annulée. Le bulletin d'intéressement est de nouveau déclaré dans un bloc versement à part du bulletin du mois.

Afin d'éviter d'affecter un remboursement de prêt sur le mauvais prêt (cas des salariés ayant plusieurs prêts successifs), le type de prêt et le mois d'origine du prêt sont désormais affichés en commentaire (uniquement en visualisation du bulletin, pas sur le bulletin imprimé) sur la ligne du remboursement du prêt, et contrôlés lors de la clôture/déclôture du bulletin.

Le programme de calcul des bulletins a été revu de fond en comble pour optimiser le temps de calcul. Ces optimisations sont décrites en détail :

• d'une part la note « utilisateur » Des calculs de bulletins (beaucoup) plus rapides
• d'autre part la note plus technique  Optimisation temps de calcul des bulletins - Mars 2019.

Suite à toutes ces optimisations, le temps de calcul d'un bulletin devrait être divisé d'un facteur 2,5 à 4, selon la configuration (base HFCS ou HF Classic, locale ou réseau...), l'amélioration la plus notable étant observée dans le cas de fichiers à fort volume sur une base HFCS.

ATTENTION : il y a une différence essentielle dans le contenu du fichier des éléments variables (fichier CAELVA) suite à la mise en place de ce correctif : ce fichier CAELVA ne contient désormais que les éléments variables saisis, les éléments fixes et les éléments interfacés. En revanche, les éléments automatiques ne sont plus présents dans ce fichier, sauf dans le cas où ils sont associés à une ligne de bulletin pour laquelle des dates début-fin ont été calculées (périodes de rattachement), ou si un commentaire a été associé à la ligne de bulletin découlant de l'élément automatique (par exemple, pour expliciter le calcul de la réduction générale de cotisations patronales).
Sachez qu'en tenant la touche Majuscule enfoncée lors d'un calcul de bulletin (ou lors du lancement d'un Tout calculer), le calcul est opéré comme auparavant, avec génération dans CAELVA de tous les éléments automatiques. On peut ainsi accéder ensuite à ces éléments automatiques en saisie des éléments variables pour en modifier ou en supprimer certains.

Dans la fenêtre de préparation de la liste de paiement, on peut désormais sélectionner les salariés individuellement. En cliquant sur le bouton Sélectionner les salariés individuellement, une fenêtre de sélection présente la liste des salariés ayant un net à payer dans le mois demandé en paiement, ou en cas de paiement partiel, ceux ayant un élément variable sur l'une des rubriques à payer, toujours dans le mois demandé en paiement.
Remarque : dès lors qu'on opère une sélection ainsi, la sélection par code statistique est inopérante (les listes de choix des codes stats sont grisées).

Complément technique : la fenêtre de sélection des salariés utilisée ici, nommée PersSel3, a été créée en copiant la fenêtre DaduCrt3 qui était utilisée auparavant pour sélectionner les salariés à ajouter dans une DADS-U. Cette fenêtre DaduCrt3 a été supprimée au passage. On utilise dans les deux cas la nouvelle fenêtre PersSel3.

 Dès lors que la fenêtre de calcul des bulletins est ouverte et que le mode de calcul dit « optimisé » est actif, les modifications du plan de paye deviennent impossibles :

• L'accès à la fenêtre des paramètres généraux est interdit.
• Dans les fenêtres de gestion des rubriques, cotisations, types de cumuls, paramètres DSN et contrats de prévoyance, tous les boutons autres que le bouton Afficher sont grisés.

Suite à la parution de l'instruction ministérielle DSS/5B/2019/71 du 29 mars 2019, pour tenir compte de ce qui est dit en réponse à la question N° 15, le mode de calcul du taux de la réduction salariale s'appliquant sur les heures supplémentaires a été revu, mais uniquement pour les salariés dont la rémunération dépasse le plafond de Sécurité sociale (ce contrôle de dépassement se faisant en cumul annuel, et non pas en valeur mensuelle).
Pour les salariés qui dépassent ce plafond, le taux est désormais calculé en faisant le rapport entre la somme des cotisations salariales Vieillesse (plafonnée et déplafonnée) et de toutes les cotisations retraite RUAA (y compris l'APEC) d'une part, la somme des assiettes des cotisations retraite RUAA T1 et T2 d'autre part. Le taux obtenu ainsi est plafonné, comme dans le cas des autres salariés, à la valeur de 11,31% (ce taux maximal étant spécifié dans la fiche de la cotisation Réduction salariale Heures sup. elle-même).

Remarques

• Pour sommer les cotisations retraites RUAA, le système additionne toutes les cotisations salariales correspondant aux cotisations déclarées en DSN en bloc 81 code 105.
  Pour sommer les cotisations Vieillesse Sécurité Sociale, le système additionne toutes les cotisations salariales (celles ayant un taux salarial) qui sont imprimées sur le bulletin simplifié et qui sont regroupées sur ce bulletin simplifié sur les lignes Retraite / Sécurité sociale plafonnée et Retraite / Sécurité sociale déplafonnée (codes regroupement 3010 et 3020).
  
• Sachez que pour les salariés dépassant le plafond, compte-tenu de la valeur du plafond SS et des taux de cotisation Vieillesse et Retraite applicables en 2019, la valeur seuil à partir de laquelle le taux moyen de cotisation Vieillesse+Retraite passe en dessous de 11,31% est de 3916,79€. Autrement dit, pour les salariés dont la rémunération brute est comprise entre le plafond SS et 3916,79€, le taux calculé par cette nouvelle règle est supérieur à ce maximum de 11,31% ; la valeur observée sur le bulletin reste donc égale à 11,31 comme dans le cas général. Ce n'est que pour les salariés dont la rémunération excède 3916,79€ que le taux commence à diminuer progressivement, au fur et à mesure que la rémunération augmente.
  Cette valeur de 3916,79 est la solution de l'équation  (PlafondSS x TauxT1) + [(SalaireBrut - PlafondSS) * TauxT2] = SalaireBrut * 11,31
  avec TauxT1 = 6,90+0,40+3,15+0,86+0,14+0,024 = 11,474   TauxT2 = 0,40+8,64+1,08+0,14+0,024 = 10,284  et PlafondSS=3377
  
• Pour les salariés ne dépassant pas le plafond SS en cumul annuel, le calcul du taux de la réduction salariale sur les heures sup. reste inchangé : on prend le taux maximum prévu sur la cotisation de réduction elle-même, taux qu'on corrige éventuellement à la baisse si le taux salarial de la cotisation Retraite RUAA T1 observé sur le bulletin est inférieur à la valeur « normale » de 3,15% (valeur lue dans la constante générale RSTRMX, avec 3,15 par défaut si cette constante n'existe pas).

Exemple : un apprenti est rémunéré sur une base de 151H67 à 78% du SMIC, soit un salaire de base de 1186€58. Il effectue 5 heures supplémentaires payées au taux de 9,7793 (10,03 x 78% x 1.25), soit 48€90, pour un total brut de 1235€48. La part du brut excédant 79% est de 1235,48 - (10,03 x 151,67 x 79%) = 33,69.
Sa réduction salariale est alors calculée sur une base de 48,90 x 33,69 / 1235,48 = 1,33. Et sur cette assiette, on applique le taux de cotisation retraite de 11,31%, soit une réduction de 0,15.
Et oui, tout ça pour ça !

Remarque importante : dans la directive citée plus haut, l'exemple qui est donné pour illustrer la méthode de calcul qui est préconisée n'est pas très clair.
Il pose problème sur 2 choses :

• La méthode pour calculer la part de rémunération représentée par les heures supplémentaires ramenée au brut total est basée sur les heures, et non sur les montants de rémunération. Si le salaire brut est composé uniquement du salaire de base et des heures supplémentaires, faire le prorata en heures ou en montant est équivalent. Mais si le brut englobe des primes, on n'a pas le même résultat. Après réflexion, nous avons opté pour un prorata en montant de rémunération plutôt qu'en heures, cela nous semblant plus juste. De plus, le prorata en heures est difficile à faire ; il faudrait ajouter des paramètres supplémentaires dans le plan de paye pour disposer, lors du calcul de la réduction salariale des apprentis, du nombre d'heures supplémentaires et non pas du montant rémunéré au titre de ces heures, nombre d'heures qu'il faut de plus pondérer selon qu'il s'agit d'heures payées à 125% ou 150%.
• Après avoir calculé ce prorata (6,91% dans l'exemple livré dans cette directive), ils l'appliquent sur une base de 91€27, en précisant que ce montant est la part de rémunération excédant 79% du SMIC. Or, en refaisant les calculs, on s'aperçoit qu'il s'agit uniquement de la part du salaire de base excédant 79% du SMIC : 1293,06 - (151H67 x 10,03 x 79%). Pour calculer la part du brut excédant 79% du SMIC, il faut aussi tenir compte des heures supplémentaires qui sont soumises à cotisations retraite. On arrive alors à 1293,06 + (9 x 1,25 x 10,03 x 85%) - (151H67 x 10,03 x 79%) = 187,18. Les cotisations salariales retraite de l'apprenti sont calculées sur cette base. Il nous semble donc beaucoup plus logique de calculer la réduction salariale à partir de cette assiette.
  Avec notre méthode, on arrive donc à une assiette de réduction égale à (9 x 1,25 x 10,03 x 85%) x 187,18 / (1293,06 + (9 x 1,25 x 10,03 x 85%) = 12,92, supérieure aux 6,31 auxquels ils aboutissent dans leur exemple.
  Où est la vérité ? Peut-être qu'une nouvelle directive ou un avenant à celle-ci nous le dira !

Lorsque les salariés ont des matricules avec des longueurs variables, des erreurs pouvaient être présentes dans les clés du fichier des affiliations salariés (PECPRS), ce qui pouvait poser problème lors de la lecture de la liste des affiliations du salarié. La liste des affiliations était parfois erronée, ce qui avait entre autres pour conséquence possible une affiliation erronée dans la DSN du salarié. Remarque : pour contourner le problème avant ce correctif, il est possible de recalculer la clé KPERS du fichier PECPRS par un scénario de modification par lot, via un hConstruitValClé.
Mais avec ce correctif, cette clé KPERS du fichier PECPRS n'est plus utilisée, le problème ne se pose donc plus.

Dans le module GED, on pouvait avoir des mélanges de répertoire lorsqu'on avait des éléments (établissements, salariés, ...) ayant un identifiant identique dans plusieurs répertoires, et que des documents était ajoutés/modifiés/supprimés pour ces éléments sans avoir fermé le progiciel entre temps (le fait de passer par l'ouverture de session ne suffisait pas).
C'était le cas principalement lorsqu'on a 2 sociétés qui ont le même code société interne, dans deux répertoires différents, avec des matricules identiques entre ces deux sociétés. Dans ce cas, si on enchaînait l'export GED des bulletins des 2 sociétés sans avoir fermé l'application (juste en changeant de société), les bulletins de la 2ème société pour les salariés dont le matricule existait également dans la 1ère société (et pour lesquels on avait placé un bulletin dans la GED juste auparavant), étaient enregistrés dans le répertoire du matricule de la 1ère société, et des liens erronés étaient créés.

Correction de problèmes divers lors d'ajout d'évènements, lorsqu'on utilisait les boutons de navigation (Suivant, Précédent) ou qu'on fermait directement la fenêtre de saisie des contrats.
Il est désormais interdit d'avoir plusieurs événements à la même date pour éviter une incohérence de l'historique.
Le message de confirmation lors de l'ajout d'un premier évènement hors affiliation est désormais affiché une seule fois si on a confirmé l'affiliation implicite.
Enfin, ajout de bornes Min-Max pour les séparateurs entre les tables afin d'éviter les « écrasements » des éléments de la fenêtre.

Un processus de dématérialisation des bulletins est désormais proposé dans LDPaye, via le service Neotouch.
On peut ainsi envoyer automatiquement les bulletins de paye sur la plateforme de dématérialisation Neotouch et suivre l'avancement des traitements réalisés par cette plateforme.
Ces options sont accessibles via un nouveau bouton Envoi dématérialisé proposé dans la fenêtre d'impression des bulletins. 

Pour être conforme au CCH-18 de la rubrique 40.005 dans le cahier technique DSN, lorsque le code PCS-ESE du salarié est renseigné avec les codes "353b", "353c", "354b", "354c", "354e", "354f", "465b" ou "637c", un contrôle supplémentaire est effectué pour vérifier que le code complément PCS-ESE fait bien partie de la table de nomenclature des emplois du spectacle (table ART). Ce contrôle provoquait une erreur du type Erreur à la ligne 83 du traitement Procédure globale zTraiterRelation. L'élément 'CEM2ART' est inconnu.

L'affichage du dernier mois (mot clé DERMOIS) dans un document bureautique affichait "0,00" au lieu d'une chaîne vide lorsque ce dernier mois n'était pas trouvé (cas où aucun bulletin ne contenait de ligne correspondant à la rubrique Net à payer définie dans les paramètres généraux).

La saisie d'un historique de valeurs du plan de paye ne permettait pas la saisie d'un coefficient de plancher ou plafond négatif.
Egalement, le calcul effectué dans le champ n'était pas pris en compte si le 1er caractère saisi était l'opérateur (+-*/) et que la bulle de calcul apparaît donc directement.

Malgré la correction N° 151, on rencontrait encore des erreurs dans le processus exécuté en arrière-plan de LDPaye, processus qui va périodiquement lire les compte-rendu métier DSN.
Un cas d'erreur au moins a été identifié : c'est celui où le processus se déclenchait alors qu'on était dans un aperçu avant impression. En effet, il semblerait que la fenêtre d'aperçu avant impression modifie temporairement le répertoire courant de l'exécutable, celui récupéré par la fonction Windev fRepExe. Or, dans le processus d'arrière-plan, pour lire certaines informations liées à la norme DSN, on fait appel au fichier PAYTAB et ce fichier était recherché dans le répertoire obtenu par cette fonction fRepExe. On avait donc une erreur liée au fait que le fichier PAYTAB n'était pas trouvé à l'endroit attendu.
La correction N° 151 n'étant pas suffisante, on a assigné cette fois-ci les fichiers "application" (comme le fichier PAYTAB) au répertoire de l'exécutable (égal au répertoire « courant » au lancement de l'application) dès le lancement du projet, pour se protéger des modifications ultérieures de ce répertoire « courant ». Sans cette assignation forcée, le fichier application est recherché dans le répertoire courant à l'ouverture du fichier, répertoire courant qui à ce moment-là n'est plus forcément le même.

En parallèle, on a remplacé quasiment partout dans le projet les références au répertoire courant (fRepEnCours) par une référence à la variable jCheminExe qui est positionnée une fois pour toute au lancement de l'application. Ainsi, les éventuels changements du répertoire courant (par l'usage du sélecteur de fichiers ou de répertoires de Windows notamment) n'ont pas d'influence sur les traitements qui recherchent un élément dans le répertoire de l'application.

La valeur du montant de régularisation de prélèvement à la source (bloc 56) était doublée en DSN (et donc dans le bordereau DGFiP) si la valeur paramétrée dans l'assiette, retourne 0.
Ce cas pouvait théoriquement se produire sur d'autres blocs à caractère obligatoires si paramétré (prévoyance notamment), mais ces blocs ne sont normalement paramétrés qu'avec une assiette ou un montant, pas les 2. Ils ne sont donc pas concernés.

Depuis la correction niveau 162, des bordereaux de versements étaient créés avec un montant versé à 0. Cela se produisait, principalement sur les OC, de manière qui semblait aléatoire, mais était lié au fait qu'il existait des éléments calculés pour d'autres OC, sur des périodes différentes de la période du bordereau qui était créée (régularisations de cotisation sur des mois antérieurs par exemple).

Dans la fenêtre d'impression des salariés, une nouvelle option Liste des changements de situation a été ajoutée. La forme de cette liste est identique à celle utilisée pour la liste des situations qui existait déjà. La différence porte sur la sélection des situations qui sont imprimées, sachant que pour ces deux listes, on doit choisir une période avec une date de début et une date de fin (par défaut, c'est du 1er jours de l'exercice à la date du jour) :
 - dans le cas de la liste des situations, on imprime toutes les situations ayant au moins un jour en commun avec la période demandée
 - dans le cas de la liste des changements de situation, on imprime toutes les situations dont la date de début ou de fin est dans la période demandée.
   Ainsi, une situation qui recouvre toute la période demandée (date de début de situation antérieure à la période demandée et date de fin de situation
   non renseignée ou postérieure à la période demandée, n'apparaitra pas sur cette liste.
   On ne cible réellement que les changements.

De plus, dans le cas de la liste des changements de situations, pour ce qui ne correspond pas à une entrée ou une sortie, on met en rouge les éléments ayant été modifiés entre les deux situations avant/après le changement. Et pour pouvoir faire cela y compris dans le cas où le changement a été opéré au 1er jour de la période demandée, on fait apparaitre également sur la liste la situation dont la date de fin est à la veille de la période demandée.

Le code de la ligne de bordereau "50.009", généré lors de la création du bordereau DSN pour la DGFiP n'était pas présent dans la liste des codes cotisations nominatives. Ce code était tronqué à "50" à tort. En cas de modification de la ligne, ce code (non modifiable) était alors remplacé par -1. Cela n'avait pour autant aucune conséquence notable car ce code n'est pas envoyé en DSN.

Lors de l'interface des éléments variables depuis un fichier Excel, la structure du fichier (entêtes de colonnes "RU.xxxx" par exemple) étaient lues sur la 3ème ligne remplie, au lieu de la 3ème ligne quel que soit le remplissage. Si la 1ère ou 2ème ligne était vide, la structure n'était donc pas lue dans la bonne ligne, et donc aucun élément à interfacer n'était lu dans le fichier.

Lors de la création d'un bordereau de versement DSN basée sur une DSN (tous les bordereaux sauf celui de l'URSSAF), la recherche de la DSN précédente était effectuée alors qu'il n'y en avait aucune utilité pour le calcul du bordereau. Et cela ralentissait fortement le calcul. Cette recherche a donc été supprimée dans ce cas.

On a désormais la possibilité de gérer deux bordereaux de versement DSN distincts pour un même OC. Cela permet d'avoir, par exemple, pour un OC donné, certains contrats de prévoyance payés au mois et d'autres au trimestre, ou encore certains contrats payés par prélèvement SEPA et d'autres par chèque. Cette situation, quoi qu'assez peu fréquente, posait problème, car dans LDPaye, on ne pouvait jusqu'alors gérer qu'un seul bordereau de versement par OPS et par établissement, et donc un seul mode de paiement et une seule périodicité de paiement.
Pour arriver à gérer plusieurs bordereaux pour un même OC, on utilisera des codes OC « fictifs », repérables par le fait qu'ils contiennent un caractère #. Voici comment procéder :

1. Dans la saisie des contrats de prévoyance, là où l'on indique le code OC, on indiquera donc un code fictif : par exemple, si on doit gérer deux bordereaux pour l'APICIL (code OC P1031), on affectera certains contrats au code OC P1031 et d'autres à un code OC fictif P1031#2. Lors de la validation du contrat, un message prévient que ce code OC P1031#2 n'existe pas, mais on peut passer outre.
2. Il faut ensuite créer un OPS sous ce code fictif P1031#2, en plus de l'OPS P1031-APICIL PREVOYANCE. Lors de la création de l'OPS P1031#2, il faut prendre soin de porter le code OC réel à fournir en DSN. On indiquera ce code réel dans le libellé de l'OPS, après le caractère #. Ainsi, dans le cas de l'APICIL, on créera l'OPS P1031#2 avec le libellé APICIL PREVOYANCE #P1031. On passera outre, là-aussi, le message d'avertissement signalant que l'OC de code P1031#2 n'existe pas. Et on pourra alors choisir, pour chaque établissement et chacun de ces deux OPS, la périodicité et le mode de paiement souhaités, via le bouton Etablissements déclarants.

Lors de la création des bordereaux de versement DSN, le fait d'avoir créé deux OPS fera que l'on aura automatiquement deux bordereaux de versement distincts. Le système utilisant à ce stade les codes OC fictifs, il traite ces deux OPS P1031 et P1031#2 comme deux OPS totalement distincts.
Puis, lors de la création de la DSN, le système tient compte des codes OC réels, et ce sont donc les codes OC réels qui sont inscrits dans la DSN, que ce soit sur les blocs 15-Adhésion prévoyance ou 20-Versement OPS. Mais on conservera à ce stade deux blocs 20-Versement OPS étant donné que deux bordereaux de versement ont été créés en amont, chaque bloc 20 sommant un ou plusieurs blocs 55-Composant de versement correspondant aux contrats de prévoyance que l'on a affectés à chaque OPS.

Parfois, lors d'un changement de société, on avait un plantage avec le message d'erreur :

Traitement de 'Procédure locale xValiderChoixSociete' (sesouv.PROCEDURE.xValiderChoixSociete), ligne 16, thread 0
Fonction 'HLitRecherchePremier', syntaxe 0
Une erreur de blocage est survenue sur la fonction 'HSupprime' précédente et n'a pas été traitée.
Fonction appelée à la ligne 12 du traitement 'Méthode Fermer'.

Ce type d'erreur est désormais intercepté (et ignoré) pour éviter le plantage, sachant que l'objectif de ce traitement est simplement de maintenir à jour la liste des sessions ouvertes. Il est donc dommage de planter la session pour cette mise à jour qui est sans grande importance du point de vue applicatif. Au pire, si l'enregistrement correspondant à la session courante n'a pas pu être supprimé alors qu'il aurait dû l'être, il restera dans le fichier des sessions ouvertes jusqu'à ce que fichier soit épuré, ce qui est fait chaque fois que quelqu'un consulte la liste des sessions actives.

Il est désormais possible d'importer des établissements depuis l'outil Reprise de données salariés (OUTIREPS).
Cette nouvelle fonctionnalité d'import de données Etablissements est décrite dans la documentation Reprise de données depuis Excel.doc en révision 5.
En parallèle, un nouveau type d'export de données DSN a été implémenté (dans la fenêtre DsnXls), permettant récupérer les données des blocs 06-Entreprise et 11-Etablissement d'une DSN, données qui peuvent ensuite être importées sur le même principe que des données salariés.
Lors de cet export de données Etablissements, une option permet de récupérer des informations supplémentaires (Raison sociale notamment, qui ne figure pas dans une DSN) par un Webservice fourni par l'INSEE. Attention toutefois : le nombre de requêtes que l'on peut envoyer à ce webservice est limité à 30/min, l'export peut donc prendre du temps pour les sociétés avec beaucoup d'établissements.

Des corrections ont été apportée dans le calcul de la réduction générale de cotisations patronales, pour le cas des salariés bénéficiant d'une Déduction Forfaitaire Spécifique (DFS, appelée aussi Abattement pour frais professionnels). Pour ces salariés, en 2020 et sous réserve de la parution d'un décret d'application, la réduction est plafonnée à 130% du montant de la réduction qui aurait été appliquée en l'absence de DFS.
La correction faite ici ne s'applique qu'à compter de janvier 2020 (sauf si on indique une valeur comprise entre 201901 et 202012 dans la constante générale RFMDPL, pour indiquer le mois à partir duquel on souhaite appliquer ce plafonnement). Et pour que cela fonctionne, une petit complément de paramétrage sera à effectuer.
Cela sera décrit dans un actualité à paraître (voir note provisoire « Réduction générale de cotisations - Etude du plafonnement en cas de DFS », paragraphe Explication détaillée du calcul effectué dans LDPaye).

Mise à disposition de la norme NEODeS P20V01. Pour le détail des modifications, se reporter à l'actualité "Prise en charge du cahier technique DSN Norme P20V01".

Sur l'état de contrôle de la DSN, les totaux par établissement des assiettes de cotisation, détaillés en dessous du tableau (principalement les OC), cumulaient à tort les assiettes, des cotisations en question, pour tous les établissements imprimés dans les pages précédentes (au lieu de ne cumuler que pour un seul établissement). En revanche, les totaux généraux (tous établissements confondus) des assiettes, sur la dernière page, étaient correctes.

Cette nouvelle correction fait suite aux corrections 202 et 205 relatives à la gestion des sessions ouvertes, qui n'avaient pas complètement réglé le problème.
Désormais, dans tous les traitements faisant appel au fichier des sessions ouvertes (fichier LDSESTMP) lors de l'ouverture/fermeture d'une session, on intercepte et on ignore les erreurs pouvant survenir, et donc notamment les erreurs de lecture/écriture dans ce fichier LDSESTMP. En effet, on pouvait rencontrer assez fréquemment, sur certains postes de travail, des erreurs du type Erreur réseau inattendue. (59).

Cela est fait désormais dans les méthodes :
 - Session:Ouvrir, Session:Fermer, Session:Rebloquer
 - Session:InterdictionOuvertureEnCours  :  cela risque de laisser ouvrir une session malgré un blocage d'ouverture de session en cours,
   mais on a fait le choix de privilégier l'ouverture de session dans trous les cas).
 - Session:SuisJeSeul. Cette méthode est appelée notamment après chaque calcul de bulletin pour fermer les fichiers bulletins
   (CAELVA, CALIBU, CACUMU, CACOCU) si on n'est pas seul à travailler sur l'environnement courant, ce qui a pour effet d'accélérer les écritures dans ces fichiers
   lorsque ceux-ci sont gérés en HyperFile Classic.

En revanche, aucune interception d'erreur n'est faite lorsqu'on demande explicitement la liste de toutes les sessions ouvertes (fonction appelée depuis le menu Fichier/Sessions ouvertes) ou lorsqu'on veut ajouter un blocage d'ouverture de session.

Depuis le correctif niveau 26, si l'option Un établissement = Une société, spécifique au cas des cabinets de gestion immobilière, est utilisée avec des codes de délégation, cela provoquait une superposition des champs sections prud'homales et dérogatoire (juste en dessous), lors de l'agrandissement de la fenêtre.

Les n° des bulletins ont été ajoutés dans la fenêtre de sélection des salariés (appelée éventuellement en création de DSN ou de bordereau de versement DSN), afin de faciliter l'identification du bulletin à ajouter lorsque le salarié a plusieurs bulletins dans le mois avec les mêmes dates (cas des bulletins pour annulation).

Le nombre d'heures rémunérées ou d'absences non rémunérées (blocs 53-activités, si unité en heures), était toujours totalisé dans le total des heures rémunérées (la distinction n'était pas faite), que ce soit sur le total par établissement ou le total général.

Une sélection supplémentaire, sur les salariés ayant accepté ou refusé l'envoi dématérialisé (par envoi mail ou sur NEOBOX) a été ajoutée dans la fenêtre d'impression des bulletins (qui sert à l'envoi sur NEOBOX).
Cette sélection se fait en tenant compte du choix porté dans les fiches salariés (choix du mail utilisé, dans l'onglet Privé). Cette zone a été remplacée par une liste déroulante afin d'afficher un libellé différent selon qu'un identifiant de dématérialisation existe ou non dans le dossier (si oui, on parle de dématérialisation, sinon on parle d'envoi mail). Le choix du mail porté en DSN a également été remplacé par une liste déroulante (sans autre modification).

De plus, dans la procédure permettant d'envoyer les bulletins dans l'espace Neobox-RH, les statuts affichés durant l'envoi n'étaient pas les bons, ce qui créait une certaine confusion.
Par ailleurs, suite à l'envoi des bulletins dans Neobox-RH, la fenêtre d'impression des bulletins est automatiquement refermée si l'envoi a été à son terme, y compris la validation du traitement dans Neobox-RH.
Enfin, une petite erreur a été corrigée dans la fenêtre de consultation du statut des derniers envois, erreur qui faisait que le bouton Valider n'apparaissait pas sur la première ligne de la table. Il fallait re-sélectionner cette première ligne pour voir le bouton Valider.

Il est désormais possible, lors de la restauration d'un dossier de paye, de modifier le code du répertoire restauré (restauration d'un répertoire XXX en YYY par exemple) ou les codes externes des sociétés contenues dans le dossier restauré.
En cas de restauration sur un répertoire déjà existant, toutes les sociétés de ce répertoire sont remplacées par celles restaurées, seuls les droits d'accès sont conservés s'il y a égalité sur le code société interne.

La procédure d'interface comptable a été modifiée pour offrir la compatibilité avec la version 11 de LDCompta qui sera disponible prochainement. Cette modification n'apporte pas de nouvelle fonctionnalité à proprement parler : la seule modification concerne la longueur du libellé (qui passe de 25 à 50 caractères en version 11), mais ce surplus de longueur n'est pas utilisé par LDPaye (dans le format TXT, le libellé est simplement complété par 25 espaces).

Lors de la création d'un contrat de prévoyance, on accepte les caractères spéciaux au sein du code Identifiant interne du contrat, y compris l'apostrophe et le guillemet (' et ").
Or, par la suite, la présence d'un de ces deux caractères posait problème, notamment quand on manipule les contrats de prévoyance ou les paramètres DSN au travers de requêtes SQL.
Pour éviter cela, ces deux caractères Apostrophe et Guillemet sont désormais interdits en sein de l'identifiant interne d'un contrat de prévoyance, lors de la création d'un contrat.
De plus, pour corriger d'éventuels identifiants posant problème, la procédure qui permet de modifier l'identifiant interne d'un contrat (bouton Gérer les identifiants de la fenêtre principale de gestion des contrats de prévoyance) permet désormais de renommer un contrat dont l'identifiant contient une apostrophe (auparavant, cela provoquait une erreur).

Dans la fenêtre de numérisation, si aucune numérisation n'a été faite ou n'a aboutie, lors du clic sur le bouton OK, le programme provoquait l'erreur :
Erreur à la ligne 1 du traitement Clic sur VALIDE. L'objet dynamique 'fNumérisationCourante' n'a pas encore été alloué.

En saisie avancée des arrêts de travail, l'erreur décrite ci-dessous pouvait survenir lors de la sortie de la colonne Jours de maintien si la valeur dans cette colonne n'était pas renseignée, ou à 0.
Erreur à la ligne 12 du traitement Sortie de NBJM ( TableMaintien ). Vous avez appelé la fonction DateVersEntier. Une date doit être représentée par une chaîne de huit caractères au format AAAAMMJJ.

La norme P20V01 prévoit des codes potentiels dans certains blocs afin de permettre une mise en place de paramétrages sans avoir besoin nécessairement de publier un nouveau cahier technique de la norme. L'utilisation de ces codes est définie par les fiches consignes sur le site DSN-INFO. Un de ces codes potentiels, le code 81.907, avait déjà été utilisé pour la prime exceptionnelle de pouvoir d'achat (PEPA). 4 autres codes peuvent eux-aussi désormais être créés dans les paramètres DSN de LDPaye :
 81.908 – Taxe forfaitaire CDDU Assurance Chômage
 81.909 - Cotisation au titre du financement des régimes de retraites supplémentaires à prestations définies
 54.92 - Eléments relatifs aux cotisations frais de santé (non-déductibles)
 54.93 - Eléments relatifs aux cotisations prévoyance et retraite supplémentaire

Dans le cas où 2 blocs (ou plus) ayant le même code et le même titre se trouvent dans le même bloc parent, le programme provoquait une erreur du type Erreur à la ligne 17 du traitement Procédure locale xArbreAffiche_UneFeuille. L'objet dynamique 'MonBloc' n'a pas encore été alloué lors de la sélection du 2ème bloc. Ce souci peut facilement être contourné en sélectionnant le 1er bloc en doublon et en modifiant le titre pour ne plus avoir de doublon. Les titres de bloc n'étant pas inscrits dans le fichier final, cela n'a aucun impact sur la DSN envoyée.

Depuis les modifications intervenues début 2018 quant aux règles de calcul du plafond Sécurité sociale, le prorata de plafond en cas de temps partiel était calculé par le rapport entre la durée contractuelle de travail du salarié et la durée de référence de l'établissement. Le taux temps partiel n'était plus utilisé dans le calcul du plafond.
Afin de se rapprocher au plus près des instructions données par la circulaire DSS/5B/5D/2017/351 du 19 décembre 2017, la méthode de calcul du prorata pour temps partiel a été revue afin d'utiliser comme dénominateur la durée légale du travail (151H67) en lieu et place de la durée de référence de l'établissement. Cela peut donc amener à un plafond légèrement différent si la durée de référence de l'établissement était autre que 151H67.

Dans la fenêtre modification d'un bordereau de versement DSN, un champ de saisie de type Calculatrice a été ajouté pour le champ Montant à régler.
De plus, des champs de saisie de type Calculatrice ont également été mis en place dans la fenêtre de modification des cotisations agrégées pour les champs de type numérique.

Dans la liste de recherche obtenue par la touche de fonction F4 sur un code complément PCS-ESE (onglet Emploi de la situation des salariés), tous les codes propres à la fonction publique et aux IEG (Industries Electriques et Gazières) n'apparaissent plus. Etant très nombreux, ils encombraient la liste inutilement, d'autant plus que les codes des différentes nomenclatures pouvant être utilisées pour ce code complément PCS-ESE se chevauchent. On avait donc beaucoup de mal à trouver les quelques codes qui peuvent concerner une PME.
Sont présentés désormais dans cette liste tous les codes provenant des nomenclatures :
 - CCP - Code Complément PCS-ESE (ce sont ceux apparaissant normalement dans le cahier technique)
 - NEHMED - Fonction publique hospitalière - emplois médicaux
 - NEHNMED - Fonction publique hospitalière - emplois non médicaux
 - ART - Professions du spectacle
Malheureusement, ces 4 codifications se chevauchent encore quelque peu, celle de la nomenclature CCP pouvant être soit un nombre à 2 chiffres, soit un mélange de lettres et chiffres, sachant que les nomenclatures NEHMED et NEHNMED contiennent majoritairement des codes à 4 chiffres, avec quelques codes à 3 chiffres+1 lettre ou 1 lettre+3 chiffres, et que la nomenclature ART contient des codes composées de 3 lettres+3chiffres. 

Le 24/01/2020, la fiche consigne DSN-INFO N° 933 donnant la définition du montant net versé à déclarer en rubrique 50.004 a à nouveau fait l'objet d'une modification.
A partir de 2020, le montant du PAS ne doit plus venir en déduction dans ce montant net versé.
Dans LDPaye, à la première ouverture de chaque dossier de paye faisant suite à la mise en place de ce correctif, le paramétrage est (en principe) automatiquement mis à jour : les cotisations PAS (celles ayant un code calcul PS ou PR) ne se reportent plus dans le cumul NETVER.

Complément technique : la mise à jour exacte qui est faite à l'ouverture de ce dossier est la suivante :
 - Pour toutes les rubriques associées au paramètres DSN 50.004,
  - Si la rubrique est alimentée, pour ce qui est du montant, par un cumul,
    - On efface les reports dans ce cumul de toutes les cotisations ayant un code calcul PS ou PR (Prélèvement à la source ou Régularisation de PAS).

Lors de la consultation des salariés pour un contrat de prévoyance ayant une date de fin antérieure au mois courant, les salariés n'ayant aucun événement mais ayant été affiliés à ce contrat ne présentaient aucune coche grise. Désormais, tout salarié ayant été rattaché au contrat contient désormais une coche (verte si actif, grise sinon).

Pour savoir traiter le cas des expatriés, le N° d'affiliation attribué par le centre de recouvrement Spectacle et Expatriés de Pôle Emploi a été ajouté dans le lien OPS/établissement, lorsque l'OPS est Pôle Emploi. Ce N° d'affiliation se retrouve en DSN dans le bloc 20-versement OPS à destination de Pôle emploi.

La correction 228 a déclenché une mise à jour automatique des paramètres dans le plan de paye, pour tenir compte de la nouvelle définition du net versé.
Cette mise à jour de paramétrage a eu un effet indésirable dans certains plans de paye mal configurés : ainsi, si c'était le net à payer qui était déclaré en DSN en tant que net versé (alors même que la définition antérieure du net versé ne correspondait pas au net à payer, ce qui signifie que les nets versés déclarés antérieurement en DSN étaient faux), le report du PAS a été retiré du cumul Net à payer (qui était dans ce cas aussi le Net versé), faussant donc le net à payer des salariés ayant du PAS.
Cette correction tente donc de rétablir les choses pour ces plans de paye erronés :

1. A chaque ouverture d'un dossier de paye au niveau 233 jusqu'au 31/03/2020, le système vérifie les reports des cotisations ayant un code calcul PAS (code PS et PR) vis à vis des cumuls NETPAY et NETVER. Les cotisations PAS doivent impacter le cumul NETPAY, mais pas le cumul NETVER. Si tel n'est pas le cas, le paramétrage de ces deux cumuls est modifié en conséquence.
2. Si une modification de paramétrage a été nécessaire (ou si le paramètre programme ERR960233 existe avec une valeur alphanumérique à blanc), le système vérifie, pour tous les bulletins déjà calculés des mois 01 à 03/2020, les lignes de bulletins Net à payer avant PAS et Net à payer, pour s'assurer que l'on a toujours Net à payer avant PAS - Montant du PAS = Net à payer. Les N° des 2 rubriques concernées sont définis dans les paramètres généraux ; en principe, ce sont les rubriques 8994 et 8995). Si au moins un bulletin en erreur est détecté, un message d'anomalie est émis, où figure la liste des premiers bulletins en erreur. Un « marquage » du plan de paye est effectué de telle sorte que ce même message d'erreur soit systématiquement affiché à chaque ouverture du dossier de paye concerné, tant que ce marquage n'est pas explicitement effacé : il faut pour cela aller effacer la valeur alphanumérique de ce paramètre programme ERR960233. Ainsi, à la prochaine ouverture du dossier de paye, ce contrôle des bulletins sera effectué une nouvelle fois et si aucun bulletin n'est plus en erreur, le paramètre programme sera définitivement supprimé.
3. Si le paramètre DSN 50.004 fait référence à la rubrique correspondant au Net à payer, là-aussi, un message d'anomalie est émis et le restera à chaque ouverture du dossier (jusqu'au 3103/2020) tant que cela n'aura pas été corrigé.

Remarque : si le plan de paye était erroné, seuls les bulletins de janvier 2020 calculés après la mise en place du correctif de niveau 230 et ayant un montant PAS non nul sont en principe erronés, sachant que le correctif 230 a été publié le 27/01/2020 vers 09H30.

De manière aléatoire, la coche des salariés affiliés était de couleur verte sur les prévoyances futures (au lieu de gris).
De plus, le clic sur le bouton Salariés depuis la fiche du contrat de prévoyance, puis le retour par le bouton Contrat pouvait dépositionner le contrat en cours de modification.

Une erreur « Erreur à la ligne 47 du traitement Méthode CréerGroupeS45G0500. Les dimensions d'un tableau doivent être positives. » pouvait survenir lors de la création d'une DADSU (ancienne déclaration).

En saisie d'une fiche cotisation, sur l'onglet Déclaration, les paramètres DSN ci-dessous sont désormais présentés dans le type d'élément Autres éléments MSA ou CCVRP au lieu de Autres éléments :
 81-903-Cotisation AFNCA
 81-904-Cotisation ANEFA
 81-905-Cotisation ASCPA
 81-906-Cotisation PROVEA

Les rubriques ci-dessous, nouvelles en norme P20V01, étaient ajoutées à tort dans les DSN événementielles :
 40.072 - Statut BOETH
 40.073 - Complément de dispositif de politique publique
 40.074 - Cas de mise à disposition externe d'un individu de l'établissement

Les bordereaux de versements à 0 n'étant pas envoyés en DSN, cela empêchait l'envoi de bordereau de régularisation pour un OC ayant des lignes qui s'annulent dans leur globalité. Désormais, si la valeur à prélever du bordereau est à 0, le bordereau est envoyé en DSN s'il est à destination d'un OC (les autres bordereaux restent non envoyés, car ne contiennent pas de sous-blocs).

Cette nouvelle correction fait suite aux corrections 202, 205 et 208 relatives à la gestion des sessions ouvertes, qui n'avaient pas complètement réglé le problème.
Désormais, dans la méthode Session:Ouvrir, en cas d'erreur survenant lors de l'ajout de l'enregistrement dans le fichier LDSESTMP, on teste explicitement s'il s'agit d'une erreur de blocage.
En effet, en l'absence de ce test explicite, on a un plantage lors du prochain ordre HyperFile exécuté. Le fait d'avoir intercepté l'erreur sur l'ajout d'enregistrement ne suffit pas à éviter cela.
Complément technique : en théorie, le fichier LDSESTMP n'étant jamais bloqué en totalité, on ne devrait pas avoir d'erreur de blocage sur un ajout d'enregistrement. Mais cela semble arriver toutefois, sans doute quand ce fichier contient un grand nombre d'enregistrements verrouillés (plus d'une centaine).

Suite à la parution de la fiche de consigne sur DSN-INFO, le paramétrage du bloc 51.019-Heures d'activité partielle a été revu afin d'obliger la saisie de la modalité d'aménagement de l'activité partielle, et la rendre compatible avec la valeur attendue. Voir l'actualité à ce sujet pour plus d’informations.

L'import DSN permet de gérer désormais l'ajout de blocs 56 - Régularisation de prélèvement à la source. Dans ce cas, le type correspond au n° de rubrique, le mois de régularisation (rubrique 001) est déduit de la date de fin de la période, et le type de régularisation (rubrique 002) est à inscrire dans la colonne ID Complémentaire (valeur 01, 02, ou 03).

Dans le cas où le début d'un code cotisation, avec un code calcul AT, correspond à une cotisation qui n'est pas AT (exemple : la cotisation 6010AT - Accident du travail et la cotisation 6010 - Maladie), et que cette dernière est paramétrée dans une ligne de bordereau agrégée avec détail par taux AT, alors le taux d'accident du travail utilisé pour détailler la cotisation agrégée était celui de la première cotisation (si calculé et taux patronal renseigné), et non celui de la cotisation AT.

Un Journal de Maintenance de la Norme DSN (JMN) a été publié (daté du 05/02/2020) dans lequel sont référencées les modifications de la norme à appliquer dans les prochaines DSN. La seule modification notable est que 3 nouveaux types blocs sont désormais attendu par l'URSSAF :
 81.075 - Cotisation Assurance Maladie
 114 - Montant de réduction des heures supplémentaires/complémentaires
 907 - Complément de cotisation Assurance Maladie (ce code était déjà attendu en norme P19V01 ; il avait été retiré de la norme P20V01
        et il revient via le journal de maintenance de cette norme P20V01).
Ces codes sont donc à (re)paramétrer dans les dossiers ayant des DSN à destination de l'URSSAF. Les entreprises qui dépendent de la MSA ne sont pas concernées car ces codes étaient déjà attendus par la MSA.

Dans la fenêtre de saisie des constantes salariés, sur l'écran présentant la liste des salariés avec les valeurs de la constante en regard de chaque salarié, toutes les colonnes qui étaient présentes dans la fenêtre de gestion des salariés ont été ajoutées.
De plus, un bouton de sélection permet désormais de filtrer les salariés affichés, avec les mêmes modalités que la fenêtre de gestion des salariés (code établissement, code service, codes profils, codes stats...).

Un bouton de sélection a été ajouté dans la fenêtre d'impression des éléments variables pour filtrer les salariés à traiter, sur le même principe que ce qui existe déjà par ailleurs, dans la fenêtre de gestion des salariés par exemple ou sur les éditions de journaux.
Les critères de sélection retenus pour l'impression sont présentés en tête de page de l'état.

Dans les fenêtres de gestion des constantes salariés et sociétés, le bouton Tout effacer avait pour effet d'effacer toutes les valeurs de la constante affichée, sans tenir compte des éventuels filtres d'affichage de la fenêtre : Personne présente ou non, payable ou non, avec une valeur renseignée ou non... Désormais, tous les filtres actifs sont appliqués : on n'efface donc les valeurs que des valeurs effectivement affichées compte-tenu des filtres actifs. Il reste cependant possible d'ignorer ces filtres en maintenant le bouton Majuscule enfoncé lors du clic sur ledit bouton.

Depuis une correction récente (niveau 234 diffusé mi-février 2020), 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 contrat "court" pouvait être ignoré lors de la création des DSN ou des bordereaux de cotisation.

Le programme de création d'une DNAC ne prenait pas en compte l'option Un établissement = Une société, spécifique au cas des cabinets de gestion immobilière, qui permet de déclarer les données de l'établissement à la place des données de la société.

Le paramétrage par défaut de l'élément DSN 51.014-Heures correspondant à du chômage sans rupture de contrat ou du chômage intempéries ne correspondait pas à un type de paramétrage « logique ». En effet, il est nécessaire pour ce bloc 51 de code 014 d'inverser le sens du nombre d'heures et du montant, car c'est une rubrique d'absence, donc de type Retenue, qui est utilisée pour alimenter ce bloc. Ce qui est fait désormais implicitement quand on renseigne le paramètre DSN 51.014 dans une fiche rubrique : cela correspond à un paramètre DSN où il y a inversion du sens sur le nombre et le montant.
De plus, à la première ouverture du dossier avec cette correction, les paramétrages existants du bloc 51 code 014, s'ils sont liés à une rubrique de type Retenue et sont sans inversion du signe, sont modifiés pour appliquer cette inversion.

Lors de la création du bordereau de versement pour un organisme MSA, le programme n'intégrait pas les blocs "82-Cotisation établissement" qui avaient été paramétrés en DSN.

Le changement de statut BOETH ne déclenchait pas les blocs changements (41) correctement.
Remarque : ce changement n'est toujours pas déclaré s'il a lieu antérieurement au 01/01/2020, étant donné que cette zone n'est attendue en DSN que depuis cette date.

Les périodes d'inactivité, créées par saisie d'une rubrique ayant un motif d'inactivité DSN, n'étaient pas transmises en DSN mensuelle sous forme de bloc 65-Autre suspension du contrat de travail si les dates de la période d'inactivité ne coïncidaient pas avec le mois principal déclaré de la DSN. Si on saisissait sur un mois M une période d'inactivité du mois M-1, celle-ci ne se retrouvait pas dans la DSN du mois M, provoquant un rejet de la DSN.
Pour éviter cela, lors de création des périodes d'inactivité à partir des éléments variables, le système renseigne automatiquement le champ Mois de déclaration en DSN de la période d'inactivité avec le mois de paye sur lequel l'élément variable a été saisi, dès lors que la date de fin de la période d'inactivité est antérieure à ce mois de paye. Et lors de la création d'une DSN mensuelle, on intègre toutes les périodes d'inactivité ayant un jour en commun avec le mois principal déclaré, ainsi que celles ayant un Mois de déclaration DSN égal au mois principal déclaré.

Depuis LDPaye, il est possible de déclencher l'interface comptable « directe » vers LDCompta, en faisant appel au serveur de messages de LDCompta.
Pour cela, LDPaye a besoin de transmettre au serveur de message un code utilisateur et un mot de passe valide dans LDCompta.
Jusqu'alors, le mot de passe transmis au serveur de message était limité à 10 caractères. Or, depuis la version 9.50 de LDPaye et la version 11 de LDCompta, on peut définir des mots de passe pouvant aller jusqu'à 20 caractères. Cette correction permet donc de gérer ces mots de passe à plus de 20 caractères dans les échanges entre LDPaye et LDCompta.
Bien entendu, si dans la fenêtre de lancement de l'interface comptable de LDPaye, on renseigne un mot de passe à plus de 10 caractères, ou si l'on coche l'option Reprendre utilisateur courant et que l'utilisateur courant a lui-même un mot de passe à plus de 10 caractères, cela ne peut fonctionner que si l'on a la version 11 de LDCompta en face. La version 10 de LDCompta est toujours limitée à 10 caractères pour les mots de passe des utilisateurs.

Par ailleurs, pour plus de sécurité, le mot de passe éventuellement saisi dans la fenêtre de lancement de l'interface comptable est désormais enregistré, dans le paramètre programme COMPTA_XXX, sous forme chiffrée (même procédé de chiffrement que celui utilisé dans la table des utilisateurs), et non plus en clair comme auparavant.
En position 101 à 110 de ce paramètre programme, là où on trouvait le mot de passe en clair, on a désormais une suite 10 caractères *. Le mot de passe chiffré est enregistré aux positions 237 à 300 (maxi 64 caractères).

Le mécanisme de neutralisation de la tranche A, tel que décrit en page 97 de la documentation Nouveautés de la version 8.00, ne fonctionnait pas pour les cotisations de retraite RUAA T2. En effet, ce principe de neutralisation de la tranche A ne s'appliquait qu'aux cotisations Tranche A (coefficient plancher = 0 et coefficient plafond = 1) et Tranche B (coefficient plancher = 1 et coefficient plafond = 4). Les cotisations RUAA T2 ayant un coefficient plancher = 1 et coefficient plafond = 8 étaient de ce fait ignorées. Avec cette correction, elles sont traitées au même titre que des cotisations Tranche B.
De plus, une modification complémentaire a été faite pour que la cotisation CET T1 soit traitée comme une cotisation T1 classique en cas de neutralisation de la Tranche A, et donc ignorée. Ainsi, on ne voit apparaître sur le bulletin que la cotisation CET T2 sur la totalité du brut. Sans cela, on trouvait une cotisation CET T1 limitée au plafond, plus une cotisation CET T2 sur la totalité du brut.

Complément d'information : quand on neutralise ainsi la tranche A sur un bulletin, bien souvent pour établir un bulletin après le départ du salarié pour verser des indemnités suite à une décision de justice, les cotisations Complément Maladie et Complément Allocations Familiales ne se calculent pas, étant donné qu'il n'y a pas d'heures effectuées et donc pas de montant SMIC de référence. Si on souhaite déclencher ces cotisations, il faut forcer une valeur de SMIC « fictive » non nulle de telle sorte que le brut soumis à ces deux cotisations se trouve supérieur au seuil de déclenchement de ces cotisations qui est calculé par rapport à ce montant SMIC, avec un multiplicateur de 2,5 ou 3,5.
Pour forcer le montant SMIC, lu dans le cumul MTSMIC, le plus simple est de saisir une petite valeur non nulle (par exemple, 0,01) sur la rubrique 5976 prévue à cette fin. Et si cette rubrique 5976 n'existe pas, on peut saisir une valeur 0,01 dans le nombre de l'élément variable automatique déclenché sur la rubrique 5975 (faire un premier calcul de bulletin en tenant la touche Majuscule enfoncée pour que cet élément automatique soit visible en saisie des éléments variables et puisse donc être complété).

Afin de permettre le dépôt d'une DADS-U à destination de l'AGIRC-ARRCO, il est désormais possible de créer une DADS-U dans les normes V01X14 ou V01X15. Dans ces cas, la nature des déclarations devra être 07 - IRC Agirc-Arrco, ou 08 - Prévoyance (la même nature pour tous les établissements sélectionnés). Pour une nature 07, le code service (S10.G01.00.009) sera alors également défini avec la valeur 47 - Agirc-Arrco.

Correction d'une anomalie du dernier correctif. Une erreur « L'objet dynamique 'MonContratPrec' n'a pas encore été alloué » pouvait arriver pendant la création de DSN. Ce cas pouvait notamment se produire lorsqu'un salarié est déclaré pour la 1ère fois en DSN (pas présent dans la DSN précédente). Cela arrive donc plus fréquemment sur des DSN de test car comme le programme compare la DSN avec la précédente DSN de test, et que des DSN de test ne sont (généralement) pas faites chaque mois, cela augmente la probabilité d'avoir un nouveau salarié déclaré.

Le journal de maintenance de la norme DSN a été mis à jour dans sa version 5. Ce correctif rassemble donc les modifications appliquées suite à cette mise à jour (essentiellement au niveau des contrôles).
La seule modification importante concerne les paramètres DSN du bloc 81, pour les codes 072 et 079 (respectivement pour la cotisation CSG, et cotisation CRDS) qui sont désormais attendus par l'URSSAF. Ces 2 paramètres sont désormais regroupés dans le type Assiettes principales (au lieu de Autres éléments MSA ou CCVRP).

Par ailleurs, pour éviter de devoir dissocier la cotisation existante 6750-CSG CRDS NON DEDUCTIBLE au taux de 2,90% en 2 cotisations distinctes CSG au taux de 2,40% et RDS au taux de 0,50%, uniquement pour permettre la distinction en DSN, on a introduit un mécanisme un peu particulier lors de la constitution d'une DSN. Si lors de la préparation de la DSN, une même cotisation est référencée par les 2 paramètres (81.072 et 81.079), au lieu de se retrouver avec l'assiette et le montant déclarés sur ces deux blocs totalement identiques (ce qui aurait été le cas en l'absence de tout artifice), le montant déclaré en bloc 81 code 079 (RDS) est recalculé en appliquant un taux de 0,5 % sur l'assiette extraite via le paramètre. Le montant ainsi calculé est affecté sur le bloc 81 code 079 et déduit de celui affecté au bloc 81 de code 072 (CSG). On se retrouve donc au final avec deux blocs 81.072 et 81.079 ayant la même assiette, mais pas le même montant. La somme des deux montants correspond à ce qu'on trouve sur le bulletin pour la cotisation CSG-CRDS ainsi éclatée.

Autre modification bien utile pour la cotisation CSG : le montant qui doit être déclaré en bloc 81.072 doit être la somme des deux cotisations 6750-CSG-CRDS NON DEDUCTIBLE (une fois la part de RDS retirée comme expliqué ci-dessus) et 6760-CSG DEDUCTIBLE. Mais l'assiette ne doit être prise qu'une seule fois, en principe sur la première cotisation 6750.
Or, pour un même paramètre, ici le paramètre DSN 81.072, on ne pouvait pas facilement configurer une cotisation qui soit sommée en Assiette et en Montant, et une autre en Montant uniquement. Ce type de paramétrage « non standard » ne pouvait être fait depuis la fiche Cotisation. Il fallait aller dans les paramètres DSN pour renseigner cela, ce qui n'était pas très naturel.
On a donc introduit une fonctionnalité complémentaire pour ce paramètre DSN 81.072, qui est désormais dédoublé quand on est dans une fiche cotisation :
 - 81.072(AM) - Contribution sociale généralisée/salaires partiellement déductibles (Assiette et Montant)
 - 81.072(M) - Contribution sociale généralisée/salaires partiellement déductibles (Montant seul)
On peut ainsi utiliser le premier paramètre pour la cotisation 6750, le deuxième pour la cotisation 6760.

Une nouvelle option a été introduite pour forcer la réponse de la méthode Session:SuisJeSeul.
Cette méthode renvoie Vrai si la session courante est la seule session ouverte en paye dans le répertoire de données courant.
Si ce n'est pas le cas, lors des calculs de bulletins, les fichiers de calcul sont refermés après chaque calcul et une temporisation de 3/10ème de seconde est introduite entre 2 calculs de bulletin successifs, de manière à permettre à un éventuel calcul lancé depuis un autre poste de travail de s'intercaler entre ces deux calculs successifs demandés sur le poste courant.

Or, il semblerait que lorsque le fichier LDSESTMP utilisé par cette méthode Session:SuisJeSeul comporte un grand nombre d'enregistrements verrouillés (donc de sessions actives), cet appel répété (pour chaque calcul de bulletin) à la méthode Session:SuisJeSeul peut poser des problèmes (fichier LDSESTMP indisponible pour réindexation automatique en cours notamment).
On peut donc désormais éviter la lecture systématique du fichier LDSESTMP en forçant la réponse à la méthode Session:SuisJeSeul .
Il faut pour cela créer un fichier LDSESTMP.INI dans le répertoire des mises à jour centralisé et renseigner la valeur du mot-clé SuisJeSeul dans la section LDPaye :
 - Valeur 0 ou N : la méthode Session:SuisJeSeul renverra toujours Faux (c'est ce qu'on souhaite dans les environnements où il y a un grand nombre d'utilisateurs en paye).
 - Valeur 1 ou O : la méthode Session:SuisJeSeul renverra toujours Vrai.
Pour toute autre valeur, ou si ce fichier n'existe pas, ou si le mot-clé n'est pas renseigné, le système fonctionne comme auparavant, en lisant le contenu du fichier LDSESTMP.FIC.

Le GIP-MDS a publié une nouvelle fiche consigne 2204 détaillant l'utilisation des valeurs de réserve prévue dans la norme P20V01.
Parmi d'autres éléments, il est évoqué le cas des codes 92 et 93 pour les blocs 54.
Ceux-ci doivent désormais être utilisés pour déclarer les cotisations patronales de prévoyance, santé et retraite supplémentaire, un peu comme le fait sur les blocs 79 de code 04 et 05.
Mais, ce serait trop simple, on ne peut pas récupérer directement le paramétrage de ces blocs, car les regroupements ne sont pas faits de la même façon :
 - en bloc 79, on déclare en code 04 les cotisations patronales Prévoyance et Frais de santé, en code 05 les cotisations Retraite supplémentaire
 - en bloc 54, on doit désormais déclarer en code 92 les cotisations patronales Frais de santé, en code 93 les cotisations Prévoyance et Retraite supplémentaire.
Pour arriver à cela, la gestion des types de contrat a été revue. Là où le type ne pouvait prendre que deux valeurs Prévoyance (au sens large, englobant les frais de santé) ou Retraite supplémentaire, on a désormais 4 valeurs possibles :
 - Prévoyance : déclarés en bloc 54 code 93 et bloc 79 code 04
 - Santé : déclarés en bloc 54 code 92 et bloc 79 code 04
 - Retraite supplémentaire : déclarés en bloc 54 code 93 et bloc 79 code 05
 - Autre : non déclarés en bloc 54 code 92 ou 93, ni en bloc 79 code 04 ou 05 (cela ne concerne que certains contrats particuliers
   gérés par des OC mais qui ne sont pas à proprement parler des contrats de prévoyance).

Suite à l'application de ce correctif, il faut donc corriger tous les contrats de prévoyance pour leur affecter le bon type, ce qui a pour effet d'ajouter les paramètres DSN des blocs 54 code 92 ou 93 selon le cas, et éventuellement de corriger le paramétrage des blocs 79 code 04 et 05.

Au passage, une correction a été apportée dans la procédure qui ajuste les paramètres des blocs 79 suite à la validation d'un contrat de prévoyance ; il y avait en effet une erreur qui pouvait avoir pour conséquence de conserver des paramètres 79.04 ou 79.05 superflus.

Des modifications ont été faites pour que l'on puisse déclarer des montants (et pas seulement des assiettes) sur les blocs 81 de code 110 à 113.
Ces montants se retrouvent ensuite :
 - d'une part sur les blocs 81 déclarés nominativement
 - d'autre part, ils sont sommés lors de la création du bordereau de versement à une caisse de retraite, de la même façon que la réduction générale de cotisation AGIRC-ARRCO déclarée en bloc 81 sous le code 106.

Notez que ces blocs 81 ne concernent que fort peu d'entreprises : les codes 110, 112 et 113 correspondent à des exonérations de cotisations patronales de retraite complémentaires applicables dans les DOM (LODEOM) pour les entreprises affiliées à une caisse de congés payés du BTP. Le code 109 correspond à une exonération de cotisations de retraite complémentaire applicable aux entreprises et associations d'aide à domicile.

La zone dans laquelle était enregistré l'identifiant de connexion au service de dématérialisation était limité à 30 caractères, ce qui pouvait être trop court. La limite de cette zone est désormais à 60 caractères.

L'édition d'un bulletin simplifié dans lequel ne figure aucune ligne de cotisation ayant un libellé de bulletin simplifié (seulement des rubriques, ou des cotisations sans libellé de bulletin simplifié) ne s'imprimait pas correctement. Dans le cas d'une impression de plusieurs bulletins, les lignes pouvaient être imprimées sur le bulletin suivant.

Les paramètres de l'export spécifique LDCHAGPI sont désormais enregistrés dans le fichier LDPParam.ini (ou équivalent défini en ligne de commande), en lieu et place du fichier Win.ini.

La gestion des erreurs a été améliorée dans les appels aux Webservices de Neobox-RH, pour afficher un message quand un ordre HTTPEnvoie échoue côté client(dans Windev).
On peut également ignorer les éventuelles erreurs de certificat (même si l'erreur 100137 ne semble pas être gérée correctement, car même si on demande à l'ignorer, Windev continue à signaler une erreur de certificat).
De plus, quand on envoie une partie des bulletins attendus seulement, on tente d'ignorer l'anomalie disant qu'il manque des bulletins. Et après avoir demandé, via le webservice, à ignorer ce type d'erreur, on attend désormais 15 secondes (au lieu de 5 auparavant) avant de relire le statut de l'envoi. Cela semble améliorer les choses, mais lorsque le serveur répond mal, même 15 secondes d'attente ne suffisent pas. Du coup, on se retrouve encore avant un statut 2-En anomalie alors que si on attend plus longtemps (mais combien de temps ?), on obtient le statut 3-En attente de validation. Ce problème sera donc à revoir plus avant très certainement.

Lors de la création des chemins vers la GED, il était possible que des caractères spéciaux s'y glissent, entraînant alors un échec de la création du répertoire. Il y a désormais un formatage du nom des répertoires lors de l'initialisation des chemins vers la GED.

Afin de pouvoir paramétrer les mesures d'aides au paiement des cotisations pour les entreprises affectées par les mesures sanitaires (prévues par le gouvernement en juin dernier), les codes 81-910 et 82-023 ont été modifiés afin de pouvoir être saisis ou paramétrés, et que leurs valeurs soient ainsi remontées dans les DSN et les bordereaux de versement.

La majoration Assurance chômage de 0,5% qui s'appliquait aux CDD d'usage a été abandonnée en Avril 2019.
Mais il reste un cas particulier, celui des dockers, où cette majoration perdure.
Or, la date limite d'application de cette majoration avait été mise « en dur » à 04/2019 dans le programme de calcul des bulletins.
Désormais, on peut demander à calculer cette majoration au-delà de ce mois 04/2019. Il faut pour cela créer une constante générale nommée *MCDDU avec une valeur comprise entre 201905 et 205012. Cette valeur sera alors prise comme mois limite d'application de cette majoration en lieu et place de 201904.
La création de cette constante générale n'est à prévoir que si l'on traite des payes Dockers dans le plan de paye, ce qui reste un cas très particulier.

L'ouverture d'un dossier déjà migré en version 10 provoquait une erreur non gérée. Désormais le message d'erreur est explicite.

Une fenêtre d'information a été ajoutée à l'ouverture du dossier pour informer les utilisateurs que la version 10 de LDPaye est disponible et doit être utilisé pour les déclarations à partir de janvier 2021. Ce message sera affiché à la 1ère ouverture d'un dossier chaque jour, pour chaque utilisateur LDPaye, jusqu'à mi-février 2021.