Discussion :

[Nerva]

Bonjour à tous.

J'aimerais avoir vos avis et conseils sur les pistes à suivre pour la conception d'un bulletin de paie. J'ai déjà réalisé la chose dans des bases assez conséquentes, techniquement ça fonctionne - et même très bien ! - mais je sais que ça n'est pas la bonne méthode. Voilà comment c'est structuré...

Pour la paye en général, une seule table Paie - plus une table de valeurs par défaut - reliée à une table Salariés et une requête tirant les infos dans les deux tables pour alimenter un formulaire de saisie. La table Paie comprend évidemment des dizaines de champs (types d'heures, cotisations avec base, label et taux, etc...), et au final, 1 enregistrement = 1 bulletin de salaire.

C'est problématique essentiellement sous deux points :

- Si on doit ajouter un nouveau champ, ça oblige à faire pas mal de modifications en veillant à ce que les anciens enregistrements ne soient pas touchés.
- Comme les champs sont fixes sur l'état, même en incluant des conditions d'affichage telles qu'invisible pour les valeurs à 0 (par exemple pour le champ "Primes"), ça laisse des blancs et ça fait très amateur.

***

Je me suis donc attelé à une nouvelle conception.

- Toujours 1 table des salariés.
- 1 table Payroll, qui comprend moins de 10 champs, et à laquelle sont reliées les tables suivantes.
- 1 table pour les heures (normales, majorées...).
- 1 table pour les cotisations salariales.
- 1 table pour les cotisations patronales.
- 1 table qui contient les primes, indemnités, etc...

Ainsi, ce ne sont plus les champs mais les enregistrements qui contiennent les différentes lignes de la fiche de paie...

Seulement, je m'arrache les cheveux pour structurer requêtes et formulaire ! Et comme je ne sais même pas si l'approche est bonne ou non, j'en appelle à vos lumières.

Merci d'avance.

[marot_r]

Bonjour.

Sache que tu t'attaques à forte partie.

Ma recommandation sincère serait d'acheter un logiciel de paye avec lequel tu pourrais interfacer pour "pousser" les données et éventuellement en récupérer (par exemple pour la compta).

Sinon personnellement j'irai vers le découpage suivant :

Type de de source de revenu (heure, primes)
* Imposable ou non

Les remboursements de frais seraient vu comme des revenus non imposables.

Type de cotisation

• Source de la cotisation
• Taux de cotisation
• Source cotisation (salarial ou patronal)

Prélévement fixes (ex : ticket resto).

Pour la présentation, tu fais un formulaire principal par employé et tu fais un sous-formulaire par catégorie (revenus, cotisation, Prélèvements).
Même chose pour l'état.

Le point délicat est de programmer la "Source de la cotisation", sachant que ce n'est pas toujours la même source et je ne parle même pas de la CSF où tu as (avais ?) un remboursement sur une cotisation :-(.

Tu pourrais peut-être mettre du SQL qui calculerai le montant de la source ou une fonction VBA avec un indicateur du type de calcul à effectuer.

Il faudrait sans doute faire la même chose avec les revenus, par exemple une prime pourrait être un montant fixe ou un % du salaire de base.

En bref, il faut écrire un mini Excel ... d'où ma suggestion initiale d'acheter un logiciel qui fait cela.

A+

[Nerva]

Devant la quasi-absence de bases de données traitant le genre sur ce forum, je me doutais que ça ne devait pas être facile. Mais je ne désespère pas d'arriver à quelque chose.

Pour ta remarque à propos d'un logiciel commercial, je te répondrai que ce n'est pas le but, que j'aimerais bien y arriver par moi-même.

Maintenant, à propos de la structure des lignes de paie, voici quelques précisions. Les bulletins sont "simples" et homogènes. On trouve, de manière immuable :

- Le nombre d'heures normales
- Le nombre d'heures supplémentaires majorées (1)
- Les primes (1)

- Les cotisations salariales, fixes et identiques pour tout le monde
- Les cotisations patronales, idem

- Les indemnités (kilométriques)

Et c'est tout...

(1) Etant donné qu'il s'agit de paies à temps partiel dans leur grande majorité, il y en a très peu mais elles doivent figurer.

***

Donc après avoir passé encore pas mal de temps à cogiter, j'entrevois deux (nouvelles) bases de travail pour la structure.

- 1 table Paie, liée aux salariés, qui contiendra pour les calculs le taux horaire brut.
- 1 table d'heures, qui contiendra également les primes.
- 2 tables pour les cotisations.

Ou alors, la même chose, mais une seule table pour les cotisations, avec un champ supplémentaire qui définira les salariales et les patronales.

Là je n'ai pas vraiment le temps, mais j'ai idée de créer des requêtes "chaînées" [Salariés et Payroll] -> [Résultante et Heures], etc... tout en ne sachant pas ce que ça va donner.

***

Que j'arrive à en tirer quelque chose ou non, reste un autre problème qui n'a rien à voir avec une base paye mais voilà tout de même. Chaque table "possède" une table identique contenant les valeurs par défaut. Pour les heures, pas de soucis, une simple fonction RechDom copiera l'intitulé de la ligne d'heures normales dans le formulaire, restera plus qu'à saisir le nombre. Mais pour les cotisations, peut-on, avec une fonction similaire, copier X enregistrements d'une table à une autre ?

[marot_r]

Ok, si tes contraintes sont plus restrictives alors un développement perso peut être intéressant.
Tu n'auras pas à couvrir toutes les combinaisons possibles.

peut-on, avec une fonction similaire, copier X enregistrements d'une table à une autre ?

Quand j'ai eu à faire cela, j'ai utilisé une requête d'ajout qui ajoutait à ma table de travail les X lignes (selon critère) de ma table de référence.
Par exemple, pour mes statistiques de fin de mois, je le fait pour mes activités pour m'assurer que tous mes services ont bien toutes les activités attendues même si ils n'en ont pas fait ce mois en particulier.

Et n'oublie pas que qu'un code type peut simplifier ta modélisation (par exemple, on peut décider d'avoir un codeTypePayeur qui donne Salarie ou Employeur et n'avoir qu'une seule table de cotisation).

Aussi prévois le coup que les taux varient dans le temps.
Il faut donc qu'une fois le bulletin générées elles soient "gelées".
Et que le taux qui s'applique au moment de produire le bulletin soit le bon.

Une méthode que j'aime bien c'est d'avoir une table du type :

CodeCotisation
TauxCotisation
DateDebutTaux
DateFinTaux

qui permet de trouver facilement le taux en vigueur à une date données (avec un simple between).

Note qu'on peut le faire avec juste une DateApplicationTaux mais c'est un peu plus compliqué d'avoir le taux à une date données (il faut prendre le taux max dont la date est <= date cherchée).

A+

[Nerva]

J'avance petit à petit, c'est structuré à peu près comme je l'avais pensé mais je ne sais pas si c'est très académique. Lorsque j'aurai nettoyé un peu tout ça et mis des données bidon, je mettrai une copie en PJ.

Alors j'en suis à 14 requêtes consécutives, pour partir de la sélection des tables tblPayroll et tblEmployees et arriver "au net à payer". Plus 4 autres requêtes structurées pareillement pour les cotisations patronales. Et au "final", dans mon formulaire de saisie... plus moyen de modifier quoi que ce soit ! A cause d'un Impossible de mettre à jour Recordset, vu le nombre de requêtes et de regroupements. Naturellement, passer les requêtes et les formulaires en "Feuille rép.dyn.(MAJ globale)" n'y change absolument rien. J'ai contourné la chose en créant un second formulaire où je peux saisir sans problème la date, la période, l'employé, le taux horaire...

Reste (surtout) la question de la copie automatique (ou par bouton) de X enregistrements (dans mon cas, 10 pour les cotisations salariales et la même chose pour les patronales) d'une table de valeurs par défaut à une autre. J'ai créé une requête d'ajout mais elle plante, sûrement à cause d'une incohérence dans les champs.

Pour les cotisations salariales...

tblContribsTA_Default (table contenant les 10 cotisations salariales que je voudrais copier dans l'autre)

DaId
DaLabel
DaRate
DaBase
DaTaxable
DaActive

tblContribsTA (table contenant les cotisations salariales)

PaId
CaLabel
CaRate
CaBase
CaTaxable
CaActive

DaId est un numéro auto.
PaId est un numérique, indexé avec doublons.

Pour la copie des 10 enregistrements, ce sont les enregistrements des champs 2 à 6 qui doivent être copiés dans les champs correspondants, mais les 10 numéros de PaId doivent être identiques puisqu'ils correspondent au numéro auto de la table tblPayroll à laquelle la table est reliée (voir diagramme en PJ). Donc là je ne suis sûr de rien...

[Nerva]

Pour ce qui est de la requête ajout, j'avais bien une incohérence et ça fonctionne maintenant... à moitié !

Dans mon formulaire de saisie, une fois tout le toutim saisi, j'ai bien le bon numéro d'incrément qui s'affiche dans la première ligne du sous-formulaire des cotisations. Mais après exécution de la requête, les 10 enregistrements sont bien copiés, mais le champ PaId reste vierge (vérification en ouvrant la table), ce qui fait que les lignes ne s'affichent pas dans le SF du formulaire de saisie. Là je ne sais pas comment faire...

[informer]

Bonjour

Comme le souligne marot_r, le sujet est particulièrement ardu.

Partir des tables est une très très mais très mauvaise idée.

Pour faire simple, il faut analyser les processus métiers et en déduire et distinguer les objets pérennes (entités) comme

• le salarié
• fiche de paye
• etc...

Des opérations génériques qui sont le liens entre les entités. A tout cela, il faut aussi distinguer les modalités de calculs qui sont du domaine du code.


Puis sur la base de tous ces éléments, il est possible de construire un modèle conceptuel de données qui sera garant de ton schéma de base, sachant qu'un MPD peut être dénormalisé pour des raison d'optimisation mais ça c'est du domaine de l'administrateur DB.

Les informations fournies sont trop parcellaires pour une aide efficace.

Mais pas de découragement, à cœur vaillant...

Bonjour chez vous

[Jean-Philippe André]

Salut,

il faut egalement faire une chose, le taux oui, mais sur quelle assiette ?

Sur le modele, tu dois avoir les montants de bases, et les montants qui en derivent.

L'idee selon moi etant d'avoir un modele des montants qui sont calcules, dans lequel tu enverras en entree le ou les montants de base, et le reste de l'application fera le calcul.

Bien noter la tres importante logique de datation des perdiodes des taux, ceux-ci ayant une (trop) facheuse manie de changer au gre des gouvernements :/


Tu trouveras un exemples de MCD ici http://www.developpez.net/forums/d14...tion-publique/

[Nerva]

Partir des tables est une mauvaise idée ? Il faut bien que les données soient stockées quelque part. Où si ce n'est dans des tables ?

Le système de paie que j'essaie de construire est basique, figé, sans la complexité d'un bulletin de paie courant. Mis à part le taux des cotisations (ainsi que les nouvelles), rien n'a réellement changé depuis des années pour l'usage qui en est fait.

Je mets donc la base là où j'en suis arrivé en pièce jointe. Techniquement elle fonctionne même si la conception n'est pas la bonne (les données des tables sont bidons, salariés, taux...).

[Invité]

Bonsoir,
Ce sujet n'est pas traiter dans la base employés fournit en standard avec le pack office?