系列之五ORACLE EBS 系统主数据管理J.docx

系列之五ORACLE EBS 系统主数据管理J.docx

《系列之五ORACLE EBS 系统主数据管理J.docx》由会员分享，可在线阅读，更多相关《系列之五ORACLE EBS 系统主数据管理J.docx（11页珍藏版）》请在冰豆网上搜索。

系列之五ORACLEEBS系统主数据管理J

系列之五ORACLEEBS系统主数据管理（J）

热度3已有172次阅读2010/5/1721:

40|系统分类：

:

专业内容|关键词:

EBSORACLE数据治理系统

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

（二十一）R12客户的账户层与地点层属性

（二十二）客户数据的合并

（二十三）客户数据的其它治理功能

五、结语

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

   每个客户账户Account能够有多个地址地点Site（编号），每个地址地点Site的真实物理地址Address能够相同。

每个地点能够有若干个不同的“用途Usage”，每个用途有其对应的“地点Location”（编号）。

每个地址地点Site的不同“用途”还能够有其“详细资料、账户、订单治理”的附加属性（具体内容取决于确定的“用途”），如下图102所示：

  “用途”的LOV值是在AR系统的LookupCode中定义的（访问级别“可扩展”），系统预置了“收单方BillTo”、“付款人Drawee”、“收货方DeliverTo”、“收货方

（1）ShipTo”、“对账单Statement”、“催款Dunning”、“法定Legal”、“市场营销Marketing”、“购货方SoldTo”、“发票Invoice”、“提单BillsofLading”、“信用联系人CreditContact”、“贷项通知单CreditMemos”、“确认Acknowledgments”、“自助用户SelfServiceUser”的常用类型的业务用途。

    每个客户Account只能有一个“要紧Primary”且“有效Active”的用途Location。

同时，每个客户Account只能有一个有效的“对账单Statement”、“催款Dunning”用途Location。

当用途为“收单方BillTo”时，能够为之在附加属性窗口“帐户”Tab页中输入“收入、应收”等账户代码（要紧供AR的“自动会计”使用）。

   当用途为“收货方

（1）ShipTo”时，能够为之选择一个“收单方BillTo”的Location。

同时在附加属性窗口“详细资料”Tab页中输入“内部地点”、“销售人员”等。

“内部地点”在定义“发运网络”、“在途时刻”以及OM系统打算发运时刻时必须存在。

如下图103所示：

    上图中，每个“内部地点”只能被分配给唯独的“客户（地点）”，它还被用于将“内部组织”与“（内部）客户”自动链接。

“内部订单”或“公司间事务流”功能使用相关业务表单中的“内部地点”，自动查找并将“内部组织”与“内部客户”关联，以便生成内部订单或公司间发票。

“税”区域，只有在“用途”为收单方BillTo，且“AR系统选项”窗口“税务”标签区域中的“承诺改写”设置为“是”时，才能够在其中输入值。

在此处输入的值将优先于在客户或AR系统选项层定义的值。

     用途的附加属性Tab页“订单治理”的内容与客户账户层“订单治理”Tab页内容完全相同，如下图104所示：

    “订单治理”Tab页中输入的值要紧用于为OM系统的销售订单提供默认值。

在多组织环境下，其中的“订单类型”与“发运方法”字段，只能在客户账户地点层而非客户账户层输入。

其中的“仓库”实际是指“库存组织”。

（二十一）R12客户的账户层与地点层属性

   R12的账户层与账户地点层属性的内容及关系差不多相同，区别仅在于账户地点层与确定的业务实体OU关联。

如下图105是R12的客户账户层Web界面：

    R12的属性Tab页分组方式与R11略有区别，其中的“附件”Tab页在R11中位于工具栏的“附件”（也是仅在Account层才有，Site层无）。

R12的AccountSite层的属性Tab页内容也与Account层差不多相似（比R11多了一个地点名称SiteName输入，未知有何用？

），如下图106所示：

（二十二）客户数据的合并

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

   客户账户合并的情形稍复杂（R12还增加了业务实体OU字段），如下图108所示客户账户合并界面：

   “客户合并”功能能够合并相同客户账户的地点用途，也能够合并两个不同客户账户的所有地点用途。

但不管要合并的是不同客户账户依旧相同客户账户的两个地点，都只能将收单地点和收单地点合并，将收货地点和收货地点合并。

在合并成功完成之后，往常与原有客户账户或地点关联的所有活动，现在将与新的客户账户或地点关联。

这些活动包括订单、发票、借项通知单、承付款、贷项、收款、调整和拖欠款项等。

在合并流程完成之后，合并的原有客户账户和地点用途将会处于“无效”状态。

无效客户账户不能生成新的事务处理，但随时能够在“客户”窗口中查看其信息或将其重新激活。

（二十三）客户数据的其它治理功能

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

    由于这些客户数据的有关治理设置与核心业务系统OM/AR一样应用的关系不是太大，故那个地点不再赘述。

此外，需要指出的是，与物料Item的创建有诸多外围支持治理系统做支持，供应商的创建与使用需要遵循严格的“准入”认证操纵流程不同的是，客户的创建与生成基于“宽进严出”的原则，则相对简单得多，系统在多个相关业务模块如OM/AR以及CRM等提供快速录入的功能，表达的是“多多益善”的治理思想（使用因此要注意风险操纵）。

五、结语

    必须指出的是，以上所讨论ORACLEEBS主数据的内容，其切入视角要紧依旧限于EBS核心模块所涉及的业务或流程范畴。

不同的行业、不同的企业以及企业所处的信息化不同时期，物料、客户、供应商主数据的有关内容通常有比较大的差异，实际有些内容是在EBS所定义的范畴内可能是并不包括的。

当企业的信息化应用达到一定层次后，除了核心业务系统需要使用到主数据之外，其它周边或外围系统也要用到主数据，而这些周边或外围系统与核心业务系统专门可能是异构的（不同的技术平台、不同的应用环境等），故如何保证核心业务系统与外围或周边系统在主数据方面的和谐一致确实是一个重要问题。

现在，建立一个独立的“企业主数据库”以及相应的主数据爱护治理机制或应用系统（包括新增、修改、操纵、公布、同步等等），就成为企业信息化规划与设计的一项重要工作。

正如笔者在“系列之二：

ORACLEEBS系统架构与应用实践”中所谈到的，企业主数据治理的系统设计所关注的是一种由多个部门、多个人员共同参与的“事务过程”，强调的是一种“治理集成”。

企业通常需要依照自己的实际情形，确定合适的技术平台、设计合适的治理流程，选择合适的第三方产品或自行开发相关主数据治理应用系统，并保证系统具有足够的灵活性与可扩展性。

“企业主数据治理”是诸多闻名咨询顾问公司向企业所提供服务的一项重要工作内容，通常会依照企业的实际情形，有着不同的解决方案。

技术解决方案只是其中一方面，更重要的是治理集成的解决方案。

某种程度上能够认为，企业主数据治理的水平与成熟度是企业信息化应用总体水平与成熟度的一个重要标志。