所定义“安全性配置文件”是系统用以控制包括“组织安全性”等在内的各种安全性控制的基础，它具体规定了系统安全性控制的范围与实现方式，所有定义的“安全性配置文件”Name构成系统多组织接入控制参数“MO：安全性配置文件”的LOV。如下图33所示：
EBS 通过“MO：业务实体”、“MO：安全性配置文件”、“MO：默认业务实体”这三个系统配置文件的共同作用，实现所谓“多组织接入”控制功能MOAC。但上述三个配置文件在R11与R12中的作用有比较大的差别。
对于“MO：业务实体”， 在R11中必须设定，而且起决定性控制作用，其LOV由系统基于创建的OU name自动创建，用户登录时系统自动定位于指定OU。而在R12中，一旦设定“MO：安全性配置文件”，则此配置文件失效而不起作用。
对于“MO：安全性配置文件”， 在R11中虽有，但实际不起OU接入的控制作用，只针对FA等模块的得某些应用如数据统计等起作用。因此，一般认为R11并不具有完善的多组织接入控制功能。在R12中，该参数如果不设定，则必须设定“MO：业务实体”参数；一旦该参数被设定，则就起决定作用，系统主要依赖其实现MOAC。
对于“MO：默认业务实体”， 在R11中虽有但实际不起作用。在R12中，随“MO：安全配置文件”起作用后才起作用，其LOV是所有已定义OU，但如果设定值不在“MO：安全配置文件”所选择的“组织层次架构”的范围内，则仍不起作用（即在与OU相关诸如PO、OM等的FORM界面，OU字段的默认值仍然为空）。这似乎是ORACLE 系统设计方面的一个难题，即“MO：默认业务实体”的LOV值集无法与“MO：安全性配置文件”中“组织层次架构”中的OU值范围保持一致。
ORACLE强调其“多组织接入MOAC”功能主要是针对业务实体OU而言，其另外一层含义是，所有构建于库存组织INV上的应用功能，实际是与上述配置文件无关的。库存组织的可接入性是在“组织访问”控制功能中，专门设定“库存组织”与“责任”的关联性，如下图34所示：
按照ORACLE的说法，如果系统在初始的时候，不定义库存组织的“组织访问”控制，则所有“责任”可访问所有INV，一旦限制或分配其中一个，则其余均必须逐个进行分配以建立“库存组织”与“责任”的链接关系。
总之，EBS系统通过“弹性域段值安全性”、“帐套/分类帐安全性”、“多组织接入安全性（MOAC）”、“库存组织访问控制”等多维度、多方面的组合系统设置，提供了灵活、方便的用户权限管理功能，厘清并掌握它们的复杂关系是系统实施的一项重要基础性工作。
基础数据通常是指与具体业务关系不大且具有全局性、基础性的一些基本数据，例如日历Calendar、币种Currency、汇率Rate、单位UOM、地点Location等等。这些基础数据的系统设置有些比较简单如“币种”，有些与真实世界的情况相似如“日历”，有些则可能比较抽象复杂如“地点”等等，情况多种多样。以下择其要者，作简要说明。
（一）关于“日历”。EBS中的日历设置，实际包括两大类，一类是与会计工作相关的，包括“会计日历”、“会计事务处理日历”等，它们的使用范围较小，有专门用途，一般是在总账模块设置（这里不赘述）。一类是工作日日历，它与企业的日常业务工作相关，使用范围广泛，大多数涉及库存组织的业务模块都可能与之相关，如下图35所示：
需要注意的是，在新设置工作日日历或更新已存在工作日日历后，需要通过在工具栏的“建立”功能启动一个后台并发程序，以最终完成设置工作。
（二）关于“币种”。各国或地区的“货币”是一种客观存在，EBS系统已经预置几乎所有企业可能使用到的币种，必要时还可以添加。用户可以决定哪些币种需要启用，以及维护其使用时的“精确度”。如下图36所示：
（三）关于“汇率”。企业对于不同币种汇率转换的管理是一项重要的基础性工作，它对企业的经营结果有重要影响。为方便该项工作的开展，EBS系统专门提供了一个名为“币种管理器”的工具，如下图37所示：
企业可以根据工作需要设定多个“汇率类型”（系统初始预置了Corporate值），并为之维护“每日汇率”或基于帐套的“期间汇率”。汇率的维护可以按一段时间范围来进行，也可以通过外部的“电子表格”导入数据。
（四）关于“单位”。计量单位虽然也可以看作是一种客观存在，但单位与基本单位之间的转换关系，则可能是与具体物料相关的（例如鸡蛋1斤=15个，鸭蛋1斤=10个等，转换系数不同）。由于EBS的物料是定义在库存组织INV上的，故单位及转换关系也是基于INV设置的。如下图38所示：
EBS的单位转换，提供了不考虑具体物料的“标准转换”，例如1米=100厘米等，也提供了基于不同物料的在同一“单位分类”（如长度、重量、体积等）内部的转换，例如牛奶 1箱=20盒，茶叶 1箱=10盒等；以及不同物料在不同“单位分类”之间的转换，例如牛奶 1公斤=4盒，茶叶 1公斤=2盒等。
（五）关于“地点”。EBS中所谓“地点”的概念不仅非常抽象，而且十分重要，因为系统相关业务处理功能如“接收、发运、人员分配”等等都与“地点”密切相关。EBS中的所谓“地点”原意实际上涉及三个词：Location、Address、Site。译成中文都可称“地点”，也是导致其理解困难的重要原因之一。如下图39所示：
Address（地址）比较好理解，它表示一个地理坐标概念，例如“北京市朝阳区安定路甲3号”等，EBS系统以一个“说明性弹性域”来精确描述，非常方便。各个国家的Address表述方式可能不同（如中国与美国有差别），故系统有所谓“中国式地址”、“美国式地址”之分等等。
Location（地点）的系统涵义则理解比较抽象，系统定义的名称可以看作是与一个具体Address相关联的一个或多个不同“称谓代号”，例如与上述Address“北京市朝阳区安定路甲3号”关联的Location“鸟巢、国家体育场、奥林匹克公园、奥运主会场”等等。也可以是一个不与具体地址Address相关联但大家都明白的称谓代号，例如Location“天安门、首都机场”等等。
EBS系统最初使用比较“简短”的Location代替比较“冗长”的Address，仅仅是为了方便IT“标准化”处理的需要。但在以后的发展过程中，系统设计逐步赋予Location更多与业务处理功能相关的“属性”，为了区分这些不同属性，系统以Site（站点）来加以区分，如图39中所示，一个Location可以具有“发运到Ship-to”、“接收至Receiving”、“开票到Bill-to”、“内部Internal”等等不同系统功用。
更进一步，EBS系统使用“地点”来实现采购申请、接收、运输清单和人员的分配，以及确定内部组织与内部客户、供应商的关联关系；使用同一供应商的不同Site来区分定义供应商所具有的不同“业务控制”属性；使用同一客户所具有的不同Location—Site组合来区分定义客户所具有的不同业务功能（OM的某些业务功能必须将客户的外部Address—Location组合与系统内部Location关联方才有效）等等；详情以后相关模块再进一步讨论。
总之，搞清楚EBS系统Address、Location、Site的三者关系，对于理解掌握系统功能十分重要，其核心与关键是不能将比较抽象的Location或Site与比较具体的Address等量齐观，两者虽有一定关系，但Location或Site更多地是从系统实现的需要出发，而做的某种“形而上”表达。
ORACLE EBS系统在后台通过运行大量“并发处理程序”的方式保证相关业务功能的实现，系统需要对这些在后台运行的“并发程序”进行有效管理，这是通过所谓“并发管理器”来实现的。系统后台可以有多个不同的“并发管理器”来管理不同的并发程序，“并发管理器”本身实际上也是并发程序，对于这些多个“并发管理器”，系统也要通过“管理并发管理器”功能进行有效管理。
系统内存在的所谓“并发管理器”按功用划分主要有三大类：内部监控程序、并发管理器、事务处理管理器。“内部监控程序”类型的管理器的功用是“监测处于并行并发处理环境下的内部并发管理器”。“并发管理器”类型的管理器的功用是“启动运行并发程序”；“ 事务处理管理器”类型的管理器的功用是“处理客户端用户发出的同步请求”。
系统在初始安装后，已经预置有若干不同类型的20多个管理器，系统也允许用户根据特殊需要自定义新的管理器。以下重点介绍几个重要的预置管理器的有关内容：
内部管理器。它充当所有其它管理器的“上层管理器”。内部管理器可以对单个管理器进行启动、验证其状态、重置以及关闭等操作。用户不能改变其定义（工作班次、特殊规则）。如下图40所示：
标准管理器。标准管理器可接受任何请求，它无特别的规定。标准管理器始终处于活动状态，即一年 365 天，一天 24 小时全天候工作。标准管理器可作为安全网使用，因为它始终可用于运行任何请求。其定义一般不可轻易更改，否则可能导致某些程序无法正常运行。如下图41所示：
事务处理管理器。常规并发管理器只允许“异步”执行运行时间长、数据密集的应用程序，而事务处理管理器则也支持“同步”处理客户机端发出的特定请求（并发程序请求运行计划的“立即”执行选项，本质上仍属于“异步”方式）。如果客户机程序发出同步运行服务器端程序的请求，则事务处理管理器会立即运行此请求，然后将状态返回至此客户机程序。事务处理管理器会等待由客户机程序发送信号，而不会轮询并发请求表来确定该如何执行操作。如下图42所示：
事务处理管理器（系统内部使用，“同步方式”）管理包括“物料事务处理、移动事务处理、资源成本事务处理、物料成本事务处理”的系统“联机”处理。系统在用户等待时“同步”作相关事务处理的处理，并且在完成后才将系统控制返回给用户。这在业务量较大、系统繁忙时，用户等待的时间可能较长，影响用户的工作效率。
事务处理管理器（请求使用，异步方式），如果相关配置文件“TP：INV 事务处理处理模式”设置为“并发”或“后台”模式，则用户应当启动“物料事务处理、移动事务处理、资源成本事务处理、物料成本事务处理”管理器于适当的“周期”运行状态。通常在事务处理工作量比较大时，应采取这种方式，以节省在库存管理系统锁定事务处理窗口和处理事务处理时所花费的空闲时间，提高用户的工作效率。
由于“事务处理”在整个EBS系统运行中的普遍性与重要性，系统为此提供了一个专门的界面功能（菜单项，非系统管理员也可授权使用）以满足对相关“事务处理”并发程序的管理监控（“启动管理器”的工作方式与提交“请求”类似），如下图43所示：
上述“事务处理管理器”所管理的事务处理并发程序（成本管理器等），每个系统只运行一个“实体”，为所有组织、用户服务，故系统设置必须对其运行方式进行恰当的“计划”。与之类似的重要系统事务处理并发程序还有“计划管理器”（受“MRP管理器”管理），“接收事务处理处理器”（受“接收事务处理管理器”管理）。
要注意的是，系统许多业务流程类的事务处理“并发程序” 由于承担的后台任务比较复杂，实际起着某种业务流程运作的管理作用，故习惯上也以“××管理器、××处理器”来命名，例如“计划管理器（控制计划系统有关预测冲减、需求冲减等等事项的自动程序，）、成本管理器（控制数据的自动计算与更新等等事项的自动程序）、接收事务处理处理器（控制PO接收的库存更新等事项的自动程序）”等等，不能与上一层的管理这些并发程序的所谓“并发管理器”相混淆。
“并发管理器”定义时需要用到的“工作班次”（系统初始已经预置值Standard），需要预先设置以作为LOV，工作班次可以同时运行的“流程数”在定义并发管理器时应设置适当值。如下图44所示：
“并发管理器”定义时需用到的“特殊规则”（系统初始无预置值），可直接输入“包括或排除”类型为“程序、请求类型、用户、ORACLE标识”的具体条目组合。这些条目的组合也可以事先定义为各种“组合规则”，供定义“并发管理器”时作为LOV调用。如下图45所示：
有关“并发程序”的运行计划及其“并发管理器”的定义工作，应当考虑系统的负载均衡，以保证系统的性能与运行效率。对于系统运行的所有“并发管理器”，系统管理员可以在“管理并发管理器”窗口进行干预、管理，如“终止、重新启动”，以及查看“并发管理器”正在管理的“哪些程序”正在运行等等。如下图46所示：
企业在系统使用过程中，基于业务变化发展得需要，不断地自定义开发各种“报表类”并发程序是一项重要的日常工作。这些自定义报表并发程序的系统管理方式没有什么特殊性，它可以使用系统预置的“并发管理器”进行管理，也可以自定义新的“并发管理器”。
对于EBS系统中处于各种运行状态的并发程序，系统管理员可以在“请求”窗口，通过设定不同查询选项（如特定请求之状态、阶段等等），查询监控相关“并发程序”的进程状况，并根据实际情况作出处理（如暂挂、重启、取消、诊断等等）。如下图47所示：
系统关于工作流的设置工作包含两部分工作，一是基于企业的特殊需要，使用Workflow Builder软件包工具自定义工作流。详情需参考ORACLE的相关文档，这里不赘述。二是为系统设置工作流管理员。系统在安装后的初始化工作流管理员是系统超级用户SYSADMIN，企业应当首先使用SYSADMIN进入系统，将工作流管理员改为一个真实的用户，或者输入“*”，则所有用户都“可以”具有工作流管理员权限（用户实际是否有工作流管理权限还必须取决于其被赋予的“责任”或“菜单”功能），如下图48所示：
实际具有工作流管理权限的用户在进入工作流管理“开发员工作室”TAB页后，可以查询出系统所有的“工作流类型”，可选择其一作具体设置，如下图49所示：
上图中，工作流管理员选定具体需设置的工作流后，点击“运行”则可以打开该工作流的“属性”设置界面（具体有哪些属性可设置，不同工作流各不相同），如下图50所示：
工作流管理员在工作流管理“状态监控程序”TAB页，可以监控选定工作流的具体运行情况的若干条目列表，针对每一个条目，可以查看其“活动历史记录、状态图、参与者回应、详细资料”等若干信息（必要时工作流管理员可实施干预，如更新属性、倒退、暂停、取消等等）。如下图51所示：
系统在各应用模块基于业务处理功能，预置有若干不同工作流，有关详情容以后结合具体业务模块应用再来讨论。以下重点介绍一个比较特殊的工作流：在多个业务模块中均需使用且系统实施必须事先完善设置的“账户生成器流程”。
传统的手工业务模式下，所有可能涉及会计记账处理的业务处理例如物料接收、发出等等，作为业务处理人员在日常工作过程中是不需要考虑如何记账的，只是需要将有关业务处理记录例如入库单、出库单等作为原始凭证提交给会计人员去做处理。会计人员依据这些原始凭证制作“记账凭证”并手工为之指定“会计科目”或“账户代码”，以便正确地向总账GL实施“过账”。
手工业务模式或会计电算化模式下，由于作为原始凭证的业务单据不包含准确的记账信息（会计科目或账户代码），需要会计人员手工去做处理，这在业务量很大，记账科目数量设置较多的情况下，会计人员的工作负担将十分繁重。再考虑人工处理难免有疏漏，可能需要反复“对账”，每月月底必须及时结账关账、时间紧迫等等因素，故非人工的、高度准确的“会计分录（日记账）”自动生成功能（即所谓“自动会计”）是系统设计时必须考虑解决的重要问题。
在EBS系统中，账户代码被扩展为一个包含多个段组合的会计科目弹性域结构，系统在业务流程类表单例如采购订单、发票等做业务处理时，依赖所谓“账户生成器流程”根据业务处理的自身属性，自动生成准确的帐户代码组合并记录于业务表单的相关字段中，如下图52所示采购申请界面每个申请行（分配）所对应的“会计账户”（弹性域结构）：