简介《小额贷款公司信贷管理系统操作手册》是一份面向小额贷款公司业务人员、信贷审批人员及系统管理员的完整操作指引围绕贷款申请、审批、放款、还款监控等业务环节帮助用户快速上手并规范日常信贷管理。资源包为单个docx格式文档大小约10.07MB文档篇幅约125页目录包含系统概要、运行环境要求、页面概述、系统登录和操作手册等章节。操作手册部分重点讲解系统维护中的机构管理、用户管理、利率维护、口令更改以及客户管理、贷款产品管理、风险管理、还款计划管理、报表分析等功能模块的操作步骤内容具体、步骤清晰既可作新员工培训材料也能作为日常操作备查手册。该手册目前已有84人浏览/学习对于准备落地或正在使用小额贷款信贷管理系统的团队具有一定参考价值。1. 小额贷款信贷管理系统的真实骨架与适用边界一家区域性小贷公司从 Excel 台账切换到专业信贷系统最痛苦的往往不是操作而是发现在旧表里随手记的一个“备注”到了系统里必须拆成五个字段、三条流程和一个审批节点。《小额贷款公司信贷管理系统操作手册》这份 125 页的 docx 文档本质上是一张完整的模块地图系统维护管权限与参数客户管理管数据底盘信贷业务管全生命周期风险管理和财务管理管闭环。适合两类人读一类是正在选型或实施小贷系统的开发、项目经理另一类是把这套系统用起来的业务骨干。读完能回答三个问题——数据从哪进、审批往哪走、钱怎么对账。2. 系统初始化机构、用户、利率构成的第一层约束信贷管理系统上线第一步不是录客户而是把“谁能操作、操作什么、以什么利率操作”定下来。绝大多数业务乱象比如两个网点抢同一笔业务、客户经理离职后客户无人跟进、利率调整后新旧借据对不上账根源都在初始化阶段没有把数据边界和权限边界划清楚。这一章按手册里“系统维护”的顺序拆开讲。2.1 机构管理与权限模型树形组织背后的数据边界小贷公司的组织架构通常不超过三层总部管政策和资金区域或分公司管审批与督导门店/营业部管获客和贷后。系统里的机构表就是一棵典型的树靠 parent_id 自关联实现核心字段如下。CREATE TABLE sys_org ( org_id INT PRIMARY KEY AUTO_INCREMENT, parent_id INT NOT NULL DEFAULT 0 COMMENT 上级机构ID0表示根机构, org_name VARCHAR(64) NOT NULL COMMENT 机构名称, org_level TINYINT NOT NULL COMMENT 层级1总部 2区域 3门店, status TINYINT NOT NULL DEFAULT 1 COMMENT 1启用 0停用, created_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_parent(parent_id) ) ENGINEInnoDB COMMENT机构信息表;字段本身不复杂真正影响权限的是 org_level 和 parent_id 的组合。总部用户能看到全部机构数据门店用户只能看到自己 org_id 及其子级的数据。常见做法是在用户表里冗余一个 data_scope 字段取值为 1仅本人、2本机构、3本机构及下级、4全部查询时通过 SQL 动态拼机构条件而不是在业务代码里逐条做数据过滤。这样做的代价是用户改机构时需要同步刷新数据权限所以手册里专门有“客户权限转移”这个功能——用户调岗或离职时把他名下的客户批量移交给另一个用户移交动作本身要记录操作人、时间、客户清单方便审计追溯。2.1.1 用户权限转移的校验逻辑权限转移不是简单的 UPDATE 语句它有几个隐蔽约束。目标用户必须处于启用状态客户必须确实归属于原用户如果客户名下有未结清的借据系统应当给出提示而不是静默转移。def validate_transfer(operator_id, source_user_id, target_user_id, customer_ids): # 校验操作人是否有客户权限转移的菜单权限 if not has_permission(operator_id, CUSTOMER_TRANSFER): raise PermissionError(操作人缺少客户权限转移权限) # 校验目标用户状态禁用状态不能接收客户 target get_user(target_user_id) if target[status] ! ACTIVE: raise BusinessException(目标用户已停用无法接收客户) # 校验客户归属防止把别人名下的客户转移走 active_count db.query( SELECT COUNT(*) FROM customer_owner WHERE user_id%s AND customer_id IN (%s) AND statusACTIVE, source_user_id, ,.join(customer_ids) ) if active_count ! len(customer_ids): raise BusinessException(存在不在原用户名下或已失效的客户请刷新列表)这段逻辑的核心是“先校验后变更”而不是直接执行 UPDATE。转移完成后建议同步写一条 owner_change_log记录客户ID、原用户、新用户、操作人、操作时间后续出现业务纠纷时这张表比主数据表更有说服力。实际项目中容易漏掉的是客户权限转移之后该客户关联的待办任务比如贷后检查任务也要跟着转移否则新归属人看不到待办任务就卡死在原用户的账户里。2.2 利率维护按贷款产品维度管理参数利率表不能做成简单的键值对因为小贷公司的利率往往跟产品绑定而产品又跟还款方式绑定。手册里划分了“无还款计划表”和“有还款计划表”两种利率调整场景这是两张完全不同处理逻辑的流程。调整场景触发条件处理逻辑典型例子无还款计划表贷款已审批但未放款、未生成计划表直接修改借据利率后续按新利率生成计划客户要求降息后重新测算月供有还款计划表贷款已放款且计划表已生成修改利率后需重新生成剩余期数的还款计划保留利率变更记录央行基准利率调整后批量变更存量贷款有计划表的利率调整最容易被忽略的是“剩余期数重新计算”和“已还期数不动”。已还部分的利息已经入账不能反算只有未还本金和未还期数按新利率重算。实现上建议把每次利率变更都插一条 loan_rate_change_log记录借据号、调整前利率、调整后利率、生效日期、操作员这样财务在对账时能看到每一笔利息差额的来源而不是对着还款计划表猜。提示利率表建议独立成 sys_rate 表字段至少包含 rate_id、product_id、rate_value、effective_date、expire_date。生效日期和失效日期必须显式维护查询时用WHERE effective_date CURDATE() AND (expire_date IS NULL OR expire_date CURDATE())取当前有效利率避免利率调整时历史数据被覆盖。3. 客户管理与数据治理贷前数据的底盘工程客户模块是整个系统的数据源头它的质量直接决定贷后管理和风险分类能不能跑起来。手册里把客户拆成企业客户和个人客户两条线各自维护的信息维度完全不同。企业客户重经营数据个人客户重收入负债和稳定性这种拆分不是 UI 层面的排列组合而是背后两套不同的数据表结构。3.1 企业客户与个人客户的标签化信息结构企业客户按证件管理、基本信息、业务基本情况、财务报表、企业关联展开。财务报表明细账、资产负债表是贷前评审的核心依据录入时需要做简单的勾稽校验。个人客户的信息维度更碎手册列了 12 类基本信息、主要资产、主要负债、工作经历、教育经历、配偶信息、居住情况、社保、保险、关联关系、机构借款、业务基本情况。这 12 类信息建议分表存储而不是塞进一张大宽表。CREATE TABLE cust_personal_finance ( id INT PRIMARY KEY AUTO_INCREMENT, customer_id INT NOT NULL COMMENT 客户ID, asset_type VARCHAR(32) COMMENT 资产类型房产/车辆/存款/理财, asset_desc VARCHAR(128) COMMENT 资产描述, est_value DECIMAL(14,2) COMMENT 预估价值, debt_type VARCHAR(32) COMMENT 负债类型个人借款/银行贷款/担保, debt_amount DECIMAL(14,2) COMMENT 负债金额, month_income DECIMAL(12,2) COMMENT 月收入, created_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_customer(customer_id) ) ENGINEInnoDB COMMENT个人客户资产负债信息表;分表带来的直接好处是前端录入哪个标签页就只更新对应表不产生大表的锁竞争查询时按客户ID联表取数。注意负债信息的录入要留修改痕迹信贷员故意少填一笔负债可能导致审批结论完全反转。实务中我一般会在负债表上加一个 source_type 字段区分“客户自报”和“征信核实”审批时对自报数据打折看。3.2 客户合并与客户托管移交数据所有权变更的规范化路径客户合并是客户管理里风险最高的操作出现场景通常是同一客户被不同信贷员录了两次。合并前必须检查两件事合并方是否有未结清借据以及双方是否存在同一产品下的重复申请。如果合并方名下有未结清贷款直接合并会把借据关联到错误的客户ID上导致贷后还款记录断链。def merge_customer(primary_id, merged_id, operator_id): # 检查合并方是否存在未结清借据 active_loans db.query( SELECT COUNT(*) FROM loan_receipt WHERE customer_id%s AND status IN (UNPAID,OVERDUE), merged_id ) if active_loans: raise BusinessException(合并方存在未结清借据禁止合并) # 同一事务内迁移联系人、审批记录、影像资料到主客户 with db.transaction(): db.execute(UPDATE cust_contact SET customer_id%s WHERE customer_id%s, primary_id, merged_id) db.execute(UPDATE cust_approval SET customer_id%s WHERE customer_id%s, primary_id, merged_id) db.execute(INSERT INTO cust_merge_log(customer_id, merged_id, operator_id, merge_time) VALUES(%s,%s,%s,NOW()), primary_id, merged_id, operator_id)合并逻辑里最容易出问题的是历史审批记录。如果直接 UPDATE 到主客户ID那么审批流里的历史留痕和原客户名会不一致事后审计时说不清。常见做法是保留一张独立的历史快照表把合并前双方的资料字段另存一份业务库里只更新外键。还有一点容易忽略合并后的客户要重新做一次征信查询因为合并前的征信报告是分别查询的合并后征信报告需要刷新关联。客户托管移交区别于权限转移它不改变用户与客户的所有权关系只是把客户名下的某些业务比如贷后检查、催收任务临时移交给他人处理。权限转移改的是 owner托管移交改的是 handler。这两个字段如果混用权限模型会出现严重漏洞一个离职员工的客户被“托管”给了新员工但新员工并没有这个客户的查看权限只能看到任务却打不开详情。4. 信贷业务全流程申请、审批、放款、还款与财务闭环信贷业务是系统的核心链路从申请一路走到财务记账每一步都在改变资金的状态。手册的编排顺序是申请、审批、修改、状态查询、贷款总账、预警监控、利率调整再到贷款归还和财务管理这其实是一条完整的资金流水线。4.1 业务申请到审批状态机节点流转的约束条件审批状态机一般包含草稿 → 申请提交 → 初审 → 终审 → 放款 → 结清以及两个反向分支退回修改、拒绝。每个节点的允许动作和前置条件如下表。节点操作角色允许动作前置条件草稿客户经理提交申请必填字段完整、影像材料齐全初审风控岗通过/退回/拒绝证件已核验、征信已查询终审审批岗批准/退回初审通过、额度未超权限放款财务岗确认放款终审批准、还款计划已生成正常还款系统自动扣款/手工还款借据状态为正常审批流实现上最忌把状态存成一个孤立字段然后到处 if 判断。建议用独立的 process_instance 表和 process_task 表记录流转历史每个节点生成一条待办任务审批通过后生成下一个节点的任务。退回修改时要记录“退回原因”客户经理修改后重新提交审批历史完整可查。4.2 还款计划表生成与罚息计算等额本息与逾期计息的落库逻辑还款计划表是信贷系统的核心数据产品它决定了每个月客户还多少钱、利息怎么摊。等额本息和等额本金是最主流的两种方式小贷公司多用等额本息因为月供固定催收和财务对账都方便。def calc_repayment_schedule(principal, annual_rate, months): monthly_rate annual_rate / 12 p a hrefhttps://download.csdn.net/download/weixin_45365017/74825668 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p