先确认是不是工资计算本身的问题
NC工资计算慢 ≠ 系统整体卡顿。需首先剥离外围干扰：关闭非必要插件、禁用自定义报表预加载、暂停其他业务模块（如固定资产折旧、成本结转）并行任务。在【人力资源】→【薪资管理】→【工资计算】界面点击「开始计算」后，观察状态栏是否持续显示「正在处理中」超过5分钟，且服务器CPU/内存无突增，则问题大概率聚焦于工资计算引擎或数据结构。
最短路径：3步定位瓶颈源头
无需深入数据库或日志，从操作层快速收敛问题范围：
- 切换至测试账套，仅导入当期10人基础档案+考勤数据，执行计算——若仍超2分钟，判定为环境或配置问题；
- 在正式账套中，取消勾选「生成凭证」「同步个税申报表」等扩展动作，仅执行纯计算——若耗时下降超60%，说明扩展逻辑拖累主流程；
- 进入【系统管理】→【性能监控】→「SQL执行耗时TOP10」，筛选关键词
psn_salary或hr_salary_calculate，查看平均执行时间是否＞800ms。
数据库层面：索引缺失与统计信息陈旧
NC工资计算重度依赖hr_psndoc（人员档案）、hr_attendancedata（考勤明细）、hr_salaryitemdata（薪资项目值）三张核心表。当员工数＞5000且未建复合索引时，单次计算可能触发全表扫描。常见缺失索引包括：hr_attendancedata(psncode, attenddate)、hr_salaryitemdata(psncode, itemid, calmonth)。统计信息未更新会导致执行计划误判，尤其在月度初大量新增考勤记录后。
计算规则复杂度：公式嵌套与跨期间引用
以下规则设计将显著拉长计算链路：
- 薪资项目公式中含3层以上IF嵌套（如：IF(工龄＞10, IF(职级=‘总监’, 5000, 3000), …)）；
- 使用
GETPREVPERIODVALUE()函数回溯调取上期个税累计额，且上期数据未做分区归档； - 社保/公积金基数自动取值逻辑绑定至【组织机构】→【部门档案】的动态字段，而该字段在计算时需实时JOIN多张中间表。
实施配置风险点：并发与缓存设置失当
NC6.5及以上版本支持工资计算并发线程控制，但默认值常为1。若服务器为16核CPU，却未在webapps/nccloud/WEB-INF/classes/config.properties中配置salary.calc.thread.count=8，则无法利用硬件资源。同时，工资计算结果缓存（salary.cache.enable=true）若被误设为false，会导致每次计算均重新读取原始数据，丧失复用性。
数据质量陷阱：异常档案与脏数据累积
以下数据问题不触发报错但严重拖慢计算：
- 人员档案中
psncode存在重复编码（系统未校验唯一性，但计算时强制去重）； - 考勤明细表中同一
psncode在同一天存在10+条记录（如打卡机误传、接口重复推送）； - 薪资项目值表中存在大量
NULL值字段未设默认值，导致公式引擎逐字段判空。
长期方案：评估业财一体化替代路径
当企业满足以下任一条件时，应启动替代方案评估：① 工资计算频次提升至周薪/日薪制；② 需与销售提成、项目奖金、股权激励等多源薪酬自动联动；③ 财务要求工资凭证实时生成并反写总账，且拒绝手工补录。此时，NC的定制化开发成本与维护复杂度已显著高于迁移收益。
推荐按业务重心选择：
— 若当前痛点集中于财务端凭证时效性、个税申报自动化、报表口径统一，可优先评估「用友畅捷通好会计」，其内置薪酬模块支持个税自动计算、银行代发直连、凭证一键生成，500人规模平均计算耗时＜90秒；
— 若薪酬强耦合业务绩效（如销售回款提成、采购降本奖励），需打通进销存数据流，则「用友畅捷通好业财」更适配，支持业务单据驱动薪酬计算，避免人工导出再导入。