Logo LD Système
  Accueil Logiciels Services Support Lettres d'info
Newsletter

Des nouveautés dans les progiciels LDCompta et LDPaye
et l'ajustement 2012 de vos paramètres GMP pour l'AGIRC

Bonjour

Le sujet principal de cette nouvelle lettre d'information est la traditionnelle régularisation de la GMP, à effectuer sur la paye d'avril si vous ne l'avez pas déjà fait en mars. Nous avions en effet publié une actualité sur notre page de Support, et certains ont donc déjà traité cette régularisation.

C'est aussi l'occasion de revenir sur les quelques nouveautés récentes ou à venir très prochainement, tant dans LDCompta que dans LDPaye.

Bonne lecture à tous.

Cotisations AGIRC - Valeurs 2012 de la GMP

Les paramètres de la garantie minimale de points AGIRC pour 2012 sont désormais connus. Les cotisations minimales de retraite complémentaire AGIRC sont fixées à 787,68 euros pour l'année 2012 (salarié à temps plein présent toute l'année), soit 65,64 euros par mois (part patronale : 40,74 euros ; part salariale : 24,90 euros).

Ces cotisations correspondent à un salaire charnière, en dessous duquel la GMP intervient, de 3 354,33 euros par mois.

Régularisation indispensable

En début d'année, dans l'attente de connaître cette valeur définitive, c'est la valeur 3 347,22 € qui a été appliquée. Il faut donc procéder à une régularisation dès que possible.

Voici l'exemple pour le cas où l'on procède à la régularisation sur Avril 2012 :

  • en avril, appliquer un salaire charnière correspondant à 3354,33 + (3354,33 - 3347,22) x 3, soit 3375,66
  • en mai, revenir au salaire charnière normal, soit 3354,33.

Rappel : le salaire charnière doit être porté dans le champ Base minimum des cotisations retraites concernées (N° 6141 dans le jeu de démonstration, celle ayant comme libellé Base T2 avec GMP).
Si vous avez un doute quant aux valeurs de ce salaire charnière utilisé au fil des mois, il est possible de se vérifier. Visualisez le bulletin de paye d'un des salariés concernés (un salarié cadre), placez vous sur l'onglet Cumuls cotisations, sélectionnez en partie haute la cotisation concernée (N° 6141 dans le jeu de démonstration). Vérifiez alors la valeur apparaissant en partie basse sur la ligne intitulée Base minimum, dans la colonne Cumul mois courant. La valeur portée ici devrait être égale à 3354,33 x N° du mois. Par exemple, si vous procédez à cette vérification sur le mois d'avril, la valeur devrait être ici de 3354,33 x 4 = 13417,32. Si vous avez une valeur différente, c'est cette différence qui doit être régularisée, en majorant d'autant le salaire charnière du mois de paye en question pour obtenir en cumul la valeur souhaitée de 13417,32.

Dans tous les cas, n'oubliez pas de ramener ce salaire charnière le mois suivant la régularisation, donc le mois de mai si vous régularisez en avril, à la valeur normale de 3 354,33 €.


Nouveautés dans LDCompta Version 9.00

Pas mal de nouveautés ont vu le jour ces dernières semaines dans LDCompta. Preuve une fois encore que les progiciels LD SYSTEME évoluent sans cesse pour répondre toujours davantage à vos besoins. Pour celles et ceux qui n'ont pas suivi tout cela dans le détail, nous présentons ci-après les améliorations les plus significatives.

Export des données comptables pour la DGI (Version 9 - Niveau 443)

LDCompta propose un nouvel outil d'export de données conforme aux recommandations de la Direction Générale des Impôts (DGI), dans le cadre du contrôle des comptabilités informatisées. Il permet de produire très simplement (quelques clics) les deux fichiers attendus par la DGI :

  • le premier correspondant à une balance des comptes généraux et auxiliaires,
  • le second contenant les écritures comptables elles mêmes.

Ce nouvel outil est accessible via le menu Outils / Export de données comptables pour la DGI.

Les deux fichiers nommés respectivement BLxx et ECxx, xx étant représentatif de l'année de clôture de l'exercice concerné, sont produits au format csv, (donc facilement lisibles par Excel), avec choix du séparateur de colonne, du séparateur décimal et du format des dates. On peut également définir quelles sont les données placées dans le second fichier, sachant que les choix proposés par défaut correspondent aux attentes de la DGI.

Consultation et impression des relevés bancaires (Version 9 Niveau 449)

De nouvelles informations sont présentées en consultation et impression des relevés bancaires :

  • le N° de pièce indiqué sur le relevé
  • le code opération interbancaire
  • la référence sur le relevé
  • un code Vir.reçu qui permet de savoir si l'écriture en question a déjà été traitée au travers de la nouvelle saisie des virements reçus, saisie décrite ci-après. Ce code peut prendre les valeurs :

    • C : écriture comptabilisée dans la saisie des virements reçus
    • I : écriture ignorée dans la saisie des virements reçus (certainement déjà comptabilisée par ailleurs)
    • blanc : écriture non traitée dans la saisie des virements reçus

Nouvelle procédure de saisie des virements reçus (Version 9 Niveau 450)

Une nouvelle procédure est offerte depuis mars 2012, pour faciliter la saisie des virements reçus. Cette procédure exploite les relevés bancaires journaliers, reçus via un logiciel de communication bancaire à la norme CFONB (comme CUBICUS) et intégrés dans LDCompta. Sur ces relevés bancaires, on ne s'intéresse qu'à certaines écritures en fonction du code opération interbancaire, et notamment les virements reçus identifiés par un code opération interbancaire égal à 05 ou 18. Pour ces opérations, cette procédure permet de déclencher une comptabilisation soit entièrement automatique, soit semi-automatique (avec choix du compte de contrepartie notamment), avec également lettrage du compte de contrepartie (un compte client bien souvent) lorsque ce compte est lettrable.

Cette procédure de saisie est accessible par le menu Saisie/Virements reçus.

Si vous disposez des relevés bancaires consultables directement dans LDCompta (menu Traitement/Relevés bancaires), et si vous recevez quotidiennement des virements, cette saisie est faite pour vous ; elle vous fera gagner un temps précieux, tout en diminuant le risque d'erreur. Enfin, le rapprochement bancaire ultérieur entre ces opérations présentées sur les relevés bancaires et les écritures saisies se fera automatiquement et là aussi sans risque d'erreur.

Pour en savoir plus, consultez le chapitre J de la documentation Nouveautés de la version 9 - Révision 3.

Rapprochement bancaire en devises (Version 9 Niveau 454)

La procédure de rapprochement bancaire a été étendue pour supporter le cas des comptes de banques gérés en devises. Le rapprochement de ces comptes de banque en devise est désormais supporté tant en rapprochement manuel qu'en rapprochement automatique.

Le rapprochement d'un compte de banque se fait en devises lorsque les 2 conditions suivantes sont vérifiées :

  • le module Devises est actif
  • le compte de banque que l'on cherche à pointer a un code devise renseigné dans le plan comptable, et ce code devise est différent de la devise de référence.

Dans le cas d'un rapprochement bancaire effectué en devises, les particularités suivantes s'appliquent :

  1. tous les montants apparaissant sur les écrans et états de rapprochement de ce compte sont présentés dans la devise du compte. Sur les écrans, ces montants apparaissent en violet pour mettre en relief cette particularité. Le code devise est rappelé dans le libellé des différents totaux et soldes qui sont présentés.
  2. les écritures présentes dans le compte ayant un code devise autre que celui indiqué dans la fiche du compte sont ignorées. Un message d'avertissement signale cela le cas échéant, mais en principe, on ne devrait jamais rencontrer ce cas de figure : sur un compte de banque géré en devise, toutes les écritures doivent être comptabilisées dans cette devise.
  3. de même, les éventuelles écritures de différence de change présentes dans ce compte de banque sont ignorées ; elles n'influent aucunement sur le solde du compte en devises, seulement sur le solde du compte en euros.
  4. dès lors qu'il existe au moins un rapprochement bancaire pour un compte de banque donné, il devient impossible de modifier le code devise de compte dans le plan comptable. Ainsi, lorsqu'on a commencé une série de rapprochements sur un compte dans une devise donnée, tous les rapprochements ultérieurs sont obligatoirement dans la même devise (il n'y a plus aucun moyen de changer cette devise de rapprochement), ce qui garantit la cohérence de ces rapprochements successifs.
  5. pour pouvoir réaliser un rapprochement automatique en devises, il faut bien entendu disposer des relevés bancaires journaliers dans la devise de gestion du compte.

Nouveautés dans LDPaye Version 7.00

Des nouveautés dans LDPaye également, déjà disponibles ou à venir très prochainement...

Un second cadre de cumuls en pied de bulletin (Version 7 - Niveau 151)

On peut désormais imprimer un second cadre de cumuls en pied de bulletin. Ce second cadre vient en lieu et place des 3 lignes de libellé provenant de la fiche Société ou Etablissement, en bas à droite du bulletin. Et dans ce cas, les informations relatives aux congés payés sont redisposées en partie droite du pied de bulletin.

Ce nouveau cadre comporte jusqu'à 9 cumuls, disposés en 3 lignes et 3 colonnes. Chaque ligne et chaque colonne dispose d'un intitulé paramétrable. L'objectif principal de ce second cadre est de présenter des données telles que les congés ancienneté ou les repos compensateur, où l'on a traditionnellement une valeur acquise, une valeur prise et un solde. Ces 3 valeurs pourront être ainsi disposées dans les 3 colonnes de ce cadre, avec les intitulés proposés par défaut : Acquis, Pris, Solde.

Le contenu de ce second cadre de cumuls se paramètre dans la fenêtre Plan de paye/Paramètres généraux, sur le nouvel onglet intitulé Bulletin 2. A l'impression d'un bulletin, si aucune case parmi les 9 cumuls disponibles n'est renseignée, le cadre n'apparait pas en pied de bulletin ; on conserve alors l'ancienne disposition, avec les 3 lignes de texte. De même, si pour une des 3 lignes données, les 3 colonnes sont à zéro, le système masque également l'intitulé de la ligne.
Notez que dans la 3ème colonne, celle censée faire apparaitre le solde, on peut indiquer la valeur "*" en lieu et place d'un nom de cumul ; le système fera apparaitre alors à cet emplacement la différence entre la valeur apparaissant en colonne 1 (acquis) et celle apparaissant en colonne 2 (pris).

Enfin, ce second cadre de cumul, lorsqu'il est paramétré, apparait aussi en visualisation de bulletin, sur l'onglet Cumuls.

Remarque : pour que cela fonctionne, il faut disposer de l'impression du bulletin standard. Si vous avez opté pour un bulletin spécifique (ou une adaptation du bulletin standard via Etats et Requêtes Utilisateur), il faut reprendre votre état spécifique pour bénéficier de cette nouveauté.

Calcul des bulletins plus rapide (Version 7 Niveau 176)

La procédure de calcul des bulletins a été revue en profondeur pour diminuer le temps de calcul, notamment sur les dossiers volumineux.

Cette optimisation a portée principalement sur la façon dont sont gérés les cumuls salariés et cumuls cotisation : plutôt que de reporter directement dans la base de données toutes les mises à jour de ces cumuls faites au fil du calcul, ces cumuls sont désormais gérés dans des tableaux directement dans la mémoire vive du poste de travail, et ne sont reportés dans la base de données qu'une seule fois à la fin du calcul. On diminue ainsi grandement les accès à la base de données, ce qui améliore très sensiblement les performances surtout lorsque la base de données est en réseau.

Une seconde optimisation a été faite, dans le cas du recalcul d'un bulletin : elle consiste, en fin de calcul, lorsqu'on doit inscrire les valeurs des cumuls dans la base de données, à procéder par différence : plutôt que de supprimer tous les cumuls en début de calcul pour les recréer en fin de calcul (car ce sont bien souvent les mêmes), on réalise une mise à jour « différentielle » des valeurs des cumuls en fin de calcul. Si le résultat final est le même, cette nouvelle façon de procéder est beaucoup plus rapide particulièrement sur les bases ayant de gros volumes, car les temps de traitement nécessaires aux ajouts et suppressions dans la base de données vont croissants avec la taille des fichiers.

Grâce à ces deux optimisations, tout le monde pourra observer une amélioration notable du temps de calcul des bulletins : entre 20 et 50% de gain selon la configuration (base locale ou réseau, taille des fichiers, premier calcul ou recalcul...). Et cette amélioration est encore plus nette quand il y a plusieurs postes qui effectuent des calculs en parallèle sur un même dossier de paye.

Seul petit bémol : ces optimisations ont nécessité la réécriture d'une bonne part du programme de calcul des bulletins, avec tous les risques inhérents à cela. Malgré des batteries de tests menés dans différents environnements, sur des plans de paye très variés, nous ne sommes pas à l'abri de petites surprises. Alors, si vous constatez une anomalie suite à la diffusion de ce correctif, faites nous en part au plus vite.

Nouveautés communes aux deux logiciels

Enfin, pour terminer, deux petites nouveautés communes aux deux logiciels, dans les prochains correctifs diffusés d'ici fin du mois...

Une meilleure sauvegarde des sous-répertoires

Des améliorations ont été apportées à la procédure de sauvegarde, tant dans LDCompta que dans LDPaye, pour ce qui concerne la sauvegarde des sous-répertoires :

  1. seule la partie indispensable du répertoire Etats et Requêtes est désormais sauvegardée. Les sous-répertoires de compilation présents dans ce répertoire Etats et Requêtes sont désormais ignorés (sous-répertoires dont le nom se termine par .cpl). De même, les sous-répertoires nommés Sauvegarde et Historique au sein de ce répertoire Etats et Requêtes sont ignorés.
  2. on a la possibilité d'ignorer le sous-répertoire Documents contenant toute l'arborescence des documents GED. En effet, la place nécessaire à la sauvegarde de ce sous-répertoire peut être très importante, et pose problème lorsqu'on réalise des sauvegarde sur clé USB. Notez toutefois que si ce sous-répertoire n'est pas sauvegardé par la procédure de sauvegarde de LDPaye, il faut qu'il le soit par ailleurs, quelle que soit la méthode employée (recopie disque à disque, logiciel de sauvegarde sur un serveur...).
  3. la gestion de la jauge qui figure l'avancement des sauvegardes a été simplifiée, car l'affichage de cette jauge pénalisait fortement le temps nécessaire à la sauvegarde des sous-répertoires.

Une meilleure gestion des licences

Depuis quelques mois, le système de gestion des licences Hasp (les petites clés USB que l'on devait connecter aux postes de travail) cède la place progressivement à un système plus moderne dénommé CopyMinder, basé sur Internet.

Suite aux remarques qui nous ont été faites après quelques mois d'utilisation, l'intégration de ce système de contrôle des licences au sein des logiciels LD SYSTEME a été optimisée, afin de rendre ce contrôle moins intrusif. Ainsi, une fois le logiciel lancé, vous ne serez plus jamais mis en attente d'un quelconque contrôle de licence, toutes les phases de ce contrôle se déroulant désormais en arrière plan, sans perturber votre travail. Aucune fenêtre ne viendra plus interrompre inopinément une saisie ou une consultation. Même dans le cas de licences « flottantes » sur un réseau, la communication entre le poste client et le serveur de licences est tout à fait transparente.

Enfin, les messages d'erreur les plus fréquents sont plus explicites, et notamment le cas où il n'y a plus aucune licence flottante disponible sur le réseau lors de l'ouverture d'une nouvelle session.


Si vous ne pouvez visualiser pas correctement ce mail, cliquez ici
Si vous ne souhaitez plus recevoir notre lettre d'informations, veuillez vous désinscrire en cliquant ici
LD SYSTEME © 2024