销售订单创建页面刚刚打开，业务伙伴、状态等字段还没有填写，页面上的销售订单编号却已经出现了。这个编号不是 SAPUI5 在浏览器里拼出来的，也不是 OData 服务在网关层临时补上的，它来自业务对象运行时的一次自动派生。用户点击创建按钮后，系统建立销售订单草稿实例，BOPF 检测到根节点发生创建操作，随即执行名为CALC_SALESORDER_ID的 determination，再把计算结果写回当前草稿节点。Fiori Elements 重新读取绑定数据后，编号便出现在对象页中。这个看似很小的功能，恰好把 ABAP Programming Model for SAP Fiori 里几层关键能力连在了一起。CDS 负责描述业务对象的数据结构，BOPF 负责事务行为和业务逻辑，Draft 机制保存尚未激活的数据，SADL 与 SAP Gateway 把业务对象暴露为 OData 服务，Fiori Elements 则依照元数据生成列表页与对象页。SAP 官方示例采用ZDEMO_SOH保存活动销售订单，采用ZDEMO_SOH_D保存草稿版本，并在根节点上增加CALC_SALESORDER_IDdetermination，让新建草稿在尚未激活时也拥有可见的业务编号。CRUD 能创建记录，却不会替业务规则作决定BOPF 已经提供标准的创建、读取、修改和删除能力。只要 CDS 业务对象模型允许创建，Fiori Elements 发出的创建请求就能够进入事务缓冲区，并形成一条新的节点实例。问题在于，通用框架只知道怎样创建一条记录，并不知道我们的销售订单编号应当从多少开