Oracle ERP 2010-08-11 10:22:47 閱讀13 評(píng)論0 字號(hào)：大中小 訂閱
ORACLE EBS 系統(tǒng)主數(shù)據(jù)管理
（十三）客戶賬戶與地點(diǎn)層的“聯(lián)系人”分組屬性
（十四）客戶賬戶與地點(diǎn)層的“聯(lián)系人：職責(zé)”分組屬性
（十七）客戶賬戶與地點(diǎn)層的“配置文件：事務(wù)處理”分組屬性
（十八）客戶賬戶與地點(diǎn)層的“配置文件：單據(jù)打印”分組屬性
（十九）客戶賬戶與地點(diǎn)層的“配置文件：金額”分組屬性
（二十）客戶賬戶的“地址地點(diǎn)與業(yè)務(wù)目的”屬性
（二十二）客戶數(shù)據(jù)的合并
（二十三）客戶數(shù)據(jù)的其它管理功能
客戶是企業(yè)提供產(chǎn)品與服務(wù)的對(duì)象，是企業(yè)的衣食父母，是企業(yè)存在的前提條件。在當(dāng)今世界經(jīng)濟(jì)全球化、一體化，市場(chǎng)競爭日益充分、激烈的大背景下，如何滿足客戶需求，為客戶提供周到、細(xì)致的服務(wù)，是企業(yè)經(jīng)營管理活動(dòng)的頭等大事。因此，在企業(yè)信息化實(shí)踐方面，相較于最近幾年才逐漸得到更多重視的供應(yīng)商關(guān)系管理系統(tǒng)SRM，企業(yè)的客戶關(guān)系管理系統(tǒng)CRM的發(fā)展歷史淵源要早得多，產(chǎn)品的發(fā)展現(xiàn)狀也豐富、完善得多。習(xí)慣上，人們很早就已經(jīng)將CRM與傳統(tǒng)的ERP看作是屬于前后臺(tái)（Front-Office、Back-Office）范疇，可以相提并論，具有一定獨(dú)立性的兩大產(chǎn)品。
任何企業(yè)在市場(chǎng)環(huán)境中總是同時(shí)扮演著“供應(yīng)商與客戶”兩種角色，作為“客戶”角色，要管理好自己的“供應(yīng)商”，這屬于SRM產(chǎn)品的范疇；作為“供應(yīng)商”，要對(duì)自己的“客戶”進(jìn)行有效管理，這屬于CRM產(chǎn)品的范疇。無論屬于哪種角色，都存在著所謂“供應(yīng)商與客戶”的競爭關(guān)系，但是在市場(chǎng)競爭的環(huán)境中，作為“供應(yīng)商的客戶”與作為“客戶的供應(yīng)商”兩者所處的競爭地位與競爭優(yōu)勢(shì)是截然不同的，存在著明顯的強(qiáng)弱差距。這一差距反映到企業(yè)管理實(shí)踐與SRM/CRM產(chǎn)品的系統(tǒng)設(shè)計(jì)上，也會(huì)表現(xiàn)出鮮明的特點(diǎn)。
在企業(yè)管理實(shí)踐中，企業(yè)對(duì)于供應(yīng)商的管理，通常會(huì)采取“嚴(yán)進(jìn)寬出”的總體策略，管理的重點(diǎn)放在供應(yīng)商的“準(zhǔn)入”資格認(rèn)證過程管理，以及使用中的績效考核管理上。而企業(yè)對(duì)于客戶的管理，則通常會(huì)采取“寬進(jìn)嚴(yán)出”的總體策略，管理的重點(diǎn)放在客戶的信息收集與挖掘管理，以及使用中的風(fēng)險(xiǎn)控制管理上。企業(yè)管理實(shí)踐這一根本性的策略差別，使得系統(tǒng)在供應(yīng)商與客戶的主數(shù)據(jù)管理的內(nèi)容方面差別較大，客戶主數(shù)據(jù)管理的復(fù)雜性與靈活性要求要明顯高于供應(yīng)商主數(shù)據(jù)。推而廣之，使用供應(yīng)商主數(shù)據(jù)的業(yè)務(wù)模塊如PO系統(tǒng)，使用客戶主數(shù)據(jù)的業(yè)務(wù)模塊如OM系統(tǒng)，其復(fù)雜性也會(huì)有很大不同。有經(jīng)驗(yàn)數(shù)據(jù)表明，PO與OM在系統(tǒng)實(shí)施上的相對(duì)困難程度比較是120：170。
盡管對(duì)于一個(gè)確定的企業(yè)來說，其所具有的客戶范疇可能并不復(fù)雜，例如有些生產(chǎn)專業(yè)儀器設(shè)備的企業(yè)，其客戶面可能很窄，客戶數(shù)量也很有限，但作為一個(gè)通用的、需要適應(yīng)各行各業(yè)需要的CRM/ERP產(chǎn)品，其客戶主數(shù)據(jù)所要考慮的因素，其所必須具有的靈活性與適應(yīng)性就異常復(fù)雜了。有些企業(yè)的客戶可能是政府機(jī)關(guān)、公用事業(yè)單位、生產(chǎn)制造企業(yè)、服務(wù)業(yè)、分銷商、零售商、個(gè)人消費(fèi)者等等，情況千差萬別。若從信息系統(tǒng)設(shè)計(jì)與管理的角度去考察，客戶主數(shù)據(jù)需要重點(diǎn)考慮以下幾種情況：
一是“潛在客戶”與“當(dāng)前客戶”。我們通常所說的“客戶”（Customer）實(shí)際上是個(gè)廣義的概念，它包括了兩種情況，一種即所謂“售前客戶”（Prospect），還未達(dá)成銷售，企業(yè)正針對(duì)其展開營銷活動(dòng)（Marketing），或者正在向其提供報(bào)價(jià)，等待最終結(jié)果；一種是所謂“當(dāng)前客戶”（Account），已經(jīng)與之達(dá)成過交易，正在繼續(xù)為之提供產(chǎn)品或服務(wù)，希望未來能達(dá)成更多銷售。
二是“集團(tuán)客戶”（Headquarter）與“子公司客戶”（Subsidiary）。有些企業(yè)采取的集中采購的管理策略，由總部統(tǒng)一執(zhí)行采購下單，但由各下述企業(yè)收貨付款，或者由總部統(tǒng)一議定采購條款、簽訂框架合作協(xié)議，但由下屬各企業(yè)執(zhí)行具體采購過程。系統(tǒng)必須考慮這些企業(yè)之間的復(fù)雜關(guān)系，考慮銷售策略、價(jià)格與條款政策、信用風(fēng)險(xiǎn)管控活動(dòng)等等在它們之間如何協(xié)調(diào)問題。
三是“組織客戶”與“個(gè)人客戶”。有些企業(yè)產(chǎn)品或服務(wù)的對(duì)象，既可能是組織或單位，也可能個(gè)人，需要進(jìn)行差別化的管理；
四是“直銷”與“分銷”。有些企業(yè)的產(chǎn)品由銷售部門直接賣給終端客戶（組織或個(gè)人），但有些則可能需要通過“中間商或渠道伙伴”（一級(jí)代理、二級(jí)代理等）才能最終到達(dá)最終用戶手上；
五是“集中銷售”與“分散銷售”。有些企業(yè)的產(chǎn)品線可能比較復(fù)雜，不同產(chǎn)品可能由不同的銷售團(tuán)隊(duì)，執(zhí)行不同的銷售政策銷售給同一個(gè)客戶，企業(yè)必須考慮相互間如何協(xié)調(diào)等問題。
六是“客商關(guān)系”。即有些企業(yè)的客戶可能同時(shí)還是企業(yè)的供應(yīng)商，存在互為買賣的關(guān)系，客觀上需要在買賣政策、款項(xiàng)結(jié)算等方面做特殊考慮。
總之，外部客戶的復(fù)雜性（個(gè)人與組織、組織與組織間關(guān)系）、銷售過程的復(fù)雜性（售前、售中、售后）、企業(yè)內(nèi)部的復(fù)雜性（不同產(chǎn)品、不同銷售團(tuán)隊(duì)、不同銷售地域）等等因素的綜合作用，要求企業(yè)的客戶主數(shù)據(jù)管理必須滿足不同業(yè)務(wù)模塊（諸如Marketing、Sales、Quote、Contract、i-Store等等）的不同功能使用的具體要求。
早期的ERP產(chǎn)品對(duì)于供應(yīng)商與客戶主數(shù)據(jù)的管理要求相對(duì)比較簡單，主要是滿足PO/AP模塊、OM/AR模塊等核心業(yè)務(wù)系統(tǒng)的要求。隨著企業(yè)信息系統(tǒng)集成從核心業(yè)務(wù)系統(tǒng)向外圍支持系統(tǒng)如SRM/CRM的擴(kuò)展，以及企業(yè)管理的數(shù)據(jù)信息逐步由過去單個(gè)企業(yè)的“分散”應(yīng)用向未來企業(yè)集團(tuán)化、全球化的“集中統(tǒng)一”過渡，系統(tǒng)對(duì)于客戶及供應(yīng)商的主數(shù)據(jù)管理在完善性、靈活性、可擴(kuò)展性等方面提出了更高的要求。正是在這一需求的大背景之下，ORACLE于2000年提出了有關(guān)主數(shù)據(jù)管理（當(dāng)時(shí)主要是針對(duì)客戶）的所謂“交易社區(qū)架構(gòu)（Trading Community Architeture，TCA）”的概念。
所謂交易社區(qū)架構(gòu)TCA的概念，主要包含兩層涵義，一層是從“技術(shù)架構(gòu)”角度的主數(shù)據(jù)如何共享去講的，系統(tǒng)中的各業(yè)務(wù)模塊被看作是“社區(qū)成員”，相互之間使用統(tǒng)一的主數(shù)據(jù)，系統(tǒng)只需集中維護(hù)單一的數(shù)據(jù)來源。有關(guān)這一層涵義，今天人們已經(jīng)很熟悉，無需多講；二層涵義是從“業(yè)務(wù)應(yīng)用”角度的主數(shù)據(jù)如何“模型化”角度去講的，正如前文已經(jīng)提到，任何企業(yè)在市場(chǎng)環(huán)境中，都同時(shí)承擔(dān)著既是供應(yīng)商又是客戶的雙重角色，作為每一獨(dú)立存在的企業(yè)個(gè)體，在系統(tǒng)中也仿佛組成了一個(gè)“社區(qū)”，“社區(qū)成員”相互之間有時(shí)也存在著復(fù)雜的交易連接關(guān)系。以下重點(diǎn)介紹ORACLE客戶數(shù)據(jù)“業(yè)務(wù)應(yīng)用”層面的TCA架構(gòu)模型化問題。
既然每一個(gè)企業(yè)作為“商業(yè)實(shí)體”是一種客觀存在，那么其在系統(tǒng)中首先也可以被看作是一個(gè)具有身份標(biāo)識(shí)、獨(dú)立存在的“交易方”（Party），該“交易方”可以是組織，也可以是個(gè)人，擁有自己的、不依賴于其他方的數(shù)據(jù)信息，如組織、人員、產(chǎn)品、物理地址等等。在未與這些“交易方”產(chǎn)生真實(shí)的買賣活動(dòng)之前，或曰“售前”階段，這些“交易方”同樣屬于廣義的“客戶”概念范疇（Prospect），需要在系統(tǒng)中對(duì)它們相關(guān)的市場(chǎng)活動(dòng)進(jìn)行有效管理。
一旦與交易方（Party）達(dá)成買賣協(xié)議或開始下單，則可能需要與交易方達(dá)成一種或多種“買賣關(guān)系”，對(duì)于每一種“買賣關(guān)系”，EBS系統(tǒng)將之稱為“賬戶（Account）”，注意，不要將這里的賬戶Account與所謂的“銀行賬號(hào)Bank Account”相混淆；在每一個(gè)賬戶Account之下，為了進(jìn)一步區(qū)分某些交易屬性（例如收單地點(diǎn)、銀行賬號(hào)等），可以再分為多個(gè)“賬戶地點(diǎn)”（Account Site）；一個(gè)“交易方”與“賬戶”的組合（Party+Account）稱之為“客戶Customer”（而不是Prospect）。我們通常所說的“客戶經(jīng)理”，其英譯“Account Manager”，正是很好地體現(xiàn)了這里的所謂“交易方賬戶”的概念。
在EBS系統(tǒng)中所謂的“客戶間關(guān)系”，主要是指“交易方關(guān)系”而言的，由于交易方Party是獨(dú)立的存在，Party之間所建立的關(guān)系也是一種客觀存在，不依賴于與己方所建立的某種買賣關(guān)系（Account），故而，這種“交易方關(guān)系”可以適應(yīng)于所有業(yè)務(wù)系統(tǒng)（而不僅僅是傳統(tǒng)的OM/AR系統(tǒng)）的使用需要。
早期的EBS版本（以及很多其它品牌的ERP產(chǎn)品）在實(shí)際應(yīng)用中，人們都習(xí)慣于以“供應(yīng)商地點(diǎn)、客戶地點(diǎn)”來表達(dá)“總公司與子公司”的關(guān)系或?qū)哟谓Y(jié)構(gòu)，但基于EBS的TCA架構(gòu)，對(duì)于客戶的“層次結(jié)構(gòu)”關(guān)系，ORACLE強(qiáng)烈建議不要使用“客戶地點(diǎn)”來表達(dá)，因?yàn)橄嚓P(guān)CRM模塊的諸多應(yīng)用（例如“商機(jī)管理”等）是建立在Party而不是Site之上的。對(duì)于一個(gè)總公司附帶若干分公司、子公司的客戶情形，只要客觀上需要將某一個(gè)分、子公司在市場(chǎng)營銷、客戶管理方面重點(diǎn)對(duì)待，ORACLE的建議傾向于為之建立單獨(dú)的“Party”實(shí)體（細(xì)粒度管理），而不是降格為Site。
關(guān)于TCA的一個(gè)賬戶Account可以有多個(gè)“賬戶地點(diǎn)Account Site”的問題，其含義類似于原來的“一個(gè)供應(yīng)商或客戶可以有多個(gè)地點(diǎn)Site”。而一個(gè)交易方Party 具有多個(gè)賬戶Account的問題，主要是為了滿足己方（而不是交易方或客戶）內(nèi)部業(yè)務(wù)管理復(fù)雜性的需要，例如公司有性質(zhì)迥異的兩種不同產(chǎn)品（如電視機(jī)和X光機(jī)），有不同的銷售團(tuán)隊(duì)、商務(wù)策略以及生產(chǎn)廠家，但可能具有同一個(gè)客戶（交易方），為了在內(nèi)部管理上加以區(qū)分，則可以在一個(gè)Party之下建立多個(gè)Account。這有點(diǎn)類似你去同一個(gè)銀行的不同支行開了多個(gè)戶頭，銀行（一般是分行級(jí)）的業(yè)務(wù)管理系統(tǒng)第一次會(huì)根據(jù)你的身份證信息建立一個(gè)統(tǒng)一的“客戶號(hào)”（類似Party Number），以后你在任一支行所開的戶頭均屬于此客戶號(hào)之下的Account。
按照ORACLE在多年以前的有關(guān)設(shè)想，最終包括供應(yīng)商數(shù)據(jù)在內(nèi)，所有有關(guān)客戶的系統(tǒng)應(yīng)用都要逐步遷移并適應(yīng)于TCA架構(gòu)。但遺憾的是，近十年時(shí)間過去，或許不可見的“技術(shù)架構(gòu)”層面的TCA工作早已完成，但可見的、業(yè)務(wù)應(yīng)用層面的TCA工作的進(jìn)展還是比較緩慢：供應(yīng)商主數(shù)據(jù)的TCA似乎尚未啟動(dòng)，客戶主數(shù)據(jù)的TCA才開了一個(gè)頭，核心業(yè)務(wù)系統(tǒng)如OM/AR的改造尚有很長的路要走，目前還無法實(shí)現(xiàn)“Party”層與“Account”層的數(shù)據(jù)分離，還無法實(shí)現(xiàn)按“Party”（或Account）實(shí)現(xiàn)業(yè)務(wù)數(shù)據(jù)與活動(dòng)的“卷積”（Roll-Up）。
甚至于用“交易方Party+賬戶Account”這個(gè)概念取代傳統(tǒng)的“Cunstomer”概念都有一定困難。原先在R11后期版本中出現(xiàn)的Party術(shù)語，在R12版本中甚至被改回用Customer術(shù)語代替，原先的Party Number則被改稱為Registry ID。在系統(tǒng)中創(chuàng)建Party（Customer）的同時(shí)，必須同時(shí)為之創(chuàng)建Account，Party或Customer與Account被捆在了一起（原先的設(shè)想是根據(jù)需要再創(chuàng)建Account）?？磥?，ORACLE的主數(shù)據(jù)TCA架構(gòu)適應(yīng)性改造還任重道遠(yuǎn)，是一項(xiàng)艱巨的長期任務(wù)。
盡管TCA架構(gòu)的目前使用尚不完善，使用范圍有限，但在下面有關(guān)客戶主數(shù)據(jù)的具體介紹中，將會(huì)不時(shí)出現(xiàn)它的身影，故為了幫助理解有關(guān)內(nèi)容，這里有必要對(duì)其概念與內(nèi)涵作簡要介紹。
盡管在R11中，“客戶配置文件分類”的設(shè)置并非為創(chuàng)建客戶數(shù)據(jù)的前提條件，但在R12中，由于被改成了必須的前提條件，故這里要首先對(duì)之作介紹。所謂“客戶配置文件分類”，簡單說就是對(duì)具有相似信譽(yù)、業(yè)務(wù)量和付款周期（以及滯納費(fèi)用制度）的客戶（賬戶Account）進(jìn)行分組。對(duì)于每個(gè)配置文件分類，可以定義諸如信用限額、付款條件、對(duì)帳單周期、開票和折扣信息之類的信息。也可以為經(jīng)營業(yè)務(wù)所用的每種幣種定義財(cái)務(wù)費(fèi)用、催款和對(duì)帳單限額等等信息。如下圖82所示：
作為業(yè)務(wù)實(shí)例，可以定義三種“客戶配置文件分類”：一種為準(zhǔn)時(shí)付款客戶，他們具有良好的信用限額；一種為延遲付款客戶，他們具有較高的財(cái)務(wù)費(fèi)用利率；另一種為經(jīng)常準(zhǔn)時(shí)付款的客戶，可以通過提供折扣來鼓勵(lì)他們提前付款。
定義的“客戶配置文件分類”被客戶（Account）所引用后，則該客戶就具有了配置文件中所定義的所有相關(guān)屬性。對(duì)于已經(jīng)定義的配置文件相關(guān)字段進(jìn)行修改，在保存時(shí)系統(tǒng)會(huì)詢問對(duì)于已經(jīng)引用該配置文件的客戶的相關(guān)字段如何處理，如下圖83所示：
具體包括：“不更新現(xiàn)有配置文件”，即配置文件分類的更改只對(duì)新增客戶數(shù)據(jù)有效；“更新所有配置文件”，即配置文件分類的更改對(duì)包括已存在的所有客戶數(shù)據(jù)有效；“更新所有未自定義的配置文件”，即只更新與當(dāng)前被更改值具有相同值的客戶數(shù)據(jù)。顯然，系統(tǒng)的這種控制方式，對(duì)于批量定義、維護(hù)客戶數(shù)據(jù)的某些字段內(nèi)容將十分方便、靈活。
R12與R11的客戶配置文件相比，內(nèi)容及Tab頁分組有一定變化，如下圖84所示：
總的來說，客戶配置文件的字段屬性主要是應(yīng)用于AR系統(tǒng)中（個(gè)別與OM系統(tǒng)有關(guān)，如信用檢查等），為AR系統(tǒng)相關(guān)字段提供默認(rèn)值或控制有關(guān)業(yè)務(wù)行為。“客戶配置文件分類”因?yàn)橹蛔饔糜诳蛻舻腁ccount層或Account Site層（被引用），故稱之為“賬戶配置文件”可能更合適。有關(guān)客戶配置文件字段詳情，請(qǐng)參考ORACLE相關(guān)文檔，這里不贅述。
目前，無論是R11還是R12，當(dāng)在其中創(chuàng)建新客戶（Customer）時(shí)，系統(tǒng)均需要同時(shí)創(chuàng)建一個(gè)賬戶Account及其賬戶地點(diǎn)Site。R11與R12的共同之處是，Acount與Site均可由系統(tǒng)自動(dòng)生成（或手工輸入）的編號(hào)Number作為唯一性標(biāo)識(shí)，Site必須具有真實(shí)的物理地址Address；R11與R12的不同之處在于，R11的賬戶名Account Name變成了R12的賬戶說明Account Description，R12的Account Site還可以為之給定一個(gè)地點(diǎn)名Site Name。系統(tǒng)同時(shí)還會(huì)給客戶自動(dòng)創(chuàng)建（或手工輸入）一個(gè)“頂層”的唯一性編號(hào)Number，在R11中稱為交易方編號(hào)Party Number，在R12中稱為注冊(cè)號(hào)Registry ID。
在R12中創(chuàng)建新客戶時(shí)，首先需確定客戶類型是“組織”還是“個(gè)人”，然后在“賬戶信息”區(qū)域選擇賬戶類型是“外部”還是“內(nèi)部”。“內(nèi)部”表示公司內(nèi)部客戶的賬戶，“外部”表示公司外部客戶賬戶。必須為賬戶賦予一個(gè)賬戶地點(diǎn)的物理地址，并同時(shí)為該“賬戶地點(diǎn)”指定其所屬的業(yè)務(wù)實(shí)體OU，及其業(yè)務(wù)目的（收單方、收貨方等等）。如下圖85所示：
系統(tǒng)會(huì)為新創(chuàng)建的客戶自動(dòng)生成（或手工輸入）注冊(cè)標(biāo)識(shí)號(hào)（亦即Party Number）、客戶賬戶號(hào)（Account Number）以及賬戶地點(diǎn)編號(hào)（Account Site Number）。然后可以根據(jù)業(yè)務(wù)需要，為該客戶添加新的賬戶Account（及其Site，所屬的OU以及業(yè)務(wù)目的等），也可以為當(dāng)前賬戶Account 添加新的地點(diǎn)Site信息。如下圖86所示：
R11的新客戶及其所屬賬戶的創(chuàng)建過程略為抽象，在輸入新客戶名稱后，系統(tǒng)如果未發(fā)現(xiàn)有重名，則會(huì)彈出是否“新建”的詢問界面，如下圖87所示：
在新建客戶名及其賬戶、賬戶地址后，系統(tǒng)會(huì)自動(dòng)為之生成兩行記錄，一行是交易方編號(hào)和地址信息，一行是該交易方所屬賬戶編號(hào)（Account）及其地點(diǎn)編號(hào)（Site）。如要為該交易方添加新的賬戶Account，需要定位到“交易方編號(hào)和地址信息”行，再按“確定”方可。如要為已經(jīng)存在的賬戶編號(hào)（Account）新增地點(diǎn)Site，必須先定位到“賬戶編號(hào)（Account）及其地點(diǎn)編號(hào)（Site）”行，再按“確定”方可。如下圖88所示：
與供應(yīng)商名稱必須唯一不同，新建的客戶名稱（Party Name）并不要求唯一，可以重復(fù)。已經(jīng)存在的客戶名稱也可以更改。與供應(yīng)商只包含一個(gè)編號(hào)不同，每個(gè)客戶數(shù)據(jù)至少包含“交易方編號(hào)Party Number”、“地點(diǎn)編號(hào)Site Number”、“賬戶編號(hào)Account Number”以及“業(yè)務(wù)目的地點(diǎn)編號(hào)Usage Location Number”（多個(gè)，具體下面介紹）等等。這些編號(hào)是自動(dòng)生成還是手工輸入，取決于如下設(shè)置：Party Number與Site Number分別由系統(tǒng)配置文件“HZ：自動(dòng)生成交易方編號(hào)、HZ：自動(dòng)生成交易方地點(diǎn)編號(hào)”控制，Account Number與Usage Location Number 則分別由AR系統(tǒng)選項(xiàng)的“自動(dòng)客戶（賬戶）編號(hào)”與“自動(dòng)地點(diǎn)編號(hào)”來控制
聯(lián)系客服
