J'ai un problème précis mais assez difficile à énoncer. J'ai donc posté un
fichier sur : http://cjoint.com/?expmJslBuC
Imaginons une balance comptable, avec des comptes, des mois, et des montants.
J'ai également une autre table qui comporte une correspondance entre mes 500
comptes comptables et 20 codes budgets internes.
Je veux trouver la formule qui somme les montants dans la balance, suivant
un mois et selon un code budget (attention : j'ai bien écrit un code budget !)
Ben je peux vous dire que faire la formule directement sans passer par un
recherchev intermédiaire, ce n'est pas de la tarte ! Alors bon, ce n'est pas
capital dans la mesure où je m'en sors de manière peu élégante, mais j'ai
l'impression que c'est jouable ...
Alors, je remercie les pros de la matricielle de mettre en évidence mon
incompétence en la matière.
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu.... Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu pourras faire l'économie de la validation matricielle Ceci dit, dans ta proposition, il manque un test logique (prise en compte du mois de référence)...
AV
Bonjour en cette nouvelle matinée.
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très
intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu....
Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu
pourras faire l'économie de la validation matricielle
Ceci dit, dans ta proposition, il manque un test logique (prise en compte du
mois de référence)...
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu.... Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu pourras faire l'économie de la validation matricielle Ceci dit, dans ta proposition, il manque un test logique (prise en compte du mois de référence)...
AV
hasco
Voili, voilou,
j'ai refait la même chose avec SP; en gardant les matrices nommées 'RESTAURATION' et 'TRANSPORTS' et en incluant le test du mois ce qui nous donne :
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu.... Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu pourras faire l'économie de la validation matricielle Ceci dit, dans ta proposition, il manque un test logique (prise en compte du mois de référence)...
AV
Voili, voilou,
j'ai refait la même chose avec SP; en gardant les matrices nommées
'RESTAURATION' et 'TRANSPORTS' et en incluant le test du mois ce qui nous
donne :
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très
intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu....
Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu
pourras faire l'économie de la validation matricielle
Ceci dit, dans ta proposition, il manque un test logique (prise en compte du
mois de référence)...
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu.... Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu pourras faire l'économie de la validation matricielle Ceci dit, dans ta proposition, il manque un test logique (prise en compte du mois de référence)...
AV
Poulpor
Ca fait plaisir de voir cette emulation autour de ce problème.
Donc, comme on ne précise jamais assez le problème et la situation, je précise :
Il s'agit d'un reporting, dont la source (balance) change chaque mois, et même la table de correspondance est amenée àévoluer quand de nouveaux comptes sont créés.
Et à partir de ces bases, on crée un tableau ( mois * codes budgétaires), et on souhaite trouver la formule miracle qui somme suivant le mois, et surtout suivant un critère dépendant le la table de correspondance.
Evidemment, il y a suffisament de lignes, comptes, et codes budgétaires pour qu'une solution de type manuel soit envisagée, comme créer une liste manuellement, faire un sommeprod avec un nombre d'arguments pouvant être monstrueux. De plus, l'évolution de la nommenclature des comptes engendrerait un contrôle de chaque formule ou nom.
Je ne sais pas vous, mais moi, je n'arrete pas de penser que sous access, ce type de problème est rapidement résolu !
Merci encore à tous.
Philippe
Bonjour en cette nouvelle matinée.
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu.... Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu pourras faire l'économie de la validation matricielle Ceci dit, dans ta proposition, il manque un test logique (prise en compte du mois de référence)...
AV
Ca fait plaisir de voir cette emulation autour de ce problème.
Donc, comme on ne précise jamais assez le problème et la situation, je
précise :
Il s'agit d'un reporting, dont la source (balance) change chaque mois, et
même la table de correspondance est amenée àévoluer quand de nouveaux comptes
sont créés.
Et à partir de ces bases, on crée un tableau ( mois * codes budgétaires), et
on souhaite trouver la formule miracle qui somme suivant le mois, et surtout
suivant un critère dépendant le la table de correspondance.
Evidemment, il y a suffisament de lignes, comptes, et codes budgétaires pour
qu'une solution de type manuel soit envisagée, comme créer une liste
manuellement, faire un sommeprod avec un nombre d'arguments pouvant être
monstrueux. De plus, l'évolution de la nommenclature des comptes engendrerait
un contrôle de chaque formule ou nom.
Je ne sais pas vous, mais moi, je n'arrete pas de penser que sous access, ce
type de problème est rapidement résolu !
Merci encore à tous.
Philippe
Bonjour en cette nouvelle matinée.
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très
intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu....
Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu
pourras faire l'économie de la validation matricielle
Ceci dit, dans ta proposition, il manque un test logique (prise en compte du
mois de référence)...
Ca fait plaisir de voir cette emulation autour de ce problème.
Donc, comme on ne précise jamais assez le problème et la situation, je précise :
Il s'agit d'un reporting, dont la source (balance) change chaque mois, et même la table de correspondance est amenée àévoluer quand de nouveaux comptes sont créés.
Et à partir de ces bases, on crée un tableau ( mois * codes budgétaires), et on souhaite trouver la formule miracle qui somme suivant le mois, et surtout suivant un critère dépendant le la table de correspondance.
Evidemment, il y a suffisament de lignes, comptes, et codes budgétaires pour qu'une solution de type manuel soit envisagée, comme créer une liste manuellement, faire un sommeprod avec un nombre d'arguments pouvant être monstrueux. De plus, l'évolution de la nommenclature des comptes engendrerait un contrôle de chaque formule ou nom.
Je ne sais pas vous, mais moi, je n'arrete pas de penser que sous access, ce type de problème est rapidement résolu !
Merci encore à tous.
Philippe
Bonjour en cette nouvelle matinée.
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu.... Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu pourras faire l'économie de la validation matricielle Ceci dit, dans ta proposition, il manque un test logique (prise en compte du mois de référence)...
AV
hasco
Oui sous access, avec les requêtes appropriées le temps de traitements des données serait plus rapides et plus facile à mettre en oeuvre.
Mais si vous voulez conserver excel, une piste serait de créer deux classeurs dont l'un contiendrait les données et l'autre la balance. En faisant appel a VBA et la bibliothèque MSADO qui permet de faire des requête SQL sur un autre classeur.
Bon courage.
Ca fait plaisir de voir cette emulation autour de ce problème.
Donc, comme on ne précise jamais assez le problème et la situation, je précise :
Il s'agit d'un reporting, dont la source (balance) change chaque mois, et même la table de correspondance est amenée àévoluer quand de nouveaux comptes sont créés.
Et à partir de ces bases, on crée un tableau ( mois * codes budgétaires), et on souhaite trouver la formule miracle qui somme suivant le mois, et surtout suivant un critère dépendant le la table de correspondance.
Evidemment, il y a suffisament de lignes, comptes, et codes budgétaires pour qu'une solution de type manuel soit envisagée, comme créer une liste manuellement, faire un sommeprod avec un nombre d'arguments pouvant être monstrueux. De plus, l'évolution de la nommenclature des comptes engendrerait un contrôle de chaque formule ou nom.
Je ne sais pas vous, mais moi, je n'arrete pas de penser que sous access, ce type de problème est rapidement résolu !
Merci encore à tous.
Philippe
Bonjour en cette nouvelle matinée.
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu.... Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu pourras faire l'économie de la validation matricielle Ceci dit, dans ta proposition, il manque un test logique (prise en compte du mois de référence)...
AV
Oui sous access, avec les requêtes appropriées le temps de traitements des
données serait plus rapides et plus facile à mettre en oeuvre.
Mais si vous voulez conserver excel, une piste serait de créer deux
classeurs dont l'un contiendrait les données et l'autre la balance. En
faisant appel a VBA et la bibliothèque MSADO qui permet de faire des requête
SQL sur un autre classeur.
Bon courage.
Ca fait plaisir de voir cette emulation autour de ce problème.
Donc, comme on ne précise jamais assez le problème et la situation, je
précise :
Il s'agit d'un reporting, dont la source (balance) change chaque mois, et
même la table de correspondance est amenée àévoluer quand de nouveaux comptes
sont créés.
Et à partir de ces bases, on crée un tableau ( mois * codes budgétaires), et
on souhaite trouver la formule miracle qui somme suivant le mois, et surtout
suivant un critère dépendant le la table de correspondance.
Evidemment, il y a suffisament de lignes, comptes, et codes budgétaires pour
qu'une solution de type manuel soit envisagée, comme créer une liste
manuellement, faire un sommeprod avec un nombre d'arguments pouvant être
monstrueux. De plus, l'évolution de la nommenclature des comptes engendrerait
un contrôle de chaque formule ou nom.
Je ne sais pas vous, mais moi, je n'arrete pas de penser que sous access, ce
type de problème est rapidement résolu !
Merci encore à tous.
Philippe
Bonjour en cette nouvelle matinée.
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très
intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu....
Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu
pourras faire l'économie de la validation matricielle
Ceci dit, dans ta proposition, il manque un test logique (prise en compte du
mois de référence)...
Oui sous access, avec les requêtes appropriées le temps de traitements des données serait plus rapides et plus facile à mettre en oeuvre.
Mais si vous voulez conserver excel, une piste serait de créer deux classeurs dont l'un contiendrait les données et l'autre la balance. En faisant appel a VBA et la bibliothèque MSADO qui permet de faire des requête SQL sur un autre classeur.
Bon courage.
Ca fait plaisir de voir cette emulation autour de ce problème.
Donc, comme on ne précise jamais assez le problème et la situation, je précise :
Il s'agit d'un reporting, dont la source (balance) change chaque mois, et même la table de correspondance est amenée àévoluer quand de nouveaux comptes sont créés.
Et à partir de ces bases, on crée un tableau ( mois * codes budgétaires), et on souhaite trouver la formule miracle qui somme suivant le mois, et surtout suivant un critère dépendant le la table de correspondance.
Evidemment, il y a suffisament de lignes, comptes, et codes budgétaires pour qu'une solution de type manuel soit envisagée, comme créer une liste manuellement, faire un sommeprod avec un nombre d'arguments pouvant être monstrueux. De plus, l'évolution de la nommenclature des comptes engendrerait un contrôle de chaque formule ou nom.
Je ne sais pas vous, mais moi, je n'arrete pas de penser que sous access, ce type de problème est rapidement résolu !
Merci encore à tous.
Philippe
Bonjour en cette nouvelle matinée.
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu.... Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu pourras faire l'économie de la validation matricielle Ceci dit, dans ta proposition, il manque un test logique (prise en compte du mois de référence)...
AV
Poulpor
Re,
J'y ai bien pensé. En fait, je sais comment aller d'Excel vers l'access (en DAO si je me souviens dans mon cas), mais je ne pensais pas d'excel vers excel, merci de me l'apprendre.
Mais j'imagine : - un problème de performance - un doute permanent sur la qualité du code (à la limite, on peut controler que les totaux soient cohérents)
J'envisageais une autre solution : créer ma fonction en vba : pour chaque compte correspondant à mon code budget choisi, faire le cumul des sommeprods correspondants. C'est ce que j'ai fait dans cet exemple. Mais là aussi je doute de la performance sur gros fichier.
La fonction créée (le code n'est pas propre du tout) : http://cjoint.com/?eymTDBQmnl
Merci encore pour l'implication.
Philippe
Oui sous access, avec les requêtes appropriées le temps de traitements des données serait plus rapides et plus facile à mettre en oeuvre.
Mais si vous voulez conserver excel, une piste serait de créer deux classeurs dont l'un contiendrait les données et l'autre la balance. En faisant appel a VBA et la bibliothèque MSADO qui permet de faire des requête SQL sur un autre classeur.
Bon courage.
Ca fait plaisir de voir cette emulation autour de ce problème.
Donc, comme on ne précise jamais assez le problème et la situation, je précise :
Il s'agit d'un reporting, dont la source (balance) change chaque mois, et même la table de correspondance est amenée àévoluer quand de nouveaux comptes sont créés.
Et à partir de ces bases, on crée un tableau ( mois * codes budgétaires), et on souhaite trouver la formule miracle qui somme suivant le mois, et surtout suivant un critère dépendant le la table de correspondance.
Evidemment, il y a suffisament de lignes, comptes, et codes budgétaires pour qu'une solution de type manuel soit envisagée, comme créer une liste manuellement, faire un sommeprod avec un nombre d'arguments pouvant être monstrueux. De plus, l'évolution de la nommenclature des comptes engendrerait un contrôle de chaque formule ou nom.
Je ne sais pas vous, mais moi, je n'arrete pas de penser que sous access, ce type de problème est rapidement résolu !
Merci encore à tous.
Philippe
Bonjour en cette nouvelle matinée.
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu.... Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu pourras faire l'économie de la validation matricielle Ceci dit, dans ta proposition, il manque un test logique (prise en compte du mois de référence)...
AV
Re,
J'y ai bien pensé. En fait, je sais comment aller d'Excel vers l'access (en
DAO si je me souviens dans mon cas), mais je ne pensais pas d'excel vers
excel, merci de me l'apprendre.
Mais j'imagine :
- un problème de performance
- un doute permanent sur la qualité du code (à la limite, on peut controler
que les totaux soient cohérents)
J'envisageais une autre solution : créer ma fonction en vba :
pour chaque compte correspondant à mon code budget choisi, faire le cumul
des sommeprods correspondants. C'est ce que j'ai fait dans cet exemple.
Mais là aussi je doute de la performance sur gros fichier.
La fonction créée (le code n'est pas propre du tout) :
http://cjoint.com/?eymTDBQmnl
Merci encore pour l'implication.
Philippe
Oui sous access, avec les requêtes appropriées le temps de traitements des
données serait plus rapides et plus facile à mettre en oeuvre.
Mais si vous voulez conserver excel, une piste serait de créer deux
classeurs dont l'un contiendrait les données et l'autre la balance. En
faisant appel a VBA et la bibliothèque MSADO qui permet de faire des requête
SQL sur un autre classeur.
Bon courage.
Ca fait plaisir de voir cette emulation autour de ce problème.
Donc, comme on ne précise jamais assez le problème et la situation, je
précise :
Il s'agit d'un reporting, dont la source (balance) change chaque mois, et
même la table de correspondance est amenée àévoluer quand de nouveaux comptes
sont créés.
Et à partir de ces bases, on crée un tableau ( mois * codes budgétaires), et
on souhaite trouver la formule miracle qui somme suivant le mois, et surtout
suivant un critère dépendant le la table de correspondance.
Evidemment, il y a suffisament de lignes, comptes, et codes budgétaires pour
qu'une solution de type manuel soit envisagée, comme créer une liste
manuellement, faire un sommeprod avec un nombre d'arguments pouvant être
monstrueux. De plus, l'évolution de la nommenclature des comptes engendrerait
un contrôle de chaque formule ou nom.
Je ne sais pas vous, mais moi, je n'arrete pas de penser que sous access, ce
type de problème est rapidement résolu !
Merci encore à tous.
Philippe
Bonjour en cette nouvelle matinée.
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très
intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu....
Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu
pourras faire l'économie de la validation matricielle
Ceci dit, dans ta proposition, il manque un test logique (prise en compte du
mois de référence)...
J'y ai bien pensé. En fait, je sais comment aller d'Excel vers l'access (en DAO si je me souviens dans mon cas), mais je ne pensais pas d'excel vers excel, merci de me l'apprendre.
Mais j'imagine : - un problème de performance - un doute permanent sur la qualité du code (à la limite, on peut controler que les totaux soient cohérents)
J'envisageais une autre solution : créer ma fonction en vba : pour chaque compte correspondant à mon code budget choisi, faire le cumul des sommeprods correspondants. C'est ce que j'ai fait dans cet exemple. Mais là aussi je doute de la performance sur gros fichier.
La fonction créée (le code n'est pas propre du tout) : http://cjoint.com/?eymTDBQmnl
Merci encore pour l'implication.
Philippe
Oui sous access, avec les requêtes appropriées le temps de traitements des données serait plus rapides et plus facile à mettre en oeuvre.
Mais si vous voulez conserver excel, une piste serait de créer deux classeurs dont l'un contiendrait les données et l'autre la balance. En faisant appel a VBA et la bibliothèque MSADO qui permet de faire des requête SQL sur un autre classeur.
Bon courage.
Ca fait plaisir de voir cette emulation autour de ce problème.
Donc, comme on ne précise jamais assez le problème et la situation, je précise :
Il s'agit d'un reporting, dont la source (balance) change chaque mois, et même la table de correspondance est amenée àévoluer quand de nouveaux comptes sont créés.
Et à partir de ces bases, on crée un tableau ( mois * codes budgétaires), et on souhaite trouver la formule miracle qui somme suivant le mois, et surtout suivant un critère dépendant le la table de correspondance.
Evidemment, il y a suffisament de lignes, comptes, et codes budgétaires pour qu'une solution de type manuel soit envisagée, comme créer une liste manuellement, faire un sommeprod avec un nombre d'arguments pouvant être monstrueux. De plus, l'évolution de la nommenclature des comptes engendrerait un contrôle de chaque formule ou nom.
Je ne sais pas vous, mais moi, je n'arrete pas de penser que sous access, ce type de problème est rapidement résolu !
Merci encore à tous.
Philippe
Bonjour en cette nouvelle matinée.
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu.... Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu pourras faire l'économie de la validation matricielle Ceci dit, dans ta proposition, il manque un test logique (prise en compte du mois de référence)...
AV
Jacquouille
Bonsoir Adepte de Sommeprod, je persiste et signe pour cette solution. Mais, il y en a des ceusses qui n'aiment pas. La maison peut proposer, moyenant un léger supplément, une solution à base de filtre, puis de SOUS.TOTAL Cette seconde recette, un rien plus longue, a aussi ses adeptes. Bonne chance.
-- Bien amicalmement, Vivement conseillés: http://www.excelabo.net http://jacxl.free.fr/mpfe/trombino.html http://dj.joss.free.fr/netiquet.htm http://frederic.sigonneau.free.fr/
Jacquouille.
"Poulpor" a écrit dans le message de news:
Ca fait plaisir de voir cette emulation autour de ce problème.
Donc, comme on ne précise jamais assez le problème et la situation, je précise :
Il s'agit d'un reporting, dont la source (balance) change chaque mois, et même la table de correspondance est amenée àévoluer quand de nouveaux comptes sont créés.
Et à partir de ces bases, on crée un tableau ( mois * codes budgétaires), et on souhaite trouver la formule miracle qui somme suivant le mois, et surtout suivant un critère dépendant le la table de correspondance.
Evidemment, il y a suffisament de lignes, comptes, et codes budgétaires pour qu'une solution de type manuel soit envisagée, comme créer une liste manuellement, faire un sommeprod avec un nombre d'arguments pouvant être monstrueux. De plus, l'évolution de la nommenclature des comptes engendrerait un contrôle de chaque formule ou nom.
Je ne sais pas vous, mais moi, je n'arrete pas de penser que sous access, ce type de problème est rapidement résolu !
Merci encore à tous.
Philippe
Bonjour en cette nouvelle matinée.
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu.... Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu pourras faire l'économie de la validation matricielle Ceci dit, dans ta proposition, il manque un test logique (prise en compte du mois de référence)...
AV
Bonsoir
Adepte de Sommeprod, je persiste et signe pour cette solution.
Mais, il y en a des ceusses qui n'aiment pas.
La maison peut proposer, moyenant un léger supplément, une solution à base
de filtre, puis de SOUS.TOTAL
Cette seconde recette, un rien plus longue, a aussi ses adeptes.
Bonne chance.
--
Bien amicalmement,
Vivement conseillés:
http://www.excelabo.net
http://jacxl.free.fr/mpfe/trombino.html
http://dj.joss.free.fr/netiquet.htm
http://frederic.sigonneau.free.fr/
Jacquouille.
"Poulpor" <Poulpor@discussions.microsoft.com> a écrit dans le message de
news: C24762F4-8470-4BAA-9225-F39576FA2CFC@microsoft.com...
Ca fait plaisir de voir cette emulation autour de ce problème.
Donc, comme on ne précise jamais assez le problème et la situation, je
précise :
Il s'agit d'un reporting, dont la source (balance) change chaque mois, et
même la table de correspondance est amenée àévoluer quand de nouveaux
comptes
sont créés.
Et à partir de ces bases, on crée un tableau ( mois * codes budgétaires),
et
on souhaite trouver la formule miracle qui somme suivant le mois, et
surtout
suivant un critère dépendant le la table de correspondance.
Evidemment, il y a suffisament de lignes, comptes, et codes budgétaires
pour
qu'une solution de type manuel soit envisagée, comme créer une liste
manuellement, faire un sommeprod avec un nombre d'arguments pouvant être
monstrueux. De plus, l'évolution de la nommenclature des comptes
engendrerait
un contrôle de chaque formule ou nom.
Je ne sais pas vous, mais moi, je n'arrete pas de penser que sous access,
ce
type de problème est rapidement résolu !
Merci encore à tous.
Philippe
Bonjour en cette nouvelle matinée.
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est
très
intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu....
Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu
donc tu
pourras faire l'économie de la validation matricielle
Ceci dit, dans ta proposition, il manque un test logique (prise en
compte du
mois de référence)...
Bonsoir Adepte de Sommeprod, je persiste et signe pour cette solution. Mais, il y en a des ceusses qui n'aiment pas. La maison peut proposer, moyenant un léger supplément, une solution à base de filtre, puis de SOUS.TOTAL Cette seconde recette, un rien plus longue, a aussi ses adeptes. Bonne chance.
-- Bien amicalmement, Vivement conseillés: http://www.excelabo.net http://jacxl.free.fr/mpfe/trombino.html http://dj.joss.free.fr/netiquet.htm http://frederic.sigonneau.free.fr/
Jacquouille.
"Poulpor" a écrit dans le message de news:
Ca fait plaisir de voir cette emulation autour de ce problème.
Donc, comme on ne précise jamais assez le problème et la situation, je précise :
Il s'agit d'un reporting, dont la source (balance) change chaque mois, et même la table de correspondance est amenée àévoluer quand de nouveaux comptes sont créés.
Et à partir de ces bases, on crée un tableau ( mois * codes budgétaires), et on souhaite trouver la formule miracle qui somme suivant le mois, et surtout suivant un critère dépendant le la table de correspondance.
Evidemment, il y a suffisament de lignes, comptes, et codes budgétaires pour qu'une solution de type manuel soit envisagée, comme créer une liste manuellement, faire un sommeprod avec un nombre d'arguments pouvant être monstrueux. De plus, l'évolution de la nommenclature des comptes engendrerait un contrôle de chaque formule ou nom.
Je ne sais pas vous, mais moi, je n'arrete pas de penser que sous access, ce type de problème est rapidement résolu !
Merci encore à tous.
Philippe
Bonjour en cette nouvelle matinée.
tu as raison AV, je vais approfondir.Quoiqu'il en soit le problème est très intérressant à développer.
Merci du retour
Une solution avec formules matricielles qui a l'air de fonctionner:
Heu.... Il ne t'a pas échappé que SP induit un calcul matriciel et en plus, tu donc tu pourras faire l'économie de la validation matricielle Ceci dit, dans ta proposition, il manque un test logique (prise en compte du mois de référence)...
