Discussion :

[antoya]

Bonjour,

J'ai une base de donnée externe ( venant d'un CRM dont je n'ai pas accès ) ayant des dates et d autres informations de type Non prénom etc..
Excel m'affiche des données datant du 29 février 2019 mais cette date n'existe pas.
Ma question est : Est ce que toutes les dates après le 29 février 2019 ont été décalées par exemple le 1er mars est enfait le 2 mars etc...?
Je ne sais pas si je suis bien clair mais devant nettoyer cette base de données je suis dans une impasse.

[78chris]

Bonjour

Excel ne t’affichera en aucun cas le 29/02/2019

C'est donc du texte et non une date...

Donc voir comment gérer cela en amont

[Patrice740]

Bonjour le Fil,

J'ajouterais à la réponse de Chris (salut ), comme il s'agit avec certitude de données au format texte, c'est ta base de données externe qui fournit des données erronées.

[unparia]

Bonjour à tous
Il semble que la question que pose antoya est :

Ma question est : Est ce que toutes les dates après le 29 février 2019 ont été décalées par exemple le 1er mars est enfait le 2 mars etc...?

Si tel est bien le cas (si, donc, j'ai bien compris), la crainte d'antoya est que les dates qui suivent cette date erronée ont été décalées d'un jour dans la base importée.
Et je ne vois alors pas (le cas échéant, donc et sans avoir accès au code qui a généré ces données) comment lui répondre en connaissance de cause.

[Patrice740]

Effectivement, comme le 29 février 2019 n'existe pas, il est difficile savoir à quelle date cela correspond, et donc difficile de savoir si le 1er mars 2019 est le jour suivant ou le même jour.
Il y a une certitude : Excel n'y est pour rien, la réponse se trouve dans la base de données source.

[unparia]

Bonjour Patrice

la réponse se trouve dans la base de données source.

Ce n'est même pas certain.
J'observe que ce sont là les données provenant de l'utilisation d'un CRM (donc un outil spécialisé en matière de gestion et suivi de relations avec la clientèle ...en général bien fait).
Le pire qui serait à craindre serait alors une manipulation "ultérieure" et peu "franche" de la base de données correspondant à une année bissextile

EDIT : une question pour toi, antoya.
As-tu dans cette base des données datées du 22 avril 2019 ? Même question , dans la foulée, pour le 21 avril 2019.

[Thumb down]

Bonjour,
Il est incontestable que tes dates sont toutes erronées. Le 29/02/2019 suffit pour s'en convaincre !

Si les date sont décalés d'1 jour il est fort à parier que tu auras le 30/02/2020!

Je ne vois pas de solution à ton problème sauf renvoyer, avec véemance, les données à l'expéditeur.

Une extraction BO?

[antoya]

Je viens de regarder ces fameuses dates du 29 sont au format standard.
Il n' y a aucune donnée au 30 février 2019 :'( ce qui complique l'affaire.

Merci à tous pour vos réponses !
cas particulier donc pas de "best practice"? Mettre toutes ces dates au 28 février 2019 ? Toutes les supprimer ?

[antoya]

Bonjour Patrice

Ce n'est même pas certain.
J'observe que ce sont là les données provenant de l'utilisation d'un CRM (donc un outil spécialisé en matière de gestion et suivi de relations avec la clientèle ...en général bien fait).
Le pire qui serait à craindre serait alors une manipulation "ultérieure" et peu "franche" de la base de données correspondant à une année bissextile

EDIT : une question pour toi, antoya.
As-tu dans cette base des données datées du 22 avril 2019 ? Même question , dans la foulée, pour le 21 avril 2019.

Cela s'arrête au 07/04/2019

[78chris]

Bonjour

Je viens de regarder ces fameuses dates du 29 sont au format standard.

Le format ne présage pas du type de données : ce n'est qu'un habillage et l'habit ne fait pas le moine...

[Pierre Dumas]

Bonsoir

On parle du 29/02/2019 qui n'existe pas. Mais il faudrait savoir si dans cette fameuse base de données, il n'y aura pas aussi un 29/02/2018, qui lui non plus n'existe pas. Et regarder comment sont les dates suivantes si cette date existe (ou pas). Si cela se trouve, les données d'avant le 29/02/2019 ne sont pas très fiables non plus.

Ce ne sont que des hypothèses...

Bonne soirée

Pierre Dumas

[Pierre Fauconnier]

Salut.

Il faudrait rapprocher d'une façon ou d'une autre tes données (celles du 29/02/19 mais également celles d'autres dates) avec les données natives du CRM en question pour voir où le bât blesse. Cela permettrait de mettre éventuellement le CRM hors cause, ou au contraire de l'incriminer (je suis nettement moins optimiste que unparia sur le fait qu'en général un CRM est bien fait, n'importe quel bidouilleur du dimanche appelant son "truc" CRM ou ERP). Peux-tu dire de quel CRM les données proviennent?

Si les données sont correctes dans le CRM, il faut progresser jusqu'à Excel en étudiant les étapes d'extraction et de préparation en amont d'Excel. Car quoi qu'il en soit, dans Excel, et pour enfoncer le clou sur lequel d'autres ont déjà tapé, 29/02/2019 ne peut être que du texte.

Perso, je ne me prendrais pas trop la tête à tester des jours fériés comme le lundi de Pâques (qui a dit qu'il était interdit d'envoyer un mail ou d'effectuer n'importe quelle action via un crm le lundi de Pâques ou un jour férié?) ou à supposer que les autres dates sont décalées ou pas. Des données qui arrivent dans Excel avec un 29/02/2019 ne sont pas fiables, même si les autres dates peuvent éventuellement être correctes, et si elles ne sont pas fiables sur la date, il n'y a pas de raison qu'elles soient a priori fiables sur le reste du traitement.

Bon courage!

[...]
J'observe que ce sont là les données provenant de l'utilisation d'un CRM (donc un outil spécialisé en matière de gestion et suivi de relations avec la clientèle ...en général bien fait).[...]

Qu'est-ce qu'il ne faut pas lire, quand même... N'importe quel crétin qui crée une liste de ses clients sur Excel peut y coller l'étiquette CRM... Faut vraiment être en déconnexion totale avec la réalité de terrain pour écrire une co*** pareille... Enfin, tu as fait ma journée, ce n'est pas tous les jours.

[unparia]

Si ont été manipulées les données mêmes de la base de données créée par le CRM (par exemple en modifiant les champs date, voire, pour certains CRM, un seul champ "millésime" éventuellement prévu, je vois mal ce qui permettra de déterminer avec assurance ceci ou cela.
Une très forte présomption (même si rien n'est "interdit") de ce type de manipulation existerait toutefois en présence, entre autres, de constats :
- d'activités apparentes systématiques tous les jours non ouvrés
- de non activités apparentes tous les mêmes jours de la semaine

[Pierre Fauconnier]

C'est juste du blabla pour se gratter. On sait que les dates ne sont pas (toutes) correctes. Vérifier dans Excel ceci ou cela ne fera éventuellement que le confirmer, mais on ne sera pas plus avancé sur le traitement à apporter.

En ce qui concerne les jours fériés, perso, je travaille pour des boites internationales pour lesquelles la notion même de jour férié ne veut rien dire car leurs bureaux sont répartis aux quatre coins du monde. De plus, le e-commerce amène les CRM à créer des transactions à toute heure du jour ou de la nuit, n'importe quel jour de l'année. Regarder un problème de dates de son bout de lorgnette franco-français ou uniquement sur base d'une présomption d'absence d'activités tel ou tel jour n'a pas beaucoup de sens, selon moi, et n'apporte rien de plus à un problème déjà connu.

Face à ce genre de problème, il me semble que la seule façon est de remonter à la source (le CRM), de s'assurer de la cohérence des dates dans le CRM, et si les dates sont cohérentes dans le CRM, d'analyser le traitement qui en est fait entre le CRM et Excel. Après avoir déterminé les erreurs de traitement des dates, on pourra appliquer une méthode pour corriger le tir, normalement à la source de l'erreur, et si pas possible, en envisageant la correction dans Excel.

Mais cela ne peut se faire qu'en ayant déterminé avec précision la méthode qui a conduit à l'erreur, et pas sur base de présomptions ou de suppositions de décalages suite à des constatations hasardeuses et aléatoires.

[Patrice740]

Il n'y a qu'un seule façon de s'assurer que les données fournies par le CRM sont correctes : les comparer avec les données sources.
Je répète donc ce que je dis depuis le début : la réponse se trouve dans la base de données source.
Tout le reste n'est qu'élucubration !

[Pierre Fauconnier]

[...]