第6章　符合性证书与车辆身份数据

6.1　从车型批准到每一辆车

整车型式批准解决的是某一车辆型式能否按照适用制度获准生产和投放市场的问题。符合性证书（Certificate of Conformity，CoC）则把这一批准与一辆已经制造出来的车辆联系起来：制造商以车辆识别代号（Vehicle Identification Number，VIN）识别该车，声明其符合相应批准，并给出该车的具体技术特征。型式批准证书由批准机关签发，CoC由制造商签发，两者分别对应型式批准与单车符合性声明。2018/858第36条所规定的对象包括完整车、非完整车和完成车；GB适用时应结合英国修订后的条文，而不能直接照搬欧盟原文。[S01，第36条；S03，regulation 28]

CoC与车辆注册证书具有不同的法律功能。英国驾驶员与车辆牌照局（Driver and Vehicle Licensing Agency，DVLA）办理注册后形成的V5C记录注册号码、登记保有人和车辆信息。CoC是注册所使用的技术与符合性证据之一，不代表进口税务手续已经完成，也不代表车辆已经注册。对进口车辆，英国税务与海关总署（HM Revenue & Customs，HMRC）的车辆到达通知（Notification of Vehicle Arrivals，NOVA）、批准证据和DVLA注册分别处理不同事项。[S06；S07]

因此，制造商内部应当同时维护三种关系：批准号对应获批范围；VIN对应实际制造状态；注册号码对应登记记录。把这三种标识放在同一数据库中可以便于追溯，但不得把任何一个标识当作另外两个状态已经成立的证明。

单车CoC的使用还取决于批准有效性及适用的法规过渡条件。2018/858第35条涉及批准失效，第48条将相应车辆的市场投放、注册或投入使用与有效CoC联系起来。电子化不会使已经失去适用性的批准重新有效，也不会替代库存车辆过渡或单车批准所需的判断。[S01，第35、48条；S03，regulations 27、32]

6.2　CoC签发责任与制造阶段

6.2.1　签发责任与代办权限

CoC的法律声明由制造商作出。对于纸质CoC，2018/858第36(6)条进一步要求签字人受雇于制造商，并获正式授权，就车辆设计、制造或生产一致性承担制造商的法律责任。外部咨询机构可以协助整理资料、生成文件和实施提交，但“获准操作账户”不等于“成为CoC签发主体”，也不当然具备替代制造商员工签署纸质CoC的资格。[S01，第36(6)条]

企业应将四类权限分别管理：批准参数的维护权、逐车数据的确认权、符合性声明的签署权和电子文件的提交权。建议由法规部门维护批准主数据，生产与质量部门确认实车状态，制造商授权人员批准签发，获授权的账户用户执行提交。服务商参与时，应按制造商分别保留授权和账户边界，不以同一个服务商账户混合提交不同制造商的车辆。

这一账户边界也是英国车辆认证局（Vehicle Certification Agency，VCA）现行电子符合性证书（electronic Certificate of Conformity，eCoC）安排的明确要求：可由制造商或获准使用制造商账户的人员提交，但不允许第三方账户代表多个制造商提交。[S04，Security and authenticity]

6.2.2　完整车、非完整车与完成车

完整车（complete vehicle）已经完成相应制造过程；非完整车（incomplete vehicle）仍需后续阶段才能满足完整车辆的相关要求；完成车（completed vehicle）是通过多阶段批准完成制造的车辆。纸质CoC模板按制造状态区分：2020/683附件VIII第2点将Model A用于完整车、Model B用于完成车、Model C用于非完整车；完整车模板内部还应按附件选择适当的A1或A2，而非统一套用一张M1乘用车表。[S02，Annex VIII，points 2.1—2.3及Appendix]

非完整车CoC反映该制造阶段已确定的参数，最终车身尺寸、座位数和质量由相应后续阶段确认。第36(8)条允许基础非完整车只填写与其完成状态相关的内容。后续阶段则依据第36(9)条反映本阶段的增加或变更，并在适用时附上前阶段CoC。[S01，第36(8)、(9)条]

多阶段CoC通过各阶段声明、参数及变更记录建立连续的符合性关系。基础车批准与最终阶段批准、各阶段制造商及文件版本都必须可以识别。最终阶段如改变车身、质量或受控系统，必须先判断改变是否已被本阶段批准覆盖，然后才能决定CoC如何填写。

6.2.3　批准路径决定文件路径

GB批准、UK(NI)批准和EU批准的CoC不能仅凭销售目的地或文件语言相互替换。对于使用EU批准在北爱尔兰投放的车辆，VCA现行指引将eCoC提交对象指向相应EU型式批准机关；对于GB或UK(NI)批准，则采用相应的英国提交安排。双重批准、双重标识或北爱尔兰货物流通安排，均不等于两套数据系统已经互联。[S04，FAQs：EU eCoCs及EUCARIS]

单车批准（Individual Vehicle Approval，IVA）是另一条证据路线。DVLA填表指南明确区分CoC与IVA证书的取值和填写方式。没有整车型式批准的车辆，不能通过制造一张CoC或上传一个XML文件取得该批准路线的法律地位。[S08，第11—14栏说明]

6.3　纸质CoC：模板、声明与防伪

6.3.1　CoC模板的法定结构与逐车参数

2020/683第8条及附件VIII规定纸质CoC的模板和要求。其第一部分是制造商的符合性声明，第二部分是按车辆类别设置的技术特征。附件VIII第0点要求体现VIN、制造日期和该车的具体参数；原则上不能用车型参数范围代替该车确定值，车辆自身性质确有需要的情况除外，例如可伸缩底盘挂车。第1.3点要求技术描述来自有关型式批准文件。[S02，Article 8；Annex VIII，points 0、1.1—1.3]

这意味着，同一批准下存在不同轴距、轮胎、电机或质量状态时，CoC必须落到该VIN实际对应的组合。逐车参数以实际装配且获批的配置组合为依据，批准资料中的全部可选配置另作范围管理。

GB纸质文件还应采用英国化的法律文字。SI 2022/1273的regulation 28将第36(5)条语言要求改为英语；regulation 86(9)修改附件VIII中A1、A2和B模板有关车辆适用性的声明文字，将原文有关成员国永久注册的表述调整为“is suitable for”。相关转换同时涉及批准身份、模板及具体声明内容。[S03，regulations 28(1)(d)、86(9)]

历史模板宽限应单独识别。SI 2022/1273插入的第36(1A)条，对2026年7月6日前制造、同时具有有效EU批准的车辆，允许采用EU法下2020/683模板并按GB CoC处理。这一规定带有制造日期和双批准条件；不能因为eCoC执行安排延至11月，就自行认定纸质模板宽限也同步延长。[S03，regulation 28(1)(b)]

6.3.2　纸张和防伪措施

附件VIII规定纸质格式最大为A4，并要求使用彩色图形，另至少采用一种规定的防伪措施：制造商注册标志形式的水印，或其他防伪印刷特征。后者包括紫外荧光油墨、变色油墨、微缩印刷、定制全息图等。纸张、签署及防伪措施须共同满足上述要求，扫描签名或二维码的采用范围据此评价。[S02，Annex VIII，points 1.2、3]

企业文件系统应将“受控纸质原件”“原件扫描件”“供查看的PDF”和“结构化eCoC”分别标识。扫描件便于传递，但扫描动作本身不会使其成为满足结构化提交要求的eCoC；二维码也只是信息入口，其指向的记录、访问能力和真实性保障仍需单独管理。

首次随车提供的纸质CoC不得另行收费或以买方另行申请为前提。第36(3)条还规定，车辆制造后十年内，车主提出要求时，制造商应出具明确标有“duplicate”的纸质副本，收费不得超过出具成本。补发副本与纠正错误记录是两个不同动作：前者再现已经正确签发的内容，后者必须处理错误来源及旧记录的后续使用。[S01，第36(1)、(3)条]

6.4　带注释的CoC样例及参数来源

以下为假设的GB批准M1纯电动汽车（Battery Electric Vehicle，BEV）完整车样例，保留附件VIII的主要字段编号，用于解释数据关系。名称、代码、日期和数值均为教学假设；VIN和批准号采用占位符。本样例是注释性节选，不是可供签发、注册或提交的完整证书。字段基于已核阅的2020/683附件VIII基础模板及本章列出的GB修订；实际签发应使用该批准档案中的受控模板。[S02；S03]

6.4.1　身份与批准关联

身份字段校验涵盖批准号、制造商、型式/变型/版本、制造阶段和实车配置之间的对应关系。同一商业名称下的不同驱动形式可能具有不同版本；同一VIN也可能出现在不同阶段的合法文件链中。因此，只按商品名称匹配数据不够，只按VIN判断多阶段记录重复也不够。

6.4.2　技术参数节选

本例的能耗及续驶里程采用全球统一轻型车辆试验程序（Worldwide harmonised Light vehicles Test Procedure，WLTP）对应数据；其试验与计算依据应回指第3章技术专篇，不由CoC生成程序另行创设。

上述功率字段编号依据附件VIII的M1模板：27.3为最大净功率，27.4为最大30分钟功率。电耗单位Wh/km与kWh/100 km应保留明确转换关系：本例175 Wh/km等于17.5 kWh/100 km。换算可以由系统完成，但不能据此改变原始结果的精度和法规取整口径。[S02，Annex VIII，Appendix，M1 Part 2]

质量也应保留定义。2,550－2,055＝495 kg只能说明在本例口径下距离技术允许最大总质量的差额，不能直接宣称“可载货495 kg”。使用载荷仍受乘员、轴荷、牵引、实际装备及适用道路使用条件约束。企业规则应分别校验整车质量上限和轴荷上限，两类限制分别形成校验结果。

6.4.3　动力形式与车辆类别对应的字段要求

燃油车、非外接充电混合动力车、外接充电混合动力车和纯电车，在附件VIII的排放与能耗部分采用不同适用项目。插电式混合动力汽车（Plug-in Hybrid Electric Vehicle，PHEV）涉及的加权组合结果与相应充电状态结果不能混写；纯电车不能因没有发动机排量，就把所有不适用的排放字段自动填为数值零。“不适用”“未提供”和“测得为零”应在企业数据层保留为不同状态，再根据目标模板和实际XSD决定输出方式。[S02，Annex VIII，Appendix，M1 Part 2，points 23、48、49]

M2/M3的载客状态、N2/N3的轴组和组合质量、O类的联接与受载情况，应按各自类别模板维护。对于没有动力系统的挂车，不能套用乘用车数据结构后用大量零值填满。对于特殊用途车辆，应保留相应用途和批准限制；涉及氢动力时，应按具体燃料电池或发动机结构选择实际适用字段，而不能用“新能源”作为共同数据类别。[S02，Annex VIII，各类别Part 2]

6.5　批准参数与逐车数据的映射

纸质CoC与XML依据同一组受控事实生成，保持数据来源和版本一致。以下为建议的企业数据组织方式，并非VCA规定的数据库架构。

作为数据组织示意，可以将关系表达为“批准档案＋逐车制造记录→受控数据快照→纸质CoC与UK IVI各自输出”。纸质交付进入适用的随车文件链；已签署UK IVI经VCA提交形成相应电子记录；DVLA注册所需数据另按注册程序提供。两种输出可共用事实来源，但此关系不表示每辆车在任何时期都必须同时提供纸质和电子文件，也不表示VCA与DVLA已自动同步。

建议在签发前设置三组检查。第一组检查身份和覆盖：批准号及扩展是否有效，型式/变型/版本是否存在，制造商与代表是否相符，实装组合是否被覆盖。第二组检查技术语义：总质量与轴荷是否各自满足条件，动力字段是否适用，电耗与续驶里程是否来自同一配置和试验制度。第三组检查输出：纸质模板、XML结构、单位转换、字符长度、枚举及签署是否符合各自要求。

这里必须区分“格式校验”和“事实校验”。将175 Wh/km误填为17.5 Wh/km，可能仍是一个符合XSD数值类型的合法字段；将V20误选为V18，两个代码也可能都在允许列表内。只有把数值与批准资料和实车记录作关联核对，才能发现这种错误。

建议保留逐字段来源，例如批准资料页码、报告编号、制造系统记录号、计算程序版本和人工批准记录。文件哈希用于标识某次提交的文件及其完整性，数值真实性由对应的源数据与审核记录支持。系统审计日志和源文件应与签发记录共同保存；共同支持提交内容的可追溯性。

6.6　UK eCoC的范围、过渡和系统边界

6.6.1　2026年11月29日是现行VCA执行安排中的制造日期节点

截至本章资料检索截止日，VCA于2026年8月28日更新的专门指引要求：GB或UK(NI)批准下的M、N、O类车辆，自2026年11月29日起新制造的车辆进入强制eCoC提交范围，包括GB中批量和UK(NI)欧洲小批量；GB和UK(NI)国家小批量不强制转换，可以继续使用纸质CoC。[S04，Scope及Implementation plan]

该指引明确，11月29日前制造的车辆，不因其在该日以后注册而被要求追溯提交eCoC；未提供eCoC时仍须免费提供纸质CoC。对进入强制范围并完成eCoC提供的车辆，不再要求常规随车纸质文件，但特殊情况下仍可能被要求出具纸质副本。[S04，FAQs：paper CoCs及vehicles built before 29 November]

需要保留法律与执行安排的区别。已核阅的2018/858第36、37条基础文本采用2026年7月5日；VCA将11月29日解释为英国交通部（Department for Transport，DfT）同意延长的过渡安排。本次取得的修法材料尚未完成这一新日期的完整法律衔接核定。11月29日据此确认为VCA现行执行日期；对应法律文本的修订依据仍待进一步核实。[S01，第36、37条；S03，regulation 28；S04]

对于项目组织，制造日期、eCoC签发日期、上传日期和注册日期应分别保存。制造日期以真实生产记录为依据，与文件导出时间分别保存。多阶段车辆还应分别识别各阶段制造事件，而不是直接以基础底盘的制造日期替代最终阶段日期。

6.6.2　车辆类别、批准路径与时间条件

表内前五项依据VCA现行eCoC指引；IVA文件关系依据DVLA填表指南。该表不代替第1章关于批准适用和第16章关于北爱尔兰流通条件的判断。[S04；S08]

6.6.3　UK eCoC与EU数据系统的衔接边界

UK eCoC采用基于EU初始车辆信息（Initial Vehicle Information，IVI）2.0的XML结构，并增加英国批准信息。XML是结构化数据文件；XSD，即XML Schema Definition，是规定其结构、数据类型和约束的模式文件。英国系统不与EUCARIS互联，也不是EU体系的国家访问点（National Access Point，NAP）。已经在一个EU国家提供数据，不能据此推定VCA已经取得该车的GB记录。[S04，eCoC data and format；FAQs：EUCARIS]

VCA的提交门户和应用程序接口（Application Programming Interface，API）已于2026年6月17日上线；公开按VIN检索及下载原始XML的第二阶段服务，现行指引仍列为上线时间待定。制造商提交门户可查看自身记录，不应被当成查询所有品牌车辆的公共数据库。对于未提交的车辆，也不能从数据库没有记录反推其没有合法纸质CoC。[S04，Implementation plan及Access to eCoC data]

6.7　UK IVI字段与版本管理

6.7.1　四类版本标识及其对应关系

VCA公开的UK IVI版本控制表将“UK 1.0 Corr”列为在用版本，发布日期为2026年5月22日，对应EU IVI 2.0的2026年5月8日发布版本；此前UK 1.0已标为被替代。修订涉及TyreTypeCode、MechanicalCouplingCanBeFitted及TypeApprovalTypeCode最大长度等内容。[S05]

项目中应分别保存：法律和模板版本；UK XSD发布版本；企业字段映射及生成程序版本；单车IVI记录版本。EU IVI 2.0与UK 1.0 Corr不是互相矛盾的版本号，分别描述不同层级；单车IviVersionNumber更不是车辆批准扩展号。

仅有版本控制表不足以完成接口验收。本次已核阅版本表和VCA字段说明，但未成功取得公开分享入口内的实际XSD原件，也未开展门户或API联调。因此，下述字段说明可用于业务设计，不作为已逐节点核对的数据字典；正式实施仍需对实际下载包的命名空间、导入文件、字段次序、必填性和枚举完成受控验证。

6.7.2　英国特有字段及其定义

VCA对初始UK IVI发布的补充说明明确列出以下差异。下表保留其公开字段/类型名称，不据此推定其XML父节点、层级或标签形式。[S04，UK-specific IVI elements及Supplementary guidance]

制造商已有EU XML生成系统时，可以复用经确认相同的技术数据和生成逻辑，但必须增加市场和批准路径映射，并用UK XSD完成最终验证。英国CoC与EU CoC的字段差异，以及纸质模板与电子数据的对应关系，需按具体定义和模式规则核定。

空值处理应单独设计。未适用字段是省略、空元素、特殊枚举还是其他表达，取决于实际XSD和业务规则。具体空值表示及XML结构以模式文件验证结果为依据。

6.8　签署、提交与回执的实际含义

6.8.1　签章与上传权限是两道不同控制

VCA现行指引要求UK eCoC包含数字签名，并说明当前接收系统检查签名是否存在，尚不对证书或密钥作进一步验证；无数字签名的文件会在上传阶段被拒绝。企业不能将“服务器接受了文件”理解为“VCA已经确认签章证书可信且文件内容真实”。[S04，Security and authenticity]

数字签名将所引用的数据与签名值和密钥关联；它本身并不定义密钥与某一法人之间的完整信任关系，也不证明车辆参数真实。[S10，第1、3.2节]

工程上，建议制造商在内部验证签名对应的文件内容、签署主体、证书适用性和可验证性，并保存签名前后文件及验证记录。应用程序接口的访问令牌用于请求接口权限，不是签名证书，也不是制造商对车辆符合性的声明。

XML数字签名（XMLDSig）与XML高级电子签名（XAdES）也不是两个绝对互斥的“证书格式”：ETSI EN 319 132-1第4.1条规定，XAdES在XMLDSig基础上增加签署和未签署的限定属性。[S10；S11，第4.1条]

具体XAdES元素、Transform及证书产品的接受条件，需依据实际UK XSD与签章验收规范确认。修改签章结构前，必须区分模式校验错误、签名内容错误、证书问题和服务器当前接受范围；不得以“现阶段只检查存在”为理由生成没有真实性保障的伪签名。

6.8.2　人工提交与API提交

人工路径的输入是已完成制造商内部放行、符合UK格式并已经签署的XML。VCA门户进行文件接收及格式检查，并向制造商反馈结果；制造商根据具体错误定位源数据、映射或签署问题，生成正确版本后重提，更正后的文件按要求重新签署。

API路径应先区分测试与正式环境。VCA要求先完成测试环境接入和成功测试，再申请正式环境访问。测试成功只是接入及预定测试场景成功，不能把测试库中的记录当作正式逐车提交。企业应分别保管两套凭据、环境配置和记录，并由责任开发人员处理一次性令牌信息。[S04，Submission of eCoC data及API Integration]

以下为建议的企业流程：法规部门确认批准及模板；质量部门确认逐车配置；数据程序生成未签名记录；系统执行结构和语义检查；授权流程完成签署；账户用户或API提交；责任人核对逐车反馈；最终将提交文件、回执和交付记录绑定到同一VIN及制造阶段。任何一步出现不符合，都应返回对应来源修正，相应控制项关闭后继续后续处理。

6.8.3　提交过程的状态层次与回执含义

提交过程分别记录传输、格式校验、记录识别及后续处理结果。以下是企业建议的控制层次，不是VCA官方响应代码或门户状态名称。

对于批量提交，还应形成逐车结果清单。建议对提交前数量、成功识别记录、拒绝记录和未获明确结果记录进行核销；在通信中断后先查询已有记录，再决定是否重试。未经实际接口规范确认，不应自行假定重复提交可无限覆盖、相同VIN只允许一条记录，或者一个HTTP成功响应必然意味着整批通过。

6.9　更正、补发与批准变更

6.9.1　错误来源与更正程序

记录更正适用于实车及批准覆盖正确，而CoC取值、身份关联或数据转换发生错误的情形。批准变更适用于产品或获批资料本身发生变化、需要按照2018/858第33、34条判断修订或扩展的情形。车辆实际装配超出获批范围时，更改CoC文字不能使车辆自动合格。[S01，第33、34、36条；S03，regulation 27]

因此，发现异常后建议先暂停受影响VIN的文件继续使用，核查实车、制造记录和批准范围，再作分类。制造日期错误要回到真实制造事件；VIN错误要核对实车打刻及记录关联；能耗错误要追溯配置和计算来源；批准号错误要确认是否只是录入问题，还是该车根本未获相应批准覆盖。

补发与更正也应区分。文件遗失而原内容正确，可以按副本制度处理；原内容错误，则需要更正、重新签发和下游处理记录。“duplicate”适用于规定的补发情形，内容实质变化另按更正或变更程序处理。

6.9.2　电子记录的版本与旧文件控制

VCA允许同一IVI文件在更正或更新时提交多个版本，使用IviVersionNumber记录，并在重复检查中考虑该版本。现行公开网页没有完整说明全部撤销、删除、误VIN处置及下游同步语义；多版本支持与旧记录的撤销、删除机制分别确认。[S04，FAQs：versions]

建议更正单至少记录原VIN与阶段、原记录版本、错误字段及旧值、正确值、错误原因、批准覆盖判断、受影响文件和下游对象、复核人、新签署文件及提交结果。错误VIN的更正同时涉及正确记录的提交及原错误记录的处置；后者需取得VCA明确意见并保留相应证据。

更正完成的判据应是：源数据已修复；重新生成的文件已验证和签署；新提交结果已核对；旧文件被标明不再用于业务；已收到旧数据的注册、进口或交付环节已确认采取相应动作。仅在邮件中发出一份“更新版CoC”，不足以证明上述过程已经完成。

6.10　CoC与进口、注册数据的衔接

本章只说明数据衔接，不替代第14章的进口注册程序。对永久进口车辆，官方指南要求先处理HMRC通知及适用税费，并取得批准证据，再向DVLA申请注册。VCA eCoC入库与NOVA处理、DVLA注册属于不同结果，不能用其中一个回执代替另一个。[S06]

DVLA的V55/4用于新车首次注册，其V355/4指南（2025年5月版）明确说明多个栏位从CoC取得数据。以下列出与制造商数据治理关系最直接的项目；其中NEDC指新欧洲驾驶循环（New European Driving Cycle），与WLTP分列。[S08]

这一衔接展示了“一致”不一定等于所有系统保存完全相同的字符。例如，DVLA第19栏要求功率取整数，而CoC原数据可能保留小数。数据转换同时保留源值、转换规则和目标值，以维持原始精度及转换过程的可追溯性。[S08，第19栏]

VCA现行资料仍将与DVLA、英国驾驶员与车辆标准局（Driver and Vehicle Standards Agency，DVSA）的信息共享描述为研究潜在用途和实现方式。项目不能预先假定UK eCoC提交后，注册申请将被自动创建或V5C自动更新。采用批量注册系统的企业，应另行按其获准注册流程及接口要求接入，相应接口规范与V55/4人工申请说明分别采用。[S04，Access to eCoC data；S07]

车辆注册后，如V5C已有错误，仍应按DVLA的更正程序处理；改变eCoC不能被视为已经通知DVLA。官方指南明确要求纠正V5C错误，并对座位、燃料、特定重量、VIN和车身类型等变化规定相应处理要求。企业应由注册责任方确认所需证据及结果，制造商提供正确的技术证明。[S09]

6.11　案例一：轮胎配置错误对CoC与eCoC的影响

本例完全为假设，不对应真实车型、证书或VCA审核结果。设某GB批准M1纯电车有V18和V20两个已获覆盖的版本，差异涉及轮胎、实际质量和相应WLTP结果。涉事车辆于2026年12月2日制造，实际装用V20配置，但数据接口误按V18生成了CoC和电子文件。

两个版本都可能是合法代码，165和175也都可能满足数值格式。因此，单独的XSD校验无法证明选中了正确的车辆版本。按照本例假设，错误使质量少报35 kg，电耗少报10 Wh/km，即1.0 kWh/100 km，续驶里程多报25 km。该问题可通过VIN实装轮胎、配置代码与批准版本映射的交叉核对识别。

处理时，先冻结该VIN以及使用同一错误映射的其他车辆，抽取实车和生产记录，确认V20确已被适用批准覆盖。若覆盖成立，问题属于文件映射错误：修复映射；重算受影响批次；由制造商重新确认数据和签署；按实际接口规则提交新版本；核对正式反馈；停止旧文件使用。若已进入注册，注册责任方还应确认错误数据是否已进入DVLA记录并办理相应更正。

反之，若V20并未获批，或轮胎虽单独列于资料中但该组合未获覆盖，就不能沿用上述“数据更正”结论。此时必须先处理车辆恢复到获批状态、批准变更或其他合法处置，并按照实际结果决定后续文件。V20文件的签发及车辆放行，以实际配置获得相应批准覆盖为前提。

这一案例对应的法理是第36条关于车辆应符合批准型式的前提、第33和34条关于批准变更的机制，以及VCA的电子多版本安排。前两者决定能否签发，后者只解决电子记录如何表达更正。[S01；S03；S04]

6.12　案例二：基础底盘与上装后的完成车

本例假设制造商A供应已获批准的N1非完整底盘，制造商B实施上装并持有覆盖该组合的GB最终阶段批准。两阶段均在2026年12月制造，按适用路径进入eCoC范围。车辆保留本例设定的同一VIN，A、B分别就其制造阶段承担文件责任；本例不讨论更换底盘、重新赋码或脱离多阶段批准链的改装。

A的输入文件包应包含该VIN的基础阶段CoC/eCoC、有关批准识别、基础车参数和供后续制造所需的限制资料。B收到后，应先核对VIN、基础版本和自身最终批准允许接收的基础车组合，再按批准范围完成上装。底盘CoC存在并不证明任意车厢或尾板组合均可接受。[S01，第36(8)、(9)条；S02，Annex VIII，Model B/C]

假设基础阶段实际质量为2,050 kg，车厢净增加550 kg，附属设备净增加100 kg；各数值均采用一致定义，且无重复计入或拆除件差额。则最终实际质量为：

2,050＋550＋100＝2,700 kg。

再假设最终技术允许最大总质量为3,500 kg，当前两轴实际负荷分别为1,420 kg和1,280 kg，各轴技术上限分别为1,850 kg和2,250 kg。当前质量之和为2,700 kg，与整车记录一致；距离最大总质量的差额为800 kg，但它仍不是对任何装载分布均成立的可用载货量。

为了展示轴荷约束，进一步假设某个800 kg附加载荷位置对前轴造成100 kg减载、对后轴造成900 kg增载。则总质量达到3,500 kg，前轴变为1,320 kg，后轴变为2,180 kg，在本例技术上限内。如果另一个位置造成前轴减载200 kg、后轴增载1,000 kg，整车总质量仍为3,500 kg，但后轴达到2,280 kg，超过2,250 kg上限30 kg。总质量3,500 kg的上限与各轴允许载荷分别构成本例的校核条件。载荷分配数值为说明原理的假设，并非某辆车的试验结论。

B签发的完成车文件应正确识别最终阶段制造商、前阶段来源、最终批准和本阶段增加或改变的技术特征。A的基础阶段制造日期不能被直接复制为B的完成日期；最终长宽高、车身代码、实际质量和本阶段受影响项目，应有相应确认记录。不得用Model C的基础底盘文件代替Model B的完成车符合性声明。[S02，Annex VIII，Model B及相关Part 2]

电子提交方面，VCA要求后续阶段填写本阶段必填或适用的内容，不要求对非必填或未改变部分一概合并全部前阶段数据。企业仍应保存可追溯的前阶段文件链。若基础阶段使用EU批准，VCA将这种EU车辆作为多阶段构成部分的情况列为可能需要EU eCoC副本的情形；这与普通EU整车是否向VCA提交是两个问题。[S04，FAQs：multistage及EU eCoCs]

本例的完整交付结果应当是一条可审查的证据链：A的基础车批准和逐车声明，B的接收核对与上装记录，最终配置和质量确认，B的最终批准与逐车声明，以及对应提交和注册所使用的最新文件。只保存最后一份XML，无法解释前阶段责任和数据来源。

6.13　量产后的维护重点

从纸质方式转换为eCoC，本身并不要求对整车批准作修订或扩展；VCA明确允许原批准档案中的纸质CoC样本继续作为主要参考。产品、声明或批准数据本身发生变化，则是另一项判断。[S04，FAQs：type approval documentation]

CoC工作不会在第一辆车成功提交后结束。对新增选装件、轮胎或电机变更、软件改变受控性能、制造商或代表信息调整、工厂和制造阶段改变，以及批准扩展和法规过渡，企业应先判断批准与证据影响，再更新数据映射和签发控制。不得以生成程序仍可运行作为无需法规评估的理由。[S01，第33—36条；S03，regulation 27]

建议按批准版本建立发布清单，明确何时开始适用哪些配置和参数，以及哪些VIN已签发旧版本文件。程序和XSD升级时，应使用受控测试集验证正常车辆、各类动力、不适用字段、多阶段、重复提交和错误更正等场景；升级后保留与历史文件关联的旧规则，避免新程序重新导出旧车时悄然改变已签发事实。

本章的控制目标是建立从批准、制造、逐车声明到注册数据的可追溯关系。纸质与电子只是不同的交付形式，制造商的符合性责任、逐车事实的准确性和错误的闭环处理不会因电子化而消失。