电子面单架构文档
电子面单架构思路
1、平台维护物流公司信息，配置物流公司与快递鸟对接所需的表单
2、商家中心根据平台设置的表单信息，填写对应参数
3、订单中心，点击打印电子面单，成功打印
难点：快递公司动态表单，每个商家都需要单独根据快递鸟所需的表单进行配置
数据结构
物流公司表(es_logistics_company)
| 字段名 | 提示文字 | 类型 | 长度 | 是否主键 |
|---|---|---|---|---|
| id | id | 整数 | 10 | 是 |
| name | 物流公司名称 | 字符串 | 100 | 否 |
| code | 物流公司代码（圆通-》yuantong） | 字符串 | 100 | 否 |
| is_waybill | 是否支持电子面单 1支持 0不支持 | 短整型 | 1 | 否 |
| kdcode | 快递号，与快递鸟对接所需编号 | 字符串 | 100 | 否 |
| formItems | 电子面单 自定义表单 | 字符串 | 255 | 否 |
店铺物流设置表(es_shop_logistics_setting)
| 字段名 | 提示文字 | 类型 | 长度 | 是否主键 |
|---|---|---|---|---|
| id | id | 整数 | 10 | 是 |
| shop_id | 店铺id | 整数 | 10 | 否 |
| logistics_id | 物流公司id | 整数 | 10 | 否 |
| config | 配置详情 | 字符串 | 255 | 否 |
电子面单领域模型
管理端
KDNForm为动态表单的对象，与快递公司对象多对一关系，用于配置动态的表单
模型
LogiCompanyDO
| 属性 | 说明 | 备注 |
|---|---|---|
| id | id | |
| name | 物流公司名称 | |
| code | 物流公司code | |
| isWaybill | 是否支持电子面单 | 1：支持 0：不支持 |
| kdcode | 快递鸟物流公司code | json格式，由FormItem对象转换json而来 |
FormItem
| 属性 | 说明 | 备注 |
|---|---|---|
| name | 表单名称 | |
| code | 快递鸟 api参数 |
商家端
KDNParams为快递鸟对接api 所需的对象，由于参数名和值完全不确定，所以直接将五个名称的参数封装为一个对象，在与快递鸟对接时，直接传递此对象即可，方便调用。
WaybillManager为电子面单接口，这里有插件化概念，方便日后对接其他电子面单的实现
KDNPlugin为快递鸟对接的完整实现，该类实现了WayBillPlugin电子面单插件接口，以供调度中心调度
模型
ShopLogisticsSetting
| 属性 | 说明 | 备注 |
|---|---|---|
| id | id | |
| shopId | 店铺id | |
| logisticsId | 物流公司id | |
| config | 配置项 | KDNParams对象json值 |
KDNParams
属性无具体意义，是javashop与快递鸟对接的内容，由快递鸟API定义
前后端对接特殊点描述
后台物流公司，电子面单设置
电子面单由于不同的快递需要不同的表单来满足电子面单需求，所以这个地方会有点问题，这里主要定义一下前后端交互的格式
请求格式
这里传递的表单对象为数组
name[0]=账号,code[0]=USERNAME,name[1]=密码,code[1]=PASSWORD 以及其他标准参数
后端响应对象为JSON，大致内容如下
{
xxx:xxx,
xxx:xxx,
formitems:[
{name:'用户名',code'password'},
{name:'用户名1',code'password1'}
]
}
商家中心配置电子面单
商家中心，需要根据电子面单对象响应的formitems对象，动态构建出表单，并且动态提交的字段名，如果有值，还需要进行自动填充。
响应事例
{
setting:[ // 这个对象为空，则不填充，否则，用前端业务填充
key1:value1, // 这个地方的key与下方的formitem中的code相等，更具下方的code来判断如何填充
key2:value2
]
,logistics:[
xxx:xxx,
xxx:xxx,
formitems:[
{name:'用户名',code'password'}
]
]
}