中华人民共和国最高人民法院 民 事 判 决 书 （2019）最高法知民终712号 上诉人（原审原告）：联合出版（集团）有限公司。住所地：香港特别行政区北角英皇道**联合出版大厦**。 授权代表：傅伟中，该公司董事长。 委托诉讼代理人：赵立辉，北京植德律师事务所律师。 被上诉人（原审被告）：北京胜龙科技股份有限公司。住所地：。住所地：北京市海淀区西三环北路**院**楼**308v> 法定代表人：施智华，该公司董事长兼总经理。 委托诉讼代理人：康圣基，北京市隆安律师事务所律师。 上诉人联合出版（集团）有限公司（以下简称联合出版公司）因与被上诉人北京胜龙科技股份有限公司（以下简称胜龙公司）计算机软件开发合同纠纷一案，不服北京知识产权法院于2019年8月15日作出的（2016）京73民初870号民事判决，向本院提起上诉。本院于2019年11月7日立案后，依法组成合议庭，于2019年12月11日公开开庭审理了本案，上诉人联合出版公司的委托诉讼代理人赵立辉、被上诉人胜龙公司的法定代表人施智华及其委托诉讼代理人康圣基到庭参加诉讼。本案现已审理终结。 联合出版公司上诉请求：依法撤销原审判决的第二项，改判胜龙公司返还联合出版公司研究开发费用266400元并赔偿损失98189.5元。事实和理由：原审判决认定事实和适用法律存在错误，联合出版公司在合同履行过程中不存在任何主观过错及违约行为，不应承担相应的法律后果；胜龙公司的违约行为构成根本违约，导致了联合出版公司与其签订合同的目的不能实现；因胜龙公司构成根本违约，联合出版公司有权解除合同，合同解除后，胜龙公司应当返还研究开发费用并赔偿损失。具体而言，（一）联合出版公司不存在任何主观过错及违约行为。原审判决认定“联合出版公司与胜龙公司均存在用户需求调研不细致、系统开发难度评估不当、涉案系统出现问题双方沟通不顺畅等诸多问题，而联合出版公司对系统上线修改问题所产生的风险缺乏足够认识，最终导致双方无法继续履行涉案合同，主观上均存在过错，双方理应承担各自产生的经济损失及相应的法律后果”。但是，联合出版公司认为，1.联合出版公司没有对用户需求进行实质性变更。首先，涉案软件是在原有软件系统上的定制开发，应当同时满足合同附件《胜龙科技资产管理信息系统解决方案》和《需求确认书6.5》的要求；其次，在合同履行过程中，联合出版公司提出的包括固定资产折旧等修改意见均在涉案合同及《需求确认书6.5》约定的范围内，并不是对用户需求提出的变更请求，而是要求胜龙公司完成合同约定的义务。并且，联合出版公司最终确认的《固定资产管理系统行政验收标准》与《需求确认书6.5》内容基本一致，根据合同实际履行情况及双方沟通情况，联合出版公司还主动简化了《需求确认书6.5》中的部分流程，删除了一些审批环节，尽可能地降低了胜龙公司的工作量和工作难度，为双方顺利开展合作创造了条件。2.联合出版公司不应当承担用户需求调研、系统开发难度评估等义务。联合出版公司并非软件开发单位，不知悉也不应当知悉软件开发的工作流程及目的，不可能从事用户需求调研、系统难度开发评估等事宜，也不应承担相应义务。联合出版公司仅需配合胜龙公司履行相应义务，而在合同履行过程中，联合出版公司积极响应并配合了胜龙公司的调研工作，胜龙公司应当根据调研结果自行评估系统开发难度。3.2014年9月30日之后，涉案合同长期停滞不前系因胜龙公司频繁的人员变动等单方面原因导致的，联合出版公司没有任何过错。（二）胜龙公司构成根本违约。原审判决认定“上述后果并非胜龙公司单方行为所致，并不能据此认定胜龙公司构成根本性违约”，但联合出版公司认为，胜龙公司在履行涉案合同的过程中存在以下严重违约行为：1.向联合出版公司交付合同标的软件系统的时间远远晚于涉案合同约定的期限；2.在涉案合同约定的验收前试运行及正式运行阶段，抽调人手去其他项目，致使本项目进度严重落后；3.交付的“固定资产管理系统”不符合涉案合同及附件的约定，经过长时间的修改后仍无法达到合同约定的验收标准，致使该系统无法投入实际使用，合同目的无法实现；4.胜龙公司的内部人事调动，持续不履行合同义务；5.胜龙公司不履行系统测试义务，致使双方不得不就软件中的低级错误反复沟通，严重影响合同履行效率；6.胜龙公司没有能力履行合同义务，也未能采取任何有效措施进行补救，致使合同履行不能。因胜龙公司的上述严重违约行为，导致联合出版公司关于获得一套能够实际投入使用的资产管理系统的合同目的不能实现，构成根本违约。（三）胜龙公司应当返还研究开发费并赔偿损失。原审判决认定“虽然联合出版公司向胜龙公司支付了首笔合同款266400元，但是，自2011年10月15日至2016年3月8日鲁晓向施智华等人发送的最后一封邮件时间，历时四年多时间，胜龙公司为涉案系统的开发付出了相应的人力、物力和财务，并于2013年12月前将涉案系统上线测试。尽管涉案系统未达到双方的预期合同目的，但双方对此均应承担相应的法律责任。因此，联合出版公司的上述主张，缺乏事实和法律依据，不予支持”，但是，联合出版公司认为，1.胜龙公司应当返还研究开发费并赔偿损失。根据《中华人民共和国合同法》第九十七条的规定，合同解除后，应当恢复至未履行的状态，且当事人有权要求损害赔偿。本案中，因胜龙公司的根本违约行为已经满足法定解除条件，联合出版公司有权解除合同，合同解除后不影响违约责任的承担。联合出版公司在涉案合同项下应履行的义务系金钱给付义务，该履行方式能够被完全恢复原状，因此胜龙公司应当返还联合出版公司已支付的第一期研究开发费266400元，以恢复原状。另外，联合出版公司还因胜龙公司的严重违约行为遭受经济损失98189.5元，胜龙公司亦应当承担上述损害赔偿责任。2.胜龙公司未举证证明其人力、物力损失，应当承担举证不能的不利法律后果。原审法院未对胜龙公司的实际履行成本进行查明，亦未认定该履行成本可以与研究开发费和经济损失互相抵消，就驳回了联合出版公司的相关诉讼请求，系事实认定与法律适用错误。3.原审判决认定胜龙公司违约，却未要求其承担违约责任，存在严重错误。 胜龙公司辩称：原审判决认定事实清楚，适用法律正确，请求法院依法驳回联合出版公司的上诉请求。事实和理由：（一）胜龙公司已开发了符合合同约定的软件产品，实现了双方在签署合同时约定的全部软件产品性能指标，不存在任何违约情形，故联合出版公司应当支付相应的合同款项，其要求解除合同并退还费用的诉求没有事实和法律依据。1.胜龙公司认为，涉案合同中对于软件开发技术标准及要求已有相关约定，双方均应按照合同约定来执行，而联合出版公司却以其自身要求并不断变更要求作为标准，并因此极大增加了胜龙公司的工作量和工作时间，给胜龙公司造成了重大经济成本支出；2.双方签约时确定的所开发软件的性能指标依据的是涉案合同附件及《用户需求确认书（版本号：1.0）》，然而在原审庭审中，联合出版公司却主张其依据的是《用户需求确认书（版本号：6.5）》，事实上，在胜龙公司开发完成后，系因联合出版公司下属各部门、各分、子公司不断提出新需求，并要求胜龙公司不断进行修改，才导致相应的用户需求确认书的版本由《用户需求确认书（版本号：1.0）》逐渐变更为《用户需求确认书（版本号：6.5）》，相应地，软件开发工期也因此一直被拖延；3.关于二次新需求的开发及据此签署《补充协议》事宜，双方已于2015年9月进行过沟通，胜龙公司已将相关《补充协议》及新需求确认函发给了联合出版公司，但联合出版公司一直未予签署，才导致在原合同范围之外的二次新需求开发工作未能进行。因此，胜龙公司就《技术开发合同》约定的义务已经履行完毕，不同意解除涉案合同。（二）不同意联合出版公司关于返还26.64万元的研究开发费用及赔偿损失98189.5元的上诉主张。1.涉案软件系在胜龙公司原有的一套成熟的固定资产管理系统软件上做的一项定向开发，胜龙公司已为联合出版公司开发出了符合合同要求的软件产品，其有权依据双方签署的合同收取相应的合同款项；2.按照合同约定，项目施工计划分为四个阶段，胜龙公司已经完成到了第三个阶段，相应的付款进度也应是由联合出版公司将合同约定的50%款项即26.64万元支付完毕，但联合出版公司却拒不履行验收程序，延迟支付合同约定的后续款项；3.合同约定的开发周期为2011年10月15日至2013年10月14日，但截止2015年底，双方仍就涉案合同一直在沟通，原因在于虽然胜龙公司已按原合同约定的软件功能开发安装完毕并进行了软件培训，但联合出版公司却不断提出新需求，并由于联合出版公司内部的结构、人员协调等原因，还导致了在后续的培训过程中，联合出版公司下属的工作人员仍对软件系统不断地增加新需求，且上述新需求均不属于原合同约定的范围之内。此外，联合出版公司工作人员对于问题反馈的拖沓也导致了开发工作的滞后；4.2015年7月18日，胜龙公司李**程向联合出版公司鲁晓发送《香港联合出版社二次需求确认函2015-7-13》，明确要求其尽快确认二次新需求的相关内容；同年8月26日，双方召开会议对需求确认函再次进行调整；同年9月10日，胜龙公司李**程向联合出版公司鲁晓发函，要求最迟在9月14日前确认需求并明确指出若迟延盖章将导致整个新功能开发严重滞后；同年10月18日，胜龙公司崔波向联合出版公司发送《7月13日沟通后的需求及解决方案初稿》、《补充协议》、双方确认的需求确认函及实施计划，要求联合出版公司查收并尽快签署，但截至目前，联合出版公司仍未就二次需求签署相应的补充协议；5.在双方沟通过的《补充协议》中，明确将合同履行期限从2013年10月14日延长至2016年12月31日，并将验收计划进行变更，提出了二次需求和二次施工计划。此外，在双方拟签署的《补充协议》中，双方对于原来的50%合同款项的付款金额及开发工作均无异议，仅将后续的50%合同款项转用于支付新的二次开发费用，但联合出版公司拒不签署上述《补充协议》，也拒不确认二次新需求的开发事宜，才导致软件的新需求开发工作无法开展；6.差旅费、购买硬件设备的款项、律师费等费用应由联合出版公司自理，联合出版公司要求胜龙公司支付上述费用没有法律规定也无合同约定作为依据。 联合出版公司向原审法院提起诉讼，原审法院于2016年9月7日立案受理，联合出版公司起诉请求判令：1.解除双方签订的《技术开发合同》；2.胜龙公司返还266400元研究开发费并赔偿损失98189.5元。事实和理由：2011年10月15日，联合出版公司与胜龙公司签订《技术开发合同》（即涉案合同），委托胜龙公司开发一套可在集团与下属二级、三级公司及下属若干公司使用的“联合出版（集团）有限公司固定资产管理系统”（即涉案系统），约定交货时间截止至2013年10月14日；研究开发经费和报酬为532800元，分四次支付。合同签订后，联合出版公司依约向胜龙公司支付价款266400元，但胜龙公司未依约完成涉案系统的研究开发工作，且多次未作说明而停止开发工作。根据涉案合同约定，如胜龙公司不再提供服务应提前3个月告知联合出版公司，应无条件移交涉案系统的软件源代码，但胜龙公司未告知也未移交软件源代码，涉案系统被搁置至今。在合同履行期间，联合出版公司除了依约支付研究开发费用外，还购买了服务器、支付了每年保养的费用、组织员工进行培训等，造成了重大经济损失。胜龙公司未依约开发出涉案系统，构成根本违约，合同目的无法实现。 胜龙公司原审辩称：涉案系统是基于现有软件基础上的定制开发。涉案合同签订后，胜龙公司开发完成涉案系统，实施了软件安装部署及培训工作，进入试运行阶段。但是，联合出版公司很多下属公司提出的反馈意见超越了涉案合同的约定，属于二次新增需求。胜龙公司要求联合出版公司确认二次新增需求，并草拟了补充协议，但联合出版公司未予签署。胜龙公司已经完成了涉案系统的开发工作，实现了合同目的，不存在违约行为，联合出版公司要求解除合同没有事实和法律依据。联合出版公司要求的差旅费、固定资产费用等，均缺乏合同依据，亦没有法律依据，胜龙公司不应承担。涉案合同明确约定涉案系统的软件源代码归胜龙公司，且该系统是胜龙公司的拳头产品，如果胜龙公司不再需要该系统，其软件源代码可以给联合出版公司。本案已超过诉讼时效。 原审法院认定事实： （一）关于涉案合同及其合同附件 2011年10月15日，联合出版公司（甲方）与胜龙公司（乙方）签订涉案合同，载明：一、标的技术内容、范围及要求1.乙方应根据甲方提供的《联合出版（集团）有限公司固定资产管理系统技术要求》，制定具体的技术解决方案，并实现技术要求中甲方提出的流程、功能以及制定有关报表。2.乙方应实现《胜龙科技资产管理信息系统解决方案》中所有相关功能，同时并根据其附件《培训计划》和《售后服务计划》，履行有关条款。二、应达到的技术指标和参数参照以下附件《联合出版（集团）有限公司固定资产管理系统技术要求》、《联合出版集团固定资产解决方案》、《售后服务计划》、《培训计划》。四、研究开发经费、报酬及其支付或结算方式（一）研究开发经费是指完成本项目研究开发工作所需的成本，报酬是指本项目开发成果的使用费和研究开发人员的科研补贴。本项目研究开发经费和报酬532800元。（二）支付方式1.合同签订生效之日起15日内，向乙方支付软件总价款的50%人民币266400元。2.完成第一阶段软件试运行结束，第一阶段验收合格之日起15日内，向乙方支付软件总价款的20%人民币106560元。3.软件第二阶段试运行，软件验收合格之日起15日内，向乙方支付软件总价款的20%人民币106560元。4.软件保修期满，即软件第二阶段验收合格之日起计，一年后，30日内，向乙方支付软件总价款的10%人民币53280元。五、利用研究开发经费购置的设备、器材、资料的财产权属乙方所有。六、履行的期限、地点和方式、地点和方式本合同自2011年10月15日至2013年10月14日在香港/北京履行行方式乙方负责将合同标的物交付甲方，双方依据合同约定以人民币进行结算。九、技术成果的归属和分享（一）本项目实施完成的技术成果（不包括源代码）的所有知识产权归甲方所有。（二）乙方应当保证其交付给甲方的研究开发成果不侵犯任何第三人的合法权益。如发生第三人指控甲方或最终用户实施的技术侵权的，乙方应当承担全部责任。十、验收的标准和方式研究开发所完成的技术成果，达到了本合同第二条所列技术指标，按客户提出的需求标准，采用《整体业务测试用例》方式验收，由双方组成的项目组出具技术项目验收证明。十三、其它1.乙方承诺甲方，如不再提供售后服务及维护或不再开发销售有关固定资产管理系统产品，需要提前3个月知会联合出版公司，并无条件向甲方移交原系统软件的源代码。2.在系统软件免费维护期满后，甲方如需乙方继续提供维护服务，乙方按照本合同软件的总价款12%收取甲方每年的维护费，即每年维护费为63936元，如需调整，另行约定。《胜龙科技资产管理信息系统解决方案》（2011年3月）、《培训计划》、《售后服务计划》作为涉案合同附件。 涉案合同附件之一的《胜龙科技资产管理信息系统解决方案》载明：4.1系统设计思路本系统主要从以下思路进行考虑：1.将所有资产业务纳入到统一的管理平台下进行管理。本系统管理的范围包括甲方单位所有固定资产、非固定资产、各种资产相关的业务申请、审批流程等，系统在设计时将这些资产进行统一编码，根据不同资产的管理特点，配置不同的管理流程进行统一管理。2.根据客户单位资产管理的流程进行应用功能的设计。本系统将根据甲方实际的管理流程进行应用功能的设计，充分考虑客户不同部门用户不同的管理需求，在不对客户现有管理流程作大的改动的情况下，进行系统应用功能模块的设计和配置，实现对业务流程的信息化管理。3.基于我公司原有资产管理系统的基础上进行定制开发。本系统设计是建立在我公司原有资产管理系统的基础上，根据客户单位的具体需求而提出的初步设计，因此，本方案不是一个全新开发的方案，而是一个以原有产品为基础进行定制化开发的方案。4.2系统体系结构，包括4.2.1系统物理架构、4.2.2系统逻辑架构、4.2.3系统功能架构、4.2.4系统主要用户角色（公司领导、资产部领导、专职资产管理员、库管员、部门资产管理员、系统管理员、一般员工）。4.4系统功能设计（系统配置子系统、系统管理子系统、业务管理子系统、资产采购管理子系统、资产入库管理子系统、资产日常管理子系统、资产变动管理子系统、资产盘点管理子系统、综合查询管理子系统、统计报表管理子系统、标签制作、数据处理、手持终端管理子系统）。5.客户个性化要求方案，主要包括应用网站、数据库的简繁体解决方案和港币人民币（其它外币）币值转换方案。7.技术要求指标。9.3项目实施计划前期准备工作的开始时间为合同签定后1个工作日内，工作内容为完成业务需求的确认和对我方现有产品的改进需求的确认，并确定详细的实施计划，工作周期为3个工作日；需求调研的开始时间为合同签定后1周内，详细业务需求调研，了解客户资产管理的现状，各业务岗位的业务流程细节，各种单据表格的样式，各种资产卡片的内容，报表的格式等，工作周期为10个工作日；系统本地化开发的开始时间为合同签定后1个工作日内，根据客户的需求完成系统的相关功能的修改和本地化定制开发工作，工作周期为35个工作日；系统安装实施的开始时间为合同签定后4周内，完成系统安装部署、基础数据的初始化，工作周期为7个工作日；硬件安装调试的开始时间为合同签定后4周内，设备到货，条形码相关硬设备调试，数据采集器可以正常上传下载，调整条形码打印格式，工作周期为2个工作日；系统培训的开始时间为合同签定后8周内，培训（软、硬件培训），详细培训安排请看培训计划，工作周期为5个工作日；软件试运行的开始时间为合同签定后8周内，软件上线测试，系统进入试运行阶段；软件正式运行的开始时间为软件试运行4周后，软件系统进入正式运行阶段；项目验收的开始时间为系统正式运行1周内；合计62个工作日。9.4项目详细施工计划9.4.1第一阶段系统开发阶段，包括需求调研和本地化定制开发；9.4.2第二阶段系统安装部署，包括软件系统的安装部署、资产基础数据的初始化、硬设备的安装部署、系统操作培训和管理培训；9.4.3第三阶段系统试运行（实施周期30天），包括系统试运行及卷标张贴和核对、系统改进；9.4.4系统验收（实施周期2天）。9.6测试方案，包括单元测试、集成测试、系统测试、系统性能和压力测试、系统模拟测试（历史数据移植）、用户验收测试。 （二）关于涉案合同的履行情况 2011年12月1日，联合出版公司委托中华商务贸易公司向胜龙公司支付了涉案合同款项266400元。胜龙公司于2011年11月29日向联合出版公司出具了技术开发费532800元发票。 为查明涉案合同履行情况，联合出版公司与胜龙公司均向原审法院提交了双方往来邮件及员工沟通记录，原审法院确定如下事实： 第一，联合出版公司钟燕（ＱＱ号：27×××15）与胜龙公司彭亮（ＱＱ号：14×××57）的ＱＱ聊天记录，载明： 2012年3月16日，钟燕要求彭亮发送用户需求，彭亮遂向钟燕发送了“香港联合出版集团业务流程调研最终版本6.4-sup.doc”（8.11MB）（简称流程调研版6.4）；同月20日，钟燕收到彭亮发送的离线文件“香港联合出版集团业务流程调研最终版本6.5-sup.doc”（8.11MB）；同月22日，彭亮13:48让钟燕“收一下，改好了”，钟燕14:00成功接收彭亮发送的“香港联合出版集团业务流程调研最终版本6.5-sup.doc”（8.12MB）（简称流程调研版6.5）；钟燕14:03回复彭亮“ok，我这边没什么问题了，一会发给詹峰，如果他也没意见，那他会安排时间确认签字的。至于资产卡片，会按我们最终确定的数据导入表来做吧？因为用户需求中的不全。” 联合出版公司向原审法院提交香港联合出版集团固定资产系统项目用户需求确认书（版本号：6.5）（简称用户需求确认书6.5），并称用户需求确认书6.5即为钟燕收到的流程调研版6.5。经原审法院组织双方当事人现场勘验，用户需求确认书6.5的文件属性显示“最后一次保存者彭亮”、“创建内容的时间2012/3/1918:05”、“最后一次保存的日期2012/3/2213:47”。对此，胜龙公司认可双方确认过用户需求确认书6.5，但不认可用户需求确认书6.5即为流程调研版6.5，因为两个文件名称不相同。 第二，胜龙公司彭亮、李**程等人与联合出版公司王凯、鲁晓、曾敏香等人的来往邮件，载明： 2013年12月17日，鲁晓向彭亮发送邮件，称“这是改用IE做测试时发现的问题，感觉兼容性还是不是很好，操作时多次出现浏览器崩溃。这次再加上了财务部运行系统时发现的问题，你转给系统开发的人员看一看。”次日，彭亮回复鲁晓，称“1.关于IE浏览器兼容性的问题，这个实在没办法，IE10的技术不太新了，对旧版本框架的兼容性不太好，我们也没办法改变微软的东西，只能尽量去适应兼容性。2.财务那边折旧模块的问题，个人感觉折旧模块整个问题较多，能否还是按照以前实施进程，整个模块放在二次验收后至三次验收正式上线这个阶段进行处理，现在要求所有全部没有问题也不可能，公司这边也比较明确，全部处理完，是不是代表二、三次付款一次性都做完，这个显然也不现实，所以建议这个阶段还是以鲁晓那边测试流程和相关业务功能性为主，折旧模块主要还是为了看统计数据，并不会过多影响管理业务的操作，如果因为这个整个系统还是无法试运行的话，基本上代表这个项目上线遥遥无期的。” 2014年1月16日，鲁晓向彭亮发送邮件，称“这几天我们各自用账号登陆固定资产系统做了测试。发现用个人账号登陆系统时，问题还是比较多（详阅附件）。希望你可以安排时间来香港，我们可以一起坐下来在电脑前一同测试，这样我们可以更直观地交流，你也能最直接地了解到我们的需求。”当天，彭亮回复鲁晓，称“1.我的通行证还未批下来，预计时间要到1月20日以后了，通行证到手后我再联系你！2.针对反馈我做了些回复的批注在附件里，麻烦你们那边看看，有问题我们再一项一项的沟通。” 2014年1月21日，彭亮向鲁晓发送邮件，称“大致问题如下：1.系统不稳定、页面崩溃等现象我去香港后具体看一下，因为引发这种问题的原因很多，需要逐一进行排除。2.部分流程出现范围超出的问题是流程设置上的范围问题，进行调整应该没问题。3.预算被占用的问题，目前的逻辑是建立预算单的时候该费用就会被锁定占用，直到成功就扣除，不成功要删除后才会解锁，这种好处是避免做了多个单没有锁定预算导致会出现有单据发现无费用可扣除，毕竟整个集团不是只做一两张预算单。如果做过的单据要留底，也就是说费用不能预先锁定，只能用单据提交成功才进行费用扣除，这样没办法预先控制费用的使用情况，最终可能出现有单据成功却无预算费用可扣，和现在费用锁定后无费用可扣一样，这个问题逻辑上有些相背，预先锁定和不预先锁定我们只能取其一。4.关于折旧部分，并不是说不处理，因为折旧这块主要是通过后台公司计算资产卡片上的折旧相关信息……相对来说比目前的系统稳定和流程审批是否符合当前要求并不是有直接关系，我的意思是先把系统稳定……然后再集中对折旧计算进行修正。5.目前系统到现在还是这样并非我方故意拖沓，前期贵方对系统做过的测试并不详细……直至提到验收日程上后才进行详细测试，暴露目前比较多的问题……之前因为问题不多，开发团队基本抽调到别的项目上去了，现在我这边目前要把开发那边……来需要过程和时间，所以我才提出先赶最紧要的进行修复，最起码能保证系统整个审批的流畅性……大家才有精力去测试相对来说计算和数字上内容比较复杂的折旧内容。6.本周四我可以过来现场测下，你那边的地址再详细告诉我下，我不太清楚你现在所在的楼层，包括你的香港的电话，便于联系你。” 2014年2月6日，鲁晓向彭亮发送邮件，称：“我们已发出通知13号下午2点培训。另外，我们有几家下设门店的分公司提出门店里面各种书架书柜铁架非常非常多，而且日常流动性很大。门店表示依次登记填写表格需要较长时间，而且如果使用系统以后，每一天每一件物品的转移调换都要从系统走手续的话，工作量会很大。不知道你们公司之前是否有类似客户的经验可以借鉴？”同日，彭亮回复鲁晓，称“导入表格的培训内容我没有准备PPT，主要是对着excel讲。关于转移那个，建议可以批量添加明细，走一个转移单，这样会比较省事点。” 2014年2月24日，鲁晓向彭亮发送邮件，称“固定资产管理系统上线时间表，会尽快整理好各公司的资产表格交给你。不知道你建议集团总部这边是用2012年的数据做测试还是直接放最新的2013年的数据？另外，请你看一下我们关于内地公司的安排，不知道3月在深圳给内地各公司讲一次填报表格的培训你是否有时间？”该邮件还列明了2014年2-7月针对香港、澳门、内地各公司进行填表格前的培训、完成表格的收集与汇总、数据的上传导入、开设系统登陆账号、设定使用者审批权限、系统上线前的使用培训等工作计划。 2014年3月14日，鲁晓向彭亮发送邮件，称：“目前我们这边觉得保证7月系统全面上线，工作量比较大，考虑专人负责及增加人手。你看一下这是我们笼统的上线时间表。麻烦你根据以往经验和培训时听到我们香港和内地公司提出的问题，帮我补充一下这个时间表，具体哪个阶段还会需要做哪些工作，做哪些准备，给我们参考。也请相应增加胜龙方面会在哪个时间做什么工作。给我们看一下系统上线前具体需要做哪些工作，好做相应的准备和安排。” 2014年3月24日，鲁晓向彭亮发送邮件，称：“目前在跟进编号对应的工作。同时在整合小分类。其他公司还好，只是以目前的对应分类名称法使用系统会很麻烦。办公用具截止目前350几个小分类，电子设备300个小分类。印刷公司深港粤京沪各不统一，问题比较大，已建议他们在七大类内增加特别小分类，但是结算的时候估计还会有很大问题。另外，之前问过你的详细时间安排的事，你能不能抽空再帮我做一个比较详细的时间安排表。”该邮件附上了鲁晓当日发送给其公司同事吴淑贤等人的邮件，称：“最近我在同集团财务部及软件公司沟通收集各分公司的资产分类后，（发现）小分类太多、不方便操作的问题。正在研究是否生财家私（办公用品）及电子设备两大类的资产可以不通过资产分类名称对应财务账及固定资产系统，而是通过财务编号做对应。不知商务同事有什么好的建议及想法？” 2014年5月27日，彭亮向王凯发送邮件，主要内容为28日（次日）当面沟通备忘：1.针对5月20-21日系统出现的问题及相关工作的不足之处，将汇总的问题逐条进行确认。2.针对目前系统上线的问题及难点进行讨论，落实具体工作。3.针对系统新提出的业务及功能新需求的讨论。4.其他项目进度及双方需交付的内容讨论。 2014年6月3日，曾敏香向彭亮发送邮件，称“关于折旧的问题及刚才面谈时提出的问题（附件），有劳跟进，谢谢…”附件为《6.9日前固定资产管理系统待修改的问题（汇总及同财务部门商议后）》，随后提出“据税务部署的要求处理转移。”。次日，彭亮回复曾敏香，称“根据你们对内部交易的要求，实际上我们系统没有处理过这么复杂的业务，以往我们只是针对资产做公司之间的调入和调出，只是状态发生变化，没有去处理涉及到财务方面这么复杂的要求，所以针对这么几种情况，我们不是很好处理。目前我们比较适合处理的就是，内部交易分为2个部分，转出公司流程审批完后直接对资产做退出处理，转入公司根据内部交易单，进行资产新增入库，同时调出资产卡片，由转入公司人员进行具体资产信息的重新录入（资产现在原值、使用年限等相关信息）后，生成一个有新的资产条码的资产。由于这个业务现在做的比较少，所以到底要如何实现，可以往后放放沟通到比较满意和合适的处理方式后再进行修改，这样可以吗？” 2014年6月16日，彭亮向鲁晓发送并抄送王凯和曾敏香邮件，称“前事不提的情况下还是有几点必须要沟通清楚：1.关于程序修改部分，9号当天我们已经明确告知了除了新增的预算导入（内部交易和折旧工作量大，肯定要延后）还未完成，其他修复的已经完成并更新了，期间你们那边的原因并未同步配合我们测试确认功能，为了进度周三的时候我要求包乐乐一定要先与你那边先把程序修复的部分先进行验证后再比对导入数据和excel表是否有误差，我出差两天，今天包乐乐反馈你那边一直没表态验证系统的修复，一直只抓着包乐乐要求比对数据，你认为应该是数据先对完再验证程序，这个先后顺序我后面再论。2.在对系统修复及需求修改工作完成后，里面有比较多的测试数据，我们需要赶紧确定检验系统有无明显问题出现，然后再把现有数据清空再导入无垃圾数据状态，才能比较出导入的excel表格内容和导入到系统中内容是否一致。如果程序都还没通过你们的验证，现在去对好数据，你们再测试检验系统，做了垃圾数据，我们再清空，再重导，我们还需要再次验证下数据的准确性，我觉得这个先后顺序总得排一下避免重复工作吧，而且到底是目前系统几个人员信息（还不是重要员工信息）有误差重要，还是系统稳定性更重要？3.据包乐乐反馈这几天比对的数据和之前提交过来导入的excel表格去比较数据差异，现在到底这个数据是在做之前提交的excel文件内容误差修正，还是在这个充满测试数据的系统上进行比对？如果是后者肯定会有垃圾数据影响比对结果；如果是前者这个误差修正工作不应该我们去做吧，我们只需要负责校验你们提交的excel导入到我们系统中是一致无错的。根据以上的内容，我建议我们应该沟通确定下后续工作的排序：1.6.9日修改需求测试需要多久检验出结果，给具体时间（在赶工的情况下不能保证还有没有没测到比较隐蔽的BUG）；2.折旧方面我们还要进行财务提交明细数据和导入数据进行比对修改后（集团资产数据应暂时不纳入数据比对范围），完成折旧功能模块。3.内部交易要在折旧完成后进行处理（少用的模块可以暂时排后）；4.数据比对在系统稳定的情况下，我们将重新清空资产数据、分类、人员、部门等信息重新按照之前提交的excel表格进行导入后，与excel表格进行比对误差，如之前提交的excel文件有新增修改，应提前说明，否则我们比对标准以以前提交的excel为标准。5.培训日期我们可以同意延后，但延后日期应按上面所有工作进行确定具体时间安排上的沟通，同时双方能很好的快速完成上述各自工作内容，配合项目的运行。关于时间方面，你们有你们实际难处，我们也有我们的难处，我们不可能一直把人都空在你们项目上不做别的事，毕竟这个项目已经拖了这么久了，再拖下去我们也拖不起了。”同日，鲁晓向彭亮、包乐乐发送邮件，称“首先关于香港地区导入数据统计，目前数据导入统计表双方已核对，除了集体人员统计数量与系统显示数量不同外，其他各公司资产及人员数量统计已相符。但我们于系统-系统维护-人员管理无法实现复核各公司人员数量，除集体外，点击各公司名称、人员列表页面均无法显示该公司人员明细。请先解决此问题，我们才可以完成数据导入是否完整的核对工作。同样还有查询与统计-比如三联资产总数为1354条，与统计清单1458条不符。另外请整理内地及澳门各公司数据导入清单。关于内地培训的时间，早前我们商定6.9日系统修改完成，如我们测试全部流程及核对数据导入情况无误，则将内地培训时间暂定为6.19-6.20。之所以要求你们于5.22-6.9完成系统修订工作，我方于6月初进行全面测试无误，并于6月中旬进行内地公司培训，是为争取于6月底至7月中旬我们集团各公司业务繁忙之前完成全面上线工作。关于这一点也是5月培训前跟你们反复强调过的。以现在情况来看，本月暂时无法进行内地公司培训。为保证内地培训的效果，系统各项功能应准确无误，符合用户需求书的全部要求；香港及内地各公司导入数据数量及内容准确无误；依据修改后的系统设定更新培训内容；于培训前完成培训所需各硬件设备（电脑、手持机、标签打印机）的准备工作，以上各项工作均已准确无误后才能进行内地培训。” 2014年6月17日，彭亮向鲁晓发送并抄送王凯和曾敏香邮件，称：“鲁晓，经过今天我们项目组内部沟通讨论，暂定一个时间计划表，你先看看，然后大家确定下具体的时间计划，今天下班前能否确定回复我，如有疑问或者需要协助的请及时联系我处理，谢谢！”该邮件附件“6月内地培训准备时间计划表（待确认）.xls”载明：6月17-18日程序修复校验；19日确认校验结果、导入数据校对；20日完成数据校对；24-25日内地培训。补充说明:1.折旧数据处理（集团数据暂不参与数据校对），目前已经在同步开始处理，因需要补充财务提交明细表中的累计折旧等参数，工作量比较大。2.内部交易按照之前邮件约定以卖出部门资产退出，买入部门新增资产重新录制卡片信息处理，此工作会安排折旧后面处理。3.目前程序修复及修改部门已经是超出以前既定的需求说明书要求，如再有新需求产生，我们不会再进行新增直至完成本期合同。4.暂定时间以我方提出为基础，双方进行各自工作安排考虑后确定最终时间。 2014年6月19日，彭亮向鲁晓发送邮件，称“之前人员查询无法按公司进行查询问题已经修复，你可以上系统看看。另外，系统验收标准今天能发出来吗？周二说要出来的，今天周四了还没发出来，基本上这2天都没有形成有效率的工作进展，如有配合上的困难请预先说明，否则我们不知道如何去配合响应了。”当天，鲁晓回复彭亮，称“行政部验收标准已发送，验收标准是根据用户需求书及系统设定进行归纳及描述，列出需要测试的项目及内容，验收的实际操作还是登入系统依次测试所有功能。我们认为有效率的工作进展是由软件设计方预先谨慎测试过所有项目，提早发现有BUG的地方，确认修复无误再呈交我方配合。而不应该是每一次都由我方在使用时发现系统运行不下去，再告知你们去改。财务功能的验收依据6月3日财务部门相关同事与您会谈时的意见进行功能测试。另附上修改后的《系统操作流程》请核对是否符合系统设定，更新已变动的图片，修改标黄部分业务描述，补充系统管理员操作教程。”次日，彭亮回复鲁晓，称“附件是对验收标准中一些补充和有疑问的地方，麻烦仔细研究后达到一致，我们会根据此标准分解各项内容形成量化的测试用例文档。对于配合效率方面，上次碰面已经说明过你们系统是全部重新定制开发的，非成熟产品，其中很多设计是根据较粗的需求内容进行，和你们主管愿望是否有偏差也是需要确认和校验的，这是需要在项目进行过程中体现出不一致的地方，然后通过沟通和处理达到一致，同时在这个过程中大多时间我们都是比较被动的，对需求修改让步也不少，整个系统是联动的，修改的地方越多，越容易产生不易察觉的BUG，这在整个软件行业中风险是最高的，这个需要理解我们，现在有这个评判标准大家角度和尺度能达到一致，后续工作的效率会高效很多，说实话，之前你们改来改去我心里是一直没底的，不知道要改成什么样才算OK符合的。这个项目推广比想象中复杂，我们双方都需要多些耐心和理解，希望能在后续工作中逐渐提升和优化工作效率吧，只有朝前看彼此合作才有希望，纠结于过往很难保证有好的结果。”鲁晓回复彭亮，称“已于附件中补充。另，查询与统计—折旧明细表页面无法显示，请确认原因。你们按系统现有功能及流程项目先依次进行全面测试，提早发现问题，我们两部门联合测试时一次通过才好继续推进。”该邮件附件《固定资产管理系统行政验收标准》载明：验收标准是根据《用户需求确认书》版本号：6.5基础上，各项系统维护功能、生命周期管理流程及2014年5月底至6月初与胜龙公司共同商议之修改方案进行验收；验收标准涉及操作系统相容性、资产预算管理/资产申购管理/资产入库管理/资产领用管理/资产归还管理/资产内部交易管理（按财务部要求进行更改）/资产对外赞助事项管理/资产维修/保养管理/资产报废管理/资产出租管理/资产出售管理/资产产净值资料（财务部门验收）/资产估值调整资料（财务部门验收）/资产折旧管理（财务）/盘点管理/查询报表管理/系统维护等18项内容，并逐项进行了补充说明。 2014年7月9日，鲁晓向彭亮发送邮件，称“今日用不同账号测试了系统内申购业务流程，有几处问题及几点疑问。请见附件。”邮件附件载明：“目前系统设定申购及预算都按大分类划分，那么添加申购明细单页面不应再显示‘选择名称’搜索框。目前系统内集团本部操作员管理权限及管理范围设定不正确，应重新设定。故前往系统维护页面发现，系统管理员进行修改及核对本公司操作员设定时，应可以直接列出本公司全部操作员才较合理及便捷。目前设定只可以依据不同部门的管理范围列出操作员，不利于日常管理。资产申购管理—采购单查询、采购单明细查询可以改为申购单查询、申购单明细查询。同理还有申购作废管理中的采购作废单希望可以改为申购作废单。资产管理员核对资料—添加预算单号时，资产分类显示的是大分类名称，但于弹出页面显示的预算单分类为小分类预算，是否合理？目前系统已修改为选择大分类，预算也按大分类来做，此处是否可以同步修改？在申购管理的流程中发现，提交时可供选择的处理人名单与驳回到这一步骤的处理人名单不同。申购申请如不通过，打开采购清单查询，该单的状态显示为101726，应该是已审核。不通过的申购单预算是否自动释放？”次日，鲁晓向彭亮发送邮件，称“关于预算业务流程测试中发现的问题，具体请见附件。”邮件附件载明：“二级公司资产管理部主管页面未见导入excel功能；三级资产管理部门主管导入excel后无法上传并生效；新增预算添加明细时，选择人员除了资产管理部主管，还出现了行政部其他员工，有几位甚至并未设定为操作员；提交预算申请时页面无反应，后出现错误；集团财务主管登陆后主页未出现待处理工单列表；为一个同事在两家公司注册了两个不同的登陆账号，情况等同于同名同姓的两个人，但登陆后不应看到其他公司的单据；欲增加操作员吴静怡，新增操作员时提示已有该登录名，但以该登录名查询时却未能查询到。” 2014年7月11日，彭亮回复鲁晓，称“根据昨天你反馈的问题，已经做出处理：问题一更新遗漏，已经更新处理完了。问题二不属于程序BUG，是浏览器使用问题，手动清理下浏览器缓存就可以了。解释下：更新系统补丁后，浏览器浏览页面缓存未清除导致未刷新更新页面显示，为了避免麻烦，我们做下调整让系统更新后自动触发浏览器这边清理更新下缓存。问题三不是BUG,不需要调整修复。（具体解释，略）问题四预算提交时会触发邮件发送，等待邮件转发的时候，系统按钮没有跳转成功，会导致不停点击提交，造成截图中的问题。邮件是否成功和邮件服务器响应有关系，我们没法管控到那么远，为了避免歧义，我们调整下提交按钮后，会提示信息对话框，遮挡提交按钮，待邮件发送成功再释放这个提示信息框，避免因后台邮件触发等待导致前台不停点击提交按钮引起这种错误，下午可以更新修复。问题五角色设置问题，集团财务主管角色设置用的员工视图，所以没显示待办事项，已经帮忙系统手动调整设置修复。问题六不是BUG，手动系统设置处理（具体解释2个账号对应2个同名同姓的人，对应不同的管理范围）。问题七该人员信息数据不完整，导致查询不正常，已经修复。”同日，鲁晓回复彭亮，称“二级资产管理部主管未见预算导入功能，请核查。如果预算导入功能之前一直遗漏了，在上周五你发过来的系统验收提交说明之前是否完全验证过系统各项功能均没问题之后才通知我们进行验收？我们需要安排人员、协调时间进行系统验收，验收一旦通过便马上会推进下一步的工作。故请你们用不同账号仔细全面检查系统已经完全没问题，万无一失之后才通知我们进行验收”。同日，彭亮回复鲁晓，称“1.二级资产管理员预算导入该功能还未更新……；由于预算导入功能属于新增功能，我们都是从三级公司预算新增开始做导入预算测试，我们测试花更多时间是导入后的预算申请是否有效，忽略了二级资产管理员也是需要导入预算权限的，非常抱歉。2.测试用例汇总统计是为了对测试结果反应的统一性和完整性，防止测试随时BUG的信息碎片化造成修复遗漏；理解测试是需要人员和时间的，我们这边也是因为时间的不充裕满负荷在拼命赶工作。有遗漏的地方也需要你们能理解……但是测试的时间计划还是应当有的，否则我并不知道什么时候可以看到结果，也无法预料工作的时段去做相应的调整和协调安排。最后说明下，任何一个系统上线都不可能做到100%无问题，即便是Windows操作系统这个全球性使用的系统，每年得不停提供修复错误和优化系统的补丁，你要求要万无一失什么问题都不会出现，怎么可能呢。”同日，鲁晓回复彭亮，称“我们目前预期进行的是系统的验收，而不是测试，你们应该做到的是检测系统各项功能是否还有问题，自测已经达到验收标准之后再通知我方进行验收……故请你们慎重检测系统无误后再通知我方进行验收。请你们给我方一个可以验收的时间。”同日，彭亮向鲁晓发送邮件，称“昨天问题修复见附件！我们按测试用例全部走一遍，每项业务系统截图作为通过结果，一切以测试用例模块我方测试为准进行验收，其他诸如界面问题、使用习惯问题等修改性要求请勿再提！” 2014年7月14日，鲁晓向彭亮发送邮件，称“今天看到系统页面修改了不少，很多都和之前不一样了。今日试操作预算流程仍有一些问题，请你们完善修改后依次逐项进行检测，尽快达到验收标准通知我方进行验收。”7月16日，彭亮向鲁晓发送邮件，称“根据业务需求及验收标准要求，我们对整个系统进行了业务模块进行过程测试，并以截图和文字描述的方法进行总结归纳，详情见附件！除开资产内部交易属于新增修改要求未完善，其他均按验收要求标准完成了相对的修改及修复工作，之前测试出现的问题也全部进行了修复，请协调下时间进行系统验收工作安排，我这边也协调人员协助你进行。另，《系统操作手册》因目前系统方面改动较大，一直未对系统本身进行定稿，现在我们以现有准备验收定稿系统为对象开始整理操作手册，更新截图及相关说明描述，预计下周可以给出，请知晓！”同日，鲁晓向彭亮发送邮件，称“今日由预算业务开始验收，仍发现有问题，具体请见附件。” 2014年7月17日，彭亮向鲁晓发送邮件，称“系统要上线最大的问题应该基于以下2点：1.页面无明显BUG,比如页面无法显示，功能按钮点击错误。2.业务功能能正常操作完成。建议还是简单列个测试的计划，把系统模块分解，大致每天可以检验几个模块，每天我们人员都在线配合你那边出现的问题，及时调整。”同日，鲁晓回复彭亮，称“收到你们自测系统的截图说明文档后，我们有一些疑问，加之昨天开始验收预算流程时发现仍有明显BUG，今日汇总关于预算、申购、直接入库部分的备注批注先发给你。系统交付验收前，你方应慎重自测无问题才应该通知我方验收，这样既是市场常规程序，也是最有效率的程序。我方多次提醒你应用不同账号进行自测，才能及时发现问题，而不应等到我方安排人员验收时。我方有两个主要问题无法认同：1.测试业务功能是否正常应处理完全部流程才可以称为完成，而不是分散测试每一个单项步骤。2.应使用不同低权限的账号测试系统，便于发现问题。以上两点如你方自测时已经做到，第一应该一早发现超出预算流程余额时仍可以提交申购单，第二可以在我方验收前处理无法新增人员的问题。希望你们真正模拟用户的使用需求，慎重全面地测试系统各项各处，我们才能顺利完成验收。”同日，彭亮回复鲁晓，称“我方是协助贵方进行资产管理系统上线工作，并非代替贵方的测试工作的，提出需求修改后提交贵方测试，贵方认为应该是我方测试后提交你们直接检验，这个要求有些过分。稍晚，我们会换一批低级账号再自测。” 2014年7月21日，彭亮向鲁晓发送邮件附件，称“附件是按照你的要求使用不同的账号的测试结果截图。”次日，彭亮向鲁晓发送邮件，称“申购预算扣除不准确的问题已经修复完毕，麻烦你那边验证下。周五已按你上周对于我们自测的账号使用问题，已经更换更低级的公司的账号进行测试，并且这个测试是按照6月23日双方确定的验收标准中的要求进行业务流程的自测和截图，可以作为验收的依据之一。系统验收本周内是否能够完成，麻烦给个回复。”7月23日，鲁晓向彭亮发送邮件，称“收到7.21测试文档，看到你们进行了更细致的自测。如未发现明显问题，流程操作顺利无误，本周应该可以验收完。如发现问题再联系你。”7月25日，鲁晓向彭亮发送邮件，称“我们本周按验收标准（6.23日电邮）对《用户需求确认书》中所列系统业务管理进行验收，系统中主要的11项业务管理中，目前已发现2个业务管理问题较大，故我们认为此次验收不成功，无法通过。部分问题见附件。”7月31日，彭亮向鲁晓发送邮件，称“目前系统已经修复上述问题（预算流程和申购流程）以及可能涉及联运页面位置的问题都已经过检验后更新完毕，周四开始可以进行系统验收，同时提以下建议：1.部门业务流程中因为设置有条件限制，如出现业务单据未显示或未正常审批完，有可能是业务要求必备条件未达到。2.由于很多人员的交叉权限较多，可能会影响到对业务执行及部分单据查询。类似以上原因可能找不到单据，或者业务未按正常流程节点提前走完审批等问题出现可能非程序BUG，可及时联系我们帮忙查清原因，避免引起误会。”同日，鲁晓向彭亮发送邮件，称“上周五我们汇总了验收系统预算流程及申购流程过程中发现的问题，今日收到你发来已修复完以上问题的回复，我们今日会重新验收这两项流程，如无其他问题再验收其他各项流程。在我们验收这两项流程时，希望你们能够详细核查其他流程业务，提早发现问题预先解决，才能顺利完成验收工作。” 2014年9月5日，彭亮向鲁晓发送邮件，称“文档未能昨天及时出来，先按约定的把计划表给你，你那边先研究下，没问题的话，就回个确认的邮件，抄给相关人员把这事就这儿定一下，后面我们也都便于工作的开展。另验收表因为Visio图较多，画起来需要点时间，只能晚点才能给你了。”同日，鲁晓向彭亮发送邮件，称“验收标准无变化。如验收顺利通过以后则进行试运行及安排内地培训，不再另行验收。此次交给领导的是验收工作时间安排及任务分配，故未列付款事宜。另外，按我们5月商定的补充协议，将付款合并为内地公司培训以后付40%，你们是否认为再改回分开两笔20%付款？如你们认为改回分开两笔付款更好，我们还应就此补充协议重新做正式电邮及文件备案。”同日，彭亮回复鲁晓，称“付款事宜和领导沟通后，晚点重新文档弄好后给你让领导看”。鲁晓回复彭亮，称“已通知财务人员下周一准备核对折旧表。如可以开始请发电邮告知。”9月7日，彭亮向鲁晓发送邮件，称“2013年的新增和撇除数据已经导入到系统中，目前折旧表可以查看比对了，如有什么不妥的地方麻烦尽量周一能反馈清楚，我们这边周二上班会进行快速处理。” 2014年9月10日，鲁晓向彭亮发送邮件，称“账务核对了2013年的折旧明细表，发现减撇资产的两行未进行计算。”同日，彭亮回复鲁晓，称“修改好了。这个问题是因为我们在统计的时候结束日期取的是月初，而报废的资产是12月中旬报废的，所以统计不到。现在我们把结束日期改成了取值为月末，这样就可以看到撇除资产了。”同日，鲁晓回复彭亮，称“我们这边核对集团本部2013年折旧明细表正确，可以开始进行功能验收了。请你们备份系统数据后通知我们开始验收。另外，其他各公司资产数据及人员名单重新核对请你们尽快开始整理，给我们留出核对数据的时间。”同日，彭亮向鲁晓发送邮件，称“验收表和补充协议我在上封邮件里已经发出了，麻烦你看下，有什么问题我们尽快落实和确定清楚就开展后续工作。数据这块我按照上次我们当面沟通的内容今天已经安排包乐乐在进行整理了，期间他有什么不确定会QQ或者微信联系你进行确认，确保每一个数据都不出错。” 2014年11月11日-2015年1月13日，联合出版公司鲁晓与胜龙公司彭亮、崔波的邮件表明：彭亮不再担任该项目经理，项目经理先后变更为王敏霞、张晶晶，双方就联合出版集团固定资产系统进度及计划多次协商会谈时间及地址。 2015年4月10日-5月8日，联合出版公司鲁晓与胜龙公司崔波、徐东强的来往邮件表明：项目经理变更为崔波，开发工程师变更为徐东强，徐东强称《需求确认函（联合出版）》所列内容为包含实施内容在内并可能影响验收的内容，并需要双方均认可；《联合出版项目进度》所列内容为开发进度，不包含实施内容及培训等内容，且未注明完成度项为尚未进行内容。鲁晓则提出2月4日双方确认的《需求确认函（联合出版）》与《联合出版项目进度》的工作内容不同，目前是否是按照需求确认函中的功能要求设计开发？多次催要开发计划；强调盘点业务流程迫切需要增加批量上传的功能，否则无法实现盘点功能，要求将盘点上传功能列为重点任务、重点开发。鲁晓在5月8日邮件中称仍未见崔波发送的4月份开发进展报告。 2015年6月29日，鲁晓向胜龙公司施智华、崔波发送邮件，邮件附件为联合出版公司给胜龙公司的函件，主要内容为：按照双方于2013年11月共同商定《联合出版项目时间表2014新》，“实物资产管理系统应于2014年5月完成香港地区培训及试运行以及验收上线，2014年6月完成内地及澳门地区培训及试运行以及验收上线。……项目进展记录如下：●2014年2月至4月，我方收集各子公司数据，将由你方导入系统。后我方在2014年8月系统测试修订过程中发现因资产分类设定等原因，引起资产分类导入错误，你方需重新导入我公司数据，系统才可正确运行。●2014年5月至6月，按《联合出版项目时间表2014新》进行港澳子公司及内地子公司上线培训，但培训过程中系统出现较大问题，无法正常运行，后你方开始进行系统修改。●2014年7月，开始测试及验收系统，仍发现较大问题，无法通过验收。●2014年8月，我方安排人手于深港两地配合你方进行系统修订及测试工作。●2014年9月，我方按《联合出版集团资产系统项目进度时间表2014_09_05》分配人手开始进行第二次系统验收工作。●2014年9月30日，我方在第二次系统验收过程中发现系统出现明显问题，无法通过验收，当时项目经理彭亮答复因放假人手问题，待正常上班后立即修改，改完后再通知我方继续验收，之后我方一直未收到通知。●2014年11月，我方得知原项目小组已解散或离职。12月2日在深圳与崔波会面，他承诺将在一个月内组建有经验的项目小组负责我方项目的重新开发及修订工作，由专人集中负责，保证于3个月内完成，交付我方验收。●2015年1月16日，我方在深圳与重新组建的项目小组经理张晶晶及组员徐东强会面，双方商定系统重新开发的需求框架。张晶晶承诺将尽快对开发需求进行评估，双方认可后3个月内完成重新开发工作，交付我方验收。●2015年2月2日，王敏霞与我方联络，告知我方项目将由她具体实施，并发来关于系统开发内容的《需求确认函（联合出版）》，双方确认后，王敏霞告知我方她已按此需求安排人手，开始开发工作。●2015年3月2日，我方得知王敏霞已不再负责实施此项目，重新由张晶晶负责具体实施。之后我方得知张晶晶此时仍未安排人手开始进行开发工作，此前也未同王敏霞沟通交接。此时张晶晶再次承诺于一周内进入开发阶段，分阶段交付，3个月完成，今年6月进入测试验收阶段。●2015年4月9日，询问张晶晶3月份的开发进展状况及开发进度时，得知张晶晶实际已于3月初离职，系统开发工作延迟至3月底才实际启动。●2015年4月23日，收到截止到4月20日的《联合出版项目进度》截图后，我方就截图中所显示的任务内容减少等问题向你方提出疑问，你方未做回信及答复。之后我方通过电邮、电话、微信多次联系你方崔波，崔波5月11日承诺会尽快一并回复我方疑问，但实际从未回复我方，更不接听电话，不回复电邮及微信，甚至退出微信群。●2015年6月初，我方联系你方施智华副总裁，得知因你方人员安排问题，我方项目实际早已陷入停滞。我方仍未清楚开发工作进展的具体程度及项目何时能够再次重新启动，以及继续完成交付所需的时间。自此次与施智华副总裁联络之后，我方再次电话联系施智华副总裁均拒不接听我方电话。项目进行至此已历时4年，从2014年5月培训出现问题之后，项目进展一直落后于计划，且未有明显进展，我方也面临重大压力。本着尽快推进项目完成的目的，希望你方尽快提出切实可行的工作计划及方案，明确重点项目的准确时间、开发人员配置、项目交付的时间计划表，交予我方领导审议。同时，应安排固定联系人与我方保持沟通。还有需要我方提供协助配合的地方也请一并提出，我方将尽力提供便利，令项目得以尽快推进。” 2015年7月15日，鲁晓向李**程、王凯发送邮件，称“将最初版本的用户需求确认书6.5版扫描件发给你，后在测试过程中简化了一些步骤，删除了一些审批环节，请见批注。去年时曾经改过一版需求2014.6，文字内容作了一些精简。图表由原项目组改了一部分，还有待修改的部分已标出。另有盘点部分功能还需最终确定。这份需求书我们需要发给各个操作员作为使用手册，所以配图应简单清楚，流程号确认签字等可以删去，只保留操作指导的功能。培训手册已于两地培训过两次，有很多同事参加过4次培训，仍然表示很难掌握系统操作方法。根据这些反馈，我们曾与原项目组商议，全面上线前除了制作操作流程录屏外，还应在系统编辑一份管理员如何设定操作员管理权限的详细说明。”7月18日，李**程向鲁晓发送邮件，称“根据7月13日在贵司深圳分公司针对之前一版需求进行详细沟通后，我们已做出详细的解决方案及页面原型，望给予确认需求的准确性及方案的可行性，希望能在7月22日前给予我司答复，需求方案详情请查阅附件。”邮件附件为“香港联合出版社二次需求确认函2015-7-13.docx”文件。7月22日，鲁晓向李**程发送邮件，称“我们已看过你发来的确认函，请留意几处删改的地方及批注。请特别注意需求二及需求三中，固定资产折旧明细表及折旧明细查询涉及的两个不同业务流程，请核对现在系统中的审批流程、页面设计以及报表样式，再就两个流程分别重新提供我们解决方案及页面示意图。需求五中的单据追踪功能页面显示不够详细，请重点示范对审批人是否已阅读单据，是否已处理单据，处理时长等追踪信息的显示。” 2015年8月2日，李**程向鲁晓发送邮件，“根据您7月22日邮件回复的内容及我们进行电话沟通后，再次针对需求进行调整及需求工作量的安排；关于邮件提到的需求三中及需求文件中的备注‘请注意固定资产折旧明细表报表样式已固定。下方配图显示折旧管理流程。这两个流程是不同的。请妥善区分固定资产折旧明细表及折旧管理两个功能后，再分别提供解决方案及页面原型。’我们进行该需求功能的方案调整，不将功能合并，保留系统原有功能，增加新—新公司级汇总的统计功能；在此新功能上以是通过‘需求一’对资产类型进行了按公司权限划分，各公司只看到各公司的，并没有您所担心的‘子公司财务人员只可以看到本公司内各部分的折旧明细，并不能查看其他公司的折旧明细表’问题出现。另外，需求对系统功能及业务做个澄清，‘折旧管理’是个业务动作，‘固定资产折旧明细表’是一个分析统计报表，但对于系统而言，业务折旧管理，在系统中均以报表的方式进行最终的呈现，并没有像您的需求将两个功能妥善区分；方案详细请查阅附件。注：需求方案并不能代表所有理解，方案只作为一个需求的表述，功能大致实现，在整个功能开发实现过程需求方案只起到80%的作用，还需要配合沟通（电话、会议）方能最终解决问题。”8月10日，鲁晓向李**程发送邮件，称“我公司资产管理部门及财务部门相关同事共同研究需求确认函之后认为小分类名称及穿透查询功能非常好，希望可以尽快上线。关于需求二所述内容我们不是很理解，不能明确具体改进的是哪一个流程，将显示在哪些报表中？望再详细解释及举例示意。当操作员点击：折旧管理及查询与统计这两个流程时，是否可以增加提示：此操作员是否具有查询权限？继续或重新登入。并增加登入输入框？以方便财务部门同事相关同事及时更换账号？关于穿透查询的区别显示，请见批注。另有预算汇总提示，新增打印模板，盘点数据导入需求我们未商定，此三项需求应列入需求确认函中。”8月21日，李**程回复鲁晓，称“关于你邮件提到的及对需求确认函做的批注内容1.关于需求二所述内容我们不是很理解，不能明确具体改进的是哪一个流程？将显示在哪些报表中？望再详细解释及举例示意。‘折旧管理’是个业务动作，‘固定资产折旧明细表’是一个分析统计报表，但对于系统而言，业务折旧管理，在系统中均以报表的方式进行最终的呈现，并没有像您说的需求将两个功能妥善区分，并不是与那个流程有关；2.‘可否设定集团财务部可进行全局查询，可以查看所有公司的折旧明细表，穿透时显示各二级公司；增加新用户；二级公司财务部，可以查看本二级公司及下属三级公司折旧明细表，穿透时显示各三级公司；三级公司财务主管穿透时，显示的是本公司各部门？’之前第一版需求中已明确通过权限去进行划分，而您在我们提供的方案中做批注修改，本次才取消；建议组织真正对需求有明确把握意见的部门同事进行一次会议，现场答疑，免得理解不一，传递有无，具体时间您可先定下再提前告知我。” 2015年9月2日，鲁晓向李**程发送邮件，称“8月26日我们在视频会议沟通的关于盘点功能升级及预算汇总提示功能部分，如有任何进展及方案，请回复我方，谢谢。”同年9月7日，李**程向鲁晓发送邮件，称“关于8月26日的沟通会上提到的盘点数据导入的需求，我方技术上可以实现，将会在需求确认函上补上该需求；关于预算汇总的功能在经过与我们技术同事沟通后，按照系统目前的架构，在实现预算汇总功能有很大难度及需要很长的开发周期，在针对预算汇总这个功能看能否再找其它解决方案？”同日，鲁晓回复李**程，称“盘点数据导入功能可以实现太好了，请在确认函上补上该需求的实施计划及时间安排。新增导入预算明细提醒的功能原为去年5月培训时，相关子公司财务同事现场操作系统时提出的想法。……如技术上无法实现这个提示功能，不知道是否可以由权限设定二级财务可查看下属三级公司预算有无完成审批，或者预期审批功能是否可以达到提醒作用？……”同年9月10日，李**程向鲁晓发送邮件，称“根据8月26日会议沟通结果已将需求确认函再次调整，并按照新的需求确认函重新排了开发实施计划，望最迟在9月14日给予盖章确认便于我司开发同事尽早开发。如迟迟未给予盖章确认将会对整个新功能开发实施严重滞后，望理解！另，在之前及8月26日会议上提到的预算汇总确认从技术角度来讲实现难度很大，实现周期也过长，如按您在邮件中提到的‘不知道是否可以由权限设定二级财务可查看下属三级公司预算有无完成审批，或者预期审批功能是否可以达到提醒作用？’这个可以实现，只要‘二级财务部’在审批流程里即可通过预期审批查阅到，如果不在审批流程里是可以通过授权的方式进行查看审批数据，需求确认函中的需求四及需求六即可解决该问题。” 2015年9月25、30日，鲁晓向李**程发送邮件，多次催要需求确认函最终版。 2015年10月18日，崔波向鲁晓发送邮件，称“附件是我方提供的补充协议，并附有双方确认的需求确认函及实施计划，请查收，并保持沟通。” 原审诉讼过程中，胜龙公司向原审法院提交了没有双方盖章签字的最终版《实物资产管理系统项目补充协议》（简称补充协议）及《香港联合出版社项目二次需求确认函》（二次需求确认函）。对此，联合出版公司认为上述证据没有双方的签字盖章，没有法律效力。 补充协议载明：1.涉案合同“六、履行的期限、地点和方式、地点和方式&rdquo截止时间2013年10月14日延长至2016年12月31日，履行地点不变。2.系统验收计划变更双方于2015年10月20日确认的二次需求确认函和《香港联合出版集团资产管理项目二次实施工作计划》中的系统验收计划表为系统验收和上线的计划，如时间上有分歧需要重新沟通一致后进行。3.涉案合同支付方式及条件变更：根据验收计划表中计划内容，重新制定甲方（联合出版公司）支付乙方（胜龙公司）费用的方式及支付条件。①计划表中第一阶段功能性验收通过签字确认后，七个工作日内甲方向乙方支付软件总款的20%人民币106560元。②第二阶段，集团本部系统上线试运行10个工作日后进行试用报告通过签字，七个工作日内甲方向乙方支付软件总款的20%人民币106560元。③系统整体上线之日起计，一年后，30日内，向乙方支付软件总价款的10%人民币53280元。补充协议生效后，即成为涉案合同不可分割的组成部分，与涉案合同具有同等的法律效力。除补充协议中明确所作修改的条款之外，涉案合同的其余部分应完全继续有效。 二次需求确认函涉及8个模块：1.系统模块：系统同一账号通过授权方式可以查看多公司数据，不需要在每个公司进行设置岗位角色及账号；2.资产入库：集团与下属公司之间资产独立管理，集团与下属子公司查看资产权限独立区分开；3.资产折旧：可按各公司的资产小类进行折旧统计；4.查询与统计：固定资产折旧明细表可进行数据穿透查询；5.系统模块：系统所有已制单据浏览查看权限限制；6.系统模块：跟踪系统所有在制单据审批情况；7.系统模块：增加针对审批人对所有已发出的单据提前预先知情功能；8.系统模块—实现系统语言实现繁简体互换功能。 2015年10月20日，鲁晓向崔波发送邮件，称“关于补充协议中付款的三个节点，我方有几点意见如下：1.补充协议中第一阶段时间节点：‘完成功能性验收’，我方先认同，但鉴于去年验收时的情况，请你方制定测试方案（技术开发合同9.6列明了测试流程及内容，你方应妥善测试后才系统交付我方验收，不应再出现边验收边修改的情况）；制定验收计划，验收内容包括集团本部及子公司孙公司所有系统功能、管理功能、导入输出功能等；进行验收时，系统内应已有各公司所有数据，因去年已发现数据导入错误，故验收前应重新导入所有数据并备份。2.补充协议中第二阶段时间节点：‘集团本部系统上线试运行’，我方认为不够全面并不认同。软件试运行验收应包括：集团本部及子公司孙公司系统上线试运行是否运行正常；集团本部及子公司孙公司核对数据是否准确；你方此时应监测系统运行情况，如系统效能存在问题应提出解决方案。”10月26日，鲁晓向崔波发送邮件，询问补充协议的进展并要求回复。 2015年11月27日，鲁晓向崔波发送邮件，要求胜龙公司统计开发进度，尽快将开发工作进度记录提供给联合出版公司。 2015年12月30日，鲁晓向崔波发送邮件，称“今年11月中旬我司与您沟通时了解到系统二次开发工作已基本完成，可以按时于今年12月底完成开发工作。我司了解到项目开发进展工作顺利，今年内有望完成的情况后，经我们双方协商条款具体内容一致，我方同意签订补充协议，唯需要您方提供项目进展报告，工作实施计划作为协议附本。您当时承诺将责由项目小组负责人一周内提供进展报告，且会尽快联络我方，具体解释并提供项目进度及未来工作安排计划。但11月底时由您提供给我司的《香港联合出版社二次开发工序及工期安排》文件中，未见到项目有任何完成进度，我方不理解是何原因，屡次询问项目小组负责人均无法联系到，您也未给予任何回复。现在已至12月底，二次开发工作本应于此时完成，开始进行下一步测试验收工作，是否可以如期进行？如无法按时进行，是何原因，您方对于我司项目有何安排？预计何时可以完成？自2011年项目开展至今，我司整个集团及子公司已为项目投入了大量时间、人力、物力、财力，迫切希望系统可以尽快上线使用。请贵公司慎重考虑，妥善安排，尽快回复。” 2016年3月8日，鲁晓向崔波、施智华发送邮件，称“关于我公司的固定资产管理系统，自去年我们双方议定二次开发相关内容后，已无实质进展。2016年第一季度现已过大半，你们对我们公司项目有何安排和计划？请尽快给出具体答复。” （三）联合出版公司主张的经济损失 在原审诉讼过程中，联合出版公司确认其经济损失计算依据如下：1.2012年11月13日，联合出版公司以中华商务贸易公司的名义向胜龙公司支付了7970元用于购置1套固定资产系统标签打印机。胜龙公司于2012年8月16日向联合出版公司出具了人民币8250元发票。2.金额为港币61800元的服务器发票，按结算月对应的汇率折合人民币50081.04元；3.2014年12月16日-2016年12月15日伺服器延长保用期费用19052元港币，按结算月对应的汇率折合人民币15661.35元；4.2012年3月28-31日培训费用人民币7646元；2012年5月30日-6月1日培训费用人民币8599.2元；5.购买培训手册港币2000元，按结算月对应的汇率折合人民币1581.03元。 在原审庭审中，胜龙公司确认其收到本案起诉状的时间为2018年8月9日，据此，联合出版公司变更其第1项诉讼请求为：请求确认涉案合同于2018年8月9日解除。 原审法院认为，联合出版公司与胜龙公司于2011年10月15日签订的涉案合同，系双方真实意思表示，内容未违反相关法律法规的规定，应属有效，双方均应依约认真履行。 （一）关于涉案合同的用户需求 根据涉案合同第一条的约定，胜龙公司在其现有的“胜龙科技资产管理信息系统”基础上为联合出版公司定制“联合出版（集团）有限公司固定资产管理系统”。根据涉案合同附件《胜龙科技资产管理信息系统解决方案》4.1.3亦明确涉案系统基于胜龙公司原有资产管理系统的基础上进行定制开发。因此，胜龙公司与联合出版公司共同确定涉案系统的用户需求，是涉案系统定制开发的基础。 为此，联合出版公司向原审法院出具了用户需求确认书6.5，其电子属性显示“最后一次保存者彭亮”、“最后一次保存的日期2012/3/2213:47”。针对该用户需求确认书6.5的最终确定时间，胜龙公司不予认可但未提供相应的反驳证据。根据联合出版公司钟燕与胜龙公司彭亮于2012年3月16-22日期间的QQ聊天记录表明，彭亮于2012年3月16日将流程调研版6.4发送给钟燕，于3月20日再次将流程调研版6.5发送给钟燕，于3月22日13：48将修改好的流程调研版6.5最终发送给钟燕，而钟燕于当天14：03回复彭亮，确认“没什么问题了”。虽然上述聊天记录所述的流程调研版6.5与用户需求确认书6.5名称上存在差异，但联合出版公司称流程调研版6.5即为用户需求确认书6.5，而胜龙公司未能提交上述聊天记录所述的名称为“香港联合出版集团业务流程调研最终版本6.5”文件，且胜龙公司对双方最终确定了用户需求确认书6.5并不持异议，故原审法院可以推定上述流程调研版6.5即为涉案系统的用户需求确认书6.5。虽然钟燕在3月22日的回复中称詹峰“会安排时间确认签字的”，但联合出版公司与胜龙公司均未提交双方签字盖章确认的用户需求确认书6.5，且双方对用户需求确认书6.5的内容均不持异议，根据彭亮与钟燕均确认用户需求确认书6.5内容的聊天记录，原审法院认定涉案系统的用户需求确认书6.5的最终确定时间为2012年3月22日。此后，胜龙公司本应根据用户需求确认书6.5开发涉案系统。 根据《胜龙科技资产管理信息系统解决方案》和用户需求确认书6.5可知，涉案系统包括多个处理模块，模块之间存在密切关联，其逻辑结构一旦发生实质性改变，必然导致各模块之间的接口衔接、数据生成和传输等系列问题发生变化，则属于用户需求的实质性变更。 但是，在涉案系统上线测试后，胜龙公司除了修改系统出现的BUG之外，还应联合出版公司的要求进行了涉案系统的部分结构性调整，在如下证据里有所体现： 从2013年12月17日鲁晓与彭亮的来往邮件得知，涉案系统于2013年12月前已经上线进行测试，出现IE浏览器兼容性不好、财务折旧模块问题较多等情形。此后，双方就涉案系统的用户需求调整、模块测试先后顺序、数据导入、资产分类方法调整、预算导入等诸多问题不断沟通、解决，有些问题得以解决，有些问题双方依然存在分歧意见。涉案系统交付上线后至2014年1月下旬期间，因测试出的问题并不多，胜龙公司的开发团队基本抽调到别的项目上。因此，当涉案系统后续测试反映出多方面问题时，胜龙公司希望先把系统稳定后再修正折旧计算问题，以应对开发人员回调期间的空档。2014年1月21日彭亮回复鲁晓的邮件体现了双方在涉案系统的模块测试及修复方面的意见分歧。从2014年5-6月的双方来往邮件亦能获知，双方就涉案系统上线测试及修改等问题多次沟通，胜龙公司认为涉案系统属于全部重新定制开发的系统，依据较粗需求形成的原有设计在测试过程中重新确认和校验导致需求不断修改。2014年6月19-20日彭亮与鲁晓的来往邮件亦载明，《固定资产管理系统行政验收标准》是根据用户需求确认书6.5基础上，各项系统维护功能、生命周期管理流程及2014年5月底至6月初双方共同商议之修改方案进行验收。2015年7月15日鲁晓与李**程等人的来往邮件亦载明，用户需求确认书6.5”在测试过程中简化了一些步骤，删除了一些审批环节……去年时曾经改过一版需求2014.6，文字内容作了一些精简。图表由原项目组改了一部分，还有待修改的部分已标出。另有盘点部分功能还需最终确定。”由此可见，涉案系统在上线测试后，根据联合出版公司相关单位及部门的反馈意见，胜龙公司在用户需求确认书6.5基础上确实存在调整、修改用户需求的情形。 基于上述问题，联合出版公司与胜龙公司曾经协商确认二次需求并签订补充协议，并在2015年1月16日双方协商涉案系统重新开发的需求框架，在2015年8月26日会议沟通二次需求确认的相关问题。2015年10月18日，胜龙公司崔波向联合出版公司鲁晓以邮件方式发送了补充协议、二次需求确认函及实施计划。2015年10月20日，鲁晓回复崔波，针对补充协议提出相应意见。虽然鲁晓于同年12月30日向崔波发送邮件，表示联合出版公司同意签订补充协议，但质疑胜龙公司未按《香港联合出版社二次开发工序及工期安排》完成项目进度，并要求胜龙公司提供项目进展报告、工作实施计划作为协议附件。最终，联合出版公司与胜龙公司未能签订补充协议，亦未在二次新增需求确认函上签字确认，导致涉案系统搁置至今。 （二）关于本案的诉讼时效问题。 根据涉案合同第四条第（二）款的约定，联合出版公司应于合同签订生效之日起15日内向胜龙公司支付50%的软件总价款266400元。而联合出版公司于2011年12月1日才向胜龙公司支付此笔款项，依照涉案合同约定的付款时间，联合出版公司延迟一个月向胜龙公司支付首笔款项，构成违约。因此，胜龙公司开发涉案系统的时间可以顺延一个月。 涉案合同附件《胜龙科技资产管理信息系统解决方案》9.3项目实施计划明确需求调研应于涉案合同签订后1周内开始，工作周期为10个工作日。根据上述约定，联合出版公司与胜龙公司应于2011年11月初确定涉案系统的用户需求。但是，联合出版公司与胜龙公司于2012年3月22日才最终确定涉案系统的用户需求，逾期4个多月，明显不符合涉案合同附件所约定的确定时间。基于涉案系统的用户需求确认应当由联合出版公司与胜龙公司配合完成，在案证据不能表明此项工作逾期的原因系单方责任所致，故由此导致涉案系统开发计划不能如期完成，双方均负有责任。 虽然涉案合同第六条约定“本合同自2011年10月15日至2013年10月14日在香港/北京履行”，但联合出版公司与胜龙公司的来往邮件及沟通记录表明，涉案系统的用户需求在不断调整，直至2015年8月26日双方还在视频会议沟通涉案系统的盘点功能升级及预算汇总提示功能，拟共同确认新增的二次用户需求，拟签订涉案合同的补充协议。然而，胜龙公司于2015年10月18日将补充协议与二次需求确认函的最终稿发给联合出版公司后，双方并未签字盖章予以确认。上述事实表明，涉案合同约定的合同履行期限在实际履行过程中已经发生变更，联合出版公司鲁晓于2016年3月8日向胜龙公司崔波和施智华发送的邮件至少表明双方仍未明确终止涉案合同的履行。原审法院于2016年9月7日受理本案，联合出版公司提起本案诉讼的时间并未超过法律规定的诉讼时效期间，故胜龙公司依据涉案合同第六条约定的合同履行期限主张本案超过诉讼时效，缺乏事实和法律依据，原审法院不予支持。 （三）关于涉案合同的解除问题 本案中，胜龙公司收到联合出版公司的首笔合同款后，于2012年3月22日与联合出版公司共同确定涉案系统的用户需求确认书6.5，并参与联合出版公司的多次员工培训。由于联合出版公司与胜龙公司均未向原审法院提交2012年3月22日-2013年11月期间的证据证明其履约的具体情况，如前所述，胜龙公司是在其原有资产管理系统的基础上定制开发涉案系统。联合出版公司与胜龙公司于2012年3月22日共同确定的用户需求确认书6.5是胜龙公司开发涉案系统的依据。但是，胜龙公司所开发的涉案系统上线测试后，联合出版公司的相关部门及关联公司提出了许多反馈意见，导致涉案系统的用户需求发生了很大变化，超出了涉案合同约定的修改范围，应当属于新增的用户需求。最初，胜龙公司同意调整用户需求并据此修改涉案系统。如前所述，随着涉案系统用户需求的不断变更，双方开始协商重新确认二次新增需求并据此签订补充协议等事宜，但是，双方最终未达成合意。鉴于胜龙公司依据用户需求确认书6.5开发的涉案系统在上线测试后，已经进行了相应的调整和修改，但依然未能满足联合出版公司的实际需求，而双方又未能就涉案合同的后续用户需求调整及涉案合同的后续履行等问题达成一致意见，胜龙公司已无履行涉案合同的事实基础和实际必要，亦无法继续开发和完善涉案系统。在此基础上，联合出版公司主张胜龙公司根本性违约致使合同目的无法实现，从而要求解除涉案合同。原审法院认为，如前所述，上述后果并非胜龙公司单方行为所致，并不能据此认定胜龙公司构成根本性违约。联合出版公司依据《中华人民共和国合同法》第九十四条第（四）项规定主张解除涉案合同，缺乏事实和法律依据，原审法院不予支持。 本案中，涉案合同约定的涉案系统用户需求发生了实质性变更，但联合出版公司与胜龙公司未就后续开发意向达成合意，涉案合同既无继续履行的基础，亦无必要，联合出版公司依据上述法律规定同样有权解除涉案合同及相应附件。本案中，联合出版公司起诉主张解除涉案合同，胜龙公司于2018年8月9日收到联合出版公司的起诉状，因此，原审法院确认涉案合同于2018年8月9日解除。 （四）关于解除涉案合同的法律后果 综观上述事实，原审法院认为，联合出版公司与胜龙公司均存在用户需求调研不细致、系统开发难度评估不当、涉案系统出现问题双方沟通不顺畅等诸多问题，而联合出版公司对系统上线的修改问题所产生的风险缺乏足够认识，最终导致双方无法继续履行涉案合同，主观上均存在过错，双方理应承担各自产生的经济损失及相应的法律后果。 联合出版公司主张胜龙公司返还已支付的合同款及赔偿损失。原审法院认为，虽然联合出版公司向胜龙公司支付了首笔合同款266400元，但是，自2011年10月15日至2016年3月8日鲁晓向施智华等人发送的最后一封邮件时间，历经四年多时间，胜龙公司为涉案系统的开发付出了相应的人力、物力和财务，并于2013年12月前将涉案系统上线测试。尽管涉案系统未达到双方的预期合同目的，但双方对此均应承担相应的法律责任。因此，联合出版公司的上述主张，缺乏事实和法律依据，原审法院不予支持。 原审法院判决：（一）确认联合出版公司与胜龙公司签订的《技术开发合同》及其合同附件于2018年8月9日解除。（二）驳回联合出版公司的其他诉讼请求。案件受理费6769元，由联合出版公司负担3769元，由胜龙公司负担3000元。 二审中，当事人均未提交新证据。 原审查明的事实基本属实，本院予以确认。 本院认为，本案的二审争议焦点问题是：涉案合同未能全面履行的原因及责任承担。 本案中，联合出版公司上诉提出，涉案合同因胜龙公司根本违约而未能全面履行；胜龙公司则认为，其已开发交付了符合合同约定的软件产品，涉案合同未能全面履行，系因联合出版公司不断变更要求所致。对此，本院评述如下： 在案证据反映，联合出版公司与胜龙公司于2011年10月15日签订涉案合同。根据涉案合同及其附件的相关约定，涉案软件系在胜龙公司原有资产管理系统的基础上，根据联合出版公司的具体要求进行定制化开发的软件，并非一个全新的开发方案，其主体架构应大体与胜龙公司已有的成熟软件基本一致。双方原本约定的需求调研工作周期为自合同签订后10个工作日，根据联合出版公司需求完成系统的相关功能修改和本地化定制开发工作的工作周期为35个工作日。同时，根据约定，软件开发与软件系统安装部署、基础数据初始化、软件系统培训以及试运行、上线测试等流程时间上部分重合，基本上同步进行。但在实际履行过程中，自合同签订后，直至2012年3月22日，双方才完成了需求确认（也即用户需求确认书6.5），实际耗费时间数倍于预计时间。此后，至2013年12月，胜龙公司向联合出版公司交付了初步的软件成果，实际开发时间同样也数倍于预计时间。由此可以推断，在合同签订之初，双方对于涉案软件的开发难度、所需时限均缺乏正确的评估。 对于计算机软件开发业务而言，软件开发方在最初签订开发合同时，并不能真正全面地了解客户需求，也因此，通常情况下，双方会在签订合同后，由开发方再行进行详细的客户需求调研，以确认最终的客户需求，而且在实际开发进程中，上述已确认的客户需求及其软件实现方式也会随着开发的不断深入存在变更的可能。本案涉案软件系联合出版公司拟自行使用的固定资产管理软件，相较于软件开发方，联合出版公司对于其自身管理业务的复杂程度应有更为直观的认识。因此，虽然联合出版公司作为委托方，并非软件开发单位，胜龙公司作为软件开发方，更具有评估软件系统开发难度的技术优势，但若将软件系统开发难度的评估责任完全归咎于胜龙公司，就本案的事实而言，也有失公允。 根据双方聊天记录反映的情况，在胜龙公司向联合出版公司交付了初步开发成果后，直至2014年9月30日，双方一直就软件测试、修改、培训、验收进行反复沟通，且在此过程中，双方参与人员相对稳定，沟通也较为顺畅，胜龙公司对于联合出版公司提出的修改要求响应及时，履约较为积极。其中所涉修改内容，既有软件开发自身不完善之处，也有应联合出版公司及其下属公司测试、培训过程中根据工作需求提出的新增需求，且双方于2014年5月至6月期间，共同商议修改了技术方案，调整了验收标准，同时，在该时段，双方开始商议签署补充协议，拟变更第二、三次付款条件，但未能签订补充协议。2014年9月30日之后，胜龙公司项目经理多次变更，胜龙公司重新组建了项目组，双方协商了软件系统重新开发的需求框架，重新确认了需求和开发进度，但项目进展缓慢。至2015年7月后，双方再次较为密切地沟通项目推进事宜，胜龙公司根据双方对软件需求的详细沟通情况，出具了解决方案，拟与联合出版公司就二次需求予以确认，双方就二次需求确认及补充协议事宜进行了磋商，胜龙公司希望联合出版公司尽快签署二次需求确认函及补充协议，联合出版公司则认为需在胜龙公司提交开发进度报告后再予以签署，至当年末，双方未能签署二次需求确认函及补充协议，项目至此陷入僵局。 从上述履约过程可见，自2011年10月15日签约，至2015年底双方最终未能就二次需求确认和签订补充协议达成一致，项目最终停滞，历时4年有余。胜龙公司在向联合出版公司交付了最初的开发成果后，根据联合出版公司的要求，在长达近2年的时间里，反复对涉案开发软件进行了修改完善，客观上投入了大量人力、物力，对于联合出版公司而言，同样也势必造成公司人财物损失及管理损耗。如前已述，双方最初均未能准确评估项目实施的难度和所需时间，在软件开发过程中，联合出版公司也不断根据测试、培训过程中发现的情况提出更为细节的要求，根据聊天记录反映的情况，其中不乏超出双方已确认的项目需求确认书中的内容，远超出胜龙公司对于涉案软件开发难度的最初设想。在项目久拖不决且双方对于签署二次需求确认函和补充协议进展不畅的情况下，胜龙公司客观上难以继续履行软件开发义务，最终合同未能全面履行。本院认为，就主观方面而言，胜龙公司与联合出版公司总体上均秉持了认真诚信履约的态度；就客观情况而言，合同未能完整履行，双方均承担了巨大的商业风险和经济损失。造成上述结果的原因较为复杂，并非由单一原因所致，如简单认定系因胜龙公司根本违约导致合同目的不能实现，有失公平。在此情况下，原审判决认定，不能认定胜龙公司构成根本违约，由双方承担各自产生的经济损失及相应的法律后果，系综合权衡各方利益所作的较为公平的判定，符合公平原则。故，对于联合出版公司关于胜龙公司构成根本违约并要求胜龙公司返还已支付合同款并赔偿损失的上诉主张，本院不予支持。 综上所述，联合出版公司的上诉请求不能成立，应予驳回；原审判决认定事实清楚，适用法律正确，应予维持。依照《中华人民共和国民事诉讼法》第一百七十条第一款第一项规定，判决如下： 驳回上诉，维持原判。 二审案件受理费6768.84元，由联合出版（集团）有限公司负担。 本判决为终审判决。 审判长 焦 彦 审判员 钱建国 审判员 魏 磊 二〇二〇年十一月六日 法官助理刘乐 书记员韩丰 裁判要点                            案  号                       （2019）最高法知民终712号                               案  由                       计算机软件开发合同纠纷                               合 议 庭                       审判长：焦 彦             审判员：钱建国、魏 磊                                                     法官助理：刘乐                       书记员：韩丰                               裁判日期                       2020年11月6日                               关 键 词                       计算机软件开发；技术合同；违约；合同解除                               当 事 人                       上诉人（原审原告）：联合出版（集团）有限公司；             被上诉人（原审被告）：北京胜龙科技股份有限公司。                               裁判结果                       驳回上诉，维持原判。             原判主文：一、确认联合出版（集团）有限公司与北京胜龙科技股份有限公司签订的《技术开发合同》及其合同附件于2018年8月9日解除。二、驳回联合出版（集团）有限公司的其他诉讼请求。                               涉案法条                       《中华人民共和国合同法》九十四条、九十七条                               法律问题                       软件开发合同中对软件开发难度评估的责任分担问题                               裁判观点                       对于计算机软件开发业务而言，软件开发方在最初签订开发合同时，并不能真正全面地了解客户需求，也因此，通常情况下，双方会在签订合同后，由开发方再行进行详细的客户需求调研，以确认最终的客户需求，而且在实际开发进程中，上述已确认的客户需求及其软件实现方式也会随着开发的不断深入存在变更的可能。尤其是对于涉案软件系委托方拟自行使用的管理软件而言，因相较于软件开发方，委托方对于其自身管理业务的复杂程度有更为直观的认识。在此情况下，虽然软件开发方更具有评估软件系统开发难度的技术优势，也不宜将软件系统开发难度的评估责任完全归咎于软件开发方。                               注：本摘要并非判决书之组成部分，不具有法律效力。