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>
Create and post an invoice ('Lock Posted Entries with Hash' on the
journal)
Edit also Bank journal enabling 'Lock Posted Entries with Hash'
Create and post a corresponding bank statement:
- same setting on the journal
- same partner on the line
Reconcile
Action will be blocked because the system try to
rewrite the partner on the posted line which is locked.
For Bank/Cash journals should not be visible the lock setting.
opw-2367688
closesodoo/odoo#61284
X-original-commit: d7f92cabb4bb12fe40356c9764c8e3e7c75e4f37
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.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>
WHAT: apply 93a7695f65baf00d1f82481d6a2a97e6c11940a8 for all res.config.settings
menus
WHY: the same reason as in 93a7695f65baf00d1f82481d6a2a97e6c11940a8:
When saving, a read is called. By default, read has
bin_size to true to avoid performances issues.
It will return the image size instead of the content
it may lead to image dissapearing or "Incorrect padding" error
HOW:
find . -iname "*.xml"|xargs grep "\"context\".*'module'" -l | xargs sed -i "s/\(\"context\".*'module'.*\)\}/\1, 'bin_size': False}/"
git checkout -- addons/base_setup/views/res_config_settings_views.xml
---
PR for General Settings: https://github.com/odoo/odoo/pull/47297
opw-2346644
closesodoo/odoo#61215
X-original-commit: 7c55efa88b72bd1f3f0f32f7f738e2fda5aa4abd
Related: odoo/enterprise#14547
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@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>
Issue
- Install "Accounting"
- Go to "Accounting Overview/Invoices"
- Switch to kanban view
Cause
The wrong field ("journal_id") was present instead of "partner_id"
Solution
Change with "partner_id"
opw-2367738
closesodoo/odoo#60970
X-original-commit: e4ac9891450d96149551d19ac2d2f74f410f877c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
- Some tax_base_amounts checks were missing
- The type of repartition used to generate tax lines was not tested; it made the test confusing (as in this case, sales taxes invert their tag, given here the impression the wrong repartition was used, and potentially shadowing a bug)
closesodoo/odoo#60966
X-original-commit: c703b3a2f5a2d4d8bfbf0bc14203dde1b1bdec23
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
- The field 'invoice_ids' no longer exists on account.payment.
- When registering a payment using a payment token, the payment is not posted directly but the payment transaction is processed instead.
It means the payment is not posted until the CRON call. Since 14.0, the journal items can't be reconciled if not posted and then, we can't wait the CRON to update the payment state.
- The payment token is no longer available when registering a payment for invoices.
closesodoo/odoo#60918
Task: 2352628
X-original-commit: 0ad8979cb345805b7b1bdc330621b42e1d625593
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.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>
- Install account / purchase / sale
- Ceate an internal user without any access rights
- Go to `/my`
A 500 error is raised because of an AccessError.
When the user has no access rights to any of the mentioned applications,
the `search` call returns an AccessError.
We prevent the access error and return 0 as a fallback.
opw-2367559
closesodoo/odoo#60849
X-original-commit: 54ef98c613219aba3bda41817f7767261b8092d2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.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>
Issue
- Install "Accounting" & "Studio" modules
- Go to "Accounting" and switch studio editor
- Go to "Reports" tab and select "Invoices" report
- Click on any block to edit.
Not possible to edit document.
Cause
Studio cannot parse dynamic `t-call` and therefore not able
to render the corrects hooks to edit the report.
The issue has been introduced by this commit: https://github.com/odoo/odoo/commit/5c5710ae8ea045569fd94504f9d8dd5209f7b662
Solution
In the corresponding localization report template,
add an 'Inheritance Specs' (position="after") that will add a condition
where it will retrieve the rigth report name
in case localization enabled.
opw-2362257
closesodoo/odoo#60660
X-original-commit: ee1580a85c9942e9a98748fa568f9f664c67a320
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.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>
The feature was actually not working as expected. It has been fixed,
and a test now ensures it does work as expected. This commit also fixes
some invalid parameters, hopefully nothing critical.
closesodoo/odoo#60429
X-original-commit: 231bdca3f26d96f578503694e5aec062de2317ed
Related: odoo/enterprise#14285
Signed-off-by: Raphael Collet (rco) <rco@openerp.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>
Before this commit, `journal_id` field was not required on model/view, Creating record without `journal_id` is not allowed since it is required on `account.move`.
Now field is required.
closesodoo/odoo#60146
X-original-commit: 7fbdfba8cbeb2ed724f2493320a5f609d07dca97
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.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
Laurent Smet