场景：物流公司派车辆去的仓储公司的仓库中提货。

一、业务流程

当买卖双方产生交易开始：

库存在仓储公司仓库中属于卖家的存货将由物流公司负责配送，物流公司派送车辆进入仓库中提货出库再送到由买家指定的地点完成运输。
流程中仓库只听从货主的指令即交易中的卖家，卖家负责将物流信息包含：物流公司名称、车辆的数量型号载重等车辆数据、司机姓名身份证号手机号码等个人信息，提货日期；可能还会包括驾驶证件信息、运输资质信息传达给仓储公司。
物流公司听从托运方的指令，托运方可以是卖家，也可以是买家。托运方告诉物流公司相关信息：仓储公司名称，仓库地址联系方式；托运商品名称、数量、车辆及司机资质要求；指定的配送地址联系方式等信息。
物流公司车辆到达仓库出示个人证件和资质证件，仓库核实后予以放行入库。
传达给仓储公司及物流公司的指令由买卖双发达成一致。

做一个简单的关系图，假设托运方是买家：

好了，核心和业务目的大家了解了，下面开始讲讲分支场景：

1. 卖家（货主）向仓储公司发送提货指令及回执

货主向仓储公司（一般是业务中心）发起提货申请：货品名称、数量、提货日期、司机车辆信息。
业务中心根据仓库库区业务情况给出回执，一般是确认或调整日期，少数情况业务中需与库区沟通确认。
提货后，业务中心主动向货主回执确认提货成功，一般可能会在与货主企业的系统对接、短信、人工微信或者业务员电话回执等方式。

2. 仓储公司业务中心与仓库库区之间的交互

业务中心接到货主的申请，需要确认库区的情况。不过一般来说业务中心在日常的工作中对仓库的情况比较了解，仓库也每日会汇报库区的工作与状况。所有基本上业务中心接到申请以后会向库区发送指令，指令可以在内部ERP系统中发送，同时传真一份纸质的提货通知。
库区在提货成功以后会向业务中心回执确认以及定时交付提货单据以供业务和账务留档复核。

3. 司机去仓库库区提货的入库及出库

司机到达库区与接待中心客服接待人员之间的交涉：出示证件单据，填写表单，签字盖章等。
司机进入库区过磅称重，到达指定地区装货。
司机完成装货后过磅称重，与库区客服人员双发签字完成单据出库。

4. 过磅及装货场景

车辆驶入库区在地磅系统称重，过磅系统工作人员合适单据证件，在单据中标明空车重量并签字。
车辆进入装货区域，工作人员核实予以装货并监督装货流程。
装货完毕车辆再经过地磅系统称重，然后双双确认签字后车辆离开库区。

由此，整个业务流程就清晰了，出货流程大致是这样。按照这个逻辑逆向入库流程基本也是这样，只是出入的单据有所不同以及地磅记录顺序反过来就可以了。

这整个流程可以看出大部分都在线下进行，现在需要把这部分内容集成到交易平台中。

二、前置条件

物流系统：提供在线找物流服务、跟踪物流。
已对接仓储公司ERP，用户在线申请提/卸货，用户查看/管理自己的库存。

三、需求纲要

基于订单和物流单发起提货流程。
货主向仓储公司发起提货，并提交物流信息及相关证件、单据。
仓储公司回执托运方。
司机提货流程：仓储接待中心–地磅系统—装货—出库。
非交易情况下货主的出入库申请。

四、产品架构设计

系统结构：平台下的订单、物流系统，对接仓储公司数据的OMS系统

基于订单的买/卖家、物流公司与仓储公司的交互

提货流程

五、产品的数据库表单设计

看一下已有数据表单及与物流仓储出入库相关字段。

1. 订单表

物流公司、物流单号、仓储公司、仓库地址、数量、出入库数量、剩余数量、损耗。

2. 物流单表

订单号、托运方、买方公司、出库仓储公司及仓库地址、入库仓储公司及地址；运次信息：车辆、司机信息、车次对应数量、地磅数据、耗损、出入时间。

3. 需要新增的表单：出入库表

这个表单部分字段可能与订单和物流单表重复，但考虑到这条支线的流程的唯一性以及方便当订单出现纠纷时更容易复核，所以有必要创建该表单。

表单记录字段：

出库申请：账号/人员
申请时间
审批回执
审批人/账号、审批时间
出库通知：出库通知人、时间
车辆司机信息；车次数量信息、地磅数据
司机签字信息

五、结尾

基于以上可以进入产品具体的设计，因为这里主要讲的是正向流程，真实交易中会出现逆向以及错误终止的情况且频次不低。所以具体设计时必须考虑到多种状况的可能并最终要形成产品的闭环。

B端比较讲究流程的实现，产品人员最重要的就是把业务流程梳理清楚。

物流IT圈

大宗商品仓储系统中，车辆出入库的集成设计