项目背景
由于公司主要业务在欧洲，客户需要使用 EDI 技术进行交易
目前的处理方式：客户提供了 WebEDI 界面，可以接收和上传 EDI 数据
第一次接触 EDI ，请参看 EDI 学习笔记
问题
客户提供了一个 WebEDI系统，这个系统是他们的 EDI 技术服务商开发的，并且没有和我们的 ERP 进行对接。
该系统是一个比较简单的 web 界面，并且操作起来不太友好，需要我们人工定期检查 ，在检查之后还需要手工录入数据到 Odoo ERP 系统，单据状态更新后需要重新录入到 WebEDI 中，需要同时维护 WebEDI 和 Odoo ERP 的数据，效率极低，且容易出错。
目标
- 客户可以通过 EDI 技术，直接使用 EDI 实现下单、获取发货和发票信息
- 我们可以通过 EDI 系统，直接获取订单数据，订单有进展后直接通过 EDI 通知客户
项目架构图
主要需求点
- 客户发送 EDI 数据报文到我们服务器
- 确定 EDI 数据报文格式、规范
- 确定可以接收 EDI 数据报文的通信服务器
- 在服务器上接收并解析报文
- 自动解析报文并映射到 ERP（确定映射规则）
- 确定映射规范和特殊情况的处理应对方法
- 确定 EDI 订单的整体流程
- 和 ERP 系统原有流程结合
- 梳理其中的特殊情况，确定特殊情况的处理方式
- 生成并发送 EDI 报文
- 开票及发货生成EDI报文
- 通过通信服务器（AS2）发送给指定的客户（需要确定报文生成规范）
- 异常情况处理
- 收集异常情况，沟通确定处理方案
- 邮件通知
- 系统日志
- 定期检查
- 其他...
- 系统监控
项目里程碑
- EDI 对接方案评估
- 熟悉 EDI 规范
- 分析客户文档
- 确定报文标准+通信协议及通信服务器
- 多轮需求沟通
- 推进各方协商达成共识
- 确定并输出需求文档
- EDI 解析服务器搭建
- AS2 通信服务器搭建
- Odoo ERP 相关功能模块开发
- QA测试（EDI、AS2、Odoo）
- 培训（文档整理 + 用户培训）
- 用户测试
- 发布上线
- 持续监控、支持 + 收集反馈、闭环
复盘
- 关于服务器选型
- 最初选用 openas2，后来发现了基于 django的 as2 服务器django-pyas2
- openas2 是基于 java 开发，没有可视化界面，部署和调试相对复杂
- 切换为 django-pyas2 后，提升了开发效率
- 反思：服务器选型时，应投入更多时间，全面了解相关项目。本次选型过急，影响了项目进展
- 关于时间评估
- 由于初次接触 EDI，低估了项目难度和时间
- 导致计划紧凑，缩减了部分必要的时间（如选型、评估）
- 后续根据情况进行了重新评估 + 持续调整，逐渐把握了节奏
- 反思：在评估项目的难度和时间时，应该预留处理紧急情况的时间（特别是第一次接触的项目类型），同时需要持续优化，根据情况适当进行合理的调整
总结
- 评估项目时，需要列出可能涉及的技术，划分好各个部分（如：技术准备、了解通信协议、可用的现成工具等），每个部分需要预留足够时间，做充分准备
- 随着项目发展，会出现各种新的问题，需要逐渐优化计划，同时需要提前考虑，尽量预防不必要的问题出现，或提前准备应对方案，及时申请资源解决问题