先看三个现场现象
在多数中小企业里，下面三个场景几乎每个月都要重演一遍：
- 算薪靠 Excel 拼。 月底 HR 桌上开着七八张表：考勤表、绩效表、社保台账、补贴名单、上月工资表，来回对照查找。谁新入职、谁调了薪、谁上个月请了三天假，全靠人记。
- 口径说不清。 员工来问"这个月为什么少了两百块"，HR 得翻半天，因为计算过程没有被记下来，只剩一个结果数字，解释不清就只能"我再核一下"。
- 数据重复录三遍。 算完薪，还要手工做一份部门汇总表、一份银行代发表、一份申报表，同一批数据录三次，每录一次都有出错的机会。
这三个现象背后其实是同一件事：薪资被当成"月底做一次的表"，而不是"一套持续维护的数据 + 一个可复算的过程"。前者只能靠人扛，人一换就断；后者才能在系统里跑起来。要落地的也就两块——把人和口径做成基础数据，把每月的核算做成有批次的流程。
第一步：把人、口径、考勤建成基础数据
薪资模块的底子是三组基础数据（在 Inkwell 构建器里，就是几个可维护的数据表）：
员工与任职。 姓名、工号、部门、岗位、入职日期、用工性质、成本归属部门。这些大多已经沉淀在员工档案里，不要重复建，直接引用过来即可——同一份人事数据在多处复用，是这套东西能不能长期维护的关键。
薪级与薪资项。 每个员工的固定部分（基本工资、岗位津贴）、浮动部分（绩效基数）、扣除项（社保、公积金、个税、宿舍水电等）。做法上建议不要"一人一套字段"，而是把薪资项做成一张字典表（如"全勤奖""夜班补贴""高温补贴"），员工档案里挂的是"这个人有哪些薪资项、对应多少钱"。以后新增一个补贴项，改的是字典和一张对照表，不用动表结构。
期间与考勤口径。 计薪周期（自然月，还是上月 21 日到本月 20 日）、应出勤天数、请假与加班的折算方式。这三条一旦定了就别随意改，因为它决定历史工资还能不能复算——口径变了，去年的数就对不上了。
基础数据不必一次建全，先建"固定薪资 + 常用补贴"，随每月核算自然补齐。构建器生成的模块自带导入入口，现成的员工工资 Excel 表可以直接导进来，不用手工敲几百行。## 第二步：把它跑成"一个期间一张核算批次"
薪资最怕两件事：算错了没人发现，改过什么说不清。解法是引入"核算批次"这一层——它是一张主表，代表"某年某月、某个薪资组的这一次核算"。一次完整的核算，按四个动作走：
- 建批次、拉数据。 选定期间与范围（某家公司、某个薪资组），系统按基础数据生成每人一行，带出应出勤、实际出勤、绩效得分、社保基数。这一步先把散在各处的数据汇到同一张表上。
- 算与调。 系统按你维护好的口径算出应发、应扣与实发；差异部分（补发、扣款、一次性奖励）由 HR 单独录入，并且必须填原因。每一笔人工调整都留痕——谁改的、改了多少、为什么改，全部记在明细里，这张明细本身就是解释。
- 复核与审批。 核算表提交后走审批：部门确认 → 财务复核 → 负责人批准。有人工调整、或金额波动较大的批次，可以要求附说明；审批不通过就退回修改，批次保留修改记录，不用靠邮件来回传版本。
- 锁定与发放依据。 审批通过后锁定批次，禁止再改，之后导出银行代发表、申报表和部门成本汇总表。锁定这一步很关键——它保证"发出去的钱"和"系统里的记录"永远对得上。
明细里的每个员工行，都要能点开看到"这个数是怎么来的"。这是薪资系统最值钱的地方：不是算得更快，而是算完之后能被解释。
中间难免遇到的例外情况，都挂一道审批即可：跨期补发、离职末期结算、一次性奖金、个税更正。审批结果直接回写单据状态，不用领导签完字再回系统补录一遍。## 第三步：页面怎么摆，不同的人各看什么
同一个数据库，页面摆法决定了系统会不会真的被用起来。建议按"角色 + 动作"而不是按表来安排：
- HR 作业页：左边是本月核算待办（拉数据、复核差异、提交审批），右边是员工明细，有手工调整的行高亮显示。HR 上班先看这个页面，而不是先翻菜单。
- 员工工资条页：员工只看到本人历史工资条，按薪资项逐条展开，能和上月对比。
- 部门成本页：部门负责人看本部门人力成本汇总与环比，看不到别人的明细——这件事由角色权限控制，不是在页面上做手脚。
- 口径与字典页：薪资项、社保口径、计薪周期集中维护，谁改过、什么时候改的，都能查到。
字段层面有几个细节要一开始就定好：工号的唯一性；员工与登录账号的对应关系（它决定了员工能看到谁的工资条）；以及"作废"和"红冲"怎么处理。核算批次一旦生成，就要走锁定与重算流程，而不是直接删掉重来。
第四步：移动端接手，把确认动作交回员工
用 Inkwell 构建器做的模块，PC 上搭好的页面会成套出现在手机端，不需要另外开发一套移动应用。落到薪资场景，手机上最该有的是这几个动作：
- 查工资条：员工自己看每月明细，不用再找 HR 要截图。
- 确认与申诉：看到异常（缺勤天数不对、补贴没发）直接提一笔申诉，附截图，自动进 HR 的待办。
- 审批人在手机上看汇总并批：一屏里看到应发合计、人工调整笔数与原因，批或不批都有依据。
一个建议：移动端只放"当场要做的动作"，口径配置、公式维护这类留在 PC。手机上入口太多，反而没人愿意用。## 上线前要确认的五件事
- 薪资口径写成一页纸。 计薪周期、应出勤天数、请假扣法、加班折算、社保公积金基数与比例、个税口径。这页纸既是系统的说明书，也是以后换人时的交接凭证。
- 历史数据从哪一天起算。 建议从某个自然月首日开始，把员工当月的固定薪资项导进来；没有历史明细就先录当月。期初口径一次定死，日后改口径等于账目重来。
- 权限分层。 谁只能看本人、谁看本部门汇总、谁能看全公司明细、谁能改口径。这件事由角色统一管理，不必挨个模块单独配。
- 代发表与申报表的格式。 事先把模板固化进系统，每月导出即用，避免临发薪那天还在调列顺序。
- 两套数据并行多久。 建议先并行一到两个完整计薪周期，把系统结果和 Excel 结果逐人比对，差异能对齐了再停用旧表。
上线后的第一个月，HR 大概率会提一堆"这一项怎么不放这里"的意见，改起来都很快；比事后集中反馈一轮有效得多。
之后可以延伸的方向
薪资跑顺之后，这套数据会成为好几件事的基础：
- 申报台账：按期间汇总社保与个税申报数据，与工资记录同源，不用两处对账。
- 人力成本分析：按部门、项目、岗位看成本结构与环比，做编制和预算时有据可依。
- 与考勤、绩效联动：考勤异常和绩效结果不再手工抄写，直接带进核算批次。
- 离职结算：离职流程走完即生成末期结算单，避免"人走了工资还没结清"。
- 到期与滞留提醒：核算周期临近、审批滞留超时，用系统里的定时任务和消息提醒推给相关人，不必靠人盯。
这套东西是怎么搭出来的
上面说的这些——员工与薪级基础数据、薪资项字典、计薪与考勤口径、核算批次与审批、工资条查询与申诉、发放与成本汇总报表、定时提醒——都是在 Inkwell AI 构建器里用业务语言描述出来的模块：先把要做的业务讲清楚，构建器搭出数据表和页面，再按自家口径逐项调整字段与规则，PC 与移动端一次成型。
改动不需要写代码。多一个补贴项、审批多一级、工资条想加一列上月对比，直接在页面和规则上调整，当天就能用上。
最后提醒一句：薪资系统真正的价值不在"算得快"，而在"每一个数字都能说清楚是怎么来的"。先把口径和数据基础打牢，再谈自动化与分析，才不会在第一次争议上把自己逼回 Excel。