GuDingZiChan/docs/2026-03-23_资产迁移推进记录.md
2026-03-23 12:05:51 +08:00

5.5 KiB
Raw Permalink Blame History

2026-03-23 资产迁移推进记录

当前 live 结果

  • 固定资产 live 总数:1640
  • 其中有借用记录的资产:1247
  • 当前无标准地址的资产:59
  • 当前无标准地址状态分布:
    • 可用:16
    • 已借出:43

今天已经完成的动作

  • 扩展了 backend/scripts/importConfirmedEquipmentToLive.js
    • 支持 --keep-existing
    • 支持 --include-ownerless
    • 支持把 import-without-owner 资产增量补导到 live
    • 自动排除空编码和重复编码
  • 已增量导入 393 条“不带使用人但可先导入”的资产
  • 已新增并使用 backend/scripts/exportAdminManualReviewWorkbook.js
    • 自动导出行政补录工作簿
    • 如果目标文件被 Excel 占用,自动生成时间戳版本
  • 已补强地址标准化规则:
    • 常州 -> 常州-天安
    • 佛山3D / 佛山平面 / 佛山建模 / 广东佛山 -> 佛山
    • 二楼分销 -> 常州-天安
    • 南京机房远程数据机 -> 南京-苏宁园区
    • 10号楼1楼机房监控 / 10号楼1楼监控室 / 10号楼1楼配电间监控 / 10号楼3楼机房 -> 南京-苏宁园区
  • 已扩展 backend/scripts/backfillImportedEquipmentLocations.js
    • 不再只处理 import-ready
    • 也能处理 import-without-owner
  • 已扩展 backend/scripts/prepareEquipmentMigrationDryRun.js
    • 支持 --live-snapshot
    • 支持读取 migration_manual_overrides.json
    • 已加入高置信度部门映射:
      • 品牌营销策划中心 -> 品牌策划中心
  • 已扩展 backend/scripts/exportAdminManualReviewWorkbook.js
    • 支持 --null-location-json
    • 可在没有远程密码的情况下做离线结构验证
  • 已新增 backend/scripts/buildMigrationManualOverridesFromWorkbook.js
    • 可把行政填写后的工作簿生成 migration_manual_overrides.json
    • 同一资产字段或同一花名如果填写冲突,会直接报错拦截
  • 今天地址回填结果:
    • 第一轮回填:32 条
    • 第二轮回填:5 条
    • 无标准地址从 96 压到 59

今天新增的本地离线验证结果

  • 使用已验证 live 快照
    • temp_migration_output/migration_dry_run_2026-03-23_03-01-06/live_reference_snapshot.json
    • 重新跑 dry-run 后结果变为:
      • importReady = 1255
      • importWithoutOwner = 402
      • pendingReview = 22
      • discardNoImport = 34
  • 已确认新增映射确实生效:
    • JS-PC-1719
    • 原部门:品牌营销策划中心
    • 从 pending-review
    • 变成 import-without-owner
  • 使用离线 null-location JSON 重跑行政工作簿导出后,结构验证通过
    • 待确认部门:22
    • 待补使用人:197
    • 花名核对:106
    • 待补地址:59
    • 新增可填写列与 填写说明 工作表均已生成
  • 已做样例闭环验证:
    • 样例工作簿 -> migration_manual_overrides.json
    • 再喂给 dry-run
    • 结果可继续把 pendingReview 从 22 压到 21

当前说明

  • 上面这轮新增验证是“本地离线验证”
  • 没有新的 live 写入
  • 原因是当前会话没有注入 FIXED_ASSET_SSH_PASSWORD
  • 但脚本链路本身已经打通到:
    • 行政工作簿可填写
    • 工作簿可生成 overrides
    • dry-run 可读取 overrides 重新分桶

关键输出文件

  • 最新 dry-run:
    • D:\AI Code\GuDingZiChan\temp_migration_output\migration_dry_run_2026-03-23_03-01-06
  • 最新地址回填结果:
    • D:\AI Code\GuDingZiChan\temp_migration_output\location_backfill_2026-03-23_03-01-32
  • 最新导入备份:
    • D:\AI Code\GuDingZiChan\temp_migration_output\live_import_backup_2026-03-23_02-47-21
  • 最新行政补录清单:
    • D:\AI Code\GuDingZiChan\行政手动补录清单-2026-03-23_03-07-12.xlsx

当前行政补录清单统计

  • 待确认部门:23
  • 缺少编码:6
  • 重复编码:
    • 重复编码数:5
    • 重复记录数:10
  • 待补使用人:196
  • 花名核对:105
  • 待补地址:59

关于 196 条“待补使用人”的结论

  • 其中 193 条原因是:owner_not_in_active_synced_roster
  • 其中 3 条原因是:multi_owner_cell
  • 已做过进一步核对:
    • 这批花名按 hr_employee_register.sys00-flowerName
    • hr_employee_register.sys00-name
    • hr_employee_register.sys02-realName
    • hr_employee.name
    • 四个字段去查,都没有命中
  • 当前结论:
    • 这不是简单的“同步规则漏同步了当前员工”
    • 更像是 Excel 里使用的是另一套历史花名/历史称呼
    • 需要行政按“花名核对”工作表,把历史花名对应到当前在职员工

当前剩余 59 条待补地址的主要口径

  • 空白:32
  • 电子设备:5
  • 河北仓:3
  • 天安/杭州:2
  • 山东仓:2
  • 抓数用:2
  • 其余都是 1 条

剩余地址为什么先不继续自动处理

  • 空白 无法推断
  • 电子设备、抓数用 不是地点字段
  • 河北仓、山东仓、睢宁仓、沭阳 等更像真实外部仓点
    • 可能应该新增标准地址
    • 不适合硬映射到现有 常州-仓库
  • 天安/杭州、杭州/天安 是双地址写法
    • 当前没有足够证据判断应该落到哪一个标准地址

如果后面继续推进,优先顺序建议

  1. 行政先处理 花名核对 工作表,确认 105 个历史花名对应的当前人员
  2. 行政确认 59 条待补地址里,哪些应新增为正式标准地址
  3. 再决定是否补第二轮“带使用人回挂”或继续回填新增地址

安全边界

  • 本次所有 live 操作都只针对固定资产系统
  • 未操作 /opt/shebeiguanli
  • 未操作任何 shebeiguanli-* 容器或其数据库