《金税三期架构需求--网络发票管理系统.pdf》由会员分享，可在线阅读，更多相关《金税三期架构需求--网络发票管理系统.pdf（53页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、金税三期工程金税三期工程架构管控架构管控项目项目 金税三期金税三期架构需求架构需求网络发票管理系统网络发票管理系统 V V1.01.0 电子文档 金税三期工程架构需求金税三期工程架构需求网络发票管理系统网络发票管理系统 编 写 人 金税三期工程架构管控项目组 审 核 人 金税三期工程办架构组 批 准 人 金税三期工程办 密 级 内部文档 提交时间 文档编号 金税三期工程金税三期工程架构管控架构管控项目项目组组 20112011 年年 4 4 月月 金税三期工程金税三期工程架构管控架构管控项目项目 第 2 页/共 53 页 修订记录修订记录 版本版本 章节章节 修改内容修改内容 修改人修改人 修
2、改时间修改时间 V1.0 文档创建 架构管控项目组 2011-4 金税三期工程金税三期工程架构管控架构管控项目项目 第 3 页/共 53 页 目录目录 第第 1 章章 金税三期总体概述金税三期总体概述 .61.1.总体战略目标 .61.2.总体技术目标 .71.3.总体架构要求 .8第第 2 章章 总体范围说明总体范围说明 .9第第 3 章章 业务功能要求业务功能要求 .10第第 4 章章 应用系统设计要求应用系统设计要求 .11第第 5 章章 与周边系统交互关系与周边系统交互关系 .13第第 6 章章 系统关键技术要求系统关键技术要求 .156.1.运营商端网络发票开具软件 .156.2.运
3、营商端网络发票业务前置 .166.3.税务局端数据发送前置 .17第第 7 章章 数据设计约束数据设计约束 .197.1.规划策略 .197.2.数据分布及流向 .197.2.1.征管系统全国集中模式 .197.2.2.征管系统省级集中模式 .207.3.网络发票数据分类 .217.3.1.运营商端 .217.3.2.税务局端 .227.4.主数据 .237.5.数据质量 .23第第 8 章章 非功能性约束非功能性约束 .258.1.范围 .258.2.系统性能 .258.3.可靠性 .268.4.可用性 .268.5.易用性 .268.6.可维护性 .278.7.可扩展性 .288.8.可伸
4、缩性 .288.9.可移植性 .28第第 9 章章 安全性约束安全性约束 .299.1.安全等级要求 .299.2.策略和措施 .299.3.应用层安全 .319.3.1.应用系统安全设计要求 .31金税三期工程金税三期工程架构管控架构管控项目项目 第 4 页/共 53 页 9.3.2.应用开发安全要求 .319.3.3.身份认证系统 .329.3.4.Web安全防护 .329.4.数据层安全 .329.5.终端安全策略 .339.6.系统层安全 .339.7.网络层安全 .349.7.1.网络结构安全 .349.7.2.划分子安全域 .349.7.3.网络访问控制 .359.7.4.恶意代码
5、防范 .359.7.5.网络安全审计 .359.7.6.边界完整性检查 .359.7.7.入侵防范 .369.7.8.网络设备安全防范 .369.8.系统层安全 .369.9.物理层安全 .37第第 10 章章 部署约束部署约束 .错误！未定义书签。10.1.生产中心部署 .错误！未定义书签。错误！未定义书签。10.2.灾备中心部署 .38第第 11 章章 架构管控约束架构管控约束 .38第第 12 章章 技术开发规范约束技术开发规范约束 .4212.1.总体概述 .4212.1.1.目的 .4212.1.2.范围 .4212.1.3.标准规范概述 .4212.2.业务流程标准 .错误！未定义
6、书签。错误！未定义书签。12.2.1.业务需求 .错误！未定义书签。错误！未定义书签。12.3.业务数据标准 .错误！未定义书签。错误！未定义书签。12.3.1.税务数据元目录标准 .错误！未定义书签。错误！未定义书签。12.3.2.税务业务代码标准 .错误！未定义书签。错误！未定义书签。12.4.模型设计标准 .错误！未定义书签。错误！未定义书签。12.4.1.关系型数据模型设计标准 .错误！未定义书签。错误！未定义书签。12.4.2.关系型数据模型标准 .错误！未定义书签。错误！未定义书签。12.5.集成标准 .错误！未定义书签。错误！未定义书签。12.5.1.应用服务集成标准 .错误！未
7、定义书签。错误！未定义书签。12.5.2.数据交换技术协议标准 .错误！未定义书签。错误！未定义书签。12.5.3.税务行业数据报文设计标准 .错误！未定义书签。错误！未定义书签。12.6.关键技术标准 .错误！未定义书签。错误！未定义书签。12.6.1.总体技术路线 .错误！未定义书签。错误！未定义书签。12.6.2.二维条码应用技术标准 .错误！未定义书签。错误！未定义书签。12.7.安全标准 .错误！未定义书签。错误！未定义书签。金税三期工程金税三期工程架构管控架构管控项目项目 第 5 页/共 53 页 金税三期工程金税三期工程架构管控架构管控项目项目 第 6 页/共 53 页 第第1章
8、章 金税三期总体概述金税三期总体概述 1.1.总体战略目总体战略目标标 金税三期工程的业务战略目标是：统一税收执法；统一纳税服务；统一管理决策；统一征管数据实时监控。首先，统一税收执法是在国家税法统一的前提下，以总局统一的政策管理为依托，包括国、地税税收执法尺度的统一，为纳税人提供公平、公正的税收环境。在现阶段，公平、公正是对纳税人最好的服务。同时，统一税收执法，也是现阶段实现应收尽收，保证税款及时入库的有效保证。其次，统一纳税服务，不是简单的建立一个平台，而是保证服务目标、服务内容、服务水平的一致，避免不同地区、不同税务人员对同类事项执法不一、口径各异和服务差异。第三，统一管理决策，是采用科
9、学的方法，利用数据集中和信息共享手段，为各级领导提供一致的管理和决策依据。第四，建立在全国大集中基础上的统一实时的征管数据监控，是促进统一执法、统一服务、统一管理决策的手段保障。在国内外新的经济形势下，为了实现四个统一的战略目标,总局确定了信息管税的总体战略，信息管税就是以税收风险管理理念为指导，以现代信息技术为依托，以对涉税信息的采集、应用为主线，优化资源配置，完善税源管理体系，加强业务与技术的高度融合，着力解决征纳双方信息不对称问题，不断提高税法遵从度和税收征收率。其中，信息管税是一项系统工程,必然要涉及到税务管理的思想观念、制度机制、业务流程、组织机构等一系列变化。如下图所示：金税三期工
10、程金税三期工程架构管控架构管控项目项目 第 7 页/共 53 页 这里的“全国大集中”，涵盖核心业务核心业务系统系统全国集中部署和应用，统一业务需求管理、统一应用开发和运行维护管理。1.2.总体技术目标总体技术目标 金税三期工程建设的主要内容是：计划用四年时间，在现有资源基础上，通过制度、业务和技术创新，完成“一个平台、两级处理、三个覆盖、四个系统”的建设，进一步强化纳税服务和税务管理，提高税法遵从度和税收征收率，降低税收成本，为税收法律法规的统一执行提供有力保障。上述目标可具体概括为“一门户、三网、四平台、七库”，具体描述如下：1、“一门户”是通过实施全国数据大集中，优化业务流程和功能配置，
11、统一国地税征管系统，为全国各级税务人员提供统一的内部门户和工作平台，实现全国税收业务的统一、规范管理。2、“三网”是建成税收征管业务网络、行政办公网络、涉密网络，这三个网络全国国、地税统一建设，具备强大的信息采集、存储、处理、交换等功能，安全可靠程度高，确保各项税收业务与管理在统一、安全、稳定的网络化信息平台支撑下平稳运行。3、“四平台”是指建设全国统一的纳税服务平台、征管和行管业务操作平台、管理决 金税三期工程金税三期工程架构管控架构管控项目项目 第 8 页/共 53 页 策平台，这四大平台能使广大纳税人方便、快捷地办理各项税费事宜，广大基层税务人员高效、简洁地处理各项业务，使各级税务管理者
12、及时有效地实施管理与决策。4、“七库”是指在总局、省局两级建立并逐步完善法人涉税数据库、自然人涉税数据库、发票数据库、第三方信息数据库、税收风险管理数据库、税务机构数据库（包括财务、固定资产等）和人力资源数据库、税收法规数据库（包括文件、档案等）这七个数据库，并进行数据的集中存储和处理，同时建立第三方信息共享机制，实时、完整、准确地掌握纳税人涉税费信息和税务机构、人员等情况，以利于提高税收服务与管理水平。1.3.总体架构要求总体架构要求 总体架构既包含业务、应用、数据、技术、安全、运维等方面的框架，也包括架构管控的体系。一方面，作为框架，总体架构定义了业务、应用、数据、技术、安全、运维等架构的
13、目标蓝图，还包括相关模型，及各部分 的指南、设计准则，项目需要根据总体架构的约束来实现其应用；另一方面，作为架构管控，它指明了项目在进行项目实施的时候需要遵守的标准、规范，可以参考的相关架构资源以及需要遵守的架构管控流程，以确保项目的实施符合金税三期的总体规划。总体架构主要由业务架构、应用架构、数据架构、技术架构（包括系统软件、基础设施等）、安全架构、运维架构、标准、架构管控体系等组成，这些总体架构的内容将构成对项目架构方面的约束，项目需要在这些架构的约束下进行业务需求分析、设计以及实现以完成项目的目标。金税三期工程金税三期工程架构管控架构管控项目项目 第 9 页/共 53 页 第第2章章 总
14、体范围说明总体范围说明 网络发票系统由税务局端和运营商端两部分构成。税务局端包括网络发票数据交换前置、发票查验前置和网络发票数据库，采用总局/省局两级部署模式；运营商端包括网络发票开具软件和网络发票业务前置。下图给出了网络发票开具软件的总体构成以及在整体金税三期应用环境的位置，见图中橙色部分。人工办理管理决策税收征管处理渠道总局省局外网内网总局省局外网内网浏览器网上税局电话核心征管处理个人税收管理查询统计征管状况分析报表管理总局前置绩效管理风险管理政策评估知识管理核算应用集成平台层级数据交换平台业务工作门户电话/手机总局内部门户网站行政办公综合办公人力资源财务纪检监察渠道外部门机构银行系统浏览
15、器12366自助终端省局前置电话/手机行政办公综合办公人力资源财务纪检监察业务工作门户省局内部门户网站省局遗留系统邮寄外部门机构国库系统IA平台IA平台大厅外部信息交换税库银层级数据交换平台防伪税控交叉稽核外部信息交换税银库基础支撑平台公共数据分析数据治理指标管理数据集成管理决策查询统计征管状况分析报表管理绩效管理风险管理政策评估知识管理核算基础支撑平台公共数据分析数据治理指标管理数据集成纳税服务应用支撑短信电子邮件政府信息公开目录系统政府信息公开目录系统省局自有网站渠道数据发送前置省级征管系统网络发票开具软件数据发送前置发票查验前置发票查验前置数据接收前置网络发票数据库网络发票数据库网络发票
16、数据库网络发票数据库网络发票业务前置网络发票开具软件网络发票业务前置 如上图所示本项目负责负责完成网络发票开具软件、网络发票业务前置和局端数据发送前置的设计与开发。网络发票开具软件、网络发票业务前置的部署层级根据各运营商自身情况来确定，数据发送前置需要在税务局端进行总局/省局两级部署。金税三期工程金税三期工程架构管控架构管控项目项目 第 10 页/共 53 页 第第3章章 业务功能要求业务功能要求 网络发票管理系统总体业务功能如下图所示：网络发票系统总体业务功能网络发票系统总体业务功能运营商端税务局端运营商端税务局端发票填开发票填开发票作废发票作废空白发票异常作废空白发票异常作废发票补打发票补
17、打发票存根联补录发票存根联补录查询与统计查询与统计系统维护系统维护网络发票资格确认网络发票资格确认发票清分发票清分发票查验查询预警信息发票查验查询预警信息通用机打发票行业分类确认通用机打发票行业分类确认发票查验发票查验纳税人端网络发票开具软件网络发票管理系统纳税人端网络发票开具软件网络发票管理系统发票上传发票上传核心征管系统核心征管系统发票监控管理发票监控管理管理决策系统管理决策系统 运营商统一开发的全国网络发票开具软件须经税务机关审核批准后方可使用，且要严格按照此标准开发和应用，在此基础上可扩展、应用其他辅助功能。按照发票管理有关规定使用发票，确保发票数据、内容的真实性。1、网络发票开具软件
18、。业务规范具体包括：发票填开、发票补打、发票作废、开票查询预警、发票存根联补录、查询与统计、空白发票异常作废、空白发票异常报告、系统维护等业务功能。详细的业务需求请参见网络发票业务需求文档。2、网络发票业务前置。需要实现与税务局端网络发票管理系统的连接，负责发送发票开具信息和发票预警信息，将其推送至税务局端的数据接收前置。3、数据发送前置。部署到税务局端，主要负责获取税务局端的发票发售信息以及纳税人基本信息变更内容，将其返回给网络发票开具软件。金税三期工程金税三期工程架构管控架构管控项目项目 第 11 页/共 53 页 第第4章章 应用系统设计要求应用系统设计要求 下图给出网络发票系统的总体应
19、用分布，整体的策略如下:1、整个网络发票系统由运营商端的网络发票开具软件、网络发票业务前置以及税务局端的网络发票管理系统共同构成。2、运营商端包括网络发票开具软件和网络发票业务前置两部分，网络发票开具软件负责实现全部的纳税人端发票开具相关业务，网络发票业务前置服务实现发票的查询统计、发票监控管理信息提供服务以及与局端数据交换前置的数据交换功能。3、税务局端网络发票管理系统总局部分由发票查验前置、数据发送前置和网络发票数据库构成，省局部分由发票查验前置、数据发送前置、数据接收前置和网络发票数据库构成。发票查验前置(总局/省局)负责为企业纳税人及社会公众提供完整的发票查验功能。数据发送前置负责为运
20、营商端提供发票发售信息以及纳税人基本信息。数据接收前置负责接收运营商端提供的发票开具信息以及发票监控信息。税务局税务局运营商端运营商端总局总局省局省局（总局）网络发票数据库（省局）网络发票数据库纳税服务渠道纳税服务渠道自开票企业(八大行业）自开票企业(八大行业）层级数据交换核心征管(总局集中)核心征管(省级集中)管理决策(省级)管理决策(总局)网络发票管理系统网络发票管理系统前置数据发送前置数据接收前置发票查验前置前置发票查验前置数据发送前置 基于上述的应用分布下面给出具体的设计思路说明。1、由各运营负责完成发票的开具相关业务、发票的查询统计业务以及发票的预警信息提供业务，发票开具数据第一次落
21、地在运营商端并在业务规定时间内经由税局端数据接收金税三期工程金税三期工程架构管控架构管控项目项目 第 12 页/共 53 页 前置同步到税局端网络发票数据库（省局）。2、运营商端可以保留能够支持发票查询统计业务以及发票预警信息业务的各类发票相关数据。3、所有的发票查验统一由总局纳税服务平台来负责提供入口（省局纳税服务平台可以提供链接跳转到总局查验页面），总局发票查验前置负责受理全部的查验请求，然后根据发票信息将具体的查验请求转发到相关省局的发票查验前置进行具体的查验处理。4、各运营商的开具数据落地后需要在业务规定时间内经由局端数据接收前置同步到网络发票数据库（省局），保证省局发票数据库数据的完
22、整性和时效性。5、由核心征管系统产生的的发票发售信息以及纳税人基本信息的变更内容，都将统一由税务局端的数据发送前置（总局/省局）负责提供给运营商，由运营商端的网络发票业务前置根据相关标准协议主动获取，整体的数据传输时间必须满足业务的时效要求。这样确保运营商系统在开票时不需要主动访问局端系统，降低局端系统故障对于前端开票业务的影响程度。6、省局网络发票数据库数据的完整性和时效性完全能够满足发票管理职能，针对网络发票的各类监管、审核、比对、预警等管理类业务，建议由运营商端负责将各类预警监管信息通过税局端数据交换前置同步到省局网络发票数据库中，具体的管理类业务全部由管理决策平台来负责实现。7、同时税
23、局端数据接收前置负责实现网络发票总局数据库与网络发票省局数据库之间的清分和汇总功能。8、必须实现运营商端与税务局端前置之间的流水管理和对账机制，最大程度降低故障的发生概率以及相应的应急措施。金税三期工程金税三期工程架构管控架构管控项目项目 第 13 页/共 53 页 第第5章章 与周边系统交互关系与周边系统交互关系 针对系统划分，下图给出网络发票各系统内部以及同外部相关系统的业务交互约束，明确定义出业务交互的对象、内容以及交互技术机制等。税务局税务局运营商运营商分部数据中心分部数据中心总局总局省局省局（总局）网络发票数据库（省局）网络发票数据库发票查验前置数据发送前置总局纳税服务渠道网络发票开
24、具软件网络发票业务前置总部数据中心总部数据中心网络发票业务前置自开票企业(八大行业）层级数据交换核心征管(总局集中)核心征管(省级集中)管理决策(省级)管理决策(总局)网络发票管理系统网络发票管理系统获取查验信息主动获取发票发售信息、纳税人基本信息推送发票开具信息发票开具信息汇总、清分推送发票发售信息纳税人基本信息获取发票开具信息获取发票预警信息获取发票发售信息、纳税人基本信息清分发票查验前置查验请求路由推送发票监控信息数据发送前置数据接收前置省局纳税服务渠道发票查验页面URL跳转主动获取发票发售信息、纳税人基本信息 交互业务交互业务 交互内容交互内容 来源系统来源系统 目标系统目标系统 交互
25、方式交互方式 运营商端需要获取纳税人基本信息 纳税人基本信息 数据发送前置（总局/省局）网络发票业务前置（运营商端）批量报文技术 运营商端需要获取发票发售信息 发票发售信息 数据发送前置（总局/省局）网络发票业务前置（运营商端）批量报文技术 税务局端需要获取发票开具信息 发票开具信息 网络发票业务前置（运营商端）数据接收前置（省局）批量报文技术 税务局端需要获取发票补录信息 发票补录信息 网络发票业务前置（运营商端）数据接收前置（省局）批量报文技术 运营商端需要将发票发票查询预警信网络发票业务数据接收前置批量报文技术 金税三期工程金税三期工程架构管控架构管控项目项目 第 14 页/共 53 页
26、 交互业务交互业务 交互内容交互内容 来源系统来源系统 目标系统目标系统 交互方式交互方式 查询预警信息推送至税务局端 息 前置（运营商端）（省局）金税三期工程金税三期工程架构管控架构管控项目项目 第 15 页/共 53 页 第第6章章 系统关键技术要求系统关键技术要求 基于前面的应用和数据需求，下面给出系统的关键性技术要求。6.1.运营商端网络发票开具软件运营商端网络发票开具软件 根据总体架构规划的内容以及功能要求,下表给出了运营商端网络发票开具软件在具体实现中一些关键性的技术约束。名称名称 定义定义 技术约束技术约束 信息安全 为确保系统和纳税人信息安全，应提供运营商端和纳税人端的网络接入
27、和平台安全保证措施 要求运营商必须提供安全的网络接入和平台安全的机制和措施。身份认证 应遵从 CA 数字证书身份认证、数字签名保护、离线时钟控制、安全加密存储、使用国密办指定税务专用算法、数据加密传输通道控制等安全保护措施，建设安全保护完备的系统，确保纳税人数据信息安全。要求运营商必须提供安全的身份认证机制和措施,必须符合税务局方提供的身份认证和应用安全支撑的相关标准。二 维 条 码应用 网络发票开具时，提供发票票面信息生成二维条形码的功能,支持含二维条码发票的打印，作为缺省实现内容，但各省根据自身情况可以确定是否使用。二维条码包含完整的发票信息和数字签名信息，通过二维码的扫描识别可还原，便于
28、传递和识别采集。总局将发布统一的网络发票二维条码应用技术标准，各运营商须遵循该标准 消 息 格 式转换 支持自定义的数据格式转换，包括 XML 之间以及 XML 同其他结构化文本的相互转换 运营商端接入纳税人端发来的消息，有可能消息是非规范的，是目标系统所不能识别的，要求系统必须提供消息格式的转换功能。故 障 隔 离机制 实现完整的故障隔离，保证某一渠道和交易出现故障时，不造成整体的访问阻塞，不影响请求系统对于其他类别交易的访问。故障隔离是保障系统可靠性的重要手段，必须提供对合理粒度的系统和服务进行隔离的机制，保证单点故障不会影响全局。交 易 流 水及 监 控 管理 提供对各类交易执行的流水信
29、息的记录、监控以及管理机制，能够完整的记录一笔业务的各类关键性执行线索信息，从而为冲正以及对账提供依据。必须符合税务局端系统的流水记录标准，能够支持双方的流水对账业务。可 靠 数 据交换机制 提供高可靠性的批量数据传输机制。必须符合金税三期工程的数据传传输技术协议和报文标准。批 处 理 管理机制 提供统一的批处理管理机制，包括任务的定义、执行、维护等，支持定时、人工、条件等多种批处理启动机制 要求系统必须提供批处理机制，从而应对各类需要进行批处理的业务场景。金税三期工程金税三期工程架构管控架构管控项目项目 第 16 页/共 53 页 6.2.运营商端网络发票业务前置运营商端网络发票业务前置 根
30、据总体架构规划的内容以及功能要求,下表给出了税务局端网络发票业务前置在具体实现中一些关键性的技术约束。名称名称 定义定义 技术技术约束约束 流量控制 流量控制是提升系统可靠性，降低系统性能风险的关键性机制。通过流量控制服务，要求能够及时掌握系统当前实际的服务访问流量，进行监控预警。提供根据设置,进行流量控制，.流量控制作为前端的一个总控点，需要保证健壮和稳定，并且支持分布式部署。针对网络发票的前置系统的流量控制分为总局和省局两级部署。消 息 格 式转换 支持自定义的数据格式转换，包括 XML 之间以及 XML 同其他结构化文本的相互转换 前置系统接入外系统发来的消息，有可能消息是非规范的，是目
31、标系统所不能识别的，要求前置系统必须提供消息格式的转换功能。可 靠 数 据交换机制 提供高可靠性的批量数据传输机制，支持多种模式的数据交换方式。必须满足业务对于数据传输的性能、安全性和可靠性要求 故 障 隔 离机制 实现完整的故障隔离，保证某一渠道和交易出现故障时，不造成整体的访问阻塞，不影响请求系统对于其他类别交易的访问。故障隔离是保障系统可靠性的重要手段，全国集中模式下必须提供对合理粒度的系统和服务进行隔离的机制，保证单点故障不会影响全局。符 合 服 务集 成 封 装机制 提供完整的服务封装机制，符合全局的服务注册、调用以及管理标准，能够很方便的将内部业务逻辑根据需求封装为全局性服务，以供
32、其他系统进行消费 必须符合全局的应用集成体系所定义的服务集成标准，从而保证各类对外暴露的服务能够被其他应用所共享 数 据 质 量保障机制 提供对整个系统各个环节数据质量的整体保障机制 考虑到未来数据利用的需求，因此数据质量是一个重要议题。要求系统在采集、处理、存储以及管理等环节提供数据质量保障机制。交 易 流 水及 监 控 管理 提供对各类交易执行的流水信息的记录、监控以及管理机制，能够完整的记录一笔业务的各类关键性执行线索信息，从而为冲证以及对账提供依据。交易流水是保证业务可靠性性的基础，要求前置必须提供交易的流水采集、记录。金税三期工程金税三期工程架构管控架构管控项目项目 第 17 页/共
33、 53 页 名称名称 定义定义 技术技术约束约束 流 水 对 账机制 提供系统间基于交易流水的业务核对和调整机制，为系统间的业务一致性提供保障。由于一笔网络发票业务涉及到多个系统间的传输，其业务复杂度较高，完全依靠的系统自身的事务机制已经无法满足，必须提供相应的异常检测和对账来保证异常情况下双方数据的一致性。6.3.税务局端数据发送前置税务局端数据发送前置 根据总体架构规划的内容以及功能要求,下表给出了税局局端数据交换前置在具体实现中一些关键性的技术约束。名称名称 定义定义 技术约束技术约束 流量控制 流量控制是提升系统可靠性，降低系统性能风险的关键性机制。通过流量控制服务，要求能够及时掌握系
34、统当前实际的服务访问流量，进行监控预警。提供根据设置,进行流量控制，.流量控制作为前端的一个总控点，需要保证健壮和稳定，并且支持分布式部署。针对网络发票的前置系统的流量控制分为总局和省局两级部署。渠 道 管 理机制 对于各类业务渠道，前置软件需要提供完备的管理机制，定义和维护渠道的接入协议、接入报文规范、接入安全机制、服务质量等特性 前置系统会面对多种不同类型的运营商渠道和自开票企业软件，因此要求前置必须提供统一的渠道管理机制 消 息 格 式转换 支持自定义的数据格式转换，包括 XML 之间以及 XML 同其他结构化文本的相互转换 前置系统接入外系统发来的消息，有可能消息是非规范的，是目标系统
35、所不能识别的，要求前置系统必须提供消息格式的转换功能。可 靠 数 据交换机制 提供高可靠性的批量数据传输机制，支持多种模式的数据交换方式。必须满足业务对于数据传输的性能、安全性和可靠性要求 数 据 同 步复制机制 针对不同类型的数据同步复制场景，提供相应的复制机制，支持同构、异构、批量、增量等多种数据复制机制。针对网络发票与其他各类数据源之间必须提供有效的同步复制机制，保证各数据源之间数据的一致性、及时性以及完整性 路由机制 支持自定义路由参数(包括地域、渠道系统、交易以及各类自定义业务参数等）和规则的路由机制，能够实现基于内容和规则的各类复杂路由场景。前置系统是实现各类渠道(包括总局和省局）
36、、省局自有系统同核心系统交互的枢纽，涉及到横向(总省局内部）和纵向(总局和省局之间）的各类路由场景，因此要求前置必须提供完备的路由机制。金税三期工程金税三期工程架构管控架构管控项目项目 第 18 页/共 53 页 名称名称 定义定义 技术约束技术约束 故 障 隔 离机制 实现完整的故障隔离，保证某一渠道和交易出现故障时，不造成整体的访问阻塞，不影响请求系统对于其他类别交易的访问。故障隔离是保障系统可靠性的重要手段，全国集中模式下必须提供对合理粒度的系统和服务进行隔离的机制，保证单点故障不会影响全局。统 一 渠 道接入标准 建立统一的渠道接入协议标准，明确定义出渠道的技术接入标准、报文协议标准、
37、异常处理标准、各类渠道、交易的命名标准等。前置作为枢纽型系统，因此必须提供全局统一的通讯协议规范来保证接入的效率和质量，避免由于缺乏标准而导致的各类问题。符 合 服 务集 成 封 装机制 提供完整的服务封装机制，符合全局的服务注册、调用以及管理标准，能够很方便的将内部业务逻辑根据需求封装为全局性服务，以供其他系统进行消费 必须符合全局的应用集成体系所定义的服务集成标准，从而保证各类对外暴露的服务能够被其他应用所共享 数 据 质 量保障机制 提供对整个系统各个环节数据质量的整体保障机制 考虑到未来数据利用的需求，因此数据质量是一个重要议题。要求系统在采集、处理、存储以及管理等环节提供数据质量保障
38、机制。交 易 流 水及 监 控 管理 提供对各类交易执行的流水信息的记录、监控以及管理机制，能够完整的记录一笔业务的各类关键性执行线索信息，从而为冲证以及对账提供依据。交易流水是保证业务可靠性性的基础，要求前置必须提供交易的流水采集、记录。流 水 对 账机制 提供系统间基于交易流水的业务核对和调整机制，为系统间的业务一致性提供保障。由于一笔网络发票业务涉及到多个系统间的传输，其业务复杂度较高，完全依靠的系统自身的事务机制已经无法满足，必须提供相应的异常检测和对账来保证异常情况下双方数据的一致性。金税三期工程金税三期工程架构管控架构管控项目项目 第 19 页/共 53 页 第第7章章 数据数据设
39、计约束设计约束 7.1.规划策略规划策略 在金税三期的大集中战略指导下，网络发票管理系统的数据库规划应遵循以下策略：数据分级存储 网络发票开具信息等数据采用运营商、省局和总局三级存储方式。纳税人网络发票开具明细信息首先落地在网络发票数据库（运营商端），运营商端负责缓存（缓存期限由业务需求决定）服务范围内的纳税人开具的网络发票明细信息，并向税务局端网络发票数据库（省局）同步；网络发票数据库（省局）负责存储本省开具的网络发票的明细信息，并向网络发票数据库（总局）同步；网络发票数据库（总局）集中存储全国网络发票开具明细信息，并向省局进行清分。数据实时性保障 运营商、省局、省局之间的数据同步频率以业务
40、时效性要求为依据，保证传输效率、数据存储可靠，支持大批量发票的及时开具和海量数据存储。数据安全保障 网络发票管理系统涉及到纳税人信息、网络发票开具明细信息等关键敏感数据，这些又数据分布在运营商、省局和省局，因此设计时必须考虑数据传输和存储的安全性。7.2.数据分布及流向数据分布及流向 7.2.1.征管系统全国集中模式征管系统全国集中模式 核心征管系统全国集中省份的网络发票数据分布及流向如下图所示：金税三期工程金税三期工程架构管控架构管控项目项目 第 20 页/共 53 页 网络发票数据库（总局）网络发票数据库（总局）网络发票数据库（省局）网络发票数据库（省局）纳税人基本信息发票发售信息纳税人基
41、本信息发票发售信息总局省局运营商总局省局运营商核心征管(全国集中)核心征管(全国集中)纳税人基本信息发票发售信息纳税人基本信息发票发售信息层级数据交换平台层级数据交换平台发票开具信息发票开具信息汇总/清分发票开具信息发票开具信息汇总/清分说明：核心征管系统全国集中省份，采用该模式说明：核心征管系统全国集中省份，采用该模式网络发票数据库（运营商）网络发票数据库（运营商）数据接收前置数据接收前置征管系统（省级集中）征管系统（省级集中）网络发票业务前置网络发票业务前置数据发送前置数据发送前置发票查验前置发票查验前置发票查验前置发票查验前置发票查验信息发票查验信息发票开具信息发票开具信息纳税人基本信息
42、发票发售信息纳税人基本信息发票发售信息纳税人基本信息发票发售信息纳税人基本信息发票发售信息发票查验路由信息纳税人基本信息发票发售信息发票查验路由信息纳税人基本信息发票发售信息发票监控信息发票监控信息发票开具信息发票监控信息发票监控信息发票开具信息税务局端税务局端 下面对核心征管系统全国集中省份的省局、总局、运营商之间的数据分布及数据流向进行说明：一、一、总局与运营商总局与运营商数据分布及流向数据分布及流向 核心征管系统通过网络发票数据发送前置（总局/省局）将纳税人基本信息及发票发售信息等数据在业务规定时间内推送至运营商端网络发票数据交换前置。二、二、省局与运营商省局与运营商数据分布及流向数据分
43、布及流向 运营商端通过网络发票业务前置将网络发票开具信息及发票监控信息等数据在业务规定时间内推送至税务局端网络发票数据接收前置（省局），由网络发票数据接收前置（省局）将上述信息同步至网络发票数据库（省局）。三、三、总局与省局总局与省局数据分布及流向数据分布及流向 网络发票数据库（省局）将本省网络发票开具信息等数据在业务规定时间内同步至网络发票数据库（总局），总局将跨省受票发票信息清分至受票方税务局网络发票数据库（省局）。核心征管系统将纳税人基本信息及发票发售信息等数据推送至网络发票数据库（总局），同时通过层级交换平台将纳税人基本信息等数据推送至网络发票数据库（省局）。7.2.2.征管系统省级集
44、中模式征管系统省级集中模式 当前，针对税收征管系统仍然采用省级集中的省份，网络发票数据分布及流向如下图所示：金税三期工程金税三期工程架构管控架构管控项目项目 第 21 页/共 53 页 网络发票数据库（总局）网络发票数据库（总局）网络发票数据库（省局）网络发票数据库（省局）总局省局运营商总局省局运营商发票监控信息发票开具信息发票监控信息发票开具信息纳税人基本信息及发票发售信息纳税人基本信息及发票发售信息发票开具信息汇总/清分发票开具信息汇总/清分征管系统征管系统纳税人基本信息发票发售信息纳税人基本信息发票发售信息纳税人基本信息发票发售信息纳税人基本信息发票发售信息金税三期核心征管金税三期核心征
45、管说明：核心征管系统未实现全国集中省份，采用该模式说明：核心征管系统未实现全国集中省份，采用该模式数据发送前置数据发送前置网络发票业务前置网络发票业务前置发票查验前置发票查验前置发票查验信息发票查验信息网络发票数据库（运营商）网络发票数据库（运营商）发票查验前置发票查验前置发票开具信息发票开具信息路由信息路由信息数据接收前置数据接收前置税务局端税务局端 下面对征管系统省级集中省份的省局、总局、运营商之间的数据分布及数据流向进行说明：一、一、省局与运营商数据分布及流向省局与运营商数据分布及流向 征管系统通过网络发票数据发送前置（省局）将纳税人基本信息及发票发售信息等数据在业务规定时间内推送至运营
46、商端网络发票业务前置；征管系统同时负责将纳税人基本信息及发票发售信息等数据推送至网络发票数据库（省局）。运营商端网络发票业务前置将网络发票开具信息及网络发票监控信息在业务规定时间内推送至税务局端网络发票数据接收前置（省局），由网络发票数据接收前置（省局）同步至网络发票数据库（省局）。二、二、总局与省局数据分布及流向总局与省局数据分布及流向 网络发票数据库（省局）将本省网络发票开具信息等数据同步（同步频率应满足业务时效性要求）至网络发票数据库（总局），总局将跨省受票发票信息清分至受票方省局的网络发票数据库。7.3.网络发票网络发票数据分类数据分类 7.3.1.运营商端运营商端 数据分类数据分类
47、内容内容 具体说明具体说明 数据来源数据来源 主数据 纳税人基本信息 税务登记信息、认定信息等 征管系统 纳税人状态 纳税人登记状态信息等 代码数据 业务字典数据、规则信息等 网 络 发 票 数据 开票资格确认信息 税务机关对纳税人网络发票资格确认信息 征管系统 金税三期工程金税三期工程架构管控架构管控项目项目 第 22 页/共 53 页 数据分类数据分类 内容内容 具体说明具体说明 数据来源数据来源 票种核定信息 纳税人可领购的发票种类信息，包括每次购买数量、每月购买数量、发票种类、数量、版本限额等 纳税人票种核定状态 在纳税人登记后，根据纳税人的基础等信息、资格情况等，提前生成对纳税人进行
48、票种核定所需的状态信息 纳税人领用存信息 纳税人的库存信息，包括纳税人发票领购、验旧、缴销、挂失等信息 发票发售状态 根据纳税人申报情况、违法违章情况、发票结存情况等提前预生成发票发售状态 网络发票明细信息 通过运营商端网络发票开具软件开具的网络发票明细数据信息 发票监控信息 网络发票监控预警信息 业 务 流 水 信息 业务流水信息 各类业务流水信息 7.3.2.税务局端税务局端 数据分类数据分类 内容内容 具体说明具体说明 数据来源数据来源 主数据 纳税人基本信息 税务登记信息、认定信息等 征管系统 纳税人状态 纳税人登记状态信息等 代码数据 业务字典数据、规则信息等 网络发票数据 开票资格
49、确认信息 税务机关对纳税人网络发票资格确认信息 征管系统 票种核定信息 纳税人可领购的发票种类信息，包括每次购买数量、每月购买数量、发票种类、数量、版本限额等 纳税人票种核定状态 在纳税人登记后，根据纳税人的基础等信息、资格情况等，提前生成对纳税人进行票种核定所需的状态信息 纳税人领用存信息 纳税人的库存信息，包括纳税人发票领购、验旧、缴销、挂失等信息 发票发售状态 根据纳税人申报情况、违法违章情况、发票结存情况等提前预生成发票发售状态 网络发票明细信息 网络发票的明细数据信息 运营商端网络发票开具软件 发票监控信息 网络发票监控预警信息 金税三期工程金税三期工程架构管控架构管控项目项目 第
50、23 页/共 53 页 数据分类数据分类 内容内容 具体说明具体说明 数据来源数据来源 业务流水信息 业务流水信息 各类业务流水信息 7.4.主数据主数据 金税工程（三期）建立税务主数据的目的，是用来描述国、地税业务实体的数据，如纳税人基本信息、纳税人状态信息、代码信息，以及个人税收管理的自然人基本信息，状态信息，代码信息等。它们是具有高业务价值、可以跨国、地税各个业务部门被重复使用的数据，并且存在于多个异构应用系统中。金税工程（三期）金税工程（三期）的的面向纳税人的面向纳税人的主数据应包含三类信息：主数据应包含三类信息：纳税人基本信息：纳税人识别号、纳税人名称、登记注册类型等；纳税人基础状态