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
ArticlePlaceMatchsur 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)
- Stocker les
-
~~Sinon :~~
- ~~Trouver un moyen efficace de trouver les
ArticlePlaceMatchd'une priorité (vue SQL ?)~~ - ~~Trouver un moyen efficace de vérifier la concurrence entre les priorités~~
- ~~Trouver un moyen efficace de trouver les