摘要：目前企業管理軟件的數據結構大多采用關係型數據庫，隨着系統處理的業務的增多，數據結構、內容和彼此相關的邏輯關係越來越複雜，整個系統在企業應用中不僅學習成本高，實施困難，而且對於企業的個性化需求二次開發難度都非常大。本文提出一種全新的數據結構和算法：“二元”分析法，用簡單的數據結構即可滿足企業管理中數據處理的需要，並且可以非常方便地修改、調整，邏輯清晰明瞭，思維方式契合管理理念，核心運算只需三個Table就可以完成。通過一個簡單的示例，介紹說明該數據結構和算法，以及在管理應用中的使用變化。該算法不同於傳統管理軟件的結構和思維方式，以極簡的辦法解決了複雜的問題，並且在此思路上還有更大的創新、擴展空間。
企業信息化是計算機應用中的一個重要領域，信息技術在企業管理中的應用對企業管理效率的提高，規範化管理等發揮着重要作用。但在企業管理軟件在企業的應用，特別是在中小企業中的應用卻不盡人意，經過多年的努力業界提供了各種概念和解決方案，成功的案例不多。大多數中小企業還停留在使用Office系統產品，做簡單的文檔和數據處理，僅實現了無紙化辦公的初級要求，目前國內企業面臨轉型壓力，迫切需要管理工具幫助企業提高管理水平，提高工作效率。在中小企業的信息化中，困難主要在於兩點：一是系統太複雜，學習和實施比較困難，費用也比較高；二是系統僵硬，管理內容和模式固定，個性化適應性差，二次開發難度高，實際根源在於系統結構太複雜、龐大，缺乏彈性。爲此經過多年在甲乙兩方的工作經驗的總結，創新出一種全新模式的數據結構和算法，極大的簡化了數據結構，這樣就很易於系統的配置和修改。在使用這一算法的基礎上設計的企業信息化工具，可以讓企業以極低的投入建立適合自己企業的信息系統，並且可以伴隨企業的發展，管理的進步不斷調整、修改，作爲真正的“企業管理信息化工具”幫助中小企業完成信息化建設。
聲明：題目中“三個Table”是指記錄、統計和計算的核心只要用三個表，如果做成完整的軟件還需其他數據的補充協助；“ERP”是泛指企業管理中對業務數據的管理應用，如ERP、進銷存等，不是嚴格意義的ERP，僅爲了便於描述。
1 傳統信息化軟件越來越複雜的原因
傳統管理軟件，不論是進銷存、ERP，還是爲行業量身打造的各種管理系統，通常都不外乎遵循：根據“業務數據”產生“表單”，然後經過“數據邏輯處理”保存到對應的“數據庫”中；查看、統計時，根據表的內容設計“查詢統計邏輯”，將結果輸出，如下圖：
圖1 傳統軟件數據處理模式
這樣的結構， “業務數據”、“邏輯處理”和“數據庫”這三層的關係是一一對應的，或者相互交叉、組合的，那麼隨着業務內容的增加，各個環節都會相應增加，業務越複雜，邏輯和數據庫也就越複雜。作爲管理軟件的供應商，爲使自己的軟件可以有更廣泛的適應性，儘量把可能會用到的管理內容加到系統中，把系統做得越來越龐大，越來越複雜，甚至以此爲傲。但這樣的系統對中小企業來說實施的困難就加大了，特別是當有行業個性化需求的時候，需要修改和添加功能，就幾乎是不可能完成的任務。雖然各廠商紛紛推出各自的PaaS系統，包裝了許多API、UI元素，“低代碼開發”甚至“0代碼開發”以提高開發的效率，但根基就是那麼複雜，中小企業自己很難駕馭，委託二次開發成本也太高，往往是個“坑”。這應該是多年來在中小企業推廣信息化非常艱難的原因之一。
如果我們目標在“簡化管理系統”，必須要考慮從根本上改變這個邏輯結構。
2 “二元”分析法的核心思想
上面所說的結構是從數據庫技術的角度去做企業管理，實際上我們應該拋開數據庫的理論結構，從管理應用的角度去思考系統的架構。也就是說當企業產生了一個業務數據，傳統思維只盯住數據，處理的方法就是把數據存儲到對應的數據庫表中，新的思維模式是首先分解這個業務操作的“管理意義”，所謂“管理意義”就是業務操作對整個管理系統的各個方面的影響和作用。例如：做了一個“入庫”的工作，那麼產生的“管理意義”就可能是：①產生了若干數量某物料的“庫存”，②產生對某供應商的“應付款”（假設是貨到付款）。設定那些“管理意義”和具體操作無關，企業根據管理流程和管理關注點的不同，設定的“管理影響”項目也可以不同。假如企業又有一項工作是“客供物料入庫”，那麼這個業務的“管理意義”只有①產生了若干數量某物料的“庫存”，和上面的入庫一樣，但沒有②產生“應付款”。一項工作可以對整個管理系統有多項影響，產生多個“管理意義”；而對於某項“管理意義”可能來源於不同的工作。這樣，通過對每個業務操作解析出“管理意義”，使具體的操作數據和管理邏輯分開，“松耦合”，這樣設置和修改就相對清晰、容易。
一個完整的企業管理系統是由一個個業務工作有順序、有邏輯、有制約組成的，都是鏈條上的一環，那麼如何將們鏈接在一起呢？這裏引入了我們古老智慧中的哲學“世間萬物，陰陽互變，有陰即有陽”，事物都有其“兩面性”，也就是說對於每個業務工作產生的每項“管理意義”都要找到它的“另一面”，例如上面的例子中，入庫操作產生了一個“庫存”的“管理意義”，如果把這個設爲“＋”，那麼假設這個入庫是根據某個採購單來的，可以設定另一個“管理意義”，即“已下單未交貨數量”，這個設爲“－”，而對於“下采購單”的這個業務操作，它產生的“管理意義”對於“已下單未交貨數量”就是“＋”，形成下面的關係：
圖2 “二元”關係描述
這樣，兩項工作就通過一對對“＋”“－”，就像鏈條的每個環節都有兩端那樣，首尾相連，建立起企業管理的完整鏈條。並且相互關係清晰明瞭，當需要關注某些管理要素的時候查詢統計會非常簡單，例如：想查看一下供應商還有多少沒交貨，合計“已下單未交數量”這個“管理意義”就得出結果了。假設我們考慮每項工作可能會對“物料”和“財務”兩方面產生影響，例如上面“入庫”的操作，在數量上產生庫存，同時在財務方面要產生相應的“應付款”，這樣我們就可以建立如下的模型：
圖3 “二元”算法數據處理模型
對“物料”和“財務”這兩方面的邏輯可以分別設置，在各項工作中可以單獨分解對這兩個方面的影響。這些就是新數據架構的主要核心思想，下面舉個簡單的例子說明一下。
3 簡單的數據模擬演示
基於上面的理論，我們模擬一個簡單的外貿業務系統，業務內容是：和外商簽訂合同，在國內找供應商生產採購，然後出口，賺取差價。將用“三個Table”，即可完成對全部業務的存儲，數據的統計管理，並且可以方便的擴展和修改調整。
3.1 先做幾項準備工作對管理系統的結構和邏輯進行設計
在進行數據配置之前，先對業務數據進行整理，作爲配置的基礎。整理的內容爲“一圖二表”，一圖是整理“業務流程圖”，“二表”爲“關鍵字段表”和“邏輯關係表”。
3.1.1 理順工作流程，畫出業務流程圖如下：
圖4 模擬企業管理流程圖
此圖可以看出管理系統所涉及的各項工作及順序、邏輯關係等。
3.1.2 分解各項工作的“管理意義”形成“邏輯關係表”
首先明確幾個概念，上面論述的“管理意義”，簡稱爲“科目”，實例中分解每項工作對“物料”和“財務”兩個方面的管理意義，如下圖所示，並且相應進行編號。
圖5 各項工作的管理意義和邏輯關係
3.1.3 列出每項工作的具體數據內容，確定“關鍵數據表”
所謂“關鍵數據”是指在工作數據中，不僅要記錄在本工作的單據中，其內容還要在後續的工作中不斷引用，或者作爲條件去查詢的，例如：合同簽訂工作中，具體數據：
表1 “合同簽訂”數據內容
|
||||||||||||||||||||
|
產品編號 |
產品名稱 |
規格型號 |
單位 |
單價 |
數量 |
金額 |
||||||||||||||
|
CP001 |
變壓器 |
KM9824 |
個 |
12.6 |
1000 |
12600 |
||||||||||||||
|
CP002 |
電感 |
ML7823 |
個 |
8.4 |
2000 |
16840 |
||||||||||||||
其中的“合同號”、“產品編號”、“規格型號” 、“單位”和“單價”等數據，在後續的採購、出入庫的工作中都有可能會需要，也就是說“關鍵數據”是在整個管理系統中共同普遍關注的數據。
下面把各項工作的“關鍵數據”羅列在一起，因爲有很多工作是在前一個工作的基礎上進行的，例如：入庫工作是根據採購的數據進行入庫，就對上面的數據基礎上只產生“入庫單據號”就可以，很多數據是在各項工作間共用的，所以總的並不多，標識中“*”是在該項工作中產生輸入的數據，“#”爲沿用上面工作的數據。
圖6 各項工作所涉及的關鍵數據列表
到此爲止，對於整個管理系統的邏輯規劃設計就已完成，整個管理系統的邏輯關係和數據內容都體現出來了。根據管理的要求建立了管理邏輯，把每項工作對“物”和“財”兩方面對管理的影響都分解出來，這樣工作的具體數據和邏輯設置是分離的，可以綜合考慮，分別設計，一個工作有多項影響，而邏輯中的某項“管理影響”可以由不同的工作產生數據。
下面就在三個表中按照上面的邏輯設計運行。
3.2 模擬數據運行
這裏使用MySQL數據庫來演示，首先建立三個表，mat，mon，index，表結構如下：
表2 mat表結構
|
字段 |
類型 |
作用 |
|
No |
int |
序號 |
|
MatIndex |
int |
Index表主鍵 |
|
MatId |
String |
邏輯組編號 |
|
MatSubId |
String |
科目號 |
|
MatValue |
Float |
數量值 |
表3 mon表結構
|
字段 |
類型 |
作用 |
|
No |
int |
序號 |
|
MonIndex |
int |
Index表主鍵 |
|
MonId |
String |
邏輯組編號 |
|
MonSubId |
String |
科目號 |
|
MonValue |
Float |
數量值 |
表4 index表結構
|
字段 |
類型 |
作用 |
|
WID |
int |
索引號 |
|
workId |
String |
*工作編號 |
|
HTId |
String |
*合同號 |
|
KHName |
String |
客戶名稱 |
|
CPId |
String |
產品編號 |
|
CPName |
String |
產品名稱 |
|
Size |
String |
規格型號 |
|
Unit |
String |
產品單位 |
|
CPPrice |
Float |
產品單價 |
|
GYSName |
String |
供應商名稱 |
|
CGPrice |
Float |
採購單價 |
|
CKNo |
String |
倉庫單據號 |
|
CWNo |
String |
財務單據號 |
三個表的關係是：mat表的MatIndex字段和mon表的MonIndex字段都和index表的WID字段關聯。
在實際應用中mat和mon表不用動，僅根據管理系統的各項工作內容不同添加index表中的字段即可。下面我們模擬業務運行這6項工作。
3.2.1 合同簽訂
單據內容：
表5 “合同簽訂”模擬數據內容
|
||||||||||||||||||||
|
產品編號 |
產品名稱 |
規格型號 |
單位 |
單價 |
數量 |
金額 |
||||||||||||||
|
CP001 |
變壓器 |
KM9824 |
個 |
12.6 |
1000 |
12600 |
||||||||||||||
|
CP002 |
電感 |
ML7823 |
個 |
8.4 |
2000 |
16840 |
||||||||||||||
在三個表添加的內容：
表6 在index表中添加的數據
|
WID |
WorkId |
HTId |
KHName |
CPId |
CPName |
Size |
Unit |
CPPrice |
CGHTId |
GYSName |
CGPrice |
CKNo |
CWNo |
|
4 |
W001 |
HT0183 |
客戶 |
CP001 |
變壓器 |
KM9824 |
個 |
12.6 |
|
|
|
|
|
|
5 |
W001 |
HT0183 |
客戶 |
CP002 |
電感 |
ML7823 |
個 |
8.4 |
|
|
|
|
|
表7 在mat表中添加的數據
|
No |
MatIndex |
MatId |
MatSubId |
MatValue |
|
9 |
4 |
M001 |
1001 |
-1000 |
|
10 |
4 |
M001 |
1002 |
1000 |
|
11 |
5 |
M001 |
1001 |
-2000 |
|
12 |
5 |
M001 |
1002 |
2000 |
表8 在mon表中添加的數據
|
No |
MonIndex |
MonId |
MonSubId |
MonValue |
|
9 |
4 |
C001 |
1001 |
-12600 |
|
10 |
4 |
C001 |
1002 |
12600 |
|
11 |
5 |
C001 |
1001 |
-16800 |
|
12 |
5 |
C001 |
1002 |
16800 |
解釋：爲了簡化數據結構，數據不分“主從”，按明細的記錄數量記錄，所以首先在index表中產生兩條記錄，並自動生成“WID”號，而對於每條記錄的正負是根據邏輯設計的：
圖7 “合同簽訂”工作物料科目、財務科目邏輯設置
在“物料”和“財務”都各有一對科目記錄，所以在mat表和mon表中各添加“兩對”四條記錄，並且其中的MatIndex字段和MonIndex字段的值和index表中的WID相關聯對應
可以看到這樣處理一項工作的涉及邏輯的數據被分離出去了，關鍵數據被集中管理了。
這時，如果想查看“有哪些產品需要採購？”可以運行如下SQL語句：
|
SELECT DISTINCT `index`.HTId AS `合同號`, `index`.KHName AS `客戶名稱`, `index`.CPId AS `產品編號`, `index`.CPName AS `產品名稱`, `index`.Size AS `規格型號`, `index`.Unit AS `單位`, Sum(mat.MatValue) AS `需求數量` FROM `index` , mat WHERE `index`.WID = mat.MatIndex AND mat.MatSubId = '1002' AND `index`.HTId = 'HT0183' GROUP BY `index`.CPId |
其中：查詢條件，合同號HT0183，科目“1002”就是在邏輯設計表中的“採購需求”。運行結果：
表9 “產品需求”查詢結果
|
合同號 |
客戶名稱 |
產品編號 |
產品名稱 |
規格型號 |
單位 |
需求數量 |
|
HT0183 |
客戶 |
CP001 |
變壓器 |
KM9824 |
個 |
1000 |
|
HT0183 |
客戶 |
CP002 |
電感 |
ML7823 |
個 |
2000 |
3.2.2 採購合同簽訂
根據簽訂的外銷合同，在國內進行採購，可以從多家工廠分別採購。
單據內容：
表10 採購合同模擬數據內容
|
||||||||||||||||||
|
產品編號 |
產品名稱 |
規格型號 |
單位 |
單價 |
數量 |
金額 |
||||||||||||
|
CP001 |
變壓器 |
KM9824 |
個 |
8.34 |
800 |
6672 |
||||||||||||
在三個表中添加內容：
表11 在index表中添加的數據（黃色爲新增數據）
|
WID |
WorkId |
HTId |
KHName |
CPId |
CPName |
Size |
Unit |
CPPrice |
CGHTId |
GYSName |
CGPrice |
CKNo |
CWNo |
|
4 |
W001 |
HT0183 |
客戶 |
CP001 |
變壓器 |
KM9824 |
個 |
12.6 |
|
|
|
|
|
|
5 |
W001 |
HT0183 |
客戶 |
CP002 |
電感 |
ML7823 |
個 |
8.4 |
|
|
|
|
|
|
6 |
W002 |
HT0183 |
客戶 |
CP001 |
變壓器 |
KM9824 |
個 |
12.6 |
CG001867 |
電子廠1 |
8.34 |
|
|
表12 在mat表中添加的數據
|
No |
MatIndex |
MatId |
MatSubId |
MatValue |
|
…… |
||||
|
13 |
6 |
M002 |
1002 |
-800 |
|
14 |
6 |
M002 |
1003 |
800 |
表13 在mon表中添加的數據
|
No |
MonIndex |
MonId |
MonSubId |
MonValue |
|
…… |
||||
|
13 |
6 |
C002 |
1003 |
-6672 |
|
14 |
6 |
C002 |
1004 |
6672 |
這時再運行SQL語句BI001，查詢結果：
表14 “產品需求”再查詢結果
|
合同號 |
客戶名稱 |
產品編號 |
產品名稱 |
規格型號 |
單位 |
需求數量 |
|
HT0183 |
客戶 |
CP001 |
變壓器 |
KM9824 |
個 |
200 |
|
HT0183 |
客戶 |
CP002 |
電感 |
ML7823 |
個 |
2000 |
再做一個採購合同：
單據內容：
表15 第二個採購合同模擬數據內容
|
||||||||||||||||||
|
產品編號 |
產品名稱 |
規格型號 |
單位 |
單價 |
數量 |
金額 |
||||||||||||
|
CP001 |
變壓器 |
KM9824 |
個 |
8.56 |
200 |
1712 |
||||||||||||
|
CP002 |
電感 |
ML7823 |
個 |
6.82 |
2000 |
13640 |
||||||||||||
在三個表中添加數據：
表16 在index表中添加的數據
|
WID |
WorkId |
HTId |
KHName |
CPId |
CPName |
Size |
Unit |
CPPrice |
CGHTId |
GYSName |
CGPrice |
CKNo |
CWNo |
|
…… |
|||||||||||||
|
7 |
W002 |
HT0183 |
客戶 |
CP001 |
變壓器 |
KM9824 |
個 |
12.6 |
CG001868 |
電子廠2 |
8.56 |
|
|
|
8 |
W002 |
HT0183 |
客戶 |
CP002 |
電感 |
ML7823 |
個 |
8.4 |
CG001868 |
電子廠2 |
6.82 |
|
|
表17 在mat表中添加的數據
|
No |
MatIndex |
MatId |
MatSubId |
MatValue |
|
…… |
||||
|
15 |
7 |
M002 |
1002 |
-200 |
|
16 |
7 |
M002 |
1003 |
200 |
|
17 |
8 |
M002 |
1002 |
-2000 |
|
18 |
8 |
M002 |
1003 |
2000 |
表18 在mon表中添加的數據
|
No |
MonIndex |
MonId |
MonSubId |
MonValue |
|
…… |
||||
|
15 |
7 |
C002 |
1003 |
-6672 |
|
16 |
7 |
C002 |
1004 |
6672 |
|
17 |
8 |
C002 |
1003 |
-13640 |
|
18 |
8 |
C002 |
1004 |
13640 |
這個操作就相當於把剩下的“產品需要”都採購了，可以看到在mat表中記錄了科目數量的變化，mon表中財務金額的變化。
3.2.3 產品入庫
根據採購合同做一筆入庫，訂貨800個，實際到貨810個，要按照實際收貨數量付款。
單據內容：
表19 產品入庫模擬數據內容
|
||||||||||||||||
|
產品編號 |
產品名稱 |
規格型號 |
單位 |
單價 |
數量 |
金額 |
||||||||||
|
CP001 |
變壓器 |
KM9824 |
個 |
8.34 |
810 |
6755.4 |
||||||||||
在三個表中添加內容：
表20 在index表中添加的數據
|
WID |
WorkId |
HTId |
KHName |
CPId |
CPName |
Size |
Unit |
CPPrice |
CGHTId |
GYSName |
CGPrice |
CKNo |
CWNo |
|
|
…… |
||||||||||||||
|
9 |
W003 |
HT0183 |
客戶 |
CP001 |
變壓器 |
KM9824 |
個 |
12.6 |
CG001867 |
電子廠1 |
8.34 |
RK012 |
|
|
表21 在mat表中添加的數據
|
No |
MatIndex |
MatId |
MatSubId |
MatValue |
|
…… |
||||
|
19 |
9 |
M003 |
1003 |
-810 |
|
20 |
9 |
M003 |
1004 |
810 |
表22 在mon表中添加的數據
|
No |
MonIndex |
MonId |
MonSubId |
MonValue |
|
…… |
||||
|
19 |
9 |
C003 |
1004 |
-6755.4 |
|
20 |
9 |
C003 |
1005 |
6755.4 |
查看統計結果：
操作到這個環節，爲了方便查看數據的變化，建立一套“企業綜合報表”，有如下結果：
表23 合同明細
|
產品編號 |
產品名稱 |
規格型號 |
單位 |
數量 |
|
CP001 |
變壓器 |
KM9824 |
個 |
1000 |
|
CP002 |
電感 |
ML7823 |
個 |
2000 |
表24 採購情況
|
生產廠名稱 |
產品編號 |
產品名稱 |
規格型號 |
單位 |
數量 |
|
電子廠2 |
CP001 |
變壓器 |
KM9824 |
個 |
200 |
|
電子廠2 |
CP002 |
電感 |
ML7823 |
個 |
2000 |
|
電子廠1 |
CP001 |
變壓器 |
KM9824 |
個 |
800 |
表25 產品庫存
|
產品編號 |
產品名稱 |
規格型號 |
單位 |
數量 |
|
CP001 |
變壓器 |
KM9824 |
個 |
810 |
表26 應付款
|
生產廠名稱 |
採購單號 |
應付款 |
|
電子廠1 |
CG001867 |
6755.4 |
表27 應收款
|
客戶名稱 |
發貨單號 |
應收款 |
|
|
|
|
數據顯示的結果符合實際工作的進展情況，並且可以達到管理要求。
上面的報表，參考SQL語句：
|
合同產品明細 |
採購情況 |
產品庫存 |
|
SELECT DISTINCT `index`.CPId AS `產品編號`, `index`.CPName AS `產品名稱`, `index`.Size AS `規格型號`, `index`.Unit AS `單位`, Sum(mat.MatValue) AS `數量` FROM `index` , mat WHERE `index`.WID = mat.MatIndex AND `index`.WorkId = 'W001' AND mat.MatSubId = '1002' AND `index`.HTId = 'HT0183' GROUP BY `index`.CPId |
SELECT DISTINCT `index`.GYSName AS `生產廠名稱`, `index`.CPId AS `產品編號`, `index`.CPName AS `產品名稱`, `index`.Size AS `規格型號`, `index`.Unit AS `單位`, Sum(mat.MatValue) AS `數量` FROM `index` , mat WHERE `index`.WID = mat.MatIndex AND `index`.WorkId = 'W002' AND mat.MatSubId = '1003' AND `index`.HTId = 'HT0183' GROUP BY `index`.GYSName, `index`.CPId ORDER BY `生產廠名稱` ASC, `產品編號` ASC
|
SELECT DISTINCT `index`.CPId AS `產品編號`, `index`.CPName AS `產品名稱`, `index`.Size AS `規格型號`, `index`.Unit AS `單位`, Sum(mat.MatValue) AS `數量` FROM `index` , mat WHERE `index`.WID = mat.MatIndex AND mat.MatSubId = '1004' AND `index`.HTId = 'HT0183' GROUP BY `index`.CPId |
|
應付款 |
應收款 |
|
|
SELECT `index`.GYSName AS `生產廠名稱`, `index`.CGHTId AS `採購單號`, Sum(mon.MonValue) AS `應付款` FROM `index` , mon WHERE `index`.WID = mon.MonIndex AND mon.MonSubId = '1005' GROUP BY `index`.GYSName ORDER BY `生產廠名稱` ASC |
SELECT `index`.KHName AS `客戶名稱`, `index`.CKNo AS `發貨單號`, Sum(mon.MonValue) AS `應收款` FROM `index` , mon WHERE `index`.WID = mon.MonIndex AND mon.MonSubId = '1006' GROUP BY `index`.CKNo |
|
統計查詢也就是圍繞這三個表，變換一下“科目”的相關查詢條件就可以，也很簡單，邏輯清晰。
下面同樣的道理，把第二筆採購合同全部入庫。
表28 第二筆產品入庫模擬數據內容
|
||||||||||||||||
|
產品編號 |
產品名稱 |
規格型號 |
單位 |
單價 |
數量 |
金額 |
||||||||||
|
CP001 |
變壓器 |
KM9824 |
個 |
8.56 |
200 |
1712 |
||||||||||
|
CP002 |
電感 |
ML7823 |
個 |
6.82 |
2000 |
13640 |
||||||||||
三個表添加數據：
表29 在index表中添加的數據
|
WID |
WorkId |
HTId |
KHName |
CPId |
CPName |
Size |
Unit |
CPPrice |
CGHTId |
GYSName |
CGPrice |
CKNo |
CWNo |
|
|
…… |
||||||||||||||
|
10 |
W003 |
HT0183 |
客戶 |
CP001 |
變壓器 |
KM9824 |
個 |
12.6 |
CG001868 |
電子廠2 |
8.56 |
RK013 |
|
|
|
11 |
W003 |
HT00183 |
客戶 |
CP002 |
電感 |
ML7823 |
個 |
8.4 |
CG001868 |
電子廠2 |
6.82 |
RK013 |
|
|
表30 在mat表中添加的數據
|
No |
MatIndex |
MatId |
MatSubId |
MatValue |
|
…… |
||||
|
21 |
10 |
M003 |
1003 |
-200 |
|
22 |
10 |
M003 |
1004 |
200 |
|
23 |
11 |
M003 |
1003 |
-2000 |
|
24 |
11 |
M003 |
1004 |
2000 |
表31 在mon表中添加的數據
|
No |
MonIndex |
MonId |
MonSubId |
MonValue |
|
…… |
||||
|
21 |
10 |
C003 |
1004 |
-1712 |
|
22 |
10 |
C003 |
1005 |
1712 |
|
23 |
11 |
C003 |
1004 |
-13640 |
|
24 |
11 |
C003 |
1005 |
13640 |
3.2.4 產品出庫
單據內容：
表32“產品出庫”模擬數據內容
|
||||||||||||||||
|
產品編號 |
產品名稱 |
規格型號 |
單位 |
單價 |
數量 |
金額 |
||||||||||
|
CP001 |
變壓器 |
KM9824 |
個 |
12.6 |
700 |
8820 |
||||||||||
|
CP002 |
電感 |
ML7823 |
個 |
8.4 |
1200 |
10080 |
||||||||||
三個表添加的數據：
表33 在index表中添加的數據
|
WID |
WorkId |
HTId |
KHName |
CPId |
CPName |
Size |
Unit |
CPPrice |
CGHTId |
GYSName |
CGPrice |
CKNo |
CWNo |
|
|
…… |
||||||||||||||
|
12 |
W004 |
HT0183 |
客戶 |
CP001 |
變壓器 |
KM9824 |
個 |
12.6 |
|
|
|
|
CK003 |
|
|
13 |
W004 |
HT00183 |
客戶 |
CP002 |
電感 |
ML7823 |
個 |
8.4 |
|
|
|
|
CK003 |
|
表34 在mat表中添加的數據
|
No |
MatIndex |
MatId |
MatSubId |
MatValue |
|
…… |
||||
|
25 |
12 |
M004 |
1004 |
-700 |
|
26 |
12 |
M004 |
1005 |
700 |
|
27 |
13 |
M004 |
1004 |
-1200 |
|
28 |
13 |
M004 |
1005 |
1200 |
表35 在mon表中添加的數據
|
No |
MonIndex |
MonId |
MonSubId |
MonValue |
|
…… |
||||
|
25 |
12 |
C004 |
1002 |
-8820 |
|
26 |
12 |
C004 |
1006 |
8820 |
|
27 |
13 |
C004 |
1002 |
-10080 |
|
28 |
13 |
C004 |
1006 |
10080 |
這時我們再運行一下建立的綜合報表：
表36 合同明細
|
產品編號 |
產品名稱 |
規格型號 |
單位 |
數量 |
|
CP001 |
變壓器 |
KM9824 |
個 |
1000 |
|
CP002 |
電感 |
ML7823 |
個 |
2000 |
表37 採購情況
|
生產廠名稱 |
產品編號 |
產品名稱 |
規格型號 |
單位 |
數量 |
|
電子廠2 |
CP001 |
變壓器 |
KM9824 |
個 |
200 |
|
電子廠2 |
CP002 |
電感 |
ML7823 |
個 |
2000 |
|
電子廠1 |
CP001 |
變壓器 |
KM9824 |
個 |
800 |
表38 產品庫存
|
產品編號 |
產品名稱 |
規格型號 |
單位 |
數量 |
|
CP001 |
變壓器 |
KM9824 |
個 |
310 |
|
CP002 |
電感 |
ML7823 |
個 |
800 |
表39 應付款
|
生產廠名稱 |
採購單號 |
應付款 |
|
電子廠1 |
CG001867 |
6755.4 |
|
電子廠2 |
CG001868 |
15352 |
表40 應收款
|
客戶名稱 |
發貨單號 |
應收款 |
|
客戶 |
CK003 |
18900 |
數據的變化完全符合邏輯。
3.2.5 付款
做一筆付款操作，爲“電子廠2”付款。
單據內容：
表41“付款”模擬數據內容
|
||||||
|
付款金額 |
||||||
|
12000 |
三個表添加數據：
表42 在index表中添加的數據
|
WID |
WorkId |
HTId |
KHName |
CPId |
CPName |
Size |
Unit |
CPPrice |
CGHTId |
GYSName |
CGPrice |
CKNo |
CWNo |
|
|
…… |
||||||||||||||
|
14 |
W005 |
|
|
|
|
|
|
|
|
電子廠2 |
|
|
CK006 |
|
表43 在mon表中添加的數據
|
No |
MonIndex |
MonId |
MonSubId |
MonValue |
|
…… |
||||
|
29 |
14 |
C005 |
1005 |
-12000 |
|
30 |
14 |
C005 |
1007 |
12000 |
Mat表沒有添加數據。
3.2.6 收款
單據內容：
表44“收款”模擬數據內容
|
||||||
|
收款金額 |
||||||
|
18000 |
三個表添加數據：
表45 在index表中添加的數據
|
WID |
WorkId |
HTId |
KHName |
CPId |
CPName |
Size |
Unit |
CPPrice |
CGHTId |
GYSName |
CGPrice |
CKNo |
CWNo |
|
|
…… |
||||||||||||||
|
15 |
W006 |
HT0183 |
客戶 |
|
|
|
|
|
|
|
|
CK003 |
CK007 |
|
表46 在mon表中添加的數據
|
No |
MonIndex |
MonId |
MonSubId |
MonValue |
|
…… |
||||
|
31 |
15 |
C006 |
1006 |
-18000 |
|
32 |
15 |
C006 |
1008 |
18000 |
Mat表沒有數據添加。
這時我們再運行一下建立的綜合報表：
表47 合同明細
|
產品編號 |
產品名稱 |
規格型號 |
單位 |
數量 |
|
CP001 |
變壓器 |
KM9824 |
個 |
1000 |
|
CP002 |
電感 |
ML7823 |
個 |
2000 |
表48 採購情況
|
生產廠名稱 |
產品編號 |
產品名稱 |
規格型號 |
單位 |
數量 |
|
電子廠2 |
CP001 |
變壓器 |
KM9824 |
個 |
200 |
|
電子廠2 |
CP002 |
電感 |
ML7823 |
個 |
2000 |
|
電子廠1 |
CP001 |
變壓器 |
KM9824 |
個 |
800 |
表49 產品庫存
|
產品編號 |
產品名稱 |
規格型號 |
單位 |
數量 |
|
CP001 |
變壓器 |
KM9824 |
個 |
310 |
|
CP002 |
電感 |
ML7823 |
個 |
800 |
表50 應付款
|
生產廠名稱 |
採購單號 |
應付款 |
|
電子廠1 |
CG001867 |
6755.4 |
|
電子廠2 |
CG001868 |
3352 |
表51 應收款
|
客戶名稱 |
發貨單號 |
應收款 |
|
客戶 |
CK003 |
900 |
結果和我們預期的一樣。
由此可見，如果用常規數據庫結構進行設計恐怕三個表很難完成，採用新的算法，可以增加更多的業務操作內容，還是使用這三個表，並且調整修改非常簡單，對已有的內容影響也不大。
3.2.7 在已有的基礎上添加新功能和調整邏輯
上面的例子只是一個簡單的應用，管理還比較粗放，只是記個賬而已，如果對企業管理要求提高，要求整個系統以“合同”爲中心開展各項工作，考覈最終合同執行完成後實際的利潤情況，並增加一項工作“其他費用錄入”，把在合同執行過程中的運費、輔料費等都計入成本，我們對已有的結構做如下調整。
對邏輯設計表進行修改：
圖8 邏輯設計表調整
在邏輯設計添加一項新工作“W007-費用錄入”，在“財務”科目裏添加兩項“1009-成本預算”、“1010-成本”，在“付款”和“費用錄入”兩項工作時，發生成本，也就是說對某個合同產生實際付款和費用的時候產生成本，統計1010科目即可查看實際成本發生情況。
對“關鍵數據”表做如下修改：
圖9 關鍵字段表調整
也添加了“費用錄入”工作，關鍵數據增加一個“費用名稱”，注意：對於“付款”增加了對“合同號”數據的繼承，也就是說，原來在付款的時候不會考慮“合同號”，只針對供應商就行，總計欠多少，付多少，現在付款要不僅要針對供應商，還有具體到哪個合同，區分款項是給哪個合同付的，這樣才能記錄合同的成本。
以上是理清思路和邏輯規劃的工作，實際上對於“三個表”的改變僅需要在index表中加個字段Cost（費用名稱）即可。
表52 index表添加字段後結構
|
字段 |
類型 |
作用 |
|
WID |
int |
索引號 |
|
workId |
String |
*工作編號 |
|
HTId |
String |
*合同號 |
|
KHName |
String |
客戶名稱 |
|
CPId |
String |
產品編號 |
|
CPName |
String |
產品名稱 |
|
Size |
String |
規格型號 |
|
Unit |
String |
產品單位 |
|
CPPrice |
Float |
產品單價 |
|
GYSName |
String |
供應商名稱 |
|
CGPrice |
Float |
採購單價 |
|
CKNo |
String |
倉庫單據號 |
|
CWNo |
String |
財務單據號 |
|
Cost |
String |
費用名稱 |
這樣在實際運行中，比如原來付款在mon表中記錄的數據將有如下變化：
|
表53 在mon表中原來的數據
|
表54 在mon表中變化後的數據
|
||||||||||||||||||||||||||||||||||||||||||||||||||
操作“費用錄入”和上面道理一樣不做贅述。這樣處理數據，當合同執行結束，各項款項都處理了，按“合同號”統計1010科目的數據即可得到整個合同的成本了。增加一個工作簡單吧！
分析：在邏輯設計中，添加“成本”時，爲了能找到可以“抵扣”的對象，同時加了個“成本預算”科目，如果系統功能要求已經達到了，那麼這個科目就沒有統計意義了，但是，再深入考慮一下，在最初“合同簽訂”的時候，和客戶談判確定產品的價格的時候是不是會考慮“根據經驗在國內採購這些產品大概價格是說多少？加上合理的利潤，確定報價”？對邏輯設計做如下修改：
圖10 邏輯設計調整
添加個“虛”的“總成本”作爲抵扣
在“合同簽訂”的工作操作時，輸入如下數據：
表55 “合同簽訂”修改後模擬數據
|
產品編號 |
產品名稱 |
規格型號 |
單位 |
單價 |
數量 |
金額 |
預算單價 |
預算金額 |
|
CP001 |
變壓器 |
KM9824 |
個 |
12.6 |
1000 |
12600 |
8.6 |
8600 |
|
CP002 |
電感 |
ML7823 |
個 |
8.4 |
2000 |
16800 |
6.85 |
13700 |
把“預算金額”加入到“成本預算1009”中，這樣將來合同執行結束後，根據“合同號”統計成本預算，通過合計的正負可知實際經營的結果和預想的差異，如果爲正，則說明實際執行的情況比預算好，多賺錢了，如果爲負，則說明實際執行情況超出預算了。這樣在管理上如果業務和採購是兩個部門，相應的考覈標準也就出來了。並且這樣的改動調整對企業業務沒有什麼影響。
這樣看來，這種算法是不是非常符合企業管理的自然思維，很多管理功能和管理想法很輕鬆的就實現了，並且邏輯關係嚴密、清晰。的
4 創新算法的意義
企業信息化的應用歷史從DOS時代的dBase，到Windows時代的FoxPro、MRP、ERP等等一路走來，都是沿着數據記錄、邏輯處理這個路子不斷羅列、擴展而來，新的算法完全顛覆目前所有管理軟件的模式，把管理邏輯作爲思維的核心，大大簡化了數據結構，處理企業管理的數據更加“簡單、清晰、合理”，系統設計的思維方式也和管理契合，以此理論爲基礎設計開發的管理軟件將更加適合企業應用，很容易二次開發和修改調整。在設計和應用中不僅可以完成企業已有的實際管理工作，還可以很自然地發現管理邏輯中的漏洞和問題，在應用過程中調動管理者的聰明才智，激發靈感，反過來推動企業管理的完善和提高，這纔是管理軟件的目標和真正意義所在。
5 應用實踐
我們根據上述的算法原理，開發了“脈達M3”軟件系統，其核心數據架構依照上面介紹的原理，只不過進一步完善輔助的各項配置數據和功能，並形成配置工具，可以方便地配置出“二元”分析所得到的結果。