Openbravo Issue Tracking System - Retail Modules
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0050304Retail ModulesCash uppublic2022-09-21 16:472022-09-27 12:54
Reporteraxelmercado 
Assigned ToRetail 
PriorityhighSeveritymajorReproducibilityalways
StatusscheduledResolutionopen 
PlatformOS5OS Version
Product VersionRR22Q3 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0050304: Processing EWIs of type Order without following the order generates errors.
DescriptionWhen we process EWIs of type Order not following the order in which they were downloaded it causes the Cashup to be created with incorrect values and generates inconsistencies in the reconciliations of the financial accounts.
Steps To ReproduceIn order to reproduce the error, EWIs of type Order must be generated, in this case, we generate them by closing the current period.

Steps:
1 - In Web POS, generate a sale with the payment type Cash.
2 - In backoffice, close the current month period.
3 - In Web POS, generate two different sales with the Cash payment type.
4 - Verify in the backoffice that 2 EWIs have been generated with these orders.
5 - Reopen the period.
6 - Process the EWIs in the opposite order to that in which they were created, i.e. process the last error first.
7 - In the Web POS, when proceeding to perform the Cashup, we can verify that it contains the correct values, before completing it, proceed to perform a full-refresh to simulate the blocking of the terminal by the EWIs.
8 - After logging in again, we now proceed to perform the Cashup by withdrawing the total amount of money and verifying that the value has changed.
9 - Verify the financial account of type Cash of the terminal, in the Reconciliations tab select the last reconciliation corresponding to the Cashup, in the Cleared Items tab perform a function Sum of the columns 'Deposit Amount' and 'Withdrawal Amount', here we will be able to observe that the values are different, reason why the money that entered is different from the one that was withdrawn.

Video with the steps: https://drive.google.com/file/d/1rrqS4q4OtAeU8WICQ1h0mf-TXL-BxD7L/view?usp=sharing [^]
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2022-09-21 16:47axelmercadoNew Issue
2022-09-21 16:47axelmercadoAssigned To => Retail
2022-09-21 16:47axelmercadoTriggers an Emergency Pack => No
2022-09-21 17:32axelmercadoNote Added: 0141292
2022-09-21 17:32axelmercadoPriorityurgent => high
2022-09-21 17:32axelmercadoSeveritycritical => major
2022-09-27 12:16ranjith_qualiantech_comAssigned ToRetail => ranjith_qualiantech_com
2022-09-27 12:17ranjith_qualiantech_comStatusnew => scheduled
2022-09-27 12:53marvintmNote Added: 0141401
2022-09-27 12:53marvintmTypedefect => design defect
2022-09-27 12:54ranjith_qualiantech_comAssigned Toranjith_qualiantech_com => Retail

Notes
(0141292)
axelmercado   
2022-09-21 17:32   
The problem has been reviewed again and we have changed the priority because we believe that the problem is reproduced if the cache is cleared before performing a cashup, which would be strange behavior.
(0141401)
marvintm   
2022-09-27 12:53   
After internal discussion we have decided to change this to design defect. The problem only happens when the user clears the cache, in a situation in which the cashup has not yet been done.

Clearing the cache should not be done normally, and most definitely not when a cashup is still pending to be done in the terminal, so the actual chances that this will happen are very low.

At the same time, fixing this would force us to do some difficult to implement checks so that it is not possible to process an EWI for an order if there is a previous one there. Therefore, for now we prefer to consider this a design defect.