• 0
gcroset

Calcul automatique au lancement

Question

Bonjour

Pour un programme qui gère le pécule de personnes accueillies temporairement, dans une Communauté.

 Soit :

-       Une TA_parametre, qui me permet de définir certains paramètres identifiants la structure

-       Une TA_contact

-       Une  TA_ séjours, qui gère la date d’arrivée, de départ, et le nb de jours de présence (Date_actuelle -  date_arrivée+1).

-       uneTA_pecule, qui gère le pécule des personnes accueillies, pécule composé de plusieurs éléments, dont plus particulièrement d’un pécule journalier, calculé en rapport au nombre de jour passé dans la communauté.

Jusque là pas de problème. Lorsque je vais dans la TA_pecule, il me calcule la somme du pécule journalier, (voir copie écran), donc mise à jour de la somme chaque fois que j’ouvre le programme.

Si je décide de modifier le montant du pécule journalier, il me fait le calcul sur tous les jours de présences avec le nouveau tarif, et c’est ce que je ne veux pas. Il doit prendre en compte le nouveau tarif seulement depuis le moment où je le change.

J’ai pensé créer une TA_calcul_pecule, qui me créerait, à l’ouverture du programme, pour chaque jour un enregistrement et me rapatrierait la somme dans ma TA_pecule, ce qui serait une manière de résoudre mon souci.

Mais là, un autre problème, surgit, il faut que le programme soit activé chaque jour, alors qu’il ne sera utilisé que 2 ou 3 fois dans la semaine, voir moins. Je devrais alors avoir une "moulinette" qui identifie la date à laquelle le programme a été utilisé pour la dernière fois, et calculer le nombre de jours sans utilisation, de façon à me créer autant d’enregistrements dans la TA_calcul_pecule.

Petite précision, je ne suis pas un professionnel de la programmation, et je pense que je me complique la vie et créant une « usine à gaz ».

Les utilisateurs aimeraient que chaque fois qu’ils ouvrent le programme, le programme calcul automatiquement la somme du pécule à la date du jour de l’utilisation

Je recherche donc une piste que me permette d’atteindre la solution à mon souci, passager je l’espère.

 Merci par avance.

Gaston 

Capture d'écran 2017-03-18 à 15.55.01.png

Partager ce message


Lien à poster
Partager sur d’autres sites

9 réponses à cette question

  • 0

Bonjour,

Il me semble qu'il faut raisonner comme pour les factures (ou tout autre base avec des "lignes" dont le contenu peut changer). pour garder l'antériorité et actualiser, il faut une table intermédiaire. Il faut fouiller ce sujet pour adapter et progresser.

Bonne recherche

G

Partager ce message


Lien à poster
Partager sur d’autres sites
  • 0

Bonjour

Merci pour ta réponse.

C'est une direction à laqelle je pensais effectivement, mais comme je ne veux pas, lorsque j'imprime le récapitulatif du pécule, ou un état chaque mois, me trouver avec 1 ligne par jour, soit 365 lignes pour l'année, j'imaginais créer une TA_calcul qui me créerait les lignes et me rapatrierait le total de l'état au jour X dans la TA_pécule. Mais là, comme le programme ne sera pas activé tous les jours, il faut qu'au travers d'un calcul, il identifie la dernière fois que le programme a été ouverte, et me crée, à l'ouverture du programme, autant de lignes que de jours où le programme n'a pas été activé, et c'est là que je me demande si je ne construis pas une "usine à gaz"

Je me demandais s'il n'y avait pas une manière plus simple de résoudre mon souci.

Je vais tout de même essayer avec une TA_calcul et voir ce que cela donne.

Bonne journée.

Gaston 

Partager ce message


Lien à poster
Partager sur d’autres sites
  • 0

Hi Gaston,

Il me semblait qu'il s'agissait de périodes de présence. On peut imaginer de créer un fiche par période (si pendant cette période le montant ne change pas !) J'ai opeur que le système "automatique" soit vraiment une usine à gaz effectivement. 

Bonne soirée

Gérard

Partager ce message


Lien à poster
Partager sur d’autres sites
  • 0

Bonjour Gérard

Cette nuit une idée m'est venue, et si j'essayais de résoudre cela en créant

  • une rubrique Date_décompte, qui serait la date de modification du tarif "Pecule_jour" et servirait de départ au nouveau décompte de jour
  • une rubrique Jour_décompte, qui serait alimentée par le nb de jour avant la modification
  • une rubrique Montant_pecule, qui serait alimentés par le montant du pécule avant le jour de modification du tarif "Pecule_jour"

et gérer tout cela au travers d'un script sur modification de la rubrique Tarif, cela éviterait de créer une TA supplémentaire, non?

Actuellement, j'ai une rubrique calcul "Nb_jours" dans la TA_séjour, et une rubrique nombre "Calcul_pecule" dans la TA_pecule. 

Un script qui part de la TA_contact et qui va sur la TA_pecule afficher les fiches du pécule du Contact, et calculer  le nb de jour, et le montant du pécule. Voir copie écran déjà donnée.

Je me dis que dans un script avec un déclencheur sur la rubrique Tarif, je devrais

  • définir une variable Date_décompte, qui me prenne la date de modification,
  • une variable Montant_pecule qui me prenne le résultat de Calcul_pecule avant la modification du Tarif
  • une variable qui prenne le nb de jour avant la modification du tarif
  • Ces variable servant à Définir les rubriques ci-dessus, et reprisent dans les différents calculs du nombre total de jour et du montant total du pécule.

L'objet de tout cela est que chaque fois que je vais dans la fiche de pécule du Contact, j'aie à l'écran le montant global du pécule et nombre de jour, le jour de la consultation des fiches Pécule de ce Contact .

Le changement de tarif n'est pas courant, il peut très bien ne pas varier durant plusieurs années.

Mon exposé n'est peut-être pas très clair, mais il montre l'état de ma réflexion, qui devrait encore être creusé et mieux spécifié, mais je ne désespère pas.

Je garde aussi l'idée de créer une fiche, mais cela suppose alors que je crée une TA_calcul, non?

Bonne fin de journée

 Gaston 

Partager ce message


Lien à poster
Partager sur d’autres sites
  • 0

Bonsoir Gaston,

Sur "le papier" la piste développée parait jouable. C'est difficile de voir tous les pièges a priori et l'intérêt c'est aussi de se faire plaisir avec nos hypothèses ;-)

Par ailleurs, il faut voir si la fréquence de modification est si faible....s'il faut investir beaucoup de temps à développer cette belle moulinette. Dans les solutions proposées par FM il y a un exemple "Factures" qui exploite la table intermédiaire, mais elle ne dispense pas d'appliquer les prix (et dans ton cas le montant du pécule) sur une "ligne", c'est à dire dans l'exemple sur une période donnée. Il y aura toujours une période avant et une après...

Mais d'autres  cadors forumiens ont sûrement plus de recul et d'expérience pour conseiller des amateurs comme nous ?

Bon courage ;-)

Gérard

Partager ce message


Lien à poster
Partager sur d’autres sites
  • 0

Bonjour Gaston,

Je réfléchis toujours à ton problème.

J'ai fait un essai d'un début de script sur la base d'ExecuterSQL qu'il faudrait adapter (remplacer débit par le nb de jours et les noms par ceux de ta base) et compléter (ajouter la contrainte de l'identifiant unique de la personne concernée, contrôler les dates pour qu'il n'y ait pas d'incohérence avant de poursuivre le script). Dans la construction de la variable $$total, il faudrait introduire le montant journalier "avant" et "après" ( Style : $$pecule_AV* Substituer(.....)).  On pourrait imaginer que la date intermédiaire (celle du script) serait stockée lors du changement de montant du pécule, et aussi d'envisager un contrôle qui déclencherait ou non le script s'il a eu, ou non, une modification du montant du pécule journalier.

La valeur de $$total peut être ensuite attribuée à une rubrique (en dur)

En bref, il y aurait encore un peu de travail pour utiliser ce principe. A ta disposition si besoin by mail ;-)

Bonne lecture

Gérard

Essai.pdf

Partager ce message


Lien à poster
Partager sur d’autres sites
  • 0

Bonsoir Gérard

Merci pour ton souci d'essayer de me proposer des solutions.

Je vais devoir me pencher sur ExecuterSQL, notion que j'ai pas vu jusqu'à maintenant, mais en voilà l'occasion. Ces prochains jours je vais être absents, plus tourné vers des activités festives. Donc je reprendrais cela dès mon retour, fin de semaine prochaine.

J'avais aussi pensé traiter ce problème comme pour une facture avec plusieurs lignes, facture que j'efface lorsque la personne part de la Communauté. 

Je te redirai alors où j'en suis.

Merci encore et bonne soirée.

Gaston 

Partager ce message


Lien à poster
Partager sur d’autres sites
  • 0

Bonsoir Gérard,

Après un long silence, partagé entre réflexions, essais divers, et voyages, je reviens te donner des nouvelles.

Je me trouvais en difficulté devant ta proposition de ExecuterSQL, je ne maîtrise ni l'anglais, ni ce genre d'instruction y relative.

J'ai donc opté pour l'utilisation d'une TA intermédiaire, TA_calcul_pecule_journalier, traitée comme une application de facturation, comme tu me le proposais plus haut.

Cela fonctionne, donc je suis satisfait.

Merci encore pour tes réflexions.

Belle fin de journée.

Avec mes cordiales salutations.

Gaston

Partager ce message


Lien à poster
Partager sur d’autres sites
  • 0

Hello Gaston,

 

Content de savoir que la suggestion ait été suivie de succès. Il est vrai que le SQL de FM est intéressant et parfois bien utile mais demande un apprentissage et une sacrée discipline.

Bien content de savoir que ça tourne alors bons calculs de pécule !

Cordialement

Gérard

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !


Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.


Connectez-vous maintenant

  • En ligne récemment   0 membre est en ligne

    Aucun utilisateur enregistré regarde cette page.