* Add refunds with liquido docs
* Add Is AFIP POS field (l10n_ar_is_pos)
* Adapt letter mapping
* Add unit test
closesodoo/odoo#111076
Related: odoo/enterprise#36322
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this commit, the accounting module had a setting on the selection of taxes used by the sales, purchase, website_sale, ... modules. In addition, the website_sale module had the same setting related to the accounting one.
This PR isolates the tax selection parameter in the website_sale module, and instead of using the tax selection, the accounting module will use rounding method (round per line, round globally).
Selecting one of the two will change the display of all account_move or other view using the tax selection setting.
Display changes:
In round per line, a column tax excluded will always be displayed while a column tax included will be in optional hide.
On the other hand, in the round globally, only the tax excluded columns will be available.
closesodoo/odoo#99209
Task-id: 2954332
Related: odoo/upgrade#3826
Related: odoo/enterprise#30853
Signed-off-by: William André (wan) <wan@odoo.com>
OPW 3117373
Task: 57576
The printed invoice hides part of the document type letter in the header.
This commit solves that problem and also this issue: https://github.com/odoo/odoo/issues/108994closesodoo/odoo#113603
X-original-commit: 91581e9090d2382ff584c199efcf3b7206ddac66
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this PR, all this localisation was written in Spanish, but all the localisation have to be written in english and then translated back in the native language. This PR correct that.
closesodoo/odoo#112803
Task-id: 3179209
Signed-off-by: Nicolas Viseur (vin) <vin@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
Total amount on printed electronic invoice include taxes if the electronic invoice has argentinian vat and document type 'B', 'C', 'X', 'R'. Also if the invoice mentioned before have more than one tax and one of them is different than "IVA" (argentinian vat), then is necessary not to show in the printed invoice report the amount untaxed of the invoice.
closesodoo/odoo#111776
Task: 922
X-original-commit: f5c0552a2b2e975db8745219af044638449c3312
Signed-off-by: Josse Colpaert <jco@odoo.com>
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
closesodoo/odoo#111103
Related: odoo/enterprise#36335
Signed-off-by: Géry Debongnie <ged@odoo.com>
Reproduction:
1. Install Sale, Inventory
2. Go to Sale->products, search for “Customizable Desk”
3. Hover the cursor on the stat button “Sold”, from its definition, the
analysis should show the sold items in last 365 days
4. Click on the “Sold” button, no filter for “Order Date”
Reason: in V14, the “time_ranges” feature is removed. Thus using it in
the context won’t create any filter for searching
Fix: We use a custom filter to replace the time range "last_365_days".
We also make sure that the domain produced by that filter is the same as
the one used to compute the button count server side (this was not the
case in Odoo 13 when "last_365_days" was used). Similar fix is also done
in mrp and l10n_ar. Mind the utc convert for correct results.
opw-3000595
Related commits:
Removal of time_ranges: https://github.com/odoo-dev/odoo/commit/be5a51a345b8986da0e19627260f64f984e11ae9
Date filter fix: https://github.com/odoo/enterprise/pull/10938closesodoo/odoo#108951
X-original-commit: 03057029b210a59f3d7012aeea66cfa95790a8c8
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@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>
Because it causes them to be inconsistent with their images,
and causes issues with some website tours depending on them.
X-original-commit: cfbe95ae05fd0c87e24668fc8550da9fdd7ee70d
Part-of: odoo/odoo#105523
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>
In this commit, we add data of amortizations accounts and correct the
accumulated amortization accounts (now they are of the fixed asset
type) to be consistent with the Argentine chart of accounts.
For each accumulated amortization account we have an expense type
amortization account.
closesodoo/odoo#103386
X-original-commit: 05a8eddebea35c29c2c41163d366d88c96158395
Signed-off-by: Josse Colpaert <jco@odoo.com>
Supplier invoice demo data was badly initialized with sales taxes. This
was given problems in some VAT reports. Fixed and they are all purchase taxes
Document type "Despacho de Importación" xml id demo_despacho_1
closesodoo/odoo#100327
Signed-off-by: Josse Colpaert <jco@odoo.com>
This commit makes FCE Is Cancellation Field inivible in non Argentinean Companies
closesodoo/odoo#99339
X-original-commit: da6b17dec3a4b13e3bf1b1cf5557aa8267f236a6
Signed-off-by: Josse Colpaert <jco@odoo.com>
Following reportalypse, reorder the menu items in order to bring
some consistency to the report menu.
Also clean the menu items by removing all the menu items no longer
used since most reports are now selectable by going on the generic
reports and then switching to localized ones.
Task id #2965755closesodoo/odoo#99210
Related: odoo/enterprise#30854
Related: odoo/upgrade#3831
Signed-off-by: William André (wan) <wan@odoo.com>
This commit adapts account's model to the new report engine introduced for v16, and updates the data files accordingly.
account.report model is now declared in community, together with the other models used by the reporting. This is done so that the tax tags can properly be created by the tax report and used on tax templates. All the actual computation logic stays in enterprise.
See enterprise commit for full details.
Task 2524389
Part-of: odoo/odoo#94125
The error message now shows that a VAT tax must be added to that line
and that if it is already added, it may be misconfigured. This improves
the functionality since previously it showed that there should only be
one VAT tax and that could generate confusion in some cases
[CLA] add new members to Adhoc CLA
closesodoo/odoo#97640
X-original-commit: 16200f80cd8ae7a471725833655a06fe049b5b4b
Signed-off-by: Josse Colpaert <jco@odoo.com>
Only for terms containing Credit Note and expenses
closesodoo/odoo#97840
X-original-commit: 1754b094a66476a0bdb29fe60dc5583c03336c3f
Related: odoo/enterprise#30262
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The report "IIBB-Sales by jurisdiction" group invoice subtotal amounts by partner address instead of the delivery address set on customers invoices. This PR changes that behavior and group amounts by delivery address.
closesodoo/odoo#96938
Signed-off-by: Josse Colpaert <jco@odoo.com>
TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
to improve perfs.
_______________________________________________________________________
The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
`write`
* by saving when switching tabs on the Invoice form, to synchronize
before showing the values
This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
intercompany, ...)
* the performance for invoices with many lines improves drastically, going
from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
which was unexpected and needed to be managed manually in all the
onchange methods
This means that:
* Some fields need to be exclusively computed on journal entries values
or invoice values, more specifically the Tax Summary widget.
It is now
- computed from entry lines, when opening the view
- computed from invoice lines when changing those, because the tax lines
will need to be recomputed anyways, erasing previously set values
- set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
(i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
This is because such a behavior was undefined (how is changing the balance going
to affect the unit price? How is the amount currency going to affect it?)
_______________________________________________________________________
Implementation Details
----------------------
The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.
Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)
By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`
The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.
Performances
------------
You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.
```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
self.env['account.move'].create([
{
'move_type': 'out_invoice',
'partner_id': random.choice(partners),
'invoice_line_ids': [
Command.create({
'name': f'line{i}',
'product_id': random.choice(products),
'tax_ids': [Command.set([random.choice(taxes)])],
})
for i in range(nline)
]
}
for j in range(nmove)
])
# After | Before
print(timeit("create(1, 1)", globals=globals(), number=1)) # 0.11 | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76 | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56 | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03 | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99 | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44 | 79.55
```
Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)
Why this commit title?
----------------------
Someone told me that this was the perfect way of naming your commits.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
By trying to avoid concurrency issues while assigning the sequence [1],
we are locking too many operations even when not in the process of
assigning a new number.
* when computing `highest_name`, we don't need to lock as this is mostly
an information on the form that can possibly change anyway while the
form view is open (without any lock anymore)
* when computing the accounting date, we don't need to lock, the only
information we want is the format of the sequence (yearly, monthly, no
reset), which is not likely to change on a same journal.
* when changing the `journal_id`, it is only a helper for encoding, if
there is a concurrency error it will be shown during the post anyways.
Also same argument as for `highest_name`
[1] https://github.com/odoo/odoo/commit/ba6ee0b75d66d6f22a592b1b6a7c5158461bec41closesodoo/odoo#95480
X-original-commit: 809557cdd02fe6581ed573b58158a927aabe0694
Related: odoo/enterprise#29212
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Because of the change in order of operations, for the main company
when we install e.g. l10n_ec, the CoA installed is the Ecuadorian
one, which makes the fiscal country EC, but the country_id still US.
We suspect https://github.com/odoo/odoo/blob/7cb109e7b0ee2e46cef79ec7d3076d16715567f9/addons/account/models/chart_template.py#L278
for the change in behaviour as the generic coa does not have US as
company anymore and that somehow led for the sales journal to
require to use document types. (there we use the fiscal country which
is set to Ecuador)
The solution anyhow here, is that for the demo data, we should
use the fiscal country as well to see if we need to add the
document type to the demo invoices or not.
closesodoo/odoo#92772
X-original-commit: 40dab08559d5b4c837589ce96d6d7ce23f14fd98
Signed-off-by: William André (wan) <wan@odoo.com>
Before this change, we bringed to the user the posibility to select the option “Unified Book” (boolean) on journals with type “Sales” and Pre-printed Invoice “AFIP POS System”. This allowed all documents with the same letter document to use the same sequence, and it does not matter if they are invoices, credit notes or debit notes for example.
Now that functionality is deleted and all documents will have their own sequence regardless of the letter document of each receipt.
closesodoo/odoo#88129
Signed-off-by: Josse Colpaert <jco@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In res.partner the Fiscal Information Tab content was broken than to a
bad adding of the Gross Income fields. This PR solves the problem.
closesodoo/odoo#88704
X-original-commit: 23f5aa3c105ca33f0146ba21d7f463a8310688c4
Signed-off-by: Josse Colpaert <jco@odoo.com>
When getting l10n_ar/l10n_cl starting_squence check with the proper
company (self.company_id) and not self.env.company_id
We do not put a journal_id anymore as it should take the correct one
automatically in v15.
Original commit d6f4fee58edf103c63836ac488be240961fd671a
closesodoo/odoo#87219
X-original-commit: f2f76dfa195226b7604076830412706447c168f2
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this change, we have the errors that documents generated on
pre-printed sales journals mark as unified book were wrongly
named using the wrong doc prefix code.
This was visible thanks to the demo data were we notices that the credit
notes were having FA- doc prefix instead of NC-
This was because we are reusing the shared sequence directly, now we
check and fix the doc prefix for those cases and all documents generated
on shared sequences are properly named.
closesodoo/odoo#86612
X-original-commit: df5bfd22c20d3a3bd72b04acbdae63657e025ce3
Signed-off-by: Josse Colpaert <jco@odoo.com>
Unify taxes computation between 'account', 'sale' and 'purchase' including:
- computation of price_subtotal/price_total.
- computation of business models total (using the json field)
closesodoo/odoo#80231
Task: 2654784
Related: odoo/enterprise#25620
Signed-off-by: Olivier Colson <oco@odoo.com>
We have a bug when we were computing the invoice rate that is used to
report to AFIP. The rate we were setting was an old rate that references
the day that the invoice was created and not the rate of the day where
the invoice was validated. This was happening because the
l10n_ar_currency_rate field that stores this value was computed before
posting the invoice. At that time the date field store the value of the
date where the invoice was created and had not been updated yet with the
accounting date.
Moving the l10n_ar_currency_rate field calculation after the invoice
post solves the problem and now the l10n_ar_currency_rate has the rate
of the accounting date.
Part-of: odoo/odoo#84470
Original commit: aac1165655d31ba3bca4b105e0c905534e91df93
closesodoo/odoo#87163
X-original-commit: ac57ac559d973a1c4c2050fa514668d20bd610f0
Signed-off-by: Josse Colpaert <jco@odoo.com>
Currently all latam localizations except Chile use country_id in _localization_use_documents().
account_fiscal_country_id should be used instead in all modules.
closesodoo/odoo#84756
Task: 2761248
X-original-commit: cf61089d9480d7450d2916911b0859cd5f6efcce
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Tastemirova Aliya (alta) <alta@odoo.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
The currency rate could be different if the invoice date is different that the accounting date
Steps to reproduce:
1- Install l10n_ar
2- Create two different currency rate for foreign currency (i.e: Dollar) with also different Date
3- Create an invoice setting the currency as foreign currency (i.e: Dollar)
Current behavior before PR:
In page "Journal Items" could see that each account line use the currency rate defined by the accounting date,
however the currency rate filed (which is not visible) is defined by the invoice date.
Desired behavior after PR is merged:
Use always the accounting date to set the currency rate
+ CLA signing Augusto Weiss
closesodoo/odoo#83689
X-original-commit: 21692f28fd1db7097e1d4c23ce7dcbaa76936449
Signed-off-by: Josse Colpaert <jco@odoo.com>
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
E documents cannot be selected for invoices and bills which is a problem for companies in Tierra del Fuego, a fiscal exception of Argentina
Steps to reproduce:
1. Install the l10n_ar module
2. Switch to the company '(AR) Responsable Inscripto'
3. Open the Invoicing app and go to Vendors->Bills
4. Create a new Bill and select '(AR) Responsable Inscripto' as vendor
5. The document type '(19) Facturas de exportacion' is not available
Solution:
Add 'E' as journal letter for AFIP responsibility type 'IVA Responsable Inscripto'
OPW-2713805
closesodoo/odoo#83119
X-original-commit: 27edc28a2c19fad80053e668a8c72e7a629e4c1a
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Katherine Zaoral