简介工资管理系统数据流程图.doc 是一份面向财务人员、HR 及信息系统初学者的流程文档聚焦企业工资核算过程中考勤、工资计算、福利费计提、个人所得税申报等核心业务的数据流转。文档定义了考勤日期、职工编码、基本工资等关键数据项附有字段类型与取值范围说明便于数据库设计时直接参考同时梳理了变动工资表、基本工资表、工资计算表、福利费分配表、个税申报表等主要存储结构并列明各数据流的来源、去向与处理频率。通过阅读可完整理解“输入考勤→编制变动/基本工资→计算工资→银行代发→计提福利费→个税申报→自动转账”的全套处理逻辑为课程设计、系统开发或流程梳理提供直接参考。资源包内含 1 个 doc 文件容量仅 95KB便于快速下载与查阅已有 2600 余人学习使用适合需要掌握工资管理系统数据流程细节的读者。1. 工资管理系统数据流程图先回答「钱怎么进、表怎么出」工资管理系统数据流程图这个东西看着就是几张圈和箭头实际是工资系统需求分析里最硬核的交付物。一个 .doc 后缀的需求文档里面真正值钱的往往就是那几张数据流程图——它回答的不是「工资系统怎么开发」而是三件事工资数据从哪里来中间经过哪些加工最后以什么形式送到谁手里。我为什么说它能卡项目因为工资系统最怕的不是代码写不出来而是口径对不上。人事说「我出考勤」财务说「我要的是工资表」银行说「我只要代发文件」。数据流程图就是把三方拉到同一张纸上让每个人都指着一条数据流说「这里我说的就是这个数据」。做课程设计的同学、被分配去补文档的开发和实施顾问先把这个图搞定后面所有事都好商量。2. 数据流程图的四个零件先定边界再画工资系统的箭头2.1 外部实体和加工系统内外不分箭头就会乱在工资管理系统里数据流程图只有四种元素外部实体、加工、数据流、数据存储。很多人拿到 Visio 就拖箭头开始画这是最容易翻车的第一步。正确顺序是先把外部实体圈出来再谈内部加工。工资系统的外部实体通常很固定我一般会先列一张清单再动笔。这五个角色基本覆盖了绝大多数项目员工、HR 专员、财务、银行、税务系统。这里有个容易被忽略的细节外部实体代表的是独立角色不是岗位名称。财务和 HR 虽然都是公司内部岗位但在工资系统里他们扮演的是不同角色数据权限和操作范围完全不一样必须拆成两个外部实体。外部实体职责定位主要输入主要输出员工提供个人基础信息与考勤数据工资条、发放通知基础信息、考勤记录HR 专员维护员工档案、薪资项配置入转调离单据、薪资方案已校验的员工档案、薪资项配置财务审核工资总额、处理异常工资汇总表、异常清单审核结果、补发通知银行接收代发数据返回发放结果银行代发文件发放回执、失败明细税务系统个税计算口径与申报反馈个税申报表扣缴反馈数据外部实体之间不能直接画箭头这是硬规矩。员工把考勤交给 HR、HR 审核后交给财务、财务再把工资发给银行——这种画法在业务上是对的但在数据流程图上就是错的因为数据流必须经过加工。外部实体之间的所有数据交换中间都必须有一个加工或存储介入否则系统边界就塌了。2.2 数据流和数据存储箭头要有名字仓库要有结构数据流是加工的输入和输出也是后面数据字典的检查点。工资系统的典型数据流包括员工基本信息、考勤记录、工资项配置、计税结果、实发工资明细、银行代发文件、工资条、发放回执。每条数据流都要能说清楚它是哪张表、包含哪些字段否则图就只是纸上谈兵。我以前见过一张图数据流名称写的是「数据」「处理结果」这种废话业务方看了点头开发拿到手完全不知道怎么建表。这就是数据流没落实到位的典型症状。数据流命名我一般遵循三个原则一是用业务名词不用技术名词比如「实发工资明细」而不是「net_pay_data」二是每条数据流能对应一个明确的表格三是名称不能重复同一个名字只能有一条箭头。数据存储是图里的仓库工资系统至少要出现这几个D1 员工档案、D2 考勤记录、D3 薪资项配置、D4 个税税率表、D5 工资计算表、D6 发放记录。编号在这里定下来后面数据字典直接复用同一套编号。存储和数据流的区别经常把人绕晕数据流是动的存储是静的。一条数据流写进存储这条流的名字就完成了使命后续加工从存储里读数据时用的是另一条新数据流。2.3 为什么不用业务流程图或时序图接替它有人会问我画业务流程图不也一样吗工资这种数据密集的业务业务流程图表达的是「谁在什么时候做什么」数据的载体是丢掉的。财务说工资表必须有基本工资、绩效、扣款三个字段业务流程图上看不到这些数据流图却能把输入输出精确到数据流直接对应数据库表结构。这是数据流程图作为需求文档的地基价值。时序图呢时序图强调的是交互顺序适合回答「先算个税还是先扣社保」这种先后问题但它同样不约束数据结构。画一张工资时序图最多能把「查税率的接口在第几步调用」讲清楚讲不清「税率表长什么样」。所以工资管理系统数据流程图这个 .doc 才会成为需求阶段的头号图纸画清楚流向才有数据字典最后才有表结构这是一条完整的链路。3. 把工资业务拆成数据流顶层图到一层图的落地步骤3.1 顶层图全系统是一个加工先让三方点头顶层图是整个 .doc 里最简单也最难的一张图。说简单是因为它只有一个加工名字就叫「工资管理系统」说难是因为它要确认边界哪些数据从外部进来哪些数据送出去送出去给谁。边界只要错了后面所有图都跟着错。画顶层图的步骤很固定。第一步把外部实体摆在外圈员工和 HR 放在上方财务和税务放在左侧银行放在右侧。第二步中间放一个加工编号记为 0名字就叫「工资管理系统」。第三步所有数据流都只连接外部实体和这个加工外部实体两两之间不能有箭头。第四步用图例标清楚每种图形的含义这一条很多人都会漏。顶层图的数据流清单如下方向数据流名称说明员工 → 系统员工基础信息、考勤记录工资数据的源头HR → 系统档案变更、薪资项配置基础数据维护入口系统 → 财务工资汇总表、异常提醒财务审核依据财务 → 系统审核结果审核通过或驳回系统 → 银行银行代发文件含账号、金额、备注银行 → 系统发放回执、失败明细用于失败重发系统 → 员工工资条每月发放结果注意顶层图里不要出现数据存储。存储代表的内部状态只在分层图里出现顶层图只讲边界。顶层图给业务方看的时候重点问三句话数据是不是只有这些进、只有这些出有没有多画或少画的外部实体银行代发文件这个产出财务和银行认不认。这三句话过了顶层图就算定稿了。3.2 一层图六个加工一套输入输出表把加工 0 拆开就得到一层图。工资系统最常见的切法是切成六个加工这个数量刚好覆盖每类角色的核心职责再多就乱再少就合不拢1 基础数据维护2 考勤与工时处理3 工资计算4 工资审核与汇总5 工资发放与回执处理6 工资条与报表输出每个加工只管自己那一摊事输入输出必须明确。我的习惯是画图之前先把这张加工清单填好图只是清单的图形化表达编号加工名主要输入主要输出1基础数据维护员工档案、薪资项配置已校验的基础数据2考勤与工时处理考勤记录有效工时、计薪天数3工资计算计薪天数、薪资项配置、个税税率应发工资、个税、实发工资4工资审核与汇总实发工资明细工资汇总表、审核结果5工资发放与回执处理审核后的代发明细、发放回执银行代发文件、失败明细6工资条与报表输出实发工资明细工资条、财务凭证报表一层图的编号规则要一开始就定死一层图用 16二层图用 3.1、3.2 这种带小数点的编号。编号不能跳号跳号在评审时会被认为是加工画漏了到时候要花大量时间解释。3.3 二层图拿「工资计算」举例子工资计算是整张图里最核心的加工值得单独画一层。常见做法是把加工 3 拆成五个子加工3.1 读取员工档案与薪资项配置3.2 根据计薪天数和考勤数据计算应发工资3.3 按累计收入和个税税率计算个税3.4 计算实发工资应发减去各项扣款3.5 生成工资计算表数据流的顺序是固定的D2 考勤记录 → 3.2 → 应发工资明细 → 3.3 → 计税明细 → 3.4 → 实发工资明细 → 3.5 → 写入 D5 工资计算表。画一条走一条不要跳。这里有一条很关键的经验存储的读写方向特别容易画错。比如 3.3 是读 D4 个税税率表还是写 D4税率是财务维护的配置数据加工 3.3 只读不写。再比如 3.5 是写 D5 工资计算表不是读。判断标准只有一个这个加工是数据消费者还是生产者。加工读了存储再吐出来存储不一定新增加工算出了新结果才有资格写存储。3.4 用 draw.io 落图的实操顺序在 .doc 里嵌图我一般用 draw.io 画完导出图片再插进文档Visio 也可以操作逻辑完全一样。落图顺序按下面这套来基本不用返工先摆外部实体。图形用矩形放在画布四边不要放在中间。再放加工。加工用圆角矩形编号写在图形的左上角名字写在中间。画数据流。每条连线都要在中间标数据流名称方向由箭头决定名称务必和之前表格里的一致。最后画数据存储。存储用右边开口的矩形编号 D1、D2 这种放在加工下方。图例很多人会忽略但建议一定画。在 .doc 里的图一旦过段时间被别人打开图例就是救命稻草。没有图例的图三个月后连作者本人都要回忆半天更不用说拿去评审了。4. 画工资系统流程图最容易翻车的 5 个地方避坑排查清单4.1 外部实体画进了系统边界里现象一层图里出现「人事专员」这个加工或者把「员工」画成一个存储并命名为 D0外部实体和系统内部元素混在一起。原因分不清什么叫系统外。外部实体是系统外的角色不是数据也不是加工。员工在系统外提供数据经过加工处理后才变成档案数据存进 D1员工本身不能是存储。解决检查方法很简单问一句「这个角色要不要登录工资系统」。要登录的是用户角色不是外部实体。外部实体只出现在图的外圈而且不能直接连存储它们之间的数据交换必须经过加工。4.2 加工编号做成平级现象一层图的加工编号是 1、2、3二层图的子加工编号也是 1、2、3评审时根本分不清这张图到底是几层。原因编号没有继承层级或者画二层图时忘记了父编号重新从 1 开始排。解决严格按 0 → 3 → 3.1 → 3.1.1 这种规则编号。一层图的父加工编号是 1 到 6二层图里对应子加工必须是 3.1、3.2而不是 1、2 开头。这样拿着一张图就能直接说出「这是 3 号加工的内部展开」评审时不用反复解释。4.3 数据流命名和工资表表头对不上现象图里数据流叫「工资明细」到实现阶段开发打开表结构看到的是 pay_detail字段有 base_salary、bonus、deduct对不上号。原因画图阶段没有定义数据流结构数据字典缺失或者字典是画完图之后才补的补的时候又没按图校核。解决画图时给每条数据流起名后在数据字典里同步登记对应的表名和字段。图里用业务名称数据库表用英文表名两者通过数据字典做映射。流程图唯一的成功标准是业务口径和技术字段能互相查得动而不是两张图长得像。4.4 把「判断」画成了加工现象加工里写着「判断应发工资是否超过起征点」然后从加工引出「是」「否」两条出口箭头把数据流程图画成了程序流程图。原因混淆了数据变换和路由决策。数据流程图只表达数据经过什么变换不表达加工内部怎么做判断。判断是加工内部的逻辑不是加工本身。解决把「个税计算」整体作为一个加工起征点判断写进数据字典的加工说明里而不是在图里画出两个分支。如果确实要表达不同处理路径可以在加工说明里用文字描述不要在数据流图上体现。4.5 数据存储画漏或画多现象工资计算下面只有 D4 个税税率表找不到 D5 工资计算表或者把「工资条」也画成存储因为它要存一下才能发。原因存储只用来保存后续加工需要读取的「状态」。工资条是输出物发给员工之后就完成了使命后续没有加工要大规模读取它不需要存储。而工资计算表后续要被审核、汇总、发放三个加工读取必须要有存储。解决用一个笨办法核对。每个加工只要写了数据后面必须有一个存储接住每个存储至少要有一条数据流写入、一条数据流读出。把这两句话对着图过一遍漏和多的位置立刻就暴露出来。5. 数据字典配套让流程图能被开发直接照做的清单5.1 库存一份最小数据字典用 SQL 建模数据流程图如果不同步建数据字典就只是画了个大概。我一般会在项目库里用 SQL 建一张数据字典表让图里的每一条数据流、每一个存储都落成一行记录。最小模型可以这样设计CREATE TABLE data_dict ( dict_id VARCHAR(20) PRIMARY KEY, -- 条目编号DF 开头是数据流D 开头是存储P 开头是加工 dict_type VARCHAR(10) NOT NULL, -- 类型DATA_FLOW / STORE / PROCESS dict_name VARCHAR(100) NOT NULL, -- 业务名称必须与图中一致 source VARCHAR(20), -- 来源外部实体或加工编号 destination VARCHAR(20), -- 去向加工编号或外部实体 field_def TEXT, -- 字段定义可以用换行分隔 remark VARCHAR(200) -- 备注对应实现表名、口径说明 );dict_id 是唯一编号我用 DF 开头表示数据流、D 开头表示存储、P 开头表示加工。source 和 destination 直接引用图里的编号比如 EMP_TO_P3 表示员工到加工 3 的数据流。field_def 放字段清单字段多的时候用换行分隔字段少就直接写在一行里。建完表之后每条数据流都要往里插一条记录。示例INSERT INTO data_dict VALUES ( DF-12, -- 数据流编号 DATA_FLOW, 实发工资明细, -- 业务名称与图一致 P3.4, -- 来源加工 3.4 P4, -- 去向加工 4 emp_no 员工编号; gross_pay 应发工资; tax 个税; net_pay 实发工资; pay_month 发放月份, 实现表 pay_detail金额单位用分 );这段 SQL 只是建字典表不是工资系统的业务表所以字段定义先用文本形式。如果项目已经上了在线设计工具可以把 field_def 改成 JSON 列前端渲染成表格效果更好。5.2 用数据字典反查流程图图画完后数据字典的第二个职责是反查。做法分三步把图中所有箭头名称抄下来去 data_dict 表里查 dict_name凡是查不到的说明图和数据字典不同步把 D 开头的存储编号全部列出来逐个核对至少有一条指向它的「写」数据流和一条「读」数据流。这个动作能查出不少毛病。最典型的是加工 3.5 生成了工资计算表但图里没有画它写入 D5 的箭头开发看到图的时候会漏掉「保存工资结果」这个动作。这种漏项在评审阶段发现是免费的进了开发周期就要花几倍的时间补接口。查遗漏的时候可以跑一条很简单的 SQLSELECT dict_id, dict_name, source, destination FROM data_dict WHERE dict_type DATA_FLOW ORDER BY dict_id;把这条 SQL 的结果和图逐条对一边对一边用笔在图里画勾。画勾过程中只要发现哪条箭头没有对应记录或者哪条记录在图里找不到箭头立即停下核对。这个习惯能挡掉大部分口径问题。5.3 图和字典同步的维护节奏一张图配一份字典最怕的就是改图不改字典。我的经验是数据流名称一旦变了字典记录当天必须同步加工编号变动source 和 destination 字段也要跟着改字段口径有调整要更新 field_def 并在 remark 里写清变动原因和时间。有些团队会把数据字典导出成 Excel 附在 .doc 后面这也是常见做法。但导出前务必要在字典表里跑一遍检查看 source 和 destination 里有没有不存在的编号。这个动作是我被坑了几次之后定下来的血泪经验字典导出去的时候看着整整齐齐实际里面有一半编号已经过期开发照着做准翻车。6. 用「一句话走通法」验证工资系统流程图三场景加自检清单6.1 三个主场景一句话走通三句话走通是我每次画完流程图必做的验证看着有点玄学实际比对着图干想有用得多。拿三个主业务场景各用一句话描述完整流程然后沿着图去走路径走不通的地方就是问题。场景一固定发薪。HR 维护档案 → 考勤进入系统 → 工资计算 → 财务审核 → 银行代发 → 员工收工资条。沿着这张图一步一步走每一步的出口都必须是下一步的入口只要中间断了一条数据流就把缺失的箭头补上。场景二补发工资。财务录入补发明细 → 工资计算重新计税 → 审核 → 并入下次代发文件。走这条路径时要检查 P3 到 P5 之间有没有一条「补发明细」的数据流很多图在这条路径上都是断的。场景三个税调整。税务系统下发新税率 → 系统更新税率配置 → 下次工资计算使用新税率。这条路径直接指向 D4 税率表如果图里税率存储没有数据流进来也没有数据流出去说明存储画成了孤岛。读图顺序也有讲究从外部实体出发最后回到外部实体。数据从员工考勤进入系统最终以工资条和代发文件的形式离开系统中间不管绕多少层加工方向应该是单向推进的不允许出现倒流。6.2 评审自检清单给评审用的自检清单我固定在文档最后一页每次提交前自己先过一遍检查项通过标准外部实体全部在边界外两两之间没有直接箭头加工编号层级连续一层与二层能对上数据流命名每个箭头有业务名称且能在数据字典里查到数据存储每个存储至少有一条写入、一条读出数据字典图里所有编号能反查source 和 destination 合法以前我评审时只看图不看字典结果被财务一句「你这里写的工资明细和我们的工资表不是一回事」问住当场下不来台。那次之后我养成了习惯图画完先走三句话再查一遍字典全都对了才敢提交。数据流程图这东西画起来不难难的是让每一个箭头都经得起追问。希望帮到你。本文还有配套的精品资源点击获取