Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 12 sur 12
  1. #1
    Membre à l'essai
    Développeur informatique
    Inscrit en
    décembre 2010
    Messages
    53
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2010
    Messages : 53
    Points : 20
    Points
    20

    Par défaut FB + Delphi + Publication de doc

    Bonjour,

    Je développe un projet sous Delphi XE2 et FB 2.5.

    Je cherche une solution pour publier un rapport à partir:
    • des données contenues dans la bdd
    • des images contenues dans la bdd
    • d'un fichier squelette contenu dans la bdd.

    Ce fichier sera éditable à partir de l'application et sera composé de balises à remplacer par les données de la bdd lors de la publication du document (ex: "balise_nomentreprise" du fichier squelette sera remplacée par "groggle" lors de la publication).

    Quelle serait la meilleure solution pour mettre en place un tel outil ?
    Je me demande:
    • quel type de fichier je dois utiliser (word, html, xml ?)
    • comment le stocker dans la bdd(blob je suppose) ?
    • comment avoir une visu modifiable de ce fichier squelette (composant vcl?) ?

    L'insertion du fichier squelette dans la bdd n'est pas obligatoire.

    Par contre, pour l'avoir déjà utilisé dans une autre vie, je pense que je n'utiliserai pas OLE/Word car trop dépendant des versions de Word installées sur les postes.

    Merci pour vos retours.

  2. #2
    Expert Confirmé Sénior Avatar de ShaiLeTroll
    Homme Profil pro
    Développeur C++\Delphi
    Inscrit en
    juillet 2006
    Messages
    9 930
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations professionnelles :
    Activité : Développeur C++\Delphi
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2006
    Messages : 9 930
    Points : 14 474
    Points
    14 474

    Par défaut

    l'XML me semble le plus ouvert
    Surtout couplé à un XSL qui te permettra dans le transformer en un autre XML, en HTML, en JSON ou même en format DFM

    les outils de Reporting comme Report Builder, utilise une DFM comme format de stockage du modèle, après tout, c'est qu'un ensemble de TComponent que l'on peut imbriquer dans des TCollection
    ou même des TGraphicControl qui gère le Canvas aussi bien à l'écran qu'à l'impression


    Pour le stockage, j'ai stocké en BLOB, des Word, Excel, PDF ..., perso, j'utilise souvent une table dédiée à cela, après c'est juste des jointures pour associer un ID Lamda à un ID de Document
    J'hévite les blobs directement avec une autre table de donné, surtout si l'on a tendance à utiliser trop souvent le SELECT *

    En C++Builder, j'ai récemment utilisé un TClientDataSet pour gérer une contenu "polymorphe" d'une table !
    Cette table est composé d'une clé primaire (deux clé étrangère) et d'un BLOB contenant le binaire Midas, le contenu de celui-ci peut varier car exploiter par différentes implémentations de la même interface dans plusieurs DLL et je n'avais pas envie de faire une table par implémentation

    Pour le merge de balise, faudrait te trouver un équivalent Delphi au Smarty du PHP

    Perso, j'en ai fait un récemment en C++Builder, un RTF contenant des <BALISE>, ouverture du fichier avec un TStringStream, des StringReplace brutal et pas optimisé, et ça génère un RTF mergé prêt à être imprimé au besoin !

    Pour intégrer un Builder, tu as des composant comme TJvInspector, alors l'outil de Scripting de TMS

    le XML génére une DFM, tu joues avec l'IDE de TMS, puis une fonction Delphi te retransforme la DFM en XML



    J'avais fait la même chose en Delphi, il y a quelques années
    Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
    Attention Troll Méchant !
    "Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
    Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
    L'ignorance n'excuse pas la médiocrité !

    L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
    Il faut avoir le courage de se tromper et d'apprendre de ses erreurs

    Halte à la ségrégation des Cinémas, VO sur Paris, VF en Banlieue, Abonnement résilié !

  3. #3
    Membre à l'essai
    Développeur informatique
    Inscrit en
    décembre 2010
    Messages
    53
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2010
    Messages : 53
    Points : 20
    Points
    20

    Par défaut

    Bonjour ShaiLeTroll,

    Je te remercie pour ta réponse même si de nombreuses notions (DFM ? C'est le même DFM que les fiches Delphi ?) dont tu me parles sont obscures pour moi

    Pour le stockage, j'ai stocké en BLOB, des Word, Excel, PDF ..., perso, j'utilise souvent une table dédiée à cela, après c'est juste des jointures pour associer un ID Lamda à un ID de Document
    J'hévite les blobs directement avec une autre table de donné, surtout si l'on a tendance à utiliser trop souvent le SELECT *
    OK, j'étais parti sur ce modèle de base.

    Pour intégrer un Builder, tu as des composant comme TJvInspector, alors l'outil de Scripting de TMS
    le XML génére une DFM, tu joues avec l'IDE de TMS, puis une fonction Delphi te retransforme la DFM en XML
    Tu me parles de la manière dont l’utilisateur pourrait construire son fichier à travers mon appli ? TJvInspector ne fait pas ça il me semble .
    Il faut pour l'utilisateur un éditeur de texte complet (type quasi-Word) intégré au programme dans lequel il pourra mettre en page son doc et ajouter ses <balises>. Ensuite j'enregistre le fichier au format xml.

    Perso, j'en ai fait un récemment en C++Builder, un RTF contenant des <BALISE>, ouverture du fichier avec un TStringStream, des StringReplace brutal et pas optimisé, et ça génère un RTF mergé prêt à être imprimé au besoin !
    Je pensais faire de même sur le fichier xml mis en page par l'utilisateur. Tu dis que c'est brutal et non optimisé. Comment faire mieux ?

    Merci

  4. #4
    Expert Confirmé Sénior Avatar de ShaiLeTroll
    Homme Profil pro
    Développeur C++\Delphi
    Inscrit en
    juillet 2006
    Messages
    9 930
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations professionnelles :
    Activité : Développeur C++\Delphi
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2006
    Messages : 9 930
    Points : 14 474
    Points
    14 474

    Par défaut

    Citation Envoyé par lefju cabro Voir le message
    DFM ? C'est le même DFM que les fiches Delphi
    le même DFM, manipulable via TStream.ReadComponent\Write et les fonctions ObjectTextToBinary\ObjectBinaryToText pour convertir une DFM binaire en DFM Texte et réciproquement


    Citation Envoyé par lefju cabro Voir le message
    Tu me parles de la manière dont l’utilisateur pourrait construire son fichier à travers mon appli ? TJvInspector ne fait pas ça il me semble .
    Oui, ce n'est qu'une partie, j'utilisais Greatis Form Designer pour cela !
    C'était pour construire des écrans !

    Un Rapport c'est pas très différent, c'est un tas de Label

    Mais, tu peux faire plus simple avec RTF et Wordpad, l'avantage est que RTF est simple à modifier à la main par rapport à un fichier word, et que son format est moins "fluctuant"

    Citation Envoyé par lefju cabro Voir le message
    Je pensais faire de même sur le fichier xml mis en page par l'utilisateur. Tu dis que c'est brutal et non optimisé. Comment faire mieux ?
    Le RTF modèle dans la dernier appli fait 2Ko, c'est quasi-instantanée !
    Disons que pour un fichier de 1Mo, ça passera, tout dépend le nombre de balise, dans ma problématique, c'était des noms de champ d'une table (environ 60)

    Tu verras par la suite pour les perfs, fait juste un code assez souple pour faciliter par d'un "merger" à un autre au besoin


    As-tu étudier FastReport et un export en PDF ?
    Cela peut faire cela aussi !
    Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
    Attention Troll Méchant !
    "Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
    Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
    L'ignorance n'excuse pas la médiocrité !

    L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
    Il faut avoir le courage de se tromper et d'apprendre de ses erreurs

    Halte à la ségrégation des Cinémas, VO sur Paris, VF en Banlieue, Abonnement résilié !

  5. #5
    Membre à l'essai
    Développeur informatique
    Inscrit en
    décembre 2010
    Messages
    53
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2010
    Messages : 53
    Points : 20
    Points
    20

    Par défaut

    Merci pour tes conseils ShaiLeTroll mais je suis perdu.

    J'ai regardé les DFM et Greatis Form Designer mais je ne pense pas (ou alors je ne vois pas) comment l'utiliser dans mon cas. Et c'est peut-être trop puissant pour ce que je souhaite faire.

    Concernant FastReport, que je connaissais uniquement de nom, j'ai pu tester une version d'essai mais le paramétrage du document par un utilisateur me parait compliqué: la création de champs et le lien avec la donnée rebutera nos utilisateurs. Ou alors existe-t-il une méthode que je pourrai utiliser dans Delphi de manière conviviale ?

    Je souhaite un éditeur de texte facile à utiliser/modifier/paramétrer et très amélioré (presque comme Word mais sans le problème de version).
    Serait-il possible de:
    - créer un fichier Word qui sera modifié par l'utilisateur
    - enregistrer ce ficher Word dans la BDD au format XML
    - modifier le XML contenu dans la BDD dans Word
    - remplacer les balises du XML lors de la publication
    - publier ce XML avec la mise en page du Word
    Possible ou je suis en plein délire ?

    Merci

  6. #6
    Expert Confirmé Sénior Avatar de ShaiLeTroll
    Homme Profil pro
    Développeur C++\Delphi
    Inscrit en
    juillet 2006
    Messages
    9 930
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations professionnelles :
    Activité : Développeur C++\Delphi
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2006
    Messages : 9 930
    Points : 14 474
    Points
    14 474

    Par défaut

    Quel est le format souhaite à la sortie ?
    Une impression papier ?
    Une page Web en ligne ?
    Un Fichier PDF ?

    Le plus difficile sera la modification façon Word !

    Pourquoi tu ne commences pas par un RTF et Wordpad, un truc simple
    un TRichEdit pour la modification et tu pourras fournir l'ajout des tes balises !

    De te façon, pour certains utilisateurs même une <BALISE> c'est déjà trop compliqué !


    Si c'est un projet pro, refléchi à de la prestation, fait toi un outil facile à utiliser pour un développeur ou un utilisateur "averti", tu pourras soit vendre de la formation, et pour les flemards, tu vends de la prestation pour configurer leurs impressions et autres courriers


    Pour le moment, tu es en train de vouloir refaire Word et ses champs de fusion !

    ReportBuilder équipé d'un TwwRichEdit gère des RTF avec balise, il fait automatiquement les merges

    Je l'avais fait à la main car je devais générer un fichier TXT non formaté au lieu d'une sortie PDF\Papier, je n'avais pas trouvé sur le ReportBuilder comment faire une telle sortie, d'où un merge à la mano !
    En fouillant, quelques temps plus tard, je pense que RB aurait pu me le faire !
    Le code fonctionnait, TPCM, comme c'était pour de l'envoie en masse, je maitrisais mieux l'affaire !


    Tu pourras imaginer un système XML <-> HTML par la suite mais cela me semble peut-être inutilement complexe pour ta problèmatique
    Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
    Attention Troll Méchant !
    "Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
    Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
    L'ignorance n'excuse pas la médiocrité !

    L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
    Il faut avoir le courage de se tromper et d'apprendre de ses erreurs

    Halte à la ségrégation des Cinémas, VO sur Paris, VF en Banlieue, Abonnement résilié !

  7. #7
    Membre à l'essai
    Développeur informatique
    Inscrit en
    décembre 2010
    Messages
    53
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2010
    Messages : 53
    Points : 20
    Points
    20

    Par défaut

    Quel est le format souhaite à la sortie ?
    Une impression papier ?
    Une page Web en ligne ?
    Un Fichier PDF ?
    Le fichier de sortie doit être électronique et modifiable par l'utilisateur. Ce logiciel professionnel sera utilisé dans un milieu technique. La publication du fichier de sortie contiendra les valeurs d'indicateurs techniques à partir desquelles l'utilisateur fera son diagnostic. Et c'est ce diagnostic que l'utilisateur va saisir dans le document de sortie avant de l'imprimer (papier/pdf).

    Pourquoi tu ne commences pas par un RTF et Wordpad, un truc simple
    un TRichEdit pour la modification et tu pourras fournir l'ajout des tes balises !
    Je vais soumettre l'idée mais je pense que ça ne sera pas accepté car le RTF est trop limité.

    De te façon, pour certains utilisateurs même une <BALISE> c'est déjà trop compliqué !
    Tu as raison, c'est pour cela que je dois faire au plus simple: Word me paraissait bien car connu de tous.


    Si c'est un projet pro, refléchi à de la prestation, fait toi un outil facile à utiliser pour un développeur ou un utilisateur "averti", tu pourras soit vendre de la formation, et pour les flemards, tu vends de la prestation pour configurer leurs impressions et autres courriers
    Le logiciel s'adressera à des techniciens dont la connaissance de l'info est parfois limitée.
    Dans ce cas, ok pour prévoir de la formation et/ou prestation pour config de rapport.
    Pour les autres, tu me conseillerais plutôt d'utiliser RaveReport (fourni avec EX-2), FastReport ou ReportBuilder intégré dans mon logiciel construit sous XE-2 et FB ?

    Merci

  8. #8
    Expert Confirmé Sénior Avatar de ShaiLeTroll
    Homme Profil pro
    Développeur C++\Delphi
    Inscrit en
    juillet 2006
    Messages
    9 930
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations professionnelles :
    Activité : Développeur C++\Delphi
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2006
    Messages : 9 930
    Points : 14 474
    Points
    14 474

    Par défaut

    Si c'est ce fichier doit être en format électronique, il faudrait étudier si il existe déjà des standards lié aux métiers que tu cibles ou même plus générale

    Par exemple en Santé, il y a HPrim par exemple.

    Le fichier de sortie doit être électronique et modifiable par l'utilisateur
    le "modifiable" me choque, est-ce que le fichier généré est modifiable ou alors c'est via ton logiciel que l'on change les données dans FireBird et tu regénère une nouvelle version du document (anulant le précédent)

    Pour une question de traçabilité, j'aurais tendance à dire que tout doit être dans FireBird, ce "fichier" n'est qu'une finalité mais pas un moyen !
    Mais cela dépend énormément de ton métier !
    Tu es vague, une clause de confidentialité ?
    Mais du coup difficile de bien comprendre ta problématique métier et donc te proposer les bonnes technologies

    Si ce fichier n'est modifié qu'au sein d'une entreprise sur un LAN, ton application Delphi sera tout à fait approprié pour gérer le "fichier" via des TForm, TEdit ... la version finale n'étant généré qu'en dernier recours

    Tu peux considérer plusieurs niveaux d'utilisateurs, ce qui vont "créer" les formulaires et ceux qui vont "répondre" aux formulaires
    A chaque formulaire est associé un rapport (voir si l'on peut en code pré-créer un rapport pour que l'utilisateur n'ait qu'à modifier son aspect sans se préoccuper des données)

    Si ce fichier peut-être modifié par des intervenants volatiles (un peu partout en france ou ailleurs), peut-être qu'une application Web serait préférable pour que tout utilisateur autorisé puisse consulter et modifier son document
    une version téléchargeable en PDF pour la finalité

    Tu as des logiciels de gestion de contenu (CMS), tu as aussi des outils de formulaire en ligne comme Drupal, Voozanoo ou Google Forms
    Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
    Attention Troll Méchant !
    "Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
    Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
    L'ignorance n'excuse pas la médiocrité !

    L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
    Il faut avoir le courage de se tromper et d'apprendre de ses erreurs

    Halte à la ségrégation des Cinémas, VO sur Paris, VF en Banlieue, Abonnement résilié !

  9. #9
    Membre à l'essai
    Développeur informatique
    Inscrit en
    décembre 2010
    Messages
    53
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2010
    Messages : 53
    Points : 20
    Points
    20

    Par défaut

    Si c'est ce fichier doit être en format électronique, il faudrait étudier si il existe déjà des standards lié aux métiers que tu cibles ou même plus générale
    Par exemple en Santé, il y a HPrim par exemple.
    A notre connaissance, il n'existe pas de solution/standard.


    Mais cela dépend énormément de ton métier !
    Tu es vague, une clause de confidentialité ?
    Mais du coup difficile de bien comprendre ta problématique métier et donc te proposer les bonnes technologies
    Mon logiciel va être utilisé pour de la prestation technique: des mesures sont effectuées sur site (connexion internet rarement dispo) et enregistrées dans la BDD. Ces mesures sont traitées pour fournir des indicateurs qui aideront l'utilisateur à faire son diagnostic (RAS ou en panne). Le diag. est également stocké dans la BDD.

    le "modifiable" me choque, est-ce que le fichier généré est modifiable ou alors c'est via ton logiciel que l'on change les données dans FireBird et tu regénère une nouvelle version du document (anulant le précédent)
    Avec ce que je viens de décrire, je me rends compte que je n'ai pas forcément besoin d'avoir un fichier modifiable. C'est juste que c'est plus confortable pour un utilisateur d'avoir un fichier éditable afin d'y rajouter d'autres infos qui ne pourraient pas être dispo dans la BDD.

    En conclusion, je pencherai vers un outil de reporting. Ai-je raison ? Si oui, tu me conseillerais RaveReport (fourni avec EX-2), FastReport ou ReportBuilder intégré dans mon logiciel construit sous XE-2 et FB ?

    Merci

  10. #10
    Rédacteur/Modérateur
    Avatar de SergioMaster
    Homme Profil pro Serge Girard
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    5 088
    Détails du profil
    Informations personnelles :
    Nom : Homme Serge Girard
    Âge : 57
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : janvier 2007
    Messages : 5 088
    Points : 9 421
    Points
    9 421

    Par défaut

    Rave aurait été parfait , il y a même une possibilité payante pour avoir une modification pour l'utilisateur. Le problème Rave n'est plus vraiment pérenne
    (plus fourni avec XE3)
    La seule chose absolue dans un monde comme le nôtre, c'est l'humour. » Albert Einstein
    J'entends et j'oublie. Je vois et je me souviens. Je fais et je comprends . Confucius
    Si votre seul outil est un marteau, vous aurez tendance a ne voir que des clous

  11. #11
    Expert Confirmé Sénior Avatar de ShaiLeTroll
    Homme Profil pro
    Développeur C++\Delphi
    Inscrit en
    juillet 2006
    Messages
    9 930
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations professionnelles :
    Activité : Développeur C++\Delphi
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2006
    Messages : 9 930
    Points : 14 474
    Points
    14 474

    Par défaut

    Citation Envoyé par lefju cabro Voir le message
    Mon logiciel va être utilisé pour de la prestation technique: des mesures sont effectuées sur site (connexion internet rarement dispo) et enregistrées dans la BDD. Ces mesures sont traitées pour fournir des indicateurs qui aideront l'utilisateur à faire son diagnostic (RAS ou en panne). Le diag. est également stocké dans la BDD.
    Donc utilisation de la BDD assez large

    Donc soit une appli Web ou même une application mobile FMX utilisant un serveur DataSnap Rest ou JSON pour échanger les données
    Mais cela nécesiste une connexion internet, avec un SmartPhone, ce n'est plus aujourd'hui vraiment un problème

    Soit un mode briefcase avec des XML de TClientDataSet, ton programme stockée sur une clé USB, il met à jour des XML sur la clé USB

    Lorsqu'une connexion réseau est disponible (ou que l'intervenant rentre au bercail), le XML est fusionné dans la DB Principale, cela peut nécessiter de la Consolidation des données lors de l'import

    Cela peut aussi se faire avec un FB Embedded

    D'ailleurs, si cela se trouve, tu n'as jamais prévu de faire une DB centralisé, mes réponses, étaient plutôt orienté centralisé ou mutualisé avec des possibilités de terminaux non connecté, maintenant le terme à la mode c'est le Cloud mais c'est déjà concept que l'on utilise déjà massivement dans beaucoup de domaine où l'information est le coeur du métier

    Tu as beaucoup d'appli qui utilisait ce genre de système de synchro avec des Palm ou PSION par exemple !
    Typiquement les livreurs, il scanne le code barre, une signature, hop à la fin de la journée, le terminal sur le dock, upload des données ...
    J'ai vu la même chose dans des entrepots lors des inventaires (le flux de données dans cette circonstance dépassant les capacité en HF pour les manip quotidienne de Picking, il était plus efficace d'utiliser un mode filaire)

    Le terminal pouvant évidemement être aussi un ordinateur portable !
    C'est même le plus fréquent !




    Citation Envoyé par lefju cabro Voir le message
    C'est juste que c'est plus confortable pour un utilisateur d'avoir un fichier éditable afin d'y rajouter d'autres infos qui ne pourraient pas être dispo dans la BDD.
    C'est le problème, tu aurais ainsi DEUX lieux de stockage, la BDD et ces fichiers qui se baladent !
    Pour faire des statistiques, ce n'est pas évident !


    Citation Envoyé par lefju cabro Voir le message
    En conclusion, je pencherai vers un outil de reporting. Ai-je raison ?
    La durée de vie des outils de reporting dans Delphi a toujours été d'environ 5 à 7 ans, QuickReport 10 plus tard existent toujours en version séparée, il serait surement de même pour RaveReport, c'est une histoire de business !

    Tout ceux qui ont des centaines de rapport en Rave acheteront la licence, ça coutera moins cher que de tout migré dans un nouvel outil

    ReportBuilder étant déjà externe, c'est un choix, tu peux d'ailleurs intégrer le Builder de Rapport à ton appli !
    La plupart du temps, je ne m'occupais pas des rapports, c'était les "installeurs" qui créait des Modèles en utilisant un outil de requêtage (assez poussé d'ailleurs, permettant de sortir des stats, des données croisées ...)
    Les "installeurs" utilisaient l'appli Delphi pour créer les rapports dans un contexte DB très ciblé


    Tu devrais analyser les besoins de tes utilisateurs, savoir au quotidien ce qui serait VRAIMENT pratique et qui garantirait la QUALITE des données !

    Peut-être que ce rapport ne sera qu'une version "finale" des données récoltées

    ou alors une version intermédiaire
    un utilisateur créer un modèle de fiche, les intervenants utilisent une version papier de ces fiches, il gribouille leurs commentaires, des opérateurs de saisie recopies les données papier dans le logiciel, puis au besoin une version finale est imprimé !
    C'est très courant cela !

    Il existe d'ailleurs, des Stylo numériques sur papier pré-imprimé pour justement éviter la phase de saisie, voir les solutions d'Anoto par Exemple
    Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
    Attention Troll Méchant !
    "Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
    Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
    L'ignorance n'excuse pas la médiocrité !

    L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
    Il faut avoir le courage de se tromper et d'apprendre de ses erreurs

    Halte à la ségrégation des Cinémas, VO sur Paris, VF en Banlieue, Abonnement résilié !

  12. #12
    Membre à l'essai
    Développeur informatique
    Inscrit en
    décembre 2010
    Messages
    53
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2010
    Messages : 53
    Points : 20
    Points
    20

    Par défaut MERCI

    Je vous remercie pour vos réponses, je pense utiliser un outil de report (qui reste encore à définir)

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •