Petit problème en access
Fermé
Bobyankishi
Messages postés
166
Date d'inscription
vendredi 6 septembre 2002
Statut
Membre
Dernière intervention
13 novembre 2009
-
28 juil. 2008 à 12:58
cchristian Messages postés 921 Date d'inscription lundi 21 janvier 2008 Statut Membre Dernière intervention 6 mars 2012 - 30 juil. 2008 à 21:39
cchristian Messages postés 921 Date d'inscription lundi 21 janvier 2008 Statut Membre Dernière intervention 6 mars 2012 - 30 juil. 2008 à 21:39
A voir également:
- Petit problème en access
- Petit colis distribution - Forum Consommation & Internet
- [Sujet Groupé] Shein livraison sans réception ✓ - Forum Consommation & Internet
- You don't have permission to access this resource ✓ - Forum Réseaux sociaux
- Ème en petit ✓ - Forum LibreOffice / OpenOffice
- Excel trier du plus grand au plus petit - Guide
7 réponses
cchristian
Messages postés
921
Date d'inscription
lundi 21 janvier 2008
Statut
Membre
Dernière intervention
6 mars 2012
131
28 juil. 2008 à 13:47
28 juil. 2008 à 13:47
Bonjour,
Peux-tu illustrer avec un cas concret, car si je comprends le problème dans son ensemble, je ne comprends pas très bien ce que tu souhaites faire.
Quelques questions :
S'agit-il d'un recalage ponctuel de fichier à l'évènement "modificatioon du salaire journalier d'un employé" ou "recalage de tout une partie des salaires suite à une antériorité" ?
Dans quel état (de pertinence) se trouvent actuellement les données des fichiers concernés ?
Le traitement informatique d'intégration de chaque (ou des) nouveau(x) salaire(s) s'efffectue-t-il par lot ou bien en temps réel ?
.....................................
Peux-tu illustrer avec un cas concret, car si je comprends le problème dans son ensemble, je ne comprends pas très bien ce que tu souhaites faire.
Quelques questions :
S'agit-il d'un recalage ponctuel de fichier à l'évènement "modificatioon du salaire journalier d'un employé" ou "recalage de tout une partie des salaires suite à une antériorité" ?
Dans quel état (de pertinence) se trouvent actuellement les données des fichiers concernés ?
Le traitement informatique d'intégration de chaque (ou des) nouveau(x) salaire(s) s'efffectue-t-il par lot ou bien en temps réel ?
.....................................
blux
Messages postés
25976
Date d'inscription
dimanche 26 août 2001
Statut
Modérateur
Dernière intervention
17 avril 2024
3 286
28 juil. 2008 à 13:49
28 juil. 2008 à 13:49
Salut,
le mieux est de créer une table avec les valeurs des différents barêmes. Ainsi, lorsque tu créées un nouveau bulletin de paie, par exemple, il suffit de le lier avex le numéro d'ordre de cette table barême pour faire les calculs.
Comme ça, à tout moment dans la vie de la base, tu peux recalculer un bulletin de paie sans souci.
Ou alors je n'ai pas compris ton problème...
le mieux est de créer une table avec les valeurs des différents barêmes. Ainsi, lorsque tu créées un nouveau bulletin de paie, par exemple, il suffit de le lier avex le numéro d'ordre de cette table barême pour faire les calculs.
Comme ça, à tout moment dans la vie de la base, tu peux recalculer un bulletin de paie sans souci.
Ou alors je n'ai pas compris ton problème...
cchristian
Messages postés
921
Date d'inscription
lundi 21 janvier 2008
Statut
Membre
Dernière intervention
6 mars 2012
131
28 juil. 2008 à 14:07
28 juil. 2008 à 14:07
Oui, mais ce qui a été calculé et payé ne doit plus être modifié. C'est là où je coince dans l'ennoncé initial.
blux
Messages postés
25976
Date d'inscription
dimanche 26 août 2001
Statut
Modérateur
Dernière intervention
17 avril 2024
3 286
28 juil. 2008 à 14:22
28 juil. 2008 à 14:22
il faut qu'il refasse son modèle de données, car sinon rien n'est possible...
soit on crée des lignes avec le salaire en dur (donc elles sont historisées et non modifiables), soit on crée des lignes avec le salaire non saisi mais pointant sur une table où on aura les valeurs de calculs qui s'appliquent au moment de l'insertion dans la table. Comme ça, si des éléments changent pour le calcul (temps journalier ou mensuel), on peut rajouter une ligne dans cette table 'éléments' et y faire référence pour les futurs calculs tout en laissant les autres valeurs pour les lignes déjà saisies.
soit on crée des lignes avec le salaire en dur (donc elles sont historisées et non modifiables), soit on crée des lignes avec le salaire non saisi mais pointant sur une table où on aura les valeurs de calculs qui s'appliquent au moment de l'insertion dans la table. Comme ça, si des éléments changent pour le calcul (temps journalier ou mensuel), on peut rajouter une ligne dans cette table 'éléments' et y faire référence pour les futurs calculs tout en laissant les autres valeurs pour les lignes déjà saisies.
cchristian
Messages postés
921
Date d'inscription
lundi 21 janvier 2008
Statut
Membre
Dernière intervention
6 mars 2012
131
28 juil. 2008 à 14:31
28 juil. 2008 à 14:31
Je crois que sur le plan comptable et légal il est interdit de recalculer un salaire. Au mieux il est possible de calculer pour un mois en cours, des rappels sur salaires pour une péroide donnée.
P.S. 14h43
Par compte où tu as certainement raison c'est que :
Une entreprise doit MALGRE TOUT être en mesure de délivrer des duplicatas. C'est-à-dire pouvoir recréer des situations administratives passées.
P.S. 14h43
Par compte où tu as certainement raison c'est que :
Une entreprise doit MALGRE TOUT être en mesure de délivrer des duplicatas. C'est-à-dire pouvoir recréer des situations administratives passées.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Bobyankishi
Messages postés
166
Date d'inscription
vendredi 6 septembre 2002
Statut
Membre
Dernière intervention
13 novembre 2009
2
28 juil. 2008 à 17:29
28 juil. 2008 à 17:29
--
slt à tous, je m'excuse, un problème technique.
En fait le problème est que dès que j'introduit le nouveau bareme, tous les anciens calculs de salaire deviennent faussés, tu veux consulter le salaire d'il ya 1 an mais il te fout un salaire avec une base de juillet 2008.
Alors moi j'ai pensé créé une table historique, avec les éléments des toutes les tables, je l'ai en fait créé sur base d'une requete globale, maintenant mettre les anciennes données dans la table historique ne pose pas de blème mais c'est quand il faut actuellement calculer le salaire, comment faire pour que ces données soient directement enregistrées dans historique.
Bob; l'homme c'est l'homme
slt à tous, je m'excuse, un problème technique.
En fait le problème est que dès que j'introduit le nouveau bareme, tous les anciens calculs de salaire deviennent faussés, tu veux consulter le salaire d'il ya 1 an mais il te fout un salaire avec une base de juillet 2008.
Alors moi j'ai pensé créé une table historique, avec les éléments des toutes les tables, je l'ai en fait créé sur base d'une requete globale, maintenant mettre les anciennes données dans la table historique ne pose pas de blème mais c'est quand il faut actuellement calculer le salaire, comment faire pour que ces données soient directement enregistrées dans historique.
Bob; l'homme c'est l'homme
Bobyankishi
Messages postés
166
Date d'inscription
vendredi 6 septembre 2002
Statut
Membre
Dernière intervention
13 novembre 2009
2
30 juil. 2008 à 10:22
30 juil. 2008 à 10:22
--
Resalut, Cchristian et blux.
je n'ai pas trop envie de tout chambouler d'autant plus que ce n'est pas moi qui travaillerai dessus, alors j'ai fait ceci:
1) j'ai créé la table historique, vide au départ
2)J'alimente cette table par une mise à jour qui tient compte des barêmes des éléments de paie dépuis la création de la base.
3) J'ai créé un formulaire pour le calcul de la paie et qui met à jour en meme temps la table historique
4) il reste à ce que je change la source des données des états, normalement ça sera dorenavent la table historique ou une requete basée sur cette table.
HISTORIQUE(matricule, codemois, codan, codett,nom, post-nom,liban,libmois,catégorie, fonction, date d'engagement, etatcivil,sexe, salbase,nbrejr, nbrejrpr,nbrejhs,nbrejhs160,nbrejhs200,nbrjmal,tauxhs, tauxhs160, tauxhs200, tauxjmal,allocaf,allocaEp,transmens,logement,primdip,avanceSal,congépayé, totaltaxable,inss, retenu,taxe;net à payer)
J'ai pas encore terminé mais ksk vous en pensez? les autres tables restent telles qu'elle...
Bob; l'homme c'est l'homme
Resalut, Cchristian et blux.
je n'ai pas trop envie de tout chambouler d'autant plus que ce n'est pas moi qui travaillerai dessus, alors j'ai fait ceci:
1) j'ai créé la table historique, vide au départ
2)J'alimente cette table par une mise à jour qui tient compte des barêmes des éléments de paie dépuis la création de la base.
3) J'ai créé un formulaire pour le calcul de la paie et qui met à jour en meme temps la table historique
4) il reste à ce que je change la source des données des états, normalement ça sera dorenavent la table historique ou une requete basée sur cette table.
HISTORIQUE(matricule, codemois, codan, codett,nom, post-nom,liban,libmois,catégorie, fonction, date d'engagement, etatcivil,sexe, salbase,nbrejr, nbrejrpr,nbrejhs,nbrejhs160,nbrejhs200,nbrjmal,tauxhs, tauxhs160, tauxhs200, tauxjmal,allocaf,allocaEp,transmens,logement,primdip,avanceSal,congépayé, totaltaxable,inss, retenu,taxe;net à payer)
J'ai pas encore terminé mais ksk vous en pensez? les autres tables restent telles qu'elle...
Bob; l'homme c'est l'homme
cchristian
Messages postés
921
Date d'inscription
lundi 21 janvier 2008
Statut
Membre
Dernière intervention
6 mars 2012
131
30 juil. 2008 à 21:39
30 juil. 2008 à 21:39
Bonsoir Bobyankishi,
C'est une solution, mais elle est lourde (redondance, stockage, sauvegardes, intégrité,.......... des données).
Mais de toute manière il est nécessaire de disposer d'un historique cohérent et en fait il n'existait pas vraiment.
Tu pourras toujours à terme, en maintenance évolutive/adaptative, , dégonfler le(s) autre(s) base(s) d'une quantité (de données) équivalente.
Tiens-nous informés,
A+
C'est une solution, mais elle est lourde (redondance, stockage, sauvegardes, intégrité,.......... des données).
Mais de toute manière il est nécessaire de disposer d'un historique cohérent et en fait il n'existait pas vraiment.
Tu pourras toujours à terme, en maintenance évolutive/adaptative, , dégonfler le(s) autre(s) base(s) d'une quantité (de données) équivalente.
Tiens-nous informés,
A+
29 juil. 2008 à 08:48
Slt Cchristian, quand mon copain a realisé son programme, il a mis tous les éléments succeptibles de ne pas changer dans le temps, dans la table personnel, des éléments comme le salaire journalier, le logement, le transport etc... hors il se fait que la legislation du pays vient de changer le smig et donc le salaire journalier, le salaire de base, le transport. Si on introduit le nouveau salaire journalier et le transport, toutes les données des années antécédentes changent. Hors ça ne doit pas se passer comme cela. Je n'aimerai pas changer du coup le MCD, j'aimerai dans la mésure du possible, rester dans la logique de mon pote, c'est pourquoi j'ai pensé créer une table historique où se trouveront tous les éléments de la paie et toute l'info sur le personnel, je crée cette table à partir d'une requete général qui existe dejà. Là ou je plante, c'est comment faire la connexion en temps réel entre cette table et les autres, ça veut dire lorsqu'il saisit un nouveau salaire, dans la table personnel il change directement et tout le calcul qui s'en suit mais il faudrait qu'au meme moment ces informations entre dans la table historique... Voilà je pense avoir été un peu plus clair.
Bien à toi
Bob; l'homme c'est l'homme
29 juil. 2008 à 12:12
Est-ce que ce résumé traduit l'existant et ce que tu souhaites réaliser :
En l'absence de toute modification de zones sensibles (telle saljour) les tables en ligne de l'application reflètent la dernière situation des mois passés (et de celui en cours à une date d'arrêté) et ce pour tout le personnel. De par leur contenu ces tables semblent donc constituer un historique des traitements mensuels de la paie.
Aucun changement sur ces tables n'est souhaitable afin de permettre à cette application de continuer de fonctionner sans qu'il soit nécessaire de changer le MCD avec les modifications que celà sous-entend .
Préalablement une ou plusieurs tables "historique" doivent etre créées et chargées à une date arrêtée (reprise de l'existant).
Cette table "historique" évoluera au gré des modifications intervenant sur chaque matricule. A l'issue de la prise en compte effective de toute nouvelle modification, elle devra elle aussi refléter la dernière situation des données de la paie.
Questions:
Si on introduit le nouveau salaire journalier et le transport, toutes les données des années antécédentes changent
Là je ne comprends pas pourquoi et surtout comment au niveau fonctionnel de l'appli en question un changement (salaire journalier, transport, ......) affecte toutes les données des années antérieures pour chaque matricule concerné. Ce que tu appelles un changement, est-ce une modification EFFECTIVE des données des tables (y compris les lignes des années antérieures, notamment la colonne "saljour" de la table "personnel" ? OU BIEN ce changement non souhaité n'est-il qu'un reflet; c'est-à-dire la conséquence d'un algorithme de calcul utilisant à tort et systématiquement les dernières valeures et aboutissant pour l'utilisateur à un constat visuel de résultats erronés (affichage (papier, écran)
Ce point est particulièrement important car il conditionne les modifications à effectuer et les objets concernés (programme, tables, ..)
Je pense que la réponse se trouve dans l'illustration qui suit :
Salaire :
Clé primaire :
mat0001 01 2008 ...............
mat0001 02 2008 ...............
mat0001 03 2008 ...............
........................................
mat0002 01 2008 ...............
mat0002 02 2008 ...............
mat0002 03 2008 ...............
Personnel :
Clé primaire :
mat0001 nom ............................. 100 10 ..........
mat0002 nom ............................. 150 15 ..........
Si je ne me suis pas trompé dans ce qui précède les colonnes saljour, transport, .... devraient se trouver dans la table "salaire" et non dans personnel . (il semble qu'une forme normale n'a pas été respectée au niveau de la table "Personnel")
Salaire :
mat0001 01 2008 ............... 080 10 .......... (SITUATION AU 01 2008)
mat0001 02 2008 ............... 080 10 .......... (SITUATION AU 02 2008)
mat0001 03 2008 ............... 100 10 .......... (SITUATION AU 03 2008)
........................................
mat0002 01 2008 ............... 130 15 .......... (SITUATION AU 01 2008)
mat0002 02 2008 ............... 140 15 .......... (SITUATION AU 02 2008)
mat0002 03 2008 ............... 150 15 .......... (SITUATION AU 03 2008)
Personnel :
mat0001 nom ............................. 100 10 .......... (éventuellement dernière SITUATION AU 03 2008)
mat0002 nom ............................. 150 15 .......... (éventuellement dernière SITUATION AU 03 2008)
---------------------------
Il suffirait pae conséquent d'ajouter ces colonnes à la table "Salaire" en leur donnant le nom qu'elles ont dans la table "Personnel"
après les avoir renommées dans cette dernière.
Cela ne résoudrait probablement pas tout au niveau des modifs à apporter à l'existant mais permettrait de minimiser les interventions et réglerait le problème de l'historique qui de toute façon doit, à mon avis, d'une manière ou d'une autre être intégré dans l'application.