Discussion :

[haich]

Bonsoir a tous,

Je viens vous demander conseil car je n arrive pas à modeliser la TVA

voici les règles :
R01: chaque pays peut avoir plusieur taux de tva
R02: a chaque produit un taux de tva est appliqué
R03: la tva appliqué a ce produit depend de son lieux de livraison.


merci

[escartefigue]

Bonjour,

Le taux applicable pour un code TVA et un code pays, dépend de la date.
Il faut donc modéliser une entité-type pays, une entité-type date, une entité-type TVA, et une relation entre les 3 entités-type porteuse de l'attribut "taux"

Vous considérez que facture et livraison ne font qu'un, c'est possible mais très restrictif, Est-ce volontaire ?
De plus, je ne vois pas d'entité-type commande qui, classiquement fait le lien entre un client et les produits, via des lignes de commande...

[haich]

Bonjour,

tout d abord merci de vous intéresser à mon problème.

Le taux applicable pour un code TVA et un code pays, dépend de la date.
Il faut donc modéliser une entité-type pays, une entité-type date, une entité-type TVA, et une relation entre les 3 entités-type porteuse de l'attribut "taux"

Représenté par l'entité type TVA dans mon mcd

Vous considérez que facture et livraison ne font qu'un, c'est possible mais très restrictif, Est-ce volontaire ?

Non, la partie du mcd ne représente que la partie de mon problème. Les relation représenter par les relations entre l'entité type Facture et l'entité type Adresse sont pour dire que le client peut avoir une adresse de livraison différente de l adresse de facturation.

De plus, je ne vois pas d'entité-type commande qui, classiquement fait le lien entre un client et les produits, via des lignes de commande...

L'entité type Commande et Lignes de commande ne "sont qu 'une copie" de l'entité type facture et lignes de facture.

[fsmrel]

Bonsoir,

je n’arrive pas à modéliser la TVA.

R03: la tva appliquée à ce produit dépend de son lieu de livraison.

Donc, quel que soit le produit figurant dans la facture, la TVA est à déterminer en fonction de l’adresse de livraison.

Partons du MCD suivant, où l’on spécialise les adresses (une adresse de facturation peut être une adresse de livraison : pas de contrainte d’exclusion) :





Dérivons ce MCD en MLD (MPD au sens de l’AGL, car je passe ici par « Outils » > « Générer un MPD ») :





Sous des noms différents, l’attribut client_id est présent 3 fois dans l’en-tête de la table FACTURE :

— client_id, faisant l’objet de la clé étrangère <fk3> {client_id} référençant la clé primaire {client_id} de la table CLIENT ;

— client_facturation_id, participant à la clé étrangère <fk1> {client_facturation_id, adr_facturation_id} référençant la clé primaire {client_id, adr_id} de la table ADRESSE_FACTURATION ;

— client_livraison_id, participant à la clé étrangère <fk2> {client_livraison_id, adr_livraison_id} référençant la clé primaire {client_id, adr_id} de la table ADRESSE_LIVRAISON.

Or il s’agit bien d’un seul et même client, autrement dit les attributs client_facturation_id et client_livraison_id doivent être remplacés par client_id dans les relations avec les tables ADRESSE_FACTURATION et ADRESSE_LIVRAISON.

Pour cela, on sélectionne le lien entre FACTURE et ADRESSE_FACTURATION, on ouvre la fenêtre « Propriétés de la référence » (onglet « Jointures »), et dans la colonne « Colonne de la table enfant », on sélectionne la colonne client_facturation_id :





On descend alors le curseur sur la colonne client_id :





On clique, et au résultat, client_facturation_id a été remplacé par client_id :





Constatant que la colonne adr_facturation_id n’a plus d’emploi, l’AGL la supprime carrément de l’en-tête de la table FACTURE, c'est-à-dire qu’on n’aura même pas à le faire soi-même.

On procède de la même façon pour le lien entre FACTURE et ADRESSE_LIVRAISON, et le MLD devient le suivant :





Ainsi, pour un client et une facture donnés, on peut déterminer le pays de l’adresse de livraison, donc (à une date donnée) la liste des taux de TVA correspondants.

Il faut donc modéliser une entité-type pays, une entité-type date, une entité-type TVA, et une relation entre les 3 entités-type porteuse de l'attribut "taux"

On n’est plus en Merise pur et dur. Le modèle E/R proposé par l’AGL permet de ne pas avoir à modéliser d’entité-type DATE, la date participant directement à l’identification de l’entité-type TVA. C’est chouette

[escartefigue]

Le taux applicable pour un code TVA et un code pays, dépend de la date.
Il faut donc modéliser une entité-type pays, une entité-type date, une entité-type TVA, et une relation entre les 3 entités-type porteuse de l'attribut "taux"

Représenté par l'entité type TVA dans mon mcd

En ce cas le nom n'est pas très bien choisi, cette entité-type sera probablement utile dans d'autres relations, mais surtout il faut une relation mettant en œuvre les 3 entités-type
EDIT : je n'avais pas vu la réponse de Fsmrel, autant pour moi

Vous considérez que facture et livraison ne font qu'un, c'est possible mais très restrictif, Est-ce volontaire ?

Non, la partie du mcd ne représente que la partie de mon problème. Les relation représenter par les relations entre l'entité type Facture et l'entité type Adresse sont pour dire que le client peut avoir une adresse de livraison différente de l adresse de facturation.

Certes mais je mettais surtout en exergue qu'une facture peut (peut être pas dans votre cas, mais en général), consolider plusieurs livraisons, ou éventuellement, n'en représenter qu'une partie

De plus, je ne vois pas d'entité-type commande qui, classiquement fait le lien entre un client et les produits, via des lignes de commande...

L'entité type Commande et Lignes de commande ne "sont qu 'une copie" de l'entité type facture et lignes de facture.

Je ne suis pas sur de vous comprendre
Classiquement, les attributs d'une commande et d'une facture, pour ne citer que ces entités-type sont très différents, et les 2 entités types ne font pas l'objet des mêmes relations

[haich]

bonsoir,

Tout d'abord je vous remercie de votre intervention.

Donc, quel que soit le produit figurant dans la facture, la TVA est à déterminer en fonction de l’adresse de livraison.

Désolé si je me suis mal exprimer, mais la TVA est déterminer par le produit et le lieux de livraison

exemple 1: si dan une même facture, j ai un produit soumit au taux normale et un autre produit a taux réduit, je dois pouvoir déterminer a une date donné le taux de TVA appliqué

exemple 2: si un client dans un pays A commande ces même produit (produits de l exemple 1) et se fait livrer dans un pays B, le Taux de TVA appliqué sera celui du pays B (pays de livraison)


Si au lieu de mettre la relation en l'entité-type Client et l'entité-type Facture, je mettais cette relation entre l'entité-type ligne de Facture, cela répondrais a ma problématique?

[escartefigue]

J'essaye d'illustrer mon propos par un exemple :

Je livre au même client, un même article de la façon suivante :
- L1 : livraison à une adresse française le 10-01-2016
- L2 : livraison à une adresse espagnole le 12-01-2016
- L3 : livraison à une adresse française le 12-01-2016

Les 3 livraisons sont facturées en fin de mois, le 31-01-2016, je dois donc être en capacité d'appliquer jusqu'à 3 taux de TVA distincts, puisque plusieurs pays et/dates de livraison dans une même facture.
Dans ce cas de figure, la facture aurait 3 lignes pour le même article, avec jusqu'à 3 codes TVA différents (dans les faits 2 car le taux de TVA n'aura pas changé en France entre le 10-01 et le 12-01 )

D'où la nécessité d'attacher l'adresse de livraison (en tout cas son pays) à une entité-type livraison et non facture

... sauf si pour vous 1 livraison<=>1 facture

Edit : je ne suis pas sur que la date de livraison intervienne dans le choix du taux de TVA, peut être est-ce seulement la date de facturation (à confirmer), mais ça ne change pas qu'il faut dans mon exemple à minima 2 taux de TVA pour une même facture et un même article, à cause du pays du lieu de livraison

[haich]

bonsoir escartefigure,

Citation Envoyé par haich Voir le message
Citation Envoyé par escartefigue Voir le message
Vous considérez que facture et livraison ne font qu'un, c'est possible mais très restrictif, Est-ce volontaire ?
Non, la partie du mcd ne représente que la partie de mon problème. Les relation représenter par les relations entre l'entité type Facture et l'entité type Adresse sont pour dire que le client peut avoir une adresse de livraison différente de l adresse de facturation.
Certes mais je mettais surtout en exergue qu'une facture peut (peut être pas dans votre cas, mais en général), consolider plusieurs livraisons, ou éventuellement, n'en représenter qu'une partie

Cela a été modéliser sur mon mcd général, je vous ai fourni que la partie ou se situe mon problème, afin d'éviter d être distrait par les autres entité-type et relation qui compose mon mcd

Je ne suis pas sur de vous comprendre
Classiquement, les attributs d'une commande et d'une facture, pour ne citer que ces entités-type sont très différents, et les 2 entités types ne font pas l'objet des mêmes relations

Désolé pour mon abus de language et suis en accord avec ce que vous dites.

[haich]

Les joies de la fiscalité !

Oui effectivement, cela empêche un client de commander à partir d'un pays à fiscalité privilégié (pays B) et de se faire livrer a son domicile (A) en profitant du pays a taux réduit (B).

[haich]

Edit : je ne suis pas sur que la date de livraison intervienne dans le choix du taux de TVA, peut être est-ce seulement la date de facturation (à confirmer)

Effectivement, c'est la date de facture qui est pris en compte et pas celle de la livraison.

, mais ça ne change pas qu'il faut dans mon exemple à minima 2 taux de TVA pour une même facture et un même article, à cause du pays du lieu de livraison

Malheureusement, c une obligation fiscale.

[fsmrel]

Bonsoir,



Faisons évoluer le MCD, en définissant une association PRODUIT_TVA connectant TVA et PRODUIT :

sauf si pour vous 1 livraison<=>1 facture

Supposons pour le moment qu’il en soit ainsi.

D’une part, une ligne de facture détermine une facture, laquelle détermine une adresse de livraison, laquelle détermine un pays, donc par transitivité, une ligne de facture détermine un pays.

D’autre part, une ligne de facture détermine un produit. L’association PRODUIT_TVA permet de savoir pour ce produit quels taux sont applicables à quelles dates, pour quels pays.

Si pour un pays, un produit et une date donnés il y a un seul taux de TVA applicable, comme on connaît la date de facture et le pays de l’adresse de livraison, on sait donc pour une facture et un produit donnés quel est le taux de TVA applicable.


MLD :

[haich]

bonsoir fsmrel,

merci de la proposition, je crois que que ça résolve a ma problématique.

Pourriez vous juste m enlever un doute, dans l'entité-type PRODUIT-TVA, l'attribut taux_id devrais faire partie de la clé primaire puisqu'elle fais partie de l'identification relative, non?

[fsmrel]

Bonsoir,

Pourriez vous juste m’enlever un doute, dans l'entité-type PRODUIT-TVA, l'attribut taux_id devrait faire partie de la clé primaire puisqu'elle fait partie de l'identification relative, non?

L’identification relative est une chose (merisienne), le concept de clé en est une autre (relationnelle).

Je rappelle qu’une clé candidate (ou plus simplement clé, quand il n’y a pas de confusion possible) est un sous-ensemble de colonnes K de l’en-tête d’une table T, respectant les deux contraintes suivantes :

Unicité. Deux lignes distinctes de T ne peuvent avoir même valeur de K.

Irréductibilité (ou minimalité). Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité.

Pour mémoire, une clé primaire est une clé candidate que l’on a choisie comme telle.

Si pour un pays, une date et un produit donnés il n’y a qu’un taux, alors le quadruplet {pays_id, tva_id, prod_id, taux_id} vérifie la contrainte d’unicité, mais pas celle d’irréductibilité et n’est pas clé de la table PRODUIT-TVA.

Si le quadruplet {pays_id, tva_id, prod_id, taux_id} vérifie aussi la contrainte d’irréductibilité, alors il est clé, ce qui veut dire que pour un pays, une date et un produit donnés, il peut y avoir plusieurs taux.

Qu’en est-il ?


En passant, si telle et telle réponses ont pu vous aider, n’hésitez pas à voter pour elles...

[haich]

Qu’en est-il ?

Non, il n'y aura qu'un taux.

Je vous remercie encore de votre aide