Discussion :

[pyloupylou]

pour détail factures à toi de voir, si vous ne faites jamais de prestations en régie.

Le numéro de ligne peux te permettre 2 choses -
1 constituer avec le numero de facture une clef unique,
2 offrir la possibilité à l'utilisateur de pouvoir jouer sur l'ordre d'apparition des lignes ( éventuellement positionner des lignes vierges )

[Malick]

Suite à tes différentes remarques et suggestions, voici :



Est-ce que j'ai bien appliqué tes pertinentes remarques et suggestions ?

Merci d'avance

[pyloupylou]

Joyeux noël à tous,

- Une information qui peut être utile à ajouter au niveau de la facture, le type: soit une facture (le cas le plus général), soit un avoir ( tu peux le déterminer automatiquement en fonction du sens du montant de la facture soit positif soit négatif ),
- par ailleurs l'état de la facture, soit en cours soit émis ( cela peut te permettre, à partir du moment ou une facture est émise, de ne plus revenir sur la référence, ni sur les montants ) pense d'ailleurs à voir comment tu vas la structurer ta référence ( un truc à prévoir, pas de trous dans la référence, en général les commissaires aux comptes n'aiment pas trop ...)
- par ailleurs l'information si la facture est soldée peut être intéressante ( têtu pylou )

[Malick]

Joyeux noël à toutes et à tous

Une information qui peut être utile à ajouter au niveau de la facture, le type: soit une facture (le cas le plus général), soit un avoir ( tu peux le déterminer automatiquement en fonction du sens du montant de la facture soit positif soit négatif ),

Dans ce cas, je vais créer une table supplémentaire tTypeFactures avec comme champs (Id_TypeFacture, TypeFacture). Le type de factures peut être soit une facture de doit (le cas le plus général) soit une facture d'avoir (montant qui sera enregistré en négatif).
Qu'en penses-tu ?

par ailleurs l'état de la facture, soit en cours soit émis ( cela peut te permettre, à partir du moment ou une facture est émise, de ne plus revenir sur la référence, ni sur les montants )

Bonne idée

pense d'ailleurs à voir comment tu vas la structurer ta référence ( un truc à prévoir, pas de trous dans la référence, en général les commissaires aux comptes n'aiment pas trop ...)

Pour la référence, je voudrais l'associer à l'id de la facture (qui est de type numéroauto) suivi de l'année ; quelque chose comme ---/---- exemple 001/2014.
Est-ce possible ?

par ailleurs l'information si la facture est soldée peut être intéressante

je pense que ce dernier point est pris en compte avec la création du champ "Soldee" qui est de type Oui/Non au niveau de la table tFactures.

[pyloupylou]

à partir du moment ou le type de facture n'aura que 2 valeurs, pas sûr qu'une table soit nécessaire, ce serait simplement une règle de gestion, surtout que tu vas pouvoir définir sa valeur automatiquement en fonction du sens du montant,

pour la référence de la facture, tu ne peux, à mon avis la construire à partir du numéro auto, car du coup tu pourrais avoir des trous, justement ce qui est à éviter.
Une solution alternative serait de prévoir une référence temporaire, tant que la facture n'est pas émise, et figer la référence 'de manière officielle' lorsque tu émets la facture et du coup t'appuyer sur un dispositif qui te détermine le numéro à prendre par rapport à la dernière facture émise

[Malick]

à partir du moment ou le type de facture n'aura que 2 valeurs, pas sûr qu'une table soit nécessaire, ce serait simplement une règle de gestion, surtout que tu vas pouvoir définir sa valeur automatiquement en fonction du sens du montant,

Ok pour ce point. Toutefois, pour déterminer automatiquement le type en fonction du sens du montant, j'imagine que cela se fera durant la phase de développement ? Je n'ai pas encore d'idée sur comment le faire.

Une solution alternative serait de prévoir une référence temporaire, tant que la facture n'est pas émise, et figer la référence 'de manière officielle' lorsque tu émets la facture et du coup t'appuyer sur un dispositif qui te détermine le numéro à prendre par rapport à la dernière facture émise

Est-ce que cela demande une modification du champ référence de ma table tFactures ? ou bien je dois ajouter un autre champ referencetemporaire ?

[pyloupylou]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Est-ce que cela demande une modification du champ référence de ma table tFactures ? ou bien je dois ajouter un autre champ referencetemporaire ?

bah, non, fonctionnellement c'est la même information

Ok pour ce point. Toutefois, pour déterminer automatiquement le type en fonction du sens du montant, j'imagine que cela se fera durant la phase de développement ? Je n'ai pas encore d'idée sur comment le faire.

toi un expert, tu ne crois pas qu'un truc dans le me.beforeupdate du style me.type=iif(total >= 0,"facture","Avoir"), ça le ferait pas ? , ou encore plus sioux directement au niveau de la base de données sous forme de champ calculé

[Malick]

un truc dans le me.beforeupdate du style me.type=iif(total >= 0,"facture","Avoir"), ça le ferait pas ? , ou encore plus sioux directement au niveau de la base de données sous forme de champ calculé

Super.

Est-ce que je peux considérer que le modèle est bon à l'instant t ?



Si j'ai ton accord, je passerais à la création de la table tReglement afin de suivre les encaissements et pouvoir connaître le niveau des créances après lettrage des factures réglées avec leurs règlements.

[pyloupylou]

t'as pas besoin de mon accord, je ne te donne qu'un avis....

Ah si, intégrité référentielle entre factures et détail factures, et suppression en cascade sinon ça risque d'être un peu galère....

[Malick]

t'as pas besoin de mon accord, je ne te donne qu'un avis....

Ah si, intégrité référentielle entre factures et détail factures, et suppression en cascade sinon ça risque d'être un peu galère....

La création de l'intégrité référentielle entre Factures et DétailFactures ne marche pas. En effet, j'ai le message d'erreur ci-après :



Une idée sur le pourquoi ça ne marche pas ?

[pyloupylou]

bien le bonjour Mr Malik,

bah si tu mets deux champs en clef dans table principale, c'est normal que tu ne puisses pas relier ta table détail si tu n'as qu'un élément de la clef....

[Malick]

Après correction, voici :

• La table DetailFacture a trois clé primaire.
  
• La table Facture a une seule clé.

Est-ce correct pour toi ?

[pyloupylou]

je vois que tu as ajouté la cle de mission dans détail facture ?
bah si tu l'ajoutes tu dois pouvoir remettre l'integrité référentielle sur les deux champs ? non ?

sinon tu regarderas dans les contributions, j'ai ajouté un truc qui pourra peut être, t'être utile

[Malick]

=pyloupylou;8078291]je vois que tu as ajouté la cle de mission dans détail facture ?
bah si tu l'ajoutes tu dois pouvoir remettre l'integrité référentielle sur les deux champs ? non ?

Effectivement et maintenant l'intégrité référentielle est appliquée entre les deux tables sur le champ idFacture.

sinon tu regarderas dans les contributions, j'ai ajouté un truc qui pourra peut être, t'être utile

Merci pour cette contribution ; j'avais déjà commencé à le regarder

Maintenant je pense que je peux procéder à la création de la table tReglement. Sauf si tu as d'autres avis à faire avant.

[Malick]

Ci-après le modèle prenant en compte les règlements.

Seul souci : il est possible qu'un règlement concerne plusieurs factures et j'hésite sur la façon d'intégrer cela dans mes tables.

une idée ?

[pyloupylou]

Bien le bonjour,

pour ma part, je ne peux que te répéter ce que j'ai dit précédement

si tu prévois une table règlement, ce que je pressens, c'est une table par clients et un numéro de pièce, le type (chèque avis de banque), la référence, le montant
et une table de liaison vers tes factures, cela sera ensuite plus simple pour lettrer tes règlements vers les factures et ensuite pour tirer tes balances de factures ( tu te rappelles, je te disais que tu auras souvent correspondance mais pas toujours, soit plus ou moins de ce qui est rêglé par rapport à ce qui est dû )

[Malick]

pyloupylou,

ce que je pressens, c'est une table par clients

Merci pour cet avis.

Est-ce que cela ne risque pas d'être fastidieux de créer pour chaque client une table règlement ? Aussi chaque année il peut y avoir de nouveaux clients.

[pyloupylou]

Est-ce que cela ne risque pas d'être fastidieux de créer pour chaque client une table règlement ?

ah si c'est sûr,

quand je disais une table par client, c'était une table avec un identifiant de règlement, toutes tes informations que tu citais, et une référence vers le client, pour s'y retrouver plus facilement
et comme je te disais une table intermédiaire reprenant l'identifiant de la facture et l'identifiant du règlement
avec l'information facture soldée au niveau de la facture, tu devrais pouvoir gérer tous les cas de figures

[Malick]

Merci beaucoup pyloupylou.

Après corrections, voici le modèle :



Qu'en penses-tu maintenant ?

[pyloupylou]

dans ta table règlement tu n'as pas besoin de la référence à la facture , tu l'as dans ta table de liaison
de même dans la table de liaison tu as dupliqué facture soldée alors que tu l'as déjà dans ta table facture