Add support for Internal Reverse Charge invoicing flows in Italy.
- Add 0% sale taxes and purchase taxes targeting VJ grids in `l10n_it`
for every Tax Exemption Reason involved (Scrap, Gold...)
- Add a Fiscal Position (equivalent to the Belgian "CoContractant" one)
mapping the sale tax and purchase taxes to their Reverse Charge
corresponding taxes. Those fiscal positions all have a different
law-required note (with the law reference) that has to be printed
on the PDF invoice through Odoo standard mechanisms.
- The way we compare the invoice features and each document type
requirements has been revised and expanded for the tax_tags sets case.
Now it should also avoid comparisons after the first failure, instead
of doing all the comparison anyway.
- Imported vendor bills that have TD16, TD17, TD18 now have their
0% reverse charge sale taxes converted to their purchase
22% VAT reverse charge corresponding tax impacting VJ tax grids,
following this mapping:
Sale tax examption reason -> VJ grid targeted by purchase tax
N3.2: VJ3
N3.3: VJ1
N6.1: VJ6
N6.2: VJ7
N6.3: VJ12
N6.4: VJ13
N6.5: VJ14
N6.6: VJ15
N6.7: VJ16
N6.8: VJ17
- Vendor bills that have taxes targeting grids VJ6, VJ7, VJ8, VJ12,
VJ13, VJ14, VJ15, VJ16, VJ17 are exported as Tax Integrations XMLs
to be sent to the Tax Agency with the document type TD16
- Vendor bills that have taxes targeting grids VJ3 are exported
as Tax Integrations XMLs to be sent to the Tax Agency with
the document type TD17
- Vendor bills that have taxes targeting grids VJ9 are exported
as Tax Integrations XMLs to be sent to the Tax Agency with
the document type TD18
Link: https://www.odoo.com/web#model=project.task&id=3724926
task-3724926
closesodoo/odoo#153556
Signed-off-by: Josse Colpaert <jco@odoo.com>
Added a small message in the chatter on an invoice when the invoice fails import.
Silencing errors on a blank invoice doesn't help us fix issues and
doesn't solve the import problem.
Part-of: odoo/odoo#153556
In Luxembourg, during the year 2023, the VAT rates were decreased by 1%
temporarily. Now that we are in 2024, we need to deactivate the taxes added
previously. We will not remove them so that client can still use them if needed.
closesodoo/odoo#157015
Task: 3635758
X-original-commit: 75cb238785c4979846a2db434bb5a715fec44867
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
If a partner doesn't have peppol eas or endpoint set, we still go through with checking participant's registration. This is not an issue if checking on a partner form, as the Verify button is invisible without these details being filled in. However, in the partner list view the button is always visible and it is possible to run verification for non-peppol customers. As a result, all of them show up as valid Peppol participants.
With this commit we only run verification if there are eas and endpoint details.
opw-3784945
closesodoo/odoo#156973
X-original-commit: 3caea860633744b547126f579da0c712b318e515
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
When mixing anglo-saxon accounting and multi-currency, it sometimes
leads to incorrect AMLs in the stock-in account
To reproduce the issue:
(Company in USD)
1. Setup some currency rates:
- Yesterday: 1000 EUR = 4335.1 USD
- Today: 1000 EUR = 4348.0 USD
2. Create an auto-avco product
3. (Yesterday) Buy one product at 1000 EUR and receive it
4. Deliver the product
5. Bill the PO
6. Open the journal items of stock-in account
Error: The AML for the exchange difference has been created twice
When posting the bill, it leads to `_generate_price_difference_vals`
where we generate AML/SVL in case of price differences. There, we
also generate such records in case of exchange difference. This is
what we do in the above use case. However, the AML is wrongly
encoded, we need to respect some specific conditions:
https://github.com/odoo/odoo/blob/d780a2fc73259244411329027349fad1cb353f34/addons/account/models/account_move_line.py#L1773-L1779
Otherwise, the reconciliation process won't work correctly and will
generate its own AMLs for the exchange difference (hence the above
error).
On top of that, to ensure a full reconciliation, we need to first
reconcile the exchange diff AML with the bill one. This is what we
are supposed to do in `/stock_account`: we split all stock-in AMLs
into three recordsets: `correction_amls`, `invoice_aml`, `stock_aml`.
However, we don't correctly isolate the correction AMLs. Therefore,
we try to reconcile all AMLs at once, which will not work.
Note: This commit brings a behaviour change since the amount
currency of exch-diff AML will now be zero, as it should (again, see
the comment of the code quoted above in the reconciliation process).
This also explains why this commit modifies an existing test:
comparing the `balance` and the `amount_currency` of such AML is
incorrect.
OPW-3544318
closesodoo/odoo#156951
X-original-commit: 19403baf53c38d3969b3ef1f97af955b5d454481
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Before this commit, if a receipt was reprinted, the QR code was not
included. This could lead to issues with receipt validation and
scanning.
opw-3763169
closesodoo/odoo#156948
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
- Setup 2 companies with a COA: compA & compB
- For compA, have a journal having some data
- Give you access to compA & compB but make sure compB is your main company
=> samples data are displayed on the accounting dashboard for the journal
- Setup 2 companies with a COA: compA & compB, compB being a branch of compA
- For compA, create a journal
- Add some data into this journal using compB
- Give you access to only compA
=> you should not be able to see the data from compA since the data belongs to compB
Introduced by:
https://github.com/odoo/odoo/commit/24789b2c906e71d347924bfa1bcc7d3ca77d8daf
This commit also adds the company check in all queries/domains to manage the
branches correctly.
closesodoo/odoo#156737
Issue: 3722386
X-original-commit: a8097355ee8c4891ba4161fd82eb54f5d2d80e8c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
**Before Commit:**
- In the point-of-sale, when a company had branches,
- The branch company was unable to use the fiscal position of its parent
company.
**After Commit:**
- The branch company can now use the fiscal position of its parent company in
the point-of-sale.
Task ID: 3775865
closesodoo/odoo#156676
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit:
When the user creates a branch company, the pos(accounting) setting does not
allow the selection of a default temporary account for the user.
After this commit:
The user is allowed to choose a temporary account from the branch company.
Task-3775873
closesodoo/odoo#156478
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit:
When a company having branches,
they uses the same taxes as the parent company,
In POS settings, the default tax used a company domain
which does not allow branch to change the default tax
After this commit:
A branch is allowed to change the default tax
task-3775857
closesodoo/odoo#156434
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Set 'Rounding Method' to 'Round globally'
Set 'Cash Discount Tax Reduction' to 'Always (upon invoice)'
Create a Payment term with 1% discount if paid before 30 days
Create a company partner with child contact
Create an invoice:
- Add as partner the company partner (parent contact)
- Add a line with product 420.99, tax 21% not included
- Add the payment term
Tax total will show 87.52
Add the child contact as partner (set again payment terms if needed)
Issue:
Tax total will show 87.53
This occurs because, when simulating the not yet stored epd vals,
we create the line using the `partner_id` and not the commercial
partner.
Then, when tax amounts are aggregated and rounding errors are managed
the partner is used as grouping key to retrieve vals, so we don't fix
the rounding error correctly
opw-3661210
closesodoo/odoo#156412
X-original-commit: 3c3c12f1427c7138357a7b4abffb4a15b1fd4dd5
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
She disappeared between 15.2 and 16.0 but seems she is still alive. Commit
odoo/odoo@88483a6 does not seem to have been forward ported after 16.0.
closesodoo/odoo#151920
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If the user doesn't have rights to registrations and tries to change the partner
on a SO, this will raise an access error even if there's no registrations linked
to the SO.
We use sudo to be coherent with what is done in _update_registrations.
Followup of odoo/odoo@fb17edd coming from odoo/odoo@19878d0
X-original-commit: 808ceb2
Part-of: odoo/odoo#151920
orderpoint creation should also consider archived location
while computing qty_available or else users will be faced with
a `KeyError`
closesodoo/odoo#156965
X-original-commit: 1467cc1a2d773b8c7cbb4410c5c2f756764ca7c8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Some templates are rendering the blog post cover in a very blurry way.
It was not detected sooner because of a mix of:
- The default blog posts img do not go through the `/web/image` route
and are not resized down / impacted
- Some of the layouts are working fine
- For the problematic layouts, the problem gets worse when you select
only one or two "Fetched Elements".
Steps to reproduce:
- Add an image on a blog post (you can just download the one on the PR)
- Add a "Blog Posts" dynamic snippet on a page
- Select "Card Layout"
- By default, you'll see that the image is very blurry. If you select
2 (or 1) instead of 3 fetched elements, it will get even worse.
Note that it's like that since forever, when it was introduced with
https://github.com/odoo/odoo/commit/3c0d98bcd8adf9325ee3497eb8d25ec7f904d6a5
opw-3771992
opw-3758676
closesodoo/odoo#156962
X-original-commit: 7d817e950f9e7c18a504d8bff04e02efb9d9dbde
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
to reproduce:
=============
- make a task recureent
- change its state to a closing one
-> Validation Error
Problem:
========
- when creating the next occurence, we insert the followers of the original
task in the new one, but it happens that we create a `mail_followers` twice
which violates an SQL constraint of `mail_followers`.
https://github.com/odoo/odoo/blob/ea170be9089ee6c784664475ac4ec1218d23dccd/addons/mail/models/mail_thread.py#L253-L262
the create method will create `mail_followers` for the task and as the condition
that follows is truthy in this use-case `_insert_followers` will be called
and create `mail_followers` again.
- In previous versions we didn't face this issue because the creation of
occurences was done by a cron, so the condition was never truthy thanks to
`and self.env.user.active`.
Solution:
=========
to make sure the conditon stays falsy, we set `mail_create_nosubscribe`
in context to `True` when creating the next occurence.
opw-3742737
closesodoo/odoo#156945
X-original-commit: 64ca453bc36740ce4afcd46c1afbbb31abffdf7c
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
If the user has access to picking types as a stock manager without having access to pos config, deactivating a picking type triggers an AccessError on pos.config.
closesodoo/odoo#156820
X-original-commit: 743c70e8d4e753200411aeedc8482c374792b1d5
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, if the POS user didn't have access to the first
company, an access error would be raised when accessing the self-order
page. The steps to reproduce this issue are as follows:
1. Add another company and set up POS self-order.
2. Remove the other company from the Marc user.
3. Open the POS in the new company.
4. Try to access the mobile menu.
This would result in an access error.
The issue was that the first company existed in the
`allowed_company_ids` in the context. To solve this, we need to
correctly set the `allowed_company_ids` in the context.
opw-3744500
closesodoo/odoo#156357
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
To reproduce:
- Install l10n_it
- Go in settings
- Fiscal Localization => reload
- Go to the taxes
=> You will find taxes with [old] prefix
The issue comes that we want to consider that a tax has changed
if it has different repartition lines.
We don't consider taxes that are defined without repartition lines.
The template will have no lines, but the compute
on actual taxes will generate default ones.
It then considers that the tax has changed.
task-3777629
closesodoo/odoo#156974
X-original-commit: 55c09d3fab70d241174c44a9f3d123a01211730e
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Currently the progressbar computation are not contract-aware, we fix this here
task-3777971
closesodoo/odoo#156040
Related: odoo/enterprise#57902
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Current behavior:
Orders from a closed pos that were not invoiced are not taken into
account in the sales count (can be seen in the "Sales" smart button)
Steps to reproduce:
- Create a new product P1
- Sell this product in the PoS without invoicing it
- Close the PoS session
- Go to the "Sales" smart button of the product P1
- You will see that the sales count is not incremented
opw-3726153
closesodoo/odoo#156926
X-original-commit: a579d9f00b0a9bc51a872925ae41bc285ba3e155
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Don't try to keep extra params and co. Keep it simple...
Else we should pop from request.params `forum` and `post` keys because
now they are converted as query param with the slug format:
/forum/help-1/question-1?forum=forum.forum(1,)&question=forum.post(1,)
closesodoo/odoo#156910
X-original-commit: b62bd391ccf754da9411ca5e8bff9cfafeed2a66
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Before this commit, searching for a product in the product screen was
problematic when dealing with large databases. The search function was
triggered too frequently, leading to performance issues.
With this commit, I have increased the debounce time for the product
search. This reduces the frequency of search operations when user is
typing.
opw-3788796
closesodoo/odoo#156806
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Before this commit, when loading paid orders, the tracking number would
differ from the backend. This discrepancy was due to the fact that the
`pos_session_id` was being changed to the current session.
opw-3788982
closesodoo/odoo#156733
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Current behavior:
When in a spanish PoS, every order needs to be invoiced. If no customer
is specified, there is a default customer selected. But if the payment
method is split, the default customer should not be selected. And the
user should be asked for a customer.
Steps to reproduce:
- Install the l10n_es_pos module
- Go to PoS and create a new order
- Select a product and go to payment
- Select split payment (Customer Account)
- The default customer is selected, but you should be asked for a
customer
Note:
To fix this we use the same behavior as in the base PoS, where the user
is asked for a customer if the payment method is split. If no user is
selected after being asked for a customer, the default customer is
selected. If a user is selected, the user is sent back to the payment
screen, as it's done in the base PoS.
opw-3736293
closesodoo/odoo#156570
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Steps to reproduce [17.0]:
- Go to website (in "Edit" mode) > Click on the "Contact Us" button.
- Duplicate the CTA button ("Button options" > "Duplicate icon").
- There is no way to only remove the duplicated button, and the "Header"
> "Show/Hide Button" option will disable the whole CTA container.
After the website headers redesign in [1], a new feature was added to
allow users to select the elements they want to display in the header
(social links, call to action...). The CTA section was also marked as
'oe_unremovable' which disabled the option to remove it in the editor.
When a CTA button is duplicted, the clone will also be unremovable which
makes it impossible to remove.
The goal of this commit is to prevent the duplication of unremovable
buttons. It's always possible to add buttons by drag & dropping "Button"
snippets which are also removable.
Remark: Also after [1], two header navbars were added in the DOM (for
the desktop view and mobile). Which means that the CTA field is also
duplicated and every change on the CTA buttons in Desktop will be
reflected in the mobile version.
[1]: https://github.com/odoo/odoo/pull/119650
opw-3706902
closesodoo/odoo#156164
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since existing model AccountMoveLine and AccountTax where
lying under the same file which was bit hard to find, now
the AccountTax(account_tax.py) have seperate file and removes
the bad code from `account.move.line` which ends up removal
of the model from l10n_in
Part-of: odoo/odoo#153773
Now l10n_in_gst_treatment compute field will be depending
on invoice `state`, which will be helpful when any invoice
gets reset to draft
Adding testcases for partner fields on invoice which
tests the same with different usecase
Part-of: odoo/odoo#153773
The `course_publisher_standard` tour was missing slide (channel) tags.
We are replacing values used in the tour so that the tour
runs on the same data whether demo data is installed or not.
See runbot build errors 55762 and 55768.
Task-3744848
closesodoo/odoo#156797
X-original-commit: 7d614147bde737c69bed928c7c19d1ac3e7077c8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Florian Charlier (flch) <flch@odoo.com>
This pull request replaces https://github.com/odoo/odoo/pull/156598
Description of the issue/feature this PR addresses: It is necessary to be able to select document types "80 INFORME DIARIO DE CIERRE (ZETA) - CONTROLADORES FISCALES" and "83 TIQUE" in an invoice if the journal of the invoice has "Online Invoice" set on field "AFIP POS System".
Current behavior before PR:
User is not able to select document types "80 INFORME DIARIO DE CIERRE (ZETA) - CONTROLADORES FISCALES" and "83 TIQUE" in an invoice if the journal of the invoice has "Online Invoice" set on the field "AFIP POS System".
Desired behavior after PR is merged:
User is able to select document types "80 INFORME DIARIO DE CIERRE (ZETA) - CONTROLADORES FISCALES" and "83 TIQUE" in an invoice if the journal of the invoice has "Online Invoice" set on the field "AFIP POS System".
Task Adhoc side: 34790
Task latam: 1167
closesodoo/odoo#156830
X-original-commit: 9fcfaf65bd657e3fc07ff04c8b6b0371e801f2c8
Signed-off-by: Josse Colpaert <jco@odoo.com>
This commit is a follow-up on [1] which fixed the caching of restricted
editor which was accidentally shared with public users.
It introduces a test that verifies that this fix is not lost.
[1]: https://github.com/odoo/odoo/commit/821888023db462d522c5d6de84fcab80a81c2713
task-3482439
closesodoo/odoo#156795
X-original-commit: d1ca64498ce656a2d091121d73ab2a9b6d043549
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
When adding alias domain in v17 support of configuration parameter
was dropped. We moved from singleton configuration to multi domains
using real models.
This means most of mail support lies in mail while part of it was in base
beforehand. In some cases we want to let people do some basic
configuration using base module then install mail which could migrate
this ICP based configuration into new models. This is notably the case
with odoo.sh where mail is not always automatically installed.
Use case is: install base, do some configuration using ICP allowing notably
to setup website / server domains, main mail configuration, ... then let
people install modules on top of that configuration which generally
installs mail. With this change existing ir.config_parameters matching
pre v17 names are now used to bootstrap alias domain table at mail module
initialization.
Task-3789584
closesodoo/odoo#156654
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Unblocking a workcenter incurs a reload which is bad in terms of user experience for other applications like shop floor. And since the reload is no longer needed at any other part, it is removed now.
task-3629043
closesodoo/odoo#153036
Related: odoo/enterprise#52363
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Test the following flow:
Create 2 warehouses
create a stock rule (pull) and a route between the 2 stock location of those product
create a product having the route MTO and the new replenish route
create a delivery in the second warehouse
a transfer from the two warehouse should be created and linked to the
delivery
Open the forecast report for the warehouse that deliver the product
-> the delivery is marked as "Reserved from stock" instead of being
linked to the replenish transfer.
closesodoo/odoo#156821
X-original-commit: 776aa028cdb27047ebfb28d30fd79b6254fa362e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Screencast are not always enable and a recent change broke the ffmpeg
call. This call was already broken in some ffmpeg versions.
This test will help to ensure this feature continues to work, and will
also test it in different ffmpeg versions during distro builds.
closesodoo/odoo#156738
X-original-commit: a3d6ef64e218683f7455f60d20860b62780be3b9
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit
==================
In certain scenarios, when a new subsequent payment was initiated after the
initial payment was completed, an error message appeared stating,
**Payment is canceled due to inactivity**
Issue
=====
Failing to remove the previous inactivity timeout before establishing a new
one led to the aforementioned error.
With this commit
================
Explicitly clear previous timeouts before setting a new one to prevent potential
conflicts and ensure a clean timeout environment.
closesodoo/odoo#156430
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this commit when you create an event from a lead, a button appears to jump back to the lead but while you're creating the record, it already appears but empty.
This commit hides the button in case the res_model_name is null, which happens while we are creating the event and before hitting save.
closesodoo/odoo#154956
Task: 3747059
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
The account_qr_code_emv module has an issue at the
moment where it will only return errors in
_get_error_messages_for_qr for the country the qr
code is intended for.
This makes sense since you want to check all countries
in later versions where we have multiple of them.
But it causes an issue with the standard implementation
where if you are using a country that is not supported
by an EMV QR, _get_error_messages_for_qr will just
return None.
This means that:
- The default QR CODE selection on the invoice that
depends on that may select EMV QR for unrelated
countries.
- If it gets selected, this method will not check
that the currency is correct for said countries.
To fix this issue, we will simply return an error
message in the common module, which will serve as a
fallback once all the EMV QR methods have been checked.
Task id # 3758668
closesodoo/odoo#156847
X-original-commit: 5290fb7a2d400ce1c9732e8d835f6b7990c0d145
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
The widget for actionable errors does not update when the errors it
displays are updated due to, for example, a recomputation of the field.
This results in irrelevant errors being displayed in the view, when a
particular configuration is correct. The correct errors (or an absence
of any errors) will not be displayed until the view is refreshed.
This commit adapts the component, such that the record data is accessed
directly from the template. This means that the recordObserver, and the
method it uses can be removed (as they were redundant)
closesodoo/odoo#155914
Task-id: None
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Paolo Gatti (pgi)