Openbravo Issue Tracking System - Retail Modules
View Issue Details
0035175Retail ModulesWeb POSpublic2017-02-07 08:072017-02-15 10:32
pradeepvarma 
Retail 
highmajoralways
newopen 
5
 
 
No
0035175: Loss of ticket number if ticket numbering is different from return numbering
Loss of ticket number if ticket numbering is different from return numbering :

Add prefix in the field "Return No Prefix" in the POS Terminal.

1 - Create a ticket with 1 product : number 01. Don't finalize the ticket
2 - Create a new ticket with 1 line : Number 02. Don't finalize the ticket
3 - Call back the ticket 01
4 - Delete the line . New number for the ticket is RT01 (return ticket). This is the
first problem.
5 - Add a new line in this ticket (01) the number is 03.
6 - Finalize the ticket 03
7 - Finalize the ticket 02

The ticket number 01 is lost.

After the step 5 :
6 - Create a new tikcet (all tickets are pending). The number is 03. Don't finalize
the ticket
7 - Create a new ticket, the number is also 03
8 - same than 7

We check in a standard version (16Q3 and 16Q4.2) without specific development and
it's the same.
Loss of ticket number if ticket numbering is different from return numbering :

Add prefix in the field "Return No Prefix" in the POS Terminal.

1 - Create a ticket with 1 product : number 01. Don't finalize the ticket
2 - Create a new ticket with 1 line : Number 02. Don't finalize the ticket
3 - Call back the ticket 01
4 - Delete the line . New number for the ticket is RT01 (return ticket). This is the
first problem.
5 - Add a new line in this ticket (01) the number is 03.
6 - Finalize the ticket 03
7 - Finalize the ticket 02

After the step 5 :
6 - Create a new tikcet (all tickets are pending). The number is 03. Don't finalize
the ticket
7 - Create a new ticket, the number is also 03
8 - same than 7

The ticket number 01 is lost.

We check in a standard version (16Q3 and 16Q4.2) without specific development and
it's the same.
No tags attached.
Issue History
2017-02-07 08:07pradeepvarmaNew Issue
2017-02-07 08:07pradeepvarmaAssigned To => Retail
2017-02-07 08:07pradeepvarmaTriggers an Emergency Pack => No
2017-02-07 10:44pradeepvarmaDescription Updatedbug_revision_view_page.php?rev_id=14506#r14506
2017-02-07 10:44pradeepvarmaSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=14508#r14508
2017-02-07 14:41egoitzResolution time => 1488236400
2017-02-13 11:06ranjith_qualiantech_comRelationship addedduplicate of 0035184
2017-02-13 11:13ranjith_qualiantech_comAssigned ToRetail => ranjith_qualiantech_com
2017-02-13 11:13ranjith_qualiantech_comStatusnew => scheduled
2017-02-13 11:31jorge-garciaStatusscheduled => resolved
2017-02-13 11:31jorge-garciaResolutionopen => fixed
2017-02-14 13:01marvintmNote Added: 0094310
2017-02-14 13:01marvintmStatusresolved => new
2017-02-14 13:01marvintmResolutionfixed => open
2017-02-14 15:53marvintmNote Added: 0094321
2017-02-14 15:53marvintmTypedefect => design defect
2017-02-14 16:07marvintmResolution time1488236400 =>
2017-02-15 10:31ranjith_qualiantech_comRelationship deleted0035184
2017-02-15 10:32ranjith_qualiantech_comAssigned Toranjith_qualiantech_com => Retail

Notes
(0094310)
marvintm   
2017-02-14 13:01   
The reported problem is different from issue 35184. Issue 35184 refers to empty tickets, but in this case, tickets have lines, and it's possible to generate a hole in the sequence, even when using Saving Delete Tickets functionality.
(0094321)
marvintm   
2017-02-14 15:53   
After discussing it internally, we have concluded that this is a design defect, and to fix it, the way document numbers are generated for the Web POS should be overhauled.

Currently, we only keep track of the maximum next document number which should be assigned to the next ticket. This means that it is possible to generate holes in the ticket sequence, because it's possible to create tickets after a given ticket, and then delete it. Using the Saving Delete Tickets functionality mitigates the problem in some cases, but it doesn't fix it completely, as it's still possible to generate holes by deleting empty tickets, or as this issue explains, by changing orders into returns or viceversa, and likely there are other flows which may generate this.

The proper solution for this problem would be to change the way the Web POS assigns the next document number, so that it keeps track of lost document numbers, and reuses them for new tickets when possible. This however is quite a complex development, which is why we are changing this issue to be a design defect.