The spec for electronic invoices in Colombia was updated and is now
known as Anexo 1.9. This was done in the related enterprise PR (module l10n_co_edi).
This commit introduces some changes in the base module that are needed
for the Anexo 1.9 update.
task-3639271
closesodoo/odoo#151431
Related: odoo/enterprise#55279
Signed-off-by: Josse Colpaert <jco@odoo.com>
Currently we assume that all imported invoices are incoming (i.e. bills).
This was i.e. done since the tax agency only sends users bills.
But some clients import invoices from other software (i.e. onboarding/starting).
After this PR we decide whether the invoice is outgoing or ingoing and
import the invoice correctly in either case.
task-3650355
closesodoo/odoo#159889
X-original-commit: 292521ddd566cd3d49df2dd2eb4e2850dc47620a
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
Currently there is the following problem when reloading the chart.
Journals without xmlid may not be matched to chart data correctly
(via code or name).
This then leads to duplicate journals being created / uniqueness
constraint issues on journal codes.
The matching happens in `_pre_reload_data`.
This should only be a problem for upgrade or user created journals
since journals created from the chart data have an xmlid.
The problem was introduced in commit d6695f2892ded178371f6c69cf594037c19ce438 :
(1) We load the chart data in en_US to be able to use the code translations
(2) We switched the language of the loading process to en_US
(to switch the chart data to en_US for the previous point and to
avoid inconsistencies)
When matching journals in the DB by code or name to the chart data:
- We fetch the en_US name of the journals in the DB due to (2);
Code is not translatable.
- We compare those values (journal code / name) against the en_US term
due to (1).
Thus the matching fails.
This commit improves the matching:
We also compare the name and code (still en_US version)
against the translated values.
closesodoo/odoo#159871
X-original-commit: 005ebd59cba6b6ca20c736c46d89259af8bd251a
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
There are currently translation issues related to the chart template.
Due to this the names of some records do not receive the necessary
/ intended translations when installing a localization or new language.
When installing a new localization / chart some records have the following
problem with the values of their translatabe fields:
They are only installed in the language that was active when the localization / chart was installed.
Thus when switching languages (or using a different user with a different language)
the names are displayed in the "installation language".
Translations for all active languages should be installed (for all relevant records).
The same problem happens when installing a new language
(the same records do not receive a translation for the new language).
The translation issue concerns for example (some) accounts and journals;
see the (incomplete) list at the end of this message.
This commit tries to fix the translation issue for the translatable
fields of all relevant models.
Note!
=====
* The translation mechanism only works for records with xmlid.
If a module creates a record without xmlid it will not be translated.
* The problem is only fixed for records with xmlid for which at least 1 of the
following conditions holds:
* The record (and the translatable field value) is defined in
the body of the function decorated with '@template'
* The translation of the value of the translatable field can
be found in the module 'account' or in the module that
is associated with the record (by 'ir.model.data')
I.e. the problem is not solved for demo data: It is technically
difficult to determine the module they originate from.
This makes it difficult to load the right code translation (the
module information is needed for this).
* The translation mechanism is not necessarily triggered
if the record is (in principal) part of the chart template
but not installed as part of the chart template.
This can i.e. happen if a module is installed after the
localization / chart.
* Example: account.journal "Salaries" from hr_payroll_account
* We also want to "translate" / localize some untranslatable fields
(like account journal codes). For these fields the terms will be
installed in the language of the partner of the company for which
the chart will be installed (fallback to lang / user lang from the
env in case there is none set).
* Currently there is no language set for many (all?) demo comany.
Thus the values will remain in English for them (when the
respective module is installed).
Examples / Details
==================
**Reproduce**:
1. Switch to the French language (install if needed)
(Settings App > General Settings > Languages)
2. Install a localisation (e.g. l10n_fr).
3. Check the French translations of the localization
* Comptabilité > Configuration (Menu) > Journaux
(Accounting > Configuration (Menu) > Journals)
* Here the journal names are in French
* Comptabilité > Configuration (Menu) > Plan comptable
(Accounting > Configuration (Menu) > Chart of Accounts)
* All the account names are in French
4. Switch to English on the current user (or some other language)
via the user profile on the top right.
5. Check the names of the localization again
* Accounting
* The journal names are still in French
* Accounting > Configuration (Menu) > Chart of Accounts
* Some of the account names are still in French
* E.g. "Compte d'attente de la banque" ("Bank Suspense Account")
Other things to test:
* "Salaries" journal from enterprise module 'hr_payroll_account'
* Not demo data; it will (partly) work after this commit (see "Note" above)
* "IFRS Automatic transfers" journal from enterprise module
'account_auto_transfer' (installed when installing l10n_fr)
* Demo data; the problem remains after this commit
**Technically** the main problems are the following:
1. The information of some of the created records is only defined in
the code. Thus their translations have to be taken from the
translation of the code.
But at the point of translation it is not clear from which
module the data came from. This is needed to load the right translation.
* This was fixed for data from '@template' functions
2. Some records are created without an xmlid and thus
cannot be translated with the current translation mechanism at all.
* This was fixed for the relevant records from module 'account'
Example Records
---------------
Some affected **accounts**:
* from module 'account'
* Bank utility accounts
* Bank Suspense Account
* Outstanding Receipts
* Outstanding Payments
* Cash Discount Loss
* Cash Discount Gain
* Cash Difference Loss
* Cash Difference Gain
* Liquidity Transfer
* Bank / Cash journal default accounts
* Bank
* Cash
* Unaffected earnings account
* Undistributed Profits/Losses
Some affected **journals**
* from module 'account'
* Customer Invoices
* Vendor Bills
* Miscellaneuos Operations
* Exchange Difference
* Cash Basis Taxes
* Bank
* Cash
* from module 'account_auto_transfer' (enterprise)
* IFRS Automatic Transfers
* The problem will remain since it is demo data
* from module 'hr_payroll_account' (enterprise)
* Salaries
* The translation is only loaded if the module is installed
before the localization / chart
task info
=========
task-3414329
closesodoo/odoo#158382
X-original-commit: bd6040fb8b1dee9efe0e461a6812ecf7acbb517e
Signed-off-by: William André (wan) <wan@odoo.com>
Currently the eCommerce workflow in Ecuador lacks some information
needed to issue EDI invoices.
The main adaptions needed are:
* Identification type and number in the checkout process (in the billing address)
* SRI Payment Method in the eCommerce Payment Method
SRI Payment Method
* The SRI Payment Method value is required for the EDI
* In the payment method form view the SRI Payment Method field is hidden
if the list of fiscal countries of the selected companies does not include Ecuador.
* Payment methods which do not have an associated SRI Payment Method
cannot be used in the eCommerce checkout of an Ecuadorian company.
* A (default) SRI Payment Method has been addeded to some payment methods to simplify the setup.
* When creating an invoice from a sales order we try to compute the SRI Payment Method as follows:
We consider all the SRI Payment Methods of the payment methods of the payment transactions associated with the sales order.
If there is exactly 1 such SRI Payment Method we use this on the invoice.
This should ensures that we can always set the SRI Payment Method on invoices created through the eCommerce flow.
task-3585823
Part-of: odoo/odoo#142730
In Ecuador, the ZIP code is not a required field to create invoices.
Customers usually don't even know their ZIP code as the street number,
city and state (province) are mostly used for delivery (and not the
ZIP code).
task-3585823
Part-of: odoo/odoo#142730
Consider an invoice that was reset to draft.
When its is edited to be '/' (and the record is saved) an additional "Draft" title appears.
It should not appear.
After this commit the "Draft" title will not be shown on invoices
that were posted before.
task-3680398
closesodoo/odoo#152110
X-original-commit: d0876de81dc66cb6483598deb33bf6c81212ec89
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
Currently the "Invoices to validate" link is broken in case the module
account_3way_match (from enterprise) is installed.
The same link / context is used for "Invoices to validate"
and "Bills to validate". (The text inside the link is just changed
depending on the journal type.)
The module account_3way_match changes the context of that link to
change the behaviour for the "Bills to validate" (bill specific filter).
This breaks the link for "Invoices to validate".
This commit makes invoices and bills have dedicated / separate links.
Thus after this commit account_3way_match only changes the behaviour of the "Bills to
validate" link.
task-3680398
closesodoo/odoo#149352
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
There is the following problem when editing the tax amounts on an
invoice (in quick-edit mode or via the journal item):
The changed amounts are displayed correctly on the PDF but not in the
EDI XMLs (e.g. the embedded factur-x).
This commit corrects this.
Reproduce
1. Create a new invoice
2. In tab "Invoice Lines" add 2 lines with taxes from different tax group
3. Go to tab "Journal Items" and change the tax amounts
(or use quick-edit mode; needs to be enabled in the settings)
4. Go back to tab "Invoice Lines" and notice the tax amounts of the groups
were changed.
5. Generate a PDF: Here the tax amounts are correct (the changed amounts)
6. Look at the embedded XML: Here the tax amounts are
wrong (initial / unchanged amounts).
The same issue applies to multiple other EDI exports.
To activate the EDIs go to:
Accounting > Configuration > Journals > Customer Invoices
> Advanced Settings tab > Electronic Data Interchange
The EDIs can then be found as attachment in the chatter after confirming
and/or printing an invoice.
task-3535411
closesodoo/odoo#151090
X-original-commit: 5d456ce13970980efa8b1efab92323e995eaa848
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
Currently there are the following bugs when XML-exporting invoices
that are not in company currency and use discounts:
* The discount is computed and exported in document currency.
But it should be exported in company currency.
* The unit price value (excl. discount) is computed wrongly
since it uses the wrong discount value.
This commit corrects the discount and unit price computation / export.
closesodoo/odoo#148566
X-original-commit: 1cc846e8a53fd7c4298b7324d9c4f272592f0497
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
Currently there is the following issue with cached conversion rates
from the "from currency" to the "to currency".
When the rate of the res_currency_rate of the "to currency" changes the cache is not invalidated.
Thus the cached value may be used wrongly (leading to wrong results).
This commit simply invalidates all the cached rates in case we update or
create a res_currency_rate.
closesodoo/odoo#143847
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Previously a 10mm margin was added between the top edge and the image below.
The way the margin was added only offsets the picture by 10mm without
adjusting the image size (see PR #143383).
This may lead to an overlap between the image and text
below (depending on the dimensions of the image).
This fixes this issue by putting the 10mm margin "inside" the image
instead of "outside" of it. Thus the size of the image is adjusted correctly.
closesodoo/odoo#144687
X-original-commit: 1676436f522399e78877725d99e845550f1b5c9a
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Currently there is a traceback in case of a 100% discount on an invoice line.
This commit fixes the issue by computing the discount differently.
Previously it was tried to calculate the discount amount from the
discounted value and the discount factor.
This is (mathematically) not possible if the discounted value is 0.
After this commit we compute and use the undiscounted value in case
the discount is 100% to compute the discount amount.
The computation was adapted from '_prepare_edi_vals_to_export' from account.move.line
Reproduce
1. Install l10n_es_edi_tbai
2. Select the Spanish company
3. Settings > Accounting: Ensure "Test Mode" is set in Spain Localization section
4. Create a new invoice with Spanish customer
5. Add a line with a 100% discount
6. Confirm the invoice
7. Process the invocie with TicketBAI
8. Error / Traceback
opw-3572426
closesodoo/odoo#144571
X-original-commit: 74aa7136fea8bd0f962c577fba89bbd4f7618742
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
The values in the "Total" measure are all displayed in the move currency.
Due to this amounts in different currencies are added together.
As a workaround we introduce the possibility to group by move currency.
Thus the user can choose to seperate the values by currency.
The "Total" column was renamed to "Total in Currency" to avoid confusion
There is a remaining problem.
The totals of the individual groups are still added up to form a total.
Previously it was tried to convert the values from the move currency
to the move company currency and then to the active company currency.
The problem is that there is no efficient way to do it correctly.
task-3613358
closesodoo/odoo#144065
X-original-commit: 6d7d86cd0d8335f192112129ee92077f1f25e55b
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
Due to performance reasons a previous commit was reverted.
This reverts commit 28004b7e92f22cf0f0078d4512f8a5f59c82122c.
The reverted commit i.e. converted the "Total" measure to company currency (at the time of the invoice).
The query to do this (correctly) had performance issues.
task-3613358
X-original-commit: a0121dcc72eb99519ae291e48e4e03a091b234df
Part-of: odoo/odoo#144065
Currently there is no margin between the top edge and the image below
in the DIN5008 layout.
Thus the image may be cut off when printing the page.
This commit adds a 10mm margin.
opw-3599133
closesodoo/odoo#144013
X-original-commit: 23e6f7c0f8b793d4aa30df8a65b29def516ecb87
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
Currently the following precaution is taken to not "lose" taxes
when reloading the chart template:
When the tax associated with an xmlid changes,
we "backup" the "old" tax (name prefixed with '[old] '; xmlid removed)
instead of just overwriting it.
Currently only active taxes are prevented from being overwritten.
This commit ensures that also inactive taxes are "protected".
closesodoo/odoo#142294
X-original-commit: 80babc7806cfeb1319cc857f14ea51cf8a224fd7
Related: odoo/enterprise#50806
Signed-off-by: Josse Colpaert <jco@odoo.com>
Co-authored-by: Wolfgang Taferner <wolfgang.taferner@wt-io-it.at>
[IMP] l10n_at: EC sales list
[FIX] l10n_at: wrong tax mapping
[FIX] l10n_at: description on the invoice should be neutral
[FIX] l10n_at: new version
X-original-commit: c42b4e682195d20c253c97e762dd57cf6859b492
Part-of: odoo/odoo#142294
Co-authored-by: Wolfgang Taferner <wolfgang.taferner@wt-io-it.at>
[IMP] l10n_at: more balance tags for details
[IMP] l10n_at: add more tags to organize
[IMP] l10n_at: add additional fiscal positions for auto detection
Unfortunately the rules do not allow to have less fiscal positions
as vat required is prioritized before country.
X-original-commit: eabb0c385534a9612074807ab378bc36a4bc6097
Part-of: odoo/odoo#142294
Co-authored-by: Wolfgang Taferner <wolfgang.taferner@wt-io-it.at>
[FIX] l10n_at: add missing tax (§ 19 Abs. 1e) + better inline references
[IMP] l10n_at: extend KZ 021 to have one tax for each use case
[FIX] l10n_at: tax groups and tags
[IMP] l10n_at: Import Taxes Use Case simplified
[FIX] l10n_at: remove tax as not understandable for everyone
Reduce the profile of this tax to a minimum to keep existing configurations as the former configuration is wrong and the newer one is to difficult to understand, but might be improved or explained properly in the future.
X-original-commit: a605a08173178d361f300f4d4bf8c3afc90c1273
Part-of: odoo/odoo#142294
Co-authored-by: Wolfgang Taferner <wolfgang.taferner@wt-io-it.at>
Currently the tax_scope field is never used and thus the column does
not exist.
An empty column is introduced in this commit.
It will needed for the following commit.
The commits are kept separate to make it easier to review the actual
changes in the next commit.
X-original-commit: d12f5e301eaa9a31c6e2e2b3c984857d573ddd33
Part-of: odoo/odoo#142294
Sometimes the user needs to import XML invoices (e.g. factur-x)
containing lines with the following problem:
The billed quantity of the line is set to 0 but the total of the line
(plus/minus allowances) is not 0.
The imported version (in odoo) of this line will have quantity 0 and thus a
total of 0 (since the total will be computed in odoo and not stored
directly in the database).
After this commit the quantity of these line will be calculated
such that the total computation yields the correct total.
To do this an already existing similar "exception" in the parsing
logic was extended to deal with this problem.
closesodoo/odoo#137833
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Currently for the "Total" measure on the invoice analysis report
the values in the currency of the invoice are used.
This is a problem in multi-currency environments: Different
currencies are added together leading to nonsensical sums.
This commit converts the "Total" measure to company currency (at the
time of the invoice).
In multi-company case the "Total" measure is further converted to the currency
of the active company (using the day of the report creation for the
conversion rate).
The "Total" will also be displayed in company currency when viewing
the invoices in the list view of an entry in the table (by clicking on the entry).
task-3537868
closesodoo/odoo#141277
X-original-commit: 28004b7e92f22cf0f0078d4512f8a5f59c82122c
Signed-off-by: William André (wan) <wan@odoo.com>
Currently the accounts and tax report are still defined directly in German.
This commit translates them to English and uses the appropriate
translation mechanism for the translation into German.
task-3354661
closesodoo/odoo#135485
Related: odoo/enterprise#47405
Related: odoo/documentation#5859
Signed-off-by: Josse Colpaert <jco@odoo.com>
The Austrian SAF-T specification defines a chart of accounts (CoA).
All accounts that are "exported" in the SAF-T document have to be
annotated with their corresponding account in the SAF-T CoA.
This commit introduces tags to associate individual accounts with a code that
should be used for external reports.
For now they will be used to map the company's CoA to the SAF-T CoA.
task-3354661
Part-of: odoo/odoo#135485
This commit adapts the default chart of accounts to be compatible with
the SAF-T chart of accounts.
In other commits new tags will be added to each account that map our
CoA into the SAF-T CoA (and the account names will be translated).
To make it easier to review the CoA changes the changes are kept separate in this commit.
The account "2600 eigene Anteile" was moved and made into an equity
account since as of today they are part of the equity section of the balance
sheet (by law).
task-3354661
Part-of: odoo/odoo#135485
*: 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>
Currently there is the following problem in the document layout preview:
("Settings" app > "General Settings" > "Companies" section > "Configure Document Layout")
The address is displayed in the wrong place for the DIN5008 layout
(from the l10n_din5008 module).
This is fixed in this commit.
closesodoo/odoo#131935
X-original-commit: 663334157cc4867c63aedea8d8d893eb765cfe25
Related: odoo/enterprise#45754
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
The i18n related files are currently not up to date.
This is fixed with this commit
X-original-commit: fb5b600ce8b4f6d6a8a0422ecef323cb25dffbbd
Part-of: odoo/odoo#131935
Currently the phone number is printed as part of the address
if the "fallback address" is used as address.
In DIN5008 the address does not contain a phone number.
This commit removes the phone number from the "fallback address"
task-3394263
X-original-commit: 6e437341bb067d31d01e529b251092f2fd74e940
Part-of: odoo/odoo#131935
This commit fixes a bug (corner case) concerning payments
to yourself where an early payment discount is applied.
Details / steps to reproduce the bug:
1. Create an invoice
2. Select your own (currently selected) company as customer
3. Select some payment term with early payment discount (e.g. '2/7 Net 30')
4. Confirm the invoice.
5. Click "Register Payment" and keep the default values (i.e. "Mark as fully paid" should be selected)
6. Click "Create Payment"
7. A User Error like the following should appear (with different journal entry names):
"Journal Entry Draft Entry PBNK1/2023/00001 (INV/2023/00005) is not valid. In order to proceed, the journal items must include one and only one receivable/payable account (with an exception of internal transfers)."
Why the bug happens:
The early payment discount adds some extra lines to the journal entry associated with the payment.
Currently those extra lines are classified as "counterpart lines" since the customer is our own company.
But there must be exactly 1 "counterpart line".
How the bug is fixed:
The condition that classifies the extra lines as "counterpart lines" was only intended for internal transfers.
Each company has a related "transfer account" that is used as an intermediary account for internal transfers.
Thus the old condition (c.f. commit diff) when checking whether a line is a "counterpart line"
can be replaced by checking whether the account associated with the line is the "transfer account" of our company.
task-3388294
closesodoo/odoo#127844
X-original-commit: b1536ecb6bc94a2bd5ff3bdf1b73289ca87a744d
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Sven Fuehr