J'ai choisi Excel

[kisitomomotene]

Salut à tous.

Je devais choisir un outil de reporting pour mon projet, je rappelle que je n'ai aucune expérience sur un outil de reporting dédié. J'ai finalement décidé d'utiliser Excel. Voici ce qui m'a finallement poussé à faire ce choix.

- J'étais en présence d'un état papier fait sur Word, et je me suis demandé si les générateurs d'état auront suffisamment des fonctionalités d'un traitement de texte pour reproduire le même design que j'avais devant moi.
- Je me suis posé la question de savoir si les générateurs d'état avaient des fonctionnalités suffisamment avancées pour réaliser des états complexes ou des états très spécifiques auquels je pourrais être confronté plus tard.
- Je me suis posé la question dois je prendre le risque de m'engager à me former sur l'utilisation d'un outil de reporting pour constater plus tard qu'il a des limites sur des fonctionnalités citées ci-dessus?

Face à toutes ces interrogations qui n'avaient pas de réponse, j'ai alors décidé d'utiliser Excel ou Word pour programmer mes Etats. Mais Excel ayant beaucoup plus de facilité de programmation que Word, j'ai finalement décidé de choisr Excel. Voici pourquoi:
- Réaliser les templates des états sera très facile ( à la portée de presque tous les utilisateurs), et offrira beaucoup de possibilités de design, on exploitera la richesse de Office pour concevoir des états de haute qualités.
- Comme les états sont programmés, je serais difficilement coincé par des états trops complexes ou très spécifiques.
- j'exploie la richesse de calcul d'excel, pour m'épargner des requêtes SQL très complexes.

mais comme inconvénient je suis obligé de programmer tous mes états, mais comme j'ai de l'expérience en programmation Excel ce ne sera pas un grop handicap.

Voila le temoigange que je voudrais partager avec vous.

[BiM]

Merci d'ajouter ton témoignage ici :
Quel est le meilleur générateur d'états selon vous ?

Merci

[kisitomomotene]

Envoyé par BiM

Merci d'ajouter ton témoignage ici :
Quel est le meilleur générateur d'états selon vous ?

Merci

Ok c'est déjà fait. En fait je ne m'étais pas retrouvé dans la nouvelle organisation de ce salon, je ne retrouvait plus "le comparatif".

[BiM]

Ben voilà, c'est fait, je demanderais à un modérateur de supprimer ton sujet

[hadrien.boye]

d'après mon expérience (excel et crystal reports) je pense qu'Excel est un bon outil pour faire du reporting quand il s'agit de faire du "vite fait" mais c'est loin d'être l'idéal pour les raisons suivantes :
- pour faire un nouvel état, il faut des compétences informatiques (requêtage dans la bdd et codage en VBA pour alimenter les feuilles)
- c'est pas toujours le bienvenue : ex. un responsable qualité qui veux se bricoler un état n'est pas (en général) un pro des macros excel et du SQL
- dans la plus part des cas, il faut ouvrir excel sur son poste pour éditer un état (nécessite windows, nécessite excel, nécessite de pouvoir accéder à la source de données depuis son poste)
- si il est utilisé sur une machine serveur, il faut que ce dernier tourne sous windows et dispose d'une license Excel
- les états générés sont évidement au format Excel... donc pour faire un export PDF, XML, HTML... c'est à la main, dans les menus
- les performances et la stabilié des macros VBA ne sont pas forcément une référence

En revanche, un vrai générateur d'état comme crystal reports permet de (moyennant un investissement financier certain) :
- créer de nouveaux états tout à la souris en wysiwyg (no sql, no code) notre responsable qualité a le smile
- générer des exports dans des dizaines de format (le même état est utilisé pour faire une page web, un fichier pdf, du xml... et même du XLS !)
- obtenir une mise en page beaucoup plus précise que sous Excel (on oublie les cellules)
- décrire des états aussi complexe que possible puisqu'un langage de script permet de définir des règles de calcul et d'affichage sur chacun des champs
- être pris en main assez rapidement et à différents niveaux d'utilisation

après, c'est clair que pour rentabiliser l'investissement financier et en temps d'apprentissage dans Crystal, c'est une solution addapté pour la production massive d'états de reporting

si vous avez des retours sur d'autres outils de reporting, ça m'intéresse !

[BiM]

Idem dans Quel est le meilleur générateur d'états selon vous ?

[kisitomomotene]

Envoyé par hadrien.boye

d'après mon expérience (excel et crystal reports) je pense qu'Excel est un bon outil pour faire du reporting quand il s'agit de faire du "vite fait" mais c'est loin d'être l'idéal pour les raisons suivantes :
- pour faire un nouvel état, il faut des compétences informatiques (requêtage dans la bdd et codage en VBA pour alimenter les feuilles)

Non je ne parle pas de VBA mais de la programmation en utilisant le composant COM Excel. Et on peut le faire dans tous les langages , car presque tous les langages ont une interface avec COM. Par exemple je suis entrain de le faire en Java. D'autre part je place dans la situation où l'utilisateur conçois juste un modèle de l'état qu'il souhaite en utilisant Word ou Excel ( que tout le monde connait bien) et la passe au programmeur pour qu'il l'implémente, donc chacun fait son Job.
Je ne vois pas comment on peut concevoir un état sans définir une requête dans une bdd, donc démannder à un utilisateur de concevoir entièrement ces états c'est l'obliger à la limite d'apprendre la technologie des bdd et je ne crois pas que ce soit son job.

Envoyé par hadrien.boye

- les états générés sont évidement au format Excel... donc pour faire un export PDF, XML, HTML... c'est à la main, dans les menus

On fait tout cela par programmation, le composant COM Excel a des objet pour générer automatiquement du HTML, du XML ,il ne manque que du PDF (Adobe ne veut tjrs pas donner une licence à M$)

[hadrien.boye]

ok, je perçois mieux ce que tu veux dire : tu utilise Excel simplement comme générateur de document, en le pilotant depuis une autre application... mais on ne peux pas vraiment parler de générateur de reporting.

Envoyé par kisitomomotene

Je ne vois pas comment on peut concevoir un état sans définir une requête dans une bdd, donc démannder à un utilisateur de concevoir entièrement ces états c'est l'obliger à la limite d'apprendre la technologie des bdd et je ne crois pas que ce soit son job.

Et bien les outils évolués de conception d'état permettent de concevoir d'une part les modèles de documents de manière complètement graphique et de définir les liens entre les données à requêter de manière quasi-transparente et également graphique, voir même guidée par des assistants. Dans ce cas, c'est l'outil lui-même qui va générer automatiquement les requêtes SQL (pas toujours optimisées malheureusement) qui se chargeront de ramener les données pour alimenter l'état lors de la génération.

Si tu veux plus d'infos là dessus : renseigne toi sur les fonctionnalités de Crystal Reports.

sinon, j'ai une question : quelle API utilise tu pour piloter Excel depuis du code Java ?

Envoyé par kisitomomotene

On fait tout cela par programmation, le composant COM Excel a des objet pour générer automatiquement du HTML, du XML ,il ne manque que du PDF (Adobe ne veut tjrs pas donner une licence à M$)

justement, des outils (encore une fos) comme Crystal, implémentent nativement tous les convertisseurs nécessaires à l'export du document dans un format ou un autre. Ca permet donc de limiter la charge de travail à :
1 - concevoir le modèle d'état
2 - définir les liens vers le modèle de données et les règles de présentation pour chaque champ

En bref : il ya des outils qui permettent de se passer de programmation pure et dure pour générer des documents et qui permettent de reléguer les travaux de conception directement aux utilisateurs, qui disposent d'une connaissance assez précise du modèle de données métier.

[kisitomomotene]

Envoyé par hadrien.boye

ok, je perçois mieux ce que tu veux dire : tu utilise Excel simplement comme générateur de document, en le pilotant depuis une autre application... mais on ne peux pas vraiment parler de générateur de reporting.

Effectivement, j'ai choisi de générer moi même mes rapports par programmation basée sur Excel parceque je n'ai pas à priori confiance aux outils de repporting dédié pour générer des etats très spécifiques, où très complexes, je crain de m'engager sur un outil dédié dans mon projet encours et me retrouver coincé plus tard . Avec Excel (et word), je suis en totale confiance, car je contrôle tout, côté design Word est Excellent, côté fonctionnalité de traitement, Excel excel

sinon, j'ai une question : quelle API utilise tu pour piloter Excel depuis du code Java ?

Jcom est un bon outil open source. Il permet de piloter Excel et surtout tout code écrit à partir de VB.6. C'est surtout cette dernière fonctionnalité que j'utilise à travers JCom, pour ajouter à un code java des fonctionnalités spécifiquement Windows/M$ .

[nuke_y]

Mais il y a combien de topics sur ce sujet ?