二是为已经定义子分类帐的应用模块分别针对主辅分类帐设置“子分类帐会计方法”，如下图15所示：
其中的“事件分类选项”及其相关设置是系统最基础、最复杂也是最抽象的
过程，包括了复杂的用户预定义工作，诸如会计事件分类（Event Class）与会
计事件类型（Event Type）组合定义、日记账行定义、日记账行类型定义等等。每个子分类帐应用产品的系统事务处理默认是基于主要分类帐的“代码组合”及其账户生成器规则，当子分类帐应用产品系统启动“向GL传送日记账”流程时，对于每个会计事件分类的“分类—类型”组合，流程将按照“子分类帐会计方法”中所包含的日记账行类型之“条件”与“账户推导规则”生成相应的“帐户代码”（CCID）及日记账行。不同的分类帐如主辅分类帐，生成的CCID可能不同，而这正是“多账簿”功能所需要的。有关“子分类帐会计方法”设置的详细过程需参照ORACLE相关文档。如下图16所示仅是其中的定义界面之一：
对于EBS R12来说，即使不使用辅助分类帐也要为“主要分类帐”添加“子
分类帐会计方法”，它可以使ORACLE预置默认的，也可以使用户修改后自定义的。实际上对于EBS R11来说，安装时相当于ORACLE为所有的SOB直接预置了
子分类帐会计方法，系统将复杂的子分类帐会计方法定义向用户屏蔽了，用户无法修改调整。
复杂的“子分类帐会计方法”定义是EBS R12为实现“多账簿”功能而必须付出
的代价。所幸的是它只对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所示：