Current behavior:
If the PoS has no cash method configured, and you try to make a
payment with a greater amount than the due amount, you will get an
error message. Because you cannot give money back to the customer as you
have no cash method configured.
Steps to reproduce:
- Remove Cash payment method from the PoS
- Open a PoS session
- Create an order with some products
- Pay the order with a greater amount than the due amount
- Validate the order, you will get an error message
Solution:
If the Pos has no cash method configured, and the user try to make a
payment with a greater amount than the due amount, we will automatically
set the amount to pay to the due amount and show a message to the user.
opw-3061612
closesodoo/odoo#107398
X-original-commit: 6280e5ac921b21d10100cd78a18072120d823aca
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Since the bank statements have been removed, we don't have anymore a
stat button to show the bank statement.
So we re)introduce a button that display the statement lines.
caused by: https://github.com/odoo/odoo/pull/99092closesodoo/odoo#101929
X-original-commit: dd21c708cc08d484530bc7c8433ebbb79f59323a
Signed-off-by: Masereel Pierre <pim@odoo.com>
Current behavior:
When the default intermediary account is the same as the default
receivable account define on customers, and you make a payment with
2 differents payment methods the invoice is not marked as paid.
Steps to reproduce:
- Set the Default Intermediary Account to be the same as the default
receivable account on customers. (You can get the default account
by creating a new customer and go in the accounting section and
look for "Account receivable")
- Start a PoS session, select a customer
- Add some product to the order and click on payment
- Click on invoice
- Pay with 2 differents payment methods (cash and bank)
- Validate the order
- The invoice is not marked as paid (Amount due > 0)
opw-2972726
closesodoo/odoo#101106
X-original-commit: 439f7ee0ceae01eaba6a5a352e45531d5e9c9167
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Bank statements are now optional in accounting. The users add statements directly and can assign statements for control reasons.
The users can enter end date and end balance real for the statements and attach the bank statement scan.
The system checks if there is a gap (lines without statement) before current statement and warns the user
with decoration, also we check if the ending balance match the accumulated balance of the last line.
Bank statement lines now show an accumulated balance and can be sorted by drag and drop in the same date, if the user drags a line
to a position with lines of another date, it simply doesn't have any effect.
Rename accumulated balance to cumulative balance, a better name
closesodoo/odoo#99092
Task: 2879904
Related: odoo/upgrade#3906
Related: odoo/enterprise#30824
Signed-off-by: Laurent Smet <las@odoo.com>
After this commit, the settings of coupons, promotions,
gift cards and loyalty cards are now managed under a
single one field in PoS Settings configuration. Moreover,
this settings field is "global" and shared between the
eCommerce and Sales app.
task-2959620
closesodoo/odoo#99060
Related: odoo/upgrade#3842
Signed-off-by: Masereel Pierre <pim@odoo.com>
Definition of reconciled line was recently changed [1] and draft records are not
marked as reconciled anymore. However POS session closing still needs old
definition of reconciled line, because state of the related journal entry is
still draft and hence `reconciled` value is always equal to `False`.
STEPS
1. POS -> Open Session -> Order -> Invoiced
2. Backend -> Open Order - Return Products -> Payment -> Invoiced
3. Close session
BEFORE: error *You are trying to reconcile some entries that are already reconciled.*
AFTER: POS Session is closed successfully
But previous commit fixed it. This commit only adds a test.
[1]: https://github.com/odoo/odoo/commit/1d73bc7d5458b3bb3a566aa4b4a4b101a5329b9a
opw-2859747
closesodoo/odoo#99537
Related: odoo/enterprise#31051
Signed-off-by: William André (wan) <wan@odoo.com>
Not entirely sure about TestAllocationRights. For TestEsEdiCommon
issue is quite obviously that it's inherited by tests which are
external, so when the `post_install_l10n` tag gets applied those tests
get run during "normal" l10n and they break.
closesodoo/odoo#98814
Related: odoo/enterprise#30825
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Some countries, such as mexico, require a seller to be able to
generate an invoices from a ticket from a sale done in a shop,
even after a few days.
This change aims to allow this, by allowing to create an invoice at
a later date after the POS has been closed.
This is done by partially reversing the POS closing entry, and then
generating an invoice the same way it would be done at the POS closing.
The customer can scan a QR code if enabled in order to request the
invoice by himself, requiring him to fill a for to give the customer
information required for the invoicing.
Allows to fill additional fields dependent on the localization that are
required to be set on the partner or the invoice.
Task id #2946604closesodoo/odoo#97675
Related: odoo/enterprise#30599
Signed-off-by: Laurent Smet <las@odoo.com>
Current behavior:
In the PoS if you use 2 differents payment methods (cash and customer
account), and that the cash amount given by the client require you to
give some money back, the amount due on the customer account would be
incorrect on the invoice.
Steps to reproduce:
- Start a PoS session
- Add the 750$ desk to the order
- Go in the payment screen
- Add customer account with 300$
- Add cash with 460$
- Click on invoice
- The invoice show that the client need to pay 290$ which is not
correct
Before the fix calling `_prepare_reconciliation_partials()`
with the sorted lines we had 2 credit lines (750€ and 10€)
and 1 debit line (460€).
Debit lines | Credit lines
460€ | 750€
| 10€
The function would reconcile the 2 first lines and stop after that
because the only debit line was fully reconciled
After the fix we have this
Debit lines | Credit lines
460€ | 10€
| 750€
After reconciling the 2 first lines we have this
Debit lines | Credit lines
450€ | 750€
And after reconciling the 2 last lines we have the correct amount left
to pay by the customer (300€)
opw-2857064
closesodoo/odoo#98828
X-original-commit: 1201123e272012b7b5ab65eebfd12a911ecc6c1a
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Small visual changes that should improve the user experience.
The loading demo data popup has been moved to the backend.
Created an Alert Popup that is less aggressive than an Error Popup
closesodoo/odoo#83780
Task-id: 2485062
Related: odoo/enterprise#26104
Signed-off-by: Masereel Pierre <pim@odoo.com>
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Before this commit: If a fixed tax is used for a product with the price
of zero, the tax line sign would be positive and lead to an unbalanced
move. The solution is to use its sign in its context for correct
calculation.
Also, in the PoS front-end, when you want to return a zero amount
product with a fixed tax, its sign would be positive, which is
incorrect.
Steps to reproduce the first issue:
- Install 'Point of Sale' module
- Create a new 'Tax' X with a fixed price (e.g.: 1 $)
- Create a new 'Product' with zero Sales Price
- Create a PoS session
- Add the product to the order
- Close the session
It creates a line for the "Difference at closing PoS session," and
doesn't prevent closing. But the problem is that the tax capture as
debit is incorrect. The tax for the invoice must be credit.
Steps to reproduce the second issue:
- Install 'Point of Sale' module
- Create a new 'Tax' X with a fixed price (e.g.: 1 $)
- Create a new 'Product' with zero Sales Price
- Create a PoS session
- Add the product to the order
- Change the quantity to -1 (refund)
The final amount is positive, while it should be negative.
Solution
The sign must be sent in the context, and for the PoS front-end, it
should consider zero amount cases.
opw-2833590
closesodoo/odoo#95067
X-original-commit: c5fb4f778db95fb33845b9a5e0c2190d4d9037ee
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This change removes the `barcode_nomenclature_id` in the `pos.config`.
Each pos session now starts based on the company's barcode nomenclature.
closesodoo/odoo#93072
Task-id: 2849415
Related: odoo/upgrade#3575
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
When you are in anglo saxon accounting with posting stock changes at the
end of the session, we get an issue by using the refund feature in
backend.
If you have an order invoiced, and want to refund it, it'll create the
picking of the order immediately, which is not normal as it should only
be done when there is an invoice.
The problem is that the value of the field 'to_invoice' from the
original order is copied to the refund, and so act as the invoice is
made for the return.
To avoid this behavior, we are avoiding to copy it.
OPW-2848356
closesodoo/odoo#93645
X-original-commit: e8ef74397c0b02d051823142c3457413aabfeb21
Signed-off-by: Masereel Pierre <pim@odoo.com>
When you are shipping later from POS and have a multi-step
configuration, you get an error saying that you cannot unreserve more
than what is reserved. It comes form a bad filtered list of move.
Now as we are correctly filtering the move on their product_id it
correctly works.
OPW-2854159
closesodoo/odoo#93336
X-original-commit: 93e0509d0ba7302ecdf5d0f6dbc2dbe90e98229d
Signed-off-by: Masereel Pierre <pim@odoo.com>
Purpose:
- Move PoS settings in general settings to be consistent with the rest
of Odoo (PoS being the only app where settings are split in two locations)
- Clean settings by enabling obvious settings or dropping unnecessary ones.
closesodoo/odoo#84719
Task-id: 2753430
Related: odoo/upgrade#3260
Related: odoo/enterprise#24425
Signed-off-by: Masereel Pierre <pim@odoo.com>
After a fix made in rev:bd621fd456811e7f3ce646e3ecade5e9e4a826e8
It was not possible to generate an invoice from the POS when you have a
fixed tax included applied on a base amount with tax included.
As it was not detected by a test, we are now creating a test with this
use case.
closesodoo/odoo#92106
X-original-commit: 291b564ffebaf8b8708072c981d1072b8bb33677
Signed-off-by: Masereel Pierre <pim@odoo.com>
Forward-port of PR odoo/odoo#86643.
Add a unittest for multi_step route on Ship Later warehouse to
ensure that the fix 5959d77f344 is not unintentionally reverted.
closesodoo/odoo#89595
X-original-commit: d5fb77e9d4716dd509e2e98ff39f7e1cb91ddaca
Signed-off-by: Masereel Pierre <pim@odoo.com>
Steps to reproduce:
1. pos.config is in company1
2. create a partner with company = company2
3. change pos.config to limited partners loading
4. open the pos ui (to call load_pos_data)
old behavior: access error
closesodoo/odoo#89013
Now: method is called without error
X-original-commit: eade911354dac775b3b96212698dbb7e2d644390
Signed-off-by: Masereel Pierre <pim@odoo.com>
revert commit https://github.com/odoo/odoo/commit/5f25be8eef9a9efc18a995f2c6405d08a657ac96
Goal:
- Gives the expected tag to the account move line created by the PoS.
- Add tests to the PoS regarding the created account move line
Before this commit:
If the configuration was set to round_globally, a pos.order.line was processed
as a refund only if all order.lines were a refund.
This leads to unexpected results in the tax report. Indeed,
since commit https://github.com/odoo/enterprise/commit/46769076526701d96ee4f2653e44b57604cc0b7a
"Negative" line in PoS (debit) are processed as positive to give a
correct results.
This means that if a line is set as debit and is suppose to lower a
line, it makes it bigger.
Example:
aml from PoS: debit: 10 tags: +03
---> report.line [03] is suppose to make a -10 but will do a +10.
As a result, report line [03] is false.
After this commit:
PoS never use "invoice_repartition_line" to create a refund line.
closesodoo/odoo#85461
Ticket: 2718998, 2714310, 2746890
Community-pr: https://github.com/odoo/odoo/pull/85149
X-original-commit: e4dedaf08b41cf3d80bfb01e70de714c9a84167d
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
This commit gives the possibility to create pos_order_line with discount
This is needed in order to reproduce real usecase.
X-original-commit: 49bfb576a76e2ad4449326c4b12ebf57bece7069
Part-of: odoo/odoo#85461
This commit accomplishes multiple objectives:
1. Loading of model data for the POS UI is now done in single
request (with some exemptions).
2. Backbone.js is removed and is replaced by reactivity.js
authored by the js framework team.
3. Better organization of assets in the `__manifest__.py`
Data Loading
------------
One request per model -- that's always been how the data is loaded
in POS UI. Now, we move the aggregation of data to the backend which
simplified the data loading. In the frontend, data loading is
initiated in `load_server_data` which makes the single rpc call
to the `load_pos_data` defined in `pos.session` model.
There remains some rpc calls during loading but the number is
greatly reduced.
This change result to faster loading of the POS UI. However,
there is no more progress bar during the loading.
Notable entry points:
- .js: `PosGlobalState.load_server_data`
- .py: `pos.session.load_pos_data`
It is possible to make customizations in the loading, but is done in
several steps:
1. Override `_pos_ui_models_to_load` to include the new model to load.
2. Define `_loader_params_<model_name>` to define the `search_params` and
optional `context`.
3. Define `_get_pos_ui_<model_name>` to return the data that will be
included in the full `loaded_data`. Perform the organization in this method
whenever necessary.
4. Override `_pos_data_process` for further post processing. The final
form of `loaded_data` in this method will be sent to the frontend.
Removal of Backbone.js
----------------------
POS is no longer dependent from `Backbone.js`, but it's replaced by a
new dependency -- `reactivity.js`. It's invented by the js framework
team which will be available in owl v2.
The consequences of this change are the following:
1. The old `PosModel` is renamed to `PosGlobalState`.
2. The name of the other models are kept (except Paymentline which
is renamed to Payment).
3. The name `PosModel` is now used as the base model of the data models.
This is symmetric to our use of `PosComponent`.
4. The instance of `PosGlobalState` is made reactive in `Chrome` (the
root component). As a result, whatever mutation made in that instance,
`Chrome` will rerender. But rendering is batched so multiple mutations
in a single sychronous function call will only result to a single
render call.
5. `PosModel`s can be extended in the `Registries` the same way as we
extend the `PosComponent`s.
```js
// E.g.
Registries.Component.extend(Chrome, PosResChrome);
Registries.Model.extend(Order, PosResOrder);
```
Reorganization of assets declaration
------------------------------------
This is a simple change that replaced the explicit enumeration
of loaded .js and .xml files. Also, we now have regions in the
manifest separating:
1. Augmentations of dependencies
2. Assets for `point_of_sale.index`
3. Assets for the qunit test (soon will be improved)
Other notable changes
---------------------
- Automatic call to `Order.save_to_db` is batched.
- Instances of `devices.DeviceProxy` (`proxy`), `devices.JobQueue`
(`proxy_queue`) and `BarcodeReader` (`barcode_reader`) are moved
to `point_of_sale.env`. Together with `posbus` and `posMutex`
(previously `flush_mutex`).
- `ActivePrograms` is now passed a props.
- `cashier` is no longer saved to `localStorage`.
- `pos_cache` is overhauled.
- `cache` is taken out from `PosDB` to prevent infinite rendering
loop whenever `cache` is mutated. It's now called `CACHE` in
the `db.js` file.
- reactive version of `posmodel` is exposed globally when in debug mode.
This means that calling when calling a mutator, the UI will react.
- Added control buttons in the `ProductScreen` is sorted during `Chrome`
setup. As a result, we don't need to worry on the loading order of the
control buttons components.
- Model can be simply instantiated using `BaseModel.create(obj)`. This
takes into account the extensions.
- `pos_coupon`: rewards are now updated whenever set_order is called.
- Component unit tests were removed. It wasn't useful and it just blocks
the development. We'll be introducing better unit testing later.
closesodoo/odoo#82461
Related: odoo/enterprise#23344
Signed-off-by: Masereel Pierre <pim@odoo.com>
Co-authored-by: Jacky (trj) <trj@odoo.com>
In case the product is tracked and the "Ship Later" feature is enabled,
the lots defined on the POS order are not the same that the ones on the
SMLs of the associated picking
To reproduce the issue:
(Use demo data)
1. Create a product P:
- Type: Storable
- Tracked by lots
- Available in POS
2. Update P's quantity:
- 2 x Lot01
- 2 x Lot02
3. Edit the existing POS:
- Enable the "Ship Later" feature
4. Start a POS session
5. Add some products:
- 1 x P (Lot01)
- 1 x p (Lot02)
6. Process the order with the option "Ship Lated" selected
7. Open the associated delivery order
Error: The reserved lots are incorrect: 2 x Lot01 instead of 1 x Lot01 +
1 x Lot02
When creating such a POS order, if the feature "Ship Later" is used, a
method creates a procurement for each POS order line thanks to
`_launch_stock_rule_from_pos_order_lines`
https://github.com/odoo/odoo/blob/72d6431eb26654b697fc0379f4b6d7e305bb79fc/addons/point_of_sale/models/pos_order.py#L677-L680
Then, these procurements are managed by the standard process, which does
not consider the defined lots. This is the reason why it simply uses the
available quantity in the first lot.
OPW-2704352
closesodoo/odoo#81888
X-original-commit: bc59c4eb7ef6bc216474f39ef8e2634b4ab5ff42
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Purpose
=======
The fields are not used, don't work correctly and there is a specific
report to generate the product prices according to the pricelist and
the ordered quantities
* Do not rely on context, everything should be cleary specified through
parameters
Catch context keys in an unique targeted place to improve code clarity
* Drop strange old API
* do not provide unused partner parameter anymore
* do not provide products, qty as a list of tuple, we only request the
same qty for all products anyway
* Clear methods, add/adapt comments and docstrings
* Reduce potential side-effects of context content.
* remove `component_extension_tests`, that's a test from web and
already tested by web, no idea why it's rerunning in POS
* remove all failfast specs, after discussion with ged, seb, and
xdo it was considered not useful: it's mostly for the runbot but
turns out to be pretty minor as far as positives go, and it makes
fixing errors much harder
Part-of: odoo/odoo#77735
Since changes made in currency rate default value made in this PR
https://github.com/odoo/odoo/pull/76513 the date is stored based on user
timezone, and so doesn't work if the test runs around midnight with the
belgian timezone on the servers.
closesodoo/odoo#78480
X-original-commit: 0dc9a2d47833f2a13dce9891e7710815b4d27584
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The opening cash control has been refactored and the closing of the session is now happening in the POS UI. This also leads to a cash control in the UI during the closing.
The advanced cash control is no longer a setting to activate in the config by the user but a computed field based on the presence of a cash payment method. We force the user to always have it now.
The opening cash control has been revamped with the addition of a new money calculator (`MoneyDetails`) allowing the user to easily compute how much money does he have based on his bills.
The closing control has been converted into a popup which allows the users to get an overview of his session details (about orders, payments, payment methods, cash moves, ...). If the `cash_control` has been set to `True`, the user still needs to count his money by introducing it or using the new calculator.
When trying to close the session, if it fails, depending on the error the user get, he can be redirected to the back end to manually close the session. At this point, the user is not able to open the POS UI.
(In order to fully bring the closing of the session in the front end, all the error handlings need to be brought to the front end as well which takes a lot more time.)
Rescue session can only be closed through the back end and the closing cash control is automatically being computed without the user's involvement. This avoid any cash profit/loss in the journals.
The session chatter is being logged with all the details regarding the opening and closing. This give the user a better view of his cash flow in a specific session.
task-2456424
closesodoo/odoo#73464
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
We are referring to TicketScreen and OrderManagementScreen.
The two screens almost serves the same purpose. There is not much reason
to keep them separate. We combine the two in this commit. Basically,
we remove OrderManagementScreen and its components. Some are kept and
moved to the TicketScreen.
Task-id: 2481404
Part-of: odoo/odoo#75322
When selling a tracked product, if the latter has already been sold
once, the source location of the associated stock move will be
incorrect.
To reproduce the error:
1. Create a product P
- Product Type: Storable Product
- Available in POS: True
- Inventory: By Lots
2. Update P's quantity > 0 with lot L
3. Start POS session
4. Sell one P with lot L (Register payment + Validate)
5. Repeat 4
6. Go to Inventory > Reporting > Product Moves and apply one filter:
- Product: P
Error: There are 3 product moves:
- One from Inventory adjustment to Stock
- One from Stock to Customers
- One from Customers to Customers
The third one is incorrect and should be from Stock to Customers.
Because of the first sale, a `stock.quant` is created and indicates that
one P from lot L is at location "Customers". When selling the second
one, because of the OR-condition, this `stock.quant` is selected. The
condition should be an AND-condition.
This fix is an improvement of #69750. The new test checks the above flow
and the one described in the related PR.
closes#71435closesodoo/odoo#71573closesodoo/odoo#75265
X-original-commit: e0921851a1f1a636169e62f47b4d4c32255f98ed
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Automatically activate `group_multi_currency` if there is more than one active currency,
deactivate it if there is only one active currency
retain sale/pos feature of activating group_product_pricelist
adapt tests accordingly
Task 2610735
closesodoo/odoo#74396
Related: odoo/enterprise#20106
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Margin has been added to both Order and OrderLine allowing the user to have a better view on his profitability. Margin also has been added to the order report as a measure.
Related task id: 2455794
closesodoo/odoo#66689
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
In some use cases, the seller in point of sale needs to add a note on an
order line that has to be displayed on the receipt. So we've added a
field on the order line to set a note.
The note is also set on the invoice if the order is invoiced.
closesodoo/odoo#71598
Task-id: 2556994
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When having several POS with cash control, if at least one POS already
has a closed session with cash in box, the first session of the other
POS may have an incorrect opening amount
To reproduce the error:
(Let POS01 be the existing point of sale)
1. Edit POS01's settings:
- Enable "Advanced Cash Control"
2. Duplicate POS01 (-> POS02)
3. Start a session with POS01
4. Sell one product, payment in cash (Let P be the product's price)
5. Close POS01's session (correctly set the closing cash)
6. Start a session with POS02
Error: On opening cash control, the opening amount is P, it should be 0
OPW-2574096
closesodoo/odoo#72803
X-original-commit: ba86192043ad014a0e13867a66816acede64c897
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
This commits is about two problems. The first one is a undesirable
warning message displayed when closing the POS session
To reproduce the error:
1. In POS settings, enable "Advanced Cash Control"
2. Start a POS session
3. Make an order of 70$, payment in cash
4. Close the POS session (correctly set the closing cash)
Error: When clicking on "Close Session & Post Entries", a warning is
displayed: "There is a difference between the expected and actual
closing in cash. Are you sure [...] ?" However the actual cash is equal
to expected cash so the message does not make sense
The error has been introduced with commit 7252350d35c6e8e7f47458c3aedcf05d92e71afa,
so the current commit reverts it.
However, the reverted commit was a solution to a second problem: When
cash control is disabled, if the user opens and closes a POS session
(without any order), the ending balance of the associated cash register
will always be 0. Here are the explanations: if cash control is enabled,
when the user sets the closing cash, it creates a record:
https://github.com/odoo/odoo/blob/80c28189ae6b10ad17c4de2a781233a8ffe663a6/addons/account/models/account_bank_statement.py#L82-L98
and therefore, thanks to `_validate_cashbox`, `balance_end_real` will be
defined with its correct value. However, there isn't anything to define
the ending balance when there isn't any order and when cash control is
disabled.
OPW-2580699
closesodoo/odoo#72763
X-original-commit: 550e7280212b740bfce72331f6d0aef99b7aadb6
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Acronyms:
SRL : receivable lines in the session's account move that balances
the receivable lines in the session's invoices
IRL : receivable lines of the invoices in the pos session
When closing a pos session, a single account move is created to capture
all the transactions, but, invoices are kept (each is an account move).
During the construction of this single account move, SRLs are
reconciled with IRLs.
Prior to this commit, when closing a pos session, SRLs are grouped
by `property_account_receivable_id` of the partners in the invoices.
Because of this, SRLs are blind of the partners that they are linked
to. This causes issues on tracking the 'due' in the partners that are
invoiced using the pos application.
To fix the issue, we now group the SRLs by partner before reconciling
them the the IRLs.
Same concept is employed for receivable lines generated from split
cash payments, we also assigned partner to them if applicable.
closesodoo/odoo#70662
X-original-commit: 861612baf57caa67afb32ab904fb8aa26a353dd7
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Beforehand, if two users independently opened a draft
invoice on their respective sessions, then both of them
clicked on the "Post" button, then the invoice was
posted twice.
On a more general aspect, the view currently "prevents" users
from posting moves several times, but technically speaking,
nothing stops users from posting moves several times.
Now, after checking that the user indeed has the right to post
a move, the next check is about verifying that the move is
not already posted.
opw-2479201
closesodoo/odoo#69178
X-original-commit: b7db7db283d7b9d167201b791e6282b022d59c40
Related: odoo/enterprise#17658
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Julien CHEVREAU <Julien-CHEVREAU@users.noreply.github.com>
1. Have a [DEMO] product in stock with an owner
2. Make a PoS order with [DEMO]
The system will use the stock without owner.
opw-2480341
closesodoo/odoo#68951
X-original-commit: eaa9c6cc9481fb97d8c44aa057fc97accfc4d649
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This commit removes stock.inventory(.line) and moves its general
functionality into stock.quant. Some features are lost during this
switch as well.
Feature Additions:
- New single list view for inventory adjustments (no more multiple
inventory adjustment records to keep track of!)
- Improved cyclic counts (annual inventory day setting) + next inventory
dates are immediately viewable in view (vs auto-generated inventories
based only on location)
- Specific quants (i.e. counts) can be assigned to users for more
flexibility (vs only able to restrict by location + product
combinations)
- Counts can be requested (i.e. bulk assigned to user/for a specific
inventory date)
Feature Removals:
- Can no longer look at previous inventory adjustments linked to a
specific record. Each quant has a history button to show inventory
related moves. [relevant account moves are also now harder to see via
stock as well]
Other changes:
- Bulk of changes were for demo/test
- Some changes were done to ensure "Update Quantity"/"Inventory Report"
views still mainly function the same as before with the exception of a
new column added to support updating quant quantities in these views.
Task: 2440026
ENT PR: odoo/enterprise#17329
Upgrade PR: odoo/upgrade#2326closesodoo/odoo#68409
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Part of task 2124952
By using AccountTestInvoicingHttpCommon, we have a setup independant
from the demo datas. This also prevents running tests with incompatible
localization: the tests for l10n with another currency than USD failed
because of the demo datas preventing the change of currency.
roen-odoo