我們都知道物料編碼是erp系統工作的基本前提條件，絕大多數業務物料編碼比較容易，有什麼物料就先確定乙個編碼然後錄入系統即可。我今天要討論的話題是，在某些行業的物料編碼可沒有那麼簡單，而眾所周知的erp產品軟體，似乎也不支援解決這種問題的好方案。讓我們看下是什麼樣的物料編碼如此困難吧。
在珠寶行業裡面，比如鑽石這種物料就存在手工編碼非常困難的場景，認定乙個鑽石是否和另外乙個鑽石是相同的，要通過比較鑽石的9個引數屬性才能確定，具有相同引數的鑽石**相同，配料什麼的可以通用，如果其中任何乙個引數的值不同，那就是不同的鑽石，**也不同，配料也不能通用。
鑽石的9個引數如下圖所示：
其中克拉引數的範圍值是0-999分，理論上是沒有上限的，但公司實際業務上用到的鑽石大小就是這個範圍，只能取整數，也就是鑽石大小有999種可能了。其他的引數的值都算有限的集合。公司的業務是顧客可以選購任意一種引數值的組合，我們可以計算出實際上公司業務中鑽石物料可能有多少呢？很簡單的乙個數學題就是排列組合了，計算公式為：999x6x10x12x5x5x4x7x9=4531464000種鑽石物料可用於系統中，這麼多種物料，想象一下用手工方式乙個個錄入系統那是一種怎樣的情境，估計沒有公司願意有人幹這事的。以上圖中鑽石引數屬性值，部分不完整，因為太多我就沒有一一例舉出來了。
那我們該如何解決呢？我所知道的sap解決方案是乙個叫做」可配置製造「這麼個東西，大概做法是鑽石物料編碼只定義到克拉乙個引數，那就會有999個物料編碼，這樣就大大縮小了錄入範圍，其他的引數通過對物料編碼z50（假設代表50分的鑽石）進行進一步詳細描述來作為最終確定是某種鑽石。相當於我們在訂單明細中，對這個50分的鑽石，進行了詳細的描述，其他訂單的每個明細鑽石，我們都要做這樣的工作，其他8個引數值作為該訂單明細鑽石的附屬資訊和明細關聯在一起，後面的採購加工等環節都從訂單明細的這個附屬資訊表中獲取這個z50物料的附屬資訊。
以上sap的解決方案也確實能解決那些引數眾多，難以手工一一編碼的物料型別，但是這個方案有個很大的缺點，就是整個系統以一種非常不精確的狀態在執行著，比如說，配料的時候不能直接通過物料編碼z50來尋找庫存，而是先要找到所有50分的鑽石，然後乙個個對其他引數部分進行逐個比較，直到其餘8個引數值都一樣才算匹配到了庫存。在統計鑽石銷量的時候，也沒有辦法很快統計出哪種鑽石銷量最好，等等這些情況下，都是因為物料編碼不精準造成的。
我認為的好的解決方案就是系統按照一種規則通過識別鑽石的9個引數值，進行自動物料編碼。規則如下所述，定義克拉引數為3位數字，範圍是000~999，如050代表鑽石克拉值是50分。其餘引數都用2位數字表示，範圍是00~99，如螢光02代表vg值，00則表示該項引數值為空值。然後根據以上圖中各個引數的排列次序將這些數字連線組合在一起就構成了乙個具體鑽石的唯一編碼了，如0500102040203010102編碼代表鑽石引數為克拉：50分，切工：ideal，淨度：vvs1，顏色：h，螢光：vg，拋光：med，對稱：ex，形狀：圓形，外觀顏色：紅，的鑽石商品。
那什麼時候匯入呢？因為鑽石理論上的排列組合實在太多（45億），而實際業務中常用的可能就20萬左右，但是哪20萬型別的鑽石常用，這個是不可知道的，客戶選到什麼鑽石就是什麼鑽石，而且有些引數組合的鑽石實際上也不存在（世界上還沒有出現過這種鑽石）。所有的都是不可**和知道的，系統也沒有必要將這45億鑽石全部先自動生成好存入物料庫中。應該是在實際用到什麼鑽石就及時生成這樣的鑽石物料編碼才對，所以一般只對採購入庫和客戶下訂單那兩個地方系統通過識別鑽石引數值，然後按照定義好的規則自動生成物料編碼即可。
通過這樣的方式解決引數眾多的物料編碼問題，系統後面的配料、領料、庫存查詢、銷售統計等模組就能很好的工作了，系統效率也會得到大大提公升。以上方法來自實踐經驗所得，如有雷同純屬巧合，有不妥之處，還望專家學者批評指正。