Microsoft 365 Transformation et consolidation en VBA

[Amilo]

Bonjour le forum,

Je sollicite svp votre aide pour une solution en VBA,
Je vous mets en pièces jointes les fichiers exemples et les explications ci-dessous :

- J'ai dans un dossier nommé "Dossier 03_2021" comportant plusieurs fichiers avec une table de structure identique
J'ai mis 2 fichiers exemples ("Fichier A.xlsm" et "Fichier B.xlsm" mais il peut en avoir en réalité une dizaine
Tous les mois j'aurai un nouveau dossier avec à l'intérérieur un certain nombre de fichiers
- Dans chaque fichier se trouve une table de données dans un onglet que j'ai nommé dans cet exemple "FA"

Le but est de retenir et d'exporter uniquement les lignes pour lesquelles :
. il y a un montant dans la colonne E ("MT HT")
. Et une référence sous la forme "P349XXXX" dans la colonne A ("IA")

Toutes les lignes à 0 ne sont pas à retenir quelque soit la forme de la référence en colonne A
Il y a parfois des sous-totaaux entre des plages de données qui ne sont pas à prendre en compte (exemple cellule E30 de l'onglet "FA")
Il peut aussi avoir des montants TTC manquants commme en cellule F35,
Cette ligne 35 remplit les critères même si la cellule TTC est vide car il s'agît d'une omission.
Dans tous les cas, un contrôle visuel est effectué pour corriger ce type d'erreur

Vous trouverez également dans l'onglet "Export FA" davantage de précisions avec le résultat souhaité,
Ce dernier présente une version concue avec un onglet dans chaque fichier où j'irais copier/coller manuellement le réultat de chaque fichier dans un fichier de consolidation.

Une autre version imaginée serait d'avoir tous les résultats dans le fichier de consolidation sans créer un onglet intermédiaire "Export"
Le résultat serait obtenu après sélection de la plage à transformer pour chaque fichier à ouvrir.
Mais je pense que c'est beucoup plus compliqué à mettre en ouevre de cette sorte

Je suis bien sûr preneur de toute proposition

En vous remerciant d'avance de vos réponses et de votre aide

Cordialement

 

[yal]

Il semble que j'ai trouvé la source du problème. Le code n'est pas en cause. C'est une question de droits d'accès. Vous avez probablement supprimé ou changé le nom du dossier "Export" et le programme n'a pas les droits pour le recréer. Si c'est juste un changement de nom et que le dossier existe alors dans le code modifiez la ligne, là ou ça plante

If Dir(chM & "Consolidations", 16) = "" Then MkDir (chM & "Consolidations") ' Vérifie l'existence du dossier export et le crée si nécessaire

en mettant le nom que vous avez donné à la place "Consolidations"
S'il a été supprimé créez le manuellement en passant par l'explorateur. Windows devrait vous demander confirmation. Ce qui prouverait qu'il s'agit bien d'un problème de droit d'accès.
Sinon vous pouvez aussi lancer Excel en tant qu'administrateur et ouvrir le fichier depuis cette instance. Tout devrait rouler.
Faites moi savoir ou vous en êtes…
Bonne journée

 

[Amilo]

Merci @yal pour cette piste qui semble en effet être la cause.
En me plongeant hier dans votre code très bien structuré, je me suis posé la question sur la ligne contenant notamment le nom "Export" car je n'ai effectivement pas un tel dossier. J'ai actuellement 2 dossiers : "Import" et "Consolidation" .
Certainement qu'une étape a dû m'échapper et j'ai probablement renommé ou supprimé le dossier en question.
Je vais reprendre quelques tests courant de cet après midi sur les 2 PC pour comparer et comprendre.
Je vous tiens informé,
Merci
Cordialement

 

[yal]

Pour moi les termes Export et Import sont des noms génériques pas le nom réel des dossiers en questions. Il arrive qu'un programme doive exporter un même résultat dans deux dossier différent. L'utilisation du nom générique permet de mieux s'y retrouver dans le code. En l'occurrence dans votre cas le dossier Export s'appelle effectivement "Consolidations" avec un "s". Ce qui ne change rien au problème. Même si le dossier existe si le programme n'a pas les droits d'accès à ce dossier ça boguera au moment de l'écriture du fichier.
Il y a bien une solution si les fichiers doivent absolument être dans ce dossier. Mais ce n'est plus du VBA. Il faut intervenir sur la variable "Path" de Windows.

Erreur 52 : nom de fichier ou numéro incorrect - Support Microsoft

support.microsoft.com

 

[Amilo]

@ yal, je comprends mieux concernant les noms génériques, cela répond à mon interrogation à savoir pourquoi je n'avais pas de dossier "Export" (donc idem que "Consolidations") et merci pour vos explications très claires
Sinon, j'avais omis le "s" car je répondais de mon téléphone sans avoir les fichiers sous les yeux mais vous avez raison de le signaler.

Personnellement, je n'ai pas la compétence, ni les droits pour le "Path"de Windows et je ne pense pas faire intervenir notre service Informatique..., c'est un détail.
Pour l'instant je vais utiliser l'emplacement où cela fonctionne.

Mille mercis encore
Bon dimanche

Cordialement

 

[yal]

Ca me semble une sage décision

 

[Amilo]

@yal ,

désolé je viens de voir 2 résultats différents au niveau du format des dates selon les fichiers "Source" :

- lorsque je traite un des fichiers que j'avais déposés sur ce fil, les dates bien que typées à la base en "Date" dans Excel, arrivent en type "Standard" et sous le format "jj/mm/aaaa" dans les 2 colonnes "E" et "F" du fichier "Consolidation.xlsx",
- avec un fichier de mon PC de travail, ces même dates également typées en "Date", sont récupérées par contre en type "Date" mais sous le format "mm/jj/aaaa"

J'ai testé le fichier de mon PC de travail sur mon PC Perso, même résultat avec un format "mm/jj/aaaa"

J'ai fait plusieurs tests mais sans résultat

Edit : sinon je permers de revenir sur le problème de variable du "Path" Windows,
Est-ce qu'il y aurait beaucoup à retraivailler pour que les exports soient récupérés directement dans le même fichier déjà existant (fichier avec le bouton de commande VBA) au lieu d'en créer de nouveaux fichiers dans le dossier "Consolidations" ?
Est-ce que cela contournerait le problème de "Path" Windows ?

Cordialement

 

[yal]

Le problème vient de ce qu'Excel est américain. Habituellement l'utilisation de Value2 à la place de Value suffit à régler le problème. Je ne sais pas pourquoi cette fois ça ne marche pas. Je ne m'étais pas aperçu du phénomène car il n'y avait pas de date avec un jour inférieur à 12 de les fichiers que j'avais. Le problème est résolu en lui imposant un format à l'envers. Ca peut paraitre bizarre mais ça marche.

 

[Amilo]

Merci beaucoup @yal , cela fonctionne très bien ,
Sinon, en vous lisant, je viens de comprendre que les dates étaient au format "Américain" quelque soit le fichier "Source".

En effet, les jours des dates étaient inférieurs à 12 pour l'un des 2 fichiers d'où mon analyse erronée en indiquant que cela fonctionnait dans un cas mais pour l'autre.

P.S : j'avais édité mon précédent message pour évoquer à nouveau le problème du "Path" Windows,
En fait, ce fichier sera utilisé par plusieurs personnes et devrait se trouvait idéalement dans un dossier partagé.

Si les résultats des exports sont copiés directement dans le même fichier que le bouton de commande VBA, est-ce cela règlerait ce souci de "Path" Wondows ?

Merci pour votre précieuse aide
Cordialement

 

[yal]

Je pense que oui mais honnêtement je n'ai aucune certitude. Je crois savoir que les tableaux structurés posent problème sur dans les fichiers partagés mais il n'y a aucun tableau dans ce projet donc on devrait être tranquille de ce côté là. J'ai fait d'autres projets qui sont partagés sur un réseau et à ma connaissance ça fonctionne. Conclusion : à tester.

 

[Amilo]

Je pense que oui mais honnêtement je n'ai aucune certitude. Je crois savoir que les tableaux structurés posent problème sur dans les fichiers partagés mais il n'y a aucun tableau dans ce projet donc on devrait être tranquille de ce côté là. J'ai fait d'autres projets qui sont partagés sur un réseau et à ma connaissance ça fonctionne. Conclusion : à tester.

Merci, j'aimerais bien tester mais je ne sais pas comment modifier votre code en ce sens ,
Bonne soirée
Cordialement

 

[yal]

  Set wbM = ThisWorkbook ' Alias du fichier principal
  chM = wbM.Path & "\" ' Chemin du fichier principal

  chExport = chM & "Consolidations\" ' Chemin relatif par rapport au fichier principal du dossier d'export c'est donc cette ligne qu'il faut modifier. Il suffit d'écrire : chExport = chM

Si les résultats des exports sont copiés directement dans le même fichier que le bouton de commande VBA, est-ce cela règlerait ce souci de "Path" Wondows ?

En fait je crois que j'avais mal compris la question. Si le fichier principal (celui avec le bouton de commande est stocké dans un endroit en lecture seule ça ne changera rien. Et si on peut écrire dans le dossier du fichier principal alors on peut aussi écrire dans ses sous-dossiers.

 

[Amilo]

En fait, le dossier se trouvera sous Sharepoint,
sauf erreur de ma part, il me semble que le problème de lecture seul ne devrait pas se poser,
Certainement que quelque chose m'échappe, je ne sais pas si les lignes de codes de votre précédent message devaient être reprises ou non quelque soit la version.

Cordialement

 

[Amilo]

Bonjour @yal , le forum,

Je ne vois pas du tout comment contourner le bloc de code conçu à créér de nouveaux fichiers mensuels.

La conception du fichier est géniale et fonctionne très bien lorsqu'il il est utilisé dans un environnement local (lecteur C: par exemple) mais pose problème en réseau ou Sharepoint en raison du "Path" Windows.
Cela empéche toute création de nouveaux fichiers avec un message d'erreur pointant sur le code ci-dessous :

If Dir(chM & "Consolidations", 16) = "" Then MkDir (chM & "Consolidations")

Pouvez-vous svp m'aider avec une proposition sans passer par la création de fichiers ?

En vous remerciant d'avance pour votre aide

Cordialement

 

[Staple1600]

Bonsoir le fil

Pour info (au cas où cela pourrait dépanner)
Au boulot, je connecte un lecteur réseau sur mes ressources Sharepoint
Dans cette configuration, j'arrive à exécuter mes codes VBA sur les fichiers
(sans passer par l'interface web de Sharepoint)

 

[yal]

Bonsoir Staple1600
Merci pour l'info. Vos codes VBA créent ils des fichiers sur SharePoint? Personnellement je ne connais pas du tout SharePoint, je ne l'ai jamais utilisé. J'ai vu quelque part que la syntaxe des chemins étaient différente. Je rechercherais la source.