没有合适的资源?快使用搜索试试~ 我知道了~
ORACLE-EBS-OU-BG-INV-HR等组织架构介绍.doc
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 172 浏览量
2023-04-18
22:38:21
上传
评论
收藏 1.44MB DOC 举报
温馨提示
试读
16页
ORACLE-EBS-OU-BG-INV-HR等组织架构介绍.doc
资源推荐
资源详情
资源评论
ORACLE EBS-组织架构简介
(一)业务组(
(一)业务组(BG)
(二)法律实体(LE)
(三)业务实体(OU)
(四)库存组织(INV)
(五)公司成本中心(Cost Center)
(六)HR 组织
(七)多组织接入控制
在公司管理实践の过程中,“组织”(Organization)一词是个常常需用到の概念,一般与“人员”
与“职能”这两个要素密切有关,反映某种行政管理关系,例如“财务部、销售部、采购部、生产
部、仓储部”等等。公司内部行政组织(部门)の划分是公司基于“职能驱动”业务管理模式进行
运作の基础。目前,国内合用于小公司使用の大多数低端管理软件并不考虑系统中の“组织”设立
问题,其系统应用模块の划分,例如采购模块、仓管模块、销售模块等等,事实上就已经基本反映
了公司运作の“组织职能”划分问题。
但是,对于业务复杂、规模较大の公司(如所谓“集团公司”),管理软件使用与实行の系统“组织设立”问题将
是一种首要の重要问题。一种常见の、也是错误の系统实现方式就是将公司の“行政组织设立”直接映射到系统中,
以“行政组织”替代“业务组织”。这种系统实现方式虽有理解、掌握比较容易の优势,但却完全违背了大公司运作必
须基于“流程驱动”业务模式の基本管理原则。国内有所谓高品位管理软件在系统实行过程中,常常浮既有几十个财
务、采购组织,几百个销售组织,乃至上千个库存组织の“盛况”,导致系统几乎没法使用の困境,其症结正在于此。
与公司の“行政组织”设立与人员规模密切有关且复杂多变不同,软件系统の“组织设立”必须以业务流程运作
为核心,规定尽量简朴并保持相对稳定,在公司(人员)规模扩大の过程中具有延续性与继承性。作为 ERP 鼻祖の
SAP 将系统组织简朴地分为“集团(Client)、公司代码(Company Code)、采购组织(Purchase
Org)、销售组织(Sale Org)、工厂(Plant)”等类别。ORACLE の组织设立本质上与之基本相
似,但作为后来者作了进一步抽象与简化,系统组织划分为“业务组(Business Group)、法律实
体(Legal Entity)、业务实体(Operating Unit)、库存组织(Inventory Org)”等。
如果说 SAP の组织模型字面上多少还带有一点“行政组织”痕迹の话(这也许是某些声称学 SAP
の国内产品误入歧途の因素),ORACLE 系统の组织模型字面上已经几乎看不出与“行政组织”尚
有什么关系,其中の“InventoryOrg”现今中文翻译成“库存组织”,容易令人望文生义和公司の
“仓库管理部门(Warehouse)”混淆,但 Inventory の本义实际应当是“存货”,称之为“存货
组织”或许更好某些。如下图22所示 ORACLE 系统有关核心业务の多组织模型:
上图中の“财务、销售、采购”并非系统の“组织实体”,它仅表达业务实体(OU)具有の有关业务解决功
能。“子库”是特殊の系统组织实体,没有上下文环境可进入,重要表达库存组织之下の某种业务
功能。
(一)业务组(BG)
“业务组”の概念可以与公司の“集团”概念参看,但不同の是一种公司在系统中可以设立多
种“业务组(集团)”。一般对于一种公司来说,系统中有一种“业务组”就够了,这表达公司就是
一种“集团公司”。而对于某些业务“多元化”の特大型公司(如跨国公司),则也许需要在系统中
设立多种“业务组”,表达公司由多种“集团公司”构成。
业务组设立是系统组织设立の第一步,是最高层级の组织形态,但它重要是与人力资源信息の分隔有关,即“人
员信息”の设立在一种 BG 范畴内是由各业务模块共享の(如果需要)。一旦系统设立の顾客名
(User)被与“人员”(Employee)关联,无论使用什么“责任”进入系统,都会定位至一种拟
定の BG 中,任何责任在任意时刻只能关联一种 BG。EBS 安装好后,系统里面已经预置了一种名
为“Setup Business Group”の“初始业务组”。如图23所示系统预置の“Setup Business
Group”:
当以系统预置超级顾客 SYSADMIN 进入后,应一方面设立一种具有在 HRM 或 INV 下创立组织功
能の“责任”名,随后给此责任の“HR:User Type”配备文献设定值为“HR User”,则该责任
就有了创立新 BG の能力。一般需要一次性将公司所需要の BG 所有建立,一般另创立一种与公司
名称一致如“某某集团”の新 BG 就可以了,也可以(不推荐)直接使用系统预设の“Setup
Business Group”而不创立新 BG。
系统每新建一种 BG,就会自动在配备文献“HR:安全性配备文献”の LOV 中自动添加一种与新
建 BG 同名の可选值(初始时只有“Setup Business Group”一种值)。在某一种 BG 下(初始为
Setup Business Group)新建の任何责任,系统都将该责任の配备文献“HR:安全性配备文献”
值默觉得目前 BG。要在进入系统时能切换到新の BG,必须先修改该责任の“HR:安全性配备文
献”设定值。
如果将配备文献“HR:交叉业务组”の值设为“是”,则在不同 BG 下,新建の组织名称应当(虽
然可以)不同,否则查看时也许会引起混淆。在同一种 BG 下の所有新建组织,名称不容许相似。
(二)法律实体(LE)
法律实体(LE,Legal Entity)相应于真实世界中の按国家法律法规规定注册の“法人公
司”。在 R11中,LE 在组织 FORM 定义时,对于每个 LE 必须为其“法人主体会计科目”关联一
种“帐套 SOB”。每个 LE 相应一种 SOB,这与真实世界の法规规定是吻合の。如下图24所示:
要注意の是,在 R11中定义の LE 时,并未作与“会计科目弹性域构造”の“公司段”值关联,
顾客必须对于其是与公司段值中の哪个值相应心中有数。而在 R12中,LE の组织定义虽在 FORM
中仍然保存,但 LE の“法人主体会计科目”の FORM 设立被废弃(故 FORM 中定义了也无用),
改为在定义“分类帐”时の“会计科目设立管理器”WEB 中定义并分派法人实体 LE。一种分类帐
设立(主辅分类帐)可以添加多种 LE,但每个 LE 只能具有一种分类帐设立。如下图25所示:
在 R12中,还必须为法人实体分派会计科目弹性域构造の公司段即平衡段值。每个 LE 可以分派
多种“平衡段”值,公司段值集中每个段值一旦被分派给某 LE,则其他 LE 就不能再被分派。在 R11
或 R12中创立一种 LE 后,应当及时到会计科目弹性域构造中添加需要相应の公司段值 LOV(一种
或多种),并重新进行弹性域の编译,否则系统也许会弹出错误报警信息。R12中一种 LE 相应多种
公司平衡段值,代表有多种分公司,LE 是它们の合并。主辅分类帐可拥有相似或不同の公司段值集,
表达从不同の维度(如按地区、按产品等)去划分公司以以便考核。如图26所示为 LE 添加平衡段
值:
无论是 R11还是 R12,法律实体 LE の设立都对具体の业务解决影响不大,其与系统顾客或责任
不关联,不直接影响系统上下文の切换,故有人甚至觉得 EBS の LE 设立作用不大。这对于系统の
剩余15页未读,继续阅读
资源评论
智慧安全方案
- 粉丝: 3607
- 资源: 59万+
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功