簡(jiǎn)介CO方式U8采購(gòu)訂單增刪改審接口開(kāi)發(fā)示例是一套面向用友U8二次開(kāi)發(fā)的C#實(shí)戰(zhàn)代碼包主要幫助開(kāi)發(fā)人員快速解決采購(gòu)訂單在外部系統(tǒng)中創(chuàng)建、修改、刪除與審核等接口對(duì)接問(wèn)題。資源共86個(gè)文件壓縮包僅1.89MB其中包含約20個(gè)C#源碼文件cs、19個(gè)動(dòng)態(tài)庫(kù)dll、9個(gè)XML文件、3個(gè)config等配置說(shuō)明文件以及Visual Studio解決方案sln/csproj和可運(yùn)行的exe演示程序同時(shí)附帶U8Login.dll登錄組件與使用說(shuō)明工程可直接導(dǎo)入開(kāi)發(fā)環(huán)境。已有162人學(xué)習(xí)瀏覽。示例從U8登錄認(rèn)證開(kāi)始完整演示了采購(gòu)訂單增刪改審的接口調(diào)用鏈路覆蓋參數(shù)構(gòu)造、權(quán)限校驗(yàn)、網(wǎng)絡(luò)通信、異常處理、數(shù)據(jù)同步等關(guān)鍵環(huán)節(jié)并提供了可運(yùn)行的Demo。若正在做用友U8供應(yīng)鏈集成或希望掌握C#調(diào)用U8接口的工程化寫(xiě)法這份資源能提供從接口認(rèn)識(shí)到編碼落地的真實(shí)參考顯著縮短二次開(kāi)發(fā)的摸索時(shí)間。 做U8二次開(kāi)發(fā)的朋友多多少少都會(huì)遇到“給外部系統(tǒng)提供采購(gòu)訂單接口”這種需求。尤其是公司上了SRM、OA或者自研的采購(gòu)平臺(tái)之后采購(gòu)訂單這層數(shù)據(jù)往往需要由外部系統(tǒng)寫(xiě)入U(xiǎn)8再走內(nèi)部的審批流程。我這次做的是用CO方式開(kāi)發(fā)U8采購(gòu)訂單增刪改審接口也就是通過(guò)U8的CO組件對(duì)象調(diào)用標(biāo)準(zhǔn)API來(lái)完成采購(gòu)訂單的新增、修改、刪除和審核。和直接寫(xiě)數(shù)據(jù)庫(kù)表相比這個(gè)方式最大的好處是能觸發(fā)U8本身的校驗(yàn)邏輯數(shù)據(jù)一旦寫(xiě)進(jìn)去基本上不會(huì)出現(xiàn)商務(wù)邏輯亂掉的情況。這篇文章就圍繞這個(gè)接口示例把方案選型、環(huán)境準(zhǔn)備、核心實(shí)現(xiàn)、以及我實(shí)際踩過(guò)的坑都整理出來(lái)給后面接手的同學(xué)一個(gè)可以直接參考的路線。1. 項(xiàng)目背景與方案選型1.1 為什么最終選擇了CO方式先說(shuō)需求背景。我們這邊有一個(gè)外部采購(gòu)協(xié)同平臺(tái)需要把采購(gòu)訂單同步到本地的U8系統(tǒng)里面。協(xié)同平臺(tái)負(fù)責(zé)供應(yīng)商確認(rèn)價(jià)格、交期U8負(fù)責(zé)后續(xù)的到貨、入庫(kù)、發(fā)票、結(jié)算這些環(huán)節(jié)。一開(kāi)始方案評(píng)審的時(shí)候我大概列了一下市面上能走通的幾條路。第一種是數(shù)據(jù)庫(kù)直寫(xiě)速度最快寫(xiě)起來(lái)也最簡(jiǎn)單但問(wèn)題太大。采購(gòu)訂單涉及的主表、子表、歷史表、現(xiàn)存量表加起來(lái)一大堆U8內(nèi)部的狀態(tài)位、單據(jù)號(hào)生成規(guī)則、審批狀態(tài)流轉(zhuǎn)稍有不慎就會(huì)寫(xiě)亂。而且直寫(xiě)數(shù)據(jù)庫(kù)繞過(guò)權(quán)限控制一旦審計(jì)查起來(lái)很難解釋清楚數(shù)據(jù)來(lái)源。第二種是U8的EAI也就是XML交換接口這個(gè)老項(xiàng)目里用得比較多可以實(shí)現(xiàn)基礎(chǔ)檔案同步和業(yè)務(wù)單據(jù)導(dǎo)入。但EAI在單據(jù)審核、復(fù)雜字段校驗(yàn)上支持得比較有限做采購(gòu)訂單這種涉及金額、稅率、供應(yīng)商、存貨多維度校驗(yàn)的單據(jù)經(jīng)常要繞很多彎。第三種就是CO對(duì)象方式這也是我最終選定的方案。U8的CO組件對(duì)象是通過(guò)UBF發(fā)布出來(lái)的標(biāo)準(zhǔn)業(yè)務(wù)組件里面封裝了采購(gòu)訂單的增刪改審邏輯直接調(diào)用API不僅完美復(fù)用U8本身的校驗(yàn)規(guī)則而且代碼規(guī)?？煽睾罄m(xù)版本升級(jí)時(shí)也相對(duì)不容易崩?？紤]到采購(gòu)訂單在業(yè)務(wù)鏈條里的重要性CO方式的穩(wěn)定性值回票價(jià)。1.2 CO接口的運(yùn)行機(jī)制簡(jiǎn)單理解CO接口就是U8在業(yè)務(wù)層對(duì)外開(kāi)放的一層門(mén)面。每一個(gè)業(yè)務(wù)模塊對(duì)應(yīng)一個(gè)CO對(duì)象文件例如采購(gòu)模塊就對(duì)應(yīng)采購(gòu)訂單相關(guān)的組件對(duì)象。代碼通過(guò)引用U8安裝目錄下的dll或者通過(guò)WebService方式調(diào)用系統(tǒng)就能像正常用戶在U8界面里操作一樣來(lái)創(chuàng)建和修改單據(jù)。這層機(jī)制有兩個(gè)關(guān)鍵點(diǎn)需要注意。一個(gè)是CO對(duì)象依賴登錄上下文也就是說(shuō)所有操作都要先走U8的登錄驗(yàn)證拿到合法的數(shù)據(jù)源、賬套、操作員信息后續(xù)調(diào)用API才能帶上權(quán)限模型。另一個(gè)是調(diào)用API時(shí)傳入的數(shù)據(jù)結(jié)構(gòu)跟數(shù)據(jù)庫(kù)表結(jié)構(gòu)差別很大它要求的是U8定義的VoucherData數(shù)組結(jié)構(gòu)而不是簡(jiǎn)單的DataTable或?qū)嶓w對(duì)象。理解了這兩點(diǎn)后面代碼寫(xiě)起來(lái)就不會(huì)發(fā)怵。2. 開(kāi)發(fā)前期準(zhǔn)備與登錄上下文2.1 環(huán)境依賴和引用清單這部分是我花時(shí)間最多的地方因?yàn)楹芏嗫釉跊](méi)敲代碼之前就埋下了。開(kāi)發(fā)環(huán)境必須先裝好U8客戶端一般裝完客戶端后開(kāi)發(fā)機(jī)里才會(huì)有UFSoft.U8.Framework.LoginAPI這類登錄組件以及采購(gòu)模塊的CO組件dll。這些dll默認(rèn)在U8安裝目錄的bin下面引用的時(shí)候不要自己從網(wǎng)上下載什么所謂的封裝包直接用本機(jī)裝好客戶端后自帶的程序集最穩(wěn)妥。項(xiàng)目類型用的是.NET Framework因?yàn)閁8的CO組件和登錄API本身就是基于老框架構(gòu)建的。如果你硬要用.NET Core或者.NET 5以上去引類型轉(zhuǎn)換上很容易出問(wèn)題尤其是COM互操作這一塊身份模擬和托管類型轉(zhuǎn)換的坑會(huì)讓你懷疑人生。引用清單大致如下UFSoft.U8.Framework.LoginAPI負(fù)責(zé)登錄和獲取TokenUFSoft.U8.Framework.BusinessBase提供CO對(duì)象的基類和業(yè)務(wù)上下文采購(gòu)模塊的CO組件dll不同版本名稱略有差異引用完之后記得在web.config或者app.config里配置好連接信息包括數(shù)據(jù)庫(kù)服務(wù)器地址、數(shù)據(jù)源名稱、賬套號(hào)以及登錄用的操作員賬號(hào)。這里有一點(diǎn)要特別注意操作員賬號(hào)必須是U8系統(tǒng)內(nèi)合法存在的用戶而且需要有對(duì)應(yīng)采購(gòu)訂單的權(quán)限不然接口調(diào)用時(shí)會(huì)直接報(bào)“沒(méi)有操作權(quán)限”。2.2 登錄邏輯與賬套上下文CO方式操作U8的第一個(gè)關(guān)鍵步驟就是建立合法的登錄會(huì)話。很多剛接觸U8 API開(kāi)發(fā)的人最容易在這里卡住因?yàn)榈卿洸皇呛?jiǎn)單傳一個(gè)用戶名密碼進(jìn)去就行。U8的登錄體系里有一個(gè)關(guān)鍵參數(shù)叫Token后續(xù)所有CO對(duì)象調(diào)用都依賴這個(gè)Token來(lái)識(shí)別當(dāng)前操作人、賬套和操作日期。我寫(xiě)了一個(gè)簡(jiǎn)單的封裝大致流程是先創(chuàng)建登錄對(duì)象然后調(diào)用Login方法傳入U(xiǎn)8數(shù)據(jù)源、賬套號(hào)、操作員賬號(hào)、密碼、登錄日期等。登錄成功后會(huì)返回一個(gè)Token字符串保留這個(gè)Token后續(xù)創(chuàng)建CO對(duì)象實(shí)例的時(shí)候會(huì)用到。這里我用C#寫(xiě)一個(gè)示意性代碼不是完整源碼但流程可以直接套// 創(chuàng)建登錄對(duì)象并執(zhí)行登錄 var login new UFSoft.U8.Framework.LoginAPI.clsLogin(); bool isOk login.Login( U8DataSource, // 數(shù)據(jù)源名稱 demo, // 操作員賬號(hào) your-password, // 密碼 , // 語(yǔ)言標(biāo)識(shí) 003, // 賬套號(hào) 2025-01-01, // 登錄日期 // 備份路徑等附加參數(shù) ); if (!isOk) { throw new Exception(U8登錄失敗 login.Message); } string userToken login.Token;在這個(gè)流程里登錄日期這個(gè)參數(shù)要特別留意。U8很多單據(jù)的業(yè)務(wù)日期默認(rèn)會(huì)帶登錄日期如果你傳錯(cuò)了賬期生成的采購(gòu)訂單可能會(huì)跑到上一個(gè)會(huì)計(jì)期間去后面做賬、對(duì)賬都會(huì)出問(wèn)題。所以登錄日期盡量用當(dāng)前業(yè)務(wù)日期不要用服務(wù)器當(dāng)前時(shí)間一把梭。登錄成功之后CO對(duì)象實(shí)例就可以通過(guò)這個(gè)Token建立起來(lái)后面所有操作都帶著這個(gè)身份上下文包括權(quán)限、數(shù)據(jù)權(quán)限范圍、字段級(jí)安全。3. 采購(gòu)訂單增加與修改接口的代碼實(shí)現(xiàn)3.1 新增采購(gòu)訂單的數(shù)據(jù)結(jié)構(gòu)組裝新增采購(gòu)訂單是使用頻率最高的一個(gè)操作。CO方式下核心方法是Add。這個(gè)方法接收兩個(gè)主要參數(shù)一個(gè)是單據(jù)類型標(biāo)識(shí)另一個(gè)就是單據(jù)數(shù)據(jù)對(duì)象。剛開(kāi)始開(kāi)發(fā)時(shí)最容易迷惑的是數(shù)據(jù)結(jié)構(gòu)。U8 CO接口傳的不是一個(gè)簡(jiǎn)單的實(shí)體類而是通過(guò)VoucherData對(duì)象來(lái)組織數(shù)據(jù)這個(gè)對(duì)象內(nèi)部其實(shí)就是一個(gè)多維數(shù)組結(jié)構(gòu)第一維描述表頭字段第二維描述表體字段。數(shù)組里的每一個(gè)元素是有固定格式的VoucherDataField對(duì)象包含字段名稱和字段值。這個(gè)數(shù)據(jù)格式的來(lái)源是U8單據(jù)模板設(shè)計(jì)器里看到的字段名。我踩過(guò)的坑是字段名必須和U8單據(jù)模板完全一致而且如果是自定義擴(kuò)展字段必須在單據(jù)模板里先定義好CO接口才能識(shí)別。為了少走彎路我建議在寫(xiě)代碼前先用U8的模板設(shè)計(jì)器打開(kāi)采購(gòu)訂單模板把表頭字段和表體字段的標(biāo)識(shí)列出來(lái)。采購(gòu)訂單表頭一般包括單據(jù)編號(hào)、單據(jù)日期、供應(yīng)商編碼、部門(mén)編碼、采購(gòu)類型表體一般包括存貨編碼、數(shù)量、單價(jià)、稅率、到貨日期。下面是一段新增采購(gòu)訂單的核心代碼骨架比較口語(yǔ)化地標(biāo)注了關(guān)鍵位置方便你對(duì)照自己的賬套去改// 創(chuàng)建單據(jù)數(shù)據(jù)對(duì)象 VoucherData voucherData new VoucherData(); // 設(shè)置表頭字段 voucherData.Head.AddField(cCode, ); voucherData.Head.AddField(dDate, DateTime.Today); voucherData.Head.AddField(cVenCode, VENDOR001); voucherData.Head.AddField(cDepCode, DEPT01); voucherData.Head.AddField(cPersonCode, PERSON01); voucherData.Head.AddField(cPTCode, PT01); voucherData.Head.AddField(iPOState, 0); // 添加表體行數(shù)據(jù) VoucherDataRow row new VoucherDataRow(); row.AddField(cinvCode, INV001); row.AddField(iQuantity, 100); row.AddField(iUnitPrice, 12.5m); row.AddField(iTaxRate, 13); voucherData.Body.AddRow(row); // 調(diào)用CO對(duì)象執(zhí)行新增 CO_采購(gòu)訂單 coPO new CO_采購(gòu)訂單(); coPO.UserToken userToken; bool result coPO.Add(PO, voucherData);這里特別說(shuō)明一下VoucherData相關(guān)類在不同版本的U8 API中命名會(huì)有差異有的版本直接用數(shù)組object[]來(lái)傳但底層邏輯都一樣表頭、表體、表體明細(xì)行一層層用字段名和值來(lái)映射。如果你的表體有多行就不斷AddRow就可以。新增接口完成后返回值里一般會(huì)帶出系統(tǒng)生成的單據(jù)號(hào)。這個(gè)單據(jù)號(hào)非常重要因?yàn)楹竺嫘薷?、刪除、審核操作時(shí)我們要用這個(gè)單號(hào)來(lái)定位具體是哪一張采購(gòu)訂單。3.2 修改采購(gòu)訂單的邊界條件修改采購(gòu)訂單CO方式對(duì)應(yīng)的方法是Update。但這里有個(gè)硬性條件U8里只允許修改未審核、未被下游單據(jù)引用的采購(gòu)訂單。如果訂單已經(jīng)審核了或者已經(jīng)部分到貨調(diào)用Update會(huì)直接報(bào)錯(cuò)。修改操作和Add不同的地方在于Update必須把主鍵信息帶進(jìn)去也就是單號(hào)或者單據(jù)內(nèi)部標(biāo)識(shí)。在U8的采購(gòu)訂單里最常見(jiàn)的方式是通過(guò)cCode單據(jù)編號(hào)來(lái)定位單據(jù)。下面的代碼邏輯是先構(gòu)造一個(gè)包含主鍵和修改字段的VoucherData再調(diào)用Update// 先定位目標(biāo)單據(jù) VoucherData updateData new VoucherData(); updateData.Head.AddField(cCode, PO202501001); updateData.Head.AddField(dDate, DateTime.Today); updateData.Head.AddField(cVenCode, VENDOR002); updateData.Head.AddField(cDepCode, DEPT02); // 表體可以整體覆蓋也可以只傳要改的行 VoucherDataRow updateRow new VoucherDataRow(); updateRow.AddField(cinvCode, INV002); updateRow.AddField(iQuantity, 200); updateRow.AddField(iUnitPrice, 15.8m); updateData.Body.AddRow(updateRow); CO_采購(gòu)訂單 coPO new CO_采購(gòu)訂單(); coPO.UserToken userToken; bool result coPO.Update(PO, updateData);有一個(gè)容易忽視的點(diǎn)Update的時(shí)候表體內(nèi)容是覆蓋式更新還是增量式更新取決于你們賬套的單據(jù)模板設(shè)置和CO組件實(shí)現(xiàn)。在多數(shù)標(biāo)準(zhǔn)版本里Update傳了整個(gè)表體系統(tǒng)會(huì)用傳入的表體內(nèi)容替換原單據(jù)表體。所以如果你只想改某一行卻只傳了一行表體那其他行可能就被覆蓋掉了。這個(gè)風(fēng)險(xiǎn)很大我的處理方式是修改前先通過(guò)查詢接口把原單據(jù)完整數(shù)據(jù)讀出來(lái)在內(nèi)存里改好需要變更的字段再整體提交給Update。雖然多了一次查詢但至少業(yè)務(wù)數(shù)據(jù)不會(huì)丟。還有一個(gè)細(xì)節(jié)是U8采購(gòu)訂單有表頭和表體的關(guān)聯(lián)字段如irowno行號(hào)。修改時(shí)如果不帶行號(hào)系統(tǒng)可能按順序匹配行一旦中間少了一行后面的數(shù)據(jù)就會(huì)錯(cuò)位。這部分的實(shí)操經(jīng)驗(yàn)是能用Add創(chuàng)建的就別去改老單據(jù)修改操作盡量留給價(jià)格、數(shù)量微調(diào)這種明確場(chǎng)景。復(fù)雜度高的話寧可作廢舊單重新新增也不要硬改因?yàn)槌鰡?wèn)題的排查成本遠(yuǎn)大于重新生成一張單。4. 采購(gòu)訂單刪除與審核接口的實(shí)操過(guò)程4.1 刪除采購(gòu)訂單的約束與實(shí)現(xiàn)刪除采購(gòu)訂單CO方式對(duì)應(yīng)的方法是Delete。從業(yè)務(wù)邏輯上來(lái)講刪除比修改更敏感所以U8的限制也更嚴(yán)只有未審核、未被下游累任何業(yè)務(wù)單據(jù)引用的采購(gòu)訂單才允許刪除。如果這張單子已經(jīng)審核或者已經(jīng)生成了到貨單、入庫(kù)單Delete調(diào)用就會(huì)失敗。調(diào)Delete時(shí)一般需要傳入單據(jù)類型和單據(jù)編號(hào)。它的代碼會(huì)比Add、Update更簡(jiǎn)潔因?yàn)椴挥媒M織完整單據(jù)數(shù)據(jù)只需要告訴CO對(duì)象“我要?jiǎng)h哪張單”即可。我這里給一個(gè)刪單的參考寫(xiě)法CO_采購(gòu)訂單 coPO new CO_采購(gòu)訂單(); coPO.UserToken userToken; // 通過(guò)單據(jù)編號(hào)定位待刪除單據(jù) bool result coPO.Delete(PO, PO202501001);在實(shí)際項(xiàng)目中我一般不會(huì)允許外部系統(tǒng)直接調(diào)Delete接口而是把這個(gè)接口做成“軟刪除”的思路先通過(guò)Update把單據(jù)狀態(tài)改成作廢或者關(guān)閉然后再調(diào)Delete。這么做的原因有兩個(gè)一是防止外部系統(tǒng)誤刪關(guān)鍵單據(jù)二是U8的刪除操作往往會(huì)把關(guān)聯(lián)的后續(xù)記錄也一起反審核或清理一旦誤刪修數(shù)據(jù)比刪數(shù)據(jù)難十倍。如果業(yè)務(wù)上允許作廢而不允許物理刪除我會(huì)在設(shè)計(jì)接口文檔時(shí)直接把這個(gè)邏輯寫(xiě)清楚只暴露作廢操作不暴露物理刪除。如果你所在的企業(yè)確實(shí)需要物理刪除建議在調(diào)用Delete前做二次確認(rèn)讓調(diào)用方傳入一個(gè)額外標(biāo)識(shí)字段比如操作備注、審批單號(hào)然后U8接口里再校驗(yàn)一下這個(gè)標(biāo)識(shí)是否合法。這套流程看起來(lái)多了一道工序但在生產(chǎn)環(huán)境里能擋住很多手誤。4.2 審核采購(gòu)訂單的觸發(fā)時(shí)機(jī)審核操作是采購(gòu)訂單生命周期里最關(guān)鍵的一步。一張訂單只有審核通過(guò)之后下游的到貨、入庫(kù)流程才能走。CO方式下審核對(duì)應(yīng)的方法是Audit接收的參數(shù)同樣是單據(jù)類型和單號(hào)。審核有幾個(gè)注意事項(xiàng)單據(jù)必須處于未審核狀態(tài)已經(jīng)審核的單據(jù)再次調(diào)用審核會(huì)報(bào)錯(cuò)單據(jù)必須存在且完整表頭表體數(shù)據(jù)不能缺關(guān)鍵字段操作員必須具備審核權(quán)限不然會(huì)返回權(quán)限不足的錯(cuò)誤。代碼上審核和刪除類似沒(méi)有復(fù)雜的數(shù)據(jù)結(jié)構(gòu)CO_采購(gòu)訂單 coPO new CO_采購(gòu)訂單(); coPO.UserToken userToken; // 審核指定單號(hào)的采購(gòu)訂單 bool result coPO.Audit(PO, PO202501001);在業(yè)務(wù)時(shí)序上我建議嚴(yán)格遵循“新增 - 審核”的順序不要跨過(guò)中間狀態(tài)直接調(diào)審核。舉個(gè)例子如果外部系統(tǒng)先調(diào)Add生成了一張草稿單然后又調(diào)Audit審核系統(tǒng)會(huì)正常走完。但如果你在Add之后立刻調(diào)Update修改單號(hào)或供應(yīng)商再調(diào)Audit中間狀態(tài)的單據(jù)可能觸發(fā)U8的校驗(yàn)異常比如單據(jù)編號(hào)和供應(yīng)商編碼不一致或者稅率字段沒(méi)有及時(shí)刷新。另外需要提醒的是如果U8啟用了審批流功能那么Audit的行為會(huì)跟標(biāo)準(zhǔn)審核有區(qū)別。審批流模式下采購(gòu)訂單保存后需要走工作流審批不能簡(jiǎn)單地用Audit方法一鍵審核。遇到這種場(chǎng)景你需要額外配置審批流API或者通過(guò)工作流服務(wù)來(lái)推動(dòng)審批節(jié)點(diǎn)。這在我這個(gè)項(xiàng)目里沒(méi)展開(kāi)但如果你所在企業(yè)啟用了審批流一定要提前確認(rèn)。從實(shí)際開(kāi)發(fā)節(jié)奏來(lái)看我建議把新增、修改、刪除、審核四個(gè)接口拆成獨(dú)立的接口方法而不是揉成一個(gè)“一鍵提交”邏輯。因?yàn)槊總€(gè)操作的狀態(tài)機(jī)約束不同外部系統(tǒng)對(duì)接時(shí)往往需要根據(jù)業(yè)務(wù)場(chǎng)景自由組合。比如采購(gòu)變更場(chǎng)景可能需要“先刪后增”或“修改后重新審核”如果接口粒度太粗外部系統(tǒng)反而不好做。5. 高頻問(wèn)題、排查方法與避坑建議5.1 常見(jiàn)報(bào)錯(cuò)速查表我把這次開(kāi)發(fā)過(guò)程中遇到和同行反饋?zhàn)畛Ｒ?jiàn)的幾個(gè)錯(cuò)誤整理成了表格。遇到問(wèn)題時(shí)先對(duì)照排查能省不少時(shí)間。錯(cuò)誤現(xiàn)象可能原因處理方案登錄失敗提示數(shù)據(jù)源錯(cuò)誤數(shù)據(jù)源名稱配置不對(duì)或客戶端服務(wù)器配置未刷新在U8應(yīng)用服務(wù)器配置工具里確認(rèn)數(shù)據(jù)源接口配置保持一致調(diào)用Add時(shí)提示字段不存在字段名與單據(jù)模板不一致或缺少自定義擴(kuò)展字段打開(kāi)模板設(shè)計(jì)器核對(duì)字段標(biāo)識(shí)確認(rèn)自定義字段已發(fā)布Update時(shí)提示單據(jù)已審核無(wú)法修改業(yè)務(wù)狀態(tài)不允許修改先用Audit前狀態(tài)檢查接口確認(rèn)狀態(tài)或走作廢重建流程Audit審核失敗提示無(wú)權(quán)限當(dāng)前操作員缺少采購(gòu)訂單審核權(quán)限用賬套管理員在系統(tǒng)管理里給該用戶分配審核權(quán)限D(zhuǎn)elete失敗提示單據(jù)已被下游引用已有到貨單、入庫(kù)單或發(fā)票關(guān)聯(lián)查詢下游關(guān)聯(lián)單據(jù)先處理下游業(yè)務(wù)再刪單調(diào)用CO對(duì)象時(shí)提示未注冊(cè)客戶端dll未正確引用或缺少程序集注冊(cè)檢查引用路徑重新安裝/修復(fù)U8客戶端這些錯(cuò)誤信息在接口日志里未必會(huì)寫(xiě)得跟上面一模一樣有些會(huì)是錯(cuò)誤碼加一個(gè)簡(jiǎn)短描述。建議你在封裝接口的時(shí)候把CO對(duì)象拋出來(lái)的異常信息原樣記錄到日志文件里不要只記true/false否則后面排查問(wèn)題會(huì)非常被動(dòng)。5.2 幾個(gè)值得注意的避坑細(xì)節(jié)第一個(gè)細(xì)節(jié)是Token生命周期與并發(fā)處理。登錄拿到的Token不是無(wú)限期有效的U8服務(wù)端會(huì)對(duì)登錄會(huì)話設(shè)置過(guò)期時(shí)間通常幾個(gè)小時(shí)到一天不等。如果外部系統(tǒng)是高頻調(diào)用建議做一個(gè)Token緩存池或者定時(shí)刷新機(jī)制不要每次請(qǐng)求都重新登錄否則會(huì)影響性能和穩(wěn)定性。我在項(xiàng)目里是寫(xiě)了一個(gè)定時(shí)任務(wù)每隔一段時(shí)間重新登錄并更新Token同時(shí)加上重試機(jī)制一旦調(diào)用報(bào)登錄失效的錯(cuò)誤就自動(dòng)重新登錄再調(diào)一次。第二個(gè)細(xì)節(jié)是單據(jù)號(hào)策略。U8采購(gòu)訂單的單號(hào)可以由系統(tǒng)自動(dòng)生成也可以手工指定。但如果你在Add的時(shí)候不傳cCode字段系統(tǒng)會(huì)自動(dòng)按流水號(hào)規(guī)則生成如果傳了系統(tǒng)會(huì)按照你傳的值來(lái)創(chuàng)建。自動(dòng)生成的單號(hào)在后續(xù)Update、Delete、Audit時(shí)都需要從Add返回結(jié)果里取出來(lái)所以接口返回參數(shù)一定要把單號(hào)回傳。這里有一個(gè)經(jīng)驗(yàn)采購(gòu)訂單單號(hào)在U8里通常是全公司唯一不同賬套之間也是相互隔離的外部系統(tǒng)維護(hù)映射關(guān)系時(shí)必須帶上賬套號(hào)一起保存不能只存單號(hào)。第三個(gè)細(xì)節(jié)是數(shù)據(jù)權(quán)限和字段級(jí)權(quán)限。即便操作員有采購(gòu)訂單的新增權(quán)限如果分配了數(shù)據(jù)權(quán)限范圍例如只能操作某個(gè)供應(yīng)商或某個(gè)部門(mén)的訂單那么接口調(diào)用時(shí)同樣會(huì)受限于這些權(quán)限規(guī)則。外部系統(tǒng)傳了無(wú)權(quán)限的供應(yīng)商編碼CO接口照樣會(huì)拒絕。這個(gè)問(wèn)題容易在測(cè)試環(huán)境被忽略因?yàn)闇y(cè)試時(shí)大家習(xí)慣用賬套管理員身份所有數(shù)據(jù)都能操作。到了生產(chǎn)環(huán)境權(quán)限一收緊接口就開(kāi)始報(bào)錯(cuò)。所以盡早確認(rèn)生產(chǎn)賬號(hào)的數(shù)據(jù)權(quán)限范圍比上線前才發(fā)現(xiàn)要好得多。第四個(gè)細(xì)節(jié)是冪等性控制。外部系統(tǒng)調(diào)用接口時(shí)可能會(huì)出現(xiàn)網(wǎng)絡(luò)超時(shí)導(dǎo)致接口實(shí)際執(zhí)行成功但調(diào)用方?jīng)]收到響應(yīng)的情況。如果調(diào)用方因此重試就可能生成兩張重復(fù)的采購(gòu)訂單。在接口層面我建議增加一個(gè)冪等鍵比如外部系統(tǒng)的單據(jù)號(hào)來(lái)防止重復(fù)提交。每次Add前先查一下外部單據(jù)號(hào)是否已經(jīng)在本系統(tǒng)里存在存在就直接返回原單信息而不是再新增一張。這個(gè)控制對(duì)采購(gòu)訂單這類業(yè)務(wù)單據(jù)來(lái)說(shuō)特別重要因?yàn)橹貜?fù)訂單帶來(lái)的庫(kù)存和資金影響遠(yuǎn)比其他基礎(chǔ)檔案嚴(yán)重。5.3 測(cè)試要點(diǎn)和上線檢查最后一個(gè)部分聊聊測(cè)試。我的習(xí)慣是先在測(cè)試賬套里準(zhǔn)備一套完整的數(shù)據(jù)鏈路從外部系統(tǒng)創(chuàng)建采購(gòu)訂單到調(diào)用CO接口新增再到審核、修改、刪除全程走一遍。這期間重點(diǎn)檢查三件事單據(jù)號(hào)是否按規(guī)則生成、表體金額和稅額是否正確、審核后的庫(kù)存數(shù)據(jù)是否正常預(yù)占。上線前檢查清單可以參考以下幾條用生產(chǎn)賬號(hào)權(quán)限范圍內(nèi)的供應(yīng)商、存貨、部門(mén)編碼測(cè)試不能用測(cè)試賬號(hào)代替核對(duì)U8賬套的會(huì)計(jì)期間和登錄日期防止單據(jù)落到錯(cuò)誤期間確認(rèn)采購(gòu)訂單模板里的必輸字段都在接口數(shù)據(jù)結(jié)構(gòu)里傳了不要在Add之后才發(fā)現(xiàn)缺字段確認(rèn)應(yīng)用服務(wù)器和U8客戶端在同一網(wǎng)絡(luò)內(nèi)數(shù)據(jù)庫(kù)連接字符串和U8數(shù)據(jù)源配置保持一致準(zhǔn)備好回滾方案比如誤操作時(shí)用Delete或作廢流程處理的文檔。這個(gè)項(xiàng)目整體做下來(lái)我的直接感受是CO方式本身并不復(fù)雜真正的復(fù)雜度都來(lái)自U8的業(yè)務(wù)規(guī)則和數(shù)據(jù)完整性約束。如果你只是寫(xiě)個(gè)接口能通那大概一天就能搞定但如果想讓接口在生產(chǎn)環(huán)境穩(wěn)定跑上幾年前期把單據(jù)狀態(tài)、權(quán)限、冪等、異常日志這些細(xì)節(jié)做扎實(shí)才是最值當(dāng)?shù)耐度搿ＯＭ@份增刪改審接口的開(kāi)發(fā)示例能幫你少踩幾個(gè)坑。本文還有配套的精品資源點(diǎn)擊獲取