Discussion :

[supet]

Bonjour,
Si une donnée est erronée dans le système de gestion mais que celle-ci ne peut être corrigée.
Quelle est la meilleure solution pour que la restitution soit tout de même correcte ?

Table de transco lors de l'alim ?
Règle de gestion dans le DWH ?
Rustine sur les rapports un par un ?
Autre ?

Merci de votre réponse,
Bonne journée,

[Waldar]

L'idéal c'est de remonter l'information à la source et la faire corriger.
"Garbage In Garbage Out" disent les anglosaxons.
Quand des données pourries remontent à la direction financière, en général ça fait réagir.

Si ce n'est pas possible, dans ce cas là il vaut mieux utiliser une table de transcodage dans votre DWH, avec les problèmes induits : qui la maintient, comment, tous les combien de temps, historisation et cetera.

[supet]

Merci,
L'idéal est en effet de corriger à la source...mais là c'est impossible.

Je suis favorable aussi à une table de transco dans le DWH (ou juste avant), mais cela ne semble pas être l'avis des équipes informatiques.
Qui je pense craignent pour les points que vous citez (maintien de cette table).

La proposition simple est d'agir sur les rapports je le conçois mais cela ne rendra pas correct tous les rapports volatiles et les futurs rapports génériques si nous oublions cette rustine.

Merci de votre contribution,
Bonne journée,

[Elros]

La proposition simple est d'agir sur les rapports je le conçois mais cela ne rendra pas correct tous les rapports volatiles et les futurs rapports génériques si nous oublions cette rustine.

En choisissant cette solution, le jour où en amont les données seront corrigées, en aval vous passerez un temps fou à faire de la mise jour de rapports.

Elros

[cgauder]

Bonjour

Nous avons été confrontés au même problème pour des coûts de revient manifestement erronés.
Voici la méthode employée, qui a pour seul avantage de fonctionner et de ne pas faire appel à une modif de reports.
MyReport 7 (passage en V8 ce weekend !) sur base SQL server

1/ les données de bases provenant d'un ERP Divalto sont chargées par ODBC tous les matins
2/ un report excel est généré en automatique pour l'ensemble des ventes du jour, avec ref article, prix de vente, prix de revient "initial" et taux de marge par rapport à ce prix de revient
3/ le report excel est analysé tous les matins par des personnes dédiées, une la valeur de prix de revient corrigé est saisie si nécessaire en dernière colonne du tableau
4/ le report excel est sauvegardé en CSV par une macro (qui supprime aussi toutes les lignes sans corrections), dans un dossier spécifique, avec nommage fixe
5/ une table de "Correction CR" est alimentée en mode cumul, par le lecture du fichier CSV du point 4
6/ un champ "CR réel" est alimenté par une formule qui permet de choisir le CR corrigé si il existe, ou le CR initial si il n'y a eu aucune correction

Avantages :
* pour les reports, un seul champ à utiliser pour le CR (qu'il soit corrigé ou non)
* gestion uniquement de quelques lignes d'écart par jour
* au pire si besoin de corriger un cr corrigé dans la table spécifique, on peut toujours le faire par du SQL sur la table de "Correction CR"

si necessaire je pourrai vous faire quelques copies d'écran, en espérant avoir été assez clair

Cdlt
Christophe