Posted by English version available here
Voici la suite de l’article précédent, concernant la répartition du revenu entre différents articles, dans le cadre du module reconnaissance des revenus. Après avoir utilisé le Revenue Type (Essential, Nonenssential et Post contract support), nous allons étudier l’utilisation du prix médian, et accrochez-vous, l’algorithme appliqué n’est pas simple.
Paramétrage
Tout d’abord, il faut désactiver le paramètre « Enable discount allocation method » dans les paramètres généraux, ou bien forcer dans l’entête de la commande client pour utiliser le prix médian en cochant « Apply residual method ».
Au niveau des articles, il faut non seulement cocher « Is revenue allocation active » (nous permet de rendre disponible tout le paramétrage inhérant aux prix), mais cocher aussi « Median price ». Pour la tolérance, on verra plus tard.
Pour rappel, le Revenue schedule utilisé ici est sur une base de 3 occurrences. Cela aura son importance par la suite.
Flux
Comme précédemment, on crée une commande client, on ajoute les 3 articles pour un prix de vente respectif de 1000, 100 et 50 euros. Pas de remise cette fois.
On confirme, et on vient ensuite visualiser le calcul effectuer pour le Price allocation. Voici le résultat.
Analyse des résultats
Bien bien, commençons par le facile. Dans le unit price et le total, on retrouve bien le prix appliqué sur la commande client.
Dans le champ allocation price, on retrouve les prix positionnés sur l’écran « Revenue allocation price ». Mais comment expliquer le -304.06 du Allocation amount sur la première ligne et la répartition pour le Revenue to recognize de 960.34, 126,44 et 63,22 pour les 3 articles ?
Première chose, il faut savoir que la notion de « Revenue type » n’intervient pas ici.
Ce qui s’est passé est décrit dans la capture d’écran ci-dessous.
Il y a 3 articles, donc l’algorithme itère 3 fois et ajuste à chaque fois le Revenue to recognize.
Itération 1 : Focus sur le premier article de la ligne
Pour le Laptop, le système calcule la différence entre le List price et l’Allocation Price. Si elle est positive (ce qui est le cas), le système calcul le ratio entre le Liste price / ∑ Liste price * différence entre le Liste price et l’Allocation Price. Il trouve ici 434.78, qu’il ajoute au Liste price pour obtenir 1434.78. Il fait pareil pour les 2 autres articles, en se basant toujours sur la différence entre le Liste price et l’Allocation Price du premier article.
Si la différence eut été négative, l’opération aurait été la même multipliée par -1.
Itération 2 : Focus sur le second article de la ligne
Ici, c’est plus ou moins le même principe qui s’applique, sauf qu’au lieu de comparer le Liste price vs l’Allocation price, on compare la nouvelle valeur du Revenue to Recognize – l’Allocation price, pour le second article. On trouve -128.26. On applique donc le même calcul pour retrouver les chiffres du tableau.
Itération 3 : Focus sur le troisième article de la ligne
L’algorithme continue autant de fois qu’on a d’articles à traiter. Ici on en a 3, donc on retrouve les chiffres du tableau. Cela nous donne un total de 1454.06 €. Or il faut que le total de la commande fasse bien 1150 €. Pour une raison étrange, le système fait supporter la différence sur le premier article de la ligne, ici pour un Allocation Amount de 304.06 €.
Remarques importantes : le facteur quantité et le nombre d’occurrences est à prendre en compte également dans l’algorithme, pour chaque article. Dans le précédent exemple, on a laissé la quantité à 1 ainsi que le nombre d’occurrences à 3 dans la ligne de commande client (Nombre d’occurrences de la commande client pour chaque ligne = Nombre d’occurrences du Revenue schedule = 3).
Pour le premier article, si je change le nombre d’occurrences à 2 en ajustant la date de fin, pour le premier article, cela donne :
En cliquant sur le Revenue price allocation :
Le résultat est le suivant : pour la première itération, le champ Allocation price a d’abord été ajusté par le coefficient : Nombre d’occurrences réelles / Nombre d’occurrences théoriques (soit 2 / 3).
Utilisation de la tolérance
Il est possible de paramétrer des tolérances minimum et maximum pour chaque article. Le principe est le suivant : si on est dans la tolérance, on n’exécute pas l’algorithme pour cet article.
Dans le détail, les conditions pour déclencher le calcul de l’algorithme sont les suivante :
Si le montant List price < Allocation – min % OU montant List price > Allocation + % max, alors on déclenche l’algorithme pour cet article.
J’ai mis 1000% de tolérance en min et max pour les articles Warranty et Support et 10% pour LAPTOP. Ainsi, seul le Laptop est concerné.
Le résultat de l’allocation est le suivant :
En d’autres termes, le système n’a calculé que l’itération 1 de l’exemple précédent. Les 2 autres articles n’ont pas été pris en compte. CQFD.
Voici donc pour l’explication technique/solution. Pour l’application métier de ces différentes méthodes de calcul, pas certain qu’en France cela soit utilisable. Probablement plus pour le marché des USA. Mais si quelqu’un sait mieux, les commentaires sont là pour ça.
Yohann
One comment