STORY #11144 产品库管理--包裹重算法调整 - 技术中心-需求池

业务需求

需求描述

一、背景和价值
1.背景：目前由于包裹重出现比毛重大或者少的情况，导致刊登上架产品时，价格计算错误，导致定价过高无人购买，定价过低亏本出货，导致整天的利润率整体偏低（忽高忽低）。
2.价值说明：刊登调用的重量更加平均，提高出单的率同时，把整体的利润率提升5%以上

3.价值量：利润率提升5%以上。

4.真实的数据分析结果如下

K=1.5 , 异常核查数= 3885条，异常率=3885/7111 =54.6%
K=2 , 异常核查数= 3270条，异常率=3270/7111 =45.9%
K=2.5 , 异常核查数= 2931条，异常率=2931/7111 =41%---------建议这个就可以了,K值可以配置,方便后面调整
K=3 , 异常核查数= 2590条，异常率=2590/7111 =36.4%

二、需求描述：

1.必须是【客户订单】+【单品单件】包裹称重完成后，运费计算服务执行时，算法如下

①总公式：产品包裹重=称重值相加 / N次称重

A.若SKU称重次数 ≤ 3 次，则加权后的包裹重= 包裹A+B+C / SKU称重次数（小于等于3次称重数据的，不需要使用四分位算法）

B.若4次 ≤ SKU称重次数 ≤ 15次（近15次，超过15也取15次），则加权后包裹重=包裹A+B+C .... / SKU称重次数 , 必须使用【四分位算法】K值默认取2.5（可进行修改参数），该算法自动选出异常的包裹值进行排除，正常包裹重值才进行加权计算，然后累加后除以 N次称重

③若同一个包裹号有打回称重或重复称重时，会产生重复的的称重数据，只取最新更新的一条数据纳入计算。（可考虑去重复或者直接替换更新的方式处理）

④最终的计算结果保留整数。

⑤增量加权计算服务，每天执行一次且有包裹重量更新的产品才增加到产品库中。（晚上凌晨2~5点之间执行即可）

2.测试案例的场景说明（禅道需求中含大量的测试案例）

①若2个包裹重 D01-20g,D02-30g 则结果= 20+30 / 2= 25g

②若3个包裹重同上

③若4个及以上包裹重 D01-172g,D02-182,D03-184g,D04-184g,D05-184g 则因为称重次数超过4次，故使用四分位算法后，正常包裹重182,184,184,184，异常包裹重：172，则结果=182+184+184+184 /4=184 (实际的结果为183.5，保留整数)

注：http://10.158.158.22:8080/wgtest.aspx 四分位算法测试工具，附件有大量的测试案例

3. 特殊要求：

①开发组长必须要构建好如何观察异常数据的机制和出了问题后如何恢复或者修改正确的数据，才更新到产品库。

②开发人员必须要自测并且附带截图，否则测试人员可以拒绝测试。

4.详细执行流程如下图

验收标准

特殊癖好：开发人员要做好自测，必须要有截图自测，否则测试可以拒绝。

测试人员做好监督，上线后不允许出现异常，否则要请我和开发组长喝饮料。

价值描述

2.价值说明：刊登调用的重量更加平均，提高出单的率同时，把整体的利润率提升5%以上 3.价值量：利润率提升5%以上。

附件

历史记录

2022-04-02 14:56:02, 由 李源肇 创建。
2022-04-06 18:49:57, 由刘灿记录评审结果，结果为 确认通过。
修改了 评审时间，旧值为 "0000-00-00"，新值为 "2022-04-06"。
修改了 指派给 ，旧值为 "Admin186"，新值为 "liyuanzhao"。
修改了 当前状态，旧值为 "draft"，新值为 "active"。
修改了 由谁评审，旧值为 ""，新值为 "Admin186"。
2022-04-07 15:13:24, 由 李源肇 变更。
修改了 指派给 ，旧值为 "liyuanzhao"，新值为 "Admin186"。
修改了 当前状态，旧值为 "active"，新值为 "changed"。
修改了 版本号 ，旧值为 "1"，新值为 "2"。
修改了 由谁评审，旧值为 "Admin186"，新值为 ""。
修改了 评审时间，旧值为 "2022-04-06"，新值为 "0000-00-00"。
修改了 需求描述，区别为：
002- ~~4.数据分析结果如下：~~
002+ 4.真实的数据分析结果如下
003- K=1.5 , 异常核查数= 3885条，异常率=3885/7111 =54.6% K=2 , 异常核查数= 3270条，异常率=3270/7111 =45.9% K=2.5 , 异常核查数= 2931条，异常率=2931/7111 =41% K=3 , 异常核查数= 2590条，异常率=2590/7111 =36.4%---------建议这个就可以了,K值可以配置
003+ K=1.5 , 异常核查数= 3885条，异常率=3885/7111 =54.6% K=2 , 异常核查数= 3270条，异常率=3270/7111 =45.9% K=2.5 , 异常核查数= 2931条，异常率=2931/7111 =41%---------建议这个就可以了,K值可以配置,方便后面调整 K=3 , 异常核查数= 2590条，异常率=2590/7111 =36.4%
004- 二、需求描述： 1.当客户订单包裹称重完成后，运费计算服务执行时，，算法如下： ①公式：产品包裹重=称重值相加 / N次 (N的数据为正常数值的包裹总数），则计算后产品包裹重写入到产品库中进行更新/替换 ②若SKU发货次数 ≤ 3 次，则产品包裹重=称重值相加 / N条数 ③若4次 ≤ SKU发货次数 ≤ 15次，使用【四分位算法】K值默认取3（可进行修改参数），自动选出异常的包裹值进行排查，正常的值才进行加权计算，然后累加后/N次。注：http://10.158.158.22:8080/wgtest.aspx 测试工具 2.增量加权计算服务，每天执行一次且有包裹重量更新的产品才增加到产品库中。（晚上凌晨2~5点之间执行即可） 3.详细执行流程如下图
004+
005-
005+ 二、需求描述： 1.必须是【客户订单】+【单品单件】包裹称重完成后，运费计算服务执行时，算法如下
006+ ①总公式：产品包裹重=称重值相加 / N次称重
007+ A.若SKU称重次数 ≤ 3 次，则加权后的包裹重= 包裹A+B+C /SKU称重次数（小于等于3次称重数据的，不需要使用四分位算法）
008+ B.若4次 ≤ SKU称重次数 ≤ 15次（近15次，超过15也取15次），则加权后包裹重=包裹A+B+C .... /SKU称重次数 , 必须使用【四分位算法】K值默认取2.5（可进行修改参数），该算法自动选出异常的包裹值进行排除，正常包裹重值才进行加权计算，然后累加后除以N次称重
009+ ③若同一个包裹号有打回称重或重复称重时，会产生重复的的称重数据，只取最新更新的一条数据纳入计算。（可考虑去重复或者直接替换更新的方式处理）
010+ ④最终的计算结果保留整数。
011+ ⑤增量加权计算服务，每天执行一次且有包裹重量更新的产品才增加到产品库中。（晚上凌晨2~5点之间执行即可）
012+
013+ 2.测试案例的场景说明（禅道需求中含大量的测试案例）
014+ ①若2个包裹重 D01-20g,D02-30g 则结果=20+30 / 2= 25g
015+ ②若3个包裹重同上
016+ ③若4个及以上包裹重 D01-172g,D02-182,D03-184g,D04-184g,D05-184g 则因为称重次数超过4次，故使用四分位算法后，正常包裹重182,184,184,184，异常包裹重：172，则结果=182+184+184+184 /4=184 (实际的结果为183.5，保留整数)
017+ 注：http://10.158.158.22:8080/wgtest.aspx 四分位算法测试工具，附件有大量的测试案例
018+
019+ 3. 特殊要求：
020+ ①开发组长必须要构建好如何观察异常数据的机制和出了问题后如何恢复或者修改正确的数据，才更新到产品库。
021+ ②开发人员必须要自测并且附带截图，否则测试人员可以拒绝测试。
022+
023+ 4.详细执行流程如下图
024+

002- ~~ 4.数据分析结果如下：~~
002+ 4.真实的数据分析结果如下
003- K=1.5 , 异常核查数= 3885条，异常率=3885/7111 =54.6% K=2 , 异常核查数= 3270条，异常率=3270/7111 =45.9% K=2.5 , 异常核查数= 2931条，异常率=2931/7111 =41% K=3 , 异常核查数= 2590条，异常率=2590/7111 =36.4%---------建议这个就可以了,K值可以配置 
003+ K=1.5 , 异常核查数= 3885条，异常率=3885/7111 =54.6% K=2 , 异常核查数= 3270条，异常率=3270/7111 =45.9% K=2.5 , 异常核查数= 2931条，异常率=2931/7111 =41%---------建议这个就可以了,K值可以配置,方便后面调整 K=3 , 异常核查数= 2590条，异常率=2590/7111 =36.4% 
004- 二、需求描述： 1.当客户订单包裹称重完成后，运费计算服务执行时，，算法如下： ①公式：产品包裹重=称重值相加 / N次 (N的数据为正常数值的包裹总数），则计算后产品包裹重写入到产品库中进行更新/替换 ②若SKU发货次数 ≤ 3 次，则产品包裹重=称重值相加 / N条数 ③若4次 ≤ SKU发货次数 ≤ 15次，使用【四分位算法】K值默认取3（可进行修改参数），自动选出异常的包裹值进行排查，正常的值才进行加权计算，然后累加后/N次。 注：http://10.158.158.22:8080/wgtest.aspx 测试工具 2.增量加权计算服务，每天执行一次且有包裹重量更新的产品才增加到产品库中。（晚上凌晨2~5点之间执行即可） 3.详细执行流程如下图
004+ 
005- ~~<img src="{193375.png}" alt="" /><img src="{193376.png}" alt="" />~~
005+ 二、需求描述： 1.必须是【客户订单】+【单品单件】包裹称重完成后，运费计算服务执行时，算法如下
006+ ①总公式：产品包裹重=称重值相加 / N次称重
007+ A.若SKU称重次数 ≤ 3 次，则加权后的包裹重= 包裹A+B+C /SKU称重次数（小于等于3次称重数据的，不需要使用四分位算法）
008+ B.若4次 ≤ SKU称重次数 ≤ 15次（近15次，超过15也取15次），则加权后包裹重=包裹A+B+C .... /SKU称重次数 , 必须使用【四分位算法】K值默认取2.5（可进行修改参数），该算法自动选出异常的包裹值进行排除，正常包裹重值才进行加权计算，然后累加后除以N次称重 
009+ ③若同一个包裹号有打回称重或重复称重时，会产生重复的的称重数据，只取最新更新的一条数据纳入计算。（可考虑去重复或者直接替换更新的方式处理）
010+ ④最终的计算结果保留整数。
011+ ⑤增量加权计算服务，每天执行一次且有包裹重量更新的产品才增加到产品库中。（晚上凌晨2~5点之间执行即可）
012+ 
013+ 2.测试案例的场景说明（禅道需求中含大量的测试案例） 
014+ ①若2个包裹重 D01-20g,D02-30g 则结果=20+30 / 2= 25g
015+ ②若3个包裹重同上
016+ ③若4个及以上包裹重 D01-172g,D02-182,D03-184g,D04-184g,D05-184g 则因为称重次数超过4次，故使用四分位算法后，正常包裹重182,184,184,184，异常包裹重：172，则结果=182+184+184+184 /4=184 (实际的结果为183.5，保留整数)
017+ 注：http://10.158.158.22:8080/wgtest.aspx 四分位算法测试工具，附件有大量的测试案例
018+ 
019+ 3. 特殊要求：
020+ ①开发组长必须要构建好如何观察异常数据的机制和出了问题后如何恢复或者修改正确的数据，才更新到产品库。
021+ ②开发人员必须要自测并且附带截图，否则测试人员可以拒绝测试。
022+ 
023+ 4.详细执行流程如下图
024+ <img src="{193375.png}" alt="" /><img src="{193376.png}" alt="" />
修改了 验收标准，区别为：
001-
001+ 特殊癖好：开发人员要做好自测，必须要有截图自测，否则测试可以拒绝。
002+ 测试人员做好监督，上线后不允许出现异常，否则要请我和开发组长喝饮料。

001-
001+ 特殊癖好：开发人员要做好自测，必须要有截图自测，否则测试可以拒绝。
002+ 测试人员做好监督，上线后不允许出现异常，否则要请我和开发组长喝饮料。

上传了附件 158包裹异常值测试记录.xlsx
2022-04-07 16:54:09, 由 zhengqiao 关联到迭代 【智汇】产品部 4月第2 版本（2022年） 。
2022-04-07 18:06:18, 由刘灿记录评审结果，结果为 确认通过。
修改了 评审时间，旧值为 "0000-00-00"，新值为 "2022-04-07"。
修改了 指派给 ，旧值为 "Admin186"，新值为 "liyuanzhao"。
修改了 当前状态，旧值为 "changed"，新值为 "active"。
修改了 由谁评审，旧值为 ""，新值为 "Admin186"。
2022-04-08 09:45:02, 由 林鸿贵 添加备注。

测试问题点：

1、之前发现的服务延迟的问题

即包裹称重后未进入到服务队列，操作了称重打回又继续称重
2022-04-11 11:30:33, 由 李源肇 变更。
修改了 指派给 ，旧值为 "liyuanzhao"，新值为 "Admin186"。
修改了 当前状态，旧值为 "active"，新值为 "changed"。
修改了 版本号 ，旧值为 "2"，新值为 "3"。
修改了 由谁评审，旧值为 "Admin186"，新值为 ""。
修改了 评审时间，旧值为 "2022-04-07"，新值为 "0000-00-00"。
修改了 需求描述，区别为：
003- K=1.5 , 异常核查数= 3885条，异常率=3885/7111 =54.6% K=2 , 异常核查数= 3270条，异常率=3270/7111 =45.9% K=2.5 , 异常核查数= 2931条，异常率=2931/7111 =41%---------建议这个就可以了,K值可以配置,方便后面调整 K=3 , 异常核查数= 2590条，异常率=2590/7111 =36.4%
003+ K=1.5 , 异常核查数= 3885条，异常率=3885/7111 =54.6% K=2 , 异常核查数= 3270条，异常率=3270/7111 =45.9%---------建议这个就可以了,K值可以配置,方便后面调整 K=2.5 , 异常核查数= 2931条，异常率=2931/7111 =41% K=3 , 异常核查数= 2590条，异常率=2590/7111 =36.4%
010- ~~④最终的计算结果保留整数。~~
010+ ④增量加权计算服务，每天执行一次且有包裹重量更新的产品才增加到产品库中。（晚上凌晨2~5点之间执行即可）
011- ~~⑤增量加权计算服务，每天执行一次且有包裹重量更新的产品才增加到产品库中。（晚上凌晨2~5点之间执行即可）~~
011+ ⑤最终的计算结果保留整数，且加权后插入产品的日志类型需修改为“称重日志”。
012-
012+
013- ~~2.测试案例的场景说明（禅道需求中含大量的测试案例）~~
013+
014- ~~①若2个包裹重 D01-20g,D02-30g 则结果=20+30 / 2= 25g~~
014+ 2.测试案例的场景说明（禅道需求中含大量的测试案例）
015- ~~②若3个包裹重同上~~
015+ ①若2个包裹重 D01-20g,D02-30g 则结果=20+30 / 2= 25g
016- ③若4个及以上包裹重 D01-172g,D02-182,D03-184g,D04-184g,D05-184g 则因为称重次数超过4次，故使用四分位算法后，正常包裹重182,184,184,184，异常包裹重：172，则结果=182+184+184+184 /4=184 (实际的结果为183.5，保留整数)
016+ ②若3个包裹重同上
017- ~~注：http://10.158.158.22:8080/wgtest.aspx 四分位算法测试工具，附件有大量的测试案例~~
017+ ③若4个及以上包裹重 D01-172g,D02-182,D03-184g,D04-184g,D05-184g 则因为称重次数超过4次，故使用四分位算法后，正常包裹重182,184,184,184，异常包裹重：172，则结果=182+184+184+184 /4=184 (实际的结果为183.5，保留整数)
018-
018+ 注：http://10.158.158.22:8080/wgtest.aspx 四分位算法测试工具，附件有大量的测试案例
019- ~~3. 特殊要求：~~
019+
020- ~~①开发组长必须要构建好如何观察异常数据的机制和出了问题后如何恢复或者修改正确的数据，才更新到产品库。~~
020+
021- ~~②开发人员必须要自测并且附带截图，否则测试人员可以拒绝测试。~~
021+ 3. 特殊要求：
022-
022+ ①开发组长必须要构建好如何观察异常数据的机制和出了问题后如何恢复或者修改正确的数据，才更新到产品库。
023- ~~4.详细执行流程如下图~~
023+ ②开发人员必须要自测并且附带截图，否则测试人员可以拒绝测试。
024-
024+
025+ 4.详细执行流程如下图
026+
027+

003- K=1.5 , 异常核查数= 3885条，异常率=3885/7111 =54.6% K=2 , 异常核查数= 3270条，异常率=3270/7111 =45.9% K=2.5 , 异常核查数= 2931条，异常率=2931/7111 =41%---------建议这个就可以了,K值可以配置,方便后面调整 K=3 , 异常核查数= 2590条，异常率=2590/7111 =36.4% 
003+ K=1.5 , 异常核查数= 3885条，异常率=3885/7111 =54.6% K=2 , 异常核查数= 3270条，异常率=3270/7111 =45.9%---------建议这个就可以了,K值可以配置,方便后面调整 K=2.5 , 异常核查数= 2931条，异常率=2931/7111 =41% K=3 , 异常核查数= 2590条，异常率=2590/7111 =36.4% 
010- ~~ ④最终的计算结果保留整数。~~
010+ ④增量加权计算服务，每天执行一次且有包裹重量更新的产品才增加到产品库中。（晚上凌晨2~5点之间执行即可）
011- ⑤增量加权计算服务，每天执行一次且有包裹重量更新的产品才增加到产品库中。（晚上凌晨2~5点之间执行即可）
011+ ⑤最终的计算结果保留整数，且加权后插入产品的日志类型需修改为“称重日志”。 
012- ~~ ~~
012+ <img src="{194158.png}" alt="" /> 
013- 2.测试案例的场景说明（禅道需求中含大量的测试案例） 
013+ 
014- ①若2个包裹重 D01-20g,D02-30g 则结果=20+30 / 2= 25g
014+ 2.测试案例的场景说明（禅道需求中含大量的测试案例） 
015- ~~ ②若3个包裹重同上~~
015+ ①若2个包裹重 D01-20g,D02-30g 则结果=20+30 / 2= 25g
016- ③若4个及以上包裹重 D01-172g,D02-182,D03-184g,D04-184g,D05-184g 则因为称重次数超过4次，故使用四分位算法后，正常包裹重182,184,184,184，异常包裹重：172，则结果=182+184+184+184 /4=184 (实际的结果为183.5，保留整数)
016+ ②若3个包裹重同上
017- 注：http://10.158.158.22:8080/wgtest.aspx 四分位算法测试工具，附件有大量的测试案例
017+ ③若4个及以上包裹重 D01-172g,D02-182,D03-184g,D04-184g,D05-184g 则因为称重次数超过4次，故使用四分位算法后，正常包裹重182,184,184,184，异常包裹重：172，则结果=182+184+184+184 /4=184 (实际的结果为183.5，保留整数)
018- ~~~~
018+ 注：http://10.158.158.22:8080/wgtest.aspx 四分位算法测试工具，附件有大量的测试案例
019- ~~ 3. 特殊要求：~~
019+ 
020- ①开发组长必须要构建好如何观察异常数据的机制和出了问题后如何恢复或者修改正确的数据，才更新到产品库。
020+ 
021- ~~ ②开发人员必须要自测并且附带截图，否则测试人员可以拒绝测试。~~
021+ 3. 特殊要求：
022- ~~ ~~
022+ ①开发组长必须要构建好如何观察异常数据的机制和出了问题后如何恢复或者修改正确的数据，才更新到产品库。
023- ~~ 4.详细执行流程如下图~~
023+ ②开发人员必须要自测并且附带截图，否则测试人员可以拒绝测试。
024- ~~<img src="{193375.png}" alt="" /><img src="{193376.png}" alt="" />~~
024+ 
025+ 4.详细执行流程如下图
026+ <img src="{193375.png}" alt="" /><img src="{193376.png}" alt="" />
027+ <img src="{194156.png}" alt="" />
2022-04-11 19:35:16, 由 李源肇 变更。
修改了 版本号 ，旧值为 "3"，新值为 "4"。
修改了 需求描述，区别为：
008- B.若4次 ≤ SKU称重次数 ≤ 15次（近15次，超过15也取15次），则加权后包裹重=包裹A+B+C .... /SKU称重次数 , 必须使用【四分位算法】K值默认取2.5（可进行修改参数），该算法自动选出异常的包裹值进行排除，正常包裹重值才进行加权计算，然后累加后除以N次称重
008+ B.若4次 ≤ SKU称重次数 ≤ 15次（近15次，超过15也取15次），则加权后包裹重=包裹A+B+C .... /SKU称重次数 , 必须使用【四分位算法】K值默认取2（可进行修改参数），该算法自动选出异常的包裹值进行排除，正常包裹重值才进行加权计算，然后累加后除以N次称重
020-
020+ 3. 产品库-》基础信息，包裹重字段的问号提示语修改如下
021- ~~3. 特殊要求：~~
021+ ①公式：产品包裹重=称重值相加 / N次称重 ②若SKU发货次数 ≤ 3 次，则产品包裹重=称重值相加 / 条数 ③若4次 ≤ SKU称重次数 ≤ 15次（近15次，超过15也取15次），则加权后包裹重=包裹A+B+C .... / SKU称重次数 ,则用异常包裹排除算法。 ④案例说明（异常包裹排除法） A.若2个包裹重 D01-20g,D02-30g 则结果= 20+30 / 2= 25g B.若3个包裹重同上 C.若4个及以上包裹重 D01-172g,D02-182,D03-184g,D04-184g,D05-184g 则算法执行后得出，正常包裹重182,184,184,184，异常包裹重：172，则包裹重=182+184+184+184 /4=184 (结果为183.5，保留整数).
022- ~~①开发组长必须要构建好如何观察异常数据的机制和出了问题后如何恢复或者修改正确的数据，才更新到产品库。~~
022+
023- ~~②开发人员必须要自测并且附带截图，否则测试人员可以拒绝测试。~~
023+ 4. 特殊要求：
024-
024+ ①开发组长必须要构建好如何观察异常数据的机制和出了问题后如何恢复或者修改正确的数据，才更新到产品库。
025- ~~4.详细执行流程如下图~~
025+ ②开发人员必须要自测并且附带截图，否则测试人员可以拒绝测试。
026-
026+
027-
027+ 5.详细执行流程如下图
028+
029+

008- B.若4次 ≤ SKU称重次数 ≤ 15次（近15次，超过15也取15次），则加权后包裹重=包裹A+B+C .... /SKU称重次数 , 必须使用【四分位算法】K值默认取2.5（可进行修改参数），该算法自动选出异常的包裹值进行排除，正常包裹重值才进行加权计算，然后累加后除以N次称重 
008+ B.若4次 ≤ SKU称重次数 ≤ 15次（近15次，超过15也取15次），则加权后包裹重=包裹A+B+C .... /SKU称重次数 , 必须使用【四分位算法】K值默认取2（可进行修改参数），该算法自动选出异常的包裹值进行排除，正常包裹重值才进行加权计算，然后累加后除以N次称重 
020- ~~~~
020+ 3. 产品库-》基础信息，包裹重字段的问号提示语修改如下
021- ~~ 3. 特殊要求：~~
021+ ①公式：产品包裹重=称重值相加 / N次称重 ②若SKU发货次数 ≤ 3 次，则产品包裹重=称重值相加 / 条数 ③若4次 ≤ SKU称重次数 ≤ 15次（近15次，超过15也取15次），则加权后包裹重=包裹A+B+C .... / SKU称重次数 ,则用异常包裹排除算法。 ④案例说明（异常包裹排除法） A.若2个包裹重 D01-20g,D02-30g 则结果= 20+30 / 2= 25g B.若3个包裹重同上 C.若4个及以上包裹重 D01-172g,D02-182,D03-184g,D04-184g,D05-184g 则算法执行后得出，正常包裹重182,184,184,184，异常包裹重：172，则包裹重=182+184+184+184 /4=184 (结果为183.5，保留整数).
022- ①开发组长必须要构建好如何观察异常数据的机制和出了问题后如何恢复或者修改正确的数据，才更新到产品库。
022+ 
023- ~~ ②开发人员必须要自测并且附带截图，否则测试人员可以拒绝测试。~~
023+ 4. 特殊要求：
024- ~~ ~~
024+ ①开发组长必须要构建好如何观察异常数据的机制和出了问题后如何恢复或者修改正确的数据，才更新到产品库。
025- ~~ 4.详细执行流程如下图~~
025+ ②开发人员必须要自测并且附带截图，否则测试人员可以拒绝测试。
026- ~~<img src="{193375.png}" alt="" /><img src="{193376.png}" alt="" />~~
026+ 
027- ~~<img src="{194156.png}" alt="" />~~
027+ 5.详细执行流程如下图
028+ <img src="{193375.png}" alt="" /><img src="{193376.png}" alt="" />
029+ <img src="{194156.png}" alt="" />
2022-04-11 21:00:10, 由刘灿记录评审结果，结果为 确认通过。
修改了 评审时间，旧值为 "0000-00-00"，新值为 "2022-04-11"。
修改了 指派给 ，旧值为 "Admin186"，新值为 "liyuanzhao"。
修改了 当前状态，旧值为 "changed"，新值为 "active"。
修改了 由谁评审，旧值为 ""，新值为 "Admin186"。
2022-04-29 11:12:43, 由 zhengqiao 编辑。
修改了 所处阶段 ，旧值为 "tested"，新值为 "released"。
修改了 设置阶段者，旧值为 ""，新值为 "zhengqiao"。
2022-05-04 10:30:01, 由 zhengqiao 编辑。
修改了 所处阶段，旧值为 "released"，新值为 "closed"。
2022-06-10 09:34:39, 由 liangfengming 编辑。
修改了 受益业务部门，旧值为 ""，新值为 "开发采购部"。
2022-09-26 14:02:20, 由 zhengqiao 关闭，原因为 已完成 。
修改了 由谁关闭，旧值为 ""，新值为 "zhengqiao"。
修改了 关闭日期，旧值为 "0000-00-00 00:00:00"，新值为 "2022-09-26 14:02:19"。
修改了 指派给 ，旧值为 "liyuanzhao"，新值为 "closed"。
修改了 当前状态，旧值为 "active"，新值为 "closed"。
修改了 关闭原因，旧值为 ""，新值为 "done"。
2023-03-04 15:25:53, 由周杰编辑。
修改了 所属模块，旧值为 "1683"，新值为 "1810"。

基本信息
需求的一生

迭代版本
提报业务部门
提报人员	张镇权
需求来源	业务方迭代需求
所属项目	技术中心-需求池
所属模块	供应链产品采购产品库
所属计划
业务价值
开发组
受益业务部门
验收人员
业务目标类型
中心业务目标
业务价值	提高收入
每月价值量	利润率提升5%以上
每月节省人数	0
优先级	P2
价值类型
预计工时	24
成本
ROI
操作手册
高价值
主被动
复杂度
工作流ID
工作流创建时间
更新点
是否高危	否
评分
当前状态	已关闭
所处阶段	已关闭
关键词
评审次数
计划上线
上线时间
计划验收时间
业务验收时间
满意度
价值验收
满意度分值
业务回填价值
验收达成价值
验收达成ROI
抄送给

由谁创建	李源肇于 2022-04-02 14:56:01
指派给	Closed 于 2022-09-26 14:02:19
由谁评审	刘灿
评审时间	2022-04-11
由谁关闭	zhengqiao 于 2022-09-26 14:02:19
关闭原因	已完成
最后修改	周杰于 2023-03-04 15:25:49

迭代任务
相关信息

相关Bug	[B] #29091 产品库问号提示文案与需求描述不一致以及日志调整 [B] #29097 共享库CustomerAppSetting.AppType = 17类型冲突，需调整
相关用例
相关需求
细分需求