NGCMS_DLV_业务需求规格说明书(核心接口)V10.docx

山东省农村信用合作社联合社
新一代信贷管理系统
[需求说明书]
——核心系统接口

山东省农信新一代信贷系统项目组
2012年04月

文档信息
文档名称：
山东省农村信用社联合社新一代信贷管理系统需求说明书——核心接口
初稿作者：
新一代信贷管理系统项目组
初稿日期：
2012-04-16
内容概述：
本文档是山东省农村信用社联合社新一代信贷管理系统（NGCMS）与新一代核心业务系统(NGCBS)涉及接口的业务需求说明，重点描述与原接口不同之处。两系统功能切换后的交互依据此进行设计开发。

版本修订历史

版本
修订日期
修订人
修改内容简述
1.0
2012-04-16
中创人员、新一代信贷管理系统项目组、核心技术人员、IBM人员
根据与核心三次讨论以及与IBM、中创技术人员讨论内容，补充完善。原《NGCMS涉及核心系统需求说明书-V1.4.doc》版本
1.1
2013-05-30
新一代信贷管理系统项目组
剔除并行期已经实现和验证的内容。根据新系统功能实现情况，对功能要求进行了调整。
1.2

1.3

1.4

1.1 概述
该文档描述内容为信贷业务办理中跨系统的功能需求，需要新一代信贷管理系统与核心系统协同改造；达到理清功能边界，顺畅业务，最大得发挥信贷与核心系统对业务提供支持的目的。避免出现因新一代信贷管理系统功能或业务规则变更、核心未更新，导致出现流程不衔接、功能重叠、控制冲突等影响业务办理问题。
1.2 客户信息
1.2.1 个人非身份证办理业务
1、 新一代信贷管理系统中证件类型丰富，允许个人客户以港澳台身份证、军官证、护照建立客户资料和办理信贷业务，允许对公同业客户以营业执照号或金融许可证号建立客户资料和办理业务。但核心存在如下问题：
2、 一、核心系统前端相关界面上，可选择证件种类只有身份证和组织机构代码证。
3、 二、通过接口可以成功建立合同和自下而上建立额度，但无法查询额度。
4、 三、核心返回的数据中，没有对非身份证号的客户编码进行处理，信贷无法正确解析出证件类型和证件号。
1.2.2 增加“金融许可证”证件类型存款开户等是否存在问题

在转贴现等同业业务办理中，交易对手存在较多分行或者支行级客户，特别是全国性的商业银行，更是无法直接与总行进行交易。分行、支行只具备独立的营业执照号和“金融许可证”，因此，需要在信贷系统和ECIF中增加对公证件类型“金融许可证”，能够以“金融许可证”建立客户信息和办理业务。
1.2.3 客户名称变更是否还允许变更名称。该处是否要求核心能够变更业务里的客户名称。需要和赵科确定。

客户名称变更，在核心系统认为是新增客户，不支持继承原客户下业务。信贷系统虽然继承原业务，但由于核心不更新，导致合同和放款业务不能继续办理。要求信贷系统明确告知操作员变更带来的问题。信贷管理系统中变更客户名称时，系统进行如下检查：
（1）不能有正在流程中的业务；
（2）不能有未使用的有效授权（发送核心尚未记账）；
（3）调用额度查询接口，查询客户是否存在有效额度，如果存在，提示操作员“原授信不可继续使用，原合同不能继续放款，原贷款只能结清，建议客户先进行业务结清”；
（4）检查客户是否存在贷款证，如果存在贷款证，提示变更后进行换证（卡）。
（5）提示变更后如需办理业务，需进行重授信。
（6）变更时，存在贷款证（卡）的，在贷款证关联相关表中记录名称变更标志。变更后发起贷款证下合同授权，系统控制必须先进行换证。系统对换发的第一个贷款证作颁发新贷款证处理，同时更新清楚名称变更标识。
1.3 额度管理非本次讨论内容。

1.3.1 额度管理需求
详细需求见《NGCMS_DLV_业务需求规格说明书(额度管理)》
1.3.2 额度管理方案
1.3.2.1 处理规则
1、 信贷与ECIF共管额度。在数据上收阶段，由信贷管理系统实现信贷额度的管控。
2、 ECIF系统管理客户全行额度，管理各业务条线的额度，控制信贷授信额度总额。
3、 信贷管理系统建立完整的额度管理机制，用来管理信贷系统业务额度产生和使用。
4、 ECIF保持现有额度品种不变，对额度层级和恢复机制进行改造。
5、 如果为信贷条线额度，只允许通过信贷系统接口进行建立和调整，不允许通过前端进行修改。
6、 合同建立即占用ECIF中信贷条线额度，合同失效恢复信贷条线额度的可用额。
7、 信贷条线额度不记录额度使用额。
8、 功能切换前，信贷与ECIF额度接口保持不变。
9、 功能切换阶段，信贷管理系统中额度移植到ECIF系统，作为初始的信贷条线额度。
10、 功能切换后，ECIF系统必须控制，不允许前台柜员通过额度维护交易，建立或维护信贷条线额度下的综合和单一额度。信贷条线额度及其下各层额度只能通过系统自动处理维护。
1.3.2.2 业务流程
1、 信贷管理系统新增授信和进行授信调整后，需要将信贷中授信总额同步到ECIF系统，ECIF系统保存为信贷条线授信额度。
2、 合同建立时，ECIF系统根据合同产品，在信贷条线额度范围内，自下而上建立单一额度和综合额度。
3、 额度自下而上建立时，采用已有规则进行额度扩充，但允许自动扩充信贷条线额度。
4、 如果为自下而上模式，信贷系统中的组合额度、综合额度和单项额度无需同步到ECIF。
5、 需要自上而下模式建立额度的，信贷在授信完成时，调用ECIF的额度建立或修改接口，同步相应业务综合额度。允许自上而下模式建立的额度必须为信贷和ECIF系统中额度品种一一对应的。
6、 信贷管理系统每次完成授信，调用额度接口，将额度信息同步到ECIF系统，如果ECIF中原不存在，建立额度信贷条线额度，如果已经存在，进行额度调整。
1.3.2.3 信贷条线额度管理范围
一期信贷条线额度不包含电子银行承兑额度、再贴现额度、外币类贸易融资业务额度、信用卡额度。除此之外的信贷业务额度审批均属于信贷管理系统。信贷管理系统授信审批时，将暂时禁止选择这些产品或方式。
1.3.2.4 实现时机
功能切换后，实现信贷与ECIF共管额度；并行期，额度接口保持不变。
1.3.2.5 敞口授信问题
信贷采取敞口授信规则进行额度核定，核定的额度为剔除保证金后的金额。因此，在额度扣减时，按照合同金额剔除保证金金额后的差额扣减。信贷一期中，只剔除保证金，不进行其他风险敞口折算。
1.3.2.6 同步核心额度状态
功能切换前，需要ECIF系统提供额度状态为冻结的额度明细，信贷系统据以更新信贷中额度的状态。
1.3.2.7 需要再确定问题
核心柜员是否有权对信贷条线额度进行操作，如何解决核心柜员对客户中心额度维护导致的对信贷额度影响。
1.3.3 修改额度相关接口
包括额度新增、调整、冻结解冻、锁定解锁、申请、查询等接口。
1.4 新系统上线后额度问题
1.4.1 贷款证综合额度解冻问题
存量数据中存在通过贷款证综合额度冻结、解冻接口进行冻结的贷款证综合额度。由于移植到新信贷中的数据不包含授信信息，且新系统无贷款证综合额度冻结、解冻接口，造成客户只在核心冻结综合额度的情况。此情况下，通过核心3746交易解冻时，常出现交易不成功，或者虽然交易成功完成，但信贷授信或者调整综合额度时，仍然提示综合额度被冻结的情况。请核心完善综合额度冻结、解冻交易。
1.4.2 贷款证综合额度多头控制问题
新系统中，贷款证综合额度期限会涵盖合同期限，因此，如果合同提前结清或者注销，综合额度可能尚未到期，此时，信贷是允许客户转移到新机构办理贷款证业务的。但是，在新机构在进行贷款证授信时，系统会因在不同机构下已经存在了贷款证综合额度而拦截，致使业务无法办理。
由于新系统与老系统业务要求不同，因此不能采取老系统将授信到期日修改为当天的做法。需要采取其他更合理的方案解决该问题。
1.5 合同管理
1.5.1 合同建立
1、 在功能切换阶段，合同建立接口的数据要素，根据业务需求双方系统进行讨论确定。需要重新确定接口，包括字段枚举的一致性等，例如还款方式、利率调整方式等核心提供目前合同要素表，以及要素说明。信贷业务人员在此基础上分析确定新接口数据。
。
2、 修改系统默认字段为可选择字段：
3、 新增合同要素：
1.5.2 合同修改
1、参照江苏农信接口规则，综合考虑银行承兑、保函、委托贷款等各类业务，确定新的合同接口。包括，新增、调整。
1.5.3 合同循环使用
1、 循环合同。目前，核心系统未按照信贷系统确定的合同是否循环标志控制，而是从核心产品参数中获取的默认值。除贷款证外不支持一般贷款合同的循环放款。但信贷业务中，合同是否循环不完全取决于产品，同一产品的合同，循环方式可以不同。因此，需要核心使用信贷合同界面选择的是否循环标志。
2、 是否允许循环使用，由信贷系统在建立合同时给核心。如果循环使用的合同，在合同有效期内，状态正常的合同，每次还款后，合同可用额度自动恢复。
3、 两系统合同循环属性不同，如果信贷循环核心不循环，会造成信贷授权成功，但记账放款时提示可用额不足。
1.5.4 合同分次放款
4、 原特殊处理业务。支持助学贷款、承兑、社团贷款特殊业务的分次授权。要求3001放款时，上述业务同一般业务处理，使用信贷的授权业务号，核心不再自动生成授权号。
5、 提款期控制。信贷系统需要启用最长提款期控制，超过最长提款期后不允许再新建借据。
1.5.5 合同注销同步
核心主动注销信贷合同的，需要将注销信息同步到信贷系统。建议通过批量方式。
1.6 联保合同本人建议去掉。理由是原需求对业务抽象存在偏差。联保合同应为协议与合同的结合。系统实现上应为先协议，后合同。合同取协议内容作为共用内容，而每个合同有相对独立性。如此，逻辑清晰，也符合业务实际，系统实现简单，业务处理灵活。是否决定取消，大家投票决定。

1.6.1 达成共识
1、 业务要求，联保方式进行的用信，只审批一次。多个借款人签订一个合同。
2、 信贷系统控制，每个联保借款合同下最多借款人为99人。
3、 由信贷管理系统通过联保合同方式合并审批，满足业务需求。
4、 在调用合同建立接口时，采用“联保合同业务号+序号”作为每个联保成员的合同号，核心按照现有规则每个客户建立一个合同。
5、 核心不支持一个合同多客户的需求，合同建立按照现有模式处理，一个合同所属客户必须唯一。
6、 业务已经确认，一次建立100个合同能够满足业务需求。
7、 技术方面，无论采取何种方式方案，需要能够支持合同建立、调整、失效等处理。

1.7 存款账号相关接口目前已经实现，但只校验账号是否存在。这个需求是否还需要？大家发表意见。

1、新增账户校验接口，对信贷输入的在信用社开立的贷转存、客户结算账户、自动扣款账户、保证金账户、基金账户、贷款账号等校验。
2、区分业务类型的不同，分别校验的账号内容不同。校验内容主要包括，账号所属客户与借款人是否为同一客户、账号状态是否正常、保证金余额与约定的保证金金额大小关系，委托基金账号状态及与委托方客户是否属同一客户，贷款账号在核心中是否存在等。
3、两系统间可实现输入后即调用检查。目前，信贷管理系统需求为，在输入页面提交时对本页面输入的账号进行检查。主要包括，授信发起、合同签订发起、授权、合同维护等节点。
1.8 押品出入库
1、 押品出入库流程：一、信贷人员在生效合同前，将他项权利证书等需要入库保管的凭证或者实物交核心柜员。二、柜员收妥入库，通过核心交易记表外账务，打印入库凭证，盖章后将回单提供一联给信贷人员。三、信贷人员将回单扫描入信贷管理系统，登记押品已入库，并生效合同。四、在贷款结清或者其他原因需要临时出库时，信贷人员通过信贷管理系统押品管理中的出库功能，登记出库原因，并打印出库凭证，交会计人员。五、会计人员核实后，核心进行押品出库账务处理及实物交接。将信贷出库通知书作为附件收入传票。
2、 核心凭证格式修改。核心修改凭证打印格式，增加信贷人员及柜员签章栏位，凭证加印信贷人员回单联。
3、 信贷新增出库通知书打印功能。信贷系统增加出库通知书打印功能。字段包括，信贷机构名称、核心核算网点号、客户证件号码、客户名称、合同流水号、押品名称、押品编号、数量、价值，出库原因字段（贷款结清、临时出库）。
1.9 贷款发放
1.9.1 授权规则
所有通过信贷管理系统办理的业务，必须使用信贷产生的授权业务号（凭证流水号、授权业务号+序号）。包括助学贷款、社团贷款大合同、承兑、贴现、转贴现等，因老系统不支持分次放款，而需要核心对放款进行特殊处理的业务。
1.9.2 授权接口修改
1、 授权接口修改。增加资金支付方式、贷款用途编码、放款方式（后续放款、开户放款等）、放款计划表、还款方式、还款计划表等内容。实现受托支付、用途登记、一次授权多次放款、按计划表还款等功能。
2、 核心记账时，相应利率与科目根据授权信息及合同相应信息进行重算。
1.9.3 还款计划表接口
1、 增加还款计划表接口。如果信贷选择还款方式为按照计划表还款的，信贷操作员在建立借据后，系统要求必须制定还款计划表。在完成授权后，将计划表也传输到核心，并提供还款计划表打印功能（还款计划表中要有对应的客户信息、合同业务号、授权业务号、还款序号、还款金额、还款日期）。
2、 信贷人员将授权通知（借据）及还款计划表交给核心柜员，由柜员放款后，根据信贷的还款计划表完成核心的还款计划制定。
1.9.4 授权查询及取消接口修改
1、 核心扩充授权本异地查询交易的范围，一个合同多授权的均可查询，不仅限于贷款证贷款授权查询，应用于所有一般贷款授权查询。3410、3411

2、 3203授权取消交易可用于取消一般信贷业务的授权。
1.9.5 授权状态查询接口
新增授权状态查询接口。在信贷授权界面，调用该接口查询该授权在核心中的状态。监控业务进度，方便授权单边问题的解决。
1.9.6 核心申请授权增加用途选择项
1、 根据实贷实付的要求，每次用款必须具有明确的用途。通过信贷管理系统授权时，由信贷人员根据客户申请，选择具体的贷款用途，系统记录并提供统计分析功能。如果用途记录不明还会影响贷后的用途检查等。但目前，核心与信贷的用途不同。建议替换核心已存在的贷款用途字典。其中影响核算的可以进行对应，例如住房按揭、助学贷款等。避免接口混乱。
2、 业务流程：核心柜员在向信贷管理系统申请授权时，根据合同中约定的用途大类审核客户本次放款用途。根据申请的具体用途在核心系统中选择“贷款用途”的最底层枚举。核心系统将用途代码通过核心授权申请接口发送到信贷管理系统。信贷管理系统在建立授权通知时，保存核心选择的贷款用途，并将授权信息反馈核心系统。如按照上述流程描述，核心需要进行如下改造。贷款用途枚举与信贷管理系统每日批量同步。核心系统3202、3205授权申请交易中增加“贷款用途”选择项。枚举值采取分层展示的方式，存在上下级对应关系。
3、 系统上线至功能切换前已经实现前端改造：核心前端3202和3205交易增加“贷款用途代码”输入项。要求柜员在发起授权申请时，打印的贷款用途列表，输入用途代码。授权申请接口增加“贷款用途代码”字段，信贷系统校验。但是该实现方式，柜员的录入工作量比较大。
1.10 产品匹配问题
1.10.1 需求描述
1、信贷产品不包含期限因素，但是核心的产品中期限是划分的重要标准。新一代信贷管理系统允许非贷款证类业务在合同有效期内建立多个借据，放款与合同建立不同步，因此存在中长期贷款产品的合同下发放短期贷款问题。
2、需要核心支持选择中长期产品的合同下，发放短期贷款。根据实际的期限重算利率和核算科目。
1.10.2 信贷产品体系

1.10.3 两系统产品体系对照

1.11 受托支付
1.11.1 受托支付处理流程
1、 信贷系统选择支付方式，如果为受托支付，则录入交易对手信息（账号、名称、金额、用途四要素），授权时，通过受托支付交易接口传给核心。
2、 信贷控制受托支付金额必须与本次的发放金额相同。
3、 核心系统保存授权和受托支付登记信息，核心柜员执行3001放款，贷款资金入借款人账户，同时冻结发放金额（支持一次冻结，多次解冻）。
4、 客户持信贷打印的受托支付通知书（包括授权信息和委托支付明细）填写汇款单；核心柜员根据信贷系统提供的委托支付信息，逐笔进行汇划（核心采用一个交易进行汇划及解冻）。
5、 核心汇出受托资金交易完成时，自动更新受托支付登记簿，并通过批量方式把增量数据返回信贷系统。
6、 放款时（所有贷款业务），核心检查贷转存账户状态是否正常，如果不正常，不允许放款。
7、 支付信息通过唯一键值（授权业务号+支付序号）与信贷系统进行交互。
8、 借新还旧、贷款重组业务，在放款授权时，信贷与核心系统控制必须进行受托支付。信贷管理系统自动默认交易对手账户为贷款账户，核心放款后，通过3003还款交易进行解冻。
9、 核心所有支付渠道增加受托支付的标志，对采取受托支付的，建立独立的处理机制。
10、 票据业务一律不能采取受托支付方式。
1.11.2 异常处理
1、 核心柜员汇款操作之前，信贷系统可以修改委托支付信息，并通过联机接口同步核心，核心按照最新的委托信息办理。
2、 如果出现退汇等失败交易，核心必须将资金返回原汇出账户，继续冻结原贷款发放额度。该功能需要依靠核心二代支付平台改造，在平台改造完成后才能实现。
1.11.3 非贷转存的业务处理需要商定处理方案

约定不贷转存但采取受托支付的，信贷授权后将支付明细传输核心，核心需要提供最终的支付处理结果。可以采取不冻结资金的方式实现。
1.11.4 受托支付接口
1、区别与授权接口，实现受托支付信息的在核心的新增、修改、删除等功能。
2、资金支付查询接口，查询信贷资金，特别是受托支付的资金支付情况。
1.12 账户级信息变更规则
1.12.1 基本流程和要求
1、 定义：核心账户级信息变更是指已经发放完成的贷款，再进行诸如还款方式、利率、结息方式等调整的。
2、 流程：通过信贷与会计部门制定制度，约束账户信息的调整机制。禁止核心柜员未经信贷人员授权直接调整贷款账户信息。信贷管理人员手工填写账户信息变更内容和清单交核心人员；核心柜员通过账户变更交易进行调整，核心系统调整完毕后，批量将账户变更信息同步到信贷管理系统（信贷账户层信息）。
3、 统一要求：信贷系统与核心系统账户层信息的参数枚举必须一致。需要核心提供相关的枚举字段，并备注说明。信贷系统据以进行相关修订。
4、 同步要求：信贷管理系统在用信管理模块中增加借据信息调整记录功能。核心对已发放业务进行调整后，信贷系统以借据调整内容，不改变原借据信息。主要包括结息方式、利率调整方式、执行利率等利率相关信息，还款方式、计划表、扣款账户等。
1.12.2 还款计划同步需求
1、 贷款发放之后，如需修改还款方式，制定还款计划。由信贷人员手工填写还款计划，由柜员在前台录入，维护还款计划，核心系统日终批量形式返还信贷还款计划表。信贷与核心同步修改后的还款方式以及相应的还款计划表执行情况。
2、 核心产生还款计划的产生时点为第一个批量结束期。
1.13 垫款和补授权
1.13.1 垫款处理
1、 垫款产生后，要求信贷与核心系统自动完成业务的补授权处理。建立垫款与原业务、原合同、客户的关联关系。
2、 核心信息反馈。承兑汇票、（转）贴现、保函等票据垫款时，核心通过日终批量返回贷款主档表以及授权信息表，并提供与原业务的对应关系，由信贷系统根据垫款信息自行建立对应关系。
3、 需要确认问题：贸易融资类业务垫款后核心系统如何处理？是否反馈信贷系统。
1.13.2 补授权处理
1.13.2.1 补授权业务范围
新一代信贷管理系统上线后，正常情况下不允许核心脱离信贷授权办理信贷业务。在新一代信贷管理系统中补授权作为应急措施，范围为全部信贷业务。一期不在信贷管理系统管理范围内的国际业务、电票业务除外。
1.13.2.2 授信阶段
对于补授权的业务处理是补录整个流程审批信息。通过正常评级、授信流程，进行信贷管理系统中业务的登记、审批。
1.13.2.3 用信阶段
1、 合同签订发起时，信贷人员选择对应借据，系统自动返显核心对应的合同号，合同签订提交下一岗时，不再调用单一额度申请接口，合同生效时，不再调用合同建立接口。
2、 签订借据的时候，选择对应的核心放款信息，信贷管理系统保存借据的信息，提交时不再调用核心的贷款授权通知接口。
1.13.2.4 对核心系统要求
1、 垫款类和业务转移类补授权，需要核心提供新旧业务的对应关系。例如，提供承兑汇票垫款与原票据对应关系、保函垫款与保函的对应关系。
2、 核心脱离信贷主动发起的业务，需要提供信贷系统合同号和业务号、账号内容等信息。
1.14 贷款展期
1、 信贷管理系统以合同为单位发起展期业务。同时展示一个合同下的所有贷款，由客户经理手工选择需要展期的借据。
2、 新系统中存在一个合同项下多笔贷款情况，因此展期也允许合同展期一次，其借款分别展期。
3、 每笔贷款的展期期限、金额都有不同，信贷管理系统逐笔进行授权。
4、 贷款证等循环类合同不允许展期。
5、 功能切换后，核心修改为每笔授权展一笔贷款。
6、 并行期，信贷管理系统控制，助学贷款、社团贷款展期时，只生成一个展期授权，授权金额为合同金额，到期日为展期后合同到期日。
7、 批量中增加展期标志，信贷据以识别核心3005交易是否完成预展期的交易，以正确处理信贷的展期凭证。之前未与核心讨论，后增加内容。

1.15 借新还旧
1、借新还旧的贷款归还借助受托支付功能实现。
2、业务不再要求放款时自动关联还款。核心中可以分放款和还款两个交易处理。但核心必须控制，资金不能被挪作他用。
3、实现一次放款还多笔的，信贷系统约定最大笔数上限。
4、信贷系统提供对应的贷款账户及对应金额。并控制本次发放额与还款金额的关系，至少保证放款金额小于等于贷款余额。
5、重组贷款的处理，参照借新还旧。
1.16 业务转移
1.16.1 业务场景
1.16.1.1 单户业务转移
1、 某一客户的全部信贷合同及其项下的借据转移至另一网点。
2、 主要应用于允许多头的贷款的跨机构转移。
1.16.1.2 多户业务转移
1、 同一网点部分客户的全部信贷业务（包括合同、借据）批量转移至另一网点。主要发生在网点片区重新划分或某类业务集中管理。
实例：因实行公司业务集中管理，需将网点甲入账的所有公司类信贷业务转移至乙网点，其他业务全部保留。
1.16.1.3 网点拆并
1、 某一网点全部信贷业务（包括合同、借据）批量转移至另一网点。主要发生在网点合并或者信贷权限上收。
实例：网点甲需转型为储蓄制网点，取消其全部信贷权限，现将全部信贷业务转移至乙网点，仅保留其存款业务。
系统自动批量处理，转移范围包括客户资料、评级结果、有效授信、有效合同、未结清借据等所有信贷信息。
1.16.2 功能需求
1、 转移范围包括客户资料、评级结果、有效授信、有效合同、未结清借据等所有信贷信息。
2、 支持助学贷款、按揭贷款、贷款证贷款、承兑、保函等所有业务类型转移。
3、 有效的（授信方案）额度和有效合同（包括有效期内未使用或已经使用尚有可用金额的）转移后，在新网点仍可使用。
4、 涉及核心核算机构变更的，通过系统与核心交互，批量方式完成转移。要求转移后业务，能够继承原流程及管理信息。
1.16.3 流程图

1.16.4 信贷流程描述
1、 信贷管理系统中业务交接模块下增加跨网点转移功能，与客户经理交接功能并立。县级联社信贷管理部门人员拥有跨机构业务交接功能操作权限。
2、 发起人发起交接流程，通过查询条件筛选拟转移的客户、业务等信息，并指定拟接收网点、拟接收客户经理，批量转移还是实时转移，经拟交出和接收客户经理确认后，生成跨网点交接清单。
3、 发起人在跨机构交接发起时，选择是否转移核算机构。如果需要转移，在交接明细中列出现核算机构，由客户经理确定拟接收的核算机构，默认范围为一个法人机构。（核算机构同机构参数中同步的核心网点参数。）接收核算机构栏位由客户经理选择或者直接输入，如果直接输入，系统进行实时模糊查询适配。
4、 实现复选、批量指定接收的机构、核算机构、指定接收客户经理。
5、 信贷管理系统进行转移规则校验，确保拟转移清单符合转移要求。规则包括：除不控制多头的业务和因为表内外原因外，一个客户在同一信贷机构下的业务信息必须全部转移到同一个新机构，即禁止产生违反制度的新多头。表内业务与表外业务分开转移。需要转移核心入账机构的或一次超过十个客户的，必须通过批量方式，不允许实时转移。需要变化核心核算机构的，转移清单所需信息必须完整，否则予以提示。
6、 先提交到拟交出客户经理确认，通过后，提交接收客户经理确认拟转移业务。允许后手岗退回，如需调整清单，线下进行沟通后，退回发起人修改或取消后重新发起。
7、 交出和接收人确认通过后，发起人最终确认拟转移业务，信贷系统根据是否转移核心核算机构，分别生成信贷业务转移清单和核心业务跨网点转移清单，并提供导出功能。
8、 信贷系统调用接口，将核心业务跨网点转移清单传给核心系统（txt文本或tccr报文）。
9、 核心系统对信贷传输的拟转移业务启动交易确认，确认后，完成核算跨网点转移的相应处理。完成业务转移处理后，核心生成转移结果清单。
10、 批量同步。对于转移核算机构也需要变更的，在核心转移交易完成前，信贷管理系统中不进行真正转移；通过系统批量同步核心处理结果，并在原清单内标注是否成功。成功的，信贷自动完成转移，不成功的，退回原状态。由信贷系统管理人员据以进行一步操作（撤销或重新发起转移）。
11、 对于不需要变化核心入账机构的，接收方确认后即可完成转移。
1.16.5 限制条件
1、 信贷业务转移的最小单位是一个客户，不允许一个客户部分业务进行转移，允许多头的除外。
2、 信贷系统中，允许多头的贷款转移时，利用多头贷款转移交易处理，不自动转移客户；除此之外客户资料与业务一并转移。
3、 核心系统业务转移的最小单位是合同，不允许一个合同的部分贷款进行转移。
4、 跨法人进行业务转移，需核心支持。
5、 信贷与核心系统控制承兑汇票的转移不能跨法人，业务转移时，不改变票据信息。核心系统确保能够正常兑付，正确垫款。
6、 已经结清的贷款和已经失效的合同不进行转移；转移发起后，信贷系统提示“业务转移前释放额度，处理失效的合同”。
1.16.5.1 清单格式
转移业务清单文件字段：客户名称、证件号、合同业务号（合同流水号）、授权业务号（凭证流水号）、贷款账号（票据号），转出核算机构、接收核算机构、转出信贷机构、接收信贷机构、转出客户经理、接收客户经理。
1.17 不良资产管理
1.17.1 新增划转交易
1、上收阶段，增加表内资产向表外划转交易，实现新增表内资产划转表外的交易化、核算的明细化。
2、核心系统对表内不良贷款向表外贷款划转时，区分划转内容，比如：划转到已核销贷款的；划转至资产置换贷款的；划转至政府收购贷款；划转至打包处置贷款的；划转至票据置换贷款的；划转至股东购买贷款的。
3、表外不良资产之间直接转换的交易暂不增加，例如置换转核销，先不考虑。统一按先转回表内，再通转表外新类型的方式实现。
4、对于新一代核心业务系统上线后，采用核销方式转到表外的置换贷款，在置换交易改造完成，核心系统将已经标志的该部分贷款移植到正确的科目。
没有体现接口，核心信息如何分类传到信贷，自动更新台账。
1.17.2 批量处理
1、核心系统对表外不良贷款（已核销不良贷款、票据置换不良贷款、资产置换不良贷款、整体收购不良贷款及新增加的打包处置不良贷款、股东购买不良贷款）建立明细台账，并与信贷系统通过贷款业务号（援权业务号）建立关联关系。
2、表外贷款的批量参考表内处理。核心系统向信贷系统提供交易明细，信贷系统自动据以更新相应明细台账。（参考呆账核销的账务处理）
1.17.3 存量表外贷款移植
1、存量表外贷款移植时，从信贷系统进行数据规范和获取数据，由网点核对数据的真实性后，再移植。具体移植方案，需要会计、科技、资产部门共同讨论。
2、新系统推广后再实施。
1.17.4 不良资产集中管理
1、不良贷款集中管理时在核心系统实现不良贷款业务及相关资料的跨网点转移，转移后相关贷款信息不变。
2、核心系统采用业务转移方式处理，信贷系统按照业务转移的信贷处理规则处理，确保系统自动承接集中前后的业务和管理信息。
3、信贷系统进行资产统计时，需要将集中划转的与普通新增收回区别处理，防止发生额虚增。
1.17.5 抵债资产管理
鉴于抵债资产的特殊性以及数据规范的不确定性，无需在核心系统中建立明细台账。
1.17.6 表内划转表外处理
对于表内划转表外的，信贷系统通过接口方式把信息提供给核心系统，以杜绝前台柜员在没有信贷授权的情况下主动发起交易的风险，防止两系统数据不统一。
1.18 数据提供
1.18.1 台账同步
核心系统将涉及信贷的批量接口数据，以增量全字段方式按市导出数据文件传给信贷，信贷管理系统根据业务需要自行处理数据。
1.18.2 需直接提供的贷款数据需要张姐将前段时间讨论的确定需要核心提供的数据增加上。

1.18.2.1 上收期阶段核心可以返还的
1、 账户状态
2、 科目代号/名称
3、 是否欠息
4、 产生逾期时间
5、 产生非应计时间
6、 还款方式
7、 欠本金额
8、 还款周期
9、 贷款账号
10、 保函状态
11、 贷款收回日期、收回时间
12、 欠息日期
13、 欠息金额
14、 表内欠息金额
15、 表外欠息金额
16、 本金逾期天数
17、 利息逾期天数
18、 首次欠息日
19、 欠息次数
1.18.2.2 切换期阶段核心才能返还
1、 计息明细
2、 还息明细
3、 资金支付流向数据
4、 分期贷款查询
5、 非应应计类型
6、 垫款金额
7、 还息日期
8、 还款计划表
9、 存款余额、存款日均额、保证金余额、贷款日均额、股金余额、实收利息
10、 账户状态：正常转逾期日期、正常转部分逾期日期、正常转非应计日期、部分逾期转非应计日期、逾期转非应计日期、部分逾期转正常日期、非应计转正常日期。
1.19 信贷与核心科目核对
信贷机构与核心网点不再一对一，例如公司业务部的业务分散在多个核心网点入账。因此在科目核对时，会出现不平问题。
1.20 社团贷款
1.20.1 流程图

1.20.2 业务流程
1、 主办社在信贷管理系统中对借款人进行评级授信，授信完成后，调用ECIF额度接口，建立客户信贷条线额度。
2、 授信完成后，信贷系统内发起社团贷款协议签订流程。主办社发起邀请，参与社接收到邀请后，各自发起审批流程。全部参与社审批通过后，由主办社进行签订社团贷款协议（包括参与社、分配金额、分配比例信息(信贷系统控制分配比例为整数百分比，不存在小数）。调用协议建立接口，在核心系统中建立社团贷款协议。
3、 主办社在信贷业务系统发起合同签订流程，系统根据协议自动将合同分发到各参与社确认，参与社确认完毕后，主办社签订合同。合同生效时，由主办社调用核心合同建立接口，建立社团贷款合同。
4、 信贷系统在调用合同建立接口同时，将合同与协议的关联关系发送核心，核心进行保存，以实现后续处理。
5、 主办社发起贷款发放流程，确定本次发放额，系统根据社团协议，自动分发给各个参与社，各参与社确认后打印授权通知书（对应各个参与社实际发放额）。参与社不允许修改授权信息。
6、 授权确认时，分别调用贷款授权接口，将各自授权信息发送到相应的核心。
7、 所有参与社都确认并完成授权通知书打印后，主办社打印总授权通知书（对应主办社和所有参与社本次向借款人的实际发放额）。
8、 信贷管理系统在发送大授权信息时，同时将各参与社授权与代理社总授权的对应关系发送核心。核心系统保存大授权和小授权的关联关系信息。
9、 核心系统发放各个参与社的贷款。核心系统检测各个小授权的贷款是否都完全出账，检测通过，才允许发放大授权的贷款。
10、 核心放款时，大小授权都产生贷款账户。信贷与核心系统控制大授权放款时采取监督支付，小授权放款时，不允许贷转存，统一进归集账户。
11、 信贷管理系统展期由主办社发起，各参与社确认。主办社选择大授权对应的贷款账户进行展期审批，授权时，根据协议系统自动分发给各参与社确认展期授权。信贷审批一次，核心根据各参与社展期授权分别处理。
12、 账户状态的变化，按照一般业务处理规则处理，手工干预的账户状态变化不做控制。
13、 贷款核销等转表外处理，按照一般贷款管理规则处理，不要求必须统一。
14、 贷款本息归还时，统一由代理社柜员在客户账扣款归还大授权产生的贷款账户，然后启动分配交易，核心系统根据协议信息和大小账号对应关系，自动分配各参与社归还金额。核心系统应控制，各参与社还款时，输入还款金额与分配金额相符。
15、 支持自动扣款，系统通过批量完成贷款归还。大授权中自动转存标志可以为“是”。
16、 合同中资金来源标识，目前核心区分自营和委托。信贷授权中区分自营和委托。
17、 协议编号与合同编号区分，必须遵守先建协议，后建立合同的循序。核心注意与现有实际有冲突。

18、 核心允许社团贷款的合同与放款机构属于不同法人。
19、 信贷管理系统社团贷款授权，需要增加大授权号、合同号、协议号接口。
20、 贷款发放时，信贷必须控制小授权完成后才能发送大授权；核心控制小授权使用后才能使用大授权。
21、 无论大小授权，核心不能自己产生，必须使用信贷授权。
22、 存量社团贷款移植问。新信贷系统与核心系统兼容存量数据的后续放款和还款。（信贷管理系统记录老系统中小合同以及小合同与授权的对应关系。存量合同不允许新增贷款，如需发放剩余金额，必须按照新规则重新审批，建立协议和合同，然后进行放款。存量贷款归还，需要核心系统在分配算法上考虑原未按规则还款的处理。存量社团贷款的展期，信贷系统按照老系统接口处理。对存量社团贷款协议信息进行维护，且要求必须在新程序上线前完成。）
1.20.3 系统实现
1、 增加核心授权状态查询接口。查询发送核心的授权是否已经使用。信贷系统据以控制大小授权的顺序，在小授权全部使用前，不允许发放大授权。
2、 社团贷款科目核算不改变。
3、 两系统通过技术授权满足业务需求，流程上只审批和签订一个合同，展期时只针对一个合同进行调整。
4、 核心系统中，社团贷款协议通过接口建立。
5、 核心需要记录大小授权的对应关系；以及每次贷款发放时，各参与社承贷金额与本次放款总额的放款比例。
6、 核心系统增加控制，客户对大授权产生的贷款账户还款时，系统自动根据放款时比例进行还本付息的分配，在参与社进行还款时，对输入金额与分配金额校验必须一致。
7、 自动分配还款规则只对新增的社团贷款有效。功能切换前，对核心存量社团贷款中维护的大小授权对应关系进行清理。
8、 初步确定，核心按照现有大小合同的机构建立合同。代理社建立委托大合同和承贷的自营小合同，各参与社建立自营小合同。每次放款自营部分的授权和账号挂在各自小合同上，