TSV 端口可以将TSV(Tab-Separated Values)文件转换为XML，也可以从XML生成TSV文件。 概述 XML是知行EDI系统用于处理工作流中的数据的主要格式。因此，将TSV文件转换为XML作为在流程中进行进一步处理的暂存步骤，或者在处理完XML之后将XML转换为TSV文件，这两个操作都可以通过TSV端口完成。 有关将TSV转换为XML的详细信息，请参见“将TSV转换为XML”部分；有关将XML转换为TSV的详细信息，请参见将XML转换为TSV部分。 端口配置 本节包含所有可配置的端口属性。 配置 TSV [...]
通过EDI传输的采购订单(ORDERS)符合交易双方在商务合作环节达成的商业合作协议，且关于采购订单的任何消息都应符合原始采购订单。这样，间接提到了商业交易的商业合作协议。因此，不需要在采购订单之后的采购订单变更请求或采购订单回复中指定对合同或报价协议的引用，除非发出采购订单变更请求作为行项目添加到采购订单中。 如果在同一个订单周期中引用了多个合同/报价，则业务伙伴之间需要一份适用于所有涉及付款条款、交货条款(即标题级别的数据)的合同/报价的总体协议。因为EDI消息中的报价都不能传达此信息，需要从EDI信息中排除以前在商业合作协议中约定的所有信息。 买方和卖方之间约定一个产品编号用于识别订购的项目，作为主要参考编号。 为了识别订购的单个项目，通常使用买方文件编号(如BGM+220+PO11223+9'中PO11223)和买方行号(如LIN+1++ITEM222:BP::92'中1)的组合。 所有与采购货物相关的信息必须在明细项目级别指定，以避免任何歧义。因此，每个行项目都可以被视为一个订单。如果采购订单有多个行项目，则必须将其视为由采购订单编号和行项目编号标识的一个行项目采购订单的集合。因此，每个行项目都有自己的生命周期。 以用户自定义XML转换为TI要求的EDIFACT标准的ORDERS（订单）业务报文为例。 自定义XML格式的订单源数据 PO11223 19980212 9999 [...]
PSV端口可以将Pipe-Separated Values（PSV）文件转换为XML，也可以从XML生成PSV文件。 概述 XML是知行EDI系统用于处理工作流中的数据的主要格式。 因此，将PSV文件转换为XML作为在流程中进行进一步处理的暂存步骤，或者在处理完XML之后将XML转换为PSV文件，这两个操作都可以通过PSV端口完成。 有关将PSV转换为XML的详细信息，请参见“将PSV转换为XML”部分。 有关将XML转换为PSV的详细信息，请参见“将XML转换为PSV”部分。 端口配置 本节包含所有可配置的端口属性。 配置 [...]
Map端口使用脚本语言将XML文件转换为任意平面文件格式。 概览 Map端口有两种操作模式，可视化设计器和以脚本为中心的代码视图。设计器支持在文档类型之间可视化地建立简单的关系。更复杂的翻译需要代码视图，它利用强大的脚本语言来创建一个在XML和平面文件结构之间的映射模板。 首先，在“配置”选项卡中上传一个示例源文件和目标文件。如果两个示例文件的结构都允许设计器驱动的映射，那么可视化设计器将填充源和目标字段。该应用程序还将尝试用尽可能多的目标结构填充代码视图窗口。 端口配置 本节包含所有可配置的端口属性。 配置 端口配置 与端口核心操作相关的配置。 源文件 [...]
Excel 端口使用脚本模板从XML文件生成Excel文件。 总览 Excel端口主要通过模板文件进行配置。 该模板文件是一个Excel文件，其中包含静态列标题和rsbScript的组合。 该脚本处理端口输入的XML文件，用输入的数据动态填充Excel文档。 Excel 端口包含一个默认模板文件，可以将其用作参考，有关更多信息，请参见模板部分。 端口配置 本节包含所有可配置的端口属性。 [...]
数据库端口可以使用ODBC和ADO.NET(Windows)或JDBC (Java)驱动程序从各种数据库中存储和检索数据。 概览 数据库端口连接到许多不同的数据库提供程序之一。每个数据库端口实例都配置有适合目标数据库的驱动程序。开源数据库的驱动程序可以免费安装和使用: MySQL PostgreSQL SQLite 其他数据库需要额外的许可证才能安装和使用驱动程序: SQL Server [...]
CSV端口可以将逗号分隔值（CSV）文件转换为XML，也可以从XML生成CSV文件。 概览 XML是知行EDI系统用于工作流中的主要数据格式。 因此，将CSV文件转换为XML作为在工作流中进行进一步处理的暂存步骤，或者在处理完XML之后将XML转换为CSV文件非常有用。 这两个操作都可以通过CSV端口完成。 有关将CSV转换为XML的详细信息，请参见下方“将CSV转换为XML”部分。 有关将XML转换为CSV的详细信息，请参见下方“将XML转换为CSV”部分。 端口配置 本文包含所有可配置的端口属性。 设置标签 [...]
EDI ENVELOPE(电子数据交换信封)：数字信息包 EDI ENVELOPE用于向接收公司的业务系统发送电子交易数据。EDI ENVELOPE可以包括多个业务交易集，就像可以对多个纸质采购订单文档进行物理分组、填充并一起邮寄给接收者一样。EDI ENVELOPE是包含待发送给交易伙伴的EDI(电子数据交换)文件的数字包。EDI ENVELOPE有三种不同类型，代表不同级别的数字包装。其中包括Transaction Set(事务集)、Group(组)和Interchange Envelope(交换信封)，这些信封依次由较小的Interchange Envelope(交换信封)、Group(组)至Transaction [...]
EDI段（Segment）的使用 – 强制/可选 EDI段（Segment）的使用取决于测试和设置阶段与贸易伙伴所商定的标准。当贸易伙伴讨论贸易双方将在交易中使用的EDI单据类型时，他们会为EDI（电子数据交换）过程设置特定的规则。EDI规范包括一个贸易伙伴将发送给另一贸易伙伴的业务单据中的EDI段（Segment）。此类规范还为EDI段（Segment）的使用设定了规则，以确定EDI段（Segment）应该是可选的或是强制的。 EDI段（Segment）可以有两种类型，强制的和可选的。 M（mandatory）表示EDI段（Segment）是强制使用的。通常，这种类型的EDI段（Segment）包含EDI报文中的主要信息。如果报文中缺强制的片段，可能会无法阅读或理解其他片段或报文本身）。如果标准将该EDI段（Segment）设置为强制性的，则不能以其他可选的方式使用它。 强制的EDI段（Segment）示例： BEG00SA*ASNTESTORD**20060615~ 这是BEG段的标题 - [...]
EDI提供多种不同的报文标准，其中最常见的是ANSI ASC X12 (X12)和UN/EDIFACT(EDIFACT)。这两种标准非常相似，主要在用例和术语上有所不同。以下是这两种流行的EDI标准在格式上的区别和相似之处。 用例 这两个标准最大的区别在于它们的使用方式和用户所在的地理位置。特别是X12已经在医疗保健市场取得了重大进展，并且被用于常见的符合HIPAA标准的医疗保健文档，而EDIFACT则不支持医疗保健文档。但无论如何，X12和EDIFACT都被广泛的用于其他行业，比如供应链行业，金融行业和政府。 X12是大多数总部位于美国的公司最常用的EDI标准。而EDIFACT是欧洲和亚洲的国际公司最青睐的EDI标准。 格式 从概念上讲，EDIFACT和X12是相似的。两者在很大程度上使用相同的消息结构，只是术语不同。 如下图所示，X12和EDIFACT报文包括以下元素: [...]
