当前位置: 首页 > >

系列之五:ORACLE EBS 系统主数据管理(J)

发布时间:

系列之五:ORACLE EBS 系统主数据管理(J)
热度 3 已有 172 次阅读 2010/5/17 21:40 |系统分类::专业内容|关键词:EBS ORACLE 数据管理 系统
(二十)客户账户的“地址地点与业务目的”属性 二十)客户账户的“地址地点与业务目的” (二十一)R12 二十一)

客户的账户层与地点层属性

(二十二)客户数据的合并 二十二) (二十三)客户数据的其它管理功能 二十三)

五、结语

(二十)客户账户的“地址地点与业务目的”属性 二十)客户账户的“地址地点与业务目的”

每个客户账户 Account 可以有多个地址地点 Site(编号),每个地址地点 Site 的真实物理地址 Address 可以相同。每个地点可以有若干个不同的“用途 Usage”,每个用途有其对应的“地点 Location”(编号)。每个地址地点 Site 的不同“用途”还可以有其“详细资料、账户、订单管理”的附加属性(具体内 容取决于确定的“用途”),如下图 102 所示:

“用途”的 LOV 值是在 AR 系统的 Lookup Code 中定义的(访问级别“可扩 展”),系统预置了“收单方 Bill To”、“付款人 Drawee”、“收货方 Deliver To”、“收货方(1) Ship To”、“对账单 Statement”、“催款 Dunning”、“法 定 Legal”、“市场营销 Marketing”、“购货方 Sold To”、“发票 Invoice”、 “提单 Bills of Lading”、“信用联系人 Credit Contact”、“贷项通知单 Credit

Memos”、“确认 Acknowledgments”、“自助用户 Self Service User”的常用类 型的业务用途。 每个客户 Account 只能有一个“主要 Primary”且“有效 Active”的用途 Location。 并且, 每个客户 Account 只能有一个有效的“对账单 Statement”、 “催 款 Dunning”用途 Location。当用途为“收单方 Bill To”时,可以为之在附加属 性窗口“帐户”Tab 页中输入“收入、应收”等账户代码(主要供 AR 的“自动 会计”使用)。 当用途为“收货方(1) Ship To”时,可以为之选择一个“收单方 Bill To”的 Location。并且在附加属性窗口“详细资料”Tab 页中输入“内部地点”、“销 售人员”等。“内部地点”在定义“发运网络”、“在途时间”以及 OM 系统 计划发运时间时必须存在。如下图 103 所示:

上图中,每个“内部地点”只能被分配给唯一的“客户(地点)”,它还被 用于将“内部组织”与“(内部)客户”自动链接。“内部订单”或“公司间事 务流”功能使用相关业务表单中的“内部地点”, 自动寻找并将“内部组织”与 “内部客户”关联,以便生成内部订单或公司间发票。“税”区域,只有在“用 途”为收单方 Bill To,且“AR 系统选项”窗口“税务”标签区域中的“允许改 写”设置为“是”时,才可以在其中输入值。在此处输入的值将优先于在客户或 AR 系统选项层定义的值。 用途的附加属性 Tab 页“订单管理”的内容与客户账户层“订单管理”Tab 页内容完全相同,如下图 104 所示:

“订单管理”Tab 页中输入的值主要用于为 OM 系统的销售订单提供默认值。 在多组织环境下,其中的“订单类型”与“发运方法”字段,只能在客户账户地 点层而非客户账户层输入。其中的“仓库”实际是指“库存组织”。

(二十一)R12 二十一)

客户的账户层与地点层属性

R12 的账户层与账户地点层属性的内容及关系基本相同,区别仅在于账户地点 层与确定的业务实体 OU 关联。如下图 105 是 R12 的客户账户层 Web 界面:

R12 的属性 Tab 页分组方式与 R11 略有区别,其中的“附件”Tab 页在 R11 中位于工具栏的“附件” (也是仅在 Account 层才有, 层无) R12 的 Account Site 。 Site 层的属性 Tab 页内容也与 Account 层基本相似(比 R11 多了一个地点名称 Site Name 输入,未知有何用?),如下图 106 所示:

(二十二)客户数据的合并 二十二)

包括交易方合并与客户账户合并两方面内容,如下图 107 所示交易方合并操 作界面,建立“合并批”,将需合并的交易方设置好后,先保存再“运行批”启 动后台并发请求:

客户账户合并的情况稍复杂(R12 还增加了业务实体 OU 字段),如下图 108 所示客户账户合并界面:

“客户合并”功能可以合并相同客户账户的地点用途, 也可以合并两个不同客 户账户的所有地点用途。 但不管要合并的是不同客户账户还是相同客户账户的两 个地点,都只能将收单地点和收单地点合并,将收货地点和收货地点合并。在合 并成功完成之后,以前与原有客户账户或地点关联的所有活动,此时将与新的客 户账户或地点关联。这些活动包括订单、发票、借项通知单、承付款、贷项、收 款、调整和拖欠款项等。在合并流程完成之后,合并的原有客户账户和地点用途 将会处于“无效”状态。无效客户账户不能生成新的事务处理,但随时可以在 “客户”窗口中查看其信息或将其重新激活。

(二十三)客户数据的其它管理功能 二十三)客户数据的其它管理功能 EBS 的核心业务模块

OM/AR 所使用到的有关客户数据内容只是其中一部分,在 TCA 架构下,为了满足其他应用模块如 CRM 的需求,“客户数据管理”作为一 个为相关业务模块提供调用服务、已经独立的功能模块,在有关客户间关系、分 类、 合并字典、 数据质量管理、 第三方数据访问集成等方面还有诸多的系统设置, 如下图 109 所示的“管理”设置界面:

由于这些客户数据的有关管理设置与核心业务系统 OM/AR 一般应用的关系 不是太大,故这里不再赘述。此外,需要指出的是,与物料 Item 的创建有诸多 外围支持管理系统做支持, 供应商的创建与使用需要遵循严格的“准入”认证控 制流程不同的是, 客户的创建与生成基于“宽进严出”的原则, 则相对简单得多, 系统在多个相关业务模块如 OM/AR 以及 CRM 等提供快速录入的功能,体现的 是“多多益善”的管理思想(使用当然要注意风险控制)。

五、结语

必须指出的是,以上所讨论 ORACLE EBS 主数据的内容,其切入视角主要还 是限于 EBS 核心模块所涉及的业务或流程范畴。不同的行业、不同的企业以及 企业所处的信息化不同阶段,物料、客户、供应商主数据的有关内容通常有比较 大的差异,实际有些内容是在 EBS 所定义的范围内可能是并不包括的。当企业 的信息化应用达到一定层次后,除了核心业务系统需要使用到主数据之外,其它 周边或外围系统也要用到主数据, 而这些周边或外围系统与核心业务系统很可能 是异构的(不同的技术*台、不同的应用环境等),故如何保证核心业务系统与 外围或周边系统在主数据方面的协调一致就是一个重要问题。此时,建立一个独 立的“企业主数据库”以及相应的主数据维护管理机制或应用系统(包括新增、 修改、控制、发布、同步等等),就成为企业信息化规划与设计的一项重要工作。 EBS 系统架构与应用实践”中所谈到的,企业主 数据管理的系统设计所关注的是一种由多个部门、 多个人员共同参与的“事务过 程”,强调的是一种“管理集成”。企业通常需要根据自己的实际情况,确定合 适的技术*台、设计合适的管理流程,选择合适的第三方产品或自行开发相关主 数据管理应用系统,并保证系统具有足够的灵活性与可扩展性。
正如笔者在“系列之二:ORACLE “企业主数据管理”是诸多著名咨询顾问公司向企业所提供服务的一项重要工作内容, 通常会根 据企业的实际情况,有着不同的解决方案。技术解决方案只是其中一方面,更重要的是管理集成 的解决方案。 某种程度上可以认为, 企业主数据管理的水*与成熟度是企业信息化应用总体水* 与成熟度的一个重要标志。




友情链接: