Problem
---------
The compute_is_used function currently parses through a huge amount of
data using the _read_group ORM function. Which causes some performance
issues in large databases.
Objective
---------
Improve performance of the said function.
Solution
---------
Instead of reading the data on whole tables (ex.account_move_line), we
read the relation table between the modules and the taxes. This is done
using SQL queries with the EXISTS statement.
Furthermore, the code logic is modified so that if all the taxes for
which we compute `is_used` have been found, we don't look further in
other modules since doing this cannot add an new relevant information
and actually slows down the computation.
closesodoo/odoo#139497
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Steps to reproduce:
1. Open the "Amounts to Settle" view of either the Customers of Vendors menu
2. Click on the Studio button on the top right of the window
3. A traceback appears.
Issue/Feature this commits addresses:
When on the "Amounts to Settle" view, when clicking on the Studio button,
a traceback appears and the studio menu is not opened. This should not happen.
Desired behavior after this commit is merged:
This fix makes the event that would cause the error not possible anymore.
The studio menu should always open and not cause that traceback anymore.
closesodoo/odoo#140671
Signed-off-by: William André (wan) <wan@odoo.com>
When creating a sub company with l10n_ar, we
get a ValidationError due to the check on
existing accounting entries on root company.
Steps:
- Create a new company with l10n_ar, and
create some moves
- Create a branch for the company and save
-> ValidationError: "Could not change the AFIP
Responsibility of this company because there
are already accounting entries."
In `account.res_company._existing_accounting`,
we check if there are existing move lines in
both parent and child companies, while we would
like to check only new company when it is calling
from `l10n_ar.res_company._check_accounting_info`.
With this commit, we change just change the domain
and use `self.id` instead of `self.root_id.id` and
we call `_existing_accounting` with `root_id` where
needed.
opw-3572926
closesodoo/odoo#140795
X-original-commit: 575971458d454d546d967ec4141d8c47fc28e666
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Problem
---------
When creating and editing a bank account, a creation model pops-up to
edit the bank account information. The previously entered bank account
must be entered again which isn't user-friendly.
Objective
---------
The data entered on the bank account bank account should pre-fill
acc_number on partner bank pop-up.
Solution
---------
When create & edit, `name` could be used to pass (in the context) the
value input by the user. However, we want to set the default value of
`acc_number` variable instead. By overriding the default_get method,
we can get modify the context to do just that.
task-3557753
closesodoo/odoo#140725
X-original-commit: aa28b0fbba97b1528ad6a6ad27813c44125e8d48
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Signed-off-by: Antoine Boonen (aboo) <aboo@odoo.com>
Currently, if a user has an active deferred entry whose account has been deprecated in the mean time,
we create a move line containing this deprecated account which raises an unclear error to the user.
Now, instead, we let the user create deferral entries for deprecated accounts.
We also add a test to check that old moves are not taken into account when generating deferral entries.
task-id 3544877
closesodoo/odoo#140155
X-original-commit: 47f97fb208ee6c6fc4ce522bc7ad648ea6bbe07c
Related: odoo/enterprise#49758
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
Currently, the "Amounts to settle" button in the "Vendors" drop-down menu
opens a view showing all the account.move.line that are to be reconciled.
Also, they should only be shown when their residual is less than zero.
This commit makes it now so that when clicking on that button, only the amls
linked to a purchase journal are shown and another "Amounts to Settle" button
has been added in the "Customers" drop-down menu to show the amls linked to
a sale journal
task-3572482
closesodoo/odoo#140040
Signed-off-by: William André (wan) <wan@odoo.com>
This happened when auditing an aggregation line with a sum_children formula. A test was added in enterprise to prevent that to occur again in the future.
closesodoo/odoo#140200
X-original-commit: 1b24098676c1334666fc11b9973f76f4d200fa27
Related: odoo/enterprise#49783
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Problem
---------
Previously, when receiving an email with several attachments, we created
1 invoice that contained all the attachments.
Objective
---------
We want to create several invoices depending on the attachments received.
No invoice should have more than one PDF document.
No invoice should have more than one XML document.
Other attachments should be placed in seperate invoices (except for the
first invoice that can contain 2 attachments: ex. image and PDF).
Solution
---------
Update the _extend_with_attachments to behave like such.
task-3526248
closesodoo/odoo#140196
Related: odoo/enterprise#49779
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Unwittingly broken by the removal of `__implements__` in
a6d601dc4e, these lints don't run
correctly with the old pylint, allowing new errors to creep in since.
closesodoo/odoo#139605
X-original-commit: 99cec73f585c8759142a707b06934d9c23aa5478
Related: odoo/enterprise#49473
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Description of the issue/feature this commit addresses:
Currently, the payment registration for vendor bills is kinda hard to figure.
Noticing which bills are overdue, which require a payment is not made so easy
by the interface and could be improved. Also there is no way to register a
payment for multiple lines at a time which could improve the UX.
Desired behavior after the commit is merged :
The buttons "Bills to Pay" and "Late Bills" redirect to a Journal Items view
called Payment Items with specific filters to show only the necessary lines.
The order of the columns in the Journal Items has been changed and their
visibility has been changed too.
The default filters of the Journal Items when coming from the dashboard buttons
has been changed. Payable has been replaced by Purchases.
Filters, Group by and Search by options have been added for the Due Date
and the Discount Date fields in the Journal Items.
task-3516496
closesodoo/odoo#138188
Related: odoo/enterprise#48679
Signed-off-by: William André (wan) <wan@odoo.com>
Current behaviour:
When your current company is South Korean,
The chart of account is generic.
If you try to create a South Korean company
branch, you'll get an error message:
The Currency of a subsidiary must be the same as its root company.
Steps to reproduce:
1. Install account_accountant
2. Go to Settings
3. Go to Users & Companies > Companies
4. Create a new company
5. Country: South Korea
6. Currency: KRW
7. Switch into the new company (top right)
8. Go to Accounting
9. Go to Configuration > Settings
10. Fiscal Localization: Generic Chart Template
11. Save the changes
12. Fiscal Country: South Korea
13. Main currency: KRW
14. Save the changes
15. Go to Settings
16. Go to Users & Companies > Companies
17. Select the Korean company
18. Create a new branch
19. Country: South Korea
20. The Currency of a subsidiary must be the same as it's root company.
Cause of the issue:
The generic chart of account's currency is USD
opw-3537346
closesodoo/odoo#139796
X-original-commit: 303fde24a62269159def12760e438997f6c6f147
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Purpose
=======
Make it possible to compare analytic values between plans by inputting
up to one account per plan on each line.
For instance, if we have 2 plans: "Country" and "Product Type", with the
following accounts
| Country | Product Type |
| ------- | ------------ |
| BE | Drinks |
| LU | Food |
And the following invoices:
* 1000€ of drinks in Belgium
* 2000€ of food in Belgium
* 3000€ of food in Luxemburg
We want to be able to display the following pivot tables:
| | Drinks | Food | Total |
| --- | ------ | ---- | ----- |
| BE | 1000 | 2000 | 3000 |
| LU | 0 | 3000 | 3000 |
| Tot | 1000 | 5000 | 6000 |
| | Total |
| ------ | ----- |
| Food | 5000 |
| * BE | 2000 |
| * LU | 3000 |
| Drinks | 1000 |
| * BE | 1000 |
| Total | 6000 |
Implementation
==============
* `ir.fields` are added/removed dynamically on `account.analytic.line`
* Each analytic plan corresponds to one field on `account.analytic.line`
* The fields are added dynamically in the views.
* `account.analytic.plan` doesn't have a `company_id` field anymore,
meaning that all the companies have access to all the plans. This
means that the applicability fields and lines are now company
dependent, and those can be used to know which fields/plans to display
for which company.
* There can no longer be one "Project" plan per company, even if the
accounts of that project can still be owned by only one company.
* There is now only one method to get the default (or "Project" plan),
which is `_get_plan_columns`
task-3497653
closesodoo/odoo#139225
Related: odoo/upgrade#5306
Related: odoo/enterprise#49226
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: william <wan@odoo.com>
Co-authored-by: h4818 <ayh@odoo.com>
Since it is cached by the ORM (see parent commit), there is no need to
manage the caching in the business code anymore.
In most cases in addition to making the code shorter, it also makes it
more readable by making the direction of the rate more obvious with the
use of the `to_currency` parameter.
closesodoo/odoo#137609
Signed-off-by: Raphael Collet <rco@odoo.com>
This commit contains some misc improvements based on the 16.0 overall improvements regarding navigation and Journal Items
in account.full.reconcile, 'name' field has been removed, and the replacement for matching_number will be the SQL id instead (no more sequences)
For full reconciliations, the matching number now don't have an 'A' prefix
For partial reconciliations, the matching number will have a format of 'P{id}'
Community-pr: https://github.com/odoo/odoo/pull/138140
Enterprise-pr: https://github.com/odoo/enterprise/pull/48980
Task-id: 3530458
Part-of: odoo/odoo#138140
If you assing a different payment account per payment method line
corresponding to the same journal (but different payment methods),
The method that returns the possible liquidity accounts returns a tuple
instead of a recordset, and the comparison is done with the operator
`in`, so if any of the elements of the tuple is a recordset of more
than one record, the match is not happening, which may be the case for
`self.journal_id.inbound_payment_method_line_ids.payment_account_id` or
`self.journal_id.outbound_payment_method_line_ids.payment_account_id`.
The solution is to return a recordset instead.
TT43014
closesodoo/odoo#139656
X-original-commit: 56279a17e52592fd19a5b0df6dd2669a7af6ab24
Signed-off-by: William André (wan) <wan@odoo.com>
account.report.line can have shortcuts for adding basic expressions
for various engines. This commit adds such a shortcut for external engine
so that reports with lots of external expressions (manual fields) can
be added easier and can be shorter.
Part-of: odoo/odoo#135783
Currently the Send & Print wizard is stored as regular model
and not a TransientModel.
This cause multiple problems including concurrency ones.
This PR switches the wizard back to a regular transient one.
We instead store the values of the wizard that needs to be
processed asynchronously in the related move.
closesodoo/odoo#139311
Task-id: 3415101
Related: odoo/enterprise#49310
Signed-off-by: Laurent Smet (las) <las@odoo.com>
mplemented a uniqueness constraint for account tags name, applicability
and country_id to allow some localizations to use tags over account
codes.
Task-3497548
closesodoo/odoo#136639
Related: odoo/upgrade#5240
Signed-off-by: John Laterre (jol) <jol@odoo.com>
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>
Summary
------
Currently, when removing a product from an invoice line, the account for
that invoice line is automatically reset to a default value.
Steps to reproduce
------------------
* install `account_accountant`
* create an invoice and add a product
* set a different account on that invoice line
* remove the product from the line
You should see that the account is automatically changed.
opw-3092556
closesodoo/odoo#139361
X-original-commit: 39b44dbfef0d533722ce2c96d375ada113d32b00
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
to currency
rounding rules, symbols and positions
closesodoo/odoo#139418
X-original-commit: b41a02cf1b4e0a67e56b25c5784d5fb2952c80e0
Signed-off-by: William André (wan) <wan@odoo.com>
* Avoid posting crappy forms when a redirection does the job
* use a dedicated route /shop/cart/update_address for address changes
* clean code from recent PR on invoicing address
* Public user shouldn't be able to create billing addresses
* Logged customer should always see his own partner as billing/shipping
address choices.
Part-of: odoo/odoo#138026
The Belgian localization has been updated to reflect the official Charts
of Accounts.
Users now have the choice between the official CoA for Companies or the
one for Associations and Foundations.
All related terms and translations have been reviewed and corrected in
the 3 official languages (nl, fr, de).
Non-official languages have been removed, since they both don't make
sense and they did not work because of targeting an ancient version of
Odoo.
Finally, the 580000 account has been set as the default Internal
Transfers account, avoiding a second 58 account to be created.
task-3086473
task-3258014
closesodoo/odoo#117480
Related: odoo/enterprise#35771
Related: odoo/upgrade#5291
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Currently we require the account lines `code` field to be unique across
all reports in a database. Since Reportalypse, this is not required
anymore, since we search by default only in the current report unless
we specify a `cross_report` subformula. Then it will take the first one
it finds.
In this commit, we relax the condition to have unique `code` fields per
report, instead of globally.
Furthermore, we add a test utility to check lines with the same code to
have the same properties. This is useful for localizations that have
multiple versions of the same reports, containing identical lines in
multiple report. This way we can ensure they are always calculated the
same way across reports.
task-3086473
Part-of: odoo/odoo#117480
Problem
---------
All fields in the tax definition are currently modifiable even after the
tax has been used. This raises some issues in tax reports and make
investigations difficult when things go wrong in tax report.
Objective
---------
Once an account tax has been used:
- Some fields in the account tax should not be modifiable anymore to
avoid tax report issues;
- Other fields should be logged when modified to ease debugging and
investigations.
Solution
---------
1. Add a logger to the tax form to track the modification of some fields
2. Track whether the task is being used in transactions or not. This is
done thanks to a compute field. In order to be flexible, the compute
function uses a hook function that other modules can override to easily
add transactions to computation of the field.
3. Make the fields that should not be modified anymore readonly when the
tax is being used.
4. In order to track the repartition line values, a tracked computed
field that stores the relevant value in a string is used.
Task-3450002
Part-of: odoo/odoo#130403
The code was failing because the domain it generates is too large, which
makes the SQL "compilation" reach the recursion limit.
closesodoo/odoo#138019
Related: odoo/enterprise#48916
Signed-off-by: Raphael Collet <rco@odoo.com>
The new method should be used to generate an SQL object that represents
how to order by a field in an SQL query. We introduced the auxiliary
method _order_field_to_sql() so that one can specify some SQL for
ordering by a given field with a simple method override.
Part-of: odoo/odoo#138019
The 'download' button should download *all* the attachments linked to
the move. Depending on the localization, an xml might be needed in
addition to the PDF (e.g. the CFDI and the signed PDF in Mexico).
To do that, we open a headless Send & Print wizard with only the
`download` checkbox set to True.
Secondly, do not show the 'Download' button in the portal view if no
official attachment is linked to the move (the print button still
appears).
task-3542881
Part-of: odoo/odoo#138206
Initial case to fix:
When a portal user requests an invoice using the QR code/5 digit code on
the receipt, an invoice will be generated from the pos_order, and the
PDF can be downloaded. The problem is that the PDF is currently not
signed by the government (for the localizations such as Mexico).
Fix:
The invoice should be sent to the government using the usual "Send &
Print" flow. The "Send & Print" happens right after posting the invoice,
inside `_generate_pos_order_invoice`. This means that any invoice
generated from the POS will go through the "Send & Print", as intended.
Previous fix: 2cc9a35860b59063f536eea9234a1e9c5fa2f00e
In this previous fix, the Send & Print was triggered when requesting the
PDF of the invoiced pos_order. It did not cover the above use case. We
partly revert this fix, since the Send & Print now occurs during the
`_generate_pos_order_invoice`. Hence, we only need to fetch the existing
attachment linked to the move.
task-3542881
Part-of: odoo/odoo#138206
Steps to reproduce:
- Install Accounting & Contacts
- Go to Contacts and open partner linked to a res.company (e.g. YourCompany)
- Select another value for Account Receivable (e.g. Account Receivable (Pos))
- Go to Accounting and create an invoice for YourCompany
- Check Journal Items
The used Account Receivable is not the one configured on the partner,
but the default one from the company.
The issue only happens for the "res.partner" linked to a "res.company".
Cause:
When computing the available accounts, a dict is generated with the following
structure: {(model, id, account_type): account_id}.
dict of keys: tuple (model, id, account_type)
values: int (account_id)
This dict is generated from several sources that are merged together.
One source (aka "properties") is the accounts configured on the partners.
In our example, such an entry is {('res.partner', 1, 'asset_receivable'): 35}.
Another source (aka "default_properties") is the default accounts configured on
the companies. From these data, entries are generated for the partners linked to
the companies.
In our example, YourCompany "res.partner" is linked to YourCompany "res.company
and the following entry is generated: {('res.partner', 1, 'asset_receivable'): 6}.
The key of this entry is exactly the same as the key of the entry from the other
source and is overriding its value in the final dict once merged.
Solution:
The data from "properties" should be the main ones and the data from
"default_properties" should be used as fallback.
This can be done by changing the order of the merge.
opw-3465767
closesodoo/odoo#139255
X-original-commit: ab47c12902087a2625fe079903ec3b1753ae7b3e
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
The system tray has been simplified:
- only one clickable area per activity group
- by default, a click on an activity group open the list view, except for some
model (ex.: journal entries, project, task, documents where the activity view
is opened). This can be defined per model using the _systray_view attribute on
the model.
- the clock icon providing access to the activity view has been removed. As it
is the only action, we also remove "actions" returned by systray_get_activities
in res_users.
- the KPIs are no longer clickable
The tests have been updated (for example, because we open the list view instead
of the kanban view) and one removed "activity menu widget: activity view icon"
as we only have one clickable area now and no more icons.
Task-3300854
Part-of: odoo/odoo#138135
A previous commit(ea8acc17b4)
added a compute on invoice_user_id fields to
guess the Sale Person. The problem is that by adding the compute
on the field, the readonly default value changes for True.
It causes that user can't change the sale person anymore.
no task id
closesodoo/odoo#139035
X-original-commit: af5e3eedf90d64462afc625b30dec742361389f5
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
When a user only has access to a branch and not to the parent, he can
not create a new customer invoice or vendor bill, since we need to check
the lock date on all ancestor companies (where the user might not have
access to).
This fix allows the user to create a new customer invoice or vendor bill
again when only having access to a branch.
Furthermore, in the above case we are also unable to assign a partner on
the invoice/bill, since we are checking properties that might belong to
an ancestor company we don't have access to. We also fixed that here, so
a partner can be selected.
task-3503204
Part-of: odoo/odoo#138942
*: pos_sale,purchase,sale
The '_get_query_currency_table' function of the res.currency
model (added in 'account' module) was refactored in this commit.
After this commit the functions parameters are effectively "decoupled"
from the 'account_reports' module.
Previously the the function took an 'options' parameter.
The 'options' was a dictionary that was formatted to be compatible with
the report options from the 'account_reports' module (enterprise).
Due to a change to these report options (see enterprise PR)
the function had to be changed in some ways.
It was chosen to "decouple" it from the report options for the following reasons:
1. The 'account' module does not (really) depend on 'account_reports'
or knows about it at all.
2. There was still a (soft) dependency on the 'account_reports' options though:
Changes to the report options had to be reflected here too.
3. Every function that calls this function previously had to create some pseudo
'account_reports' report options. This made it inconvenient to use the
function outside of a report.
task-3484368
closesodoo/odoo#136173
Related: odoo/enterprise#47735
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
When a tax is created using an unsigned tax tags AND a signed tax tag,
the mapper in the chart template model was crashing, skipping the needed
mapping for the signed tax (the unsigned tax doesn't need to be mapped
as it comes from a template).
task-3520182
closesodoo/odoo#138840
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Pierre-Rodéric Roose (prro) <prro@odoo.com>
Tax group are currently ordered by sequence only.
Only 2 localizations of ours have defined the sequence on them.
So, most of the tax groups have the same sequence.
The order of search made on them is thus undeterministic.
It can be seen when running the test test_generate_xml_sale with
l10n_ee_reports installed, it fails sometimes (1 in 50 to 100).
Because the invoice amounts are grouped and ordered by tax groups.
Linked to runbot error 24595
closesodoo/odoo#138890
X-original-commit: 7535c6091cb841a428ea0f4cc6d4bb1779e70346
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Followup of odoo/odoo@eb7a32c31c, on large database with lot of
account.move computation still take certain amount of time and database
resources.
This commit limit the computation of `days_sales_outstanding` only
to the commercial partners that we need.
Note: the field is only shown in the Partner form view, so most of
the time we were only computing it for a single record
| Before | After |
|--------|-------|
| 900ms | 20ms |
opw-3530408
closesodoo/odoo#138703
X-original-commit: f968ea2898d7ce314fd575da5446b0dd9d711524
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
In the enterprise PR, we allow to have a new options on reports that can hide
line that are equals to zero under certain condition.
A line should be visible depending on its value and the ones of its children.
For parent lines, it's visible if there is at least one child with a value different from zero
or if a child is visible, indicating it's a parent line.
For leaf nodes, it's visible if the value is different from zero.
This commit add the filter in the account_reports model.
closesodoo/odoo#130897
Task: 3359936
Related: odoo/enterprise#45291
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Steps to reproduce:
- Activate the receipts in the Accounting Settings
- Go to Vendors -> Receipts
- Upload a file
-> Error "The journal in which to upload the invoice is not specified."
opw-3544292
closesodoo/odoo#138612
X-original-commit: 00bad1954cd0bda21a7ec58f8ea8000a78e551ad
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
permissions) edit information at /my/account
Issue:
Internal user cannot edit their information (email, street,...) at
portal without permissions in the accounting
Analyze:
Because the method `can_edit_vat` has a search from the account.move
model, it causes an error
Fix:
Use sudo to avoid error when searching
closesodoo/odoo#138291
X-original-commit: eb9505375483d18cf21fbaf8e5a60398d5c041c5
Signed-off-by: Laurent Smet (las) <las@odoo.com>
It is now possible for aggregations to be defined with the formula 'sum_children'. An expression using this formula will take all the expressions with the same label, belonging to child lines of the line this expression belongs to, and will sum their values. This is done as an improvement in stable, as this feature is needed for a cleaner upgrade of custom-made tax reports from 15.0 to 16.0, since the former tax report engine used to behave like that by default (no formula meant you had to sum the children).
Task 3499260
closesodoo/odoo#138358
X-original-commit: 276142f899e9050ccd39f52c502e6529bbaa0493
Related: odoo/enterprise#48784
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Currently it is not easily discoverable that users can install the
PEPPOL module. They have to go to the Apps list and search for PEPPOL
there.
In order to make the installation easy and discoverable, we added a
checkbox to the Invoicing/Accounting settings to install the module and
afterwards show the checkbox to enable PEPPOL per company.
The install checkbox is only shown when editing the settings of a
company that is eligible for PEPPOL to avoid confusion. In order to do
that, we created a `PEPPOL_LIST` variable in `account` containing all
countries currently allowed to use PEPPOL. The code in `account_peppol`
formerly using the `EAS_MAPPING` variable of the `account_edi_ubl_cii`
module is now also using this new list.
task-3519564
closesodoo/odoo#137287
Signed-off-by: Laurent Smet (las) <las@odoo.com>
In the specific case in which an invoice in company currency is paid by a payment in foreign currency,
in that case, perform the reconciliation in foreign currency but convert the residual amount of the invoice
to the foreign currency using the payment rate instead of the invoice one.
closesodoo/odoo#138289
X-original-commit: 2123278215befe22d3be4568812bfe7d028e2757
Related: odoo/enterprise#48744
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
When having a company with sub company.ies, if
we select only one of the branch, the number
of entries to reconcile is not reflected only
the entries from the selected branch but the one
from all the branches, therefore when opening the
reconciliation widget, the number of line to reconcile
is not the same as indicated.
With this commit, we only count the entries that belong
to the selected company.
Steps:
- Having a company with one branch (X and X.1)
- Having 1 statement line for X and 2 for X.1
- Select the two branches
- See that there are 3 entries to reconcile
indicated on the bank journal
- Select X or X.1 only
-> There are still 3 entries to reconcile
indicated instead of 1 for X and 2 for X.1
closesodoo/odoo#138257
X-original-commit: 023c97c21194e83eda2433e2fe3c32de1d3b320b
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Maintain the playful tone whilst avoiding nonsensical phrasing.
I will not take comment at this time, thank you.
Task-🤔🙃😬💅😐🤓closesodoo/odoo#138302
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Maximilien (malb)