Première mise à disposition Version 9.50

Le programme de conversion des zones avec double codification (DSN/N4DS) pouvait convertir à tort des zones n'ayant pas de double codification. C'était le cas lors de la création de la DSN avec une norme P03V01 (précédente norme, encore utilisée jusqu'à fin 2017), l'unité de mesure de la quotité de travail n'était donc pas inscrite dans la rubrique 40.11.

Lors du calcul du 1er bulletin de l'année civile (généralement en Janvier), si le règlement a lieu dans ce même mois, le programme provoquait une clôture annuelle fiscale, même si le bulletin de Décembre était payé en Janvier (la clôture fiscale avait donc déjà eu lieu lors du calcul de Décembre).

Afin de gérer le cas des cotisations qui suivent les règles de décalage de la DGFiP (cas du CICE par exemple), une case à cocher a été ajoutée dans les paramètres généraux, intitulé "Dernier mois des cotisations fiscales décalé (Décembre payé en Janvier)", et le code "98 - Dernier mois des cotisations fiscales" a été ajouté dans le mois de RAZ des cotisations. A la première ouverture avec ce niveau, les cotisations ayant le code calcul "CI" seront automatiquement passées du mois de RAZ "99" à "98", et la case à cocher des paramètres généraux est cochée si le premier mois de l'exercice, au moment de cette ouverture, est positionné sur le mois de Décembre (cas des sociétés en décalage de paye en 2017). Pour plus de détail sur l'utilisation de ces zones, se reporter sur la documentation des nouveautés de la version 9.50 (release 1.03 minimum).

Suite aux informations communiquées par le GIP-MDS, LDPaye est capable de prévenir l'utilisateur si une DADSU est nécessaire pour un ou plusieurs établissements du dossier courant.
Pour cela, une alerte est affichée à l'ouverture du menu principal et indique les établissements concernés.

Dans le cas d'un environnement sécurisé, en cas de verrouillage automatique activé, il était impossible de déverrouiller l'application avec le mot de passe de l'utilisateur courant. Il fallait alors obligatoirement saisir le mot de passe d'un administrateur de sécurité. Pour rappel, si aucun utilisateur n'est marqué administrateur, c'est à dire que tous les utilisateurs ont tous les droits, ils ne sont pas administrateur pour autant. Cette possibilité de déverrouillage par un administrateur de sécurité n'est donc pas utilisable.
En environnement non sécurisé, le mot de passe de l'utilisateur courant (saisi sur la première zone) permettait de déverrouiller, mais en tenant compte de la casse (minuscule/majuscule).

La restauration d'un répertoire, lorsque la session a été ouverte dans un autre répertoire, ne repositionnait pas correctement les fichiers ouverts sur le répertoire en cours. Ils restaient positionnés sur le répertoire restauré.

La migration d'un dossier dans une version antérieure à la version 8.00 provoquait des erreurs ; l'ouverture du dossier était impossible.

Une gestion centralisée des droits d'accès sociétés et domaines a été ajouté afin de simplifier la mise en œuvre et la maintenance de ces droits. L'ajout de cette fenêtre n'a aucun effet sur l'application des droits en eux-mêmes, seulement sur sa gestion (création, modification, suppression des droits). Les précédentes fenêtres de gestion des droits restent toujours utilisables dans les mêmes conditions. Le détail des fonctionnalités apportées par cette nouvelle fenêtre est inscrit dans la documentation "Nouveautés version 9.50" dans lequel un chapitre a été ajouté (version de la documentation 1.05)

Amélioration :
- La plage de récupération des pointages ne se détermine plus au niveau de la demi-journée mais au niveau de la journée.

Corrections :
- En saisie des fiches, lors de la présence de certaines anomalies, des plantages récurrents pouvaient se produire.
- Un plantage pouvait se produire dès lors qu'une fonction de pointage tolérée était utilisée.
- Lors de l'édition Pointages et heures réelles, des pointages initialisés à la date et heure courante étaient affichés à tort là où il n'y en avait pas. Désormais, ces pointages ne s'affichent plus.
- Plantage lors de l'édition des fiches de présence

Dans le cas d'un environnement sécurisé, à partir du second basculement en mode simulation, le programme provoquait une erreur lors de la mise à jour de l'environnement de simulation.
En cas de basculement en environnement sécurisé sans ce correctif, les dossiers existants dans les dossiers de simulations, lors de la sécurisation de l'environnement, ne pourront plus être ouverts directement, ils devront être réinitialisés depuis l'environnement réel.

On peut désormais modifier le texte d'une fonction personnalisée dans un éditeur de texte en faisant un clic droit dans la zone de saisie.

Lorsque le fichier est modifié et sauvegardé via l'éditeur de texte, LDPaye propose de mettre à jour la zone de saisie.

Ce correctif permet de gérer les nouvelles règles de calcul du plafond de la Sécurité sociale applicables à partir de janvier 2018. Ces règles sont décrites en détail dans la documentation des nouveautés LDPaye V9.50 au chapitre Proratisation du plafond SS - Nouvelles règles en 2018.

L'option de menu "Fichier - Modifier mon mot de passe" provoquait une erreur du type "Impossible d'ouvrir le fichier (...)\PAYENVS.FIC". Cette erreur n'apparaissait que sur un environnement non sécurisé.
Pour changer son mot de passe, l'utilisateur pouvait néanmoins toujours accéder à sa fiche utilisateur depuis la gestion des utilisateurs (selon ses droits).

Dans le module bureautique, un souci dans la lecture du fichier .SRB qui sert de code source aux champs de fusion de la source de données, pouvait provoquer une erreur lors de la fusion des documents. De plus, si une modification de la source de donnée a eu lieu en V9.50 avec un niveau inférieur à celui-ci (même sur un autre champ), le programme provoquait un problème dans le fichier qui nécessitera une intervention manuelle. Dans ce cas, veuillez vous rapprocher de votre prestataire habituel pour faire corriger le fichier.
Les sources de données concernées sont celles ayant au moins 2 champs calculés, soit compilés dynamiquement, soit ayant au moins 2 lignes dans le tableau des constantes, cumuls, lignes bulletins, ... à sommer.

L'édition des bordereaux de versements DSN sur les organismes complémentaires n'affichait pas correctement le détail des contrats et des périodes d'affectations.

Une erreur était provoquée lors du lancement de l'application en passant le code société à ouvrir, ainsi que l'identifiant utilisateur et son mot de passe, en ligne de commande.

A la migration du 1er document en V9.50, outre les documents migrés, le fichier "document.pay" (qui contient la liste des fichiers modèles) ainsi que l'ensemble des fichiers sources de données (.srb) sont automatiquement copiés dans le répertoire "Sauvegarde V9.00".

Il est possible de sélectionner les salariés, contrats, et/ou bulletins à inclure lors de la création d'une DSN Mensuelle ou lors de la création avancée d'un bordereau de versement DSN. Cette nouvelle fonctionnalité est décrite dans la documentation des Nouveautés de la version 9.50 au chapitre Sélection des salariés à inclure dans une DSN.

Le programme de création d'une DNAC-AE à la norme V01X12 provoquait une erreur dans le cas où la date d'ancienneté du salarié parti n'était pas renseignée.

Suite à la version 9.50 et l'abandon du publipostage sous Word au profit d'un publipostage interne au progiciel, certaines présentations ou fonctionnalités de Word ne sont plus disponibles. Afin de pouvoir continuer à utiliser le publipostage de Word (dans le cas où il n'est pas possible de reprendre le modèle pour le rendre compatible avec ce nouveau type de publipostage), il est possible de générer un fichier au format « texte avec tabulation » contenant les données décrites dans une des sources de données définies dans ce module Bureautique (celles utilisées pour le publipostage des documents Bureautique), en tenant compte de la sélection des salariés effectuée. Ce fichier texte peut ensuite être utilisé dans un publipostage réalisé directement depuis Word.
Pour accéder à cette nouvelle fonctionnalité au sein de la fenêtre Bureautique, cliquez sur l'onglet (vertical) Source de données, disponible en bas à gauche de la fenêtre. Sélectionnez la description de la source de données dans le cadre 2, sélectionnez le ou les salariés concernés en partie haute comme on le fait habituellement, puis cliquez sur le bouton Exporter. Par défaut, le fichier contenant les données est créé dans le répertoire Bureautique, là où se trouvent les modèles et les fichiers de description des sources de données. Il porte le même nom que la source de donnée choisie, avec l'extension .txt. En tenant la touche Majuscule enfoncée lors de l'export, le nom et l'emplacement du fichier généré peuvent cependant être choisis par l'utilisateur.
Après export des données dans ce fichier au format « texte avec tabulations », il suffit donc d'ouvrir un document avec Word, puis dans l'option de sélection d'une liste de destinataires existant, sélectionner le fichier ainsi généré.
Note : les modèles originaux, avant migration en V9.50, ont automatiquement été enregistrés dans le sous-répertoire Sauvegarde V9.00 du répertoire Bureautique ; ils peuvent donc y être récupérés pour être repris sous Word. 
Attention : dans quelques cas, il peut y avoir besoin de modifier certains champs de publipostage, notamment en cas d'utilisation de caractères accentués ou de caractères spéciaux dans les noms des champs de fusion.

Une correction a été apportée afin de permettre la sécurisation des répertoires qui n'auraient pas été correctement « marqués » lors de la mise en place initiale de l'environnement sécurisé, suite à une erreur éventuelle (problème de connexion, de droits d'accès, ...).

Corrections :
- Il n'était pas possible de valider une fiche ayant un cycle à cheval sur deux périodes et présentant des anomalies sur le mois suivant.
- Il n'était pas possible de sauvegarder une nouvelle fiche type.

Amélioration :
- Un nouveau mode de calcul des heures a été ajouté au mécanisme des heures supplémentaires.

Plusieurs choses ont été corrigées dans la gestion des commentaires présents dans la fiche Salarié :

• Quand on ouvrait une fiche salarié, si on avait choisi, dans la fenêtre des Paramètres généraux, onglet Préférences l'option d'affichage du commentaire Toujours, ou l'option Si un commentaire existe et qu'un commentaire était présent dans la fiche salarié appelée en modification, il y avait un problème de "focus" : la fenêtre de saisie du commentaire s'ouvrait effectivement, mais on ne pouvait rien saisir, ni dans cette fenêtre de commentaire, ni dans la fiche du salarié, et ce tant que cette fenêtre de commentaire n'était pas refermée en cliquant sur le bouton Commentaire de la fiche salarié.
• Dans la fenêtre des Paramètres généraux, onglet Préférences, la nouvelle option permettant de choisir si la fenêtre de commentaire salarié doit s'afficher ou pas en saisie des éléments variables s'enregistrait mal (ou plutôt, l'option s'enregistrait bien, mais elle n'était pas relue chaque fois qu'on rappelait cette fenêtre, ce qui avait pour effet de remettre l'option à la valeur Jamais).
• Enfin, en saisie des éléments variables, lorsque l'option d'affichage du commentaire salarié était à la valeur Jamais, mais qu'on demandait explicitement à ouvrir cette fenêtre de commentaire en cliquant sur le nouveau bouton Commentaire, cette fenêtre restait affichée lorsqu'on changeait de salarié, sans rafraichissement de la valeur : on voyait toujours le commentaire du salarié courant au moment de l'ouverture de la fenêtre. Désormais, avec cette option Jamais, la fenêtre est refermée dès qu'on change de salarié.

Le masque de saisie appliqué sur le montant des honoraires, dans la fenêtre de saisie, empêchait de saisir un montant supérieur ou égale à 1 000 000 d'euros.

La date de règlement définie dans les paramètres de calcul des bulletins d'intéressement n'était pas prise en compte pour la détermination de l'automatisme de la clôture fiscale.

Dans le cas de l'import de bénéficiaires sans SIRET (étrangers), si un bénéficiaire existe déjà sans SIRET (dans les bénéficiaires existants ou dans les bénéficiaires précédents du fichier importé), les honoraires sont cumulés dans ce bénéficiaire trouvé au lieu de créer le bénéficiaire attendu.

Les paramètres DSN 81.040 à 81.043, et 81.048, ne sont plus nécessaires sur les cotisations à destination de l'URSSAF (CT DSN 2018). Un outil est donc lancé à la première ouverture du dossier avec ce correctif pour supprimer les éventuels paramètres DSN référençant des cotisations liées à une famille de cotisation qui n'est pas de type "MSA" (seul type d'organisme destinataire de ces valeurs à compter de 2018).
Un message interdisant le paramètre 81.044 apparaissait également à tort sur les cotisations liées à une famille de cotisation de type "URSSAF"

Une modification a été apportée dans la procédure d'initialisation de l'environnement afin de pallier au souci de sécurisation des répertoires de données qui ne s'applique pas correctement. Dans ce cas, les sociétés concernées ne pouvaient pas être ouvertes, et un message indiquait alors : Le code de sécurité de la société est différent de celui de l'environnement.

L'abandon du décalage de paye à partir de 2018 n'était pas appliqué correctement sur les éditions des DSN. Une période de rattachement de janvier 2018 était affichée sur l'édition de la DSN de décembre 2017, si le premier mois de l'exercice est en décembre.
Ce cas ne se provoquait qu'en décembre 2017, car à partir de janvier 2018, le 1er mois de l'exercice sera alors obligatoirement en janvier.

En création d'une DSN sur un bulletin calculé au-delà de la fin de l'exercice courant (cas d'une DSN de fin de contrat lors d'un départ en Janvier, alors que le mois courant est encore décembre), si une valeur est paramétrée à partir d'un cumul cotisation, la déduction de la valeur du cumul cotisation du mois précédent (pour obtenir uniquement la valeur mensuelle) était appliquée à tort (car ce bulletin est sur le 1er mois de l'exercice suivant, le cumul cotisation a donc été remis à zéro).
La correction est générique et peut éventuellement corriger également des traitements, non identifiés à ce jour, sur les cotisations dans ce même cas (traitement appliqué sur le bulletin sur le 1er mois de l'exercice suivant, avant clôture du dernier mois de l'exercice courant)

3 petites améliorations ont été apportées dans la procédure d'export d'une DSN en format Excel, pour ce qui est de l'export de type 1 (Données numériques, blocs 50 et ses blocs fils) :

1. Une colonne Mois est désormais insérée entre les colonnes Nom prénom et N° bulletin. Ainsi, quand on réouvre un fichier Excel après coup, on sait de quel mois il s'agit.
2. On peut désormais exporter toutes les colonnes choisies, y compris celles non renseignées dans la DSN traitée. Cela permet après coups "d'additionner" plusieurs feuilles Excel issues de plusieurs exports, qui ont ainsi toutes exactement le même colonage.
3. On peut enregistrer un choix de colonnes, de façon à reproduire une sélection de colonnes sur plusieurs exports DSN successifs.
   Complément technique : chaque sélection est enregistrée sous forme d'un fichier portant le nom indiqué au moment de la mémorisation de la sélection et l'extension .dsnsl, dans le répertoire des sous-répertoires.

Le calcul du tout premier bulletin du salarié ignorait les valeurs des cumuls éventuellement saisis, même si l'option Reprise des cumuls de la période précédente était cochée dans la situation du salarié (nouveau problème lié à une autre correction faite en version 9.50 sur des questions de reprises de cumuls cotisations).

Le contrôle de l'existence d'une assiette de taxe sur les salaires, lors de la validation de la fiche établissement, ou en création de la DSN, provoquait à tort un avertissement si aucune assiette de taxe sur les salaires n'existait pour l'établissement, mais qu'une cotisation établissement existait pour cet établissement, ou à l'inverse ne provoquait pas d'avertissement si une cotisation établissement (autre que de taxe sur les salaires) existait sur un établissement assujetti à la taxe sur les salaires.

Plusieurs corrections ont été apportées dans la création de la DSN mensuelle manquante du mois précédent (à zéro) lors de la création des DSN événementielle :

• Dans le cas de plusieurs DSN événementielles successives (pas dans le même envoi), quelle que soit la réponse, la DSN mensuelle à zéro existant dans une précédente DSN événementielle était reprise.
• Toujours dans le cas de plusieurs DSN événementielles successives, les contrats de prévoyances étaient recréés systématiquement (ce qui provoquait des doublons sur les blocs 15).
• Dans le cas de plusieurs arrêts ou fin de contrats envoyés dans le même envoi, le programme créait autant de DSN mensuelles qu'il y avait de DSN événementielles.
• La réponse à la question de création de cette DSN mensuelle manquante n'est désormais posée qu'une seule fois par création de DSN événementielle, et est valable pour l'ensemble des événements ajoutés à l'envoi.

Dans le calcul de l'assiette de l'assujettissement fiscal à la formation professionnelle des CDD qui est déclarée en DSN (bloc 44 code 013), on exclut désormais automatiquement certains types de CDD. On se base pour cela sur le Code dispositif politique enregistré dans le type de contrat. On exclut automatiquement les codes suivants :
 41-CUI - Contrat d'Accompagnement dans l'Emploi
 42-CUI - Contrat d'accès à l'emploi - DOM
 61-Contrat de Professionnalisation
 64-Contrat d'apprentissage entreprises artisanales ou de moins de 11 salariés (loi du 3 janvier 1979)
 65-Contrat d'apprentissage entreprises non inscrites au répertoire des métiers d'au moins 11 salariés (loi de 1987)
 71-Contrat à durée déterminée d'insertion
Au passage, si on déclare l'établissement comme étant soumis à cet assujettissement (code 013), mais que le calcul aboutit à une assiette nulle (aucun contrat de type CDD soumis à cette taxe dans l'année), le code 013 est automatiquement remplacé par le code 014-Nous soumis sur le bloc 44 correspondant à cet assujettissement.

Remarque : il faut aussi exclure d'autres types de CDD de cette assiette : ceux transformés ensuite en CDI ou ceux conclus avec un jeune dans son cursus scolaire, ou encore les CDD conclus avec un saisonnier pour formation. Mais à ce jour, le programme n'est pas en mesure de faire ces distinctions.     

La saisie d'un code BIC dans les fiches salariés, en complément de l'IBAN, est désormais facultative. Un IBAN est suffisant pour pouvoir faire le virement SEPA.
Dans la pratique, lors de la préparation d'un fichier de virements à la norme SEPA, s'il existe au sein de l'ordre de virement au moins un destinataire pour lequel le code BIC est manquant, le fichier SEPA est préparé sans aucun code BIC pour les destinataires (pas de balises CdtrAgt, FinInstnId et BIC dans le fichier XML) .
Il faut savoir que le code BIC du destinataire (celui contenu dans la balise CdtrAgt) est facultatif depuis 2014. Ce fichier SEPA sans codes BIC pour les destinataires sera donc accepté pour toutes les banques.
Attention : le code BIC de la banque émettrice du virement (balises DbtrAgt, FinInstnId et BIC) reste obligatoire.
Complément d'information : si on a demandé à « enrichir » le fichier de virements SEPA (quasi spécifique client, déclenché via le paramètre programme SEPAPLUS, voir correction V9 N239), le BIC reste obligatoire si on a choisi l'option de remplacement, pour les destinataires du virement, de la balise <BIC> par une balise <CmbndId> composée elle-même des balises <BIC> et <PstlAdr><Ctry>. Dans ce cas, s'il manque le code BIC pour un destinataire, le fichier n'est pas créé et cette erreur est signalée.

Lors de la génération du fichier des virements SEPA à la norme TRAX, la balise BEI s'est retrouvée à tort en minuscule.

Désormais, elle devrait rester en majuscule.

Suite au niveau 44, le contrôle de présence des assujettissements à la taxe sur les salaires, pour les établissements marqués comme assujettis à la taxe sur les salaires (dans la fiche établissement) continuait à être déclenché si les assujettissements existants pour l'établissement étaient sur le même mois que le mois des assujettissements à extraire dans la fenêtre de création de la DSN, et qu'il n'en existe pas sur des mois postérieurs.

Le prorata du plafond en fonction des jours d'absence tient compte désormais des jours d'absence saisis même si ceux-ci sont en dehors de la période payée. Ainsi, si on saisit en janvier une absence effective sur décembre, le plafond de la paye de janvier sera proratisé en tenant compte de ces jours d'absence, conformément à ce qui a été fixé par la directive DSS/5B/5D/2017/351 du 19/12/2017, question 6. Jusqu'alors, seuls les jours d'absence compris dans la période payée par le bulletin entrainaient une réduction du plafond.
3 limitations toutefois :
 - on ne tient pas compte des éventuelles périodes d'absence qui seraient en dehors de la période couverte par Date entrée-Date sortie du salarié (il s'agit dans ce cas d'une erreur de saisie très probablement)
 - le décompte de ces absences ne peut pas déboucher sur un plafond négatif. En clair, le nombre de jours de présence pour plafond, égal au nombre de jours de la période payée (Date début, Date fin du bulletin) diminué du nombre de jours d'absence, ne peut être inférieur à zéro.
 - si on souhaite forcer un plafond négatif, il faut forcer un nombre de jours par la 1ère règle de proratisation du plafond, en saisissant une valeur négative sur un élément variable avec la rubrique 5950 ayant un code calcul 25.

Une nouvelle fonctionnalité, d'import de données en DSN, a été ajoutée. Pour plus d'informations, se reporter à la documentation des nouveautés LDPaye V9.50 au chapitre Import de données dans une DSN.

En validation de la création d'un salarié par duplication d'un salarié existant, si le paramètre de proposition de création des nouveaux salariés dans LDPlanning est activé, le programme ouvre la fenêtre de création du salarié dans le planning. En sortie de cette dernière, par réponse "Non" à la question de création du salarié, ou en cliquant sur le bouton "Salarié" dans la fenêtre, le programme réaffichait à tort la fenêtre de création d'un salarié par duplication du salarié courant.

Les 4 motifs de pénibilité supprimés à partir de 2018 ne sont pas supprimé du CT DSN 2018, afin de pouvoir saisir d'éventuelles régularisations sur des périodes antérieurs, c'est pourquoi la gestion des pénibilités dans LDPaye n'a pas été modifiée. Toutefois, les blocs 34 - Pénibilité ne seront pas déclarés en création de la DSN pour ces 4 motifs, à partir de l'année de rattachement 2018.
Egalement, les blocs 34 - Pénibilité étaient déclenchés, jusqu'en décembre 2017, par l'ajout de blocs 78, code 37. A compter des déclarations 2018, ces blocs seront systématiquement déclenchés lors de la DSN du mois principal de décembre (du fait de la suppression du décalage social, toutes les entreprises devront déclarer la pénibilité en décembre), ou déclenchés par la déclaration d'un bloc 62 - Fin du contrat.

Les contrôles effectués en validation de la fiche salarié et lors du calcul de paye, pour les salariés entrés après le 01/07/2013, pour l'exonération de charge patronale d'assurance chômage, ont été limités aux salariés entrés au plus tard le 30/09/2017. Les salariés entrés après cette date ne doivent pas bénéficier de cette exonération. La liste des salariés embauchés en CDI qui s'imprimait en clôture mensuelle a également été supprimée à compter de la clôture de janvier 2018.

Le Journal de Maintenance de la Norme DSN apporte une modification au niveau des bases de cotisations à déclarer à l'URSSAF. Désormais, ils souhaitent que leur soit déclaré les bases de cotisations brute et plafonnée spécifiques (bloc 78, codes 22 et 24).

La date d'affiliation du salarié ne doit être envoyée en DSN que si elle n'est pas identique au début du contrat de prévoyance. Elle ne peut pas non plus être antérieure au 01/01/2000. Cette date n'est donc plus envoyée dans ces cas.

Lors de la création des bordereaux DSN, si un bordereau ne contient aucun élément à déclarer (établissement sans salarié, aucun contrat adhéré par l'établissement, ...), le bordereau n'est pas créé et un message en informe l'utilisateur.

Dans le cas d'une DSN incluant un salarié parti (suite à un bulletin calculé sur un mois postérieur à son départ par exemple), les affiliations du salarié aux contrats de prévoyance (blocs 70) étaient systématiquement déclarées. Désormais celles-ci ne sont ajoutées que si une base de cotisation (bloc 78) y fait référence dans la DSN.

Corrections :
- Lors de l'édition des fiches de présence en sélectionnant une période à imprimer, les cumuls des heures supplémentaires affichées en bas de page étaient ceux de la période complète.
- Dans la fenêtre de sélection des fiches à saisir, on conserve le tri et les filtres.
- Dans la fenêtre de saisie d'une fiche, la liste des pointages ne bloque plus la fenêtre de saisie.

La réindexation des fichiers parcourait les fichiers du dossier courant (en passant par l'option de menu "Outils - Réindexation des fichiers") mais ne les réindexait pas.

Les dates d'affiliation inscrites dans les blocs 78 qui sont créés à 0 lorsqu'aucun montant n'a été généré pour une affiliation prévoyance (cas d'un contrat de prévoyance sans cotisation individuelle) ne tenaient pas compte des dates d'entrée et/ou de sortie du salarié.

Dans certains cas, des cotisations, sans libellé de regroupement sur bulletin simplifié, pouvaient ne pas être imprimées sur le bulletin simplifié.

Le nouveau format de sauvegarde (extension .SVL) ne supportait pas la création d'un fichier supérieur à 2 Go (taille du fichier compressé). Désormais le fichier de sauvegarde est limité à une taille de 16 Eo (soit 16 777 216 To).

L'import de données dans la DSN ne s'enregistrait pas correctement dans la DSN.

Suite à la correction 65, les DSN "fin de contrat" provoquait une erreur : "Erreur à la ligne 13 du traitement Méthode CréerDéclaration_UneAffiliationPrévoyance. L'objet dynamique 'MonBloc70' n'a pas encore été alloué."

Corrections :
- Remise à disposition car il y avait un problème de compilation sur une fenêtre qui empêchait la validation des fiches.
- Il n'était pas possible de créer des motifs

Pour respecter l'obligation d'avoir au moins un bloc 78 lié à chaque bloc 70 du salarié, des blocs 78, 79 et 81 sont créés à 0 pour chaque affiliation du salarié (bloc 70) n'ayant pas eu de bloc généré du fait des paramétrages DSN (cotisations). Depuis le dernier correctif, dans le cas où le mois de la DSN est différent du mois de la date d'entrée du salarié, la date de début de rattachement était créée sans le jour (uniquement mois et année). Cela provoquait une erreur de date invalide lors de la création du fichier final (erreur lors d'un DateVersChaine)

Dans le cas où plusieurs contrats de prévoyances sont liés via les paramétrages DSN au même élément de paye (même cotisation). Toutes les affiliations liées étaient ajoutées sur les salariés ayant eu une affiliation sur ces différents contrats (cas par exemple de contrats remplacés, ou de passage de non cadre à cadre avec un calcul commun), et ce malgré les dates d'affiliation et de radiation inscrites sur les contrats de prévoyance ou sur l'affiliation du salarié. Désormais seuls les affiliations (blocs 70) des contrats de prévoyance en cours d'affiliation sont ajoutées, en tenant compte des dates d'affiliation et de radiation du contrat de prévoyance ou de son affiliation par le salarié, mais sans tenir compte de la date de sortie dans le cas où un élément de paye est paramétré sur ce contrat de prévoyance (cas d'un élément de paye calculé sur un salarié parti, pour qu'il ne reste que le dernier contrat affilié au moment du départ).

La procédure de clôture mensuelle et d'épuration des bulletins a été optimisée, notamment pour le cas des répertoires volumineux (plus d'un millier de salariés) où le temps de traitement peut devenir conséquent (plus de 20 minutes) :

• Des jauges ont été ajoutées sur toutes les phases de la clôture elle-même, permettant de mieux suivre l'avancement
• La mise à jour des périodes d'inactivité a été légèrement revue, ce qui a diminué le temps de traitement d'un facteur supérieur à 2
• Le traitement d'épuration des anciens bulletins, qui représente la moitié du temps de traitement global de la clôture mensuelle, peut désormais être déconnecté du traitement de clôture proprement dit. Cela se fait via une nouvelle option disponible dans les paramètres généraux (onglet Général, juste à côté du nombre de mois d'historique). Lorsque cette option est cochée, la clôture mensuelle n'englobe plus l'épuration des bulletins les plus anciens. Et cette épuration peut être lancée séparément, via une nouvelle option de menu Traitement/Epuration des bulletins, option située juste après celle de lancement de la clôture mensuelle.
• Enfin, ce traitement d'épuration peut aussi être lancé via une tâche planifiée. A cette fin, ce traitement crée systématiquement un fichier de trace, dans le sous-répertoire Log du répertoire des sous-répertoires. Ce fichier se nomme Trace Epurations AAAAMMJJ.log. Il contient pour chaque traitement d'épuration un message de début et fin de traitement où apparait le répertoire de données traité, ainsi que le nombre d'enregistrements supprimés dans chacun des fichiers traités.
  La ligne de commande pour lancer cette épuration en mode automatique sera de la forme :
    C:\Ldsystem\Program\Paye\LDPAYV9.exe LDZ /U=PAYE:{pQIuxg} /FEN="CLOMMAJ1(EA)"

Les règles de proratisation du plafond de la sécurité sociale ont changé au 01/01/2018, comme cela est décrit ici.
A cette occasion, le code calcul permettant de faire des proratas au 30ème, à savoir les codes [13] NombreXtaux+prorata30e et [23] NombreXtaux+Temps partiel+prorata30e, ont évolué aussi. Ils prennent en compte désormais les absences non rémunérées, celles ayant été paramétrées pour réduire le plafond (champ Réduction du plafond SS sur l'onglet Calcul de la fiche Rubrique), en plus des entrées-sorties dans le mois.
Or, dans certains cas, ce n'est pas ce qu'on souhaite : on veut parfois faire un prorata ne tenant compte que des dates d'entrée-sortie dans le mois, comme cela était le cas avant le 01/01/2018.
Pour remédier à ce problème, deux nouveaux codes calculs ont été créés :
[47]  Nombre X taux + prorata E/S
[48]  Nombre X taux + Tps partiel + prorata E/S
Ce sont les pendants des codes [13] et [23], mais pour faire le prorata au nombre de jours de présence dans le mois, les codes calculs 47 et 48 ne prennent en compte que les dates d'entrée-sortie dans le mois, pas les éventuels jours d'absence venant réduire le plafond SS.

Exemple d'un salarié entré le 5 janvier 2018 (soit 31-4=27 jours de présence) et ayant eu une semaine sans solde du 15 au 21/01 (soit 7 jours).
Supposons qu'on ait une rubrique qui calcule l'acquisition CP sur une base de 2,5 jours par mois.
  Avec le code calcul 13, l'acquisition CP serait de 2,5 x (27-7) / 31 = 1,61
  Avec le code calcul 47, l'acquisition CP sera de 2,5 x 27 / 31 = 2,18

Du fait du calcul particulier du complément d'allocation familiale (calcul sur la totalité du salaire si franchissement du seuil), le regroupement des cotisations sur le bulletin simplifié a été revu afin d'ignorer le cumul des bases (différentes)sur la même ligne "Famille - Sécurité sociale". Le cumul des taux, pour des lignes de cotisations ayant la même base reste actif. Cette modification ne s'applique qu'à ce libellé de regroupement.

Extrait de la fiche Modifications des modalités déclaratives de la CVAE dans la base de connaissance DSN-INFO : "A la suite de l'annonce du Secrétaire d'État auprès du Ministre de l'Action et des Comptes publics du 25 janvier 2018 devant l'assemblée générale de l'association SDDS (simplification et dématérialisation des données des sociétés), la DSN ne sera plus utilisée pour les besoins de la CVAE."
http://dsn-info.custhelp.com/app/answers/detail/a_id/1885

Pour cette raison, toutes les références à la CVAE ont été supprimées des programmes. Outre la non-génération des données concernées dans les nouvelles DSN, cela se traduit par la suppression des fonctionnalités suivantes :
- Définition des périodes CVAE, qui étaient à saisir pour chaque nouvel exercice dans la fiche société (ou fiche établissement)
- Coche Assujettissement à la CVAE de la fiche établissement
- Saisie des effectifs (menu Traitements mensuels - Autres données DSN - Affectations fiscales (CVAE))
- Sélection de l'envoi des effectifs CVAE en création de la DSN (étape Déclarations annexes)
- Edition des informations concernant la CVAE (y compris sur les anciennes DSN) sur l'état de contrôle de la DSN.

La notion de « circuit dérogatoire », qui doit être déclarée en DSN (depuis la version 2018) lors de la fin des contrats à durée déterminée d'usage (et qui est définie dans les informations de fin de contrat le cas échéant), ne s'intégrait pas dans les DSN mensuelles concernées.

La correction 71 (qui corrigeait un souci de réindexation du dossier) a introduit une erreur lors de la réindexation d'un dossier restauré, depuis une sauvegarde sans index provenant d'une version précédente. Dans ce cas, le programme de restauration ne réindexait plus les fichiers restaurés avant la migration du dossier dans la version courante, ce qui provoquait un plantage au moment de la validation de cette migration.

2 corrections ont été apportées à l'import dans une DSN d'une liste de valeurs (ou d'un fichier Excel) :
- Le contrôle du SIRET marquait la ligne en erreur à tort lorsque le SIRET recherché n'était pas le 1er SIRET de la DSN sur le même SIREN (plusieurs établissements d'une même entreprise dans la DSN)
- Certains libellés d'erreurs de contrôle n'étaient pas remontés. Les lignes étaient en rouge, mais sans explication.

La date de radiation, si elle a été saisie sur l'affiliation du salarié, était inscrite en DSN dans le bloc 70 - Affiliation Prévoyance, même si la date saisie était postérieure au mois principal déclaré de la DSN. Dans ce cas, la date de radiation n'est désormais plus inscrite en DSN.

Quand on lance l'interface de LDPaye vers LDCompta avec l'option de validation automatique dans LDCompta (via le serveur de message de LDCompta), il faut indiquer le code utilisateur et éventuellement le mot de passe pour ouvrir la session dans LDCompta.
Une option Reprendre l'utilisateur courant est également disponible, pour ouvrir la session LDCompta avec le même utilisateur et le même mot de passe que ceux de l'utilisateur courant dans LDPaye.
Lorsqu'on avait basculé LDPaye en environnement sécurisé, cette option ne fonctionnait plus (à cause du mot de passe de l'utilisateur courant qui est désormais crypté). Cette option fonctionne à nouveau via cette correction, mais uniquement dans le cas où l'environnement a été sécurisé par mot de passe interne. Si on a opté pour une sécurité via Active Directory, cette option est impossible, LDCompta Version 10 ne prenant pas en charge ce mode Active Directory. Attention aussi au fait que dans LDCompta Version 10, le mot de passe est encore limité à 10 caractères.

Les nombres de salariés affichés pour chaque cotisation sur l'état de cotisations pouvaient être erronés dans le cas où le n° de cotisation correspondait au début du n° d'une autre cotisation, également imprimée sur l'état. Exemple : cotisations 6010 et 6010B.

Lors de la validation de la fenêtre de paramétrage de l'environnement sécurisé, en appuyant sur la touche Entrée du clavier, le programme demandait à tort le mot de passe du jour, alors que cela n'était pas le cas si on cliquait à la souris sur le bouton OK.

Le correctif niveau 64 avait introduit le fait de ne pas créer les bordereaux n'ayant aucun salarié (bordereau vide) pour éviter d'avoir des bordereaux qui ne seraient jamais envoyés en DSN. Mais cela pose des soucis vis à vis des déclarations URSSAF.
En effet, les bordereaux de versement correspondent principalement aux blocs 20-Versement de la DSN, blocs que l'on ne renseigne que dans le cas où l'on a effectivement un paiement à effectuer. Mais dans le cas de l'URSSAF, on a aussi un bloc 22-Bordereau de cotisations dues, bloc qui est toujours attendu par l'URSSAF, même si le total indiqué dans ce bloc est nul. C'est le cas par exemple d'un établissement avec un seul salarié qui serait en absence tout le mois et pour lequel il n'y a donc aucune cotisation URSSAF. Le seul cas où le bloc 22 n'est pas nécessaire est celui d'une déclaration « néant », c'est à dire un établissement sans aucun salarié.
On est donc revenu à la situation antérieure au correctif 64 : la création des bordereaux de versement URSSAF est effective, même si le total du bordereau est à zéro.
Mais cela ne vaut que pour l'URSSAF : pour tous les autres OPS, les bordereaux à zéro ne sont pas créés. Le message d'avertissement signalant cela a toutefois été modifié afin qu'il ne soit affiché qu'une seule fois, à la fin de la création, pour l'ensemble des bordereaux non créés.

2 améliorations ont été apportées dans la fenêtre d'affichage des sessions actives (menu Fichier/Sessions actives) :

• Un bouton CMViewer permet de lancer le gestionnaire de licence CMServer en mode Viewer, pour voir qui détient des licences (dans le cas où l'on utilise des licences de type « réseau »).
• Dans la colonne Poste de travail, dans le cas d'un poste travaillant en environnement TSE ou Citrix, on voit désormais le nom du poste client et le nom du serveur TSE, par exemple PCJocelyn sur SERVEURLD. 

Dans la fiche d'une cotisation, lorsqu'on tentait de supprimer un paramètre DSN sur l'onglet Déclaration, cela pouvait provoquer un plantage. Cela se produisait lorsqu'on supprimait un paramètre DSN sur une ligne N et qu’il existait un paramètre DSN « incohérent » sur une ligne N+i.
Un paramètre « incohérent », c’est un paramètre qui est présent dans la table des paramètres, mais qui est invalide par rapport à l’organisme auquel est attaché la cotisation.
C’est le cas :
- Soit lorsqu’on modifie le type d’organisme sur une famille de cotisation (fortement déconseillé)
- Soit parce qu’un paramètre autorisé à un moment donné pour un organisme ne l’est plus suite à une évolution du cahier technique DSN.
C’est le cas par exemple de nombreuses cotisations CCVRP : il y avait auparavant tout un tas de paramètres à renseigner pour celles-ci. Puis la CCVRP est sortie du cadre DSN (fin 2017) et tous ces paramètres ne sont donc plus attendus par la CCVRP.

Dans le cas d'une nouvelle sortie (les informations de fin de contrat ne sont pas déjà saisies), si le code motif Pôle Emploi lié au code motif interne de fin de situation, défini dans la fiche situation du salarié, n'est pas renseigné (si par exemple, le code a été supprimé de la norme depuis la création du code motif interne), l'ouverture de la fenêtre de saisie des informations de fin de contrat pouvait provoquer l'erreur "Erreur à la ligne 4 du traitement Procédure locale xGérerAffichage. Vous avez appelé l'opérateur [] sur le champ MOFC. L'indice spécifié [-1] est invalide. "
Dans ce cas, pour pallier à ce souci (avant ce correctif), il suffit de retourner dans la codification du code motif de fin de situation, et renseigner le motif Pôle emploi par défaut qui servira à initialiser les informations de fin de contrat.

La copie du mot de passe utilisateur, utilisable pour ouvrir une session via une ligne de commande (cf. correctif V9.00 niveau 328), ne tenait pas compte du fait que le mot de passe copié était crypté dans le cas d'un environnement sécurisé. La valeur copiée, alors que l'environnement était sécurisé, ne pouvait donc pas être utilisée.

Suite à la fermeture de la norme P03V01 sur les serveurs de dépôt de la DSN (à compter du 16/04/2018), la création d'une DSN mensuelle a été interdite dans les normes antérieures à P18V01 pour les déclarations à créer postérieures à mars 2018.

Le contrôle du mot de passe actuel, s'il est demandé (utilisateur non administrateur) dans la fenêtre de modification de l'utilisateur, ne pouvait être validé si l'environnement était sécurisé car le programme contrôlait le mot de passe saisi avec une autre valeur que le mot de passe de l'utilisateur (ce qui provoquait une erreur disant que le mot de passe actuel était erroné).

Une modification a été apportée au contrôle du mot de passe via LDAP, pour gérer les domaines composés de plusieurs parties (ex : User@Domaine.LOCAL.fr). Il était possible jusque là de saisir ce type de domaine en ne gardant que la première partie (jusqu'au premier ".") dans le domaine du nom d'utilisateur LDAP, la suite était à inscrire dans la gestion des paramètres de l'environnement sécurisé (Alt+F2 à l'ouverture de session), dans la zone "Racine LDAP", sous la forme "DC=LOCAL, DC=fr" (pour cet exemple). Il est donc désormais possible d'utiliser la syntaxe avec les points dans le nom de domaine, et supprimer ce qui avait été mis dans la racine LDAP.

Dans certains cas, le mauvais positionnement du fichier des rubriques ou des cotisations provoquait la suppression d'un autre enregistrement que celui voulu. Cette suppression engendre alors la suppression de tous les enregistrements dans les fichiers liés (paramétrages, éléments variables, lignes de bulletins, ...).

Suite au décret du 12 mai 2018, qui mentionne les libellés à indiquer dans le bulletin de paye simplifié, les libellés des lignes de regroupements de cotisations du bulletin simplifié ont été mis à jour.

Le correctif précédent (niveau 112) ne s'appliquait à tort que sur les bulletins des salariés non cadre. Ces nouveaux libellés n'étaient pas non plus appliqués dans la liste des libellés simplifiés dans la fiche de cotisation.