[分享知识 原创连载]浅谈EBS中系统架构的含义

U200916756

由于这周工作任务比较多，关于对EBS的个人认识和学习心得就之后再抽时间和大家分享了。那这周周末呢，就和大家分享搭建系统的首要工作吧，只有先把企业的组织结构了解清楚，清晰准确地在系统中实现，才能相继地搭建后续的业务和财务模块，例如，采购到应付模块，销售到应收模块。那企业的组织架构是如何在EBS中实现的呢，希望接下来相关的名词解释能帮助大家更好地理解，有不清楚或是有疑问的地方大家可以一起探讨探讨！
下面是一张简单的组织结构图，解释说明附在图下：

BG：
1.业务组是一个组织，可以代表集团、战略业务单元、利润中心或经营公司，是ORACLE EBS系统中所有组织的基础，但并不会对会计处理产生影响；
2.业务组主要是对人力资源信息与组织架构进行划分，不同业务组之间人力资源信息与组织架构信息是完全屏蔽的。如果在ORACLE EBS系统某个职责中查询员工信息，则只能查看该职责所属业务组的员工信息；
3.业务组代表ORACLE EBS系统多组织中的最高层次，例如多个法人主体可以与一个业务组关联。
HR：
1.人力资源（HR）组织是一个人力资源管理的组织，可以代表集团、战略业务单元、利润中心、经营公司或部门，并且不会对会计处理产生影响；
2.每一个员工都会属于一个人力资源组织；在EBS系统可以限制对不同人力资源组织员工信息的访问。
LE：
法人实体（LE）是通过法定主管部门注册来确定的实体，具有以下权利与责任：拥有财产(如资产、库存、应收款和其他类法人实体)，购买、销售、借款、雇佣。
Ledger:
1.分类帐（Ledger）在Oracle EBS系统中是最基本的概念，用来对会计信息进行划分，是会计信息最大的数据单位，所有的会计信息最终会归属到一个分类帐；
2.Oracle EBS总帐系统根据不同的目的可以定义多个分类帐，一个分类帐可以处理多个核算主体的账务；
3.分类帐是由会计科目结构、记帐本位币、会计期间和会计方法四个要素组成；
4.从理论上来说，在一个 Oracle Instance中，凡是具有相同的会计科目结构、记帐本位币、会计期间和会计方法的核算单位均可共享一个分类帐，仅需通过不同的会计科目结构中的平衡段进行区分；
5.分类帐可分为三种类型：主分类帐(Primary Ledger)、辅助分类帐(Secondary Ledger)和货币报告(Currency Report)；
6.一个法人实体归属于一个（仅一个）主分类帐，但可以有多个辅助分类帐和货币报告，例如公司在中国大陆经营，必须使用中国会计准则作为主分类帐进行法定报告，但作为香港上市公司需使用香港会计准则及港币作为本位币来披露上市监管报告。
OU:
1.业务实体（OU）与法人实体（LE）不同，业务实体从业务角度描述企业的组织方式。业务实体由企业自行决定，目的是为了优化经营；
2.在EBS系统中业务实体隶属于法人实体，一个法人实体可有一个或多个业务实体；
3.业务实体用于对子分类帐应用产品（如采购模块、应付模块、应收模块、销售订单模块）中的数据进行划分；
4.除了供应商题头记录和客户题头记录等特定数据外，应用产品的所有数据都可按业务实体划分；
5.每个业务实体都向一个（且仅向一个）主要分类帐传送数据，多个业务实体可以向一个分类帐传送数据。
INV:
1.库存组织（Inventory Organization）在EBS系统是用来划分库存材料和库存商品的组织；
2.可以按地点，也可以按产品系列来划分库存组织；
3.不同的库存组织可以采用不同的成本核算方法；
4.在EBS系统需要指定一个库存组织作为主组织来统一管理物料项目（ITEM）的类别、编号等物料属性；
5.库存组织隶属于业务实体，一个业务实体可有一个或多个库存组织。

下面是在EBS中如何搭建组织架构的详细步骤，大家对于如何而编写操作手册有更好的建议可以一起分享！

纵横四海

学习EBS，理解多组织概念是很关键的，很多多组织的概念是需要不断的理解和深入才会有很深刻的理解；你越到后面你的体会会越来越深刻；

tutula

我是个新手，最近就卡在这个地方了，除了在这里，找不到人交流，很是郁闷！

forward10

持续关注楼主的帖子，加油！

U200916756

关于EBS系统功能学习的一些“冠冕堂皇”的话



    大学毕业那一季，5月初开始了为期两个半月的EBS R12标准功能和项目实施的入职前培训，毕业后再过一个月，刺激又好玩的培训也落幕了。七月中下旬底直接上项目，现在的角色是Oracle FIN Consultant，个人背景也就不在次赘述了，点到为止吧！下面主要谈谈个人在学习EBS系统功能和上项目一个月以来的心得，比较零散，希望后期能抽出时间总结，将一些还不错的建议逻辑化，系统化！
    学习标准功能，不是单纯地学习系统知识，每完成一个功能点的学习，都要考虑系统这样设置的目的是什么，为什么要设置这样的一个功能点，这个功能点对应的实际业务需求是什么，在实务中，涉及到哪些岗位，每个岗位需要管控这个功能点的那些步骤，流程的每一步中会涉及到那些单据，单据的格式、有几联以及每一联的用途这些都是我们需要了解最好能熟练掌握的东西，这就是要求我们将实际业务需求和系统功能结合起来。
    在这里有个比较好玩的乙方需求，对于零售型企业的乙方，B2C的业务占主体，因为是面向“C”的客户，所以个性化服务和需求会比较多。在预收款的处理方式上，例如充值卡的业务，有些个人客户会要求给充值卡充值时就开发票，有些客户又不要求开发票。而乙方的应收会计是要求统一以发货确认收入，即只要销售时进行了发货在应收会计中就要确认收入（做“主营业务收入”等科目的入帐处理），这样应收处理的目的是由于实际中对发票开出的时点不好管控，有时候发票可能延迟一个月再开出，而有些客户不要求开出发票，所以与乙方需求以“发货”确认需求，而不以“开票”确认需求。由此看来预收款的处理分为“预收开票不确认收入，销售不开票确认收入”和“预收不开票不确认收入，销售开票确认收入”两种业务。对于“预收时不开票，销售时开票并确认收入”的系统处理方式为收到预收款，系统内录入收款（并核销到记账（根据习惯可选））；待发生销售时开票给客户，生成应收事务处理，出纳找到原预收账款（取消核销到记账），将其与发票进行核销，确认收入。而对于“预收时开票不确认收入，销售时不开票确认收入”的系统处理方式为收到预收款开票给客户，系统内做定金事务处理，即手工录入定金事务处理，对定金做收款，即收款后核销定金事务处理；待发生销售时，系生成应收事务处理，并核销定金，确认收入。
    所以每学完一个功能点，我们都可以按照“功能介绍-业务现状-需求分析（或难点）-解决方案-系统实现”来总结。说到系统功能，我们要非常熟悉操作流程，也要熟悉系统中每个界面的内容以及重要字段，这样给客户公司出方案的时候才不会对“系统功能能不能实现客户的需求，需不需要开发” 存在疑问（当然，也并不只有乙方才需要为此而发愁，在甲方做实施的时候应该同样会遇到这类情况），没有判断能力。所以对于字段和界面内容以及作用，也很有必要总结。在项目上总结是一项看似很简单实际却很巨大的“工程”。
    一开始做总结时，我们思路也许并不会很清晰，而且总结得不完善，不够系统，框架性不强，但慢慢的，随着所学习知识的深入，我们总结的内容会越来越完善。虽然有很多总结性文档，我还是建议自己做总结。因为每个人的逻辑思维方式不一样，别人的总结未必是适合你的。通过别人的总结学习，与自己学习自己总结，效果应该会有很大差别的，自己的方式往往是最适合自己的。当然，在总结的过程中我们可以不断学习和借鉴别人的亮点，编写自己的总结文档。
    PPT,Word,Excel,Viso-绘制流程图,Mind-manage-思维导图工具,都是一些很nice的总结工具，有些很适合锻炼我们的逻辑思维，对学习知识的系统性框架性的总结，例如Mind-manage，Excel；而关于业务流程的理解，我们可以通过绘制流程图来让自己更好的理解，例如 PPT，Viso工具。尤其是关于流程图的绘制，较于成片的文字说明，流程图是最能直观反映方案中业务流程或系统功能的方式，也是能最快最清晰让读者理解内容的方式。