上月十五号下午三点，一家有八百多名兼职人员的企业在做批量申报，页面一直转圈。财务连刷了四次，最后有两个批次没提交成功。第二天补报，回执时间和实际发放时间对不上，解释起来很麻烦。
这类事每年征期最后两天都会重演。拥堵不是意外，是集中报送的固定规律。把动作提前两个工作日，比当天反复刷新有用得多。
一、拥堵通常卡在三个位置
卡在登录。验证码刷新不出来，或者登录后会话超时，做到一半被踢出去，已经填好的数据全部丢失。
卡在批量导入。名册文件稍大就传不上去，或者传上去解析报错，改一行重传，又排一次队，来回几轮就把时间耗完了。
卡在回执回读。提交之后看不到受理结果，不知道成功还是失败，只能反复点查询，越查越不敢走。
| 环节 | 典型表现 | 预案 |
|---|---|---|
| 登录 | 验证码不显示、会话超时 | 提前登录并保持页面活跃，避开整点 |
| 批量导入 | 文件上传失败、解析报错 | 单批控制在两百人以内，清掉特殊字符 |
| 回执回读 | 受理状态查不到 | 按批次号逐批查询，记录提交时间 |
三个位置里最容易出问题的是第三个。看不到回执，就无法判断要不要重报，重报又怕重复申报，进退两难。
二、前置到哪一天合适
按两个工作日留余量。征期截止日如果是十五号，批量报送放在十一号之前完成，十二号到十四号专门用来处理回执和异常。
批次要拆小。八百人一次性提交，失败就得整体重来；拆成每批一百到两百人，失败只影响一批，重报的代价小得多。
拆批还有一个好处：能尽早暴露数据问题。第一批解析报错，说明名册格式有问题，后面几批可以先改再传，不用全部返工。
三、提交失败之后按什么顺序处理
先查受理状态，再决定要不要重报。系统里有查询入口，按批次号或按人员查，确认没有受理记录的才重报。
重报前把批次号改一下。同批次号重复提交，有时会被判为重复数据；换一个后缀，能区分是重报还是新增，日后核对也清楚。
一直提交不上的，先降低单批人数，再看是不是文件里的特殊字符导致解析失败。名册里混入空格、全角字符、重复身份证号，是最常见的解析报错原因。
确实赶不上截止日的，留存提交失败的截图与时间记录，在申报说明里写清楚过程，比事后口头解释有用得多。
四、现在做什么
判断：征期拥堵无法消除，只能错峰。能不能按时报完，取决于报送动作放在哪一天，而不是当天手速多快。
判断的另一面是成本。提前两个工作日，意味着名册要在八号之前定稿，业务部门的数据回收也要跟着提前，不只是一个部门的事。
能落地的动作有三个：把全年征期日历标出来贴在财务工位；名册按每批两百人预先拆好；回执查询入口和批次号记在同一张表上。
申报口径与结算数据的对应关系，可参考平台服务指南；批量发放名册的字段规范见灵活用工服务，常见报错情形的处置见常见问题。
今天先做一件小事：打开上一期的报送记录，数一数当时拆成了几批。少于四批的，下一期就按四批以上来拆。
