Accounts 10x -> 13x should be of 'equity' type.
(In the Balance Sheet, they are referenced under the Equity section.)
opw-3743637
closesodoo/odoo#160324
X-original-commit: cfb474a7081f5b123bf27a5234d2d11819f19011
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Commit 14abe7acb11 (PR #123816) introduced default tax closing accounts
for localizations that were so far missing them. However, the mechanism
for specifying the default tax closing accounts changed in 16.2: they
must now be specified on the tax groups. This was not correctly done
in the fw-port, so we fix this in this commit.
closesodoo/odoo#155911
Taskid: 3524378
X-original-commit: f522550e083af22e63d219124273b47e0fcb7bbd
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
In https://github.com/odoo/odoo/pull/105119, new accounts were added
to represent employee-related expenses. Based on the non-official
document https://swissdec.ch/document/share/295/4cc46aca-8b47-49e9-882a-03c37eb8dea3
we used account codes 2990 and 2999 for accounts 'Indemnities' and
'Company Car Correction'.
However, these accounts have no place with the equity accounts in 29xx,
since they are not equity but rather expense accounts. Examples of CoAs
that include employee indemnity accounts place them under account group
5 with the other employee-related expenses.
(e.g. https://plancompta.com/plan-comptable-suisse-pcg-2021/)
As such, we move accounts 2990 Indemnities -> 5840
and 2999 Company Car Correction -> 5031.
Fixing this in stable will not cause any in-database corruption, since
the updated code is only executed when the CoA is loaded/reloaded.
However, users will need to reload the CoA in order to take advantage
of the fix.
This also ensures that the Swiss Balance Sheet is balanced.
taskid:3060790
closesodoo/odoo#150692
Related: odoo/enterprise#54941
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
_l10n_ec_get_identification_type will get called quite often in a loop
in the ATS report, so it's important that it gets orm-cached. This
reimplementation removes calls to ref() and replaces them with calls
to _xmlid_to_res_model_res_id() which is entirely orm-cached.
closesodoo/odoo#147723
X-original-commit: f95540bb8b92e795b1331910049d0d6de7da120c
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
4424 VAT to be recovered should be liability_current.
4426 VAT deductible should be asset_current.
4427 VAT collected should be liability_current.
closesodoo/odoo#146572
Taskid: 3634044
X-original-commit: 2581dda5217a6434cee529ed2ef144eb71fca467
Related: odoo/enterprise#52907
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
- refund tax repartition lines lack tax grids -> added
- Outgoing credit notes lack base line grids -> should decrease total
active transactions -> added.
- Purchase taxes 0% G and 0% S should increase total passive
transactions, not increase total active transactions -> fixed
closesodoo/odoo#145636
Taskid: 3175384
X-original-commit: 114a3e3c1587a057da96d4148d61416cfd434dac
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Previously, the code that sets default tags on bank accounts was in
l10n_de_reports, so was not yet loaded when the demo company is created
at module init of l10n_de.
As a result, the demo company was created without the necessary tags
on the 1001 Cash and 1201 Bank accounts, which meant that the Balance
Sheet would not be impacted by these accounts on the demo company.
This commit fixes this.
taskid:none
closesodoo/odoo#145357
X-original-commit: 70c3cf2fa31fca3fea93d8623dc38cad0d048450
Related: odoo/enterprise#52302
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
- Moved VAT report to Community repo
- Re-numbered XMLids of the report lines so that they correspond to the
tag names
- Changed the tax repartition line templates to use the new tax tags
defined in the VAT report
- Removed the obsolete tax tags and account tags
closesodoo/odoo#134590
Related: odoo/enterprise#47033
Related: odoo/upgrade#5122
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Bugfix.
Steps to reproduce:
1. Create a fresh DB with the Brazilian localization.
2. Create a new Credit Note (directly from the menu, not from an
invoice). Confirm.
3. Observe that you get a ValidationError: "Another entry with the same
name already exists." because the name of the Credit Note is
NFe 00000001, and an invoice called NFe 00000001 already exists.
Analysis:
The credit note should be called NFe 00000002, because in Brazil the
same sequences should be used both for invoices and for credit notes of
a given document type.
However, because the `refund_sequence` field is set to True on the
'Customer Invoices' journal, the sequence mixin doesn't consider
invoices and credit notes as using the same sequence, and therefore
doesn't consider the existing invoice when finding a new name for the
credit note.
Solution:
Set the field `refund_sequence` to False on the journal created by the
l10n_br template.
We also take the opportunity to move the code that provides a default
name to the demo invoices to a separate file demo/account_demo.py, for
consistency with other localizations.
closesodoo/odoo#137700
Signed-off-by: Josse Colpaert <jco@odoo.com>
For the l10n_ro_saft module that generates the D.406 declaration, we
needed to:
- create a new export tax specifically for services (which should be
reported separately from goods); and
- make sure the Bank, Outstanding Receipts and Outstanding Payments
accounts are created with codes 5121xx, and the Cash account with code
5311xx, because codes 5120 and 5130 are not available in the official
CoA and were therefore causing validation errors in the SAF-T export.
- because the CUI number (found in the company_registry field) for
partners is required for the SAF-T export, and it is substantially
the same as the VAT number, re-use logic from l10n_be to automatically
fill in the company_registry if the VAT exists.
closesodoo/odoo#132269
Task-id: 3172198
X-original-commit: 74be0779164f8cd65c399977d5f3e058c213318d
Related: odoo/enterprise#45939
Related: odoo/documentation#5532
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Bugfix. When installing l10n_eu_oss with l10n_de_skr03, an OSS account
'17010 Unsatzsteuer 19% OSS' is created. However, this account has
no account tags set on it, so it gets left out from the Balance Sheet
report. (Note that in Germany, due to there being two CoAs, the Balance
Sheet report still works using account tags.)
The solution: when creating the OSS account, re-use the account tags
of the account we are copying.
closesodoo/odoo#130287
X-original-commit: f541ef903085ed95b0aa0bc6d3e82bf9efa2a23d
Signed-off-by: John Laterre (jol) <jol@odoo.com>
At the moment, there is no test that checks that normal credit notes
(i.e. of type TD04, not reverse-charge refunds) are correctly exported
in FatturaPA.
So we're adding one. We're making it a complicated credit note (it
contains some negative amounts) in order to improve the test coverage.
closesodoo/odoo#125690
X-original-commit: f7f2c4275531751253e0fe57a6a192fe98d6da5c
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Since the coming into force on 01/01/2016 of Legislative Decree 139/2015
implementing EU Directive 2013/34/EU, extraordinary gains and losses
should no longer be accounted separately on the P&L statement.
See this article https://www.fisco7.it/2017/02/come-ricollocare-nel-conto-economico-gli-abrogati-oneri-e-proventi-straordinari/
There is therefore no point in having special accounts for
extraordinary gains and losses.
So we are removing accounts 71 and 72, both from the CoA and from the
Profit and Loss accounts.
Since they should no longer be used since 2016, this should not have any
impact for existing users.
closesodoo/odoo#122990
X-original-commit: 19cd212f762afdc906aa9f41793cc5c1fa9ea828
Related: odoo/enterprise#41687
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Currently, if you use the automatic entry wizard to change the period of
a journal item dated prior to the lock date, you'll just get blocked
with a UserError, with no workaround.
This commit changes the date of the adjustment entry to be the first end
of month after the lock date. As a result, the adjustment entry can be
created.
Based on PR #92439closesodoo/odoo#122997
Taskid: 2823170
X-original-commit: fdeaff0a879bdf1242ed0a8d85e3e0363dd3276b
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
At the moment, the lock date message is generated in
_compute_tax_lock_date_message. We delegate it to a separate function
in order to use this message elsewhere as well.
Note: this refactor introduces minor changes in behaviour:
- we remove the second part of the lock date message (that mentions
other lock dates than the most blocking one), because it is too much
information.
- we calculate the new accounting date from the existing accounting date
rather than from the existing invoice date. This should not change
anything in practice, since the new accounting date will be the last
day of the period after the lock date.
task-2823170
X-original-commit: aeb6707dfc0f4aa093d7687bbb0e488558d2a99f
Part-of: odoo/odoo#122997
When creating an invoice with a positive line and a negative line, with
different taxes, the DatiRiepilogo node for the tax of the negative
line contained positive amounts when they should be negative.
This is because we were applying `abs()` too naively in the XML template
and in the code of _l10n_it_edi_prepare_fatturapa_tax_details.
This bugfix commit changes the logic to no longer use abs().
opw-3316300
closesodoo/odoo#122982
X-original-commit: 0241e96fe12401f0891efc00f840e03d0c0219fd
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Based on Allegro-IT's PR https://github.com/odoo/odoo/pull/112159
with several adjustments and fixes (renamed XMLIDs, taxes, fiscal
positions, VAT report).
closesodoo/odoo#121073
X-original-commit: 815a817ff53760d57f978fd88b529a8b38bda62d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Bugfix: at the moment, if the environment's language is not en_US,
loading a CoA doesn't correctly load the translations: the translations
for all languages are created with the en_US terms.
Steps to reproduce:
1. Create a DB and install l10n_be.
2. Switch to French.
2. Create a new company based in Belgium.
3. Install the Belgian CoA on the company.
Expected behaviour: The accounts should be in French.
Actual behaviour: The French translation of the accounts contains
the terms in English.
Analysis:
When the records are created by _load_records(), the language of the
environment is French. As a result, all translatable terms are created
with translations in en_US and in fr_FR.
See https://github.com/odoo/odoo/blob/39292a02ab34ea86abd5601055901eb968006944/odoo/fields.py#L1762-L1771
Later on, when the translations are loaded by _load_translations,
there already exists a name->'fr_FR', so our call to
translation_importer.save(overwrite=False) doesn't want to overwrite it.
See https://github.com/odoo/odoo/blob/2780c37cfdb8560ac7c725fd27f4fe272f1d3072/addons/account/models/chart_template.py#L787
As a result, we end up with the English terms in both the en_US and
fr_FR translations.
The fix:
Set the language to en_US when calling _load_records().
closesodoo/odoo#120863
X-original-commit: 52ef69aa8423a0fd5d78af1ab018a98dba87361c
Signed-off-by: William André (wan) <wan@odoo.com>
At the moment, XSD files are automatically downloaded at database
initialization, which is quite unnecessary.
The idea is to change Odoo's use of XSDs from being systematically
downloaded and used for validation to simply being available if desired
(e.g. for development or for customers who want them).
To achieve this, this commit does the following:
- remove the XSD download crons;
- provide a 'download XSDs' button in the Settings (next to the debug
mode button) which is available in debug mode;
- skip XSD validation if any required XSD file is not present; and
- deprecate the 'force_reload' option.
Entreprise PR: odoo/enterprise#38350
Task id: 3010716
closesodoo/odoo#118790
X-original-commit: c8174c7914e567489de74b574b076467440bdb2d
Related: odoo/enterprise#39879
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Issue / How to reproduce:
At the moment, if a localization's python module is not present,
the computation of the `ir.module.module.account_templates` field fails
with a ModuleNotFoundError
How to reproduce:
- Create a fresh DB with a localization e.g. l10n_be
- Remove the localization directory
- Start the DB again and navigate e.g. to Inventory > Configuration >
Settings. You will see a traceback, whose root cause is that the
computation of the `account_templates` field failed.
We noticed this in a runbot upgrade between 16.1 and 16.2, for a new
localization that was introduced in 16.0.
Solution:
Make the computation return False if the Python module cannot be found.
Also, filter out the modules where account_templates is False when
constructing the list of available chart templates.
closesodoo/odoo#113875
Signed-off-by: William André (wan) <wan@odoo.com>
Unfortunately, when I wrote the loc, I forgot to include
`account.group.template.csv` in `__manifest__.py`.
As such, the account groups were not loaded, and I didn't notice an
error in the chart template name.
Thanks to WAN for finding this.
closesodoo/odoo#110890
X-original-commit: 7610f1ef5f329a52ee16fe88909be30ddf395b8d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
In Odoo 16, we redesigned the `Accounting > Miscellaneous` menu to
provide a convenient interface for inspecting any journal entry or
journal item.
As such, it no longer makes sense to call it 'Miscellaneous'.
This commit aligns the name with the new functionality.
We also remove the default filter of the 'Journal Entries' view, which
restricted it to miscellaneous entries, and replace it with a filter
on posted entries, consistent with the purpose of conveniently
inspecting the accounting journals.
closesodoo/odoo#106749
Task: 3083921
X-original-commit: ee551d74557b889a463bd7dff234ff5f12539e4a
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
When creating draft deferred entries in a reconcilable account,
we should not attempt to reconcile them, because only posted entries
can be reconciled.
closesodoo/odoo#106603
X-original-commit: edaf019eac9124cb64c0a1dce55291d40b542256
Signed-off-by: William André (wan) <wan@odoo.com>
With PRs odoo/89145 and enterprise/26393 came new methods for
retrieving XSD files and using them for XML validation.
The new retrieval method expects modules to provide a 'prefix' that
is prepended to the XSD's filename. For example, l10n_cl_edi will
name its XSD files 'l10n_cl_edi.<filename>.xsd'.
However, this messes things up when one XSD file needs to import
another. For example, l10n_cl_edi.DTE_v10.xsd has the statement
'<xs:include schemaLocation="SiiTypes_v10.xsd"/>'
Currently, the filename resolver has no way of knowing that this
should resolve to 'l10n_cl_edi.SiiTypes_v10.xsd', not
'SiiTypes_v10.xsd'.
In addition, the new retrieval method saves the ZIP archives
received over the network under the '<filename.xsd>'. Thus
'SiiTypes_v10.xsd' might actually be a ZIP-encoded file.
So, we need to do something to fix the imports.
Here are two possible solutions:
1. We scrap this 'prefix' stuff and either save the ZIP files under
a different name, or we just don't save them.
2. Or, we provide a mechanism for indicating a prefix to the filename
resolver.
Personally, I don't see the point in saving the ZIP files, and this
'prefix' stuff seems pointless. So I prefer solution 1.
But, because I assume there must be a reason to all of that 'prefix'
stuff, here is an implementation of solution 2.
I'd be keen to know the reason, btw.
EDIT:
In addition to the first issue described above, we have the second
issue that some XSD files returned by the Chilean SII are encoded
using ISO-8859-1 encoding (e.g. SiiTypes_v10.xsd). If we leave them
in this encoding, then LXML isn't able to parse them when performing
imports.
closesodoo/odoo#102601
Solution: convert the files to UTF-8 before storing them.
X-original-commit: 75555df56475b457331938453657c1f73d231e33
Related: odoo/enterprise#32482
Signed-off-by: Josse Colpaert <jco@odoo.com>
At the moment, if we try to make a website field conditionally visible
based on whether a file has been uploaded, the field never appears even
after uploading the file.
Steps to reproduce issue
- Create a new fresh DB with the website app.
- Go to the Contact Us page, click on 'Edit'.
- Add a File Upload field
- Add another field, and set it to be conditionally visible on the
File Upload field.
Fix:
- Create visibility comparators for files (fileSet / !fileSet), which
check whether the `value.name` property is set / not set.
opw-2856054
closesodoo/odoo#93756
X-original-commit: fec02f6cfc4abd68f0d6bd49285580510fe59465
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
PR 91638 introduced a write() on the partner_id after the AML state
was set to 'posted'.
This causes a problem for users who have the journal hash activated.
Fix => move the write() before posting the AMLs.
closesodoo/odoo#91997
X-original-commit: cd3bbeb15983b263ba2ffb419d59575b64a41ca2
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
compute tax amounts corresponding to each invoice line in the edi
document for the invoice.
The issue
In Mexico, companies are required to send every invoice in electronic
format to the government. This document (called the CFDI) specifies,
for each invoice line, the taxes applicable, the amount before tax
and the tax amount. The document also specifies the total amounts
withheld for each tax which was applicable to the invoice.
The PAC (the external service which signs this electronic document
and sends it to the government) does checks on those amounts. In
particular, the tax amounts must satisfy two constraints to pass
validation:
(1) The total tax amount for a tax must be equal to the sum of the
tax amounts reported for each invoice line.
(2) The tax amount reported for each line must be equal to
(tax rate * base amount), rounded either up or down. For example, for
a line with base = MXN 398.28 and an applicable VAT of 16%, the
exact tax amount would be 0.16 * 398.28 = 63.7248, so the acceptable
values for the tax amount on that line are 63.72 and 63.73.
In v14, we used the AccountTax.compute_all method to compute the tax
amounts reported for each invoice line. This gave the exact tax
amount, rounded (either up or down depending on which side of 0.5 it
is). This always fulfils condition (2) but fulfils condition (1)
only if the tax rounding method is 'Round Locally'. Because of this,
in v14 MX users couldn't use 'Round Globally'.
In v15, we use a new SQL-based method to compute the tax amount
reported for each invoice line: we take the total tax amount, and
allocate it among the invoice lines proportionately to the base
amount of the invoice line. This always fulfils condition (1) but
sometimes doesn't fulfil condition (2). This has caused many issues
in customer DBs (see list of tickets at the end).
This was introduced in commit 433656415a and seems to be an issue
for all MX customers who have upgraded to v15.
The solution
@smetl and I have looked into what can be done about this.
Modifying the tax amount computation method in a way which satisfies
both conditions is possible, but requires more work and testing.
The existing v14 code generates tax amounts which satisfy both
conditions, at least when the tax computation method is
'Round Locally'.
A good temporary solution, while we try to modify the tax amount
computation to satisfy both conditions, would therefore be to use
the v14 tax amount computation when the tax rounding method is
'Round Locally'. While not ideal, this will at least enable
customers with the 'Round Locally' rounding method to correctly
submit their invoices to the government. Customers with the
'Round Globally' method will need to wait for the full fix.
This commit does exactly that.
Tickets linked to this problem (non-exhaustive list):
opw-2695243
opw-2733280
opw-2723571
opw-2724805
opw-2722370
opw-2722388
closesodoo/odoo#85407
X-original-commit: cddb5bc3af4806c7d1b9b09d07a5b9361d2815c0
Related: odoo/enterprise#24767
Signed-off-by: Laurent Smet <las@odoo.com>
The issue:
When creating a fresh DB with demo data, the demo company and
customer are created with l10n_latam_identification_type_id set to
the default, which is 'VAT', rather than 'RUC'.
This creates a problem when we create an invoice with the demo
company and the demo customer and validate it: when the l10n_pe_edi
module sends the invoice to the OSE, the OSE responds with the
following error code:
'1007|El dato ingresado no cumple con el estandar - [...]
error: Error Factura (codigo: 1007): 1007
(nodo: "cbc:ID/schemeID" valor: "0")'
Some observations on how the issue occurs:
Interestingly, when you create a new company or partner using the UI,
the `l10n_latam_identification_type_id` is automatically set to 'RUC'.
This is ensured by the `ResCompany.create()` and
`ResPartner._onchange_country()` methods, see
https://github.com/odoo/odoo/blob/f84dbf63b9354a3c577589178a09c3ffb151cba3/addons/l10n_latam_base/models/res_company.py#L10 and
https://github.com/odoo/odoo/blob/f84dbf63b9354a3c577589178a09c3ffb151cba3/addons/l10n_latam_base/models/res_partner.py#L24
However, when the demo company is created, the `create()` method is
called at the first <field> element, which is `name`, and so,
`create()` does not set `l10n_latam_identification_type_id`.
And because the demo partner is created without the UI, the onchange
is not called when the partner's country is set.
The solution:
Therefore it is necessary to manually set the
`l10n_latam_identification_type_id` in the demo data.
closesodoo/odoo#82920
X-original-commit: 33e174d58e7ad2a5a965f31a23c4b8281fedef79
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Issue:
Our functionality for merging PDFs from multiple vendor bills relies on PyPDF2. It is well-known that PyPDF2 is sometimes unable to manipulate even perfectly normal PDFs. To provide a helpful error message to the user when this happens (i.e. give them the names of the vendor bills corresponding to the offending pdfs), the `_get_unreadeable_pdfs()` function is called right before we try to merge the PDFs in `_merge_pdfs`. This function is meant to identify the offending PDFs and provide them to the user.
However, _get_unreadable_pdfs did not notice the problem with 3 of my customer's pdfs, because the error was only triggered once the PdfFileWriter.write function was called in _merge_pdfs. This function, however, is not called in _get_unreadable_pdfs, therefore, it did not notice that anything was wrong.
Fix:
- Change _get_unreadable_pdfs so that it also makes a call to PdfFileWriter.write
- As soon as PdfFileWriter.write fails once, it will continue failing when we append more PDF streams to the PdfFileWriter. I therefore suggest initialising a different PdfFileWriter at each iteration of the for loop in order for an offending PDF to not cause a false positive on subsequent PDFs.
closesodoo/odoo#78966
X-original-commit: 0b4efd37376223806e7ff7273f520b2d17337bc8
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
