Discussion :

[Malick]

Bonjour,

Je souhaiterais mettre en place une base de données pour le suivi de la facturation de notre structure.

Merci de bien vouloir me donner vos avis par rapport à mon MCD ci-après :

[pyloupylou]

Bonjour,

quelques remarques en vrac,

1/ c'est juste pour un suivi de facturation et pas de commande et facturation ?

2/ en terme de facturation ou de commande, personnellement j'aime bien avoir des notions d'entête de commande et des lignes de commandes tout comme un entête de facture et des lignes de factures, cela me permet être plus fin au niveau des relation avec par exemple : 1 commande pour 1 client mais cette commande a plusieurs interventions

3/ par ailleurs, essayez de lier une facture à un règlement, tu ne risuqe que de couvrir partiellement le problème, (je parle d'expérience) en effet, tu va rencontrer souvent des cas où tu n'as pas de correspondances entre la facture émise et le règlement, exemple tu émets et tu recois autre chose, soit parce que c'est anticipé , soit le règlement est incomplet ...ou encore un règlement couvre plusieurs factures etc.
je prévoirai plutôt de distinguer les deux ensembles factures et règlement et de positionner une entité intermédiaire qui te permettent de faire du lettrage entre les deux, derrière c'est plus un besoin de faire une balance entre les travaux facturés et les règlements reçus

bon j'arrête sinon tu vas me haïr (), mais tout ça c'est parce que j'ai beaucoup souffert avec des comptables.....

[Malick]

Bonjour pyloupylou,

Merci beaucoup pour cette intervention.

Pour répondre à vos interrogations :

1/ c'est juste pour un suivi de facturation et pas de commande et facturation ?

Oui, c'est juste pour un suivi des prestations facturées, réglées et non réglées. En fait, c'est un cabinet d'audit et chaque année, on effectue des missions d'audit pour le compte de nos clients.
Au terme de la modélisation et de la conception, je voudrais pouvoir éditer directement les factures à partir de l'outil qui sera mis en place.

2/ en terme de facturation ou de commande, personnellement j'aime bien avoir des notions d'entête de commande et des lignes de commandes tout comme un entête de facture et des lignes de factures, cela me permet être plus fin au niveau des relations avec par exemple : 1 commande pour 1 client mais cette commande a plusieurs interventions

Pour ce point, peut-être que je devrais intégrer le champ "DescriptionMissions" dans la table T_Facture.
Qu'en penses-tu ?

3/ par ailleurs, essayez de lier une facture à un règlement, tu ne risuqe que de couvrir partiellement le problème;;;

Dans le modèle que je propose, je pense que j'ai pris en compte le fait qu'une facture pourrait faire l'objet de plusieurs règlements.
Penses-tu qu'il manque quelque chose

[pyloupylou]

intéressant comme sujet

à mon avis tu risques de t'apercevoir que sera nécessaire une gestion des personnes qui interviennent, ainsi que des taux d'interventions, en effet même sur des interventions au forfait, le TJM reste roi
Par ailleurs, si on veut ensuite analyser une rentabilité, le besoin de savoir le nombre de jours qui était initialement prévu et le coût de production (surtout s'il y a des prestataires externes) reste indispensable .... mais je m'éloigne des questions de bases.

bon je suis un peu têtu, à propos des factures je reste persuadé que tu as besoin de 2 niveaux - une entête de facture et des lignes détails ( n'oublie pas le cas des frais qui sont éventuellement à refacturer ), donc une nature de facturation peut également être nécessaire ( j'ai en tête les problématiques d'interprétation comptable).

En fait au point 2 de mon premier message, quand je parlais de plusieurs interventions il faut voir ça avec un ou plusieurs intervenants....sinon oui il te faut une description de mission, mais j'irais même plus loin, sur une prestation au forfait ( par exemple) tu risque d'avoir une notion de tâches qui vont être facturées à des moments différents, où sur des livrables précis et tu devras pouvoir indiquer exactement ce que tu factures

bon tel le joueur de ping pong moyen () je renvoie la balle ( pour faire évoluer le sujet)

A+

[Malick]

à mon avis tu risque de voir nécessaire une gestion des personnes qui interviennent, ainsi que des taux d'interventions, en effet même sur des interventions au forfait, le TJM reste roi

Pour le point ci-dessus, j'ai un projet en tête qui sera beaucoup plus large. Ce dernier va gérer tous les aspects relatifs aux missions (durée, intervenants, facturation, rentabilité, etc.).
Pour ce cas-ci, c'est juste un outil simple que je souhaite mettre à la disposition de la secrétaire pour mieux suivre la facturation, les créances et dettes du cabinet. Aujourd'hui, elle utilise un registre pour faire ce suivi et je trouve cela pas très pratique.

à propos des factures je reste persuadé que tu as besoin de 2 niveaux - une entête de facture et des lignes détails

Pourrais-tu me proposer quelque chose par rapport à cela ?

[Malick]

Bonjour Claude,

Merci pour cette réponse et cet intérêt à l'endroit de mon projet.

Dans un premier temps, j’envisagerais de se concentrer d’abord sur le « Quoi facturer », c’est-à-dire ce qui compose un audit pour un client

En fait, c'est un cabinet d'audit et d'expertise comptable. Chaque année, nous effectuons des missions d'audit (exemple : commissariat aux comptes, audit fiscal, audit contractuel, audit social, audit d'investigation, etc.) pour le compte de nos clients. Ce sont ces différentes missions ou prestations que nous facturons aux clients.

2e temps : quand tAudits est complétée, mettre à point un formulaire pour élaborer la facturation
alimenter une table tFactures

La table T_Factures déjà créée ne fait-elle pas l'affaire ? Il manque des choses ?

3e temps : élaborer un système pour le suivi des paiements du client, la rentabilité de la mission…

Super ça.

Bonjour Malick,
À la lecture de ton premier poste, j’avais commencé à réfléchir et je comptais poster ce qui suit :

Dans un premier temps, j’envisagerais de se concentrer d’abord sur le « Quoi facturer », c’est-à-dire ce qui compose un audit pour un client




2e temps : quand tAudits est complétée, mettre à point un formulaire pour élaborer la facturation
alimenter une table tFactures
3e temps : élaborer un système pour le suivi des paiements du client, la rentabilité de la mission…

La table T_Factures déjà créée ne fait-elle pas l'affaire ?

[Malick]

Voici le modèle corrigé :



Informations

Sur une mission d'audit, on peut avoir un ou plusieurs auditeurs.

Chaque auditeur a un grade qui peut évoluer d'année en année (assistant débutant, auditeur confirmé, chef de mission audit, superviseur, manager, associé).

Il un y un barème de facturation en fonction du grade des auditeurs intervenant dans une mission, mais la plupart du temps la facturation se fait sur la base d'un forfait préalablement discuté et validé avec le client. Donc ce n'est pas les mêmes honoraires pour tous les clients.
Est-ce que la table tTarif permettra le suivi des forfaits ?

Je pense qu'il faudra que je crée une table tGrade, de façon à pouvoir garder un historique des missions et des grades de chaque intervenant au moment de la réalisation de la mission.

Qu'en pensez-vous ?

[pyloupylou]

bonjour Milkoseck,

Intéressant, mais ça me rappelle quelque chose, on retombe sur une notion de commande, qui va faire intervenir n intervenants à des taux prédéfinis

Sinon pour le suivi des évolution de grade, j'avais géré le problème avec:
une table employé ( id_employe (autonumber) , nom, prenom )
une table suivi d’évolution ( id_evolution (autonumber) , id_employe, id_grade , date_deb, date fin )
une table grade ( id_grade (auto number) , grade , tarif theorique )

Le tarif théorique permet ensuite une analyse de rentabilité entre le prix négocié avec le client et le tarif théorique du grade

[Marcello5255]

Je suis la discussion avec intérêt.
J'attirerais bien l'attention de Milkoseck sur trois points.

1. Je ne mettrais pas une clé primaire sur le numéro de facture, mais sur un identifiant de type numérauto.
2. Je nommerais toujours une clé primaire et une clé secondaire de la même façon: id..... pour une clé primaire et RF....... pour une clé secondaire par exemple. Ou comme Claude Leloup: .........PK pour une clé primaire et .............FK pour une clé secondaire.

Clé primaire de type numérauto (automatiquement entier long)
Clé secondaire de type numérique entier long.

Au terme de la modélisation et de la conception, je voudrais pouvoir éditer directement les factures à partir de l'outil qui sera mis en place.

3. S'il existe l'hypothèse d'émettre des factures de vente, d'entrée, d'autres pièces comme les opérations diverses, la saisie des financiers, il faudra travailler avec des formulaires et sous-formulaires, comme l'envisage Pyloupylou.

Pour ce dernier point, le bon fonctionnement de l'intégrité référentielle et suppression en cascade sera appuyé sur les deux premiers.

Je laisse maintenant intervenir les Pros.

[Malick]

bonjour Milkoseck,

Intéressant, mais ça me rappelle quelque chose, on retombe sur une notion de commande, qui va faire intervenir n intervenants à des taux prédéfinis

Sinon pour le suivi des évolution de grade, j'avais géré le problème avec:
une table employé ( id_employe (autonumber) , nom, prenom )
une table suivi d’évolution ( id_evolution (autonumber) , id_employe, id_grade , date_deb, date fin )
une table grade ( id_grade (auto number) , grade , tarif theorique )

Le tarif théorique permet ensuite une analyse de rentabilité entre le prix négocié avec le client et le tarif théorique du grade

Bonjour Pyloupylou,
Merci pour cette proposition relative à l'évolution des grades pour chaque employé. Je vais l'intégrer au modèle proposé par ClaudeLELOUP . Après cela, je posterai le modèle mis à jour.

Je suis la discussion avec intérêt.
J'attirerais bien l'attention de Milkoseck sur trois points.

1. Je ne mettrais pas une clé primaire sur le numéro de facture, mais sur un identifiant de type numérauto.
2. Je nommerais toujours une clé primaire et une clé secondaire de la même façon: id..... pour une clé primaire et RF....... pour une clé secondaire par exemple. Ou comme Claude Leloup: .........PK pour une clé primaire et .............FK pour une clé secondaire.

Clé primaire de type numérauto (automatiquement entier long)
Clé secondaire de type numérique entier long.


3. S'il existe l'hypothèse d'émettre des factures de vente, d'entrée, d'autres pièces comme les opérations diverses, la saisie des financiers, il faudra travailler avec des formulaires et sous-formulaires, comme l'envisage Pyloupylou.

Pour ce dernier point, le bon fonctionnement de l'intégrité référentielle et suppression en cascade sera appuyé sur les deux premiers.

Je laisse maintenant intervenir les Pros.

Bonjour Marcello5255,
Merci pour ces pertinentes remarques. Je vais aussi les intégrer dans le modèle que je posterai.

[Malick]

Bonsoir tout le monde,

Suite à vos différentes remarques, voici le modèle après mise à jour :




Qu'en pensez-vous ?

[pyloupylou]

Je vois que tu as une seule adresse pour un client, peut être serait-il judicieux de prévoir n adresses pour un client

[Malick]

Je vois que tu as une seule adresse pour un client, peut être serait-il judicieux de prévoir n adresses pour un client

J'imagine que c'est pour les éventuels changements de siège social. N'est-ce pas ?

[pyloupylou]

Pas forcément, c'est surtout pour permettre à ton modèle d'évoluer plus facilement et fonctionnellement tu peux être face à une entité cliente, qui va avoir une ou plusieurs adresses de siège, et 1 ou plusieurs adresses de facturation possible en fonction du lieu d'intervention.
Le généraliser dès le départ peut te permettre d'avoir une seule entité adresse et une seule interface, ensuite c'est simplement un rattachement a effectuer vers les entités concernées

[Malick]

Pas forcément, c'est surtout pour permettre à ton modèle d'évoluer plus facilement et fonctionnellement tu peux être face à une entité cliente, qui va avoir une ou plusieurs adresses de siège, et 1 ou plusieurs adresses de facturation possible en fonction du lieu d'intervention.
Le généraliser dès le départ peut te permettre d'avoir une seule entité adresse et une seule interface, ensuite c'est simplement un rattachement a effectuer vers les entités concernées

Comment pourrais-je intégrer cette possibilité dans le modèle que j'ai mis à jour (une idée) ?

[minot83]

Salut, je te le dépose ici, comme cela on peut en parler à plusieurs
j'ai pas tout repris, juste pour l'idée principale déjà

[Malick]

Salut, je te le dépose ici, comme cela on peut en parler à plusieurs
j'ai pas tout repris, juste pour l'idée principale déjà

Merci minot83 pour cette remarque et proposition.

Voici le modèle actualisé :

[pyloupylou]

hello,

petit exercice: je repars de ton modèle et te décris ce que je comprend:

- tu as un client
- un client n'a qu'une seule adresse ()
- ce client commande des audits
- un audit a un responsable de mission ( référence à auditeur )
- un audit fait intervenir n intervenants qui interviennent sur différentes missions
- chaque mission est facturée à un prix standard
- a chaque prix est attaché une description
- pour chaque intervenant à un grade pour une fourchette de dates données
- chaque grade est facturé à un coût standard

bon maintenant quelques questions ( plutôt des pistes de réflexions...) :
- à quoi te sers la référence à la mission dans t_audits ?
- il n'y a pas de notion de localisation de la mission ( ou de l'audit ) mais peut être ce n'est pas nécessaire
- plus gênant pas de notion de date, du coup pour déterminer quel taux d'intervenants à appliquer, difficile
- le modèle traduit la facturation de la mission à un tarif standard, mais qu'en est-il du prix réellement facturé ( j'imagine qu'il va être spécifique à chaque client ) mais alors peut-il être le même pour plusieurs missions ( j'ai un doute sur ce que je comprends du modèle )
- comment vont être facturés les frais, la tva ?

bon j'arrête avant

A+

[Malick]

Je vous explique un peu l'activité que je veux gérer.

Nous avons un cabinet d'audit et d'expertise comptable et nous avons un portefeuille de clients.

Pour un client, nous effectuons chaque année, en fonction de la durée du contrat qui nous lie, des missions d'audit.

Ces missions peuvent être de différents types à savoir :

• un audit légal ou commissariat aux comptes (c'est le plus fréquent) ;
• un audit d'investigation ;
• un audit fiscal ;
• un audit d'acquisition ;
• etc.

Chaque mission chez un client fait intervenir un ou plusieurs auditeurs avec des grades différents (manager, chef de mission, auditeur confirmé, auditeur débutant).

Le grade d'un auditeur peut évoluer d'une année à l'autre suite aux différentes évaluations.

Sur chaque contrat est défini le montant hors taxe des honoraires à facturer à la fin de chaque mission pour une année donnée, la TVA 18 % et le montant TTC ; tout cela pendant toute la durée du contrat.

Une facture d'acompte de démarrage est remise au client, la facture pour solder le reliquat sera transmise au client à l'émission du rapport.

Cependant, il existe un barème définissant le tarif à appliquer en fonction des grades et par heure de présence chez le client (ce qui fait intervenir la notion de durée que pyloupylou a signalée dans son dernier post ). La prise en compte de cet aspect devrait permettre de faire des analyses de rentabilité.

J'espère que le process que je viens de décrire est un peu clair.

Voici une proposition de modèle après prise en compte des remarques :



J'ai aussi un problème sur la façon d'intégrer la détermination du nombre d'heures de présence de chaque collaborateur dans une mission. Une idée ?

[pyloupylou]

Bien le bonjour Milko,

Ton modèle s'affine

et KADO de noël, j'ai fait un exercice, j'aime bien la modélisation Merise (c'est ça les vieux singes ) mais je trouve que cela permet de bien poser les règles de gestion

Le mcd traduisant ton modèle pourrait se représenter comme ça :


ça donne en modèle physique, ce qui se rapproche de ta modélisation avec access


Sans vouloir pinailler (), en regardant ta description tu indiques

Chaque mission chez un client ....

alors ce n'est peut être qu'une question de dialectique mais du coup j'ai l'impression que le client est rattaché non pas au type d'audit ( d'ailleurs est ce véritablement la dénomination adaptée ? ) mais à la mission

en modifiant le modèle j'arrive à ça


En passant j'ai intégré le suivi des temps réalisés , et prévus ce qui donne au niveau physique


Si t'es pas franchement à l'aise avec la lecture de Merise, y a un bon tuto sur le site

Il ne me reste qu'à souhaiter de très bonnes fêtes à tout le monde