最近在S/4HANA升級(jí)項(xiàng)目的運(yùn)維群里幾乎每天都會(huì)看到類似的提問XD03查客戶還正常為什么新建客戶時(shí)系統(tǒng)提示必須走BP事務(wù)代碼XK01在Fiori里點(diǎn)不開采購催著錄新供應(yīng)商結(jié)果一群人圍著事務(wù)代碼BP發(fā)懵——屏幕上全是角色、賬戶組、分組字段和以前XK01那套完全不是一個(gè)畫風(fēng)。大家撞上的就是S/4HANA里強(qiáng)推的BPBusiness Partner業(yè)務(wù)伙伴主數(shù)據(jù)模型以及讓這套模型能夠平穩(wěn)落地的CVICustomer-Vendor Integration客戶/供應(yīng)商集成機(jī)制。CVI這個(gè)詞在項(xiàng)目里經(jīng)常被當(dāng)成“一個(gè)配置項(xiàng)”帶過可實(shí)際上它是連接傳統(tǒng)客戶/供應(yīng)商主數(shù)據(jù)和BP主數(shù)據(jù)的橋梁直接影響FI、MM、SD能不能正常開單、過賬、對(duì)賬。我打算把這套模型從頭到尾拆一遍包括它到底解決了什么問題、底層是怎么設(shè)計(jì)的、配置要?jiǎng)幽男┦聞?wù)代碼、大批量遷移時(shí)怎么避坑。內(nèi)容偏顧問實(shí)操向也適合主數(shù)據(jù)專員、技術(shù)顧問和剛接手S/4項(xiàng)目的人參考。1. CVI模型的設(shè)計(jì)背景為什么S/4非要把客戶和供應(yīng)商綁在一起1.1 傳統(tǒng)ECC的“雙軌制”主數(shù)據(jù)帶來了什么麻煩在ECC時(shí)代客戶和供應(yīng)商是兩套完全獨(dú)立的主數(shù)據(jù)?？蛻糇遆D01/XD02落在KNA1、KNB1這些表里供應(yīng)商走XK01/XK02落在LFA1、LFB1這些表里。這兩套數(shù)據(jù)各有各的編號(hào)范圍、字段狀態(tài)和屏幕規(guī)則互不感知。聽起來好像也沒什么對(duì)吧但業(yè)務(wù)一跑起來就難受了。一個(gè)公司既可能是你的客戶又是你的供應(yīng)商這在制造、貿(mào)易、集團(tuán)內(nèi)部交易里非常常見。于是同一個(gè)法人實(shí)體在系統(tǒng)里有客戶編碼A和供應(yīng)商編碼B地址各維護(hù)一份銀行賬號(hào)各維護(hù)一份財(cái)務(wù)對(duì)賬的時(shí)候還要人工在兩張表之間來回核對(duì)。維護(hù)成本高還是小事數(shù)據(jù)不一致帶來的風(fēng)險(xiǎn)才是大問題——客戶側(cè)改了注冊資本和銀行信息供應(yīng)商側(cè)忘了同步發(fā)票校驗(yàn)的時(shí)候就容易報(bào)警。更深一層的問題是SAP后來推出的CRM、SRM、MDG等產(chǎn)品都是圍繞BP來建模的ECC的雙軌制主數(shù)據(jù)讓這些系統(tǒng)之間的集成非常別扭。你看CRM里建了個(gè)“客戶”到了ERP側(cè)卻要映射成客戶主數(shù)據(jù)到了SRM側(cè)又要映射成供應(yīng)商主數(shù)據(jù)還要處理兩套編號(hào)、兩套同步邏輯項(xiàng)目組光做接口映射表就累得夠嗆。1.2 S/4HANA統(tǒng)一主數(shù)據(jù)模型的邏輯S/4HANA的決策很干脆把所有業(yè)務(wù)伙伴統(tǒng)一到一張主數(shù)據(jù)上就是BP。客戶和供應(yīng)商不再是獨(dú)立的主數(shù)據(jù)類型而是BP下面的一個(gè)角色Role。你可以把BP理解成一個(gè)人的“戶籍檔案”客戶身份只是他的一張“名片”供應(yīng)商身份是另一張“名片”。同一個(gè)BP編號(hào)下可以同時(shí)掛“客戶”和“供應(yīng)商”兩個(gè)角色地址、銀行信息等基礎(chǔ)數(shù)據(jù)復(fù)用同一份。但是問題來了S/4HANA推出的時(shí)候市場上已經(jīng)有大量ECC客戶在用傳統(tǒng)的客戶/供應(yīng)商主數(shù)據(jù)底表、報(bào)表、接口、打印單據(jù)全是按KNA1/LFA1來做的。如果SAP直接把這些表干掉整個(gè)生態(tài)都得重寫。所以SAP做了一個(gè)兼容層也就是CVI。CVI的全稱就是Customer-Vendor Integration它的作用是把傳統(tǒng)客戶字段、供應(yīng)商字段映射到BP的一般數(shù)據(jù)上同時(shí)保留KNA1/LFA1作為視圖供舊邏輯讀取。你通過BP創(chuàng)建客戶時(shí)系統(tǒng)后臺(tái)會(huì)同時(shí)維護(hù)BUT000BP一般數(shù)據(jù)和KNA1客戶一般數(shù)據(jù)并通過CVI相關(guān)表記錄兩者之間的關(guān)系。從業(yè)務(wù)角度看經(jīng)典表還在從主數(shù)據(jù)治理角度看唯一入口已經(jīng)變成BP。1.3 CVI模型對(duì)業(yè)務(wù)操作的影響范圍這個(gè)影響是實(shí)打?qū)嵉牟皇窃诤笈_(tái)悄悄進(jìn)行的而是改變了用戶的日常操作路徑新建客戶和供應(yīng)商事務(wù)代碼XD01、XK01在S/4HANA里基本不能用了必須通過事務(wù)代碼BP創(chuàng)建選擇對(duì)應(yīng)的BP角色比如FLCU00是客戶FLVN00是供應(yīng)商。查詢和修改XD03、XK03一般還能打開做查看但很多S/4版本里也會(huì)建議你切到BP界面操作避免兩邊顯示不一致。底表和報(bào)表KNA1、LFA1仍然存在很多傳統(tǒng)報(bào)表、接口程序不需要改動(dòng)就能繼續(xù)跑這是CVI帶來的最大好處。財(cái)務(wù)過賬FI憑證創(chuàng)建時(shí)依然使用客戶編號(hào)/供應(yīng)商編號(hào)系統(tǒng)通過CVI映射自動(dòng)找到BP用戶感受不到底層變化。所以CVI模型并不是讓客戶/供應(yīng)商概念消失而是把它們統(tǒng)一收口到BP之下同時(shí)保證舊世界和新世界能無縫銜接。理解這一點(diǎn)后面配置和排查問題的思路就清晰了。2. 上手前先吃透賬戶組、角色和編號(hào)范圍這三個(gè)概念2.1 賬戶組決定字段狀態(tài)角色決定業(yè)務(wù)身份很多第一次接觸BP的人會(huì)被“賬戶組”和“角色”繞暈。我習(xí)慣這樣類比賬戶組相當(dāng)于一個(gè)檔案袋的規(guī)格它決定了袋子上要印哪些欄目、哪些欄目必填、哪些欄目隱藏角色則相當(dāng)于這個(gè)人的身份標(biāo)簽決定了他可以被當(dāng)成客戶用還是供應(yīng)商用。在CVI模型里原來的客戶賬戶組SPRO-財(cái)務(wù)會(huì)計(jì)-應(yīng)收賬款和應(yīng)付賬款-客戶賬戶-主數(shù)據(jù)-客戶主記錄準(zhǔn)備-定義賬戶組和供應(yīng)商賬戶組對(duì)應(yīng)供應(yīng)商配置路徑仍然存在它們控制客戶/供應(yīng)商側(cè)的業(yè)務(wù)字段。但你在BP里創(chuàng)建主數(shù)據(jù)時(shí)界面布局受BP賬戶組控制SPRO-跨應(yīng)用組件-SAP業(yè)務(wù)伙伴-業(yè)務(wù)伙伴-基本設(shè)置-賬戶分組。CVI要做的就是把客戶賬戶組、供應(yīng)商賬戶組與BP賬戶組建立映射。舉個(gè)例子?？蛻糍~戶組0001通常是“普通客戶”供應(yīng)商賬戶組0001通常是“普通供應(yīng)商”。在CVI配置里把客戶0001映射到BP賬戶組0001把供應(yīng)商0001也映射到BP賬戶組0001。這樣創(chuàng)建BP時(shí)系統(tǒng)會(huì)知道“這個(gè)BP既可以當(dāng)客戶0001類型用也可以當(dāng)供應(yīng)商0001類型用”。2.2 CVI如何把客戶/供應(yīng)商賬戶組映射到BP賬戶組做映射的核心工具是事務(wù)代碼BUCF_ASSIGN它的作用是把客戶/供應(yīng)商字段分配到BP賬戶組的各個(gè)塊中。CVI相關(guān)的主要事務(wù)代碼還有BUCF_RECEIVE01把客戶編號(hào)范圍接收為BP編號(hào)范圍BUCF_RECEIVE02把供應(yīng)商編號(hào)范圍接收為BP編號(hào)范圍BUCF_MAP定義客戶、供應(yīng)商與BP編號(hào)之間的映射規(guī)則CVI_ACTIVATE激活CVI集成功能字段分配界面里通常有“常規(guī)數(shù)據(jù)”、“公司代碼數(shù)據(jù)”、“銷售范圍數(shù)據(jù)”、“采購組織數(shù)據(jù)”幾個(gè)分配區(qū)域。這幾個(gè)區(qū)域是否分配給某個(gè)BP賬戶組直接決定BP創(chuàng)建界面是否會(huì)顯示對(duì)應(yīng)的頁簽。項(xiàng)目上最典型的坑就是BP賬戶組只分配了常規(guī)數(shù)據(jù)結(jié)果創(chuàng)建BP時(shí)找不到“公司代碼”頁簽統(tǒng)馭科目、付款條件這些關(guān)鍵會(huì)計(jì)字段沒地方維護(hù)FI那邊根本沒法用。常見映射邏輯可以參考這樣一張表客戶賬戶組供應(yīng)商賬戶組映射到的BP賬戶組說明0001 普通客戶0001 普通供應(yīng)商0001最常用的內(nèi)外不給號(hào)/內(nèi)部給號(hào)場景0002 一次性客戶0002 一次性供應(yīng)商0002一次性業(yè)務(wù)往來0003 集團(tuán)內(nèi)部客戶0003 集團(tuán)內(nèi)部供應(yīng)商0003內(nèi)部交易主數(shù)據(jù)ZC01 自建客戶組ZV01 自建供應(yīng)商組ZBP1按業(yè)務(wù)自定義2.3 編號(hào)范圍內(nèi)部給號(hào)還是外部給號(hào)決定遷移策略CVI配置里最需要提前決策的就是編號(hào)范圍策略。傳統(tǒng)ECC里客戶編號(hào)和供應(yīng)商編號(hào)各自有號(hào)碼段互不相干一個(gè)客戶可能是10000001一個(gè)供應(yīng)商可能是20000005。到了BP模型里同一個(gè)業(yè)務(wù)伙伴最好只有一個(gè)BP編號(hào)再關(guān)聯(lián)到客戶/供應(yīng)商編號(hào)。最穩(wěn)妥的做法是讓BP編號(hào)、客戶編號(hào)、供應(yīng)商編號(hào)三者等長、同起點(diǎn)。比如ECC里歷史客戶號(hào)最大到500000供應(yīng)商號(hào)最大到400000那BP號(hào)段可以設(shè)計(jì)成從500001開始客戶號(hào)和供應(yīng)商號(hào)也從這個(gè)段里面取。這樣打印出來給客戶看的單據(jù)編號(hào)不會(huì)變供應(yīng)商對(duì)賬時(shí)也不會(huì)出現(xiàn)“你們系統(tǒng)里我怎么換號(hào)了”這種尷尬。如果歷史數(shù)據(jù)量不大也可以完全重新編號(hào)BP客戶號(hào)供應(yīng)商號(hào)讓三者在數(shù)字上完全一致。但要注意重編號(hào)會(huì)影響歷史單據(jù)、歷史發(fā)票、外部合同中對(duì)舊編號(hào)的引用需要評(píng)估所有打印表單和周邊接口。大多數(shù)升級(jí)項(xiàng)目為了減少業(yè)務(wù)沖擊都會(huì)選擇保留歷史客戶/供應(yīng)商編號(hào)并讓BP編號(hào)等于舊客戶或舊供應(yīng)商編號(hào)。3. CVI配置全流程實(shí)操從激活到真正能用BP創(chuàng)建主數(shù)據(jù)3.1 激活CVI功能CVI_ACTIVATE新建的S/4HANA系統(tǒng)里CVI一般是默認(rèn)激活的。但如果是ECC升級(jí)上來的系統(tǒng)或者有人做過業(yè)務(wù)功能調(diào)整有可能出現(xiàn)“CVI未激活”的狀態(tài)。這時(shí)候事務(wù)代碼BP打開時(shí)會(huì)有提示或者在創(chuàng)建客戶/供應(yīng)商時(shí)系統(tǒng)直接報(bào)錯(cuò)。激活路徑運(yùn)行事務(wù)代碼CVI_ACTIVATE。系統(tǒng)會(huì)彈出客戶/供應(yīng)商集成的激活儀表盤列出待激活步驟。按順序執(zhí)行包括檢查賬戶組映射、編號(hào)范圍接收、字段分配等。激活完成后用事務(wù)代碼CVI_ACT_CHECK做校驗(yàn)確認(rèn)狀態(tài)為綠燈。激活過程中最常見的失敗原因就是“部分賬戶組沒有分配到BP賬戶組”。系統(tǒng)會(huì)明確提示哪個(gè)客戶賬戶組或供應(yīng)商賬戶組沒映射。此時(shí)不要硬激活應(yīng)該先到SPRO或?qū)?yīng)事務(wù)代碼里補(bǔ)齊映射再重新激活。3.2 配置編號(hào)范圍與同步規(guī)則BUCF_RECEIVE01/02這塊的目標(biāo)是把客戶、供應(yīng)商的編號(hào)范圍接入BP編號(hào)范圍。操作時(shí)可以這樣理解客戶和供應(yīng)商以前各自有一個(gè)號(hào)碼池現(xiàn)在要合并成一個(gè)共享的號(hào)碼池并讓BP也從同一個(gè)池子里取號(hào)。事務(wù)代碼BUCF_RECEIVE01用于接收客戶編號(hào)范圍BUCF_RECEIVE02用于接收供應(yīng)商編號(hào)范圍。執(zhí)行后會(huì)列出系統(tǒng)中已有的號(hào)碼段你可以選擇將這些段復(fù)制為BP的號(hào)碼段。需要注意的細(xì)節(jié)是“區(qū)間重疊”問題。如果客戶號(hào)和供應(yīng)商號(hào)的歷史范圍重疊比如客戶到了600000供應(yīng)商也到了600000合并到BP號(hào)段時(shí)會(huì)發(fā)生沖突。項(xiàng)目上的處理方式通常是提前調(diào)整供應(yīng)商號(hào)段比如把供應(yīng)商歷史號(hào)整體加一個(gè)偏移量或者在遷移清洗階段合并重復(fù)主數(shù)據(jù)。這屬于數(shù)據(jù)治理范疇但配置層面要先留出足夠的BP號(hào)段空間。3.3 字段分配BUCF_ASSIGN字段分配是CVI配置里最容易出問題的環(huán)節(jié)也是項(xiàng)目上線后BP界面字段顯示異常的源頭。執(zhí)行BUCF_ASSIGN后界面會(huì)列出BP賬戶組每個(gè)賬戶組下有若干分配塊常規(guī)數(shù)據(jù)包括名稱、地址、語言、檢索項(xiàng)等公司代碼數(shù)據(jù)統(tǒng)馭科目、容差組、付款條件、催款程序等銷售范圍數(shù)據(jù)銷售組織、分銷渠道、產(chǎn)品組相關(guān)的客戶字段采購組織數(shù)據(jù)采購組織相關(guān)的供應(yīng)商字段、默認(rèn)物料組、付款條款等分配的原則很簡單你的業(yè)務(wù)在哪幾個(gè)維度使用客戶/供應(yīng)商主數(shù)據(jù)就把對(duì)應(yīng)塊分配給BP賬戶組。比如企業(yè)有海外銷售客戶側(cè)有多個(gè)銷售范圍視圖那就必須把“銷售范圍數(shù)據(jù)”分配給相關(guān)BP賬戶組如果沒有采購業(yè)務(wù)就不需要把“采購組織數(shù)據(jù)”分配給供應(yīng)商賬戶組相應(yīng)的BP賬戶組。做分配時(shí)要小心“和字段狀態(tài)變式聯(lián)動(dòng)”。有些字段即使在賬戶組字段狀態(tài)里已經(jīng)設(shè)置成“可選輸入”在BP界面卻顯示為隱藏或只讀很可能是因?yàn)镃VI字段分配的某個(gè)塊沒勾選對(duì)應(yīng)字段組。我的習(xí)慣是先做完整分配再創(chuàng)建一個(gè)測試BP用不同賬戶組各試一遍確認(rèn)所有業(yè)務(wù)必填字段都顯示出來了才算完成。3.4 配置客戶/供應(yīng)商到BP的編號(hào)映射BUCF_MAPBUCF_MAP用來定義編號(hào)映射規(guī)則。這里可以設(shè)置的規(guī)則包括“BP編號(hào)等于客戶編號(hào)”、“BP編號(hào)等于供應(yīng)商編號(hào)”、“客戶編號(hào)和BP編號(hào)相同”等。實(shí)際項(xiàng)目中如果BP編號(hào)、客戶編號(hào)、供應(yīng)商編號(hào)完全統(tǒng)一業(yè)務(wù)最簡單。但如果系統(tǒng)里有“同一公司既是客戶又是供應(yīng)商”的場景且舊客戶號(hào)與舊供應(yīng)商號(hào)不一致那就需要在遷移時(shí)確定一個(gè)主編號(hào)。比如以客戶號(hào)為主供應(yīng)商號(hào)在BP下作為“其他標(biāo)識(shí)”保存或者反過來。這個(gè)決策直接影響財(cái)務(wù)對(duì)賬和報(bào)表取數(shù)應(yīng)該在項(xiàng)目前期就和業(yè)務(wù)確認(rèn)清楚。配置完成后可以運(yùn)行事務(wù)代碼BUCF_DISPLAY查看最終的映射關(guān)系。如果發(fā)現(xiàn)某個(gè)客戶/供應(yīng)商沒有BP關(guān)聯(lián)就要進(jìn)入下一步的數(shù)據(jù)同步環(huán)節(jié)了。3.5 實(shí)操演示創(chuàng)建一個(gè)同時(shí)是客戶和供應(yīng)商的BP配置做完真正在BP里創(chuàng)建主數(shù)據(jù)的流程是這樣的運(yùn)行事務(wù)代碼BP進(jìn)入業(yè)務(wù)伙伴編輯界面。選擇BP角色。要?jiǎng)?chuàng)建客戶就勾選FLCU00客戶一般數(shù)據(jù)要?jiǎng)?chuàng)建供應(yīng)商就勾選FLVN00供應(yīng)商一般數(shù)據(jù)。如果同一個(gè)BP既當(dāng)客戶又當(dāng)供應(yīng)商兩個(gè)角色都勾上。維護(hù)一般數(shù)據(jù)名稱、搜索項(xiàng)、地址、通訊信息。保存時(shí)系統(tǒng)會(huì)根據(jù)CVI配置自動(dòng)生成BP編號(hào)、客戶編號(hào)、供應(yīng)商編號(hào)。在界面里可以看到“客戶一般數(shù)據(jù)”、“供應(yīng)商一般數(shù)據(jù)”幾個(gè)頁簽。分別維護(hù)客戶側(cè)公司代碼數(shù)據(jù)統(tǒng)馭科目、付款條件等和供應(yīng)商側(cè)公司代碼數(shù)據(jù)。根據(jù)需要維護(hù)銷售范圍數(shù)據(jù)SD和采購組織數(shù)據(jù)MM。保存完成。這里有幾個(gè)字段新手容易懵。“客戶編號(hào)”和“供應(yīng)商編號(hào)”在BP界面里通常是灰的這是正常的因?yàn)榫幪?hào)由CVI自動(dòng)分配。如果你希望手工錄入編號(hào)必須把對(duì)應(yīng)的編號(hào)范圍設(shè)置成“外部給號(hào)”并且在事務(wù)代碼BUCF_RECEIVE01/02或編號(hào)范圍同步里做相應(yīng)調(diào)整。3.6 批導(dǎo)與接口BAPI比BDC更合適項(xiàng)目上創(chuàng)建BP不可能全靠人工點(diǎn)界面尤其是上線初期的歷史數(shù)據(jù)遷移和日常大批量的主數(shù)據(jù)新增。常見的三種方式是BAPI、BDC和直接寫表強(qiáng)烈不推薦。推薦優(yōu)先使用CVI專用BAPICVI_EI_INBOUND_MAINTAIN。這個(gè)BAPI功能非常全可以同時(shí)創(chuàng)建BP、客戶角色、供應(yīng)商角色、地址、公司代碼視圖、采購組織視圖、銷售范圍視圖。傳參結(jié)構(gòu)稍微復(fù)雜但主數(shù)據(jù)集成工具和自研接口都建議基于它來做。傳統(tǒng)BAPI_BUSINESS_PARTNER_CREATE_FROM_DATA也可以創(chuàng)建BP但它更多是創(chuàng)建BP一般數(shù)據(jù)對(duì)創(chuàng)建客戶/供應(yīng)商角色和擴(kuò)展視圖的支持不夠好容易被CVI數(shù)據(jù)來源Data Origin字段卡住。BDC錄屏嘛不是不能用而是BP界面有太多動(dòng)態(tài)字段和隱藏字段。同一個(gè)BP賬戶組下不同客戶賬戶組的屏結(jié)構(gòu)可能不一樣錄屏容易在某個(gè)數(shù)據(jù)組合下突然報(bào)“輸入字段不存在”。如果非要錄屏建議按賬戶組分多個(gè)錄屏并且做足數(shù)據(jù)組合測試。批量工具里常見的“SAP BDC”討論基本都在講這個(gè)痛點(diǎn)所以我建議新項(xiàng)目直接走BAPI/API。4. CVI模型不是孤立功能與FI、MM、SD的聯(lián)動(dòng)細(xì)節(jié)4.1 FI側(cè)統(tǒng)馭科目、字段狀態(tài)與會(huì)計(jì)視圖完整性BP創(chuàng)建客戶或供應(yīng)商時(shí)公司代碼視圖里的“會(huì)計(jì)信息”是財(cái)務(wù)能否正常過賬的關(guān)鍵?？蛻魝?cè)的統(tǒng)馭科目決定了FI-AR記賬時(shí)自動(dòng)帶出的總賬科目供應(yīng)商側(cè)的統(tǒng)馭科目決定了FI-AP的過賬方向。統(tǒng)馭科目配置錯(cuò)誤最常見的后果就是FB60、F-22、F-43一保存就報(bào)“科目xxxx不是統(tǒng)馭科目”或者“未定義統(tǒng)馭科目”。此外客戶主數(shù)據(jù)里的容差組容差限制、付款條件、催款程序供應(yīng)商里的付款條件、自動(dòng)付款參數(shù)也都在BP的公司代碼視圖里維護(hù)。這些字段如果沒放開采購和財(cái)務(wù)在過賬時(shí)會(huì)覺得“怎么金額差異報(bào)警”“怎么付款條件總不對(duì)”。這里順便提一個(gè)經(jīng)常被問到的問題評(píng)估類物料側(cè)和統(tǒng)馭科目往來側(cè)是兩回事。評(píng)估類是物料主數(shù)據(jù)里分配庫存記賬科目的依據(jù)不會(huì)出現(xiàn)在客戶/供應(yīng)商主數(shù)據(jù)里。如果你在BP里找“評(píng)估類”字段找不到是正常的因?yàn)槟鞘荕M物料主數(shù)據(jù)的范疇不是BP主數(shù)據(jù)的范疇。很多顧問把兩個(gè)概念混在一起排查問題時(shí)就容易跑偏。4.2 MM側(cè)供應(yīng)商主數(shù)據(jù)的采購組織視圖采購模塊對(duì)供應(yīng)商主數(shù)據(jù)的依賴非常強(qiáng)。ME21N創(chuàng)建采購訂單時(shí)供應(yīng)商編號(hào)其實(shí)是BP模型里的“供應(yīng)商角色”編號(hào)。如果BP里沒有維護(hù)該供應(yīng)商在某個(gè)采購組織的視圖系統(tǒng)會(huì)報(bào)“供應(yīng)商XXXX不在采購組織XXXX中定義”或者“必須首先維護(hù)貨源清單才能創(chuàng)建采購訂單”。貨源清單確實(shí)是個(gè)獨(dú)立的主數(shù)據(jù)但它和供應(yīng)商主數(shù)據(jù)的采購組織視圖是兩個(gè)層面的問題。貨源清單決定的是“這個(gè)物料能不能和這個(gè)供應(yīng)商在這個(gè)采購組織下交易”而供應(yīng)商主數(shù)據(jù)的采購組織視圖決定的是“這個(gè)供應(yīng)商在采購組織下是否存在、有哪些采購默認(rèn)值”。實(shí)際項(xiàng)目里經(jīng)常出現(xiàn)兩種情況并存供應(yīng)商主數(shù)據(jù)有采購組織視圖但缺貨源清單或者貨源清單有但采購組織視圖沒維護(hù)。排查時(shí)建議先從供應(yīng)商主數(shù)據(jù)入手確認(rèn)采購組織視圖存在再檢查貨源清單和采購信息記錄。CVI模型下供應(yīng)商主數(shù)據(jù)的創(chuàng)建、擴(kuò)展采購組織視圖都在事務(wù)代碼BP里操作。采購信息記錄和貨源清單數(shù)據(jù)可以單獨(dú)維護(hù)不受CVI約束。但從主數(shù)據(jù)治理角度一個(gè)供應(yīng)商的編號(hào)如果是從BP統(tǒng)一管理的后續(xù)新增采購組織視圖就只是“給同一個(gè)BP加一個(gè)采購組織頁簽”而已不會(huì)產(chǎn)生第二個(gè)供應(yīng)商編號(hào)。4.3 SD側(cè)客戶銷售范圍視圖與數(shù)據(jù)來源字段SD模塊的客戶主數(shù)據(jù)也是一樣。VA01創(chuàng)建銷售訂單時(shí)系統(tǒng)根據(jù)客戶編號(hào)銷售范圍銷售組織/分銷渠道/產(chǎn)品組組合校驗(yàn)客戶是否存在、是否被凍結(jié)、信用額度是否夠。如果BP里創(chuàng)建客戶時(shí)沒有維護(hù)對(duì)應(yīng)的銷售范圍視圖銷售訂單就會(huì)報(bào)“客戶XXXX不在銷售范圍XXXX中定義”。SD顧問還會(huì)經(jīng)常碰到一個(gè)叫“數(shù)據(jù)來源”Data Origin的字段這個(gè)字段在BP界面里往往不可編輯。比如FLCU00角色的數(shù)據(jù)來源是“CVI集成創(chuàng)建”FLCU01可能代表另一個(gè)賬戶組創(chuàng)建的客戶數(shù)據(jù)。數(shù)據(jù)來源決定了這條客戶記錄是哪個(gè)BP角色寫入的也影響后續(xù)修改權(quán)限。所以盡量不要在BP里繞過CVI直接去改KNA1表否則會(huì)出現(xiàn)BP界面和客戶主數(shù)據(jù)不一致的情況。底表層面可以用一條很粗的邏輯理解BUT000存BP一般數(shù)據(jù)BUT0ID存BP角色標(biāo)識(shí)KNA1/LFA1存客戶/供應(yīng)商一般數(shù)據(jù)CVI相關(guān)表比如CVI_CUST_LINK/CVI_VEND_LINK記錄BP與客戶/供應(yīng)商編號(hào)的關(guān)聯(lián)。所以在S/4里看到KNA1有數(shù)據(jù)不代表它一定和BP完整關(guān)聯(lián)反過來BP有客戶角色也不代表KNA1數(shù)據(jù)一定完整必須通過同步程序來確保兩邊一致。5. 高頻故障與排查經(jīng)驗(yàn)激活失敗、主數(shù)據(jù)不同步等實(shí)錄5.1 CVI激活失敗怎么處理“BP激活失敗怎么辦”是運(yùn)維群里高頻問題。這里要區(qū)分一下如果是事務(wù)代碼CVI_ACTIVATE激活失敗常見原因是賬戶組映射未配置、編號(hào)范圍未接收、某些客戶/供應(yīng)商賬戶組沒有BP角色對(duì)應(yīng)。系統(tǒng)給出的錯(cuò)誤信息一般比較直接比如“客戶賬戶組0001尚未分配到業(yè)務(wù)伙伴賬戶組”。排查步驟可以這樣走運(yùn)行CVI_ACT_CHECK看激活狀態(tài)到底是哪一步失敗。檢查SPRO里的賬戶組映射補(bǔ)齊缺失的映射關(guān)系。檢查編號(hào)范圍是否接收成功必要時(shí)重新運(yùn)行BUCF_RECEIVE01/02。確認(rèn)業(yè)務(wù)功能已激活沒有其他業(yè)務(wù)功能依賴沖突。重新激活并把錯(cuò)誤日志截圖保存方便對(duì)比。如果是在業(yè)務(wù)操作中BP本身“激活失敗”比如創(chuàng)建BP報(bào)錯(cuò)那不一定是CVI配置問題要看具體錯(cuò)誤消息。很多情況是賬戶組的字段狀態(tài)沒配好某個(gè)必填字段沒顯示所以沒填保存時(shí)后臺(tái)校驗(yàn)失敗。處理思路是回到BP界面把必填字段全部填完整再不行就到字段狀態(tài)配置里調(diào)整。5.2 創(chuàng)建BP時(shí)看不到客戶/供應(yīng)商子視圖這個(gè)問題十有八九出在BUCF_ASSIGN字段分配上。BP賬戶組沒有分配到“客戶一般數(shù)據(jù)”、“公司代碼數(shù)據(jù)”、“銷售范圍數(shù)據(jù)”等塊界面自然就不顯示對(duì)應(yīng)頁簽。排查路徑確認(rèn)當(dāng)前BP使用的賬戶組是哪個(gè)。運(yùn)行BUCF_ASSIGN找到該BP賬戶組檢查右側(cè)各數(shù)據(jù)塊的分配狀態(tài)。把缺失的數(shù)據(jù)塊分配上去。重新打開BP必要時(shí)重新登錄系統(tǒng)再檢查界面。還有一種情況是角色不對(duì)。比如你只想建供應(yīng)商但選的BP角色只有FLCU00客戶那界面里就看不到供應(yīng)商頁簽。這種屬于操作問題加選FLVN00即可。5.3 同一個(gè)客戶/供應(yīng)商出現(xiàn)多個(gè)BP記錄這是升級(jí)項(xiàng)目里最嚴(yán)重的數(shù)據(jù)質(zhì)量問題。發(fā)生場景通常是系統(tǒng)升級(jí)后業(yè)務(wù)人員直接用了舊事務(wù)代碼比如XD01還能用創(chuàng)建了客戶產(chǎn)生了KNA1和KBU1記錄但CVI沒有生成對(duì)應(yīng)的BP之后又在BP里手動(dòng)創(chuàng)建了同一個(gè)客戶的BP兩邊數(shù)據(jù)沒有關(guān)聯(lián)系統(tǒng)里就有“兩個(gè)客戶”。處理手段是用CVI同步功能。事務(wù)代碼CVI_SYNC可以把已有客戶/供應(yīng)商數(shù)據(jù)同步到BP生成關(guān)聯(lián)。更穩(wěn)妥的做法是用BAPI CVI_EI_INBOUND_MAINTAIN在已存在的BUT000上補(bǔ)充客戶/供應(yīng)商角色并建立映射。如果已經(jīng)存在重復(fù)的BP需要先確定保留哪個(gè)把另一個(gè)的客戶/供應(yīng)商編號(hào)做合并或者刪除再做同步。建議項(xiàng)目上線前就給運(yùn)維團(tuán)隊(duì)一個(gè)快速判斷方法對(duì)某個(gè)客戶編號(hào)用事務(wù)代碼BP顯示客戶角色看BP是否存在再對(duì)客戶編號(hào)用事務(wù)代碼XD03打開看“客戶/供應(yīng)商集成”字段狀態(tài)是否顯示“已集成”。如果狀態(tài)不是“已集成”就說明這個(gè)客戶主數(shù)據(jù)還沒有被納入BP模型需要同步。5.4 BP刪除受限、編號(hào)不可修改BP主數(shù)據(jù)在很多表里被引用直接刪除幾乎不可能即使沒有業(yè)務(wù)過賬也存在地址、角色等關(guān)聯(lián)數(shù)據(jù)。正確做法是“標(biāo)記刪除”在BP里設(shè)置刪除標(biāo)記再用歸檔程序處理。關(guān)于編號(hào)不可修改這是BP模型的固有特性。BP編號(hào)一旦分配原則上不允許修改因?yàn)樗钦麄€(gè)S/4HANA主數(shù)據(jù)的核心外鍵?？蛻艟幪?hào)和供應(yīng)商編號(hào)也一樣如果底表已經(jīng)有過賬記錄改號(hào)會(huì)導(dǎo)致財(cái)務(wù)憑證對(duì)應(yīng)的往來編號(hào)和主數(shù)據(jù)不一致審計(jì)上過不去。所以編號(hào)策略一定要在上線前定好上線后再改基本就是“翻車現(xiàn)場”。5.5 主數(shù)據(jù)字段顯示為灰色、只讀怎么辦BP界面里“數(shù)據(jù)來源”字段不可編輯、某些CVI創(chuàng)建的客戶/供應(yīng)商標(biāo)識(shí)不允許手工維護(hù)這些是設(shè)計(jì)如此不是故障。CVI的數(shù)據(jù)來源決定了記錄來源系統(tǒng)不允許你隨便改否則BP和客戶/供應(yīng)商的映射會(huì)亂套。但如果你指的是業(yè)務(wù)字段比如客戶統(tǒng)馭科目、銷售范圍字段灰掉無法輸入那就要檢查賬戶組字段狀態(tài)。用事務(wù)代碼OB20客戶賬戶組字段狀態(tài)或者供應(yīng)商對(duì)應(yīng)配置查看字段狀態(tài)是隱藏、可選還是必填。有時(shí)候字段分配塊已經(jīng)分配了但字段狀態(tài)是“隱藏”BP界面里也不會(huì)顯示。字段分配和字段狀態(tài)要配合使用很多人只調(diào)了BUCF_ASSIGN忘記看賬戶組的字段狀態(tài)卡了半天。6. 升級(jí)到S/4HANABP主數(shù)據(jù)規(guī)劃的三個(gè)關(guān)鍵決策6.1 賬戶組映射方案越早定越好從ECC升級(jí)到S/4HANA賬戶組映射方案必須在項(xiàng)目藍(lán)圖階段就定清楚。不要等到系統(tǒng)激活CVI時(shí)臨時(shí)抱佛腳因?yàn)榇媪靠蛻糍~戶組、供應(yīng)商賬戶組少則三五個(gè)多則幾十個(gè)每個(gè)賬戶組和BP賬戶組的映射關(guān)系都影響字段狀態(tài)、編號(hào)范圍和數(shù)據(jù)遷移。我見過一個(gè)反面案例客戶側(cè)有10個(gè)賬戶組供應(yīng)商側(cè)有8個(gè)賬戶組項(xiàng)目組因?yàn)闆]人負(fù)責(zé)主數(shù)據(jù)治理直接讓顧問“先把CVI激活再說”。結(jié)果激活后系統(tǒng)生成了幾十個(gè)BP賬戶組每個(gè)賬戶組的字段狀態(tài)都要重新梳理業(yè)務(wù)部門創(chuàng)建BP時(shí)經(jīng)常選錯(cuò)賬戶組主數(shù)據(jù)質(zhì)量一塌糊涂。后來花了幾個(gè)月清理返工成本遠(yuǎn)超當(dāng)初省下的規(guī)劃時(shí)間。建議客戶賬戶組和供應(yīng)商賬戶組盡量向2到3個(gè)BP賬戶組收斂。比如保留一個(gè)“標(biāo)準(zhǔn)賬戶組”、一個(gè)“一次性賬戶組”、一個(gè)“自集團(tuán)內(nèi)部賬戶組”。如果歷史賬戶組有太多特殊字段狀態(tài)可以考慮用字段狀態(tài)變式去控制而不是無限增加BP賬戶組數(shù)量。6.2 歷史數(shù)據(jù)清洗與編號(hào)連續(xù)性策略遷移前清洗歷史數(shù)據(jù)比遷移后補(bǔ)救便宜得多。重點(diǎn)清洗三類數(shù)據(jù)重復(fù)主數(shù)據(jù)同一客戶或供應(yīng)商在系統(tǒng)里有多個(gè)編號(hào)的要提前合并否則CVI同步會(huì)產(chǎn)生多個(gè)BP。不完整視圖有部分客戶/供應(yīng)商缺少公司代碼視圖或采購組織視圖同步前要確認(rèn)是補(bǔ)齊還是忽略。地址與聯(lián)系人數(shù)據(jù)地址格式不統(tǒng)一、稅號(hào)缺失等問題最好在遷移前處理因?yàn)锽P界面后維護(hù)成本更高。編號(hào)連續(xù)性方面如果歷史紙質(zhì)單據(jù)和已簽合同廣泛使用客戶編號(hào)建議保留客戶編號(hào)不變讓BP編號(hào)等于客戶編號(hào)供應(yīng)商側(cè)同理。如果客戶數(shù)量不大、外部影響很小也可以全系統(tǒng)重新編號(hào)但要提前修改所有打印表單和接口。兩個(gè)方案沒有絕對(duì)優(yōu)劣但決策后一定要在測試環(huán)境完整模擬一遍別靠想象。6.3 數(shù)據(jù)同步的窗口與順序CVI激活和存量主數(shù)據(jù)同步建議按以下順序執(zhí)行在測試環(huán)境完整跑通CVI激活、字段分配、編號(hào)范圍同步。凍結(jié)業(yè)務(wù)側(cè)的客戶/供應(yīng)商主數(shù)據(jù)新建變更窗口。在生產(chǎn)系統(tǒng)激活CVI。立即執(zhí)行存量客戶/供應(yīng)商同步把KNA1/LFA1數(shù)據(jù)同步成BP角色。運(yùn)行校驗(yàn)報(bào)表檢查每個(gè)客戶和供應(yīng)商是否都有對(duì)應(yīng)的BP且編號(hào)映射正確。解凍主數(shù)據(jù)變更業(yè)務(wù)恢復(fù)使用。上線后一周內(nèi)持續(xù)監(jiān)控同步日志處理遺留問題。同步必須放在業(yè)務(wù)凍結(jié)期是因?yàn)槿绻贿呁揭贿呌腥嗽赬D01里新建客戶很容易產(chǎn)生漏網(wǎng)之魚。上線后檢查“未同步客戶”報(bào)表再補(bǔ)同步雖然不是不可以但窗口越短數(shù)據(jù)質(zhì)量問題越少。6.4 面向未來的擴(kuò)展BP模型是后續(xù)所有集成的底座S/4HANA里BP模型不是終點(diǎn)而是起點(diǎn)。MDG主數(shù)據(jù)治理要基于BP做規(guī)則和校驗(yàn)S4CCustomer Management里客戶數(shù)據(jù)也和BP打通BTP上的擴(kuò)展應(yīng)用、SAP AI等功能面對(duì)的是標(biāo)準(zhǔn)化的BP主數(shù)據(jù)模型。如果你在項(xiàng)目初期就把賬戶組映射、編號(hào)范圍、字段狀態(tài)這些基礎(chǔ)打扎實(shí)后續(xù)做任何集成和分析都會(huì)輕松很多。反過來如果CVI模型里的映射關(guān)系亂糟糟未來任何一個(gè)和客戶/供應(yīng)商相關(guān)的AI、數(shù)據(jù)分析項(xiàng)目都會(huì)先在數(shù)據(jù)清洗上栽跟頭。這也就是為什么我總覺得現(xiàn)在多花一點(diǎn)時(shí)間把主數(shù)據(jù)模型理順比以后寫一百個(gè)數(shù)據(jù)修復(fù)程序都值。寫在最后的一個(gè)小建議做了幾個(gè)S/4HANA升級(jí)和新建項(xiàng)目之后我最大的體會(huì)是CVI配置本身工作量并不大真正難的是在項(xiàng)目初期把賬戶組映射方案和編號(hào)范圍策略想清楚。很多“BP激活失敗”、“主數(shù)據(jù)不同步”、“BP界面字段找不到”的問題根子都在最初幾個(gè)配置點(diǎn)上埋下了雷。如果你現(xiàn)在正好在準(zhǔn)備S/4項(xiàng)目我建議你把一個(gè)“既是客戶又是供應(yīng)商”的測試對(duì)象從頭到尾走一遍完整流程BP角色創(chuàng)建、公司代碼視圖維護(hù)、銷售范圍數(shù)據(jù)維護(hù)、采購組織數(shù)據(jù)維護(hù)、同步校驗(yàn)、開銷售訂單、開采購訂單、做發(fā)票過賬。把這套流程在預(yù)生產(chǎn)環(huán)境完整跑通比看十篇配置文檔都管用。那些藏在字段狀態(tài)、數(shù)據(jù)來源、隱藏字段背后的坑只有親手做一遍才會(huì)冒出來。