Recent changes to bugs

#44 unique invoice number on suspend sale

2015-09-15T20:17:23.509000Z

status: open --> closed

#48 Error in Report Page when Tax Included Checked

2015-09-15T20:16:30.683000Z

status: open --> closed

#50 Paid amount in cash, debit card, credit card...

2015-09-15T20:16:10.465000Z

status: open --> closed

#50 Paid amount in cash, debit card, credit card...

2015-07-16T07:29:03.002000Z

The 'Payments' report still seems to be present under the summary and graphical reports. Is it this report you were looking for?

#50 Paid amount in cash, debit card, credit card...

2015-07-15T10:56:45.840000Z

Btw, I might close the 'bugs' section here, and leave the forum open for general discussion only. Currently it's way easier to track issues from github (thanks to the integration with git itself)

#50 Paid amount in cash, debit card, credit card...

2015-07-15T10:55:42.913000Z

It might have vanished after the reports permission rework. In this case it's probably still present in the code but not listed in the reports module. I'll check that later on.

Paid amount in cash, debit card, credit card...

2015-07-15T07:28:47.253000Z

Hi,

not sure when this change was introduced, but OSPOS used to report the paid break down in the sale reports like: Cash £nnn, Debit Card £nnn.
That's useful because sale assistants need to check the cash and list of payments against PDQ machine reports at the end of the day.

Can that be restored?

Thanks,

Francesco

Paid amount in cash, debit card, credit card...

2015-07-15T07:28:47.253000Z

Ticket 50 has been modified: Paid amount in cash, debit card, credit card...
Edited By: jekkos (jekkos)
Status updated: u'open' => u'closed'

#49 Invoice Number

2015-06-24T21:00:46.765000Z

sale_id is a technical key. While invoice number can use any kind of numbering sequence. Rules for invoicing differ across countries ,eg in Europe you need to maintain a separate numbering scheme for sales to customers that don't need to pay taxes (as they pay it afterwards).

Good point on the multi user usecase Looks like your putting it to good use.

Invoice Number

2015-06-24T13:03:23.987000Z

The invoice numbering for sales seams to be flawed for suspended sales, and when in a multi-user environment.

Steps to reproduce multi-user problem:
1) create 2 users
2) in different browsers or machines start a sale
3) tick the box for create invoice on both users
4) provided both sales are active at the same time, the invoice number on both screens/browsers will be the same
5) complete the sale on one machine/browser
6) complete the sale on the second machine/browser
7) second machine will throw an error message about duplicate invoice number

steps to reproduce suspended sales error:
1) start a new sale
2) suspend the first sale
3) start a new second sale
4) suspend the second sale
5) second sale throws error about duplicate invoice number

it looks like this check for complete sale (sales.php line 234) is missing from the suspend function (sales.php line 484)
if ($this->sale_lib->is_invoice_number_enabled() && $this->Sale->invoice_number_exists($invoice_number))

As for the first problem, im thinking that the invoice number should be generated on sale completion like the POS number(sale_id) rather than at the start of sale. This then leads to the question that if the sale_id in unique and sequential, what is the need for the invoice number in the first place.