Le principe des remises repose sur un mécanisme général extensible par surcharge de classes. Il n'est disponible que dans la version “Pro” de la boutique Moodle.

Une instance de classe de remise effectuera la vérification d'une condition particulière pour déclencher ou ne pas déclencher la remise.

Si plusieurs instances de boutiques sont utilisées, alors la politique de remise de chaque boutique est indépendante.

Les remises peuvent affecter la totalité d'un catalogue produit, ou uniquement une partie du catalogue, sous forme d'une liste explicite de produits sélectionnés.

Les remises sont définies dans une pile, évaluée dans l'ordre de la pile. Chaque instance est associée à un opérateur qui influe le process de calcul.

• Accumulatif: (par défaut) : Accumule la remise avec les remises précédentes dans la liste
• Remplace et stoppe: la remise remplace le calcul précédent de la pile. Toutes les remises antérieures sont annulées. L'évaluation de la liste de remise est stoppée.
• Stoppe si s'applique: La remise est appliquée en mode cumulatif, puis l'évaluation de la liste est stoppée si la remise était applicable.
• Stoppe si ne s'applique pas: La remise est appliquée en mode cumulatif, puis l'évaluation de la liste est stoppée si la remise N'était PAS applicable.

La remise finale est le résultat final de l'évaluation de la pile, à savoir, la somme des remises individuelles 'par ligne produit' consenties par chaque instance de remise activée pendant le processus de calcul.

En cas d'application des taxes sur les lignes produit, la remise est calculée avec la même taxe que la ligne produit sur laquelle elle joue. Le processus de calcul calcule le net et la taxe de l'ensemble des remises.

Pendant la phase de sélection panier, et avant que la commande ne soit enregistrée, le calcul des remises s'effectue à partir des données en session. Toutes les informations pilotant les conditions de remise n'étant pas toujours disponible (acheteur non connecté non identifié, condition dépendant contextuellement de la commande, comme un montant total d'achat, ou une combinaison de produits) le calcul se fait “au mieux selon les informations disponibles”.

Il revient à chaque classe concrète de remise de définir comment elle calcule les remises applicables et présentables au client pendant cette phase là.

Lorsque la commande est enregistrée en base (lors de la phase de paiement), l'ensemble de la pile est jouée et les résultats de remise sont ajoutés à la commande en cours. Le traitement d'application des remises se divise en 2 phases :

• La vérification d'applicabilité : vérifie les règles qui valident ou invalident l'application de la remlse.
• L'application à la commande/facture.

Lors de calcul, les paramètres de contexte des remises sont enregistrées en paramètres de production.

Rappel : Il est possible de constituer une facture par le backoffice, ou de modifier une commande tant qu'elle n'a pas été lettrée (c'est à dire, enregistrée en comptabilité “officielle”).

Les modifications d'une facture ou commande, dans la version actuelle :

• Ne changent pas le résultat de l'application des remises initialement consenties au moment de l'enregistrement de la commande. La commande ne bénéficiera donc pas de nouvelles clauses de remises configurées APRES son enregistrement.
• Peuvent par contre changer le résultat de calcul si les paramètres de la remise ont changé entre-temps.

• Valéry Frémaux (valery@activeprolearn.com) Conception - Développements
• Florence Labord (florence@activeprolearn.com) Revue Fonctionnelle - Tests

Retour à la structure - Revenir au sommaire du composant Local Shop (Boutique) - Revenir au catalogue