:salut: pyloupylou,
Merci pour ces corrections.
Voici le modèle corrigé :
Pièce jointe 164871
:fleche: D'autres remarques ?
Version imprimable
:salut: pyloupylou,
Merci pour ces corrections.
Voici le modèle corrigé :
Pièce jointe 164871
:fleche: D'autres remarques ?
non :king:
y'a plu ka, il a bien évolué ce modèle depuis le premier jet...:mouarf:
@ pyloupylou : un très grand merci à toi.:king:
Tout cela a été très riche en expérience pour moi.
:merci::merci:
:salut:
:fleche: 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 ?
:fleche: 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
bonne année malik,
je la laisserai en numéro auto, et considère que c'est une clé techniqueCitation:
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 ?
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.Citation:
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
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
Merci. Bonne et heureuse année à toi aussi.
Bien noté.Citation:
je la laisserai en numéro auto, et considère que c'est une clé technique
:fleche: 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 ?Citation:
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
oui, tout est faisable.... ( c'est juste une question de temps :mouarf:)
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
Cela me rassure. Merci beaucoup.Citation:
oui, tout est faisable.... ( c'est juste une question de temps )
Non, elle sera gérée par une seule personne. ;)Citation:
ton application va être en multi utilisateur ?
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éesCitation:
Non, elle sera gérée par une seule personne.
Entendu.Citation:
je te conseille quand même de prévoir une architecture de type dorsale frontale
:fleche: Et pour cela, il y a des choses à prévoir sur le modèle pour que je puisse les intégrer tout de suite ?
:fleche: Ou bien devrais-je attendre la finalisation de l'application pour procéder au fractionnement en frontale et dorsale ?
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
:merci: beaucoup.
Je prends bonne note.
@+
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
Maître Jimmy, Meilleurs Voeux,
je ne vois pas ce qui te gène ::aie:
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 :Citation:
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.
- 1 reglement pour une facture
- 1 reglement pour n factures
- n reglement pour 1 facture
sinon
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 écransCitation:
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.
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 ttcCitation:
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 ??
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.Citation:
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 ?
A bientôt... :mouarf:
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 :mouarf:
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 ;)
@++