检查：从客户需求到发送约定

相同的 order_id·SKU·数量到达两次但 event_id 不同。这份合同的处理流程是怎样的？

• 仅保留第一行作为候选，其余行用于重新交付。
• 由于事件不同，每个事件都被留下作为新保留的候选者。
• 将两行归类为冲突并暂停整个订单
• 将两行中的数量相加以创建一个候选项。

在文件的末尾，我发现数量与我之前看到的订单不同。传输之前需要什么设计？

• 先发送上一行，如果发现冲突，将其从报告中删除
• 检查整个文件并保存该订单的所有行
• 它假定文件的最后一个值被修改并仅发送最后一行。
• 最先出现的值被视为原始值，仅保留后面的行。

预订API仅需要订单、SKU和数量。我该如何处理原件中包含的电子邮件地址？

• 将其保留在保留正文中，但将其与原始行一起保留在错误日志中。
• 如果调查失败，电子邮件地址将包含在所有预订标头中。
• 从传输/报告/日志中提取并留下经过验证的订单 ID 和行
• 删除成功的订单并仅在报告中写入失败订单的电子邮件。

两行相同的有效订单 ID，一行为正常，另一行为数量 2。分类是什么？

• 传输正常行并仅将坏行保留为无效。
• 坏行被视为重新传递，只有好行才被视为候选行。
• 将 2 更改为数字 2，并仅比较两行的内容。
• 两行均被视为无效并被排除在候选之外。

收到的数量字符串 02。在本合同中，允许的范围是字符 1 到 5？

• 它不会自动用整数更正，并且由于输入有缺陷而被搁置。
• 由于数字含义为 2，因此它的传输方式与正常输入完全相同。
• 将原文02维护为JSON字符串并发送给仓库。
• 将其转换为十进制 2.0 并与整数输入分开传输。

客户尚未确定冲突订单的确切数量。 FDE 现在可以提供什么？

• 选择量大进行预约并要求客户稍后更正
• 实施保留政策并在移交的基础上留下未清项目
• 选择少量，保留，并从以下文件中接收不足部分。
• 关闭重复检查，让仓库直接判断所有行