# PDA手持机如何实现与现有系统的无缝集成？

原文：[https://www.rfidpda.cn/news/wenti/2775.html](https://www.rfidpda.cn/news/wenti/2775.html)

现场人员用PDA扫完码，屏幕显示“成功”，回到办公室却发现ERP里没有这笔记录。也有另一种情况：系统里确实有记录，但数量重复、库位不对，最后还得人工对账。碰到这

现场人员用PDA扫完码，屏幕显示“成功”，回到办公室却发现ERP里没有这笔记录。也有另一种情况：系统里确实有记录，但数量重复、库位不对，最后还得人工对账。碰到这些问题，先别急着换设备。PDA负责采集，能不能把结果准确写进现有系统，取决于业务规则、数据字段、接口和异常处理是否事先约定清楚。

如果你正准备对接，先做一个判断：现有系统是否有可用的接口，供应商是否允许外部程序提交业务数据？这会决定后面采用实时接口、文件导入，还是先走人工审核的过渡方案。所谓“无缝”，在实际验收时应当说得更具体：工作人员少做重复录入，系统能识别每笔操作，并能查到成功、失败和处理过程。

![PDA手持机对接现有系统：字段映射，离线补传，验收测试](https://www.rfidpda.cn/uploads/allimg/20261022/114030-61032b54.jpg)

## 先选一笔业务，不要一上来接所有流程

把最常用、最容易核对的一笔业务作为试点，比如“按采购单收货并上架”。画出它现在怎么走：订单从哪里来，谁核对实物，什么时候允许入库，ERP或仓储系统中哪一步才算完成。若只问“PDA能否对接ERP”，双方往往会给出“能”，但不知道究竟要接哪个动作。

启动前建议把下面几件事找齐：

- 现有系统的负责人和供应商对接人，以及测试环境、接口或导入说明。没有测试环境，也至少要约定不会改动正式库存的试验方式。
- 一张真实业务单据的字段样本，隐去客户和价格等敏感信息即可；还要有商品编码、条码、批次、库位等基础资料。这里的“基础资料”是系统识别商品和位置所用的固定信息。
- 现场网络情况、扫码标签类型、操作人员权限，以及网络断开时能否暂停作业。
- 谁有权确认异常：多扫、少扫、错码、无条码、单据已关闭，都不能只交给设备自行决定。

## 第一步：把“扫到什么”翻译成系统认识的字段

拿收货举例，PDA扫到商品条码，并不等于系统已经知道这批货属于哪张采购单、哪个货主、哪个批次、哪个库位。先做一张字段对照表，至少写清“PDA显示什么、从哪里取得、提交给系统哪个字段、是否必填、错了由谁改”。同一条码可能对应不同包装单位，系统商品编码也可能与外箱码不同，这些要在现场拿样品核对，不能靠猜。

<table><thead><tr><th>现场要确认的事</th><th>对接时要落实的规则</th></tr></thead><tbody><tr><td>正在处理哪张单</td><td>单号由系统下发，PDA扫描或选择后锁定，不允许把别的单据混进来。</td></tr><tr><td>扫到的是哪种货</td><td>明确条码与商品、规格、单位的对应关系；一物多码和同码多包装要有转换规则。</td></tr><tr><td>实际收了多少</td><td>区分“扫一次算一件”与“扫一箱再录箱内数量”；超收时按现有审批规则处理。</td></tr><tr><td>放到了哪里</td><td>库位在系统里必须存在且可用；收货暂存区和正式库位不要混写。</td></tr><tr><td>本次操作是谁做的</td><td>记录账号、设备、操作时间及业务流水号，方便追查和纠错。</td></tr></tbody></table>

字段对照完成后，请系统负责人拿两三张有代表性的单据逐项确认。能被扫描并不代表数据能被系统接受，尤其要核对单位换算、批次有效期、货主和单据状态。

![先把现场采集字段逐项对应到现有系统。](https://www.rfidpda.cn/uploads/allimg/20261022/114030-d3cb074a.jpg)

先把现场采集字段逐项对应到现有系统。

## 第二步：定清楚谁说了算，以及“成功”是什么意思

现有ERP、WMS或生产系统通常已经保存订单和库存。要先指定每类数据的权威来源：订单、商品资料、库位从哪里下发；现场实收数量由谁产生；库存何时更新。PDA不宜自己保留一套“最终库存”，再事后与系统猜着合并。

一次操作至少要区分三个状态：**已采集**，表示PDA记下了扫码；**已提交**，表示数据送到了服务端；**已确认**，表示现有系统接受并生成对应业务结果。只有第三个状态才能作为业务完成的依据。若系统拒绝，比如单据已关闭，应在PDA上说清原因和下一步，不要只显示笼统的“上传失败”。

还要为每笔提交生成不会重复的业务流水号。同一条记录在网络抖动后再次发送，系统应能识别并返回原结果，避免收货数量翻倍。这种“重复发送也只记一次”的处理叫幂等。接口提供方需要约定由谁校验流水号，以及重复提交时返回什么。

## 第三步：按现有系统能力选对接方式

如果系统提供受支持的接口，优先请系统供应商给出接口说明、测试账号和错误码。接口可以理解为两套软件交换数据的约定；需要写清请求字段、返回结果、鉴权方式和版本。用统一文档记录这些约定，后面改字段才不会只靠口头通知；<a href="https://spec.openapis.org/oas/" rel="noopener noreferrer nofollow">OpenAPI规范</a>可作为描述HTTP接口的一种参考格式。

如果没有写入接口，但支持规范的数据导入，先做“系统导出任务—PDA采集—审核后导入结果”的闭环。文件中要保留原单号、业务流水号和错误回执；导入失败的记录单独列出，不能把整个文件标为成功。导入有时间差，应提前告诉现场人员什么时候可以继续下一个依赖库存的动作。

如果老系统连稳定导入都做不到，应先让PDA承担扫码核对、留痕和生成待审核清单，由有权限的人员按原系统流程录入。此时目标是减少抄错和漏记，不能宣传为库存实时同步。直接写现有系统数据库看似省事，却容易绕过它的校验、审批和日志，除非系统供应商明确提供并负责维护这种方式。

## 第四步：让现场页面按业务顺序走

页面不必堆很多字段。先选任务，再扫实物或位置，随后显示系统识别出的名称、规格、单位和应收数量，最后让操作员确认差异。扫错码时立即拦住，比等整单提交后再让人回忆哪一件扫错更容易处理。

网络不稳定的现场，要事先决定能否离线。如果允许离线，PDA应明确显示“待上传”，记录原始扫码时间和流水号；恢复网络后逐笔提交，并保留失败清单供人处理。若业务要求即时占库存、锁序列号或防止重复领用，就不要默许离线继续办完业务。设备端还应限制账号权限，退出或换班时及时交接，避免下一人的操作记在前一人名下。

## 第五步：用异常单据验收，不只演示顺畅流程

先在测试环境跑一张正常单，检查PDA、接口回执、现有系统记录三处的单号、商品、数量、批次和库位是否一致。随后再测：重复扫码、同一提交重发、无效条码、单据关闭、超量、网络中断后恢复、换班登录、撤销和修改。每个测试都要留下“预期结果—实际结果—处理人”。

可以把试点完成标准定为：操作员不必再抄一次同样的数据；每笔扫码都能查到对应单据和处理状态；系统拒绝时能准确提示并由指定人员处理；重复提交不会产生重复业务；抽查实物、PDA记录和现有系统结果一致。试运行期间保留原流程的复核口径，确认差异如何纠正后再逐步扩大到更多单据和岗位。

![网络恢复后按原流水号补传并逐笔查结果。](https://www.rfidpda.cn/uploads/allimg/20261022/114029-b36431bc.jpg)

网络恢复后按原流水号补传并逐笔查结果。

## 出了问题先从哪里查

<table><thead><tr><th>看到的现象</th><th>先检查什么</th><th>下一步</th></tr></thead><tbody><tr><td>PDA显示已扫，系统没有记录</td><td>看状态是否只是“待上传”或“已提交”，查业务流水号和接口回执。</td><td>网络恢复后按原流水号补传；若系统拒绝，按错误原因修正，不手工重复建单。</td></tr><tr><td>数量多了一倍</td><td>查是否重复扫码、单位换算错误，或重试被系统当成新业务。</td><td>先暂停该流程，核对原单，再让接口方修正重复提交规则。</td></tr><tr><td>能扫到条码却找不到商品</td><td>核对条码、商品编码、包装单位是否在基础资料里正确关联。</td><td>由资料维护人改映射，再用同一实物复测。</td></tr><tr><td>一部分单据成功，一部分失败</td><td>比较失败单据的状态、批次、库位、权限和必填字段。</td><td>按错误类型分组修正，逐笔确认系统最终是否接收。</td></tr></tbody></table>

对接方案最终要交付的，不只是一个能扫码的安装包，还应有字段对照、接口或导入规则、异常处理人、测试记录和上线后的查询入口。以后系统升级时，这些资料能帮助你判断是设备、网络、业务规则还是接口发生了变化。


封面：/uploads/allimg/20261022/114030-61032b54.jpg
