Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
SPEC 1: prepare all tracking values at same code place
Delegate all computation of tracking values into the 'create_tracking_values'
method. Curently part of it (currency field) is done in the caller. Better
split code per feature.
Method is also made private, as it is not required to expose it.
SPEC 2: cleanup tracking value formatting methods and calls
Code used to display tracking value can be simplified: remove unnecessary
wrappers, make code easier to read, avoid composition of field name but
use a mapping instead (easier to grep 'old_value_char' when it is effectively
used).
Ensure code always calls '_tracking_value_format' to ease future improvements
and have all formatting code being batch-enabled.
SPEC 3: simplify Chatter formatted value structure
'fieldType' is currently added in old and new values. As it is a field
property it can be moved higher in the formatting result to be included
only once. Also add 'fieldName', the column name, to the formatted results
as it will soon help various tool methods. Moreover it makes sense to have
the source of the tracking as the real column name, in addition to its
string and type.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
Problem
---------
In master, XML attributes have been modifed from attrs={'invisible':...}
to invisible=. During the conversion, the condition where not properly
cleaned up.
Objective
---------
Clean up the XML attributes.
Solution
---------
Reduce conditions by removing unecessary elements:
- `fiscal_country_codes` always returns at least an empty string.
- All country codes are in capital letters, no need to `lower` them.
task-3493124
closesodoo/odoo#134329
Related: odoo/enterprise#46920
Signed-off-by: Josse Colpaert <jco@odoo.com>
before this commit, _compute_amount_total_words function
is defined twice in account and l10n_in module with a
difference of ',' in the generated amount word
after this commit, _compute_amount_total_words function
from l10n_in module is removed as there is no legal
need in india of having ',' in it
closesodoo/odoo#134892
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
These changes are made as a result of simplifying attrs and 'states' in
views.
Before applying the migration script, it is necessary to fix some views.
These views are erroneous and either work by chance or are simply
untested. We have for example wrong domains, elements used by modifiers
but not present in the view, obsolete domain operators, inherit views
not targeting the right views, xpaths using attributes as target, the
use of %(...)s in views, false attribute value types in python.
Part-of: odoo/odoo#104741
These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
The default taxes for most localisations have been left undefined by
default. When loading the chart template, the model generally selects
the first sales and purchase taxes, based on the order in which the
taxes appear in the csv, for the default sales and purchase taxes
respectively.
This behaviour can be confusing to those who are not yet familiar with
it. It has been decided that it is preferable instead to specify the
default tax in _get_*_res_company function on the account chart template
model, such that the default taxes are defined explicitly for every
localisation.
task-3453997
closesodoo/odoo#130733
Related: odoo/enterprise#45531
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit
==================
COA for CGST-SGST, IGST, CESS & RC Tax was not properly set in the distribution
for refunds.
After this commit
=================
COA for CGST-SGST, IGST, CESS & RC Tax in the distribution for refunds has been
updated according to the attached spreadsheet.
task - 3284312
closesodoo/odoo#131595
X-original-commit: 6a67b7055c2c53fae2462c70cb5899f372365661
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Problem
---------
During the conversion from XML to CSV, some python taxes were broken.
Objective
---------
The task consist in checking all python taxes and ensures it's working.
Solution
---------
Problem appears to be that the migration script from XML to CSV, removed
the '\n' in the python compute code, making things like
`result=base_amount * 0.21tax=quantity * 4.17` appear.
The solution consists in separating the operations using semi-colons and
a ternary operator to execute the if statement. The goal was to keep the
operations in a single line to avoid added escape caracters.
task-3319164
closesodoo/odoo#130792
X-original-commit: 2beea5f14a3886c5da9e81ccb8797141e7d7a186
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Antoine Boonen (aboo) <aboo@odoo.com>
For Mexican localization, activate by default the setting display_invoice_amount_total_words for the Mexican localization. As this localization uses its own amount to words function, the related commit enables an override of the generic function to use it correctly with Mexican localization.
For the other mentioned localizations (ua,in,dz,ma), the setting was already activated but overriding the create method was not a proper way of doing.
task - 3367243
closesodoo/odoo#124909
X-original-commit: 6ee9842764e0b1244927cb8ece1f6407ccec20d5
Related: odoo/enterprise#42510
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: hupo-odoo <hupo@odoo.com>
* l10n_ae, l10n_ar, l10n_at, l10n_au, l10n_bg, l10n_br, l10n_ch,
l10n_cl, l10n_dk, l10n_es, l10n_hu, l10n_in, l10n_mn, l10n_nl, l10n_no,
l10n_pt, l10n_sa, l10n_se, l10n_sg, l10n_si, l10n_uk
Some localizations do not have any default account for tax closing.
This leads to the opening of a RedirectWarning when trying to do a tax
closing.
task-3082332
closesodoo/odoo#124003
X-original-commit: 14abe7acb11d522fb2b4a274ac0eb06d41e637ed
Related: odoo/enterprise#42071
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
With this commit, Made the tree line clickable instead of clicking View Related
Document Button. Updated the description, to be similar to chatter in audit trail
tree view. Also Updated error message while deleting entries once it's posted for
Indian Company.
closesodoo/odoo#122566
X-original-commit: 8833329191acc56468a62b3f00171c14d0252eb7
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nishant Jain(niai) <niai@odoo.com>
This commit adapts the directional icons to improve the usability and
maintain consistency with the ui icons library.
task-2818586
Part-of: odoo/odoo#116641
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>
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
In Indian government required audit trail report for private limited companies
So from this commit user can't delete journal entries after posting once.
Create an audit trail report from mail.message to show a full log of journal entries
task - 3239932
closesodoo/odoo#118945
X-original-commit: f4365ee1c6e979e352ece66b03f3c00e830f2117
Signed-off-by: Josse Colpaert <jco@odoo.com>
Removing external links from localization manifests and redirect to our own documentation. Ensure that users can learn about our standard localization modules from a source of information that we have authorship on.
closesodoo/odoo#117005
Task-id: 3248632
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Currently, all localizations of UoM fields are visible in all countries.
So in this commit, I have added a new compute field in UoM models, the field
contains comma-separated company's country codes, and I have used this field
for the hide/unhide fields.
closesodoo/odoo#112604
Related: odoo/enterprise#36572
Related: odoo/upgrade#4284
Signed-off-by: Josse Colpaert <jco@odoo.com>
Taxes have a `description` field that has been hijacked to
represent tax label on invoices. We want the description field
to be used for its original purpose, thus created a dedicated field
`invoice_label` in which we transferred `description` content.
We also make description translatable.
This is part of the Tax Taxonomy 2 rework.
Task: 3052677
Part-of: odoo/odoo#113236
A lot of the separate files were kept up to now because it made the
process easier while applying the script to rebase.
The files can now be merged.
Some code is also cleaned by using CSV instead of a python dict.
Part-of: odoo/odoo#114164
1. Install [Expenses], [Indian - Accounting], [Accounting] on Apps
2. [Settings] [Users & Companies] [Companies]
- create a company based in India with address there
3. Enter [Expenses], [CREATE]
- create and add an employee w contact info (private address) in India
- set paid by: Company, write an amount, category > [CREATE REPORT]
- [SUBMIT TO MANAGER] [APPROVE] [POST TO JOURNAL ENTRIES]
4. Click on the [Journal Entry] created at the top right corner
Issue: Missing pos field hinders revising it by [reset to draft]
Resolve by: change the requirement in view and enable further revision
Impacted versions: 16.0 up to master
opw-3168426
closesodoo/odoo#113270
X-original-commit: bc08a6e9d0cc42d1586913bf95d01d4547c13b05
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Rewrite the whole chart template mechanism, removing the templates
stored in the database. The new format will mainly use CSV.
Speed up install time
---------------------
* About half of the time of installing a localization for the first time is
taken by creating the template records. This new in code format gets
completely rid of this.
* Creating the template records could often not be done in batch because
of parent/children relations.
* The instanciation of the accounts on the company has been entirely
reworked too, by
- optimizing the order of creation of records to avoid UPDATE queries
- using precomputed fields to avoid UPDATE queries
- updating the translation in batch
- deactivating logging in the chatter
- avoiding access rights checks by checking the rights at the start
Overall, when installing a chart template for the first time, it is 4
times faster because half of the time spent on saving the template in
the database is not done at all anymore, and the instanciation on the
company is more than twice as fast.
Reduce technical debt
---------------------
There is no need to synchronize the templates with the real records
anymore. No need to use hooks to copy the data from one to the other.
It is easier to change a template in a stable version, which can often
be necessary due to legal reasons (i.e. a change of tax rates, reporting
tags,...)
Two modules have been removed:
* `l10n_generic_coa`: since there is nothing left datawise in this
module, it can be integrated in `account` for free. It is just code
and CSV.
* `l10n_multilang`: the fields that this module modified to be
translatable are now always translatable:
- there was an issue when updating modules that deleted all the
translations because the fields were not translatable at some point
during the loading of the registry, then they because translatable
again but lost all translations because of the column type change.
- most devs are not able to understand all the languages needed for
all the localization available. Therefore, english has been added in
the sources in most localization to understand better issues while
debugging.
- no need to call post init hooks anymore, doing the sync with the
templates.
- more: see "Translations" section
Because most of the data is now in CSV, it is also easier for product
owners to edit, audit, modify files themselves, removing one layer
during trivial development processes when only data should be changed.
More flexibility for declaration
--------------------------------
The data declaration can now be done easily in python or CSV.
A nice feature is that you can declare everything at once, even for some
more complex chart of accounts:
* if you have to set default taxes on accounts, would need to
- declare the accounts because accounts are required on the taxes
- declare the taxes
- declare the taxes to put on the accounts
This would lead to scatter information in multiple files. Now,
everything can be declared in the same place and the loading of the
chart of accounts will do the 3 steps automatically.
* if you have a relation of child/parent, you would first need to
declare the parents then the children, and the loading would not be
efficient because done one by one. Now, everything is done in batch
automatically without having to think about it.
It is also easier to update fields on records where there was no field
for that on the templates, like
* setting a restriction for journals on accounts
* setting specific values on the company
* modifying journals and linking them easily by using the xml_id instead
of having to compute it manually
Translations
------------
Some countries have multiple languages (i.e. Belgium uses officially
French, Dutch and German, and the CoA also has an official English
version) and we must support the languages in all these countries.
All these translations are known, and hard coded without using out
translation platform (Transifex). We also like to have the English
version (even if an official one doesn't exist) so that support can be
done more easily in databases using chart templates in other languages
(especially using a non roman alphabet).
Because the translations were not on Transifex for these records, it was
really hard to maintain: the translation templates (`.pot` files) were
not easy to extract as the automatic export would give values mixing
both the CoA and the menuitmes, the fields' strings,... But we don't
want to translate the CoA as we already know the value.
Managing the translations in the `.po` files was also annoying:
- it is easy to forget that the translations need an update too
- it requires a special editor, special terminal commands that everyone
is not familiar with
- it is easy to make mistakes in the source string
The new format is the following: `field@en_US` where `field` is the
translatable field (usually `name`) and `en_US` is the locale code.
This allows to have the whole declaration on one line, everything in one
file. It also makes the process easier when debugging: instead of
searching for the translation in the `.po` files, it directly appears
next to the configuration of the account/tax/... .
Update of the code
------------------
The code can be updated using this script
https://github.com/william-andre/transform_coa
Forward ports can be managed too by stashing/resetting/checkout the new
modules or the changes in the modules updated in the same PR.
task-2687567
Part-of: odoo/odoo#110016
As it is now possible to activate the total amount of an invoice in letters, these localizations (dz,in,ua,ma) need by default the feature to be activated. In addition, some of them had aleady such feature which has therefore been removed to accommodate the new generic feature.
The indian localization also has a different message on the right side of QR code on invoices
closesodoo/odoo#107714
Task: 3097097
Pr: 107714
Related: odoo/enterprise#35959
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
After this commit GST treatment will be only assigned to Indian invoices/bills.
closesodoo/odoo#111738
X-original-commit: 6ede766eab05b621bfee6e6af259c7d2d0bfbd94
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this commit
==================
GST Treatment will not be assigned to those invoices/bills
whose partners don't have GST Treatment.
After this commit
=================
GST Treatment will be assigned to those invoices/bills whose
partners don't have GST Treatment.
closesodoo/odoo#111528
X-original-commit: de944b54715db0a0b6898fb9b049449c5ced29c9
Related: odoo/enterprise#36555
Signed-off-by: Josse Colpaert <jco@odoo.com>
This demo data was made for the purpose of GST return report but now we have
new functionality of GST return E-filing(l10n_in_reports_gstr) so moves demo
data in that module so we don't need the demo data in this module.
X-original-commit: 0981188715210c6e5a170e9a70f2bcb5a6785e04
Part-of: odoo/odoo#111528
Before this commit
==================
all the settings of Indian integration like E-waybill,and e-invoice were
having different setting blocks.
After this commit
=================
all the Indian integration settings will be shown in one setting block.
closesodoo/odoo#111175
Related: odoo/enterprise#36382
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Currently, the Place of supply value is set from the partner state for all journal types.
So in this commit, we set the partner state in `Place of supply` only when
the journal type is a sale. Also added the country domain in XML view.
Part-of: odoo/odoo#109717
We just set a place of supply(state_id) from partner_id in the Invoice/Bill if partner country is india because there are many complex cases so we can't get it automatically in all cases like
(a) where the supply involves movement of goods, whether by the supplier or
the recipient or by any other person, the place of supply of such goods shall be the
location of the goods at the time at which the movement of goods terminates for
delivery to the recipient;
(b) where the goods are delivered by the supplier to a recipient or any other
person on the direction of a third person, whether acting as an agent or otherwise,
before or during movement of goods, either by way of transfer of documents of title
to the goods or otherwise, it shall be deemed that the said third person has received
the goods and the place of supply of such goods shall be the principal place of business
of such person;
(c) where the supply does not involve movement of goods, whether by the
supplier or the recipient, the place of supply shall be the location of such goods at the
time of the delivery to the recipient;
(d) where the goods are assembled or installed at site, the place of supply shall
be the place of such installation or assembly;
(e) where the goods are supplied on board a conveyance, including a vessel, an
aircraft, a train or a motor vehicle, the place of supply shall be the location at which
such goods are taken on board.
we add new state "Other Country" to set place of supply(state_id) incase of partner country is not India
for more details check CHAPTER V here https://www.cbic.gov.in/resources//htdocs-cbec/gst/igst-act.pdf;jsessionid=63D695F612B9972934E8131415FEBA28closesodoo/odoo#82011closesodoo/odoo#109286
X-original-commit: https://github.com/odoo-dev/odoo/commit/b76ee098e2a4c4d26d6d1c689bb0750e770201dc
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
In this commit, the following points are covered
- updated error messages
- remove renaming the `Customer Invoices` journal name
- updated Fiscal Opening Date and Year End for Indian localization
- updated Indian E-Invoicing report and settings setup
Part-of: odoo/odoo#109396
In this commit, I have added a new module for TCS/TDS Tax Report in India.
It will load TCS/TDS-related taxes for an Indian Company.
Added a new character field PAN on the partner.
Added post_init_hook to load these taxes in current company.
closesodoo/odoo#109338
X-original-commit: 367c32684e572dbc9413dc4bc2ba30b14f730541
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Unable to print the customer address on invoice report while the company country is INDIA and bill to ship to address is different.
To reproduce the issue:
Step 1: Create an Indian company
Step 2: Activate Customer Addresses from setting
Step 3: Create an invoice with a different Bill to Ship to address
Step 4: Print the invoice
boom! The customer's address is not there!!
Origin from: https://github.com/odoo/odoo/commit/eb23c0c9d513bdefba20f523e70a807f9a634c57closesodoo/odoo#108908
X-original-commit: 2a83bb3079462bda720935f05dd46241ccae5996
Signed-off-by: Laurent Smet <las@odoo.com>
In this commit, we have removed the multi-GSTIN feature from the journal.
Multi-unit is created if there is a different branch with the same GSTIN(vat) so
now we decided to create a multi-company instead of this.
because functionally we discuss with Indian CA and we find out that it's good
practice if we create a different company.
The main problem is one company and the same Bank account but we also find a
functional solution using a transfer balance to another company.
so we remove this so our other integrations do not have complexity
like E-invoice, E-waybill, GST E-filing
TaskID - 2723109
closesodoo/odoo#107234
Related: odoo/upgrade#4107
Signed-off-by: Josse Colpaert <jco@odoo.com>
Many country-specific fields were displayed while a company with another country was selected (in case of a multi-company environment).
These country-specific fields are now visible only if one of the selected companies with said country is selected.
closesodoo/odoo#106221
Related: odoo/enterprise#34226
Signed-off-by: John Laterre (jol) <jol@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
Current behaviour:
When installing Sales, then PoS, we get an error when loading the modules.
Expected behaviour:
No error should be present when installing PoS just after the Sales app.
Steps to reproduce:
(With demo data)
- Install Sales
- Install PoS
- Get Error
Reason for the problem:
When installing Sales, there is the Product dependency that creates a product variant,
named product_product_4d.
Then in the Sales demo data there is the addition of an "exclude_for"
record (basically an exclusivity rule for variant attributes, for ex: A AND B cannot be together).
In our case it happens to be the attributes which product_product_4d was based of. Therefor the ORM
deletes said record (from the database).
Then when installing PoS, it installs Stock as a dependency, which demo data references product_product_4d,
which is not present anymore in the database.
Fix:
Remove the creation of product_product_4d and all the records that reference it.
Affected versions:
- 14.0 (separate PR)
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master
opw-2999180
closesodoo/odoo#104184
X-original-commit: 3e49e533892f94eeb094a436fa34cbac3ed7ad6d
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Due to the deprecation of t-esc to the unique use
of t-out in the rendering template, this replace
every usage of it and ensures everything continues to
work as inteded. Removing deprecation warnings
polluting terminal
deprecation commit: odoo/odoo:9ce5bc8881ae06b613ef61eb07453b224f62bae6
closesodoo/odoo#103731
Related: odoo/enterprise#33037
Signed-off-by: William André (wan) <wan@odoo.com>
Modules:
- hr_maintenance;
- maintenance;
- l10n_ch;
- l10n_generic_coa
- l10n_il.
The plural of "equipment" is "equipment" and not "equipments"
changes in the enterprise version: odoo/enterprise#31498
Remark:
Runbot test log:
Two fields (equipment_count, equipment_ids) of maintenance.equipment.category() have the same label: Equipment. [Modules: maintenance and maintenance]
Two fields (equipment_count, equipment_ids) of hr.employee() have the same label: Equipment. [Modules: hr_maintenance and hr_maintenance]
Using "Equipment Count" to differentiate them
opw-2981186
closesodoo/odoo#100558
Signed-off-by: Adrien Widart <awt@odoo.com>
The early payment cash discount functionality was merged in 16.0.
This PR allows for the behavior to be as localization specific as possible.
This concerns :
The tax computation (some countries leave it untouched after the discount, some countries discount it, and Belgium has a mixed behaviour)
The account in which the cash difference resulting of the cash discount should be put.
task- 2983913
related to #99572closesodoo/odoo#102032
X-original-commit: 591757902dcdf1e3609d9c5ae23e2b134ee8e4da
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
Issue :
- `account.move.state` has only 3 possible values cancel, draft, posted
- the wrong value was used
Fix:
- Use the correct value `posted`
OPW-2991389
closesodoo/odoo#101324
X-original-commit: e33acb06c90cf9cab93471e1019d092478db35d4
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
`l10n_in_gstin_partner_id` should be hidden on the journal form for non-Indian companies. It's probably also a good idea to hide `l10n_in_tin`in the country state form whenever the state added is not in India.
vat field on `res.company` should be renamed to GSTIN only when the company country is India.
task-2765567
closesodoo/odoo#100542
X-original-commit: 7888a3c43e01c4578b51fc200c7c1706fffbb330
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Xavier Morel