系列之五：ORACLE-EBS-系统主数据管理(J).doc

word完整版)系列之五：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层才有,Site层无）。R12的Account 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所定义的范围内可能是并不包括的.当企业的信息化应用达到一定层次后，除了核心业务系统需要使用到主数据之外,其它周边或外围系统也要用到主数据,而这些周边或外围系统与核心业务系统很可能是异构的(不同的技术平台、不同的应用环境等），故如何保证核心业务系统与外围或周边系统在主数据方面的协调一致就是一个重要问题。此时，建立一个独立的“企业主数据库”以及相应的主数据维护管理机制或应用系统（包括新增、修改、控制、发布、同步等等），就成为企业信息化规划与设计的一项重要工作。
正如笔者在“系列之二：ORACLE EBS系统架构与应用实践”中所谈到的，企业主数据管理的系统设计所关注的是一种由多个部门、多个人员共同参与的“事务过程",强调的是一种“管理集成"。企业通常需要根据自己的实际情况，确定合适的技术平台、设计合适的管理流程，选择合适的第三方产品或自行开发相关主数据管理应用系统,并保证系统具有足够的灵活性与可扩展性。
“企业主数据管理"是诸多著名咨询顾问公司向企业所提供服务的一项重要工作内容,通常会根据企业的实际情况,有着不同的解决方案。技术解决方案只是其中一方面，更重要的是管理集成的解决方案。某种程度上可以认为,企业主数据管理的水平与成熟度是企业信息化应用总体水平与成熟度的一个重要标志。