- Add 16 document type for "in invoices" when partner type identification is RUC.
closesodoo/odoo#119870
X-original-commit: d5a1a1aa8c7e3af8bc07da90cd7aa39e2d0fd931
Signed-off-by: Josse Colpaert <jco@odoo.com>
Co-authored-by: Andres Calle <andres.calle@trescloud.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115525
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115483
Task-id: 3052677
Related: odoo/enterprise#38286
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115324
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
AttributeError "account.move.line" object has no attribute "purchase_line_id"
occurs in `stock_account` when we confirm vendor BILL or REFUND with product
costing method "first in first out" or "average cost".
With the recent reflacted changes in commit[1], the `purchase_line_id`
field is used and it belongs to `purchase`, but it is not installed and does
not depend, so it causes an error.
The above issue is solved by removing some code in commit[1] from
`stock_account` and adding it to `purchase_stock`.
committ[1] - https://github.com/odoo/odoo/pull/99411/commits/e9ce88a9372843abef7cf8fc94c4dbe5f16c5fa3#diff-e6134a1a5a13058e35f86426a96db0acac44553fa3b0ca26716390f7b19fc96cR318
sentry-3975529425
closesodoo/odoo#121070
X-original-commit: 23ba3c6684e388bcfe317e7ab9f4c9008622e2b4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Ansari Mahamadasif (maan) <maan@odoo.com>
the error will occur when adding more than one attachment to draft invoice
chatter and click on send button.
applying these changes will resolve this issue.
sentry-4059207297
closesodoo/odoo#120238
X-original-commit: a2fcf96df23a7eea7ff9ddb94798e8375590ae28
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Smit Nagar (smna) <smna@odoo.com>
Enable floor plan for all PoS Restaurant config. To accomplish this, we are
removing the following fields:
- `pos.config.is_table_management`
- `res.config.settings.pos_is_table_management`.
All access to `is_table_management` can be replaced by `module_pos_restaurant`
because originally, `is_table_management` can only be true if
`module_pos_restaurant` is true.
To adapt the tests, we should manually set `module_pos_restaurant` to `False` for
the `pos.config` used in tests outside `pos_restaurant` addon. This is because
when pos_restaurant addon is installed, it sets every new `pos.config` record to
be restaurant by default.
Task-3282975
closesodoo/odoo#120117
Related: odoo/enterprise#40532
Related: odoo/upgrade#4622
Signed-off-by: Monnom David (moda) <moda@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115543
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
This pr also correct an error in two taxes.
closesodoo/odoo#115367
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115321
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#114825
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#114790
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#114741
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes names so that it's more clear for users
closesodoo/odoo#114638
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
For a strange reason, some bug where revealed in this tour with this
pull request.
closesodoo/odoo#121103
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since 16.0's 0501bbd62e fields with groups are now removed from the view
instead of being set as invisible.
Scenario:
- template user has group "Access to export feature"
- create a new user while being in debug=0 mode
- save
=> the users don't have the group "Access to export feature" set,
because the corresponding field is not in the view. If the same scenario
was done in debug=1 mode, we would get the group set.
Solution: duplicate the field that are inside base.group_no_one section
and have them be invisible if someone is not in debug mode.
note: before the fix, added assert fails because there is missing groups
in the newly created user.
closesodoo/odoo#121097
Note: issue observed when working on another ticket
X-original-commit: 9deb1e6aa902a09c4fd6a91ecbd34a89b9c98f98
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When triggering the CRON "Sale Subscription: generate recurring invoices
and payments", invoices are created from subscriptions, the emails and
xml attachments are sent to the recipients.
Similarly, the CRON "automatic invoicing: send ready invoice" should go
through the Send and Print wizard to be able to create the xml
attachments.
task-3299540
closesodoo/odoo#121075
X-original-commit: 79770f1b5abc79bcf0feb12b4316fc864ba291dd
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
While creating a new product in product category with barcode value in inventory
module, `_check_barcode_uniqueness` method is called. In which variable 'domain'
is passed, and getting wrong value.
Steps to Produce:-
1) Go to Inventory then configuration
2) Click on 'Product Categories' under products
3) Click/Create Product Category
4) Click stat button 'product'
5) Create a product
6) Then add barcode value
7) Click on Save
8) Trace-back will be generated
Reason:-
While creating new product from product category when user add the barcode value
in product form, the '_check_barcode_uniqueness' method is called. In this
method the value of 'domain' is getting updated by reference from variable
'domain' from method '_search' present in the same model.
This results in a traceback with the message
'Invalid field product.packaging.categ_id'.
Applying these changes will resolve this issue.
sentry - 4073963761
closesodoo/odoo#121072
X-original-commit: ce9889e314ae696773ce040f662569e281abe700
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#115224
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#114811
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#114705
Task-id: 3052677
Related: odoo/enterprise#37953
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes names so that it's more clear for users
closesodoo/odoo#114590
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
When sending email with gift card, it will have the user langauge and not the partner language
Steps to reproduce the error :
1- Add french and english language
2- Make the current language english
3- Install contact and sales and activate gift cards
4- create a contact having french language
5- create a gift card for the french partner and send it to him
6- the email will be in english lang
The origin of the problem was the missing lang field in the template
opw-3308919
closesodoo/odoo#121086
X-original-commit: f09ac453aa7cffe1e31f30b68fa0665ef504283a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Related enterprise PR: odoo/enterprise#39669
Steps to reproduce:
Install mrp_workorder
Create Product P1, Workcenter W1
Edit W1 > Specific capacities > Add line: Product = P1, Start time = 5, End time = 5
Create BoM > Product: P1, Operations tab > Add line: Workcenter = WC1, Default duration = 60:00 min > Save
Click on overview stat button
Issue:
The created operation has expected time of 60:00, instead of 70:00. The workcenter start and stop times are considered in this calculation, so the workcenter capacities should be considered too.
Solution:
Use `_get_expected_duration` to compute the expected duration.
opw-3229485
closesodoo/odoo#121060
X-original-commit: 7b5a30fb3e51434154050052ec39ed299c6094d3
Related: odoo/enterprise#40905
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, the date/datetime/daterange fields only allowed for
an optional end date field. This meant that the primary date was always
the start date.
This commit allows the field to do the opposite: with the primary date
being the end date, and having a `start_date_field` option for an
optional start date.
closesodoo/odoo#120695
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
*: mass_mailing_themes, website_mass_mailing
This commit adds TikTok to the already existing social networks in all
email marketing templates (droppable blocks and default mail templates).
task-3235451
closesodoo/odoo#116837
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
*: website, website_blog, website_event
This commit adds the TikTok social network to the other social networks
stored in DB. Thus, users of the Website application will be able to
reference their TikTok page on their websites. This commit also updates
the different templates and the social media block to integrate this new
social network.
task-3235451
Part-of: odoo/odoo#116837
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116371
Task-id: 3052677
Signed-off-by: John Laterre (jol) <jol@odoo.com>
When receiving an email on a mailbox with an alias that triggers the
creation of invoices, 4 bugs could occur.
1. If the xml received contains replacement characters (U+FFFD �), and
the charset of the part of the email is "US-ASCII" the encoding of the
string will fail, preventing the rest of the flow to be completed. Be
more resilient, encode the string and ignores these characters if this
case occurs.
NB: sometimes, the charset is omitted for a Content-type: text/xml. This
is valid but not recommended (see:
https://www.ietf.org/rfc/rfc2376.txt). In this case, the default used is
"US-ASCII". This means that any non-ascii char will be lost (they are
replaced by the replacement character: �, see:
https://github.com/python/cpython/blob/3.10/Lib/email/contentmanager.py#L67)
when decoding the attachment.
2. When the xml attachment is created in Odoo, the mimetype is
'text/plain' (rather than 'application/xml'). Thus, the
`_decode_attachment` needs to be more flexible when guessing the type of
the attachment (to know which function to use to read the content of the
attachment and create the invoice).
3. When creating an invoice from an email with an xml attachment, the
xml is attached as the `message_main_attachment_id`. It's only later on
that the content of the xml is read and we possibly find the PDF in
base64 inside. When creating the PDF attachment, it was not set as the
`message_main_attachment_id`, so the PDF was not rendered on the right
part of the invoice form view. Add a clause to replace the
`message_main_attachment_id` in such a case.
4. When the xml attachment represents a credit note, the move_type of
the invoice created by the email alias needs to be changed. Indeed, the
invoice is created before decoding the attachment, so we can only change
the `move_type` later.
opw-3144519
opw-3149649
closesodoo/odoo#121076
X-original-commit: 1e193a92b9c84e75b958985f8067873b90f686e0
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Due to numerous client complaining about their automated scanner not
seeing the CSP header on the http request, we add it for good mesures
opw-2793379
closesodoo/odoo#121098
X-original-commit: 70a54ac604cf2aeef33d11b95851e35dd463727f
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Prevent crashing when there is no VAT for an autralian partner for A-NZ
Bis Billing 3.0.
closesodoo/odoo#121093
X-original-commit: 58efba364364e7d040bc8b9bf5fb2fb897d7cb30
Signed-off-by: Laurent Smet <las@odoo.com>
Based on Allegro-IT's PR https://github.com/odoo/odoo/pull/112159
with several adjustments and fixes (renamed XMLIDs, taxes, fiscal
positions, VAT report).
closesodoo/odoo#121073
X-original-commit: 815a817ff53760d57f978fd88b529a8b38bda62d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Readonly email fields break the layout if the value is long enough
Steps to reproduce:
1. Install CRM and Studio
2. Go to CRM and open any lead
3. Change the lead email and make it too large for the field size
4. Toggle Studio, in the View tab, uncheck 'Can Edit'
5. Close Studio
6. The email overflows its expected position
Solution:
Put the email field inside a grid layout div
opw-3248361
closesodoo/odoo#121020
X-original-commit: 855e72af9907cbfdcf1a0debd8011be9934eeb8f
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
on clicking the graph view of the Partnership Analysis, currently the tree
view and form view is opened. actually the tree and form view for this model
are not defined in the code and thus the end user get the tree view with only
ID field in it.
As those view have no sense, prevent from jumping on those.
closesodoo/odoo#121007
X-original-commit: 82a9900633b2cfc98d1d96146645646f0d5d70d2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, a test spawning a datetime field in an editable list
view would crash randomly based on the assertion that a datepicker
should not be in the DOM after clicking on that field.
This is wrong however since a click triggers a focus, which is the
condition for the picker to open, althouth this mostly happens after an
additional animation frame because of the way the list works (field
becomes editable on next render -> picker then opens on next render).
This commit adds a nextTick delay after clicking on the cell to restore
the intended behaviour, which is to wait for the picker to open.
closesodoo/odoo#120999
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
When one customize a course by adding the 'buy now'
button. Both the 'Add to cart' and 'Buy now' button
doesn't fill the container width.
This commit fix this by changing 'btn-block' class
by 'd-block'.
See commit eee625bbb0
Task-3299234
closesodoo/odoo#120986
X-original-commit: 77d8bc4e9ed5925967294e89440cf667b26b4cbf
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- Connect with the company A
- Create a consumable product “P1”
- Create a receipt transfer with this product
- confirm the transfer
- Come back to the product form
- limiter le produit que a la “Company B”
Problem:
no user error triggered
Go to inventory > operation > transfer: a Traceback is triggered
Before this commit, there is no verification while changing a product's
company for consumable. That can lead to an issue where some operations
cannot be done because of access errors. To avoid that, this commit
prevents to change the product's company if some move lines for this
product exist in another company.
opw-3300559
closesodoo/odoo#120983
X-original-commit: a6666de7f492f9f94abc23a080134dd473d0dddc
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Issue 1: before this patch it was impossible to create a manual model
marked as "Is blacklist". The reason is that a blacklist model
implicitly need an `email` field, but such field is impossible to add in
a manual model: the field must start with `x_`.
Solution: append `x_` to the implicit email field. Note, in principle
the user gets an error if `x_email` is not present. Solved by adding the
field when creating the custom model. Ideally we should show some hint
in the interface to make it more user friendly. That is out of the scope
of this patch.
Issue 2: when we have a manual model that is mail blacklist it's
impossible to create its model class. We get an error because the MRO is
not correct. The reason is that we are adding `mail.thread.blacklist`
_after_ `mail.thread` in the `_inherit` list. That list is used to
generated the `__bases__` of the model class[1]. According to Python's
MRO rules[2], since `mail.thread.blacklist` appears after `mail.thread`
as parents of the custom model class this order _must_ be respected. But
`mail.thread` must appear _before_ `mail.thread.blacklist` because the
latter inherits from the former. This is a contradiction and the MRO
algorithm cannot succeed. To put it in a simple example:
```py
class A: pass
class B(A): pass
# This fails:
# class C(A, B): pass
# The right order is:
class C(B, A): pass
# Equivalent to:
class D(B): pass
# C and D have the same MRO linearization excluding themselves
assert D.mro()[1:] == C.mro()[1:]
```
Example traceback:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1201, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 464, in load_modules
registry.setup_models(cr)
File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 263, in setup_models
env['ir.model']._add_manual_models()
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/ir_model.py", line 430, in _add_manual_models
Model = model_class._build_model(self.pool, cr)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 585, in _build_model
ModelClass.__bases__ = tuple(bases)
TypeError: Cannot create a consistent method resolution
order (MRO) for bases BaseModel, mail.thread, mail.thread.blacklist, base
```
Solution: check if a model inherits from `mail.thread.blacklist` first.
There is no need to add `mail.thread` if inheriting
`mail.thread.blacklist` because the inheritance is already implicit.
This issue was observed during upgrades. We convert custom models and
fields into manual to allow upgrading without custom code. This causes
issues because the MRO error appears when a custom model inherits mail
blacklist.
[1]: https://github.com/odoo/odoo/blob/02f820fb0eaddbb3a4269a0967184c8aaf52c363/odoo/models.py#L585
[2]: https://www.python.org/download/releases/2.3/mro/closesodoo/odoo#120977
X-original-commit: 8848bb57ff7f086d801178c582d7f6371eeb8479
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
In delivery address, `country name` and in shipping method, `country name`
will be same and no zip in delivery address. While creating new sale order
along with product and clicking on "Add shipping", error will be generated.
Steps to Reproduce
-Install `sale_management' and 'delivery' modules
-Go to the settings and enable the 'Customer Address'.
-Go to the settings and enable 'Shipping Methods' and configure it.
-Select a shipping method and go to the 'Destination Availability' tab and
set to the 'Countries' and set to 'Zip Prefixes'.
-Create a new customer and add the delivery address of the customer in
res.partner.
-The delivery address and shipping method of the 'Countries" or 'Country'
name should be the same.
-Set the 'Zip Prefixes'
-Set the delivery address of zip code null.
-Create a new quotation and add to the customer and delivery address
-Add to the product in the sale order line.
-Click on the 'Add Shipping' or 'Update Shipping Cost' button.
A trace back will be generated.
Applying this commit will resolve this issue.
sentry-4147077852
closesodoo/odoo#120968
X-original-commit: 60d5c7d5668da542e251d7d6fb8774043cfddea8
Signed-off-by: Tiffany Chang <tic@odoo.com>
Partial revert of b15116179e71040ffa01bb35161e32b16aac477d .
This fix introduced a new bug: when creating an write-off with taxes from the bank reconciliation widget, signs were all inverted in the tax report, because that commit was forcing the values of tax_tax_invert in a wrong way.
The proper fix is to fix the computation of the is_refund field in community, so that negative repartition lines are taken into account ("debit" is a refund for a "sales" tax only for positive repartition lines, for example).
Community part is in https://github.com/odoo/odoo/pull/120152closesodoo/odoo#120924
X-original-commit: 67e789074cb00b9db6e3fd83ef92ed712b28edfb
Related: odoo/enterprise#40856
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Cash basis taxes use a distinct transition account on their tax lines; the tax account set on the repartition lines is only used when the payment is received, on the cash basis move.
In enterprise, the bank reconciliation widget allows setting a tax on the manual write-off done for a statement line. When doing so, we expect the tax to behave just like on an invoice. For cash basis taxes, this means the "final" tax account has to be used instead of the transition one ; it wasn't the case.
OPW 3255511
X-original-commit: 991fa46081296c3560bd7ca195996693a81a46b8
Part-of: odoo/odoo#120924
Before this commit, the Order button wasn't displayed due to an
incorrect comparison with a `LazyTranslatedString` object
(`this.props.actionName`). This commit resolves the issue by ensuring
proper comparison of `this.props.actionType` with the string "payment".
Step to reproduce:
- create a pos_config (bar)
- active a printer on it
- open the PoS bar
- select a table and add some product
- The orderline are green but there's not order button.
opw-3300533
closesodoo/odoo#120846
X-original-commit: a04f8ebdfb724c74531f38927a655e6aae86bc26
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allows for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116381
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allows for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116379
Task-id: 3052677
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allows for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116377
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allows for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes name so that it's more clear for the users
closesodoo/odoo#116374
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
