EBS基础设置要点.docx

EBS基础设置要点.docx

《EBS基础设置要点.docx》由会员分享，可在线阅读，更多相关《EBS基础设置要点.docx（68页珍藏版）》请在冰豆网上搜索。

EBS基础设置要点

ORACLEEBS根底设置要点简介

一、安全性管理

从系统使用角度来看，系统管理的一项重要的日常工作是关于“用户〞与其“权限〞的管理，在ORACLE中即所谓“安全性〞〔Security〕管理。

“安全性〞是一个涵义较之“权限〞更为丰富、更为广阔的概念术语，它虽然比拟抽象，但顾名思义，它很好地涵盖了于实际业务与系统使用中，有关企业数据与信息管理的某些需要重点保护、控制的容。

有关用户权限的管理，在ORACLE系统中主要有三个根本要素构成：

菜单〔Menu〕、责任〔Responsibility〕、以与用户〔User〕。

三者的有机结合构成了系统权限或安全性管理的根底，辅之以参数或“安全性配置文件〞等的使用，如此进一步对用户的“实体〔组织、帐套或分类帐〕接入〞权限进展细分。

此外，系统在各个应用模块中，还将可能基于不同业务特点采取各具特色的系统实现方式，对用户的准入管理或功能权限作更进一步的划分〔具体方式与系统设计者的个人偏好也有一定关系，不能一概而论〕。

“菜单〞〔Menu〕在今天信息时代的日常生活中已是一个很普通的术语。

ORACLE中的“菜单〞概念并无甚特别，它也是表示用户的系统应用功能入口。

最根本的“菜单〞由系统预置的假如干“表单功能〞所组成，EBS目前大概具有2万个左右的此类表单功能；〔基于某些特殊需要，系统还可提供虽不可见但可由表单包含的逻辑调用的某些非表单“子功能〞，需开发后台设置〕。

用户可以自定义包括假如干根本菜单作为“子菜单〞的用户菜单，自定义的“用户菜单〞也可以作为“子菜单〞来使用，这样就形成了一个菜单结构〔树形图〕。

如图1所示菜单定义与可选择使用的系统预置表单功能LIST：

EBS系统在安装好后，针对每个应用模块均已经预定义包括所有功能〔或权限〕所谓的“超级用户菜单〞〔SuperUserMenu〕，企业〔系统管理员〕在定义用户“责任〞时可利用“排除法〞来满足实际的业务管理需要。

此外，系统还提供了“仅具查询〞功能的预定义菜单，供某些需要限制做业务的用户使用。

相较于“菜单〞的耳熟能详，EBS的所谓“责任〞〔Responsibility〕概念就生涩、抽象得多，通常可以将之与人们相对熟悉的“角色〞〔Role〕概念来参看。

在企业管理常会将人员按“岗位角色〞来划分，例如“计划员、采购员、仓管员〞等等，它们通常对应于一定的岗位职责〔责任〕，有真实的业务管理涵义，比拟具体。

系统预先定义的角色，分配给用户〔User〕后，该用户就具有该角色的全部应用功能；但EBS未象其它产品〔如SAP〕使用角色概念，而是使用“责任〞概念，如此更倾向于抽象地表示某些功能〔入口菜单〕的组合，可以不具有真实的管理涵义，比如所谓“销售经理〞责任之下，尽可以与“采购员〞有一样的菜单项，具有完全一样的功能，而这一点如对应到实际的“岗位角色〞，显然是不适宜的。

Role更清楚直接，但使用不够灵活；Responsibility可灵活使用，但容易带来理解上的歧义与误会，使用时要注意区分。

如如下图2所示的“责任〞定义界面：

每个责任必须对应关联一个确定的菜单，但可以使用“排除〞功能使之具有不同的菜单结构组合，这里的“排除〞功能并不影响菜单原先的结构设置，这方便并简化了系统管理员对“责任〞与“菜单〞的管理。

“责任名〞总是从属于某一“应用产品〞〔模块〕，不同的模块可定义具有完全一样的“责任名〞〔包括菜单〕，但这两个完全一样的责任名在“配置文件〞作层次结构设置时，可以具有不同的值，这进一步提供了系统的灵活性。

责任一经定义就不可删除，只能通过设置有效期使之失效。

为之设置“请求组〞如此限制了其可以使用的“请求〞〔并发程序〕围。

至于其“可采用〞应用产品围设置〔Web、自助等〕，似乎只起到统计分析的系统管理作用，实际并不影响具体的功能应用。

系统在安装后将具有一个名为“SYSADMIN〞〔密码sysadmin〕且具有“系统管理员〞责任的初始用户〔该用户有时也被称之为“超级管理员〞〕。

使用此初始用户可设置“菜单、责任与用户〞。

如如下图3所示“用户〞的定义界面：

每个定义的系统“用户〞可以关联假如干个不同的责任，每个责任也可以设定用户使用的有效日期围。

具有多个责任的用户在登录使用系统时，需要在不同责任间作选择切换，并非可以同时使用。

系统初始设置时设定的密码，在用户初次登录时，将被系统提示要求修改。

密码可以设定“使用天数〞或“访问次数〞的限制，系统的预警平台可以设置密码失效的提前预警，以督促用户与时修改。

“用户〞一经设置也无法删除，只能使用有效期设置使之失效。

“用户〞不一定必须和HRM模块设置的“人员〞关联，但对于有些模块的应用功能，关联已经HRM恰当设置的“人员〞如此是必须的。

而关联“客户〞或“供给商〞如此主要起到统计分析的系统管理作用，并不影响具体的功能应用。

用户所关联的“电子〞地址，主要是供系统预警平台发送信息使用。

关于EBS系统使用相关“配置文件〞诸如“MO:

业务实体、MO:

安全配置文件、HR:

安全配置文件、GL:

数据访问权限集、GL帐套名或GL分类帐名称〞等等，进一步对责任或用户的“实体接入〞权限进展细分的问题〔R12与R11比拟，变化较大〕，将在下面的“组织架构〞设置中讨论。

关于具体应用模块中对责任或用户的权限作更进一步划分问题，例如库存模块的“组织进入〞〔Access〕、发运模块的“权限管理〞〔Grant〕，容后在相关模块文档中再来讨论。

二、会计科目弹性域结构

在讨论EBS的“组织结构〞的设置之前，有必要先讨论会计科目弹性域〔AccountingFlexfield〕与其帐套〔SOB〕或分类帐〔Ledger〕的设置问题。

“帐套〞是R11与之前系统中的术语，“分类帐〞是R12中替代帐套并为有所区别而使用的术语。

为表述方便，后文如不特别指明，习惯上的“帐套〞术语将等同于“分类帐〞术语。

在EBS关于“组织实体〞的概念畴中，帐套实际上也是“组织实体〞的一种存在形式，之所以如此和ORACLE产品的开展历史有一定关系。

会计科目是企业进展财务数据核算工作的根底，各个国家基于企业监管与税收工作的需要而制定的会计法律法规都对之有相应规定。

我国于2006年颁布的新会计准如此将会计科目分为六大类：

资产类、负债类、共同类、所有者权益、本钱类、损益类，共计156个〔一级〕科目。

简单的财务会计软件或单公司规模很小时，类似手工记账的“电算化〞系统实现方式问题不大，但当会计业务管理需求复杂，企业从单公司向多公司集团化方向开展时，就必须考虑在系统层面如何方便地对多个公司的会计数据进展集中统一管理的问题。

ORACLE的ERP产品最初也是从财务软件开展起来的，总账GL是其第一个应用模块。

事实上，在计算机或管理软件出现以前，企业所谓“集团管控〞的需求与实践早已存在。

ORACLE财务软件中包含“多公司信息〞的独特会计科目弹性域结构设计，使得财务工作的集团管控更加具备技术上的可行性与方便性。

一个最根本、最简单的会计科目弹性域结构就是“公司代码+会计科目代码〞的组合，它的原始业务需求来源并无多少深奥之处。

在ORACLE的会计科目弹性域结构中，表现国家法律法规要求的“会计科目〞成为其中必不可少的一个组成段即“自然账户〞段，自然账户所使用的值集，即为通常所说的“科目表〞。

系统在自然账户之上附加“公司、部门〞等多个段信息，大大方便了在公司与公司间的会计数据的统计分析工作。

如图4所示，就是一个典型的5段式会计科目弹性域结构：

图中的“公司段〞为“平衡段〞〔弹性域限定词FlexfieldQualifiers，是具有某种特定属性的“识别标记〞〕，表示在“公司段〞层面，日记账〔Journals，“会计分录〞〕的“借项等于贷项〞，总是平衡的。

其值集为包含所有公司的代码LOV，包括法律实体与基于公司管理需要而设定的运营实体；如图5所示会计科目弹性域结构的“公司段〞值集定义：

在EBS系统中定义的法律实体LE必须对应于公司段值集中的〔至少〕一个值〔行〕，但R11与R12的区别是，R11在定义LE时并没有明确告诉系统对应〔绑定〕哪个段值，只要用户自己清楚并不混淆即可。

而在R12定义LE时，需要将其与会计科目弹性域结构中的某个公司段值明确关联，这是R12的改良之处，防止了R11实际使用中当定义的法律实体LE数量较多时可能产生的混淆不清。

“部门段〞的弹性域限定词为“本钱中心段〞，本钱中心LOV值可能是企业中的一个具体行政组织，也可能表示共享一个本钱中心的多个行政组织的组合，还可能是表示基于统计管理需要而设定的多个本钱中心的组合；如如下图6所示：

“账户段〞的弹性域限定词为“自然账户段〞，其LOV值即法定科目表与为统计需要而设置的汇总科目；如图7所示：

注意，图7与图5、6中的“段限定词〞的容有所不同，它具体规定了自然账户的段值所代表的会计科目的类别〔资产、负债等〕，“弹性域限定词〞与“段限定词〞是两个不同的概念，段限定词的取值受控于弹性域限定词的取值。

会计科目弹性域结构的“子账户段〞表示“二级科目或明细科目〞，与账户段的一级科目具有汇总与被汇总的关系；“产品段〞，如此表示基于特定统计分析需要而设置的产品LOV。

系统允许设置最多30个段，但必须至少包含两个段〔平衡段、自然账户段〕。

由于会计科目弹性域结构一经设定并使用之后，以后修改比拟困难，故通常会设定一个或多个预留段，如可在上述典型的5段结构之外再增加一个暂时不使用的段〔预留段〕而成为6段结构。

会计科目弹性域结构的设定是系统根底设置的重要工作之一，有关详细设置方法与步骤请参看相关系统设置文档。

此外，EBS系统针对所有弹性域的“段值〞的接入权限，提供了“安全性〞设置功能，控制“责任〞实际可以使用的段值围，如如下图8所示：

三、帐套〔分类帐〕

会计科目弹性域结构〔COA〕、币种〔Currency〕、日历〔Clander〕三者的组合构成EBSR11与之前系统的所谓“帐套〞〔SOB〕。

在R12中，再增加一个维度“会计方法或会计惯例〞，即成为所谓“分类帐〞。

所谓“会计方法或惯例〞，例如对于不同国家或地区、不同企业，会计法规可能规定物品单价5000元是作为“固定资产〞还是“期间费用〞处理的判定标准，也可能规定这个判定标准是1万元。

标准不同，记账的会计科目也就不同，企业报告的经营结果也就会有差异。

一个诸如在注册的企业，一方面需要向政府机关提交符合本地法规的财务报告，另一方面可能还需要向在国的总公司提供符合国法规的财务报告〔便于考核管理〕，这就出现所谓“多账簿〞〔对应R12中的主辅分类帐〕的系统功能问题。

如如下图9是EBSR11中“帐套〞的定义界面：

如如下图10所示是EBSR12中使用“会计科目管理器AMB〞设置“主要分类帐〔PrimaryLedger〕〞与“辅助分类帐〔SecondLedger〕〞的定义界面：

R12中定义的一个“主要分类帐〞可以附带定义与之关联的多个“辅助分类帐〞，如如下图11所示：

“主要分类帐〞与“辅助分类帐〞，可以有不同的科目表结构〔COA〕。

由于系统其它的应用模块〔R12中称之为“子分类帐应用产品〞〕，例如PO/AP/AR等等，其事务处理默认是基于“主要分类帐〞的会计科目表〔COA〕，所以，如果主辅分类帐的科目表不同，如此必须在两者之间建立“映射〔Mapping〕〞关系〔1对1或多对1的关系〕。

如如下图12所示为主辅分类帐的映射定义界面，如果两者科目表一样〔币种不同〕，如此该定义界面将有所不同，没有“科目表〞映射的容，只有后面局部〔币种转换与日记账转换等〕：

如下图13所示为当主辅分类帐的科目表不同时，系统科目表映射的定义界面，账户规如此定义中可见，源账户可以是一个围，而目标账户只能是一个：

ORACLEEBSR12中四维〔4C〕定义的“分类帐Ledger〞构成了ORACLE系统“多账簿〞功能的处理根底。

实际上，在R11中三维〔3C〕定义的“帐套SOB〞也有“多报告币账簿〞的概念，但那仅限于财务报表在不同币种之间的自动转换，并不是真正意义上的系统“多账簿〞功能〔即一个公司自动生成符合会计法规要求的多套帐〕。

ORACLEEBSR12“多账簿〞功能的核心与关键是各相关应用模块〔子分类帐应用产品〕在向总账模块传送日记账时，如何自动为总账中的“主要分类帐和辅助分类帐〞自动生成各自的日记账分录。

这就涉与到分别为主辅分类帐设置图10中的“子分类帐会计选项〞的问题，它实际包括两个步骤，一是为系统定义哪些应用模块可以使用子分类帐会计方法〔ORACLE已经预定义〕；如如下图14所示，系统已经预定义了包括PO/AP/AR/CST/FA等在的21个需要用到子分类帐会计方法的应用产品：

二是为已经定义子分类帐的应用模块分别针对主辅分类帐设置“子分类帐会计方法〞，如如下图15所示：

其中的“事件分类选项〞与其相关设置是系统最根底、最复杂也是最抽象的过程，包括了复杂的用户预定义工作，诸如会计事件分类〔EventClass〕与会计事件类型〔EventType〕组合定义、日记账行定义、日记账行类型定义等等。

每个子分类帐应用产品的系统事务处理默认是基于主要分类帐的“代码组合〞与其账户生成器规如此，当子分类帐应用产品系统启动“向GL传送日记账〞流程时，对于每个会计事件分类的“分类—类型〞组合，流程将按照“子分类帐会计方法〞中所包含的日记账行类型之“条件〞与“账户推导规如此〞生成相应的“代码〞〔CCID〕与日记账行。

不同的分类帐如主辅分类帐，生成的CCID可能不同，而这正是“多账簿〞功能所需要的。

有关“子分类帐会计方法〞设置的详细过程需参照ORACLE相关文档。

如如下图16所示仅是其中的定义界面之一：

对于EBSR12来说，即使不使用辅助分类帐也要为“主要分类帐〞添加“子分类帐会计方法〞，它可以使ORACLE预置默认的，也可以使用户修改后自定义的。

实际上对于EBSR11来说，安装时相当于ORACLE为所有的SOB直接预置了子分类帐会计方法，系统将复杂的子分类帐会计方法定义向用户屏蔽了，用户无法修改调整。

复杂的“子分类帐会计方法〞定义是EBSR12为实现“多账簿〞功能而必须付出的代价。

所幸的是它只对GL模块的使用有一定影响，对各相关应用模块的用户使用并无直接影响，从R11到R12，“多账簿〞功能只相当于多调用了一个“服务〞，EBS系统升级与使用保持了良好的继承性。

在EBS的总账GL模块中，由于工作的对象主要是基于“账户代码〞的日记账〔会计分录〕的数据信息，来自各业务模块的有关不同公司的会计数据的“组织属性〞实际上通过账户代码中的不同公司段值已经得到表现，与各来源业务模块〔子分类帐应用产品〕中的相关“〔业务〕组织属性〞设置无关。

故总账模块与其它业务模块比拟，总账模块无需再作所谓“组织〞的划分，可说是“无组织〞的。

总账系统用户一般来说可以处理所有公司的会计数据〔除非作弹性域段值的安全性设置〕。

如果一定要说总账GL也有类似业务组织属性划分的话，那么这个“组织实体〞就是帐套或分类帐，系统将使用类似业务模块的“组织接入〞配置文件〔如“MO：

业务实体〞〕的“帐套接入〞配置文件〔例如R11的“GL帐套名〞或R12的“GL：

数据访问权限集〞、“GL分类帐名称〞等〕，来分隔用户的工作权限。

有关“帐套接入〞配置文件的使用有下述须知事项。

对于配置文件“GL帐套名〞，R11中该参数的LOV由系统基于创建的SOB名自动创建，一旦为其赋值后，用户登录时系统自动定位于已指定SOB。

由于GL模块与OU无关，所以进入GL后，数据的区隔主要基于这个参数，但这个参数并不限制某些需要跨SOB功能如FSG对数据的访问。

如如下图17所示：

对于配置文件“GL分类帐名称〞，该参数只在R12中有，类似R11中的“GL帐套名〞，但作用与R11大不一样，其LOV为分类帐名的集合〔创建时自动添加〕，只表示当前用户所进入的该“分类帐〞同时还需要用到子分类帐产品诸如AP/AR等等。

如如下图18所示〔而当前用户所能够进入的分类帐如此是由“GL：

数据访问权限集〞控制〕：

对于配置文件“GL：

数据访问权限集〞，该参数只在R12中才有，必须设置〔有值〕，否如此系统会报错。

但是系统给出了特别控制机制，即在每当修改设置“GL分类帐名称〞时，系统会同时自动修改“GL：

数据访问权限集〞的值，使之与“GL分类帐名称〞的值一致。

如果是先设置“GL分类帐名称〞，后修改了“GL：

数据访问权限集〞的默认值，如此系统在进入日记账的FORM时，如果后者的值不包含前者的值，如此前者的设置被无效，但系统无法使用相关子分类帐产品。

如果后者的值包含前者的值，如此前者的值代表该分类帐还需要使用相关子分类帐产品。

如如下图19所示：

配置文件“GL：

数据访问权限集〞的取值LOV需要在系统中另外设置，每个取值包含了假如干已经定义的分类帐/分类帐集与其读写权限，用户进入后，可在FORM界面于其中选择切换，如如下图20所示：

要特别注意，对于R12的“GL分类帐名称〞的任何一次修改〔包括清空〕，都会自动影响“GL：

数据访问权限集〞的值。

系统之所以如此设计，目的在于保证原R11的业务控制功能不变，通过增加参数，在R12中控制“可访问数据的围〞。

因此正确的做法应该是：

先设定“GL分类帐名称〞的值，实现根本的业务功能〔与子分类帐产品关联〕，再修改“GL：

数据访问权限集〞的默认值，控制数据可访问围，但必须保证其值包含了前者的值。

测试中发现，如果“GL分类帐名称〞配置文件值留空，而修改设定了“GL：

数据访问权限集〞，“GL：

数据访问权限集〞默认的分类帐并未出现在FORM的窗口界面中，这似乎是设计人员的疏忽。

ORACLEGL在“创建分类帐、定义分类帐集〞时会自动创建“数据访问权限集〞LOV值，并且其类型为“全局部类帐〞，提供完整读写权限。

在需要进一步限制对分类帐、分类帐集或分类帐/分类帐集的特定平衡段值或管理段值的读写权限时，用户需要创建自己的数据访问权限集。

在R12中还可以为财务系统另外定义“访问权限集〞〔不同于参数“GL：

数据访问权限集〞〕，并分配给责任来限制该责任所具有的功能〔当然这是在已经进入的当前分类帐之下的〕。

系统预置了一个“超级用户定义访问权限集〞〔不可修改〕。

推测“权限〞的限制方式可能是“倒剥式〞〔为空时，权限最大，每增多一项，就少一个与之对应的权限〕，如如下图21所示：

最后需注意的是，EBS系统所谓“多账簿〞功能与“多帐套〔分类帐〕接入〞功能是两个不同的概念。

“多账簿〞功能表示“一个用户的同一业务处理，系统自动生成多本帐〞，反映的是系统业务处理功能，R12具备，而R11不完全具备〔R11仅能提供多币种报表〕。

“多帐套〔分类帐〕接入〞功能表示“一个用户如何接入多个帐套〔分类帐〕〞的权限管理方式〔“上下文〞环境切换方式〕，R11也具备，但对于同一用户，必须通过在具有一样业务功能的不同责任间切换才能实现，使用时不是太方便，而R12的同一用户，无需进展“责任〞切换，仅通过在表单上直接选择切换就能实现，使用比拟方便。

R12与R11的上下文切换方式虽然不同，但切换后的系统业务处理功能如此根本一样。

四、组织架构

在企业管理实践的过程中，“组织〞〔Organization〕一词是个经常需用到的概念，一般与“人员〞与“职能〞这两个要素密切相关，反映某种行政管理关系，例如“财务部、销售部、采购部、生产部、仓储部〞等等。

企业部行政组织〔部门〕的划分是企业基于“职能驱动〞业务管理模式进展运作的根底。

目前，国适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织〞设置问题，其系统应用模块的划分，例如采购模块、仓管模块、销售模块等等，实际上就已经根本反映了企业运作的“组织职能〞划分问题。

但是，对于业务复杂、规模较大的企业〔如所谓“集团企业〞〕，管理软件使用与实施的系统“组织设置〞问题将是一个首要的重要问题。

一个常见的、也是错误的系统实现方式就是将企业的“行政组织设置〞直接映射到系统中，以“行政组织〞代替“业务组织〞。

这种系统实现方式虽有理解、掌握比拟容易的优势，但却完全违背了大企业运作必须基于“流程驱动〞业务模式的根本管理原如此。

国有所谓高端管理软件在系统实施过程中，常常出现有几十个财务、采购组织，几百个销售组织，乃至上千个库存组织的“盛况〞，导致系统几乎没法使用的困境，其症结正在于此。

与企业的“行政组织〞设置与人员规模密切相关且复杂多变不同，软件系统的“组织设置〞必须以业务流程运作为核心，要求尽可能简单并保持相对稳定，在公司〔人员〕规模扩大的过程中具有延续性与继承性。

作为ERP鼻祖的SAP将系统组织简单地分为“集团〔Client〕、公司代码〔panyCode〕、采购组织〔PurchaseOrg〕、销售组织〔SaleOrg〕、工厂〔Plant〕〞等类别。

ORACLE的组织设置本质上与之根本相似，但作为后来者作了进一步抽象与简化，系统组织划分为“业务组〔BusinessGroup〕、法律实体〔LegalEntity〕、业务实体〔OperatingUnit〕、库存组织〔InventoryOrg〕〞等。

如果说SAP的组织模型字面上多少还带有一点“行政组织〞痕迹的话〔这可能是某些声称学SAP的国产品误入歧途的原因〕，ORACLE系统的组织模型字面上已经几乎看不出与“行政组织〞还有什么关系，其中的“InventoryOrg〞现今中文翻译成“库存组织〞，容易令人望文生义和企业的“仓库管理部门〔Warehouse〕〞混淆，但Inventory的本义实际应该是“存货〞，称之为“存货组织〞或许更好一些。

如如下图22所示ORACLE系统有关核心业务的多组织模型：

上图中的“财务、销售、采购〞并非系统的“组织实体〞，它仅表示业务实体〔OU〕具有的相关业务处理功能。

“子库〞是特殊的系统组织实体，没有上下文环境可进入，主要表示库存组织之下的某种业务功能。

〔一〕业务组〔BG〕

“业务组〞的概念可以与企业的“集团〞概念参看，但不同的是一个企业在系统中可以设置多个“业务组〔集团〕〞。

通常对于一个企业来说，系统中有一个“业务组〞就够了，这表示企业就是一个“集团公司〞。

而对于某些业务“多元化〞的特大型公司〔如跨国公司〕，如此可能需要在系统中设置多个“业务组〞，表示企业由多个“集团公司〞组成。

业务组设置是系统组织设置的第一步，是最高层级的组织形态，但它主要是与人力资源信息的分隔有关，即“人员信息〞的设置在一个BG围是由各业务模块共享的〔如果需要〕。

一旦系统设置的用户名〔User〕被与“人员〞〔Employee〕关联，无论使用什么“责任〞进入系统，都会定位至一个确定的BG中，任何责任在任意时刻只能关联一个BG。

EBS安装好后，系统里面已经预置了一个名为“SetupBusinessGroup〞的“初始业务组〞。

如图23所示系统预置的“SetupBusinessGroup〞：

当以系统预置超级用户SYSADMIN进入后，应首先设置一个具有在HRM或INV下创建组织功能的“责任〞名，随后给此责任的“HR：

UserType〞配置文件设定值为“HRUser〞，如此该责任就有了创建新BG的能力。

通常需要一次性将企业所需要的BG全部建立，一般另创建一个与企业名称一致如“某某集团〞的新BG就可以了，也可以〔不推荐〕直接使用系统预设的“SetupBusinessGroup〞而不创建新BG。

系统每新建一个BG，就会自动在配置文件“HR：

安全性配置文件〞的LOV中自动添加一个与新建BG同名的可选值〔初始时只有“SetupBusinessGroup〞一个值〕。

在某一个BG下〔初始为SetupBusinessGroup〕新建的任何责任，系统都将该责任的配置文件“HR：

安全性配置文件〞值默认为当前BG。

要在进入系统时能切换到新的BG，必须先修改该