Current behavior:
When using a pricelist and discount, the discount wasn't applied on the price from the pricelist but on the price defined on the product.
Steps to reproduce:
- Create a pricelist for a products
- Set the pricelist on the POS session
- Open the POS session
- Apply the 10% coupon code to the product.
opw-2714342
closesodoo/odoo#82484
X-original-commit: c7bc5f6884bb607ac50b29762ea4900a3af91f90
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
We provide a better experience when more settings are activated by default.
For this reason, we activated by default the following settings:
1. POS Settings
- Inventory Management is set to "In real time"
2. POS Shop Settings
- Product Prices is set to "Tax-Included Price"
- Product Configurator is activated
task-2616749
closesodoo/odoo#80376
Signed-off-by: Masereel Pierre <pim@odoo.com>
Current behavior :
When you add a promotion campagn to a PoS the promotion is applied
on every line of every order everytime you load the order. This cause situations
where you have multiple discount for a single product.
Steps to reproduce:
- create a standrard promotion program (automatically applied, 10%)
- set that promotion on the PoS (bar)
- open a session, chooses a table and make an order --> promotion correctly applied
- get out of the table and go back to the same table --> 2 additional lines are created because of the promotion
opw-2699544
closesodoo/odoo#81096
X-original-commit: 72d6431eb26654b697fc0379f4b6d7e305bb79fc
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Current behavior :
When installing l10n_de_pos_cert on runbot module you couldn't start a PoS session
Steps to reproduce :
Duplicate runbot database
Install l10n_de_pos_cert
Try to start a PoS session in a german store
opw-2691615
closesodoo/odoo#80608
X-original-commit: 467708cbedfb2b8146c653afc06625dc4af7e893
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Before this commit, when you clicked on "Review" the order lines weren't
visible due to the number of control-buttons.
To fix this, a "More..." button is displayed if there is more than 3 buttons.
When you click on this button, a new modal will display a menu with all controls.
Note that we had to find a way to close this popup after clicking on an action.
Task ID: 2453679
X-original-commit: 430d40f90c1e9a7e8e3663e8f2b129b0c24911e1
Part-of: odoo/odoo#79448
Co-authored-by: Adrien Dieudonné <adr@odoo.com>
It is possible that the user can mistakenly delete a reward line which
completely deactivates the program in that order. We provide a warning
message to the user to make sure of his intent.
Part-of: odoo/odoo#77903
1. Sell Product A with discount because of Automatic Promo on specific
product.
2. Refund Product A with its discount.
3. Add Product A in the refund order.
[BUG] No discount for the added Product A because the total
count of Product A in the order is 0 (or less because of the discount
line).
In this fix, we don't count the refund orderlines, this way, when
a product is added which qualifies the automatic promo, that new line
will be properly discounted.
Part-of: odoo/odoo#77903
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
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>
* Refactor the use of Mutex. We remove the unnecessary resolves and
rejects. The excess rejects trigger the unhandledrejection event
handler.
* Make sure that the validation of order is not broken when the error
is about connections (aborted or lost).
* In Chrome, we introduce a set of methods to handle
"unexpected errors". Prior to wowl, POS just augments the CrashManager
to show the right popup. But since CrashManager is no longer supported,
we have to introduce a way to handle those unhandled errors.
closesodoo/odoo#73725
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.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.
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
roen-odoo