方案概览：无人值守不是装个摄像头，而是把「谁来过磅、拉什么、算多少钱」变成一条自动链
一辆车从进厂到出厂，要经过预约、排队、门禁、上磅、品种确认、化验、结算、放行八件事。传统做法是司磅员在磅房里逐车问、逐车填，一天两百车就是两百次手工录入，白天排队堵门，夜里没人守磅。无人值守把这条链交给系统：司机提前预约，到场刷卡或识别车牌，系统自己找到那张单、自己取重、自己算价、自己放行，人只在异常时介入。
判断一套系统值不值，不看它会不会自动抬杆，而看三件事：预约单能不能落到具体车辆与具体品种；拔掉网线还能不能照常过磅；算出来的数字能不能和 ERP、财务对上。这三件缺一件，所谓的无人值守最后都会退回「司机打电话叫人」。
本页按「系统由什么组成、车怎么过磅、异常怎么防、现场怎么落」的顺序写，适用于煤炭、砂石骨料、水泥、粮食收储、化工、废钢回收、混凝土搅拌站等有地磅的场地。咨询电话与微信同为 15910090001。
方案视频
三段视频分别对应现场过磅实拍、预约派车与后台配置、磅单到对账的全过程，各在三分钟以内。视频未上线时下方为占位区，正文照常阅读。
现场一次无人值守过磅
车牌识别触发、停稳取重、语音报净重、道闸放行，全程司机不下车。
预约单怎么建、怎么派车
内部预约、供应商端与司机端派单，车辆六个状态在后台实时可查。
一张磅单从称重到对账
称重记录、扣量扣价、可提货金额报表，以及如何生成 ERP 凭证。
一、核心特色：六件事决定这套系统能不能用三年
地磅系统不难在「称一次重」，难在三年里一直称得准、对得上、换人也能维护。下面六条是可以逐项核对的事实，选型时按这六条问，答不清楚的先放一放。
多 ERP 平台对接
支持 YS、U9、BIP、U8C、T+C 等主流平台，自建档案与来源单据，采购订单、销售订单可直接取价，理论上可对接各种 ERP，不必为了对接去改 ERP 的库表。
独立数据库架构
全新架构、独立数据库，采用 MySQL，支持 Windows 与 CentOS 部署，符合信创环境要求；称重数据在自己的库里，升级或更换 ERP 不受牵连。
在线 / 离线双模式
网络正常时在线过磅、数据实时上传；断网时本地库继续称重、继续打印磅单，网络恢复后按时间顺序补传，不重号、不重复结算，多场地多机构互不影响。
有人 / 无人可切换
同一套程序支持有人值守与无人值守，可按磅点、按班次、按时段切换。固定客户走无人通道，临时车走人工通道，不用买两套软件、两套数据。
多类型称重过磅
采购、销售、调拨、材料出库、成品入库、退货等多类型称重，支持订单取价、价格本与手工输入价格（改价留痕），混装业务也能按品种分别计量。
移动端多端协同
货主端、供应商端、司机端三类微信小程序，预约、派车、排队与进度全程可视，司机不用再打电话问「排到哪了」，采购也不用挨个催。
这六条里最容易被话术盖过去的是「离线」。真正的离线不是「断网还能存一条记录」，而是断网期间门禁、排队、取重、打印磅单、扣量规则全都照常跑，恢复后还能按时间顺序补传。验收时把网线拔掉跑一天，比看十页 PPT 有效。
二、功能模块：从进厂到放行的六块
六块可以整套上，也可以先上称重与门禁、后补化验与排队。先上哪块，取决于现在最疼的是「排队堵门」还是「月底对不上账」。
地磅称重
有人 / 无人值守、多类型过磅、来源单据关联、订单取价与价格隐藏；取重瞬间抓拍，磅单与照片绑定，事后可查。
进出场门禁
车牌识别抬杆，与预约单联动；无预约车辆不予放行或转人工登记，避免外来车插队、场内车数失控。
排队叫号
按品种、按磅点、按预约时段排队，大屏与语音叫号，待检区与磅台分离，减少场内拥堵与插队争执。
化验管理
化验指标与指标集维护、存货绑定，化验单支持扣量或扣价，化验结果直接带入本次结算，不再二次录入。
品种确认与放料
装卸货确认、质检划价、放料控制，装车前确认品种与批次，防止「报的是高料、拉的是低料」。
收款与通知
微信、支付宝、网银收款登记，短信通知货主与司机，自动打印磅单与条码标签，减少磅房窗口的人工核对。
| 现场常见的疼 | 对应模块 | 上了之后的变化 |
|---|---|---|
| 车堵到厂门外 | 预约派车 + 排队叫号 | 按时段分流，场内同时在册车数可控，门口不再排长队 |
| 拉错品种、混料 | 品种确认 + 放料控制 | 装车前确认，磅单记录品种与批次，事后能追到哪一车 |
| 现场议价、看价改价 | 价格隐藏 + 字段级权限 | 司机端只显示净重或金额，改价必须走审批并留痕 |
| 月底和供应商对不上 | 称重记录 + 可提货金额报表 | 一车一单，按单位与品种汇总，差额能定位到具体车次 |
不建议一上来就全模块铺开。先把「称重 + 门禁 + 预约」跑顺，让每一车都有单可依，再上化验与排队 —— 顺序颠倒的话，化验和排队都在为一张不存在的预约单服务。
三、有人值守与无人值守怎么选
无人值守不是「完全没人」，而是「人不在磅房里」。两种模式的差别不在功能多少，而在异常由谁处理、多久处理。
| 对比项 | 有人值守 | 无人值守 |
|---|---|---|
| 触发方式 | 司磅员目视确认车辆上磅，手工选择往来单位、品种、业务类型后取重 | 车牌识别、二维码扫码、IC 刷卡自动触发，系统匹配预约单后取重 |
| 人员配置 | 每班一至两人常驻磅房，夜间与节假日要加班 | 磅房无人，设一名远程值守处理异常与放行审批 |
| 单车耗时 | 含录入与核对，通常一到两分钟 | 停稳即取重，通常半分钟以内 |
| 适合场景 | 车少、品种杂、临时车多、结算规则常变 | 车多、品种固定、以预约单为主、夜间也要过磅 |
| 主要风险 | 人情秤、手工改数、夜班疲劳漏记 | 车牌污损、无预约车到场、异常需远程介入 |
多数企业最后落在混合模式：白天高峰留人盯异常，夜间与节假日切无人；固定客户走无人通道，临时车走人工通道。这套组合在同一套系统里按磅点、按时段配置即可，数据仍在同一个库里，报表不用合并两套账。
切无人之前先算一笔账：一天多少车、夜间多少车、一台磅配几个司磅员、一年人力成本多少。车少而杂的场地，无人值守省下的钱可能抵不过异常处理的人力；车多且固定的场地，半年到一年就能回本。
四、一次无人值守过磅的完整流程
下面是无人值守下一次过磅的动作序列。每一步都会在后台留下时间戳与操作人，出问题时不用靠回忆。
- 预约建单：货主或供应商在小程序建预约单，填写车牌、品种、计划数量与到厂时段；内部人员用内部版建单，关联合同或生产计划。
- 到场识别：车辆到厂，门禁相机识别车牌，系统校验当日是否有有效预约；无预约转人工登记，登记后才放行。
- 排队叫号：按品种与磅点自动排号，大屏与语音提示；车辆在待检区等待，不占用磅台。
- 上磅取重：车辆停稳、红外对射确认整车在磅、无人下车，系统取重并抓拍车头与车厢两张照片。
- 品种与质量确认：按需做装卸货确认或化验，化验单的扣量与扣价结果直接带入本次称重。
- 结算与打印：按订单或价格本算金额，自动打印磅单与条码标签，短信通知货主与司机。
- 放行与二次过磅：门禁抬杆记录出场时间；空车回皮时自动匹配同一车次，算出净重。
- 上传与对账：数据实时上传或断网后补传，形成称重记录与可提货金额报表，按需生成 ERP 凭证。
二次过磅最容易出错：重车与空车要靠「预约单 + 车牌 + 时间窗」三者同时匹配。只靠车牌，同一车当天多次往返就会错配；只靠人工选单，又退回有人值守。这条匹配规则要在实施时写清楚，并在测试里专门跑一遍同车多趟的场景。
五、预约派车与移动端协同
无人值守的前提是「车来之前，单已经在了」。预约做不好，系统只能识别出一辆没有单的车，最后还是要人来处理。
内部预约
内部基础版与增强版建单，按合同、按库存、按生产计划派车，内部业务不用在两个系统之间抄一遍。
外部派车
供应商端自主派车、客户端查看进度、司机端接单改期，三方看到的是同一张单，改一处三处同步。
车辆进度
预约、到场、排队、过磅、化验、放行六个状态实时可见，采购与货主不用再挨个打电话催问。
远程监控
磅房画面、磅台状态、门禁与排队异常同屏显示，异常自动推送到值班手机，无人磅房也能盯着。
预约时段要按磅点产能设上限，不是「随便填个时间」。一个磅点一小时能过多少车是物理上限，预约不设上限，等于把拥堵从磅房搬到厂门口。
六、化验、结算与报表
称重解决「多少吨」，化验解决「值多少钱」。两者不打通，结算就得靠人拿计算器对，一对就是半天，还容易对错。
化验指标（水分、灰分、热值、含杂率等）与指标集按品种绑定，同一品种对不同供应商可以挂不同指标集；化验单录入后按约定的扣量或扣价规则算出结算量或结算价，直接带入磅单，不需要第二次录入。
| 报表 / 单据 | 用来做什么 | 口径要点 |
|---|---|---|
| 称重记录查询 | 按车、按单位、按品种查每一笔过磅明细 | 含毛重、皮重、净重、扣量、单价、金额与两张抓拍 |
| 可提货金额报表 | 看供应商当期可提货额度与已提金额 | 与合同、预付款挂钩，超额预警 |
| 分组汇总查询 | 按单位、品种、时间段汇总吨数与金额 | 与明细同一口径，避免两张表两个数 |
| 运输任务计划单 | 计划量与已完成量对比，安排次日运力 | 支持按日、按周、按月排产 |
| 收款单与称重补录 | 收款登记、漏单补录与异常修正 | 补录必须记录操作人、原因与改前改后 |
报表最容易失信的地方是「同一个数字在两张表里不一样」。做法是把净重、扣量、结算量的计算收敛成一条链路，所有报表都从这条链路取数，而不是各表各算一遍。对账时客户只认一个数，多一个版本就要多解释一次。
七、防作弊、权限与数据安全
地磅作弊的手段不多，但每一种都很贵：压磅、换车、遥控器、重复过磅、里应外合改单价。技术能挡住大部分，剩下的小部分要靠权限与流程。
全程抓拍留证
取重瞬间抓拍车头与车厢，照片与磅单绑定；争议时调出照片，比翻记录快得多。
红外与道闸联动
车辆未完全上磅、压边、多车同时在磅时不予取重，从物理条件上排除压磅与搭磅。
车牌与预约双校验
车牌、预约单、品种三者不一致时锁定并转人工，避免换车过磅与套牌过磅。
价格与金额分离
司磅端可隐藏单价，只显示净重或金额；现场看不到价格，议价与改价的空间就小。
关键操作留痕
改价、补录、作废、重打磅单均记录操作人、时间与改前改后，审计时按时间线还原。
四层权限体系
机构权限、功能权限、数据范围权限、字段级权限，多组织架构下各看各的车与各算各的账。
数据安全另外三件事：数据库每天自动备份并定期做恢复演练；账号不共用，离职即停用；对外只开必要端口，远程维护走审批。这三点写进交付清单，比事后补要省事。
权限设计有个简单的判断标准：一个刚入职的司磅员，用他自己的账号，能不能把一笔已经结算的单改掉。能，说明权限没设计；不能，但可以借别人的账号改，说明流程没设计。
八、硬件清单、实施步骤与周期
硬件按「一个磅点」列，多磅点按数量叠加。已有设备能用的尽量复用，不必为了卖硬件重复采购。
| 设备 | 作用 | 选型注意 |
|---|---|---|
| 工控机 / 一体机 | 运行称重程序与本地数据库 | 每磅点一台，双网口或 4G 备份，断电后能自动恢复 |
| 车牌识别相机 | 进场识别与磅台二次校验 | 夜间需补光，污损车牌识别率下降，需配 IC 卡或扫码兜底 |
| 道闸与地感 | 车辆放行控制 | 与识别、预约联动，一车一杆，防跟车 |
| 红外对射 / 地感线圈 | 判断车辆是否完全上磅 | 防压边、防多车同磅，安装位置按磅台尺寸定 |
| 读卡器 / 扫码枪 | IC 卡与二维码触发 | 无车牌、临时车、内部车的备用入口 |
| 语音与显示屏 | 提示停稳、报净重与金额 | 减少司机下车询问，夜间可视距离要够 |
| 打印机 | 打印磅单与条码标签 | 热敏或针式，按现场粉尘与温湿度选 |
实施通常分四步：现场勘察与磅台标定、基础数据与单据模板配置、联调（门禁、识别、ERP、短信）、试运行与培训。单个磅点的标准周期三到五周；多磅点多机构、或需要对接 ERP 的，每增加一个系统按一到两周往上加。
试运行阶段建议保留人工复核：前两周每车核对，第三周起只核对异常车，稳定后再切全无人。开门就无人，第一周一定会出现「车过了、单没生成」的情况，补单比复核更费人。
验收要跑三个场景：断网过磅、同车多趟往返、无预约车辆到场。这三个过了，日常九成情况都能覆盖；只演示「顺利过一车」，说明不了任何问题。
九、常见问题
无人值守是不是就不需要人了？
不是完全没人，而是人不在磅房里。常规过磅由系统自动完成，异常车、无预约车、单据不符的车仍需人处理，通常设一名远程值守就能覆盖一个场地的两三个磅点。人力从「每班盯磅房」变成「有事才介入」，夜班可以不再排人。
断网了还能过磅吗？
能。本地部署独立数据库，断网时取重、抓拍、打印磅单、扣量计算照常进行，数据先落本地；网络恢复后按时间顺序补传，单号连续、不重复结算。要注意的是跨场地的预约校验在断网时无法实时做，通常改为本地白名单校验，恢复后再核对。
我们现有的地磅和仪表比较老，能接吗？
多数能。常见仪表通过串口或网口输出重量数据，只要协议开放就能接入；仪表本身不带通讯口的，加一块称重采集模块即可。勘察时要确认三件事：仪表型号与协议、接线距离、磅台是否已有红外与道闸。老磅体只要结构没问题，通常不需要换。
能对接我们正在用的 ERP 吗？
主流平台有现成接口，包括 YS、U9、BIP、U8C、T+C 等，可按订单取价、回写称重结果与结算单。非主流或自研系统，只要能提供数据库视图或接口文档，也可以做对接。对接前建议先明确三件事：以哪边的档案为准、价格从哪取、称重结果回写成什么单据。
车牌脏了、临时车来了怎么办？
识别率再高也有边界。做法是三条兜底：小程序二维码扫码、IC 卡刷卡、远程值守人工放行。临时车没有预约的，入口登记后生成临时预约单，照样走自动称重，只是单价按现场录入并留痕。不建议给临时车开口头放行的口子，那等于把防作弊的墙拆了一角。
化验的扣量、扣价怎么算？
按品种绑定指标集，化验单录入指标值后，系统按约定规则计算：扣量是按超标幅度扣减净重，扣价是按等级或指标区间调整单价，两种可以叠加。规则写在配置里，不是写死在代码里，指标调整时由业务人员改配置，不用改程序。
一套系统大概多少钱、多久上线？
价格主要由四件事决定：磅点数量、是否含门禁与排队、是否对接 ERP、是否需要定制报表。单个磅点的标准实施三到五周，含门禁与排队的通常五到七周，多磅点多机构或对接多个系统的按里程碑推进。做完现场勘察后我们会给出设备清单、模块清单与分期方案，费用按模块列明，不按人天含糊估算。
数据存在哪里？以后能不能自己维护？
默认部署在客户自己的服务器或指定云主机上，数据库为 MySQL，数据归客户所有。交付包含数据库结构说明、部署与备份文档、常见故障处置清单，并提供一次交接培训；有内部 IT 人员的，可以从试运行阶段就介入，后续自行维护或按年签运维服务。