关于销售订单挑库发放卡接口以及发运处理卡接口的处理方式

本文详细介绍了在处理销售订单挑库发放卡接口异常时的处理方式,包括清除接口表和保留表的记录,备份数据,重新创建交货和生成搬运单号,以及检查并处理发运确认卡接口表情况。对于未勾选发运的物料,已发运确认且已产生AR接口的处理方式也进行了阐述。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1.关于销售订单挑库发放卡接口的处理方式:

        在处理异常过程中,有时会碰到销售挑库后物料已有保留,但是交易记录就一直卡接口,到待定事务处理处提交也不成功,也没任何错误提示。

       对于出现上面的情况,只能将接口表和保留表的记录都清除,然后点击延交,重新创建交货和生成搬运单号。之后再到处理物料搬运单那里直接选择库存挑库发放即可。

     需要对于删除的数据进行备份保留:

    SELECT * FROM MTL_RESERVATIONS
    WHERE ORGANIZATION_ID = 2149
    AND INVENTORY_ITEM_ID = 17778538

    INSERT INTO MTL_RESERVATIONS_BAK
   SELECT * FROM MTL_RESERVATIONS
   WHERE ORGANIZATION_ID = 2149
   AND INVENTORY_ITEM_ID = 17778538

    DELETE FROM MTL_RESERVATIONS
    WHERE ORGANIZATION_ID = 2149
    AND INVENTORY_ITEM_ID = 17778538;

    删除接口表数据

   delete
   from mtl_material_transactions_temp a
   where a.inventory_item_id = 17778538;

  delete
   from mtl_transaction_lots_temp a
   where a.transaction_temp_id = 309494113;


2.对于发运确认卡接口表情况的处理

    首先查看是否已经产生了接口表数据

    SELECT INV_INTERFACED_FLAG,OE_INTERFACED_FLAG,SOURCE_LINE_ID,SOURCE_HEADER_NUMBER,INVENTORY_ITEM_IDFROMWSH_DELIVERY_DETAILS

     WHERE DELIVERY_DETAIL_ID =34303742

     INV_INTERFACED_FLAG :N 代表尚未产生数据到INV的接口表,若为P则代表已经产生数据到interface表了,只是在处理数据时出错了。

 

     OE_INTERFACED_FLAG :N代表尚未产生AR INTERFACE数据

 

      INV接口

      SELECT TRANSACTION_TYPE_ID,TRANSACTION_INTERFACE_ID,SOURCE_HEADER_ID,TRANSACTION_HEADER_ID,ORGANIZATION_ID

       FROM MTL_TRANSACTIONS_INTERFACE

       WHERE SOURCE_LINE_ID =7805072

       AR 接口

      SELECT * FROMRA_INTERFACE_LINES_ALL

       WHERE sales_order ='104215010233'

        AND INTERFACE_LINE_ATTRIBUTE3 =1128744

 

若没有产生接口数据,则需要跑  连接行程停靠站– SRS  以及工作流   工作流后台流程   OEOL, , , Y, N,N

 

若状态还是没有变过来,仍然卡在物料事物处理的接口表中,到相应的库存组织下的

查到数据后点击提交

然后查看事物处理是否已经产生了。

跑完后数据变成已连接,不适用



3.对于未勾选发运的物料,已发运确认且已产生AR接口的处理方式:

     这种物料只有转移记录,没有挑库和发放记录,有AR接口数据,对于这种已经到财务的数据,只能再重新下一个退货单,并将此具体的发货批次退回来。

     针对前期就停留在FHC的数据,先到标准保留界面去删掉,之后用其他杂项事物处理将数据从发货仓杂出。最后将退回到外仓的数据重新备货到相应的合同上做发货确认 。


  






   

<think>好的,我现在需要解决用户提出的EBS销售订单发放失败,状态显示为已延交的问题。首先,我得理解用户的问题场景。用户在使用EBS系统处理销售订单时,在发放阶段遇到了失败,导致订单行状态变为已延交。需要找出可能的原因并提供解决方案。 首先,我应该回顾系统级指令中的引用内容,特别是引用[1]、[2]、[3]提到的相关步骤和API调用。根据引用[1],销售订单的有效性验证是关键步骤,包括检查子存的货位控制、物料可用量等。如果这些验证未通过,可能导致后续发放失败。 用户提到状态是已延交,根据引用[1]中的说明,发放失败后,行状态会变为已延交,下一步仍需发放。这可能意味着在调用API进行发放时,某些条件未满足,导致处理中断。 接下来,我需要考虑可能的失败原因。根据引用[2]中的代码示例,发放可能失败的原因包括物料搬运单处理问题、存不足、货位配置错误等。例如,如果子存启用了货位控制但未生成货位,或者可用量不足,都会导致API调用失败。 解决方案的第一步应该是检查有效性验证的步骤。用户需要确认销售订单是否完全传回客户化表,关键字段是否正确,子存是否启用了货位控制,是否生成了正确的货位。如果货位未生成,需要调用API生成,如引用[1]提到的。 其次,检查物料可用量。如果物料在子存中的现用量不足以满足订单需求,发放会失败。此时需要调整存或修改订单数量。 然后,查看错误日志和发运例外报表。引用[2]中提到,如果发放出现警告或部分完成,需要检查相关报表以获取具体错误信息。例如,并发模式下可能存在的锁冲突,或者物料搬运单未能正确处理。 另外,引用[3]提到提货区(pick_from_subinventory)的配置可能影响发放。需要确认提货子存是否正确配置,是否与订单要求的子存一致。 如果问题仍然存在,可能需要手动处理或重新运行发放。引用[2]中的代码示例显示,当联机发放失败时,建议在并发模式下运行,这可能更稳定或提供更详细的错误信息。 最后,系统配置和补丁也是需要考虑的因素。某些情况下,系统参数设置不正确或缺少必要的补丁会导致API行为异常,需要与系统管理员确认。 总结步骤,应该包括验证订单有效性、检查存和货位、查看错误日志、调整并发处理、确认子存配置,以及系统检查。用户需要按照这些步骤逐一排查,找到具体原因后采取相应措施。</think>### EBS销售订单发放失败(状态已延交)的解决方案 #### 一、核心问题定位 发放失败导致行状态为“已延交”,通常与以下环节相关: 1. **存可用性不足**:子存中物料现用量无法满足订单需求[^1] 2. **货位控制异常**:启用了货位控制但未生成有效货位[^1] 3. **物料搬运单处理失败**:API调用后未成功返回处理批号[^2] 4. **并发冲突**:在线发放模式与后台进程产生资源竞争[^2] #### 二、分步解决方案 **第一步:验证存可用性** 1. 检查子存物料可用量: ```sql SELECT SUBINVENTORY_CODE, INVENTORY_ITEM_ID, ON_HAND_QUANTITY, RESERVABLE_QUANTITY FROM MTL_ONHAND_QUANTITIES WHERE ORGANIZATION_ID = [目标存组织ID] ``` 2. 若可用量不足: - 调整存分配策略 - 执行存补充操作 - 修改订单需求数量 **第二步:货位控制验证** 1. 检查子存货位配置: ```sql SELECT SECONDARY_INVENTORY, LOCATOR_CONTROL FROM MTL_SECONDARY_INVENTORIES WHERE ORGANIZATION_ID = [组织ID] ``` 2. 若未生成货位: - 调用`INV_LOCATOR_PUB.CREATE_DEFAULT_LOCATORS`生成默认货位[^1] - 验证货位与物料的关联性: ```sql SELECT LOCATOR_ID, INVENTORY_ITEM_ID FROM MTL_ITEM_LOCATIONS WHERE ORGANIZATION_ID = [组织ID] ``` **第三步:API调用排查** 1. 检查发放API返回参数: ```csharp wsh_pick_list.online_release( p_batch_id => l_batch_id, p_pick_result => l_pick_result, p_pick_phase => l_pick_phase ); ``` - 若`l_pick_result='F'`表示完全失败 - 若`l_pick_result='W'`表示部分成功[^2] 2. 失败处理策略: ```flow st=>start: API调用失败 cond1=>condition: l_pick_phase='MOVE_ORDER_LINES'? op1=>operation: 部分完成需手动处理物料搬运单 op2=>operation: 改用并发模式重新发放 e=>end: 更新状态 st->cond1 cond1(yes)->op1->e cond1(no)->op2->e ``` **第四步:并发模式处理** 1. 通过标准功能提交请求: ``` 路径:订单管理 > 订单发放 > 发放销售订单 ``` 2. 设置关键参数: - 选择`处理方式=并发` - 指定`发放批次ID`[^3] 3. 监控请求日志: ```sql SELECT REQUEST_ID, PHASE_CODE, STATUS_CODE FROM FND_CONCURRENT_REQUESTS WHERE REQUEST_DATE > SYSDATE-1 ``` #### 三、高级调试方法 1. **启用诊断日志**: ```sql EXEC FND_GLOBAL.APPS_INITIALIZE([用户ID],[责任ID],[应用ID]); EXEC MO_GLOBAL.SET_POLICY_CONTEXT('S',[组织ID]); ``` 2. **捕获详细错误堆栈**: ```csharp BEGIN wsh_pick_list.online_release(...); EXCEPTION WHEN OTHERS THEN l_err_msg := SQLERRM; fnd_file.put_line(fnd_file.log, DBMS_UTILITY.FORMAT_ERROR_STACK); END; ``` #### 四、预防性措施 1. 建立预检查脚本: ```sql -- 货位可用性检查 SELECT COUNT(*) FROM MTL_ITEM_LOCATIONS WHERE INVENTORY_LOCATION_ID IN ( SELECT PICK_FROM_LOCATOR_ID FROM WSH_DELIVERY_DETAILS WHERE DELIVERY_DETAIL_ID = [目标行ID] ) ``` 2. 配置自动重试机制: ```csharp FOR i IN 1..3 LOOP BEGIN wsh_pick_list.online_release(...); EXIT WHEN l_pick_result = 'S'; EXCEPTION WHEN OTHERS THEN DBMS_LOCK.SLEEP(60); -- 等待资源释放 END; END LOOP; ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值