财务人员正在处理一张供应商发票，付款状态还是未支付，备注栏允许补充说明，页面上的「设为已支付」按钮也处于可用状态。付款操作完成后，业务对象的状态已经发生变化，备注栏随即变成只读，「设为已支付」按钮也不再允许点击。页面看起来只是少了一个输入框，多了一个灰色按钮，背后却牵涉到一个很关键的设计问题，究竟由谁判断字段能不能修改，动作能不能执行。把判断逻辑写在 SAPUI5 Controller 里当然能做。页面读取Paid字段，发现值为true，便调用setEditable(false)，再把动作按钮设为禁用。可是一旦同一个 OData 服务还要提供给另一套 Fiori Elements 应用、移动端应用或者第三方客户端，这套规则就得重复实现。更麻烦的是，前端判断只负责界面表现，并不能天然代表后端业务对象的真实能力。浏览器里看不到按钮，不等于服务端不接受请求。Field and Action Control 处理的正是这类问题。业务对象把字段属性、实体能力和动作能力作为服务语义提供出来，SAP Fiori UI 再依据这些信息决定字段以输入控件还是文本形式呈现，动作按钮应该启用、禁用或者隐藏。经典 ABAP Programming Model for SAP Fiori 通过 CDS、BOPF、SADL 与 SAP Gateway 串起这条链路，现代 RAP 则把同类能力归入 Feature Control。两套编程模型的实现位置不同，设计目标却高度一致。字段控制并不只是让输入框变灰谈到字段控制，最容易想到的是只读。其实，一个事务字段通常至少包含三类消费属性。