For now, when you are selling products in the point of sales, the stock
is affected once the order is validated or the session closed. But in
some case, you don't have the product in your store, and you have to
plan a delivery for the order.
To be able to plan a delivery, you can now choose the warehouse in POS
Config and the routes of your warehouse will be applied. You can also
set a specific rule on your POS Config if you've enabled the
multi-step-routes in the inventory module
closesodoo/odoo#58506
Task-id: 2082104
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When the customer use Anglo-Saxon stock valuation and have already
reconciled some `account.move.line` related to an open `pos.session`,
closing the session will fail.
(You are trying to reconcile some entries that are already reconciled)
Now, the reconciled lines are ignored.
The inventory valuation is still correct as these lines were already
reconciled.
opws:
2374559
2376187
2377958
2391395
2425197
closesodoo/odoo#64668
X-original-commit: 3f939af62df65dcb9c8cdd2ecc3ac3d4c2983a2f
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Journal entries coming from PoS are based in UTC instead of local time.
This commit is an improvement over 23d3856f2a4323097f51254b5e32c517d45bfe66
to add the timezone info
opw-2371863
closesodoo/odoo#63075
X-original-commit: 30ee2ebae3275de259eff6019d3a4582ef86a729
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Instances like deleting a tax used in a pos.order before closing a
session is allowed but it renders error when closing the session
because of imbalance move lines. In this commit, we are adding
a 'balancing' line in the move before it is created. This ensures
the closing of pos session. The introduced move line is named
'Difference at closing PoS session' and is a receivable making it
easy to find and can be reconciled.
closesodoo/odoo#62308
X-original-commit: 7b9545387962981b5729318e2bbc5714dcbac68c
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
When a session is created and no orders can be created because of
misconfiguration. We should be able to close the session.
When a chart of account is installed, we should not try to create
payment methods on config that have active session as it is forbidden.
Check that there is at least one payment method configured when
launching a session.
closesodoo/odoo#61954
X-original-commit: 17bc5d31722c1a90b03ada16f8e100b8713095ca
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- Create a POS session
- Sell some items
- Close the session, go to the closing page
- Duplicate the browser tab
- Close the session in tab 1
- Close the session in tab 2
The journal entries are created twice.
There should be a server check before closing the session.
opw-2379278
closesodoo/odoo#61860
X-original-commit: 0ba535c5123fecb410fa7546b5bb39a52884ca40
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, if a customer/supplier has an invoice address, when
creating an invoice/bill it's the invoice address that will be
identified as the customer/supplier and that will have its rank
increased and not the commercial partner.
Now, the rank increment is done to the commercial partner as well.
opw-2377870
closesodoo/odoo#61778
X-original-commit: dbf042611ccb134a220704d6b775aab650364ca2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The open_action_with_context was not using _for_xml_id, producing an
error when reading the action content.
In open_action, the action_name was taken from the context and needs
sanity checks. Ensure only actions from the account module can be
read and only if the user has access to the target model.
This is a limitation of the previous behaviour but, at the moment, all
known calls are made refering to an action from the account module.
Limit the scope of this method while the 14.0 is still early to avoid
having a door open to ready any action, and difficult to close later.
Remove old action fetching from the context in create_move that is no
longer used.
closesodoo/odoo#61602
X-original-commit: a39e94f7e4dc74e850650ac90bbc5f85af130bc8
Related: odoo/enterprise#14695
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
- Use the tax tags returned by the compute_all for the base lines instead of recomputing them separately
Splitting the computation caused inconsistent computation in some cases between the base and tax lines (one could select the refund distribution, while the other selected the invoice one).
- Pass the is_refund parameter to True if either the quantity or the price is negative (but not both)
Those negative lines should correspond to refund repartition (double-checked with the Belgian tax report in v12).
OPW 2351412
closesodoo/odoo#60925
X-original-commit: 7827581b208b464638a91044462d0bc497025326
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Open POS
Make some cash transaction
Close POS
Repeat for some days and close the session
Cash statement lines will be saved with the closing date, even
if the payment entries are saved with their payment date
opw-2347645
closesodoo/odoo#60385
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Starting this commit: 8f57863707
regular pos User now don't have a read access to ir.property model.
Because of this, if a user opens a session, he won't be able to close
it. We sudo the search to stock.move (because the query parameters
requires reading from ir.property) to make sure that closing a session
will succeed.
closesodoo/odoo#59712
X-original-commit: 5e2763fdc94b63eee637f9679f8ea3a07beb74ce
Related: odoo/enterprise#13981
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
Have a payment method [PAYMENT] on POS with split transactions enabled.
Make a POS sale to a specific customer, pay with [PAYMENT].
Close and validate the session.
While the accounting entry for the POS sale will have the partner set,
this is not the case for the entries related to the payment.
opw-2307973
closesodoo/odoo#56142
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
HTTPS had been disabled on SaaS to allow the use of the IoT Box that
had no valid SSL certificate. As of V13.0, IoT Boxes connected to
Enterprise DBs have a valid certificate. POS can then use HTTPS.
Nginx is configured to redirect all requests to `/pos/web` to HTTP,
so we change the POS URL to `/pos/ui`, except when using a Six
payment terminal as it only works in HTTP.
closesodoo/odoo#56933
Taskid: 2191878
X-original-commit: 8aee4992778fee5e2f146c4cff8b35e83c7f56b3
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
A single anglo saxon line was created in the pos.session journal
entries, even if some products were returned. We now distinguish
positive from negative lines.
E.g. Selling 10 Product1 (cost=10) and returning 5 Product1 used to
create the following line:
```
Stock Interim Account (Delivered) 0 50
```
and now creates the following lines:
```
Stock Interim Account (Delivered) 0 100
Stock Interim Account (Delivered) 50 0
```
Task ID: 2126521
closesodoo/odoo#55086
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This commit switch the cash control opening mangement from the backend to the front end of the point of sale.
task_id: 2258817
closesodoo/odoo#55741
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
- Set the following access rights to a user A:
Point of Sale: User
Invoicing: Billing
Inventory: User
- Create a product P, FIFO + Automated
- Add some stock for P
- As user A, open the POS
- Sell one unit of P
- Close the POS and validate entries
An access error is raised because the user doesn't have the right to
read the `stock.valuation.layer` object.
We can retreive the value as `sudo` in this case.
opw-2305446
closesodoo/odoo#55224
X-original-commit: d3147910e031253ddb172959e9016a0f326d7cdb
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Avoid concatenation of translated strings & raw values and/or other
translated values, and use the new _ API (by providing the formatting
values to ensure the fallback on the english terms in case of wrong
translation).
By including the expected values inside the string to translate, we
ensure that the formatted values are included at the right place in the
resulting translated text.
This also provides more information on the string to translate to
the translators, s.t. the chosen terms for the translations can be more
adapted to the translation context.
closesodoo/odoo#54635
Related: odoo/enterprise#11925
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
- Create a user with only Point Of Sale User rights
- As this user, open a POS session, create a POS order
- Validate and Close the session
An `AccessError` is raised because the user has no Accounting access
rights.
A POS user should be allowed to close a POS session, as it was the case
in 12.0.
opw-2251699
closesodoo/odoo#52710
X-original-commit: bc3aec38a092c7117dd8de8f6c975cdfad04b05d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set rounding policy to 'Round Globally'
- Create a Tax T
Amount: 21.0%
Different tax tags for invoice and credit notes
Set any account Repartition Line
Advanced Options => Included in Price
- Create a Product P1
Sales Price: 11.8
Customer Taxes: T
- Create a Product P2
Sales Price: 15.3
Customer Taxes: T
- Create a new POS Session
- Create a POS order:
P1, Quantity: -6, Discount: 5%
P2, Quantity: 6, Discount: 5%
- Validate and close the session
A difference of 0.01 prevents from closing the session.
The error arises because the tax tags are different for an invoice and a
refund. In the following:
https://github.com/odoo/odoo/blob/1a9e147639012cc847099e69fc964f3669a36cbb/addons/point_of_sale/models/pos_session.py#L394
Both lines have different `tag_ids`, therefore their amount is not
summed when closing the session. On the other hand, the POS UI is not
aware of the `tag_ids`, so it sums then round the amounts.
The situation is quite unusual: from SO or Invoices, it is possible to
create either an invoice or a refund, but not a mixed object as the POS
is doing. Moreover, if a user invoices the POS order, there is no
problem to close the session since a regular invoice is created and tax
amounts are summed.
We consider a refund if all lines have negative quantities. We only do
it in 'Round Globally' configuration to avoid impacting non-problematic
use cases.
opw-2254211
closesodoo/odoo#52704
X-original-commit: 5f25be8eef9a9efc18a995f2c6405d08a657ac96
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal.
- Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal).
- Adapt and simplify the bank reconciliation report.
- Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly.
- Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account.
With invoicing, the payment will do that so the "in_payment" state should never be shown up.
With accounting, only the statement lines have the power to move an invoice to the "paid" state.
- Fix various corner cases about the management of multi-currency in bank statement lines.
- Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one.
- Ensure the 'reconcile' method will raise an error if the involved moves are not posted.
related enterprise PR odoo/enterprise#7019closesodoo/odoo#41301
--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
1. Install PoS and Accounting
2. In the PoS setting activate the Invoicing option
3. Sell an item X with Invoice toggle to client Y and pay it
4. Sell the same item X with Invoice toggle to the same client Y with
quantity -1
5. Close the PoS session
Traceback wil occur when trying to Validate Closing & Post Entries
because in '_create_invoice_receivable_lines' already reconciled lines
are already filtered out so invoice_receivable_lines is empty
opw-2206625
closesodoo/odoo#49407
X-original-commit: e9f5e2b7fdd332ca0fc0f43c839118ef82d4eddb
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit:
When a PoS session is closed in anglosaxon accounting with real time stock valuation, the stock moves linked to PoS orders are used to create the stock valuation entry.
When an order is composed of only products of type 'service', there are no picking linked to the order, and so the entry is created with all stock moves having no picking_id.
After this commit:
To avoid this problem, we are checking that the PoS order has a picking before looking for stock moves.
OPW-2206625
closesodoo/odoo#49117
X-original-commit: 0386e1f099bf42a59a79febfa06906dd76bd62e2
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- Create a tax:
Fixed price: 0.355
Included in price
- Assign the tax to product P
- Create a POS order with P and a price 0, pay by bank
- Create a POS order with P and a price 10, pay by bank
- Close the POS session.
The following entry is created:
D C
Tax Received 0.01 0.00
Product Sales 0.00 9.65
Product Sales 0.36 0.00
Receivable 10.00 0.00
Several issues:
- the entry is posted and unbalanced: covered in #48484
- rounding of 0.355 was either 0.36 or 0.35: to fix one day... [1]
- the tax received of 0.36 for the POS order of 0 is booked on the debit
rather than on credit, leading to a difference 0.01.
This happens because the taxes amounts for the POS order of 10 are
positive, while they should be negative for a sale as done in [2].
We set the amounts as negative as done for incoming invoices, and adapt
the tax line creation accordingly.
[1] The use case is weird: a fixed price of 0.355 while we only have 2
digits in the currency?
[2] https://github.com/odoo/odoo/blob/e415cffa2ffb3fe4b5f0e32bd96b3433387a95e3/addons/account/models/account_move.py#L461
opw-2168096
closesodoo/odoo#49104
X-original-commit: 5df8ed72d03de635f3c38ce59c1b3e9c9ce51ed2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Have a clean V13 db with point_of_sale and account_accountant
- General Settings => Accounting => Check "Anglo-Saxon Accounting"
(debug mode)
- Choose or create a storable product P with category C
- Go to category C and set 'inventory valuation' to 'automated'
- Open a new POS session PS
- Sell product P with qty 1
- Pay
- New order
- Sell product P with qty -1 (refund)
- Pay
- Close session PS
- Validate session PS
Error "You are trying to reconcile some entries that are already
reconciled." will popup because the 0 sum AML is already marked as
reconciled. This can be fixed by avoiding asking reconciliation when the
amount_residual is 0.
opw-2177881
closesodoo/odoo#48799
X-original-commit: 2c5ef4ed7ea98f890f95f8892c8a0df64b88db98
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The problem is described in https://github.com/odoo/odoo/issues/48550.
This is caused by reconciled receivable line in the invoice being
reconciled with another reconciled receivable line in pos_session's
move_id. The lines are already reconciled because their balance is zero.
So to avoid trying to reconcile those reconciled lines, we do not
include them in the list of lines to be reconciled.
closesodoo/odoo#48587
X-original-commit: f24677098bec9b96108a901dde08bf75dc7d4c5f
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- Create a POS in a currency different from the company currency
- Open a POS session
- Do a refund (negative quantity)
- Close the session
An incorrect journal entry is being created, blocking the process.
This is because the sign of `amount_currency` is changed, while it
shouldn't.
opw-2191664
closesodoo/odoo#45619
X-original-commit: 1ac17f5d05dc4dd82db4a622229ba1ca2a7f31aa
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The problem occurs when the pos session has currency that is different
from the company's currency. Additionally, product that is tracked in
accounting is also sold in this session.
This situation results to anglo saxon move lines that are incorrectly
converted.
The current implementation considers the value from the stock valuation
layer to be in the session's currency. However, that is not the real
case because values in the valuation layer are always in the company
currency.
With regards to tax line, the tax_base_amount is not converted to the
company's currency. It's value should always be in company's currency.
This commit fixes the behavior of pos in generating anglo saxon lines
and setting the correct tax_base_amount in the pos session's accounting
entry.
X-original-commit: 2bdbea3bbf87a921ed3b343f5146a519f10e0add
This factorization is needed for support purpose.
I.E.: This will allow to post an account move to balance
unbalanced journal entries.
Basically, it divides the function into sections
that were already present in comments.
closesodoo/odoo#45231
X-original-commit: 26e012015a6803af6c2a5480984f1c02e0244e83
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Install point_of_sale and a localization (i.e. l10n_be) with a tax
configured with 0% and no account.
Assign the tax to a product available on POS. Open POS session, sell
such product, close session and validate. Error message will popup,
blocking the action because the tax used for the product has no
associated account for posting the entry.
This should not be the case because the tax is 0% so it should not be
posted. Skipping taxes based on the amount to avoid the issue.
opw-2155173
closesodoo/odoo#41821
X-original-commit: c7936d2884c10865bfc39a43d30aef6926f29079
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce:
-install the POS module
-install the Contacts module
-create or use an existing partner as a customer during the pos session
-go to contacts and activate the "customer" filter
-> partners used during the pos session are not showing in the list
The problem was that the 'customer_rank' property
https://github.com/odoo/odoo/blob/d8d7635d6cf2af60791f25201a7bd1c2d5ec238b/addons/account/models/partner.py#L430
was not updated properly after a pos account move was done
Previous behavior
After ending a POS session, partners that are created and/or used
during the session are not showing on the Contacts views when the
'customer' filter is active
Current behavior:
The customer_rank of the partners is increased by one for every sale
during the pos session
Partners created or linked during a POS session are now considered
customers and appear in the contact view when the "customer"
filter is active
opw-2148894
closesodoo/odoo#41792
X-original-commit: 22874376594f94232e0c4ad5a4db3ee76f24b39a
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Because of the law of the 1st december 2019, we can't pay with 1 or 2 cents anymore.
We have to round the total price to the 0.05 unit.
If the customer pay without rounding values, it triggers an error.
Before the order is finalized, we add a line with a product rounding to round the total amount.
Task-id: 2035010
X-original-commit: 58477e5503a18cc98fe686f8857233063eb26f4c
When a pos session is closed, the difference and transactions of cash
control are not good anymore, because it is based on the statement
linked to the cash payment method, and it is modified during the
validation of the session to create a balanced account move.
So we are now storing the values in fields, to keep history of the
closing control
closesodoo/odoo#35286
Task-id: 2032173
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When you have a lot of pos order to synchronize with Odoo, it may take a
lot of time because it has to create a picking for each order. So we've
added an option in the settings that will create the picking at the end
of the session.
So the new option by default is creating the picking at session closure,
and if you need a real time stock you can enable the creation of picking
for each order.
closesodoo/odoo#39584
Task-id: 2082064
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Prior to this commit: b234e97f87,
uninvoiced orders' state is set to 'done' when the session is validated.
However, this was not taken into consideration in the said commit such
that even if the session is already validated, the uninvoiced orders'
state remains 'paid'.
Setting the orders state to 'done' is the correct behavior and is
implemented in this commit.
closesodoo/odoo#39735
X-original-commit: bb490301c22c84c86d2b1c2d27ecb96a4ff19ac5
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- Go to POS application
- Click on the 3 dots of the session to open configuration
- Remove the "Cash" payment method and just keep "Bank"
- Open the session, proceed to a sell and close it.
- Try to open the session either clicking on "Close" on the kanban card
`CacheMiss` error.
opw-2116470
closesodoo/odoo#39570
X-original-commit: 62cb92644de3cfa6e7864583d1efcaf5821f05e4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The default `compute_sudo=True` makes sense for recomputing stored
fields that are indirectly related to a business operation. This
ensures that the recomputation of the field does not break an operation
that is not aware of the fields to recompute.
However, computing non-stored fields in superuser mode is usually not
necessary. It even leads to unexpected values: counting a partner's
sales orders does not give the same result in superuser mode as in
normal mode. That is why non-stored fields are not computed in
superuser mode by default.
[FIX] account, delivery, event, hr_recruitment, point_of_sale, stock:
adapt the model definition to make all fields with the same compute
method have the same value for `compute_sudo`.
[FIX] sale: split the computation of `invoice_ids`, `invoice_count`
(non-stored) and `invoice_status` (stored), as no code is actually
shared.
closesodoo/odoo#39195
X-original-commit: 843fd38a97f02b49dc09d7f55919072d272fd80e
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Since https://github.com/odoo/odoo/pull/34297, sudo() allows to keep
current user information when creating/modifying records.
There is no need anymore to use with_user(SUPERUSER_ID) to have sudo rights.
This commit ensures the user information is kept when creating pos sessions,
instead of having OdooBot as create_user.
closesodoo/odoo#38441
X-original-commit: aff1dc1ea68c345fb2632f9666dc298f685b8748
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
We cannot close a session without POS order as we are giving explicitly
a name to the account_move, it is not possible to delete it at the end
when it is empty.
So we don't name it anymore, and it takes its name from the journal
sequence when it is posted, which actually do exactly the same as
before, except that it avoid to have gaps in the sequence and allow
deletion of the move if it's not named.
closesodoo/odoo#37787
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Close a rescue PoS Session from another company triggers this error:
"Please define income account for this product: "Office Chair" (id:5).
property_account_income_id on product is company dependent but no
company was forced before this fix.
closesodoo/odoo#36280
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Pierre Masereel