新一代交易与核算分离的帐务一致性测试方法研究【毕业论文】

1、图书分类号:密级毕业设计（论文）题目：“新一代”交易与核算分离的帐务一致性测试方法研究学生姓名班级学院名称专业名称指导教师学位论文原创性声明本人郑重声明：所呈交的学位论文，是本人在导师的指导下，独立进行研究工作所取得的成果。除文中已经注明引用或参考的内容外，本论文不含任何其他个人或集体已经发表或撰写过的作品或成果。对本文的研究做出重要贡献的个人和集体，均已在文中以明确方式标注。本人完全意识到本声明的法律结果由本人承担。论文作者签名：日期：年月日学位论文版权协议书本人完全了解关于收集、保存、使用学位论文的规定，即：本校学生在学习期间所完成的学位论文的知识产权归所拥有。有权保留并向国家有关部门或机

2、构送交学位论文的纸本复印件和电子文档拷贝，允许论文被查阅和借阅。可以公布学位论文的全部或部分内容，可以将本学位论文的全部或部分内容提交至各类数据库进行发布和检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。论文作者签名：导师签名：日期：年月日日期：年月日“新一代”交易与核算分离的帐务一致性测试方法研究摘要在“新一代”财务会计组件交易与核算分离的背景下，对财务会计相关组件的功能测试提出了更高的要求。前端应用组件更关注产品设计，而后端财务会计组件负责账务核算，实现交易与核算分离的同时，对账务一致性测试提出更高要求。为了对银行账务相关正确性进行验证，需要联合多应用组件进行跨组件测试。通过

3、对“新一代”财务会计组件业务和架构设计的分析，介绍了其主要账务处理流程，账务一致性的整体测试规划和目标。在此基础之上分别对注重科目核算的会计引擎部分和总分核对的总账部分测试方法进行总结。针对现有测试提出改进方法和实施意见。有效提高测试效率和测试实施中的可控性。在账务一致性基础之上着重对财务会计的中收计量系统进行分析。介绍其基本业务架构、核算范围等。对联合多组件进行的中收计量专项交易核算测试进行总结。并借鉴账务一致性的思路，对经过中收计量的各组件交易进行账务测试案例设计和实施方法分析。确保通过中收计量系统的收费项目在计量周期内入账正确，科目转换和总分核对无误。关键词：交易核算分离财务会计账务一致

4、性中收计量目录1绪论31.1 研究背景31.2 研究意义31.3 研究内容41.4 论文结构42功能测试理论方法52.1 功能测试基础实践总结52.2 新一代财务会计业务架构62.2.1 新一代交易与核算分离实施背景62.2.2 新一代财务会计实施业务方案73新一代交易核算的账务一致性测试分析103.1 账务一致性的整体规划与目标103.2 会计引擎核算测试方法实施总结113.3 总分核对测试方法实施总结133.4 帐务一致性测试提升与改进154账务一致性测试方法在中收计量系统中的应用184.1 中收计量系统分析与核算范围184.2 中收计量专项交易核算测试方法194.3 中收计量专项交易核算

5、测试提升与改进225总结与展望235.1 总结235.2 展望及改进建议241绪论1.1 研究背景在现代银行业务中，交易是对于银行与客户界面合同关系变化的实际有效确认，是双方权利义务关系得以确立的具体实现，其目的在于确立经济事实真实发生，这是产品/交易组件所承载的本质上的功能。核算是按照特定规则对于经济事实（不仅限于银行与客户的合同关系，还包括了其他能够影响银行经济利益的事项）的反映和表达，其目的在于为利益相关者提供有用的信息。在“新一代”核心系统的财务会计架构中，借鉴国际先进的交易与核算体系，进行了交易与核算的分离。在前端银行网点或其他对客渠道进行的业务运营，按照账户、客户的关系，参照产品与

6、核算条件、原子动作与金额类型的映射关系传递到后端的专门负责核算的会计计量组件。通过已有的核算规则和条件进行核算，生成会计分录。在此基础上再进行相关的账务处理，如中间业务计量、税金计提等处理。交易与核算分离是国际金融业的长期实践成果，其中交易定位专注前端客户服务，而会计核算进行后端财务加工。交易与核算分离是财务核算与业务运营相对独立管理运营的基础，有利于在各自的领域向专业化、精细化发展。从核算引擎与应用组件的实施角度来说：建立标准、灵活、可拓展的业务数据交互界面，应用组件与引擎之间相对独立、共同协作，满足财务核算的需求。1.2 研究意义财务会计组件是账务核算的核心，其关系到整个银行运营的核心。交

7、易与核算的关联是整个账务处理过程中的关键。由于组件架构产生了变化，相较于以往的各组件负责各自体系内账务核算的实施，交易与核算分离后的系统架构在测试中需要多个应用组件与财务会计组件协同合作，具测试覆盖面更广，需要的验证点和数据处理节点更多。随着银行业务多样化和国家化发展趋势，应用组件自身设计的交易也越来越多样，其核算类型与科目映射覆盖也更加复杂。针对“新一代”核心系统财务会计组件，由于其本身并不发起交易，因此在应用组装测试中，应充分模拟生产中日切的环境，结合前端应用的交易，对整体的账务核算进行测试。应能够完整并准确的由前段交易组件生成交易流水信息传递到后端的财务会计组件中，并通过财务会计组件进行

8、核算账务处理，生成正确的银行账务信息。明细分录、汇总分录与总分核对的正确性，将影响到基于财会组件核算信息的后端应用组件的统计和分析，如管理会计、监管统计、风险监控等。作为银行业务运营的核心，对交易与分离后的财务会计组件测试进行总结和提升具有重要意义1.3 研究内容文章首先从新一代财务会计系统业务架构的角度出发，对交易与核算分离的系统架构进行了介绍，这也是后续开发和测试的基础。只有结合系统架构特点对财务会计业务进行分析，才能够得到完整并有效的测试方案。通过对“新一代”财务会计架构的介绍，其中包括交易核算分离实施的背景、出发点以及基本设计方案。对整体的“新一代”财务会计组件特点进行了解。在此基础之

9、上分析了交易核算的账务一致性测试需求。并解析了账务一致性的整体规划和目标。针对应用组装阶段进行的会计引擎核算专项测试和总分核对专项测试方法进行了总结。结合现有方法在实施中遇到的困难和问题，对总装测试中财务会计组件的账务一致性进行分析，并给出了提升点和改进意见。最后结合账务一致性的测试思路和财务会计中收计量系统的架构特点，在财务会计中收计量核算系统应用组装测试中，对中收计量交易核算分离后的账务核算进行测试方法分析和提升改进，并给出了相关意见和建议。1.4 论文结构本论文共分为五章。第一章，绪论（即本章）。介绍论文的研究背景、研究意义、研究内容以及论文的组织结构。第二章，首先对一年功能测试处的工作

10、和学习进行了总结。其次介绍了“新一代”财务会计组件业务实施方案。包括交易与核算分离了的背景和涉及思路，架构方案。第三章，交易核算分离后的账务一致性测试。结合上一章的架构方案特点，对整体目标和现有方法进行总结。在此基础上对现有测试方法和实施策略提出提升和改进意见。第四章，在前一章节的基础上，利用账务一致性的思路，针对财务会计中收计量系统的账务核算工功能测试进行分析，并结合系统特点和核算测试方法给出改进意见。第五章，总结与展望2功能测试理论方法1.1 功能测试基础实践总结从2014年7月至今，主要功能测试相关实践基础包括：1、0913版本企业现金收付款参数测试在企业现金项目组参与了0913版本中收

11、付款参数的测试工作。通过这个测试任务，对建行企业现金收付款业务有了更深刻的了解。学习了主要的大额小额和超级网银的支付渠道，掌握我行现金管理的基础知识。在此之上掌握了基本测试技能、QC工具的使用以及测试沟通技巧。入职培训中学习的各方面业务知识在实际应用中得到了加深理解。2、1115版本信息报告应用组装测试在收付款测试任务之后，加入了1115版本的信息报告应用组装测试。首先对信息报告的业务范围，目前系统现状和新的业务需求进行了学习。其次通过案例准备学习了基本的案例编写技巧、功能分析方法。在组内负责案例整理和导入工作，进而熟悉了案例检测等测试工具的使用。在业务知识储备的基础上，学习了P1、P2和TO

12、P渠道相关业务操作，向组内有经验的分行员工学习探讨相关的业务知识。协调测试工作中遇到的各方面问题，协助测试经理才t进信息报告1115版本的测试进程。针对测试过程中的缺陷，及时与开发团队沟通，发现问题及时处理，保障信息报告的应用组装测试按期完成。其中，共进行了一轮应用组装测试，两轮回归测试，涉及迁移和接口的专项测试各一轮。在测试工作中，除了自身的测试任务，也负责组内测试数据的准备工作。3, “新一代”三期贷记卡需求分析与测试方法研究结合正在实施的“新一代”信用卡项目，学习相关的业务知识。掌握整个建模结构，用户流程分析方法以及对应的业务规则。协助合约组进行建模流程visio图修改、业务规则梳理、渠

13、道部署统计等工作。除此之外，与信用卡开发小组学习界面原型图的绘制。根据修改的业务规则，绘制交互界面，形成动态DEMO图，掌握基本的应用设计流程界面交互方法。在此基础之上，参与了需求到测试的落地工作。结合建模结果，提出测试规划，结合建立信用卡合约和维护信用卡合约的三级活动，进行业务规则拆分和测试方法研究讨论。4, “新一代”2.2期财务会计与管理会计功能测试20*年1月起进入上开的财会组，主要负责财务会计中收部分的测试实施和管理工作和厦开的管理会计项目组应用组装测试管理工作。对“新一代”财务会计和管理会计系统分别进行了学习。包括“新一代”核心系统中的交易与核算分离的基本业务架构和实施原理，分别对

14、财务会计上开部分的中收计量、会计引擎和内部帐部分，以及厦开财会的总账部分进行了了解和掌握。除了常规测试实施和管理，另外协同8个组件进行中收计量核算专项测试，推进测试进展，跟踪测试问题，协调收费项目确认，测试实施方法落实和执行问题解决。以确保经过中收计量系统的账务核算正确。在总装测试阶段结合应用组装测试经验参与账务连续性测试方案分析与实施工作。从业务端到端的角度对账务一致性进行了研究。2.2新一代财务会计业务架构2.2.1 新一代交易与核算分离实施背景在现代银行业务中，交易是对于银行与客户界面合同关系变化的实际有效确认，是双方权利义务关系得以确立的具体实现，其目的在于确立经济事实真实发生，这是产

15、品/交易组件所承载的本质上的功能。核算是按照特定规则对于经济事实（不仅限于银行与客户的合同关系，还包括了其他能够影响银行经济利益的事项）的反映和表达，其目的在于为利益相关者提供有用的信息。对于交易和核算两者来说，会计仅仅是对经济事实或交易结果的反映，核算所包含的确认、计量和报告等一系列动作是基于交易所产生的特定经济结果。所以无论在系统实现上二者相隔的时距有多么短，从时间顺序和逻辑顺序上，交易所达成的结果只能是会计核算的前提和输入项，而会计核算本身并不影响交易事实是否达成。例如：产品出售给了客户，双方交易就已完成，只要交易要素被真实记录，不会因记账与否或如何核算、核算结果而影响或改变这一经济事实

16、。通过上述分析可以看出，在银行业务过程中，交易和核算是可以进行分离的。就是使对客服务组件只专注于交易确认和对客服务，而将会计确认和核算处理交由专门组件完成。在前端银行网点或其他对客渠道进行的业务运营，按照账户、客户的关系，参照产品与核算条件、原子动作与金额类型的映射关系传递到后端的专门负责核算的会计计量组件。通过已有的核算规则和条件进行核算，生成会计分录。在此基础上再进行相关的账务处理，如中间业务计量、税金计提等处理。交易与核算分离是国际金融业的长期实践成果，其中交易定位专注前端客户服务，而会计核算进行后端财务加工。相比于传统的交易核算一体化运营，交易核算分离更有利于快速相应产品创新，即会计准

17、则变化不影响前端业务运营，前端产品创新不受后端会计处理的制6约。其次交易核算分离在独立的会计计量模块实现准则要求，确保财务报告各项数据真实准确。在核算结果的基础上进行的管理会计分析，能够保障银行业务的成本分摊、盈利计算和业绩分成计算可靠、正确，为银行的预算和发展提供可靠的业务支持。取消交易端账务处理的功能，有利于核算独立化，能够客观准确的体现交易结果。另外交易核算分离的适应性较强，能够充分适应未来收购和交易系统扩建的要求，为未来真正实现集团一体化管理奠定基础。交易与核算分离还可以满足精细化管理要求，多维度COA在保证核算效率的同时也保证了管理所需信息的可获得性。最后，交易与核算的分离有利于银行

18、内部业务的职责划分，有利于业务运营和会计核算在各自领域向专业化、精细化发展。总的来说交易与核算分离是财务核算与业务运营相对独立管理运营的基础，有利于在各自的领域向专业化、精细化发展。从核算引擎与应用组件的实施角度来说：建立标准、灵活、可拓展的业务数据交互界面，应用组件与引擎之间相对独立、共同协作，满足财务核算的需求。2.2.2 新一代财务会计实施业务方案在“新一代”财务会计交易与核算分离的实施基础是统一的会计引擎，使交易与核算处理相对分离，产品系统更专注客户服务。同时支持多个法人、多套科目、多套会计准则和全球化多时区的会计处理，有利于银行业务的全球性运营发展趋势。参数化的会计规则，由业务人员参

19、数化统一维护，自动产生会计分录。减少了人为因素在交易与核算中产生的错账和误差。具体到核算部分又分为总账和会计引擎两个部分进行实施。如下图所示，在“新一代”各产品组件中交易发生，对应到产品和核算条件生成核算类型，此为分户账部分。同时，各组件的交易流水传送给会计引擎。对应核算类型和余额类型映射到自然科目中。此部分为明细分录，每日再形成汇总分录传递给总账系统。在银行交易系统的日终切换时，各组件也将自己的分户账面余额传送给总账。由总账进行总分核对的工作。下面将对会计引擎和总账分别进行介绍。事件P2PSP”P7/阳PQM易组件联机-'贴房址理（含造乐曷组共文曷坦.土交易组匚|收期育总眠及相关功能

20、，由原开向看_1会计引颦:摩I含清算）P9/H0所错营业税会计信息面11+忌步核对肉诩型监性电词，含计斑永中间业至破入计里新旧科目转检k，LP97P10管理会计组件班计信息管理泰埃集团财务甄告指产负债管理系境风隆管理系妹交易菜”（含总收）ERP经费破产“新一代”的会计引擎主要包括六大功能：分录接入、分录生成、分录汇总、平衡检查、段值变动和自动挂账。核算引擎的原理方程式为：可售产品+原子动作+金额类型=会计分录，例如：个人活期存款+存入+正常本金=贷记个人活期存款本金科目。由于新一代可售产品的颗粒度较粗，无法清晰反映银行核算所需要的信息，经过决策，通过可售产品+产品条件+状态变化等要素映射到核算

21、类型。对应的核算引擎方程式改为：核算类型+原子动作+金额类型=会计分录。可看出核算分录由核算类型、原子动作、金额类型三要素决定，根据会计核算办法与核算业务场景提炼并定义。按照会计核算要求，为每一种具体的业务定义一个核算类型核算类型包括：产品、内部账类型、费用类型、实物类型几大类等。原子动作定义了最小的业务操作单元，体现了业务场景的动态信息。金额类型用于反映某一特定业务含义的余额或发生额金额类型是在某一交易场景下，原子动作操作的金额种类。会计模型包括产品与核算类型映射表、核算类型表和分录规则等，会计引擎通过会计模型，生成明细分录。“新一代”核心系统的总账是指总分类账。是根据总分类科目开设账户，以

22、COA段值为载体，用来登记全部经济业务，进行总分类核算，提供总括核算资料的分类账簿。总分类账所提供的核算资料，是编制会计报表的主要依据。具关键功能是支持多级机构财务报表生成，支持灵活的组织架构变更，支持多币种、多会计准则套帐处理，支持总账数据回溯，账表联查，支持附加期间的调整分录记账功能等。总账优化的目的是基于瘦科目体系，遵循准则、准确核算、客观反映，构建单一视图的总账数据体系，自动化生成集团层面的总账报表，提升总账数据应用的能力与效果，更好地支持会计数据质量控制与业务决策，总账全流程自动处理；从交易到账务无人工干预，由总行生成所有机构报表，满足及时性要求；明确总账数据对业务和管理数据的统驭功

23、能，强化数据一致性；总行、境内分行、海外分行及子公司均使用集团统一COA,以便自动生成汇总报表；便捷地从总账数据回溯到交易数据等，从而形成集团单一视图的总账信息。要成功实现单一总账视图，有多方面的关键成功因素，归纳起来应从三个方面来响应：建立准确、高效、客观的核算体系；建立总账到财务报告的自动生成机制；建立总账数据用于集团服务决策的机制。为了解决当前的问题和缩小与先进性实践的差异，需要建立集团层面单一、权威的总账视图（“新一代”核心系统、总账系统和报表系统使用新COA原CCBS采用建立境内核算码与新COA的映射，未来逐步替代）；实现总账与财务报告完全对接，消除总账与报告的科目口径差异，支持期后

24、调整的入账处理，增加包含期后调整的报表展示功能；集团合并报表编制实现自动化，海外分行和子公司自动传输账务信息，自动合并抵销，生成集团合并财务报表；实现准实时总账应用和快速高效的总账数据回溯四个流程能力。除了会计引擎和总帐部分，在“新一代”核心系统中对中收计量和内部帐也进行了重新规划涉及。这两者也是财务会计系统的重要组成部分。中间业务是指不构成商业银行表内资产、表内负债，形成银行非利息收入的业务。中间业务收入包括支付结算类、银行卡类、代理类、担保类、承诺类、交易类、基金托管类、咨询顾问类和其他类的银行收入。权责发生制要求企业按照实际会计期间进行收入/成本确认，规范企业会计确认、计量和报告行为，保

25、证会计信息质量。会计确认的过程不再只是原始对客交易的直接、单纯反映，在交易过程之外，会计核算还需要会计计量的辅助过程。参考国际上各银行的系统实现，均有单独的、专业化的会计计量系统，与产品和交易系统分离，在会计核算的范畴内完成会计计量工作。在交易核算分离的整体架构下，建立中间业务合约的管理，为计量提供必要的输入信息。确定中间业务收入计量的业务范围，合理的计量种类。“新一代”中收计量系统的详细业务范围和计量实施方法在第四章中进行系统介绍。“新一代”核心系统根据减少内部账种类和数量，提高管理效率，降低风险的业务要求，对内部帐系统也进行了改造。通过有效的措施减少内部账的种类和数量，同时能够明确每种内部

26、账户的用途和开立原则。目前现状是内部账总数为600多万个，账户的维护和监控比较困难，并产生了相关的海量会计分录。挂销类账明细信息不足，存在销账资料混用，乱用情况，造成资金风险。由于账户数量巨大且没有统一的自动化监控，对账户使用的合理性和合法性都埋下隐患。因此为了提高内部帐管理要求，包括从内部账管理系统的开户审批、销户管理、内部账户交易权限管理，完善销账资料，由交易驱动会计引擎的分录产生，避免对内部账直接记手工帐等几个方面进行了优化。严格控制权限，设定交易操作权限的管控规则，支持柜员内部账类型权限、交易权限的参数设置，通过交易机构的检查、柜员和账户权限/交易权限的检查，确定柜员是否能进行操作。完

27、善销账式管理方式，提高销账资料数据质量，加强内部账预警控制。通过上文的分析可以看出，在“新一代”核心系统的财务会计中，对交易与核算进行了明确的职责分工，前端组件着重于交易实施，财务会计组件着重账务核算，与以往的交易核算一体结构相比，这种结构下的开发测试需要更大的协同成本投入。在财务会计的账务核算中需要协同所有涉及账务的前端组件进行统一的测试，对测试计划和方案涉及有更高的一致性要求。交易核算的路径更长，涉及组件和验证点更多，数据要求更高。在下一章中将对“新一代”核心系统的账务一致性测试进行分析介绍和改进。3新一代交易核算的账务一致性测试分析在本章中将对“新一代”核心系统中的交易核算分离后的账务一

28、致性测试进行分析，对账务核算和总分核对的测试方法进行总结、提升。3.1 账务一致性的整体规划与目标“新一代”核心系统中应用组件与财务会计相关组件进行交易与核算分离后一致性测试的基础是数据迁移。因为从整体“新一代”核心系统的客户服务层面出发，要求系统切换前后，账务核算、营运管理、对外报告等管理分析类功能和数据视图，在系统切换前后没有大的波动。在时间维度上，当业务数据的生命周期贯穿系统切换过程时，数据在切换前后的不同时间点上的变化仍然保持连续和平滑，而没有发生异常的突变。例如：科目的当期余额=上期余额+当期发生额；本期数据=上期数据+本期发生数；因此在整个账务一致性的整体规划中，首先要以数据迁移为

29、基础。下图对CCBSW“新一代”核心系统中财务会计部分的迁移计划映射进行了分析。分别给出了迁移过程中数据来源于转换后的对应部分。10CCBS的内部帐，总账等系统的数据迁移是后续对“新一代”核心系统应用组件接入总账和引擎进行账务核算测试的前提。首先要在数据前一种保证迁移过程的平滑，数据准确映射无误。后续在此基础上进行的应用组件增量交易才有可测性。此部分数据迁移的核算转换测试要求对映射覆盖规则、变化量、新老科目一致和前后总账一致等问题进行测试。在此基础之上，进行余额连续性检查、新一代分户账和总账核对检查、新一代内部账户取消转科目账的检查、新旧科目结转结果检查。以确保CCB蒐账在迁移过程中能够按照新

30、的COA段值正确的与ERP总账进行映射，产生初始化的总账信息。通过第二章“新一代”核心系统财务会计的业务架构介绍，依据“新一代”核心系统财务会计的基本设计思路和架构，结合交易与核算分离的特点，财务会计账务的测试可以从两个主要的角度出发。首先前端组件的交易流水结合核算参数表按照分录规则能够准确映射到对应的自然科目中，生成正确的分录，这是交易与核算账务正确的前提。其次在分录和流水分别传递到总账后进行总分核对，交易与核算的结果平衡，即确保每一笔交易在金额和自然科目上都能够正确的在总账和引擎的分录中体现。这两个方面的账务正确性是后续期后调整、管理会计分析等功能测试的基础，也是银行账务交易与核算的核心。

31、在下面两节中将分别对会计引擎核算和总分核对的测试方法进行总结。3.2 会计引擎核算测试方法实施总结会计引擎的核算测试从产品组件产生的交易流水到对应的结合核算参数表按照分录规则能够生成正确的明细分录和汇总分录。此部分测试的工作流程如下图所示。其中由于核算条件的复杂性，因此要求在测试案例设计和实施准备中严11格控制，下面也将针对这两点进行重点说明核算类型+余额类型一一自然科目一、测试分析：根据交易与核算分离的业务架构和会计引擎的核算原理，测试组件范围包括各应用组件和会计引擎（上开-财务会计）。具体应从以下几个角度进行分析调研与准备：1,各应用组件的产品与核算类型映射表分析：若应用组件需要接入核算引

32、擎，其在逻辑上必然存在“对象”、“事件”两个概念，即围绕“对象”所发生的“事件”，调用核算引擎服务接口，由核算引擎生成对应会计分录。“对象”可为可售产品、内部账、收费项目、实物、核算费用等等，财会业务统称为“核算类型”。各应用组件需将所梳理可售产品、内部账、收费项目、实物、核算费用与“核算类型”的映射关系，在应用组件内部落地为参数数据实体，并发布给后端系统（核算引擎、总账、管理会计等）使用。需要应用组件提供三个参数的副本：参数表目的映射条件定义表在核算引擎服务接口、产品与核算类型映射参数中，均存在映射条件。从统一设计的原则出发，应该假设这些条件是未知的，可配置的。需要应用组件在本定义表中，说明

33、每个映射条件的技术特征，以支持后台解析映射条件数据。核算类型映射主表核算类型映射主表、子表，存储了产品至核算类型的一条条映射关系。因为在一条映射关系中，可能存在多个可配置化的映射条件，故需要应用组件将映射关系拆分为主表、子表处理核算类型映射心其次，各应用组件应确认映射条件定义表，应用组件需自身保证：其唯一性和互斥性，即总账来源编号+多实体标识+映射参数版本号+映射条彳编号+启用日期+截至日期的唯一；并且对于同一总账来源编号+多实体标识+映射参数版本号+12映射条件编号，时间拉链不可重叠，不可间隔。最后各组件应保证核算映射主表和子表的唯一性，即主表物理主键编号的唯一，和子表物理主键编号的唯一。2

34、,财务会计组件与应用组件确定产品与核算类型映射参数财会业务会与各应用组件沟通各应用组件的产品范围，为各应用组件分配“核算类型”，各应用组件需要将自身所承接的可售产品、内部账、收费项目、实物、核算费用映射向“核算类型”。其中产品与核算类型映射参数，是各组件发布到P9的文件及P9装载的表。二.测试案例设计1,验证核算场景要求应用组件对于每一条产品与核算类型映射关系，编写相关案例（一条映射关系，应用组件可能有多处逻辑会使用，案例应覆盖所有逻辑）。在测试验证中必须写明：可售产品+条件+核算类型；对于财务会计所提供的核算类型+原子动作+金额类型，编写相关案例（一个业务场景，应用组件可能有多处逻辑会使用，

35、案例应覆盖所有逻辑）。在测试验证中必须写明：核算类型+业务事件+金额类型。2,验证COA值变更对于每一个核算类型，就其可能发生的COA段值变更场景（机构变更、核算类型变更、客户类型变更等，具体见引擎指导手册），编写相关案例。每一种COA段值变更，可能有多种场景，例如机构变更会有部分机构撤并、账户转移两种场景，核算类型变更可能会对应各个产品条件的变更场景，且有从核算类型A变更为B、变更为C等不同场景，案例应覆盖所有场景在测试验证中必须写明“变更”和具体变更内容，如：变更，核算类型A变更为核算类型B3,验证数据同步场景（1）编写一个对P9发布产品与核算类型映射参数的案例（2）编写一个对会计引擎传输

36、会计日期变更信号的案例三、测试实施测试实施主要有应用组件每日传递相关账务至引擎进行核算科目映射和入账处理。过程中由引擎和组件共同对账务信息进行检查和核对。针对映射失败的科目，逐一进行检查，确保组件与会计引擎的核算信息无误。3.3 总分核对测试方法实施总结总分核对是总账系统的科目余额和交易系统归属该科目的账户/合约/实物13的余额核对。具体包括总账和客户账户/内部账户的核对、总账和中间业务合约的核对、总账和实物的核对。总分核对要求从各交易系统/计量系统/实物管理系统、会计引擎、总账三个层次抽取数据进行总分核对。交易系统提供分户账户（包括客户账户和内部账户）余额；计量系统提供中间业务合约的计量金额

37、；实物管理系统提供实物的存量（余额）；会计引擎提供产品与科目的对应关系；总账提供科目余额。其基本流程如下图所示：三易i懂*检查会计信息质量的种类主要包括：总账科目余额的合理性检查（如检查余额必须在借方且不得为红字的科目、检查余额必须为零的科目等）；总账科目余额间勾稽关系的合理性检查。在总分核对中比较重要的是如果出现不平的情况，差错的过程控制和排查错误的步骤，其查错流程如下图所示：如果总分存在不平，首先确定是否是由于COA段值校验不通过或交易生成分录失败产生的总分不平。判断各个流程中数据是否出现错误、遗漏。判断数据同步（文件传输）是否出现错误。逐步排查可能出错的组件，找到总分不平的原因并进行修改

38、。其查错过程具体分析如下图所示：14产品拒件会泗攀即早存在i即口X?伯t:登不通过的脸，展呀"M国手曲国:“日图至一面曲a生9rTTH母因jscmr握w初U提供奖喻T,甫于HL建国；总生桢安京皿时产生息云不平崎国是T工我土型，目FIH的*fix匕日士1代bwei1H-=tB=3.4 帐务一致性测试提升与改进在上两节中分别对会计引擎核算科目准确和总分核对的测试方法进行了总结，其中核算科目正确仅在组件和引擎中进行，总分核对只能对整体账务余额部分进行核对，总分核对并不能确定在账务中的具体科目的核算是正确的。而针对具体交易通过引擎到达总账后的核算科目缺少测试验证。因此需要在海量的核算科目中挑

39、选重要的核算科目进行从应用组件到会计引擎到总账的全流程验证。针对测试执行结果的验证也不是粗略看科目总分是否平衡，而是通过检查应用组件分户账、会计引擎明细分录、总账科目一条线上记账、入账的“准确”性，整体视角和分段视角结合的检查方式。一，测试分析首先针对与财务会计组件直接产生核算交易的应用组件进行梳理。共涉及如下组件与开发中心，如下表。其次针对以下应用组件对核算表进行确认，确认各组件对应的核算参数表，确定各自然科目与业务事件和余额类型的对应关系。在此基础上才能继续对重点核算科目进行分析和测试案例的编写。15开发中心应用名称组件名称北开企业现金企业现金管理上开财务会计（上开）中收计量内部帐上开对公

40、信贷与存款存款贷款资金监管现金管理上开支付结算支付结算P6支付结算P8上开产品支持基础客户结算上开金融市场二期对客资金交易厦开对公信贷业务流程管理保理担保管理成开托管托管武数代收代付代收代付二期（银医银校社保）武数代收代付代收代付一期（公共事业代缴费）武数代理财政代理财政,测试案例设计选择重点核算自然科目：以核算参数表为基础，结合业务场景，挑选业务上重要并且触发率高的核算科目作为重点测试的科目。通过核算类型和科目进行倒推，选取触发该科目金额变化的具体交易。以现金管理为例，选取自然科目现金管理类集团式委托贷款参照核算科目表，对应此科目的核算类型为集团式委托贷款”，余额类型为委托贷款本金核算类型名

41、称核算科目余额类型1余额类型编号余额类型名称自然科目编号自然科目名称集团式委托贷款Y1104委托贷款本金129506现金管理类集团式委托贷款在此基础之上结合核算三维表，筛选出该核算类型和余额类型对应的业务事件为发放”和归还”。即可明确对应科目的业务场景为发放和归还集团式委托贷款，金额类型为正常本金，触发自然科目现金管理类集团式委托贷款的借贷方向金额变化。16核算类型名称业务事件编号业务事件名称金额类型编号金额类型名称分录信息余额类型1借贷标志借贷收付余额类型编号余额类型名称集团式委托贷款D014发放J101正常本金DrY1104委托贷款本金D020归还集团委贷J101正常本金CrY1104委托

42、贷款本金通过对业务场景各条件的明确，确定前端交易后设计交易线与账务核算协同测试案例。要求为：案例概述：需要写满发起交易概述操作步骤，第一步：应用发起交易的操作步骤，第二步：应用组件检查分户账记账的步骤，第三步：应用组件检查会计分录相关字段的步骤，第四步：财务会计检查会计分录相关字段的步骤，第五步：厦开总账入账、日结后科目记账准确性检查的步骤。*测试案例关联的测试范围类型*测试案例编号*测试案例名称*测试概述*操作步骤序号*步骤描述*测试数据需求*预期结果功能SUCUL05741AH-001129506现金管理类集团式委托贷款|243106现金管理类集团式委托贷款基金-执行内部委贷一自动任务-0

43、01验证：系统根据汇总的整个池的委贷金额，与上一日的贷出金额进行轧差，比上一日的贷出金额增加，分别记入在合约委托贷款户和委托贷款基金户中，核实入账机构是否准确，入账金额11=1何友也多弟非同一法八的资金归集/下拨（委贷）会计日期：账务机构：资金归集/下拨成功2应用组件检查分户账入账金额是否正确父易机构：交易金额：88.88可售产品：账簿现金池核算类型：集团式委托贷款业务事件：发放金额类型：正常本金会计科目：129506现金管理类集团式委托贷款、243106现金管理类集团式委托贷款基金入账金额正确3应用组件检查会计分录中相关字段是否正确，主要检查：会计日期、交易机构编号、账户机构编号、币种代码、

44、发生额、客户类型代码、核算类型编号、原子动作编号、客户账号、客户编号会计分录相关字段值正确功能SUCUL05741AH-002129506现金管理类集团式委托贷款|243106现金管理类集团式委托贷款基金-执行内部委贷一自动任务-002验证：会计分录相关字段是否正确1财务会计检查会计分录相关字段是否正确，主要检查：引擎变式编号、自然科目编号、核算类型组编号、核算服务类别代码、科目发生方向代码会计日期：账务机构：交易机构：交易金额：88.88可售产品：账簿现金池核算类型：集团式委托贷款业务事件：发放金额类型：正常本金会计科目：129506现金管理类集团式委托贷款、243106现金管理类集团式委托

45、贷款基金分录字段正确功能SUCUL05741AH-003129506现金管理类集团式委托贷款|243106现金管理类集团式委托贷款基金-执行内部委贷一自动任务-003验证：财务会计科目记账的准确性1日终后，财务会计厦开（总账）入账、日结、总分核对，由财会会计厦开出具COAi度的科目余额情况，根据前端发生交易，检查科目记账的准确性会计日期：账务机构：交易机构：交易金额：88.88可售产品：账簿现金池核算类型：集团式委托贷款业务事件：发放金额类型：正常本金会计科目：129506现金管理类集团式委托贷款、243106现金管理类集团式委托贷款基金科目记账正确，总分平衡,测试实施计划其中对交易金额和入账

46、日期等进行严格的控制，测试条件允许的情况下采取独立的交易核算机构进行科目测试。选取的科目和对应业务场景不应过多，应用组件应有重点的选取2-4个科目，对应每个科目选择一种业务场景，并且在金额上做特殊金额处理。如选取金额6.66,9999.99等易区分的金额。测试执行中严17格控制每一种业务场景对应的交易仅触发1笔或固定的笔数，方便在会计引擎和总账中进行查找核对。通过以上的设置来查看每一笔交易在会计引擎和总账中对应的入账正确性。由应用组件执行案例1,由财会组件测试人员执行测试案例2、3,参照入账日期、机构、金额等信息进行入账检查。4账务一致性测试方法在中收计量系统中的应用结合会计核算中对测试案例评

47、审、测试准备和总分核对中对查错控制的经验。在中间业务收入计量核算的测试专项中，重点对测试案例评审和测试实施方法等进行多角度分析。确保经过财务会计中收计量系统的账务计量正确，与各应用组件和客户结算等公共组件核算信息一致。下文将首先对中收计量系统和其核算范围进行介绍，再针对财务会计中收计量组件的特点对期交易核算分离后，多组件系统测试的测试需求调研准备、案例准备、测试实施方法等方面进行分析。最后针对应用组装的中收计量测试实施方案进行提升和改进。4.1 中收计量系统分析与核算范围为确保会计信息的可靠性，符合分期确认的收入应根据权责发生制原则，合理运用会计估计和判断，进行正确的会计计量。现状中存在需要计

48、量的中间业务收入依赖人工处理，以及系统处理的中间业务收入计量规则不统一等问题，为改善核算质量和提高系统自动处理能力，需要对照中间业务收费清单对所有收费项目逐项分析，符合计量条件的收费项目，统一纳入计量管理。中间业务后续计量的目标是除部分金额较小且业务量巨大的对私业务外，对其他对公、对私业务的收费，都实现在最小计量周期内的逐笔收费精确计量。对于部分金额较小且业务量巨大的对私业务，实现逐笔计算，按责任中心、收费项目、币种、客户等汇总记账的批量计量。按照逐户/合约进行计量；部分小额、大量的对私业务逐户计算批量计量。中间业务收入计量的核算规则：范围业务核算规则交易定义借贷对客业务收费对客实际收费资金来

49、源科目递延收益退费对客实际退费递延收益资金去向科目18计量预提产品或服务已提供，款项尚未收到，银行提前确认已实现的收入应计收入中间业务收入摊销款项收到后，分期确认收入递延收益中间业务收入冲销应计款项收到时，将预提的收入确认递延收益应计收入补回应计退回款项时，将确认的收入补回应计应计收入递延收益手工调整冲减收入合约结束时，预提收入大于实际收入中间业务收入应计收入补足收入合约结束时，预提收入小于实际收入递延收益中间业务收入计量重算报告日后冲销摊销由计量重算产生的自动冲销交易报告日后以前年度损益调整应计收入报告日后冲销预提报告日后以前年度损益调整递延收益冲销预提中间业务收入应计收入冲销摊销中间业务收

50、入递延收益根据以上“新一代”财务会计组件交易核算分离的特点，由于中收计量属于财会组件，自身不能发起交易，因此在应用组装测试中需要联合产生中收计量账务的应用组件进行测试。针对财务会计部发布的中间业务收费清单，结合账务核算方式进行分析。需要确定收费项目、收费项目入账方式、涉及的核算场景等信息。在此基础之上进行测试案例设计和实施。下文将对具体每个流程进行分析。4.2 中收计量专项交易核算测试方法在中收计量账务核算中结合上一节的核算范围分析，重点是对纳入中收计量系统的收费项目在前端组件进行费用收取或退费交易后，能够通过批处理或联机交易，在中收计量组件中生成正确的账务核算信息。其整体规划如下：19测试分

51、析测试案例设计测试执行审核执行结果测试完成1、确定涉及中收计量系统的前端应用组件2、确定产品与核算映射三维表3、确定各应用组件涉及的收费项目、产品目录4、确定收费项目产品组合对应的业务场景前端应用组件编写测试案例中收计量项目组负责案例评审若存在问题则,双方项目组进.行检查并修改前端应用组件执行测试案例并反馈执行结果中收计量项目组针对反馈执行结果的业务要素进行账务审核测试案例均通过中收项目组审核，账务核算正确下文将着重对每一个环节进行详细的分析设计。一、测试分析根据会计核算专项的实施经验，在各项目组进行测试案例编写和测试计划之前应首选对测试范围进行调研。对于中收计量专项首先应确定应用组装测试涉及

52、的应用组件范围和纳入中收计量核算的收费项目对应产品，及每个收费项目涉及的不同业务场景。以上均是从架构和业务角度进行分析调研。按照核算规则并不是所有银行的中间业务收入都需要按照权责发生制进行递延或计提处理。所以应根据客户结算发布的收费项目基线确定进行中收计量的收费项目和对应产品。第二章对“新一代”核心系统的财务会计实施方案进行了介绍，其中生成自然科目与收费项目和对应可售产品相关客户类型等因素有关。为了能够完全覆盖涉及账务变化的科目，应对照核算表和收费项目基线，对收费项目可售产品组合进行遍历。其次在覆盖了自然科目之后，应对收费项目可能出现的业务场景进行分析。在业务上，有的收费项目可能只涉及收费场景

53、，不涉及退费场景。在收费中又涉及到是通过建立合约登记簿来进行收费还是直接联机缴费。而有的收费项目则需要收费、退费、冲正和变更场景。其中变更场景又包括营业机构、收费项目、合约日期等要素。应对每个收费项目+可售产品进行逐一分析。二、测试案例设计与评审测试案例设计由各交易发起的应用组件进行编写，之后由财务会计中收计量业务人员进行案例评审。其中结合中收计量核算范围与账务变化要求，要求案例编写参照引擎核算测试，首先应设计案例产生的交易能够满足所有核算科目的覆盖。其次针对变更合约的场景内容，应分别针对能够影响账务核算的条件逐一设20计案例，每次仅变化一个业务要素。在此基础之上再设计同时所有要素变更的测试案

54、例。在测试验证点中明确收费项目、可售产品、业务场景等要素。通过中收计量相关评审后的项目组测试案例才通过QC进行管理并开始测试执行。在案例模板中，主要项目均参照主体测试案例的测试方法，其中主要在测试名称和测试概述中，为方便明确各关键字段，标红的部分要求各应用组件均应重点填写。测试案例名称明确业务场景和收费项目，在测试概述中明确收费项目，可售产品和业务场景。以上要素均为财务会计中收项目组的评审依据。中收组件应参照测试分析对应用组件提交的测试案例进行评审，是否测试案例完全能够覆盖收费项目、可售产品与场景的组合。通过中收项目组评审后的案例才进入QC管理并开始执行测试。*测试案例名称*测试概述*操作步骤

55、序号*步骤描述中间业务合约建立-收费项目代码验证：中间业务合约建立的正确性收费项目代码：*可售产品：*业务场景：建立合约1对收费项目XXI立中间业务合约2交易成功中间业务合约维护-收入递延编号验证：中间业务合约金额变更的正确性收费项目代码：*可售产品：*业务场景：合约金额变更1变更合约X海额2交易成功中间业务合约交费-收入递延编号验证：中间业务合约交费金额的正确性收费项目代码：*可售产品：*业务场景：合约交费1合约缴费X瀚额2交易成功中间业务合约退费-收入递延编号验证：中间业务合约退费金额的正确性收费项目代码：*可售产品：*业务场景：合约退费1合约退费X瀚额2交易成功中间业务合约交费-收费项目代码（无合约）验证：收费项目交费金额的正确性收费项目代码：*可售产品：*业务场景：交费（无合约）1针对收费项目陶费X）金额2交易成功中间业务合约退费-收费项目代码（无合约）验证：收费项目退费金额的正确性收费项目代码：*可售产品：*业务场景：退费（无合约）1针对收费项目腿费XXfe额2交易成功三、测试执行与执行结果审核在执行过程中由各项目组分别发起相关的中间业务收入的交易。在执行一个案例后，要在反馈表中记录该交易的重要业务要素，最后反馈给中收项目组业务人员在中收计量账务核算中进行审核。是否前端的每一笔交易，能够对应正确的交易流水号在中