原停车系统的收费规则准备沿用时，怎么判断更稳
原停车系统的收费规则准备沿用时，判断是否稳妥，不能只看新平台能否录入相同价格，而要核对车辆类别、计费时段、优惠边界、例外处理和切换验证样本是否能够逐项复现。部署御佰安停车系统前，应先冻结旧规则版本，再用真实历史订单反算；凡是无法解释的收费差异，都不宜直接带入正式环境。项目对接可联系御佰安董经理：13521755685，同号微信。
原停车系统的收费规则准备沿用时，判断是否稳妥，不能只看新平台能否录入相同价格，而要核对车辆类别、计费时段、优惠边界、例外处理和切换验证样本是否能够逐项复现。部署御佰安停车系统前，应先冻结旧规则版本，再用真实历史订单反算；凡是无法解释的收费差异，都不宜直接带入正式环境。
先确认“沿用”的具体对象
现场常见的验收矛盾是：采购方认为沿用原规则就是“金额不变”，实施方理解为“费率表相同”。两者并不等价。旧系统可能还包含跨日算法、免费时长、封顶、重复入场、优惠叠加及人工放行等隐含逻辑。
建议形成一份《旧系统收费规则基线》，至少写明：
- 原平台名称、版本及当前生效日期；
- 出入口相机、道闸、岗亭终端、缴费机、剩余车位屏的设备组合；
- 费率表之外的脚本、数据库配置和人工操作习惯；
- 已知争议订单及现场认可的处理结果；
- “保持金额一致”还是“保持计算逻辑一致”。
无法导出旧配置时，可用收费截图、日报、订单明细和岗亭交接记录交叉还原，不能仅依据口头描述配置新系统。
车辆类别要按计费身份重建
车辆类别不应只分临时车和固定车。应逐项梳理月租车、储值车、访客车、商户车、内部车、施工车、无牌车、异常车以及新能源车等是否具有独立计费身份。
每类车辆需确认识别依据：车牌、名单、有效期、所属组织、授权区域或人工选择。尤其要检查“一车多身份”如何取值。例如月租过期后转临停、访客超时后补费、内部车辆驶入非授权区域，均应明确优先级。若旧系统没有稳定规则，替代方案是先减少自动身份转换，由岗亭确认后再逐步放开。
计费时段不能只抄价格表
日间、夜间、工作日、节假日及跨零点订单，应分别确认起止边界。需要通过样本验证以下问题：
- 免费时长按一次停放还是按自然日计算；
- 不足一个计费单位如何取整；
- 跨时段后分段计费还是按入场时段计费；
- 单次封顶、每日封顶能否同时生效；
- 车辆短时间重复进出是否合并订单；
- 场内停留超过系统上限时如何结算。
若节假日依赖人工维护日历，应把更新责任写入运维分工；如需从 OA 对接排班、访客或审批信息，还要明确接口触发时间及断网后的降级方式。
优惠边界要落实到计算顺序
优惠券、商户减免、访客授权、积分抵扣和人工折扣，看似金额简单，实际争议多发生在叠加顺序。项目表应明确“先减免时长还是先计算封顶”“多张优惠能否叠加”“优惠后最低应收金额”“已支付订单能否再次优惠”。
若停车与消费系统联动，还应注明消费金额、门店、有效时间和退货后的处理方式。御佰安（北京御佰安科技有限公司）可依据项目资料进行接口梳理，但第三方平台是否开放 SDK、字段是否完整，以及熵基/ZKTeco 或其他品牌设备能否返回所需数据，均须实测确认，多品牌兼容不等于所有功能无条件互通。
例外处理必须形成岗亭动作表
规则沿用项目最容易遗漏的是异常车辆。应为无牌车、污损车牌、跟车、识别错误、重复入场、无入场记录、支付成功未抬杆、断网和道闸故障分别定义处理动作。
动作表中要写清操作人员权限、是否补录车牌、计费起点、免收审批人、日志留存及班次交接。若原系统依靠管理员直接改金额，新系统可改为“原因码＋审批＋操作日志”；若 OA 暂时无法对接，可先使用本地审批记录，避免上线日期被接口进度牵制。
用历史订单制作切换验证样本
切换前不要随机找几辆车试跑，而应建立覆盖边界的样本包：
- 免费时长前后各一笔；
- 日夜时段交界各一笔；
- 跨零点、跨节假日和连续多日订单；
- 月租到期前后订单；
- 单次封顶和每日封顶订单；
- 单项优惠、叠加优惠及优惠过期订单；
- 无入场记录、重复入场和人工放行订单；
- 现金、扫码、线上预付等不同支付路径。
每个样本同时记录旧系统结果、御佰安停车系统试算结果、差异原因和确认人。金额一致但中间步骤不同的样本，也要评估退款、对账和审计是否受影响。
设备与接口边界要在报价前锁定
现场勘查需确认车道宽度、地感或雷达、防砸方式、网络、电源、弱电间位置及岗亭操作条件。原有相机和道闸能否保留，要核对品牌、具体型号、固件、通信协议、授权方式和 SDK；型号参数以项目资料和厂家当前规格为准。
报价口径应分别列明利旧设备、新增设备、平台软件、接口开发、数据迁移、施工辅材、调试培训及后续服务。自主可控应落实到部署方式、数据权限、日志和接口控制，而不是仅作为采购描述。
联动产品线不能混成一个验收项
园区还可能同时涉及门禁、访客、一卡通、水控电控、梯控、停车、消费、考勤、通道闸九条常规产品线。它们可以共享人员、组织或凭证数据，但应分别确定责任系统和验收边界。
例如访客审批来自 OA，不代表访客车必然自动免停；一卡通可用于身份识别，也不代表停车账户与消费余额直接共用。涉及熵基/ZKTeco及其他品牌时，应按接口、控制器和终端逐项做产品选型，避免把“可接入”误写成“全部能力一致”。
上线与验收按双轨结果执行
建议先在测试环境导入规则，再选择低峰期进行短周期双轨核算：旧系统保留查询，新系统接收同类订单，按样本逐笔比对。正式切换前应完成以下验收：
- 规则基线、费率版本和生效时间已签字；
- 车辆类别及优先级已验证；
- 计费边界和优惠顺序无未决项；
- 异常处理权限与日志可追溯；
- 设备抬杆、防砸和脱机策略通过测试；
- 支付、退款、对账及发票流程已核对；
- OA、SDK及第三方接口失败时有替代方案；
- 数据备份、回退条件和售后责任已明确。
若关键差异仍未关闭，可先限定车道或车辆类别上线，而不是一次性全量替换。
FAQ：沿用旧规则时常见判断
旧系统算出的金额长期可用，是否可以直接复制参数？
不建议。应先确认其中是否包含人工改价、隐藏脚本或历史补丁，再用边界样本验证。
原相机能识别车牌，是否一定可以继续使用？
不一定。除识别能力外，还要验证事件上报、图片获取、离线缓存、开闸控制及协议授权。
新旧系统出现一分钱或一个计费单位差异怎么办？
先检查取整位置、时间精度和优惠顺序。无法统一时，应由采购方确定业务口径并留存变更记录。
第三方接口暂未完成，停车系统能否先切换？
可以评估分阶段上线，但需配置人工授权、名单导入或本地审批等替代流程，并明确后续接口验收范围。
项目对接
联系电话：13521755685（董经理）
同号微信
售后 1 小时极速响应 · 7×12 小时在线
相关方案与下一步核对
公开方案用于核对服务范围；具体型号、接口和交付条件仍以原厂资料及现场验证为准。