客户按箱下单、目录按件销售，Agent 怎样核对销售包装与整倍数

客户按箱下单、目录按件管理时，Agent 应保留原始订货表达，用该产品获批销售包装换算，再检查订货倍数。换算不满足整箱条件，就列例外供客户和销售确认，不自动加量。销售包装核对 Agent 开发可以减少数量解释返工，但本篇不算应收金额、不安排仓储出库。

“一箱”不是全公司的固定单位

先由产品资料方提供每个SKU的销售包装、所含基础数量、适用渠道和版本。一箱A含6件，一箱B含12件，不能建一个全局“箱等于6件”的规则。包装名称相同并不表示数量相同，客户自己的箱叫法也未必等于卖方目录包装。

Odoo的包装文档原文将包装设为产品专属，并记录数量与参考单位，可作为数据结构参考。最小订量、整倍数及例外审批则由客户提供，不把平台包装功能说成已经实现完整商业订货规则。

输入记录包含客户原文、产品身份、销售包装、基础数量和依据。先完成客户料号对应再换算，避免拿对数量规则却用错产品。产品不明确时保持未匹配，不因订单写3箱就找到一个最近销售过的包装。

SKU-A每箱6件，客户订3箱，得到18件，并在确认表同时保留3箱与18件。下游需要件数时有确定值，客户核对时仍看得见自己最初表达，不能只留下18而丢掉包装含义。

A订20件且仅允许整箱时，不能自动向上取24，也不向下取18。报告列20件不是6的整倍数、当前批准规则和需确认窗口。B订3箱则为36件；与A输入文字相同，结果不同，正好检查系统有没有错误共用包装。

下载包装数量与例外演练，各条输入均有实际核算结果和后续确认栏。数量只是合成例子，附件没有真实库存、售价或客户订单。正确结果不只是算对乘法，还要保留无法直接接受的例外状态。

确定程序可以检查整数倍、按明确换算关系计算，模型只负责解释原文、展示差异和提出补充问题。若客户写“大箱”而目录只有“6件装”，需要取得对应确认，不能让模型凭习惯等同。即使系统能除出小数箱，也不证明企业允许拆箱销售。

最小订量与包装倍数独立。例如某产品有6件装，同时本企业还可能规定其他最小订量；没有给出后者就不自行增加要求。首期只核已取得的规则，在报告中列覆盖范围。不要为了看起来专业补一套通用订货门槛。

产品已满足客户选型条件后，仍需要商业数量核对；反过来数量正确也不能证明产品符合用途。可按获批目录筛选把产品候选与包装条件串成两个独立步骤，避免用包装可订替代选型成立。

销售同意本次按20件处理时，应记录本次订单、例外内容、批准人和范围，不修改A所有客户的整箱规则。客户接受改为其他数量，保留修改前后表达；价格和交期影响另经商务确认，不能随数量修正自动承诺。

包装资料更新后，需要判断这张订单引用哪个版本。新包装不能直接回填历史订单，旧数据也不能永远沿用。确认页应显示换算来源和待核事项，让录单人员能看到解释而不只看一个基础数量。

验收先人工复算三行，再检查错误分支是否产生了确定订单。重点验证20件没有被取整、B没有套A规则、原始箱数仍在。表格重跑结果应相同，人工填写实际处理后留审核人，不能将附件预期直接当成自动化通过。

确认表应同时让销售和客户看懂数值变化。对3箱换成18件，可直接展示乘法和包装来源；对20件不满足整箱，应显示原请求仍为20，并把是否允许例外留给批准窗口。数学上能得到余数，不表示这个余数可以由系统自行舍弃。

如果订单系统只接受基础件数，还要在只读预览中保留原始包装表达和转换规则编号。这样下游发现数量争议时能回查，而不是面对一个来源不明的18或36。本文只准备这种业务解释，不声称已经完成任何ERP写入。

接口数量字段的传递另见数量单位契约，本题处理产品特定销售包装。更多方向见流程自动化专题。到定制咨询提供两种包装目录、一次非整箱申请和现行确认方式，可先确定换算、例外和录单预览边界。