客户发来改单邮件，Agent 怎样按原订单行生成变更审批草案

客户发来改单邮件，Agent 应按原确认订单行列出增减、取消和保留项，再结合当前履行状态准备审批草案。没有提到某一行，不代表取消它；客户提出变更，也不等于卖方已经接受。销售改单 Agent 定制先解决请求语义与影响解释，不直接提交ERP修订。

原确认与当前状态一起取得

原确认说明双方此前接受什么，当前状态说明哪些部分已经履行，两者都不能缺。只拿原订单比较新邮件，可能把已交付数量也覆盖；只看当前系统，又可能不知道原商定范围。输入应保留订单ID、行号、数量单位、现行确认和受控状态来源。

客户原话保存为请求，不转写成已生效指令。邮件同时改数量与范围时分字段核对；对象不清先列待匹配，不凭最近订单猜是哪一行。收到时间晚，也不能独立证明它取代了全部先前确认。

Oracle的订单履约期间变更说明区分订单头、订单行与明确取消，并提示不同渠道的字段语义。本文只形成草案，不调用可能直接提交履约的修订接口，也不把某平台空字段行为套到所有系统。

L1从10增至12，草案写增2，保留原10。L2在邮件未被提及，只修改L1，应保留5，不能因输入未带该行就删除。L3原10、已履行4，客户要求全部取消，应分别显示已履行4和剩余6，交商务判断可处理范围。

下载改单明细合成演练有三种请求和预期，实际结果栏记录批准决定。本篇不判断客户是否有取消权、不计算损失或赔偿，也不自动撤销已发生履行。

合成记录	输入要点	预期处置
Z026-1	订单行：L1；原数量：10；客户请求：增至12；当前：未履行	增2的变更草案，待批准
Z026-2	订单行：L2；原数量：5；客户请求：邮件未提本行，只改L1；当前：未履行	保留L2原值，不视为删除或取消
Z026-3	订单行：L3；原数量：10；客户请求：全部取消；当前：已履行4	列已履行4和剩余6，交业务判断可变更范围
Z026-4	订单行：L3；补充：草案期间当前履行量从4变5	原草案过时，按当前状态重新核可变范围，不提交旧剩余6

变更表按行显示原值、客户请求、计算差异、当前状态及所需批准。对没有变化的行可折叠，但应明确保留集合。只给“订单已更新”一段摘要，会让审批人看不见被误删的行。

订单头地址变化是否作用于全部行，需要企业规则；客户只改某行日期，不应自动改其他行。空白、未提供和明确清空采用不同状态，缺少含义时请业务确认。模型不能凭语气决定取消是否已经生效。

主体改变时先查交易角色确认，不能把更换收货方当普通文字修订。客户要求分批时，再形成分批交付请求，每批数量与日期单独核对，不能用一行备注替代结构化影响。

已批准改单后又有新请求，保留新旧请求关系，重新呈现差异。审批只覆盖某行数量时，不连带接受新增服务、价格或日期。旧批准号不能被复制到范围更大的新草案。

本题比较买卖双方业务文件及原订单行，产物是可审阅变更材料。外部通知乱序处理则是另一种工程机制：它决定收到的状态是否可归并，不能代替商务判断哪些数量允许改变。

批准前重新核对当前履行状态，若L3在草案期间继续履行，原差异可能过时。报告应提示需刷新，而不是按旧剩余量提交。无法取得当前状态时保持待核，不能把未知当未履行。

验收请销售手工列出三行的原值和拟变更范围，再比系统。关键是L2没有消失、L3没有把已履行4抹掉，L1没有直接写成已接受12。实际审核结果另存，不将预期标签当作目标订单状态。

接手窗口需能从每个差异回到客户原话和原订单；修改说明只缩短阅读，不改变对象和条件。试点可先使用脱敏导出数据生成草案，正式写入、通知和结果核对另列实现范围。

改单审核人还需看到原订单中本次保持不变的行数和引用。只看新增差异，可能无法发现L2被实现层漏传；保留集合能让审核人核对本次确实只改L1。预览应明确哪些是客户要求，哪些是系统计算的增减，不能把建议描述写成客户原话。

试点回放时可以连续处理同一组三行，确认每次得到相同保留与变化集合。保存当前状态的来源截止，避免把已经过时的草案继续交下一部门执行。

项目新增需求的范围变更记录与本题对象不同。更多任务见流程自动化专题。到定制咨询提供原订单、三条改单和人工批准方式，可先确定行映射、影响说明及确认入口。