Discussion :

[Simplifi]

Bonjour à tous
Voilà, pour commencer, j'ai utilisé 1 à 1: une facture, un paiment simpliste
Ensuite j'ai eu un règlement partiel je suis donc passé de 1 à N: une facture pluseiurs paiments
(dans les cas de paiments groupés, j'éclatait le paiment en plusieurs)
Maintenant, je rencontre un client chez qui les paiments groupés sont la règle donc les éclatements de paiment deviennent fastidieux, je pourrais bien passer de N à 1 mais il peut rester des paiments fracturés
Je passe donc de N à N avec une table de jointure.
Mon souci vient simplement que dans mon shéma précédent 1 à N, je pouvais faire de la saisie semi-automatique qui était fort ergonomique: par exemple, dès que j'ai choisi quelle facture est payée, je propose que la date de paiment soit l'échéance de la facture, que le mopntant payé soit le montant de la facture, etc, ce qui dans 90% des cas est vrai.
Or, si je dois saisir complètement les caractéristiques du paiment avant de le mettre en relation avec la facture, je perds ces facilités.

Je serais donc heureux de vos expériences et conseils

[f-leb]

Bonjour Simplifi,

Une possibilité peut-être…

Tu conserves la structure actuelle qui convient dans la majorité des cas: ReglementPartiel-∞-------1-Facture

Tu rajoutes une table spécifique ReglementGroupe pour tes règlements groupés avec la structure :
ReglementGroupe-1-----∞-TblJonction-∞-------1-Facture.

Au niveau IHM, peut-être une bascule pour changer la source du sous-formulaire (ReglementPartiel ou TblJonction---ReglementGroupe).

Pour sortir avec une requête tous les règlements d’une facture il faudra jouer avec l’opérateur UNION.

Voilà l'idée…

[alassanediakite]

Salut
Je préfère la relation "ReglementGroupe-1-----∞-TblJonction-∞-------1-Facture" puisse qu'elle prend en compte l'autre, prend moins de place (date et idtiers dans une table pour plusieurs règlements).
J'avais un tel problème avec les remboursements de prêt: le client donne un montant::=(date, idclient, n°) et je le distribue sur les différentes échéances.

[Simplifi]

Salut f-leb, salut alassanediakite
Finalement, je suis arrivé à utiliser la relation Factures-1-----∞-TblFacture_payement-∞-------1-Paiements
Le plus gros problème est que quand on choisit une facture, qu'on précise son N° dans la table de jonction (par la relation père fils, la facture s'affiche dans le sous formulaire), on ne peut passer à la saisie du N° de paiement puisqu'il n'existe pas, et on ne peut passer à la création du paiement car la table de jonction avec son index double n'accepte pas de vide.
En attendant, j'attribue donc le paiement 0 zéro puis lorsque le paiement est rempli (avec par défaut les données de la facture, qu'on peut bien sûr écraser) je modifie l'enregistrement de la table de jonction.
Enfin, pour éviter des erreurs d'update (un peu incongrues) j'ai supprimé les relations père-fils avec le sous formulaire des paiements mais je l'ai remplacé par un petit bouton qui affiche le paiement surabondant en cas de nécessité

Enfin, pour la consultation d'enregistrements déjà complets, je rétabli les relations père-fils par VB lors de l'appel

[f-leb]

Re,

je n’ai pas ton formulaire sous les yeux mais je suis surpris par :

Le plus gros problème est que quand on choisit une facture, qu'on précise son N° dans la table de jonction (par la relation père fils, la facture s'affiche dans le sous formulaire), on ne peut passer à la saisie du N° de paiement puisqu'il n'existe pas, et on ne peut passer à la création du paiement car la table de jonction avec son index double n'accepte pas de vide.

Je suppose que la source du sous formulaire est une requête sur les deux tables: TblFacture_payement-∞------1-Paiements.

Si la clé Paiement.idPaiement est un NuméroAuto et que le sous formulaire comporte (entre autres) le champ Paiements.MontantPaiement, lors de la saisie du montant le numéroAuto va se remplir tout seul et cela va créer d’un coup un nouveau paiement et la ligne correspondante dans la table de jonction, non ?

Aurais-je loupé un truc ?