← 返回
03 独立开发 · 需求到上线 · 2025
物流出单自动化
从商业发票解析到承运商面单与海关申报,中间几十次复制粘贴全部消失。DHL 三项验收全过,FedEx 认证上线。
PythonFastAPISQLiteDHL MyDHL APIFedEx RESTDHL DPS
3/3
DHL 验收用例
已通过
FedEx 认证
2 家
承运商在线
交付与结果
DHL 三项验收通过，FedEx 认证上线
- 我的职责
- 独立完成商业发票解析、承运商接口联调、幂等出单和面单申报流程。
- 数字的范围
- 3/3 指 DHL 三项验收测试；FedEx 认证指系统接口集成的认证上线，不是对个人的推荐，也不是长期零故障保证。
- 公开材料
- 可查看虚构数据的出单后台演示。承运商验收原件涉及账户信息，不在公开站展示。
遇到异常，怎么处理
下面是系统设计中的处理路径，展示方案的边界与取舍。
- 承运商请求超时
- 标记为 unknown，不自动重试；先在承运商侧核对是否已产生运单。
- 运单成功，本地落库失败
- 保留待补录记录，不把已经成立的外部运单当作已回滚。
要解决什么
出一票货,业务要把发票上的信息誊到承运商系统里,再誊一遍到申报系统。慢,而且抄错就是实打实的损失。
更麻烦的是重复出单:点两次、或者网络超时后重试,就可能真的产生两张运单 —— 那是要付钱的。
- 01 解析商业发票 支持 xls / xlsx 与文本型 PDF
- 02 校对与补全 收发件人、明细、参数逐项确认
- 03 询价比价 跨承运商比服务档次与时效
- 04 幂等出单 键先落库再调用,未知状态不重试
- 05 面单与申报 面单落地,自动进海关申报队列
- 3/3
- DHL 验收用例
- 已通过
- FedEx 认证
- 2 家
- 承运商在线
高亮的一步是整套系统的要害 —— 下面每一区都在讲它为什么这样定。
怎么搭的
每一层都是一次真实的取舍。图里高亮的那层,是整套系统的要害 —— 它错了,别的做得再好也没用。
- 解析商业发票:支持 xls / xlsx 与文本型 PDF
- 校对与补全:收发件人、明细、参数逐项确认
- 询价比价:跨承运商比服务档次与时效
- 幂等出单:键先落库再调用,未知状态不重试
- 面单与申报:面单落地,自动进海关申报队列
为什么这么选
幂等键什么时候写?
调承运商之前
调完再写,一旦在中间崩掉就没有任何记录 —— 重试会真的出第二张单。先写后调,最坏情况是留下一条"状态未知"待人工核对,不会多花钱。
承运商返回超时怎么办?
标记 unknown,不自动重试
超时不等于失败,单可能已经出了。自动重试是在赌,而赌错要赔钱。交人工去承运商后台核一眼,几十秒的事。
本地落库失败要不要回滚已成功的运单?
不回滚
运单在承运商那边已经成立,本地回滚改变不了这个事实,只会让两边账对不上。宁可留一条待补录。
系统界面
本地演示实例 + 确定性演示数据,客户信息全部虚构
