TEI 架构概述
简介
本文档提供有关 M3 运输执行接口 (TEI) 解决方案的当前架构的详细信息。
TEI 功能
此图描述整个 TEI 功能。
M3 TEI 解决方案是推式解决方案,这表示信息在 M3 中创建,并且可以在发送到外部系统之前进行处理、查看和更改。该解决方案与 Infor Enterprise Collaborator (IEC) 一起实现了灵活的、拉式运输信息的信息流。这表示集成更灵活,并且发送到 TEI 系统的数据通过 IEC 使用 M3 API 从 M3 提取。
以下列表简要描述了 M3 TEI 解决方案中的事件。
-
事件触发器
触发创建 TEI 传输的一种方法是使用预定义事件。发生此事件时,可以触发 TEI 传输文档。事件示例为打印拣货单或发放交货。
-
按功能手动触发
触发创建 TEI 传输的另一种方法是使用在某些功能中添加的手动触发。通过从交货。打开工具箱 (MWS410) 或发货。打开工具箱 (DRS100) 中选择选项 53,可以创建包含交货信息的 TEI 传输。从交货。连接包装 (MWS423),可以选择选项 53 以触发包含包装信息的 TEI 传输。
-
按选择的群组手动触发。(MYS510)
创建 TEI 传输的第三种方法是在报表版本中进行手动选择,并让系统根据选择创建一个或多个传输。为出站交易创建 TEI 传输时,将使用发货和交货中的选择对象。对于入站交易,将使用交货 (DO)、采购订单或采购订单行中的选择对象。
-
基于事件的文档控制
基于事件的文档控制 (EDC) 用于从系统事件(例如,状态提升)或手动事件(例如,使用交货工具箱中的选项 53)触发 TEI 传输。EDC 功能基于由选择表控制的预定义事件,以检测何时或是否应打印特定文档。此功能可用于多个文档,并且一个特定文档是 TEI 传输文档。
-
TEI 传输文档
TEI 传输文档不是常规文档,而是用于启动 TEI 传输创建的触发器。本文档仅包含有关触发创建的事件或来自报表版本中所选内容的信息的基本信息。用于 TEI 传输文档的文档号为 915。只有文档变型 00 是标准的,但是可以最高为 99 的任何值。对于将使用的每组输出信息,建议使用一种文档号和文档变型组合。例如,如果包装信息应发送到外部运输系统,则应使用一个文档变型,但如果将交货信息发送到运输执行系统,则使用另一个文档变型。
-
管理 TEI 传输 - MYMNGTEI
此程序是管理 TEI 传输的核心。它将调用其他程序来触发特定任务。例如,调用程序 MYRTVTOC 来检索输出控制记录并创建 TEI 传输标题时,将调用程序 MTITHEPI。当 TEI 传输发送到外部系统时,将由用于创建 MBM 触发器并将其发送到 IEC 的此程序完成该操作。
-
检索 TEI 输出控制数据
应添加到已创建 TEI 传输中的某些数据是对象控制的数据。此数据从 MDOCTI 表中检索。应接收特定 TEI 传输的外部运输系统是在此功能中管理的参数之一。将对每个事件触发的 TEI 传输调用此程序。
-
管理 TEI 传输标题。MTITHEPI
检查、添加或更改 TEI 传输标题时,将使用功能 MTITHEPI。MTITHE 表中 TEI 传输的每个管理都由此功能管理。
-
管理 TEI 传输明细。MTITDEPI
此功能将按照 MTITHEPI 管理 TEI 传输标题的方式管理 TEI 传输明细。应以任何方式处理 MTITDE 中的 TEI 传输明细时,此操作由功能 MTITDEPI 完成。
-
使用 TEI 传输标题
此功能用于管理已创建的 TEI 传输标题。可以在此处更改、添加 TEI 传输标题以及人工将其发送到外部系统。
-
处理 TEI 传输明细
此功能用于管理已创建并连接到传输标题的 TEI 明细。可以在此功能中添加、删除或更改 TEI 明细。
-
IEC 映射
TEI 传输已发送到 IEC 时,它将用于触发预定义模板,即 IEC 映射。这些模板将使用几个不同的 API 从序列中检索来自 M3 的交易信息。
-
XML
IEC 映射的输出将始终采用 XML 格式。如果接收系统可以管理 XML 文件,则不需要对输出文件进行额外处理。
-
平面文件存储库
在接收系统只能管理平面文件格式的情况下,可以转换 XML 文件。此操作使用平面文件存储库完成。
-
管理 TEI 传输 - MYMNGTEI
将 IEC 映射到 TEI
下图描述了使用 IEC 和 API 从 M3 BE 下载运输信息的原则。IEC 的对应方可以是运输执行系统或接收 B2B 消息(EDI、XML 等)的外部合作伙伴(例如,客户、供应商或转运商)。
系统将 M3 BE 业务逻辑和 TEI 接口中的 API 视为根据正常例行程序交付和支持的标准功能。IEC 中需要从 M3 BE 提取信息并创建将发送到运输执行系统的任意类型输出文件的映射遵循不同的例行程序。由于没有通用标准(比较 ANSI X12、EDICFACT 等),因此 Infor 无法为此目的提供标准交货。
Infor 提供的模板 IEC 映射将同时生成 XML 文件(支持出站物流)和平面文件输出(支持入站物流)。XML 文件和平面文件输出基于称为 EDICOM 的运输执行系统及其接口文件标准“CEDITRAN”生成。然后,每个实现都可以使用这些模板,并根据所使用的运输执行系统将其修改为自己的格式。如果使用 EDICOM,可能需要较小的调整,因为每个 EDICOM 实现都是唯一的。
也可以在 IEC 中生成 B2B 映射,以支持将 B2B 消息(EDIFACT、XML、ANSI X.12 等)发送到转运商或海关。这些实现唯一的格式和 B2B 消息不是来自 Infor 的交货。
一般建议 - 自定义的 IEC 映射
每个客户唯一的 IEC 映射必须始终包含以下内容:
- 对 MYS500MI GetHead 的初始 API 调用(基于已发送的包含 TEI 传输 ID 的 MBM 发起程序)。
- 对包含字段 STAT = 15 的 MYS500MI ChgHead 的 API 调用。将更新 (MYS500) 中的 TEI 传输 ID,其状态指示 IEC 映射已启动。
- 对 MYS500MI LstDetail 的 API 调用,以检索在 (MYS501) 中创建的详细记录的列表。明细的性质根据当前事件类型和明细类型。
- 定制 API 调用,基于应作为来自当前 IEC 映射的输出生成的内容。此处必须替换 IRD 模板映射解决方案,但将其重复使用。
- 可以有选择地对包含字段 STAT = 19 的 MYS500MI ChgHead 执行 API 调用。将更新 (MYS500) 中的 TEI 传输 ID,其状态指示 IEC 映射在计划结束之前已停止处理,并带有不应创建任何输出文件的控制错误。
- 对包含字段 STAT = 20 的 API MYS500MI ChgHead 的初始 API 调用。将更新 (MYS500) 中的 TEI 传输 ID,其状态指示 IEC 映射已成功完成。
概念日志
为了支持事件触发分析,可以在服务器视图中激活概念日志。概念日志将显示触发事件和 TEI 创建期间使用的数据。
应该仅在分析期间激活概念日志,以最小化工作量。
要激活概念以记录事件触发,请启用以下概念:
mvx.sce.edc.EventTriggering
要激活概念以记录 TEI 传输的创建,请启用以下概念:
mvx.sce.tei.TransferCreation
激活概念时,信息将在处理期间写入 JVM 日志。
(MYS015) 中的配置
在 (MYS015) 中,可以将 TEI 合作伙伴连接到文档号 915 和文档变型。建议对每个目的和每个 TEI 合作伙伴使用一个文档变型。例如,要将包装信息发送到外部信息,则应使用一个文档变型,而如果是要发送到外部系统的运输信息,则应使用另一个文档变型。
(MWS145) 中的配置
可以在 (MWS145) 中使用多个序号多次触发文档。在触发 TEI 传输文档的情况下,应该避免使用此功能,因为它可以导致出现多个包含发送到外部系统的相同明细的 TEI 传输。如果可能,请仅使用一个序号的 TEI 传输文档,或者在 MWS145 中设置控制对象时要小心,以避免出现这种情况。
如前所述,事件 Release_Pick 只能在 TEI 传输中触发包装明细。由于此事件是在打印每个拣货单后缀时触发的,因此包装报告方法 = 4(打印拣货单时自动)是最有用的方法。但是,此功能中存在限制。打印拣货单后缀 1 并且所包含的拣货单行打包在 2 个完全包装和第三个半完整包装中时,将创建一个 TEI 传输,其中每个包装号都有一条详细记录。打印拣货单后缀 2 时,有可能在第三个半完整包装中继续进行打包。这将导致出现包含 TEI 传输中已存在一条详细记录(第三个包装)的第二个 TEI 传输。因此,根据接收系统,这可能会导致一些问题。如果接收系统可以管理多次发送的同一详细记录,这不会产生任何问题,但是如果接收系统无法管理同一详细记录两次,则参数“允许重复的明细”应设置为 0,这将避免出现明细未根据上述拣货单后缀 2 打印连接到 TEI 传输的情况。
此问题的解决方案可以是使用另一个自动事件(如 Delivery_Issued)或使用手动事件 Manual_Package。在随后的示例中,可以在包装完全打包时分别触发每个包装。
(MWS275) 中的配置
(MWS275) 中最重要的设置是 TEI 合作伙伴应接收根据 TEI 输出控制记录创建的 TEI 传输。但是,可能存在一些扩展解释的区域是 (MWS275) 中关于 TEI 别名编号的其他字段。对于每个已创建的 TEI 传输标题,可以连接 TEI 标题别名,而对于每个 TEI 明细,可以连接 TEI 明细别名。该功能的主要目的可以是,如果明细级别为包装号,并且根据 TEI 传输的接收方(例如,转运商),每个包装应具有唯一编号,则应激活 TEI 明细别名。现有的别名方法为 0(无 TEI 明细别名)、1(来自序列号)或 2(来自用户退出程序)。使用方法 2 时,必须开发客户修改程序以满足该实施的特定需求。
TEI 传输实体概述
TEI 域围绕 TEI 传输实体,该实体是下载运输相关信息的请求的结果。对于每个 TEI 传输,存在与包含其相应实体的出站或入站物流相关的关系。
相关实体(例如,发货、交货、交货行、包装、采购订单和采购订单行)在 M3 内部基于出站和入站流程创建。可以配置所涉及实体的创建,并且在配置 M3 产品时此配置具有基于灵活性的变化。
事件发生时,由用户选择的基于事件的文档触发器将自动启动 TEI 传输。根据 M3 内部的正常处理活动选择所选事件触发器。此类触发器的示例为当关闭发货并且没有更多交货将添加到发货时。另一个示例是当发放交货并且交货号的所有拣货单都是已报告的发放时。或者,可以人工启动 TEI 传输,允许正常分组标识(例如,发货、交货和采购订单)之外的用户自定义分组。
实体概览
以下实体概览包含关于包装和交货行之间的连接以及与拣货单实体的关系的一些简化。
TEI 传输实体描述
实体 |
描述 |
---|---|
TEI 传输 |
表示从与 TEI 相关的 M3 下载一组信息的请求。 TEI 传输将保留多个特性,目的是表示每个下载运输信息请求的关键信息。这些特性包括: 消息方向、方向、传输 ID、状态、事件、事件关键字、文档号、文档变型、合作伙伴级别。 |
文档定义 |
通过用于创建文档的程序表示每个 M3 文档号和文档变型。 与运输执行系统的集成由文档号 915 表示,但可以使用多个文档变型 (00 - 99)。文档变型用于根据流程中的什么阶段需要什么信息来实现发货流程中的多个集成点。例如,拣货单以变量 00 的形式下达时发送标签信息。随后,发放交货时,变量 01 用于发送关于所有运输和海关单据的更多信息。 |
事件 |
供应链执行 (SCE) 和采购订单处理 (PUR) 流程中可用的可检测事件。每个事件都包含事件的允许文档列表。一些事件将允许并启动 TEI 传输。有关所允许的事件,请参阅“TEI 传输事件”。 |
文档触发器 |
表示可检测事件、序号和对象组合的组合。当已定义对象发生事件时,指向要触发的一个或多个文档号和文档变型。 |
文档输出控制 |
保留与 TEI 文档号和文档变型相关的多项控制信息。 控制信息包括标识、序列号、文档号和变量、传输和包装 ID 以及传输变量之类的内容。 |
发货 |
发货将收集多个交货,这些交货共享关于启运日期/时间、交货模式、转运商、路线、运输设备等的相同特性。 |
交货 |
交货将收集多个订单行,这些订单行共享关于发货人、收货人、启运日期/时间、交货条款、交货模式、转运商、路线等的相同特性。 |
交货行 |
按订单类别(客户订单、配送单、请购订单或制造订单)分类的特定交货行。交货行指定物料号和数量。它链接到每个订单类别的订单输入功能中创建的订单行并且是其结果。 |
拣货单 |
表示根据一次交货创建的每个单独的拣货单。系统定义和用户自定义的不同规则适用于如何将交货拆分成多个拣货单。库存输入和分配的时间也可能导致按交货拆分拣货单。 |
包装 |
表示要发货 (CO/DO/RO) 或要接收 (DO) 的每个物理包装。包装包含物料、其他包装或两者的组合。保留有关连接到包装的物理特性(重量、体积等)的信息。 |
包装组 |
表示共享关于包装或包装组的相同特性的一组包装。可以使用交货、发货或传输 ID 作为分组级别来请求分组。 |
采购订单 |
表示从特定供应商处进行采购。 |
采购订单行 |
表示采购物料和数量。 |
采购订单行交易 |
表示在输入订单行之后针对采购订单行进行的每项报告交易。例如,收货交易。 |
TEI 传输事件
每个事件可以选择作为启动 TEI 传输的事件。除了手动 TEI 传输之外,所有事件都由实体上的提升状态表示。
出站物流事件
事件 |
描述 |
---|---|
已下达拣货单 |
通过人工或时间触发下达拣货单,从而生成新拣货单(交货号和拣货单后缀)。根据配置,可以同时执行包装报告。 适用于 CO、RO 和出站 DO。 |
已关闭发货 |
已人工关闭发货,表示无法再添加更多交货。所有可能的延交订单行都将移至新的交货号,还可能移至新发货。 适用于 CO、RO 和出站 DO。 |
已关闭交货 |
已人工关闭交货,表示无法再添加更多订单行。所有可能的延交订单交货行都将移至新交货号。 适用于 CO、RO 和出站 DO。 |
发货已发放 |
已发放发货,并且已超过截止时间。这表示已发放所有包含的交货,并且不会再自动添加交货。所有可能的延交订单行都将移至新的交货号,还可能移至新发货。 适用于 CO、RO 和出站 DO。 |
交货已发放 |
已发放交货。这表示交货已进行完全发放报告,并且所有可能的延交订单行都将移至新交货号。 适用于 CO、RO 和出站 DO。 |
发货已开票 |
发货已完全开票,表示所有包含的交货和交货行都已开票。此事件在开票例行程序打印发票时发生。 仅适用于 CO。 |
交货已开票 |
交货已完全开票,表示所有包含的交货行都已开票。此事件在开票例行程序打印发票时发生。 仅适用于 CO。 |
Manual_Del |
此事件由手动操作(交货。打开工具箱 (MWS410) 中的选项 53)触发,而不是通过更改状态触发。此事件按交货触发,并且事件关键字将为交货号。 适用于 CO、RO 和出站 DO。 |
Manual_Shp |
此事件由手动操作(发货。打开工具箱 (DRS100) 中的选项 53)触发,而不是通过更改状态触发。此事件按发货触发,并且事件关键字将为出货号。 适用于 CO、RO 和出站 DO。 |
Manual_Package |
此事件由手动操作(交货。连接包装 (MWS423) 中的选项 53)触发,而不是通过更改状态触发。此事件按包装触发,并且事件关键字将由交货号和包装号的组合组成。 适用于 CO、RO 和出站 DO。 |
入站物流事件
事件 |
描述 |
---|---|
收货 DO |
每个 DO 根据随实际交货提供的信息报告为已收货。 报告完整的入站交货号时发生此事件。 适用于入站 DO。 |
收货采购订单 |
每个采购订单行都基于物理交货提供的信息报告为已收到货物。 在报告单个采购订单行收货(报告编号)时,将发生该事件。 适用于采购订单。 |
TEI 报表版本
可以使用具有手动选择的报表版本代替使用事件触发 TEI 传输的创建。选择可以跨功能,这表示可以选择连接到不同发货的交货,并且仍然在一个 TEI 传输上获得它们。可以使用多次每个报表版本,但是参数“报表版本类型”无法在创建后进行更改。报表版本可以具有报表版本 1(出站)、2(入站)或 3(入站 DO)。
-
类型 1(出站)
创建包含出站交易(例如,交货和发货)的 TEI 传输时应使用此报表版本类型。来自交货和发货的选择对象可用于将交货分组到 TEI 传输。根据类型 1 的报表版本创建的 TEI 传输的明细级别始终基于每个交货号。
-
类型 2(入站)
创建包含入站交易(例如,采购订单)的 TEI 传输时应使用此报表版本类型。来自采购订单标题和采购订单行的选择对象可用于将采购订单行分组到 TEI 传输。根据类型 2 的报表版本创建的 TEI 传输的明细级别始终基于每个采购订单行。
-
类型 3(入站 DO)
创建包含入站 DO 交易(例如,将为收货的交货)的 TEI 传输时应使用此报表版本类型。来自入站交货和发货的选择对象可用于将 DO 交货分组到 TEI 传输。根据类型 3 的报表版本创建的 TEI 传输的明细级别始终基于每个交货号。