Blog Homsys

Retour d’expérience sur le projet GASPAR pour le groupe PVCP (Pierre & Vacances – Center Parcs).

Dans ce projet le challenge était d’utiliser BODS comme middleware pour envoyer à SAP des écritures (pièces) comptables via la technologie IDOC.

Le contexte :

• Un système Tiers dépose un fichier plat contenant la facturation client et les comptes d’imputations correspondants,
• BODS charge ce fichier,
• BODS traduit les imputations comptables du système tiers en code d’imputation comptable SAP,
• BODS poste la pièce comptable dans SAP au format IDOC en mode message.

Les solutions :

• Les utilisateurs métier maintiennent dans SAP des tables de correspondance entre compta système tiers et compta de SAP (hors périmètre de ce post),
• BODS traduit via des lookup_ext les données d’imputation comptables (hors périmètre de ce post),
• BODS envoi un IDOC par pièce comptable à SAP en utilisant l’IDOC ACC_DOCUMENT003.

La difficulté majeure résidait dans la génération des IDOC. Un fichier plat pouvant contenir jusqu’à 34000 documents comptables générant autant d’IDOC.

Un IDOC SAP ce présente sous un format de type xml. L’ACC_DOCUMENT003 simule la saisie d’une pièce comptable, il y a de nombreux champs à remplir pour satisfaire SAP, et de nombreux contrôles sont réalisés pour que la pièce comptable soit considérée comme juste.

Ce qui nous intéresse ici est la partie génération de l’IDOC.

Génération massive d’IDOC :

1. Structurer les données pour ce rapprocher du schéma cible :

Deux méthodes ont été utilisées sur le projet, création d’une table par segments d’IDOC, ou division de la table source en autant de query que de segments d’IDOC

Chaque IDOC est référencé par un Identifiant unique, un IDOC peut contenir plusieurs lignes, qui doivent être référencées de manière unique par IDOC.

La table/query d’en-tête ne doit comporter qu’une seule ligne par identifiant d’IDOC, les autres tables/query peuvent contenir plusieurs lignes.

A l’image d’un modèle en étoile les données sont réparties entre : la table d’en-tête (Fait) et les tables de lignes (Dimension).

ci-dessous des données en exemple :

2. Lier les Tables/Query à une en-tête pour générer tous les IDOC en une passe. 

(Dans l’exemple précédent : la query « QRY_MATCH_IDOC »)

La query en amont de l’IDOC (query_2) place les segments dans l’IDOC.

Chaque Tables sources doivent être insérées dans la cible comme schéma.

2.1 L’en-tête :

La clause FROM est déterminante pour structurer l’IDOC. La clause FROM de query_2 aura pour valeur la table d’en-tête.

Puis tous les segments d’en-tête auront comme valeur dans la clause FROM le « Row_Generation ». Cela permet de ne remplir l’en-tête qu’une seule fois. Dans l’exemple ci-dessus les segments EDI_DC40, E1BPACHE09 et E1BPACEXTC

(détail d’un segment)

2.2 Les lignes :

Les autres segments sont rempli par les tables correspondantes, avec en clause FROM la table, et en clause WHERE le lien vers l’identifiant de l’en-tête

En exemple le segment E1BPACGL09 :

2.3 Cas particulier d’une duplication de segment :

Dans certains cas un segment doit être répété. Lors de la première itération le segment est paramétré à l’identique des autres, et la deuxième itération la clause FROM prendra pour valeur un « ROW_GENERATION ».

 

3. Paramétrage de l’envoi d’IDOC

Afin d’optimiser l’envoi des IDOC en mode message la fenêtre suivant permet de modifier le nombre d’envoi simultané d’IDOC. Deux solutions, par paquet ou par division chronologique.

La solution d’envoyé les IDOC par paquet de 100 a été choisi compte tenu du paramétrage de SAP chez le client.

Conclusion

Cette méthode permet d’envoyer en masse en quelques minutes des milliers d’IDOC.

Certes BODS est détourné de son utilisation première (ETL) pour devenir un modeste intégrateur, néanmoins les performances sont très bonne.

Aujourd’hui la moyenne est : 1 min / 1000 IDOC de type ACC_DOCUMENT003.