1、供应链模块转换

a.采购订单 → 进货单 → 采购入库单

场景：供应商确认采购订单后，系统自动生成进货单作为收货依据。

b.报价单 → 销售订单 → 发货通知单→ 运输单 → 销售出库单

场景：客户确认订单后，系统生成发货通知单，并生成运输单通知安排物流车辆，分批发货或直接生成出库单，触发库存扣减。

c.销售订单 → 采购单

场景：商贸企业在预销（以销定产或采）场景下，当库存不足时，立马下采购订单，通过单据转换实现信息流转。

2、财务模块，包括其他模块往财务模块流转，比如：

a.材料出库单 → 生产成本凭证

场景：生产领料时，系统自动将材料出库单数据转换为生产成本分录（借：生产成本/原材料，贷：原材料）。

b.采购入库单 → 应付暂估

场景：物料到货后生成入库单，系统暂估应付账款（借：原材料，贷：应付暂估）。

c.销售发票 → 应收账款与成本结转

场景：开票时生成应收账款凭证（借：应收账款，贷：主营业务收入），同时结转销售成本（借：主营业务成本，贷：发出商品）。

要注意的是，有些企业是根据销售出库单→应收单，因为销售发票会定期、汇总开具，而不像销售出库单必须确认收当月或合并、或一对一流转至应收单。

核心能力：支持单据的组合（Join）、合并（Merge）、拆分（Split）、分组（Group）等操作，适应复杂业务场景。

技术本质：基于主从结构（单头+明细）的数据处理系统，通过规则引擎驱动自动化流程，实现业务单据与业务单据的映射与转换（单据与凭证的转换见拆解会计引擎（核心部分），不属单据引擎范围）。

单据引擎通常采用分层架构，分为输入层、规则引擎层、执行层、输出层：

1.输入层：输入层包括数据源配置、元数据管理、解析规则等，通过对接业务系统的原始单据（如采购订单、销售出库单等），通过元数据解析获取单据字段、类型及关联关系。

比如：费控系统的《费用报销单》（广告费用），对接到ERP的《应付单》，再生成《付款凭证》；同时采购平台的《采购入库单》，也对接ERP的《应付单》，则是生成《暂估应付凭证》；

这一层里，元数据是关键点，因为业务永远是动态变化的，为适应这种动态变化，低成本、动态可配、低代码的元数据才是解决问题的方向。比如下面这种元数据管理：

2.规则引擎层：核心模块，包括转换规则、校验规则、计算规则的配置。例如：

金蝶BOTP通过KScript脚本定义字段映射、分组策略、选单策略等；

a.源单据与目标单据映射，如源单据《采购订单》，目标单可勾选《应付单》、《付款申请单》、《采购退料单》、《收料通知单》甚至《销售订单》等等；

b.字段映射策略，即源单的A字段，映射到目标单据的B字段；

c.分组策略，配置源单批量下推生成目标单时采用的单据分组依据、分录合并依据，比如将多个《采购申请单》按同一“组织、供应商”分组（合并）生成一个目标《采购订单》 ；

d.选单策略，也叫漏斗策略，将源单符合某些条件的筛选出来，生成目标单；

字段映射示例：

中兴新云FOL通过可视化界面配置字段类型、校验条件（如敏感词检测、金额合规性）及计算逻辑（如差旅补贴自动计算）。

架构流程（概）图：

其中：

• 源单据：即元数据，是上游系统传来后对应（单据引擎）本系统的表及字段，与上游数据结构一模一样，比如上游费控系统的《费用报销单》有哪些字段，对到单据引擎也会有一个一模一样的《费用报销单》，就是通过元数据配置，起着承接与记录的作用。

• 单据规则：设置单据生成的具体规则，比如单据每一个字段是怎么来的，是从源单据的某个字段还是有特定规则；以及是否要冲销，冲销的规则又是什么？是按单号冲销一对一冲销还是按供应商&单据类型整冲整提？示例：

如【单据编码】的规则：“关键字（'FYBX'）+年月+流水号（跨月重置）”；

如【汇率】：根据源表中【日期】&【币别】查《汇率表》中对应区间、同币别的汇率；

【费用类型】：根据源表《费用报销单》中【报销项目】查《费用类型mapping》表对应【费用类型编码】

• 拆分合并：源单据与目标单据的生成规则，是1:1还是多个合并生成一个，或一个拆分成多个，但禁止多对多！如果是合并生成，合并规则又是什么？以金蝶示例：

比如多个《费用报销单》，按同一【收款人 or 供应商】、【组织】合并生成1个《应付单》单据头，再用【报销项目（即转换后的费用类型】、【费用承担部门】、【币别】作汇总，汇总求和字段为【报销金额（价税合计）】；

• 输出策略，即目标单据是哪个，以及生成目标单据后是直接保存到数据库，还是要调用接口往下游推送？

• 模型构建：将上述规则组装成一个协议或集合，即给一组规则保存一个特定标识或名称，同样条件的规则在同一时间只有只有一个生效，比如前面提到的，《费用报销单》与《采购入库单》都是生成《应付单》，但二者的后续处理规则是不一样的，《费用报销单》生成《应付单》的单据类型是“费用单”，下一步是生成《付款单》；而《采购入库单》生成《应付单》的单据类型是“暂估单”，是没有下一步策略的；对比如下：
  

《采购入库单》→ 《应付单》；

《费用报销单》→ 《应付单》→ 《付款单》

另外，如果想做得更完美的同学，可把单据关系设计成可拖拽式的画布，可以一图将单据整个链条设计概全，一目了然，清晰全面，比如下面这种：

3.执行层：调用脚本解析引擎或规则引擎执行转换/校验操作，例如金蝶BOTP通过KScript引擎解析脚本并生成目标单据。包括：

• 预处理：预处理有可能在接收源单调用，也可能是在生成目标单据时调用，目的是将单据转换生成所需信息补充完整，确保后续的单据转换步骤能顺利执行。包括数据清洗与标准化（比如前述中定义“【费用类型】”规则）、规则预校验（比如字段非空性验证、数据类型匹配（如金额是否为数值型））、上下文环境加载等。

• 单据生成：根据定义的单据规则生成目标单据，包括模板动态填充、自动化赋值逻辑、分组等。有些场景目标单据不止1个，可能会有多个；比如《物流费用计提单》，从BMS（仓储物流费用平台）传来后，单据引擎根据规则，不仅要生成《计提应付单》，还要生成《暂估（冲销）应付单》。

• 校验：包括系统自动化校验和人工复核与修正；

• 自动化校验有完整性校验（如检查必填字段）、逻辑一致性校验（验证业务规则，比如单据总金额=sum（每行【价税全额）之和）、合规性检验（ 匹配税务法规（如发票税率合规）及企业内控标准）；

• 人工复核，提供可视化界面标注异常项（如红色高亮字段），支持审核人添加批注；支持“驳回-修正”流程：若检测到单价与合同不一致，可退回至预处理阶段重新匹配数据。

​

4.输出层，功能模块如下：

• 单据保存：输出层专注生成并保存目标单据（如应付单、出库单、审批单）记录转换前后的单据关联关系，支持追溯。

• 单据流转：有些场景还会根据规则触发下推动作，将生成好的单据通过调用接口或RabbitMQ/Kafka实现任务分发，推送给下游消费方。

• 操作审计（日志）：记录单据接收、转换、生成、下推过程的操作时间、操作用户、数据版本等相关信息，异常信息实时预警。记录单据转换过程中的上下游关系图谱，便于后期追溯排查。

阅读原文：原文链接