Aller au contenu

Récapitulatif des besoins liés au module de priorité de ventes

Objectif

Permettre aux gestionnaires de donner des priorités d'achats à des clients :

  • Priorité sur une place (Place verrouillée pour les autres)
  • Priorité sur un produit : possibilité d'acheter un produit non ouvert à la vente pour les gens sans priorité (à déterminer)

Attribution des priorités

Les priorités peuvent être attribuées de plusieurs manières :

  • Manuellement : depuis une règle de priorité, un gestionnaire peut donner une priorité à un client (sélection manuelle de la place si besoin ?)
  • Automatiquement :
    • Soit à l'achat d'un article correspondant à une règle (tache asynchrone après passage de commande ?)
    • Soit à la création/modification d'une regle → on détecte les articles concernés et on génère les priorités

Création des priorités

2 possibilités :

  • Les priorités sont des snapshots des leurs règles au moment de leur création → à la création d'une priorité, on y stock les données nécéssaires à son utilisation. Puis si la règle change, on ne répercute pas les modifications.
  • Les priorités dépendent directement de leur règle, les ModeleArticle (déclencheurs ou cibles) sont calculés sur la règle, et accédés à travers elle par les cibles.

La première approche est simple à mettre en place, mais risque de poser des problemes (calcul des ArticlePlaceMatch variant en fonction des modifications des formules ou des listes dynamiques d'événements type saison, et compétition). Elle garantit aussi une certaine constance.

La 2ᵉ approche permet de ne pas avoir à mettre à jour les priorités en cas de modification de la règle ou de ses dépendances (formules...), mais demande de mettre en place un système peut être plus complexe. De plus, cela rend les priorités inconstantes (une modification des règles entraine une modification des portées des priorités déjà existantes).

PS : Un moyen de gérer les priorités d'un contact semble aussi nécéssaire.

Gestion des règles de priorité

Une règle se compose de 2 parties principales :

Les déclencheurs

Optionnel (pour les règles 100% manuelles)

Ensemble de modèles/filtres servant à définir les achats donnant accès à une priorité :

  • Liste d'événements
  • Liste de produits (ModeleArticle) → Gestion via : Formules, TemplateArticleEvent
  • Listes de catégorie de places et de publics
  • Liste de filières de vente
  • Liste de contacts (client)

Les cibles (portée)

Obligatoire

Ensembles de règles délimitant la portée de la priorité :

  • Soit une ou plusieurs Formule
  • Soit un ou plusieurs TemplateArticleEvent
    • Auxquels on ajoute une iste d'événements
  • Place (choisie manuellement ou via l'article déclencheur)

Questions:

  • Bloquer les tarifs possibles?

Limitations

Optionnel

Limites de validité de la règle :

  • Statut
  • Dates

Limites mises aux priorités :

  • Dates : début et fin d'application de la règle (pour mode automatique).

Génération des priorités

2 cas à différencier :

  • Manuelle : génération séquentielle à la demande du gestionnaire
  • Automatique :
    • Après le passage d'une commande, ou après l'annulation d'un article → on gère les priorités liées (via tâches asynchrones).
    • Après sauvegarde d'une règle : via tâches asynchrones → trouver les articles impactés et gérer les priorités selon le contexte. (en option à sélectionner par le gestionaire)

Prise en compte dans les calculs

Il est probablement plus simple de séparer les calculs "normaux" et de priorité pour la partie "disponibilité" des produits. Pour les disponibilités de places :

  • Intégration des priorités de vente au calcul de disponibilité pour l'exclusion de places (Si priorité d'un autre contact présente sur la place, la place est indisponible)
  • Second calcul pour les places disponibles par priorité uniquement ?

Cycle de vie des priorités

Ouverture et fermeture

Via un nouveau modèle PriorityDisponibility, semblable aux ArticleDisponibilite ou Eventdisponibilite

Nombre d'utilisations

Le nombre d'utilisations est un paramètre de la règle, une fois atteint, la priorité est désactivée.

Problèmes

Doublons de priorités pour un même contact

Comment gérer les cas ou un contact a plusieurs priorités dont les portées se chevauchent ? L'utilisation d'une priorité annule les autres ? Elles sont cumulatives ?

Doublons de priorités pour 2 contacts

Comment gérer les cas ou deux contacts ont des priorités dont les portées se chevauchent ? Premier arrivé, premier servi ? Erreur à la création ?

Solutions au problème des doublons

À la création d'une priorité, on vérifie si elle entre en compétition sur des ArticlePlaceMatch d'une ou plusieurs autres priorités. Si oui, on passe la nouvelle priorité en erreur, et on y stock les concurrentes (afin de donner la possibilité de gérer le problème aux gestionnaires).

Gestion des ArticlePlaceMatch

  • Si version snapshot :

    • Stocker les ArticlePlaceMatch
    • Mettre à jour les ArticlePlaceMatch sur le même modèle que les articles en cas de modifications des formules cibles, ou d'ajout d'événements aux compétitions/saison (si l'option est choisie)
  • ~~Sinon :~~

    • ~~Trouver un moyen efficace de trouver les ArticlePlaceMatch d'une priorité (vue SQL ?)~~
    • ~~Trouver un moyen efficace de vérifier la concurrence entre les priorités~~

Modèles