医疗器械行业客户EDI项目案例

项目背景

医疗器械行业的发展直接受制于其供应链上下游的发展状况，“上游”零组件供应商的支持占据着重要地位。如何确保与供应链“上游”建立长期稳定的合作关系，对医疗器械行业的企业而言至关重要。国内某医疗器械行业客户(以下简称M公司)在国内市场已有近三十年的行业经验，在持续巨额的研发投入之外，通过EDI技术，有效加强与“上游”供应商的合作关系。

edi

方案简介

近期，医疗器械行业M公司与知行软件达成合作，在本地部署EDI系统，并与其“上游”供应商TI建立EDI连接，实现业务数据收发流程的自动化。通过EDI系统向TI下订单，并且将负载均衡应用于本次EDI项目，实现高可用。 双方达成的方案如下：

1.EDI 平台部署，需考虑数据安全及高可用 2.EDI 平台对接 TI EDI

EDI平台部署方案

知行之桥 EDI 系统的单个实例已经能轻松地满足大多数企业的自动化传输需求，在本次M公司EDI部署过程中，考虑到客户日处理数据量庞大，并且具有长期的数据处理需求，我们的项目经理将把负载均衡以及高可用的共享存储服务以及高可用数据库服务纳入本次EDI部署方案之中，从而实现更高级别的可用性和伸缩性。下图是EDI平台部署方案示例：

edi

出于数据安全考虑，我们的顾问协助客户部署了Nginx服务器。使用Nginx 作为反向代理实现负载均衡，将所有请求平均分发到每台部署EDI的服务器，保证了M公司内网的安全，同时减少内存占用，提高并发能力，实现了高可用并发需求。 如上图所示，应用程序Server1和Server2 表示部署EDI平台的两台服务器，通过共享存储服务，实现EDI平台的配置共享，通过数据库服务实现平台所有交易日志、访问日志的共享。

EDI 平台部署方案达成一致后，结合 TI EDI需求，通过知行之桥EDI平台，实现AS2通信，同时对于EDI国际标准报文格式进行转换，通过 tRFC 连接 SAP 以 IDOC 形式将数据同步到 M 公司的SAP系统。

EDI平台对接方案

1. 传输方式

通过AS2端口实现与 TI EDI的通信。

2. 报文标准

TI 支持的报文标准包括EDIFACT、X12以及RNIF。本次项目M公司选择的是X12标准，基于TI的PO & POC模式，业务层面涉及了以下五种业务单据；

本次EDI项目共使用5种业务报文，如果企业还需采用JIT模式，则需要再加上830物料需求预测以及830R物料需求预测回复等报文。

3. 数据格式转换

将接收到的X12报文通过X12端口转换为EDI XML，再将得到的EDI XML通过XML Map端口进行映射，转换为IDoc XML。通过SAP IDoc端口连接到客户的SAP系统，传输IDoc文件。

知行之桥如何连接 SAP 系统呢？可以参考文章：SAP(IDoc) 端口配置

EDI平台对接方案概览如下图所示：

edi

通过方案概览我们可以很清晰地看到，本次EDI项目中，M公司与TI之间的EDI项目需要完成以下环节：

1. M公司本地部署EDI系统
2. 与TI通过AS2建立EDI连接
3. M公司的EDI系统与SAP系统进行集成
4. M公司的EDI系统与TI的EDI系统之间交换业务文件

项目计划

我们的项目经理会提前根据项目的实际情况安排EDI部署流程和项目周期。通常情况下，由于对接交易伙伴以及EDI项目难易程度的不同，项目周期也各不相同。对接TI的EDI项目，通常情况下，项目周期为两到三个月。项目计划明细如下图所示：

edi

需要注意，与TI进行业务场景测试阶段，是整个EDI项目中时间占比最大的部分。这部分需要完成上文提到的PO&POC模式或者JIT模式的测试。业务场景测试过程短则4-6周，长则需要6-8周。由于这个阶段需要沟通业务场景和业务细节，因此需要进行多方参与。如果企业希望在这个环节加快项目进度，那么需要企业及时跟进项目，多多协调配合才能确保项目高效进行。

项目回顾

在EDI项目实施过程中，为了使业务数据更加切合企业间数据传输需求，我们的顾问根据M公司的需求以及TI EDI项目的特点，对本次EDI项目进行了针对性处理：

预计到货时间和实际到货时间不匹配

预计到货日期与实际到货日期之间会存在时间差，该问题不仅出现在M客户案例中，对于其他客户而言也可能存在这样的问题。如果需要消除这个时间差，获取到实际到货日期，如何在实际项目中处理交期问题呢？有以下两种方案：

需求日期提前

M公司在下单时可以选择将交期提前，这样预计到货时间虽早，但是实际到货时间满足实际需求到货时间。

预计到货日期延迟

M公司在收到TI的发货通知后，将预计到货时间进行处理，加上一段在途或者从中转仓库运输至实际仓库的时间，这样预计到货时间就更加准确了。

数据拆分处理

尽管在EDI规范中对数据进行了严格的要求，但是实际情况远远比预期要更加复杂。比如数据拆分，应该如何处理呢？

例如，供应商传输的XML文件包含一批数据，例如多个订单、多个行项目或多个客户记录时，想要将每个订单/项目/记录从这个“批量”的XML数据中拆分出来。就可以使用知行之桥的Split端口，实现XML文件划分。实现的效果如下图所示：

edi

类似这样的需求几乎每天都在发生，我们在满足客户需求的同时，也在不断地对知行之桥EDI系统的功能进行优化升级。