Bonjour à tous,
Qui dit épisode III, dit pour rappel Episode I et Episode II.
Il y a 2 sujets pour lesquels j'ai le plaisir de vous solliciter.
1) La gestion du paiement de commissions
2) La gestion des emails associés au paiement des échéances
Après avoir présenter une partie du MCD, je présenterai le contexte et ensuite (malheureusement) pourquoi je n'arrive pas à finaliser le MCD.
MCD actuel:
ce qui donne en gros le MLD suivant:
Rappel succinct du contexte général : domaine de la location de bateaux
Un client fait une demande sur Internet pour louer un bateau. Une fois que sa demande se concrétise commercialement, on fait une réservation. Cette réservation entraine l'établissement d'échéanciers qui viennent directement alimenter des comptes bancaires. (pour une meilleure compréhension voir début de l'
Episode I)
Point 1 - Gestion du paiement de commissions
Contexte et cahier des charges:
Marge Brute d’une réservation = (Somme des paiements du client – Somme des paiements fournisseurs) associées à la dite réservation.
Marge Brute d’un dossier commercial = Marge Brute d’une demande = somme des marges des réservations associées. Dans 90% des cas, une demande d'info (table demande) qui se concrétise commercialement fait d'objet d'une seule réservation (dossier de réservation). Il peut néanmoins arriver que soit rattachée à une demande plusieurs dossiers de réservations.
Marge Brute Finale:
La marge brute finale est la marge calculée lors de la clôture du dossier. C’est le service gestion qui définit la clôture: date et montant. En principe, la marge brute finale ne peut pas être calculée tant que le client n’a pas terminé sa location et/ou que tous les fournisseurs liés à cette réservation n’ont pas été payés.
Règle 1: La marge brute finale se calcule uniquement à partir de données comptables : encaissements et décaissements constatés. Par données comptables, il faut traduire données enregistrées dans les comptes bancaires. (= données issues de la table opération)
Règle 2: La marge brute associée à une réservation s’exprime toujours en euro, même si les encaissements et les décaissements se font en dollar ou autres monnaies.
Pratique 3: Dans le cadre de réservation faisant intervenir d’autres monnaies que l’euro, il est d'usage qu'un seul taux de change (par monnaie) soit pris en compte, indépendamment de toutes considérations (date d’encaissement réel, de décaissement, etc) . Ce taux est choisi par la personne en charge de la gestion.
Règles 4: Principe de précaution et afin de garantir la pérennité de la solution, l'application doit pouvoir s’affranchir de la pratique n°3! En d’autres termes, le système doit être capable de calculer la marge d’un dossier en considérant des taux de change différents.
Règle 5: Un taux de change se détermine en fonction de sa date de référence. Autrement dit, on ne saisit pas un taux de change, on saisit une date. En fonctionne de cette date, le système doit connaître le taux de change à appliquer.
Le commercial perçoit une commission. Cette commission se calcule à partir de la Marge brute selon la formule suivante :
commission = (marge brute) x (taux de commission).
Ce taux est jusqu'à présent toujours de 50%, mais rien ne dit qu'il en sera toujours à l'avenir pour tous les dossiers.
En début de mois (généralement), la gestion procède au paiement des commerciaux.Chaque commercial perçoit alors un montant global qui est la somme de ses commissions. Ce paiement est enregistré dans les comptes bancaires. Cela fait donc l'objet d'une opération bancaire.
La marge s'exprimant en euro, la commission s'exprime de facto en euro. Si le commercial est américain et doit être payé en dollar, la commission doit être valorisée en dollar. C'est la personne en charge de la gestion qui choisi la date du taux de change.
Un petit exemple pour bien comprendre :
Un client américain, mr OBAMA loue un bateau en Espagne. Le client paye sa réservation en dollar sur un compte (en dollar). Le client fait 3 paiements de 3000 $. Le ou les fournisseurs qui sont impliqués dans ce dossier seront eux payer en euro (ici un seul fournisseur pour simplifier).
Prenons le cas le plus «compliqué»:
Pour Y raisons, il est décidé de valoriser les paiements du client comme suit:
paiement du 1er janvier au taux du 2 janvier 2009. A cette date la parité euro_dollar était de 1.25, donc 1/1.25 euro (=0,8) pour 1 dollar
paiement du 1er août au taux du jour. A cette date, la parité euro_dollar était de 1.3456 soit 1 dollar pour 0,7432 euro
paiement du 29 octobre au taux du 1er décembre 2009. A cette date, la parité euro_dollar était de 1.1123 soit 1 dollar pour 0,899 euro
Sachant que pour cette réservation, le taux de commission est de 50%, la commission est de 1213,20 €. Le commercial étant américain, on valorise sa commission en dollar. Il est décidé de prendre la date du 1er décembre 2009 pour le taux de change.
Commission = 1213,20 x 1.1123 = 1349,44 $
Dans la pratique, si on reprend l'exemple ci-dessus, on valorise tous les paiements au même taux de change. Idem pour le taux de change retenu pour le calcul de la commission. C'est le taux de change en date du paiement des commissions qui est pris en compte. Ici la date du 1 décembre 2009.
Commission = (3131,33 x 0,5) x 1.1123 = 1774,85 $
Mon analyse pour le MCD.
Quelles sont les entités et relations associées à définir et qui ne sont pas encore représentées dans le MCD actuel ?
La notion de marge brute me pose problème. C'est un champ calculé. La marge prend en considération une ou plusieurs opérations bancaires, chaque opération bancaire pouvant être associée à un taux de change (date de taux de change). Initialement, je me suis dit, c'est simple, il suffit de rajouter l'attribut date_taux_change dans la table opération. Seulement voilà, cet attribut ne concerne que des opérations résultant d'une réservation, opérations appartenant en plus à un compte bancaire libellé dans une autre devise que l'euro. Je vais avoir beaucoup de NULL pour cet attribut.
J'ai donc pensé à la notion d'héritage/spécialisation.
Une opération bancaire servant au calcul de marge , n'est ni plus ni moins qu'une opération bancaire, elle en a tout les attributs, mais en plus elle a l'attribut date_taux_change.
Oui mais, cela sous entend qu'on utilise une date de taux de change pour chaque opération, or en pratique ce n'est pas vrai. En effet, généralement, on utilise le même taux de change (date) pour toutes les opérations.
Doit-on prendre on considération cet état de fait, sachant que dans le cas où l'on gère différents taux de change, il sera toujours possible de calculer la marge. Toutes les opérations bancaires auront la même date de taux de change.
N'y aurait-il pas là une notion d'exclusion à modéliser ? Le calcul de la marge fait intervenir une date de taux de change ou s'appuie sur plusieurs de taux de change. Nous avons donc une notion de modalité de calcul de Marge avec Taux_Change_Unique ou Taux_Change_Multiple.
Cependant, la notion de modalité de calcul n'a de sens que pour des comptes bancaires dont la devise n'est pas l'euro. Dois-t-on le modéliser ?
En faisant abstraction cette notion de marge, au mieux (à priori) , on peut dire qu'une commission se rattache à une réservation avec comme cardinalité (1,1) et (1,1). Cette entité «commission» ayant pour attribut le tx_de_commission. Il existerait aussi une relation entre Commission et Commercial.
[commission]----1,1-----(concerne)----0,n-------[commercial]. Tout ceci ne me convainc guère ...
J'ai beau «brouillonner» plusieurs nouvelles entités, relations, j'aboutis à rien .
J'ai même étudié la piste de mettre des attributs d'association comme présentée ici. Je verrai bien en effet une relation se_calcule entre une entité [Marge_brute] et l'entité [opération] avec comme attribut d'association date_taux_change. Ce serait mon premier attribut d'association! J'en ai pas encore dans mon MCD!
Bref, j'ai du mal à faire la différence entre ce qui relève purement du MCD voir MLD et des requêtes qui seront mises en œuvre.
Pour ce qui est du point 2 ( La gestion des emails associés au paiement des échéances), on verra cela après !
En espérant ne pas vous avoir perdu en cours de route,
Bien à vous
Tavar
Partager