EBS基础要点简介帐套分类帐.doc

18ORACLE EBS 基础设置要点简介三、帐套（分类帐）会计科目弹性域结构（COA）、币种（Currency）、日历（Clander）三者的组合构成EBS R11及之前系统的所谓“帐套”（SOB）。在R12中，再增加一个维度“会计方法或会计惯例”，即成为所谓“分类帐”。所谓“会计方法或惯例”，例如对于不同国家或地区、不同企业，会计法规可能规定物品单价5000元是作为“固定资产”还是“期间费用”处理的判定标准，也可能规定这个判定标准是1万元。标准不同，记账的会计科目也就不同，企业报告的经营结果也就会有差别。一个诸如在香港注册的企业，一方面需要向香港政府机关提交符合本地法规的财务报告，另一方面可能还需要向在国内的总公司提供符合国内法规的财务报告（便于考核管理），这就出现所谓“多账簿”（对应R12中的主辅分类帐）的系统功能问题。如下图9是EBS R11中“帐套”的定义接口：如下图10所示是EBS R12中使用“会计科目管理器AMB”设置“主要分类帐（Primary Ledger）”与“辅助分类帐（Second Ledger）”的定义接口：R12中定义的一个“主要分类帐”可以附带定义与之关联的多个“辅助分类帐”，如下图11所示：“主要分类帐”与“辅助分类帐”，可以有不同的科目表结构（COA）。由于系统其它的应用模块（R12中称之为“子分类帐应用产品”），例如PO/AP/AR等等，其事务处理默认是基于“主要分类帐”的会计科目表（COA），所以，如果主辅分类帐的科目表不同，则必须在两者之间建立“映射（Mapping）”关系（1对1或多对1的关系）。如下图12所示为主辅分类帐的映射定义界面，如果两者科目表相同（币种不同），则该定义界面将有所不同，没有“科目表”映射的内容，只有后面部分（币种转换及日记账转换等）： 下图13所示为当主辅分类帐的科目表不同时，系统科目表映射的定义界面，账户规则定义中可见，源账户可以是一个范围，而目标账户只能是一个：ORACLE EBS R12中四维（4C）定义的“分类帐Ledger”构成了ORACLE系统“多账簿”功能的处理基础。实际上，在R11中三维（3C）定义的“帐套SOB”也有“多报告币账簿”的概念，但那仅限于财务报表在不同币种之间的自动转换，并不是真正意义上的系统“多账簿”功能（即一个公司自动生成符合会计法规要求的多套帐）。ORACLE EBS R12“多账簿”功能的核心与关键是各相关应用模块（子分类帐应用产品）在向总账模块传送日记账时，如何自动为总账中的“主要分类帐和辅助分类帐”自动生成各自的日记账分录。这就涉及到分别为主辅分类帐设置图10中的 “子分类帐会计选项”的问题，它实际包括两个步骤，一是为系统定义哪些应用模块可以使用子分类帐会计方法（ORACLE已经预定义）；如下图14所示，系统已经预定义了包括PO/AP/AR/CST/FA等在内的21个需要用到子分类帐会计方法的应用产品：二是为已经定义子分类帐的应用模块分别针对主辅分类帐设置“子分类帐会计方法”，如下图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所示：配置文件“GL：数据访问权限集”的取值LOV需要在系统中另外设置，每个取值包含了若干已经定义的分类帐/分类帐集及其读写权限，用户进入后，可在FORM界面于其中选择切换，如下图20所示：要特别注意，对于R12的“GL 分类帐名称”的任何一次修改（包括清空），都会自动影响“GL：资料访问权限集”的值。系统之所以如此设计，目的在于保证原R11的业务控制功能不变，通过增加参数，在R12中控制“可访问数据的范围”。因此正确的做法应该是：先设定“GL 分类帐名称”的值，实现基本的业务功能（与子分类帐产品关联），再修改“GL：数据访问权限集”的默认值，控制数据可访问范围，但必须保证其值包含了前者的值。测试中发现，如果“GL 分类帐名称”配置文件值留空，而修改设定了“GL：资料访问权限集”，“GL：资料访问权限集”默认的分类帐并未出现在FORM的窗口接口中，这似乎是设计人员的疏忽。ORACLE GL 在“创建分类帐、定义分类帐集”时会自动创建“数据访问权限集”LOV值，并且其类型为“全部分类帐”，提供完整读写权限。在需要进一步限制对分类帐、分类帐集或分类帐/分类帐集的特定平衡段值或管理段值的读写权限时，用户需要创建自己的数据访问权限集。在R12中还可以为财务系统另外定义“访问权限集”（不同于参数“GL：数据访问权限集”），并分配给责任来限制该责任所具有的功能（当然这是在已经进入的当前分类帐之下的）。系统预置了一个“超级用户定义访问权限集”（不可修改）。推测“权限”的限制方式可能是“倒剥式”（为空时，权限最大，每增多一项，就少一个与之对应的权限），如下图21所示：最后需注意的是，EBS系统所谓“多账簿”功能与“多帐套（分类帐）接入”功能是两个不同的概念。“多账簿”菜单示“一个用户的同一业务处理，系统自动生成多本帐”，反映的是系统业务处理功能，R12具备，而R11不完全具备（R11仅能提供多币种报表）。“多帐套（分类帐）接入”菜单示“一个用户如何接入多个帐套（分类帐）”的权限管理方式（“上下文”环境切换方式），R11也具备，但对于同一用户，必须通过在具有相同业务功能的不同责任间切换才能实现，使用时不是太方便，而R12的同一用户，无需进行“责任”切换，仅通过在窗体上直接选择切换就能实现，使用比较方便。R12与R11的上下文切换方式虽然不同，但切换后的系统业务处理功能则基本相同。 -END