Introduction

L’impression des étiquettes via Crystal Reports n’est pas optimale et pose des problèmes régulièrement. La raison est simplement que l’outil n’est pas adapté à ce genre de mises en page ( marges, orientation, format, etc. ) 

Des logiciels du marché, comme BarTender, permettent de gérer les imprimantes à étiquettes ou de cartes de façon optimale. Il suffit de fournir à ceux-ci les données nécessaires et le logiciel se charge de l'impression. La configuration de la mise en page s'effectue dans ces logiciels également.

Limitations

• Pas d’aperçu avant impression disponible 
• Les options d’impression disponibles dans les modales pour définir l’imprimante ainsi que la définition de la mise en page ne sont pas prises en considération. 
• Les appels de webservices sont à définir en PL/SQL, dans une fonction appelée par la commande SQL de configuration. Ceci est une individualisation. 

• Le contenu du fichier est défini dans une fonction appelée par la commande SQL de configuration. Ceci est une individualisation. 
• La configuration de la mise en page des étiquettes se fait dans le logiciel tiers.

Principes de base

L'utilisateur choisit un rapport et l'imprime. Ce rapport est traditionnellement Crystal, mais cela peut également créer automatiquement un fichier contenant les données nécessaires à un logiciel tiers.

La configuration s'effectue dans le logiciel tiers. ProConcept se borne à fournir à ces logiciels les données nécessaires et celles-ci sont définies au travers d'une commande SQL qui indique à la fois le nom et l'emplacement du fichier, mais également son contenu et le lie à un nouveau rapport.

Pour le cas habituel, le répertoire correspond à une imprimante à étiquette précise. Le logiciel tiers scanne le répertoire en question et se charge de lancer l'impression.

Disponibilité de cette fonctionnalité ( objets, applications )

Partout où l'impression de rapports Crystal y compris via macros CALL_REPORT et printserver est possible.

Configuration des types de rapports

Les types de rapports permettent de définir certains attributs qui facilitent ensuite la maintenance des fonctions qui ramènent les informations souhaitées par les interfaces.

Dans la gestion des rapports, un type peut être associé. Par défaut, sa valeur est nulle et correspond donc à Crystal Reports.

Le type permet de définir les attributs utiles aujourd’hui et pour le futur : 

• Nom 
• Encoding ( UTF8, MS1252 ) 
• Système d’échange de données ( facultatif ). De cette manière, la fonction PL/SQL pourrait également permettre un fonctionnement via un système DESY, asynchrone ( mais peut-être plus flexible ).  Dans ce cas, une transaction autonome devra être appelée pour effectuer l'insertion ( voir remarque au bas de ce document )
  

• Commentaire ( facultatif )

• Les paramètres suivants ne sont pas utilisés de manière standard, mais pourrait faciliter le travail en cas d’interfaçage avec des solutions de reporting plus élaborées. Dans ce cas, les appels aux webservices doivent être définis et configurés sous forme d'individualisations dans la base de données.
  

• • URL 
  • Username 
  • Password 

• • Callback pour l’aperçu avant impression ( non-géré pour l'heure )
    

Configuration des rapports pour interfaces (étiquettes)

Pour les types autres que Crystal, la commande de recherche associée au rapport doit être visible à interface et facilement modifiable ( lookup et tunnel ). 

La commande SQL contient les colonnes suivantes qui doivent avoir des noms fixes : 

• Nom du fichier ( RTP_FILENAME ) 

• Répertoire de destination ( RTP_DIRECTORY )  
• Contenu ( RTP_FILE_CONTENT )  
• Statut ( C_RTP_STATUS à traiter, traité, erreur )  
• Message d'erreur ( RTP_ERROR_MESSAGE ) 

La commande de recherche doit être configurée pour gérer les paramètres comme d'habitude. Le paramètre facultatif PC_REPORT_ID est passé automatiquement le cas échéant et il ne faut donc pas le rendre visible.

A l'exécution, il y aura autant de fichiers créés que de records ramenés par la commande SQL appelée en tenant compte de l’encoding indiqué au niveau du type. Les fichiers ne sont créés que lorsque le champ Contenu n’est pas vide et que le statut n’est ni en erreur ni traité 

Notons que lorsque le répertoire n'est pas défini, le fichier sera téléchargé sur le poste client.

La commande de recherche peut être donc quelque chose comme :

select * from table(PCS.pc_lib_report_label_export.sample_export_for_good(:GCO_GOOD_ID,:NB_COPIES, :PC_REPORT_ID))

La fonction pipelined appelée dans cet exemple est celle-ci :

create or replace package pcs.pc_lib_report_label_export
is
    type rt_label is record(rtp_filename varchar2(255), rtp_directory varchar2(255), rtp_file_content clob, c_rtp_status varchar2(10), rtp_error_message clob);
    type tt_labels is table of rt_label;
    
    /* fonction à appeler dans le cadre d'un rapport étiquettes - exemple */
    function sample_export_for_good(in_id in number, in_copy in integer, in_report in pcs.pc_report.pc_report_id%type) return tt_labels pipelined;
    
    -- Commande appelée select * from table(PCS.pc_lib_report_label_export.sample_export_for_good(:GCO_GOOD_ID,:NB_COPIES, :PC_REPORT_ID))
end;

create or replace package body pcs.pc_lib_report_label_export
is
    /* fonction à appeler dans le cadre d'un rapport étiquettes - exemple */
    function sample_export_for_good(in_id in number, in_copy in integer, in_report in pcs.pc_report.pc_report_id%type) return tt_labels pipelined
    is
    lt_label rt_label;
    lt_report pc_report%rowtype;
    lt_report_type pc_report_type%rowtype;
    begin
        -- Les documents sont à traiter
        lt_label.c_rtp_status := '01';
        lt_label.rtp_error_message := null;
        
        BEGIN
            select * into lt_report from pc_report where pc_report_id = in_report;
            
            select * into lt_report_type from pc_report_type where pc_report_type_id = lt_report.pc_report_type_id;
            EXCEPTION WHEN NO_DATA_FOUND THEN NULL;
        END;
        /* Définition de l'imprimante à étiquettes en fonction du rapport, du type de rapport, de l'utilisateur ( ex.champs virtuels ), de l'atelier, du contexte, etc. */
        lt_label.rtp_filename := 'sample'||to_char(sysdate,'YYYYMMDD_HH24MISS')||'.txt';
        /* par exemple, imprimante définie via le chemin du rapport 
           ( mais ce pourrait également être le cas d'une fonction dépendante de l'utilisateur indiquée au niveau du type de rapport ou tout autre stratagème ) */      
        lt_label.rtp_directory := lt_report.rep_reppath;  -- lt_report_type.RTP_FREE_TEXT_01;
        
        -- Définition de l'en-tête / exemple
        lt_label.rtp_file_content := 'GOO_MAJOR_REFERENCE;PDE_BASIS_QUANTITY;MEA_NET_WEIGHT;MEA_NET_VOLUME;DMT_NUMBER;LOC_DESCRIPTION;DATE;FOURNISSEUR';

        -- Ajout des lignes
        FOR tpl IN (select goo_major_reference
                      || ';Quantité:  ' || PDE_BASIS_QUANTITY
                      || ';Poids de la tare: ' || MEA_NET_WEIGHT
                      || ';Quantité référence: ' || MEA_NET_VOLUME
                      || ';Caract.: ' || dmt_number
                      || ';Emplacement: ' || loc_description
                      || ';' || to_char(sysdate, 'dd.mm.yyyy')
                     || ';' || dmt_name1
                     vData
                FROM (select '3000.01' goo_major_reference, 1 pde_basis_quantity, 3 mea_net_weight, 1 mea_net_volume, '1234' dmt_number, 'Stock' loc_description,'XY' dmt_name1 from dual )) loop
            for cp in 1..in_copy loop
                lt_label.rtp_file_content  := lt_label.rtp_file_content ||chr(10)||tpl.vData;
            end loop;
        end loop;
        
        pipe row (lt_label);
        return;
        
    end;
end;

CALL_REPORT

Dans la configuration de la macro CALL_REPORT, il faut prêter attention au fait que les paramètres sont passés de manière indicée ( PAR00, PAR01, PAR02, etc. )

Dans l'exemple ci-dessus :

[CALL_REPORT] RPT=DOC_LABEL_PRINT_RHE;PAR00=[GCO_GOOD_ID];PAR01=:NB_COPIES

Considérations particulières

Utilisation de queues

En cas d'appel à la fonction pour insérer des enregistrements dans une table, une queue par exemple ou un système d'échange de données, il sera nécessaire d'exécuter ceci au travers d'une transaction autonome.

La procédure appelée aura donc le pragma autonomous transaction.