从 SM30 到 ABAP Cloud，老表维护迁移到 Business Configuration 的一条干净路径

很多 S/4HANA On-Premise 或 Private Cloud 项目走到 Clean Core 这一步时，最先暴露出来的不是复杂的销售定价增强，也不是 RAP 大对象建模，而是一堆看起来不起眼的 Z 表维护。以前大家习惯用 SM30，SE54，维护视图，函数组，授权组，配合 S_TABU_DIS 做权限控制。业务顾问改几条配置，ABAP 顾问查几条数据，流程很熟。问题出在系统开始引入 ABAP Cloud 开发模型之后，同一类配置数据会同时散落在 SAP GUI 和 SAP Fiori 两套入口里。老对象还在 SM30，新对象走 Custom Business Configurations App。业务用户要记住两套界面，权限团队要维护两套授权思路，开发团队还要解释为什么某张配置表在 Fiori 里看不到，另一张表又只能在 SAP GUI 里改。这个割裂感会越来越强。ABAP Cloud 里的 Business Configuration Maintenance Object 正好就是为这种场景准备的。SAP 官方文档对它的定位很明确，它把一个 service binding 声明为业务配置相关对象，使其能出现在 Custom Business Configurations App 的可维护配置列表里，并可通过 ADT 或 API 维护。(