People sometimes have an open POS client (/pos/web) which is associated
to a closed POS session. This causes multiple issues. The most important
problem occurs when a user closes the session and opens a new session
without refreshing the POS client. When doing this new POS orders will
become part of the old, already closed session and no new accounting
entries will be generated.
In order to fix this we make sure to check that the session that's
associated with the order that we get from the client is still open. If
it isn't we'll try to find a new, compatible session and add the order
there. If we cannot find a compatible session we'll create a new one
based on the old, closed one. When creating this new session we bypass
the opening_control phase which normally takes care of opening cash
control.
opw-652356
With 3e82c94d we use the timezone in the context to format date
sequences when formatting an ir.sequence.
This commit adds the other missing context when getting a sequence, so
these sequences are also dependant on the timezone.
closes#8351
opw-646487
Previously when replacing time related sequence in a prefix or suffix of
a sequence, the timezone used for the time values would always be the
server's timezone.
With this fix, the context timezone is used if available (UTC is used
otherwise).
closes#8159
opw-646487
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
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 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
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
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
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.
Using a payment method belonging to another company will raise errors when closing the session.
To avoid being stuck at session closing, forbid to create a POS using a journal of another company.
A new ir.sequence is generated at pos.config creation for the orders. However it was not used as the type was not set. The fallback was done on the general sequence.
In addition to the sequences being shared, it was not possible to create a pos.order in multicompany (no sequence found for user company, name was null).
Same issue for the pos.order.line.
This patch generates correctly pos.order and pos.order.line sequences at pos.config creation.
Instead of using the pos.config sequence to generate session number (not what this field was intended to), use the existing sequence for pos.session.
Remove company_id value on default pos.session sequence to make sure it's shared between companies and correctly set the prefix.
If the pos.config is not properly configured for multicompany (e.g. using location belonging to another company), launching a session with this config may fail (access rights).
This prevents to configure an incorrect point of sale in the first place.
When a pos session is closed & confirmed, the account.move were generated with the commercial partner except for the bank statement which prevented automatic reconciliation.
This patch uses the commercial partner also for bank statement.
Fixes#1558, #1764
Joren Van Onder
Goffin Simon
Nicolas Lempereur
Martin Trigaux
Alexis de Lattre
Jos De Graeve
Mario Arias Badilla
Nicolas Martinelli
han-odoo
Goffin Simon
David Monjoie
Denis Ledoux
Christophe Simonis
Nicolas Seinlet
Alexis de Lattre
Frederic van der Essen
Olivier Dony
Martin Trigaux
Fabien Pinckaers