Reprise du message précédent :

Pas sûr de la pertinence d'alourdir et de complexifier autant ce genre de fichier de suivi pour la récup d'une vl.
A moins que cette donnée ne revêt un caractère si important que sa disponibilité permanente soit nécessaire j'imagine qu'on peut aussi patienter quelques secondes de loading en cas d'indisponibilité du site source (encore qu'avec funds360 ça fait bien longtemps que je n'ai pas eu de problème.)

Merci malgré tout pour le partage si ça peut servir à quelqu'un

Perso ça reste souvent en Error pendant longtemps, et ensuite ça casse mon historique automatique, donc la seconde solution (qui fait tout en une ligne exactement comme celle qu’elle remplace) me convient pas mal

Plein de bonnes idées, je verrai ce que je garde    
 
En attendant j'ai décidé de fusionner complètement la 1ere page et la Worktable.
Ça ressemble à ça:
 

 
Et c'est super souple: on peut déplacer les lignes et les colonnes comme on veut  

Avec Quantalys, de mon XP ça peut durer plusieurs heures si tu laisses tel quel. Un peu chiant quand c'est pile au moment où tu as décidé de poser tes louches et que tu n'as que ça pour vérifier où tu en es dans tes % d'allocations.

1. Il n'y a plus le total et la perf de chaque enveloppe.
2. Et si j'ai un fonds identique dans 2 enveloppes différentes je le gère comment ?

 
 
Depuis le temps qu'on dit de passer sur morningstar ou encore mieux funds360....

avec ma solution tu as les trois en même temps

OK, comme tu veux, pas de souci.

Mais pour être exact, avec ta solution, le iferror ne gérant pas la notion de timeout, voilà les hypothèses:

1/soit il considère que le "Loading" est une erreur directement, auquel cas tu exécutes une requête inutile puisque tu n'attends même pas le résultat avant de passer à la suivante.
2/soit il considère que le "Loading" n'est pas une erreur et il te l'affiche, tu auras donc exactement le même problème qu'avant, à savoir le loading qui peut rester affiché un moment avant d'avoir une valeur.

Je ne vais pas attendre que Quantalys se remette à déconner pour pousser les tests plus avant, mais de ce que j'ai pu essayer depuis un moment avec ce fichier de suivi je dirai que c'est la cas 1 qui est le bon.
D'ailleurs c'est confirmé par ta capture d'écran, tu as un résultat affiché en "valeur unitaire" alors même qu'une requête est encore en cours de chargement dans "valeur", et donc dans la majorité des cas tu afficheras le résultat de ta deuxième ou troisième recherche.

Effectivement ça fonctionne, mais c'est tout sauf optimum en terme de performance du fichier en lui même, 2 à 3 requêtes pour un seul résultat (et ne parlons pas de la charge serveur avec ce genre de document bancal). Suivant le nombre de ligne de ton suivi ça fait un paquet de requêtes inutiles.

J’ai testé, et effectivement c’est cela
et d’ailleurs ça se voit dans mon premier screenshot, comme tu le notes.
 
Quant au nombre de requêtes, je pense que le IFERROR a une évaluation paresseuse (Edit : vérifié avec un test simple en mettant =IFERROR(C15;1/0) dans une case : cela ne cause pas d’erreur tant que C15 est valide), donc il n’ira chercher les requêtes suivantes que si la première échoue. Comme la première est funds360.euronext.com, bah tant que celui si marche, pas d’autre évaluation. C’est juste une sécurité, je trouve ça assez transparent, écrit comme ça

 
Pourquoi ne pas rajouter une ligne de total après chaque produit composé ? genre entre les lignes 8 et 9, ou 18 et 19.  
 
Je suis parti là dessus et pour le moment ça ne semble pas me bloquer sur autre chose. Aurais-tu anticipé un blocage quelconque pour certaines fonctionnalités/recherche par la suite ?
 

 
Je me suis basé uniquement sur le screen pour réagir sur l'ordre d'exécution, je n'avais pas fait gaffe que dans ta requête finale tu interrogeais funds360 en premier. Du coup tu fais sauter tous les problèmes de charge/optimisation évoqués, pas de souci.
 
Désolé d'avoir insisté

+1, je trouve ça un peu bordélique, j'aime bien avoir que l'essentiel sur la 1ere page comme avant.

Bon du coup (et en attendant de piquer d'autres bonnes idées à Mitch ) je suis arrivé à quelque chose qui convient à mon usage. La problématique ucompte a été l'occasion de revoir tout le fichier avec une idée de simplification pour la partie gestion de patrimoine (j'ai beaucoup d'autres choses dedans maintenant).
 
Ca donne ça :
 
Feuille de suivi :  
 

 
Feuille de travail :
 


 
Feuille de suivi des TRI :
 

 
Feuille Historique : pas de changement
 
Voilà, ce que ça donne (les chiffres sont bien évidemment totalement fictifs, comme les investissements d'ailleurs)

Je vais rajouter une colonne pour ça.

Ça ne pose pas de problème, tu fais comme s'ils n'étaient pas identiques: 1 ligne chacun dans chaque produit dans lequel tu possèdes le fonds.
T'aura un PRU différent sur chaque ligne.

Parfait: ça ne multiplie pas le nombre de requête donc ça ne nuira pas à la performance du fichier.
J'ajouterai ça.

Je préfère une colonne.

Le fichier dans cette nouvelle forme est très souple et customisable à souhait: tu choisis les colonnes qui te plaisent, tu les déplace à gauche et tu masque les autres. Ou tu ajoute une large colonne vide pour pousser les données que tu ne veux pas voir loiiiiin à droite.

 
Mince alors: t'es plus avancé que moi.    
 
Comment tu fais pour récupérer les données d'allocation géographique ?

Elles sont pour le moment rentrées à la main en attendant de trouver une solution fiable ET pas trop gourmande pour ne pas alourdir le doc.

Et si je ne trouve rien pour automatiser, les allocations ne changeant pas du tout au tout tous les jours et bien ça restera comme ça, et je ferai une maj manuelle une ou deux fois par an.

Pblm avec tes regexp si la VL est supérieure ou égale à 1000€
exemple: https://funds360.euronext.com/opcvm [...] orizon-n-5
renvoie 39,91 au lieu de 1039,91

J'ai repris ma solution de la V1 sans regexp:
=SUBSTITUTE(SUBSTITUTE(LEFT(S8;LEN(S8)-4);" ";"" );".";"," )+0
S8=TRANSPOSE(IMPORTXML(P8;"//*[@id='lastVL']" ))

Inconvénient: il faut 2 cases. Je pourrai le faire en 1 mais il y aurait alors 2 IMPORTXML dans la case

Ce n'est pas grave d'avoir plein de cases de travail: une fois que le fichier fonctionne on peut les masquer ou les bouger à droite pour ne pas les voir.
C'est également plus facile à maintenir et plus facile pour saisir.
Par exemple pour les URL j'ai fais 3 colonnes, c'est plus facile à remplir que de séparer par des @.
J'admet néanmoins bien volontiers que ta solution est plus clean d'un point de vue code.

 
ok, j'ai cru un instant que t'avais codé un miracle dans la nuit de samedi à dimanche  

Petit aparté : je remarque que personne ne semble utiliser les plages/cellules nommées, ce qui rend quand même la lecture des formules plus simples (que ce soit pour en comprendre la logique ou pour les modifier par la suite).
 
Mes deux centimes.

Je ne vois pas l'indice de risque SRRI sur Morningstar    
 
Je vais donc me contenter de basculer de funds360 à Quantalys.
 
sachant que pour le CW8 l'un remonte 6 et l'autre 5  

Non malheureusement. Je m'arrache la tête la dessus, ce n'est quand même pas simple cette histoire.

faudrait peut-être chercher sur des sites américains ... y'en a bien un qui doit avoir fait une page simple.

 
 
Je vais essayer de m'y remettre ce soir si j'ai un peu de temps.

n’étant pas du tout habitué d’excel mais complètement autodidacte, je ne connaissais pas
je vais regarder, ça doit pas être compliqué

 

 
En effet j’avoue que tous mes fonds ont une VL<1k€ donc j’avais pas rencontré le pb
C’est une simple histoire de regex, ça se règle sans pb — c’est pas mon domaine par contre, il faudrait quelqu’un un minimum balèze en informatique pour nous régler ça

Par ailleurs j’ai eu une idée en travaillant sur le gsheets hier : on pourrait mettre en place une formule pour actualiser automatiquement le nombre d’UC possédées en impactant les frais via une formule. Actuellement, je suis obligé de mettre à jour la colonne « Quantité » (= nombre d’UC) régulièrement, pour suivre les frais pratiqués par l’assureur.

 
À l’avenir, on pourrait les prendre en compte automatiquement en faisant quelque chose comme  

où G8 contient la quantité initiale d’UC, pour le cas où les frais de gestion d’UC sont de 0.5% par an.
 
Ça pourrait même permettre de faire une colonne « frais cumulés » en plus, pour voir à quel point les assureurs se gavent

 
   
 
La colonne de l'enfer  

 
 
Le gsheet de l'enfer même à force
 
@Gosferayn :
Par contre si tu ré-investis régulièrement sur ta ligne ça ne marche plus, et même en passant à un truc du genre :
 

Il faudrait une ligne différente par abondement pour une même UC. Ca risque de vite devenir un sacré bazar non ?
Ou je passe complètement à côté de quelque chose ?
 
Edit:
Quoique ça peut se faire en fait :
 

 
A chaque ré-investissement il suffit de mettre à jour la case Quantité_Investie avec la valeur du nombre d'UC possédé d'après le relevé de l'assureur et la case DateMaj avec la date de valeur dudit relevé.
 
Impec

drap

T'as quoi comme zones géographiques ?
C'est pas la mêmes sur ucompte, Morningstar et Amundi  

Je galère pour trouver des données cohérentes pour le CW8  

Morningstar (1ere colonne):

Amérique du Nord  69,06  62,40
Royaume-Uni  4,42  6,21
Europe développée  14,80  16,74
Europe émergente  0,01  0,19
Afrique/Moyen-Orient  0,17  0,37
Japon  7,86  7,00
Australasie  2,08  1,47
Asie développée  1,28  2,60
Asie émergente  0,21  2,76
Amérique latine  0,11  0,26

Amundi:

Je serai tenté de choisir la source Amundi vu que c'est l'émetteur de l'ETF ...

Ou alors faudrait voir du côté de MSCI puisque c'est lui qui met à jour l'indice. Ils ont peut-être une page facile à scrapper d'ailleurs, ce serait bien pratique ça ...
EDIT: ils ont ce document avec un joli camembert 3D: https://www.msci.com/documents/1019 [...] fc565ededb
avec un gros 15% de "other"  

 
Hé bien je découvre cette fonction grâce à toi.
 
Et c'est plutôt sympa, notamment pour le script d'historisation:
 

Oui, ça marche nickel, merci pour ton Edit
je vais implémenter ça chez moi prochainement
 
Seule déception, quand on met à jour ce sera un enfer de garder trace de tout l’historique des frais payés, tant pis pour cette idée

Ravi de vous l'avoir fait découvrir, alors. Et j'ajoute un avantage non négligeable : ça permet d'éviter les erreurs débiles pas toujours faciles à repérer (genre une référence à la cellule G345 au lieu de G346 perdue au milieu d'une formule).

Je me suis  arrêté sur sicavonline pour le moment, en attendant de me re-pencher sur le problème de la récupération automatique.

 
J'ai une solution:
 
Je créee une page GEO qui récupère les données géographiques sur sicavonline:
 

 
Et ensuite depuis la page principale on fait un HLOOKUP dans GEO qui recherche le titre de colonne (AD3) par exemple "Japon":
=IFERROR(HLOOKUP(AD3;geo!$B$1:$N$2;2;FALSE);0)
 
Et ça fonctionne.
 
Bon pour l'instant la page GEO est un peu manuelle, il reste un peu de boulot.
Sachant que la moitié de mes fonds n'ont pas d'informations géographique renseignées sur sicavonline ET que les fonds obligataires contiennent des infos sur la qualité des obligations mais pas d'infos géographiques non plus je me demande si c'est bien utile de me prendre la tête pour même pas 1/4 des lignes concernées.    
 
Et en plus le total ne fait pas toujours 100% Exemple CW8 = 97,93%  

Pourquoi vous faites pas un sort() sur le nom de la zone géographique tout simplement au lieu de vous taper un tableau intermédiaire ?

Bordel je ne connaissais pas !

Si Plage_Allocation_Geo est un tableau genre premiere ligne = pays et deuxième ligne = valeur ca marche nickel, ça nous retourne le tableau trié par ordre alpha.

Top, merci pour ça

Bon reste quand même une grosse problématique en plus de l'histoire de tri, c'est que l'allocation géographique n'est pas fixe en terme de pays mentionné.

Pour un etf tu peux avoir l'alloc avec les pays A, B, C, D, E par exemple, et pour un autre A, B, E, M, N
Du coup le sort() ne permet pas de remplir un tableau de manière systématique et ne devrait pas éviter l'utilisation d'un HLOOKUP comme le propose mitch.

@mitch:
Je m'en suis rendu compte en rentrant les valeurs d'allocation en dur. Ca plus le fait que tous les sites ne donnent pas exactement les mêmes pourcentages m'ont fait pencher pour une solution "arbitraire".
Je remplis la case "Autres" avec un magnifique =if(isblank(X4);;sum(X4:AJ4)) ou X4 est la valeur pour les US  
C'est vraiment du temporaire cette histoire ...

Sur morningstar il y a 10 zones géographiques, c'est pas suffisant ?
Et puis tu mets à 0 les zones géographiques absentes en utilisant unique().  

 
Si c'est suffisant mais :
 
1/On ne peut pas parser les données de morningstar aussi facilement que ça (car il faut cliquer sur le "région" pour activer la zone qui nous intéresse).  
2/Trier les résultats avec un sort() n'évitant pas l'utilisation d'un hlookup (puisque la liste de pays n'est pas fixe), il ne représente pas une solution au final.
 
Bref, je passe peut être à côté de quelque chose d'évident, éclaire nous si c'est le cas. Des fois à force d'être sûr un truc on cherche a se compliquer la vie pour rien
 
Pour ce qui est de mettre à 0 les pays absents, on est bien d'accord.

Oui, la page attend notre clic sur "Régions" pour envoyer la requete à l'API de morningstar https://www.us-api.morningstar.com/sal/sal-service/etf/portfolio/regionalSector/F0GBR06TFO/data
Mais on peut envoyer la requête nous-même, qui retourne un json tout propre :

Reste à régler le problème du token  

 
 
Courage, tu y es presque
 

Je me suis résolue à passer en manuel pour la répartition géographique, car j'ai pas bc de lignes.
J'ai des fonds lyxor qui ne sont pas sicavonline. Coup de bol, sur Lyxoretf, la compo géographique est dispo et à jour.
Mais mais mais... C'est détaillé par pays   Je me retrouve avec la Zambie, l'île de Man, etc.
Vous savez s'il y a une table récapitulative qq part des grands regroupements géographiques (asie émergent, etc)  ? Histoire de pas me planter.