L’intégrateur de données (INTEG)

Cette fonction permet d’intégrer dans les bases ACE des données provenant d’applications externes : événements commerciaux, stocks, produits ou tiers.

Chaque domaine est décrit sous la forme d’un fichier dont il faut respecter un format de description des données (voir Données intégrées).

Couplé à la gestion des rejets, l’intégrateur simplifie les tâches d’administration.

Généralités

Principes

L’intégrateur s’articule autour des fonctionnalités suivantes :

Deux bases permettent de mémoriser les données propres à l’intégrateur : table des Intégrations (ITG) et table des Rejets (IRJ).

Pour la partie Finances, une fonctionnalité identique, l’Intégrateur Finances, permet d’intégrer des données externes à ACE (plans, comptes, écritures comptables, etc.).

L'intégrateur permet également d'afficher dans le fichier journal du traitement d'édition une série de messages informatifs afin de mieux comprendre le déroulement du traitement d'intégration.

Ces messages ne sont pas des messages d'erreur, ils justifient le traitement normal de l'intégrateur et ne sont pas édités en standard car ils peuvent occasionner un fichier journal trop volumineux. Ils sont donc conditionnés par le positionnement dans la maquette du mot clé :

P TRT="mess_normaux_log".

Format fixe et format variable

Format fixe

Les valeurs des champs à intégrer doivent être positionnées à l’emplacement prévu (en position, taille) par l’enregistrement à intégrer (voir la documentation des enregistrements d’intégration). Dans ce format, le fichier doit être dans une police de caractère mono-octet (il ne peut dont pas être en UTF8).

Par ailleurs, les champs marqués ‘UTF8’ dans la colonne type sont ceux acceptant de l’UTF8 avec le format variable. Pour ces champs, en format fixe, ne pas dépasser le nombre de caractères (précisé dans la colonne ‘Désignation’ de la description du format d’intégration, sinon = taille/4).

nompro Nom du produit ACE 1.60 630 120 UTF8

Renseigner au maximum 30 caractères.

Champ OBLIGATOIRE sauf si le champ nompro_30 est alimenté…

Format variable

Depuis la version ACE 1.6.0, pour les nouveaux fichiers d’intégration, il est préconisé d’utiliser le format variable (FVxx) (voir documentation INTEG_FV). Le format variable FV01 permet de s’adapter à l’internationalisation selon la façon dont sont générés les fichiers à intégrer.

Si le serveur de traitement est paramétré en UNICODE (ou UTF8), il faut utiliser le format FVxx et un fichier à intégrer au format UTF8.

Attention : disponible uniquement sur INTEGR (pas disponible sur l’intégrateur finance).

Attention

Le format variable est disponible pour les formats de type ‘INTEG_xxx’. Il n’est pas possible de l’utiliser dans l’intégrateur Finance (P_2ITF).

Fichier à intégrer

ACE ECHANGE fonctionne avec un nom de fichier par traitement.

Le fichier à intégrer subit un contrôle préliminaire pour répondre à certains contextes d'utilisation.

Depuis la version ACE 1.6.0, les fichiers des formats d’intégration peuvent contenir un ‘\r’ (fichier DOS déposé sous UNIX sans transformation), ce caractère étant simplement ignoré.

Attention
  • A la fin du fichier à intégrer, il faut toujours ajouter un saut de paragraphe (retour chariot), sinon le dernier enregistrement du fichier n'est pas intégré.
  • Toutes les dates doivent être formatées de la manière suivante : AAAAMMJJ (année, mois, jour).

Le mode standard de fonctionnement d’ACEest le suivant : le fichier à intégrer possède un nom fixe et doit être « disponible » dans le répertoire des fichiers prêts à être intégrés. Rappelons qu'il est toutefois possible d'utiliser des noms avec un caractère joker (voir ci-après).

Comme le fichier peut être verrouillé par d’autres traitements non ACE, ce qui n'est pas le mode de fonctionnement normal d’ACE, le contrôle d'existence du fichier est renforcé par un contrôle de « disponibilité » du fichier (non verrouillé par un autre process).

Si le fichier n’est pas disponible, une erreur est enregistré dans le fichier .log (message ‘Pb fichier !’) et l’intégration des données cesse. Ce fichier ‘Trace’ peut être consulté par la fonction UEDI.

Le statut du traitement est toutefois positionné à la valeur ‘5 : traitement incorrect’.

Une tâche automatique (UPRC) peut ou non (choix de paramétrage de la tâche) entraîner une autre tâche. Cette fonctionnalité permet notamment de traiter le cas de figure suivant : est-il cohérent, pour le fonctionnement de l'application, d'effectuer le traitement à la date D2 alors que celui de la date D1 a rencontré une difficulté ?

Ce contrôle permet d'éviter l'arrêt complet du processus d'intégration avec nécessité d'une relance manuelle. Mais il ne règle pas la fluidité des intégrations.

Attention

Il est donc indispensable pour le bon fonctionnement de déposer dans le répertoire adéquat un fichier qui restera toujours disponible.

Intégration de fichiers comportant des caractères « joker »

Au niveau du lancement de l’intégrateur, le nom de ficher avec joker peut être saisi comme un fichier à intégrer. Ce code peut être programmé et utilisé de manière récurrente.

Le caractère joker prévu est l’astérisque ‘*’.

Pour permettre le suivi des fichiers sur les différents serveurs et les reprises sur incidents de transmission, il faut avoir unicité sur les noms de fichiers. Le type d’interface est défini dans le nom du fichier.

Le nom du fichier, sur 25 caractères, est codifié de la façon suivante : EDI_aaaaaaaaaa_bbbbbbbbbb.

EDI

Constante

aaaaaaaaaa

Nom du destinataire : à définir pour HP 9000 ADV.

bbbbbbbbbb

Nom du fichier avec formatage wxxxyyyzzz avec :

  • w = G comme fichier envoyé par Danzas (exemple),
  • xxx = constante 200 pour envoi à ADV,
  • yyy = chrono toutes interfaces confondues,
  • zzz = code de l’interface (SE2 pour les commandes et mouvements ; SE3 pour les niveaux de stocks).

Les fichiers sont localisés sur le serveur où est installé ACE (répertoire logique de 5 caractères défini dans le Generix.ini).

La chaîne de caractères acceptée par l’intégrateur comprend donc 30 positions (longueur du nom du répertoire logique : 5 caractères + longueur du nom du fichier : 25 caractères).

Règles de gestion

Au début de traitement, le nom du fichier à intégrer est automatiquement analysé.

S’il ne possède pas de caractères joker, le traitement continue.

S’il contient au moins 1 caractère joker, une recherche sur le répertoire est lancée, correspondant avec le nom du fichier donné. Le fichier à intégrer est le premier trouvé.

Paramétrage

Dans la fonction INTEG, si l’on spécifie en position 3 du fichier d’intégration une fonction en particulier et que l'on veut positionner un paramètre de contrôle (sur la quantité ou le prix par exemple), il faut le positionner à la fois sur la fonction différée INTEGR et la fonction spécifiée dans le fichier.

Par exemple: le paramètre CTRQTE pour la gestion des commandes (GCOV).

Principes

Les quatre types de gestion du comportement transactionnel de l’Intégrateur répondent à la majorité des besoins.

Transaction sur poste

Les opérations sur la base de données sont validées ou non à chaque rupture sur poste. Par poste, on entend la plus petite structure indépendante intégrable.

Ainsi, une création de produit (type d’enregistrement 05), suivi de la modification d’un commentaire (type 03) correspond à l’intégration de deux postes, de même que l’intégration d’un entête d’événement (type 01), suivi de son poste d’événement (type 02).

En revanche, une création d’un poste d’événement (type 02), suivi immédiatement par la modification de ce même poste (type 02) correspond à une seule transaction de poste. L’utilisation des cadences illustre encore mieux cet état : l’intégration d’un poste cadencé (type 21) et des différentes lignes le composant (type 22) correspond alors à une seule transaction.

Transaction sur fichier

Les opérations sur la base de données sont validées ou non pour le fichier à intégrer en entier. Ainsi, une seule erreur commise sur l’intégration d’une ligne du fichier suffit à provoquer une annulation de toutes les créations, modifications ou suppressions codées dans le fichier.

Transaction sur événement

La rupture de transaction est pratiquée au niveau de l’événement, c’est à dire tout type d’enregistrement de nature événementielle et correspondant bien évidemment aumême événement (même clef : nature (Achat/Vente), Type d’événement et Numéro d’événement).

Les types d’enregistrement retenus sont les suivants :

  Table
Entête d’événement EVE
Poste d’événement EVP
Ligne d'événement (cadence) EVL
Numéros de série EVN
Nomenclature EVS
Frais divers EVF
Commentaire événement EVT
Tiers associé événement EVTA

Trucs et astuces (optimisation des temps de traitement)

Pour conserver une performance suffisante lors de l'intégration, il est impératif de faire suivre les types d'événements de même nature événementielle et de ne pas intercaler d'autres types d'enregistrements.

Par exemple : le type d’enregistrement 42 à l'intérieur d'une intégration d'événements génère une rupture avec des valorisations intermédiaires et augmente considérablement le temps de traitement de l'intégration.

Voir nos exemples ci-après.

Exemples :

Ne pas suivre la séquence suivante :

Mais préférer plutôt le regroupement des enregistrements 42 :

Transaction sur enregistrement 99

Il s’agit ici d’une rupture sur un ensemble cohérent d’enregistrements. Ce type d’enregistrement 99 permet de placer aux « endroits stratégiques » des balises servant de rupture de transaction. Cette structure permet de déclencher un « commit » validant les données depuis la transaction précédente et ainsi d’intégrer des structures cohérentes de données.

Cet enregistrement qui se limite en fait aux deux caractères ‘99’, placés dans le fichier à intégrer en début de ligne, délimite les ouvertures et fermetures de transaction.

Ainsi, la première transaction correspond aux enregistrements du début du fichier au 1er enregistrement « 99 », la seconde transaction du 1er enregistrement « 99 » au 2eenregistrement « 99 », etc. et la dernière transaction du dernier enregistrement « 99 »à la fin du fichier.

Depuis la V4.4-00, il est possible d’ajouter ‘1’ à la suite de ‘99’. En plus de fermer la transaction, l'événement est changé ; c'est-à-dire que le compteur de poste et d'événement est remis à 0.

On peut ainsi encadrer un évènement de la manière suivante :

991

Enr.21 : modification du poste,

Enr.22 : modification de la ligne 1,

Enr.22 : création de la ligne 2,

Enr.22 : création de la ligne 3,

99

Nom Désignation Position Taille Type Valeur AGILIX Règles de gestion et contrôles en intégration
typenr Type d’enregistrement 1 2 num 99 Transaction

Données intégrées

Simulation des autres enregistrements

Type Domaine Format description
FV Format variable d'intégrateur (internationalisation) INTEG_FV

Les événements

Type Domaine Format description
01 Entête d’événement INTEG_EVE
02 Poste d’événement INTEG_EVP
03 Commentaire événement INTEG_EVT
04 Adresse éphémère (remplacé depuis la version ACE 1.1 (ACE 5.2-00) par INTEG_TIE_ADR) INTEG_ADR
05 Données complémentaires événement INTEG_EVT
06 Acomptes / échéances INTEG_EVM
07 Frais divers INTEG_EVF
08 Nomenclature INTEG_EVS
09 Tiers associé événement INTEG_EVTA
10 Intégration d’événements dans les dossiers de frais d’approche INTEG_FAP
11 Validation événement INTEG_EVE
12 Liens achat/vente INTEG_EVAV
21 Poste d'événement (cadence) INTEG_EVP
22 Ligne d'événement (cadence) INTEG_EVL
30 Commentaire limité à une ligne par enregistrement INTEG_EVT_
37 Détail TVA INTEG_EVTVA
87 Numéros de série INTEG_EVN

A8

C4

C5

Répartition postes/lignes par magasin

Ligne prévisionnelle d’une commande Extranet Fournisseur

Validation d’une commande Extranet Fournisseur

INTEG_EVRP

INTEG_EVL_PRV

INTEG_EVE

Les produits

Type Domaine Format description
46 Familles produit (et tiers) INTEG_FAM
49 Déclinaisons de produits en multi-variantes (table PRD) INTEG_PRD
50 Fiche produit et contrôles du produit INTEG_PRO
51 Traduction du nom et des 12 désignations du produit (ancien format, désignation traduite sur 39 caractères) INTEG_PRM
52 Catalogue fournisseur ou client INTEG_PRC
53 Fiche stock (tables DSK ou LSK) INTEG_STK
55 Nomenclature de produit (table PRN) INTEG_PRN
56 Produits de remplacement INTEG_PRR
57 Unité de conversion des produits INTEG_PRU
58 Variantes d’un produit INTEG_PVA
59 Variantes logistiques INTEG_PRL
68 Associations rubriques / produit INTEG_PRB
84 Suremballage INTEG_COL_SE
85 Colis INTEG_COL
A5 Traduction du nom et des 12 désignations du produit INTEG_PRM
P0 Produits dangereux et matières dangereuses INTEG_PRO_DANGER

La tarification

43 Tarifs sur plusieurs périodes INTEG_TSC_TCO
44 Elaborations tarifaires (prévisions de tarifs) INTEG_TAL
45 Données complémentaires des élaborations tarifaires INTEG_TAL
54 Tarifs (tables TAS,TAB,TAC,TAV) INTEG_TAR
73 Conditions tarifaires INTEG_CTS

Les services

Type Domaine Format description
13 Prestation d’un contrat de service INTEG_ICP
14 Intervention INTEG_IEV
60 En-tête des installations INTEG_ISE
61 Postes d’installations et zones complémentaires. INTEG_ISP
62 En-tête de contrat de service INTEG_ICE
63 Poste de contrat de service INTEG_ICF
64 Domaine de couverture INTEG_ICL
65 Echéances facturées d’un contrat de service INTEG_ICH
88 Les appels (IAP) INTEG_IAP

Les tiers

Type Domaine Format description
15 Campagnes commerciales INTEG_CPG
16 Opérations commerciales INTEG_OPE
17 Promotions commerciales INTEG_OPC
18 Critères de ciblage commercial INTEG_OCC
46 Familles tiers INTEG_FAM
69 Dossier Client et Planning d’action INTEG_TIM
70 Fiche tiers INTEG_TIE
71 Adresses du tiers (tables ADR et LAD) (remplacé par le format “86” depuis la version ACE 1.1 (ACE 5.2-00)) INTEG_TIE_ADR
86 Adresses du tiers (tables ADR et LAD) – Format 50 caractères INTEG_TIE_ADR
72 Encours INTEG_ENC
74 Devises (tables DEV et DEM) INTEG_DEM
75 Représentants multiples INTEG_TII
76 Domiciliation bancaire INTEG_RIB
77 Liens tiers INTEG_TIL
78 Contacts de l'adresse INTEG_CTC
79 Contextes d’actions INTEG_CXA
A4 Adresses éphémères INTEG_TIE_ADR
A6 Lien entre le client et ses cartes privatives. INTEG_TICB

Les contrats

Type Domaine Format description
80 Entête de contrat (CNT) INTEG_CNT
83 Poste de contrat (CNP) INTEG_CNP

Le catalogue WEB

Type Domaine Format description
31 Objets média (MEDIA) INTEG_MEDIA
32 En-tête de catalogue (CAT) INTEG_CAT
33 Eléments du catalogue (CAE) INTEG_CAE
34 Modèles de recherche (ZODM) INTEG_ZODM
35 Rubriques de classification INTEG_RCA

La logistique

Type Domaine Format description
19 Objets de stock (SCE) INTEG_LOBJSTK
89 Le journal d’inventaire INTEG_ISKJ
95 Affectation Picking / Dépôt INTEG_DEP
97 Les colis (GEL) INTEG_LCOL
A7 Les emplacements INTEG_EMP
B1 Les en-têtes de cadencier de préparation INTEG_LCADE
B2 Les lignes du cadencier de préparation INTEG_LCADL
B3 Les familles et flux des lignes de cadenciers de préparation INTEG_LCADF
B4 Les en-têtes de BL DESADV INTEG_LRBE
B5 Les lignes de BL DESADV INTEG_LRBL
B6 Les listes de colisage INTEG_LRLCOL
B8

Gestion Aviexp Stock

INTEG_LMVTEE

La localisation au Brésil

C1 Les prix par axe logistique INTEG_AXELOGD
C2 Le détail des coûts logistiques par axe logistique INTEG_AXELOGDC
C3 Les taxes brésiliennes INTEG_TAXEBRESIL
     

Les autres informations

Type Domaine Format description
40 Texte libre (table TXT) INTEG_TXT
41 Zones paramétrées datées (table ZOD) INTEG_ZOD
42 Objet Lot (table OST) INTEG_OST
90 Mouvements de stock (table MSK) INTEG_MSK
96 Mode multi entités INTEG_ME
99 Rupture sur un ensemble cohérent d'éléments INTEG_RUP
91 Indicateurs (Spécifique Yves Rocher) INTEG_SINT
92 Quotas INTEG_SQTA
36 Cartes privatives INTEG_CPR
A9 Requêtes SQL INTEG_REQ_SQL
B7 Habilitation selon le type de QUE (table HQUE) INTEG_HQUE

L'interface AGILIX

Pour ce qui est des données intégrées entre ACE et AGIL, voir la documentation INTEG_AGILIX.

Fonctionnalités

Compte-rendu des intégrations (INTEG_CR)

Description technique des champs de cet écran.

Cette fonctionnalité, accessible par le menu ‘Compte-Rendu’, permet de visualiser les différentes informations propres aux intégrations.

Intégration n° : le compteur NUMINTEG doit être défini au préalable dans la gestion des compteurs (fonction UCPT).

Chaque intégration est identifiée par ce numéro et on y associe des informations complémentaires.

Code état : état de l’intégration

N° d’édition : numéro attribué automatiquement par le traitement différé.

Fichier Interface : nom du fichier intégré.

N° d’intégration de la relance : dans le cas où l’intégration a été relancée, numéro attribué par le système.

Fonctionnalités accessibles par popup à partir de cet écran :

Permet d’accéder au fichier journal (.log) en consultation. Pour accéder à ce popup, il faut positionner le paramètreINTLOG.

Le fichier log est codifié ‘PPPPPPssss_nnnnn.log’ avec :
  • PPPPPP représentant le préfixe du fichier (précisé par la zone L1 du paramètre INTLOG (ap$log :INT par défaut),

  • ssss=>

    le n° de société,
  • nnnnn => le n° d’intégration.

Pour connaître le nom du fichier et le numéro d’intégration sans voir les fichiers « log », utilisez le bloc d’édition integr_b95.

Traitements différés

Edition des formats d’intégration (INTEG_EDIT)

Description technique des champs de cet écran.

Cette fonctionnalité est accessible par le menu ‘Interface’.

Format Maquette
Texte (ASCII) INTEGE1
Blocs d’édition : INTEGR  

Relance des traitements d’intégration (INTEG_REL)

Description technique des champs de cet écran.

Cette fonctionnalité, accessible par le menu ‘Relance Fiche rejet’, permet de relancer des Intégrations.

Il est possible de traiter les rejets en utilisant le paramètre INTREJ.
Pour en savoir plus sur le paramétrage des fonctions, consulter la documentation "Le Configurateur Fonctionnel".

Trois options sont possibles :

Génération d’un fichier de relance

La première option crée un fichier à partir des données de la table des Rejets.

Relance de l’intégration

La seconde relance l’intégration à partir du fichier dont le nom est sauvegardé dans la table des Intégrations (entrée modifiable).

Génération + relance de l’intégration

Enfin, la troisième génère le fichier des rejets à partir de la table des Rejets et relance l’intégration directement après. Attention, les données sauvegardées dans la table des Rejets vont être rapatriées directement de la base de données afin de créer le fichier source pour l’intégration ; celles-ci ne sont donc pas modifiées depuis la première intégration.

Format Maquette
Texte (ASCII) INTEGE1
Blocs d’édition : INTEGR    

La Gestion des Rejets

Cette fonctionnalité permet d’identifier clairement chaque processus d’intégration (attribution d’un numéro unique) et d’y rattacher les éventuels éléments rejetés.

De cette manière, les données erronées peuvent être corrigées et l’intégration portant uniquement sur ces erreurs peut être relancée.

Sauvegarde des éléments rejetés de l’intégration

Les éléments rejetés de l’intégration sont sauvegardés dans une table et clairement identifiés par rapport à l’intégration origine.

Exemple de la logique utilisée pour la gestion des rejets par cet exemple : en cas d’erreur sur un poste (transaction sur événement), l’ensemble des enregistrements liés à l’événement est sauvegardé dans la table des rejets.

Pour les intégrations dont la taille de l’enregistrement dépasse 1000 caractères, les rejets sont mémorisés sur 2 enregistrements consécutifs. Pour les versions V500 V450 V440, le premier enregistrement, la zone LIGI01 contient 50 *, les autres zones contiennent la totalité de l’enregistrement rejeté. Pour la version V501, une zone a été ajoutée, INDSUI. Quand elle est positionnée ‘O’, cela signifie qu’un second enregistrement suit avec la suite du l’enregistrement.

Attention

La sauvegarde des données rejetées est consommatrice de mémoire. Par défaut, le fonctionnement autorise la sauvegarde.

Visualisation des erreurs

Le fichier journal de l’intégration est toujours généré identifiant le type d’erreur rencontrée sur l’élément. Les processus de correction peuvent alors être conçus.

Génération d’un fichier de relance

Un fichier créé à partir des données de la table des rejets est alors généré en vue d’une relance de l’intégration.

Relance des éléments corrigés de l’intégration

Il est alors possible de relancer l’intégration originelle qui s’est mal terminée. Un nouveau traitement différé est exécuté, qui est automatiquement associé à l’intégration originelle.

Purge des données d’intégrations (INTEG_PURGE)

Description technique des champs de cet écran.

Cette fonctionnalité, accessible par le menu ‘Purge’, permet de supprimer des données d’intégration et de rejets selon des critères de sélection.

Format Maquette
Texte (ASCII) INTEGP1
Blocs d’édition : INTEGP  

Editions

Pour les blocs d’édition, voir la description de la fonction INTEGR.

Description des enregistrements « Evénements »

Attention

Depuis la version ACE, il n’est plus nécessaire de compléter les champs numériques par des 0 à gauche. Pour exemple, les formats numériques acceptés sont « 001 » et/ou « 1 ».