框架协议分批下单，Agent 怎样核对本次释放量和剩余承诺

框架协议分批下单时，Agent 应先确认承诺类型，再核对本次订单是否关联正确协议、是否在期间内以及已经使用多少。输出是释放核对表和剩余承诺草算，不自动放行超量订单，也不判断合同法律效力。框架协议下单核对 Agent 的难点不在减法，而在什么记录可以参与减法。

一条协议可能有不同承诺类型

按产品数量承诺与按金额承诺不能共用余额字段；特定产品金额和类别金额也有不同适用对象。资料方先提供批准协议行、承诺类型、产品或类别、单位、有效期和约束。原文含义不清时由商务窗口解释，不让模型从历史订单推定类型。

微软的销售协议说明区分数量与金额承诺，并将相关订单行计入履约，可作为核对结构参考。本篇不套用其所有价格规则，实际是否计入、如何处理退回与取消，需要企业批准口径。

协议总额和订单本次金额也要分开。只有属于该协议、该行且符合口径的释放记录才能累计，不能按同客户所有交易求和。缺关联信息时保留未知，不因为金额看起来接近就匹配。

合成协议数量100，已释放60，本次30，演示剩余10。若本次50，累计110，列超承诺10候选，不能自行将订单截为40。另一协议是类别金额承诺，本次只有数量30，不适用数量余额，需要正式金额口径数据。

下载协议释放合成演练保留承诺、已释放和本次输入，并预留实际判断及审核人。数值仅供计算路径验证，不代表真实采购安排或通用协议限制。

每个汇总量能展开到组成订单行，显示为什么计入。已取消但尚未确认是否释放额度的记录，单列待核，不直接返还余额；退回与更正也要有原行关系，不能把负数一概当额度可再用。

本次订单应采用哪种业务日期判断有效期，需要资料方明确。订单录入时间与客户要求交付时间可能不同，不能任选一个令条件满足。临界日期缺解释时先暂停采用结果，交协议窗口确认，不从系统时区猜商务含义。

协议改版后，历史释放记录仍引用当时有效版本，不能把新承诺无痕覆盖旧记录。若批准调整承诺数量，应显示原承诺、变化和当前可用口径；不把后续加量当成过去未超量的证明。

接单前还应看PO差异核对，确认客户文件与商定范围一致；涉及不同下单方或收货主体时，再用交易主体确认判断该订单是否可归入协议客户范围。名字相同不能代替主体关联。

核对状态至少区分可形成草案、疑似超承诺、数据不足与类型不适用。超量不是自动拒单，可能有有效调整或例外，但必须取得对应批准。资料齐全也不代表已经生成正式销售订单。

商务人员确认本次释放后，后续系统实际生成的订单行应能回到本次核对记录。本篇不写回ERP，试点可以先用导出表演练；若未来接写入，需要另验证审批、并发和结果读取，不能直接用草算余额作为执行锁。

验收从附件手工计算，检查30和50的差别，以及金额类型没有被错误相减。然后从60反查组成明细，确保它不是无来源的手填汇总。能解释每项参与范围，比最终显示一个正确数字更重要。

维护人员还需要知道未来哪些事件会触发复核，例如协议批准版本改变、关联释放记录更正。本助手只读取明确业务变化，不猜订单已经撤销，也不把申请取消等同实际额度返还。最终余额状态由业务与系统记录共同核对。

协议窗口可以先查看本次释放行，再展开已释放60的组成记录，确认是否有不应纳入的其他产品或期间。余额计算正确但组成集合错误，仍会导致后续超量或漏计。参与计算的每一行应有稳定引用，不能只接受一列汇总值。

同一申请重复核对时保留原请求号，生成草算不占用额度。正式订单形成后，依目标记录核对实际释放，避免把草案和正式行累计两次。

与沟通承诺台账相比，本题依据正式协议行及释放关系。更多任务见流程自动化专题。在定制咨询提供脱敏协议、两批释放明细和本次订单，可先确定计入范围、草算与人工放行材料。