📚 课程目录第3章设备资产台账数据模型解析

3. 设备资产台账数据模型解析

设备资产台账不是一张“设备清单表”，而是一套围绕资产对象组织起来的数据模型。它要回答四个问题：设备是什么、它现在处于什么状态、它发生过哪些业务、这些数据由谁在什么条件下修改。EAM系统能否支撑盘点、维修、折旧、点检和合规追溯，取决于台账模型是否把“主数据”和“事务数据”分清楚，以及表与表之间的约束是否足够严密。

一、台账核心字段：从“身份”到“状态”

设备台账的核心字段可以按语义分为四组。第一组是身份标识：资产编码（asset_no）、设备名称、规格型号、制造商、出厂编号、二维码/RFID标签号。其中资产编码是业务主键，通常由“公司码+资产类别码+流水号”构成，例如 SH-FAN-000231；出厂编号是厂商侧唯一标识，用于保修与备件匹配，二者不可互相替代。

第二组是归属与位置：资产类别、使用部门、成本中心、安装位置（厂区—车间—产线—工位）、责任人。位置字段建议采用层级编码而非自由文本，例如 A1-B2-L3-ST05，否则盘点时无法按区域聚合。

第三组是价值与寿命：购置日期、启用日期、原值、累计折旧、净值、预计使用年限、残值率。这些字段直接决定财务口径的资产状态，必须与财务系统保持同源或定期对账。

第四组是运行状态：在用、闲置、封存、维修中、待报废、已报废。状态字段是盘点差异判定的关键依据——同一台设备在“维修中”和“闲置”下的盘点处理方式完全不同。

二、主数据与事务数据的区分

主数据描述“资产本身相对稳定的属性”，事务数据描述“围绕资产发生的、随时间累积的业务记录”。区分标准不是“是否变化”，而是变化频率、责任归属和是否可追溯。

维度	主数据（Master Data）	事务数据（Transaction Data）
典型对象	设备、位置、部门、资产类别、供应商	盘点记录、维修工单、点检记录、调拨单、折旧凭证
变化特征	低频、受控修改、需审批	高频、按业务事件产生、只追加不覆盖
主键示例	asset_no、location_code	inventory_id、wo_no
责任角色	设备管理员、主数据专员	盘点员、维修工、财务
错误后果	全系统引用错乱	单笔业务失真，可追溯修正

实践中常见的错误是把“当前状态”和“历史状态”混在一张表里。正确做法是：主表只保留当前状态字段，状态变更写入事务表 asset_status_log，通过时间戳还原任意时点的状态。这样盘点时既能看“现在是什么状态”，也能回答“盘点基准日当天是什么状态”。

三、数据关系模型与EAM表结构

EAM台账的典型关系是：资产主表为核心，向上关联位置表和部门表，向下关联事务表。资产与位置是“多对一”（多台设备可在一个位置），资产与事务是“一对多”。

ASSET_MASTER (asset_no PK, asset_name, spec, category_id FK,
              location_code FK, dept_id FK, status, original_value,
              useful_life, start_date, rfid_tag)

ASSET_LOCATION (location_code PK, parent_code FK, location_name, level)

ASSET_CATEGORY (category_id PK, category_name, depreciation_years)

ASSET_STATUS_LOG (log_id PK, asset_no FK, old_status, new_status,
                  change_time, operator, reason)

INVENTORY_TXN (inventory_id PK, batch_no FK, asset_no FK,
               expected_location, actual_location, result,
               scan_time, checker)

其中 ASSET_MASTER.status 是当前状态快照，ASSET_STATUS_LOG 是状态流水；INVENTORY_TXN.result 取值通常为 MATCH、LOC_MISMATCH、NOT_FOUND、EXTRA，分别对应账实一致、位置不符、盘亏、盘盈。

四、数据完整性约束

完整性约束分三层。第一层是实体完整性：asset_no 非空且唯一，rfid_tag 若启用则唯一。第二层是参照完整性：ASSET_MASTER.location_code 必须存在于 ASSET_LOCATION，删除位置前必须先处理其下资产。第三层是业务规则完整性：

status 只能取预定义枚举值，禁止自由文本；
start_date 不得早于 purchase_date；
original_value ≥ 0，累计折旧不得超过原值减残值；
同一 asset_no 在同一盘点批次中只能有一条 INVENTORY_TXN 记录；
状态从“已报废”不可直接回到“在用”，必须经“待报废→审批→处置”流程。

盘点前建议先跑一次约束体检：检查是否存在 location_code 悬空、status 非法值、asset_no 重复、折旧超限四类问题。这四类问题会直接导致盘点差异无法归因。

把上述模型落到盘点场景：盘点任务生成时，从 ASSET_MASTER 按 location_code 范围抽取应盘清单，写入 INVENTORY_TXN 的 expected_location；盘点员扫码后回写 actual_location 和 result。若 result 为 LOC_MISMATCH，系统应同时生成一条 ASSET_STATUS_LOG 或位置变更待审记录，而不是直接改主表位置。这样，一次盘点既完成了账实核对，也留下了可审计的数据轨迹。

不要用“删除+新增”方式处理资产位置变更。位置变更必须走事务记录，否则历史盘点结果将无法还原，审计时也无法解释“为什么上期在这个位置、这期在那个位置”。

最后，数据模型的质量最终体现在盘点差异的可解释性上。如果一台设备盘亏，系统应能回答：它最后一次出现在哪个位置、由谁在何时确认、当时状态是什么、之后有没有调拨或维修记录。能做到这一点，台账模型才算真正支撑了数据治理，而不只是存了一张设备表。