业务架构

image.png

image.png

客户体系设计

image.png

image.png

客户索引层：以全行统一客户编号作为唯一键建立全行客户索引，记录全部客户的编号及其对应的客户类型。

• 基本信息层：针对每一类型的客户，记录该类型的客户的基本识别信息，可根据新增的客户类型，灵活扩展。
• 分类信息层：将一个客户的全部信息，按照信息种类进行模块划分，所有类型的客户，相同种类的信息共用一套数据模型。
• 扩展信息层：针对分类信息层的进一步细分，保证了一个种类的扩展信息的灵活性和可扩展性。

客户基本信息

客户基本信息视图以客户号为检索条件，展示客户的所有基本信息。每个客户拥有一个全行唯一的客户编号，核心与 ECIF 系统保持同步。由于不同客户的基本信息的差异，在存储上，采用分表存储的机制，为不同客户类型分别建立一张基本信息表。客户的基本信息是较为稳定的，因此，为了提高查询存储效率，采取的是单表记录所有信息的平铺式数据结构。针对未来可能出现的基本信息变更，可以根据具体的情况，进行表结构变更或者批量建立附加信息档案。根据客户类型，
客户基本信息包括： 个人客户基本信息：客户编号、名称、VIP 等级、境内外标志、是否内部员工、主办行等
单位客户基本信息：客户编号、名称、行业代码、经济类型、注册地、同业客户标志、境内外标志、主办行等。
内部客户基本信息：客户编号、名称、主办行等。

客户证件信息

客户证件信息体现了在银行系统之外，国家其他行政管理机关对于一个客户的身份的确认及证明，对于校验一个客户的合法性有重要的意义。由于一个客户可以拥有多套证件，因此，客户证件信息采用参数化设计理念，证件类型按照国家数据标准制定标准化参数。采用纵向表结构的设计，通过证件类型表明该套证件的种类，同时，一个客户可以通过多条记录在系统中记录多套证件。
由于采用该种设计，证件类型可以任意扩展，保证了视图的灵活度。 开户证件信息，由开户证件标志来识别。 目前，核心客户证件只保留开户证件，多套证件功能留后续扩展使用。

产品体系设计

image.png

核心业务系统提供对所有银行存款、贷款等业务实现产品化管理，提供灵活的产品参数化配置，满足金融产品创新和业务扩展的需要。能根据市场需要，通过参数配置，快速定制、组合、创新产品。

产品定义

银行产品是指银行为满足客户某种需求并获取确定或可能收益，向市场提供的金融服务。是由银行生产、可供市场及客户选择、能满足客户金融交易和服务的需求、银行同时可从中赚取各种实际和潜在收益的综合金融服务。

产品体系总览

image.png

全行统一的产品编号。根据不同的系统特性，建立不同的产品信息表。通过一对一或一对多的关系，建立产品共通的分类信息。 从丰富的维度对产品的使用进行控制，包括币种、期限、渠道、介质、客户、功能等。与公共定价模块灵活解耦的关联关系。可以灵活扩展分类信息或特色信息，不影响原有的结构。

产品模型

image.png

产品分为单一产品（系统中最细粒度、最底层的产品）、复合产品以及组合产品（复合产品、组合产品是若干单一产品按按照业务要求设置了一些规则的组合）

产品结构

image.png

产品模型一共包括 4 个区，分别为：基本区、特征区、控制区、核算区。将属性接近的内容分到同一个区，方便对参数的维护和读取，每个区都留有扩展域，方便以后扩展。

产品分类

银行产品的分类是信息系统板块分的基础。产品的分类可以有按客户群分类(分为个人产品、法人产品、第三方机构产品、内部管理产品等)、按业务性质分类(可把银行业务划分为资产业务、负债业务及中间业务三类)等多个维度

产品规划原则

产品定义没有固定的分类标准，可以根据实际业务需求定义产品，既可按具体科目定义，或按参数功能分类，也可两者配合使用 ；
按参数功能定义产品：“随心还”住房按揭贷款等，以上产品实际是为推出某项特色贷款而设定一组特定参数产生的产品；
两者配合使用 ：实际多采用此方式，即会计定义产品时，既不拘泥于会计科目，又不必完全与信管系统的产品分类保持一致；对于非经常使用的贷款品种，可按科目简单定义相关产品，对于经常使用的贷款品种，可根据业务需求定义不同的参数组合，产生不同的产品，方便柜员应用

分类设计及产品编码

产品分为活期、定期、贷款、内部户产品信息，还可横向扩展其它产品种类。
定期产品条线，记录了定期产品的一般信息，包括产品名称、最低开户金额、允许提前支取次数、是否计息等。
活期产品条线，记录了活期产品的一般信息，包括产品名称、余额反映方向、通兑方式、是否计息等

产品定制

银行产品有多种特征，每个特征对应不同的业务功能。产品可根据不同的业务种类，实现不同产品特征的组合，以满足客户不同的业务场景中的对产品服务的要求。
对公同业客户期望开立了一种对公定期存单，存期为 21 天，起存金额为80000 元人民币，最低留存金额为 20000 元人民币，可提前支取次数为 3 次，续存期数为 5 次。 摒弃传统的代码开发模式，引入产品工厂的设计理念，可以通过产品工厂快速的配置新的产品，而不需要编写任何代码。
产品工厂的原理：
对于业务进行抽象形成产品属性、功能对象、事件等产品基本组件，通过产品对这些组件进行组装即可形成新的产品。在产品层面对账户的属性、功能、事件进行严格限制，确保产品处理的规范性。

产品工厂机制

image.png

产品工厂适用的模块：
资产、负债、卡、理财、国债模块按照产品工厂的模式设计，每个模块由自己独立的产品工厂。
产品工厂的功能：
包括新增产品、复制产品、产品模板、修改产品等功能。
产品与交易的关系：
每个产品产品工厂有自己独立、统一的交易，它配置的产品有统一交易进行后续的支撑，其权限和业务控制在产品进行控制。
产品的参数处理原则：
产品参数分为系统层原则性参数、产品原则性参数、缺省性参数。

• 系统原则性参数：该类参数是该产品的关键性参数，不允许在开户或账户资料变更时修改，即该类参数的账户层必须和产品层保持一致。系统原则性参数永远是原则性参数，不会由于不同的产品性质发生变化。
• 产品原则性参数：该类参数系统层原则性参数基本相同，区别是产品原则性在不同产品上其性质会发生改变，即可以变化为缺省性参数。
• 缺省性参数 ：该类参数可以在产品层定义，在账户开户时作为缺省值使用，允许柜员修改，也允许以后在账户资料变更时修改。

产品定价

产品系统中建立产品与定价模块的关联关系，而不直接在产品系统中定义定价相关信息。
产品与利率。针对不同产品设置对应的利率。同一产品，还可根据产品特殊定义特征，个性化定制利率。
产品与费率。针对不同产品设置相应的费率。开立一种产品的活期账户，通兑手续费优惠 20%。
产品与税率。针对不同产品设置相应的税率。针对购买基金产品专用账户，从产品维度设置自身的税率。
产品与汇率。针对产品设定相应的汇率规则。如设置产品对应的汇率信息等。

产品控制

产品的控制可以从多个维度进行，包括：币种、行所、存期、渠道、介质、客户、功能、限额等，控制的维度可以扩展。
产品从单一维度控制。如产品只支持开立人民币，产品只支持在广州分行使用，产品只可在柜台交易、产品只支持同业客户使用、产品不计息、产品只支持定期一年以上的存期。
产品从多个维度组合控制。如产品只支持在广州分行地区（行所）的同业客户（客户）在柜台（渠道）交易使用， 产品支持在自助渠道的每日取现限额为 20000 元人民币。

产品统计

产品统计可通过产品自身的统计，也可通过产品和其它维度组合统计，以满足客户、银行自身和监管的需要。
按产品本身统计。如统计智能通知存款产品开立了多少未结清的存单，统计托付通产品开立了多少未销户的账户。
按产品与其它维度组合统计。如统计全国各分行分别开立了多少活期保证金账户，以此来调整各分行的营销方案。统计在网银渠道开立的定期存单，按存单的存期分别有多少张。

产品技术实现

产品的技术实现就是要把产品的各个属性，根据业务的具体分析结果，以技术的手段，体现在参数设计中。并根据这些参数，编写相应的控制处理程序。
核心系统的参数分为四层：系统层、产品层、机构层、账户层。各层之间遵循前文提到的“覆盖原则”：覆盖次序依次为：账户－>机构－>产品－>基础产品－>系统。
在实际交易时，核心系统处理交易的基本流程如下：

1. 核心系统接收送入交易
2. 核心系统通过送入的介质号，找到对应的客户产品账号和客户基础产品账号
3. 核心系统根据该条交易所属的具体的产品账户数据，可以得到产品码和基础产品码，进而得到产品控制参数和基础产品控制参数；同时，也能得到机构控制参数和系统控制参数
4. 核心系统将账户、机构、产品、基础产品、系统各层的参数进行归并，得到该笔交易最终起作用的参数集合
5. 核心系统根据最终确定的参数，执行对应的控制程序，对客户账户 , 公共数据, 核算等数据的处理。

通过以上过程，即实现了以产品为导向的系统技术模型。

image.png

帐户体系设计

image.png

在传统的业务操作模式下，客户需针对不同的情况开立多个账户，如果涉及一些操作比较密集的业务，则开立的账户就会更加的多，加大客户在账户管理上的成本，也增加了银行的账户管理成本。基于业务的发展，在现行实际业务场景中，客户提出了主子账户的需求，需要在一个账户体系中存在主账户，在主账户下挂多个子账号。不仅如此，更有客户提出了可设立多层级的子账号体系，同时根据客户资金的使用管理的实际情况，可将子账号用于管理不同类型的资金，同时还要求可根据需要对特定子账号独立设置是否参与核算。

例如：某一财政客户，在传统的账户体系下根据所管理的资金用途，开立了 5 个账户。后因管理的需要，需要将 5 个账户合并成一个账户，这就要求了在一个账户下管理 5 个用途的资金，同时又要求在原有每一项资金用途下按该市的划分的地区分别开立下一级的子账户，每一个子账户用于管理该地区对于该种用途的资金。因该账户为财政账户，存在较多的存款余额，客户也提出可以在该账号下挂定期存款，以满足增加资金收益的要求。以上业务要求，如在账号、科目核算等密切关联情况下，难以满足客户业务上的要求。

为了满足类似于以上情况的客户需求，必需对账户体系进行多层级设置的创新管理。在实现账户体系的创新之前，需要对账户所包含的信息和作用进行进一步的分析。

对于以往传统意义上的账户，面向客户和银行承担了多种职责：
面向客户提供账号，做为交易依据（因此就纯粹的账号可视为一种介质，就类似于银行卡）；面向银行，提供合约信息，进行客户账的业务处理；面向银行内部的会计处理，提供核算信息，进行核算业务处理。基于账户的本质，我们可以将账户分为介质、合约和核算账号三层体现，同时可针对合约层进行多层次的设置，以满足客户多层级管理的要求。通过合约的多层级和合约的不同种类，同一账户中既可挂活期、又可挂定期、保证金、贷款等，同时又根据合约与核算账号对应关系，可根据业务需要设置该合约是否参与核算。

帐户模型

image.png

客户可按需在一账号下对不同的资金进行管理，开立账号时会自动生成初始合约信息和核算分户信息。
合约信息：记录合约的一般信息，包括户名、状态、开销户信息等。
核算信息：主要包括核算相关的要素，包括当前账户余额、上期账户余额、计提利息金额、当日借记金额、当日贷记金额等。

• 同一账号下可通过签约服务，新开立不同类型的合约。
• 同一合约下可通过签约服务，开立同类型的子合约，且可根据客户资金管理需要，逐级下挂新的子合约，无层级限制。
• 同一账号下开立子合约，只能在行内的同一机构开立。

多层级的账户体系在满足客户对资金分层精细化管理的诉求同时，也面临着如何帮助客户在多层级的账户体系中进行区分和识别的问题。本质上来说，正是因为客户对于自身的资金账户出现了使用和管理的差异诉求（或者说不同“用途”）才产生了账户资金细分的要求。

账户与交易映射关系

账户体系分为多层级，也表明账户包含多个合约，每个合约均可参与交易。使用账户进行交易时，必定需要指定使用某个合约。通过用途来区分合约，达到客户使用合约的明确性和便利性。

交易区分说明

image.png

image.png

• “用途”可以用于客户分层账户体系的账户识别，以及基于“用途”的账户资金使用情况的分类统计。

账户体系的“默认账户”
多层级的账户体系需满足客户在各种复杂业务场景使用管理的便捷性、准确性要求。

• 对于客户可以主导的业务场景，如柜面、网银、手机银行等，可以查询展现客户的多层级账户列表供客户自主选择交易。

• 对于客户无法主导或希望系统自动识别的场景，如 POS 交易、支付来账、自动缴费等，可通过设置客户希望适用于各个业务场景的“默认账户”实现。
  

  image.png

客户可设置用途为“网上支付”的活期合约为 POS 交易的“默认账户”，所有 POS 发生的交易均会自动通过该活期合约交易。

账户核算

核算约定规则如下：
（1）每一层级的合约在一定条件下支持设置是否参与核算。不核算的合约需要从下至上设置，允许从末端合约向上逐级设置合约不核算。不允许存在合约不参与核算，该合约下层合约参与核算，即不允许出现合约层出现中断的情况。

image.png

（3）参与核算的变更设置

• 合约由不核算修改为核算，通过合约关系维护功能实现。需要将合约的起息日期修改为变更生效日期。
• 合约由核算修改为不核算，需要对该合约做结息处理，然后将分户余额转至上级合约，即该合约对应的分户余额必须清零，以保证该合约不在科目余额上反映。

账户透支

资金共享
建立的多层级账户，每一层子账号均可独立核算。通过相关的签约交易可以实现主账户下的资金池（资金池是主账户下所有子账户余额的总和）共享。每一个具有核算功能的子账号在余额不足情况下，可使用资金池里的资金，使用的额度和资金计价通过协议约定。
账户透支
通过签约约定在账户合约余额不足时，可支持透支的方式提前对外结算付款。透支的方式包括：日间透支，日终时轧差金额确认银行是否垫款；日间透支，银行实时垫款。

账户管理

账户冻结
输入“外部账号”进行冻结：外部账号是银行提供给客户的账号。遇到司法冻结，权利机构通过外部账号做冻结。

• 账户冻结：输入外部账号（包括活期和定期外部账号），将该账号下所有层级的合约做冻结处理。
• 金额冻结（也叫部分冻结）：输入外部账号，冻结该外部账号下的一部分资金，所冻结的资金对任一合约都有效。计算合约可用余额，判断合约本身的可用余额，再与整个账户的可用余额比较，较小者为该合约的可用余额。

案例一：账户冻结

image.png

image.png

image.png

image.png

合约 11 的可用余额为 700 元，整个账户级的可用余额为 800 元，则较小者700 元为合约 11 的可用余额。

• 合约冻结：包括两种类型，一是整个合约的冻结，二是针对合约的金额冻结。

如合约存在自定义账号，针对自定义账号进行冻结，只对该合约进行账户冻结或金额冻结。

账户久悬管理

单位结算账户实行久悬户管理机制。久悬户指账户一年内未发生除结息外的收付活动，金额在规定的限额内，账户无未结清贷款，不存在冻结、止付等特殊状态，在经转久悬科目交易，将其账户状态置为久悬。久悬户针对外部客户账户，不针对合约实行久悬管理。
久悬户管理基本流程为：
（1）每日对当日满足转久悬户待确认处理条件的单位活期账户进行久悬户待确认处理，生成“待转久悬登记簿”（此时只是生成待转久悬的报表，还不是真正的久悬报表，不修改账户状态）。
（2）针对已转入“待转久悬登记簿”账户的客户发出转久悬通知书，并登记发出通知日期。账户如在规定的时间内（通常为 30 天）发生金融交易，则从“待转久悬登记簿”去掉。
（3）“待转久悬登记簿”中的账户在规定时间内仍未发生金融交易，则可针对已发出转久悬通知书的单位活期账户进行转久悬处理。
（4）针对已转久悬户的单位活期账户进行销户处理。

账户销户

外部账号销户
外部账号销户需要将账号下的所有合约销户完成才可销户。

• 合约销户：根据实际的需要，在签订服务协议后，如果无需使用某一层级的某个合约时，可对该合约进行解约（即对某一合约进行销户）处理。合约解约时，该合约不可存在下一层级合约；合约解约时，必需对该合约做结息和余额转出处理。 账户余额体现外部账户余额。查询交易输入外部账户时，按存款类型展现账户余额，包括活期余额和定期余额。
• 活期用途余额：输入外部账号前指定某一用途时，体现该用途下的汇总余额及该用途对应可用余额。
• 合约的余额：针对某一具体合约的余额，包括合约余额和可用余额。

账户余额证明

支持按汇总出余额证明，按某一合约出余额证明，按活期汇总/按定期汇总出余额证明。

• 按汇总出余额证明时，可在余额证明中体现合约明细的余额。
• 按某一指定合约出余额证明，体现该合约的余额。

账户对账

可对多层级账户体系下的每一层级合约选择是否对账，以及选择对账方式、对账周期和频率等。

• 可对总账户进行对外出具对账单，亦可按每一层级合约独立出具对账单。

账户报送

账户开立的对外报送均使用外部账号。

• 活期账户的数据报送，按外部账号统计该账号下所有同一类型账号的汇总余额报送。
• 定期账户的数据报送，则按每一个具体账号的余额报送。
• 报送所对应的账号均使用外部账号。
• 合约的开户和销户无需报送。

定价体系设计

image.png

利率定价方法

建立职能明确层次分明的分级授权定价体系及规范的操作规程进行不同层次利率市场化定价策略的制定，同时杜绝操作风险。

• 总行可综合考虑全行资产负债管理的战略目标需要及市场竞争性价格，制定全行级的本外币产品基准利率和税率，并可参数化设定利率浮动的上下限。总行可为各分行或多个分行组成的区域制定基准利率和税率之上的差异化定价策略。
• 分行可针对总行维护或定制的定价策略进行差异化处理，但浮动上下限参数必须在总行限定的范围内。分行经过总行审核后可自行定制适用于本分行的定价策略；分行也可为辖下指定机构或多个机构组成的区域制定基准利率和税率之上的差异化定价策略。
• 各机构可针对上级分行制定的定价策略进行差异化处理，但浮动上下限参数必须在限定的范围内。各机构经过分行审核后可自行定制适用于本机构或特定账户的定价策略。

基于利率市场化的定价体系建立完善的客户产品服务全生命周期的数据回馈和分析机制，以便提供详实可靠的分析结果供评估利率市场化的实施效果、及时监控市场风险，为定价策略依据。按机构/地区统计的单位周期（如按月）客户、账户增长率及其定价策略的分布（找出更受客户认可的定价策略）。

• 按机构/地区统计的单位周期（如按月）客户、账户交易量（根据活跃程度分析定价策略对客户粘度的影响）。
• 按定价策略分类统计的单位周期银行收益情况（衡量定价策略对银行收益的贡献度，对于贡献度低甚至产生负收益的定价策略进行识别和风险监控）。
• 可针对定价策略设定不同参数的监控阈值（如上浮比例大于 5%），按机构/地区统计达到或超过监控阈值的账户信息，供分析是否存在利率市场风险。

利率定价策略和计算要素

利率体系为支持利率定价设计的参数化，需要能够解决 2 个问题：一是参数化支持不同的利率定价的纬度，二是参数化支持不同的利率的计算要素。

• 利率定价的纬度：利率定价的参与维度约定的是我行构建的利率定价体系可针对哪些业务要素及其组合进行差异化的市场定价
  

  image.png

利率定价的计算要素：利率定价的计算要素约定的是根据上述定价策略进行利息计算时可灵活设定的计算参数。

image.png

利率参数化要素
本金的参数化体现在分层中，主要有两类：一是将本金划分成若干小段的金额，将其称为按分量分层；二是先划定若干区间，然后看目前的本金会处于哪个区间上，将此称为按总量分层。不管是按分量分层，还是按总量分层，最终的目的都是获取相应的利率。

• 利率参数化跟本金分层紧密结合。例如按分量分层时，其每一层有对应的利率；而按总量分层时，其每一个区间有其对应的利率。获取利率时，根据本金的不同而使得获取的利率不同。利率参数化的另一表现是利率可以基于基准利率
  进行上下浮动，浮动的幅度也是参数化的范畴。
• 期限参数化，对不同期限的约定不同的利率。对于那些长期将资金存于银行不动的客户，给予比较优惠的利率，从而达到吸引客户的目的。
• 由上几点可知，本金、期限的参数化不是单单为其自身所设定的，而都是跟利率参数化紧密相连的。

利息计划

利率参数化集中体现在利息计划，实际是对利息计算公式（利息=本金利率期限）中的本金、利率和期限参数化。

image.png

image.png

不同的产品会对应不同的类型的利息计划。除了具有个性的利息计划的合约之外，产品利息计划会影响所有购买该产品的客户合约。例如，整存整取存款、通知存款等。

合约利息计划
客户合约层的利息计划，可以继承产品层的利息计划，它们的含义跟产品的含义相同，只是其影响的范围仅限于特定的客户合约。像协议存款、协定存款，其利息定价便会因客户的不同而不同，可通过合约利息计划实现其个性化设置。

核算体系设计

image.png

核算科目映射方案

将核算相关的要素抽取出来，实现核算要素配置的参数化，实现交易与核算分离。 交易要素的变更，不影响核算科目；核算科目的变更，不影响交易要素；交易要素变更和核算科目的变更，只需要调整两者对应关系，实现交易要素与核算科目的映射。

客户账核算映射方案

在客户账户中不再存储科目号，只需要在发生业务交易时提供与核算相关的核算要素，核算引擎将这一组核算要素映射到相应的核算科目，再进行后续的核算处理。

image.png

• 定期账户举例
  只需提供该定期存单的“产品-对公普通定期产品”、“客户行业-G0200-计算机服务业”、“存期-一年存期”、“金额类型-定期本金”，即可关联该定期账户的核算科目。
• 活期结算账户举例
  只需提供“产品-对公一般活期存款”、“客户行业-G0200-计算机服务业”、“存期-不限存期”、“金额类型-活期本金”，即可关联该活期结算账户的核算科目。

内部账核算映射方案

内部账户是对银行内部资金或者资金流通环节的分户管理，如手续费收入、利息支出、应付利息等。内部账户直接针对最底层级的科目开立。因此，核算与发生交易的客户账信息有关，又与涉及内部核算的事件信息有关。如定期支取发生结息，产生“利息支出”核算事件，而具体关联到哪个核算科目，又与发生交易的定期账户信息有关。比如存期为一年期和三年期分别对应到不同的“利息支出”核算科目。

因此，内部账的核算要素建议

image.png

• 定期账户的利息支出
  只需提供“产品-对公普通定期产品”、“客户行业-G0200-计算机服务业”、“存期-一年存期”、“金额类型-定期本金”、“事件类型-利息支出”，即可关联该定期账户的利息支出核算科目。
• 应解汇款活期账号
  假定交易需要使用某机构的应解汇款账号，则只需提供“事件类型-应解汇款”、“交易机构号”、“交易币别”，即可找到该机构对应币种的应解汇款账号和相应的核算科目。

业务与核算说明

对于业务人员来说，开户时不再选择核算科目，而是选择开立的产品。涉及账户交易的核算，则由系统自动根据产品和行业代码等交易要素获取对应的科目进行核算。

核算引擎技术方案

交易与核算处理流程
应用层和拆分录的调用关系，应用层在处理完交易的外部账务，登记完核算流水档后，进行事务提交后，调用拆分录请求发送程序异步发送拆分录请求到拆分录模块。

拆分录模块根据应用层的交易请求码、渠道、业务系统等信息进行判断该交易是实时处理还是批次处理。若是批次处理，程序直接退出结束；若是实时处理，则根据交易请求码对应的内部交易码获取该交易的拆分录规则进行拆分录。拆分录模块实时读取核算接入流水档的记录进行拆分录，同时将拆出的分录发送到后续账务处理系统进行入账处理。

如此，拆分录的失败与否不影响应用层对交易的处理，同时由于采用了实时和批次拆分录入账的方式，则缓解了交易高峰期系统压力。

交易层与核算层流程

image.png

应用登记核算接入档处理模块

功能概述
该模块被应用层调用登记核算接入流水档。应用层在处理完所有的外部账务后，在事务提交之前，调用该模块将本笔交易应用需要的进行加工的核算信息登记到核算接入流水档中。登记到核算接入流水档的信息被后续拆分录模块加工处理形成分录。

该模块需要应用层提供应用信息：以数组作为接口，供应用层将交易信息传入到该模块。每一笔转出方和转入方组成，也就是一借一贷，费用信息是交易时收取的费用信息，一个交易可以收取多笔费用，每笔费用都作为数组的 1 笔记录上送。
该模块将应用层传入的数组解析到核算接入流水档，由于应用都是以转出或转入作为接口信息传入，所以该模块将判断传入科目或者账号的借贷方向，将数组信息填写到核算接入流水档的借贷方。

功能流程
应用登记核算功能流程

image.png

核算体系实现

核算分离处理流程
为了满足系统扩充的需要，新一代的核心系统采用核算分离的方法，来达到联机交易尽量不处理交易分录，由单独模块完成会计分录处理，交易与核算的松耦合、保持业务处理灵活性的目的。

分录的处理根据业务类别，既可日间产生也可晚间批处理产生，该配置由交易参数配置实现。 除内部账、会计系统外, 前台业务人员, 从输入界面到输出打印, 包括扎账, 都没有会计概念。 系统的业务处理模块与拆分录的模块不绑在一起。

核算分离处理流程

image.png

• 是否实时拆分录, 由系统参数配置决定, 可以联机实时拆也可以晚上批量拆。
• 联机实时写分录, 由平台调用拆分录子程序完成写分录, 并在场景记下已写分录标志。
• 晚上批量拆分录, 先检查场景的‘已出分录标志’，当标志为‘否’时再由批处理程序调用拆分录子程序完成。
• 对于日间已出分录的场景，晚上批量程序不会再对该场景进行拆分录处理。

场景产生分录流程

image.png

数据库表设计

客户体系数据库表设计

image.png

客户证件信息表：客户编号、证件类型号码、证件生效失效日期、发证机关、开户证件标志等。

产品体系数据库表设计

image.png

帐户体系数据库表设计

image.png

介质信息

• 卡信息表：定义卡的基本信息
• 存折信息表：定义存折的基本信息
• 定期存单信息表：定义定期存单的基本信息
• 支票信息表：定义支票的基本信息
• 汇票信息表：定义汇票的基本信息
• 本票信息表：定义本票的基本信息
• 自定义账号对照关系表：定义自定义账号与合约的关联关系信息，把自定义账号等同于介质管理
• 外部账号信息表：定义外部账号的基本信息，把外部账号等同于

介质管理

• 介质与介质关系表：定义介质与介质的关联关系信息
• 合约介质关系表：定义合约与介质的关联关系信息

合约信息

• 个人活期账户信息表：定义个人活期账户的合约信息
• 对公活期账户信息表：定义对公活期账户的合约信息
• 个人定期账户信息表：定义个人定期账户的合约信息
• 对公定期账户信息表：定义对公定期账户的合约信息
• 个人定期保证金账户信息表：定义个人定期保证金账户的合约信息
• 对公定期保证金账户信息表：定义对公定期保证金账户的合约信息
• 个人活期保证金账户信息表：定义个人活期保证金账户的合约信息
• 对公活期保证金账户信息表：定义对公活期保证金账户的合约信息
• 内部账户信息表：定义内部账账户的合约信息
• 合约关系表：定义账户之间的关联及层级关系信息

核算信息

• 个人活期核算表：定义个人活期账户的核算信息
• 对公活期核算表：定义对公活期账户的核算信息
• 个人定期核算表：定义个人定期账户的核算信息
• 对公定期核算表：定义对公活期账户的核算信息
• 个人定期保证金核算表：定义个人定期保证金账户的核算信息
• 对公定期保证金核算表：定义对公定期保证金账户的核算信息
• 个人活期保证金核算表：定义个人活期保证金账户的核算信息
• 对公活期保证金核算表：定义对公活期保证金账户的核算信息
• 内部账户核算表：定义内部账户的核算信息

定价体系数据库表设计

image.png

利息计划表：定义利息计划的属性。

• 利息计划层级表：利息计划分层时，定义分层的金额和期限等相关信息。
• 计息算法历史表：指定该利息计划的算法，按实际天数，还是对年对月对日。
• 编号利率表：记录发布的利率信息。
• 利率变动历史表：记录所有利率的信息，包括利率变动的历史记录。
• 利息计划待复核表：建立利息计划复核前的保存记录的临时表。
• 利息计划层次临时表：建立利息计划层级表前的保存层级记录的临时表。

核算体系数据库表设计

核算体系数据

image.png

关键数据表设计

核算要素表

image.png

image.png