Une case à cocher "Calculer par établissement" a été ajoutée dans la fenêtre de calcul des effectifs. Si cochée (par défaut pour les dossiers avec spécifique immobilier activé), le calcul sera donc effectué par établissement.

Le barème de prélèvement à la source a été mis à jour selon le projet de loi de finance 2021.

Report de la correction V9.60 niveau 274.
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.

Le code IDCC n'était pas inscrit en DSN dans les blocs 06 et 11 (nouvelles rubriques de la norme P21V01).

La saisie d'un retour chariot était possible à tort dans la convention collective, ce empêchait l'affichage des classifications ajoutées à cette convention. Ces classifications étaient alors rattachées, dans la liste déroulante des conventions, à une ligne vide (affichée également à tort).

Le marquage des anomalies contenues dans les comptes-rendus métiers (CRM) de la DSN a été revu afin de permettre de marquer toutes les anomalies (et non pas que certaines comme auparavant) comme traitées, et ainsi faire en sorte que ces retours DSN ne soient plus considérés comme contenant une anomalie.
Le marquage se fait désormais par un bouton qui apparaît sous le contenu du retour, lorsque celui-ci contient une anomalie (traitée ou non). Pour marquer l'anomalie en traitée, il suffit de cliquer sur ce bouton. Pour démarquer après coup, il faut tenir Ctrl enfoncé lors du clic sur ce même bouton.

Une nouveauté, déjà existante dans LDCompta, a été ajouté dans l'ergonomie de LDPaye : on peut désormais afficher les menus dans une barre latérale de menus, que l'on peut placer à gauche ou à droite de la fenêtre principale.
Cette barre de menus reprend fidèlement toutes les options apparaissant dans la barre de menus traditionnelle, en tenant compte des sécurités ; seules les options auxquelles l'utilisateur courant est autorisé sont affichées.
La visibilité, l'emplacement et la largeur de cette boîte de menus est mémorisée indépendamment pour chaque utilisateur de LDPaye.
L'intérêt de cette barre de menus, par rapport aux menus traditionnels, est qu'elle permet de conserver visible la dernière option sélectionnée. On peut ainsi facilement enchaîner plusieurs options au sein d'un même sous-menu (lancement de plusieurs journaux par exemple, ou suite des traitements à exécuter pour les virements).

Le bandeau indiquant que le dossier est en mode simulation n'apparaissait pas correctement.

La déclaration des organismes destinataires des "DSN sans individu" ne correspondait pas à l'utilisation attendu en DSN des blocs 08. Contrairement à ce qui était fait, ces blocs 08 ne doivent pas être déclarés lors d'une "DSN sans individus", mais au contraire pour signaler un organisme pour lequel il n'y a plus de salarié affilié à un organisme, alors que la DSN contient bien d'autres salariés (affiliés à d'autres organismes). Ce cas de figure ne semble pas possible parmi nos utilisateurs, la liste des organismes destinataires, dans la fiche établissement, a donc été supprimée, et aucun bloc 08 ne sera généré en DSN.

Pour faire face aux nombreux problèmes de certificats rencontrés lors de l'appel des webservices de Neobox-RH, une partie des appels à ces webservices a été réécrite. On peut désormais, en fonction d'un paramètre programme nommé DEMATRH :
 - Ignorer toutes les erreurs de certificats. Cette option était déjà offerte via une case à cocher dans la fenêtre d'envoi des bulletins.
   Elle a déplacée dans le paramètre programme DEMATRH et son fonctionnement est maintenant un peu différent. Avant, 
   on envoyait chaque requête une première fois sans ignorer les erreurs de certificats, puis une deuxième fois en ignorant les
   erreurs de certificat si nécessaire. En procédant ainsi, on pouvait avoir une erreur de certificat 100137 qui persistait même
   si on l'ignorait lors du 2ème envoi, ou on avait une erreur 100138 la 2ème fois, erreur qui elle persistait même si on demandait à l'ignorer.
   Désormais, si on a activé l'option pour ignorer les erreurs de certificats, on ignore tous les types d'erreurs de certificat dès le premier
   envoi de chaque requête. Et ainsi, ça fonctionne mieux.
 - Gérer tous les appels aux webservices via les fonctions Windev httpRequete plutôt que de passer par des variables httpRequete.
   En effet, les fonctions httpRequête utilisent les API WinInet de Windows contrairement aux variables htppRequête. Le comportement
   n'est donc pas tout à fait le même selon la méthode employée, notamment pour la gestion des certificats.
Ces deux options s'activent via le paramètre programme DEMATRH, via les deux premiers caractères de la valeur alphanumérique de celui-ci, caractères où l'on doit indiquer O=Oui ou N=Non.
Si ce paramètre n'est pas renseigné, tout se passe comme si on avait indiqué N=Non pour la première option Ignorer les erreurs de certificats et O=Oui pour la deuxième option Utiliser les fonctions httpRequête.

Avec ces deux options, sur le PC utilisé pour les tests (PCJOCELYN3), on arrive au résultat suivant :
 - Ca fonctionne si on active l'option Utiliser les fonctions httpRequête même sans activer l'option Ignorer les erreurs de certificats.
 - Ca fonctionne si on n'active pas l'option Utiliser les fonctions httpRequête, mais à condition d'activer l'option
   Ignorer les erreurs de certificats ou de désactiver, dans les options de l'antivirus ESet, le filtrage du protocole SSL/TLS.

Dans le calcul du PAS, on a besoin d'isoler le montant des IJ soumises au PAS, notamment pour les apprentis et les abattements CDD (les IJ soumises au PAS le sont toujours pour les apprentis, indépendamment du seuil annuel d'imposition).
Ce montant IJ soumises au PAS était calculé par différence entre le net fiscal et l'assiette du PAS en tout début du calcul de la cotisation 7050PS. En 2021, cela ne peut être fait ainsi, car on a aussi le montant des Heures sup. défiscalisées qui vient en différence entre le net fiscal et l'assiette du PAS.
Du coup, suite à cette correction, le montant des IJ soumises au PAS est calculé non plus par différence  Assiette PAS - Net fiscal, mais en sommant tous les montants trouvés sur le bulletin sur la rubrique 7050PI (plus précisément, sur la rubrique dont le N° est fourni dans la rubrique spécialisée  BUL - Montant des IJSS soumis au PAS, visible sur l'onglet Calcul des Paramètres généraux).
Au passage, on a aussi modifié l'intitulé de la première ligne dans le cadre d'explications lorsqu'on clique en mode Expliquer sur la cotisation PAS 7050PS : la mention Net imposable a été remplacée par Net fiscal hors HS.

En parallèle, il a été décidé de doubler la rubrique 5940 - Dont montant défiscalisé en 7050HS, pour aider à la compréhension de la différence entre le montant Net fiscal et l'assiette du PAS.

Afin d’homogénéiser les logiciels, les raccourcis d'affichage et de déplacement droite/gauche du menu latéral ont été modifiés. Désormais il faut utiliser, respectivement, les touches Ctrl+F3 pour afficher/masquer le menu latéral et Ctrl+Shift+F3 pour basculer ce menu de gauche à droite ou inversement.

Le contrôle de cohérence entre le N° de caisse CP et la nature de caisse CP, dans les situations et établissements, a été amélioré du fait de l'ajout des n° de caisse CP autres que BTP en V10. La nature de caisse CP découle désormais automatiquement du n° de caisse saisi.

Le lien de la page de téléchargement de l'outil DSN-VAL, ainsi que les versions installées et disponibles, n'étaient pas correctement affichés lorsque l'outil n'est pas téléchargeable pour la version de Java sélectionnée, dans la norme DSN sélectionnée. C'est désormais le cas en 32 bits, à partir de la norme P21V01. Cela n'avait toutefois aucun impact sur l'ouverture de la page, qui était fait avec le bon lien.

Les regroupements et libellés des éléments imprimés sur l'édition DSN en détail, sous le tableau principal du versement du salarié, ont été revus afin d'intégrer les nouvelles cotisations déclarées en norme P21V01 (et notamment toutes les cotisations SS à destination de l'URSSAF, jusque-là uniquement à destination de la MSA ou CCVRP).
Les cotisations déclarées en bloc 81, en dehors des cotisations Maladie, Allocations familiales et de leurs compléments qui apparaissent dans le corps principal du tableau, sont désormais groupées en Cotisations SS, Assurance chômage, Transport (une ligne par code INSEE commune), CSG/CRDS sur revenus d'activité, Autres cotisations patronales, Prévoyance. Et suite à ces groupes, on trouve tous les éléments déclarés « divers », donc non regroupés : heures supplémentaires ou d'activité partielle, primes, avantages en nature, frais professionnels, bases spécifiques, exonération de cotisations...

Si le premier rafraîchissement du widget Actualités du tableau de bord n'aboutissait pas, le rafraîchissement était répété indéfiniment. Le sablier était alors continuellement affiché, par intermittence.

Courant 2020, une distinction avait été faite dans les paramétrages DSN sur le code 81-072 afin de permettre de cumuler le montant de CSG sans l'assiette, et ainsi déclarer la CSG non déductible et la CSG déductible sur le même bloc DSN. On avait donc depuis lors le choix entre les paramètres 81.072(AM) et 81.072(M). Du fait de l'ajout du taux de cotisation dans les blocs 81 à partir de la norme P21V01, cette distinction ne doit plus se faire car les blocs 81 sont désormais cumulés par taux ou assiette identiques. Il faut donc calculer l'assiette sur toutes ces cotisations, afin qu'elles soient ensuite regroupées par taux ou assiette identiques.
Pour assurer la transition entre les normes P20V01 et P21V01, la distinction entre 81.072(AM) et 81.072(M) n'a pas été supprimée, mais désormais, sur les DSN de norme P21V01 (et futures), les cotisations paramétrées sur le code 81-072(M) sont calculées comme si elles avaient été paramétrées en 81-072(AM).

Le nouvel outil de contrôle DSN apparu en version 10 ne traite pour le moment que les données déclarées au titre du mois principal. On ignore tous les blocs 78-Base assujettie et leurs dépendances (blocs 79 et 81) afférents à des périodes antérieures (régularisations de cotisation).
Jusqu'alors, on ignorait également les blocs 51-Rémunération afférents à des périodes antérieures (rappels de salaire ou d'heures supplémentaires le plus souvent). Mais cela entraînait bien souvent des anomalies lors du rapprochement entre les blocs 51.001-Rémunération brute non plafonnée et 78.03-Assiette brute déplafonnée.
Désormais, si lors du contrôle de la DSN, on détecte au moins un bloc 51 rattaché à une période antérieure au mois principal déclaré, on pose la question pour savoir si on doit sommer ou pas ces rémunérations antérieures :
On trouve dans cette DSN un ou plusieurs blocs 51-Rémunération rattachés à une période antérieure au mois principal déclaré.
Voulez-vous inclure ces rémunérations pour les rapprochements effectués avec les blocs 78-Base assujettie du mois principal ?
Si ces rémunérations sont des rappels de salaire ou d'heures supplémentaires payés ce mois-ci sans entraîner de régularisation de cotisations antérieures (cas le plus fréquent), répondez Oui.
Si ces rémunérations antérieures ont nécessité des régularisations de cotisations au titre des mois afférents à ce rappel (par exemple, rappel de salaire après le départ du salarié, suite à une décision de justice), répondez Non.
Notez que la réponse est globale pour un fichier contrôlé. Dans le cas où l'on a des rémunérations antérieures concernant plusieurs salariés distincts, on ne peut pas opérer de choix propre à chaque salarié.

Au passage, le fichier des règles de contrôle a fait l'objet d'une petite modification concernant le cas des régularisations de réduction générale (CTP 669) où il y avait un problème : on lisait le montant alors que pour ce CTP, le montant de la régularisation est déclaré en tant qu'assiette.

Une anomalie dans la création du fichier de sauvegarde SVL générait des sauvegardes mal sécurisées. De ce fait, les sauvegardes faites antérieurement à ce niveau étaient restaurées sans demander de mot de passe (comme si elles provenaient du même environnement). Avec cette correction, les sauvegardes faites avant ce niveau seront repérées et le mot de passe sera systématiquement demandé (même si la sauvegarde est issue du même environnement). Pour les sauvegardes faites après ce niveau, le mot de passe n'est demandé que pour les sauvegardes issues d'un autre environnement.

Le menu latéral ne s'affichait pas correctement en fonction de la position du ruban principal.

Plusieurs modifications ont été apportées à l'outil de script de modification du plan de paye :
- La suppression des paramétrages DSN sur un élément provoquait une erreur 0 à tort.
- Il n'était pas possible de récupérer la valeur saisie d'une variable (pour un conditionnement par exemple),
  mais uniquement l'existence de l'élément saisi, ou la valeur de l'élément dans le plan de paye.
  Désormais, il faut précéder la variable par "_" pour que ce soit la valeur saisie dans la variable elle-même qui soit utilisée en test.
- La saisie d'un paramètre DSN avec la mention "(AM)" ou "(M)" est désormais possible (cas du 81.072)

Le message d'avertissement des paramètres DSN indispensables manquants, lors de la création d'une DSN, affichait à tort des paramètres DSN qui étaient marqués indispensables dans les normes précédentes, mais qui sont supprimés dans la norme avec laquelle est créée la DSN.

Le calcul des blocs 81.72 et 81.079 qui sont censés être diminués de 0.5 % (81.072) ou recalculé à 0.5 % (81.079) n'étaient pas calculés correctement dans les normes précédentes (jusqu'en P20V01 inclus). Les montants de cotisation de ces blocs pouvaient donc être faussés.

Suite à la remontée du taux de cotisation en DSN, dans les blocs 81, les cotisations paramétrées pour un même code sont désormais regroupées par base ou taux identique. Si la somme des taux de 2 cotisations correspondait au taux d'une 3ème cotisation, ce regroupement pouvait être fait par erreur sur le taux pour ces 3 cotisations, au lieu du montant pour la 3ème. Dans ce cas, l'assiette de cette 3ème cotisation était ignorée et le taux correspondait à la somme des 3 cotisations (soit le double de ce qu'il aurait fallu).

Dans certaines configurations, la gestion des sessions ouvertes peut provoquer des crashs aléatoires.
Sachant que ce mécanisme de gestion des sessions ouvertes n'est pas indispensable au bon fonctionnement du logiciel, on a ajouté, pour un usage transitoire dans l'attente d'une solution pérenne, la possibilité de désactiver complètement tout ce mécanisme.
Pour cela, il faut créer un fichier nommé LDSESTMP.INI dans le répertoire des mises à jour centralisées (là où se trouve déjà le fichier LDSESTMP.FIC) et renseigner les 2 lignes ci-dessous :
[LDPaye]
Désactivé=1

Dès lors que le mécanisme est désactivé, on n'a plus accès à l'option de menu Fichier/Sessions actives. Et de ce fait, on ne peut plus bloquer des ouvertures de session dans une plage horaire donnée. De même, le widget Liste des utilisateurs ne peut plus être affiché sur le tableau de bord.

Enfin, pour le calcul des bulletins, lorsque ce mécanisme est désactivé, tout se passe comme s'il y avait toujours un autre utilisateur actif lorsqu'on lance le calcul d'un ensemble de bulletins : il y a attente de 3/10ème de seconde entre 2 calculs successifs de façon à permettre à un calcul demandé depuis un autre poste de travail de s'intercaler.
On peut éventuellement désactiver aussi cette attente en ajoutant le mot-clé SuisJeSeul=1 juste après le mot-clé Désactivé=1, mais c'est déconseillé : si un utilisateur lance depuis un poste donné un calcul de 50 bulletins, un calcul lancé simultanément dans le même environnement de paye depuis un autre poste de travail devra attendre la fin du calcul des 50 bulletins avant de commencer.
Pour plus d'informations sur cette dernière option, voir correction V9.60 Niveau 265.

1) Suite à la correction 37, il y avait un plantage pour les nouveaux utilisateurs (ceux n'ayant encore jamais configuré de tableau de bord en version 10) si le mécanisme de gestion des sessions était désactivé. 

2) Il n'était plus possible d'exécuter des scripts de modification du plan de paye (mauvaise compilation de l'exécutable).

L'ajout des taux dans le bloc 81 pouvait empêcher la création de certains blocs 81 code 059.

Dans le cas où plusieurs lignes du bulletin, dont certaines avec des dates, étaient présentes sur un bulletin et se rapportaient à un même bloc DSN 51-Rémunération (tous codes de ce bloc 51, sauf 002 et 019), une partie des données présentes sur le bulletin n'étaient pas reprises en DSN.

La version 2021.1 de l'outil de contrôle DSN-VAL, pour contrôler vos déclarations dès janvier 2021, n'est plus disponible qu'en version 64 bits, contrairement aux versions antérieures qui était proposées en version 32 ou 64 bits, en fonction de l'environnement d'exécution Java installé sur votre ordinateur. Afin de contourner les soucis inhérents aux différentes versions de Java possiblement installées sur les postes de travail, une version de Java 64 bits (dit Module Java pour LDPaye) sera désormais téléchargée et utilisée lors du lancement de DSN-VAL à partir de la version P21V01, indépendamment de celle éventuellement déjà présente sur le poste de travail. L'installation de ce module Java sera proposée à la 1ère utilisation de l'outil de contrôle en P21V01 ou si une mise à jour est mise à disposition sur notre site.
Ce module Java ne sera pas visible dans les paramètres Windows (dans les paramètres Java du panneau de configuration) et ne sera utilisé que pour DSN-VAL (lancé depuis LDPaye ou depuis le fichier DSN-VAL.bat). Il n'interfère en rien avec les autres installations de Java déjà présentes sur le poste de travail.

La liste des nomenclatures DSN prévoit des codes caisse CP (pour les dockers) sur 3 caractères alors que le fichier n'est prévu que sur 2 caractères. Une conversion des codes sur 3 caractères est désormais réalisé dans les fichiers pour pouvoir tout de même enregistrer ces valeurs.

Ajout de la lecture des paramètres généraux pour le format de date pour Excel ainsi que le séparateur décimal, dans la procédure zLireParamètresEnvironnement (c'était un oubli lors de l'ajout du composant LDFrameworkV1).

Suite à la mise en place ces derniers jours du nouveau site Net-entreprises.fr, les liens de téléchargements pour l'outil DSN-VAL n'étaient plus valides.

La prochaine version de l'outil DSN-VAL en P20V01 a été publié (mais applicable seulement à partir de janvier 2021) et utilise le même fonctionnement que l'outil en P21V01. Pour l'instant, cette version de l'outil P20V01 ne sera pas installé en automatique. En revanche, elle sera donc utilisable avec le module JAVA pour LDPaye.
Par défaut, le module JAVA pour LDPaye, même s'il a été installé (lors d'un contrôle en P21V01 par exemple), ne sera pas utilisé lors du contrôle avec l'outil DSN-VAL en P20V01. Pour que ce soit le cas, il faudra que le fichier DSN-VAL.bat soit présent dans le répertoire d'installation de l'outil DSN-VAL en P20V01. Ce fichier peut être copié depuis le répertoire de l'outil en P21V01.
Par ailleurs, le module JAVA pour LDPaye est désormais installable manuellement par un nouveau bouton en bas à gauche de la fenêtre d'installation de l'outil DSN-VAL dans LDPaye.

En parallèle, il est aussi possible de choisir un autre répertoire que le répertoire des mises à jour centralisée pour toute cette gestion des sessions actives, en renseignant le répertoire souhaité dans le fichier de configuration LDPParam.INI, section [Données], mot-clé RepSession. Le fichier LDSESTMP.FIC sera alors créé à cet emplacement, sauf si à cet emplacement, on trouve un fichier LDSESTMP.INI qui donne l'emplacement final à utiliser, qui peut être un autre répertoire réseau (sans grand intérêt) ou les données de connexion à un serveur HFCS (comme indiqué plus haut).
Attention : le répertoire spécifié au mot-clé RepSession doit exister ; il ne sera pas créé. En revanche, le fichier LDSESTMP sera créé à cet emplacement s'il n'existe pas déjà.
Cette fonctionnalité permet de gérer autant de fichiers LDSESTMP que l'on a d'environnements différents, tout en ne conservant qu'un seul répertoire de mise à jour centralisée. Cela peut être utile dans le cas où l'on a par exemple plusieurs environnements correspondant à plusieurs clients distincts hébergés sur un même serveur Windows, partageant un même répertoire de mise à jour centralisée, et qu'on ne souhaite pas que ces utilisateurs se voient les uns les autres (données hébergées sur des serveurs HFCS distincts notamment). 

Dans le cas de l'ouverture d'un dossier de simulation, le tableau de bord est abaissé pour éviter le chevauchement de ce dernier avec le message d'information apparaissant en haut de l'écran principal.

Si l'on déplace un widget de telle sorte qu'il chevauche un autre widget, cela déplace automatiquement le widget en question. Or, ce déplacement automatique n'est pas enregistré et cela pouvait poser problème lors de la réouverture de la session puisqu'on se retrouvait avec deux widgets superposés.
Désormais, en cas de chevauchement, les widgets sont automatiquement déplacés vers la droite de l'écran à la réouverture de la session.

Dans la fenêtre d'épuration des DSN, on a désormais la possibilité d'épurer uniquement les DSN de type Test ou de type Réel.

1) Création automatique des blocs 30-Individu et 40-Contrat
L'import de données dans une DSN est désormais en mesure d'ajouter les blocs 30-Individu (salarié) et 40-Contrat nécessaires pour importer les blocs 51, 78, 79, 81 demandés. Il n'est donc plus nécessaire d'ajouter manuellement les salariés et les contrats pour lesquels on veut effectuer des régularisations par import de donnée, ajout qui devait se faire auparavant lors de la création de la DSN et qui était assez délicat.
Les données du bloc 30-Individu sont extraites de la Fiche salarié au moment de l'import.
Les données du bloc 40-Contrat sont extraites de la situation en cours à la date de fin de la période de rattachement indiquée ligne par ligne, dans le fichier importé, avec même si nécessaire création de plusieurs blocs 40 si les périodes à régulariser correspondent à différents contrats successifs du salarié. Il y a aussi création des 71-Retraite complémentaire et 86-Ancienneté associés à chaque contrat. Et pour les contrats antérieurs pour lesquels les informations de fin de contrat ont été renseignées, il y aussi ajout du bloc 62-Fin de contrat correspondant.
Les autres blocs que l'on peut rencontrer en tant que bloc fils d'un bloc 30-Individu ou 40-Contrat (adhésion prévoyance, changements de contrat, ...) ne sont pas générés.

Afin d'améliorer la lisibilité des informations de prévoyance sur l'état de contrôle DSN, le code contrat de prévoyance a été ajouté sur les lignes d'adhésion (blocs 15), d'affiliation (blocs 70), et détails (blocs 79, 81). Ce code contrat est également repris dans les totaux. Le libellé du contrat de prévoyance a lui été supprimé du libellé de chaque valeur dans les totaux (plus nécessaire du fait de l'ajout du code contrat), car étant trop long, il était tronqué et empêchait de visualiser le type de valeur affiché.

Une désactivation optionnelle du cache Internet, tant navigateur que dans l'entête des requêtes HTTP, a été ajouté dans les procédures de récupération des retours de l'API-DSN. Pour désactiver les caches, il faut créer le paramètre programme APIDSN et indiquer la valeur O en 3ème paramètre (chaque paramètre étant séparé par ";").
Un 4ème paramètre permet également d'ignorer les requêtes sur certaines URL. Cela ne doit être utilisé que par des personnes dûment informées car cela peut empêcher l'accès à certaines fonctions, avec le risque de ne plus recevoir certains CRM ou de bloquer le fonctionnement pur et simple de l'API-DSN.

Le fichier créé spécifiquement pour le logiciel de gestion immobilière était déclaré, si le spécifique est activé, à chaque création de bordereau de versement DSN, et non au lancement de l'ensemble des créations demandées.

Le champ Pourcentage partage plafond ayant pour masque 99,9999 ne pouvait être saisi qu'avec 3 décimales car il était trop étroit.
Les champs de l'onglet Bulletin ont donc été redimensionnés pour y remédier.

Le script générait une erreur, qui arrêtait son exécution, lors de la copie des liaisons depuis un autre élément (par exemple : copie des rubriques liées à la cotisation 6010 sur la cotisation 6020).

En cas de paramétrage DSN de plusieurs contrats de prévoyance sur une même cotisation, paramétrage concernant une cotisation établissement (bloc 82), lors de la création du bordereau de versement, tous les paramètres étaient calculés et donnaient lieu à un bloc 82, et ce même pour les contrats auxquels le salarié n'était pas affilié. Du coup, cela provoquait des doublons dans le bordereau. Pour éviter cela, on ne traite désormais que les paramètres des contrats auxquels le salarié est affilié.

Lors de la création des enregistrements relatifs à la taxe sur les salaires pour transmission en DSN, suite à l'impression de l'état de taxe sur les salaires pour l'année entière, la nouvelle rubrique TYPE du fichier PEETCO en version 10 n'était pas renseignée à la valeur TS. Du coup, on ne voyait pas ces enregistrements quand on ouvrait la fenêtre de gestion Assujettissement à la taxe sur les salaires (menu Traitement mensuel/Autres données DSN).
Par ailleurs, la détection des établissements non assujettis pour lesquels on avait créé des enregistrements pour la taxe sur les salaires se faisait mal, avec de ce fait des messages d'anomalie s'affichant à tort.

A la première ouverture de chaque dossier de paye faisant suite à l'installation de ce correctif, le code source des fonctions personnalisées liées à l'activité partielle TACTPI et TACTPL est automatiquement adapté en prévision de l'année 2021.
Les valeurs 8,03 et 0,70 sont remplacées par des références à 2 nouvelles constantes générales MACTPI et TACTPI qui sont créées automatiquement, avec un historique de telle sorte qu'en cas d'activité partielle sur 2020, ce soit bien les valeurs 8,03 et 0,70 qui soient prises en compte.
Notez que lors de la création de la constante générale MACTPI, si le dossier de paye est déjà sur 2021, la valeur est positionnée à 8,11 au lieu de 8,03, pour tenir compte de la nouvelle valeur du SMIC en 2021.
Toujours dans le code source de ces fonctions, on a jouté un plafonnement du taux d'indemnisation à 70% de 4,5 SMIC dès lors que l'activité partielle concerne une période sur 2021 (date début >= au 01/01/2021).

La correction niveau 82 qui contrôle l'affiliation du contrat lors du calcul des blocs 82 était liée, par erreur, à l'affiliation du salarié, alors que ces cotisations établissement ne sont généralement pas déclarées par salarié (en bloc 81-059), mais uniquement au niveau établissement (en bloc 82). L'affiliation des salariés ne doit donc pas être utilisée dans ce cas. Le contrôle est donc désormais fait sur l'affiliation de l'établissement uniquement.

Le contrôle entre les dates début et fin indiquées en saisie ou interface d'un élément variable et les dates de début et fin du contrat, introduit par la correction N° 77, a été restreint. Il n'est désormais effectué que si l'élément variable porte sur une rubrique qui est déclarée dans l'un des blocs :
  51-Rémunération code 001-Rémunération brute non plafonnée
  51-Rémunération code 002-Salaire brut soumis à contributions d'Assurance chômage
  52-Prime et indemnité code 026-Prime exceptionnelle liée à l'activité avec période de rattachement spécifique
  52-Prime et indemnité code 027-Prime liée à l'activité avec période de rattachement spécifique
  52-Prime et indemnité code 029-Prime liée au rachat des jours de RTT avec période de rattachement spécifique
  65-Suspension du contrat de travail
  66-Temps partiel thérapeutique

Le niveau de droit d'accès aux sociétés de l'utilisateur est dorénavant contrôlé lors de l'impression des comptes-rendus DSN. Ce contrôle était déjà présent lors de la modification et visualisation d'un compte rendu. Ce contrôle a aussi été appliqué lors du marquage Tout marquer comme lu.

Suite à la correction niveau 82, les blocs 82-Cotisations établissement, à destination de la MSA, qui n'ont (par définition) pas de lien avec des contrats de prévoyance, n'étaient plus créés dans les bordereaux de versement.

La correction du niveau 79 est reportée sur la fenêtre de saisie/affichage d'une Fiche salarié (disposition des champs sur l'onglet Bulletin).
Dans cette même fenêtre, le champ NOPE a été déplacé car il était superposé à un autre champ, le rendant illisible.

Le répertoire "démarrer dans" des raccourcis créés lors de l'installation de DSN-VAL P21 était manquant, ce qui empêchait l'exécution depuis le bureau ou le menu démarrer.
De plus un "\" était doublé (mais sans conséquence) dans le fichier de lancement de l'outil.

Pour l'affichage des CTP URSSAF que l'on observe lors de l'ajout d'une ligne dans la configuration du bordereau de versement URSSAF (menu Traitement mensuel/Paramètres DSN/Bordereau URSSAF DSN), appelés aussi « Code cotisation agrégée » dans la terminologie DSN, LDPaye procède en comparant 2 tables :
 - d'une part la table des CTP fournie par l'URSSAF, récupérée automatiquement sur le site Net-Entreprises
   comme toutes les autres tables de codification DSN (ce qui est dénommé « Nomenclatures »).
 - d'autre part une table définissant les niveaux de pertinence de ces différents CTP : Inutilisés, Peu courants, Courants, Très courants.
   Avec en regard, chaque fois qu'on les connait, les code qualifiant assiette à utiliser (920, 921 ou les deux).
   Cette 2ème table est livrée dans le fichier PAYTAB, avec code ZDAU=DSN-CTP.

C'est le contenu de cette 2ème table qui a été revue, pour tenir compte :
 - des nouveaux CTP ajoutés par l'URSSAF
 - de ceux qui ne sont plus utilisés (CICE par exemple).
 - de l'usage beaucoup plus fréquents de certains CTP (notamment ceux liés à l'activité partielle, ou ceux liés aux apprentis,
   étant donnés que les contrats d'apprentissage sont de plus en plus fréquents).

Remarque : comme indiqué plus haut, la 1ère table est mise à jour automatiquement dans LDPaye à partir du site Net-Entreprises.
Mais il faut savoir que certains CTP référencés dans des fiches consignes DSN n'ont toujours pas été ajoutés dans la table de référence URSSAF. C'est le cas par exemple des CTP 667 et 051 pour l'exonération et l'aide au paiement COVID-19, ou encore le CTP 510 relatif à la prime de pouvoir d'achat.

Au passage, dans la fenêtre modification d'un bordereau de versement ainsi que dans la fenêtre de paramétrage du bordereau URSSAF, on a ajouté la touche de fonction F2 pour basculer entre Afficher à partir d'un CTP ou Filtrer sur libellé contient, comme cela existe dans la plupart des autres fenêtres de ce type. On peut ainsi rapidement rechercher une ligne en fonction de son libellé, très pratique sur les bordereaux comportant de nombreuses lignes.

Sur certains postes de travail, de manière aléatoire et inexpliquée, on avait parfois une erreur à l'ouverture du logiciel, lors de l'affichage des nouvelles actualités. L'erreur signalée était :
Erreur à la ligne 9 du traitement Méthode AfficherSiNouvellesActualités.
L'autodiagnostic des threads a détecté un comportement interne inattendu.
Pour y remédier, on a intercepté tout type d'erreur pouvant survenir à l'ouverture de la fenêtre d'affichage de ces actualités.

Lors de la création d'un contrat de prévoyance pour un code interne qui existe déjà, toutes les données du contrat déjà existant dans une société sont récupérées : Libellé, code OC et code délégataire, Code population et option... Seule la référence de contrat n'est pas reprise.
Ainsi, si on doit saisir un nouveau contrat pour plusieurs sociétés d'un même environnement, la saisie est beaucoup plus rapide.

Au passage, deux contrôles non bloquants ont été ajoutés :
 - on vérifie qu'il y a au moins un établissement affilié au contrat
 - on vérifie que l'on dispose bien d'une référence de contrat, soit saisie sur le premier onglet, soit saisie
   sur chaque établissement affilié sur le 2ème onglet.

Des valeur invalides sont parfois présentes dans la zone "organisme de base" des situations des salarié. Cela peut entraîner un mauvais calcul des bordereaux (URSSAF) et de la DSN. Un outil sera lancé à la première ouverture du dossier avec ce correctif afin de rétablir ces valeurs invalides.

Diverses optimisations ont été apportées dans les phases de préparation/calcul d'une DSN mensuelle d'une part, des bordereaux de versement DSN d'autre part. Ces optimisations sont particulièrement sensibles dans les contextes suivants :
 - un grand nombre de salariés (plus d'une centaine)
 - un grand nombre d'établissements dans un même envoi DSN.
Dans ces configurations, le temps total nécessaire à l'élaboration des bordereaux de versement et de la DSN mensuelle peut être divisé par 2, voire par 3.

Il est désormais possible de définir le mode HTTP du formulaire d'envoi des DSN via l'API. Pour cela, il faut inscrire la valeur de mode souhaitée  ("0" par défaut, "1" ou "2") dans le 5ème paramètre (séparé par ";") du paramètre programme APIDSN.
Par ailleurs, lors du dépôt d'une DSN par l'API-DSN, la syntaxe de la clause Content-Encoding: gzip a été corrigée : on avait un espace en trop entre Content-Encoding et le caractère :. C'est cela qui, depuis le 26/01/2021, provoquait le rejet des déclarations déposées depuis d'anciens systèmes d'exploitation (Windows 7, Windows Serveur 2008 et 2012). Car sur les systèmes plus récents comme Windows 10, cette faute de syntaxe est automatiquement corrigée par la couche API WinINET de Windows, l'en-tête HTTP envoyé est donc correct.
Cela étant, cette syntaxe incorrecte Content-Encoding : gzip était accepté avant le 26/01/2021 et ne l'est plus depuis cette date, sans doute en raison de changements opérés sur les serveurs de Net-Entreprises en même temps que la bascule en norme P21V01.

Suite à des modifications opérées sur les serveurs neobox.primobox.net, l'envoi des bulletins à Neobox-RH par les web-services de LDPaye ne fonctionnait plus. On obtenait des erreurs 403 ou 400.
Complément technique : pour régler le problème, on a ajouté une directive content-type: application/vnd.ms-excel lors de l'envoi de la liste des salariés et une directive content-type: application/pdf lors de l'envoi des bulletins requête Http.

Il n'était pas possible de définir de logo différent par société. Le paramètre dans lequel le logo de société était enregistré était commun à toutes les sociétés du même dossier. Une modification des paramètres est exécutée à la première ouverture du dossier avec ce correctif afin de dupliquer le logo, s'il a été défini, dans chaque société. Le logo est donc désormais défini par société, indépendamment des autres sociétés du dossier.

Pour les environnements propres à l'immobilier, nous avons décliné le calcul de la taxe sur salaire par établissement.
Pour ce faire, deux nouveaux champs ont été ajoutés afin de préciser, pour chaque établissement assujetti, le rapport d'assujettissement (entre 0,01% et 100%) et la fréquence déclarative (mensuelle, trimestrielle ou annuelle). Ces champs sont accessibles d'une part dans la Fiche établissement, sur l'onglet Détail, et d'autre part via le bouton Liste des établissements proposé au bas de la fenêtre de lancement du calcul de la taxe sur les salaires.
Le rapport d'assujettissement est ainsi ajusté, lors du calcul, pour chaque établissement (qui est en fait une société à part entière).
De plus, on sélectionne implicitement les établissements en fonction de leur fréquence déclarative et de la période de calcul choisie :
 - si la période choisie ne couvre qu'un seul mois, seuls les établissements à fréquence mensuelle sont sélectionnés
 - si la période choisie couvre un trimestre, seuls les établissements à fréquence trimestrielle sont sélectionnés
 - si la période choisie couvre l'année complète, tous les établissement sont sélectionnés quelle que soit leur fréquence.

Remarque : à l'installation de ce correctif, pour les environnements « Immobilier », tous les établissements assujettis à la taxe sur les salaires (Coche Assujettissement à la taxe sur salaires renseignée sur l'onglet Détail de la Fiche établissement) sont initialisés avec une fréquence annuelle et un rapport d’assujettissement à 100%.

L'ouverture de la fenêtre présentant les retours DSN (CRM) d'une déclaration (depuis la liste des DSN) était anormalement longue. Une correction a été faite pour optimiser ce temps de chargement.

Des erreurs, à la compilation ou à l'exécution, pouvaient survenir si du code était écrit sur plusieurs lignes (entre [], notamment pour le source des fonctions personnalisées) et contenait une ligne finissant également par un crochet.
De plus, le code source des fonction personnalisée générait à tort des variables (si le code contenait des valeurs du type "CG.", "CS.", ...).
Les conditions ([TT.XXXX/IF.n]) généraient également des variables à tort.
Quelques modifications d'ergonomie ont également été apportées (libellés, ancrage des champs).

L'option de démarquage de l'anomalie traitée (pour la remettre en non traitée) nécessitait l’appui de la touche CTRL lors du clic sur le bouton. Cette sécurité était exagérée par rapport au risque de clic malencontreux, elle a donc été enlevée.

Certains salariés n'apparaissaient pas dans le calcul des effectifs : c'était ceux dont le contrat commençait dans le mois d'arrêté demandé.
Au passage, on a fait quelques modifications d'ergonomie :
 - on affiche par défaut les en-têtes de colonnes et de la barre de formule dans le tableau présentant les résultats.
   Cela permet d'ajuster facilement les largeurs de colonnes.
 - les colonnes de droite où figurent des codes et libellés ont été élargies et sont désormais cadrées à gauche et non plus centrées.
   On peut lire ainsi le début du libellé. 

Lorsqu'on tentait de faire une régularisation de cotisations sur le bulletin du dernier salarié dans un environnement de paye donné, on obtenait une erreur :
La régularisation de cotisation demandée au travers de la ligne rubrique 9999 au titre du mois MM/AAAA est rejetée car antérieure au premier mois pour lequel les régularisations sont autorisées...
Cette erreur n'était toutefois signalée que lors du premier calcul du bulletin. Si on recalculait le même bulletin, tout fonctionnait normalement.

En cas de régularisation de cotisations CSG et/ou CRDS (principe de régularisation de cotisations avec le repère @Rnn par exemple), des blocs 81.072 et 81.079 pouvaient être générés avec les codes 072$$/079$$ (avec 2 caractères $ à la fin, ou plus). Cela provoquait donc des erreurs dans l'outil DSN-VAL car le code contenait des caractères non autorisés.

Dans le cas d'un arrêt pour temps partiel thérapeutique, le bloc 66 n'était pas créé en DSN mensuelle, en P21V01, sur les nouveaux codes motifs des arrêts 15 à 18.

Un traitement exécuté en début de création d'une DSN (quel que soit sa nature) a été optimisé. Ce traitement, dont le temps d'exécution était proportionnel au volume de DSN existantes dans les fichiers (jusqu'à quelques minutes pour les plus gros dossiers), est désormais instantané.

Lorsqu'un envoi DSN contient plusieurs déclarations (blocs 05), chaque déclaration est envoyée dans un flux DSN distinct (l'API n'accepte que les envois ne contenant qu'une seule déclaration). Mais le N° de flux correspondant à chaque déclaration n'était enregistré dans LDPaye qu'après l'envoi de la dernière déclaration. En cas d'erreur (quelle qu’en soit l'origine) durant l'envoi, ces N° flux n'étaient donc pas enregistrés alors qu'une partie des déclarations, celles envoyées avant l'erreur, avaient bien été reçues par le SI DSN. Et comme on n'avait pas enregistré le N° de flux pour ces déclarations, on ne pouvait pas récupérer les CRM en retour.
Afin donc de fiabiliser ces informations, les N° de flux sont désormais enregistrés un à un après chaque envoi.

Il est désormais possible de créer des DSN événementielles de nature 07-Fin de contrat de travail Unique (dite FCTU).
Cette nature de déclaration va remplacer progressivement la nature 02-Fin de contrat de travail (dite FCT), pour devenir obligatoire à partir de 2022. La nature de DSN est à choisir à la 1ère étape de création d'une nouvelle DSN.

L'ajout d'un flux, sur une DSN qui n'en avait pas, était possible en cliquant sur Modifier tout en tenant la touche Alt Gr enfoncée, mais il n'était possible que de modifier le flux existant s'il y en avait déjà un enregistré. Un bouton Nouveau flux a été ajouté à cette fenêtre dans ce dernier cas pour permettre d'ajouter un flux lorsqu'un autre flux existe déjà pour cette DSN (et ainsi permettre de rajouter par exemple un 1er envoi qui n'avait pas été enregistré, alors que la DSN a été renvoyée, sans doute par erreur, depuis).

Depuis la correction niveau 117, les scripts contenant une lecture du fichier des conditions (si on met à jour un élément du type [xx.xxxx/IF.n] ) ne se compilaient plus et provoquaient une erreur (erreur de compilation, sans vraiment donner l'origine de l'erreur).

Suite à la correction niveau 126, l'envoi d'une DSN pouvait provoquer l'erreur suivante :
Erreur à la ligne 207 du traitement Méthode SauverRetour. Vous avez appelé la fonction HLitRecherchePremier. Une erreur d'intégrité est survenue sur la fonction 'HAjoute' précédente et n'a pas été traitée.
Cette erreur survenait juste après l'envoi de la première DSN de l'envoi. Dans ce cas, cette première déclaration a bien reçue sur le portail, mais pas les éventuelles déclarations suivantes composant l'envoi. Il faut donc renvoyer les autres déclarations, si l'envoi était composé de plusieurs déclarations.
Par ailleurs, pour disposer des retours (CRM) associée à la première déclaration qui elle a bien été envoyée, il vous faut enregistrer l'identifiant de flux associé :
 1) Récupérez l'identifiant de flux sur le site Net-entreprises, pour la déclaration ayant été reçue
 2) Depuis la fenêtre de gestion des DSN, sélectionnez la DSN sur laquelle l'erreur s'est produite, cliquez sur le bouton Modifier
     en tenant la touche Alt Gr enfoncée. Dans la fenêtre qui s'ouvre, saisissez l'identifiant de flux repéré sur Net-Entreprises.
Grâce à cela, les différents CRM associés à cette déclaration seront récupérés et intégrés dans LDPaye.

Lors du calcul d'un bulletin d'intéressement, on force implicitement les coefficients plancher et plafond de toutes les cotisations à la valeur 0. L'objectif est de ne pas décompter deux fois le plafond de Sécurité sociale pour les cotisations CSG-CRDS (le plafond SS jouant sur le plafond d'abattement de ces cotisations), une première fois sur le bulletin d'intéressement, une deuxième fois sur le bulletin de paye qui suit, dans le même mois.
Cette posait problème lorsqu'on voulait utiliser le bulletin d'intéressement en tant que « bulletin de reprise », de façon à calculer en un bulletin unique un peu particulier (grâce à l'utilisation des codes profils rubrique et cotisation dédiés à l'intéressement), l'ensemble des rubriques et cotisations correspondant à plusieurs bulletins antérieurs établis dans un autre logiciel de paye. Le fait de forcer à zéro les coefficients plancher et plafond faisait qu'on ne cumulait pas, sur ce bulletin de reprise, les planchers des cotisations Complément Maladie et Complément Allocations Familiales, qui sont normalement calculés par la formule (Cumul MTSMIC x Coefficient plancher). Et du coup, sur le premier bulletin calculé suite à ce bulletin de reprise, il y avait déclenchement à tort de ces compléments Maladie et AF.
On a donc fait en sorte qu'à l'avenir, sur les bulletins d'intéressement, les coefficients plancher et plafond ne soient pas forcés à zéro pour les cotisations ayant un code calcul égal à AF. Cela ne jouera sur les bulletins de reprise, car sur les « vrais » bulletins d'intéressement, on n'a jamais de cotisations Complément Maladie ou AF, seulement des cotisations CSG-CRDS.

Par ailleurs, on a aussi modifié une petite chose qui faisait que la cotisation RETRAITE CET T1 (celle ayant un code calcul particulier T2-Taux avec seuil) ne se calculait pas correctement sur un bulletin d'intéressement. Cela n'était pas un souci sur un vrai bulletin d'intéressement sur lequel cette cotisation ne figure pas, mais posait problème lorsqu'on voulait utiliser le bulletin d'intéressement en tant que « bulletin de reprise ».

La rubrique 62.020 était renseignée à tort dans les DSN FCT depuis la mise à disposition de la DSN FCTU (au niveau 127).

Un bloc changement de contrat (41) pouvait être généré à tort le mois suivant le changement d'établissement. Ce bloc changement, daté du 1er jour de la situation (date du changement d'établissement) contenait alors le SIRET courant comme "ancien SIRET", ce qui pouvait provoquer des informations erronées auprès des organismes.

Les blocs de changements de contrats en DSN (bloc 41) pouvaient ne pas être générés correctement en cas de correction des dates de début et fin des situations du salarié en dehors du mois déclaré. Ces changements portent sur les valeurs déclarées sur les rubriques 48 à 62 du bloc 41.

Depuis la norme P21V01, le code motif d'arrêt pour temps partiel thérapeutique ayant été décliné en 4 nouveaux codes, ces arrêts (avec les nouveaux codes) n'étaient pas repris comme cela aurait dû, dans les DSN Mensuelle (sauf si une DSN événementielle de l'arrêt a été créée, mais non envoyée car ces codes ne sont pas autorisés en DSN événementielle arrêt).

Les éléments associés aux éléments interfacés n'étaient pas déclenchés, malgré le choix d'application sur l'écran de lancement de l'interface. Cela pouvait également entraîner, dans de rares cas, des éléments associés d'une autre rubrique. Cette anomalie n'était pas provoquée si tous les éléments interfacés étaient affichés (option sur l'écran de lancement).

La zone de saisie du n° de rubrique modifiable à la volée en cas d'anomalie ne permettait pas de saisir des lettres (uniquement des chiffres). On pouvait cependant sélectionner le n° de rubrique souhaité (avec des lettres) dans la fenêtre de sélection (bouton à côté de la zone de saisie, ou F4).

La gestion des différentes jauges de progression dans les procédures de sauvegarde et restauration a été améliorée.
De plus, une correction a été apportée dans la sauvegarde des sous-répertoires : en effet, il manquait le premier niveau de répertoire dans le chemin sauvegardé au sein du fichier ZIP, ce qui posait problème en cas de restauration : les fichiers n'étaient pas restaurés à leur emplacement d'origine.
Par ailleurs, la couleur de la jauge de la fenêtre de réindexation a été alignée sur celle du gabarit actif.

Les données du bloc 79 de code 24-Tranche 2 Unifiée Prévoyance n'étaient pas imprimées correctement. Ce bloc était affiché comme une donnée supplémentaire (1 ligne par bloc) sans mentionner l'affiliation au contrat de prévoyance auquel il était rattaché. Il n'était pas non plus coloré en vert, comme toutes les données Prévoyance.

La récupération automatique des retours pouvait, en cas d'anomalie, provoquer une erreur affichée à l'écran et fermer l'application. Ces anomalies sont désormais affichées uniquement par notification, et seule la récupération automatique des retours est alors arrêtée.

Le traitement des retours DSN (CRM) a été amélioré afin d'éviter au maximum l'affichage de "fausses anomalies" sur les DSN. Un traitement de vérification des retours présents sera proposé à l'ouverture des DSN ou de la liste des retours DSN. Il sera proposé tant que l'outil n'aura pas été lancé au moins une fois.
Les retours n'ayant pas été traités par l'outil le seront à l'ouverture des bilans depuis une DSN, ou à l'affichage d'un retour depuis la liste complète des retours. De ce fait, certaines "fausses anomalies" seront toujours présentes malgré ce correctif, mais disparaîtront après ouverture des retours concernés.

Dans le cas où un identifiant DSN est utilisé dans plusieurs répertoires (voir dans d'autres logiciels), la récupération automatique des retours téléchargeait tous les retours, avant d'écarter ceux dont le flux n'est pas connu. Ce téléchargement est désormais filtré en amont afin d'éviter des téléchargements inutiles.

De plus, en cas d'anomalie de téléchargement, le retour est désormais tout de même enregistré, pour stipuler l'erreur. Si une erreur survient (et que le retour n'a pas été marqué "traité"), la date de dernière récupération ne sera pas avancée pour que le téléchargement soit tenté à nouveau lors de la prochaine récupération. De ce fait, il est important de bien marquer ces anomalies si elles perdurent de manière à ne pas surcharger les récupérations suivantes de tous les retours depuis le 1er retour en anomalie non marqué.

Lorsqu'un flux DSN est ajouté manuellement sur la déclaration (en cas d'anomalie lors de l'envoi, ou si dépôt manuel du fichier), la DSN est considérée envoyée mais, au départ, sans CRM reçu (le temps de la prochaine récupération des retours). Dans ce cas, la tentative d'ouverture des retours (clic sur envoyée) n'ouvrait pas la fenêtre, sans aucun message, ou pouvait engendrer une erreur.

LDPaye intègre désormais nativement un mécanisme d'historisation des calculs de bulletins : pour chaque calcul effectué, on conserve la date et l'heure de calcul ainsi que le code de l'utilisateur ayant demandé le calcul.
Ces informations sont visibles en consultation de bulletin : en haut à gauche du premier onglet, on a les informations concernant le dernier calcul effectué. En survolant ce libellé à la souris, on visualise l'historique de tous les calculs antérieurs de ce bulletin. 
Remarque : cet historique est perdu si on supprime explicitement le bulletin avant de le recalculer.

Complément technique : pour gérer cet historique, LDPaye utilise une rubrique spécifique (en standard, 9990CA, rubrique créée automatiquement lors de l'application de cette correction, référencée par la rubrique spécialisée HISCAL, visible sur l'onglet Calcul de la fenêtre des paramètres généraux).
L'historique est enregistré dans le commentaire associé à une ligne bulletin portant ce N° de rubrique, une ligne de commentaire pour chaque calcul, dans l'ordre chronologique inverse (le plus récent en premier). Mais cette ligne Historique du calcul est masquée dans le corps du bulletin, même en mode Expliquer.
Lorsque qu'à l'installation de ce correctif, on crée la rubrique 9990CA, dans la foulée, on suspend la rubrique 9990 si elle existe. C'est la rubrique qui était utilisée auparavant pour noter la date et heure du dernier calcul de bulletin, rubrique qui existait dans le plan de paye LDZ depuis 2019, et chez quelques autres clients où on l'avait créé. Plus précisément, on suspend toutes les rubriques qui font référence à la fonction personnalisée LOGCAL, en alimentation du nombre ou montant.

Le clic sur les chemins des répertoires affichés dans la fenêtre d'information de l'environnement (menu ? - A propos, puis Environnement) a été ajouté afin d'ouvrir l'explorateur Windows directement aux répertoires correspondant.
Le chemin du répertoire des sous-répertoires a également été ajouté à cette fenêtre.

Les retours DSN non gérés dans LDPaye n'étaient pas affichés dans les retours de la DSN (clic sur Envoyée). Ils n'étaient accessibles que depuis la liste complète des CRM.
Dans le cas d'un retour non géré, en anomalie, l'envoi était alors marqué en anomalie, mais l'anomalie n'était pas affichée ni sur la ligne de la déclaration (tableau du bas), ni dans les retours présentés dans la fenêtre. Désormais, ces retours non gérés sont affichés dans la fenêtre des retours de la déclaration. Le groupe "Autre (non géré)" dans lequel sont rangés ces retours est réduit par défaut, sauf en cas d'anomalie dans l'un d'eux afin de voir lequel est concerné par l'erreur.

Les améliorations ont portées principalement sur deux points :
1) La gestion des acomptes mensuels et trimestriels
Lorsque qu'on lance l'état pour une période mensuelle ou trimestrielle, on a désormais la possibilité d'enregistrer le montant de taxe calculé pour chaque établissement (sachant que cela ne concerne que les établissements ayant une fréquence mensuelle ou trimestrielle). Ces montants d'acomptes, lorsqu'ils ont été enregistrés, sont repris sur l'état annuel, et permettent de calculer le solde dû au titre de l'année : total dû pour l'année moins les acomptes enregistrés au fil des mois ou trimestre. Ce total des acomptes et le solde dû apparaissent donc en plus sur la liste, après le total dû pour l'établissement (si et seulement s'il y a eu un acompte dans l'année).
Bien que cette gestion des acomptes ait été conçue essentiellement pour les clients immobiliers, elle est aussi disponible pour les autres types de clients. Dans ce cas, les acomptes sont enregistrés globalement pour la société, et non par établissement. Mais comme un code établissement est requis pour cet enregistrement, on utilise le code de l'établissement déposant la déclaration de résultat, code qui doit alors être renseigné dans la fiche de la société, en haut de l'onglet Détail.
Les acomptes sont enregistrés dans le fichier PEETCO, pour la société et l'établissement concernés, avec le code type TS-Taxe sur salaire, le code cotisation ACT-Acompte et le mois de versement.
Ces acomptes enregistrés peuvent être vus et éventuellement corrigés en cliquant sur le bouton Acomptes au bas de la fenêtre de lancement de l'état de taxe sur salaires.
Notez qu'on peut enregistrer aussi, sur le même principe, le total dû au titre de l'année et le solde versé en décembre pour chaque établissement. On utilise respectivement les codes cotisation TOT-Total dû et SLD-Solde versé en décembre. Ces données sont toujours enregistrées sur le mois de décembre.

2) Un état supplémentaire avec présentation de type CERFA
Dans le cas des clients Immobiliers uniquement, un nouvel état est proposé en plus de la liste « classique » proposée jusqu'alors (liste qui reste toutefois disponible, car c'est uniquement sur celle-ci qu'on a le détail du calcul par salariés).
Cet état présente une page par établissement, avec une mise en page s'inspirant grandement du CERFA 2502-SD - Déclaration annuelle de liquidation et régularisation de la taxe sur salaires et 2501-SD - Taxe sur les salaires - Relevé de versement provisionnel.
Notez que le système choisit directement l'un ou l'autre de ces deux états en fonction de la période indiquée au lancement de l'état.
Remarques importantes :
 - dans l'état actuel, le relevé de versement provisionnel ne tient pas compte d'un éventuel excédent de l'année précédente.
 - De même, la gestion du crédit d'impôt de taxe sur salaires, réservé aux employeurs mentionnés à l'article 1679-A du CGI,
   n'est pas faite (cadres III - Crédit d'impôt TS  et V - Demande de remboursement du crédit d'impôt TS au verso du CERFA 2502-SD,
   non repris sur l'état produit par LDPaye).
 - De même, les lignes 26-Montant déjà versé au titre du solde et 27-Remboursement déjà demandé, prévues sur le CERFA 2502-SD,
   ne sont pas prises en charge (cases grisées sur l'état produit par LDPaye).

Pour renseigner ce nouvel état de type CERFA, il est nécessaire de connaitre le centre des impôts auquel est rattaché chaque établissement.
Cette information a donc été ajoutée dans la fiche de l'établissement, sur l'onglet Détail, là où l'on avait déjà les autres informations relatives à la taxe sur salaires (N° de dossier, rapport d'assujettissement, fréquence déclarative). Le centre des impôts doit être sélectionné dans une liste déroulante. Cette liste est ajustable via l'option <Gérer> proposée en fin de liste, option qui donne accès à la saisie des paramètres programmes, avec un positionnement à partir de SIP. Les données de ces centres sont en effet enregistrées dans des paramètres programmes, un paramètre programme par centre avec un code de la forme SIP_XXXXXX, XXXXXX étant un identifiant de centre à choisir (on conseille d'utiliser le code postal sur 5 chiffres + 1 lettre pour le secteur). Pour chaque centre, il faut indiquer un libellé (celui qui apparait dans la combo de sélection et qui est repris dans la case SIE en tête de l'état type CERFA, à gauche du N° de dossier), et 4 lignes d'adresse (4 premières lignes de la valeur alphanumérique du paramètre, en se limitant à 40 caractères par ligne).

Lors de la récupération de retours DSN déjà récupérés auparavant (en cas de rafraîchissement des retours d'une DSN, ou si un nouveau retour a été remplacé), certaines mise à jour du retour pouvaient provoquer des erreurs de doublon sur le fichier DNFLUR (l'erreur apparaissait en tant que notification).

La nature de contrat 03-Contrat de mission n'était pas autorisé avec un dispositif de politique publique 64 ou 65 (apprentissage). Cette règle ayant été ajoutée dans le cahier technique DSN 2021.1.0 (JMN V3), cette nature n'est donc désormais plus refusée avec ces dispositifs.

Les règles d'application du code motif de fin de contrat 081-fin de contrat d'apprentissage ont été modifiées dans le cahier technique DSN 2021.1.1 (JMN V4). Le contrôle de ce motif a été mis à jour en conséquence.

La gestion de l'alimentation des cotisations établissements en DSN a été revue compte-tenu de modifications du cahier technique DSN 2021.1.1 (JMN V4) qui ajoute certaines cotisations établissement sans impact sur le versement.
Désormais, les cotisations établissement à destination des OC, et certaines cotisations établissement à destination de la MSA, sont ajoutées dans le bordereau de versement DSN correspondant. Et c'est seulement si ce bordereau est ajouté en DSN que la cotisation établissement est également ajoutée.
Les autres cotisations établissement sont quand à elles directement ajoutées en DSN (sans passer par un bordereau).

Afin de tenter de contourner l'erreur 100138 qui se provoque parfois lors de l'envoi des DSN (erreur de certificat révoqué) et qui arrête l'envoi des DSN lorsque l'envoi contient plusieurs déclarations, un paramètre a été ajouté afin d'ignorer cette erreur et continuer à traiter le retour reçu comme si l'erreur n'était pas survenue. Pour cela, il faut ajouter un "O" dans la 6ème valeur de la zone alpha du paramètre programme APIDSN (les valeurs étant séparées par ";").

Lorsqu'un élément de paye est paramétré en DSN sur le bloc 56, si l'élément n'a pas été daté (en saisie d'élément variable), le programme de création d'une DSN, que ce soit en création de DSN elle-même, en visu DSN du bulletin, ou en création de bordereau de versement, pouvait provoquer une erreur du type "Erreur à la ligne 43 du traitement Méthode CalculerRubriqueLB. Vous avez appelé la fonction DernierJourDuMois. Une date est une chaîne qui ne doit comporter que des chiffres. "

Depuis une mise à jour récente du site de l'URSSAF (le 25/04/2021), le fichier téléchargé depuis ce site qui liste les codes types de personnel (CTP) est vide ; il ne contient que les entêtes de colonnes. De ce fait, les contrôles et affichages effectués dans les programmes ne fonctionnaient plus correctement. C'était notamment le cas de de la liste des codes CTP qui était affichée via le bouton (F4) à côté du code de cotisation agrégée dans la fenêtre de paramétrage du bordereau de versement URSSAF, mais aussi du programme de contrôle de cohérence de la DSN, pour le contrôle des blocs 23.
Pour remédier à ce problème, un contrôle de validité a été ajouté suite au téléchargement du fichier depuis le site de l'URSSAF, afin de ne pas garder le fichier téléchargé s'il ne contient qu'une ligne d'en-tête. Et en lieu et place de ce fichier trouvé en principe sur le site de l'URSSAF, on exploite une version de ce même fichier livrée par nos soins dans le répertoire des programmes, version plus ancienne mais qui contient les CTP principaux.
Pour ce qui est du contrôle de cohérence d'une DSN, on se base désormais sur une liste des CTP extraite depuis le site de l'URSSAF au format XML, sachant qu'à ce jour, si la liste des CTP fournie par l'URSSAF au format CSV est défaillante, celle fournie au format XML semble correcte.

Les nouvelles cotisations OETH (correctif niveau 167) sont désormais automatiquement intégrées dans les bordereaux de versement URSSAF et/ou MSA, et dans la DSN (blocs 82). Contrairement aux autres cotisations établissement, ces cotisations ne sont pas déclenchées en DSN si un bordereau de versement les a inclus ; elles sont prises en compte uniquement (et systématiquement) en fonction du mois de déclaration défini dans la cotisation.
Une petite correction a également été apportée dans la saisie des compléments OETH afin que le complément soit saisie avec un accord agréé OU un type de complément OETH (et non les 2)

Suite à la correction 171, dans le cas des dossiers « Immobilier » (DADUETAB[[1]]="O"), la création d'une DSN événementielle (Fin de contrat ou Arrêt de travail) provoquait une erreur :
Traitement de 'Méthode _01_EmetteurCOSO' (dsnFabrique._01_EmetteurCOSO), ligne 6.
La dimension 1 du tableau possède 0 élément(s) et vous tentez d'accéder à l'élément 1.

Lors de la récupération des retours DSN (CRM), une erreur du type Le document XML "XML_DOC" existe déjà (ligne 28 de la méthode ExtraireContenuXML) pouvait intervenir dans certains cas. Ce problème a été réglé.

Il est possible de sélectionner les déclarations de l'envoi à inclure dans le fichier DSN final. Il faut pour cela afficher le bouton de sélection dans la fenêtre de création du fichier final, par la combinaison de touche Maj Alt F1.

De nouvelles natures de retours sont désormais gérées dans la liste des CRM. Il s'agit des retours :
34 - Compte-rendu métier AT
71 - Compte-rendu AGIRC-ARRCO
90 - Mandat à acquitter
92 - Accusé de réception DGFiP
93 - Compte-rendu DGFIP
A noter que la nature 90 affiche une page internet qui contient un script. Ce script ne pouvant s'exécuter de manière sécurisée dans LDPaye, il est proposé dans ce cas d'ouvrir cette page dans le navigateur habituel du poste.

La création d'un bordereau URSSAF dans lequel ne devait être inscrit qu'une cotisation OETH provoquait la création d'un bordereau de régularisation à tort, sans date. Cela provoquait ensuite une erreur d'affichage :
Erreur à la ligne 5 du traitement Procédure locale xDonnerLibelléPériode. Vous avez appelé la fonction DateVersEntier. Une date doit être représentée par une chaîne de huit caractères au format AAAAMMJJ.

L'initialisation de la liste des liaisons entre une cotisation et les cumuls, lors de l'exécution d'un script de modification du plan de paye, provoquait l'erreur suivante : L'élément PMLICT.KLIRC est inconnu.

Dans la fenêtre de gestion des cumuls salariés, il y avait un mauvais ancrage de la table affichant les cumuls pour un salarié donné : lorsqu'on agrandissait la fenêtre, la table ne s'agrandissait pas.

Lors de la restauration d'un dossier de paye comportant plusieurs sociétés, dans le cas où il existe déjà des sociétés dans l'environnement courant avec les mêmes codes externes de société, mais dans un autre répertoire que celui restauré, LDPaye propose automatiquement de nouveaux codes sociétés externes pour les sociétés à restaurer (les codes société interne et externe seront donc différents).
Dans certains cas, les nouveaux codes sociétés externes proposés pouvaient faire doublons entre eux.
Exemple : on restaure un dossier comportant 2 sociétés 001 et 004, qui existent toutes deux déjà dans un autre répertoire. Le nouveau code externe proposé pour ces deux sociétés 001 et 004 était 002.

Suite au correctif 177, une nouvelle erreur arrive lors du marquage de certains retours DSN (CRM) qui ne sont pas en XML : Erreur à la ligne 16 du traitement Méthode MarquerAnomaliesCommeTraitée.

Lors de l'envoi d'une DSN FCTU (type 07), l'AER est retournée via un retour DSN (CRM) code 44 (et non 42 comme lors de l'envoi d'une FCT). Ce nouveau type de retour est désormais géré dans LDPaye.

L'outil de modification du plan de paye par script est désormais capable de gérer les paramétrages du bordereau de versement DSN URSSAF (cotisations agrégées).

Si un bulletin est calculé après la sortie du salarié, la DSN Fin de contrat unique (FCTU) doit inclure les bulletins du mois (M) du dernier bulletin, et les bulletins du mois précédent (M-1). Jusqu'à présent, les bulletins calculés après le départ du salarié (sur les mois suivants) n'étaient pas pris en compte pour déterminer les 2 mois à inclure dans la déclaration. Désormais, c'est le dernier bulletin calculé sur la situation qui détermine le mois M (et donc M-1), quelle que soit la date de sortie du salarié.

Dans le cas d'un calcul de taux PAS au barème, si le barème de l'année du bulletin n'est pas présent dans le fichier des taux au barème (non encore diffusé), le taux était systématiquement défini à 0. Désormais, le programme utilise dans ce cas le barème de la dernière année connue (l'année précédente généralement).

Lors de la création de plusieurs FCTU dans le même envoi DSN, le programme ne créait le bloc 15-Adhésion prévoyance que sur le 1er salarié calculé (pas forcément dans l'ordre d'affichage) ayant une affiliation sur cette adhésion. Les blocs étaient donc manquants sur les autres salariés de l'envoi.

Lors de la création des bordereaux de versement, si tous les contrats existants d'un organisme de prévoyance contenaient un code délégataire (le même sur tous), et que le total du bordereau de versement était nul, le code délégataire n'était pas inscrit sur le bordereau.

Suite à un précédent correctif, la date de versement d'origine, inscrite dans la rubrique 007 du bloc DSN 52-Prime, n'était plus inscrite. Pour rappel, cette date est récupérée, si elle est saisie, depuis la date de fin (ou de début, si pas de date de fin) de la rubrique paramétrée avec un code du bloc 52 n'étant pas géré avec période de rattachement (tous les codes du bloc 52, sauf 026, 027, 029, 031).

Dans la fenêtre de gestion des contrats de prévoyance pour un salarié, l'application cessait de fonctionner lorsqu'on cliquait sur le bouton Nouveau dans le cadre central Événements liés au contrat, s'il n'existait aucun contrat de prévoyance en partie haute de la fenêtre.

Les scripts de modifications du plan de paye ne fonctionnaient pas correctement pour ce qui était du bordereau DSN URSSAF (cotisations agrégés) : le code qualifiant assiette n'était pas pris en compte. De plus, l'utilisation de variables pour ce type Cotisation agrégée n'était pas permis. Enfin, il y avait un problème d'affichage de la liste des variables du script si la dernière variable du script portait sur une cotisation agrégée.

Une nouvelle doctrine, issue du BOSS (Bulletin Officiel de la Sécurité Sociale), entre en vigueur en 2022, pour le calcul du plafond annuel de la Sécurité Sociale et des différentes tranches de salaire qui en découlent. Désormais, les rémunérations prises en compte sont constituées de l’ensemble des rémunérations dues par un même employeur à un même salarié, y compris au titre de plusieurs contrats, successifs ou non (BOSS, Assiette générale, § 1211, 01/04/2021).
Pour gérer cela, dans LDPaye, il est désormais possible de définir au niveau de la cotisation, ou du cumul (sauf ceux qui sont remis à zéro tous les mois), si le cumul est multi-contrats ou pas, sachant que le mode « multi-contrats » n'est pris en considération qu'à partir de janvier 2022). Si l'option est cochée, le cumul salarié ou cotisation ne sera pas remis à zéro sur le premier bulletin calculé pour une situation, même si cette situation n'a pas l'option Reprise cumuls période précédente.
Remarque : cela ne change rien au fait que les cotisations se calculent toujours par exercice social (année civile). Les assiettes brutes et les plafonds repartent donc à zéro au 1er janvier de chaque année.

A l'installation de ce niveau 202, toutes les cotisations sont marquées multi-contrats, ainsi que les cumuls salariés suivants : ALLEGA, AVNATU, BRNFIA, BRUFIA, CAL%ME, CHARTA, COTPAA, COTSAA, CSGCOA, CSGDEA, FRDEPL, HPCUMA, HSCUAN, HSNFIA, HTCUMA, JPCUMA, JTCUMA, NETIMA, NTNFIA, et PLSSAN

Le calcul de la DSN Fin de Contrat Unique (FCTU) générait des valeurs paramétrées à 0 si le bulletin (généralement celui du mois précédent) est lié à une situation précédente de celle de la sortie (mais avec le même n° de contrat, ou la même date d'entrée si pas de n° de contrat).

Il avait été observé depuis quelques temps que l'option Envoi des bulletins sur mail (renommée Dématérialisation des bulletins, pour ceux qui ont choisi la dématérialisation via la solution Neobox-RH), présente sur l'onglet Privé de la fiche salarié, se perdait de façon semble t'il aléatoire.
On pouvait avoir coché les options Personnel ou Professionnel dans ce champ et on se retrouvait quelques temps après avec la première option Pas d'envoi par mail ou Refusée.
Après une longue recherche, le programme en cause a été trouvé et corrigé : il s'agissait de la fenêtre de modification des valeurs d'une constante salarié, fenêtre où est présentée la liste des salariés, avec entre autres informations une colonne Accepte par mail correspondant au champ Envoi des bulletins sur mail ou Dématérialisation des bulletins. Le simple fait de parcourir la liste des salariés dans cette fenêtre remettait la première valeur Pas d'envoi par mail ou Refusée pour tous les salariés sur lesquels on était passé, même sans modification de la valeur de la constante salarié.
Au passage, deux autres petites corrections moins gênantes ont été faites :
 - Dans la fenêtre de mise à jour de la fiche salarié, la largeur du champ Dématérialisation des bulletins a été agrandie
   pour que son libellé et les valeurs présentées dans la liste déroulante ne soient pas tronquées.
 - Dans la fenêtre qui présente la liste des salariés pour un contrat de prévoyance donné, les 4 colonnes Accepte par mail, Sorti,
   Afficher heures, Afficher CP ne s'affichaient jamais (on n'avait aucune coche dans la colonne).

Application du cahier technique DSN P22V01 (1ère déclaration au 5 ou 15 février 2022).

La création des blocs DSN 81.001, 81.002, et 81.003 (Exonérations apprentis) était conditionnée au type de contrat d'apprentissage, ce type de contrat étant celui déclaré en DSN en bloc 40-Contrat. Cela posait problème en cas d'embauche en CDD ou CDI de l'apprenti au lendemain de la fin de son apprentissage, si cette embauche intervenait en cours de mois, avec donc 2 bulletins de paye dans le mois, l'un pour la période en contrat d'apprentissage et l'autre pour le contrat faisait suite à ce contrat d'apprentissage. Dans ce cas de figure, aucun des blocs 81.001, 81.002 et 81.003 n'apparaissaient pour le premier bloc 50-Versement correspondant au contrat d'apprentissage car le contrat déclaré en DSN en bloc 40 n'était pas un contrat d'apprentissage, mais un CDD « classique » ou un CDI. Le contrat d'apprentissage n'apparaissait alors que dans les blocs 41-Changement de contrat.
Désormais, pour le remplissage de ces blocs 81.001, 81.002 ou 81.003, on se base sur le type de contrat défini dans la situation à laquelle se rattache le bulletin de paye, et non sur le type de contrat apparaissant sur le bloc 40-Contrat.

L'exécution d'un script faisant référence à un élément de type DN.xxx avec une valeur se terminant  par (AM) ou (M)  provoquait une erreur.

Suite à des modifications opérées sur le site de la DPAE, les champs Sexe et Type de contrat ne se remplissaient pas correctement depuis LDPaye.
Au passage, on a fait trois autres corrections :
 - Le navigateur Internet s'exécute désormais en mode « silencieux ». Ainsi, on ne voit plus apparaître les fenêtres signalant des erreurs de script.
 - L'URL est désormais www.due.urssaf.fr (au lieu de www.due.fr, qui fonctionne encore et renvoie sur la même page).
 - Dans la fenêtre de gestion des situations, le libellé du bouton est désormais Déclaration DPAE (et non plus DUE).

Dans la fenêtre de gestion des événements pour un type d'événement, 2 améliorations ont été apportées :
 1) des colonnes supplémentaires présentant toutes les données de la fiche salarié ont été ajoutées
 2) Le bouton Salarié a été ajouté (bouton avec menu déroulant), pour accéder aux différents écrans de mise à jour de la fiche salarié. 
Par ailleurs, des modifications ont été faites sur les fenêtres de mise à jour d'une fiche Salarié pour que les boutons situés en partie droite soient repositionnés correctement lorsque les boutons de parcours ne sont pas visibles.

Une nouvelle fenêtre permettant de consulter ou imprimer la liste des associations entre rubriques est disponible. Elle est accessible :
 - depuis le menu Plan de paye/Imprimer
 - depuis la fenêtre de Définition d'une rubrique associée, via un nouveau bouton en bas à gauche Imprimer.
   On a dans ce cas un filtre par défaut pour ne voir ou imprimer que les associations de la rubrique courante.
 - depuis le menu Outils/autres outils/Lancer un autre outil, avec dans ce dernier cas un filtre par défaut
   qui permet de n'imprimer que les associations en erreur, c'est-à-dire les associations entre rubriques qui bouclent entre elles,
   et les rubriques actives associées à des rubriques suspendues (ou vice-versa).

Le copie d'un élément de paye (rubrique ou cotisation), par un script de modification du plan de paye, copiait les paramètres DSN en double.

On avait un souci dans le cas d'une demande de régularisation de cotisations sur un mois antérieur, saisie sur un bulletin établi après le départ du salarié.
Exemple : salarié parti en Mai, Régularisation d'une assiette de cotisation au titre du mois de Mai faite sur un bulletin d'octobre. Dans ce cas de figure, on retrouvait sur le bulletin d'octobre :
 - les lignes de régularisation au titre du mois de Mai
 - des lignes de régularisation au titre du mois de Juin (pour la part de T1 liée à la régularisation demandée et ne pouvant être absorbée en Mai)
 - des lignes au titre d'octobre venant annuler exactement les lignes du mois de Juin (calculées donc à tort).
Pour éviter ce phénomène curieux, le système ne crée plus désormais de lignes de régularisation de cotisations sur un mois antérieur pour lequel aucun bulletin n'a été calculé (sauf si une régularisation de cotisation est demandée explicitement pour le mois en question).

Les comptes-rendus métier (CRM) venant de l'AGIRC-ARRCO (ceux portant le code 71) sont maintenant consultables sous la forme de fichiers PDF, et donc beaucoup plus lisibles qu'avant où ils étaient présentés sous forme « XML brute ». Ils s'apparentent désormais beaucoup aux documents mis à disposition par l'AGIRC-ARRCO sur le site Net-Entreprises.
Ces CRM en format PDF sont visibles directement dans la fenêtre de LDPaye permettant d'afficher les CRM (via un lecteur PDF intégré), au même titre que tous les autres CRM (MSA, URSSAF, DGFIP...).

Une nouvelle possibilité a été ajoutée sur le 1er écran de l'outil de modification du plan de paye par script, il s'agit de la possibilité d'exécuter un script "en ligne". Concrètement, des scripts seront mis à disposition de l'outil sur internet, et seront ainsi proposé à l'exécution. Ces scripts ne sont pas modifiable par l'utilisateur.

Suite à une modification de la page de téléchargement des outils de contrôle DSN-VAL sur le site net-entreprises.fr, la recherche des versions installées et disponibles ne fonctionnait plus correctement.

Les scripts de modification du plan de paye peuvent désormais être conditionnées par un code WL. Si un code est renseigné, il doit renvoyer la valeur Vrai pour que le script pusse être exécuté. Dans le cas contraire, le script ne peut pas être exécuté.
Un commentaire, ainsi que des informations sur l'auteur, la date et heure, et la version du script peuvent également être ajoutés lors de l'étape de sauvegarde du script. Si elles sont renseignées, ces informations apparaissent dans la bulle au survol du script dans la liste des scripts sur le 1er écran.

Afin de déclarer les heures supplémentaires de décembre 2020, payées en 2021, dans le bloc 51, code 026 (qui n'existait pas à l'époque, en P20V01), il est nécessaire de déclarer ce bloc avec les dates exactes du 07/01/2021 au 07/12/2021. Le paramétrage DSN de ce code permet désormais de saisir (uniquement) ces dates sur la ligne de bulletin, qui seront alors repris sur le bloc 51 en DSN.

Le libellé de la règle de contrôle N° 18 a été modifié, suite aux changements opérés dans la façon de déclarer nominativement la CSG sur activité partielle. Ce libellé est désormais :
Vous avez déclaré une base nominative de CSG (78.04) différente de la somme des assiettes de CSG/CRDS renseignée dans le bordereau URSSAF (CTP 260 920, 060 920). Ceci est une anomalie, sauf si vous avez déclaré de l'activité partielle pour au moins un salarié.

La particularité de l'indemnité inflation est que le montant de ces indemnité doit être déclaré uniquement dans l'assiette du CTP 390-920, il ne doit impacter également que le total versé du bordereau (bloc 20 en DSN) et pas le total des cotisations (bloc 22 en DSN). Egalement, ces indemnités doivent être déclarés dans des blocs 81, uniquement en montant (sans base ni taux).

A partir de 2022, l'abattement pour frais professionnels ne doit être appliqué que s'il y a effectivement des frais professionnels dans le mois. Les mois où le salarié n'a aucun frais, on ne doit pas appliquer d'abattement.
Cette nouvelle méthode de calcul a donc été implémentée dans LDPaye. Aucune modification de paramétrage n'est nécessaire, tout se fait automatiquement dès lors que le bulletin calculé porte sur un mois supérieur ou égal à Janvier 2022.

Principes mis en œuvre
Pour tester le fait qu'il n'y a pas de frais professionnels dans le mois, et donc qu'il faut neutraliser l'abattement, on peut utiliser 2 méthodes :
 1) Si un nom de cumul a été spécifié dans les rubriques spécialisées (une nouvelle ligne a été ajoutée en bas du tableau
     des rubriques spécialisées pour cela, mais sans nom de cumul en regard), on teste que la valeur de ce cumul est nulle.
 2) Sinon (cas général donc), on teste que le cumul RFBASB-Réduc.Fillon-Brut hors FP est égal (ou même plus grand) que
    le cumul BRUFIM-Brut mensuel. Le cumul RFBASB avait été mis en place début 2020, pour gérer le mécanisme de plafonnement
   de la réduction générale en cas de DFS à 130% de ce qu'elle serait sans DFS
   (voir note d'actualité Plafonnement de la réduction générale en cas d'application d'une déduction forfaitaire spécifique).
   Ce cumul est par nature égal au cumul brut mensuel frais professionnels exclus. Du coup, s'il y a des frais
   professionnels dans le mois, ce cumul RFBASB est inférieur strictement au cumul BRUFIM.
Dans ces deux cas, on peut exclure les salariés ayant certains types de DFS (les VRP par exemple) via la liste fListeTypeDFSmemeSansFrais, salariés pour lesquels on applique l'abattement même en l'absence de frais professionnels.
Cette liste est définie dans le paramètre programme CUM*_FRDFS (dans lequel est également enregistré le nom du cumul éventuellement défini en 1), en positions 65 à 78. On peut y inscrire jusqu'à 5 codes de 2 caractères avec un point-virgule comme séparateur. La valeur de ce paramètre est initialisée par défaut à 09 pour exclure les VRP.
En effet, pour les VRP multicartes notamment, les frais professionnels ne sont pas repris en partie haute du bulletin (pas plus qu'en partie basse d'ailleurs). Ils restent à la charge du VRP. Mais cela ne doit pas empêcher l'application de l'abattement de 30%.
Au besoin, on ajoutera d'autres valeurs dans cette liste (comme 04 pour les journalistes par exemple) si on a d'autres types de DFS pour lesquelles on doit appliquer l'abattement même en l'absence de frais professionnels dans le mois.

Autre chose à savoir : si on effectue des régularisations d’assiette sur mois antérieurs (réguls de type @Rmm ou @Rmmaa), cette nouvelle règle de neutralisation de l'abattement en l'absence de frais professionnels n'est pas gérée. Par exemple, si on fait en juin une régularisation au titre de janvier, donc de type @R01, pour un salarié ayant une DFS de 30%, cela ajoute 1000 sur le brut et 700 sur le brut abattu de janvier. Et cela sans tenir compte du fait qu’il y a eu ou pas des frais professionnels en janvier ! Si non ne veut pas que l'abattement s'applique sur cette régularisation de janvier, il faut faire une double régularisation : @R01 de 1000 et @A01 de 300 pour neutraliser l’abattement de janvier (rappelons que les régularisations de type @Amm ou @Ammaa permettent de régulariser l'assiette brut abattue d'une cotisation sans toucher à l'assiette brute de cette même cotisation).

Lors de la création d'une DSN, si la norme choisie ne correspond pas à celle de l'année, un message de confirmation (Oui/Non) était affiché. Désormais, lors de la création d'une DSN de janvier, si la norme choisie correspond à la norme de l'année précédente, le message affiché offre la possibilité, en répondant Oui, de modifier automatiquement la norme utilisée sans avoir à revenir sur l'écran précédent. En répondant Non, le programme continue la création de la DSN avec la norme choisie. Et le bouton Annuler permet de ne pas continuer (équivalent au Non d'avant). En revanche, s'il s'agit d'un autre mois, ou que la norme choisie n'est pas celle de l'année précédente, le message reste identique à celui d'avant.

Dans les fiches paramétrages de DSN pour le BTP, il est précisé que les blocs 78 pour les codes 34 et 35 doivent être déclarés s'ils sont différents du bloc 78 code 02, et de la même manière, pour les codes 21, 36, 39, et 40, s'ils sont différents du code 20. Ces blocs ne sont donc désormais plus créés si les valeurs sont identiques (en valeur et en dates) au bloc correspondant (02 ou 20 selon le cas).

Il est désormais possible de saisir un code population ou un code option pour un seul établissement ayant souscrit le contrat de prévoyance, comme c'était déjà le cas pour la référence du contrat. S'il est saisi au niveau de l'affiliation de l'établissement, le code saisi sera pris en lieu et place de celui éventuellement défini sur le contrat de prévoyance.

Sur les journaux standards et journaux détaillés, on a ajouté la possibilité d'utiliser une fonction personnalisée pour effectuer la sélection, ce qui permet d'aller au-delà de ce qu'on pouvait déjà faire avec une expression de sélection (expression limitée à 256 caractères).
La fonction personnalisée appelée pour sélection doit renvoyer une valeur numérique : le salarié sera sélectionné si et seulement si la fonction renvoie une valeur non nulle.
Dans cette fonction personnalisée, on peut faire appel (comme c'était le cas dans l'expression de sélection) aux variables :
 - Présent : est à Vrai si le salarié a au moins une situation dans la période demandée pour le journal
 - Payable : est à Vrai si le salarié est payable sur au moins une des situations de la période demandée pour le journal
 - Montant : tableau des 13 montants qui ont été calculés pour le salarié.
En sus, on peut utiliser tous les champs des fichiers PEPERS-Salariés et PEPACT-Situations salariés. Attention toutefois à ce dernier fichier PEPACT : la situation sur laquelle on se trouve au moment de l'appel de la fonction de sélection dépend de ce qui est choisi au lancement de l'état : dernière situation connue, situation à la date d'arrêté de l'état ou situation de chaque bulletin.

L'affichage de la fenêtre d'ouverture de session ne s'affichait pas correctement en mode simulation.

L'affichage, sur l'édition DSN, des blocs 81 pour les taxes d'apprentissages et formation continue a été optimisé pour n'apparaître que sur une seule ligne par salarié.

Suite au correctif 152 du 30/03/2021, si les totaux calculés et montants versés ont été enregistrés lors du calcul de la taxe sur les salaires (données accessibles via le bouton Acomptes sur l'édition des taxes sur les salaires), l'ajout des données des taxes sur les salaires lors de la création d'une nouvelle DSN pouvait dans certains cas ne pas se terminer (boucle infinie).

Le test d'existence d'une rubrique dans les scripts de modification du plan de paye renvoyait Faux si le n° testé existait en cotisation. Et inversement pour tester une cotisation si le n° existait en rubrique. Cela pouvait générer des erreurs d'intégrité.

Les taux de cotisation accidents du travail (AT) sont envoyés en retour de DSN (CRM 34). Ces taux peuvent désormais être intégrés directement à partir de la liste des codes accident du travail (menu Fichier/Codification/Codes accident du travail). Un nouvel onglet Comptes rendus métier AT a été ajouté pour cela. Selon le nombre de CRM dans les fichiers, il peut être nécessaire de cliquer sur Recherche les CRM AT pour lancer le chargement de cette liste (peut être long).
Cela affiche alors une liste des CRM reçus, regroupés par code section, code risque, et taux. Par défaut, seuls les derniers CRM sont affichés.
Dans la liste des codes AT, ceux pour lesquels un établissement (ayant un salarié avec ce code AT depuis le début de l'année précédente) a reçu au moins un CRM, une coche sera affichée si tous les CRM trouvés ont le taux actuel, une croix si l'un de ces CRM n'a pas le taux actuel (le code est donc à mettre à jour).
Côté CRM (nouvel onglet), une coche sera affichée s'il existe au moins un code AT existant pour le code section et le code risque (mais sans tenir compte des établissements !!!). Cette coche sera remplacée par une croix si l'un de ces code concerne un des établissement reçu, et que le taux est différent de celui reçu dans le CRM.
Il est alors possible de mettre à jour les codes soit en cliquant sur le bouton Mettre à jour proposé dans la fiche du code AT (si un CRM a été identifié pour un établissement utilisé avec ce code), soit depuis la liste des CRM, en double cliquant sur la ligne de CRM à utiliser (ou bouton Afficher les codes existants), puis en sélectionnant les codes à mettre à jour (par défaut sont cochés ceux identifiés pour des établissements de la ligne de CRM sélectionnée) et en cliquant sur Mettre à jour (en haut de la fenêtre). Si un historique existe déjà à cette date, le taux sera remplacé, sinon un nouvel historique sera créé.
Si aucun code n'existe pour le code section et code risque de la ligne de CRM sélectionnée, ou si on clique sur Nouveau code, la fenêtre de création sera proposée avec un 1er historique déjà renseigné au taux de la ligne de CRM.

La correction 238 qui était censée corriger d'éventuelles erreurs d'intégrité s'est avérée trop restrictive et empêchait la création des rubriques et cotisations par les scripts (notamment par copie). Cette correction a été annulée.

Complément à la correction N° 239 : la lecture des taux AT reçus ne prenait pas en compte l'ensemble des taux reçus dans les CRM. Seul le 1er taux reçu de chaque notification était traité. De plus, lors de l'analyse des salariés, seules les situations des salariés ayant une date de fin était prise en compte.

Pour les codes calculs [47]  Nombre X taux + prorata E/S et [48]  Nombre X taux + Tps partiel + prorata E/S, le calcul du montant par la formule Nombre X Taux n'était pas réalisé. Seule l'application du prorata s'effectuait, sur le nombre et sur le montant si ce dernier était effectivement renseigné (par une alimentation directe par exemple).
Remarque : les codes calculs 47 et 48 avaient été ajoutés en 2018 (Correction V9.50 N° 86 du 29/03/2018).

Lorsqu'on modifiait un bordereau de versement URSSAF de décembre, et que celui-ci contenait une ligne CTP 390 pour l'indemnité inflation, on rencontrait deux soucis :
 - Si on modifiait une ligne, pour une raison quelconque, le montant prélevé était recalculé égal au total du bordereau.
   Le montant de l'indemnité inflation n'était pas déduit du montant prélevé, comme il l'est à la création du bordereau.
 - A la validation finale du bordereau, dès lors qu'on avait une indemnité inflation venue en déduction du montant prélevé,
   on avait un message d'avertissement signant une différence de plus de 1€ entre le total du bordereau et le montant prélevé.
   Désormais, ce contrôle tient compte de la présence éventuelle d'une indemnité inflation.

La dernière mise à jour de l'API DSN (diffusée fin décembre 2021) consistait, entre autres, à modifier la structure des CRM 34 (reçus ces jours-ci) dans lesquels sont transmis les taux AT à appliquer pour les établissements. Cette nouvelle structure a donc été prise en compte pour le traitement de mise à jour des codes AT à partir des CRM.

Le Bulletin de paye évolue en 2022, conformément à l'Arrêté du 23 décembre 2021, "fixant les libellés, l'ordre et le regroupement des informations figurant sur le bulletin de paie".

Modifications apportées sur le bulletin de paye simplifié dans LD Paye :

- Lignes de cotisations :
. La colonne Part salariale a été renommée en Part salarié,
. La ligne Complémentaire Santé apparaît désormais au-dessus de la ligne Complémentaire Incapacité Invalidité Décès,
. Les lignes Assurance chômage / Chômage et Assurance chômage / APEC n'apparaissent plus dans le regroupement Assurance chômage, et sont renommées Assurance chômage et APEC,
. La ligne Exonérations de cotisations employeur est renommée en Exonérations, Ecrêtements et allègements de cotisations.

- Bloc de pas de page :
Les informations figurant sur le modèle officiel apparaissaient déjà sur le bulletin de LD Paye, elles ont simplement été remises en forme pour respecter la mise en page du bulletin officiel.
A noter que le Montant net des heures compl/suppl exonérées, qui pouvait apparaître dans le tableau des cumuls à 10 colonnes en-dessous du cadre Net à payer, apparaît désormais systématiquement dans le tableau Impôt sur le revenu situé entre le NET A PAYER AVANT IMPOT SUR LE REVENU et le NET A PAYER AU SALARIE (EN EUROS).

Jusqu'alors, le champ Qualification ou Emploi de la situation d'un salarié (en haut de l'onglet Emploi) se présentait sous la forme d'une liste déroulante avec saisie. On pouvait donc soit sélectionner une valeur dans la liste proposée, soit saisir une nouvelle valeur. La liste des valeurs proposées était chargée avec l'ensemble des valeurs déjà utilisées parmi toutes les situations des salariés.
Plusieurs modifications ont été apportées :
 1) Liste des valeurs autorisées
     On peut désormais charger la liste à partir du contenu d'un fichier texte. Le nom et l'emplacement du fichier texte doivent
     être indiqués dans la fenêtre des Paramètres généraux, onglet Contrôle. Le fichier texte doit contenir une ligne par valeur.
     Si aucun fichier n'est indiqué, la liste des valeurs proposées est chargée avec l'ensemble des valeurs déjà utilisées parmi toutes
     les situations des salariés des 2 dernières années écoulées seulement (plus l'année en cours).
     Dans les deux cas, la qualification « courante », celle de la situation du salarié appelée en modification, est toujours ajoutée
     à la liste si elle n'y figure pas suite au chargement effectué via les règles décrites ci-dessus. Dans le cas où la liste a été chargée
     à partir d'un fichier externe, cette valeur éventuellement ajoutée figure en rouge dans la liste.
 2) Contrôle des valeurs autorisées à partir d'un fichier externe
     Lorsqu'on a indiqué un fichier externe pour charger la liste des qualifications ou emplois, lors de la validation d'une situation,
     on a un message d'avertissement (message de type Oui Non) dans le cas où la qualification du salarié n'est pas une des valeurs
     présentes dans le fichier externe.
     De plus, en cochant l'option Qualification ou emploi : Liste limitative dans la fenêtre Paramètres généraux, ce qui n'est possible
     que si on a indiqué un nom de fichier externe contenant la liste des qualifications ou emplois, le champ Qualification ou emploi
     de la situation devient une liste déroulante « stricte », sans saisie possible : on est donc obligé de sélectionner l'une des valeurs
     présentes dans le fichier externe des qualifications. Impossible d'y déroger, sauf dans le cas où l'on modifie une situation et que la
     qualification portée par celle-ci ne figure pas dans la liste (situation saisie avant la mise en place de ce contrôle, ou avant une
     évolution du fichier externe contenant la liste des qualifications) : la qualification « courante » figure dans ce cas en rouge
     dans la liste déroulante. Et lors de la validation, on a un message d'avertissement : il faut confirmer qu'on souhaite conserver
     cette valeur ne figurant pas dans la liste des qualifications normalement autorisées.

Jusqu'en 2021, pour les établissements relevant du BTP, si des cotisations établissements 038, 039, 040 devaient être déclarée, elle étaient accompagnées d'une cotisation établissement 037. Cette dernière n'est plus à déclarer en 2022, mais un CCH du cahier technique oblige toujours qu'un bloc 82 code 037 soit déclaré. La fiche consigne 2503 indique qu'il faut donc désormais la déclarer à 0. Aussi, si une cotisation établissement 038, 039, ou 040 est présente dans le bordereau de versement, sans code 037, un bloc 82-037 sera également créé, à 0, dans la DSN.

Sur les DSN générées à partir de la norme P21V01, lors d'une régularisation de taux PAS, via un bloc 56-Régularisation de prélèvement à la source, avec le code 02 - Rectification sur taux, la rubrique 015-Montant soumis au prélèvement à la source déclaré le mois de l'erreur est alimentée en lieu et place de la rubrique 04-Rémunération nette fiscale déclarée le mois de l’erreur.

Lors de l'ajout d'un nouvel arrêt, la validation de la fiche pouvait provoquer l'erreur suivante, et l'arrêt du programme, si le matricule saisi était erroné : "Erreur à la ligne 237 du traitement Procédure globale zTraiterRelation. L'élément 'ONGLET' est inconnu.".

La recherche de l'outil DSN-VAL correspondant à la norme de la DSN à contrôler pouvait renvoyer vers une version de l'outil trop ancienne. Ainsi, en l'absence de l'outil DSN-VAL dans la norme DSN attendue (à partir de la norme P20V01), le programme pouvait trouver, si elle était encore présente sur le poste, la version de l'outil dans la norme "P02V01" (répertoire "DSN-VAL P2"). Cette ancienne version de l'outil était alors lancé pour contrôler la DSN (récente) au lieu de proposer le téléchargement de l'outil. Ce qui provoquait une erreur de compatibilité de JAVA (car l'outil fonctionnait à l'époque en 32 bits, alors qu'il est désormais obligatoirement en 64 bits).

Dans le cas d'un salarié déclaré sans bulletin, le bloc 53 obligatoire pour les contrats en heure ou en jours (cf correction niveau 257), n'était pas généré (à 0).

A partir des bulletins de février 2022, le calcul du taux de la réduction salariale HS ne tiendra plus compte de la cotisation APEC, tel que prévu dans la fiche du Bulletin officiel de la sécurité sociale (BOSS) dédiée aux exonérations des heures supplémentaires et complémentaires, entrée en vigueur le 1er février 2022.

Nous avions pris en compte des consignes disant, il y a encore peu de temps (décembre ou janvier), que l'ancienneté des salariés du BTP devait toujours être calculée au 31 mars (cela avait d'ailleurs été à l'origine de la correction 260). A ce jour, il s'avère que toutes ces consignes ont été supprimée, sans aucune autre explication. Le calcul de l'ancienneté pour ces salariés a donc été remis comme avant, en P21V01, c'est à dire calculé à la date de la fin de la période déclarée (seul persiste pour ces salariés la particularité sur le calcul en année, mois ou jours).

Les codes "78-20 Caisses de congés payés (CIBTP, Transport, Manutention portuaire) - Base brute de cotisations congés payés" et "78-55 Assiette de pénibilité conventionnelle de la Manutention portuaire", n'étaient calculés en DSN que si le salarié relevait d'une caisse de congés payé du bâtiment. Or, le code 20 doit également être déclaré pour les salariés relevant du transport (code nature de caisse 03) et des dockers (code nature de caisse 04), et le code 55 pour les dockers.

Seuls certains cas de recalcul du plancher/plafond étaient gérés par l'outil d'initialisation des cumuls cotisation. Désormais, le recalcul du plancher/plafond est possible dès lors que les 2 cotisations (modèle et à initialiser) ont un code calcul TX et qu'elles ont des coefficients de plancher ou de plafond différents (et différent de 0).

De nouveaux retours DSN sont retournés à la suite des DSN de janvier 2022 (depuis la norme P22V01). Les comptes-rendus métier CI-BTP et ceux remontant les effectifs généraux et OETH, diffusés à la nouvelle norme NEORES, sont notamment désormais gérés.

Le programme de vérification des mises à jour de DSN-VAL a été modifié afin de pouvoir intervenir en cas de modification des pages ou des liens de téléchargements sans nécessiter de correctif.
De plus des paramètres pourront être mis en place, également sans correctif, en cas d'anomalie générale lors de cette vérification, lors de l'envoi de DSN, ou lors des réceptions des CRM.

Une nouvelle option est désormais affichée sur la dernière étape de création des DSN événementielles qui permet de ne plus créer (ni même proposer) de DSN mensuelle dite « à zéro ». Ce choix est sauvegardé d'une création à l'autre.
Pour rappel, cette proposition de création de DSN mensuelle est faite lorsque la dernière DSN mensuelle de l'établissement est antérieure au mois précédent l'événement. Dans ce cas, l'utilisateur peut décider de créer (ou non) une DSN mensuelle, du mois précédent, contenant uniquement le(s) salarié(s) concerné(s) par les événements envoyés de manière à ce que l'événement puisse être traité au plus tôt par l'organisme compétent (dans le cas contraire, l'événement est généralement mis en attente par l'organisme, le temps de recevoir la DSN mensuelle manquante). IMPORTANT : Si cette DSN « à zéro » est créée et envoyée, la DSN mensuelle « réelle » devra obligatoirement être créée et envoyée avant la veille de l'échéance à minuit, en « annule et remplace ».

Lors de l'impression d'une DSN créée avec la norme P19V01 ou antérieure, si un bloc 42 - Affectation fiscale était présent, l'édition de la DSN provoquait une erreur "Après impression de TOT_ETAB(dsneta1.TOT_ETAB), ligne 1. L'objet dynamique 'fMaDeclaration' n'a pas encore été alloué."

L'outil de contrôle de l'intégrité des fichiers a été amélioré. L'ensemble des éléments à corriger est rassemblé dans un tableau qui indique :
- La liaison impliquée
- Le champ concerné
- La valeur du champ
- Le type de problème rencontré
Un champ permet de choisir la correction à apporter et éventuellement de corriger la valeur.

Les codes options et populations définis dans les contrats de prévoyance n'étaient pas repris dans les DSN Fin de contrat (FCT) ou Fin de contrat unique (FCTU).

Sur certains postes, lorsque la lecture des fichiers en ligne n'aboutit pas, que ce soit pour la récupération des paramètres HTTP pour la DSN, à l'ouverture du dossier par exemple, ajouté au niveau 268, ou pour la lecture des scripts en ligne, cela posait des soucis de blocage de l'application. L'application restait figée pendant de longues minutes, ce qui faisait penser à un plantage. Le fait que cette lecture n'aboutisse pas n'est pas bloquant, mais pour éviter ce temps d'attente, le TimeOut a été limité à 10 secondes par requête, au lieu de 200 auparavant (sachant que système exécute plusieurs requêtes successivement, cela pouvait faire beaucoup de temps à attendre).
De plus, il est désormais possible de complètement désactiver l'appel des fichiers en ligne en paramétrant, dans la section Logiciel du fichier de configuration LDPParam.ini, un mot clé FicOnLine, avec la valeur N. Mais dans ce cas, le système ne bénéficiera plus des paramètres ou fichiers en ligne.

La création du fichier final de la DSN provoquait une erreur "Erreur à la ligne 29 du traitement Méthode EcrireRubrique. Vous avez appelé la fonction VérifieExpressionRégulière. Le format à vérifier est incorrect" lorsque la DSN contenait un bloc 56-Régularisation de prélèvement à la source, ayant la rubrique 005 - Régularisation du taux de prélèvement à la source renseignée avec des décimales.

Après l'exclusion de l'APEC du calcul du taux de la réduction salariale HS, amené par la correction 262, en février 2022, c'est cette fois la CET qui ne sera plus prise en compte dans ce calcul à partir de mars 2022, tel que cela figure dans l'exemple paru le 11 mars 2022 dans le Bulletin officiel de la sécurité sociale (BOSS).
De plus, le taux moyen calculé pour cette réduction est désormais calculé avec 3 décimales, tel que cela est également présenté dans l'exemple du BOSS.

Une nouvelle option permet désormais de recalculer les cotisations des mois antérieurs pour effectuer une régularisation de taux. Il faut pour cela utiliser la mention @Tmm ou @Tmmaa dans le libellé de l'élément variable (où mm correspond au mois, ou mmaa au mois et à l'année, le plus ancien à régulariser). Dans ce cas, le calcul procède à la vérification des valeurs calculées, à partir des cumuls cotisations, sur tous les mois à partir du mois indiqué. En cas de différence, une première ligne de régularisation sera ajoutée pour annuler les calculs effectuées, et une seconde pour recalculer avec le bon taux sur le mois en question.
Le taux vérifier est celui historisé, aussi pour effectuer une régularisation de taux, il faut tout d'abord réinitialiser le taux de la cotisation erronée dans l'historique du plan de paye, puis inscrire un élément variable avec avec la mention @T sur le mois à partir duquel il faut régulariser.
Il n'est pas nécessaire d'inscrire de montant sur l'élément variable. Mais en cas de saisie, le montant sera ajouté sur le mois en question sur la cotisation de régularisation. Sans changement de taux, la seule différence avec la mention @R est que la mention @T fait donc la régularisation par annule et remplace, là où la mention @R ne régularise que le montant indiqué.
Les lignes d'annulation sont créées sans taux afin qu'aucun taux ne soit envoyé en DSN, comme cela est indiqué dans les fiches de consignes Net-entreprises pour une régularisation de taux par annule et remplace.

Afin de permettre le calcul des cotisations complémentaire d'allocation familiale et maladie sur un bulletin sans heure, donc sans SMIC calculé, il est possible de saisir un montant de SMIC à 0,01 dans le cumul MTSMIC (via la rubrique 5976 dans le plan de paye de démonstration LDZ). Ce montant, étant normalement paramétré pour être déclaré en DSN dans le bloc 79, code 01-Montant du SMIC retenu pour le calcul de la Réduction générale ..., ne sera pas déclaré s'il est inférieur à 0,03.

Lorsque des éléments de paye, ayant le même libellé, sont imprimés les uns à la suite des autres sur l'édition de la liste de contrôle par élément de paye, le libellé n'était affiché que sur le 1er élément imprimé.

Dans le fichier d'export de la DSN au format Excel, les commentaires des colonnes G et H (Nombre de blocs 30 et Nombre de blocs 50) étaient créés sur les colonnes F et G (Bulletin et Nombre de blocs 30). Ils ont été replacés sur les bonnes colonnes.

La migration d'un environnement de simulation créé dans une version 9.00 de LDPaye ou antérieure, pouvait provoquer une erreur bloquante.

Lors de la préparation des virements, depuis le menu Traitement mensuel / Préparation et édition des paiements, le libellé des virements d'un paiement fin de mois était obligatoirement "VIREMENT PAYE MM/AAAA"  dans le fichier des virements SEPA (où MM/AAAA correspond au mois de paye). Désormais, ce libellé est paramétrable, pour un paiement fin de mois, dans la fenêtre de Préparation de la liste de paiement des salaires. Par défaut ce libellé reste identique à ce qui était fait précédemment. Si présent dans ce libellé, le mot clé MM/AAAA est remplacé par le mois de paye.

En saisie des éléments variables par rubrique, si l'affichage des commentaires salarié était actif, lors de la création d'un élément variable pour un salarié pour lequel un commentaire était présent dans sa fiche, il n'était pas possible de saisir le libellé, le nombre ou le montant de l'élément. Dès qu'on avait saisi le matricule, la fenêtre de commentaire s'affichait et on ne pouvait plus rien saisir sur la ligne en cours. Le même phénomène se produisait en modification d'un élément variable, pour un salarié ayant un commentaire dans sa fiche.
En même temps que cette correction, une autre chose a été revue : le raccourci clavier associé au petit bouton (en haut à droite) permettant d'afficher/masquer le commentaire est désormais Ctrl F9. En effet, le raccourci antérieur F9 était déjà utilisé pour le bouton Elément fixe.

En gestion des fiches salariés, la gestion du focus a également été revue. Désormais, quand la fenêtre de commentaire salarié s'affiche, elle ne prend pas le focus. Celui-ci reste toujours dans la fenêtre principale. Et donc, pour saisir/modifier ce commentaire, après avoir ouvert la fenêtre de commentaire si elle n'est pas déjà affichée (bouton Commentaire avec raccourci F9), il faut cliquer dans cette fenêtre pour lui donner le focus.

Enfin, dans ces deux fenêtres, la popup d'affichage des commentaires s'affiche toujours par dessus toutes les autres fenêtres, pour qu'elle soit bien visible.

Lors d'un export vers la GED des éditions de taxes sur les salaires, globales à la société, les documents générés n'apparaissaient pas dans la GED de la société.
Cela ne se produisait pas pour les éditions par établissement, seulement pour la société.

Une correction a été apportée dans le calcul de la réduction générale : on gère mieux désormais le cas (assez rare) des mois antérieurs où le SMIC est nul, alors que le nombre d'heures SMIC (cumul RFHORR) est non nul, ce qui résulte la plupart du temps d'une correction « manuelle » du SMIC, via une saisie d'un élément variable sur la rubrique 5976.
Dans ce cas précis, le système additionnait le nombre d'heures SMIC (cumul RFHORR) en tant que valeur du SMIC pour ce mois. Cela ne sera plus le cas à l'avenir. En l'absence du cumul SMIC (cumul MTSMIC ou MTSMIF) sur un mois antérieur, on ne reconstitue le SMIC de ce mois à partir du nombre d'heures SMIC (cumul RFHORR) que s'il existe pour ce même mois un taux SMIC dans le cumul RFTAUX, sachant que ce cumul n'est en principe plus alimenté si on a appliqué les modifications de paramétrage de cette réduction générale telles que cela a été prescrit en 2015.

Lors d'une régularisation d'un taux de cotisation (par @T) sur des mois précédant le début de l'exercice, la somme des retenues salariales et patronales du cumul cotisation du mois courant était mal calculé. Par conséquent, en cas de nouvelle régularisation de taux sur cette cotisation, l'annulation du mois de la régularisation précédente tenait compte, à tort, de toutes les régularisations (des exercices antérieurs).
Un outil (OUTICOCU) a été ajouté pour recalculer les valeurs erronées.

Les basculements de cumuls paramétrés sur le mois de clôture des CP n'étaient pas appliqués pour les salariés n'ayant pas eu de bulletin sur le mois défini.

Lors de l'export GED des bulletins, avec la sélection Tous les bulletins de la sélection courante, un document était tout de même exporté pour les salariés n'ayant pas de bulletin. Il s'agissait alors du dernier bulletin exporté (le salarié précédent, dans l'ordre de traitement, ayant réellement un bulletin).

Pour prévenir certaines erreurs rarissimes, il est désormais possible de désactiver le lancement des threads qui est fait systématiquement à l'ouverture de la fenêtre principale de LDPaye. Cela concerne 3 traitements :
 - la lecture des dernières actualités publiées sur notre site Internet.
 - la lecture des nomenclatures DSN (toutes les tables codifiées : SIRET URSSAF et Caisses de retraite, Code IP...).
 - la lecture des CRM DSN (Comptes-rendus Métier, dont les taux PAS ou les AER).
Pour désactiver ces threads, il faut renseigner un mot-clé fonction du thread concerné (voir ci-dessous), dans la section [THREAD] du fichier des paramètres d'initialisation de LDPaye (fichier nommé par défaut LDPParam.INI, dans le répertoire des programmes), avec une valeur N (pour Non) ou 0 (Zéro).
Exemple pour désactiver les 3 threads :
[THREAD]
ACTUALITES=N
NOMENCLATURES_DSN=N
CRM_DSN=N

Attention : la désactivation de ces threads ne doit être faite qu'à la demande d'une personne qualifiée. La non récupération par ce biais des nomenclatures DSN ou CRM DSN peut avoir d'autres impacts dans LDPaye.

Dans le cas où un retour n'est plus disponible sur le serveur de l'organisme d'origine (URSSAF, Pole emploi, ...), une erreur HTTP 410 est générée. Dans ce cas, cela empêchait de valider la récupération globale des retours et tous les retours étaient alors systématiquement téléchargés depuis cette date à chaque récupération des retours jusqu'à ce que le lien vers ce retour indisponible soit supprimé de la liste des retours sur Net-entreprises. Désormais les liens provoquant ces erreurs 410 sont ignorés.
De plus, les retours AER pouvaient provoquer (notamment dans le cas de l'erreur 410) une erreur de doublon lors de leur enregistrement en raison d'un mauvais traitement des données.

Nouveau code calcul AC pour gérer, à partir de septembre 2022, le taux Bonus/Malus de la cotisation d'assurance chômage.

Il pouvait arriver dans certains cas que des changements de contrats (blocs 41) ayant eu lieu et ayant été déclarés précédemment soient renvoyés dans des DSN mensuelles, sans raison apparente. Cela étant dû à l'ordre de lecture des enregistrements dans un fichier interne qui n'a pas de critère de tri, les cas où cela se produisait sont impossibles à identifier précisément.

Suite à l'information du BOSS paru le 1er juillet 2022, qui fait marche arrière sur l'exclusion de la CET du calcul du taux moyen de la réduction, la modification du niveau 280 ne s'appliquera que durant la période de mars à juin 2022. La CET sera de nouveau prise en compte pour le calcul à partir des bulletins de juillet 2022. Le taux calculé sera également de nouveau arrondi à 2 décimales à partir de ce même mois.

L'option de la déclaration Fin de contrat de travail unique (FCTU) est désormais à l'emplacement de celle de Fin de contrat (FCT) dans la fenêtre de Nouvelle déclaration DSN.
La FCT n'étant plus d'actualité, car remplacée par la FCTU, elle n'est plus accessible depuis la fenêtre de Nouvelle déclaration DSN.
Il reste quand même possible d'utiliser l'option de la FCT en maintenant la touché Ctrl enfoncée lors de l'ouverture de la fenêtre de Nouvelle déclaration DSN.

3 corrections ont été apportées dans la fenêtre principale de gestion des cotisations :

1. Suite à la correction N° 252, dans la fenêtre principale de gestion des cotisations, la colonne Regroupement sur bulletin simplifié ne contenait plus rien.
2. La colonne Coeff majoration a été ajoutée.
3. L'ordre des colonnes Abattement à Régul au net a été revu pour qu'il corresponde à l'ordre d'affichage de ces champs dans la fiche de la cotisation.

Sur l'écran de définition du conditionnement d'une cotisation, dans la liste des opérateurs possibles en colonne 1, il apparaissait la valeur Code profil cotisations, alors qu'il fallait comprendre Code profil rubriques. C'est bien le code profil rubriques qui est testé lors du calcul du bulletin si on référence cette valeur Code profil pour une condition.
De plus, lors de la saisie de la condition, on contrôle (avertissement seulement) que la valeur testée existe bien dans la table correspondante. Là-aussi, il y avait erreur : on testait par rapport à la table des profils cotisations, et non pas celle des profils rubriques. Mais comme les codes profils rubriques et cotisations sont assez similaires, on ne s'était encore jamais aperçu de cette erreur.

Lorsque l'entête de l'opération inscrite dans le script de modification du plan de paye n'a pas d'élément défini (c'est à dire sous la forme [<TYPE>], [<TYPE>/<TYPE LIÉ>] ou [<TYPE>/<TYPE LIÉ>.<NOM LIÉ>]), le parcours des enregistrements du fichier de base n'était pas correctement effectué.
Dans ce cas, le filtrage des enregistrements à traiter doit être fait avec des lignes IF ou IFF. Il est alors désormais possible de tester les rubriques de l'enregistrement lu dans la condition en préfixant le nom de la rubrique à tester par "_".
Exemple :
// Pour filtrer uniquement les enregistrements dont le libellé contient le mot "Réduc"
IF=Position(_LIBE, "Réduc")>0

Dans la fenêtre Export des données d'une déclaration DSN dans un tableur, accessible depuis le bouton Exporter de la liste des DSN, lors de l'export des Données numériques de la DSN (blocs 50-Versement et ses blocs fils), seuls les blocs 50.002 - Rémunération nette fiscale et 50.004 - Montant net versé étaient exportés.
Désormais, les blocs suivants sont également exportés :
. 50.009 - Montant de prélèvement à la source, 
. 50.011 - Montant de la part non imposable du revenu, 
. 50.012 - Montant de l'abattement sur la base fiscale (non déduit de la rémunération nette fiscale), 
. 50.013 - Montant soumis au PAS.

Dans l'édition de la Liste des constantes générales, il manquait la colonne de libellé des constantes. Elle a été ajoutée.

Les codes potentiels du bloc 52 prévus au CT DSN ont été modifiés afin de permettre leur utilisation de manière simplifiée dans les rubriques. Le libellé du code 904 a été modifié pour la mise en place de la « Prime de partage de la valeur ».

Lors des lectures des fichiers en ligne, chaque lecture pouvait attendre sa réponse jusqu'à 10 secondes. Aussi, afin de limiter les temps d'attente en cas d'échec de la lecture, notamment au lancement de l'application, le module de lecture des fichiers en ligne est désormais désactivé automatiquement après 3 tentatives non réussies. Un toast est alors affiché lors des tentatives suivantes pour informer l'utilisateur de cet état.
Le temps d'attente a également été réduit à 5 secondes par lecture. En cas d'échec (si pas d'internet par exemple), l'ouverture du dossier n'est désormais ralenti que d'un vingtaine de secondes environ (au lieu de plus de 2 min 30 s auparavant).

Dans la fenêtre des Bordereaux de versement DSN, la liste des bordereaux pouvait apparaître quelques fois par dessus le bandeau du bas de la fenêtre, rendant ainsi inaccessibles les boutons qui se trouvent sur le bandeau.

Les fenêtres d'Imputation comptable des cotisations et d'Imputation comptable des rubriques n'étaient pas présentées de la même manière. Leur présentation a été homogénéisé.

Un outil a été créé pour gérer les taux de cotisation chômage personnalisés (bonus/malus) reçus en DSN.
Lors de l'affichage d'un retour de DSN indiquant un taux de cotisation chômage personnalisé, le bouton "Gérer les taux de cotisation personnalisés" permet d'ouvrir l'outil. Cela permet :
- la création de la constante générale TXACBM si elle n'existe pas (pour le code calcul cotisation AC).
- la modification du code calcul des cotisations chômages.
- la mise à jour de la déclinaison de la constante générale, par société (ou établissement), à partir des taux personnalisés reçus dans les CRM de DSN.
A l'ouverture d'un dossier, ou après chaque récupération des retours DSN, une vérification des taux reçus dans les CRM est effectuée. Si un taux n'est pas appliqué sur l'établissement concerné (valeur de la constante générale déclinée), un message apparaît pour proposer à l'utilisateur de lancer l'outil.
Cette vérification n'est faite que pour les utilisateurs ayant le droit de modification sur les cotisations, et peut être désactivé en inscrivant un "N" en 1ère position du paramètre programme TXACBM.
Cet outil a également été ajouté dans la liste des autres outils (menu Outils - Autres outils - Lancer un autre outil)

Sur la liste des éléments variables, pour ceux qui découlaient d'un arrêt de travail (cas de la gestion avancée des arrêts de travail), le N° qui apparaissait dans la colonne Type, après la mention Arrêt, était le N° interne de l'arrêt de travail, numéro qui n’apparaît nulle part ailleurs. Désormais, c'est le N° de l’événement DSN associé à cet arrêt qui figure sur cette liste, sachant que ce N° figure aussi en partie droite de la fenêtre principale de gestion des arrêts. On peut donc faire une recherche sur ce numéro, comme indiqué dans la documentation.

Complément du 20/09/2022 : par souci de cohérence, la même chose a été faite en saisie des éléments variables. c'est désormais le N° d'événement DSN qui est affiché et non le N° interne de l'arrêt de travail.

Le principe de taux bonus/malus d'assurance chômage prévoit qu'un taux différent de celui reçu par CRM est à appliquer pour les salariés affiliés à une caisse de CP. Pour gérer ce cas, le code calcul [AC] recherche désormais le taux, lors du calcul d'un bulletin pour un salarié affilié, dans la constante générale TXACCP avant de rechercher dans la constante générale TXACBM (mais après la recherche dans la constante salarié TXACBM). Ce taux n'étant pas véhiculé dans le CRM 117, cette constante n'est pas contrôlée à l'ouverture du dossier ou à la réception des CRM, ni gérée dans l'outil (cf niveau 322). La saisie de ce taux dans TXACCP doit donc être faite manuellement depuis la saisie des constantes générales (avec ou sans déclinaison).

Lors de la lecture d'un fichier d'import dans la DSN, le SIRET pouvait dans certains cas être remplacé par le SIRET d'un autre établissement de l'environnement. Cela arrivait de manière aléatoire (ça dépendait de la dernière position d'un fichier qui n'avait pas été lu lors de l'import) mais lorsque cela se produisait, toutes les lignes correspondant au SIRET en question étaient impactées.
De plus, lors de la création des blocs 40 manquants (salariés partis), des valeurs "99" étaient être inscrites à tort dans les rubriques 021, 042, 073 et 074, si la zone correspondante n'est pas renseignée dans la situation du salarié.

En cas d'anomalie lors du téléchargement du fichier des CTP dans le répertoire Nomenclatures, la liste des CTP était initialisée avec un fichier par défaut trop ancien (livré dans le répertoire de l'application), ce qui provoquait une erreur lors de l'exécution du contrôle de cohérence indiquant qu'une règle sur le CTP 725 n'avait pas été interprétée correctement et donc était ignorée. Le fichier livré par défaut a été mis à jour.

Suite à une énième mise à jour du Journal de Maintenance de la Norme (JMN) DSN et à une énième mise à jour de la fiche consigne 2592 relative à la déclaration de la Prime de Partage de la Valeur (PPV), le bloc 52-prime doit désormais être déclaré avec une période de rattachement (correspondant au mois complet de la date de versement de la prime) qui fixe le millésime pour la DGFiP et une date de versement d'origine pour les primes à attacher à une autre date (cf. fiche consigne).
Pour indiquer ces dates dans LDPaye, on peut désormais inscrire la date de versement d'origine dans la date de début de l'élément variable, et la date de versement de la prime réelle dans la date de fin. Si ces dates sont identiques, seule la date de versement d'origine sera prise en compte, la période de rattachement sera définie avec la date de règlement du bulletin.
En cas de saisie avec régularisation (@R..) la période de rattachement est définie à partir de ce mois régulé, quelque soit la date de règlement ou la date de fin saisie.

Il n'était pas possible de définir les paramétrages des blocs 81, pour les codes 001 et 002 (apprentis), affiliés au bloc 78 code 02-Assiette brute plafonnée. Une mise à jour automatique des paramètres sera effectuée à la première ouverture du dossier avec ce niveau.

Afin de diagnostiquer d'éventuels problèmes d'affichage, il est maintenant possible de visualiser le code source des retours DSN dans les deux fenêtres de visualisation des retours. Un bouton Source a été ajouté dans ces fenêtres, mais invisible par défaut. Pour l'afficher, il faut ouvrir la fenêtre de visualisation en maintenant la touche Alt enfoncée. Ce bouton permet alors de basculer de la visualisation classique à l'affichage de la source XML.

Suite à la modification du niveau 314 qui ajoutait des rubriques du bloc 50 dans l'Export des données d'une déclaration DSN dans un tableur, il manquait encore le taux de prélèvement à la source (S21.G00.50.006) afin de permettre de se servir de cet export pour des régularisations de DSN (en import de DSN)

Les fichiers des nomenclatures et des CTP étaient systématiquement téléchargés à l'ouverture de l'application alors qu'ils ne devaient être téléchargés qu'une fois par jour. La présence du dernier fichier téléchargé (le xml des CTP) est désormais également contrôlé pour relancer ou non ces téléchargements.

Les modifications écrites en WLangage sur plusieurs lignes étaient mal gérées dans l'outil de script de modification du plan de paye et provoquaient une erreur de compilation. Il fallait alors écrire chaque ligne dans des opérations séparées (précédées de WL=).

Le calcul des régularisations de cotisation (@R, @T, @A, @P) ne fonctionnait pas pour les cotisations d'assurance chômage (cotisations avec le code calcul AC).

Un nouvel outil a été ajouté pour forcer la dernière valeur des rubriques de type Identifiant automatique. Pour lancer cet outil, il faut aller dans le menu Outils - Autre outils - Lancer un autre outil, puis choisir Lancer une fenêtre Windev, et saisir la fenêtre OUTIIDAUTO.

La date d'entrée a été remplacée par la date d'ancienneté dans l'export spécifique GPI.

La saisie des régularisations, avec ou sans @, sur les cotisations de réduction patronale des heures supplémentaires (cotisations ayant le code calcul RP) n'était pas prise en compte lors du calcul. Désormais, le nombre d'heure à ajouter dans le calcul peut être saisi, en saisie d'élément variable, dans la colonne nombre de la cotisation. Ce nombre d'heure sera ajouté au nombre d'heures calculées. ATTN : en cas de régularisation sur les mois antérieurs (@Rmm), le plafond des réductions appliqués (via le cumul RFPLAF) n'est pas contrôlé et ne limite donc pas le calcul de ces régularisations. Il est par contre bien pris en compte si la régularisation porte sur le mois courant.

Lorsque les fichiers de virement SEPA, générés depuis l'application, sont envoyés via CUBICUS, il est désormais possible de chiffrer le fichier afin de sécuriser les échanges. Pour cela, un mot de passe est à paramétrer à la fois côté CUBICUS et dans la fenêtre de génération des virements. ATTENTION : le mot de passe renseigné est valable pour toutes les sociétés définies dans l'application. En effet, le mot de passe étant unique dans CUBICUS, il doit être le même pour l'ensemble des échanges avec l'application.

LDPaye prend désormais en charge la présence d'un proxy pour les éléments qui nécessitent un accès Internet. 
Pour paramétrer ce proxy, dans la fenêtre d'ouverture de session, appuyez sur les touches Alt F1 et cliquez ensuite sur le bouton Proxy. 
Dans la fenêtre qui s'ouvre, renseignez les paramètres du proxy et cliquez sur OK pour les activer. Le proxy est alors directement pris en charge par l’application (inutile de la relancer).
Avant de valider les paramètres, vous pouvez les tester ; si aucun test n’a été réalisé, un test sera lancé lors de la validation des paramètres.

Il est désormais possible de conditionner les rubriques et cotisation en fonction du code IDCC de la convention collective du salarié, ou du code risque inscrit dans le code AT défini pour le salarié.

LDPaye récupère certains fichiers de paramétrages et de script via Internet. Dans certains cas, cette récupération ne s'effectuait pas correctement : la version du fichier récupérée n'était pas la bonne en raison de l'utilisation d'un cache web. Cette correction supprime donc l'utilisation du cache pour accéder systématiquement à la dernière version des fichiers à télécharger. 
De plus, malgré les différentes corrections précédentes, des erreurs de code CTP inconnu persistaient dans certains cas lors du contrôle de cohérence de la DSN. Cela était dû au fichier des CTP récupéré qui était soit trop ancien (à cause du cache internet), soit partiel, soit vide. La liste des CTP est désormais chargée à partir du fichier livré dans les programmes ET du fichier téléchargé (et non qu'un seul des deux).

Une erreur était déclenchée lors de l'appui sur le bouton Supprimer dans la liste des établissements, si aucun établissement n'est sélectionné.

Les possibilités offertes par les corrections V5.10 niveaux 34 et 113, enregistrées dans le paramètre programme BULLETA, apparaissent désormais sur l’onglet Bulletin de la fenêtre des paramètres généraux.
Il est en effet désormais possible de paramétrer depuis l'onglet Bulletin de la fenêtre des paramètres généraux, le titre du bulletin de paye et la police utilisée, ainsi que le libellé affiché pour identifier l'employeur.

Rappel du correctif V5.10 niveau 34 : ENTETE DU BULLETIN : LIBELLE ETABLISSEMENT OU SOCIETE
Lors de l'édition du bulletin de paye, il est possible de choisir le libellé affiché pour identifier l'employeur.
Pour définir ce libellé, le paramètre programme BULLETA doit exister et contenir en première position de la valeur alpha :
- 1 (ou omis) : Libellé de la société
- 2 : Raison sociale de la société
- 3 : Libellé de l'établissement
- 4 : Raison sociale de l'établissement (ou Enseigne)

Rappel du correctif V5.10 niveau 113 : TITRE BULLETIN DE PAYE MODIFIABLE
Il est possible de remplacer le titre du bulletin de paye. En standard, le titre est BULLETIN DE PAYE.
Pour obtenir un autre titre, il faut créer un paramètre programme BULLETA, et renseigner le titre souhaité en position 65 à 128.
En position 129 à 192, on peut aussi spécifier la police à utiliser pour ce titre.
En effet, selon le titre choisi, il faudra parfois réduire la taille de la police utilisée, sans quoi une partie de ce titre sera tronquée.
La police utilisée en standard est Arial,20.
Pour spécifier une autre police, indiquez en position 129 le nom de la police, une virgule, et le pas souhaité.
Exemple : Arial,18

Selon les dates indiquées dans les comptes rendu définissant le taux de bonus/malus pour les cotisations chômage (CRM 117), il peut arriver que le taux pris en compte par l'application ne soit pas le dernier reçu. Ce correctif rétablit le bon traitement de ces retours.

L'affichage des acomptes doit obligatoirement être daté sur le bulletin de paye.
Pour une rubrique datée, si la date de début et la date de fin est identique, l'affichage sera dorénavant sous la forme de ... DU JJ/MM afin d'éviter d'avoir DU JJ/MM AU JJ/MM dans le cas où la période porte sur une seule journée.
Exemple : ACOMPTE DU 26/12 au lieu de ACOMPTE DU 26/12 AU 26/12
Ce type d'affichage sera aussi mis en œuvre pour les absences qui portent sur une seule journée.

Pour les salariés en forfait Jour (code Unité d'expression du temps de travail contractuel à 20-Forfait jour), à compter du 01/01/2021, la règle est la même que pour les unités classiques 10-Heure, 12-Journée, 21-Forfait heure : si le salarié est à temps partiel (code modalité autre que 10-Temps plein), le salarié n'est plus compté pour 1 comme auparavant, mais au prorata de la durée contractuelle portée pour ce salarié par rapport à la durée contractuelle de l'établissement. 
Exemple : si le salarié est à 109 jours pour une durée établissement de 218, il est décompté pour 0,50.

Pour la DFS (Déduction Forfaitaire pour Frais professionnels), il était prévu qu'à compter de janvier 2023, l'application de la DFS ne puisse se faire, mois par mois, que s'il y avait effectivement des frais supportés par le salarié.
Pour les secteurs listés ci-dessous, cette règle a été abandonnée. En contrepartie, une sortie progressive de ce mécanisme de la DFS est actée, via un abaissement progressif du taux de la DFS applicable chaque année.
Salariés concernés (avec le code catégorie DFS correspondant) :
 - Journalistes (04) 
 - Chauffeurs routiers (13)
 - Ouvriers du BTP (19)
Rappelons que les VRP (09) pouvaient déjà bénéficer de la DFS même en l'absence de frais (règle déjà mise en place en 2022). 
Conséquence pour 2023 : les taux DFS, portés dans les fiches des salariés, restent inchangés (ils ne commenceront à baisser qu'en 2024). Et on peut appliquer la DFS même en l'absence de frais. Pour cela, via ce correctif, les codes catégorie DFS 04, 13 et 19 sont ajoutés au code 09, dans le paramètre programme CUM*_FRDFS, en positions 65 à 78.
En effet, ce paramètre programme permet de définir la liste des codes catégories DFS pour lesquels on peut appliquer la DFS même en l'absence de frais.

L'application des paramètres de proxy de LDUpdate lors de la vérification des mises à jour disponibles, empêchait le prise en compte du proxy défini dans LDPaye lors du fonctionnement de l'application, en dehors de la fenêtre de paramétrage.

Depuis la norme P23V01, l'extension du régime définie dans l'onglet Régime de la fiche établissement est obligatoire. Si l'établissement n'a pas à appliquer d'extension (hors Alsace-Moselle), il faut utiliser le code 99-Non applicable. Ce code a été initialisé dans les établissements existants lors de la mise à disposition de cette norme, mais n'était pas initialisée en création d'un établissement. C'est désormais le cas.

Lors de l'édition de plusieurs bulletins successifs, en mode détaillé, avec affichage du tableau des cumuls complémentaires en bas de bulletin, la zone en haut du bulletin dans laquelle était affichée l'identification de l'URSSAF n'était imprimée que sur le 1er bulletin. Cette zone n'est pas imprimée sur le bulletin simplifié, ce n'est plus une zone obligatoire. Le bulletin détaillé ayant été gardé uniquement pour contrôle, cette zone a été complètement masquée (car n'étant pas envoyée en DSN, elle était quelque fois pas maintenue à jour).

Dans la fenêtre de Fiche Rubrique, dans l'onglet Déclaration, le bouton de Motif DSN suspension contrat était mal positionné.
Les boutons en bas de fenêtre ont également été repositionnés.

L'installation du module JAVA (utilisé pour le contrôle de DSN) depuis la fenêtre de MAJ de DSN-VAL, n'était pas installé dans le bon répertoire. Cela forçait l'utilisateur à réinstaller ce module lors du contrôle.

Dans la fenêtre de consultation de l'historique des valeurs des constantes historisées, accessible depuis une fiche salarié, les valeurs des constantes historisées n'étaient pas visibles dans la table des historiques. Il fallait cliquer sur le bouton Afficher pour pouvoir voir les valeurs modifiées.
Pour faciliter la consultation de l'historique, ces valeurs sont maintenant affichées directement dans la table de l'historique des constantes salarié.

Un nouveau module de déclaration préalable à l'embauche (DPAE) est mis en place afin de déclarer les nouvelles embauches via une API et ainsi récupérer les retours dans l'application. Une actualité sera publiée ultérieurement pour activer ce module en lieu et place du module de pré-remplissage de la DPAE sur le site de Pôle emploi.

La transmission d'une DSN évènementielle (hors FCTU) oblige la saisie d'un bloc 07 correspondant au contact émetteur. La création de ce bloc ne prenait pas en compte le paramétrage dans la table de Contacts pour la DSN. Lors de la création de ce bloc 07, le Type de contact (rubrique 07.004) était mis par défaut soit à 01 - contact chez le déclaré pour les IJ; soit à 09 - contact chez l’établissent centralisateur pour les IJ. Le choix du contact émetteur tient compte désormais des types de contact définis pour les contacts. Le type 01 étant pris en priorité sur le type 09 si les deux sont cochés. Si aucun contact n'a été défini avec les types 01 ou 09, la sélection du type par défaut sera faite comme avant.

Le choix de l'émetteur de la DSN, sur la dernière étape de la création d'une nouvelle DSN apparaissait sur les DSN événementielles alors qu'elle n'était pas prise en compte. Ce choix n’apparaît désormais que lors de la création d'une DSN Mensuelle.

Les contrôles fait lors de la saisie d'un individu non salarié étaient trop restrictifs et ne correspondaient plus à la norme actuelle de la DSN. Ils ont donc été revus pour correspondre au cahier technique P23V01.

Les contributions liées à l'apprentissage (blocs 82-076 à 82-079) étaient déclarées 2 fois pour les DSN adressées à la MSA. Une fois issue directement des cotisations établissement, et une autre fois issues du bordereau de versement MSA (lui-même généré depuis ces mêmes cotisations établissement). Ces blocs ne sont désormais plus générés depuis le bordereau.

Une collecte d'information sur l'utilisation des fonctionnalités de l'application a été implémentée. Cette collecte ne concerne que les informations relatives aux programmes utilisés et ne recueille aucune donnée de la base de données du dossier ouvert.
L’objectif de cette collecte est d’identifier les problèmes éventuels de fiabilité ou de lenteur dans l’application, et ainsi augmenter la qualité du service rendu. La participation à ce programme n’a pas d’impact sur le fonctionnement de l’application.
Lors de la première ouverture de LDPaye par un administrateur de sécurité, une nouvelle fenêtre s'ouvrira pour lui permettre d'activer cette participation. Cette fenêtre n’apparaîtra qu’une seule fois. L'administrateur de sécurité pourra ensuite modifier son choix à tout moment, depuis la fenêtre des Paramètres de sécurité de l’environnement, accessible depuis l'écran d’ouverture de session en appuyant simultanément sur les touches Alt+F2.

Dans les contrats de prévoyance, les cases à cocher Déclarer en DADS-U et Inclure RIB Salarié dans DADS-U ont été supprimés suite à la désactivation de la DADS-U. De plus, lors de la copie d'une rubrique ou cotisation, la copie des paramètres N4DS n'est plus effectuée.

Une nouvelle option sur l'onglet Général de la fenêtre des paramètres généraux (Menu Plan de paye/Paramètres généraux) permet d'activer la numérotation automatique des fiches salariés. Si activée, lors de la création d'une fiche salarié, ou lors du choix de la société lors d'une duplication, le matricule sera chargé avec le n° correspondant au matricule le plus élevé déjà existant + 1, pour la société. Cette numérotation automatique ne gère que les matricules composés exclusivement de chiffres. Les matricules avec des lettres sont ignorés. Si le matricule maximum (9999) existe déjà dans la société courante, le matricule proposé sera le 1er matricule inexistant dans la société courante, à commençant cette recherche à partir de 0001 : on bouche ainsi les trous de numérotation s'il y en a.

Un nouveau module de gestion des bordereaux de paiement des IJSS est mis en place pour gérer la subrogation des indemnités en cas d'arrêt de travail. Une actualité sera publiée ultérieurement pour activer ce module.

Dans la fenêtre d’édition des Bordereaux de versement DSN, une jauge de progression s'affiche désormais lors de l'envoi des bordereaux vers la GED, depuis le bouton Vers GED.

La liste des paramètres jugés indispensables a été revu compte tenu des changements liés à la norme P23V01 et aux évolutions des réglementations.

Depuis la fenêtre de modification d'une DSN, un bouton Importer un fichier DSN a été ajouté (l'ancien bouton Importer a été renommé en Importer un fichier Excel) et permet d'intégrer un fichier DSN final dans la DSN courante.
A l'ouverture de cette nouvelle fenêtre, il faut sélectionner le fichier à intégrer, puis cliquer sur le bouton Importer pour intégrer les données dans la DSN courante.
A noter : Tous les blocs ne sont pas repris. Seuls les blocs des établissements déjà existant dans la DSN courante (SIRET identique) sont repris. Les salariés sont recherchés par leur n° SS (ou NTT). Les blocs 30 ne sont pas repris si un bloc 30 équivalent a été trouvé dans la DSN courante. Les contrats ne sont également pas repris si un contrat existe déjà avec la même date de début (dans ce cas, le n° de contrat du bloc contrat existant est repris dans les blocs importés).
Les données à destination des OC ne sont pas repris (blocs 20 pour des OC, 55, 78-31, 81-59, ...).

S'il y a plusieurs déclarations dans un même envoi de DSN, le n° de la déclaration est désormais affiché dans le libellé. Cela permet de retrouver la déclaration concernée en cas d'anomalie détectée par DSN-VAL.

Le montant du solde de la taxe d'apprentissage, dans le CTP 995 du bordereau URSSAF, est à déclarer dans la rubrique assiette du bloc 23, et non dans la rubrique montant de cotisation. Ce montant reste néanmoins affiché en montant de cotisation dans le bordereau de versement, la modification est effectuée uniquement à la création de la DSN.

Suite à la correction 386 (mars 2023), les blocs 82-cotisation établissement, à destination de la MSA, pour les codes 076, 077 et 078, n'étaient plus inclus dans la DSN.

Suite au correctif 408, le montant de la cotisation agrégée 995-920 (solde de la taxe d'apprentissage) a été déclarée en assiette, tel que cela a été précisé dans les consignes, or il n'était pas précisé que ce n'était pas le montant qui était attendu, mais bien la masse salariale soumise correspondant à la période de référence (la véritable assiette). Cette assiette a donc été ajoutée dans la fiche de cotisation établissement afin de générer correctement la cotisation agrégée.

Les retours de DSN concernant les erreurs d'identification de salariés passent désormais par une nouvelle norme de présentation des données NEORES. Ces retours, beaucoup plus détaillés sur les motifs d'erreurs et possibilités de résolution, sont pris en charge et sont affichés sous forme de fichier PDF.
Par ailleurs, lors de l'affichage d'un retours 118 119 120, il était possible que le document affiché ne corresponde pas au retour sélectionné. L'affichage de ces retours pouvait également faire apparaître des champs décalés par rapport au libellé de la ligne.
Enfin, dans la fenêtre listant les retours, le types de retour 120 n'était pas correctement affiché dans la liste déroulante du filtrage de la table.

La fenêtre des Paramètres pour l'API-DSN a été modifiée pour permettre de paramétrer la désactivation du cache internet (nouvelle case à cocher Désactiver le cache internet). De plus, l'unité de temps est désormais précisée dans le champ Durée du time out (en secondes).
Enfin, la gestion du time-out et le traitement des erreurs HTTP ont été optimisés.

Windows rend régulièrement les lecteurs réseaux inactifs (sortie de veille, inactivité, ...), et des erreurs peuvent se produire dans l'application suite à cette inactivité des lecteurs réseaux.
Pour éviter cela, il est préférable d'utiliser les chemins UNC plutôt que les lecteurs réseaux lors de la sélection d'un fichier ou d'un répertoire dans l'application.

Exemples : un lecteur réseau L:\ pointe vers un répertoire partagé LDSysteme\ sur un serveur SRV-PROD.
- Le chemin UNC du lecteur L:\ est \\SRV_PROD\LDSysteme\.
- Le chemin UNC du fichier L:\MonRepertoire\MonFichier.txt est \\SRV_PROD\LDSysteme\MonRepertoire\MonFichier.txt.

Désormais, lors de la sélection d'un fichier ou d'un répertoire dans l'application depuis le sélecteur de fichier/répertoire, si le chemin du fichier ou du répertoire sélectionné comporte un lecteur réseau, alors il sera automatiquement remplacé par son chemin UNC. Et si un chemin de fichier ou de répertoire est saisi manuellement sans passer par le sélecteur de fichier/répertoire et comporte un lecteur réseau, alors il sera proposé à l'utilisateur de remplacer le chemin saisi par son équivalent UNC lors de la validation de la fenêtre.

De même, si les chemins des répertoires partagés définis dans l'application comportent des lecteurs réseaux, alors ceux-ci seront automatiquement transformés en leurs équivalents UNC.

Lors de l'envoi du fichier pdf du bulletin de paie sur l'espace NEOBOX, le code retour 100 est pris en charge afin de ne plus bloquer le traitement.

La fenêtre d'interface comptable a évolué afin de générer les fichiers exportés en fonction d'un fichier de description (fichier avec l'extension _.fdf_). La sélection d'un _Progiciel comptable cible_ permet la sélection rapide d'un fichier de description compatible avec LDCompta (les fichiers fdf standards correspondants ont été copiés dans le répertoire des programmes). Un dernière option _Autre_ permet de définir un autre fichier. En outre, pour les exports compatibles avec _LDCompta Version 11_, il est désormais également possible de générer un fichier d'interface au format Excel.

L'option Arrêter le calcul si une valeur a pu être extraite par cette règle, qui peut être cochée sur un paramètre DSN, n'était pas prise en compte correctement lors du calcul de la DSN.

 Ajout de deux icônes indiquant l'état de mise à jour pour: * L'outil de mise à jour LDUPDATE  * le moteur de base de données (pour les installations basées sur un serveur de données). Ces icônes sont présentes dans les widgets information et configuration ainsi que dans la fenêtre environnement.

Le montant net social a été ajouté sur l'édition du bulletin simplifié, ainsi quand dans les paramétrages DSN. Une rubrique spécialisée (RUB*NETSOC), contenant la ligne du bulletin à afficher, doit être ajoutée pour que cette mention soit affichée sur l'édition. Pour le paramétrage du net social dans le plan de paye, se reporter à l’actualité LDPaye correspondante.

Mise en place d'un système de mise à jour automatique du fichier de paramétrage, généralement nommé _LDPParam.ini_, au lancement de l'application.

La correction niveau 413 qui propose d’utiliser les chemins UNC au lieu des lecteurs réseau ayant provoqué quelques soucis et surtout beaucoup de questionnements, seuls les chemins enregistrés dans le fichier de paramétrage, généralement nommé _LDPParam.ini_, et qui contiennent un lecteur réseau sont désormais migrés en chemin UNC. Lors de la sélection d'un fichier ou d'un répertoire dans la fenêtre _Ouverture de session - Choix des répertoires_, accessible en appuyant sur les touches _ALT+F1_ depuis la fenêtre d'identification, si le chemin du fichier ou du répertoire sélectionné comporte un lecteur réseau, alors il est automatiquement remplacé par son chemin UNC. Et, toujours dans la fenêtre de _Choix des répertoires_, si un chemin de fichier ou de répertoire est saisi manuellement sans passer par le sélecteur de fichier/répertoire et comporte un lecteur réseau, alors il sera proposé à l'utilisateur de remplacer le chemin saisi par son équivalent UNC lors de la validation de la fenêtre.

Le code 023 du bloc 51 n'apparaissait pas dans la liste des paramètres DSN. Il s'agit d'un code potentiel qui a été utilisé pour déclarer le nombre de jours de RTT monétisés.

La migration des chemins prévue par le corectif 421 provoquait l'erreur :"Erreur à la ligne 33 du traitement Procédure interne xModifierChemin.
La procédure 'gValiderCheminRepertoire' n'est pas accessible".

Lors de l'ouverture d'un CRM 121 (identité) une erreur pouvait être provoquée, et arrêter l’application, si une date de naissance n'est pas correctement entrée dans le document. Par ailleurs, si une erreur sur une date de naissance a été rapportée, elle apparaissait en double en bas du compte rendu. Une amélioration de la présentation des CRM 118, 119 et 120 (affichage correct des dates) a également été réalisée.

Lors de la création d'un nouveau dossier de paye, avant de créer le 1er salarié, il faut au préalable avoir créé les fiches sociétés et établissement. Si cela n'était pas respecté, une erreur était provoquée et arrêtait l’application. Un contrôle interdit désormais la création de salarié si la fiche société n'a pas été initialisée et au moins un établissement n'a pas été créé. 

Dans la fenêtre de modification de données par lot, si on double clic sur le bouton Suivant quand on est positionné sur Nouveau scénario, l'application déclenche une erreur car aucun fichier n'est sélectionné. Ce correctif impose la sélection d'un fichier et évite le déclenchement de l'erreur.

Les filtres applicables sur la liste des comptes rendus métiers DSN pouvaient ne pas fonctionner correctement. De plus, le tri par établissement, société, type de DSN et type d'envoi a également été amélioré.

En DSN, les salariés qui ont l’option _Temps Plein sur la Retraite_ ont obligatoirement l’option _Temps Plein sur le Régime de Base._ En effet, il n’y a que deux valeurs possibles pour la rubrique 40.044 :  * 01 : Pour la vieillesse régime de base, * 02 : Pour la vieillesse régime de base et la retraite complémentaire. Or il était possible de ne cocher que l’option Temps plein sur le régime de Retraite, sans le régime général, dans la situation du salarié. Désormais, dans la fiche de situation, onglet _Emploi_, lorsqu’on coche l’option _Temps Plein sur la Retraite_, l’option _Temps Plein sur le Régime Général_ est automatiquement cochée et grisée. Une modification automatique des situations ayant l’option sur le régime retraite, sans le régime général, est effectué à la première ouverture du dossier avec cette correction.

Lors de la génération des DSN, les régularisations de cotisations prévoyance ne généraient pas tous les blocs 79 et 81 paramétrés dans le contrat de prévoyance, pour la période régularisée. Seuls les blocs ayant une valeur étaient générés. Cela pouvait provoquer des anomalies notamment si seule la base de cotisation était régularisée, mais que cela n’avait pas d’impact sur le montant cotisé. Dans ce cas, le bloc 81-059, pour la période régularisée, était manquant.

Lorsqu’une colonne d’un journal standard est alimenté par une constante salarié, la valeur de cette constante est renvoyée pour chaque répartition calculée (selon les regroupements définis). Le calcul pouvait être erroné dans certains cas, notamment lorsque la répartition est portée sur un code analytique et que la répartition du salarié a évolué depuis le début de l’exercice.

Les CRM 117 indiquant les taux de cotisation chômage personnalisés (Bonus/Malus) fournissent, dorénavant, le taux à appliquer pour les salariés affiliés à une caisse de congé payé.
Ce correctif ajoute la prise en charge de ces taux de cotisation personnalisés pour les caisses CP et assure son intégration dans le plan de paye.
Ce correctif englobe :
- La création d'une constante générale TXACCP (si elle n'existe pas).
- La vérification d'absence d'écart entre les taux reçus via les CRM 117 de la DSN et les taux paramétrés.
En cas d'écart, LD Paye fera apparaître un message au démarrage de l'application pour effectuer la mise à jour des paramètres.
à noter que la fenêtre de paramétrage de ces taux est accessible depuis la fenêtre de visualisation d'un CRM 117.

Le calcul des cotisations agrégées pouvait être erroné en cas de détail de la cotisation par taux AT (cas du CTP 100) si des régularisations ont été saisies, sur des mois antérieurs, pour lesquels le taux AT était différent (dans l'historique des taux AT) du taux AT actuel.
De plus, toujours en cas de régularisation sur des mois antérieurs, les montants pour contrôle des cotisations agrégées des CTP 100, 726, et 727 pouvaient être erronés.

En cas d'affichage simultanément de la fenêtre d'actualités et celle de la disponibilité d'une nouvelle version, l'application pouvait s'interrompre et déclencher une erreur.

Application du cahier technique DSN P24V01 (1ère déclaration au 5 ou 15 février 2024).

Mise en place de la gestion des _Cotisations agrégées_ dans le module _Script de modification du plan de paye_, accessible depuis le menu _Outils_.

La gestion des fichiers en ligne a été modifié afin de permettre la mise à jour de certains fichiers, sans attendre le prochain correctif. Ainsi, le fichier contenant les règles de contrôle de cohérence en DSN est désormais mis à jour automatiquement (si nécessaire) avant chaque contrôle. Ceci afin de permettre une meilleur réactivité dans les modifications de ce fichier (il n'était mis à jour jusqu'à présent que lors de la publication d'un correctif).

L'affichage des comptes rendus de DSN appelé "CRM Effectifs" indique l'effectif moyen de chaque entreprise calculé par l'URSSAF ou la MSA. Désormais, le tableau fait apparaître la codification de chaque effectif renseigné.

La taille maximale des fichiers de données était fixé à 2 Go par fichier. De ce fait, si un fichier atteint cette taille, plus aucun enregistrement ne pouvait y être ajouté. Il fallait alors optimiser le fichier pour libérer la place des enregistrement supprimés, et dans certains cas épurer une partie du fichier. La limite de taille de tous les fichiers est désormais levée dans l'analyse. Cette modification ne sera pas appliquée sur les dossiers courants mais pourra être mise en place lors de la réindexation des fichiers (menu _OUTILS / Réindexation des fichiers_). Dans cette fenêtre, une case à cocher _Mettre à jour la structure des fichiers_ a été ajoutée afin de lancer la modification structurelle des fichiers de données et ainsi pouvoir, entre autres, dépasser la limite de 2 Go des fichiers.

Suite à l'arrêt du protocole TLS 1.0 et 1.1 sur le domaine net-entreprises.fr, les envois de DSN et la récupération des retours DSN peut poser des soucis sur certains postes fonctionnant sur des systèmes d'exploitation plus anciens (Windows XP, Windows Serveur 2008, ou 2012 par exemple). Il est désormais possible d'activer un mode WD28 qui exécute les requêtes HTTP via un programme externe, plus récent, capable de gérer ce problème de compatibilité. En revanche, l'utilisation de ce mode rallonge le temps de traitement habituel. Une activation du mode est nécessaire (fenêtre des paramètres de la fenêtre d'envoi d'une DSN).

Lors de l'ouverture d'un dossier, le message indiquant qu'au moins un taux ACBM n'est pas à jour par rapport à ceux récupérés en retour de DSN (CRM) pouvait s'afficher à tort si un établissement a été désactivé et qu'un CRM a été envoyé pour cet établissement.

Un critère de sélection par établissement de la société courante a été ajouté à la fenêtre de la liste des DSN. La sélection d’un établissement permettra d’afficher : - uniquement les envois contenant une déclaration qui concerne cet établissement dans l'écran _Liste des déclarations regroupées par envoi_, - les déclaration qui concernent cet établissement uniquement dans l'écran _Liste des déclarations_ non regroupées par envoi. A noter que la sélection d’un établissement restreint la recherche des déclarations à la société courante uniquement. De plus, une case à cocher _Rafraichissement manuel_ a été ajoutée dans l'écran _Liste des déclarations_ non regroupées par envoi. Cette case sera automatiquement cochée s’il existe au moins 10 000 déclarations dans la base de données.

Pour tout bloc 60-Arrêt, ayant un motif de type temps partiel thérapeutique, et si aucun bloc 66 n'a été calculé par les paramètres DSN, un bloc 66 est désormais créé à 0.

La récupération de l’outil DSN-VAL a été amélioré pour éviter les coupures en cours de téléchargement. Seules les versions 64 bits sont maintenant supportées.

A la 1ère ouverture d'un dossier venant d'être migré d'une ancienne version, antérieure ou égale à la version 9.60 niveau 206, un message d'erreur était provoqué lors d'une requête de mise à jour du dossier.

Optimisation de la vitesse d’affichage des statuts des envois DSN.

Lors de l’affichage des retours d’une DSN, l’application peut s’arrêter inopinément. Le passage d’un retour à un autre ne nettoie pas correctement la mémoire et stoppe l’application lorsqu’il faut affiche le retour suivant.

Les cotisations dues au titre de la _CCVRP_ étant recouvrées depuis 2019 par l’_URSSAF_, l’organisme de base _CCVRP_ a été supprimé dans _LDPaye_.

Le programme des règles de contrôle des DSN a été amélioré afin de pouvoir prendre en charge de nouveaux éléments déclarés en DSN, et également pour pouvoir réaliser, lorsque cela est possible, des contrôles au niveau de chaque salarié, et plus seulement pour la globalité de la déclaration.

Mise à disposition du fichier des liens de l’aide en ligne dans les fichiers en ligne, de manière à ce qu’il soit téléchargé au lancement de _LDPaye_ s’il n’est pas à jour.

Une nouvelle option a été ajoutée dans la gestion de l'environnement sécurisé par LDAP pour définir une option de chiffrement des messages. Pour rappel, la gestion des paramètres de l'environnement sécurisé est accessible depuis l'ouverture de session, via les touches _Alt+F2_. Par défaut, les messages LDAP ne sont pas chiffrés (Option __). On peut désormais choisir de chiffrer les message avec gestion d'une connexion sécurisée SSL (Option _SSL_), ou avec gestion d'une connexion sécurisée SSL et authentification (Option _SSL+Auth_).

A partir de 2024, le montant du SMIC à utiliser pour le calcul des compléments maladie et allocations familiales doit être calculé à partir du montant de SMIC au 31/12/2023, dans la limite de 2 fois le SMIC courant. Le code calcul AF a été modifié afin que le montant de ce nouveau SMIC soit pris en compte dans un nouveau cumul MTSMIA.

Lorsque l'on veut séparer un bordereau en plusieurs morceaux (pour, par exemple, le passer sur deux mois de paye différents), dans certains cas, le calcul du reliquat ne se fait pas correctement. Par ailleurs, la saisie des valeurs lors de la génération des éléments variables (nombre de jours/montant et dates de début/fin) pouvait amener à des erreurs ou à un blocage.

Lorsqu'un champ de fusion est défini, dans une source de données du module bureautique,avec du code compilé, et que le résultat de ce code doit renvoyer une chaîne vide (=""), la valeur renvoyée était remplacée par "0,00".

Après la création d’une DPAE pour un salarié à partir de la liste des situations, la liste des DPAE du salarié s’affiche, permettant ainsi d’envoyer immédiatement la DPAE sans avoir à retourner dans la fenêtre de gestion des DPAE. Par ailleurs, ce correctif rétabli l’affichage correct du sexe de la personne lorsqu’on visualise une DPAE déjà créée.

Un nouveau menu Paramètres API-DSN a été ajouté dans le menu FICHIER - Autres paramètres afin d'accéder directement aux paramètres HTTP utilisés dans les différents échanges liés à la DSN, notamment pour la récupération des CRM.
Cette option de menu est contrôlée, dans la gestion des droits, par rapport aux droits sur la fenêtre DSNAPIPP.

Correction d’une erreur dans la fenêtre d’_Interface comptable_, qui pouvait se produire lors du lancement de l’interface et qui indiquait, à tort, que le fichier de description n’existait pas.

Correction d’une erreur dans la fenêtre d’_Interface comptable_, qui pouvait se produire lors du lancement de l’interface et qui indiquait, à tort, que le fichier de description n’existait pas.

La notion de “Rang de naissance” n'étant pas plus utilisé en DSN (uniquement en N4DS), le champ correspondant avait été enlevé de la fiche du salarié. Or le libellé devant la date de naissance y faisant encore référence.

La fenêtre de saisie des classifications permet de saisir des valeurs de coefficient avec une partie décimale, mais le calcul du bulletin ne tenait compte que de la partie entière de ces coefficients.

La fenêtre de saisie des classifications permet de saisir des valeurs de coefficient avec une partie décimale, mais le calcul du bulletin ne tenait compte que de la partie entière de ces coefficients.

La fenêtre de saisie des classifications permet de saisir des valeurs de coefficient avec une partie décimale, mais le calcul du bulletin ne tenait compte que de la partie entière de ces coefficients.

Lors de la suppression d'un élément variable via la liste des BPIJ, il peut arriver que l'application renvoi une erreur d’intégrité et rende la suppression impossible. Ceci se produit lorsqu'il y a plusieurs éléments variables issus de BPIJ dans le même bulletin. La correction permet de supprimer correctement le bon élément variable.

Lors de la définition des champs de fusion d’une source de données bureautique, il est désormais possible de définir une table de correspondance. NB : Les valeurs “avant” doivent tenir compte de la casse (minuscule/Majuscule).

Le Framework LD a été recompilé avec les paramètres de partage de contexte afin qu'il puisse être utilisé dans du code compilé dynamiquement.

Le format de fichier généré depuis la mise à jour 459 n'était pas accepté par le site de dépôt du fichier, malgré que le fichier soit conforme au cahier technique. L'anomalie ne concerne pas les données déclarées, mais uniquement la structure de l'entête du fichier. Le format a donc été modifié pour tenir compte de cette anomalie et ainsi être accepté en dépôt.

Si le Montant Net Social (MNS) est à 0, le bloc 58 (nouveau en P24), de type 03 n'était pas créé alors qu'il est obligatoire dans les blocs de versement dont le date de versement est postérieur ou égale au mois principal déclaré. Il est donc désormais créé à 0 dans ce cas.

La liste des identifiants qui est affiché lorsqu’on utilise un service de dématérialisation n’était pas filtrée correctement. Les identifiants DSN étaient également affichés.

Le libellé du pays de naissance est limité à 30 caractères dans le cahier technique DSN, or il y a certains pays de la table de nomenclature qui sont trop grands... ce qui provoque des erreurs en DSN. Ce libellé est donc désormais tronqué à 30 caractères.

Le correctif précédent (niveau 469) pouvait déclencher une erreur WLangage ayant pour explication : "Vous avez appelé la fonction ChangeStyle. L'élément 'D:\WINDEV 24\Personnel\Gabarits\240 LD Bleu\LD Bleu.WDY' n'a pas été trouvé".

L’envoi et le suivi des déclarations préalables à l’embauche devient plus souple avec la possibilité de choisir n’importe quelle situation du salarié comme base de création d’une DPAE. L’affichage inclus maintenant le numéro de la situation et le numéro du contrat de travail (s’il y en a un) pour bien identifier la situation concernée.

Le montant salarial des cotisations regroupées sur la ligne "Exonérations, Ecrêtements et allègements de cotisations" n'était pas imprimé sur le bulletin simplifié.

Un certain nombre de libellés et de retours ont été modifiés avec la nouvelle version de l’API. Il faut donc reporter ces modifications dans les différents fichiers et procédures concernés.

Lors de la création de la société, l'initialisation des fichiers ne copiait pas les dates de validité des paramètres DSN. Cela pouvait notamment engendrer la création des blocs 51-026 ou 51-027 sur ces nouvelles sociétés alors qu'ils ne sont plus attendus en 2024. Un outil sera exécuté à la première ouverture du dossier avec ce niveau pour vérifier (et corriger le cas échéant) le mois de fin de validité de ces 2 codes.

Lors de la création d’un répertoire, l’historique des valeurs des _Constantes générales_, des _Cotisations_ et des _Bordereaux_ du répertoire modèle est désormais récupéré.

Pour les dossiers « _Immobilier_ », il est désormais possible d'interfacer la comptabilisation liée à un seul établissement ou à un seul salarié. Pour cela, deux filtres _Établissement_ et _Salarié_ ont été ajoutés dans la fenêtre d'_Interface comptable_.

Lors de l'enregistrement des AED dans la GED des salariés (si demandé), si le flux reçu dans le CRM n'est pas connu dans le dossier de paye (cas par exemple d'un utilisateur DSN qui gère plusieurs dossiers qui ne sont pas dans le même répertoire), l'AED pouvait être enregistré à tort dans la GED d'un autre salarié du dossier.

La ligne de bulletin de la cotisation AT n'était pas créée si le montant de la cotisation est égal à 0. Comme pour la plupart des cotisations de type "Taux", cette cotisation doit être créée si la base est renseignée pour pouvoir être cumulée lors du calcul des bordereaux de cotisation. C'est donc désormais le cas.

Jusqu'à présent, la seule façon de conserver l’historique d’une ancienne affiliation de prévoyance, qui n’est plus à déclarer en DSN, était de saisir une radiation. Or, dans certains cas, il peut s’avérer nécessaire de changer de contrat de prévoyance sans pour autant radier le salarié (s'il s’agit d’un simple changement d’option par exemple). Il est donc désormais possible de mettre fin à l’affiliation d’un salarié sans radiation. Pour cela, un code “_FA-Fin d’affiliation (hors DSN)_” a été ajouté dans la liste des motifs, et permet de mettre fin à l’affiliation sans déclencher d’inscription de la date de fin en DSN. De plus, de la même manière, il est désormais également possible d'activer un contrat de prévoyance à une date donnée sans inscrire cette date en date d’affiliation. Pour cela, un code “_DA-Début d’affiliation (hors DSN)_” a été ajouté dans la liste des motifs, et servira comme date début de l’affiliation au sens LDPaye. Si ce motif est saisi, l'éventuelle date d’affiliation antérieure (motif _01_) sera ignorée. En DSN en revanche, on se servira de ce motif _01,_ si renseigné, pour renseigner la date de début du contrat. Dans la fenêtre d’affiliation, une case à cocher “_Début de contrat antérieur_” a été ajoutée, et, si elle est cochée, permet de saisir ou non la date de début initiale du contrat. Si la case est cochée, la date de d’affiliation devient obligatoire, et le motif _DA_ sera créé (au lieu de _01_). Si en plus une date de début de contrat antérieur est saisie, alors un motif _01_ sera ajouté à cette date. Ainsi, en cas de changement de code option, la première affiliation sera à terminer avec le code _FA_, et la nouvelle affiliation (dans l’autre contrat de prévoyance dans LDPaye) sera à démarrer en cochant la case (pour générer un motif _DA_) à la date du changement, et il faudra saisir en date initiale l'éventuelle date d’affiliation qu’il y avait dans l’autre contrat de prévoyance (uniquement s’il y en avait une).

Une colonne a été ajoutée dans le tableau de calcul des effectifs pour afficher la qualification du salarié.

Dans le cas où le salarié est présent tout le mois, le calcul de la prime d'ancienneté sur minimum pouvait générer une différence d'arrondi de 1 à 2 centimes par rapport au montant défini dans la classe d'ancienneté.

Les codes DSN de réserves 81-914 et 81-915 ont été modifiés afin de permettre de paramétrer les nouvelles réductions sapeurs-pompiers volontaires.

Lorsqu’un retour de DSN “Mandat à acquitter” est réceptionné, le contenu du compte rendu n’est pas exploitable. Ce correctif permet de visualiser les liens pour accéder au mandat à signer en ligne.

Suppression du message d’explication qui s’affichait lors de l’appui sur la touche _F1_ au survol des colonnes _Calculé_, _Présent_ et _Payable_ dans la fenêtre de calcul des bulletins. Désormais, l'appui sur la touche _F1_ ouvre l'aide en ligne sur la page correspondante.

Dans la fenêtre de sélection d’une constante générale, une colonne a été ajoutée pour informer que la constante générale a été déclinée pour au moins une société ou un établissement.

Il est désormais possible de saisir le caractère “-” dans la zone _N° du contrat de travail_ de la fenêtre de saisie d’une situation, onglet _Emploi_.

Le contrôle de cohérence sur les blocs 82 ne fonctionnait pas. Les blocs 82 n'étaient pas pris en compte.

Application du nouveau _Matricule_ dans tous les fichiers de l’analyse concernés lors de la _Renumérotation d’une fiche salarié_.

Une nouvelle fonction xAjouterDansCumulCotisation a été ajoutée dans la fenêtre de calcul des bulletins, afin de pouvoir intervenir sur les cumuls des cotisations en cours de calcul via les fonctions personnalisées.

Le nouveau module DPAE a été activé pour tous, en lieu et place de l’ancienne fenêtre de création de DPAE, qui permettait un pré-remplissage du site internet des DPAE (cette fenêtre reste toutefois accessible en cliquant sur le bouton “Déclaration DPAE” en maintenant la touche “Contrôle” depuis la fenêtre des situations du salarié).

Lors de la préparation des fichiers à envoyer sur la plateforme de dématérialisation, salariés et bulletins, le traitement commence désormais par supprimer les fichiers qui seront préparés, s’ils existent, en début de traitement. Cela évite que les anciens fichiers soient envoyés à tort en cas d’anomalie pendant la préparation des fichiers.

Le montant de la réduction sapeurs-pompiers volontaires sur les cotisations et contributions recouvrées par l’Agirc-Arrco (bloc 81-915) est désormais cumulé dans le calcul du bordereau de versement DSN à destination de l'AGIRC-ARRCO.

Correction d’un dysfonctionnement dans la fenêtre de consultation/modification des _Contrats de prévoyance d’un salarié_, accessible depuis l’option _Prévoyance_ du sous-menu des boutons _Afficher_ ou _Modifier_ dans la liste des salariés ou la liste des bulletins, entre autres. Il pouvait arriver qu’un évènement soit affiché à tort dans la table des _Évènements liés au contrat_, alors qu’il n’y avait aucune donnée dans la table des _Contrats._ Cet affichage erroné produisait une erreur à la fermeture de la fenêtre, et entraînait la fermeture de LDCompta.

Lors d’une déclaration préalable à l’embauche, le choix du centre de santé implique que le code URSSAF renseigné dans la fiche établissement corresponde à celui attendu par l’administration. Ce correctif va vérifier que le code URSSAF est bien celui attendu et propose de le modifier dans la fiche de l'établissement s’il est incorrect.

Lors de l’envoi d’une DPAE, l’adresse de l'établissement est renseignée quel que soit le champ d’adresse rempli dans la fiche de l'établissement. Ceci évite de voir la DPAE refusée par manque d’adresse. Attention, ceci ne fonctionne que si au moins un des champs d’adresse de la fiche a été rempli.

Correction d’un problème d’arrondi lors du contrôle de cohérence.

Mise en place progressive du terme _France Travail_ : Les premières modifications ont été effectuées, en modifiant le terme _Pôle Emploi_ par _Pôle Emploi/France Travail_ dans un premier temps, là ou il était possible de le faire sans modifier profondément l’interface.

Une erreur stoppant l’application peut survenir lors de l’envoi des DPAE. Cette erreur provient de l’absence de réponse du serveur de réception des DPAE. Ce correctif améliore la gestion de cette erreur et permet de savoir si toutes les DPAE à envoyer l’ont bien été.

Le type de contrat qui apparait dans la liste des DPAE peut ne pas être celui de la DPAE. Ceci se produit lorsque le code de contrat de travail pour des CDD ou des CDI n’est pas CDD ou CDI. Le correctif rétabli un affichage correct du type de contrat dans la liste des DPAE

Lors de la _Préparation de la liste de paiement des primes d'intéressement_, le fait de sélectionner les salariés individuellement entrainait une erreur dans l'édition, avec notamment l’impression du même destinataire sur toutes les lignes de l'édition.

L’interface comptable permet désormais d’exporter la rubrique _PEPERS.HEXA_, champ _Numéro de badge_ de la fiche _Salarié_.

Lors de l’interface comptable, il est désormais possible d’obtenir dynamiquement le mois de paye dans la zone _N° de pièce_ en saisissant les balises suivantes : * *_%M_* : Mois de paye, sur 2 caractères, * *_%A_* : Année du mois de paye, sur 2 caractères, * *_%AAA_* : Année du mois de paye, sur 4 caractères. Cela évite de saisir manuellement tous les mois le champ _N° de pièce_.

Dans la fenêtre de _Modification de données par lot_, accessible depuis le menu _OUTILS_, la taille des champs _Sélection des enregistrements_, _Traitement avant mise à jour_ et _Traitement après mise à jour_ a été augmentée, permettant ainsi de saisir des requêtes et traitements plus longs.

Dans la fenêtre d'édition des _États et bordereaux de cotisation_, accessible depuis le menu _TRAITEMENT MENSUEL_, il est désormais possible de grouper les données à imprimer, ou à exporter vers _Excel_, par _Salarié_.

Pour les gestionnaires de syndic immobilier, un nouvel outil vient compléter ceux dédiés aux déclarations annuelles : l’export pour les OPCO. Cette fenêtre génère le fichier excel nécessaire pour effectuer cette déclaration. Il suffit d’indiquer l’emplacement de sauvegarde du fichier excel, l’année de déclaration et la rubrique utilisée pour la cotisation formation pour générer le fichier. Vous pouvez aussi choisir d’exclure un ou plusieurs établissements dans le tableau.

L’outil d’export des données de paie n’affichait pas les bons libellés lors de la sélection des champs à exporter vers Excel. Ce correctif rétabli le bon fonctionnement de cet outil.

Un avertissement est affiché à l’ouverture du projet si le programme est installer sur un lecteur réseau. Cette configuration n'est pas conseillée et peut aboutir à des ralentissements lors de son utilisation.

Lors de l’export d’une DSN en Excel, seuls certains blocs 53 étaient exportés, ceux pour lesquels une unité a été prévue dans le programme d’export. Il manquait actuellement le bloc 53.01-40 correspondant au nombre de jours calendaires de la période d’emploi pour le calcul de plafond de la sécurité sociale. Désormais, toutes les unités actuelles ou à venir seront bien exportées.

L’authentification DSN permet l’utilisation de caractères spéciaux dans le mot de passe. Certains caractères ne sont pas correctement gérés dans LD Paye et provoquent une erreur d’authentification dès qu’on tente d’accéder à un des services de Net entreprise (envoi de DSN/ récupération de retours DSN, etc) dans LD Paye. Ce correctif permet la bonne prise en charge de ces caractères spéciaux.

L'outil de comparaison des DSN (à partir de la DSN sélectionnée, ou entre 2 exports DSN) ne gérait pas le cas des blocs 53 qu'il faut comparer par code ET par unité. Ces blocs étaient comparés jusqu'à présent uniquement sur le code, ce qui provoquait des incohérences.

Afin de prévoir la fin de l’application du bonus-malus de taux AC au 31 octobre 2024 tel que la loi le prévoit (pour l’instant), une constante générale masquée “*MACBM-Dernier mois taux A.C. BM” a été créée dans les plan de paye avec la valeur “202410”. Si cette constante existe et est renseignée avec un mois valide, les valeurs des constantes TXACBM ou TXACCP ne seront plus prises en compte au delà de ce mois dans le calcul du taux pour les cotisations ayant le code AC. Pour augmenter en réactivité (en cas de prolongation de la validité des textes par exemple), cette valeur sera mise à jour à partir d’un fichier en ligne géré par nos soins.

L'envoi de la DPAE se solde systématiquement par un retour en échec indiquant que la date de début de contrat n'est pas valide.

La rubrique “81.002-Identifiant Organisme de Protection Sociale” doit être renseignée pour les cotisations à destination des organismes de base (URSSAF, MSA), mais pas pour les cotisations à destination de l’AGIRC-ARRCO. Depuis 2024, en prévision de la collecte des cotisations de retraite par l’URSSAF et la MSA (finalement abandonnée), la plupart des cotisations de retraite sont marquées également à destination de l’URSSAF et de la MSA. De ce fait la rubrique 81.002 était renseignée. Désormais, cette rubrique n’est plus renseignée pour les cotisations à destination de l’AGIRC-ARRCO, des OC, ou de la DGFiP, même si elles sont également à destination de l’organisme de base du salarié.

Dans l'édition des _États et bordereaux de cotisation_, accessible depuis le menu _TRAITEMENT MENSUEL_, les cotisations patronales n’apparaissaient pas lorsque les données étaient groupées par _Salarié_.

L’authentification avancée à 2 facteurs (OAUth 2.0) est pris en charge pour l’envoi des mails sécurisés.

Cette mise à jour apporte un suivi de l’utilisation des scripts de modification du plan de paye. Pour chaque script, l’application indique dorénavant si le script a déjà été exécuté, la date/heure de l’exécution et l’utilisateur qui a lancé le script et le résultat obtenu (exécution OK ou en erreur).

Lors de la création des borderaux de paiement, les taux de cotisation agrégés sont mis à jour automatiquement par rapport aux taux indiqués par l’URSSAF pour la période de paye en cours. Une option permet de conserver une gestion manuelle de ces taux. Un message vous avertira si ces taux gérés manuellement ne correspondent plus à ceux indiqués par l’URSSAF.

Lors de l’impression d’un bulletin lié à une situation de sortie, des documents peuvent être ajoutés. La liste de ces documents est paramétrables selon la société et/ou l'établissement du bulletin de sortie.

Il est désormais possible de paramétrer une cotisation ayant le code calcul [AT], pour que son calcul tienne compte du code AT du salarié, quel qu’il soit. Pour cela, la case à cocher _Uniq. si Code AT_ a été ajoutée dans l’onglet _Calcul_ de la fiche de saisie d’une cotisation. Si cette case est cochée, alors le code AT doit être renseigné et le fonctionnement est inchangé. Sinon, si cette case n’est pas cochée, alors le code AT n’est pas saisissable et le calcul de la cotisation tiendra compte du code AT du salarié.

Mise à disposition de la norme DSN P25V01 (2025).

Lors de la récupération d’un retour DSN (au format NEORES, CRM 119 120 etc), si les données ne sont pas complètement téléchargées et que le code XML n’est pas valide, l’application s’arrête lorsqu’on veut afficher ce retour.

A partir de la norme P24V01, il est possible de créer et déclarer des DSN de signalement d’amorçage des données variables (SADV), permettant entre autres de remplacer le service TOPAZE qui prendra fin au 31/12/2024.

Dans la fenêtre d’_Export des données d’une déclaration DSN dans un tableur_ il est désormais possible d’exporter les _Données versements_ (blocs 20).

La fenêtre des paramètres de l'environnement sécurisé n'était accessible (Alt+F2 depuis l'ouverture de session) que par un administrateur de sécurité, après saisie et validation de son mot de passe. Dans le cas où la validation du mot de passe n'est pas possible (changement des paramètres LDAP), il n'était plus possible d'accéder à cette fenêtre de paramétrage. Un accès a donc été ajouté, via la touche Alt+Maj+F2, afin de permettre à l'éditeur de pouvoir donner l'accès à cette fenêtre via la saisie du mot de passe du jour.

Dans l'écran d’identification, lors de la bascule vers les dossiers de simulation via le bouton situé à droite du libellé _Choix de la société_, la suppression avant mise à jour des fichiers d’environnement est désormais contrôlée, évitant ainsi la fermeture inopinée du logiciel.

Dans le module de gestion avancé des arrêts, le décompte des arrêts n’est pas correct, si dans les 12 derniers mois, un arrêt n’a pas généré d'éléments de paye ( C’est le cas pour les mi temps thérapeutique dont les éléments ne sont pas générés par le module de gestion des arrêts). Dans ce cas, tous les arrêts précédents ce mi temps thérapeutique, même s’ils sont dans la période des 12 mois, ne seront pas pris en compte dans le cumul des jours d’arrêt.

L’URSSAF met à disposition un nouveau retour appelé “CRM de rappel” qui est distribué annuellement en accompagnement de la DSN mensuelle de février et qui rappelle toutes les erreurs rencontrées dans les déclarations de l’année précédente.

Mise en conformité de l’affichage de l'état d’impression du registre du personnel. Ajout du regroupement par établissement.

Ajout d’options pour la ré-indexation et la compression des fichiers de données.

Dans le cas d’un salarié absent tout le mois, le bloc 53-01, avec l’unité “40 - jours calendaires de la période d’emploi pris en compte dans le calcul du plafond de Sécurité Sociale”, n'était pas créé. Les organismes en déduisait une absence de déclaration et considérait que le salarié était présent tout le mois. Désormais ce bloc 53 est créé systématiquement (avec la valeur 0 en cas d’absence totale sur le mois).

Lorsque le produit n’est plus maintenu, l’utilisateur en est informé à l’ouverture de l’application.

L'outil de contrôle de cohérence des DSN permettait uniquement d'ajouter de nouveaux contrôles pour les nouvelles normes. Les contrôles existants devaient être supprimés s'ils n'étaient plus cohérent dans les normes suivantes. Désormais l'outil a été amélioré afin de pouvoir faire évoluer les contrôles existants selon la norme de la DSN.

Intégration de l’outil de _Vérification des identifiants automatiques_ dans la fenêtre des _Outils_, accessible depuis le menu _OUTILS_, option _Autre outils_, puis _Lancer un autre outil_.

Lorsque les compléments maladie ou allocation familiale cotisés dans les bulletins du salarié sur les mois précédent doivent être remboursés (si le cumul des brut redescend en dessous du plafond), alors les cotisations doivent être impactées sur le mois auquel le complément avait été retenu, et non en globalité sur le mois courant. A partir des bulletins de janvier 2025, les remboursements de compléments seront donc générés comme des régularisations de cotisation.

Historiquement, le plafond de la réduction générale ne permettait pas de réduire plus de cotisation que ce qui a été cotisé dans le mois. Ce plafond a ensuite été enlevé, il y a quelques années, car pour un salarié, cela peut se produire. De fait, cela peut provoquer dans certains cas des bordereaux négatifs (si 1 seul salarié dans l'établissement par exemple). Il est désormais possible de réactiver ce plafonnement sur la cotisation de réduction générale, afin de limiter le risque de montant cumulé de cotisation, négatif, en cours d’année. Il faut pour cela créer la constante générale RFPLFn (où n correspond au 2ème numéro du code calcul, par exemple RFPLF1 pour le code calcul 81, RFPLF2 pour le code calcul 82, …) et y inscrire une valeur différente de 0. Les montants des cotisations de réduction patronale seront alors plafonnés au montant du cumul RFPLAF pour l’URSSAF ou au montant du cumul RFPLFR pour la retraite, sauf en cas de départ du salarié (et au delà) ou sur le dernier mois de l’année (décembre), pour que le cumul annuel reste juste. NB : Le cumul RFPLAF existe dans la plupart des plans de paye, ce qui n’est pas le cas du cumul RFPLFR. Il convient donc de le créer et de le paramétrer pour recevoir les différentes cotisations retraite. Outre la constante générale RFPLFn, les 2 cumuls RFPLAF et RFPLFR doivent exister pour que le plafonnement s’applique.

Lors de l’affichage de la liste des DPAE et lors de l’envoi, le type de contrat indiqué peut ne pas correspondre à celui qui a été envoyé (CDI/CDD).

Depuis le correctif niveau précédent (539), dans le cas où des champs avaient des valeurs mémorisées (FAA) dans la fenêtre de création d'une DSN arrêt/reprise, la fenêtre pouvait provoquer une erreur avec le message "Erreur à la ligne 11 du traitement Procédure locale xExtraireDonneesSalarie. Vous avez appelé la fonction HLitRecherchePremier. La source de données n'est pas initialisée" dès son ouverture. Pour éviter cela, il fallait supprimer les valeurs de la base de registre sur cette fenêtre.

 En création de DSN arrêt de travail depuis la fenêtre de gestion des arrêts, un filtre a été appliqué sur la liste des arrêts pour afficher uniquement les arrêts du salarié sélectionné dans la fenêtre de gestion.

La récupération des CTP depuis le site de l'URSSAF ne fonctionnant pas toujours selon les postes (généralement, dû a des questions de cache internet), le fichier est également livré dans le répertoire Nomenclature de l'application. Afin d'être plus réactif, il est également mis en ligne sur le site LDSystème et ainsi, sa mise à jour est vérifiée à chaque ouverture.

En environnement HFSQL (serveur), la réindexation ne fonctionne pas et renvoi un message d’erreur.

A l’appui sur le “+”, lors de la création d’une DSN d’amorçage, seuls les salariés affichés étaient cochés. Pour que tous les salariés soient cochés, il fallait au préalable parcourir l’ensemble de la table (pour qu’elle soit entièrement chargée). Désormais la table est systématiquement entièrement chargée. De plus, certaine colonnes de la table ont été modifiées. Le n° de contrat et l’ancien n° de contrat (s’ils sont renseignés) ont été ajoutés. La colonne “début de contrat” a été renommée “début de situation” et la colonne “déjà créée” a été supprimée car pas alimentée.

Lors de l’affichage d’un retour de DSN d’amorçage, les comptes rendu métier 114 (SADV) comportent des zones de données non identifiées.

Depuis le niveau 520, il est possible de paramétrer des documents du module bureautique pour qu'ils puissent être édités en même temps que le bulletin de sortie des salariés. Mais l'initialisation de ce module bureautique à l'ouverture de la fenêtre d'impression provoquait dans certains cas, une erreur bloquante lors de la migration du module.
L'initialisation du module est désormais effectué que si l'impression des documents de sortie est demandée et donc que le module a été migré, car cela est nécessaire, si ce n'était pas déjà fait, pour paramétrer les documents de sortie.

Lors de la création des DSN événementielles (amorçage, arrêt/reprise ou fin de contrat), l'émetteur de la DSN (bloc 01), était renseigné avec l'établissement concerné par la première déclaration (bloc 05) inclue.
Désormais, comme pour une DSN mensuelle, le choix de l'émetteur est soit proposé sur la dernière étape de la création de la DSN (avec possibilité de sélectionné la société comme émetteur), soit obligatoirement la société pour les dossiers pour lesquels le module de création des établissements en tant que société a été activé (secteur immobilier).

Gestion des nouveaux blocs dans l’export DSN vers Excel.

En 2025, les valeurs paramétrées dans la cotisation agrégée 005 doivent être déclarée en 004. Les paramètres de la cotisation agrégée 005 sont donc cumulés lors du calcul du bordereau avec ceux de la cotisation 004. Mais si seul la cotisation agrégée 005 est paramétrée, le calcul n'était pas effectué.

Les paramètres DSN 81-131, 132, et 142 créés pour la norme P25V01 ne devraient pas se calculer sur des périodes de décembre 2024 ou antérieures (cas de régularisation). Une période de validité sera ajoutée automatiquement sur tous ces paramètres à la 1ère ouverture du dossier avec ce correctif.

Lors de la préparation du fichier de paiements +partiels+, si une sélection de salariés est effectuée via la case à cocher _Sélectionner les salariés individuellement_, alors celle-ci est bien prise en compte et seuls les salariés sélectionnés ressortent dans la liste.

Conformément à la nouvelle norme de nommage des options de sécurité pour le SMTP, les libellés des options ont évolués : - L’option _TLS_ devient _STARTTLS_, - L’option _SSL_ devient _SSL/TLS_. De plus, le n° de port SMTP sera désormais proposé par défaut lors de la sélection d’une option de sécurité : - Pour l’option _SSL/TLS_ : port _465_, - Pour l’option _STARTTLS_ : port _587_, - Si aucune option de sécurité n’est sélectionnée : port _25_.

Lors de l’envoi d’une DPAE,les identifiants URSSAF disponible pour toutes les sociétés sont accessibles quel que soit la société utilisée.

Sur certains postes, un message d’avertissement pouvait être affiché à l’ouverture du dossier indiquant que le fichier DSN-CTP.xml ne pouvait pas être mis à jour, car en lecture seule. Désormais ce message n’apparaîtra que si l’utilisateur n’a pas suffisamment de droit pour modifier l’attribut lecture seule du fichier avant d'être mis à jour.

Les rubriques étant marquées en “Prime avec période de rattachement” étaient déduites du bloc 51-001 de la période courante, et réaffecté avec la période saisie sur la rubrique. Désormais ces rubriques sont ignorées de cette requalification du bloc 51-001. Seules les autres rubriques de rappels de salaire restent concernées.

Ajout d’une nouvelle méthode d’authentification utilisateur en mode silencieux.

Lors de l’affichage d’un retour au format PDF par la liste des retours, le bouton “ Marquer l’anomalie comme traitée” n’apparait pas et ce même si le retour est en erreur.

Création d’un nouveau module qui permet de gérer les demandes et enregistrements des autorisations de sociétés gérées en Web-service.

Jusqu'à présent, seules les régularisations sur les cotisations étaient prises en compte lors du calcul de la DSN. Désormais, si le paramètre DSN pointe sur une ligne de bulletin d'une rubrique qui est saisi avec une régularisation (@R, @A, ou @T), alors la valeur sera affectée au mois concerné par la régularisation.

Le taux barème 2025 du prélèvement à la source (PAS) a été diffusé, mais ne doit pas être appliqué avant le 1er mai 2025. La date d'application du taux barème a donc été affichée dans la fenêtre d'historique des taux PAS (onglet Barème non personnalisé) et pris en compte lors du calcul du taux barème.

Dans le fichier DSN final, envoyé à net-entreprises, les rubriques qui ne sont pas renseignées ne sont inscrites dans le fichier que si la rubrique est obligatoire pour cette nature de DSN. Ce contrôle ne fonctionnait pas pour les DSN d'amorçage, les rubriques obligatoires n'étaient pas générées dans le fichier final si non renseignées.

Les rubriques de régularisations (saisis avec un @ dans le libellé) n'étaient pris en compte pour le calcul des réductions salariales HS que si la régularisation était sur l'année courante. Le calcul était toujours fait sur le mois courant. Les régularisations sur les années antérieures étaient ignorées. Désormais, le calcul tient compte du mois de régularisation, y compris sur les années antérieures.

La rubrique 81.004-Montant de cotisation était manquante sur les blocs 81 dans la DSN envoyée si le montant est égal à 0. Or cette rubrique doit être présente pour les types 059 (déjà le cas), 060, 061, 105, 131, et 132. Désormais, la rubrique est toujours envoyée pour ces types, même si 0.

Le fichier d’export des salariés, généré lors de l’envoi des bulletins sur la plateforme de dématérialisation RH, est désormais paramétrable. Un nouveau champ _FICHIER DE DESCRIPTION A UTILISER POUR L'EXPORT DES SALARIES_ a été ajouté dans la fenêtre d’_Envoi des bulletins sur la plateforme de dématérialisation RH_. Si ce champ contient le chemin complet d’un fichier de description simplifié (fichier d’extension _.FDF_), alors le fichier d’export des salariés sera généré en fonction du paramétrage défini dans ce fichier. Si ce champ n’est pas renseigné, alors le fonctionnement sera inchangé, et les rubriques exportées seront les mêmes qu’auparavant.

Depuis 2011, le plafond de réduction générale n'était normalement jamais dépassé du fait de son calcul. Suite à l'ajout des montants de PPV dans le calcul de la réduction générale, il peut y avoir des cas où le montant de réduction générale dépasse le montant maximal de réduction. Un plafonnement a donc été ajouté dans les cotisations de réductions générale. Ce plafonnement s'applique automatiquement avec recalcule depuis le début de l'exercice, lors du calcul du 1er bulletin du salarié avec cette correction, puis chaque mois pour la valeur du mois. Le montant du plafond calculé s'applique sur le montant total de charge patronale de la cotisation (et non sur la base comme pour les autres cotisations).

Lors d’une sortie d’un salarié, l’impression des bulletins permet maintenant d’imprimer l’attestation France Travail en plus des documents de sortie paramétrés (lorsque cette dernière a été réceptionnée via les retours de DSN).

Les fonctions utilisées pour les calculs avancés des arrêts, lorsque la fonction personnalisée n'est pas créée, ont été modifiées.

Mise à disposition de CMServer version 6.4.0.

Si un enregistrement vide est présent dans le fichier CALILI, outre qu'il faut le supprimer, celui-ci était lu et affiché après chaque ligne du bulletin n'ayant pas généré (ou n'étant pas issu) d'élément variable.

Le contrôle d'inexistence des variables définies dans les scriptss de modification du plan de paye n'était pas effectué correctement. Le script était tout de même exécuté dans ce cas et provoquait une erreur (suite au doublon ainsi généré) lors de la création de l'élément en question.

La lecture des fichiers en ligne (dont notamment les scripts de modification du plan de paye) n'étaient pas lus correctement depuis le correctif précédent (niveau 571)

Un nouveau Widget présent sur la fenêtre principale permet d'être informé de l’arrivée de nouveau compte rendu métier en provenance des DSN.

Il est désormais possible de générer un fichier par établissement, service ou salarié depuis l’interface comptable. Pour cela, le nom du fichier à générer doit comporter une des trois balises suivantes : * *_%E_* pour générer un fichier par établissement, * *_%V_* pour générer un fichier par service, * *_%M_* pour générer un fichier par salarié. Ces balises seront automatiquement remplacées respectivement par le code établissement, le code service et le matricule du salarié. Si aucune de ces balises n'est renseignée, un seul fichier sera généré. Il est également possible d’utiliser la balise *_%S_*, qui sera automatiquement remplacée par le code société. A noter : * La génération de plusieurs fichiers (par établissement, service ou salarié) aura pour conséquence de ne pas annuler les provisions éventuellement calculées pour le mois précédent. Il faudra dans ce cas les annuler manuellement en comptabilité. * L’utilisation d’une fenêtre de post-traitement est incompatible avec la génération de plusieurs fichiers (par établissement, service ou salarié).

Le plafonnement de la réduction générale inclus dans la correction 566 ne tenait pas compte du mois de début éventuellement saisi dans la constante salarié RFMDEB. De plus, il est désormais possible de définir, de la même manière, une constante générale RFMDEB qui se substituera à la constante salarié si elle est plus récente (mais toujours antérieure au mois du bulletin).

Mise à jour du composant LDFramework.

Dans la fenêtre de _Calculs avancés de paye_, accessible depuis le bouton _Plus d’options_ dans la fenêtre de _Calcul des bulletins_, l’ouverture de la fiche de la situation depuis le le bouton _Afficher_ n’ouvrait pas toujours la situation sélectionnée dans la table _Situation(s) connue(s) pour ce mois_.

Dans la fenêtre d'_Édition des bulletins_, l’impression directe en PDF sans passer par l’aperçu permet désormais d'éditer un document PDF par établissement, service, code statistique 1, code statistique 2 ou code statistique 3, selon le critère de tri choisi (champ _Triés par_). Pour cela, il suffit de placer la balise *_%T_* dans le _Nom du fichier d’export_ dans la fenêtre de paramétrage des fichiers PDF, accessible depuis le clic droit sur le bouton _PDF_ de la fenêtre d'_Édition des bulletins_. Le regroupement des PDF sera fait en fonction du critère de tri choisi (champ _Triés par_), et la balise _%T_ qui se trouve dans le nom du fichier d’export sera remplacée par le code du critère de tri choisi (code établissement, code établissement+code service, code statistique 1, code statistique 2 ou code statistique 3). Par exemple : si la balise _%T_ est présente dans le _Nom du fichier d’export_, et que le champ _Trié par_ est positionné sur _Établissement_, alors le logiciel génèrera un document PDF par établissement, et remplacera la balise _%T_ dans le nom du fichier d’export par le code de l'établissement, De plus, il est désormais possible de renseigner un sous-répertoire avant le _Nom du fichier d’export_, afin de placer les différents fichiers générés dans des répertoires spécifiques. Par exemple : si, dans la fenêtre de paramétrage des fichiers PDF, le répertoire défini pour l'_impression directe en PDF sans passer par l'aperçu avant impression_ est le répertoire +_C:\PAYE\BULLETINS_+, et que le _Nom du fichier d’export_ est +_ÉTABLISSEMENTS_++*_\_*++_%T_++*_\_*++_Bulletins de paye %1 %2 %3 %T_+, alors : - les bulletins de l'établissement de code _ET1_ seront générés dans le répertoire +_C:\PAYE\BULLETINS\ÉTABLISSEMENTS_++*_\_*++_ET1_++*_\_*+*,* et seront nommés +_Bulletins de paye simplifiés LDZ 202504 ET1.pdf_+, - les bulletins de l'établissement de code _ET2_ seront générés dans le répertoire +_C:\PAYE\BULLETINS\ÉTABLISSEMENTS_++*_\_*++_ET2_++*_\_*+*,* et seront nommés +_Bulletins de paye simplifiés LDZ 202504 ET2.pdf_+, - etc.

Le calcul du plafond de la RGCP initié avec le correctif niveau 566 ne prenait pas en compte la majoration du coefficient de réduction générale pour les entreprises qui ont une caisse de CP. De plus, la base du calcul des plafonds des bulletins antérieurs (pour reprise du calcul en milieu d'exercice) était erronée pour les bulletins dont la base de cotisation ne correspond pas au brut abattu (à forciori donc sur les bulletins sans réduction générale appliquée).