第三方商城项目对接（2022-11）

项目概述：
作为第三方平台的供应商，进行系统和接口的对接（商品/订单/票/款）
以往项目对方开发为主，我方主动调取；这次反过来。
项目前期：
只有一个接口对接文档（别的什么也没有），deadline已确定
项目中期：
边开发，边联调，边设计，边测试
项目后期：
协调分批上线
问题总结：
1.需要由接口文档返回数据结构反推功能设计（只有接口文档，没有业务流程）
2.以往是以订单纬度进行开票，这次是以商品作为最小颗粒度进行开票
3.消息设计时类型颗粒度的设计（商品上/下架，新增/删除/价格变动有单独的消息类型通知，但是主图/商品名称/属性等的编辑并没有设计单独的消息类型），但是我方系统并没有相对应的功能（比如单独的价格编辑功能用于价格变动的精准消息推送），兼顾我方系统的通用性设计和研发进度，没有进行单独功能设计用于精准消息推送，而是采用了相对模糊的消息推送的方式（比如编辑商品后把相关消息都推送一遍）
4.第三方物流信息的对接（只对接了查询的订阅接口）
a)按快递单收费
b)支持多次订阅
c)支持不同的回调地址
d)一个快递单的订阅以已签收状态为结束
e)已签收订单的也可以订阅
f)由于对接了快递查询，订单或者发票（需要邮递的发票）以查询到的物流状态进行更新（比如已签收的更新状态为已妥投）
5.手动填写造成的问题（票号/物流单号的手动输入）
物流单号的错误问题–对接第三方物流单检验或者支持编辑
票号错误–拆分功能，上传票号和通知第三方拉取分开或者再加入审核流程
6.上线时商品的批量导入处理（这是耽误时间最久的）
不要指望一开始想的那么好让业务方自己手动上传（领导会说那要技术干什么）
不要指望业务方整理的数据质量有多高（类目乱填/甚至价格为零）
7.开票金额与订单和售后单（退换货）的关联处理
开票金额需要减去退货金额
总结：
不要猜测对方怎样怎样，沟通，沟通，还是沟通，有些问题一个电话就解决了！