2017/2/14
一、定義
交易數據有稱為靜態數據，是和易變的主數據相對而言的。目前沒有標准的命名。交易數據是指反映企業日常經營活動中實際業務的發生的數據。這樣將可能比較抽象，具體講，一筆訂單、一筆采購入庫，一筆銷售記錄，都是交易數據。交易數據反映企業內部，在某個時刻，某個組織，與外部組織或內部組織發生的一個活動，而這個活動是本部企業經營活動的具體反映。
與主數據一樣，不同的企業，不同的業務系統，都有不同的交易。業務系統就是講企業的日常手工化的交易數據電子化，也叫信息化，這個過程就是企業經營的信息化。還是一樣，我們試圖羅列一些具體的交易類型。
二、常見的交易類型
企業要正常運營，經營活動分類兩類：一類是內部管理活動，一類是與外部的交易活動，沒有一個企業不存在對外部的交易活動。封閉的企業是不存在的，否則怎么創造價值。先說內部管理類的。
（一）內部管理類
1，入職過程、轉正過程（人力資源類）
2，請銷假，用車申請
3，工資調整申請
4，出差報銷
（二）交易活動
1，主數據創建申請（主數據管理類）
2，采購過程
3，付款過程
4，出入庫過程
5，資產報廢申請
6，調撥申請
三、交易的結構
（一）體現為單證類的交易
一般交易記錄模型分兩部分。一是交易頭，一是交易明細。
1. 交易頭
交易頭上有交易號（一般稱為單據號），交易時間，交易主體（誰參與的，那個部門，哪個公司），交易狀態，交易修改信息（創建人，創建時間，修改人，修改時間）。
2. 交易內容
交易對象（比如物資編號，科目編號），交易量（數量，金額，單價），交易輔助信息。
以一個訂單為例。訂單頭存放訂單號嗎，供應商，訂單日期等等交易全局信息，訂單明細存放訂單的訂購內容，一個訂單可能訂購多件商品，每個明細行記錄一條訂購商品。訂單頭和訂單明細通過訂單編號關聯。
也有的交易比較簡單，只要一個表就可以了，比如請假申請單，只要包括請假人，請假開始時間和結束時間久可以了，沒有請假明細。
也有很復雜的交易，有三層結構。比如公司的fmis的憑證，憑證頭->分錄->輔助分錄。一個憑證頭對多條分錄，一條分錄對多條輔助分錄。
（二）其他交易
比如中間交易數據。這些交易數據可能由單證類交易數據生成，比如我們做的一卡通收費系統的每月的費用數據也可以認為是一種交易數據。
（三）交易的業務環境數據
交易數據中除了記錄衡量交易規模和屬性的即時數據外（比如采購物品的規格，數量和金額），還要記錄當時的一些業務環境數據。所謂業務環境是指與本次交易相關的依賴數據，而這些依賴數據可能在一個記賬期間內保持穩定的，但是超出后就可能發生變化的數據，比如一個住戶的補貼情況，資產所屬的成本中心。記錄這些數據的原因是，這些數據有可能在以后的交易期間內發生變化，而發生交易時的這些數據的值對本筆交易來講有是比較重要的，無論是處於查詢還是賬務核算。因此這些數據要記錄在交易中。
到底哪些業務環境數據需要寫入到交易數據中，這個要根據具體的系統具體分析。一般來講，如果i個數據在將來可能發生變化，並且這個數據也是核算或者數據查詢比較重要的一個數據，而且和本筆交易有很大的關聯性，在設計數據結構和具體代碼時，就需要將其放倒交易數據中。比如我們做的一個系統：一卡通繳費系統，住戶有個屬性：價格類型，這個屬性表示了住戶執行價格，比如工業用水，商用，民用等，民用還有很多中價格。這個價格類型，根據政策的調整，可能會發生變化，而財務上每個月又需要按照價格類型進行統計報表，在核算上也有所不同（核算上這個原因沒有具體落實），因此，價格類型這個業務環境數據，就必須寫入到交易數據--每個月份每個住戶的費用記錄，中。區分哪些數據放到交易中，需要豐富的業務經驗，並且有時候仁者見仁。但是上面提到的原則要遵循。
還有一仲環境數據與當前交易相關性較強的數據，比如在審請借款吋顯示當前的借欯余額，這類數據有更強的易變性，而且也不會做為將來的查詢，但是如果該數據對當時的交易很重要，比如可以作為審計數據的一部分，為了"還原"交易現場，也可以保有在交易中。
四、交易數據的變更
任何事情都有可能出錯，並且出了錯要提供改正的機會和手段。做系統也是。做系統前，要評估那些數據可能發生變更，那些數據能變更，變更對其他數據的影響（尤其是狀態數據），如果變更，能否保證變更后的數據與被其影響的數據保持一致（比如憑證和賬本的關系，要保持一致）。
交易數據的變更有三種做法：
（一）直接修改。這種一般適合於沒有批准，審核流程的交易，並且還沒有最后確認這筆交易。批准和審核是一種通常的做法，很多企業內控都規定了交易的處理流程，必須有1或多個崗位對交易的准確性、合法性就行監控。一般批准了的交易時不允許修改的。即便沒有復雜的流程，也有一個確認的過程。
修改后，要對被其影響的數據進行修改，以保證系統內部數據之間的一致性。
（二）取消交易，重新輸入。
將錯誤的交易標為無效，重新錄入正確的交易數據。取消的含義類似於數據庫的回滾rollback操作。一般在交易表上有一列，標志該交易的有效性。默認是有效的。
這種做法的前提是，該筆交易沒有產生或者導致其他難易變更的狀態。比如導致其他系統的數據變更。常見的是業務系統的交易會產生財務系統的財務憑證，如果憑證已經產生，作廢該交易的話，需要同步作廢財務系統的對應憑證。這種情況下就不適合用取消交易來做。還有我們做的項目，一卡通繳費，如果發現今天的某筆交易時錯誤的，就可以取消掉，重新錄入正確的交易，但是一旦日結后，就不可以取消了。日結的處理內容，包括：收銀員將收到的款項存到銀行，並且提交存款記錄，財務根據該存款記錄做銀行存款收入憑證。
（三）沖紅交易，重新做一筆正常的交易
這種方式與前兩種方式，在企業的整個經營周期內，效果是一樣的，但是放到某個核算期間（日，或者月）可能會有不同。
做一筆反向reverse交易（把原先的錯誤的交易抵消掉），然后做一筆正確的正常的交易。不適合第二種方式的情形下，可以采用這種方式。並且，在任何情況下，都可以采用這種方式。這種方式尤其適合那種“歷史”的交易已經“凍結“，不能再被修改（比如財務上的月結后）。
前兩種方式都是對原交易的直接修改，這種是間接修改。一般做了階段性總結（月結）后，歷史的數據就凍結了，不允許修改了。
五，交易對象與其他對象的關系
如果把主數據，交易對象 和 狀態數據 放在一起的話，交易數據處於中間位置，向下引用主數據（訂單引用供應商），向上形成狀態數據（訂單確定后形成計划到貨數，賬本）。
主數據 --> 交易數據 --> 狀態數據。