In backend, the method "_unit_compute" doesn't round the fixed tax amount
before adding to "cur_price_unit" in the case "tax.include_base_amount".
opw:644421
When giving back change, prioritize the same cache method as the one that was
use for the transaction.
This prevents cases where cash input is registered in journal B and change in
journal A.
Fixes#6975, closes#6976
In the receipt report, the quantity decimal precision
was hardcoded to 0, while it should use the decimal
precision from the field definition.
opw-644507
When you apply payment in POS,
it takes current time for "date" field
on bank statement line,
but should use context_timestamp to take care
of user timezone adjustments.
Example:
If user is in time zone GMT-6:00,
then after 6:00pm all bank statement lines will be recorded
with date of next day, and all closing reports and related
accounting will be wrong!
Fixes#2199Closes#2200
The price without taxe must be rounded on each line like 'price_subtotal' in "sale.order.line"
with digits_compute= dp.get_precision('Account').
The total taxes included must be the sum of the rounded total without taxe and
the rounded taxes like in "sale.order" in _amount_all.
opw:643254
The amount total computed for pos order must be the sum of the rounded tax amount
and the rounded untax amount. Inspired from _amount_total in "sale.order".
opw:643254
In the method action_invoice, the call to the method "_prepare_analytic_account" in dict "inv_line"
had no effect because the value of account_analytic_id was being cleared by the product_id_change statement.
So in the end the invoice line was created without any account attached
Now it checks for an existing value, and if it is not already filled in,
the value from _prepare_analytic_account is taken.
amount_line_tax must be used to compute the _amount_all. In this way,
the taxes are computed by "compute_all" which takes into account how
to round(globally or per line). Inspired from "sale.order" behaviour.
Fixes#6765
opw:640211
When rounding globally, the function compute_all in charge to compute the taxes for
each line uses a very high currency rounding to avoid rounding per line.
The round must be done on the sum of each total amount line with taxes. To validate a payment with the pos,
the function is_paid verified that this sum is the same that the amount just paid.
Inspired from "sale.order.line", the precision of 'price_unit' and 'price_subtotal' in "pos.order.line"
must be taken from 'Product Price' to avoid rounding per line.
ps: we could not use the function get_all_prices to round globally because it used on every line.
Fixes#6681Closes#6682
opw:639686
This is related to revision bb913d0.
':' in product names are removed, to avoid issues when
searching products with ':' in their name.
JS replace method only replaces the first occurence, if the
needle isn't set as a regex with 'g', e.g. /':'/g
opw-634547
The previous filters didn't take timezones into account, and
returned stringified naive datetime values in local browser
time. Those would then be interpreted by the server-side as
UTC date, and depending on the current timezone offset vs UTC,
yield partially incorrect results.
By returning directly a datetime.datetime object instead of
a stringified version (see previous commit 76881fb),
we can get the expected result regarless of the timezone.
Fixes#2972Closes#6229
opw-621282
By default, the point of sale awlways uses the rounding method per line.
But the accounting configuration allows to use the globally rounding method,
this is why the point of sale must consider this configuration.
Inspired from the compute_all of account.tax model within
addons/account/account.py.
opw:632537
The box "Tax on children" was ignored in the pos, leading to 100% taxes for these
taxes (as amount is 1.0 on these taxes).
Add child tax fields when loading the pos to be able to correctly compute
recusively the tax amount on children.
Courtesy of Jean-Nicolas Brunet
Fixes#1515, lp:1231574, opw 622143
When the session is closed, the date used is the date of the session start instead of the
system date. This is necessary when the server is not on the same timezone than the user,
opw: 631497
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
If "Group Journal Items" option is checked, the generated accounting entries may get an invalid tax amout.
This will happen when several entries for the same product do not use the same tax amout (e.g. discount).
Avoid grouping products with different taxes under the same line by creating one line per tax_code_id.
opw 626695
Debian does not allow fetching data from external website at runtime.
This fixes the privacy-breach-generic lintian warnings for Debian packaging.
The removed youtube url was a dead link...
Some .xml,.csv,.po,.woff,.ttf,.png,.eot,.svg had perm 755, provocating
'executable-not-elf-or-script' lintian warning for Debian packaging.
Set permission to 644 for those files.
Also remove unnecessary executable permissions on some .py:
-addons/l10n_fr_hr_payroll/report/fiche_paye.py
-addons/l10n_ro/res_partner.py
-addons/l10n_ro/__openerp__.py
-addons/l10n_ro/__init__.py
-addons/l10n_do/__openerp__.py
-addons/l10n_do/__init__.py
This reverts commit d970cc40f8.
point_of_sale does not depends on share. This domain can therefore not be applied.
It works for new databases as the module share is auto installed.
But as soon as the module share is uninstalled, this domain will lead to a crash
There is no way to "solve" this issue, other than by a view customization
if the issue is critical for the customer.
I did not pay enough attention when I reviewed the PR.
name_get of pos.category should use a browse instead of a read.
For a company having thousands of products and a few categories, using a browse
will greatly improve the load time as it is cached.
POS users should not be able to create nor modify payment methods (account.journal)
POS users should not be able to create nor modify point of sales (pos.config)
At first opened session, if no payment methods was set, this is possible that the pos user should temporary have accesses granted to mark a payment method as pos payment method. This is done by the openerp.SUPERUSER_ID added by this rev.
opw-625489
When generating account.move.line from pos.order, orders with different analytic
account should not be groupped in generated lines (possible if inherit
_prepare_analytic_account).
Add the analytic_account_id in the key to avoid this grouping.
Fixes#4602
Registered payment uses the partner receivable account. As this field is
a property field, it will select different accounts based on the user that
registers the payment (in multicompany).
Should use the company of selected journal instead of the one of the user.
Goffin Simon
Alexis de Lattre
Odoo Translation Bot
Denis Ledoux
Jos De Graeve
Mario Arias Badilla
Tam Vu
Stéphane Bidoul (ACSONE)
Frédéric van der Essen
Martin Trigaux
Nicolas Martinelli
Olivier Dony
Nicolas Lempereur
Martin
han-odoo
Jeremy Kersten
Goffin Simon
David Monjoie
Christophe Simonis
Sylvain LE GAL
Yenthe666
Aaron Bohy
Antoine Huvelle
Nicolas Seinlet
Alexis de Lattre
Frédéric Van der Essen
Josse Colpaert
Fabrice Henrion