【IT168 技术文档】
税务应用现状
税务行业应用经过多年的发展演进,已经形成了税务征管系统(CTAIS)、出口退税系统、税控发票系统、增值税管理系统等多个独立系统。随着SOA架构的日趋成熟,其面向业务的灵活性也得到广泛认可。税务系统近几年也基于SOA架构进行了企业应用集成,实现了税务征管系统和其他内部系统的内部集成,同时,与银行、国库的数据交换也相对完善。另外,也具备了向一户式查询这样的类似操作型应用系统(ODS),也初步实现了对数据初步利用,能够实现部分查询统计、报表等信息应用系统。如下图:
但在税务行业的应用仍然存在以下问题:
以流程为中心
税务信息化经历了十几年的建设,在各个阶段根据不同的业务流程需求建立相应的信息系统,这些阶段建设的系统基本是将业务流程信息化,模拟手工流程,是以流程为中心的,其架构设计很少全盘考虑。虽然在当时的阶段,提高了税务业务的效率,但随着信息化的不断发展,这样建立的系统已经显现出其弊端,很难适应变化的业务变化,不能做到业务的随需应变。这很大程度上限制了税务业务流程的重组及优化。
应用竖井导致信息资源分散
每个独立应用都绑定了专有数据库,应用竖井导致了数据竖井,有价值的信息资源被分散到多个数据库中,存在严重的不一致性。另外,数据库的设计也是针对当时的业务进行设计的,缺乏全面的数据架构设计,导致数据难于利用,其利用价值也大打折扣。
数据标准执行不利
国税总局虽然制定了数据标准,但应用是不同时期由不同厂商开发,对数据标准的遵从度不高,只是专注与实现系统功能。所以,数据标准执行效果较差,从而带来了数据质量的下降,难于管理及利用。
对外信息交换弱
目前,与外部委办局的数据交换相对较弱,纳税人在工商的信息变更、在公安的身份信息、在检查机关的涉案信息等不能实时交换到税务机关,而这些信息对纳税人的动态管理是非常重要的,根据这些交换得到的信息,税务机关能够有针对性的管理纳税人,便于决策。税库银、税银库相对完善,可以实现实时、批量的实时扣款及入库,这点体现了技术助力业务流程的重组,传统的上解销号、在途、入库销号等已经弱化,打印税收缴款书(完税证)等部分流程也相当与外包给了银行。对外信息交换的加强将很大促进业务流程的重组。
数据利用成熟度低
在目前的整体架构中,数据仓库、ODS不能动态实时参与业务流程,只是局限在做一些即席查询统计等传统数据利用业务。而数据利用的真正价值在于数据利用结果能够实时反馈业务流程,提供决策依据并最终改进业务流程。如果要达到高的信息利用成熟度,首先在架构层面将数据仓库参与到SOA架构当中,实现信息随需应变。
另外,目前数据仓库的企业数据模型缺乏有效设计,大部分数据简单的从各个系统抽取上来,堆集在数据仓库中,也是数据利用效果不不佳的重要原因。建立相对稳定、灵活的企业级数据模型是数据利用成功的关键。
系统固定难于适应业务变化
税务业务变化平凡,如各种登记表的变更,业务流程的变更等。在目前的系统中,这些变化大多通过修改程序代码的方式进行维护,维护费用很高,且响应周期长,维护的主题是开发商的技术人员,客户很难参与到维护工作中做到业务随需应变。评价一套系统架构的是不是灵活的关键点是系统能不能由用户参与定制来实现业务的随需应变。
无纳税人全景视图
虽然税务建立了很多的系统,但各个系统的信息层面没有有效集成,不能形成纳税人的全景视图。零散的纳税人信息散落在各个系统当中,存在严重的不一致性,有时我们根本不知道相同业务语义的内容到底以哪个系统为准,这对业务的价值大大降低了。由此,导致对纳税人服务质量降低以及对纳税人的管理难度加大。一个税收管理员如果能方便的拿到一个纳税人的全景视图,一目了然的看到纳税人的登记、涉税、稽查、发票等信息,必然提高他对纳税人的管理及服务质量。如果我们在业务流程当中能够随时取得我们纳税人的全景视图,必然能够为审批等环节产生决策依据,这大大提高了信息的业务价值,信息成为企业的战略资产,理应发挥它的作用。纳税人档案系统的建立将有效解决这个问题,提升业务价值,在纳税人关系管理中扮演重要角色。
PUREXML助力税务应用
每次新技术的出现都会推动行业应用发生大的发展,PUREXML技术的成熟将在很多行业应用领域实现根本性的改变,对软件系统的随需应变及业务价值提升方面产生深远影响。税务行业典型场景有前端数据采集及纳税人档案。
表单驱动型数据采集应用
行业应用一个重要的功能组成就是根据业务表单采集数据,在税务行业,诸如开业登记、申报等都属于这种类型的应用。如何实现面向业务的灵活性是我们考虑的首要问题,在业务表单发生变化的时候如何做到快速应变,能够以客户为主体实现软件系统的维护呢?这需要有技术的保障来支持这种灵活性。
我们通过分析一个场景来说明这个问题。2006年上旬,国税总局对税务登记表进行调整,原税务登记表包括六类登记表,分别适用于内资企业、外商投资企业、企业分支机构、外国企业、个体经营、其他单位,调整后,税务登记表分为三类:单位纳税人,个体工商户、个人独资、个人合伙企业,临时税务登记纳税人。此次调整,新增了临时税务登记表,同时,将原有的适用于内资企业、外商投资企业、企业分支机构、外国企业、其他单位的登记表合成一份登记表,此次换证工作将税务登记表由原来的6种变为3种,税务登记证件由原来的4种变为2种,税务登记表所涉及的新增加项目归并后有52项,减少项目归并后有51项 。这种业务表单的表单的改变通常引发软件系统大规模的修改,另外,一个更为严重的问题,是修改前的信息难于在修改后的系统中进行处理。为什么会出现这种情况呢,让我们深入分析一下现有系统的实现方式,相信会得到一个满意的答案。
目前软件系统的实现方式如上图:
展示层
通过对XML的DOM解析进行动态数据的展示。表单变化必然导致展示及解析代码的修改。修改过程通常经过硬编码来实现,这样带来的一个问题是维护周期及成本很高,以技术人员为主,客户难于参与其中,难于做到面向业务的灵活性。另外,修改后的程序难于适应修改前的业务表单数据。
业务逻辑层
该层的针对经过SAX解析形成的JAVA对象进行业务逻辑操作,表单的数据项变化必然导致硬编码的修改,通过补丁的方式更新到生产系统上,涉及一整套的测试发布流程,且对生长系统的是否正常运行产生挑战,需要专业技术人员大力参与。
数据层
数据库设计采用严格的关系表,表单的变化必然导致关系表模型的重构,如果涉及重构的表是核心表,对系统的影响面非常大,系统中所有设计该表的代码都要进行修改,风险是很高的。究其根源,大部分修改都是因为数据模型欠缺灵活性所致,所以,如何具备灵活的数据架构是保证面向业务灵活性的关键点。
综上,数据模型灵活性的缺失是导致大部分维护工作量的元凶,技术人员陷入了修改泥潭,业务人员仍然在抱怨应对业务变化太差。一个永远也解不开的恶性循环。我想是到了我们应该仔细考虑一下这种问题该如何解决的时候了,这个问题不能有效解决,何谈业务流程改造等目标呢?
假设我们在数据层进行大胆创新,变换设计思路,将传统设计中纯关系表转换为关系表和XML有机结合,会带来什么效果呢?
首先,我们看一下根源所在:
关系模型
– 严格的数据及关系定义
– 高性能的索引机制
– 缺乏数据模型上的灵活性
– 适合固定的结构化数据
XML
– 层次型的结构
– 具备自描述能力,易于理解
– 数据模式的灵活性
– 适合结构化、半结构化和非结构化数据
面对数据日益复杂的要求,纯关系数据库受到了灵活性的挑战。在我们明确的关系模型和XML的区别以后,我们认为,我们发现了数据模型灵活性缺失的根源,接下来要考虑如何解决。
关系和XML的有机结合是唯一的选择。设计原则如下:
封装原则:将变化的数据封装到XML数据包中,通过灵活的匹配SCHEMA和XSLT应对变化的数据。
抽取原则:将不变的数据,如纳税人识别号、纳税人名称、纳税人所属税务机关、登记日期等,这些数据是纳税人的标识属性、管理属性及时间属性,不管表单将来如何变化,这些属性是必然存在的,我们可以将这些属性作为关系列进行设计。
如果按照这两点进行设计的数据库,将是一个关系型和XML混合的数据模型,XML自身固有的层次结构及灵活扩展能力使的数据模型层具备了一定的灵活性支持。由此带来的价值怎样呢?如下图:
数据模型的改进给我们带来了前所未有的灵活性。变化的内容被封装在XML内部,通过SCHEMA和XSLT的灵活映射来面对变化。不变的内容以关系型数据存在,好处如下:
数据模型简化,以前类似电路板的复杂关系表不见了,代之而来的是清晰的关系和XML的混合模型,管理上也相对简化
维护的主体不在是技术人员为主,客户重新夺回了控制权
维护量大大降低,只需要调整SCHEMA及XSLT,硬编码大大降低,能够快速适应业务变化,实现新旧版本的统一对待。
从泥潭中解脱出来,能够投入到业务流程改进当中,有效提升业务价值
有一个问题相信很多人会提出,用了这种体系机构的数据模型在支持查询统计方面是否存在性能问题,毕竟,我们的前端采集系统70%的功能实际上是查询,尤其很多是在交易过程中的查询。我想在这个问题上我们应该注意两点:
数据是分职责的,前端采集系统的数据模型除了承担采集交易内查询外,不应该承担大量的查询统计,如果数据职责不能有效划分,系统最终还是会负载过载,而跟采用关系和XML混合无关。
XML技术已经成熟,不在局限在存成大文本的时代了,而是以直接存储成层次结构。另外,PUREXML技术中通过基于XML节点的索引技术将查询性能提升了几个数据级,只要设计合理性能不在是瓶颈。
综上,XML数据模型的采用在承担前端数据采集的系统中提供了很大的灵活性,附之以良好的应用层展示层设计,业务系统将能够提供业务随需应变。
数据模型从纯关系模型到关系和XML混合的数据模型演化后,客户重新夺回了控制权,成为维护的主体,避免了在业务发生变化时大量修改硬编码的情况。
纳税人电子档案
税务机关在经过多年的信息化建设,已经构造了很多应用,但却没有一个应用能够提供纳税人的统一视图,相反,纳税人数据越来越分散。系统不断升级改造,但纳税人仍然在重复报送着各种资料,税务审批人员在审批环节中仍然靠有限的数据进行决策,税收管理员在实地勘查时仍然看不到纳税人的登记、涉税、发票、出口退税、纳税人身份证件鉴定、是否违法等信息,这点从根本上制约了税务机关对纳税人关系的有效管理及服务质量,同时对税源的动态管理也成为空话。要实现这些目标,必须有纳税人档案及数据交换平台的支持,能够在业务环节中看到纳税人的全景信息,能够动态得到纳税人在其他委办局的一切动态。所以,纳税人档案系统业务价值如下(不限于):
将有效提升纳税人关系管理,是纳税人关系管理的基础
实现动态税源管理,从工商、海关、公安等其他委办局交换来的数据作为档案的一部分,能够使税务机关动态实时监控纳税人的动态
对业务流程反馈决策依据
对档案系统的增值开发将体现更多的业务价值
纳税人档案业务特点:
涉及纳税人各个方面的信息,包括税务信息,另外包括工商信息等其他委办局的交换信息,数据量大
信息复杂多样,涉及结构及非结构化数据,对纳税人影像资料等进行有效管理
对纳税人各个阶段的历史数据能够原样展示,避免信息失真,版本管理很重要
作为档案,信息更新应具备不可抵赖性
体现档案价值,反馈业务流程,如减免缓退的审批流程、税收管理员业务等,另外,档案信息应有效提高纳税人动态管理,进而提高纳税人服务质量
根据以上业务特点分析,纳税人档案系统的建设能够有效提升纳税人管理及服务水平,其关键点不在功能,而在与数据层面的有效设计,灵活的数据架构是达到这个目标的关键所在。
纳税人档案数据模型设计探讨
档案数据抱括了纳税人方方面面的信息:
税务信息:
纳税人登记信息
纳税人涉税信息
纳税人财务信息
纳税人出口退税信息
纳税人发票信息
其他
交换信息:
纳税人相关法人证件信息(来源与公安数据交换)
纳税人工商登记信息(来源与工商数据交换)
海关报关信息(来源与海关数据交换)
所有相关委办局纳税人信息
信息分类:
结构化数据
非结构化数据
影像资料
关系模型描述:
涉及几千张表,表关系复杂,难于管理
关系型数据难于实现可抵赖性设计
档案版本变化支持困难,数据模型稳定性差导致大量系统维护工作
对非结构化数据支持困难
关系型设计引发的问题总结
正如上图中所示,在业务变化没有导致表结构变化的情况下(无红色部分),数据模型还是相对清晰,容易管理的,但当业务变化导致出现增加列、增加表等情况时,情况就变的越来越糟糕(增加红色部分),上图左侧所描述的问题出现了。长此以往,数据库里堆积了很多垃圾表,以致于无法管理的地步。
纵表设计也有下图中描述的一些问题存在:
应该采用更加灵活的数据模型进行描述,关系型和XML相结合的数据架构能够避免以上问题,增加系统灵活性。
从上图可以看出,描述档案内容的共有属性一般包括标识符、名称、分类属性、时间属性、管理属性等,这些属性是稳定的,我们把这些稳定的属性设计成关系型数据。而对于档案的内容信息是不稳定的,业务上经常出现表单等变化,需要经常调整,这些不稳定的数据我们采用XML类型的关系列来存放,优势如下:
XML自身的层次结构能够描述复杂的数据,针对传统设计中采用LOB大字段处理的信息可以通过XML类型来解决,并可以通过SQL/XQUERY灵活访问
数据模型中的表明显减少,表之间的关系也大大简化,便于管理
XML通过匹配多版本的SCHEMA及XSLT体现灵活性,很容易适应业务变化
XML很好的支持数字签名等安全机制,很容易实现防抵赖
设计示意如下:
上图中我们发现两个XML列字段,这两个字段容纳了税务登记信息及税种核定信息,这在以前关系数据库设计中需要约20张关系表进行描述,现在只需一张表。XML字段以下图所示的层次机构清楚的描述税务登记信息的内容。
综上,采用关系型和XML混合建模适合档案系统的建设,大大提高系统灵活性,参考下图:
如上图所示,数据模型简化且相对稳定,通过XML匹配响应的SCHEMA及XSLT实现应对业务变化,数据模型相对保持一个清晰的结构,不会出现蜘蛛网状的表间关系。通过动态拼装XML形成复杂的纳税人档案全景数据视图。
基于关系和XML实现的纳税人档案系统具有以下优势:
管理角度
– 避免纳税人重复报送各种资料,提高纳税人满意度;
– 降低基层资料信息重复采集,提高工作效率,减少工作量;
– 辅之以CA签名,符合未来档案管理规范。
– 随时可调阅的360度全景视图
业务角度
– 可利用电子档案数据真实的再现纳税人的涉税历史,不会因为业务的变化而产生信息失真
– 随需而动,拥抱业务变化
技术角度
– 提供实现SOA的数据层支持
– 表结构设计简化,容易管理
– XML技术的大量采用是今后软件系统的趋势
维护角度
– 避免由于表征单书的变化导致大规模的程序修改甚至重新开发
– 从繁重的程序修改中解脱出来,而是通过客户自己定义相关的XML数据包、XSLT转换样式来适应业务变化
IBM作为数据库的领导者,在其DB2 9 中提供了XML的支持,这一创新将引发数据模型设计的一个变革,真正做到信息随需应变,进而真正实现业务随需应变。