企业要做一套靠谱的人事及OA系统，入转调离（入职 / 转正 / 调动 / 离职 + 基础数据）是核心模块之一。它承载员工从进入公司到离开公司的全生命周期管理，不只是填写表单那么简单：涉及审批流、合同管理、附件收集、岗位变更、社保/薪资联动、交接与审计、以及人力报表的期初/期末统计。做好它，HR能省大量事务性时间，企业数据可用性和合规性都增强。
下面我把整套方案用“接地气、有干货、能直接落地”的方式写出来：先总览、再拆模块（功能、业务流程、实现技巧、关键代码片段、效果验证），最后给常见 FAQ。
快速看点
- 为什么要讲入转调离？
- 什么是人事及OA系统中的入转调离模块？范围与边界
- 总体架构（含架构图 mermaid）
- 核心设计原则与开发策略
- 详解五大子模块（每个子模块都有功能、业务流程、DB 设计、API 与代码参考、开发技巧、实现效果） 入职管理 转正管理 调动管理 离职管理 基础设置（辅助表、期初/期末统计）
- 审批流、权限、审计与通知设计（重要！）
- 常见集成点：合同/电子签名、社保/薪资、考勤/门禁、BI 报表
- 测试、上线与运维建议
- FAQ
一、为什么要讲入转调离？
- 多表单、多审批、信息分散：纸质或 Excel 管理导致丢件、信息不一致。
- 合规与审计难：合同签署、附件留存、离职手续往往缺乏可追溯记录。
- 跨系统联动难：入职需要开工号、发邮箱、建薪资档、连考勤与社保。
- 报表与人员口径不统一：期初/期末口径、试用/正式状态变化缺失，影响人员成本核算。
目标：把“人”“事”“证”“合同”“流程”五类数据打通，并以流程化、可审计、可通知、可统计的方式管理。
二、什么是人事及OA系统中的入转调离模块？
入转调离模块负责员工生命周期的关键人事异动：
- 入职（申请 → 审核 → 档案建档 → 合同签署 → 社保/薪资联动）
- 转正（试用期满评估 → 审核 → 正式员工状态变更）
- 调动（岗位/部门/成本中心/地区变动 → 审批 → 工资、权限、考勤规则联动）
- 离职（申请 → 交接 → 审批 → 结算 → 合同归档）
- 基础数据支持（年月、岗位、成本中心、社保节点、期初期末人员数据等）
三、总体架构（Mermaid 简易架构图）
下面是一个简化的架构示意（可复制到 mermaid.live 或支持 mermaid 的工具查看）：
mermaid
graph LR
A[前端 Web/移动端] -->|REST / GraphQL| B[API 网关]
B --> C[人事服务(微服务)]
B --> D[审批服务]
B --> E[文件/附件服务]
C --> F[(主数据库：Postgres)]
E --> G[(对象存储：S3)]
D --> H[(工作流/消息队列：RabbitMQ)]
C --> I[第三方集成]
I --> J[电子签/社保/薪资/考勤]
C --> K[BI/报表服务]
说明：把“人事服务”做成一套核心微服务（或单体模块化也可），审批工作流使用独立服务以便复用；附件放对象存储，用数据库保存元数据。
四、核心设计原则与开发策略
- 单一事实来源（SSoT）：员工基本信息在一个表，异动记录以事件/事务形式记录。
- 不可变审计链：所有审批与状态变更写入审计表（who/when/what）。
- 异步联动：与薪资/考勤/邮箱等系统采用事件或队列，避免同步阻塞。
- 角色+审批模版：审批链用模板驱动（可配置多级审批），支持回退、加签。
- 附件可检索：身份证、合同等附件支持 OCR/元数据，便于快速查找。
- 数据口径明确：期初/期末人员统计规则文档化（例如：期初为当期第一天 00:00 在职）。
五、详解五大子模块
1.入职管理（新员工入职流程）
功能清单
- 发起入职申请（HR/用人部门）
- 审批流（部门负责人 → HR → 人事专员）
- 员工档案建档（个人信息、紧急联系人）
- 附件上传（身份证、学历证书、体检报告）
- 合同管理（模板生成、电子签）
- 启动下游联动（开工号、邮箱、考勤卡、薪资档）
业务流程（Mermaid）
mermaid
flowchart TD
A[创建入职申请] --> B{是否需要审批}
B -- 是 --> C[发起审批]
C --> D{审批通过?}
D -- 否 --> E[结束：驳回]
D -- 是 --> F[创建员工档案]
F --> G[合同生成并签署]
G --> H[触发下游（邮箱/薪资/考勤）]
H --> I[入职完成]
数据库设计（关键表）
sql
-- 员工主表
CREATE TABLE employees (
id UUID PRIMARY KEY,
employee_no VARCHAR,
name VARCHAR,
id_card VARCHAR,
status VARCHAR, -- probation/active/resigned
department_id UUID,
position_id UUID,
join_date DATE,
created_at TIMESTAMP,
updated_at TIMESTAMP
);
-- 入职申请表
CREATE TABLE onboard_requests (
id UUID PRIMARY KEY,
applicant_id UUID,
department_id UUID,
position_id UUID,
planned_join_date DATE,
status VARCHAR, -- pending/approved/rejected
approval_flow_id UUID,
created_at TIMESTAMP
);
-- 附件表 (文件元数据)
CREATE TABLE attachments (
id UUID PRIMARY KEY,
owner_type VARCHAR, -- employee/onboard
owner_id UUID,
file_key VARCHAR,
file_name VARCHAR,
file_type VARCHAR,
uploaded_by UUID,
uploaded_at TIMESTAMP
);
后端 API（示例：Node.js + Express + Sequelize）
js
// routes/onboard.js (示例)
const express = require('express');
const router = express.Router();
const { OnboardRequest, Employee, Attachment } = require('../models');
router.post('/', async (req, res) => {
const t = await sequelize.transaction();
try {
const data = req.body;
const reqRec = await OnboardRequest.create(data, { transaction: t });
// 创建审批任务（调用审批服务）
await createApprovalTask(reqRec.id, 'onboard', data);
await t.commit();
res.json({ ok: true, id: reqRec.id });
} catch (err) {
await t.rollback();
res.status(500).json({ error: err.message });
}
});
module.exports = router;
开发技巧
- 入职附件建议先上传到对象存储（S3/OSS），后端保存文件 key。上传时做病毒扫描与大小限制。
- 合同模板用参数化模板（例如 docx 模板替换）再调用电子签服务。
- 试用期/转正的日期、社保起始日期需提前和用人方确认。
实现效果
- HR 发起入职 -> 5 分钟内完成审批与合同签署（如果电子签联通），自动建档并推送到 IT 与财务系统。
2.转正管理（试用期转正式）
功能清单
- 自动或人工发起转正申请（试用期到期前 N 天触发提醒）
- 试用期评估表（岗位考核、KPI、直属领导意见）
- 转正审批（负责人 → HR → 部门领导）
- 转正后状态变更（status、薪资变动、岗位权限）
流程（Mermaid）
mermaid
flowchart TD
A[到达试用期结束日] --> B{是否自动触发}
B -- 是 --> C[生成转正申请]
B -- 否 --> D[人工发起]
C --> E[填写评估表]
E --> F[发起审批]
F --> G{审批通过?}
G -- 是 --> H[员工状态变为正式]
G -- 否 --> I[延期或离职处理]
关键字段与 API（示例）
- 转正记录表 probation_evaluations 包含评分、评语、附件、建议结果（通过/延期/不通过）。
开发技巧
- 试用期到期提醒用 CRON + 业务过滤（排除已离职或已转正）。
- 转正可能伴随薪资审批，建议把薪资变更做二次审批。
实现效果
- 自动提醒、标准化评估表，减少主管忘记审核与被动操作。
3.调动管理（岗位变动）
功能清单
- 岗位/部门/成本中心/城市调动申请
- 调动审批（原部门负责人 → 新部门负责人 → HR）
- 调动后岗位权限、薪资、成本中心更新
- 调动生效历史留档
流程（Mermaid）
mermaid
flowchart TD
A[提交调动申请] --> B[原部门同意]
B --> C[新部门同意]
C --> D[HR 确认（薪资/社保影响）]
D --> E[执行调动（更新档案、权限）]
DB 设计（关键）
- transfers 表：记录 from_department, to_department, effective_date, approval_status
- 同时保留 employee_history 用于记录岗位变更的历史快照。
开发技巧
- 调动生效日对薪资/应付工资核算有影响，务必在生效日上做幂等处理。
- 权限变更建议通过角色映射表自动下发或回收。
实现效果
- 调动由系统驱动，相关系统（考勤规则、审批链、工资口径）自动同步。
4.离职管理（员工退出）
功能清单
- 离职申请（员工或主管发起）
- 离职审批（部门负责人 → HR → 财务）
- 工作交接（任务/客户/知识库）流程与确认项跟踪
- 离职面谈记录（原因收集、保留反馈）
- 结算与合同归档（社保/公积金停缴、最终工资）
- 离职归档与权限回收
流程（Mermaid）
mermaid
flowchart TD
A[发起离职申请] --> B[部门审批]
B --> C[HR 审核交接清单]
C --> D[财务核算（结算）]
D --> E[交接完成 -> 正式离职]
E --> F[权限回收、档案归档]
DB 设计
- resignation_requests, handover_items, exit_interviews。交接项需要有负责人、状态、完成时间。
关键代码片段（交接项 API）
js
// 更新交接项为完成
app.post('/handover/:id/complete', async (req, res) => {
const { id } = req.params;
const item = await HandoverItem.findByPk(id);
if (!item) return res.status(404).send('not found');
item.status = 'done';
item.done_at = new Date();
await item.save();
// 若所有交接项完成，自动推进离职审批
const pending = await HandoverItem.count({ where: { request_id: item.request_id, status: { [Op.ne]: 'done' } }});
if (pending === 0) {
// 推送事件给离职审批服务
}
res.json({ ok: true });
});
开发技巧
- 离职结算涉及税务和加班/补休核算，财务接口要预先约定好数据字典（例如加班小时、未休年假天数的计价公式）。
- 离职后权限回收要在 IAM 服务中做幂等处理，避免手动遗漏。
实现效果
- 员工申请离职后，系统跟踪交接进度、面谈记录与结算，离职流程全程可审计与可追溯。
5.基础设置（数据支撑）
功能
- 年月维护（如入职月份、调薪周期）
- 岗位、成本中心、部门树、合同模板维护
- 期初/期末人员统计（支撑月度/季度/年度报表）
期初/期末统计思路
- 期初：统计该期第一天 00:00 在职（status != resigned 且 join_date <= period_start）。
- 期末：统计该期最后一天 23:59 在职情况，考虑入职/离职在期内的人员变动。
示例 SQL（期末在职人数）
sql
SELECT COUNT(*) FROM employees e
WHERE e.join_date <= '2025-07-31'
AND (e.leave_date IS NULL OR e.leave_date > '2025-07-31');
开发技巧
- 基础字典尽量做导入/导出功能，便于与 ERP/财务系统对齐。
- 数据字典变更记录审计，避免历史口径与当期口径冲突。
六、审批流、权限、审计与通知设计（重点）
- 审批：采用模板驱动审批，支持并行/串行/条件分支、加签和回退。审批实例保留审批人、时间、意见。
- 权限：RBAC（角色-资源-操作） + 行级权限（基于部门/成本中心）用于控制谁能看到哪些员工数据。
- 审计：所有关键操作写入 audit_logs（user_id、action、before、after、timestamp）。删除操作改为软删除并保留历史。
- 通知：支持邮件/SMS/企业微信/系统消息，多渠道并可配置触发条件。
开发技巧：审批失败/驳回要把表单数据保留，方便修改后再次提交；审批过程中尽量做乐观锁避免并发状态错乱。
七、常见集成点
- 电子签：通过第三方（如国内常见电子签平台）API 完成合同签署并把签署结果回填附件。
- 社保/公积金：调用第三方或人事外包平台的 API 同步参保与停缴。
- 薪资系统：用事件（员工状态变更）触发薪资系统重新计算。
- 考勤/门禁：调动或离职时自动调整考勤规则与门禁权限。
提示：集成外部系统时，一定做好重试策略与幂等处理，并记录请求日志便于排查。
八、测试、上线与运维建议
- 单元测试：模型、审批逻辑、权限判断均要覆盖。
- 集成测试：与假接口（mock）联调电子签、薪资、考勤。
- 灰度上线：逐步在一个部门或小团队内启用，收集流程异常。
- 监控：关键流程（例如审批失败率、文件上传失败率、异步队列积压）建立告警。
- 数据迁移：期初期末人员数据、历史档案需做一次性迁移，迁移后做双写一段时间以核对口径。
九、示例前端片段（React：入职表单精简版）
jsx
// OnboardForm.jsx
import React, { useState } from 'react';
import axios from 'axios';
export default function OnboardForm() {
const [form, setForm] = useState({ name:'', idCard:'', departmentId:'', positionId:'', plannedJoinDate:''});
const handleSubmit = async () => {
const res = await axios.post('/api/onboard', form);
if (res.data.ok) alert('已提交，ID: ' + res.data.id);
};
return (
setForm({...form, name:e.target.value})} />
setForm({...form, idCard:e.target.value})} />
setForm({...form, plannedJoinDate:e.target.value})} />
提交入职申请
);
}
在这里我给大家推荐一个业务人员就能够直接上手的高性价比、零代码平台——简道云人事及OA管理系统，简道云背靠国内BI龙头帆软，在数据处理、数据展示上的能力有绝对优势，数据分析支持高度自定义，任何分析需求都可以快速制作仪表盘，人事及OA管理系统实现了组织人事、考勤、绩效、薪酬、招聘等人事核心模块全面线上化、一体化，业务流程效率提升
十、安全与合规要点（快速提示）
- 个人隐私（身份证、学历）做加密存储或最小化保留，加密字段用 KMS 管理密钥。
- 附件下载需鉴权，带过期签名 URL。
- 合规性：保存合同期限、离职档案保留政策和当地劳动法要求。
十一、常见问题 FAQ
FAQ 1：如何确保入职资料（身份证、学历证）在系统中的安全与合规？
对于身份证、学历等敏感材料，系统设计必须遵守最小化原则：只在必要范围内保存必要字段。文件存储建议使用对象存储（例如 S3/OSS），文件本体加密（服务端加密或使用 KMS）并使用文件 key 在数据库中保存元数据；下载时通过鉴权生成短期有效的签名 URL，避免文件直接暴露在公网。同时，对敏感字段在数据库中进一步做字段级加密（例如身份证号做可逆加密以便必要时查询）、并限制只有特定角色（HR、合规）能查看明文。最后，保留访问日志（谁在何时下载/查看了哪份附件），以备审计。不同国家地区对个人信息保护有法律要求（例如 GDPR、国内个人信息保护法），上线前请与合规/法务确认数据保留期限和跨境传输规则。
FAQ 2：转正/调动涉及薪资变更，如何设计审批以降低出错率？
转正或调动往往伴随薪资调整，建议把薪资变更做成独立审批节点：在转正审批通过后，若涉及薪资调整，系统自动生成“薪资变更审批单”，由财务/薪资专员审核并签批后才生效。实现上把员工状态变更与薪资变更分为两个事务：主事务（员工状态）提交后，触发薪资审批的工作流；薪资审批通过后，再由薪资系统按生效日做工资计算与历史记录。同时，为避免同步问题，采用幂等事件与重试机制（消息队列 + 唯一事件 ID），并在前端显示“转正已通过，等待薪资确认”的明确状态，减少主管误解与重复提交。
FAQ 3：如何处理复杂的跨部门/跨城市调动（例如需审批多个负责人、调动伴随成本中心变更）？
复杂调动要把审批模板做好参数化支持：审批链可由业务规则驱动（例如如果目标部门成本中心不同，则需要财务审批；若跨城市则需要本地 HR 审核）。在设计时，把审批模板分为条件判断、审批节点和并行/串行设置。实现上，审批引擎应该支持基于表达式的条件分支与动态审批人（通过岗位或用户组解析）。此外，调动伴随成本中心变更的，需要在申请阶段明示变更影响（例如预算、薪资承担方），并在审批通过后触发相应的财务分摊变更。测试方面，用多种场景（同城调动、跨城调动、成本中心变更、外派）做回归，确保审批合规且不会漏掉任何下游联动。
结束语（可执行的下一步建议）
- 先做核心表与审批引擎的 PoC：员工表、入职申请、审批实例、附件元数据。
- 把合同电子签、薪资与考勤的接口定义好（API 文档），优先做 mock 联调。
- 选择合适的部署策略（单体快速上线 or 微服务分阶段拆分），并做好数据迁移脚本。
- 先在一个业务部门灰度上线，收集流程异常与体验优化点，再全公司推广。
