企业官网建设流程全解析

做 EBS 实施的人都经历过这种对话：业务部门指着屏幕说，这个字段我们根本不用，能不能去掉？那个字段名太专业，能不能改成车间里的叫法？每次开单都要选一串默认值，能不能自动带出来？需求确实不大，但走 Form 二次开发，要开发资源、要排期、要测试，上线窗口一等就是一两个迭代，业务早就没耐心了。

实际上 EBS 自带一套面向表单界面的规则配置器，就是标题里说的“个性化设置界面”。它不是改主题皮肤，也不是调一调显示风格，而是一个能控制字段显隐、可编辑性、必输属性、默认值和校验逻辑的轻量级工具。不碰 fmx、不用编译、不需要应用服务器重启，保存规则、重新打开表单，效果就出来了。

我见过不少顾问和运维人员，要么找不到入口，要么以为它只能改个提示文字，要么因为踩过坑就再也不敢用。这篇我就把这几年用个性化设置界面的实操经验、配置写法、层级关系和排查思路完整写出来，尤其把那些文档里不会写、但实际项目里很容易踩的坑一起讲清楚。

1. 个性化设置界面为什么值得认真学

1.1 它解决的其实是表单层体验问题

业务系统上线之后，大量后续需求都集中在“录得不舒服、看不明白、容易录错”这些界面层问题上。字段太多导致关键字段被淹没，标签术语和业务习惯不一致导致选错，该默认填写的值每次都要手输导致效率低，组合条件校验缺失导致脏数据进了后线表。

这些问题单个看都很小，但堆在一起就成了“系统不好用”的体感来源。个性化设置界面存在的意义，就是把这些中低频、低复杂度的界面优化需求，从开发部门手里接过来，让懂业务的人直接在界面上配置完成。配置结果存储在数据库规则表里，Forms 在启动和运行阶段会根据规则动态修改界面组件属性，不需要对标准 Form 做任何物理改动。

1.2 和 Form 二次开发的边界要划清楚

有些人觉得个性化既然这么方便，干脆所有界面改动都交给它。这也是不行的。我一般用下面这个表判断需求该走哪条路：

我的判断标准很简单：如果需求是“这个字段在某些条件下应该怎样”，几乎都可以用个性化解决；如果需求是“界面上要新增一张表、一个多行复杂交互区”，那就老老实实走二次开发。个性化解决的是规则问题，不是界面重构问题。

1.3 熟悉整个界面的隐藏收益

除了表面上快速响应需求，还有一个容易被忽略的收益：个性化规则可以把很多“临时救火”的需求挡在开发流程之外，降低 Form 二次开发的数量。开发数量少了，后续打补丁的冲突率也明显下降，运维负担会小很多。哪怕某些需求最终还是要走开发，前期用个性化快速验证业务逻辑，也能把需求文档里的疑点提前暴露出来，开发团队拿到的需求反而更干净。

2. 进入个性化设置界面的准备与完整入口

2.1 权限和配置文件是两个前提

进入个性化设置界面之前，先确认两件事。

第一，当前职责要有使用个性化功能的权限。一般情况下，系统管理员职责（System Administrator）默认具备进入和保存规则的权限。如果你们把个性化权限单独分配给了某个职责，那就用对应职责登录。

第二，菜单入口的可见性受配置文件“隐藏诊断菜单”（Hide Diagnostics Menu）控制。这个配置文件默认值为“否”，也就是显示诊断菜单。如果实施时有人把它设成了“是”，帮助菜单下的“诊断”子菜单会消失，自然找不到个性化入口。遇到这种情况，先用系统管理员职责到“配置文件 -> 系统”里搜索该配置文件，改为“否”，重新登录后再操作。

2.2 从标准表单打开“自定义代码”窗口

入口本身不复杂，但很多同事第一次找的时候容易对不上名称。实际操作路径是：

1. 用有权限的职责登录 EBS，打开你要做个性化的目标表单，比如采购订单录入界面或物料主文件维护界面。
2. 点击菜单栏“帮助” -> “诊断” -> “自定义代码”（Help -> Diagnostics -> Custom Code）。
3. 系统弹出一个独立的“自定义代码”窗口，这就是个性化设置界面的主窗体。
4. 窗口上部是规则定义区，包括层级、规则名称、表单名、触发器事件、触发器对象、条件；下部是处理区，用来维护这条规则要执行的动作列表。

之所以强调“先打开目标表单再进入口”，是因为个性化设置界面会自动定位到当前表单，省掉了手工搜索表单名和手工补表单映射的麻烦。对新手来说，这一点能少踩很多坑。

2.3 快速弄清表单名、块名和字段名

配置规则时经常要写块名和字段名，尤其是条件和 PL/SQL 处理里要引用字段的地方。这里有三个实用技巧：

• 查看表单名：在目标表单里点“帮助” -> “关于 Oracle 应用”，能看到表单文件信息和表单名，这个名称就是个性化规则里要填的“表单”值。
• 用“帮助” -> “诊断” -> “检查”（Examine）工具：诊断菜单打开后，可以进入 Examine 窗口，鼠标点中界面上的任意字段，Examine 会显示出当前项所属的块名（Block）和项名（Item）。这比我当初对着文档找字段名快得多。
• 在个性化设置界面新建规则时，表单下拉框默认选中当前表单；后续在添加与字段相关的处理时，块和字段都有下拉列表，可以直接从列表选择，不需要手工敲，比文本输入更安全，也避免拼写错误。

3. 一条个性化规则的解剖：触发器、条件、处理

3.1 规则的三层结构

个性化规则的逻辑结构，其实就是一个 if-then 模型：触发器决定“什么时候检查”，条件决定“满不满足”，处理决定“满足后干什么”。把这三层拆开理解，后续所有配置都是添砖加瓦。

• 触发器（Trigger Event）：定义了规则被激活的时机。比如刚进入表单、光标进入某个记录、光标进入某个字段、字段校验时、记录校验时。
• 条件（Condition）：可选的 PL/SQL 布尔表达式。不写条件，就表示只要触发器发生就执行处理；写了条件，则必须满足表达式才会执行。
• 处理（Actions）：规则命中后要做的具体动作。一条规则下面可以挂多个处理，按设置的序号依次执行。

3.2 触发器选择是第一步，也是大部分问题的源头

触发器选错，规则经常会出现“好像生效了又不完全生效”的现象。下面是我最常用到的几个触发器：

举一个典型问题：有人希望在进入采购订单表头时，给“币种”赋一个默认值。结果他选了 WHEN-NEW-FORM-INSTANCE，测试发现第一行默认值生效了，但往下新增一行时，币种又是空的。原因很简单，新建字段时根本没有再次进入表单，WHEN-NEW-FORM-INSTANCE 在整个 Form 生命周期里只触发一次。正确的做法是选 WHEN-NEW-RECORD-INSTANCE，这样每条新记录创建时都会触发默认值赋值。这种细节，文档里容易略过，但实际配置差异很大。

3.3 条件建议先写简单再逐步加码

条件字段直接写 PL/SQL 布尔表达式。比如想限定“仅当订单类型为标准订单时显示某个字段”，条件可以写成：

:ORDER_HEADERS.ORDER_TYPE = 'STANDARD'

新手容易犯的错是把复杂业务判断一股脑塞进条件里。我的建议是：第一次配置规则时，有条件也先空着，把触发器、处理这一段完整跑通，确认规则本身没问题，再往里面加条件。这样一旦规则不生效，可以快速排除是规则写错了，还是条件逻辑有问题。条件里引用的字段，务必确保它存在于当前表单，且块名、字段名大小写正确。Forms 里对字段引用是区分上下文的，引用错误不会在保存时报警，只会在运行时导致条件异常，规则被悄悄忽略掉。

3.4 处理类型就是规则的核心动作

个性化设置界面的处理区支持多种动作类型，我常用的是下面四种：

属性处理是最常用的。比如要让某个字段置灰不可编辑，属性名填ENABLED，值填FALSE；要隐藏字段，属性名填VISIBLE，值填FALSE；要改成必输，属性名填REQUIRED，值填TRUE；要改提示文字，属性名填PROMPT_TEXT，值填新的标签文字。

运行 PL/SQL 适用于属性表达不了的逻辑。比如给字段赋值：

:ORDER_LINES.QUANTITY := 1;

如果校验不通过，要阻止保存：

FND_MESSAGE.SET_STRING('数量不能大于可用量'); FND_MESSAGE.SHOW; RAISE FORM_TRIGGER_FAILURE;

这段代码可以放在 WHEN-VALIDATE-RECORD 触发器里，实现标准 Form 界面上的组合校验。

4. 我常用的四个配置场景与具体写法

4.1 字段显隐和可编辑性控制

需求最常见的是“某某字段在这个界面用不上，隐藏掉”或者“这个字段只能看，不允许改”。实际配置时，前者用属性VISIBLE=FALSE，后者用属性ENABLED=FALSE。

两者区别要分清：隐藏是用户完全看不见，适合彻底不用的字段；禁用是看得见但灰置，适合需要展示、但不允许编辑的字段。如果只是不想让用户修改，却把字段隐藏了，其他用户可能会疑惑数据从哪来的，而且有些必输字段隐藏后会导致保存失败，这一点在后面的坑专门讲。

比如在物料主文件界面，很多企业根本不用“版本”字段，我通常直接建一条规则，表单打开时把该字段设为VISIBLE=FALSE。如果想做得更精细一点，可以加条件，只有具备特定职责的用户才看到版本字段。

4.2 设置默认值，用 PL/SQL 赋值最稳

设置默认值是我在项目里用得最多的功能之一。最典型的场景：销售订单录入时，币种默认人民币；采购单录入时，收发类型默认“标准采购”。

我的固定写法是：

1. 触发器选WHEN-NEW-RECORD-INSTANCE。
2. 处理类型选“运行 PL/SQL”。
3. 调用代码直接赋值：

:ORDER_HEADERS.INVOICE_CURRENCY_CODE := 'CNY';

之所以用运行 PL/SQL，而不是用属性处理去设值，是因为字段值的初始化时机在不同 Form 上表现不完全一致。直接赋值是最直观、最容易理解、排查问题时也最透明的做法。要同时赋多个默认值，在同一个 PL/SQL 块里多写几行赋值语句就行。需要根据不同的组织或库存地点给不同默认值时，可以先从配置文件或后端表取出值，再赋值给字段。

4.3 标签文字改造要像做数据字典一样规范

业务用户不是 IT 人员，很多标准界面上的标签对他们来说太抽象。比如把“请求号”改成“申请单编号”，把“SEGMENT1”改成“物料编码”，这些都可以通过属性处理里的PROMPT_TEXT实现。

有个细节需要注意：修改标签时，值直接填要显示的文字，不要加前后空格，也不要用引号。如果提示文字包含特殊字符，尽量在测试环境先验证一次，避免保存后显示异常。标签改造虽然简单，但建议在项目里形成统一的术语对照表，至少保证同一个字段在整个系统里的标签是一致的。否则一个字段在采购界面叫“申请单编号”，在库存界面又叫“申请号”，用户很容易懵。

4.4 用个性化做前端组合校验

业务校验如果全放在存储过程和接口层，用户往往要等保存报错才知道录错了，体验很差。用个性化可以在界面层提前拦截，把错误暴露在字段旁边。

比如订单行数量不能超过某个上限，同时仓库不能为空，可以这么配：

• 触发器选WHEN-VALIDATE-RECORD。
• 条件写成：

:ORDER_LINES.QUANTITY > 1000 AND :ORDER_LINES.WAREHOUSE_ID IS NULL

• 处理选运行 PL/SQL：

FND_MESSAGE.SET_STRING('订单数量超过上限且仓库未维护，请检查后再保存'); FND_MESSAGE.SHOW; RAISE FORM_TRIGGER_FAILURE;

当用户触发校验时，弹窗提示并阻止保存。这类配置虽然不属于复杂逻辑，但能明显降低后端校验的压力。特别是那些老表单，标准存储过程里校验逻辑很“含蓄”，错误提示只写个错误码，用户根本看不懂；个性化可以把这些提示翻译成人话，直接在界面友好触发。

4.5 工艺路线等制造类界面的个性化机会

这段时间搜“ebs工艺路线取数”的人不少，很多企业到了制造阶段，工艺路线界面的录入量很大，字段又深又长。工艺路线取数本身依赖 BOM_ROUTING 等底层表的数据完整性，但界面录入不规范，后面取数就全是脏数据。个性化在这里也能派上大用场。

比如按物料分类控制工序中的某些字段是否必输，按资源类型控制标准工时是否显示，或者在某道工序创建时默认带入一批工作中心参数。这些规则能让一线工艺人员在录入时少填重复信息、少看到无关字段，从源头保证工艺路线取数时需要的关键字段不被漏填错填。拿它当取数治理的第一步，比在报表层反反复复清洗数据有效率得多。

5. 层级、规则顺序与生效范围怎么控制

5.1 Site、Responsibility、User 三类层级

个性化规则可以挂在三个基本层级上：

• 站点（Site）：所有职责、所有用户登录后都会加载，适合全局统一的界面调整。
• 职责（Responsibility）：只有指定职责下的用户才会加载，适合按业务部门区分规则。
• 用户（User）：只有指定用户才会加载，适合给个别用户单独配置辅助规则。

实际项目里，全局隐藏字段通常用站点级；按部门或岗位的差异用职责级；个别用户的特殊配置用用户级。规则可以多条并存，同一字段在不同层级下的表现是叠加的，而不是互斥的。

需要注意一点：层级不是“单选”之后其他层级就不管了。系统会按顺序把所有命中当前上下文的规则都执行一遍。想实现“站点级对所有人生效，但采购职责例外”这种需求，最简单的做法是在站点级规则的条件里排除采购职责：

FND_PROFILE.VALUE('RESP_ID') <> '采购职责的RESP_ID'

也可以用职责级规则反方向覆盖站点规则，但覆盖逻辑依赖规则顺序和属性赋值，不如条件判断直观，我一般优先推荐条件写法。

5.2 规则顺序常常是“隐形杀手”

同一触发器下，多条规则的执行顺序按“序号”从小到大执行。如果序号相同，系统内部的处理顺序不一定每次都可控，所以最好主动给每条规则分配不重复的序号，并且留出间隔。我习惯用 10、20、30 这样的间隔编号，方便后续在中间插入新规则，不至于为了插一条规则把后面所有序号全部改一遍。

更隐蔽的问题是多条规则修改同一个字段的不同属性。比如规则 A 隐藏了字段 X，规则 B 又将它设为VISIBLE=TRUE，最终结果取决于 A 和 B 谁后执行。如果后执行的规则把前面规则的效果覆盖掉了，看起来就是“规则没生效”。所以排查“个性化无效”问题的时候，不要只盯着一两条规则看，要把当前表单所有命中规则按触发器梳理一遍，确认没有互相覆盖。

5.3 配置文件与个性化规则组合使用

个性化条件里可以调用FND_PROFILE.VALUE读取配置文件值，利用这个机制可以把个性化做成按组织或按业务类型自适应。比如同一个订单录入界面，不同库存组织使用不同默认仓库，规则可以写成：

:ORDER_LINES.SHIP_FROM_WAREHOUSE := FND_PROFILE.VALUE('WIP_WAREHOUSE');

这样系统上线新组织时，只需要维护配置文件，不用改个性化规则。把可变的参数放到配置文件里，把规则的逻辑固定下来，维护成本和出错概率都会明显下降。这也是我在项目里比较推荐的一种做法。

6. 实际项目中踩过的坑和排查链路

6.1 触发器选错导致默认值只生效一次

有次上线前测试，业务反馈“默认供应商第一次进入界面有，新增一行就消失了”。开发查了半天表单脚本，没发现问题。我一问，果然是经验不足的同事在设置默认值时选了WHEN-NEW-FORM-INSTANCE，规则只在进入表单时执行一次，后面新建记录不触发。

排查链路其实不复杂：先把规则里条件清空，看是否能稳定触发；开关几次表单，观察执行次数是否和预期一致；再换触发器事件测试。最后改成WHEN-NEW-RECORD-INSTANCE，问题立刻消失。这类问题之所以常见，是因为很多人对触发器时机的理解还停留在“大概差不多”的程度，没有逐个验证。

6.2 字段隐藏完，保存反而失败了

有一次给采购表单隐藏了一个“审批状态”字段，第二天业务就说单据都保存不了。因为该字段在标准 Form 的属性是必输项，隐藏之后用户看不到它，自然也不会去填，而底层校验仍然要求非空，于是每次保存都被卡住。

正确做法是：隐藏一个必输字段之前，先弄清楚它为什么必输。如果标准逻辑确实需要这个值，要么给它赋值一个默认值，要么同时把REQUIRED属性改成FALSE，要么在业务合理的前提下另找字段承载这个信息。这个检查步骤应该写在个性化配置的自查清单里，每次做隐藏操作都要过一遍。

6.3 多条规则互相覆盖，看起来像“没生效”

运维同事报过来一个问题：某个字段在职责 A 下可以正常显示，在职责 B 下被隐藏了，但配置里明明已经删掉了职责 B 的隐藏规则。后来查出来，站点级规则里还留着一份旧的隐藏规则，只是规则名称没有体现职责范围，当时配置的人自己都忘了。规则之间互相覆盖，正是“个性化没生效”的头号假象。

排查这个问题的标准动作，是按“站点级 -> 责任级 -> 用户级”逐级展开当前表单的全部规则，再按触发器筛选，画出同一字段上所有规则的影响链路。建议每个项目都建一个个性化规则台账，至少包含表单名、触发器、目标字段、属性、值、适用范围、配置日期、配置人、用途说明。规则少的时候台账看不出价值，规则超过几十条后，台账就是你排查问题的主心骨。

6.4 条件里引用错误的字段名，规则被静默忽略

有一回做接口字段联动，规则怎么都不生效。条件里写的是:HEADER.ATTR1 = 'Y'，但实际字段名是:HEADER.ATTRIBUTE1。保存规则时没有任何报错，运行时代码因为找不着字段，异常被 Forms 底层吃掉，整条规则被悄悄跳过。

之后我的做法是：所有条件里引用的字段，先用“帮助 -> 诊断 -> 检查”确认一遍内部名称，再进个性化界面里的下拉列表复核，绝对不靠记忆手敲字段名。如果规则确实不生效，我会先在条件处留一个恒真的表达式（比如1=1）测试规则本身能不能执行，逐层缩小范围。这样五分钟内就能定位是条件问题还是处理问题。

6.5 测试只做了“能进入”没做“能保存”造成生产事故

最后一个坑来自权限层面。曾经有个环境，个性化规则在生产上配置好了，业务打开表单也能看到效果，但点“保存”时提示无权修改。原因是生产环境把个性化功能的保存权限收紧到了指定职责，而配置人是拿系统管理员看到规则，以为保存成功，其实保存按钮点了也没写入。这个现象特别坑人，因为规则列表看起来是好的，界面也显示了预期效果，但数据库里根本没有这条规则。

所以我每次在生产配置完，都会做两个动作：第一，确认保存时没有权限报错，并重新打开规则看到刚才新增的记录还在；第二，在目标职责下登录，重新打开表单完整验证一次规则效果。保存动作本身不复杂，但因为在低权限环境下操作太顺手，反而容易被忽略。把“保存后重开确认”养成肌肉记忆，能避免很多事后救火。

最后说一点个人体会

用了这么多年个性化设置界面，我最大的感受是它被严重低估了。EBS 项目的持续运维阶段，真正需要写代码才能解决的问题远没有想象中多，大量需求都停留在界面字段级调整这个维度。把这套配置工具用好了，需求响应从“下周版本”变成“下午就好”，业务满意度提升非常明显。

最后分享一个小习惯：我配置每条规则时，规则名称都按“模块_表单_作用描述_配置日期”来命名，比如INV_ITEMS_隐藏版本字段_20240527。这样一年之后翻台账，看到名字就知道这条规则干什么用、哪一天加的，升级排查时一目了然。个性化设置界面本身不复杂，但把它当作一个长期维护的系统来管理，才能避免自由发挥带来的混乱。