Imputation des indices variétés dans les DDC

# Imputation des indices variétés dans les DDC ## Complément de l'actuelle procédure d'imputation ### Contexte Dans l'hypothèse qu'une variable du référentiel d'articles disparaisse (le problème pourrait également se poser ponctuellement avec une absence temporaire de remplissage de certaines variables du référentiel), plusieurs cas sont à distinguer selon si la variable qui disparait participe aux variables d'intérêt pour les classes d'équivalence ou aux règles de classement. | | Variable dans les variables d'intérêt : :heavy_check_mark: |Variable dans les variables d'intérêt : :x:| |-----| -------------------------------------------|---------------------------------------------| |**Variable dans les règles de classement** : :heavy_check_mark: | *Cas A* | *Cas B* | | **Variable dans les règles de classement** : :x: | *Cas C* | (Cas D) | La première étape de "redressement" est l'analyse métier de l'impact de la disparition de certaines variables et leur éventuel remplacement par d'autres : il faut modifier autant que possible les règles de classement afin que l'on soit capable de suivre les variétés (quand bien même les classes d'équivalence ne seraient plus définies). Note : le **cas D** correspond à une situation favorable où rien n'est censé changer. - Le **Cas A**, si la variable disparait ou n'est pas remplie : - Imapct *règles de classement* : l'EAN correspondant n'est plus classé dans sa "bonne" variété (il rejoint a priori dans la majorité des cas les NCA du poste, mais pourrait également se retrouver dans une variété proche si les autres variables "matchent" avec une variété non NCA) - Impact *classes d'équivalence* : l'EAN se voit attribuer un nouveau `numero_article_elargi` puisqu'il manque une variable pour "hacher" correctement la classe d'équivalence (si la variété change alors le numéro d'article élargi change également) - Le **Cas B**. Cas a priori peu fréquent mais qui existe - Imapct *règles de classement* : l'EAN correspondant n'est plus classé dans sa "bonne" variété (il rejoint a priori dans la majorité des cas les NCA du poste, mais pourrait également se retrouver dans une variété proche si les autres variables "matchent" avec une variété non NCA) - Impact *classes d'équivalence* : l'EAN n'est plus dans sa "bonne" classe d'équivalence dans la mesure où la variété changeant le numéro d'article élargi change également - Le **cas C** : - Impact *règles de classement* : l'EAN est bien classé dans sa "bonne" variété - Impact *classes d'équivalence* : comme une variable d'intérêt manque, on lui attribue un nouveau `numero_article_elargi`. ### Eléments généraux Préalable : dès lors que des variables disparaissent du référentiel d'articles qui ont un impact sur les règles de classement, il faut autant que possible modifier ces règles de classement pour pouvoir continuer à bien classer les EANs dans les variétés impactées. Ce qui suit est réalisé à la suite de la procédure actuelle d'estimation des micro-indices. Afin de conserver la logique de calcul des indices et d'agrégation actuelle, l'idée est d'imputer au niveau des micro-indices (pdv x variété). Les tables sur lesquelles il faut enregister des résultats sont les suivantes : - table Hive `entrepot_ddc.micro_indices` : la variable `indice` - table PostgreSQL `ddc.micro_indices` : la variable `indice_p2` et la variable `indicatrice_estimation` - tables PostgreSQL dans le schéma `ddc`, la table `micro_indices_yAAAAmM` correspondant au mois et année en cours Cette procédure s'ajoute aux étapes déjà existantes et, au même titre, sont exécutées systématiquement dès le calcul du provisoire [**peut-être à confirmer**]. Comme dans les autres cas, il sera possible d'annuler certains micro-indices. Une version "code" de cette procédure a été écrite (probablement pas de manière optimale et sans certains passages (étapes 5, 6, 10, 11, 14, 15 )) et est disponible sous Hive dans les requêtes enregistrées : "Procédure imputation". ### Initialisation La procédure prend comme donné le fait qu'un micro-indice existe pour le mois précédent. Or, certains micro-indices n'ont pas été calculés dans l'application (pour les variétés appartenant au poste `01.1.6.4.1`) mais imputées hors appli puis transmises aux applications "Old IPC" et Prisme. **Ces valeurs devront être rentrées en base Hive et PostgreSQL.**, avec dans PostgreSQL la valeur 99 pour la variable `indicatrice_estimation`. ### Procédure #### 1. Contrôle du caractère `NULL` de l'ensemble des micro-indices d'une variété On identifie les variétés pour lesquelles, actuellement l'indice variété est `NULL` dans la mesure où aucun micro-indice (à l'échelle pdv x var) n'est calculé. On note $v$ une telle variété, cette variété $v$ appartient à un poste $p$ : $v\in p$. #### 2. Vérification de l'existence au sein d'une variété identifiée $v$ d'EAN communs entre le mois en cours ($m$) et le mois précédent ($m-1$) Cela correspond au cas où les règles de classement fonctionnent toujours (**cas C**) ou ont été adaptées (**sous cas A** ou **sous cas B**), i.e. la variété n'a pas d'indices calculés mais a toujours des EAN qui lui sont attribués. On note $\mathcal{P}^{v,pdv}_m$ l'ensemble des EAN distincts appartenant à la variété $v$ le mois $m$, pour un point de vente $pdv$. Pour tous les **pdv** pour lesquels on a des EAN communs d'un mois à l'autre ($\mathcal{P}^{v,pdv}_{m-1} \cap \mathcal{P}^{v,pdv}_m\neq\emptyset$) : - **on passe à l'étape 3**. - **Sinon** on passe à l'étape 5. #### 3. Calcul d'un coefficient d'estimation de l'évolution d'un micro-indice basé sur un indice de Törnqvist Sur la base des EAN communs, on calcule le coefficient suivant, basé sur un indice de Törnqvist : $$\widehat{coeff}_{v,pdv}^{m-1,m} = \prod_{i\in\mathcal{P}^{v, pdv}_{m-1} \cap \mathcal{P}^{v, pdv}_m}\left(\frac{\bar{p}_i^m}{\bar{p}_i^{m-1}}\right)^{\frac{\alpha_i^{m-1}+\alpha_i^m}{2}}$$ où : - $i$ fait référence à un EAN - $\alpha_i^m = \frac{\bar{p}_i^m q_i^m}{\sum_{i\in\mathcal{P}^{v, pdv}_{m-1} \cap \mathcal{P}^{v, pdv}_m}\bar{p}_i^mq_i^m}$ est la part du CA que représente l'EAN $i$ pour le mois $m$ *dans l'ensemble du CA correspondant aux EAN communs aux deux mois dans le point de vente*. - $\bar{p}_i^m$ correspond au **prix unitaire** du produit $i$ défini par son EAN pour le $m$. Correspond à la formule donnée dans le guide utilisateur. *Note : en pratique, on calcule ce coefficient en passant par la transformation $\exp\log$* : $\widehat{coeff}_{v,pdv}^{m-1,m} = \exp\left(\sum_{i\in\mathcal{P}^{v, pdv}_{m-1} \cap \mathcal{P}^{v, pdv}_m}\frac{\alpha_i^{m-1}+\alpha_i^m}{2}\log \left(\frac{\bar{p}_i^m}{\bar{p}_i^{m-1}}\right)\right)$ *Rq : par construction* $\sum_i \alpha_i^m =1$ donc $\sum_i\frac{\alpha_i^{m-1}+\alpha_i^m}{2}=1$ #### 4. Mise à jour du micro-indice et de l'indicatrice d'estimation Suite à l'étape 3 : - le micro-indice $MI_{v,pdv}^m =\widehat{coeff}_{v,pdv}^{m-1,m}\times MI_{v,pdv}^{m-1}$ - la variable `indicatrice_estimation`de la table **Postgresql** `micro_indices` prend la valeur 4 pour indiquer la façon dont a été estimé le micro-indice. La qualité de cette estimation est moindre que le calcul habituel dans la mesure où on ne tient plus compte des classes d'équivalences (et donc pas des relances commerciales). Pour autant, au regard de la perte d'information générée par l'appauvrissement du référentiel, cela parait raisonnable : le périmètre des EAN est *a priori* toujours bien défini. #### 5. Mise à jour des micro-indices toujours à `NULL` avec la valeur régionale maintenant disponible Si un point de vente pour lequel le micro-indice de la variété est toujours `NULL` appartient à une région dans laquelle des micro-indices sont non `NULL`, alors on impute le micro-indice du point de vente, en appliquant au micro-indice du mois précédent l'évolution moyenne régionale, déduite des imputations de l'étape précédente. La variable `indicatrice_estimation` prend la valeur 5 dans la table **Postgresql `micro_indices`** Tous les micro-indices qui auront comme `indicatrice_estimation = 5` auront été estimés à partir des micro-indices qui avaient `indicatrice_estimation = 4`. - :arrow_right: *Cela correspond au début du bloc "Calcul des indices - IP3" dans le code transmis par Valérie*. Probablement qq adaptations à faire mais la logique est la même : "si j'ai un micro-indice NULL pour un pdv dans une variété $\times$ région alors que certains micro-indices de cette même variété $\times$ région sont non NULL alors je veux que ces micro-indices NULL soient imputés par la valeur moyenne (pondérée) des micro-indices non NULL de cette variété $\times$ région". #### 6. Mise à jour des micro-indices toujours à `NULL` avec la valeur nationale maintenant disponible Si un point de vente pour lequel le micro-indice de la variété est toujours `NULL` ainsi que pour tous les points de vente de la région correspondante (i.e. n'ont pas été estimés au cours des deux étapes précédentes), on impute les micro-indices correspondant en appliquant l'évolution moyenne nationale au micro-indice du mois précédent. La variable `indicatrice_estimation` prend la valeur 6 dans la table **Postgresql `micro_indices`** Tous les micro-indices qui auront comme `indicatrice_estimation = 6` auront été estimés à partir des micro-indices qui avaient `indicatrice_estimation = 4` et `indicatrice_estimation = 5`. - :arrow_right: *Cela correspond au début du bloc "Calcul des indices - IP3" dans le code transmis par Valérie*. Probablement qq adaptations à faire mais la logique est la même : "si j'ai un micro-indice NULL pour un pdv à l'issue de l'étape précédente (i.e. tous les micro-indices de la région sont NULL) dans une variété alors que certains micro-indices de cette même variété sont non NULL alors je veux que ces micro-indices NULL soient imputés par la valeur moyenne (pondérée) des micro-indices non NULL de cette variété à l'échelle nationale". #### 7. Détermination de l'ensemble des EAN pertinents à l'estimation sans variétés bien définies Dans le cas où à l'issue de l'étape 6, tous les micro-indices d'une variété sont toujours `NULL`, alors on détermine un novueau périmètre d'EAN sur lequel calculer une évolution. Cela correspond au cas où les variétés ne sont plus correctement définies, voire plus définies du tout, i.e. on n'est plus capable de répartir les EAN dans les variétés initiales (**cas A et cas B** pour lesquels les règles de classement n'ont pas pu être adaptées). Périmètre noté $\tilde{\mathcal{P}}^m_{v}$ : il correspond à l'ensemble des EAN rattachés à la variété $v$ encore présents dans les données au mois $m$. :arrow_right: ce sont tous les EAN qui avant la date $m^\star$ (date à laquelle le référentiel s'est appauvri) étaient classés dans la variété $v$ = *ceux dont on sait qu'ils correspondaient à la variété qu'on suivait* :warning: idéalement un contrôle sur la variable `gen` pourrait être utile. On l'omet par soucis de simplicité. On se restreint à ceux qui sont retrouvés dans les mois courants, sans pour autant être rattachés à la variété. $\tilde{\mathcal{P}}^m_{v} =\{\text{EAN classés dans la variété }v\text{ avant }m^\star\}\cap\{\text{EAN classés dans le poste de la variété }v\text{ après }m^\star\}$ **L'hypothèse** faite est que les EAN sont toujours présents sur le marché, au moins certains d'entre eux et que, donc, on peut s'appyer sur eux pour estimer une évolution. La qualité de cette évolution estimée est moindre en raison du plus petit périmètre d'estimation (les nouveaux EAN correspondants à la variété ne sont pas identifié et ici exclus), les EAN sur laquelle on s'appuie sont les EAN de la variété qui restent sur le marché. Or, ces EAN peuvent avoir des trajectoires de prix/quantités différentes en fin de vie sur le marché. Cela reste néanmoins préférable à travailler à l'échelle du poste sans essayer de distinguer les différentes variétés au sein de celui-ci (d'autant plus que cela correspond à une situation déjà dégradée). #### 8. Calcul d'un coefficient d'estimation à partir du périmètre $\tilde{\mathcal{P}}_{v}$ On introduit $\tilde{\mathcal{P}}^m_{pdv}$ l'ensemble des EAN disponibles dans un point de vente $pdv$ au cours d'un mois $m$, qui est la déclinaison à l'échelle du $pdv$ de $\tilde{\mathcal{P}}^m_{v}$. Soit $\tilde{\mathcal{P}}^{m-1,m}_{v, pdv} = \tilde{\mathcal{P}}^m_{pdv}\cap\tilde{\mathcal{P}}^{m-1}_{pdv}$ correspondant à l'ensemble des EAN pour un point de vente $pdv$ communs aux mois $m$ et $m-1$ appartenant au périmètre des EAN sur lesquels estimer une évolution. On reproduit le calcul utilisé à l'étape 3, mais sur ce nouveau périmètre : $$\widetilde{coeff}_{v,pdv}^{m-1,m} = \prod_{i\in\tilde{\mathcal{P}}^{m-1,m}_{v, pdv}}\left(\frac{\bar{p}_i^m}{\bar{p}_i^{m-1}}\right)^{\frac{\alpha_i^{m-1}+\alpha_i^m}{2}}$$ où $\alpha_i^m = \frac{\bar{p}_i^m q_i^m}{\sum_{i\in\tilde{\mathcal{P}}^{m-1,m}_{v, pdv}}\bar{p}_i^mq_i^m}$ soit la part du CA que représente l'EAN $i$ pour le mois $m$ *dans l'ensemble du CA correspondant aux EAN appartenant au périmètre retenu*. #### 9. Mise à jour du micro-indice et de l’indicatrice d’estimation Lorsqu'une valeur de $\widetilde{coeff}_{v,pdv}^{m-1,m}$ a été calculée, on met à jour : - le micro-indice jusque-là `NULL` comme $MI_{v,pdv}^m =\widetilde{coeff}_{v,pdv}^{m-1,m}\times MI_{v,pdv}^{m-1}$ - la variable `indicatrice_estimation` prend la valeur 7 dans la table **Postgresql `micro_indices`** #### 10. Mise à jour des micro-indices avec la valeur régionale potentiellement disponible Si le micro-indice est toujours à `NULL` mais qu'au moins une valeur est disponible dans la même région, alors on applique l'évolution moyenne de la région au micro-indice du mois passé. La variable `indicatrice_estimation` dans la table **Postgresql `micro_indices`** prend la valeur 8. Tous les micro-indices qui auront comme `indicatrice_estimation = 8` auront été estimés à partir des micro-indices qui avaient `indicatrice_estimation = 7`. :arrow_right_hook: même procédure qu'à l'étape 5. #### 11. Mise à jour des micro-indices avec la valeur nationale potentiellement disponible Si l'ensemble des micro-indices d'une région est toujours à `NULL` mais qu'au moins une valeur est disponible à l'échelle nationale, alors on applique l'évolution moyenne nationale au micro-indice du mois passé. La variable `indicatrice_estimation` dans la table **Postgresql `micro_indices`** prend la valeur 9. Tous les micro-indices qui auront comme `indicatrice_estimation = 9` auront été estimés à partir des micro-indices qui avaient `indicatrice_estimation = 7` et `indicatrice_estimation = 8`. :arrow_right_hook: même procédure qu'à l'étape 6. #### 12. Calcul d'un coefficient d'estimation à partir du périmètre $\tilde{\mathcal{P}}_{p \ni v}$ Si à l'issue des étapes précédentes, l'ensemble des micro-indices d'une variété sont à `NULL`, il s'agit du cas où : - les variétés ne sont plus correctement suivies - ET les EAN qui correspondaient à cette variété "en début d'année" ne sont plus sur le marché Autrement dit, il n'est plus possible d'affiner facilement le périmètre pour identifier des EAN qui se rapprocheraient de la variété - Note : on pourrait raffiner "un peu" - en retirant les EAN qui appartenaient aux NCA avant l'appauvrissement du référentiel : ceux-là, on sait qu'ils ne correspondent pas à notre cible. Ce raffinement semble complexifier la tâche pour un gain de qualité incertain - en retirant les éventuels EAN "correctement" classés dans d'autres variétés du poste. Pour des raisons de simplicité, on s'en tient à l'entièreté du poste. Cela correspond aux **cas A et cas B** pour lesquels les règles de classement n'ont pas pu être adaptées et pour lesquels il n'y a plus d'EAN précédemment correctement identifiés sur le marché. On définit $\tilde{\mathcal{P}}^m_{p \ni v}=\{EAN \in p | v\in p, m\}$ qui rassemble l'ensemble des EAN appartenant au poste auquel appartient la variété $v$ d'intérêt, pour un mois donné $m$. Cela correspond au cas où l'ensemble des variétés du poste ne sont plus définies et aucun EAN précédemment bien attribué à une variété n'est encore sur le marché. Soit $\tilde{\mathcal{P}}^{m-1,m}_{p\ni v, pdv} = \tilde{\mathcal{P}}^{m-1}_{p \ni v, pdv}\cap\tilde{\mathcal{P}}^m_{p \ni v, pdv}$ correspondant à l'ensemble des EAN pour un point de vente $pdv$ communs aux mois $m$ et $m-1$ appartenant au périmètre des EAN sur lesquels estimer une évolution - périmètre correspondant à l'ensemble du poste. On reproduit le calcul utilisé à l'étape 3, mais sur ce nouveau périmètre $$\widetilde{\widetilde{coeff}}_{p\ni v,pdv}^{m-1,m} = \prod_{i\in\tilde{\mathcal{P}}^{m-1,m}_{p\ni v, pdv}}\left(\frac{\bar{p}_i^m}{\bar{p}_i^{m-1}}\right)^{\frac{\alpha_i^{m-1}+\alpha_i^m}{2}}$$ où $\alpha_i^m = \frac{\bar{p}_i^m q_i^m}{\sum_{i\in\tilde{\mathcal{P}}^{m-1,m}_{p\ni v, pdv}}\bar{p}_i^mq_i^m}$ soit la part du CA que représente l'EAN $i$ pour le mois $m$ *dans l'ensemble du CA correspondant aux EAN appartenant au périmètre retenu*. #### 13. Mise à jour du micro-indice et de l’indicatrice d’estimation Lorsqu'une valeur de $\widetilde{\widetilde{coeff}}_{p\ni v,pdv}^{m-1,m}$ a été calculée, on met à jour : - le micro-indice jusque-là `NULL` comme $MI_{v,pdv}^m =\widetilde{\widetilde{coeff}}_{p\ni v,pdv}^{m-1,m}\times MI_{v,pdv}^{m-1}$ - la variable `indicatrice_estimation` dans la table **Postgresql `micro_indices`** prend la valeur 10. #### 14. Mise à jour des micro-indices avec la valeur régionale potentiellement disponible Si le micro-indice est toujours à `NULL` mais qu'au moins une valeur est disponible dans la même région, alors on applique l'évolution moyenne de la région au micro-indice du mois passé. La variable `indicatrice_estimation` prend la valeur 11. Tous les micro-indices qui auront comme `indicatrice_estimation = 11` auront été estimés à partir des micro-indices qui avaient `indicatrice_estimation = 10`. #### 15. Mise à jour des micro-indices avec la valeur nationale potentiellement disponible Si l'ensemble des micro-indices d'une région est toujours à `NULL` mais qu'au moins une valeur est disponible à l'échelle nationale, alors on applique l'évolution moyenne nationale au micro-indice du mois passé. La variable `indicatrice_estimation` prend la valeur 12. Tous les micro-indices qui auront comme `indicatrice_estimation = 12` auront été estimés à partir des micro-indices qui avaient `indicatrice_estimation = 10` et `indicatrice_estimation = 11`. #### 16. Imputation à la main. Si jamais à l'issue de cette procédure, une variété a toujours l'ensemble de ses micro-indices à `NULL` alors une imputation à la main par le métier doit être faite. L'imputation est réalisée "à la main", hors appli. Le code de `indicatrice_estimation` est alors 99. ### En pratique En pratique, il faudra prévoir : - des requêtes adapatées pour tenir compte de ces nouvelles façons d'imputer au moment de l'analyse des indices - modifier le guide utilisateur en conséquence ## Brouillon / réflexion / échanges avec SNDIO ### Contexte Dans l'hypothèse qu'une variable du référentiel d'articles disparaisse (le problème pourrait également se poser ponctuellement avec une absence temporaire de remplissage de certaines variables du référentiel), plusieurs cas sont à distinguer selon si la variable qui disparait participe aux variables d'intérêt pour les classes d'équivalence ou aux règles de classement. | | Variable dans les variables d'intérêt : :heavy_check_mark: |Variable dans les variables d'intérêt : :x:| |-----| -------------------------------------------|---------------------------------------------| |**Variable dans les règles de classement** : :heavy_check_mark: | *Cas A* | *Cas B* | | **Variable dans les règles de classement** : :x: | *Cas C* | (Cas D) | Description des cas : - Le "cas D" n'est pas intéressant : tout est censé bien se passer dans ce cas-là. - Le **Cas A**, si la variable disparait ou n'est pas remplie : - Imapct *règles de classement* : l'EAN correspondant n'est plus classé dans sa "bonne" variété (il rejoint a priori les NCA du poste) **=> cela dépend des variables qui disparaissent – l’article pourrait être classé dans une autre variété si les autres variables « matchent » avec une variété non NCA** => **ça c'est embêtant !** Il faudrait qu'en règle générale, ces cas soient étudiés de près afin de les éviter au maximum. Par ailleurs, est-ce que généralement, dans ce cas rare, les EAN ne vont pas tomber dans une autre variété du même poste ? - Impact *classes d'équivalence* : l'EAN se voit attribuer un nouveau `numero_article_elargi` égal à son EAN puisqu'il manque une variable pour "hacher" correctement la classe d'équivalence **=> le numero_article_elargi est égal à l’ean si la caractéristique volume_total n’est pas renseignée. Si volume_total n’est pas vide, cela peut être un nouveau numero_article_elargi recalculé en « hachant » les nouvelles infos. A noter que si volume_total reste inchangé et que le nouveau numéro gen n’est pas supérieur à l’ancien, le numero_article_elargi n’est pas modifié.** - Le **Cas B**. Cas a priori très peu fréquent.. **=> peu fréquent mais cas qui existe – Exemple : famille ‘0279’ (CAHIERS AGENDAS REPERTOIRES ET CARNETS) – type_de_cahier est présent dans les règles de classement mais pas dans les variables d’intérêt** - Impact *règles de classement* : l'EAN n'est plus classé dans sa "bonne" variété (il va a priori dans les NCA du poste) **=> idem que le cas A** - Impact *classes d'équivalence* : **à confirmer** : l'EAN est bien dans la bonne classe d'équivalence avec le bon numéro d'article élargi. **=> si la variété a changé, la valeur du numéro d’article élargi peut changer puisque la variété participe au calcul du numéro d'article élargi** - Le **cas C** : - Impact *règles de classement* : l'EAN est bien classé dans sa "bonne" variété **=> oui** - Impact *classes d'équivalence* : comme une variable d'intérêt manque, on lui attribue un nouveau `numero_article_elargi` égal à son EAN. **=>idem que le cas A** **Questions pour Valérie :** - Est-ce qu'une classe d'équivalence définie par un numéro d'article élargi égal à un EAN (classe d'équivalence qui ne rassemble donc qu'un EAN) peut être un produit remplaçant ? - N'a pas l'air d'être le cas dans les données... (en regardant dans la table `remplacements_definitifs`) ``` select * from entrepot_ddc.remplacements_definitifs where length(numero_article_elargi_remplacant) < 14 and mois in (6,7,8) ; ``` - Est-ce qu'un remplacement peut se faire **s'il n'y a pas de période de recouvrement** ? - Serait plutôt attendu qu'il faut une période de recouvrement - Et donc dans notre cas, comme il n'y a pas de recouvrement (et que les "nouveaux" `numero_article_elargi` ne sont pas comme attendus), il faut imputer. => **je ne comprends pas ta question...** => **j'ai trouvé ma réponse dans un des docs que tu m'as transmis par mail (des échanges de Pierre Vernedal) : pour être remplaçant lors d'un mois $m$, il faut que le produit ait été présent en $m$ et en $m-2$.** - Si aucun remplacement n'est possible : que se passe-t-il ? Pas d'indice calculé, c'est sûr, mais dans les tables qui gardent trace des remplacements effectués, que se passe-t-il ? - Suite au remplissage moindre du référentiel d'articles la semaine du 11/09, avec tous les EAN dont le `volume_total` n'était pas renseigné qui ont vu leur `numero_article_elargi = EAN`, est-ce que maintenant que le référentiel d'articles est de nouveau "bien rempli", ils vont retrouver leur `numero_article_elargi` initial ? - J'imagine que oui : la variable `volume_total` a changé donc même si la variable `gen` n'a pas changé, ce numero est mis à jour et reprend sa valeur intiale. Permettant donc de calculer un prix moyen pour le mois donné, puis un indice élémentaire, puis un micro-indice... **C'est exactement cela** - En regardant dans les données le cas `EAN = 3173310011749`, il semblerait que... *pas eu le résultat de la requête* :cry: ``` SELECT distinct date_vente, date_chargement, ean, numero_article_elargi, weekofyear(date_vente) as semaine_vente, weekofyear(date_chargement) as semaine_chargement FROM entrepot_ddc.donnees_caisse where ean = "3173310011749" and date_vente > "2023-08-31"; ``` Quand on requête sur la table donnees_caisse, il est fortement conseillé d'utiliser les variables de partitionnement : en ajoutant l'année et le mois dans ta requête, le temps de traitement a été réduit à 4mn : ``` SELECT distinct date_vente, date_chargement, ean, numero_article_elargi, weekofyear(date_vente) as semaine_vente, weekofyear(date_chargement) as semaine_chargement FROM entrepot_ddc.donnees_caisse where ean = "3173310011749" and mois=9 and annee=2023; ``` Et voici le résultat : | date_vente | date_chargement | ean | numero_article_elargi|semaine_vente|semaine_chargement | -------- | -------- | -------- |-------- |-------- |-------- |2023-08-28|2023-08-30|3173310011749|145840533136533048770522022150802467199_1|35|35 |2023-08-29|2023-09-01|3173310011749|145840533136533048770522022150802467199_1|35|35 |2023-08-30|2023-09-01|3173310011749|145840533136533048770522022150802467199_1|35|35 |2023-08-31|2023-09-02|3173310011749|145840533136533048770522022150802467199_1|35|35 |2023-09-01|2023-09-03|3173310011749|145840533136533048770522022150802467199_1|35|35 |2023-08-31|2023-09-03|3173310011749|145840533136533048770522022150802467199_1|35|35 |2023-09-01|2023-09-04|3173310011749|145840533136533048770522022150802467199_1|35|36 |2023-09-02|2023-09-04|3173310011749|145840533136533048770522022150802467199_1|35|36 |2023-09-03|2023-09-05|3173310011749|145840533136533048770522022150802467199_1|35|36 |2023-09-04|2023-09-06|3173310011749|145840533136533048770522022150802467199_1|36|36 |2023-09-05|2023-09-07|3173310011749|145840533136533048770522022150802467199_1|36|36 |2023-09-06|2023-09-08|3173310011749|145840533136533048770522022150802467199_1|36|36 |2023-09-07|2023-09-09|3173310011749|145840533136533048770522022150802467199_1|36|36 |2023-09-08|2023-09-10|3173310011749|3173310011749|36|36 |2023-09-08|2023-09-11|3173310011749|3173310011749|36|37 |2023-09-09|2023-09-11|3173310011749|3173310011749|36|37 |2023-09-10|2023-09-12|3173310011749|3173310011749|36|37 |2023-09-11|2023-09-13|3173310011749|3173310011749|37|37 |2023-09-12|2023-09-14|3173310011749|3173310011749|37|37 |2023-09-11|2023-09-14|3173310011749|3173310011749|37|37 |2023-09-13|2023-09-16|3173310011749|3173310011749|37|37 |2023-09-14|2023-09-16|3173310011749|3173310011749|37|37 |2023-09-15|2023-09-17|3173310011749|145840533136533048770522022150802467199_1|37|37 |2023-09-14|2023-09-17|3173310011749|145840533136533048770522022150802467199_1|37|37 |2023-09-17|2023-09-19|3173310011749|145840533136533048770522022150802467199_1|37|38 |2023-09-14|2023-09-19|3173310011749|145840533136533048770522022150802467199_1|37|38 |2023-09-15|2023-09-19|3173310011749|145840533136533048770522022150802467199_1|37|38 |2023-09-16|2023-09-19|3173310011749|145840533136533048770522022150802467199_1|37|38 |2023-09-17|2023-09-20|3173310011749|145840533136533048770522022150802467199_1|37|38 |2023-09-18|2023-09-20|3173310011749|145840533136533048770522022150802467199_1|38|38 ### Compléments d'info sur les modifications du référentiel d'articles, du numéro d'article élargi. Sur la **modification du référentiel d’articles** - Un article du référentiel est modifié quand : - Les nouvelles caractéristiques sont différentes - OU le nouveau gen est supérieur à l’ancien - OU le nouveau numéro d’article élargi est différent - OU le classement en types_biens est différent (ce classement n’est pas actif pour l’instant…) Sur la **mise à jour du numéro d’article élargi**. - Il est modifié quand : - L’article n’appartient pas au panier - OU L’article appartient au panier ET le nouveau gen est supérieur à l’ancien - OU la caractéristique volume_total a changé Sur le **calcul du numéro d’article élargi**. Il est calculé si : - la famille a des variables d'intérêt - l'article est dans le champ de l'indice (type_ean = CH) - le code promotion est égal à 0 ou 1 - la caracteristique "volume_total" est renseignée **Si une de ces conditions n’est pas remplie, numero_article_elargi=ean**. Valeur du numéro d’article élargi = "hachage" des variables suivantes - les valeurs des caractéristiques de l'article qui sont mentionnées dans les variables d'intérêt de la famille - la variété de l'article calculée avec la règle de classement - le conditionnement de l'article mentionné dans la caractéristique "volume_total" (ml, gr, lt, ct, mt...) du referentiel_articles_actif ### Stratégies d'imputation en cours de réflexion Si la réponse à ces deux premières questions est **non**, alors : - Dans le **cas C**, il suffit à l'échelle du micro-indice (variete x point de vente), d'estimer un coefficient d'évolution mensuelle qui sera appliqué à l'indice du mois précédent. On estime cette évolution avec un indice de Törnqvist sur l'ensemble des EAN présents au mois courant et mois précédent *au niveau de la variété* (puisque les observations continuent à être bien classées). - Dans le **cas B**, à voir selon le `numero_article_elargi` qui est attribué. De toute façon, ne concernera que peu de cas. - Dans le **cas A**, les observations ne sont pas correctement classées dans les variétés et `numero_article_elargi = EAN`. Dans ce cas (si la procédure d'imputation actuelle n'a pas fonctionné), on estime un coefficient d'évolution au niveau du poste avec un indice de Törnqvist de la même façon que pour le cas C mais sur l'ensemble des EAN du poste (i.e. y compris de la variété NCA). - Si envisageable, il serait intéressant de retirer du poste (et donc de la variété NCA), l'ensemble des EAN qui étaient déjà présents dans les NCA depuis plusieurs mois. A voir selon la complexité que ça ajoute. - Autre façon de voir les choses : ne considérer que les EAN qui viennent d'apparaitre pour la première fois dans la variété NCA. - Si c'est effectivement possible, il faudrait ajouter un contrôle sur le fait qu'il faut appliquer cette restriction uniquement le premier mois d'imputation et ne pas "enrichir" la restriction les mois d'imputation suivants.

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.