2012產品創新數字化峰會有獎征文火熱進行中……
0 引言
Teamcenter是Siemens 公司在整合UGS 和SDRC 的產品和技術優勢后所提供的一套完整的企業級PLM解決方案。Teamcenter能夠支持由制造商、供應商、合作伙伴和客戶組成的擴展企業在網絡環境中生成、共享、管理、集成和評價各種產品數據（包括產品需求、項目數據、工程設計數據、零部件和文檔以及產品配置數據等）。
某大型家電企業使用Teamcenter PLM系統作為其研發產品的生命周期管理工具。任何產品，需要以唯一的銷售碼形式存儲在企業信息系統中，并且與對應的產品生產碼、產品設計碼相關聯，滿足單一數據源與數據可追溯性的要求，規范企業的生產與銷售之間的關系。而企業應用于生產、銷售的信息系統往往是分步實施，其間的關系混亂。為此，筆者力圖通過客戶端的二次應用開發，來解決特定需求，對其他類似問題也具有借鑒意義。
1 銷售碼應用開發方案
1.1 問題描述
企業產品的生產碼、設計碼、銷售碼存在以下現狀。
產品的生產碼作為產品的Item ID，也就是產品的物料編碼，產品的生產碼，在創建產品保存后系統根據生產碼規則自動生成，一經生成便不可更改，并且，當為內銷產品時，業務上被作為銷售碼使用。而產品的設計碼，在創建產品保存后系統根據設計碼規則自動生成，且可手工更改設計碼，它作為產品版本對象表單屬性進行存儲。
其生產碼生成規則如圖1所示。
圖1 生產碼生產規則
第“5～7”位基準產品規格小類：為產品型號中的規格代碼，對規格代碼不足3位的應用“0”補足三位。超過3位的，1000L-3000L,10用A表示，11用B表示，以此類推。3000升及以上的統一用W00表示，字母O和I不得使用，字母X、Y、Z備用。例：BC-48冷藏箱，其規格代碼為48，則應表示為“048”。如BD/BC-1065DKM，其規格代碼為A65。
其設計碼生成規則如圖2所示。
圖2 設計碼生成規則
第一位至第三位取值：產品類別的值為：1、3、4歸類為冰箱，對應的代碼值只能從000-9ZZ，R00-ZZZ生成；產品類別的值為：5、6、7、8歸類為冷柜，對應的代碼值只能從C00-KZZ，P00-QZZ生成。第四位取值：根據產品在分類上的制冷劑分類屬性值獲�。篟12-1；R134a-2；R600a-3；混合工質-4；R404a-5。
由冰箱產品的壓縮機對產品成本影響很大，而壓縮機型號及價格往往隨市場波動很大，所以原本設計相同的同一種產品，由于壓縮機不一樣，產生了多個生產碼，但由于其作為同一種產品對外銷售，在ERP系統中，其銷售碼要唯一，而現階段出現了同一產品多個銷售碼的狀況。而且因以前的設計碼歷史數據的編碼是手工編制，不是按順序編制的，毫無規律可言，也相對混亂。所以急需在PLM系統中尋找一種解決此混亂情況的方法。
1.2 解決方案
根據企業要求銷售碼對象必須存儲銷售碼、銷售碼描述、設計碼、生產碼（數組型）、品牌、品類，且銷售碼和銷售碼描述以及設計碼必須按規則自動生成；銷售碼方案上線前的產品（稱呼為老產品），其生產碼從業務上還是作為銷售碼同時使用，若銷售碼方案上線前的產品（稱呼為老產品）存在壓縮機替代項，則必須由研發部門手工創建壓縮機替代項產品（稱呼為替代項產品），并且系統自動創建一個銷售碼對象，此銷售碼對象的銷售碼和設計碼為老產品的生產碼和設計碼，銷售碼描述根據規則自動合成，銷售碼對象的生產碼屬性存儲老產品的生產碼和替代項產品的生產碼；銷售碼與設計碼前三位的關系為1：1；銷售碼與生產碼關系為1：N，其都是基于型號和顏色決定唯一性。
1.3 應用開發控制方法
根據方案描述，需要在PLM系統對相應的業務點要進行控制。
在不同組織中，同一個銷售碼對應的多個產品（生產碼），若產品對應的型號或顏色發生變化，要求銷售碼及其對應的多個產品的描述必須更改一致（僅針對描述中的型號和顏色）。
在不同組織中，一個產品因工廠轉產存在多個具有相同生產碼的產品（生產碼后加工廠后綴區分），要求這些產品的描述必須更改一致。
產品分類屬性中填寫的壓縮機屬性值必須和產品實際BOM中的壓縮機一致。
在不同組織中，一個產品因工廠轉產存在多個具有相同生產碼的產品（生產碼后加工廠后綴區分），要求這些產品實際BOM中的壓縮機及其配套物料必須一致。
在不同組織中，同一個銷售碼對應的多個產品（生產碼），這些產品實際BOM結構必須一致（除壓縮機及其配套物料之外）。
在不同組織中，不允許存在BOM結構完全一樣而編碼不一樣的兩個物料，包括產品和子裝配件。（除生產工藝引起的原輔料和采購標識不同之外）。
2 系統應用開發
2.1 開發環境
Teamcenter的二次開發分為客戶端和服務器端。客戶端用Java語言開發，同樣它的二次開發也使用Java語言；服務器端的二次開發利用集成工具包( Integrated Tool Ki，t ITK ) 及C語言。由于Teamcenter Engineering版本的升級可能導致所開發程序需要改寫并重新編譯, 所以二次開發的原則是盡可能利用Teamcenter Engineering已有的功能，減少二次開發量�；谝陨峡紤]，二次開發的重心應放在客戶端，盡量利用服務器端的已有功能。
開發程序應用環境如表1所示。
表1 應用環境
應用環境確定后，根據業務需求，PLM系統涉及的數據模型描述如表2所示。
表2 數據模型描述
2.2 系統Handler開發
Teamcenter提供了ITK的開發方式。事實上，ITK是Teamcenter與NX定義的一系列C函數，是一套經過封裝的C語言程序集。其主要用于Handler的創建。
此handler為Workflow具體任務節點的ACTION-Handler，Handler名稱可自定。使用此Handler時，“流程目標對象”會固定為M6_ProductRevision。主要用于新建與產品對應的銷售碼對象，或將新建產品分配入已有銷售碼對象。
具體實施建議放置在“新增圖紙明細審核流程”的發放節點之后。程序邏輯如圖3所示。
圖3 銷售碼生成/關聯邏輯圖
判定檢查“流程目標對象”的itemid是否為51開頭，如果是則“通過”，不是則“不通過”；是否已存在匹配的“銷售碼對象”，獲取“流程目標”的屬性——“產品型號”將屬性“產品型號”，作為搜索輸入，去遍歷M6_SalescodeRevisionMaster的屬性字段——“產品型號”若返回存在滿足條件的ITEM——M6_Salescode；則判定為“存在”；若返回結果為空，則判定為“不存在”；新建銷售碼對象，新建一個ITEM類——M6_Salescode，其itemid自動生成，規則為：“流程目標”的itemid經12位編碼化后（十二位編碼化：流程目標的itemid可能是xxxxxxxxxxxx，也可能是xxxxxxxxxxxx-xxx兩種形式，只需要xxxxxxxxxxxx部分）。將12位化后的結果第2位碼改為固定數字7后得到的“更新后12位編碼”；與新增的銷售碼對象關聯，將“流程目標對象”的itemid，Append至新增的“銷售碼對象”的屬性字段，將新增的“銷售碼對象”ITEM類型——M6_Salescode，以關系M6_SalesRelation關聯到“流程目標對象”所在的M6_Product對象下；加入到匹配的“銷售碼對象”中，在步驟邏輯步驟#1中，記錄返回存在滿足條件的ITEM——M6_Salescode的編碼，將“流程目標對象”的itemid，Append至此滿足條件的“銷售碼對象”的屬性字段；產生“設計碼”屬性，按照規則自動生成“設計碼”，并將生成的結果值，同時寫入新增出的“銷售碼對象”的屬性。
2.3 PLM系統與ERP系統接口傳遞
PLM系統與ERP系統之間的信息由接口進行傳遞。Teamcenter支持Plug-in開發方式實現其客戶化需求。利用Teamcenter提供的開發入口Teamcenter\portal。將入口加入目標平臺，即可利用Plug-in對Teamcenter進行客戶化定制。信息的傳遞即通過Plug-in開發方式，讀取PLM中的信息并將信息寫入中間表，實現信息的傳遞。
利用JAVA線程技術，利用程序每隔20秒時間進行遍歷讀取器工作列表下的任務。順序執行其獲取的任務，根據任務類型選擇具體的處理方法。信息機器人除了具有任務分析及處理功能外，還具備工作日志存儲、出異常關閉、自動重啟等功能。
對于物料的新建、更新，BOM的新建、更新，以及新供應商與物料供應關系，為了完成從PLM到ERP的傳遞，在PLM系統本地數據庫中創建傳遞請求中間表，在ERP系統本地數據庫中創建傳遞反饋中間表，對于每種需要傳遞的數據：
首先由PLM中的信息機器人，響應用戶在工作流任務中提交的傳遞請求動作，將傳遞請求數據記錄到PLM本地的請求中間表，該請求的初始狀態為‘NEW’；
然后定時運行的ERP客戶化程序讀取狀態為‘NEW’的請求數據，如果初步判斷無法接受該請求，則更新PLM中間表的請求記錄為‘REJECTED’狀態；如果可以處理，則在ERP本地的反饋中間表生成對應的傳遞數據記錄，經過進一步轉換處理后，提交ERP標準處理程序進行處理，然后將中間表請求記錄更新為‘ACCEPTED’狀態；
ERP客戶化程序跟蹤ERP標準處理程序的執行結果，更新ERP本地反饋表中傳遞記錄的的狀態為‘SUCCESS’或‘FAIL’狀態；
PLM中的信息機器人響應用戶在工作流任務中執行的檢查傳遞結果動作，讀取ERP反饋表中狀態，反饋給用戶傳遞結果信息；PLM工作流中信息機器人的處理程序，檢查傳遞必須成功，才允許流程向下推進。
其具體傳遞邏輯如圖4所示。
圖4 信息傳遞邏輯圖
3 應用實例
該企業通過新增產品明細工作流程進行銷售碼的生成及數據的傳遞。主要包括工程師提交、標準化審核、會簽、部長批準、系統發布、物料傳遞ERP、物料傳遞到OCM\BOM傳遞到ERP、BOM傳遞到OCM、發送通知等工作步驟。工作流程如圖5所示。
圖5 產品新增明顯流程
在系統發布節點中加入銷售碼生成Handler程序，用于銷售碼的生成；在物料傳遞ERP節點，開發plug-in程序，用于銷售碼的物料傳遞及銷售碼與生產碼關系傳遞。
銷售碼生成部分代碼如下：
AOM_ask_value_string(revMasterTag，"m6_product_model"，&xinghao_value1)；
ICS_ico_find(""，attachObjectTags[i]，ICS_SEARCH_ORDER_BY_ID，&theCount，&theICOTags)；
ICS_ico_ask_class(theICOTags[h]，&theClassId)；
ICS_ask_attribute_value(theICOTags[h]，"*顏色"，&attributeValue)；
ICS_ask_attribute_value(theICOTags[h]，"*制冷劑"，&zhilengjiValue)；
ICS_keylov_get_keylov(key_lov_id，&key_lov_name，&options，&n_lov_entries，&lov_keys，&lov_values，&deprecated_staus，&owning_site，&n_shared_sites，&shared_sites)；
……
//銷售碼創建
ITEM_create_item(item_id，NULL，"M6_Salescode"，NULL，&tagSalescodeItem，&tagSalescodeItemrev)；
流程運行結束之后，實際產生銷售碼符合銷售碼生成規則，其與生產碼關系傳遞正確。
4 結束語
PLM系統實施過程中，業務流程需求往往會產生新的技術需求。如何讓PLM系統更適合具體企業，使其達到預期的效果，需要業務人員與開發人員緊密合作。此PLM系統銷售碼啟用，正是業務人員與開發人員相互配合實施的良好案例。實踐證明，Teamcenter系統中銷售碼的開發應用，滿足了企業額業務需求，解決了企業銷售碼、生產碼、設計碼混亂的現狀，提高了企業的生產效率，提升了企業的市場競爭力。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
相關文章
