PT2QE - Pricing Tier 2 Quote Engine¶

Vue d'ensemble¶

PT2QE (Pricing Tier 2 Quote Engine) est un système de recommandations de prix personnalisées qui calcule des prix optimaux à la maille client × article. Il s'appuie sur les corridors optimaux générés par PT1CE pour proposer des ajustements tarifaires adaptés à chaque relation commerciale, en tenant compte de l'historique transactionnel et de la sensibilité prix.

Objectif stratégique¶

PT2QE transforme les corridors de prix théoriques en recommandations opérationnelles concrètes. Là où PT1CE définit des fourchettes de prix acceptables par segment de marché, PT2QE personnalise ces recommandations pour chaque couple client-article en analysant :

• La performance historique de la relation commerciale (4 derniers trimestres fiscaux)
• La position actuelle du prix dans les corridors
• Les contraintes de sensibilité prix produit
• Les règles métier de protection tarifaire

Positionnement dans la chaîne tarifaire¶

PT0CE                    PT1CE                      PT2QE                    Déploiement
(Statistiques) ──────► (Optimisation) ──────► (Personnalisation) ──────► (SAP/Client)
  - Analyse marge        - Nouveaux PAS/PRB        - Prix client × article   - Mise à jour
  - Corridors actuels    - Corridors optimaux      - Historique 4Q          - Conditions
  - Sensibilité prix     - Validation métier       - Cappings personnalisés  - Suivi

PT2QE intervient en Tier 2 : après que PT1CE ait optimisé les corridors globaux, PT2QE descend au niveau opérationnel pour générer des offres de prix individuelles prêtes à déployer.

Concepts fondamentaux¶

1. Double système de recommandations¶

PT2QE calcule deux recommandations indépendantes pour chaque offre de prix :

Recommandation 1 (RECO1) : Repositionnement intelligent dans les paliers tarifaires - Analyse la position actuelle dans le corridor PT1CE - Applique des règles de repositionnement paramétrables (configuration JSON) - Pousse vers les paliers supérieurs selon la logique métier - Exemples : PL5_PL6 → remonter vers PL5, PL2_PL3 → remonter vers PL1

Recommandation 2 (RECO2) : Hausse proportionnelle au PAS - Répercute le pourcentage d'évolution du PAS (Prix d'Achat Standard) - Si PAS passe de 10€ à 11€ (+10%), prix de 15€ devient 16,50€ (+10%) - Maintient la cohérence avec l'évolution des coûts d'achat - Plus simple et plus prévisible que RECO1

La sélection finale suit un arbre de décision à 3 chemins (détails section Concepts).

2. Arbre de décision à 3 chemins¶

PT2QE ne sélectionne pas systématiquement le maximum entre RECO1 et RECO2. Il utilise un arbre de décision intelligent avec 3 branches distinctes :

CHEMIN 1 - Gel du prix : Lorsque le nouveau PAS est inférieur au PAS actif, le prix est gelé totalement (0% de hausse). Rationale : ne pas répercuter les baisses de coût d'achat aux clients.

CHEMIN 2 - Conservation premium : Lorsque le prix actuel est dans le palier PL1 des anciennes bornes, conservation du prix actuel avec plancher de sécurité PL2_PL3. Rationale : maintenir les clients premium en position haute.

CHEMIN 3 - Optimisation standard : Pour tous les autres cas, application de MAX(RECO1 cappée, RECO2) avec cascade complète de cappings.

Ce système permet d'adapter la stratégie tarifaire selon le contexte spécifique de chaque offre.

3. Cascade de cappings¶

Les cappings (plafonds de hausse) sont appliqués en cascade hiérarchisée uniquement sur le CHEMIN 3 :

1. Capping sensibilité prix : Selon la classification HIGH/MEDIUM/LOW héritée de PT1CE
2. HIGH : 2,5% maximum (produits très sensibles)
3. MEDIUM : 5% maximum (sensibilité modérée)

4. LOW : 7,5% maximum (faible sensibilité)

5. Capping produits basiques : 50% maximum pour les produits classés "Basiques"

6. Écrase le capping sensibilité si plus restrictif

7. Protection contre les hausses excessives sur commodités

8. Capping PRB final : Plafond absolu (tous chemins)

9. Empêche tout dépassement du PRB nouvelles bornes
10. Garantit la cohérence avec les corridors PT1CE

Ordre de priorité : Un capping de niveau supérieur peut écraser un capping de niveau inférieur.

4. Enrichissement historique transactionnel¶

Chaque offre est enrichie avec les métriques des 4 derniers trimestres fiscaux complets :

Métriques globales (hors prix promo) : - CA total (MT_CAB_4Q) - Volumes UF et KG (QT_UF_4Q, QT_KG_4Q)

Métriques par type de prix : - Prix fermes : CA, UF, KG dédiés - Prix indexés : CA, UF, KG dédiés

Ces données permettent d'identifier les couples client-article actifs et d'évaluer l'importance de chaque relation commerciale.

5. Triple positionnement tarifaire¶

PT2QE calcule et affiche 3 positions distinctes pour chaque offre :

Position 1 : Prix actuel dans les anciennes bornes (PT0CE) - Montre d'où on part historiquement - Référence pré-optimisation PT1CE

Position 2 : Prix actuel dans les nouvelles bornes (PT1CE) - Révèle l'impact du recalibrage PT1CE - Le prix peut avoir changé de palier sans bouger

Position 3 : Prix recommandé dans les nouvelles bornes (PT2QE) - Montre où on arrive après optimisation PT2QE - Objectif : remonter vers les paliers supérieurs

Les 8 positions possibles : ABOVE_PRB, PL1, PL2, PL3, PL4, PL5, PL6, PLX, BELOW_PAS

Cette triple vision permet de comprendre l'évolution complète du pricing.

6. Stratégie de fallback MASTER → NATIONAL¶

Pour maximiser la couverture, PT2QE utilise une stratégie de matching en 2 étapes :

Tentative 1 - MASTER : Match exact avec les 4 dimensions - ID_ART × TYPE_CLIENT × TYPE_RESTAURANT × GEO - Corridors les plus spécifiques et pertinents

Tentative 2 - NATIONAL : Si échec, fallback vers le corridor national - ID_ART × NATIONAL × NATIONAL × NATIONAL - Vision agrégée, moins spécifique mais garantit une couverture

Le champ MATCH_TYPE permet de tracer quel corridor a été utilisé.

Workflow principal¶

PT2QE s'articule autour de 3 étapes séquentielles, dont 2 obligatoires et 1 optionnelle.

Étape 1 : Calcul des recommandations (OBLIGATOIRE)¶

Fichier : 1_calculer_recommendations.bat ou Menu Option 1

Phases d'exécution : 1. Extraction des offres actuelles (ZOOM1 uniquement) 2. Enrichissement avec historique 4 derniers trimestres fiscaux 3. Jointure avec corridors PT1CE_OPTIMAL_* (MASTER puis NATIONAL) 4. Calcul RECO1 (repositionnement selon règles paramétrables) 5. Calcul RECO2 (hausse proportionnelle PAS) 6. Application cascade cappings (sensibilité → basiques) 7. Exécution arbre de décision (3 chemins) 8. Génération analyses détaillées (6 fichiers CSV)

Fichier requis : inputs/capping_type_client.csv

Résultats générés : - recommendations_detail.csv : Détail ligne à ligne avec traçabilité complète - statistics_by_dimension.csv : Agrégations par TYPE_CLIENT, TYPE_RESTAURANT, UNIVERS - impact_analysis.csv : Impact CA et distribution hausses par segment - price_increase_distribution.csv : Histogramme global des hausses - decision_path_analysis.csv : Statistiques par chemin de décision - capping_distribution.csv : Impact détaillé des cappings - capping_cubes_generated.csv : Cappings générés par cube (référence pour ajustements)

Durée estimée : 20-40 minutes selon volumétrie

Étape 2 : Ajustement des cappings (OPTIONNEL)¶

Fichier : 2_ajuster_cappings.bat ou Menu Option 2

Quand utiliser cette étape : - Après analyse des résultats de l'étape 1 - Si certains segments ont des hausses trop agressives ou trop conservatrices - Si une stratégie différenciée par cube est nécessaire

Processus : 1. Copier capping_cubes_generated.csv vers corrections/ 2. Renommer en capping_cubes_corrections.csv 3. Modifier les valeurs CAPPING_HIGH/MEDIUM/LOW selon la stratégie souhaitée 4. Relancer le calcul avec les nouveaux paramètres

Caractéristiques : - Recalcul complet sans réextraire les offres (--skip-extraction) - Réutilise les tables existantes pour gain de temps - Permet des itérations rapides (10-20 minutes) - Génération d'un nouveau dossier outputs/corrections_*

Cas d'usage typiques : - Assouplir les cappings pour un segment spécifique (ex: RCI PI GI) - Durcir les cappings pour des produits sensibles - Créer une stratégie progressive par zone géographique

Étape 3 : Génération des offres finales (OBLIGATOIRE)¶

Fichier : 3_generer_offres_finales.bat ou Menu Option 3

Prérequis : - Avoir exécuté l'étape 1 - Avoir validé les résultats (avec ou sans ajustements étape 2)

Génération : - final_price_offers.csv : Export final client × article - validation_report.csv : Statistiques de validation - export_summary.txt : Résumé textuel

Format du fichier final : - ID_CLN, ID_ART, ID_CND : Identifiants SAP - PRIX_TARIF_ACTUEL : Prix actuel de référence - NOUVEAU_PRIX : Prix recommandé PT2QE - PCT_HAUSSE : Pourcentage de hausse appliqué - Les 3 positions : Anciennes bornes, nouvelles bornes, après reco - VALIDATION_STATUS : Statut (VALIDE, A_VERIFIER, ANOMALIE)

Durée estimée : 2-5 minutes

Utilisation : Ce fichier est prêt pour intégration dans les outils de pricing ou import SAP.

Prérequis obligatoires¶

1. Exécution préalable de PT1CE¶

PT2QE dépend strictement de PT1CE. Les tables PT1CE_OPTIMAL_* doivent exister :

• PT1CE_OPTIMAL_ZOOM1 (obligatoire - PT2QE en mode ZOOM1 exclusif)
• PT1CE_OPTIMAL_ZOOM2 (non utilisé actuellement)
• PT1CE_OPTIMAL_ZOOM3 (non utilisé actuellement)

Workflow PT1CE requis : 1. PT1CE Option 1 : Application nouveaux PAS/PRB 2. PT1CE Option 2 : Finalisation corridors (crée PT1CE_OPTIMAL_*)

Vérification : PT2QE Menu Option 5 → Vérifier les prérequis

2. Tables de mapping PT0CE¶

Deux tables de correspondance doivent exister :

PT0CE_TYPE_CLIENT_MAPPING : - Colonnes : UNIVERS, ID_TC_CG, ID_TC_CIBLE, FG_HM, TYPE_CLIENT - Permet de passer des codes SAP aux segments métier - Gère la dualité mercuriale (FG_HM='0') / hors mercuriale (FG_HM='1')

PT0CE_TYPE_RESTAURANT_MAPPING : - Colonnes : LC_SFC_CIBLE, Type_Restaurant - Segmentation par type d'établissement client

3. Fichier de capping obligatoire¶

Fichier : inputs/capping_type_client.csv

Format :

TYPE_CLIENT;CAPPING_HIGH;CAPPING_MEDIUM;CAPPING_LOW
RCI PI GI;0,025;0,05;0,075
RSI HM;0,025;0,05;0,075

Valeurs recommandées : - CAPPING_HIGH : 2,5% à 5% - CAPPING_MEDIUM : 5% à 10% - CAPPING_LOW : 7,5% à 15%

4. Configuration système¶

Environnement Python : - Python 3.8+ - Modules : pandas, numpy, oracledb, openpyxl - Variable PYTHONPATH pointant vers P:\PRD\Python\00_Commun\libs

Accès Oracle : - Connexion à la base TARIFAIRE (par défaut) - Permissions lecture sur : SYS_TARIF_SIMULATION, SYS_MD_CLIENT, SYS_MD_ARTICLE, SYS_FACTURE_LIGNE, SYS_MD_CALENDRIER_SYSCO - Permissions écriture pour création tables PT2QE_*

Navigation dans la documentation¶

Cette documentation est structurée en modules thématiques. Voici un guide de navigation selon vos besoins :

Pour comprendre les mécanismes¶

Section Concepts : - Les 2 types de recommandations en détail - Fonctionnement de l'arbre de décision - Logique de cascade des cappings - Stratégie de matching corridors - Les 3 positions tarifaires

Section Calculs : - Formules de calcul RECO1 et RECO2 - Algorithme de sélection finale - Calcul des pourcentages de hausse - Règles de repositionnement paliers - Exemples chiffrés

Pour travailler avec l'application¶

Section Workflow : - Guide pas à pas des 3 étapes - Quand utiliser l'ajustement de cappings - Interprétation des résultats - Bonnes pratiques d'utilisation - Scénarios d'usage typiques

Section Capping : - Philosophie du système de capping - Paramétrage des cappings par type client - Ajustements par cube (corrections) - Stratégies de capping recommandées - Impact business des différents niveaux

Section Guide d'utilisation : - Lancement de l'application (menu, scripts) - Préparation des fichiers d'entrée - Interprétation des résultats - Gestion des itérations - Déploiement des recommandations

Pour les aspects techniques¶

Section Architecture : - Structure du code Python - Organisation des modules - Rôle de chaque composant - Flux de données - Points d'extension

Section Tables : - Structure des tables PT2QE_* - Champs clés et leurs significations - Relations entre les tables - Index et performances - Volumes de données

Section Mapping : - Rôle des tables de mapping PT0CE - Construction du FG_HM dynamique - Détermination de l'UNIVERS - Enrichissement dimensionnel - Traçabilité des correspondances

Section Exports : - Description des 6 fichiers CSV générés - Format et structure de chaque export - Utilisation pour analyses pivots - Visualisations recommandées - Intégration dans d'autres outils

En cas de problème¶

Section Troubleshooting : - Messages d'erreur courants - Solutions aux problèmes fréquents - Diagnostic des échecs - Vérification de la qualité des résultats - Contacts et support

Points d'attention critiques¶

1. Mode ZOOM1 exclusif¶

PT2QE fonctionne actuellement en mode ZOOM1 uniquement. Tous les filtres et extractions sont paramétrés pour ce périmètre :

• Seules les offres ZOOM1 sont extraites
• Seuls les corridors PT1CE_OPTIMAL_ZOOM1 sont utilisés
• Les mappings doivent couvrir le périmètre ZOOM1

Impact : Les autres univers (ZOOM2, ZOOM3) ne sont pas traités par PT2QE. Si nécessaire, l'extension à d'autres univers nécessite des ajustements dans le code.

2. Historique transactionnel obligatoire¶

PT2QE enrichit systématiquement chaque offre avec l'historique des 4 derniers trimestres fiscaux complets. Cet enrichissement est obligatoire même si les métriques ne sont pas utilisées dans les calculs de recommandations.

Période analysée : Déterminée automatiquement via SYS_MD_CALENDRIER_SYSCO

Filtres appliqués : - Uniquement ZF2 (factures de vente) - Hors prestations (FG_PRESTA = '0') - Hors prix promo (via PRP_LABELS) - Marchandises uniquement (FG_MARCHANDISE = 'X' ou '1') - MT_GM4 renseigné

3. Détermination dynamique du FG_HM¶

Le statut mercuriale n'est pas stocké dans les conditions de prix. PT2QE le détermine dynamiquement depuis l'historique transactionnel :

• FG_HM = '1' : Hors mercuriale (prix négocié)
• FG_HM = '0' : En mercuriale (prix catalogue)

Cette information est essentielle car elle conditionne le mapping vers TYPE_CLIENT et donc le choix du corridor PT1CE.

4. Paramétrage des règles RECO1¶

Les règles de repositionnement pour RECO1 sont paramétrables via le fichier config/pt2qe_config.json. Il est possible de modifier la stratégie sans toucher au code :

Exemple de personnalisation : - Changer la cible de repositionnement (ex: PL3_PL4 → PL1 au lieu de PL2) - Ajouter des règles conditionnelles supplémentaires - Ajuster l'agressivité du repositionnement

Attention : Toute modification doit respecter la syntaxe JSON et la logique métier.

5. Volumétrie importante¶

PT2QE traite potentiellement des millions de lignes (clients × articles). Les performances dépendent de :

• Qualité des index Oracle
• Parallélisation des requêtes (PARALLEL hint)
• Compression des tables (COMPRESS)
• Ressources serveur disponibles

Temps de traitement observés : - Étape 1 : 20-40 minutes pour ~2M offres - Étape 2 : 10-20 minutes (réutilise tables existantes) - Étape 3 : 2-5 minutes (export uniquement)

6. Workflow itératif par conception¶

PT2QE est conçu pour l'itération rapide. L'étape 2 (ajustement cappings) peut être répétée autant de fois que nécessaire :

Cycle typique : 1. Calcul initial → Analyse résultats → Ajustement cappings → Nouvelle analyse 2. Comparaison avant/après dans dossiers séparés (run_* vs corrections_*) 3. Convergence progressive vers la stratégie tarifaire souhaitée

Astuce : Conserver l'historique des runs permet de tracer l'évolution de la stratégie.

7. Traçabilité complète¶

Chaque recommandation contient tous les champs intermédiaires de calcul :

• RECO1_BASE : Recommandation 1 brute (sans capping)
• RECO1_APRES_CAPPING_SENSIBILITE : Après étape 1 de capping
• RECO1_AVEC_CAPPING : Après cascade complète (étapes 1+2)
• RECO2 : Recommandation 2
• DECISION_PATH : Chemin emprunté dans l'arbre
• RECO_SELECTIONNEE : Quelle recommandation a été retenue
• CAPPING_APPLIED : Type de capping le plus contraignant

Cette transparence permet d'auditer chaque décision et de comprendre pourquoi un prix a été retenu.

Différences avec PT1CE¶

PT1CE et PT2QE sont complémentaires mais ont des rôles distincts :

Séquence logique : 1. PT1CE définit la stratégie globale (corridors optimaux) 2. PT2QE décline cette stratégie au niveau opérationnel (prix personnalisés)

Les deux systèmes utilisent le même référentiel de données mais avec des granularités différentes.

Limitations connues¶

1. Périmètre ZOOM1 uniquement¶

Actuellement, PT2QE ne traite que les offres classées en ZOOM1. Les offres ZOOM2 et ZOOM3 ne sont pas couvertes.

Impact : Couverture partielle du portefeuille tarifaire.

Solution future : Extension progressive aux autres univers avec adaptation des règles métier.

2. Dépendance stricte à PT1CE¶

PT2QE ne peut fonctionner sans les tables PT1CE_OPTIMAL_*. Il n'y a pas de mode dégradé.

Mitigation : Toujours exécuter PT1CE avant PT2QE dans le workflow tarifaire.

3. Historique 4Q requis¶

L'enrichissement historique est obligatoire et peut poser problème pour : - Nouveaux articles sans historique - Nouveaux clients sans transactions - Périodes de référence incomplètes

Comportement : Les métriques sont à zéro (NVL(..., 0)) mais l'offre est tout de même traitée.

4. Pas de prise en compte des stocks¶

PT2QE ne tient pas compte des niveaux de stock ou des ruptures prévisionnelles. Les recommandations sont purement tarifaires.

Conséquence : Des ajustements manuels peuvent être nécessaires en fonction du contexte logistique.

5. Pas de simulation de scénarios¶

PT2QE calcule un seul jeu de recommandations par exécution. Il n'y a pas de fonctionnalité de simulation de scénarios multiples en parallèle.

Contournement : Exécuter plusieurs runs avec des paramètres différents et comparer manuellement.

Évolutions futures envisagées¶

Court terme¶

• Extension ZOOM2/ZOOM3 : Couverture complète du portefeuille
• Mode simulation avancée : Calcul de plusieurs scénarios en parallèle
• Tableau de bord interactif : Visualisation des résultats avec filtres dynamiques
• Alertes automatiques : Détection des hausses anormales ou des incohérences

Moyen terme¶

• Intelligence artificielle : Apprentissage des patterns de succès tarifaire
• Prise en compte stocks : Intégration contraintes logistiques
• API REST : Exposition des recommandations en temps réel
• Historisation : Suivi longitudinal des recommandations déployées

Long terme¶

• Pricing dynamique : Ajustements en fonction de la demande
• Analyse concurrentielle : Intégration prix marché
• Optimisation multi-objectifs : Équilibre CA / marge / volume
• Recommandations proactives : Suggestions automatiques selon contexte

Support et ressources¶

Documentation technique¶

• README.md (ce document) : Vue d'ensemble et navigation
• Section Concepts : Compréhension des mécanismes
• Section Calculs : Formules et algorithmes
• Section Architecture : Structure technique
• Section Tables : Données et schémas
• Section Workflow : Guide opérationnel
• Section Capping : Stratégie de plafonnement
• Section Mapping : Enrichissement dimensionnel
• Section Exports : Résultats et analyses
• Section Guide d'utilisation : Mode d'emploi
• Section Troubleshooting : Résolution de problèmes

Fichiers de configuration¶

• config/pt2qe_config.json : Paramétrage des règles de calcul
• inputs/capping_type_client.csv : Cappings par segment
• corrections/capping_cubes_corrections.csv : Ajustements par cube (optionnel)

Outils de diagnostic¶

• Menu Option 5 : Vérification des prérequis (connexion, tables PT1CE, mappings)
• validate_mappings.py : Script de validation des correspondances PT0CE
• test_connection.py : Test de connexion Oracle

Logs et traçabilité¶

Tous les traitements génèrent des logs détaillés incluant : - Timestamp de chaque phase - Volumétrie traitée (nombre d'offres, clients, articles) - Statistiques de matching (MASTER vs NATIONAL) - Avertissements et erreurs éventuels - Durée d'exécution

Les logs sont affichés dans la console et peuvent être redirigés vers un fichier.

Conclusion¶

PT2QE est un système sophistiqué de pricing personnalisé qui transforme les corridors théoriques PT1CE en recommandations opérationnelles client × article. Sa force réside dans :

1. Double recommandation : RECO1 (repositionnement) et RECO2 (proportionnelle) pour maximiser les opportunités
2. Arbre de décision intelligent : 3 chemins adaptatifs selon le contexte
3. Cascade de cappings : Protection multi-niveaux contre les hausses excessives
4. Enrichissement transactionnel : Contexte historique de chaque relation commerciale
5. Triple positionnement : Vision complète de l'évolution tarifaire
6. Workflow itératif : Ajustements rapides jusqu'à convergence stratégique

Utilisation recommandée : 1. Exécuter PT1CE pour définir les corridors optimaux 2. Lancer PT2QE étape 1 pour les recommandations initiales 3. Analyser les résultats et identifier les ajustements nécessaires 4. Itérer avec l'étape 2 jusqu'à satisfaction 5. Générer l'export final avec l'étape 3 6. Déployer les nouvelles conditions de prix

Pour toute question ou besoin d'assistance, référez-vous aux différentes sections de documentation listées dans ce README.

Version : 1.0.0
Dernière mise à jour : Novembre 2025