zoukankan      html  css  js  c++  java
  • 诡异的销售订单辅助数量

    现象:

    用户反映说在处理物料搬运单的一笔记录后,发运事务处理变成了两笔,如下:

    搬运单:

    物料 数量 主单位 辅助数量 辅助单位

    A 82 T 44 EA

    发运事务处理记录:

    物料 请求数量 主单位 辅助请求数量 辅助单位

    A 82 T 41 EA

    A 0 T 3 EA

    所以在发运确认时候,无法成功发运确认。提示请求数量0.


    经过与用户沟通,并且诊断该笔销售订单,重复虚拟操作各种情况,终于重现出该问题。

    首先物料A设置双单位,主单位T,辅助单位EA 。100%~200%

    然后根据系统计算转换单位的标准API计算数量82T的值是41EA,即转化率为1/2

    订单操作流程:

    1. 创建一笔销售订单并登记。

     物料数量 主单位 辅助数量 辅助单位

    A 184 T 98 EA

    2.发放该订单。

    3.挑库101T,辅助数量54 ,处理物料搬运单,发运确认

    发运行中辅助请求数量是50.5, 已延交辅助请求数量为3.5

    4.查看物料事务处理记录

     从st出库有两笔记录,一笔是50.5,一笔是3.5,两笔记录的事务处理类型不一样

    5.回到销售订单,此时订单行由原来的一行变为两行。

    第二行的辅助数量为47.5.

    更改第二行的辅助数量为44.

    输入更改原因,保存,然后提示创建新的版本。

    6.发放、挑库、处理物料搬运单

    此时在发运事务处理行中搞出一笔请求数量为0的记录。 


     如果第五步不更改订单行,44EA在挑库时输入,则不会发生此现象。

  • 相关阅读:
    WebClien简单示例(一)
    关于WQS二分算法以及其一个细节证明
    Scut游戏服务器免费开源框架快速开发(1)
    Scut游戏服务器免费开源框架快速开发(3)
    Scut游戏服务器免费开源框架快速开发(2)
    Struts中的 saveToken的方法
    CKEditor 3.6
    Oracle 笔记 day01
    Oracle日期格式问题
    Oracle 笔记 day03
  • 原文地址:https://www.cnblogs.com/benio/p/2524728.html
Copyright © 2011-2022 走看看