Discussion :

[Malick]

pyloupylou,

Merci pour ces corrections.

Voici le modèle corrigé :



D'autres remarques ?

[pyloupylou]

non

y'a plu ka, il a bien évolué ce modèle depuis le premier jet...

[Malick]

@ pyloupylou : un très grand merci à toi.

Tout cela a été très riche en expérience pour moi.

[Malick]

Au niveau de ma table tFactures, j'ai mis le champ IdFactures_PK comme clé primaire en Numérique ; est-ce préférable de le mettre en numéroauto ?

Ou bien devrais-je le laisser en numérique, d'autant plus que j'ai le champ RefFacture que je voudrais mettre sous la forme (------/----) soit Idfacture/Année

[pyloupylou]

bonne année malik,

Au niveau de ma table tFactures, j'ai mis le champ IdFactures_PK comme clé primaire en Numérique ; est-ce préférable de le mettre en numéroauto ?

je la laisserai en numéro auto, et considère que c'est une clé technique

Ou bien devrais-je le laisser en numérique, d'autant plus que j'ai le champ RefFacture que je voudrais mettre sous la forme (------/----) soit Idfacture/Année

pour le champ ref facture, tu devrais voir avec tes utilisateurs ( ou futurs ) ce qu'il souhaitent, un numéro de facture sert souvent à faire des rapprochement notamment avec les règlements et ... la compta, mais ce qui est clair c'est qu'il faudra un dispositif pour la rendre unique, séquentielle et sans trous ( donc à gérer manuellement ) lors de l'émission de cette dernière.
N'oublie pas une chose, c'est d'offrir la possibilité à l'utilisateur de travailler comme il le souhaite, exemple commencer une facture, avoir la possibilité de suspendre sa saisie et revenir le lendemain dessus pour l'emission

[Malick]

Merci. Bonne et heureuse année à toi aussi.

je la laisserai en numéro auto, et considère que c'est une clé technique

Bien noté.

pour le champ ref facture, tu devrais voir avec tes utilisateurs ( ou futurs ) ce qu'il souhaitent, un numéro de facture sert souvent à faire des rapprochement notamment avec les règlements

Effectivement et aujourd'hui, ce qui est utilisé c'est le format que j'ai donné et que je souhaiterais reproduire si possible à savoir le numéro de la facture combiné à l'année (exemple : 099/2014 au 31/12/2014). Chaque année, la numérotation recommence à 1 (exemple : 001/2015 au 01/01/2015). C'est faisable ?

[pyloupylou]

oui, tout est faisable.... ( c'est juste une question de temps )
ton application va être en multi utilisateur ? si oui fais attention aux opérations de réservation de numéros, tu table de séquence sera peut être nécessaire

[Malick]

oui, tout est faisable.... ( c'est juste une question de temps )

Cela me rassure. Merci beaucoup.

ton application va être en multi utilisateur ?

Non, elle sera gérée par une seule personne.

[pyloupylou]

Non, elle sera gérée par une seule personne.

je te conseille quand même de prévoir une architecture de type dorsale frontale ( qui peut le plus peut le moins ), ne serait ce que pour un aspect sécurité des données

[Malick]

je te conseille quand même de prévoir une architecture de type dorsale frontale

Entendu.

Et pour cela, il y a des choses à prévoir sur le modèle pour que je puisse les intégrer tout de suite ?

Ou bien devrais-je attendre la finalisation de l'application pour procéder au fractionnement en frontale et dorsale ?

[pyloupylou]

rien de particulier, mais plutôt prévois dès le départ la segmentation, comme cela tu pourras jouer entre les éventuelles tables de travail (temporaires sur la frontale ) et tes tables définitives sur la dorsale

[Malick]

beaucoup.

Je prends bonne note.

@+

[jimbolion]

Cher tous,

En lisant (peut être en diagonale) le modèle me semble effectivement tenir la route :

quelques suggestions :

1. Le modèle suppose que plusieurs factures puisse faire l'oeuvre d'un seul règlement (peut t'il y avoir plusieurs règlements pour la même facture). Souvent il est de mise de fournir un règlement en plusieurs fois (chèque initial et chèques à encaissements différés voire possibilités multi-règlements : espèces + chèque). Dans ce cas le modèle ne tiendrai pas la route.

2.Le taux de TVA en vigueur (ne serait t'il pas judicieux de mettre une date début et fin) afin d'affecter par défaut le taux de tva lors de la génération des écritures de détail factures.

3.Intérêt de redonder le totalTTC dans t_factures (cela peut être utile pour optimiser le travail sur requête je l'accorde plutôt que des sum). Mais l'information TVA + HT est ce utile ? et puis totalHT + tva induisent également le prix TTC ??

4. Pour les périodes (teffectuer) et la jonction avec tperiode ? je ne comprends pas l'intérêt (sauf à agréger les données de tauditeurs + tsuivisevolution) mais j'ai dû omettre quelque chose ?

@++
jimmy

[pyloupylou]

Maître Jimmy, Meilleurs Voeux,

je ne vois pas ce qui te gène :

1. Le modèle suppose que plusieurs factures puisse faire l'oeuvre d'un seul règlement (peut t'il y avoir plusieurs règlements pour la même facture). Souvent il est de mise de fournir un règlement en plusieurs fois (chèque initial et chèques à encaissements différés voire possibilités multi-règlements : espèces + chèque). Dans ce cas le modèle ne tiendrai pas la route.

le fait de passer par une table de jointure entre tfactures et treglement , et uniquement basée sur des clés purement technique techniques, justement autorise soit d'avoir :
- 1 reglement pour une facture
- 1 reglement pour n factures
- n reglement pour 1 facture

sinon

2.Le taux de TVA en vigueur (ne serait t'il pas judicieux de mettre une date début et fin) afin d'affecter par défaut le taux de tva lors de la génération des écritures de détail factures.

C'est vrai, que si on veut être complétement carré, il faudrait avoir au moins une date de début en cle, mais cela risque de complexifier un peu plus les écrans

3.Intérêt de redonder le totalTTC dans t_factures (cela peut être utile pour optimiser le travail sur requête je l'accorde plutôt que des sum). Mais l'information TVA + HT est ce utile ? et puis totalHT + tva induisent également le prix TTC ??

Oui c'est vrai, que l'on peut toujours re déterminer ce total TTC, mais à l'usage, le fait de disposer directement de l'information va faciliter les restitutions, pour le CA on manipule toujours le ht, en revanche pour la compta, c'est la tva et le ttc

4. Pour les périodes (teffectuer) et la jonction avec tperiode ? je ne comprends pas l'intérêt (sauf à agréger les données de tauditeurs + tsuivisevolution) mais j'ai dû omettre quelque chose ?

la table teffectuer va servir notamment à calculer les taux de staffing. Sinon pour la tperiode, c'est en effet une table que l'on pourrait ignorer, qui n'a un intérêt qu'au niveau conceptuel, pour ensuite faire migrer les clefs mois et année ( ce qui n'est pas franchement traduit dans le modèle d'ailleurs ), Malik et moi avons échangé là dessus, et il préfère conserver cette notion.

A bientôt...

[jimbolion]

pyloupylou,

meilleurs vœux également (même si j'ai du les honorer dans un autre fil de discussion )

oups effectivement la table tfacturesreglements agit comme table de jonction (comment ai-je pu passer à côté). Va falloir que je consulte mon opticien préféré moi

donc pour le reste c'est ok! le modèle évoluera quelque peu lors de la phase de développement mais les axes sont correctement identifiés, pour moi c'est abouti

@++