先弄清结果
扫入本车，不等于已经生成送货单
- 确定车次和部门
确认车辆、司机、出货区；流程只使用交货部门。
- 扫码加入本车
按 PDA 查正式对象，得到客户、部门、批次、数量等。
- 复核并生成单据
按客户＋部门＋车次分组，写所绑环境的单头和明细。
- 送审与电脑审核
手机按状态送审/反送审；电脑审核。结存由旧 ERP 处理。
出货从哪个部门发，不由“成品仓”“包装部”等名字决定。只要是本功能所绑流程的合法交货部门，并满足本账套 PDA 和业务规则，就按配置执行。
准备资料
先准备能证明“这箱货是谁、在哪里”的资料
出货流程与送货单环境
核对真实交货部门、送货单单头/明细、主键关系、编号与检查器。记录本厂单据在什么状态影响结存。
做到这一步应看到：知道从哪个部门出、生成什么正式单据，而不只是看到一个“出货”名字。
现场会扫的条码样例
分别准备作业 WorkID、旧包装箱号或本厂实际采用的码。注明它们各自指向的正式对象及可出货状态。
做到这一步应看到：每种码都能查出客户、部门、批次和数量，不能只证明正则匹配。
单头必填项与人员
核对客户、日期、结算方式、送货方式、车辆等实际需要的来源；准备装车员和单据处理账号。
做到这一步应看到：没有默认值的必选项有合法候选；不用最近一张历史单替当前单补值。
按配置专家操作
出货按这条顺序配
选固定“出货” → 基础绑定
绑定本厂真实工作流程和送货单数据环境，核对流程交货部门后保存。出货不使用接收部门、性质或处理对策。
做到这一步应看到：流程交货部门正是允许从中发货的部门。
使用范围 → 授权装车与操作人员
按真实账号、手机角色或工位授权并保存；核对账号身份和所选 API。
做到这一步应看到：目标账号可用该流程；无权账号不能进入操作。
字段设置 → 分清单头和明细
明确客户、部门、车次等单头来源，以及批号、货品、数量、重量等明细来源；补齐其他必填列，配置允许修改和读回。
做到这一步应看到：正式表、父子键及主键明确，扫码结果能完整写入并读回。
扫码规则 → 分两次保存
先保存 PDA 表单，再将该表单的实际输出接到手机字段并单独保存。正则、SQL、ERP 映射和防重扫仍在旧 ERP 维护。
做到这一步应看到：各种现场码都查到正确正式对象，不混用作业码与旧箱号。
体检启用 → 用一车测试货闭环
修复阻断后保存启用。从扫码、撤下、本车复核到生成送货单走完，再核对 ERP。出货没有生产作业标签输出页。
做到这一步应看到：单据分组、数量、状态及结存处理均符合客户原有规则。
扫码专项
都是一串码，指向的对象可能完全不同
| 码或配置 | 应该核对什么 | 不要混淆 |
|---|---|---|
| 生产作业 WorkID | 下游 PDA 明确查询生产作业事实并输出所需字段；作业码、批号与当前部门范围保持可追溯。 | 作业码不是旧生产包装表的箱号，也不是交接 RID。 |
| 旧包装箱号 | 采用对应 PDA 码类（如 PackIDRegex）及旧包装对象查询，核对状态和防重扫。 | 不能把一条查询旧箱号的 SQL 拿来扫新作业码。 |
| Regex | 输入外形、多个规则的命中歧义。 | 识别式匹配不代表数据库里有货。 |
| SQLSELECT / 参数 | 原码 @BarCode、当前部门等条件是否查对正式对象。 | 不能删部门或状态条件来让任何标签都能通过。 |
| 输出与重扫 | MAPPINGCOLUMNS 实际输出、手机字段映射、FINDTYPE 及业务状态。 | 扫码带回数量不等于已经生成送货单；重复表现要按规则验。 |
一车为什么会有多张单
分单键是：客户＋部门＋车次
示例：同一车次里有三组货
客户甲／部门 A 两箱，客户甲／部门 B 一箱，客户乙／部门 A 一箱。按客户＋部门＋车次，应该形成三组，不能因为都是同一辆车就合成一张。
客户甲／部门 A 的两箱满足同组条件，但各箱的码、批次和数量仍要可追溯。换一个车次后，即使客户和部门一样，也不是这一组。
- 先看客户
这件货属于哪位客户？缺客户就先修扫码/来源。
- 再看部门
从哪个合法交货部门出？同客户不同部门分开。
- 再看车次
是否本次装车？同车牌不代表永远同一车次。
- 核对单头与明细
组别、箱数、数量、重量、正式业务键都对应。
手机侧验证
用一车实物核对扫码、复核和生成三个阶段
图中为装车页示意。实际接受哪种码、从哪个部门出、怎样处理重复，以当前功能的流程和 PDA 配置为准。
- 1本车资料与出货区
- 2扫码或手输，核对带回结果
- 3撤下当前车次中的错误箱
- 4本车清单：逐箱与分组核对
- 5装车完成后还有生成前复核
- 1
确认当前车次
先看车辆、司机、出货区及部门，再开始扫码。现场人员切车次时不要把上一车的结果当成本车。
- 2
正确码、重复码和错误码都试
既用相机扫，也手输同一码。检查对象、客户、部门、数量；错误码或范围外数据应准确提示。
- 3
复核后生成送货单
本车清单核对无误，装车完成后再检查生成前分组，确认才生成。不要把“扫入本车”的提示当成生成成功。
- 4
按正式键到 ERP 查
逐张查单头、明细、车次、批号/码、数量、重量与状态；再验证送审和电脑审核。
完成结果：同一车的每张单都可追溯，客户和部门没有错误合并。
影响范围必须分清
撤下、放弃本车、作废草稿不是同一个动作
| 动作 | 主要影响 | 验证重点 |
|---|---|---|
| 撤下本箱 | 从当前装车记录中移除该箱，不删除原生产作业/包装记录。 | 本车数量变化，原码指向的业务事实仍存在。 |
| 放弃本车 | 处理尚未生成正式送货单的当前装车草稿。 | 先确认没有需要保留的装车内容；不当成作废已生成单据。 |
| 作废关联草稿 | 已生成送货单后按正式草稿状态处理关联单据。 | 检查器和旧 ERP 状态限制生效，关联单据结果核对完整。 |
| 送审 / 反送审 | 手机发起送审，未审核时可按正式流程反送审回草稿。 | 审核和反审核在电脑端；已审核不当作普通草稿改。 |
出货故障速查
从扫不进、生成失败到分错单
码能识别，却提示没查到货
- 先分清
- 识别式通过了，但 SQL 查询的对象、原码参数、部门或状态条件不满足。
- 这样处理
- 先分清 WorkID 与旧包装箱号，再查本功能 PDA 的 SQLSELECT 和参数；核对货是否仍处于可出货状态。
- 改后确认
- 查到正确对象，范围外或已处理对象仍按规则拒绝。
同一标签在交接能扫，在出货不能扫
- 先分清
- 两个功能各自绑定 PDA，交接识别成功不代表出货也配置了。
- 这样处理
- 在出货扫码页单独确认码类、查询与手机输出；不要改上游标签前缀来迁就错误查询。
- 改后确认
- 按出货规则得到正确客户、部门、批次和数量。
装车正常，生成时报客户/部门/数量为空
- 先分清
- 扫码或复核显示有值，但正式输出映射、单头/明细写入可能未接通。
- 这样处理
- 从 PDA 实际输出到手机字段，再到 ERP 目标列逐段核对；查 ERP 补值、父子关系和必填列。
- 改后确认
- 生成后的单头明细都完整，不靠固定客户/部门补空。
同车货分成多张单，是不是重复生成？
- 先分清
- 客户或部门不同本就需要分组；也可能发生了真正重复请求。
- 这样处理
- 按客户＋部门＋车次核对每张单的业务键和明细。不同时属于同组三键的，不是仅凭数量判断的重复。
- 改后确认
- 每组与预期对应；同一组没有多出不明业务单。
生成超时，要不要再扫一车？
- 先分清
- 超时只说明结果尚未确认，可能已生成。
- 这样处理
- 先查询当前车次关联单据和正式业务键，确认结果后按页面提供的继续/恢复路径处理；不新建一车来赌重试。
- 改后确认
- 原车次与关联单据一致，没有重复工作量或重复扣减。
库存不足或负库存检查拒绝
- 先分清
- 输入、部门结存或本账套检查器规则不满足。
- 这样处理
- 核对正式部门结存与本车数量，再看检查器名称和原因。确为业务规则问题才调整配置，不直接删库存条件。
- 改后确认
- 允许的出货成功，不允许的仍被拒绝；结存按正式触发器维护。
送货单打印机在配置专家哪里设？
- 先分清
- 配置专家的标签输出属于生产作业蓝牙标签，不是正式送货单打印。
- 这样处理
- 正式送货单回 ERP 电脑端审核和打印；不要建立移动打印站、队列或把作业模板当送货单模板。
- 改后确认
- 两种打印的业务对象与使用位置清楚。
出货交付验收
既验一箱，也验混合客户与部门
用可回滚测试车次验证。验收记录需关联车次、原码、送货单号与对应部门，数量之外也要核对身份和状态。
- 1. 权限与部门
目标账号可用；合法交货部门可选；没有固定仓库或样本部门兜底。
- 2. 每种码类
实际采用的 WorkID/旧箱码分别通过，手输与扫码一致，重复与错误码按规则处理。
- 3. 分单
同客户同部门同车次归同组；不同客户、部门或车次不会误合并。
- 4. 正式写入
单头、明细、关联键、数量、重量、默认值和读回正确，结存按正式规则变化。
- 5. 状态操作
撤下、放弃、生成、送审、反送审、作废各验影响范围；审核仍在电脑端。
- 6. 失败恢复
超时先查结果，检查器失败明确提示；没有半组遗留或重复业务，按正式流程清理测试。