Les Editions CRYSTAL REPORTS®

Ce chapitre présente le paramétrage à effectuer pour utiliser CRYSTAL REPORTS® à partir de DIAPASON et détaille la marche à suivre pour monter un rapport destiné à être imprimé.

Dans tout ce qui suit CRYSTAL REPORTS® sera nommé CR.

Principes Généraux de CR

Cette partie présente la notion de rapport dans CR et, par là même, et fait le parallèle avec la notion de rapport dans DIAPASON.

CR est basé sur les notions de rapport et de sources de données, le rapport étant la notion principale dans CR. Un rapport est constitué de :

Une source de données (permet de définir la structure des tables impliquées) : il existe différents types de sources de données, toutefois l’intégration de CR dans DIAPASON utilise uniquement le type XML natif.

La conception du modèle (correspondant à l’image finale de l’édition proprement dite)

La conception du modèle se fait par glisser-déposer des champs des tables issues de la connexion à la source de données.

Remarque : CR intègre d’autres entités au sein d’un rapport, mais seuls les deux précités seront explicités dans cette documentation. (Voir documentation CR pour plus de détail).

La source de données issue du fichier XML est vue dans le rapport sous la forme de tables et de champs de base de données accessibles directement en conception de rapport dans l’explorateur de champs. Le glisser-déposer se fait donc entre l’explorateur de champs et le rapport Crystal.

L’Expert Base de données permet de visualiser simplement l’ensemble des sources de données du rapport ainsi que les liens éventuels entre les tables.

Remarque : Les relations entre les tables sont déduites automatiquement à partir des noms de champs identiques entre les tables.

Dans DIAPASON, un paramétrage spécifique à CR est basé sur les notions de rapports et de sources de données permettent de faire le lien avec les rapports et les sources de données de CR.

Utilisation d’un rapport DIAPASON avec CR

Rappel des Eléments Nécessaires

Deux origines possibles pour les données :

Requêtes DIALOG : de type REN ou REB. Leur but étant de générer une ou n listes de sortie constituant les données utilisées pour le document.
Liste d’extraction : nouvelle entité DIAPASON permettant de décrire une structure de données manipulable par la suite dans DIALOG par le biais des nouvelles instructions « CREATION LISTE EXTRACTION » et « PRENDRE LIS-EXT ».

Une source de données définie dans DIAPASON permet d’indiquer les listes utilisées en sortie.

Type ‘DIC’ : sélection des listes d’extraction (ou dites aussi listes du dictionnaire)
Type ‘REN’ : sélection des requêtes de type REN. Par défaut les noms des listes sur la source de données correspondent aux références des requêtes sélectionnées.
Type ‘REB’ : indiquer la requête REB utilisée puis renseigner la ou les n listes utilisées par cette requête.

Remarque : dans les cas REN ou REB, il est possible d’indiquer un nom de balise propre à chaque liste utilisée. Dans le cas des listes d’extraction, cette information est donnée sur la définition de la liste elle-même.

Et une liste des variables transmissibles : sélection parmi les SCR, VCR, XML et VBP utilisées par les requêtes sélectionnées. Il est possible de donner un nom de balise à chaque variable sélectionnée sous forme de liste chaînée.

Un rapport défini dans DIAPASON permet de faire le lien entre le rapport CR utilisé (zone « Fichier ») et la source de données (et donc, les listes) utilisée.

Un document : permet de générer les fichiers XML résultats qui seront fusionnés avec le rapport pour l’état final. Comme pour WORD, ce document EXCEL est de type 1 (Edition par requête Diapason) ou 6 (REB/MFD).

Génération source de données

La génération des sources de données, lancée depuis DIAPASON, a pour but de générer les fichiers XML et le fichier XSD qui seront utilisés dans le rapport sur CR. Suite à cette opération il est possible de concevoir le rapport dans CR (portant le nom contenu dans « Fichier »).

Le fichier XSD est unique par rapport et décrit la structure de la ou des listes déduites de la source de données utilisée.

Les fichiers XML générés sont :

SDO.racine_CTX_DIAPASON.xml : ce fichier est toujours généré, il contient les variables contextuelles du rapport (variables figées par DIAPASON et éventuellement les variables transmissibles indiquées sur la source de données courante).
SDO.racine_Liste1.xml : fichier décrivant les données de la liste liste1
SDO.racine_ListeN.xml : fichier décrivant les données de la liste N.

NB : chaque liste utilisée à son propre fichier de données XML correspondant.

Les fichiers « xml » générés sont dits ‘fichiers défauts’, leur contenu est générique en fonction du type et du format des champs des listes concernées.

SDO.racine_CTX_DIAPASON.xml

<?xml version="1.0" encoding="ISO-8859-1" ?>

- <DATA_DIAPASON>

- <CTX_DIAPASON>

<DOCUMENT>XXXXXXXXXX</DOCUMENT>

<DESIGNATION>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</DESIGNATION>

<FICHIER>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</FICHIER>

<IMPRIMANTE>XXXXXXXXXX</IMPRIMANTE>

<NB_EXEMPLAIRE />

<TYPE_PJOINTE>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</TYPE_PJOINTE>

<DESI_PJOINTE>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</DESI_PJOINTE>

<FIC_PJOINTE>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</FIC_PJOINTE>

<INVENTAIRE>XXXXXXXXXXXXXXXXXXXX</INVENTAIRE>

</CTX_DIAPASON>

</DATA_DIAPASON>

NB : Les balises présentées dans cet exemple sont toujours présentes. Suite à la balise « UTILISATEUR », se trouveront les éventuelles variables transmissibles paramétrées sur la source de données utilisée.

SDO.racine_Corres.xml

<?xml version="1.0" encoding="ISO-8859-1" ?>

- <DATA_DIAPASON>

- <CORRES>

<InvRef>XXXXXXXXXXXXXXX</InvRef>

<ResGenRef>XXXXXXXXXXXXXXX</ResGenRef>

<InvCTRef>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</InvCTRef>

<InvCTDes>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</InvCTDes>

<RefArt>XXXXXXXXXXXXXXXXXXXXXXXXX</RefArt>

</CORRES>

</DATA_DIAPASON>

NB : dans les fichiers exemples, les champs sont formatés tels que récupérés dans CR au niveau de la structure de données.

En mode XML avec Formatage Alphanumérique respecté, un champ caractère défini avec un format C/3 sera décrit dans CR avec ce format là, ce qui veut dire que CR ne verra toujours que 3 caractères même si la valeur en contient 30.

En mode Dataset ou XML sans respect du formatage Alphanumérique, CR verra la totalité de la valeur.

Ces fichiers sont générés dans le dossier des rapports paramétré depuis l’application de définition des serveurs d’édition. Bien entendu, les rapports, eux même, devront se trouver dans ce même dossier. Lors d’une édition, ces fichiers de données, contenant les informations voulues, seront générés dans le dossier de travail paramétré dans cette application.

A compter de cette phase, tous les éléments nécessaires à la conception du rapport dans CR sont utilisables.

Définition du rapport dans CR

Principe de constitution d’un rapport sous CR

A l’entrée de CR faire « nouveau rapport », la fenêtre de connexion de source de données s’ouvre, sélectionner le type XML :

Dans la zone « Fichier XML local », indiquer le fichier XML généré par DIAPASON. Cette opération est à répéter autant de fois que de fichiers XML générés par DIAPASON (ou du moins pour chacune des listes devant être utilisées).

Les fichiers XML générés par DIAPASON se trouvent sur le serveur d’édition de type Crystal paramétré, toutefois il est conseillé de les récupérer en local de façon à modéliser son rapport (il faut éviter de concevoir les rapports directement sur le serveur).

A la suite de la modélisation en local, il faudra copier le fichier rapport CR (.rpt) sur le serveur à l’emplacement prévu ET lancer obligatoirement l’action « Synchronisation » accessible depuis la gestion des rapports DIAPASON.

En effet, CR mémorise l’emplacement des sources de données connectées sur le fichier rapport (.rpt). Ensuite, les chemins font toujours référence à l’emplacement du PC local. La fonction a pour effet de remplacer les chemins par ceux définis sur le serveur CR.

Une connexion se fait toujours par :

le fichier XML de la liste (données) devant être utilisée
le fichier XSD relatif à la source de données (descriptif structure).

Le fait de cliquer sur le bouton « Terminer » connecte la source à CR. :

Double cliquer sur la branche « Etablir une nouvelle connexion » pour connecter la ou les autres listes utilisées par le rapport.

Exemple sur listes Entête et Ligne :

Chacune des connexions présente la totalité des tables, mais pour chacune d’entre elles une seule est à connecter. Cette liste est issue du schéma qui décrit systématiquement toutes les tables de la source de données.

Voici les connexions qui ont été faites dans cet exemple :

DATA_DIAPASON/CTX_DIAPASON depuis paniercd3b_CTX_DIAPASON.xml
DATA_DIAPASON/Entete depuis paniercd3b_Entete.xml
DATA_DIAPASON/Ligne depuis paniercd3b_Ligne.xml

Le bouton « Suivant », nous montre la structure de données récupérée telle que :

Les 3 listes sont récupérées, des liens défauts son générés sur un identifiant interne à CR.

Il faut impérativement supprimer ces liens afin de pouvoir définir les liens désirés.

Ici, il est possible de définir un lien entre Entête et Ligne par le biais du champ « cde ». Pour cela il suffit de cliquer sur le cde de la table Entête et de le faire glisser sur celui de la table Ligne.

Il est possible à ce stade de cliquer sur le bouton « Terminer » et accéder à la conception du rapport :

Principes de Génération

L’action de génération de source de données va remplacer le fichier XSD de description de la source de données ainsi que les fichiers XML d’exemple sur les Serveurs Crystal sélectionnés.

Comportement particulier

Code barre 128

Ce problème est lié à l’utilisation d’un serveur de service JAVA.

Au passage à P17 ce paramétrage est à supprimer.

Nous avons pu constater que le serveur Java ne se comportait pas de la même manière face à la police de code barre 128 lors d’une édition Crystal Report. En effet, celle-ci ne s’affiche pas correctement lorsque l’on passe par le serveur d’édition Java, le code barre est décaler vers le haut.

Voici l’effet constaté :


Edition via le serveur Progress	Edition via le serveur Java

Pour palier à ce phénomène dans Crystal Report, il faut modifier le rapport.

Voici la procédure :

Entrer en modification dans le rapport
Sélectionner le champ contenant le code barre
Clic droit : « Mise en forme le champ … »
Cliquer sur l’onglet « Paragraphe »
Modifier l’Interlignage de l’Espacement à Exactement 20 points.
Enregistrer le rapport.

Passage au mode « Optimisé »

Passage du mode « XML » au mode « DATASET »

Une nouvelle information a été ajoutée sur la définition des sources de données Diapason pour utiliser le mode Dataset.

Onglet Caractéristiques
- Données XML ? : Fonctionnement par Fichier XML ?

Zone Logique indiquant si la communication avec Crystal Reports® se fait par fichier XML ou par Dataset (Données en Mémoire).

Le mode « XML » est le mode de communication historique mais est moins performant que le mode « Dataset ».

En création sa valeur est par défaut à Non.

Les principales différences entre le mode « XML » et le mode « Dataset » pour le paramétrage des rapports Crystal Reports® se situent sur la gestion des formats dans Crystal Reports® :

Format Date : En mode Dataset le format est transformé en « Datetime » dans la source de données Crystal Reports®, il est nécessaire de formater les champs en fonction de ce format particulier dans Crystal Reports® sinon l’affichage défaut de Crystal Reports® est « JJ/MM/AAAA hh:mm:ss » au lieu de « JJ/MM/AAAA » pour l’ancien Format « Date »
Format Alpha : Les formats définis dans Diapason (par exemple « C/10 ») ne sont plus interprétés par Crystal Reports® c’est-à-dire que Crystal Reports® ne tronquera plus au format défini sur le champ dans Diapason.

Remarques:

Par défaut lors du changement de version sa valeur est à Oui sur l’ensemble des sources de données existantes.
Après avoir migrer une édition Crystal Reports® du mode « XML » vers le mode « Dataset », il est nécessaire de lancer l’action « Génération Source de données » depuis les rapports utilisant la source de données courante.
Lors de mise à jour de ce champ, si la source de données contient un Champ « Date », une alerte prévient qu’une modification du rapport Crystal Reports® peut être nécessaire pour mettre à jour le format d’affichage des champs de type « Date ».

Procédure de migration d’une source de données en mode XML vers un mode Dataset

Les principales différences entre le mode « XML » et le mode « Dataset » sont :

Format des champs « Date » Diapason sont au format « Datetime » dans Crystal Reports® : nécessite un formatage différent du format « Date » en mode « XML ».
Les liens avec les fichiers XML et XSD pour la conception et le débogage sont gérés en chemins relatifs : ceci permet une portabilité plus simple pour la conception et le déploiement d’un rapport Crystal Reports®

Exemple avec un document de test :

-Document Avant Migration :

-Document après migration sans interventions :

Il est donc nécessaire dans ce cas de suivre la procédure ci-dessous :

Etape 1 : Désactivation du mode XML dans Diapason

Aller sur la définition de la sources de données que vous souhaitez basculer et décocher « Données XML ».

A la validation de la fiche, une alerte s’affichera si votre source de données contient au moins un champ au format Date :

Etape 2 : Synchronisation du rapport Depuis Diapason

Pour chaque rapport utilisant votre source de données, lancer l’action « Synchronisation source de données » :

Sélectionner votre serveur de service P17 et valider :

Refaire la synchronisation pour chaque Rapport Diapason utilisant votre source de données.

Etape 3 (si Utilisation de champ de type Date dans les sources de données) : Mise à jour de la mise en forme des dates dans le rapport et dans les formules du fichier

Aller dans le répertoire des rapports sur votre serveur de service et ouvrir le rapport Crystal Reports® lié.

Identifier les champs aux format Date qui sont utilisés dans votre rapport à partir de l’explorateur de champ (coche verte sur les champs) :

Plusieurs cas sont à gérer :

➡️ Cas 1 : le champ est utilisé directement dans le document

Sélectionner le champ dans le rapport, Action « Mettre en Forme le champ … »

Sur l’onglet « Date et Heure » sélectionner le format que vous souhaitez

➡️ Cas 2 : le champ est concaténé dans une zone caractère

Dans ce cas il faut d’abord convertir le champ au format caractère en utilisant un champ de formule, puis il faut remplacer l’utilisation du champ date par ce nouveau champ :

Exemple de formule pour convertir le champ au format Datetime en chaine de caractère :

IF ISNULL({DATA_DIAPASON/ENTETE.jour}) THEN "" ELSE Cstr(CDate ({DATA_DIAPASON/ENTETE.jour}))

Ensuite remplacer l’utilisation du champ Date par le nouveau champ de formule.

➡️ Cas 3 :le champ est utilisé dans une formule

Depuis l’explorateur de champ, Lancer l’action « Rechercher dans les formules … »

et convertir le format Datetime au format Date comme au point 2 :

Etape 4 : test du résultat

Sur un document utilisant votre rapport, lancer l’action « Test Edition (F11) »

Cas de la création d’un nouveau rapport

Bonnes Pratiques lors de la conception de rapport Crystal Reports® et de l’édition

SAP recommande de mettre à jour les pilotes de vos imprimantes régulièrement pour éditer des documents Crystal Reports®
SAP recommande de cocher « Dissocier la taille de la page mise en forme et la taille de papier de l’imprimante » dans les options de mise en forme de vos rapports pour diminuer les écarts lors de l’impression d’un même document sur plusieurs imprimantes différentes.

Nous recommandons d’utiliser lors de la conceptions des tailles prédéfinies sur les imprimantes notamment sur des documents avec des dimensions particulières comme les étiquettes :

Exemple de définition d’un Format sur une imprimante ZEBRA :

➡️ Sur la gestion de l’imprimante :

➡️ Ensuite dans Crystal Reports® :