9f0120d73b solved this issue already, but
it was only applied to POS orderlines. There is other data on the
report (eg. payments, taxes, ...) that should also correctly respect the
user time zone as well.
opw-678748
The Sales Details report wizard gives the possibility
to print the details of the POS orders between two dates.
The fields in the wizard are of type `date`,
while the orders dates are of type `datetime`.
`00:00:00` and `23:59:59` were naively added
to the `date_start` and `date_end` (respectively) to
handle the case.
But, this doesn't take care of the user time zone:
When a user choose between February 24th and February 25th,
it's within his time zone, and therefore, for the search,
where the datetime are in UTC, adding `00:00:00` isn't enough,
the dates have to be converted from the user time zone
to UTC.
opw-6698831
product_taxes_rel is the many2many table between
product.template and account.tax
product_id on the POS order line is a product.product.
Therefore, the join on product_taxes_rel should
be done using the product.template id of
the product on the pos order line, and
not directly the product.product id.
opw-632720
In the report pos order, average_price was set as a numeric(16,2), therefore, if the amount was too big, it led to a psql crash:
A field with precision 16, scale 2 must round to an absolute value less than 10^14.
This reverts commit 97d097a2af.
As explained in the commit comments (on Github), this patch leads to an infinite loop in 7.0, the filter of the pos orders report using the '=' operator in its domain, which is not available for datetime fields, but is for date fields.
This should not be forward ported to newer release (saas-3)
product_id column of pos_order_line is a product_product
the left join of l.product_id was done on product_template, instead of product_product
It worked as long as the ids product_product were the same as product_template. Meaning that, if you used variants, this report view was screwed.
The date_order field of the pos.order is a datetime, not a date
As, in report.pos.order, the date field is related to date_order of the pos.order
We usually do not commit fixes altering the model fields structure in 7.0, but this one is retro-compatible, as the database structure won't change
* remove old 'day', 'month', 'field' and replace them by the actual
date/datetime field
* remove weird cast to char when creating the view to prevent crash
when grouping on them
* remove duplicates (such as 'creation_date' and 'create_date')
* fix typing errors (field type date defined as a datetime in the
postgres view)
* fix search view definition
[REM] dead code: pos_box_entries.py/xml, pos_box_out.py/xml, pos_return_view.py/xml
[ADD] lines, invoice, cashbox of the day, payment, receipt, users product reports converted to QWeb. Added YML tests for the bank statement reports.
[FIX] closed cashbox of the day sql using old fields in its queries, yml test not correctly generating an invoice from a pos order
bzr revid: sle@openerp.com-20140414104954-xj10wi640tyr3ufe