保理信息系统需求说明书
保理信息系统需求说明书
保理信息系统需求说明书保理信息系统需求说明书1.引言本需求说明书旨在对保理信息系统进行全面的需求分析和规划,以满足公司保理业务的管理和发展需求。
本文档将详细描述系统的功能、性能、安全性、用户界面等方面的需求,并提供相应的附件供参考。
2.业务背景在本章节中,将介绍保理业务的背景和相关的业务流程,以便更好地理解保理信息系统的需求。
2.1 保理业务概述保理业务是指一方(被保理人)将其应收账款转让给另一方(保理商),由保理商提供资金融资和账款管理服务的一种融资方式。
2.2 保理业务流程在此部分,将详细描述保理业务的流程,包括供应商与保理商之间的合作、应收账款转让、资金融资、账款管理和结算等环节。
3.功能需求本章节将列出保理信息系统的功能需求,包括但不限于以下内容:3.1 用户管理保理信息系统需要实现用户的注册、登录、权限管理等功能,以便管理不同角色的用户,如供应商、保理商、资金方等。
3.2 业务流程管理保理信息系统需要支持保理业务的各环节管理,如应收账款转让、资金融资、账款管理、结算等,确保业务流程的顺畅进行。
3.3 资金融资管理保理信息系统需要提供资金方案管理功能,包括资金方信息管理、融资方案设定、融资申请与审批、资金调度等,以满足资金方的需求。
3.4 应收账款管理保理信息系统需要提供应收账款管理功能,包括应收账款登记、查询和统计分析等,以便企业对应收账款进行有效管理。
3.5 风险管理保理信息系统需要实现风险管理功能,包括风险评估与监控、风险预警和应对措施等,以保证保理业务的安全性和稳定性。
3.6 报表与统计保理信息系统需要提供丰富的报表与统计功能,以辅助用户进行决策和分析,同时满足监管报表的要求。
4.性能需求本章节将列出保理信息系统的性能需求,包括但不限于以下内容:4.1 响应时间系统应具备良好的响应时间,用户在进行操作时不会出现卡顿或无响应的情况,能够快速地获取所需信息。
4.2 并发处理系统应能够处理大量的并发请求,能够同时服务多个用户,并保持系统的稳定性和性能。
招商银行网上国内保理用户手册
招商银行网上国内保理用户手册一、概述1、定义和概念保理业务是指由保理商向销售商提供的一种综合性金融服务,包括销售商与买方订立货物销售合同所产生的应收账款,以及与该等应收账款有关的一系列风险管理和融资服务。
其中,销售商指的是通过向保理商申请保理服务来解决其资金需求和信用风险问题的企业。
买方则是指与销售商签订货物销售合同并产生应收账款的自然人或法人。
保理业务中的应收账款是指销售商向买方销售货物或提供劳务后,按照合同约定向买方索取货款的权利。
在保理业务中,销售商将其应收账款转让给保理商,保理商则向销售商提供一系列风险管理和融资服务,包括对买方的信用评估、应收账款的催收、坏账风险的承担、资金周转的协助等。
保理业务中的风险管理和融资服务是指保理商根据销售商的需求和应收账款的情况,向其提供的一系列金融服务。
其中,风险管理服务包括对买方的信用评估、应收账款风险评估、风险准备金计提等;融资服务则包括向销售商提供应收账款融资、对销售商的短期资金需求提供流动性支持等。
保理业务的申请人通常是中小企业或个体工商户,因为这些企业通常缺乏有效的融资渠道和风险管理手段。
保理业务也有助于提高企业的资金使用效率、降低融资成本、优化财务报表、减轻税负等。
总之,保理业务是一种为销售商提供综合性金融服务的业务,旨在解决其资金需求和信用风险问题,提高企业的经营效率和财务状况。
2、保理业务的历史与发展保理业务源自于国际贸易中对于买方和卖方的信任需求。
最初,保理服务主要应用于国际贸易领域,随着经济的不断发展,保理业务也逐渐扩展到国内贸易领域。
招商银行作为国内领先的金融机构之一,早在上世纪90年代就开始探索保理业务,并且逐步形成了以“诚信、尊重、公平、执行”为核心价值观的保理业务品牌。
随着互联网技术的不断发展,招商银行在网上国内保理业务方面也取得了长足的进步。
通过不断的技术创新和服务升级,招商银行网上国内保理业务已经成为市场上最具竞争力的保理产品之一。
保理业务管理系统解决方案
1.保理业务管理系统解决方案1.1.产品描述保理业务管理系统解决方案为商业保理公司展开保理业务提供信息化服务,功能包括客户管理、产品管理、项目管理、合同管理、作业管理、财务管理、预警管理、查询统计、日志管理、流程管理、系统管理。
系统支持保理业务流程全生命周期管理,提供应收账款管理、应收账款融资功能、销售分账户管理、利息/手续费催收、风险控制、移动商务。
系统提供外部系统接口平台,能快速、方便的与第三方系统对接,系统已实现与核心企业销售数据对接、财务核算系统对接、金税系统对接、数据中心。
1.2.产品特点●成熟领先的商业保理系统1)产品成熟:软通动力商业保理产品自2015年在农投保理成功实施以来,到目前为止已有多家商业保理公司采用软通动力的商业保理解决方案。
2)业务流程化:保前调查、保中审查、保后检查均可线上操作。
3)消息提醒及时性:业务功能完成后用户通过消息提醒、待办提醒告知后续功能用户即时登录系统操作。
4)风险预警:自定义风险预警,预警数据即时通知相关人员,便于相关人员掌握风险,即时纠正风险、规避风险,对于保理业务起到至关重要作用。
5)高稳定性、高并发性:系统按照100人并发、1000人同时在线的标准建设,经过压力测试工具检验,均达到设计要求。
6)软件界面友好:界面简洁清晰,用户交互采用EASYUI,统一数据录入校验格式,统一数据表格展示、排序,兼容IE9+、火狐、Google Chrome。
7)扩展性、开放性:系统采用模块化设计,遵循低耦合、高内聚原则,对外服务均采用IESB进行管理。
8)稳定性、可移植行:系统支持Windows、Unix操作系统,中间件采用Weblogic、Tomcat,数据库使用Oracle11g、Oracle 12c、MySQL5.7,保证了整个技术平台的先进性和可靠性。
9)零客户端:系统基于B/S架构开发,客户端只需浏览器即可进行系统操作。
●支持保理类型丰富按照需求定义产品类型,支持国内保理、池保理、反向保理、双保理、再保理,根据产品类型可以自定义业务流程。
信息管理系统需求说明书
信息管理系统需求说明书信息管理系统需求说明书1.引言1.1 目的本文档旨在定义和说明信息管理系统的需求,从而满足用户的信息管理及处理需求。
1.2 范围本文档适用于设计和开发信息管理系统的整个过程,包括需求分析、系统架构设计、模块开发、系统集成和测试等。
1.3 定义在本文档中,以下术语具有特定的含义:●信息管理系统:指用于收集、存储、处理和管理各种类型信息的计算机系统。
●用户:指系统的最终使用者。
2.业务背景2.1 业务概述详细描述信息管理系统所要管理的业务领域,以及相关业务流程和数据。
2.2 业务需求列出用户对信息管理系统的基本需求,如数据收集、数据存储、数据分析等。
3.功能需求3.1 系统功能概述描述信息管理系统的基本功能,包括数据输入、数据存储、数据查询、数据分析等。
3.2 功能详细描述详细描述每个功能的具体要求和功能流程,包括输入、处理和输出等。
4.非功能需求4.1 性能需求描述信息管理系统对于数据处理、数据存储和查询等方面的性能要求。
4.2 可靠性需求描述信息管理系统对于数据的可靠性要求,如数据完整性、数据可用性等。
4.3 安全性需求描述信息管理系统在数据访问和传输过程中的安全性要求,如数据加密、权限控制等。
5.界面需求描述信息管理系统的用户界面,包括界面布局、交互方式和界面设计原则等。
6.数据需求6.1 数据字典列出信息管理系统中使用的所有数据对象及其属性,包括数据类型、数据长度、数据关联关系等。
6.2 数据处理描述信息管理系统对于数据输入、处理和输出的要求和流程。
7.系统架构需求描述信息管理系统的整体架构,包括系统组成、模块划分和模块间的关系等。
8.测试需求描述信息管理系统的测试策略和测试方法,包括单元测试、接口测试、系统测试等。
9.项目实施计划描述信息管理系统的项目实施计划,包括开发阶段、测试阶段和上线阶段的计划安排。
10.维护和支持需求描述信息管理系统的维护和支持要求,包括系统更新、问题解决和用户培训等。
信息系统需求说明书
业务流程分析
业务流程梳理
确定业务流程的目标和范围
评估业务流程的效率和效果
识别业务流程中的关键活动和任务
优化业务流程,提高效率和效果
分析业务流程中的数据流和信息流
制定业务流程的文档和规范
业务流程优化
优化目标:提高 效率、降低成本、 提高客户满意度
优化方法:流程 再造、流程自动 化、流程标准化
优化效果:缩短 流程时间、减少 人力成本、提高 流程质量
架构设计要素: 硬件、软件、网 络、数据、安全
架构设计工具: UML、 ArchiMate、4+1 视图模型
系统平台选择
操作系统:Windows、Linux、Mac OS等
开发工具:Eclipse、Visual Studio、 PyCharm等
数据库系统:MySQL、Oracle、SQL Server 等
数据存储与处理
数据类型:文 本、数字、图 像、音频、视
频等
数据存储方式: 数据库、文件、
云存储等
数据处理技术: 数据清洗、数 据挖掘、数据
分析等
数据安全与隐 私保护:加密、 访问控制、数
据备份等
数据安全与保密
数据加密:采用加密技术对数据进行加密处理,确保数据在传输过程中的安全性 访问控制:设置访问权限,确保只有授权用户才能访问数据 数据备份:定期备份数据,防止数据丢失或损坏 安全审计:定期进行安全审计,确保数据安全策略的有效性和合规性
功能需求优先级排序
核心功能:满足用户基本需求,确保系统正常运行 重要功能:提高用户体验,增强系统竞争力 次要功能:优化系统性能,提高系统效率 边缘功能:满足特殊需求,提高系统灵活性
技术方案设计
系统架构设计
医疗保险信息系统需求说明书
医疗保险信息系统需求说明书医疗保险信息系统需求说明书●引⾔●编写⽬的⽬的:1)正确表达医保中⼼建⽴医疗保险系统的需求,为系统设计⼈员和程序开发⼈员提供系统需求的依据。
2)为系统的维护和升级提供参考资料。
预期读者:系统分析员、系统设计师、程序开发⼈员、系统使⽤⼈员。
同其他系统的联系:医疗保险中⼼领导、各参保单位领导、各医院医疗信息系统●背景系统名称:医疗保险信息系统项⽬任务提出者:北京医疗保险中⼼项⽬开发者:中国⼈民⼤学信息学院Vivian项⽬使⽤者:北京医疗保险中⼼及各⼤医院●任务概述●⽬标加快医疗保险制度改⾰,建⽴城镇职⼯基本医疗保险制度,为⼴⼤职⼯提供基本的医疗保障,是党的⼗五⼤和九届⼈⼤⼀次会议明确提出的重要任务,是政府的五项重要改⾰之⼀,这关系到社会主义市场经济体制的建⽴与完善,关系到改⾰、发展和稳定的⼤局,关系到我国跨世纪战略⽬标的实现。
建⽴城镇职⼯基本医疗保险制度,即适应社会主义市场经济体制,根据财政、企业和个⼈的承受能⼒,建⽴保障职⼯基本医疗需求的社会医疗保险制度。
建⽴医疗保险制度的⽬标是:基本医疗保险的⽔平要与社会主义初级阶段⽣产⼒发展⽔平相适应;城镇所有⽤⼈单位及其职⼯都要参加基本医疗保险,实⾏属地管理;基本医疗保险费由⽤⼈单位和职⼯双⽅共同负担;基本医疗保险基⾦实⾏社会统筹和个⼈帐户相结合。
医疗保险机构是为参保单位或个⼈提供医疗保险服务的专门机构。
参保单位或个⼈在医保中⼼建⽴档案,缴纳相关费⽤,享受相关的医疗保险服务。
以往对于各项医保服务都是进⾏纯⼿⼯操作;但随着参保⼈员的不断增多以及各项医保服务的完善和扩充,⽆疑,再完全由⼈⼯处理各项服务将会给医保⾏业带来很多不必要的⿇烦,⽐如:由于操作⼈员记录失误带来的档案登记错误,由于信息不流通带来的缴费延迟等等。
在这种情况下,医保中⼼就需要借助于现代飞速发展计算机技术和数据库技术建⽴⼀个功能庞⼤的医疗保险信息系统。
该系统可以将绝⼤多数⼈⼯服务转为计算机内部实现,既减少了⼯作⼈员的负担,⼜具有准确,⾼效,流通性好的优势,⼤⼤提⾼整个医疗保险中⼼的服务效率。
保理信息系统需求说明书
【保理系统】需求说明书目录1 引言 (3)1.1 编写目的 (3)1.2 范围 (3)1.3 定义 (3)1.4 参考资料 (3)2 项目概述 (3)2.1 目标 (3)2.2 产品功能 (4)2.3 用户特点 (5)2.4 假定和约束 (5)3 具体需求 (6)3.1 功能需求 (6)3.2 性能需求 (8)3.3 外部接口需求........................................... 错误!未定义书签。
3.4 属性 (9)3.5 其他需求 (10)4 运行环境需求 (10)4.1 设备 (10)4.2 支持软件 (10)4.3 接口................................................... 错误!未定义书签。
4.4 控制................................................... 错误!未定义书签。
5 附录 (11)1引言1.1编写目的此文档用于说明描述保理系统的系统提供功能,业务流程情况及运营说明。
1.2范围本文档的适用范围为项目开发人员、业务或需求分析人员、测试人员、用户文档编写者、项目管理人员,也适用于客户。
该产品是在积累了丰富业务经验的基础上进行开发的,在需求上,充分考虑了具体用户的实际情况。
1.3定义1.4参考资料2项目概述2.1目标本系统的目标是能够提供一套简单的保理业务支撑平台,能够在一定人工运营的基础上完成保理业务的流程处理,符合实际业务要求。
系统功能主要面对四方面使用者:A: 卖方用户(供应商)B: 买方用户(经销商)C:银行人员D: 系统运营人员2.2产品功能本软件为用户提供一个保理业务支撑平台,能在运营支持上提供一套基础的保理业务流程。
2.3系统总体业务流程2.4用户特点面相4方用户:1:卖方:提交单据2:买方:确认单据3:银行人员:查询下载融资单据4:运营人员:审核单据,单据申请融资,买卖家管理,合同管理,资金源管理2.5假定和依赖本项目是否能够成功实施,主要取决于以下几点:(1)为了项目的开发下的条件和实施,在必要时对现有的业务流程进行合理的调整。
信息系统需求说明书
信息系统需求说明书一、引言信息系统需求说明书旨在详细描述所需的信息系统的功能、性能、安全性、可靠性等方面的要求。
本文将对信息系统的需求进行全面的阐述,确保系统能够满足用户的实际需求。
二、背景随着科技的不断发展,信息系统在各个领域中的作用越来越重要。
为了适应市场的需求和提高企业的效率,我们公司决定开发一个全新的信息系统。
这个系统将在销售管理、库存管理、财务管理等方面提供全面的支持。
三、系统范围与目标本系统的范围包括销售管理、库存管理以及财务管理等模块。
其主要目标是实现销售流程的自动化、库存管理的精确控制以及财务数据的准确统计。
通过该系统,用户可以方便地进行销售订单的处理、库存的管理和财务数据的分析。
四、业务需求4.1 销售管理模块销售管理模块需要具备以下功能:- 销售订单管理:支持创建、修改和删除订单,记录订单状态和交付日期。
- 客户管理:记录客户基本信息,包括联系方式、历史订单等。
- 销售报表:实时生成销售统计报表,包括销售额、销售数量等指标。
4.2 库存管理模块库存管理模块需要具备以下功能:- 库存记录:记录库存的入库和出库情况,包括商品名称、数量、入库日期等信息。
- 库存查询:根据商品名称和库存数量等条件查询库存情况。
- 库存预警:当库存数量低于设定的阈值时,系统自动发送预警信息。
4.3 财务管理模块财务管理模块需要具备以下功能:- 费用管理:记录各类费用支出,包括采购成本、营销费用等。
- 财务报表:实时生成财务报表,包括利润表、资产负债表等。
五、非功能性需求5.1 性能要求- 系统响应时间应不超过2秒。
- 系统能够同时支持1000个用户并发操作。
5.2 安全要求- 用户登录采用用户名、密码的方式进行验证。
- 系统要有权限管理机制,不同用户拥有不同的权限。
5.3 可靠性要求- 系统应具备数据备份和恢复的功能,确保数据安全。
- 系统应具备容错机制,能够通过自动恢复和重启等方式解决系统故障。
六、总结通过对信息系统的需求进行详细描述,我们已经清楚了系统的功能、性能和安全等方面的要求。
信息系统需求文档
信息系统需求文档第一点:信息系统需求概述信息系统在现代企业的运营中起着举足轻重的作用。
一个高效、稳定的信息系统能够为企业带来巨大的竞争优势,提高企业的运营效率,降低运营成本,增强企业的核心竞争力。
本文档主要描述了企业信息系统的需求,包括系统的功能需求、性能需求、可用性需求等。
1.1 功能需求功能需求是信息系统最基本的需求,它描述了系统需要实现的功能和特性。
根据企业的业务需求和运营需求,本文档提出了以下功能需求:1.数据采集与录入:系统需要能够采集和录入企业的基本信息、业务数据等,为后续的数据处理和分析提供基础。
2.数据处理与分析:系统需要具备数据处理和分析的能力,能够对采集到的数据进行处理和分析,生成各种报表和统计数据,为企业决策提供依据。
3.数据查询与展示:系统需要提供便捷的数据查询和展示功能,让用户能够快速找到所需的信息,并能够以图表、列表等形式展示信息。
4.数据安全管理:系统需要具备数据安全管理的能力,包括数据的备份、恢复、权限控制等功能,确保数据的安全性和完整性。
5.用户管理:系统需要能够管理用户的信息和权限,包括用户的注册、登录、权限分配等功能,保证系统的安全性和稳定性。
1.2 性能需求性能需求是信息系统的重要组成部分,它描述了系统在各种不同情况下的性能表现。
根据企业的业务需求和运营需求,本文档提出了以下性能需求:1.响应时间:系统需要能够在用户发起请求后,尽快做出响应。
根据实际的业务需求,系统需要能够在秒级或毫秒级完成响应。
2.并发能力:系统需要能够支持多用户同时访问和操作,保证系统的稳定性和可靠性。
根据实际的业务需求,系统需要能够支持数千或数万并发用户。
3.数据处理能力:系统需要能够处理大量的数据,包括数据的采集、存储、处理和分析等。
根据实际的业务需求,系统需要能够处理数亿或数十亿级别的数据。
4.系统可用性:系统需要能够提供高可用性的服务,保证系统的稳定性和可靠性。
根据实际的业务需求,系统需要能够实现故障转移、故障恢复等功能。
CLGL_需求规格说明书
道路运输车辆管理信息系统需求规格说明书编号:CLGL_REQ_001版本:V1.0发布时间:2009-12-30成都兆益科技发展有限责任公司文件变更记录*A - 增加 M - 修订 D - 删除目录1产品介绍 (1)2产品面向的用户群体 (1)3产品应当遵循的标准或规范 (2)4产品范围 (2)5产品中的角色 (2)6产品的功能性需求 (2)6.1需求分类 (2)6.2我要申请 (4)6.2.1固定资产申请 (4)6.2.2设备购置入库申请 (5)6.3设备维护 (6)6.3.1设备管理查看 (6)6.3.2设备管理浏览 (7)6.3.3设备管理 (7)6.3.4设备库浏览 (9)6.3.5设备出入库记录 (9)6.3.6设备库存 (10)6.3.7设备库存分类统计 (11)6.3.8我的设备 (11)6.3.9设备库存出库 (12)6.4工作任务 (13)6.4.1我的工作 (13)6.4.2我参与未完成 (13)6.4.3我与已完成 (14)6.4.4所有未完成 (15)6.4.5所有已完成 (15)6.5条码维护 (16)6.5.1条码生成 (16)6.5.2条码生成历史 (17)6.6参数设置 (18)6.6.1管理类别 (18)6.6.2签名管理 (19)6.6.3报废期限管理 (20)6.6.4设备来源管理 (21)6.6.5供应商管理 (22)6.6.6规格管理 (23)7产品非功能性需求 (24)8接口需求 (31)9其它需求 (31)《需求规格说明书》客户确认本《需求规格说明书》完整地体现“中银保险浙江分公司”项目的需求,同意项目按此说明书进行实施。
签字(签章):日期:1产品介绍云南省公路运输管理局负责云南省道路运输车辆的行业管理工作。
随着社会主义市场经济体制的不断建立和完善,信息技术的飞速发展,政府职能正在逐步由管理型向服务型转变,推行电子政务是对传统行政管理方式的深刻变革,其实质是对现有的政府形态进行改造,利用信息技术来构造更适合信息时代要求的政府治理结构和运行方式,因此,大力推进信息化建设,实现信息资源共享,在建设省、州市、县三级网络和数据交换平台的基础上,以数据为核心,整合道路运输信息资源,逐步建立信息交换共享和集中发布协调机制,建设一个规范、统一、信息资源共享的全省数据中心,统一管理道路运输公共数据资源,通过对各类数据资源进行集成加工,为政府和社会提供服务。
信息系统需求说明书示例模板
XXX需求说明书XXXX-XX-XX1引言 (2)1.1编写目的 (2)1.2背景 (2)1.2.1现状描述 (2)1.2.2系统开发目的 (2)1.2.3软件部署位置及网络 (2)1.2.4与其他系统的关系 (2)1.3定义 (3)1.4参考资料 (4)2概述 (5)2.1目标 (5)2.2用户特点 (5)2.3用户角色 (5)2.4系统运用情况 (5)2.5假定和约束 (6)3需求分析 (6)3.1业务概述 (6)3.2系统结构图 (6)3.3功能清单 (6)3.4系统流程图 (7)3.4.1企业管理 (7)4系统功能描述 (7)4.1企业管理 (7)4.1.1企业基本资料 (8)4.1.1.1数据条目 (8)4.1.1.2数据收集方式 (8)4.2对性能的规定 (8)4.2.1数据精度要求 (8)4.2.2时间特性要求 (9)4.2.3灵活性 (9)4.3输入输出要求 (9)4.4数据管理能力要求 (9)4.5故障处理能要求 (9)4.6其他专门要求 (9)5运行环境规定 (9)5.1设备 (9)5.2支持软件 (10)5.3接口 (10)5.4控制 (10)6文件需求支持 (10)1引言1.1编写目的本软件需求说明书根据“XXX信息化项目”招投标文件,XXX部分基本需求概述及功能清单编写而成,意在作为项目需求调研的指南版本;本软件需求说明读者范围:软件开发需求调研人员、软件使用方需求调研人员。
1.2背景1.2.1现状描述在根据招投标相关文件的基础上形成用户软件需求说明,项目建设方和软件使用方对需求内容进行确认,软件供应商根据软件需求说明确认的基础进行开展软件概要设计、详细设计、系统开发、测试、系统交付、验收;1.2.2系统开发目的根据项目建设方及软件使用方的实际需求开发完成XXX,为XXX业主运营管理提供信息化、数字化、智能化的管理手段,提高运营管理水平。
1.2.3软件部署位置及网络XXX将不属于用户指定的网络机房及云服务设备上;1.2.4与其他系统的关系XXX将同其他系统或其他机构的系统发生数据共享与交互,数据交互传输方式及与其他系统或其他机构的系统交互的数据结构,由软件建设及使用方进行协调提供。
保理业务管理系统解决方案
1.保理业务管理系统解决方案1.1.产品描述保理业务管理系统解决方案为商业保理公司展开保理业务提供信息化服务,功能包括客户管理、产品管理、项目管理、合同管理、作业管理、财务管理、预警管理、查询统计、日志管理、流程管理、系统管理。
系统支持保理业务流程全生命周期管理,提供应收账款管理、应收账款融资功能、销售分账户管理、利息/手续费催收、风险控制、移动商务。
系统提供外部系统接口平台,能快速、方便的与第三方系统对接,系统已实现与核心企业销售数据对接、财务核算系统对接、金税系统对接、数据中心。
1.2.产品特点●成熟领先的商业保理系统1)产品成熟:软通动力商业保理产品自2015年在农投保理成功实施以来,到目前为止已有多家商业保理公司采用软通动力的商业保理解决方案。
2)业务流程化:保前调查、保中审查、保后检查均可线上操作。
3)消息提醒及时性:业务功能完成后用户通过消息提醒、待办提醒告知后续功能用户即时登录系统操作。
4)风险预警:自定义风险预警,预警数据即时通知相关人员,便于相关人员掌握风险,即时纠正风险、规避风险,对于保理业务起到至关重要作用。
5)高稳定性、高并发性:系统按照100人并发、1000人同时在线的标准建设,经过压力测试工具检验,均达到设计要求。
6)软件界面友好:界面简洁清晰,用户交互采用EASYUI,统一数据录入校验格式,统一数据表格展示、排序,兼容IE9+、火狐、Google Chrome。
7)扩展性、开放性:系统采用模块化设计,遵循低耦合、高内聚原则,对外服务均采用IESB进行管理。
8)稳定性、可移植行:系统支持Windows、Unix操作系统,中间件采用Weblogic、Tomcat,数据库使用Oracle11g、Oracle 12c、MySQL5.7,保证了整个技术平台的先进性和可靠性。
9)零客户端:系统基于B/S架构开发,客户端只需浏览器即可进行系统操作。
●支持保理类型丰富按照需求定义产品类型,支持国内保理、池保理、反向保理、双保理、再保理,根据产品类型可以自定义业务流程。
产品说明书供应商保理系统互融云样本
供应商保理系统产品说明书
文档时间: 6月
目录
1.产品介绍 (3)
2.系统优势 (3)
3.功能结构 (4)
4.功能清单 (4)
5.品质服务 (9)
6.技术架构 (10)
7.海量经验 (11)
7.1.十余年项目服务支持经验 (11)
7.2.唯一一家全业务软件企业 (11)
7.3.专家级解决方案制定 (11)
1.产品介绍
互融云供应商保理系统拥有自主知识产权, 基于JAVA技术开发, 在多年行业经验基础上为广大保理服务商提供最专业的保理系统服务和解决方案, 支持多种投融资业务, 适用于经营核心企业保理业务、供应商保理业务等的保理公司, 系统包括: 业务管理、票据管理、票据查询、贷后管理、保理台账、业务查询、风控管理、网站内容管理、运营管理等基本功能板块。
2.系统优势
3.功能结构
4.功能清单。
保理平台申请书模板
尊敬的XX保理平台:我代表我方公司(以下简称“申请人”),向贵保理平台提交申请,希望贵平台能为我们提供国内保理业务服务。
以下是我方公司对贵保理平台的申请资料:一、申请人基本信息1. 公司名称:XXX有限公司2. 成立时间:XXXX年3. 注册资本:人民币XX万元4. 注册地址:XX省XX市XX区5. 经营范围:XXX行业相关业务6. 法人代表:XXX7. 联系方式:电话:XXX,邮箱:XXX二、申请保理业务类型1. 业务类型:国内保理业务2. 应收账款金额:人民币XX万元3. 应收账款期限:XX个月4. 融资需求:人民币XX万元三、申请人财务状况1. 最近一年审计报告:附件2. 最近一个月财务报表:附件3. 应收账款情况:详细列出应收账款明细,包括购货方名称、合同金额、已收款金额、未收款金额等。
四、申请人信用状况1. 信用评级报告:附件2. 贷款卡(证):附件3. 法人代码证:附件五、购货方信息1. 购货方名称:XXX有限公司2. 营业执照号:XXX3. 联系人:XXX4. 联系方式:电话:XXX,邮箱:XXX5. 购货方财务状况:提供购货方最近一年审计报告或财务报表。
六、交易背景及应收账款情况1. 交易背景:详细描述申请人与购货方的交易背景,包括货物或服务内容、合同签订时间、合同履行情况等。
2. 应收账款情况:提供经购货方确认的应收账款对账单,标明相关交易合同应收账款付款情况、付款期限及付款条件明细。
七、其他资料1. 申请人公司简介:提供申请人公司简介,包括公司经营情况、市场竞争力、发展前景等。
2. 法定代表人及管理人员资格证明:提供法定代表人及管理人员的相关资格证明。
3. 授权委托书:如法定代表人授权他人代为办理保理业务,需提供授权委托书及受权人身份证明。
我们希望贵保理平台能对我们的申请进行认真审核,并尽快给予答复。
我们相信,通过贵保理平台的服务,我们将能更好地解决应收账款融资问题,提高公司经营效益,实现双方共赢。
传统保理业务系统需求分析说明书
第1章引言 (1)1.1 编写目的 (1)1.2 工程背景 (1)1.3 业务术语 (2)1.4 业务涉及的标准与标准 (2)1.5 参考资料 (2)第2章总体需求描述 (4)2.1 目标 (4)2.2 预期用户 (4)2.3 业务品种总体描述 (4)2.3.1 有追索权保理业务描述 (4)2.3.2 无追索权保理业务描述 (4)2.3.3 其他 (4)2.4 总体业务流程描述与风险限制要点 (5)2.4.1 业务全流程总体描述 (5)2.4.2 全流程总体风险限制要点 (8)2.5 各业务品种业务流程与风险限制要点 (11)2.5.1 有追索权保理业务流程与风险限制要点 (11)2.5.2 无追索权单保理业务流程与风险限制要点 (15)2.5.3 行内双保理业务流程与风险限制要点 (20)2.6 系统功能总体描述 (27)2.7 与其他系统〔业务〕的关系 (28)2.7.1 与对公信贷治理系统的关系 (28)2.7.2 与核心系统的关系 (29)2.7.3 与其他系统的关系 (31)第3章业务需求详细描述 (33)3.1 业务操作治理 (33)3.1.1 业务操作内容 (33)3.1.2 操作权限限制 (33)3.1.3 二级核准治理 (34)3.1.4 日常交易操作错误治理 (35)3.1.5 日志治理 (37)3.2 风险治理概要 (37)3.2.1 风险控管概要 (37)3.2.2 额度控管要求 (40)3.3 账务治理概要 (43)3.3.1 会计账务治理总体原那么概述 (43)3.3.2 会计科目治理功能 (44)3.3.3 传票账务治理功能 (44)3.3.4 通过传票账务设置来建立出账行规那么 (45)3.3.5 通过传票账务设置来建立账务归户规那么............................... 4 53.3.6 通过传票账务设置来建立额度治理规那么 (46)3.3.7 通过传票账务设置来建立不同业务品种的治理规那么 (47)3.3.8 依据以上治理规那么在交易发生自动核算账务并记账 (47)3.3.9 治理所有历史账务流水 (48)3.4 利息治理 (48)3.4.1 利息计提 (48)3.4.2 结息方式 (49)3.4.3 利率调整、浮动方式 (49)3.5 费用治理 (50)3.5.1 计费方式 (50)3.5.2 收取方式 (50)3.5.3 支付方式 (50)3.6 根底信息治理 (50)3.6.1 客户信息治理 (50)3.6.2 额度信息治理 (52)3.6.3 合同信息治理 (54)3.7 正常交易治理 (55)3.7.1 账款受让 (55)3.7.2 预付款支用 (57)3.7.3 预付款偿付 (57)3.7.4 账款回收........................................................... 5.8 3.8 异常交易治理. (59)3.8.1 商业纠纷及账款折让 (59)3.8.2 买方退货 (60)3.8.3 账款逾期 (60)3.8.4 预付款逾期 (61)3.8.5 担保付款 (62)3.8.6 账务冲正 (63)3.9 参数治理 (63)3.9.1 公用参数治理 (63)3.9.2 系统参数治理 (64)3.10 用户与权限治理 (65)3.10.1 组织机构与用户治理 (65)3.10.2 权限治理 (66)3.11 在线帮助 (67)3.12 报表治理 (67)第1章引言1.1 编写目的编写本工程需求分析说明书的目的是为了使用户和开发者双方对该系统的功能和需求有一个共同的理解,使之成为整个系统客户化开发工作的根底, 便于系统开发过程中的限制与治理.本需求分析说明书是整个系统开发的主要依据之一,对工程的设计、开发构建和系统测试等阶段提供依据;为设计工程方案、核定工程本钱、编制方案进度提供文字依据;同时为对工程的完成进行用户测试、用户确认和验证提供支持.1.2 工程背景在参加WTCB,国内银行面临着跨国金融集团进入国门所带来的巨大挑战, 毋庸置疑中间业务将成为双方竞争的主要阵地, 而保理业务更是外资银行凭借其技术和实力优势而志在必得的业务领域.在我国业已结束的“入世〞双边谈判所达成的协议中,保理业务被明确列入开放工程. 和国外同行相比,无论是保理业务的专业技术人员方面,还是运作治理方面,我们都明显处于劣势.另外,随着传统资产负债业务的盈利空间不断缩小和同业竞争的进一步加剧,银行迫切需要开展中间业务,寻求新的利润增长点.保理业务属于银行的中问业务,其收益高于传统的贷款业务.此项业务一般按销售额收取一定比率的手续费用以及治理费用,并对企业获得的融资款收取利息,且年利率通常较银行优惠利率高出一定比例.为此,开展保理业务对银行来说无疑具有十分重要的现实意义.中国XX银行获人行批准自2003年开办保理业务.保理业务是指卖方将其现在或将来的基于其与买方订立的货物销售合同和劳务合同所产生的应收账款, 根据契约关系转让给中国XX银行,由中国XX银行针对受让的应收账款为卖方提供销售分户账治理、应收账款催收、保理预付款、信用销售限制和信用风险担保等效劳中的特定的两项或两项以上的综合性金融效劳产品.保理业务开办至今XX银行一直采取手工操作模式.随着业务的逐步推广, 迫切需要有相应的IT系统支持保理业务的流程治理、风险治理、会计核算及数据信息治理等,到达优化流程、标准操作、增强风险防范,增强市场竞争力的目的.1.3 业务术语1〕保理:指XX银行接受基于商业贸易中形成的应收账款债权,并为卖方提供信用风险担保或预付款支用或应收账款治理或催收的效劳;2〕应收账款:应收账款是指企业因赊销产品或劳务而形成的债权,3〕有追索权保理:指建行银行为企业提供账款催收、销售账户治理以及发票预付款支用效劳,但不承当买方信用风险.4〕无追索权保理:指XX银行有条件地买断企业的应收账款债权,并提供信用风险担保和预付款支用效劳.1.4 业务涉及的标准与标准1〕?GRIF〉或?国际保理通那么?,FCI,世界保理商联合会2〕?国际保理公约?,国际统一司法协会3〕?联合国国际贸易中应收账款转让公约?,联合国4〕?中华人民共和国合同法?5〕?中华人民共和国共和国物权法?6〕?中华人民共和国担保法?7〕?中华人民共和国商业银行法?1.5 参考资料1〕?GRIF〉或?国际保理通那么?,FCI,世界保理商联合会2〕?国际保理公约?,国际统一司法协会3〕?联合国国际贸易中应收账款转让公约?,联合国4〕?中华人民共和国合同法?5〕?中华人民共和国共和国物权法?第2章总体需求描述2.1目标保理业务系统为XX银行国内保理业务的治理和操作提供一个运行平台,通过该平台实现以下业务目标:1〕实现保理业务操作电子化,提升业务效率;2〕标准全行保理业务操作和执行规划;3〕实现总行、一级行等保理业务治理部门对保理业务的治理和业务监控;4〕实现保理业务的准入、审核、审批、支用、账户治理、风险监控等全流程的治理;5〕建立国内保理业务支撑平台,支持保理业务的产品创新.2.2 预期用户系统的最终用户定位于总行保理业务治理岗位、一级分行保理业务治理岗位、二级行保理业务操作岗位.2.3 业务品种总体描述2.3.1 有追索权保理业务描述有追索权保理是指建行银行为企业提供给收账款治理和预付款效劳,但不承当买方信用风险.有追索权保理以单保理方式提供.2.3.2 无追索权保理业务描述无追索权保理是指XX银行有条件地买断企业的应收账款债权,并提供给收账款治理、预付款和信用风险担保效劳.无追索权保理主要通过“单保理〞和“行内双保理〞两种方式提供效劳.2.3.3 其他系统需要具备灵活配置业务品种的条件,可以根据对收息方式、追索权、收费方式等要素的灵活组合形成新的业务品种.2.4 总体业务流程描述与风险限制要点2.4.1 业务全流程总体描述如“图2.4 -1〞所示需要与其他业务与治理系统的有效协作,实现保理业 务的 准入、审核、审批、支用、账户治理、风险监控等全流程的治理.CCBS纹果〔图2.4-1保理业务全流程示意图〕流程说明:⑴ 客户提出业务申请时,客户经理判断是否已经完成一般授信.假设没有完成,那么先在对公信贷治理系统系统中完成一般授信,并根据额度授信管理的要求,将该客户的国内保理额度纳入到某一个大类产品额度当中〔暂定为流动资金贷款类额度,尚待风险治理部确定〕.〔2 〕完成授信后,在对公信贷治理系统系统中实施保理业务审批. CLPM; 0-雕信2;煤理业务甫批 ③一合赢h 1-3.CCBFS ⑥ 激度处理 _帐务处理 _4— 特登处理解帐英处室及成款咪籥外理交跑理5 Y还就交曼处理尊而度处理1P(3)完成业务审批后,在对公信贷治理系统系统实施合同审批,确定客户保理额度数量、期限、币种等信息和数据.(4)完成合同审批后,保理业务经办行根据合同审批的要求与客户签署保理合同.(5)对公信贷治理系统系统将审批通过的合同信息传递给保理业务系统, 保理业务系统对相应的客户信息、额度信息、合同信息等进行集中维护.(6)客户提出账款转让与预付款支用申请,客户经理发起完成申请审批, 并提交保理业务系统实施账款受让和支用相关业务处理.(7)完成相关业务处理后保理业务系统暂时扣减相应客户额度.(8)保理业务系统根据交易和支用处理,实施相应的账务处理和会计处理, 并形成相应的会计凭证.(9)保理业务系统完成账务和会计处理后形成支用通知和相应的会计凭证.(CCBFSf核心系统系统连接之间,打印会计凭证和支用通知)(10)核心系统系统根据保理业务系统提供的会计凭证和支用通知实施账务处理后和支用操作.(保理业务系统与核心系统系统连接前,柜面会计人员核对会计凭证和支用通知,根据会计凭证和支用通知在核心系统系统中实施会计处理.)(11)核心系统系统在完成账务处理和支用处理后, 保理业务系统通过查询获取相关结果数据.(12)保理业务系统根据查询结果,实施相应的账务处理,并为额度治理提供结果依据.假设支用成功,那么通过;假设支用不成功,那么更正已经初建的账务数据. (13)保理业务系统根据查询结果,对额度实施相应的处理.假设支用及账务处理通过,那么额度扣减保持不变.假设支用失败,那么复原预先扣减的额度.(14)客户还款时(卖方还款或买方还款),保理业务系统实施还款交易处理.(15)完成还款交易处理后,保理业务系统记录还款对应需要释放的额度.(暂时不释放)(16)完成额度处理后,保理业务系统实施相应的账务处理和会计处理.(17)保理业务系统形成相应的还款通知或还款信息以及相应的会计凭证提交给核心系统系统.(系统未完成连接,手工操作阶段,打印还款通知和相应的会计凭证.)(18)核心系统系统根据保理业务系统的还款信息和会计信息实施还款操作和账务处理.(系统未完成连接,手工操作阶段.柜面操作人员审核会计凭证和还款通知,并在核心系统系统中实施还款操作和会计处理.)(19)核心系统系统在完成还款处理和账务处理后,保理业务系统通过查询获取相关结果数据.(20)保理业务系统根据查询结果,实施相应的账务处理,并为保理业务系统额度治理提供结果依据.假设还款成功,那么通过;假设还款不成功那么更正已经初建的账务数据.(21)保理业务系统根据查询结果,对额度实施相应的处理.假设还款及账务处理通过,那么释放额度.假设还款失败,那么不释放额度.(22)保理业务系统根据业务的实际情况实施相应的正常与非正常的业务处理.(23)保理业务系统根据根据业务的实际情况对于某些与额度相关的业务处理实施相应的额度处理(例如发生商业纠纷时,将冻结客户的相关额度等).(24)保理业务系统根据会计准那么和相关业务治理标准,自动实施相应的计息、计提、摊提等账务处理;并根据系统相应的业务处理实施相应的账务处理(如对逾期的预付款计收逾期违约金的处理),并将相应的账务处理结果提交给核心系统系统.(25)核心系统系统根据保理业务系统提供的账务信息实施相应的账务处理.(26)核心系统系统在完成账务处理后,保理业务系统通过查询获取相关结果数据.(27)保理业务系统根据查询结果,实施相应的账务处理,并实施相应的额度处理.(28)保理业务系统根据对公信贷治理系统系统的要求,将客户的额度使用情况按时反应给对公信贷治理系统系统,以便对公信贷治理系统系统实施额度监控.(29)保理业务系统根据十二级分类的要求,将保理合同项下的支用信息反馈给对公信贷治理系统系统供十二级分类使用.2.4.2 全流程总体风险限制要点在全流程当中的主要风险包括信用风险、操作风险和技术性风险.其中主要的信用风险包括了卖方信用风险、买方信用风险、买卖方交易带来的信用风险. 由于具体的信用风险和限制策略与具体的保理业务品种有关,所以这里将主要讨论全流程业务的操作风险和技术性风险,将信用风险的限制要点留在具体保理业务品种的风险限制要点中描述.保理业务全流程的操作风险、技术性风险及相应的限制要点主要包括以下几个方面:1)额度输入风险风险内容:在全流程保理额度由对公信贷治理系统系统负责审批形成,在保理业务系统与对公信贷治理系统系统实现互联之前,由手工将对公信贷治理系统审批的额度录入到保理业务系统当中.这就容易形成相应的操作风险.限制要点:该风险的限制要点包括两个方面.第一是尽快完成两个系统的互联,并在保理业务系统中将该额度设置为一般操作人员不可更改的数据项.第二是在手工录入阶段,增强复核工作.2)保理额度控管风险内容:保理业务系统从对公信贷治理系统系统为每一客户获得一个保理总额度,在操作当中可将该额度分解为客户作为卖方时的额度和作为买方时的额度.限制要点:系统对额度分解工作进行限制,使两额度的总和小于等于保理总额度.3〕交易操作风险风险内容:在保理业务系统当中进行交易操作时,操作内容包括发票录入、收息、收费、支用比例等.由于需要录入的信息量较大,所以容易产生操作失误等问题.限制要点:系统在这个方面提供两种限制方式.第一是在交易提交前设置复核〔主管放行〕进行一次审核,再提交.第二种限制方式是系统提供“冲正〞〔抹账〕处理机制,在交易完成并提交后,发现错误时,系统够通过冲正的方式化解错误操作.4〕支用操作风险风险内容:在核心系统与保理业务系统实现全自动化处理之前,保理业务系统需要打印支用通知和会计凭证,再由柜面人员登录核心系统系统实施操作,这就大大提升了操作风险. 限制要点:对于这种操作风险的限制主要包括两个方面.第一是核心系统自身的管控举措来降低操作风险.第二是通过系统提供的“冲正〞〔抹账〕处理机制,在交易完成并提交后,发现错误时,通过冲正的方式化解错误操作.5〕额度释放风险风险内容:保理业务系统暂时还无法实现与核心系统系统的实时交互,所以在业务操作过程中,保理业务系统中在支用时的额度扣减、还款过程中的额度释放都将存在一定的时延.这就带来的额度释放风险,即在实际完成还款之前就释放了额度.限制要点:对于这个潜在风险的限制,采用额度“剩余值最小化原那么〞.即在支用时,保理业务系统先进行额度扣减,支用正常保持扣减,支用失败,额度复原.在还款时,先不释放额度,在确认还款成功后再释放额度.6〕账务一致性风险风险内容:核心系统系统负责最终支用和还款等操作, 同时在核心系统系统内部也有相应的会计科目和账务处理,同时目前核心系统系统提供的批处理数据传输为“T+1〞.为此,核心系统系统与保理业务系统之间的账务存在着不同的可能性,特别是实现系统实时交互之前,这种潜在风险的概率由于人为操作失误的可能性和时间延迟的问题而加大误差的可能性.限制要点:对于这一潜在风险,风险限制要点主要集中在以下几点:〔1〕在系统实现实时交互之后.首先业务的计息、计费、罚息、结息、计提、摊提、逾期等处理全部由保理业务系统实施, 并将结果传递给核心系统,核心系统根据保理业务系统的处理结果进行账务更新.其次,系统提供直接数据交互,减少人为操作失误.第三,系统通过对账来检验账务一致性. 第四,对于错误操作通过“冲正〞来纠错.〔2〕在系统实现实时交互之前.首先业务的计息、计费、罚息、结息、计提、摊提、逾期等处理全部由保理业务系统实施, 并将结果传递给核心系统,核心系统根据保理业务系统的处理结果进行账务更新.其次,保理业务系统通过核心系统系统的实时查询了解业务处理情况,并根据处理结果操作保理业务系统实施相关账务更新,减少时间延迟带来的误差〔比方计息〕.第三,对于错误操作通过“冲正〞来纠错.7〕贸易真实性风险风险内容:在保理业务预付款支用过程中,通常以商业票据〔发票〕作为债权认定的依据.为此就存在这伪造票据骗取融资的风险.限制要点:对于这个潜在风险的限制,主要包括两个方面.第一是制度上规范,在卖方融资的时候,不仅仅要核对发票,贸易合同,还要实方提供相应的货物验收单等商业凭证.第二是系统操作上,建立 核查岗位,操作人员在操作保理交易时对票据进行检验,在完成 操作,提交后,再有复核岗进行一次核查,再提交才能完成整个 交易的操作过程.2.5 各业务品种业务流程与风险限制要点2.5.1 有追索权保理业务流程与风险限制要点2.5.1.1 业务流程描述如“图2.5—1〞所示,有追索权保理的全业务流程如下:有追索单保理〔图2.5-1有追索权保理业务流程示意图〕卖方信 _________________ 授 业务申请卖方客户经理岗卖方保理岗卖方会计岗买方客户经理岗买方七信息用支款付预理保支用申请回收款账收应维护,受让、核准・ 审核、放行计息、结息 还款交易保埋专尸 开户L户账号 J/-►受让、收费1 呆埋预1、」款计息、结息保理专户:送买方还款ran…|公证送达买方应收账款5让通知书工应收账款,让通知书\ 受理f ______________ />■放款流程注释:I表示在对公信贷治理系统系统内完成的工作;I I表示在保理业务系统内完成的工作;/ / 表不关键信息;I I表示在核心系统系统内完成的工作;; 二?表示在线下手工完成的工作;流程概要:阶段处理行处理方式主要岗位概述业务核准二级行线下客户经理-业务主管国内保理业务申报一级行线下产品经理-业务主管卖方客户准入,买方客户准入*,业务方案审核*买方额度核定一级行线下产品经理保理系统新增买方客户额度〔非授信〕申报总行线下产品经理核定业务审批二级行对公信贷治理系统客户经理-业务主管发起业务审批流程一级行对公信贷治理系统信贷审批人审批可使用额度二级行线下客户经理-业务主管〔行长〕保理合同制作、签章业务信息维护二级行线下客户经理提交客户资料、核准文件、审批文件、合同二级行保理系统操作岗一复核岗业务信息录入〔客户经理提交〕或导入〔对公信贷治理系统〕二级行保理系统操作岗打印“应收帐款转让通知书〞二级行线下客户经理送卖方签章后,公证送达买方正常交易处理受理转让申请二级行线下客户经理受理应收帐款转让朝#二级行保理系统操作岗发票录入应收帐款受让二级行保理系统操作岗一复核岗单据审核、应收帐款受让核准二级行核心系统会计岗〔虚拟柜员〕受让及收费入帐二级行保理系统操作岗打印“应收帐款受让通知书〞、“应收帐款转让通知书〞〔或“帐号更改通知书〞〕二级行线下客户经理送卖方,前者取回执,后者签章后寄送买方〔不需公证〕预付款支用二级行线下客户经理受理预付款支用申请、二级行保理系统操作岗录入支用信息并计算可使用额度二级行线下业务主管放款核准二级行保理系统复核岗复核放行二级行核心系统会计岗〔虚拟柜员〕转帐预付款偿付二级行线下客户经理受理预付款偿付申请、二级行保理系统操作岗一复核岗卖方还款二级行核心系统会计岗〔虚拟柜员〕扣款入账应收帐款收回二级行核心系统会计岗收款入帐〔保理收款专户〕二级行保理系统操作岗一复核岗买方还款〔冲抵保理预付款、利息,尾款付卖方〕二级行核心系统会计岗〔虚拟柜员〕转帐异常交易处理争议二级行线下客户经理收到“争议通知〞二级行保理系统操作岗一复核岗录入争议信息并冻结发票额度帐款折让/退货二级行线下客户经理收到“应收账款调整申请〞二级行保理系统操作岗一复核岗录入争议解决信息、账款折让金额二级行保理系统操作岗打印“保理预付款调整通知书〞二级行线下客户经理通知卖方偿付超额支用的预付款二级行保理系统操作岗一复核岗卖方还款二级行核心系统会计岗〔虚拟柜员〕扣款入账间接还款二级行保理系统操作岗一复核岗卖方还款二级行核心系统会计岗〔虚拟柜员〕扣款入账帐款逾期二级行保理系统操作岗一复核岗额度变更〔冻结买卖方关联额度〕二级行保理系统操作岗打印“应收账款逾期通知书〞二级行线下客户经理寄送买方,通知卖方回购二级行保理系统操作岗一复核岗卖方还款二级行核心系统会计岗〔虚拟柜员〕扣款入账预付款逾期二级行保理系统操作岗一复核岗预付款逾期〔按逾期违约金率计息〕二级行保理系统操作岗一复核岗额度变更〔冻结卖方额度〕2.5.1.2主要风险限制要点有追索权保理的风险相对较小,主要包括卖方客户信用风险、业务品种操作风险等.以上已经描述了系统的技术性风险,为此这里主要描述业务信用风险、业务品种的操作风险及相应的风险限制要点.1〕卖方偿付风险风险内容:尽管有追索权保理可以要求卖方回购,但同样会面临着卖方偿付水平缺乏而形成坏账的风险,或者由于买方的偿付水平缺乏而造成卖方不能按时还款,形成逾期等问题. 限制要点:对于卖方偿付风险的限制主要包括三个方面.第一是制度和操作上需要增强对卖方客户的选择、信用评审、买卖方交易的核查和卖方经营状况的监控.第二个方面是,系统额度控管方面的,即系统在有追索权保理状况下也需要考虑买方的风险额度.第三个方面是,在支付保理预付款时,可以分批、分次发放,而不选择一次性预付全部,以降低潜在的风险损失.2〕假贸易真融资风险风险内容:在保理业务实践中,存在这卖方客户假贸易真融资的可能性,这种可能性虽然较小,但也形成了潜在的风险.。
保理信息系统需求说明书
【保理系统】需求说明书目录1 引言 (3)1.1 编写目的 (3)1.2 范围 (3)1.3 定义 (3)1.4 参考资料 (3)2 项目概述 (3)2.1 目标 (3)2.2 产品功能 (4)2.3 用户特点 (5)2.4 假定和约束 (5)3 具体需求 (6)3.1 功能需求 (6)3.2 性能需求 (8)3.3 外部接口需求........................................... 错误!未定义书签。
3.4 属性 (9)3.5 其他需求 (10)4 运行环境需求 (10)4.1 设备 (10)4.2 支持软件 (10)4.3 接口................................................... 错误!未定义书签。
4.4 控制................................................... 错误!未定义书签。
5 附录 (11)1引言1.1编写目的此文档用于说明描述保理系统的系统提供功能,业务流程情况及运营说明。
1.2范围本文档的适用范围为项目开发人员、业务或需求分析人员、测试人员、用户文档编写者、项目管理人员,也适用于客户。
该产品是在积累了丰富业务经验的基础上进行开发的,在需求上,充分考虑了具体用户的实际情况。
1.3定义1.4参考资料2项目概述2.1目标本系统的目标是能够提供一套简单的保理业务支撑平台,能够在一定人工运营的基础上完成保理业务的流程处理,符合实际业务要求。
系统功能主要面对四方面使用者:A: 卖方用户(供应商)B: 买方用户(经销商)C:银行人员D: 系统运营人员2.2产品功能本软件为用户提供一个保理业务支撑平台,能在运营支持上提供一套基础的保理业务流程。
2.3系统总体业务流程2.4用户特点面相4方用户:1:卖方:提交单据2:买方:确认单据3:银行人员:查询下载融资单据4:运营人员:审核单据,单据申请融资,买卖家管理,合同管理,资金源管理2.5假定和依赖本项目是否能够成功实施,主要取决于以下几点:(1)为了项目的开发下的条件和实施,在必要时对现有的业务流程进行合理的调整。
招商银行网上国内保理业务用户手册
网上国内保理用户手册目录一.欢迎使用招商银行网上国内保理产品................................................. 错误!未定义书签。
二.网上国内保理产品介绍及特点............................................................. 错误!未定义书签。
三.网上票据系统客户端操作指南............................................................. 错误!未定义书签。
1.概述..................................................................................................... 错误!未定义书签。
2.应收款信息查询和维护..................................................................... 错误!未定义书签。
3.应付款信息查询和维护..................................................................... 错误!未定义书签。
4.供应链客户关系查询和维护............................................................. 错误!未定义书签。
5.卖方融资经办..................................................................................... 错误!未定义书签。
6.卖方销账经办..................................................................................... 错误!未定义书签。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
【保理系统】需求说明书
目录
1 引言 (3)
1.1 编写目的 (3)
1.2 范围 (3)
1.3 定义 (3)
1.4 参考资料 (3)
2 项目概述 (3)
2.1 目标 (3)
2.2 产品功能 (4)
2.3 用户特点 (5)
2.4 假定和约束 (5)
3 具体需求 (6)
3.1 功能需求 (6)
3.2 性能需求 (8)
3.3 外部接口需求........................................................................................ 错误!未定义书签。
3.4 属性 (9)
3.5 其他需求 (10)
4运行环境需求 (10)
4.1 设备 (10)
4.2 支持软件 (10)
4.3 接口........................................................................................................ 错误!未定义书签。
4.4 控制........................................................................................................ 错误!未定义书签。
5 附录 (11)
1引言
1.1 编写目的
此文档用于说明描述保理系统的系统提供功能,业务流程情况及运营说明。
1.2 范围
本文档的适用范围为项目开发人员、业务或需求分析人员、测试人员、用户文档编写者、项目管理人员,也适用于客户。
该产品是在积累了丰富业务经验的基础上进行开发的,在需求上,充分考虑了具体用户的实际情况。
1.3 定义
1.4 参考资料
2项目概述
2.1 目标
本系统的目标是能够提供一套简单的保理业务支撑平台,能够在一定人工运营的基础上完成保理业务的流程处理,符合实际业务要求。
系统功能主要面对四方面使用者:
A: 卖方用户(供应商)
B: 买方用户(经销商)
C:银行人员
D: 系统运营人员
2.2 产品功能
本软件为用户提供一个保理业务支撑平台,能在运营支持上提供一套基础的保理业务流程。
2.3 系统总体业务流程
2.4 用户特点
面相4方用户:
1:卖方:提交单据
2:买方:确认单据
3:银行人员:查询下载融资单据
4:运营人员:审核单据,单据申请融资,买卖家管理,合同管理,资金源管理
2.5 假定和依赖
本项目是否能够成功实施,主要取决于以下几点:
(1)为了项目的开发下的条件和实施,在必要时对现有的业务流程进行合理的调整。
(2)项目投资人为调研、开发和实施过程提供必要的工作环境和系统运行环境,这些环境有助
于软件开发开展工作。
(3)项目投资人为软件系统的运行提供必要的且能够满足系统运行条件的硬件环境和通讯环境,不合适的硬件环境和通讯环境将会影响系统的性能和业务支撑程度。
3具体需求
3.1 功能需求
3.1.1 运营端功能需求
3.1.1.1买卖方信息管理
主要用于买卖家基础信息录入,更新和查询管理,由运营人员负责维护,买卖家录入完成后可建立对应的帐号用于登录系统卖家端,系统买家端和使用系统功能。
3.1.1.2资金源信息管理
主要用于资金源(银行)基础信息录入,更新和查询管理,由运营人员负责维护,资金源录入完成后可建立对应的帐号用于登录系统银行端,系统买家端和使用系统功能。
3.1.1.3买卖家合同管理
1:主要用于建立买卖家关联合同信息,更新和查询管理,由运营人员负责维护。
2:合同建立后需关联3.1.1.2建立的对应资金源信息,单据在由买家确认后可提交到对应的资金源(银行)端让银行人员下载进行融资操作。
3:买卖家必须先建立合同关联才能在系统上开展业务流程,卖家可进行订单提交,买家可进行单据确认。
3.1.1.4单据审核
运营人员在此页面对卖家提交到系统的单据进行人工审核,审核通过后单据进入买家确认状态,等待买家进行确认。
此功能为基础的风险审核环节,可对单据进行初步风险审核。
3.1.1.5单据申请融资
运营人员在此页面对买家以确认的单据进行向资金源(银行)提交申请融资操作,提交后的单据将转到买卖家合同关联的资金源(银行)端页面供银行人员进行查看和下载,进行后续的银行人工放款操作。
3.1.2卖家端功能需求
卖家端主要服务于系统的卖家客户,如IT分销供应商等
3.1.2.1 单据提交
卖家登录买家端系统后可由此页面进行单据提交操作,支持单笔提交和excel批量提交单据。
3.1.2.2 单据查询
卖家可由此页面进行单据信息和当前状态查询,可查看未审核,未确认,融资申请中和已放款等状态。
3.1.2.3 单据撤销
卖家可对未被买家确认过的单据进行撤销操作,撤销的单据可重新通过3.1.2.1功能提交到系统。
3.1.3 买方端功能需求
买家端主要服务于系统的买家客户,如代理商,分销商等
3.1.3.1 单据确认/拒绝
1:买家登录买家端后可通过此页面查看以通过审核,未被确认的单据信息。
2:买家可对未确认单据进行确认和拒绝操作,确认后的单据状态将变为融资申请中,由后台运营人员提交至资金源(银行)进行融资申请。
3.1.3.2 单据查询
买家可由此页面进行单据信息和当前状态查询,可查看未确认,融资申请中和已放款等状态。
3.1.4银行端功能需求
银行端主要服务于银行操作人员进行单据查询下载,以便后续进行融资放款操作。
3.1.
4.1待融资单据查询
不同银行人员可在此页面查询已被确认和由运营人员提交到本银行申请融资的单据,进行后续的融资放款操作
3.1.
4.2单据查询
银行人员可由此页面对以提交到本银行的单据信息和当前状态,可查看待融资中和已放款等状态的单据
3.1.
4.3单据下载
不同银行人员可在此页面下载已被确认和由运营人员提交到本银行申请融资的单据,进行后续的融资放款操作
3.2 性能需求
(1)查询页面一般响应时间不能过长,影响用户的使用。
(2)要保持数据库中的信息是最新的。
3.2.1硬件接口
服务器端使用专用IBM服务器,以保证系统的稳定和数据安全。
3.2.2软件接口
暂无。
3.2.3通信接口
暂无。
3.3 属性
3.3.1可用性
(1)方便操作,操作流程合理
尽量从用户角度出发,以方便使用本产品。
(2)支持没有计算机使用经验、计算机使用经验较少及有较多计算机使用经验的用户均能方便地使用本系统。
(3)容错能力
系统具有一定的容错和抗干扰能力,在非硬件故障或非通讯故障时,系统能够保证正常运行,并有足够的提示信息帮助用户有效正确地完成任务。
(4)用户可自定义
为了满足业务的不断变化,一些重要的参数应该可以灵活设置。
(5)联机帮助与操作指南。
3.3.2安全性
(1)权限控制
根据不同用户角色,设置相应菜单权限,用户的重要操作都做相应的日志记录以备查看,没有权限的用户禁止使用相关系统功能。
系统管理员可以维护系统。
(2)记录日志
本系统应该能够记录系统运行时所发生的所有错误,包括本机错误和网络错误。
这些错误记录便于查找错误的原因。
日志同时记录用户的关键性操作信息。
3.3.3可维护性
3.3.4可转移/转换性
3.4 其他需求
3.5.1 数据库
4运行环境需求
4.1 设备
该系统为B/S三层结构,它的运行环境分客户端、应用服务器端和数据库服务器端三部分。
以下是系统的软件环境。
(1)客户端
操作系统:Windows XP/VISTA/win7或更新版本。
浏览器:IE6以上,其它常见浏览器。
(2)应用服务器端
操作系统:linux。
应用服务器:Tomcat 6或更新版本。
数据库访问:JDBC。
(3)数据库服务器端
操作系统:linux。
数据库系统:Oracle 11g。
4.2 支持软件
对具体开发环境和语言不做要求。
5附录。