XL 2010 Conversion date MJA / JMA

[F22Raptor]

Bonjour à tous,
Notre progiciel interne génère un fichier Excel avec en en-tête une date.
Lorsque celle-ci peut être ambigüe (3/04 ou 4/03), elle est présentée "à l'envers".
Par exemple, le 5 avril (05/04/17) se présente sous la forme 4 mai (04/05/17).

MAIS : ce n'est pas une question de format de cellule.

Pour régler ce problème, il faudrait faire un DONNEES/CONVERTIR, et choisir "Date MJA".
Le souci étant qu'en dessous de cette date en en-tête, j'ai des données qui ne sont pas des dates ...
DONNEES/CONVERTIR ne s'applique qu'à la totalité de la colonne, et modifie donc mes chiffres !

Une solution pour faire reconnaître une cellule en MJA ?

EDIT : le DONNEES / CONVERTIR marche en manuel, mais pas quand je le lance par macro :
Selection.TextToColumns Destination:=Range("G1"), FieldInfo:=xlMDYFormat

 

[Dranreb]

Bonjour.

Function DateFr(ByVal DateUS As String) As Date
Dim TD() As String
TD = Split(DateUS), "/")
DateFr = DateSerial(TD(2), TD(0), TD(1))
End Function

Function DateHeuFr(ByVal DateHeuUS As String) As Date
Dim P As Long
P = InStr(DateHeuUS, " ")
DateHeuFr = DateFr(Left$(DateHeuUS, P - 1)) + TimeValue(Mid$(DateHeuUS, P + 1))
End Function

 

[F22Raptor]

Merci Dran.
Ton code ne pose t il pas de souci lorsque la date est non ambigüe (28/03 par exemple) ? Cela ne va pas tenter de créer une date 03/28 ?

 

[Dranreb]

Normalement non, si c'est toujours une date US qui est portée dans les données.
Si c'est en fait une date française il faut DateSerial(TD(2), TD(1), TD(0))

 

[Modeste geedee]

Bonsour®

Bonjour à tous,

MAIS : ce n'est pas une question de format de cellule.
Pour régler ce problème, il faudrait faire un DONNEES/CONVERTIR, et choisir "Date MJA".
Le souci étant qu'en dessous de cette date en en-tête, j'ai des données qui ne sont pas des dates ...
DONNEES/CONVERTIR ne s'applique qu'à la totalité de la colonne, et modifie donc mes chiffres !

Une solution pour faire reconnaître une cellule en MJA ?

EDIT : le DONNEES / CONVERTIR marche en manuel, mais pas quand je le lance par macro :
Selection.TextToColumns Destination:=Range("G1"), FieldInfo:=xlMDYFormat

voir si ceci peut t'aider à détecter le format et agir en conséquence:

 

[Modeste geedee]

Bonjour à tous,
Notre progiciel interne génère un fichier Excel avec en en-tête une date.
Lorsque celle-ci peut être ambigüe (3/04 ou 4/03), elle est présentée "à l'envers".
Par exemple, le 5 avril (05/04/17) se présente sous la forme 4 mai (04/05/17).

MAIS : ce n'est pas une question de format de cellule.

Pour régler ce problème, il faudrait faire un DONNEES/CONVERTIR, et choisir "Date MJA".
Le souci étant qu'en dessous de cette date en en-tête, j'ai des données qui ne sont pas des dates ...
DONNEES/CONVERTIR ne s'applique qu'à la totalité de la colonne, et modifie donc mes chiffres !

Une solution pour faire reconnaître une cellule en MJA ?

EDIT : le DONNEES / CONVERTIR marche en manuel, mais pas quand je le lance par macro :
Selection.TextToColumns Destination:=Range("G1"), FieldInfo:=xlMDYFormat

Encore un stigmate du fameux "Entry behavior By Design" ....

 

[F22Raptor]

Normalement non, si c'est toujours une date US qui est portée dans les données.
Si c'est en fait une date française il faut DateSerial(TD(2), TD(1), TD(0))

je l'ai adaptée en macro :

Dim DateUS As String
Dim TD() As String
DateUS = Range("G1")
TD = Split(DateUS, "/")
Range("G1") = DateSerial(TD(2), TD(0), TD(1))

Et quand la date est "ambigüe", ça fonctionne.
Mais quand la date est non ambigüe (31/03), elle est d'office bien écrite dans mon fichier.
Du coup, ton code inverse le mois et le jour, alors qu'il n'y a pas lieu de le faire.
Je vais mettre une condition : "si les deux premiers chiffres sont > à 12, alors ne rien faire"

 

[Dranreb]

Voir poste #4.
Ça doit être une date française où il ne faut en fait jamais inverser le jour et le mois.
Et cette inversion résulte alors d'un vieux bogue dans Excel, que ma Function évite en principe en mettant les éléments dans l'ordre 2, 1, 0.

 

[F22Raptor]

Bizarre : bon, en attendant, avec la condition "Si les deux premiers chiffres sont > 12, alors ne rien faire", ça tourne correctement selon que la date est bien reconnue ou pas.

On verra si ça bugge à l'avenir ...

Merci !

 

[Dranreb]

Inutile de faire ce test bon sang ! Prendre toujours TD(1) comme mois et TD(0) comme jour.

 

[F22Raptor]

Inutile de faire ce test bon sang ! Prendre toujours TD(1) comme mois et TD(0) comme jour.

je viens encore de tester :

TD2 TD1 TD0
n'a pas d'effet sur une date type 04/03 (au lieu de 03/04)
colle à droite une date type 31/03 (elle devait être reconnue comme texte, et donc collée à gauche)

TD2 TD0 TD1
fonctionne sur une date 04/03
transforme le 31/03/2017 en 03/07/2019 !

 

[chris]

Bonjour à tous

Dans la plupart des cas les fichiers exportés sont en réalité des fichiers texte.
A tenter : remplacer l'extension pat .txt puis ouvrir le fichier dans Excel : un assistant permet de préciser le type de chaque champ ainsi que les formats de date et donc d'importer correctement.

Si cela fonctionne, on pourra automatiser le paramétrage d'import.

 

[Dranreb]

Mais qu'est ce qui est faux, à la fin ?
Si c'est déjà ce qui est porté dans les données, évidemment on ne peut rien faire !
Il faut agir à la source.

 

[Modeste geedee]

Bonsour®

Notre progiciel interne génère un fichier Excel avec en en-tête une date.

!!! Fournir ici le fichier tel que issu du progiciel et avant toutes autres manipulations (renommage, lecture, conversion) !!!

 

[F22Raptor]

Bonsour®

!!! Fournir ici le fichier tel que issu du progiciel et avant toutes autres manipulations (renommage, lecture, conversion) !!!

Compliqué : on n'a pas le droit de sortir des fichiers internes.

Par ailleurs, cela n'aiderait pas forcément !
Quand j'ouvre avec VBA Workbooks.Open, j'ai mes inversions m/j sur la date.
Mais quand j'ouvre par l'explorateur, j'ai un message à l'ouverture "le format du fichier est différent de celui spécifié par l'extension. Souhaitez vous ouvrir le fichier".
Quand je clique sur OUI, ça s'ouvre, et là le format de date est OK !!!
(peut-être une histoire de fichier CSV avec une extension XLS).

Bon, en attendant, un mélange de la soluce de Dran, et la condition sur les deux premiers chiffres, fonctionne correctement.
On verra si je tombe sur des dates particulières qui buggent.