ERP 数据录入的错误，往往不是“员工不认真”造成的，而是系统允许一张业务上不成立的单据一路走到审批、接口或报表环节。优化字段校验与流程设计，重点不是把必填项越加越多，而是让错误在最便宜、最容易修正的位置暴露，并明确谁能处理、如何留痕、怎样验证规则有效。下面这份清单从字段、流程、异常和复盘四个层面展开，并用采购申请作为示例；文中涉及的数字均为明确标注的情景模拟，不代表行业统计或企业实测结果。
我判断一套 ERP 数据录入流程是否值得优化，通常先问三个问题：错误最初在哪一步产生？它在哪一步才被发现？发现后由谁承担修正成本？如果错误在录入时已经可以识别，却要等到审批人发现后退回，说明校验时点偏晚；如果某字段格式正确、业务含义却错了，说明只做了格式检查；如果同类错误反复出现但没人统计，说明流程缺少反馈闭环。
因此，优化目标不是“字段零错误”，而是减少错误从录入到发现之间的传播距离。越晚发现，通常牵涉的人越多，修正所需的信息也越难找。一个编码选错的问题，若在选择时提醒，录入人员当场可改；若在审批后才暴露，可能还要撤回单据、重新提交、解释原因，甚至更正下游记录。
我不建议把校验规则只记在需求文档里的“字段限制”一栏。每条规则至少要写清：校验对象是什么、为什么要校验、在哪个节点触发、失败后怎么提示、谁有权处理例外。缺了其中任何一项，规则都可能变成“系统拦住了，但用户不知道怎么办”。
这五项把“技术上能不能校验”转成“业务上应不应该拦”。举例来说，系统可以检测一张采购申请是否与已有记录高度相似，但是否直接禁止提交，还要判断重复申请是否可能合理、误判代价多大，以及谁能批准例外。
对资源有限的团队，我建议先选一类高频单据做小范围优化，不要一开始就全模块重构。最小闭环包括：挑出一至两个高频错误，确认业务规则，设计校验节点和错误提示，准备正常与异常测试样例，上线后按错误类型复盘。只有当规则运行稳定、例外可控，再复制到其他单据。
这比一次性给所有字段添加校验更稳妥。新增规则会改变用户操作路径，也可能影响接口、审批和报表口径；分阶段上线能让团队区分“规则设计不对”“主数据有缺陷”和“用户尚未理解”这几类不同原因。
以采购申请为例，一张单据可能包含申请组织、需求日期、物料或服务信息、数量、单位、用途说明、成本归属等内容。具体字段名称和规则会受企业制度、ERP 配置及业务类型影响，因此不能把示例直接当作某个系统的标准字段定义。
常见问题并不只有“没填”。申请人可能选择了一个仍可检索、但已经不适用于当前组织的编码；数量字段符合数字格式，却与单位或包装规格不匹配；需求日期格式完全正确，却早于业务允许的时间范围；申请组织和成本归属各自有效，组合起来却不符合授权关系。
这几类问题对应不同治理对象。格式问题适合字段校验；编码有效性问题需要主数据和使用范围共同判断；字段组合问题需要业务规则；权限问题则涉及角色与组织关系。若把所有问题都当作“录入人员填写错误”，最终往往会出现培训越来越多、退回却不明显减少的情况。
错误在录入页出现时，操作人员通常还知道自己为什么选了某个对象、原始需求来自哪里。等单据经历保存、提交、审批或接口传递之后，相关背景可能散落在聊天记录、邮件或附件中。修正者不仅要改字段，还要重新确认业务意图。
我会把“发现延迟”作为诊断信号，而不只盯着最终退回量。若错误总在审批环节被发现，可能是审批人承担了系统本应执行的基础校验；若错误总在接口回传时发现，可能是外部系统与 ERP 的编码、必填条件或状态口径不一致；若错误在月末集中暴露，则还要检查周期性业务和临时操作是否没有进入常规测试。
新建单据和修改单据的校验条件未必完全相同。新建时，系统可能需要阻止引用已经失效的数据；修改历史单据时，却可能要保留原始记录，或者允许有限字段修改并保留审计轨迹。若把“当前规则”不加区分地套到全部历史数据上，可能造成旧单据无法保存或无法完成必要的更正。
修改场景还涉及状态边界。未提交单据可以由申请人自行修正；已提交或已审批单据是否允许改动、允许改哪些字段、改动后是否重新审批，应由制度和系统权限共同定义。规则不能只写“字段必填”，还要说明不同单据状态下的行为。
现有搜索资料中出现过 SAP MM 采购申请创建、修改过程中的字段校验这一具体主题，但可见材料仅能确认主题方向，无法据此确认字段名称、配置方式或技术实现细节。涉及特定版本、增强机制和具体配置时，应由熟悉项目环境的实施人员核验，不宜将局部经验写成所有 ERP 的通用做法。
对每类错误，我会记录四个节点：错误产生、系统首次有能力识别、业务人员首次发现、修正完成。记录时还要标记发现者和影响范围。例如，需求日期问题可能在录入时就能发现；编码状态问题可能要查询主数据；组织权限组合问题可能要依赖规则引擎或审批关系。弄清路径后，才知道是补字段提示、完善主数据，还是改流程节点。
必填项太少，信息可能不完整；必填项太多，用户会开始用无意义字符、默认值或复制粘贴来通过校验。结果是系统表面上“字段齐全”，实际数据却无法支持业务判断。
我会把必填条件拆成“始终必填”和“条件必填”。例如，某类申请必须说明用途，但另一类由系统自动生成用途信息；某字段只在特定业务类型下适用，就不应对所有用户无差别显示为必填。条件逻辑必须来自确认过的业务规则，并在界面上让用户看懂触发原因。
日期符合格式、金额是数值、编码长度正确，只能证明输入满足形式要求。它并不能证明日期合理、金额符合边界、编码仍在使用范围内。若规则停留在格式层，系统会把“看起来能解析”的数据送入后续流程，错误直到业务人员发现才被纠正。
因此，校验应分层设计：数据类型和格式是底层校验；范围与状态是有效性校验；字段之间的组合条件是业务校验；重复记录和例外行为则需要结合风险、权限和留痕规则判断。并不是每个字段都需要所有层级，但每条关键业务路径都应说明覆盖到哪一层。
审批的价值是判断业务是否合理、是否符合授权，并处理需要人工判断的例外。让审批人逐一检查日期格式、必填项和基础编码状态，会把大量可自动化的检查推给人工，也可能让审批注意力被机械核对消耗。
更稳妥的分工是：系统负责明确、稳定、可重复执行的规则；审批人关注业务理由、风险取舍和政策例外。若某条校验能被清晰描述、适用于大多数正常单据，就优先评估能否在录入或提交时完成，而不是默认留给审批环节。
“数据不合法”“提交失败”“请联系管理员”这类提示没有给用户明确的修正方向。好的错误反馈至少告诉用户：哪个字段有问题、触发了哪类规则、下一步怎么改。涉及权限或主数据维护时，还要说明由谁处理、用户是否能继续提交其他内容。
提示也不能泄露不必要的敏感信息。对于权限规则，告诉用户“当前账号无法选择该组织，请联系组织数据管理员”通常比展示内部授权细节更合适。错误文本应由业务与系统团队共同评审，不应只由开发人员按异常代码生成。
测试环境里一两个正常样例通过，不代表规则覆盖了边界条件、批量导入、接口数据、历史修改和授权例外。规则上线后，用户行为可能发生变化：字段被复制、模板被改动、主数据状态变化，或者新业务类型出现。缺少运行期观察，规则可能逐渐偏离实际流程。
我会把测试和运行复盘视为同一件事的两段：测试证明规则按设计运行，复盘证明设计仍然适用。二者都要有记录，尤其是频繁被例外放行的规则，因为高频例外可能意味着规则边界设计错误，而不一定代表用户在绕流程。
我通常先把字段分为四类：身份与归属字段、业务对象字段、数量金额等交易字段、说明与附件类字段。分级不是为了给字段贴标签，而是为了判断错误后果和可校验程度。
这一分级仍需要企业自己的字段清单支持。某字段即使名为“备注”，也可能承载合规或审计所需信息；不能仅凭字段名称认定其风险低。关键是追问：这个字段后续被谁使用？缺失或错误会造成什么后果？系统是否有足够信息判断它对不对？
规则设计可以用两个问题做初筛：错误后果有多大？系统能否可靠识别错误？后果高且可判断性高的规则，适合明确阻断；后果高但系统无法可靠判断的情况，应提供人工复核或例外审批；后果较低、误拦截代价较高的规则，可以先提示并记录，而不是立即禁止操作。
这不是要把所有规则机械打分，而是避免“发现任何异常就阻断”的单一做法。误拦截也有成本：业务人员可能被迫走线下流程、重复录入，或者请求管理员临时改权限。规则的收益应与误判代价同时评估。
| 业务风险 | 系统判断把握 | 建议处理方式 | 需要保留的信息 |
|---|---|---|---|
| 高 | 高 | 在提交前阻断，明确说明修正条件 | 触发规则、字段值、修正时间 |
| 高 | 低 | 进入人工复核或授权例外流程 | 例外原因、批准人、适用范围 |
| 低 | 高 | 提示或轻量阻断，依据业务影响决定 | 提示次数、用户处理结果 |
| 低 | 低 | 先观察并采集样本，不急于自动拦截 | 问题类型、后续影响、误判情况 |
不是所有规则都应该在同一时间触发。用户输入时适合做格式、必填和选项有效性检查；提交前适合做完整性与字段组合检查；审批时适合处理业务判断和授权例外；接口接收或批量导入时则需要完整反馈每条记录的错误位置。
我会优先把“用户当前有能力修正”的问题放在靠前节点。若用户无法在录入时知道某个主数据状态，就需要界面提供有效选项或明确的维护路径；若某个跨字段规则只有提交整张单据后才能计算，就在提交前给出一次清楚、可定位的反馈，避免让用户逐字段猜错因。
提示文案、修正动作和责任人应一起设计。例如，“需求日期不符合当前业务规则，请调整为允许的交付日期范围，或联系业务负责人确认例外”就比“日期校验失败”更有用。若用户没有权限修改基础数据，系统应告知正确的维护渠道，而不是要求申请人反复尝试。
当一张单据触发多条错误时，应优先展示可同时修正的问题，并按单据区域或字段位置组织，而不是一次只报一个错误。例外处理也要有边界：谁能批准、批准适用于哪张单据、是否限定有效期、是否记录原因，都应明确。
不建议只看“错误总数”。总数增加，可能是规则覆盖更完整，也可能是用户错误真的变多；总数下降，也可能只是错误被转移到线下或不再被记录。至少需要把规则触发量与提交单据量放在一起，并按错误类型、触发节点、修正时长和例外频次分层查看。
可用的观察指标包括：字段错误率、重复退回率、单据一次通过率、规则误拦截率、平均修正耗时、例外审批占比、接口导入失败率。指标口径必须写清分母、统计周期和排除项。例如，“一次通过率”究竟指没有退回，还是没有任何字段修正，应在报表里保持一致。
以下采购申请示例用于展示设计方法，不代表某个 ERP 的标准字段、固定审批路径或系统默认能力。实际字段、状态和规则应依据企业制度、系统配置与接口情况核实。搜索结果曾指向 SAP MM 采购申请字段校验这一局部技术主题，但现有资料不足以确认具体配置细节，因此这里不写未经核实的事务码、字段名或增强方式。
假设业务团队近期观察到三类现象：需求日期被反复退回、物料或服务选项存在失效引用、申请组织与归属信息需要人工确认。我们不先假设这些问题的真实比例，而是将其放进一轮两周的样本盘点中，记录每类问题发生在哪个节点、是否能够在录入时判断、修正由谁完成。
| 校验对象 | 建议确认的问题 | 推荐触发位置 | 失败后的动作 | 规则负责人 |
|---|---|---|---|---|
| 申请组织与归属信息 | 当前用户是否有权限使用？彼此组合是否允许？ | 选择时检查有效选项，提交前复核组合 | 阻断提交并指明需要联系的维护角色 | 业务授权负责人 |
| 物料或服务引用 | 引用项是否有效？是否适用于当前业务类型？ | 选择时或提交前 | 提供可选数据或说明无法选择的原因 | 主数据负责人 |
| 数量与单位 | 数值格式是否正确？单位是否匹配？边界从何而来？ | 录入时校验格式，提交时校验业务关系 | 标出具体字段和规则，不只提示失败 | 采购业务负责人 |
| 需求日期 | 日期格式、最早或最晚范围依据是什么？是否存在例外？ | 录入时提示，提交前检查业务条件 | 展示修正范围或例外申请渠道 | 计划或采购负责人 |
| 需求说明与附件 | 哪些业务类型需要用途说明或支持材料？材料由谁使用？ | 条件满足时提示或要求提交 | 说明缺少信息的原因和所需材料 | 申请流程负责人 |
台账里最重要的不是列了多少规则，而是每条规则都能追溯到业务依据和责任人。如果“为什么要校验”写不出来，先不要急着开发；如果规则有依据但没人负责维护，业务制度变化后它很可能失效。
规则不能只用“正常提交成功”来验收。对每个关键字段，我至少准备五种用例：正常值、缺失值、格式错误值、边界值、合法例外。涉及字段组合时，还要测试单字段分别有效但组合不允许的情况。批量导入和接口数据也要有对应测试，否则网页上的校验可能只保护了手工录入入口。
测试结果要记录预期与实际，而不是只打“通过”勾。例如，预期在提交前拦截组织与归属组合错误；实际却在审批时才提示，就说明规则运行了，但节点设计没有达到目标。若用户收到“字段无效”却不知道如何修正，也应视为测试未通过。
以下是一个用于展示分析方法的样本推演：假设团队选取 200 张采购申请进行试运行，其中 30 张曾触发至少一条校验提醒。试运行阶段记录到 18 张在录入时直接修正、8 张在提交前修正、4 张仍需业务人员确认。上述数字是情景模拟，不是客户案例或行业平均值；真正上线时应由企业自己的系统日志和人工记录替代。
这个推演不用于宣称错误减少了多少，而是帮助团队验证三件事：哪些规则能被自动识别，哪些需要人工判断，哪些提示没有让用户一次修正成功。若同一条规则反复触发但最终经常被批准例外，就要回到业务定义，确认是边界设得过严、主数据未及时更新，还是例外路径缺少正式规则。
实际复盘时，我会按“规则编号，单据类型，触发节点，错误类别，修正动作，是否再次触发，处理耗时，例外批准人”形成记录。这样团队才能把错误从个别人的抱怨，转成可分析、可调整的流程信号。
若企业使用数据分析平台汇总 ERP 日志、表单记录和退回原因，可以将规则触发量、单据量、修正耗时和例外频次按周观察。像九数云这类数据分析工具可以作为报表与分析层的一个选项，适合在数据源和权限条件允许时做指标汇总；它不能替代 ERP 内部的字段校验、权限控制或审批机制，也不应将未脱敏的敏感业务数据随意外传。
看板应回答具体问题，而不是只展示漂亮的总数：哪一类规则最常触发？哪些错误集中在同一录入环节？哪条规则的误拦截或例外比例偏高？修正耗时是否下降？接口导入错误是否被单独统计？没有清晰口径时，工具只会更快地呈现不一致的数据。
先不要立即增加规则。选取一个短周期，对退回单据和失败日志做分类，至少区分格式错误、主数据问题、字段关系冲突、权限问题、业务政策例外、操作理解问题。没有统一错误分类时，可先人工抽样整理，再决定哪些类别值得系统化。
记录时避免只写“资料不全”。应尽量定位到字段、发生节点和缺少的信息。例如“需求说明缺少用途”比“申请信息不完整”更便于后续判断：究竟是字段缺少提示、某业务类型漏设条件必填，还是审批人对用途的要求没有被制度化。
针对高频字段先确认错误是否有稳定定义。如果定义明确，且系统能够可靠识别，就把检查前移到录入或提交阶段；如果错误与主数据维护有关，则同时检查更新责任、失效数据处理和用户可选范围。不要把主数据问题只用输入校验遮盖，因为用户仍可能在其他入口遇到同样问题。
试点时只改一组相关规则，保留上线前后同口径的样本记录。观察错误触发量、修正时间、退回次数和例外次数是否发生变化，同时检查是否出现新的绕行方式，例如线下提交、字段填入占位内容或管理员代录。
不要只在 ERP 页面增加提示。导入模板、接口映射、外部系统状态和 ERP 校验都应纳入同一条数据链路。首先对齐字段含义、编码口径、时间格式、精度规则和无效值处理方式；其次要为失败记录提供行号、字段和原因；最后明确修正后是整批重传还是只重传失败记录。
批量处理尤其需要区分“整批失败”和“部分记录失败”。若一条无效记录就让所有正确记录无法进入，可能影响业务时效；若系统静默跳过错误记录，用户又可能误以为全部导入成功。哪种方式更合适，应结合交易风险、记录间依赖和回滚能力决定。
频繁例外不应自动解释为“用户不遵守规则”。先判断例外是否集中在某类业务、某个组织、某种单据状态或某段时间。若业务确有合法差异，应把差异转成条件规则或正式例外流程；若是数据状态过期，应改主数据维护；若是误报，应调整规则范围。
例外路径要可控而且可审计。至少明确授权角色、适用范围、放行理由、有效时间和后续复核方式。对高风险例外，可以要求额外审批；对低风险且可追溯的情形，则可以减少不必要的层级。关键在于“有依据地放行”，而不是让管理员临时关闭规则。
先建立可复用的规则台账和测试模板，再扩展至其他单据。不同模块的业务对象和风险并不相同，复制的是方法，不是具体校验条件。每次迁移都要重新确认字段用途、主数据来源、流程节点和责任人，尤其要检查不同部门对同一字段是否使用相同口径。
规模扩大后，建议形成规则变更管理：谁提出、谁确认业务依据、谁评估接口影响、谁验收测试、谁批准上线、如何通知用户。字段规则看似小改动，但可能影响录入页面、审批、权限、批量导入和分析报表，不能只把它当成前端提示文案的调整。
阻断能让明确违规的数据不进入下一环节，但也会放大规则误判造成的业务中断。提醒保留了灵活性，却可能被用户忽略。我的判断方式是：规则定义是否稳定、错误后果是否严重、系统判断是否可靠、误拦截是否会迫使用户绕行。
如果错误后果高、规则清晰且系统可准确识别，通常应阻断，并说明如何修正；如果问题需要业务背景判断，应优先提示并进入复核；若规则尚未验证，可以先记录触发情况，在试运行阶段评估误报后再决定是否升级为阻断。上线后的阻断策略也应保留回退方案，避免规则故障造成全流程停摆。
即时校验反馈快，适合格式、必填和有效选项，但不适合要求复杂上下文、可能频繁调用远端数据或会引发输入中断的检查。提交时校验便于一次性检查整张单据，却可能让用户填写较久后才发现问题。
常见的稳妥做法是分层：轻量、明确的检查即时反馈；跨字段或需要整体状态的检查在提交前执行；人工判断留给审批或复核。对于网络条件不稳定、外部接口响应较慢的场景，还要考虑超时处理和保存草稿能力，避免校验服务暂时不可用就让用户丢失已填内容。
自动化适合重复、明确、可重复验证的规则；人工复核适合信息不完整、需要经验判断或风险差异明显的情况。两者不是替代关系。将复杂判断硬编码成简单阈值，可能出现边界误判；把稳定规则交给人工，则会增加重复劳动并造成判断口径不一致。
例如，疑似重复申请可以先根据对象、日期、数量或申请人等信息给出相似记录提示，但是否属于重复业务，应结合申请背景判断。可把“发现相似记录”和“禁止新增记录”拆成两条不同规则：前者系统能够支持，后者未必适合自动执行。
同一字段在不同部门可能有不同业务用法。完全放开，会让报表口径难以统一；强行统一，又可能让特殊业务无法正常录入。遇到这种冲突，我会先区分“字段含义必须一致”和“字段取值可以按业务类型不同”两件事。
如果字段含义必须一致，应统一定义、维护责任和数据口径；如果业务确实存在差异，可以通过业务类型、组织范围或单据场景设置明确条件，而不是让用户在同一个字段里自行创造不同含义。条件越多，测试和维护成本越高，应确认差异是否足够稳定、是否值得进入系统规则。
局部优化上线较快，适合高频、边界清楚的问题；缺点是如果没有统一规则台账，可能逐步形成散落在不同页面、接口和报表里的重复逻辑。一次性重构有机会统一规则，但需求范围、数据依赖和回归测试更大，也更容易延长上线周期。
我通常建议先做有边界的试点，同时把规则登记到统一台账。试点检验的是业务逻辑和用户反馈；台账解决的是长期维护和跨模块复用。只有在确认多处重复、现有逻辑相互冲突或维护成本持续上升之后，再评估是否重构，避免为了“统一”而过早扩大项目。
上线前，我会要求业务、系统和数据责任人共同确认规则依据、适用单据、触发节点、失败动作、例外权限和测试结果。还应确认提示文案、错误日志字段、报表口径以及规则变更负责人。若某个字段的业务含义还在争议中，先解决定义，再做系统化。
第一组是发生率，例如按单据量计算的字段错误率和接口失败率；第二组是流程结果，例如一次通过率、退回率和重复提交率；第三组是处理成本，例如平均修正耗时和人工复核次数；第四组是规则健康度，例如误拦截、例外放行和无人负责的规则数量。
每个指标都应附上定义和分母。单看“退回量”容易受单据总量变化影响；单看“错误提醒次数”可能把同一张单据多次触发计算多遍。对于小样本，建议同时看具体案例和趋势，不要根据几次波动就判断优化成功或失败。
组织调整、产品或服务目录变化、审批制度更新、接口升级，都会让原来的校验条件失效。规则复核可以按风险和变更频次安排，不一定所有规则都用相同周期。高风险、频繁变更或例外较多的规则，应优先复核；长期稳定且低风险的规则，可以降低复核频率，但仍要保留责任人和变更记录。
复核时不只问“规则还在不在”，还要问：触发量是否异常、例外是否越来越多、用户是否采用线下绕行、下游是否仍然发生相同问题。若某条规则长期没有触发，可能说明风险已经消失，也可能是埋点、日志或入口覆盖不完整，需要查清后再决定停用。
读者可以先选择一类退回频繁、业务影响明显且责任人相对清楚的单据，不必等全公司数据治理项目启动。用一张表记录字段、规则、业务依据、触发节点、错误提示、例外权限、责任人和复核日期；再抽取一批正常与异常样本验证规则，试运行后根据触发日志和用户反馈调整。
我的核心判断是：高质量的数据录入不是靠更多拦截获得的，而是靠正确的规则在正确的节点被正确的人理解和维护。下一步最值得做的，不是先问“还能加哪些校验”，而是找出一类高频错误，追溯它从哪里产生、为何没有被及时发现，再决定该改字段、主数据、流程还是责任分工。这样得到的优化，才会真正减少返工，而不是把错误从一个环节推到另一个环节。
我发现有些单据在录入时看起来没问题，提交后却被退回；也有些系统一填错就立刻拦截，用户连正常录入都很难。我想知道，字段校验究竟该放在录入、提交还是审批环节，怎样安排才不增加不必要的操作？
不要把所有校验都堆到审批环节，也不要把每条规则都设成录入时阻断。更实用的判断方式是看错误能否即时发现、错误后果有多大，以及用户是否有条件当场修正。录入时适合检查格式、必填和有效选项，例如日期格式、数量是否为数字、物料编码是否仍可使用。
提交前适合检查字段组合和流程完整性，例如申请组织与可选物料是否匹配。审批时则应聚焦业务合理性和例外情况，不应让审批人重复检查基础格式。以采购申请为例，选错失效物料应尽早提示；需求日期不符合已确认的业务约束，可在提交前说明原因并允许修改；确需例外的情况，则进入授权审批并记录理由。
规则放得越晚，返工成本通常越高；放得越早，也越要保证提示可理解、可修正。
我准备整理一份单据字段检查表，但目前想到的主要是必填和格式校验。我担心字段都填了、格式也正确，单据之间仍然存在业务矛盾；想知道一张实用的校验清单还要检查什么。
字段清单至少要覆盖六类规则：是否必填、格式与类型、数值或日期范围、引用数据是否有效、字段之间是否匹配，以及是否可能重复提交。必填规则还要区分始终必填和条件必填，避免把所有字段一律设为必填，增加无效填写。
规则类别采购申请示例设计注意 必填与条件必填按业务场景要求补充用途先确认触发条件 格式与范围数量为有效数值，日期符合格式明确边界和单位 引用有效性选择当前可用的物料或服务项依赖受维护的基础数据 字段关系组织、物料、单位组合符合业务规则由业务部门确认约束 重复检查识别相同申请是否可能重复提交先提示，谨慎直接拦截 关键不在于规则数量，而在于规则有明确业务依据、责任人和例外处理方式。
某项规则如果说不清拦截原因、由谁维护，或无法解释合法例外，就不宜直接做成硬性阻断。
我遇到过错误提示只显示一个代码，录入人员不知道要改哪一项，只能截图发给管理员；还有的单据被退回后，原因没有留下记录。我想设计一套能让用户自行修正、也方便后续追踪的处理方式。
一条有效的错误提示应回答三个问题：哪里有问题、为什么不符合规则、用户下一步能做什么。与其显示字段校验失败，不如指出需求日期早于允许范围，并说明应核对业务约定或选择符合条件的日期。提示要定位到字段，避免用户在整张单据里反复查找。按风险把处理方式分为提醒、警告、阻断和授权例外。
低风险或可能存在合理重复的情况可先提醒；涉及无效基础数据、关键归属错误等情况，可在提交前阻断；确有业务例外时，允许有权限的人员说明理由后放行，并保留操作记录。退回记录至少保留单据编号、错误类别、发生节点、退回原因、修正结果和处理时间。
这样管理者能分辨问题来自规则缺失、基础数据失效还是操作不熟悉，而不是只看到退回次数。错误原因应使用稳定分类，便于后续统计和调整规则。
我不想只用培训次数或系统上线作为优化成果，也不希望没有依据就写错误率下降了多少。我想知道应该记录哪些指标、观察多久，以及如何判断问题是校验规则不够还是主数据和流程出了问题。
先建立可复核的基线，再比较优化前后的同类单据。可记录首次提交通过率、因字段问题退回的单据数、每类规则触发次数、重复退回情况、例外放行记录，以及从提交到修正的耗时。指标要说明统计口径，例如按单据数统计还是按字段错误次数统计，避免前后不可比。
可先选择一个高频单据做试运行，例如采购申请，连续观察一个完整业务周期，并把问题按字段规则、基础数据、界面提示、权限和流程节点分类。若格式错误反复出现，优先检查输入控件和提示；若有效编码选择困难，检查基础数据维护；若大量单据在审批时才发现缺项，检查校验时点和提交流程。
不要只看拦截次数下降：次数变少可能是规则被绕开，也可能是数据真的改善。应同时检查抽样单据质量、退回原因和例外放行记录。没有可靠实测数据时，报告趋势和问题构成即可，不要把示例或目标值写成已经实现的效果。
读者评论
文章把问题从“员工不认真”转向校验时点和责任分配，这个角度比较实用，尤其适合排查审批环节反复退回的情况。
字段格式正确不代表业务含义正确，文中区分格式、有效性和组合规则，有助于避免只加格式限制却解决不了实际错误。
条件必填比一概增加必填项更合理，但前提是业务场景和触发条件定义清楚，否则用户仍可能不知道为什么被拦截。
文中强调错误提示要说明问题字段和修正方向，这点容易被忽略；如果还涉及主数据或权限，明确处理责任也很关键。
情景模拟数据都标明不是实测结果，边界交代得比较清楚。上线后按错误类型复盘，也能帮助判断规则是否需要调整。