金税合并的具体算法如下：首先检索操作员提交的这组记录里面有没有红票发票类型，若有进入红票发票类型金税合并算法，若不是红票类型，进入普通发票类型金税合并算法。
1、红票发票类型算法：在确认收票方一致，税码相同的情况下，分两种情况：（1）、红票和标准发票的合并：直接合并，然后删除合并前的红票和标准发票的信息记录，之后再存储新生成的金税合并发票记录到数据库中，并给该新发票随机生成一个税号。
（2）、红票和红票的合并：直接合并，保留之前合并的所有红票的信息记录，之后再存储新生成的红票记录到数据库中，并给该新发票随机生成一个税号。
2、标准发票类型算法：确认收票方一致，税码相同。其中，合并后总金额超过预设置总金额上限值（本文初始值设置为10万，首先单张发票不可以超过10万元，其次是在合并的过程中，所有合并发票的金额上限也不可以超过10万元），且税差额大于0.06的不可开票（税额= 金额*税率，税额差算法见表1）。

表3.1 税额差算法      62.97 sum(税金明细)
            sum收入（明细） 370.35    0.17   62.96 sum（收入明细）
62.97-62.96=0.01<=0.06就可以开票
    上述条件均符合的就可以直接合并。保留合并前所有发票信息记录，然后再存储新生成的金税合并发票记录到数据库中，并给该新发票随机生成一个税号。
由于金税合并后的商品名称和单价字段过长，增加了数据库执行负担，所以在金税合并后就不显示商品名称、商品单价及开票时间等属性。
该模块实体图：
 
图3-5 金税合并实体图
5、发行依赖模块
在本模块，操作员通过多重检索获取一组待发行依赖的发票数据信息，操作员再根据自己的要求勾选需要发行的发票信息，然后点击确认提交。发票就发行成功。在状态结果列表中，需显示提交的发行依赖的发票信息，并显示“正在打印中…..”等字样。
该模块实体图：
 
图3-6 发行依赖实体图
6、金税文件导出模块
在本模块，操作员按照发票类型进行检索，将检索结果进行列表展示，操作员浏览后，勾选需要导出的发票记录（可多选或全选），点击确认导出。由此，该组类型的发票全部以EXCEL的格式导出。最后，根据导出的文件状态进行发票回传操作。
红票发票类型的导出文件原先设计的是红票和对应的正数发票一起出文件，但是红票和标准发票已经列为金税合并的情况下，所以就只是出具红票的显示内容，到时候发行依赖成功后，在由企业自行进行合并处理。
该模块实体图：
 
图3-7 金税导出实体图
7、发票回传模块
    该功能再以上的功能基础上，最后实现的功能，由于我设计的是先开票然后处理完才可以导出，导出完后才可以发票回传，基于这些前提，该模块具有统计整理查看的功能。那么从企业业务上来看也可以针对回传检索，调查企业的相关财务业务支出，方便整理后续的财务计算等工作。基于这个模块只是用来方便企业做处理的，因此不是核心模块，是作为一个辅助模块的功能。
导出后的金税文件具有发票回传功能，设导出状态字段为“Receipt_Out”，若： 说明该发票已经导出，若： 则为未导出状态。在发票回传子系统中，将导出后的总发票件数，废票件数，红票件数（赤字发票），普通发票件数以及金税合并发票件数列表显示，并可按照设置的查询条件进行模糊查询。 C#+sqlserver的SAP金税接口研究及红票优化处理(10):http://www.751com.cn/jisuanji/lunwen_3235.html