销售刚把订单数量改成12件，仓库同事补了一句发货备注，数量却又变回10件。两个人都看见了“保存成功”，也没人主动把数量改回去，问题出在哪里？在多人使用的订单、客户和项目管理系统中，这种情况值得单独测试。
假设两个人同时打开一张数量为10件的订单。销售改成12件并保存，系统里的记录已经更新；仓库同事的页面没有刷新，仍然显示10件。他只改备注，但如果系统提交并覆盖的是整张旧表单，数量也会跟着写回10件。后保存的人覆盖了前面的修改，却未必知道自己覆盖了什么。
这也说明，“最后保存的那一版”不等于“业务上应该采用的那一版”。仓库同事确认的是备注，不是把数量从12件改回10件。
只保存改过的字段，为什么还不够
一种改法是只提交本次真正修改的字段。仓库只改备注，就不把旧数量一并送回系统。对于数量和备注这两个互不影响的修改，这能减少误覆盖，但不能解决所有冲突。
如果两个人都改数量，一个改成12件，另一个改成15件，系统仍然需要知道：后一个人是在原来的10件上作决定，还是已经看过12件才改成15件。数量还可能影响金额、备货和审批状态，不能看到字段不同，就认定所有修改都能直接合并。
因此，记录需要有可比较的版本标记。打开时记住读取的版本，保存时检查它是否仍与系统中的版本一致。这项检查要和写入一起完成，不能只是进入页面时查一次，或者先单独查版本，再不带条件地保存；否则检查之后，仍可能有人抢先改动。
发现冲突后，要让人看懂哪里变了
如果版本不同，直接提示“保存失败，请刷新”也不够好。使用者可能已经填写了很长的备注，刷新后全部丢失，只能重写；也可能不明白哪里冲突，照着原来的内容再提交一次。
更合适的做法是保留尚未保存的输入，显示与本次修改有关的差异：打开时数量是10件，现在是12件；本次改的是哪条备注。使用者看清最新记录后，再决定是否把备注补进去。需要重新提交时，应以刚核对的版本继续检查，不能因为已经提示过一次，就放开覆盖。
互不影响的字段可以按事先确认的业务规则合并；涉及数量与金额、收货信息与已生成的发货单，就要检查关联状态。订单已经进入发货环节时，改数量也许需要走变更流程，不能让一个通用的“仍然保存”按钮绕过去。
做业务系统开发时，把这些处理放进实际操作过程，比单纯展示一个“多人在线”的功能更有意义。有人正在编辑的提醒可以帮助沟通，但保存时仍需检查记录是否已经变化。
两个人按这个顺序操作，就能看出区别
准备两个测试账号，同时打开同一张未发货的测试订单。甲先修改数量并保存，乙保持旧页面不刷新，只改备注后保存。查看数量有没有回退、备注是否保留，以及乙能否看懂发生了什么。
然后交换保存顺序，再让两个人修改同一个字段。系统可能选择提示冲突，也可能在明确规则下合并独立修改，但不应无提示地用旧值覆盖新值。测试时还要保留乙尚未提交的文字，确认处理冲突没有把输入一起丢掉。
多人协作的关键不是谁最后点了保存，而是每次修改都建立在使用者看过、系统核对过的记录上。
返回列表