si tu as des documents complexes où la mise en page est importante et dont les layouts te seront fournis par un autre service (au hasard le service marketing...) pour moi la meilleure solution est....

le document Word + le mail merge contrôlé par PB (ou le contrôle direct de Word par OLE)

ça m'arrache un peu la g. de dire ça mais d'après mon expérience vécue c'est le mieux car ainsi tu n'as pas à te tracasser quand le modèle de document change et tu n'est pas responsable d'éventuelles fautes d'orthographe ou de mise en page , tu peux "exiger" des services qu'ls te fournissent le doc en format Word (alors que tu ne peux pas leur demander de faire la DW Object)
Et comme souvent ces services changent d'avis il est parfois très pénible de devoir retoucher une DW qu'on a mis 3 heures à configuer au milipoil ...

My 2 cents

Agimation a écrit:

J'aurais voulu aussi pouvoir tout mettre dans la DB et intégrer l'édition entièrement dans l'application. (Les documents sont stables).

salut, à ce moment-là c'est de la bonne DW composite "100% pur pb, label rouge" avec plein d'autres composites embarquées et faudra faire passer les bons paramètres entre tout ça, mais y'a rien de sorcier. Tu seras certainement amené à faire le genre de composite qui affiche un sous-report ou un autre selon un paramètre, etc.
C'est la DW principale qui risque d'avoir une bonne tripotée d'arguments, sauf si tu stockes ça dans une ligne d'une table "arguments" avant le retrieve et tu ne passes à la dw que l'ID de la ligne
voilà quelques pistes

bon courage

EDIT : un petit tip au passage : il est possible de faire une "pseudo-DW composite" qui utilise une requête SQL en créant une DW form ou tab puis y en insérant un report.

on te soigne aux petits oignons, car tu nous ramenes que des cas tordus... 
c'est normale non ?

chez le client actuel, les editions complexes sont faites sous Crystal Report.
Mais bon, je ne pense pas que ca va te faire avancer...