单位

数量

（一）广东省政法跨部门大数据办案平台广州分中心（市检察院分平台）二期项目

广东省政法跨部门大数据办案平台广州分中心（市检察院分平台）二期项目

项

1

指标项

技术规格要求

补充材料

此业务需求涉及大约80余个业务（80余个业务主要根据一期对接业务估算，包含普通案件和未检案件），其中每个业务涉及到收发各两个共4个流程节点的定制开发，合计需要定制研发300余个补充材料的对接流程节点。

（1）通知补充材料

当检察机关作为通知补充材料单位：

1.1、抽取检察院业务系统对应案件的案件基本信息、补充信息等相关的数值信息和代码信息，把检察院的标准转换为中心平台确定标准，按照政法委平台约定的特定格式规范封装构成XML文件。

1.2、将检察机关制作补充说明文书抽取出来，同步做好盖章校验，必备文书校验。在XML中构造好文书指引信息并统一打包，同步做好数据包的加密，并按照约定规范传输并调用政法委平台提供的数据处理接口。

当检察机关作为接收材料单位：

1.3、接收外单位“补充材料推送”数据包，根据对应配置模板映射关系对数据包进行解压，解析出案件基本信息、补充信息等数值信息项和代码信息项，将时间、日期、单值代码等字段转换成检察机关业务系统能识别的字段，并导入到不同的业务数据表中，导入的信息需要满足检察业务应用系统2.0的案卡数据项校验规则。

1.4、接收外单位移送补充的文书或卷宗材料，并导入到检察机关业务应用系统2.0的文书或卷宗区中。

（2）补充材料推送

当检察机关作为接收材料单位

2.1、接收外单位“补充材料推送”数据包，根据对应配置模板映射关系对数据包进行解压，解析出案件基本信息、补充信息等数值信息项和代码信息项，将时间、日期、单值代码等字段转换成检察机关业务系统能识别的字段，并导入到不同的业务数据表中，导入的信息需要满足检察业务应用系统2.0的案卡数据项校验规则。

2.2、接收外单位移送补充的文书或卷宗材料，并导入到检察机关业务应用系统2.0的文书或卷宗区中。

当检察机关作为补充材料单位：

2.3、抽取检察院业务系统对应案件的案件基本信息、补充信息等相关的数值信息和代码信息，把检察院的标准转换为中心平台确定标准，按照政法委平台约定的特定格式规范封装构成XML文件。

2.4、将检察机关制作补充说明文书抽取出来，同步做好盖章校验，必备文书校验。在XML中构造好文书指引信息并统一打包，同步做好数据包的加密，并按照约定规范传输并调用政法委平台提供的数据处理接口。

涉案财物流程对接

（1）接收涉案财物

1.1、接收其它政法单位移送的包含“涉案财物”的数据包，根据对应配置模板映射关系对数据包进行解压，解析出案件基本信息、涉案财物基本信息、外单位处置意见等数值信息项和代码信息项，将时间、日期、单值代码等字段转换成检察机关业务系统能识别的字段，并导入到定制化开发的涉案财物功能模块对应数据表中。

1.2、接收外单位移送的涉案财物清单等相关文书，并导入到检察机关业务应用系统2.0的文书卷宗区中。

（2）移送涉案财物

2.1、抽取定制化涉案财物功能模块中涉案财物基本信息、处置意见等相关的数值信息和代码信息，把检察院的标准转换为中心平台确定标准，按照政法委平台约定的特定格式规范封装构成XML文件。

2.2、将检察机关制作的涉案财物附件、物品清单、处置意见书等文书抽取出来，同步做好盖章校验，必备文书校验。在XML中构造好文书指引信息并统一打包，同步做好数据包的加密，并按照约定规范传输并调用政法委平台提供的数据处理接口。

涉案财物功能模块定制开发

（1）功能模块定制化开发

对涉案财物处置意见功能做定制化功能开发，对涉案财物相关页面做定制化开发，支持对外单位移送的涉案财物信息列表进行查看、预览详情、修改意见等功能，实现对外单位移送的涉案财物后台数据的管理。

（2）处置意见生成

初始化加载处置意见，检察官可对其进行修改，尽量减少办案人员工作量，针对多个涉案财物相同处置意见可以同时给出意见。

（3）处置意见文书生成

定制化本地处置意见文书模板，根据办案人员处置意见系统自动按照文书模板生成处置意见文书。

未检专项流程对接

（1）附条件不起诉

附条件不起诉听取意见

1.1、抽取检察院业务系统对应案件的附条件不起诉听取意见相关字段，包含案件基本信息、嫌疑人基本信息等相关的数值信息和代码信息，把检察院的标准转换为中心确定标准，按照政法委平台约定的特定格式规范封装构成XML文件。

1.2、将检察机关制作的附条件不起诉听取意见书等法律文书抽取出来，同步做好盖章校验，必备文书校验。在XML中构造好文书指引信息并统一打包，同步做好数据包的加密，并按照约定规范传输并调用政法委平台提供的数据处理接口。

反馈意见

1.3、接收公安机关移送的反馈意见数据包，根据对应配置模板映射关系对数据包进行解压，解析出案件基本信息、反馈意见信息等数值信息项和代码信息项，将时间、日期、单值代码等字段转换成检察机关业务系统能识别的字段，并导入到不同的业务数据表中，导入的信息需要满足检察业务应用系统2.0的案卡数据项校验规则。

1.4、接收公安机关移送的反馈意见书等相关文书，并导入到检察机关业务应用系统2.0的文书卷宗区中。

附条件不起诉决定

1.5、抽取检察院业务系统对应案件的附条件不起诉决定相关字段，包含案件基本信息、嫌疑人基本信息、决定信息等相关的数值信息和代码信息，把检察院的标准转换为中心确定标准，按照政法委平台约定的特定格式规范封装构成XML文件。

1.6、将检察机关制作的附条件不起诉决定书抽取出来，同步做好盖章校验，必备文书校验。在XML中构造好文书指引信息并统一打包，同步做好数据包的加密，并按照约定规范传输并调用政法委平台提供的数据处理接口。

解除取保候审决定

1.7、抽取检察院业务系统对应案件的解除取保候审决定相关字段，包含案件基本信息、嫌疑人基本信息等相关的数值信息和代码信息，把检察院的标准转换为中心确定标准，按照政法委平台约定的特定格式规范封装构成XML文件。

1.8、将检察机关制作的解除取保候审决定书抽取出来，同步做好盖章校验，必备文书校验。在XML中构造好文书指引信息并统一打包，同步做好数据包的加密，并按照约定规范传输并调用政法委平台提供的数据处理接口。

（2）未成年犯罪记录封存/解除通知

通知封存未成年人犯罪记录

2.1、接收法院移送的通知未成年人犯罪记录数据包，根据对应配置模板映射关系对数据包进行解压，解析出案件基本信息、嫌疑人基本信息等数值信息项和代码信息项，将时间、日期、单值代码等字段转换成检察机关业务系统能识别的字段，并导入到不同的业务数据表中，导入的信息需要满足检察业务应用系统2.0的案卡数据项校验规则。

2.2、接收法院移送的通知封存未成年人犯罪记录的相关文书，并导入到检察机关业务应用系统2.0的文书卷宗区中。

通知解除未成年人犯罪记录

2.3、接收法院移送的通知解除未成年人犯罪记录数据包，根据对应配置模板映射关系对数据包进行解压，解析出案件基本信息、嫌疑人基本信息等数值信息项和代码信息项，将时间、日期、单值代码等字段转换成检察机关业务系统能识别的字段，并导入到不同的业务数据表中，导入的信息需要满足检察业务应用系统2.0的案卡数据项校验规则。

2.4、接收法院移送的未成年人犯罪记录基础通知相关文书，并导入到检察机关业务应用系统2.0的文书卷宗区中。

（3）深化原有协同流程涉未成年人案件条件必填逻辑

主要针对公安提请批准逮捕阶段协同、公安移送审查起诉阶段协同、检察院审查逮捕阶段协同、检察院审查起诉阶段协同、法院审理、判决阶段协同、司法未成年人法律援助数据协同等流程进行数据项收发完善。

与公安业务流程对接

主要根据需求中罗列出的相关字段诉求，在已建设的业务流程中追加相关字段

（1）审查逮捕 增加以下结构化数据项返回：

是否有补侦意见

（2）变更强制措施 增加以下结构化数据项返回：

决定机关

法律帮助流程对接

（1）抽取检察院业务系统对应案件的法律帮助相关字段，包含案件基本信息等相关的数值信息和代码信息，把检察院的标准转换为中心确定标准，按照政法委平台约定的特定格式规范封装构成XML文件。

（2）将检察机关制作的法律帮助等文书抽取出来，同步做好盖章校验，必备文书校验。在XML中构造好文书指引信息并统一打包，同步做好数据包的加密，并按照约定规范传输并调用政法委平台提供的数据处理接口。

程序性风险监督、案件评查适配改造

研究检察分平台数据交换子系统与中心平台的对接逻辑，对程序性风险监督及案件评查进行配套改造，同时也为下一步扩展和调整预留空间。由于具体实施的复杂性和不确定性，在深化设计阶段进一步进行需求确认，以确保最终方案的可行性和有效性。

系统对接

（1）协同对接接口

检察院业务协同子系统与其他政法单位进行数据交换，需要与政法协同平台进行对接，而政法协同对接对于检察院而言就像一座桥梁，用于连接公安、法院、司法局，从而实现与他们之间的业务协同办理与数据共享。

根据数据对接的方式方法进行分析，数据对接交换主要分为：接收数据和发送数据。由于对接在技术层面本身是没有业务的所以在对接设计时仅需要考虑方式与流程即可，而业务是需要在数据中去体现、然后在对应的子系统中去衔接。

针对对接的流程与对接技术、下面描述检察院与政法协同平台系统交互过程所产生的发送设计和接收设计。

1.1系统对接

系统对接方式

协同平台与各政法单位对接时，以前置服务器为边界，通过文件交换的方式从前置服务器获取数据与发送数据。

协同平台与各政法单位业务系统对接涉及两种数据类型：协同业务数据和消息数据。其中，协同业务数据是用于各单位业务系统间需要交换的业务数据；消息数据为保障业务数据的可靠传输与各业务系统间通信的数据，同时平台提供数据校验机制，对各系统发出的数据进行校验后，通过消息反馈数据校验结果。

系统对接应满足以下要求：

1、各政法单位发送业务数据时，将业务数据以及文书卷宗文件压缩成交换数据包ZIP文件，放到当前政法单位的前置服务器发送目录。

2、各政法单位接收业务数据时，从当前政法单位的前置服务器接收目录获取数据包，并对数据包解压，解析处理。

系统对接流程

1、接收数据流程

检察院接收数据包，首先对数据包进行处理，处理成功后，检察院需要反馈接收成功消息给发送机关，如果检察院处理数据失败时，要反馈接收失败消息给平台，平台根据错误信息重新给检察院发送数据包。

2、发送数据流程

发送数据有以下步骤：

1.检察院发送数据时，先将数据打包后，将数据发送到前置区发送目录。

2.政法协同平台从前置区发送目录接收到数据后，对数据包进行校验，校验完后数据包的校验结果，反馈给检察院校验消息，校验失败时，检察院应该根据错误信息重新打包数据并发送。当数据包验证成功后，平台将数据发送到接收机关前置交换服务器上的接收目录。

3.接收机关收到数据包后，对数据包进行解析，当系统解析成功后，反馈给检察院接收成功的消息。

系统对接目录规范

公检法司各政法单位的前置服务器上，目录的命名规则：

XTXX+政法单位类型+发送/接收类型(send/receive)+数据类型(data/msg)

公检法司各政法单位的前置服务器上，发送接收目录按照规范要求进行：

1.2数据包结构

一、数据包整体结构

数据包包含结构化和非结构化数据。其中，案件信息、嫌疑人信息、强制措施信息等属于结构化数据，文书信息、卷宗信息、其他附件信息属于非结构化数据。

二、数据包命名规则

各政法单位发送和接收的数据包命名规则一致。

命名规则：

协同业务代码_协同流程节点编号_发送单位代码_接收单位代码_UUID_MD5码.zip

（1）协同业务代码：用于标识该协同业务。

（2）协同流程节点编号：协同流程中对应的流程节点标识。

（3）发送单位代码：数据包发送方的单位代码。

（4）接收单位代码：数据包接收单位的单位代码。

（5）UUID：标识数据包的全局唯一标识，由发送单位生成，使用32位UUID作为数据标识；

（6）MD5码：数据包的MD5码。

注：各信息项之间使用“_”分隔。

三、数据存储规范

（1）结构化数据，用XML文件存储，

（2）非结构化数据，以文件形式存储在数据包对应的目录下，并在结构化数据对应标签中说明存放路径。其中目录存放规范如下：

1、文书文件放在数据包的WSXX目录下，并在<WSXX>节点中说明文书在相对数据包的存放路径；

2、卷宗文件放在数据包的DZJZ目录下，并在<DZJZ>节点中说明文书在相对数据包的存放路径；

3、其他类型的文件，例如音频、视频等附件信息，放在QTFJ目录下，可以根据需要自行划分子目录。

四、业务信息结构

交换信息结构描述了业务协同环节的业务场景，定义了各业务流程的结构化数据和非结构化数据标准。为各政法单位改造业务系统提供详细的数据标准。

（1）业务数据文件名规则

业务数据xml文件名称,统一命名。

（2）业务数据文件结构

业务数据文件格式为XML文件，由五部分内容组成，包含协同信息、案件信息、文书信息、电子卷宗、其他附件。

（3）文件内容结构

1、协同信息

协同信息用于标识数据的发送方和接收方等协同交换信息。数据发送方组装此信息，协同平台根据协同信息里的接收单位进行数据转发。

2、协同案件编号信息

（1）例如起诉案件，检察院向法院提起公诉、此流程为起始流程、那么检察院把移送的案件编号存入此节点中，可携带多个编号。

（2）法院收到此信息后、对起诉做出了“立案”的决定，此时法院的发送时应通过叠加的方式把法院的案件编号存放到此标签内，同时把检察院移送来的编号原路返还（若涉及到其它单位、操作一样）

3、案件信息

案件信息根据业务数据规范进行XML定义。其中，XML的层级使用分类信息的中文简拼，XML的节点使用数据项的中文简拼。使用XML可以方便的描述出案件的各类信息，便于各业务系统解析和处理XML信息。

案件数据项为代码类型的，需要参考代码标准进行代码转换。

4、文书信息

文书信息由标签<WSXX>标签组成，一个文书标签允许多个文书，每个文书由<R>标签组成，文书包含文书名称、文号、文书路径等内容。若文书需要附带结构化数据，结构化数据写在XML文件的<R>子标签<JGHSJ>中，各文书根据结构化数据自行定义。

5、电子卷宗

电子卷宗由<DZJZ>标签组成，一个案件可以包含多个卷，每个卷由目录和文件组成层级结构。

卷宗信息XML与卷宗格式对应，分为卷宗、目录、文件三部分。

电子件卷宗的内容存放在专门的电子卷宗区域，卷宗信息由标签<JZJBXX/>进行组成，因为电子卷宗存在多个卷，每个卷以<JZMLJ/>进行组成，每个卷下由多份卷宗文件组成，每个文件以<JZWJ/>进行组成，卷宗文件必须为PDF格式文件。

1.卷宗基本信息，一个卷宗基本信息一个节点，包含多个子节点，子节点为目录信息。

2.卷宗目录，父节点为卷宗基本信息，包含多个子节点，子节点为卷宗文件。

3.卷宗文件，父级为目录信息，一个文件标签一个节点。

五、其他

（1）平台统一编号

案件在各业务流程中流转时，协同平台定义平台统一编号信息项，将同一案件的不同业务流程关联起来，并提供查询案件办理的全流程信息。刑事案件办理时，公安对新案件提起逮捕时，由协同平台生成平台统一编号，附加到协同信息中，并将新平台统一编号发送给接收单位与发送单位，后续业务流转时各政法部门业务系统发送数据时要携带该案件的平台统一编号。

平台统一编号的生成规则如下：

年月日+协同单位类型+组织机构代码+当天4位序列号

（2）数据校验规则

协同平台和接收单位在接收到数据包后，对接收到的数据进行校验

1.3消息机制

一、概述

数据包发送和接收过程中，会有数据解析失败、数据校验失败、数据处理失败等情况，对于这些情况，平台与政法单位间通过消息来完成非业务流程节点的信息交换。消息类型有四种，分为数据校验消息、数据发送消息，业务受理消息和业务退回消息。

二、消息命名规则

消息数据文件的格式是XML，消息的命名规则为：

消息发送单位_消息接收单位_消息类型_UUID.xml。其中：

（1）消息发送单位：代表消息的发送单位。若消息是平台发送的，则对应的发送单位代码字段定义为0；

（2）消息接收单位：代表消息的接收单位，

（3）消息类型：用于标识该消息是数据发送消息、数据校验消息、业务受理消息、业务退回消息。

（4）UUID：如数据接收消息或数据校验消息则与对应的交换数据包名中的数据标识一致，如通知消息无对应的交换数据包则该消息的发送单位重新生成32位UUID。

三、消息类型

1、数据校验消息

发送单位发送数据到前置服务器后，平台收到数据包，根据数据校验规则对数据包进行校验，校验内容包含数据包名称规范、文件是否损坏、MD5是否吻合。平台校验完成后将校验结果反馈给发送单位。发送单位如果收到数据校验失败的消息，需要重新发送数据包。（此消息是平台发送的，对应的发送单位代码字段定义为0）

接收单位从前置服务器的接收目录获取数据包后，接收单位也要根据数据校验规则对数据包进行校验，校验内容包含数据包名称规范、文件是否损坏、MD5是否吻合。接收单位校验完成后将校验结果反馈给发送单位。发送单位如果收到数据校验失败的消息，需要重新发送数据包。

2、数据发送消息

平台校验数据包成功后，当成功把数据包发送到接收单位的前置机接收目录时，会给发送单位发送数据发送消息。

（2）检察业务应用系统2.0对接设计

2.1系统对接说明

协同子系统与检察业务应用系统2.0的对接涉及三种数据接口：接收接口、移送接口和消息接口。其中，接收接口用于协同子系统将其他政法单位移送的数据上传至检察业务应用系统2.0；移送接口用于将检察业务应用系统2.0中相关数据下载至协同子系统；消息接口为保障协同子系统与检察业务应用系统2.0间数据及时、可靠传输提供支持。

系统对接协调由采购人负责，系统对接落实由中标人负责，费用包含在报价中。

2.2业务流程说明

协同子系统与检察业务应用系统2.0的对接可抽象为两种场景，一种是接收流程（向检察业务应用系统2.0写入数据），另一种是移送流程（从检察业务应用系统2.0获取数据）。

2.3接收流程

接收流程数据流转说明：

1.协同系统接收到外部系统移送数据并入库后，将待接收案件信息推送至检察业务应用系统2.0。推送信息中应该包含协同KEY值、协同主键、案件状态等信息。

2.检察业务应用系统2.0通过URL地址跨系统调用协同系统案件详情展示页面。调用时，检察业务应用系统2.0会在URL地址中增加用户信息供协同系统进行用户认证等操作。

3.在协同子系统案件详情页面确认是否接收案件，案件接收分为多种情形：

（1）新案件接收

主要表现为需要检察业务应用系统2.0新建案件，生成统一受案号及部门受案号。调用案件受理接口实现受理，需要由各厂商自行组装受理向导界面。

1.新案件接收时，调用检察业务应用系统2.0创建新案件接口进行案件受理。

2.接口调用后，反馈案件受理结果、部门受案号信息，协同系统通过反馈的部门受案号信息完成案卡、文书、卷宗上传接口的调用，完成案件受理动作。

（2）已协同已有案件接收

主要表现为该案件已进行过协同办理，且已在检察业务应用系统2.0中完成受案，协同案件与检察业务应用系统2.0案件之间已建立关联关系。

1.已协同已有案件接收时，调用检察业务应用系统2.0相关接口获取案件信息，并与协同移送信息进行差异比对提供数据筛选功能。

2.Ø筛选时由用户确定案卡、文书、电子卷宗信息是否需要上传，根据实际情况调用案卡、文书、卷宗接口完成受理动作。

（3）未协同已有案件接收

主要表现为该案件未进行过协同办理，但已在检察业务应用系统2.0中完成受案。此时，协同案件与检察业务应用系统2.0案件之间需要手动建立关联关系。

1.未协同已有案件接收时，调用检察业务应用系统2.0相关接口获取在办案件信息列表，选择检察业务应用系统2.0中对应案件。

2.调用检察业务应用系统2.0相关接口获取案件信息，并与协同移送信息进行差异比对提供数据筛选功能。

3.筛选时由用户确定案卡、文书、电子卷宗信息是否需要上传，根据实际情况调用案卡、文书、卷宗接口完成受理动作。

4.受理完成后，协同系统向协同平台（政法平台）反馈受理成功消息，同时调用检察业务应用系统2.0推送待接收案件信息接口，更新待接收案件状态为已受理、已反馈。

2.4移送流程

移送流程数据流转说明：

1.用户在检察业务应用系统2.0中确定送案后，将移送消息推送至消息中心。

2.协同系统订阅移送消息，获取移送标识编号、移送内容编号启动移送服务。

3.协同系统根据订阅消息内容，根据实际需要调用案卡、文书、卷宗下载接口获取案卡、文书、卷宗信息。

4.协同系统将获取的案卡、文书、卷宗信息进行数据清洗转换成协同统一标准格式并完成打包，发送至协同平台。同时调用检察业务应用系统2.0推送待接收案件信息接口将案件状态修改为已发送。

5.协同系统接收到协同平台发送反馈消息后，调用推送待接收案件信息接口将案件状态修改为已发送，对方已收到。

标的提供的时间

中标人必须在合同签订后12个月内完成软件开发、测试、部署上线和初验，并交付采购人试运行；试运行三个月内并通过相关安全评估工作后，由项目单位主管部门统筹合同验收。合同验收通过后再由市政务服务数据管理部门组织项目终验工作。

标的提供的地点

采购人指定的地点。

付款方式

1期：支付比例25%,详见“采购需求”。

2期：支付比例30%,详见“采购需求”。

3期：支付比例30%,详见“采购需求”。

4期：支付比例15%,详见“采购需求”。

如项目发生合同融资，采购人应当将合同款项支付到合同约定收款账户。

验收要求

1期：本系统在推广实施之前，中标人需对产品进行模拟环境测试和实际环境下的试运行，包括文档验收、程序验收与测试结果评审等几项工作。 1、试运行验收 在完成用户要求的客户化定制开发和软件安装部署工作后，投标人可申请试运行验收，经采购人同意后，进行试运行验收。 在试运行验收前，投标人应做好以下工作：制定验收方案，完成相关验收文档的整理，包括需求文档、设计文档、操作手册、应用单位安装实施报告、数据字典等。所有文档应以书面、电子两种形式提交采购人。 2、最终验收 在试运行验收通过后，投标人需完成所有本项目系统的配置信息初始化及专项定制工作，并进行全面推广，全面推广工作完成后，投标人可申请最终验收，经采购人同意后，开展最终验收。 在进行最终验收前，投标人应做好以下工作：相关的实施报告，试运行阶段运行记录，项目验收报告，应用系统的相关需求分析文档、系统设计文档、系统测试文档、软件用户操作手册、软件培训资料以及采购人需要中标人提供的验收文档等。最终验收的结果要求提供由参加项目终验各方签字的最终验收报告，并且给出最终验收的明确结果。通过最终验收后，即进入系统运行维护阶段。

履约保证金

不收取

其他

序号

品目名称

标的名称

单位

数量

分项预算单价（元）

分项预算总价（元）

所属行业

技术要求

1

其他信息技术服务

广东省政法跨部门大数据办案平台广州分中心（市检察院分平台）二期项目

项

1.00

732,480.00

732,480.00

软件和信息技术服务业

详见附表一

参数性质

序号

具体技术(参数)要求

1

详见“采购需求”。

说明

 打“★”号条款为实质性条款，若有任何一条负偏离或不满足则导致投标无效。
打“▲”号条款为重要技术参数，若有部分“▲”条款未响应或不满足，将导致其响应性评审加重扣分，但不作为无效投标条款。