Discussion :

[kisitomomotene]

Salut à tous.

Je trouve un peu surprenant que les solutions basées sur MS office pour la génération d'état sont rares et pas populaire. Pourtant je compte bien choisir ce type de solution comme base de génération d'état pour mes projets actuels et à venir. Je precise que je n'ai aucune expérience sur les générateurs d'état, mais je recherche un solution . D'abord comment est que cela fonctionnerait? en entré du générateur d'état on a un template qui est un document office (word, excel, powerpoint etc) et une source de donnée, et en sortie on a un état en pdf, html etc..
Pourquoi Office?
D'une part tous les utilisateurs ont une expérience sur Word. Donc les utilisateurs pourront facilement eux même construire les modèles de leur Etats.
D'autre part si on a à faire à un état très complexe, on peut le construire facilement par programmation en utilisant les api de création de document d'office et ceci avec n'importe quel langage, car Office s'intégre à tous les langages de programmations actuels.
Alors quelqu'un a t'il déjà regardé du côté d'office?
quel est son retour d'expérience?

[moritan]

Salut à tous.

Je trouve un peu surprenant que les solutions basées sur MS office pour la génération d'état sont rares et pas populaire. Pourtant je compte bien choisir ce type de solution comme base de génération d'état pour mes projets actuels et à venir. Je precise que je n'ai aucune expérience sur les générateurs d'état, mais je recherche un solution . D'abord comment est que cela fonctionnerait? en entré du générateur d'état on a un template qui est un document office (word, excel, powerpoint etc) et une source de donnée, et en sortie on a un état en pdf, html etc..
Pourquoi Office?
D'une part tous les utilisateurs ont une expérience sur Word. Donc les utilisateurs pourront facilement eux même construire les modèles de leur Etats.
D'autre part si on a à faire à un état très complexe, on peut le construire facilement par programmation en utilisant les api de création de document d'office et ceci avec n'importe quel langage, car Office s'intégre à tous les langages de programmations actuels.
Alors quelqu'un a t'il déjà regardé du côté d'office?
quel est son retour d'expérience?

Je te dirais de regarder aussi du coté d'accès qui as déjà une foction de reportting de prévu.
On peut utilisé access comme front-end ppour n'importe quelle base.
Je sais que j'avais fait ça en cours pour faire des états sur une base AS400.

[kisitomomotene]

Je te dirais de regarder aussi du coté d'accès qui as déjà une foction de reportting de prévu.
On peut utilisé access comme front-end ppour n'importe quelle base.
Je sais que j'avais fait ça en cours pour faire des états sur une base AS400.

Non il ne s'agit pas de la même chose plutôt que d'utiliser access c mieux d'utiliser directement crystall report ou autre.
Les utilisateurs n'ont pas l'expérience d'utilisation d'access. Le style de reporting dont je parle est basé directement sur word ou excel. L'utilisateur crée un état comme s'il editait un document, il peut utiliser les styles, les formatages de word ou excel, puis un état sera générer directement par la suite. Voir des exemples sur les liens suivants http://www.windward.net et
http://www.ljzsoft.com pour avoir un idée de quoi g parle.

[moritan]

Non il ne s'agit pas de la même chose plutôt que d'utiliser access c mieux d'utiliser directement crystall report ou autre.
Les utilisateurs n'ont pas l'expérience d'utilisation d'access. Le style de reporting dont je parle est basé directement sur word ou excel. L'utilisateur crée un état comme s'il editait un document, il peut utiliser les styles, les formatages de word ou excel, puis un état sera générer directement par la suite. Voir des exemples sur les liens suivants http://www.windward.net et
http://www.ljzsoft.com pour avoir un idée de quoi g parle.

Dans access tu as un générateur d'état qui marche comme Word on excel justement.
C'est pour ça que je t'en ai parlé.

[kisitomomotene]

Dans access tu as un générateur d'état qui marche comme Word on excel justement.
C'est pour ça que je t'en ai parlé.

Ah bon? j'aimerais bien que tu me montres comment dans Access je peux saisir un Etat en me retrouvant dans l'environnement Word (même menu, même présentation etc..).
Je rappelles que l'objectif est de permettre aux utilisateurs de créer leur propres modèles d'état directement à partir de Word ou Excel

[moritan]

Ah bon? j'aimerais bien que tu me montres comment dans Access je peux saisir un Etat en me retrouvant dans l'environnement Word (même menu, même présentation etc..).
Je rappelles que l'objectif est de permettre aux utilisateurs de créer leur propres modèles d'état directement à partir de Word ou Excel

Effectivement tu es dans Access pas dans Word.
Après à toi de voir si l'interface va convenir à tes Utilisateurs, elle est très proche à quelle offre la possibilité de placer le code.

[kisitomomotene]

Effectivement tu es dans Access pas dans Word.
Après à toi de voir si l'interface va convenir à tes Utilisateurs, elle est très proche à quelle offre la possibilité de placer le code.

Je ne sais pas si vous avez déjà essayez ce que vous dites, mais s'il y a un seul environnement où j'ai un peu d'expérience concernant la génération des états c'est bien Access. En mes connaissances il n'est pas possible de générer un état dans access en utilisant un fichier word ou Excel comme template. Et ce que je veux c'est générer un Etat en utilisant Word ou Excel comme template, je ne veux pas former les utilisateurs à un autre logiciel, et je pense que cela a beaucoup d'avantage parceque l'utilisateur obtient exactement les états qu'il veut à partir de son traitement de texte ou son tableur habituel. G n'ai vu que deux solutions par rapport à mes besoins par les liens que j'ai donné précédemment. Le plus stable à savoir WDReportGen, ne génre pas les états en PDF. Par contre Winward me génére des erreurs dès que je le lance. Et j'aimerais savoir si quelqu'un connait d'autre solutions dans le même sens ou bien à de l'expérience sur Winward pour me dire pourquoi il ne se lance même pas sur ma machine.

[moritan]

Je ne sais pas si vous avez déjà essayez ce que vous dites, mais s'il y a un seul environnement ou j'ai un peu d'expérience concernant la générations des états c'est bien Access. En mes connaissances il n'est pas possible de générer un état dans access en utilisant un fichier word ou Excel comme template. Et ce que je veux c'est générer un Etat en utilisant Word ou Excel comme template, je ne veux pas former les utilisateurs à un autre logiciel, et je pense que cela a beaucoup d'avantage parceque l'utilisateur obtient exactement les états qu'il veut à partir de son traitement de texte ou son tableur habituel. G n'ai vu que deux solutions par rapport à mes besoins par les liens que j'ai donné précédemment. Le plus stable à savoir WDReportGen, ne génre pas les états en PDF. Par contre Winward me génére des erreurs dès que je le lance. Et j'aimerais savoir si quelqu'un connait d'autre solutions dans le même sens ou bien à de l'expérience sur Winward pour me dire pourquoi il ne se lance même pas sur ma machine.

Ok je n'avais pas compris tous à fait ton besoin...
Quel version d'office utilises-tu? Car avec la version 2003 et InfoPath, tu dois pouvoir fair ce dont tu as besoin.
Par contre c'est juste une piste avec des infos lus deci de là, et jamais testé.

[kisitomomotene]

Ok je n'avais pas compris tous à fait ton besoin...
Quel version d'office utilises-tu? Car avec la version 2003 et InfoPath, tu dois pouvoir fair ce dont tu as besoin.
Par contre c'est juste une piste avec des infos lus deci de là, et jamais testé.

Infopath est un générateur de formulaires et pas d'état. Il permet de créer rapidement des formulaires qui peuvent se remplir hors connexions, puis se synchroniser directemnt avec Sql server, Access ou une source de donnée Web service dès qu'il y a connexion. En fait Infopath est un concurrent des Winforms pour des formulaires relativement simples et légers.

[moritan]

Mais couplé avec WOrdML, cela ne te permettrait pas de générer tes fichiers Word??

[kisitomomotene]

Mais couplé avec WOrdML, cela ne te permettrait pas de générer tes fichiers Word??

WordML est le format XML de Word. Cela permet par exemple à un système qui n'a pas le runtime word, de pouvoir lire un document word à l'aide des feuilles de styles et des technologies comme XSLT. Je ne cherche pas générer des fichiers Word, mes à générer des PDF à partir d'un fichier template word+une source de donnée ( SQL ou XML) et cela par programmation ou de façon interactive par les utilisateurs de word.

[kisitomomotene]

En fait voici la génése de mon problème et j'aimerais que vous me dites comment est ce que vous pouvez résoudre de façon optimale le pb que je vais poser. Je dois déveloper une appli de gestion. Actuellement les états sont faits manuellement sur word et sur Excel, et les modèles sont déjà validés par l'entreprise. Je ne suis pas sûr de reproduire fidèlement la mise en forme originale si j'utilise un autre outil de templating (je ne suis même pas sur que la mise en forme soit reproductible en dehors d'un traitement de texte), ou bien si je propose d'autre modèles d'état qu'ils soient acceptés par les utilisateurs. Alors j'ai trouvé que la solution idéale c'était de prendre tel quel les états actuels et des les utiliser comme input d'un générateur d'état.
Alors personne n'a été confronté à ce type de problème?
Comment l'a t'il résolu?

[nuke_y]

Avantages d'Office par rapport à un générateur d'état :
- pas cher
- assez ouvert
- utilisation simple
- formation réduite

Inconvénients d'Office par rapport à un générateur d'état :
- pas de capitalisation (référentiel commun, univers comme sous BO, partage des rapports, fonctions, conversions, etc.)
- pas de gestion centralisées (partage, administration, droits, etc.)
- fonction de présentation réduites (mise en page, Maître/Esclave, etc.)
- puissance limitée (Excel ne peut pas recevoir plus de 65000 lignes dans un seul onglet, etc.)

Je ne parle même pas du fait qu'il va falloir réinventer la roue complétement pour un certain nombre de fonctionnalités.

Personnellement, à ne pas prendre de générateur d'état tout fait, je monterais une série de rapports en PHP (ou autre) plutôt que jouer avec Office.

[nuke_y]

En fait voici la génése de mon problème et j'aimerais que vous me dites comment est ce que vous pouvez résoudre de façon optimale le pb que je vais poser. Je dois déveloper une appli de gestion. Actuellement les états sont faits manuellement sur word et sur Excel, et les modèles sont déjà validés par l'entreprise. Je ne suis pas sûr de reproduire fidèlement la mise en forme originale si j'utilise un autre outil de templating (je ne suis même pas sur que la mise en forme soit reproductible en dehors d'un traitement de texte), ou bien si je propose d'autre modèles d'état qu'ils soient acceptés par les utilisateurs. Alors j'ai trouvé que la solution idéale c'était de prendre tel quel les états actuels et des les utiliser comme input d'un générateur d'état.
Alors personne n'a été confronté à ce type de problème?
Comment l'a t'il résolu?

De mon point de vue, tu as raison à court terme. Il sera IMPOSSIBLE de faire accepter à tes utilisateurs la nouvelle mise en forme du générateur d'état.

Cependant il faut que dans le même temps tu arrives à convaincre tes utilisateurs de passer petit à petit à un générateur d'état qui te permettra de centraliser le reporting.

[kisitomomotene]

Inconvénients d'Office par rapport à un générateur d'état :
- pas de capitalisation (référentiel commun, univers comme sous BO, partage des rapports, fonctions, conversions, etc.)

Le partage des rapports peut se faire à travers une plateforme de publication non? (portail d'entreprise par exemple) et en plus on peut bien convertir un etat généré avec office en format html, ou pdf. Je ne comprend pas très bien ce que vous désignez par fonctions, conversions (Excel intégre bien les fonctions s'il s'agit de la même chose). Quant au reférentiel commun franchement je ne vois pas de quoi il s'agit

- pas de gestion centralisées (partage, administration, droits, etc.)
- fonction de présentation réduites (mise en page, Maître/Esclave, etc.)
- puissance limitée (Excel ne peut pas recevoir plus de 65000 lignes dans un seul onglet, etc.)

La gestion centralisée de la publication peut bien se gérée par un portails non? quant à la présentation, je ne vois pourquoi vous dites que c'est limité, pourtant je pense que Word et/ou Excel ont justement comme point fort leur capacité à faire présenter correctement des documents. La puissance limitée de Excel à 65000 lignes, c'est vrai ça peut être un frein (même si on peut tjrs contourner)

Je ne parle même pas du fait qu'il va falloir réinventer la roue complétement pour un certain nombre de fonctionnalités.
.

Là, vous avez raison. Mais si on doit générer un état trop spécifique ou trop complexe, je me dis qu'en programmant directement avec office (Excel et/ou Word) on prend moins de risque de se retrouver "coincé".

[nuke_y]

Je te l'ai dit, à court terme tu as raison, à long terme moins.

Un portail de publication t'oblige non seulement à l'acheter/développer et à l'administrer/maintenir (après s'il le faut c'est super facile pour toi) mais surtout ça ne te permet que de gérer la partie publication.

L'intérêt de certains générateurs d'états c'est aussi de fournir un univers permettant d'avoir une vision métier simplifiée des données. En gros, ton chef de service, il préfère cliquer sur "Nom", "Prénom", "Matricule", "Salaire", "lister par ordre alphabétique" puis exécuter ou taper à la main "Select CD_NOM, CD_PRE, CD_MAT, CD_SAL FROM TAB_EMPLOYE ORDER BY CD_NOM ASC" dans la query Excel ?

L'intérêt d'un générateur d'état c'est justement de pouvoir mettre à disposition de gens du métier, qui n'aiment pas la technique, toutes les analyses que TOI tu ferais en requête manuelle mais qu'ils sont incapables de faire. A force, cette capitalisation de la vision métier des données informatique devient tellement importante que des gens du metier viennent te voir TOI pour que tu leur rappelles certaines règles, ou que tu leur expliques pourquoi certaines donnes n'apparaissent pas, etc.

C'est comme avoir un vieux qui se rappelle de tout depuis le début de l'entreprise ou d'avoir des placards de documentation décrivant toutes les règles, mais disponibles tout de suite.

Un autre exemple : quand je fais des analyses rapides qui ne doivent avoir lieu qu'une seule fois, je ne développe pas un univers ou des rapports BO spécifiques. Je met tous les résultats sous Excel et je met dans un onglet du même fichier les requêtes que j'ai utilisé. Pourquoi ? Parce que dans 3/6/12 mois ils vont me redemander la même requête mais avec des données à jour et que je risque de ne pas m'en rappeler.

Après tu peux toujours te débrouiller : développer ton propre système de bibliothèque, de templates de documents, de référentiel commun, de système de publication, de conversion en PDF, de conversion métier des données informatiques, etc.

Mais sache que tout ça existe déjà tout fait et que le temps et l'énergie passé à le re-développer n'est pas forcément plus rentable que l'existant. Pas forcément... mais peut-être !

Après c'est un choix qui est évident dans les gros groupes, moins dans les PME, encore moins dans les toutes petites entreprises.

Un bon critère c'est le nombre de gens. Si moins de n personnes ont l'intention de se servir de l'infocentre, fait plutôt un truc toi même, ça coûtera moins cher.

EDIT :
Encore une chose : plus l'outil sera cher, facile d'utilisation, etc. et moins tu pourras faire de choses. Donc c'est vrai que tu risques de te retrouver bloquer avec un générateur d'état si tu veux faire des trucs très beaux ou des requêtes très complexes.

[kisitomomotene]

L'intérêt de certains générateurs d'états c'est aussi de fournir un univers permettant d'avoir une vision métier simplifiée des données. En gros, ton chef de service, il préfère cliquer sur "Nom", "Prénom", "Matricule", "Salaire", "lister par ordre alphabétique" puis exécuter ou taper à la main "Select CD_NOM, CD_PRE, CD_MAT, CD_SAL FROM TAB_EMPLOYE ORDER BY CD_NOM ASC" dans la query Excel ?

Ah vous avez touché là à un pb que je suis tjrs posé. Comment est ce que certain s'organise pour laisser la génération des états aux utilisateurs?

Parce que je crois que pour pouvoir générer des états il faut aux moins connaître le schéma de la base de donnée, car il faut savoir quelle table ou quelle vue utiliser, et si la vue n'existe pas , il faut être capable d'en créer, il faut en plus connaître le rôle des colonnes d'une table donnée car je ne suis pas sûr que le "matricule" sera représenté par une colonne "matricule" dans la table. Quand je vois le nombre de tables qui se trouvent dans mon ERP, plus de 600. Je trouve personnellement que tout ça n'est pas à la portée des utilisateurs.
Alors je me demande comment vous faites pour que vos utilisateurs générent eux même leur état.

[nuke_y]

Dejà, on évite souvent de taper directement dans l'ERP (une mauvaise requête et vlan l'ERP est à genoux). Pour ça on construit un Datawarehouse dans lequel les données sont déjà organisées pour un requêtage optimal.

Ensuite des outils comme Business Objects permettent de créer un Univers, qui est une représentation métier de tes bases. Toutes les jointures sont déjà programmées, certains champs ne sont pas accessibles, certains sont calculés à la volée, etc.

Et ainsi l'utilisateur ne se demande JAMAIS "mais est-ce que je fait ma jointure correctement".

Personnellement, il m'arrive d'aller voir dans l'Univers comment la jointure est faite parce que je ne m'en rappelle plus.

[kisitomomotene]

Si je vous ai bien compris, si par exemple on ne peut pas avoir un datawarehouse (car ça coûte très cher je crois), si on veut simplement permettre aux utilisateur de "gérer" eux même les données pour le décisionnel, on doit créer des vues orientées métiers et donner l'accès à ces vues aux utilisateurs pour qu'il fasse des analyses ou des états.
Si c'est le cas, personnellement, je vois que pour réaliser correctement un état, il faudrait trois modules ou trois compétences.
-Il y aurait d'abord la création de l'univers des objets "metiers" là on aurait besoin d'un informaticiens pour créer des vues orientées metiers (en utilisant le SQL par exemple), et d'un expert metier pour définir son "univer global"
- ensuite l'utilisateur metier pourra alors avec un reporting tool extraire le sous ensemble de "l'univer global" qui l'interesse.
-Enfin en utilisant une maquette conçue par un designer, l'utilisateur pourra alors générer effectivement son état.

[nuke_y]

Dans l'idée oui. Maintenant un DWH coûte ce que l'on veut bien y investir. Si vous avez déjà des BDD hebergeant l'ERP, il doit être possible de monter un petit DWH de données agrégées dessus.

Pour les vues oui, je ne laisserais jamais mes utilisateurs taper dans les données de production sans contrôle.

Sinon il y a des solutions intermédiaires comme de faire des cubes de données sous Access : une base Access que les développeurs alimentent toutes les semaines/mois avec des données fraîches, et les utilisateurs requêtent directement dans cette base. L'avantage c'est que la structure des données sous Access peut être très simple avec des noms de table ou de champs très parlants.