Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0048416
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajoralways2022-01-18 13:052022-03-21 07:35
ReporterivazquezView Statuspublic 
Assigned Toranjith_qualiantech_com 
PrioritynormalResolutionfixedFixed in VersionRR22Q2
StatusclosedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Merge Request Statusapproved
Review Assigned To
OBNetwork customerOBPS
Support ticket36939
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0048416: POS - Data inconsistency when making a verified return of a product with attributes

DescriptionExplanatory video: https://watch.screencastify.com/v/Y5mwXtFUJtxjObmRh5eN [^]

Reproduced in livebuilds 21Q4.3
Steps To Reproduce1.- Preference "Web POS Enable support for product attributes" with value = 'N'
2.- Create a Attribute Set of the type "Expiration Date" with "Require At Least One Value" although the problem also occurs with attribute sets of type "Lot" or "Serial No".
3.- Add the attribute to a product without stock and create two Stocks, one with 1 unit and the other with 20 units.
4.- Exit the Backoffice and enter Web POS
5.- We make a sale of the product
6.- We make a return
7.- Back to Backoffice
8.- We look for the product again and go to the "Stock" tab.

We see that the "Attribute Set Value" is empty when the use of attributes is mandatory for this product.
If we go to the transactions we observe that in the sale the "Attribute Set Value" was consumed, but in the return the unit is returned with an empty attribute.
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]

-  Notes
(0134364)
eugeni (viewer)
2022-01-18 14:11

 Proposed solution:
- As RFC flow in the BO does, verified return in POS should use the same m_attributesetinstance_id consumed by the shipment line of the original receipt line (SO).
- In the rare situation where same sales order line has several shipment lines allocated (same product with different attribute set instances) and the verified return is a partial return, take one of the attribute set instances of the original shipment lines with a reasonable criteria: first shipment line no found or similar
(0134704)
hgbot (developer)
2022-02-01 11:59

 Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal/-/merge_requests/703 [^]
(0134802)
hgbot (developer)
2022-02-07 07:53

 Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal [^]
Changeset: e5da161f8a001754f5a3afb631390f8b8a9557ee
Author: Ranjith S R <ranjith@qualiantech.com>
Date: 07-02-2022 06:53:11
URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal/-/commit/e5da161f8a001754f5a3afb631390f8b8a9557ee [^]

Fixed ISSUE-48416: Shipment Attributes should be used to create Verfied Return transactions
* When doing verified returns, if orderline doesn't have attribute value
  and shipmentline has attribute value,
  then return shipmentline should be created with original shipmentline's attribute value

---
M src/org/openbravo/retail/posterminal/utility/ShipmentUtils.java
---
(0134803)
hgbot (developer)
2022-02-07 07:53

 Merge request merged: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal/-/merge_requests/703 [^]
(0134838)
ivazquez (viewer)
2022-02-08 17:16
edited on: 2022-02-08 17:16

 The client reports that there is still data inconsistency in the verified product returns with attribute set.
The test when the original order line has been converted to a single packing slip line with attribute value is OK. That is, when making a verified return of that order, total or partial, the return packing slip takes the attribute value correctly according to what the original packing slip had.
However, when the original order line has been converted to two or more delivery note lines, the verified return still generates a return delivery note with attribute value = empty.

Steps to reproduce:
1) In BO, via physical inventory enter two lines of the same product, one with quantity = 2 and attribute_value1 and one with quantity = 2 attribute_value2 (different lots or expiration or any other attribute).
2) Login in POS: make a ticket of 4 units -> Verify that a delivery note is generated with two lines, each one with 2 UN and the above attribute values.
3) From the POS, make a verified return of the previous ticket, for the total or partial quantity. Verify that the return receipt (or the packing slip depending on the configuration) generated in the BO has the two lines but with attribute value = empty -> KO
(0134857)
hgbot (developer)
2022-02-10 08:09

 Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal/-/merge_requests/711 [^]
(0135108)
hgbot (developer)
2022-02-18 08:02

 Merge request merged: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal/-/merge_requests/711 [^]
(0135109)
hgbot (developer)
2022-02-18 08:02

 Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal [^]
Changeset: 14cb6e5559abdd218a2a7ff0ab991b6a8c930cc1
Author: Ranjith S R <ranjith@qualiantech.com>
Date: 18-02-2022 07:02:12
URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal/-/commit/14cb6e5559abdd218a2a7ff0ab991b6a8c930cc1 [^]

Fixed ISSUE-48416: Shipment Attributes should be used to create Verified Return transactions
* When receipt line has multiple shipment lines, then
  original shipment line's attribute value must to used to generate return shipment line

---
M src/org/openbravo/retail/posterminal/utility/ShipmentUtils.java
---
(0135199)
ivazquez (viewer)
2022-02-21 19:56

 The customer informs us that the problem is still occurring:

When making a verified return of N units corresponding to more than one source delivery note line (with different attribute value) the customer return is correct with N units, but the return delivery note is always with "-1" UN, which is inconsistent with the quantity actually returned by the customer.
(0135588)
ivazquez (viewer)
2022-03-09 12:53

 Video demonstrating the steps to reproduce the error:

https://watch.screencastify.com/v/GE7I6TOBfKsl48bhxrnE [^]

Note that it works correctly in a verified return wherein the original delivery note the product only has one attribute value

The test when the original order line has been converted to a single packing slip line with attribute value is OK. That is when making a verified return of that order, total or partial, the return delivery note takes the attribute value correctly according to the one that the original delivery note had.

However, when the original order line has been converted to two or more packing slip lines, the verified return will generate a return packing slip with incorrect quantities

Steps to reproduce:

1) In BO, using a physical inventory, create lines to enter two of the same product, one with quantity = 2 and value_attribute1 and another with quantity = 2 and value_attribute2 (different batches or expirations or any other attribute)

2) Login in POS: make a ticket of 4 units -> Verify that a delivery note is generated with two lines, each one with 2 UN and the previous attribute values

3) From the POS, make a verified return of the previous ticket, for the total or partial amount. Verify that the return receipt (or the delivery note depending on the configuration) generated in the BO has the two lines but with amounts different from those of the return order
(0135607)
ranjith_qualiantech_com (viewer)
2022-03-10 07:08

 Last mentioned note is not reproducible in livebuilds.
https://drive.google.com/file/d/1AjeMj44KuDKa7A0Q0uB3Rjvs0a8TndDV/view [^]

Steps followed
Backoffice
1) Created Product "48416_10Mar" with Attribute Set
2) Added Stock Qty 2 with Attribute Value ("20-03-2022") Sthrough Physical Inventory
3) Added Stock Qty 2 with Attribute Value ("30-03-2022") Sthrough Physical Inventory
4) Preference for "Web POS Enable support for product attributes" should be disabled
POS
1) Add Product "48416_10Mar" 4 times
2) Complete it
3) Check in Backoffice, Stock is consumed
4) Do verified return for above receipt with 3 Qty
5) Check in Backoffice, Stock updated with 3 Qty
6) Do verified return for above receipt with remaining 1 Qty
5) Check in Backoffice, Stock updated with 1 Qty (Total 4 Qty)
(0135798)
hgbot (developer)
2022-03-17 13:08

 Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.returns/-/merge_requests/37 [^]
(0135872)
hgbot (developer)
2022-03-21 07:35

 Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.returns [^]
Changeset: 1305673f080364b1d9a6e6f38f63ffbe230d644f
Author: Ranjith S R <ranjith@qualiantech.com>
Date: 17-03-2022 17:36:31
URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.returns/-/commit/1305673f080364b1d9a6e6f38f63ffbe230d644f [^]

Fixed ISSUE-48416: Remaining Qty should not be updated when doing verified returns
* If new state actions is not enabled, then Remaining Qty should not be updated
  when doing verified returns.

---
M web/org.openbravo.retail.returns/js/modalReturnLines.js
---
(0135873)
hgbot (developer)
2022-03-21 07:35

 Merge request merged: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.returns/-/merge_requests/37 [^]

- Issue History
Date Modified Username Field Change
2022-01-18 13:05 ivazquez New Issue
2022-01-18 13:05 ivazquez Assigned To => Retail
2022-01-18 13:05 ivazquez OBNetwork customer => OBPS
2022-01-18 13:05 ivazquez Support ticket => 36939
2022-01-18 13:05 ivazquez Triggers an Emergency Pack => No
2022-01-18 13:56 eugeni Issue Monitored: eugeni
2022-01-18 14:11 eugeni Note Added: 0134364
2022-01-25 14:00 ranjith_qualiantech_com Assigned To Retail => ranjith_qualiantech_com
2022-01-31 10:16 ranjith_qualiantech_com Status new => scheduled
2022-02-01 11:59 hgbot Merge Request Status => open
2022-02-01 11:59 hgbot Note Added: 0134704
2022-02-07 07:53 hgbot Merge Request Status open => approved
2022-02-07 07:53 hgbot Resolution open => fixed
2022-02-07 07:53 hgbot Status scheduled => closed
2022-02-07 07:53 hgbot Fixed in Version => RR22Q2
2022-02-07 07:53 hgbot Note Added: 0134802
2022-02-07 07:53 hgbot Note Added: 0134803
2022-02-08 17:16 ivazquez Note Added: 0134838
2022-02-08 17:16 ivazquez Note Edited: 0134838 View Revisions
2022-02-08 17:17 ivazquez Status closed => new
2022-02-08 17:17 ivazquez Resolution fixed => open
2022-02-09 11:21 ranjith_qualiantech_com Status new => scheduled
2022-02-10 08:09 hgbot Note Added: 0134857
2022-02-18 08:02 hgbot Resolution open => fixed
2022-02-18 08:02 hgbot Status scheduled => closed
2022-02-18 08:02 hgbot Note Added: 0135108
2022-02-18 08:02 hgbot Note Added: 0135109
2022-02-21 19:56 ivazquez Note Added: 0135199
2022-02-21 19:57 ivazquez Status closed => new
2022-02-21 19:57 ivazquez Resolution fixed => open
2022-03-09 12:53 ivazquez Note Added: 0135588
2022-03-10 07:08 ranjith_qualiantech_com Note Added: 0135607
2022-03-17 06:52 ranjith_qualiantech_com Status new => scheduled
2022-03-17 13:08 hgbot Note Added: 0135798
2022-03-21 07:35 hgbot Resolution open => fixed
2022-03-21 07:35 hgbot Status scheduled => closed
2022-03-21 07:35 hgbot Note Added: 0135872
2022-03-21 07:35 hgbot Note Added: 0135873

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker