Current behaviour:
Search filter is not showing correct results for projects that are in
overtime. Some projects that are not in overtime are not shown.
Expected behaviour:
Search filter for projects that are in overtime should work correctly.
Steps to reproduce:
- Install Project, Timesheets
- In one of the projects, create a task in an "In Progress" stage
- Add an employee on it, planned hours to 1h, and log in the
timesheet 50 hours (so the task is clearly in overtime of 49h)
- In that task, add an employee, planned hours to 50h
- In the same project, create a task in a folded stage, log in the
timesheet 1h (the task is +49h remaining hours in the green)
- Fold the stage when done editing the stage.
- In the project default view, we can clearly see that the project
is in the red (-49h).
- Filter based on overtime, the project is not present in the results
Reason for the problem:
There is a divergence of behaviour between the compute and the
search method of the `is_project_overtime` on the project.
The compute takes only the overtime of the tasks that are not in a
folded stage. While the search is query all the tasks of the project,
regardless of stage and summing those to deternine if the project is
in overtime. So if you have 2 tasks, one in a folded stage and the
other not, that have `remaining_hours` that are cancelling each other,
the search result is incorrect for that project
Fix:
Update the SQL query in the search method for `is_project_overtime`,
to reflect the domain conditions from the compute about the stages.
Affected versions:
- saas-15.2
- 16.0
- saas-16.1
- master
opw-3182077
closesodoo/odoo#116992
X-original-commit: 69f1441133e30b8dc0cc331afcec933d694665e0
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Issue:
Despite the behavior which is to recalculate the hours to keep
the same number of days from the point of view of the company,
when distributing allocations for a department,
an incomprehensible calculation appears.
This behavior appears even if all the working times are the same
(both for the company and for the employees).
Cause:
When we need to calculate the number of days for an allocation given in hours,
we use the number of hours per day of the employee.
However, in the case of an allocation by department, this value is `0.0`.
Therefore, we will use the hard-coded `HOURS_PER_DAY` value which is `8.0`.
This value makes sense if the company's schedule is 40 hours per week (8 hours per day).
It is also useful in the case of an undefined company's schedule.
But if the company schedule is defined and is different from 40 hours per week,
this value no longer represents anything.
Solution:
First use the number of hours from the point of view of the company
before using the hard-coded value.
opw-3205685
closesodoo/odoo#116991
X-original-commit: 6ddf340f0f19e1abd58ce8345bdc25763cb32878
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Current behavior:
If you create a product tracked by serial number and set an owner on the
product. If you make an order from the PoS with this product, the owner
wouldn't be set correctly on the picking created from the PoS.
Steps to reproduce:
- Create product A, tracked by serial number, storable, and available in
the PoS.
- Add some quantity of product A with an owner (e.g. "Owner A").
- Create a PoS order with product A.
- Validate the order.
- Close the PoS session, go to the picking created from the PoS order
there will not be any owner set on the picking.
opw-3206618
closesodoo/odoo#116919
X-original-commit: d6c44280eb8a86925392e87cf1a35bfe8b00177e
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Users without HR Officer rights would see an empty avatar for the
employees, as the m2x_avatar_fields were using `hr.employee` as model.
closesodoo/odoo#116972
X-original-commit: 3205680cf902e1b84900f28cfdda5528cbb37ae5
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In case we retrieve the maximum number of documents the IAP server
can send, we retrigger the cron to receive more documents, until
we get them all.
Parameter `recipient_codice_fiscale` wasn't used at all, download is
related to the proxy user which is determined by authentication on the
IAP proxy.
See odoo/iap-apps#583closesodoo/odoo#116927
X-original-commit: 43c9820b1d3020d89b1b7ca016754e29d1fc6b58
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Before this commit, when the "Create" button of a m2x is clicked and
an error is returned by the server, a form view dialog is opened to
create the record. We want to know if the error is caused by a missing
required field but not by any other type of error.
So we open the form view dialog only if the error is of type
ValidationError otherwise we display an error dialog.
closesodoo/odoo#116954
X-original-commit: 49bae69c602d1587fe159719667ff8dd0fb23984
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This is useful when using the owl dev tools to have a better feedback on
which app is which
closesodoo/odoo#116948
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since commit [1], which updates jQuery to version 3.6.3, when dropping a
dynamic snippet (Events, Blog Posts), it appears broken. This happens
because in jQuery 3.5.0, the `htmlPrefilter` function (which is called
when the dynamic snippet content is rendered) has been modified.
The dynamic snippets are broken because auto-closed tags are contained
in the data that are fetched from the server and without the jQuery
regex to fix them, they are never closed properly, which breaks the
rendering. Indeed, the `etree.tostring(...)` function auto-closes the
tags of elements having no content when no method is specified as a
parameter.
This commit prevents auto-closed tags to appear in the data sent by the
server when rendering the dynamic snippets, by enforcing the fact that
they will be used as HTML.
[1]: https://github.com/odoo/odoo/commit/ae1cd3d5bb99b9835501144522b71f152aaf8e34
task-3199318
closesodoo/odoo#116929
X-original-commit: f6cbec8d0116305041f018870ab63e26c8cbef41
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Current behavior:
When a fiscal position was applied in the PoS, it was considered as a
discount and was shown in the receipt and on the product screen.
Steps to reproduce:
- Create a product with a price of 10€ with 15% tax included in the
price
- Create a fiscal position that map the 15% tax to 0% tax
- Open a PoS session
- Add the product to the order
- Apply the fiscal position
- The price of the product is now 8.70€ but the order show it as a
discount of 1.30€ (e.g 10€ -> 8.70€).
opw-3154499
closesodoo/odoo#116918
X-original-commit: d054e7dd2474fad49dab63bf4b2aef09f57780c8
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
To reproduce the issue:
1. Change the language to french
2. Go to Accounting > Payment terms
3. Select one payment term
4. Look at the example section
5. Examples are in English
Error: The examples should have been in French
The sentence was hardcoded and not translatable
OPW-3203268
closesodoo/odoo#116883
X-original-commit: 7b244e71284d9bfb7186caa82f33f39902937b96
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Demany Antoine (ande) <ande@odoo.com>
When the template layout was made more mail-client friendly in 16.0
we used padding on a <td> node with
a color background to make it look like a button with centered text.
This approach makes most of the button unclickable.
The fix is to put the padding inside the link itself so that the whole
'button' is clickable. We already do this for most templates.
task-3168757
closesodoo/odoo#116945
X-original-commit: c40327db4f46040d4a6ed0231afcdefd5be47db5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
To reproduce:
- Go to Dashboards
- Select a long product name
-> The tag overflows
opw-3053801
closesodoo/odoo#116899
X-original-commit: 94897fa258322d02a91b57df7f896d17b514b093
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Before this commit, if you made a product to be tracked by unique
serial number and then make a sale order with hundreds of units
of the same product, each unit will make a separate line with qty = 1.
The issue is each serial makes a different `stock.move.line` and
`_get_commodities_from_stock_move_lines` groups by move lines, which
leads to the issue.
To solve the problem we need to group the move lines by product.
opw-3212809
closesodoo/odoo#116882
X-original-commit: 3c4a12bac1302c8e39dc2a1c617e6536c2d07d3d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Khanalizadeh Ahmad (khah) <khah@odoo.com>
Steps:
install calendar app.
enable sms template of calendar.
go to calendar event form view.
try to send SMS.
Issue:
traceback clicking `Send SMS' of Send SMS wizard.
Cause:
trying to write on field even though field does not
exist in model.
Fix:
check field exist in model before write on it.
task-3084701
closesodoo/odoo#114824
X-original-commit: b773006055f0c29e56b2719621e2abd80af6b9e7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
before this commit, for the company_id field
the user groups given was base.main_company,
such a group is not existing in the system
after this commit, the group will be changed
to base.group_multi_company from base.main_company
closesodoo/odoo#116939
X-original-commit: e259a33b0bff33005bc119838c517aec804695ae
Related: odoo/enterprise#38942
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, the "Card" payment method would always be shown on
Stripe's hosted checkout form, even if there is no related payment icon
(VISA, MasterCard, Discover, American Express) set as "supported payment
icon" in Odoo.
After this commit, Stripe is instructed to hide the "Card" payment
method if all related payment icons are unset in Odoo. If at least one
related payment icon is set, the "Card" payment method is hidden. If the
"Supported payment icons" field is left completely empty, all payment
methods are available on Stripe.
closesodoo/odoo#116917
X-original-commit: d7e96a771e92020938658cdd4dc4a41c45f1644e
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The operator =? is recognized by expression.py as a valid operator but
was not recognized by the Domain class (see the method "contains") as
such.
closesodoo/odoo#116914
X-original-commit: b6495bd51295c513ab0d5c083560ac3a1236bd4f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps:
- In the global settings:
- Activate Comparison Price (group_product_price_comparison)
- Put Line Subtotals Tax Display to “Tax Included”
- Go to a product (e.g. Customizable Desk)
- Set Compare to Price to a higher price than the sales price
- Set a Customer Tax
- Go to the shop on the website
Issue:
The crossed-out price is not the same in the product list page and in the product detail page.
Cause:
No condition of the application of the tax on base_price.
Similar to: https://github.com/odoo/odoo/pull/113108/commits/8b7595deace98da26ee016ca565776ffd537284c
opw-3199343
closesodoo/odoo#116821
X-original-commit: b58014d87d9e7b9520ec8aff35395ec3d921c36e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Djoumatchoua Eteil Junior (etdj) <etdj@odoo.com>
Before this commit, in a list view, the style of a decoration on a m2o
widget was ignored. For example, when applying the danger decoration,
we want the m2o field to be in red.
How to reproduce:
Go to a list view with a field having the many2one widget and
a danger-decoration.
Have a line that respects the decoration condition.
Before this commit:
m2o field text uses its base colour (blue)
After this commit:
m2o field text uses the colour red for danger decoration
closes odoo/odoo#116621
Forward-port-of: #115831
X-original-commit: 9e0eac2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: project,utm
**Before this commit**
With the following steps, it is possible to use kanban column quick
creation with unexpected fields, i.e. creating projects instead of
stages inside a project:
- Project > New > Groupby 'Project'
- Click on the "see examples" link in the column in creation
- Apply any column examples
- Instead of stages inside the project, new projects are created
**After this commit**
The kanban_examples registry elements should now clearly
state which are the allowed groupby fields.
The 'See examples' link will not be displayed if the groupby field
is not allowed.
**Usage**
See the modified files in project and utm modules in this commit.
Taskid: 3246042
Part-of: odoo/odoo#115909
*: crm
Before this commit, the KanbanColumnQuickCreate receives
the groupByFieldString property as a string.
This commit changes that in order to give the groupByField object.
This change eases the further work in same pull request.
Taskid: 3246042
Part-of: odoo/odoo#115909
When passing the customer data to adyen to execute a payment an error occurred if the address did not follow a pattern that might be
unkown to the customer.
This fix allows for the user to be aware of what the issue is through
the logs and inform the customer if necessary.
opw - 3171407
closesodoo/odoo#116936
X-original-commit: 66716551f1f75d228876b49cda9fd92732756afc
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
Activate avatax.
Create a contact [1], and validate it with avatax.
Create a product A, priced 11.70, add avatax code [P0000000]
Create a product B, priced 9.85, add avatax code [FR000000]
Create an invoice, add the two products, set avatax fiscal position
Compute taxes with avalara, taxes will be 0.73
Confirm invoice
Taxes will update to 1.35. This occurs during `_post`:
when invoice date is set, invoice sync will recompute taxes
for all lines.
[1]
Client Avatax-test
133 Route 20
North Oxford MA 01537-1210
United States
opw-3174739
closesodoo/odoo#116872
X-original-commit: 7e399b0eb4daa5151eba59a65bc649d453ca6883
Related: odoo/enterprise#38908
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
Before this commit, the notebook tabs were skipped when navigating with
the keyboard tab or shift+tab keyboard shortcuts. This commit simply
modify the tabindex to 0, so they are not ignored.
Users can now move through the tabs with the tab key, and press enter to
activate a specific tab.
Note that there is not tests because that kind of user interaction cannot
be simulated from the js code
closes odoo/odoo#116874
Task: #2622077
X-original-commit: 1a9a4aef728b406b4c3a1c99cb66e3fc4fd4ff52
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps to reproduce the issue:
1. Install modules "point_of_sale", "sale", and "account_accountant"
2. Create a user with only "Point Of Sale User" and "Sales User: Own
Documents Only" access
3. Open a point of sale session and input a different opening amount
=> This resulted in incorrect information being displayed in the
"Closing Control"
opw-3188250
closesodoo/odoo#116877
X-original-commit: dc494bc8e68ddde361e0f73b4b2593a59fdeccba
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
**To Reproduce**
- Calendar > Month View > Create Many Events the same day
- Click on "+x more" link: will open fc popover
- Click on an event: will open owl popover
- Click somewhere in owl popover
**Before this commit**
Both the popovers will close and nothing happen
**After this commit**
It works.
closesodoo/odoo#116912
Taskid: 3246033
X-original-commit: 7ee230d9ecf3678ef4246b81783fedaf82119a53
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Will be reintroduced properly afterward. Currently, even if the
field is defined using ondelete='set null', the M2M relation
doesn't handle the fact that the target table is a real model
and not a simple relational table.
closesodoo/odoo#116880
X-original-commit: f58d2ad669710a353263e418bbf69f5f49145cac
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Changeset #115803 tried to reduce issues regarding the statusbar
chevrons wrapping in an ugly fashion when the number of buttons increase
in the header.
Unfortunately, this has side-effect in other cases which actually
degrade the experience.
This commit removes most of that changeset, with the exception of
keeping the -flex-wrap on header buttons - it's better to break the list
of buttons over 2 lines than breaking the buttons themselves into 2
lines.
Follow-up of Task-3215622
closesodoo/odoo#116857
X-original-commit: bc5aebfca3c4b2f67e235b9e0bbdba6fd58140dd
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Some nightly builds failed due to the hardcoded id present in the `test_order_refund_with_owner`.
closesodoo/odoo#116856
X-original-commit: 9c924888635045a34b1d8521c253f9dda83946bf
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Invalid taxes could lead to invalid results from the
`_prepare_edi_tax_details` fonction. For instance: a tax without tax
repartition lines will be disregarded, which in turns leads to an
invalid xml being generated.
opw-3175701
closesodoo/odoo#116855
X-original-commit: 22b18a17348be6bd3982cbffd31da383442a6433
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
list view
In some occasions, we want to be able to download all edi documents so
the user can upload them on a governemental platform. From the list view
of all the invoice, it is now possible to selected as many invoice as we
want, and with a newly added action download them into a zip.
task-3122424
closesodoo/odoo#116854
X-original-commit: 5171f607e1fddde06b769ebb78d82548ad4dc84d
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Before this commit, tour may end before emojis are loaded.
This results in following crash:
```
Trying to set result to failed (AssetsLoadingError: The loading of /web/assets/3949-d14fea7/mail.assets_emoji.min.js failed
at HTMLScriptElement.<anonymous> (http://127.0.0.1:8069/web/assets/3709-a5ab371/mail.assets_public.min.js:7008:270)) but found the future settled (<Future at 0x7fee7552a410 state=finished returned bool>)
```
This commit hides the crash in case the loading of emoji fail,
and instead show emoji picker without any emoji.
Fix runbot issue 19877
closesodoo/odoo#116845
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
Current behavior:
When no account is set on a product category, you cannot close a POS
session. This happens because we are not using the default account set
on the POS journal in this case.
Steps to reproduce:
- Create product A, and product category B that has no account set on it
- Open a POS session, add product A. Validate the order
- Close the POS session, you will get an error message.
opw-3178181
closesodoo/odoo#116838
X-original-commit: 18be148083ebce27154452bef7aa2620e68f18f0
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Current behavior:
If you apply a discount on a product, the PoS ui will show the old price
without taxes.
Steps to reproduce:
- Install PoS and l10n_fr_pos_cert
- Create a product with a price of 100€ and a tax of 20%
- Create a pricelist with another price for the product (e.g. 80€)
- Open a PoS session
- Add the product to the order
- Apply the pricelist
- It show the old price as 100€ instead of 120€ (100€ + 20% tax)
opw-3211796
closesodoo/odoo#116836
X-original-commit: e5549d7a9962d92b1abc79d416c3c47303e06134
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
In the current tour steps, there's ambiguity in the failing step and its
preceding steps. Basically, the failing step asks to click a selection item
that contains "Monitor Stand" and the previous step also do the same: clicking a
selection item with "Free Product - [Desk Pad, Monitor Stand]". And if you
notice, both step has text "Monitor Stand". Given the nature of the tour runner,
it will try as fast as it could to do the steps, so it will click "Free Product
- [Desk Pad, Monitor Stand]" then it will immediately be followed by clicking
"Monitor Stand" which is the same element clicked by the previous step. In
essence, the two steps only resulted in one action.
As a solution, we make sure to distinguish the first step of selecting
the reward program, followed by selecting the reward product.
We use the fact that a second span under `.selection-item` will be rendered
when displaying the program selection, therefore, we introduce an
extra_trigger in first step (provided by `claimReward` helper function).
Then, we add more steps that checks the selection items on the expected
2nd selection popup.
closesodoo/odoo#116819
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Register a ph contact with vat 123-456-789-012
Validation Error will raise
Currently we use check the PH vat against regexp \d{3}-\d{3}-\d{3}-\d{5}
This seems to be not correct according to the official documentation
https://serp-p.pids.gov.ph/publication/public/view?slug=taxpayer-identification-number-tin-its-development-and-importance-in-tax-administration
"""
12 digit number (E.g. 123 456 789 002), of which the first digit
identifies type of taxpayer (0 for corporations, 1-9 for individuals
and other businesses), second to eighth digits are sequential numbers
between 0 and 9, ninth digit is a check number, last three digits are
000 for individuals and head office of businesses and 001-999 for
branches of businesses, if any
"""
The TIN should be a 9 digit code + 3 for the branch code
opw-3141793
closesodoo/odoo#116491
X-original-commit: f0e9a3ce7fec9bb86b8703a6d49c0bc70c80d5c3
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
`PartnerRoot` is a confusing name for what is in fact what everyone call `odoobot`
closesodoo/odoo#116823
Signed-off-by: Debondt Didier (did) <did@odoo.com>
This commit mocks the "preference_save" action on the res.users model during
the test that checks that the user can modify its own preferences.
This allows to ease the testing as a context reload in the middle of test steps
was not handled correctly by the test runner.
Task-3246086
closesodoo/odoo#116800
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since commit 2ecfed335d, m2x_tags_avatar
are based on dynamic.readonly to know if they are readonly or not. This
is a mistake, the only information that depends on dynamic.readonly is
the presence or absence of the popover.
In this commit, we'll set the initial value to readonly and add the
isEditable props that will tell iif you can delete or add records with
the popover.
closesodoo/odoo#116782
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Exporting Kenyan invoices in a format readable by the Kenyan fiscal
device creates some complex output. The data is significantly modified
in order to represent an odoo invoice in the native format of the
communication with the device (for instance global discount lines must
be distrubuted accross the existing positive lines of the invoice, since
the device is incapable of representing negative lines).
This commit adds a series of tests designed to ensure the format of the
export is correct, and that the values of these invoices are
represented in a way that best reflects the data on the invoice, whist
being readable by the device.
closesodoo/odoo#116615
X-original-commit: dec8e7e3fefc8e00b916f4be9227a789c2a40b65
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
When both the price and quantity are negative, this creates a few
problems that the serialisation code does not handle appropriately.
Firstly, the device does not accept negative values for price or
quantity. Price and quantity should therefore always be positive. In the
case where both the price and the quantity are negative, the line is
positive, and we must therefore processes it in the same manner as
positive lines.
A line with both negative and price and quantity should qualify as a
line that, when negative lines are present, can be subtracted from in
order to represent a discount.
This commit adapts the serialisation function in order to correctly
represent a negative price and quantity line as positive (by using the
absolute values of each). It also adapts the discount line code in order
to recognize these lines as candidate lines for discount.
X-original-commit: db774ac144e760e23d4a032971c64e2010486325
Part-of: odoo/odoo#116615
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 commit, we change the taxes name so that it's more clear and consistent for the users
closesodoo/odoo#116384
Task-id: 3052677
Signed-off-by: Quentin De Paoli <qdp@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 commit, we change the taxes name so that it's more clear and consistent for the users
Task-id: 3052677
Part-of: odoo/odoo#116384
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 commit, we change the taxes name so that it's more clear and consistent for the users
Task-id: 3052677
Part-of: odoo/odoo#116384
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 commit, we change the taxes name so that it's more clear and consistent for the users
Task-id: 3052677
Part-of: odoo/odoo#116384
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 commit, we change the taxes name so that it's more clear and consistent for the users
Task-id: 3052677
Part-of: odoo/odoo#116384
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 commit, we change the taxes name so that it's more clear and consistent for the users
Task-id: 3052677
Part-of: odoo/odoo#116384
Victor Piryns (pivi)