Vue d'ensemble de l'architecture IET

Introduction

Ce document fournit des informations détaillées sur l'architecture actuelle de la solution interface d'exécution de transport (IET) de M3.

Fonctionnalité IET

Cette figure illustre la fonctionnalité IET dans son ensemble.

La solution IET de M3 est orientée transfert ('push'), ce qui signifie que les informations sont créées dans M3 et peuvent être traitées, visualisées et modifiées avant d'être envoyées vers le système externe. Cette solution active un flux d'informations de transport flexible, orienté acheminement avec Infor Enterprise Collaborator (IEC). En d'autres termes, l'intégration est plus flexible et les données envoyées au système IET circulent de M3 vers IEC à l'aide des interfaces API de M3.

La liste suivante fournit une explication brève des événements de la solution IET de M3.

• Déclencheurs d'événements

  L'utilisation d'un événement prédéfini constitue une façon de déclencher la création d'un transfert IET. Dans ce cas, il est possible de déclencher le document. L'impression d'une liste de prélèvement ou la sortie d'une livraison constituent des exemples d'événements.

• Déclencheur manuel par fonction

  Le déclenchement manuel qui est ajouté à certaines fonctions constitue une autre façon de déclencher la création d'un transfert IET. En sélectionnant l'option 53 dans 'Livraison. Ouvrir boîte à outils' (MWS410) ou 'Expédition. Ouvrir boîte à outils' (DRS100), vous pouvez créer un transfert IET comprenant les informations de livraison. A partir de 'Livraison. Connecter colis' (MWS423), vous pouvez sélectionner l'option 53 pour déclencher un transfert IET comprenant des informations de colis.

• Déclencheur manuel par groupe sélectionné – (MYS510)

  La troisième façon de créer un transfert IET consiste à sélectionner manuellement une version d'enregistrement et à laisser le système créer un ou plusieurs transferts à partir de cette sélection. Lors de la création d'un transfert IET à partir d'une transaction sortante, toute sélection d'objets à partir de l'expédition ou de la livraison est utilisée. Pour une transaction entrante, toute sélection d'objets à partir de la livraison (OD), de l'ordre d'achat ou de la ligne de commande d'achat est utilisée.

• Contrôle de documents basés sur les événements

  Les documents basés sur les événements (CLA) permettent de déclencher un transfert IET à partir d'un événement système (une hausse de statut, par exemple) ou d'un événement manuel (comme l'utilisation de l'option 53 dans la boîte à outils de livraison). La fonction CLA est fondée sur des événements prédéfinis qui sont contrôlés par une table de sélection afin de détecter si (ou à quel moment) un document spécifique doit être imprimé. Il est possible d'utiliser cette fonction pour plusieurs documents. Le document de transfert IET est un document spécifique.

• Document de transfert IET

  Le document de transfert IET n'est pas un document habituel, mais plutôt un déclencheur utilisé pour démarrer la création d'un transfert IET. Il contient uniquement des informations de base concernant soit l'événement ayant déclenché la création, soit l'information tirée de la sélection effectuée dans une version d'enregistrement. Le numéro de document utilisé pour le document de transfert IET est le 915. Seule la variante de document 00 est standard, mais il est possible d'utiliser toute valeur jusqu'à 99. Il est conseillé d'utiliser une combinaison de numéro et de variante de document pour chaque ensemble d'informations de sorties qui sera utilisé. Par exemple, si une information de colis doit être envoyée à un système de transport externe, il convient d'utiliser une variante de document. Cela dit, une autre variante sera utilisée si l'information de livraison est envoyée aux systèmes TES.

  • Gestion des transferts IET – MYMNGTEI

    Ce programme est essentiel pour gérer les transferts IET. Il appelle d'autres programmes pour déclencher des tâches spécifiques. Par exemple, lorsque e programme MYRTVTOC est appelé pour extraire un enregistrement de contrôle des sorties et créer un en-tête de transfert IET, le programme MTITHEPI est ensuite appelé. Pour envoyer un transfert IET à un système externe, le système utilise ce programme qui crée un déclencheur MBM et l'envoie à IEC.

  • Extraction des données de contrôle des sorties IET

    Certaines données devant être ajoutées à un transfert IET créé sont contrôlées par un objet. Ces données sont extraites de la table MDOCTI. Le système de transport externe devant recevoir un transfert IET spécifique est l'un des paramètres que gère cette fonction. Ce programme est appelé pour chaque transfert IET déclenché par un événement.

  • Gestion d'un en-tête de transfert IET – MTITHEPI

    Lorsque vous vérifiez, ajoutez ou modifiez un en-tête de transfert IET, la fonction MTITHEPI est utilisée. Chaque gestion d'un transfert IET dans la table MTITHE est gérée par cette fonction.

  • Gestion des détails de transfert IET – MTITDEPI

    De la même manière que MTITHEPI gère les en-têtes IET, cette fonction gère les détails de transferts IET. Lorsqu'un détail de transfert IET figurant dans MTITDE doit être traité d'une manière ou d'une autre, c'est la fonction MTITDEPI qui effectue l'opération.

  • Utilisation d'un en-tête de transfert IET

    Cette fonction permet de gérer les en-têtes de transfert IET déjà créés. De là, il est possible de modifier, d'ajouter et d'envoyer manuellement un en-tête de transfert IET au système externe.

  • Utilisation des détails de transfert IET

    Cette fonction permet de gérer les détails de transfert IET déjà créés et associés à l'en-tête de transfert. Elle permet d'ajouter, de supprimer ou de modifier des détails IET.

  • Mappage IEC

    Le transfert IET, une fois envoyé à IEC, permet de déclencher un modèle prédéfini, un mappage IEC. Ces modèles utilisent plusieurs interfaces API différentes pour extraire des informations transactionnelles à partir de M3 dans une séquence.

  • XML

    La sortie du mappage IEC s'effectue toujours au format XML. Si le champ réception peut gérer les fichiers XML, tout traitement supplémentaire du fichier de sortie est inutile.

  • Référentiel de fichiers non hiérarchiques

    Dans les cas où le système de réception peut uniquement gérer un format de fichiers non hiérarchiques, il est possible de convertir le fichier XML. Cette opération s'effectue à l'aide du référentiel de fichiers non hiérarchiques.

Mappage d'IEC et IET

La figure suivante illustre les principes d'utilisation de IEC et des API pour télécharger des informations de transport à partir de M3 BE. La contrepartie d'IEC peut être soit un système d'exécution de transport, soit un partenaire externe (un client, un fournisseur ou un transitaire) qui reçoit des messages B2B (EDI, XML, etc.).

Les interfaces API et la logique métier de M3 BE sont considérées comme des fonctions standard fournies et prises en charge selon des routines normales. Les mappages de IEC nécessaires pour récupérer des informations de M3 BE et créer tout type de fichier de sortie envoyé à un système d'exécution de transport suivent une routine différente. En l'absence de norme universelle (comparez ANSI X12, EDICFACT, etc.), Infor ne peut pas fournir de livraison standard dans ce cadre.

Les mappages de modèle IEC fournis par Infor génèrent un fichier XML (qui prend en charge la logistique des sorties) ainsi qu'un fichier non hiérarchique (qui prend en charge la logistique des entrées). Ces deux fichiers sont générés d'après un système TES appelé EDICOM, dont le fichier standard d'interface a pour nom 'CEDITRAN'. Chaque mise en œuvre peut alors utiliser ces modèles et les modifier pour qu'ils prennent le format approprié aux systèmes TES. Si vous utilisez EDICOM, vous devrez effectuer quelques ajustements, chaque mise en œuvre EDICOM étant unique.

Il est également possible de lancer des mappages B2B dans IEC pour prendre en charge les messages B2B (EDIFACT, XML, ANSI X.12, etc.) envoyés aux transitaires ou aux douanes. Ces formats uniques, propres aux mises en œuvre et les messages B2B ne constituent pas une livraison provenant d'Infor.

Recommandations d'ordre général - Mappages IEC personnalisés

Chaque mappage IEC propre à un client doit comprendre les éléments suivants :

1. Appel initial de l'interface API à MYS500MI GetHead en fonction de l'initiateur MBM envoyé qui contient l'ID de transfert IET.
2. Appel de l'interface API à MYS500MI ChgHead avec le champ STAT = 15. Cette opération met à jour l'ID de transfert IET dans (MYS500), avec un statut indiquant que le mappage IEC a démarré.
3. Appel de l'interface API à MYS500MI LstDetail pour extraire la liste des enregistrements détaillés créée dans (MYS501). La nature des détails dépend du type d'événement en cours et du type de détails.
4. Appels de l'interface API personnalisée d'après les éléments à générer comme sortie du mappage IEC en cours. Ici, la solution de mappage de modèles d'IRD doit être remplacée mais réutilisée.
5. Facultatif : effectuez un appel de l'interface API à MYS500MI ChgHead avec le champ STAT = 19. Cette opération met à jour l'ID de transfert IET dans (MYS500), avec un statut indiquant que le mappage IEC a interrompu le traitement avant la fin planifiée avec une erreur contrôlée qui ne doit pas créer de fichier de sortie.
6. Appel initial de l'interface API à l'API MYS500MI ChgHead avec le champ STAT = 20. Cette opération met à jour l'ID de transfert IET dans (MYS500), avec un statut indiquant que le mappage IEC s'est déroulé correctement.

Journaux de concepts

Pour prendre en charge l'analyse du déclenchement d'événement, il est possible d'activer des journaux de concepts dans la vue serveur. Ces journaux affichent des données utilisées lors du déclenchement d'événement et de la création IET.

Pour activer le concept et journaliser le déclenchement d'événement, activez

mvx.sce.edc.EventTriggering

Pour activer le concept et journaliser la création d'un transfert IET, activez

mvx.sce.tei.TransferCreation

Une fois les concepts activés, des informations sont écrites dans le journal JVM au cours du processus.

Configurations dans (MYS015)

Dans (MYS015), il est possible d'associer un partenaire IET au numéro de document 915 ainsi qu'à une variante de document. Il est recommandé d'utiliser une variante de document pour chaque objectif et chaque partenaire IET. Par exemple, pour envoyer des informations de colis à un système externe, il convient d'envoyer une variante de document et d'en utiliser une autre si les données à envoyer au système externe sont des informations de transport.

Configurations dans (MWS145)

Il est possible d'utiliser plusieurs numéros de séquence dans (MWS145) afin de déclencher un document plusieurs fois. Il est préférable d'éviter cette fonctionnalité en cas de déclenchement du document de transfert IET, dans la mesure où cela peut entraîner l'envoi de plusieurs transferts IET avec les mêmes détails au système externe. Pour éviter cette situation, utilisez si possible le document de transfert IET dans un seul numéro de séquence, ou soyez prudent lors du paramétrage des objets de contrôle dans (MWS145).

L'événement LANCEMENT_PRELEVEMENT peut, comme mentionné précédemment, uniquement déclencher des détails de colis du transfert IET. L'événement étant déclenché lors de l'impression de chaque suffixe de liste de prélèvement, la méthode de validation de conditionnement = 4 (automatiquement au moment de l'impression de la liste) constitue l'option la plus utile. Toutefois, cette fonctionnalité a ses restrictions. Lors de l'impression du suffixe de liste de prélèvement 1 et du conditionnement des lignes de cette dernière en deux colis complets plus un troisième colis semi-complet, un transfert IET est créé avec un enregistrement de détail par numéro de colis. Une fois le suffixe de liste de prélèvement 2 imprimé, il est possible de poursuivre le conditionnement dans le troisième colis semi-complet. Cela permet de déclencher un deuxième transfert IET avec un enregistrement de détail (le troisième colis) déjà existant sur transfert IET. Ainsi, selon le système de réception, cette opération peut provoquer quelques problèmes. Si le système de réception parvient à gérer l'envoi du même enregistrement de détail plusieurs fois, il n'y a aucun problème, mais s'il est incapable de l'envoyer deux fois, le paramètre Autoriser les détails dupliqués doit avoir la valeur 0, ce qui empêche la non-association des détails au transfert IET, d'après l'impression du suffixe de liste de prélèvement 2 ci-dessus.

La solution à ce problème peut être l'utilisation d'un autre événement automatique (LIVRAISON_LANCEE, par exemple), ou celle de l'événement manuel COLIS_MANUEL. Dans le dernier exemple, chaque colis peut être déclenché individuellement lorsqu'il est intégralement conditionné.

Configurations dans (MWS275)

Le paramètre le plus important dans (MWS275) est le partenaire IET qu'un transfert IET créé à partir de l'enregistrement de contrôle de sortie IET doit recevoir. Des explications supplémentaires peuvent être spécifiées dans les autres champs de (MWS275), qui concernent les numéros de référence complémentaire IET. Il est possible d'associer une référence complémentaire d'en-tête IET à chaque en-tête de transfert IET créé, et une référence complémentaire de détail IET à chaque détail de transfert IET. L'objectif principal de cette fonctionnalité peut être si le niveau de détail est le numéro de colis, et si chaque colis doit avoir un numéro unique d'après le destinataire du transfert IET (un transitaire, par exemple). Ensuite, la référence complémentaire de détail IET doit être activée. Les méthodes de référence complémentaire existantes sont 0 (aucune référence complémentaire de détail IET), 1 (à partir du numéro de série) ou 2 (à partir d'un programme de sortie utilisateur). Si vous utilisez la méthode 2, vous devez développer un programme de modification client afin de correspondre aux demandes spécifiques à cette mise en œuvre.

Présentation des entités de transfert IET

Le domaine IET gravite autour de l'entité de transfert IET qui résulte de la demande de téléchargement d'informations liées au transport. Chaque transfert IET recèle des relations associées à une logistique des entrées ou des sorties avec leurs entités respectives.

Les entités associées (expéditions, livraisons, lignes de livraison, colis, ordres d'achat et lignes d'ordres d'achat) sont créées dans M3 en fonction du flux de processus entrant et sortant. La création d'entités impliquées est configurable et ses variations sont fondées sur la flexibilité lors de la configuration du produit M3.

Les déclencheurs de document basé sur les événements qui sont sélectionnés par l'utilisateur lancent automatiquement un transfert IET lorsqu'un événement a lieu. Les déclencheurs d'événements sélectionnés sont choisis d'après les activités de traitement habituel dans M3. Exemple de déclencheur : lorsqu'une expédition est fermée et qu'aucune livraison ultérieure n'y est ajoutée. Autre exemple : lorsqu'une livraison est effectuée et que toutes les listes de prélèvement correspondant à un numéro de livraison sont des livraisons enregistrées. Il est aussi possible de lancer manuellement des transferts IET permettant un regroupement défini par l'utilisateur hors des entités de regroupement habituelles, comme les expéditions, les livraisons et les ordres d'achat.

Aperçu des entités

Les entités suivantes contiennent des simplifications concernant l'association entre un colis et une ligne de livraison, ainsi que les relations à l'entité de liste de prélèvement.

Description des entités de transfert IET

Evénements de transferts IET

Chaque événement peut être sélectionné pour lancer le transfert IET. Tous les événements (à l'exception du transfert IET manuel) sont représentés par un statut supérieur de l'entité.

Evénements de logistique des sorties

Evénements de logistique des entrées

Version d'enregistrement IET

Au lieu d'utiliser un événement pour déclencher la création d'un transfert IET, il est possible d'avoir recours à une version d'enregistrement avec sélection manuelle. La sélection peut être interfonctionnelle, ce qui signifie qu'il est possible de sélectionner des livraisons associées à différentes expéditions, par exemple, et d'y avoir accès dans un seul transfert IET. Chaque version d'enregistrement peut être utilisée plusieurs fois, mais le type de version de l'enregistrement des paramètres ne peut plus être modifié une fois la création terminée. Une version d'enregistrement peut avoir la valeur 1 (Sortant), 2 (Entrant) ou 3 (OD entrant).

• Type 1 (Sortant) :

  Il est recommandé d'utiliser ce type de version d'enregistrement lors de la création des transferts IET, y compris les transactions sortantes, comme les livraisons et les expéditions. Il est possible d'utiliser toute sélection d'objets de la livraison et de l'expédition pour regrouper des livraisons en un transfert IET. Le niveau de détail du transfert IET créé à partir d'une version d'enregistrement de type 1 est toujours par numéro de livraison.

• Type 2 (Entrant)

  Il est recommandé d'utiliser ce type de version d'enregistrement lors de la création des transferts IET, y compris les transactions entrantes, comme les ordres d'achat. Il est possible d'utiliser toute sélection d'objets de l'en-tête et des lignes de l'ordre d'achat pour regrouper des lignes d'ordre d'achat en un transfert IET. Le niveau de détail du transfert IET créé à partir d'une version d'enregistrement de type 2 est toujours par ligne de commande d'achat.

• Type 3 (OD entrant)

  Il est recommandé d'utiliser ce type de version d'enregistrement lors de la création de transferts IET (notamment les transactions OD entrantes), comme une livraison sur le point de devenir une réception de marchandises. Il est possible d'utiliser toute sélection d'objets de la livraison et de l'expédition pour regrouper des livraisons OD entrantes dans un transfert IET. Le niveau de détail du transfert IET créé à partir d'une version d'enregistrement de type 3 est toujours par numéro de livraison.