最近在排查 SAP Fiori Elements 业务对象的保存问题时，经常会碰到一种很有迷惑性的现象。页面可以正常打开，列表能够显示客户、状态、金额等字段，对象页里的编辑框也能接收输入，保存动作甚至可能没有直接抛出特别醒目的前端错误，可回到数据库检查活动数据时，某些字段却仍然是初始值。客户编号没有落表，最终状态没有更新，后续校验又因为关键字段为空而失败。这类问题很容易被误判为 UI 注解没有生效、OData 请求丢字段、SADL 转换异常，或者 BOPF 保存逻辑没有执行完整。可真正需要检查的地方，往往藏在 CDS 视图元素名称与活动持久化对象字段名称之间。许多 SAP 系统经历过多轮版本演进。早期透明表受限于命名长度、历史编码规范和模块内部习惯，字段名常常很短，甚至只有熟悉业务背景的人才能看懂。BPARTNER表示业务伙伴，OSTATUS表示订单状态，这类名称放在传统 ABAP 程序里并不罕见。到了 CDS 数据模型层，我们更希望使用Customer、FinalStatus这类能够直接表达业务语义的元素名。CDS 不只是数据库查询定义，它还承担语义模型、关联关系、事务行为和服务暴露等职责，所以元素名称越清楚，后续的 OData 元数据、Fiori Elements 页面、扩展代码和测试脚本就越容易理解。问题也正是在这里出现。读取路径可以借助as完成别名投影，写入路径却需要事务运行时把 CDS 元素重新落到活动持久化对象。名称不一致时，读与写便可能走向两套完全不同的结果。SAP 官方文档明确说明，当底层表字段名与 CDS 元素名不一致，排除仅有大小写或驼峰形式差异的情况，C
