ERP 各模块究竟如何集成

“集成”一词背后其实是三种不同的东西

几乎每一份 ERP 宣传册都会用到“集成”一词。其背后至少有三种安排，而到了月末出问题时，它们的表现截然不同。第一种是文件或定时批量传输：一个系统导出，另一个系统导入，通常在夜间进行。第二种是 API 或中间件同步，两个独立的数据库通过交换消息保持同步。第三种是真正的数据共享：各模块根本不是独立的系统，而是同一组数据表、同一个总账和同一套主记录的不同视图。

这几种方式没有哪一种是普遍正确的。批量传输成本低、易于理解，任何一方宕机都不受影响，因为文件会一直等待。但它按设计就总是滞后的，而且一次失败的任务可能在有人质疑报表之前都不被察觉。API 同步能提供近乎实时的效果，并让您保留那些有充分理由保留的系统，但您从此就拥有了一个分布式系统：重试、顺序、部分失败，以及两份可能相互矛盾的“事实”。数据共享消除了两个数据库相互偏离这一类问题，因为只有一个数据库；但这意味着各模块必须统一使用一套科目表、一种物料定义和同一发布节奏，这是一种约束，而非免费的好处。

实际要问的不是哪一种最好，而是每一条数据流值得采用哪一种。银行对账单在夜间传输没有问题；为实时 POS 提供支撑的库存水平在夜间传输则不行。Skyline Nexus 自身的模块处于第三种层次：会计、POS 与库存、CRM、维护、人力资源、车队和资产写入同一个总账和同一套主数据，并在客户已有值得保留的系统时，通过 API 与外部系统集成。

偏差始于主数据

集成失败通常被归咎于接口，但最初的裂缝一般是某条主记录以略有不同的内容存在了两份。一旦两个系统各自保存自己的客户清单，几周之内清单就会出现分歧，而下游的每一个数字都会继承这一分歧。

• 客户：在销售、开票、收款和信用控制中使用同一身份，否则应收账款账龄将与销售报表对不上。
• 供应商：在采购、应付和付款之间共享，包括银行账户信息——一旦重复，便会成为欺诈目标。
• 物料：一个编码、一个计量单位、一种成本核算方法。两套物料主数据意味着两种存货估值。
• 科目表：只有一套结构。如果某个模块保留自己的科目清单再映射到您的科目表，映射本身就成了又一件需要维护、也容易出错的事。
• 税码：对税率、处理方式和生效日期只有一个定义，交易和纳税申报共同使用。
• 分支机构与地点：必须共享，因为库存和会计都按它划分维度。
• 员工：一条记录同时支撑薪资、考勤、维护工单和车辆分配。
• 资产：一份台账同时支撑折旧、维护历史和处置。

明细分类账与统驭账户

总账保存汇总余额，明细则保存在明细分类账中，每本明细分类账都对应总账中的一个统驭账户（控制账户）。应收账款按每张客户发票和每笔收款逐行记录，合计等于应收账款统驭账户。应付账款对供应商账单采用同样方式。存货变动过账到存货统驭账户，商品出库时确认销售成本。薪资过账应发工资、雇主缴费、扣款和应付净额。固定资产针对资产原值和累计折旧过账新增、折旧和处置。POS 过账销售额、已收税款、各类支付方式，并在采用永续盘存制时过账每笔销售的成本。

让这一切值得信赖的规则很简单：明细分类账必须始终与其统驭账户核对一致，精确到最小货币单位。如果应收账款账龄表显示一个数字，而应收账款统驭账户显示另一个数字，那么其中必有一个是错的，不经调查就无法知道是哪一个。这就是为什么通常禁止直接向统驭账户录入手工分录。向应收账款录入一笔手工分录，会产生一笔没有任何客户欠付的余额，而且它不会出现在您寄出的任何对账单上。

对账应当是一份可以随时运行的报表，而不是某人维护的电子表格。当各模块共享同一个总账时，对账几乎是同义反复；当它们不共享时，这就是您能够自动化的最重要的一项检查。

过账规则与审计轨迹

每一行总账记录都应能追溯到原始单据：发票号、收货单、薪资批次、折旧计划表、POS 交易。如果某一行没有来源，说明有人绕过了流程。单据标识应随总账行一起流转，而不是存放在单独的映射表中。

已过账的分录不应被悄无声息地修改。更正应通过冲销分录或贷项通知单进行，这样原始记录和更正记录都保持可见，并各自带有日期和操作用户。期末结账应锁定期间，而不是依赖人们记得不要倒填日期。检验标准是：您能否选取任何一个余额，打开它，一路追溯到产生它的单据，而无需离开系统。

集成究竟在哪里出问题

故障模式众所周知，而且几乎总是那几种。

• 时点与截止：在期间最后一天午夜前过账的销售，在截止之后才到达另一个系统，于是两边的期间永远对不上。
• 无人监控的失败任务：定时传输停止运行，而数据缺失看起来像是清淡的一周。
• 部分写入：发票表头已创建，明细行却失败了，一方持有另一方无法识别的单据。
• 重复键：一条重试的消息生成了同一张发票的第二份副本，或者编号规则在不同分支机构之间发生冲突。
• 币种与舍入偏差：两个系统在不同环节进行舍入，或对同一天使用不同汇率，产生的小额差异不断累积。
• 重复计税：交易系统和会计系统各自计算税额，在折扣、含税定价或按行与按单据舍入方面采用略有不同的规则。于是交给客户的发票与申报表中的数字不一致。

幂等性，以及证明两边一致

凡是可以重试的操作，终究都会被重试，因此每一次过账操作都需要一个源自原始单据的稳定键。同一张发票发送两次，结果必须是一次过账，而不是两次。接收方应记录已处理过的键，并返回先前的结果，而不是新建一条记录。否则，普通的网络行为就会变成重复收入。

与此同时，您需要把对账作为一项一等功能：按期间、按单据类型统计数量和合计数，在两边进行比较，并逐条列出差异，而不是只给出汇总。一个只表明上次任务成功的绿色对勾，并不能证明两边一致。有用的报表，是能点名指出那七张只存在于一方、不存在于另一方的单据的报表。

分支机构与币种

多分支机构运营意味着每笔交易从创建之时起就带有地点维度，而不是之后由报表逻辑分配。库存、收入、成本和人员都归属于某个分支机构，分支机构之间的调拨需要双方都过账，否则两家分支机构的库存数字加起来将不等于公司数字。单据编号必须在各分支机构之间唯一，同时在单个分支机构内保持意义。

多币种要求在行项目上同时保存交易币种、所用汇率和本位币金额。只保存折算后的数字，就等于丢弃了证据。这样一来，未结余额的重估和结算时的已实现汇兑损益就有了过账之处，汇兑差额也不再是一个说不清的舍入谜团。

地区说明：清关模式改变了时点

在实行电子发票制度的地方，集成的时点不再是设计偏好问题。一些税务机关现已要求发票在送达买方之前或同时，向税务机关完成清关或报告。沙特阿拉伯的 ZATCA 制度就是一个现行实例：发票按规定的结构、加密要素和标识符生成，税务机关参与单据的整个生命周期，而不是事后接收一份汇总。这使发票的开具成为一个实时集成问题。夜间批处理无法生成客户正在柜台前等待的单据。

其他地方的情况各不相同，值得准确描述。美国没有联邦层面的电子发票强制要求，销售税由州一级管理，规则和税率因州而异，往往还因地方辖区而异。加拿大在联邦层面实行 GST 和 HST，各省有所差异，部分省份还征收省销售税。更广泛的中东和北非市场处于不同阶段。设计上的启示是：把税额确定和单据开具放在同一处，这样当某个市场从报告模式转向清关模式时，改变的是配置，而不是架构。Skyline Nexus 在写入总账分录的同一笔交易中处理 ZATCA 清关，因此客户收到的发票与申报表中的数字来自同一次计算。