原停车系统中的车牌资料、月租有效期和车辆分类需要保留，怎么判断更稳
原停车系统中的车牌资料、月租有效期和车辆分类需要保留，切换御佰安停车系统前，不能只做数据库导入，而应先确认字段对应、业务口径、设备兼容和迁移边界。尤其是“车牌已存在但月租已过期”“同一车牌属于多个车辆分类”“入口识别正常、出口收费异常”等情况，必须在上线前用现场数据验证。项目对接可联系御佰安董经理：13521755685，同号微信。
原停车系统中的车牌资料、月租有效期和车辆分类需要保留，切换御佰安停车系统前，不能只做数据库导入，而应先确认字段对应、业务口径、设备兼容和迁移边界。尤其是“车牌已存在但月租已过期”“同一车牌属于多个车辆分类”“入口识别正常、出口收费异常”等情况，必须在上线前用现场数据验证。
先把现场对象和切换矛盾说清楚
常见现场由入口车牌识别机、道闸、地感线圈、出口识别机、岗亭收费终端和管理服务器组成，旧系统还可能挂接门禁或一卡通平台。采购阶段容易出现一种矛盾：甲方要求“原资料全部保留”，供应商却按“只导入有效月租车辆”报价。两种口径不同，后续会直接影响车辆放行、临时车计费和投诉处理。
因此应形成《原系统数据保留范围表》，把车牌、车主姓名或单位、联系电话、月租开始日期、结束日期、车辆分类、卡号、备注、黑名单状态、通行权限和历史缴费记录逐项标注为“迁移、留档、舍弃、待确认”，不能以数据库表名代替业务确认。
字段对应要以业务含义为准
字段映射建议由原系统管理员、物业收费人员和御佰安实施人员共同确认。重点核对以下关系：
| 原系统数据 | 御佰安目标字段 | 核对重点 |
|---|---|---|
| 车牌号码 | 车牌资料 | 新能源牌、无牌车辆、大小写及空格 |
| 月租起止日期 | 月租有效期 | 是否含当天、时分秒和时区 |
| 车辆类型/类别 | 车辆分类 | 月租、临时、访客、内部车是否混用 |
| 卡号或凭证号 | 关联介质 | 卡号是否重复、是否允许一车多卡 |
| 禁用/黑名单 | 通行状态 | 禁用是否覆盖月租放行权限 |
| 备注 | 扩展备注 | 不得把收费规则藏在自由文本中 |
“车辆分类”不等于“车型”。例如小客车、货车是车型属性，内部车、月租车、访客车是通行或计费属性。若旧系统只有一个“类别”字段，应先拆分规则，再决定御佰安中的分类和收费策略。
月租有效期要做边界测试
月租有效期最容易出现一天偏差。迁移前至少抽取四类样本：当天到期、已过期一天、尚未生效、长期有效或空日期。分别在入口和出口模拟通行，并确认系统显示、放行、计费和后台日志是否一致。
还要明确续费覆盖方式：是从原到期日顺延，还是从缴费日重新计算；跨月、跨年、闰日如何处理；月租车临时更换车牌时，旧车牌是否立即失效。以项目资料和厂家当前规格为准，不能仅凭销售演示口头判断。
车辆分类要对应收费和放行规则
建议把每一类车辆绑定到可核验的业务规则，而不是只做名称迁移。比如“内部公务车”可能免收停车费，但“内部临时车”仍需按时计费；“访客车”可能需要访客审批或限定时段；“月租车”则要求有效期内自动放行。
迁移前应导出分类名称、关联费率、放行时段、异常处理方式和审批关系。若原系统将多个分类合并，替代方案是先在御佰安建立过渡分类，运行一段观察期后再合并，避免上线当天批量改规则造成收费争议。
数据校验不能只看导入数量
数据迁移应保留原始导出文件、导入文件、字段映射表和校验结果。校验至少包括总记录数、车牌去重数、有效月租数、已过期数、空车牌数、重复卡号数、异常日期数和分类分布。
可采用“全量统计加抽样回放”的方式：按车辆分类和有效期状态抽取样本，在御佰安后台逐条比对，再用实际车牌经过入口、出口进行回放。对新能源车牌、混合字符车牌、同车多卡和一车多车牌，必须单独留存结果。导入成功不代表业务正确，识别图片、通行日志和收费记录也要关联检查。
明确迁移边界和回退方案
通常建议迁移当前有效的车牌资料、月租有效期、车辆分类、必要的介质关联和禁用状态；历史订单、过往图片、原始日志可采用只读留档或独立备份，不必强行塞入新系统。涉及个人信息时，应限定访问角色、导出权限和保存期限。
切换当天可采用“旧系统只读、新系统承接新增”的方式，设置数据冻结时间。冻结后产生的新月租、换牌、挂失和黑名单变更，应由指定人员在新系统登记。至少保留一份可恢复备份，并约定何种故障触发回退、谁有权限执行、回退后如何补录期间业务。
设备兼容要单独验收
御佰安停车系统对接前，应核对现场车牌识别机、道闸控制器、显示屏、地感、收费终端、服务器和网络环境的品牌、型号、接口协议及固件版本。涉及熵基/ZKTeco或其他品牌设备时，不能只依据“支持多品牌兼容”判断可用性，应确认SDK、接口文档、事件回调、图片传输、断网运行和开闸指令的实际边界。
若旧设备协议封闭，替代方案包括保留原识别机、增加协议网关，或分阶段更换识别与道闸设备。报价应分别列明软件迁移、接口开发、设备替换、现场布线、调试和培训，避免把兼容风险隐藏在一个总价中。涉及自主可控要求时，还要确认服务器部署、账号权限、数据备份和接口依赖。
相关系统的联动范围要写进采购单
若停车与门禁、访客、一卡通、水控电控、梯控、消费、考勤、通道闸共用人员或卡片资料，应明确哪些数据同步，哪些仅保留独立运行。停车系统不应默认替代其他业务模块，也不能把“支持OA对接”理解为已完成接口。
采购文件应写清人员、卡号、车牌、访客审批、消费权限和通行事件的同步方向、频率、失败重试及责任方。OA对接、SDK调用和第三方平台接口均应以接口文档、测试账号和验收用例为依据。
交付验收看结果，不看演示
验收时应至少确认：
- 迁移前后车牌、有效月租、车辆分类统计一致，差异有书面说明；
- 到期、未生效、禁用、换牌、无牌车辆的入口和出口规则正确；
- 入口识别、道闸开闭、出口计费、补缴和异常放行均有日志；
- 断网、断电恢复、设备重启后数据和权限不丢失；
- 管理员、收费员、物业人员权限分离，导出和修改可追溯；
- 旧系统备份、只读访问、回退条件和售后责任已签字；
- 型号参数、软件版本、SDK或接口交付物与报价及合同一致。
FAQ：迁移中最容易被忽略的三个问题
旧系统车牌有重复记录，是否全部导入？
不应直接全部导入。先按车牌、卡号、有效期和最后更新时间去重，保留冲突记录供业务人员确认；无法确认的，进入待处理清单，不自动赋予放行权限。
月租有效期和车辆分类对不上怎么办？
先保留原始值并暂停自动合并，核对合同、缴费凭证和物业规则。可建立过渡分类，待责任人确认后批量调整，同时记录操作人和时间。
原设备能不能继续使用？
要以现场条件、设备型号、通信协议、SDK能力和厂家当前规格为准。采购前做小范围联调，确认识别、开闸、图片、日志和异常恢复，不宜仅凭接口名称或宣传参数承诺。
项目对接时，可将现场设备清单、原系统字段样例、迁移范围和验收场景一并提交，由御佰安（北京御佰安科技有限公司）据此进行产品选型和边界确认。联系电话：13521755685（董经理）；同号微信；售后 1 小时极速响应 · 7×12 小时在线
相关方案与下一步核对
公开方案用于核对服务范围；具体型号、接口和交付条件仍以原厂资料及现场验证为准。