Openbravo Issue Tracking System - Retail Modules |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0048416 | Retail Modules | Web POS | public | 2022-01-18 13:05 | 2022-03-21 07:35 |
|
| Reporter | ivazquez | |
| Assigned To | ranjith_qualiantech_com | |
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | |
| Platform | | OS | 5 | OS Version | |
| Product Version | | |
| Target Version | | Fixed in Version | RR22Q2 | |
| Merge Request Status | approved |
| Review Assigned To | |
| OBNetwork customer | OBPS |
| Support ticket | 36939 |
| Regression level | |
| Regression date | |
| Regression introduced in release | |
| Regression introduced by commit | |
| Triggers an Emergency Pack | No |
|
| Summary | 0048416: POS - Data inconsistency when making a verified return of a product with attributes |
| Description | Explanatory video: https://watch.screencastify.com/v/Y5mwXtFUJtxjObmRh5eN [^]
Reproduced in livebuilds 21Q4.3
|
| Steps To Reproduce | 1.- 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. |
| Proposed Solution | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | |
| Attached Files | |
|
| 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 | bug_revision_view_page.php?bugnote_id=0134838#r23643 |
| 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 | |
|
Notes |
|
|
(0134364)
|
|
eugeni
|
|
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
|
|
2022-02-01 11:59
|
|
|
|
|
(0134802)
|
|
hgbot
|
|
2022-02-07 07:53
|
|
|
|
|
(0134803)
|
|
hgbot
|
|
2022-02-07 07:53
|
|
|
|
|
|
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
|
|
2022-02-10 08:09
|
|
|
|
|
(0135108)
|
|
hgbot
|
|
2022-02-18 08:02
|
|
|
|
|
(0135109)
|
|
hgbot
|
|
2022-02-18 08:02
|
|
|
|
|
|
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. |
|
|
|
|
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 |
|
|
|
|
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
|
|
2022-03-17 13:08
|
|
|
|
|
(0135872)
|
|
hgbot
|
|
2022-03-21 07:35
|
|
|
|
|
(0135873)
|
|
hgbot
|
|
2022-03-21 07:35
|
|
|