C#+sqlserver的SAP金税接口研究及红票优化处理(9)
进入该系统首先需要注册用户登录，本系统用户类别分为开票员（主要操作为企业开票）及系统操作员（主要是负责对开具的发票进行相关一系列的操作）。所有用户需先注册个人基本信息，才能登录本系统进行相关操作。注册信息主要有：用户名、密码、姓名、用户类型及邮箱地址等信息。
另外，系统操作员除了可进行一般用户的权限操作外，还能进行后台管理操作，例如修改个人信息资料，修改系统初始化配置参数（诸如发票税务统计时间、发票最高总金额上限和税率等）等。所有注册成功的管理员可进行在线开票、发票确认、金税合并、发行依赖及电子表格导出，发票回传等多种功能操作，并可对当前本用户修改密码或注销。
该模块实体图：
图3-2 登陆注册信息实体
2、在线开票模块
开票员进入该系统，输入发票初始相关参数信息，确认后提交。这样就初步提交一份未处理的发票到数据库，供操作员处理。其中，发票总金额不能超标，否则前台输入脚本阻止该数据库的录入，并提示开票员不能开具发票。这里的开具发票的功能其实本身企业并无需求，但是我在这里加的这功能的原因是因为，如果企业之前导入的一些发票已经做过确认，但是这些做过确认的发票万一有变动的，开错了，需要开一张红字发票的，这时在返回企业内部数据库去更改就比较麻烦，那么我这里的功能其实就已经在为企业红票优化进行的第一部处理。
其中，发票类型定义：设定一个字段“Receipt_Type”参数表示发票的类型。主要发票类型如下：
1、 废票类型：
2、 普通票类型：
3、 红票类型：
4、 金税合并票类型：
该模块实体图：
图3-3 未处理发票信息实体图
3、发票审核模块
在该模块中，操作员检索开票员新近提交的未经确认的发票。操作员根据保存状态，检索出未保存的新发票，并列表展示出来。操作员可单选，或多选其中的一项或多项，或全选，然后点击确认提交。这样，就完成了这些新发票的确认保存。如果发现开票员的发票信息有误，操作员选择错误的发票信息，点击废除对该发票进行废除处理，并仍然确认提交，但是该票的类型变为废票。
其中，保存状态的定义如下：
设定一个字段“Flag_Save”参数表示企业对发票的确认状态。如企业已经确认该发票就设置为保存状态： ；否则就设置为未保存状态： 。
该模块实体图：
图3-4 未处理发票审核信息实体图
4、金税合并模块
在本模块，操作员检索出初步符合金税合并要求的发票，然后根据这些发票信息分类为红票类型和普通类型2大类，之后，根据相应类型的算法进行发票的金税合并。对于符合要求的发票，合并后，删除原来的发票信息，生成一个合并后的新的发票信息，并给予一个随机的新发票税号；对于不符合合并要求的发票，返回合并失败信息给系统操作员。
首先，操作员需要根据下列约束条件来检索可以进行金税合并的发票数据信息：
1、保存状态必须是已经确认保存的。即， 。
2、发票类型不得为废票。即， 。
3、发行依赖必须为未输出（未打印）状态。即， 。
其中，发行依赖的状态的定义如下：
设定一个字段“Flag_Print”参数表示发行依赖状态，则发行依赖后的输出状态为： ；否则就设置为未发行输出状态： ；
检索出初步符合金税合并条件的这些发票信息后，操作员自由选择这些满足初步合并条件的发票进行进一步的金税合并操作。操作员可以自由勾选多个发票信息进行合并，然后确认合并提交。金税合并的基本前提条件是收票方相同，税码相同，操作员已经确认该发票可以进行合并（已经确认过的）。后台系统服务器实时获取操作员提交的这些发票数据信息，并根据预先设定的金税合并算法进行发票自动合并。如果符合算法要求就完成新合并，并随机生成新的税号。否则，返回操作员提示信息，如“该组发票不符合要求，不能进行金税合并。”