The open_action_with_context was not using _for_xml_id, producing an
error when reading the action content.
In open_action, the action_name was taken from the context and needs
sanity checks. Ensure only actions from the account module can be
read and only if the user has access to the target model.
This is a limitation of the previous behaviour but, at the moment, all
known calls are made refering to an action from the account module.
Limit the scope of this method while the 14.0 is still early to avoid
having a door open to ready any action, and difficult to close later.
Remove old action fetching from the context in create_move that is no
longer used.
closesodoo/odoo#61602
X-original-commit: a39e94f7e4dc74e850650ac90bbc5f85af130bc8
Related: odoo/enterprise#14695
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
Create a tax as follows:
* Tax Computation: Percentage of Price Tax Included
* Tax Scope: Purchase
* Amount: 100%
* Included in Price
* Affect Base of Subsequent Taxes
Create a vendor bill with the tax on the line
Change unit price
The total does not change
This occur because when having 100% tax debit/credit are unchanged.
So the onchange `_onchange_mark_recompute_taxes` is not triggered and
the tax lines are not updated, thus not changing the
total (as in this case the invoice total is just the tax value)
opw-2370861
closesodoo/odoo#61555
X-original-commit: 9e203cc016b45875f699ffab24fe3f8382a97303
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
A cash rounding precision must be strictly larger than zero to follow
the restriction introduced in e270e9e0cc.
opw-2341804
closesodoo/odoo#61382
X-original-commit: 563752358d233d4fc9cf1d7e7abd0b1656dc82c1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
We extract the `price_unit` and `tax_ids` recomputation logic from the
`_onchange_product_id` method. This way, it can be called
programmatically.
opw-2371934
closesodoo/odoo#61477
X-original-commit: ca6f25bef45137c032bc5cafd336c3f16a97a929
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The order to find when to reset the sequence needs to be the following:
* find a sequence used before the date of this move
* if there isn't any, find the sequence of any move
Because we were not looking at the second step for bank statements, we
could have an issue since we were not checking the sequence relative to
the correct date.
closesodoo/odoo#61495
X-original-commit: b863b9cfedb3e7b4d1e3d409c829ffa0bfa1d9bb
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
We need to ensure the name stays consitent with the journal_id and the
date when we try to change one of those fields.
X-original-commit: 634aaeeac36d2371743338536466a0bcc9ad6c69
Steps to reproduce:
- Let's consider a camt file F with Stmt Id > 2147483647
- Import F
Bug:
An index out of range was raised because range of an integer type in postgresql must be
in [-2147483648, 2147483647]
opw:2372401
closesodoo/odoo#61391
X-original-commit: 953d3069fb77605a8d69f80124d011144595d459
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When the invoice is fully reconciled but not using payments, set the 'paid' status on invoices.
closesodoo/odoo#61339
X-original-commit: 052324cca4ec8682f065a4158e86fc113b0242e0
Related: odoo/enterprise#14590
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
A classic payment uses the outstanding account to create the line that needs to be matched later with a statement line.
In some cases, the user doesn't want to encode twice the same transaction, e.g. when encoding a cash payment, and want to create directly a payment impacting the cash account to skip the 'statement line' step.
X-original-commit: 2b472fd59e8eebbc2cf1f592cf6e657f2ae9e778
Use case:
1) Create an invoice matching reconciliation model, matching 90% percent of the amount, with a write-off line applying a 100% write-off of the remaining amount.
2) Create a 100€ invoice
3) Create a bank statement with a 90€ statement line whose payment reference corresponds to the one of the invoice
4) Click 'reconcile' on the bank statement
On enterprise, this crashes when preparing the data to give to the reconciliation widget, as the write_off_vals key is not set properly by the call to _apply_rules.
OPW 2367754
closesodoo/odoo#61265
X-original-commit: 1dd6199519b4ad5b5b17dfa17965ededcecb6da4
Related: odoo/enterprise#14563
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before that, even though the code contained something about it, the duplication of account.journal objects handled their code field pretty poorly (as it was trimmed to 5 characters), leading to situations where journals could have the same code, leading to possibility for account moves to have the same name.
This commit improves the SQL constraint testing journal codes so that they must now be unique per company. We also recompute the code in a more advanced way so that journal duplications works as smoothly as possible.
Task 2346404
closesodoo/odoo#59791
Related: odoo/enterprise#14447
Related: odoo/upgrade#1880
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The dashboard "View Statement" action on bank journals was using the
`open_action` helper, but it was badly computed for journals with
`bank_statements_source` set to `online_sync`. We were directed to the
statement lines instead of the statements; and there was no other way to
go to the list of statements.
closesodoo/odoo#61190
X-original-commit: 78286851034b8f3ef4dcab78e50b7220c0bdd213
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
Steps to reproduce the bug:
- Create a vendor bill VB1 with one line L1
- Set an analytic account AA on L1
- Post VB1
- Create a new vendor bill VB2
- Set VB1 on the field Auto-complete
Bug:
The created line L2 on VB2 had no analytic account
PS: In 12.0, the analytic account was kept when using Auto-complete field
opw:2359432
closesodoo/odoo#60962
X-original-commit: 5f46c50442dbe42bc534718719a6b19ee087eab0
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Co-authored-by: smetl <las@odoo.com>
When the exchange difference journal entry shouldn't be created, don't check its configuration in order to avoid an UserError in single-currency company.
closesodoo/odoo#61047
X-original-commit: 3ab451f3c4ce8dd42337f43628c1335d2caee011
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Issue
- Install "Accounting"
- Go to "Configuration/Reconciliation Models"
- Create new reconciliation model "Test" with "620000 Bank Fees" account
- Go to "Customers/Payments" and try to reconcile a payment via "Manual Operations"
by clicking on "Test" button
Cause
This instruction "st_line.company_currency_id.is_zero(residual_balance)"
needs at least one element in st_line
Solution
Skip this instruction if "st_line" is empty
opw-2370034
closesodoo/odoo#61045
X-original-commit: 161a6c494a412097468fca214817c42f022d29e2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Use of '_for_xml_id' instead of read in order to avoid
access right issue on 'ir.actions.act_window'.
closesodoo/odoo#60946
X-original-commit: 4e65fbf14491ea97415ede6d10385222c8d4d074
Signed-off-by: ndeodoo <ndeodoo@users.noreply.github.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this, misc operations always used the balance of the base line as the tax_base_amount of the tax line. This was inconsistent with the invoices, for which we invert its sign when making a sale invoice or a purchase refund (as for those operations, positive amounts are put in credit). This commit should make everything behave in the same way.
closesodoo/odoo#60912
X-original-commit: 2ca3158ce2de596526067dbd86da2ef7d4ae85bd
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
* Analytic defaults keep their old value
* The date_maturity is non-sense, it isn't set on lines needing analytic
* Analytic default should work for misc. operations too, but only for
product/service lines on invoice documents.
closesodoo/odoo#60904
X-original-commit: 4d2b8dd1bef40c592215728fab6c31f192176e93
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
Purpose
=======
Change the logic of the KPI "Day-1" to "Last 24 hours", so new freshly
created data in the free trial are included in the statistics (same for
last week and last month logic). This requires to change from date-based
computation to datetime-based.
Change the URL of the "connect" button from "/web/login" to the root
URL (so the user is not stuck if he didn't activate yet his database).
Task ID-2359406
closesodoo/odoo#60166
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When switching immediate payment term to 30% advance then back to immediate payment term, the receivable line is back to its previous value.
This is due to the '_get_fields_onchange_balance' that is not updating correctly the business fields since price_subtotal == amount_currency.
So, when `writing`, debit/credit are removed from the dictionary because the values are the same as before. However, `price_unit` hasn't be updated with the new value and remains as its previous value.
It leads to a recomputation of accounting fields regarding the business fields and then, trigger the unbalanced journal entry.
closesodoo/odoo#60654
X-original-commit: 18b5ad16a442404061b1028c2ffd82f179beaba3
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
A tax line could have something in the `tax_ids` field.
Then, these condition needs to be inversed in order to not handle them as base lines.
closesodoo/odoo#60473
X-original-commit: eada9f91f3361f8335c23b3a27161803cfda6608
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Behavior before the fix:
- if you create a sales order for a customer invoice address (a child
partner record), then create the invoice for that order, the partner_id
is not consistent between the move_line (some get the child partner id,
some get the commercial partner id = the parent partner id)
- if you create the invoice directly from the accounting app for a
child partner, the commercial partner id is used consistently for all
move lines (the invoice itself keeps the child partner id)
Behavior after the fix:
- when an invoice is created from a sales order, the partner id is set
using the commercial partner id, consistently for all lines (in this way
the behavior is consistent with that of the accounting app)
It is more appropriate to use the commercial_partner_id for this purpose
as it is used pretty consistently in the account_move file
opw-2347878
closesodoo/odoo#60302
X-original-commit: cd299518ae45f2732d47788869b013be16b814e8
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Nicolas Galler <nicocrm@users.noreply.github.com>
Currently the onchange is setting the price_unit to the price_subtotal to work out the proper price unit related to the tax, but does not have a different line quantity in mind.
The update of the price_unit was raising a balance difference UserError which is now resolved by the fact that we only update the price_unit if it is affected
OPW-2362066
closesodoo/odoo#60256
X-original-commit: 8c8d803992c31ba68a12801fa6dd4dcf909d9ed9
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Suppose two price_included taxes: 10%, 20%, a product having a sale price of 110.0 and a fiscal position tax 10% => tax 20%:
When onchange_product_id is called, the price_unit is computed as follow:
110 / 1.1 = 100
100 * 1.2 = 120
So price_unit = 120 and balance = 100.0
But in onchange_uom_id, we do the same thing and we call _get_fields_onchange_balance_model with balance=100.0.
However, in this method, an empty dictionary is returned because price_subtotal == balance.
Then, {}.get('price_unit', price_unit) will return the original price_unit (110.0) instead of the new computed one (120.0).
closesodoo/odoo#60108
X-original-commit: f2a5476c52c1312d3dfc558f92b4a678d6aa5e25
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
As-is, the warning will reports that post() is called from within
post, which is not very convenient when trying to find what calls
post() (as there are other "post" methods in the system).
By increasing the stacklevel from 1 (default) to 2, the warning will
report the method's caller, which is a lot more useful.
closesodoo/odoo#60043
X-original-commit: 5bc6eb9b387112138ac118726ff746bad6d00f8d
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- Create a tax:
5%
Included in price
- Set the company currency to USD
- Set the currency rounding of CHF to 0.05
- Set the rate for CHF to 0.654065014
- Create the following invoice in CHF:
Set a payment term
Prod 1, 1 unit, 5.0 CHF, tax 5%
Prod 2, 1 unit, 10.0 CHF, tax 5%
Prod 3, 1 unit, 50.0 CHF, tax 5%
It is not possible to save the invoice because of an unbalanced journal
entry.
Indeed, the Receivable line is $99.30 while it should be $99.29. This
happens because we round the `total_balance` with the rounding precision
of the invoice currency while it is in the company currency.
closesodoo/odoo#58798closesodoo/odoo#60035
X-original-commit: dad5e2a575448b68cc1b59880fecfe48dbe30a4e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a tax:
5%
Included in price
- Set the currency rounding of the company to 0.05 (e.g. CHF)
- Create the following invoice
Prod 1, 1 unit, 5.0 CHF, tax 5%
Prod 2, 1 unit, 10.0 CHF, tax 5%
Prod 3, 1 unit, 50.0 CHF, tax 5%
The total amount of the invoice is 64.95 CHF instead of 65.00 CHF, even
in a 'Round per line' configuration.
It happens because `compute_all` rounds the amounts following the number
of digits of the currency instead of using the `rounding` field.
Note that there is a discrepancy between the POS computation and the
Account computation: the POS already uses the `rounding` field instead
of the number of digits:
https://github.com/odoo/odoo/blob/80073c5430f0ab562dfc27572c108114161ebb25/addons/point_of_sale/static/src/js/models.js#L1855-L1991
opw-2341566
X-original-commit: 94353ebd6b47a286157f0559b194ff03ea49ff68
Do not set a default `account_id` for section and note lines. Indeed,
when set the constraint `check_non_accountable_fields_null` will raise.
fine-tuning of c22f99dd09
opw-2357415
opw-2355559
opw-2359283
closesodoo/odoo#59988
X-original-commit: b6791a5183ef1015b47312785501a99ed68e5718
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Steps to reproduce the bug:
- Enable Multi-Currencies and Multi-Companies
- Create a vendor bill
- Remove the default journal
- Set an other currencies
Bug:
A traceback was raised
opw:2350490
closesodoo/odoo#59546
X-original-commit: d9f8efcc330bc7454411aad3546de663424724f7
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The date depends on the user's locale, and needs to be consistent with
the `date` field.
closesodoo/odoo#59580
X-original-commit: ed06aab626cb51b86b4178705b45bbcbfbf2c0f2
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
In case we have an account type which is allowed it is not needed to check the account allowed as it would fail although the account type is allowed before, so we need to do the check correctly as it was done in previous versions.
closesodoo/odoo#59547
X-original-commit: 220a1ffe69ddd9e4b45f31bf2911f1b6c3bfdfd7
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Steps to reproduce the bug:
- Open a customer invoice I
- Click on the partner P set on I
- Change the contact name of P
- Go to the list view of customer invoice
Bug:
The name of P was not updated.
opw:2354492
closesodoo/odoo#59507
X-original-commit: be5d72974ad89c985e413f0eb84352a00a6cd043
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Select an invoice in the list
- Click Action -> Export
- Select "I want to update data (import-compatible export)"
- Click the field "Tax Cash Basis Entry of"
Bug:
Traceback
Cause:
Crashes because of a KeyError here: https://github.com/odoo/odoo/blob/2d860cdddf29b9fbd1a5401082c9f743028d2fb5/addons/web/controllers/main.py#L1743
The KeyError occurs because AccountPartialReconcile hasn't got a `name` field; `rec_name` is therefore `None`. Setting it to any field fixes the issue and `id` is the safest.
opw:2349511
closesodoo/odoo#59273
X-original-commit: 6327c86d0ea30bc056c6db320d0a1413d5807b10
Signed-off-by: backspac <backspac@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, the terms and conditions could not be html formatted text.
closesodoo/odoo#56512
Taskid: 2304199
Related: odoo/upgrade#1689
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closesodoo/odoo#59022
X-original-commit: 26efc84c5cac47a2cc83d7b084f8b71528fec6c7
Related: odoo/enterprise#13781
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When coming from the dashboard (dashboard => Bills to pay => Bill)
The context contains information about the purchase journal and not the
move line, causing an issue in the wizard. This change will make sure
the context always contains the necessary move line information
Task id #2344722closesodoo/odoo#58835
X-original-commit: f9ef2c8cd980ecb9eee22d4cc43d5291953471ef
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
- Install accounting
- Create a company with a '.' as last character of the name, e.g. 'Test
Inc.'
- Set the Fiscal Localization for the company
An error occurs: "You cannot use anything else than unaccented latin
characters in the alias address."
This happens because we try to create the alias `test-inc..inv`: `..` is
not allowed by the RFC 3696.
We replace the `.` by `-` which is a supported character in the
localpart.
opw-2347965
closesodoo/odoo#58904
X-original-commit: 5053183ac7612d9cf2247b84ec6e0aac5974fd85
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In a multi-company environment it can be difficult to see which journal
is from which company on the dashboard, when multiple company have been
selected.
This commit will update the dashboard to show the company names on the
journals in those cases
Task id #2337719closesodoo/odoo#58574
X-original-commit: 64402d92e8e96350a909bd77818e70c40bdd29ae
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before that, making a misc operation with cash basis taxes always set the move lines as tax_exigible=False (or at least, it was supposed to, see below). This was wrong, as if the move did not contain any payable/receivable account, it would result in no cash basis move being ever created, and so the entry would never affect the tax report.
Additionnally, the tax line was wrongly managed for cash basis taxes on misc entries, as vals.get('tax_ids') returned an ORM command, so a non-False value, even when the tax_ids field was empty. this caused the condition to execute and to reassign taxes to an empty list, which then caused tax_exigible not to be set to False, even when it should.
X-original-commit: https://github.com/odoo/odoo/commit/2437eb0691d07f92094152b84c96a2149c8f4fd8
[FIX] account: make tax exigible correct in cases where the move lines are created separetely from the move.
Additional fix on top of https://github.com/odoo/odoo/commit/02fe997932070cc101a96eb869023702c224318b
Also, add tax_exigible to the form view of account.move.line, as it will not be computed automatically anymore when modifying a single line in draft state through its form view. It now needs to be manually changed in case the user wants to change something having an impact on it through this form (note that this is absolutely not a typical use case).
closesodoo/odoo#58260
X-original-commit: 867797e4983b704599be7943490fc6f071d8c0b7
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
* Change the `addons/account/i18n/vi.po` PO file to replace the
translation of `Vendor Bill` like msgids from `Công nợ nhà cung cấp`
to ` by `Hóa đơn Nhà cung cấp`, there should be 3. What's matter is
the `đ` character.
* Create a brand new Vietnamese database (using `-l vi_VN` and
`--load-language=vi_VN`)
* Install Invoicing (`account`), an email alias constraint is raised.
> You cannot use anything else than unaccented latin characters in the
> alias address.
During the installation of the invoicing module, an email alias is
created for every journal account of purchase type. The alias is created
using the current journal name. Here the journal name is `Hóa đơn Nhà
cung cấp`, as mail aliases should only contain ascii characters, we
attempt to remove the accents. The `tools.misc.remove_accents`
successfully remove most of them but the `đ` character is left as-is,
the final alias is `hoa-đon-nha-cung-cap` which is invalid as it
contains some non-ascii characters.
The `remove_accents` function uses the [NFKD] Unicode Compatibility
Decomposition Normalization Form. This normalization process unify all
abstract equivalent characters, i.e. characters only different by font
or rotation. While this normalization process helps to transcript a lot
of characters to their ascii compatibility equivalent, some 118,230
other non-ascii characters (mainly from the Chinese and Japanese scripts)
are left as-is as they lack an ascii compatibility equivalent.
The solution has been to not use the journal name but rather the journal
code or journal type as email alias when the name is unsafe. The journal
code is a short version of the name, the journal type is not
translatable so is always ascii.
One additional watchdog has been added to the sanitization function of
email aliases so non-ascii characters are replaced with a '?' which is
an authorized character in emails local-part.
[NFKD] https://unicode.org/reports/tr15/Closes#55492Closes#55493closesodoo/odoo#58279
X-original-commit: 8dc85be3821cf26226cd0bf4ce2b6739e68fc66f
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Co-authored-by: Thong Le <thongthele@users.no-reply.github.com>
Laurent Smet