10年老陈醋
-------------------------------------------------
一、定义
交易数据又称为静态数据，是和易变的主数据相对而言的，这类数据一旦创建生效，一般不会发生变化。交易数据是指反映企业日常经营活动中实际业务的数据。具体讲，一笔订单、一笔采购入库，一笔销售记录，都是交易数据。交易数据反映企业内部，在某个时刻，某个组织，与外部组织或内部组织发生的一个活动，而这个活动是本部企业经营活动的具体反映。
与主数据一样，不同的企业，不同的业务系统，都有不同的交易。业务系统就是讲企业的日常手工化的交易数据电子化，也叫信息化，这个过程就是企业经营的信息化。还是一样，我们试图罗列一些具体的交易类型。
二、常见的交易数据
企业要正常运营，经营活动分类两类：一类是内部管理活动，一类是与外部的交易活动，没有一个企业不存在对外部的交易活动。封闭的企业是不存在的，否则怎么创造价值。
（一）内部管理类
1，入职过程、转正过程（人力资源类）
2，请销假，用车申请
3，工资调整申请
4，出差报销
（二）交易活动
1，主数据创建申请（主数据管理类）
2，采购过程
3，付款过程
4，出入库过程
5，资产报废申请
6，调拨申请
三、交易的结构
从软件开发的角度，讨论下交易的内容的结构。
（一）体现为单证类的交易
一般交易记录模型分两部分。一是交易头，一是交易明细。
1. 交易头
交易头上有交易号（一般称为单据号），交易时间，交易主体（谁参与的，那个部门，哪个公司），交易状态，交易修改信息（创建人，创建时间，修改人，修改时间）。
2. 交易内容
交易对象（比如物资编号，科目编号），交易量（数量，金额，单价），交易辅助信息。
以一个订单为例。订单头存放订单号吗，供应商，订单日期等等交易全局信息，订单明细存放订单的订购内容，一个订单可能订购多件商品，每个明细行记录一条订购商品。订单头和订单明细通过订单编号关联。
也有的交易比较简单，只要一个表就可以了，比如请假申请单，只要包括请假人，请假开始时间和结束时间久可以了，没有请假明细。
也有很复杂的交易，有三层结构。比如公司的fmis的凭证，凭证头->分录->辅助分录。一个凭证头对多条分录，一条分录对多条辅助分录。
（二）其他交易
比如中间交易数据。这些交易数据可能由单证类交易数据生成，比如我们做的一卡通收费系统的每月的费用数据也可以认为是一种交易数据。
（三）交易的业务环境数据
交易数据中除了记录衡量交易规模和属性的即时数据外（比如采购物品的规格，数量和金额），还要记录当时的一些业务环境数据，又称为业务上下文。所谓业务环境是指与本次交易相关的依赖数据，而这些依赖数据可能在一个记账期间内保持稳定的，但是超出后就可能发生变化的数据，比如一个住户的补贴情况，资产所属的成本中心。记录这些数据的原因是，这些数据有可能在以后的交易期间内发生变化，而发生交易时的这些数据的值对本笔交易来讲有是比较重要的，无论是处于查询还是账务核算。因此这些数据要记录在交易中。
到底哪些业务环境数据需要写入到交易数据中，这个要根据具体的系统具体分析。一般来讲，如果i个数据在将来可能发生变化，并且这个数据也是核算或者数据查询比较重要的一个数据，而且和本笔交易有很大的关联性，在设计数据结构和具体代码时，就需要将其放倒交易数据中。比如我们做的一个系统：一卡通缴费系统，住户有个属性：价格类型，这个属性表示了住户执行价格，比如工业用水，商用，民用等，民用还有很多中价格。这个价格类型，根据政策的调整，可能会发生变化，而财务上每个月又需要按照价格类型进行统计报表，在核算上也有所不同（核算上这个原因没有具体落实），因此，价格类型这个业务环境数据，就必须写入到交易数据--每个月份每个住户的费用记录，中。区分哪些数据放到交易中，需要丰富的业务经验，并且有时候仁者见仁。但是上面提到的原则要遵循。
还有一仲环境数据与当前交易相关性较强的数据，比如在审请借款吋显示当前的借欯余额，这类数据有更强的易变性，而且也不会做为将来的查询，但是如果该数据对当时的交易很重要，比如可以作为审计数据的一部分，为了"还原"交易现场，也可以保有在交易中。
四、交易数据的变更
任何事情都有可能出错，并且出了错要提供改正的机会和手段。做系统也是。做系统前，要评估那些数据可能发生变更，那些数据能变更，变更对其他数据的影响（尤其是状态数据），如果变更，能否保证变更后的数据与被其影响的数据保持一致（比如凭证和账本的关系，要保持一致）。
交易数据的变更有三种做法：
（一）直接修改。这种一般适合于没有批准，审核流程的交易，并且还没有最后确认这笔交易。批准和审核是一种通常的做法，很多企业内控都规定了交易的处理流程，必须有1或多个岗位对交易的准确性、合法性就行监控。一般批准了的交易时不允许修改的。即便没有复杂的流程，也有一个确认的过程。
修改后，要对被其影响的数据进行修改，以保证系统内部数据之间的一致性。
（二）取消交易，重新输入。
将错误的交易标为无效，重新录入正确的交易数据。取消的含义类似于数据库的回滚rollback操作。一般在交易表上有一列，标志该交易的有效性。默认是有效的。
这种做法的前提是，该笔交易没有产生或者导致其他难易变更的状态。比如导致其他系统的数据变更。常见的是业务系统的交易会产生财务系统的财务凭证，如果凭证已经产生，作废该交易的话，需要同步作废财务系统的对应凭证。这种情况下就不适合用取消交易来做。还有我们做的项目，一卡通缴费，如果发现今天的某笔交易时错误的，就可以取消掉，重新录入正确的交易，但是一旦日结后，就不可以取消了。日结的处理内容，包括：收银员将收到的款项存到银行，并且提交存款记录，财务根据该存款记录做银行存款收入凭证。
（三）冲红交易，重新做一笔正常的交易
这种方式与前两种方式，在企业的整个经营周期内，效果是一样的，但是放到某个核算期间（日，或者月）可能会有不同。
做一笔反向reverse交易（把原先的错误的交易抵消掉），然后做一笔正确的正常的交易。不适合第二种方式的情形下，可以采用这种方式。并且，在任何情况下，都可以采用这种方式。这种方式尤其适合那种“历史”的交易已经“冻结“，不能再被修改（比如财务上的月结后）。
前两种方式都是对原交易的直接修改，这种是间接修改。一般做了阶段性总结（月结）后，历史的数据就冻结了，不允许修改了。
五，交易数据与其他对象的关系
如果把主数据，交易数据 和 状态数据 放在一起的话，交易数据处于中间位置，向下引用主数据（订单引用供应商），向上形成状态数据（订单确定后形成计划到货数，账本）。
主数据 <-- 交易数据 --> 状态数据。
