Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
Task 2292368
Bundle
https://runbot.odoo.com/runbot/bundle/master-reconcile-model-boost-wan-60105
* Search in Notes and References, not only in the statement's
communication.
* Activate the partner mapping for Suggest Counterpart models
* Always show the Amount Matching field
* Do not block the deletion of models with a partner mapping
* Allow to archive models
* Add a button to get back to Processing state from Validated state on
bank statements.
closesodoo/odoo#55031
Related: odoo/upgrade#1619
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Because we used the same variable to compute the partner, it was
overriden once we went through a model with a partner mapping, and kept
for models with lesser priority.
Also remove the key param to sort the recocniliation models. We want the
models to be sorted according like in the list view, and that is exactly
what the .sorted() function does without params. (no need to worry about
changing it if we change the _order)
Lets assume we have these records
```json
{
'id': 1,
'journal_id': 1,
'date': '2020-01-01',
},
{
'id': 2,
'journal_id': 1,
'date': '2020-01-01',
}
```
with the domain
```
[('date', '<=', st.date),
('journal_id', '=', st.journal_id.id),
('id', '!=', st.id)]
```
in the compute method of `previous_statement_id`, the previous
statement of 1 will be 2 and vice versa.
A solution is to change the declaration of the field from Date to
Datetime
This config parameter was used in order to choose another country than the company's to select the tax report. It is now replaced by a new account_tax_fiscal_country_id field in account_reports.
closesodoo/odoo#55308
Related: odoo/enterprise#12156
Related: odoo/upgrade#1624
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Go to Point of Sale
- Switch to View list
- Select a POS and click on Action\Export
- On Export wizard:
* check "I want to update data (import-compatible export)" option
* expand "Default Balance" section
A KeyError is triggered while trying to access undefined field referred by "_rec_name"
of "account.bank.statement.cashbox".
opw-2309064
closesodoo/odoo#55480
X-original-commit: 7e3143b93ffd7162c90e0c50758a4f44b0645cd6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
There are inconsistencies in the m2o accounts create & edit behavior.
New off-balance account type was not correctly filtered
This change correct those two issues
Task ID: #2288757closesodoo/odoo#54626
Related: odoo/enterprise#11920
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
- Create Tax 0:
Percentage
Amount: 0
Tax Included
Tax Group 0
- Create Tax 8:
Percentage
Amount: 8
Tax Included
Tax Group 8
- Create a customer invoice with one line
Quantity: 8.0
Price Unit: 15.55
Taxes: Tax 8, Tax 0 (order is important)
The tax amounts are:
Tax 8: 9.22
Tax 0: -0.01
If the taxes are inverted, the tax amounts
Tax 8: 9.21
Tax 0: 0.00
The difference is due to the rounding of the 8% tax done differently. In
the second case, the computation of the 8% tax goes through:
https://github.com/odoo/odoo/blob/8c5cd335a57c20ed5faa6b7c7630c296c1f2a5cf/addons/account/models/account.py#L1480
In the first case, the amount is recomputed in:
https://github.com/odoo/odoo/blob/8c5cd335a57c20ed5faa6b7c7630c296c1f2a5cf/addons/account/models/account.py#L1483
The rounding is different in both cases, leading to an inconsistency.
When the tax amount is zero, there is no need to save the amount in
`total_included_checkpoints`.
opw-2306676
closesodoo/odoo#55812
X-original-commit: e2776e188070221ef465a864bd2cb8dcfc971e14
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
When an user wants to lock his fiscal year lock date.
The system checks whether all the bank statement lines are reconciled.
However, the date must also be added to the search domain to receive
only the bank statement lines that are included in the lock date.
Task ID: 2297407
closesodoo/odoo#55672
X-original-commit: d232ecacda28614f36dd655a3f000290c6d3a91c
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Order move for hash: In the method write, we sort the recordset following this rule: by date, by ref and by id.
This rule is used because we need to be consistent with the method _compute_name.
If we don't filter moves like that, we could possibly have a problem.
If you have several moves and you post them at the same moment with the action "Post entries", the hash sequence
could be in another order than the name sequence.
For example:
Move_20 (29/07/2020) - Hash_2
Move_21 (02/07/2020) - Hash_1
About security check, if the hash is activated, the user cannot reorder by date with resequence
because we don't want that the name sequence have not the same order than hash sequence.
Task ID: 2297407
closesodoo/odoo#55669
X-original-commit: b3ae96dc52178a3b13dda845244fe34268aed8a0
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Change ValidationError to RedirectWarning, RedirectWarning is usefull to redirect user to
the problem. For the lock date, we can redirect user to unposted entries or unreconciled bank statement lines.
Task ID: 2297407
With company country and localization set to Peru
Go to invoice dashboard
Click on 'Send sample'
User will receive the warning
'If you want to use "Off-Balance Sheet" accounts, all the accounts of the
journal entry must be of this type'
and the action will abort because the first account fetched for the
operation is an 'Off Balance' account
opw-2300813
closesodoo/odoo#55509
X-original-commit: 27a9eb3083e7938199ff047060135e030496eec0
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
- Create an invoice using a tax exigible on_payment.
- Refund the invoice with 'Full refund'.
=> Traceback: The lines are already reconciled.
Explanation:
Odoo tried to reconcile all lines having a reconcile account, including the one set on taxes.
- The first reconciliation is made on the receivable account triggering the cash basis entries that will be reconcile with the tax account.
- The second reconciliation fails because the account has been reconciled to the cash basis entries.
closesodoo/odoo#55594
X-original-commit: 01f2a4c3d95b4ea762ef34ae56ee717a9614cb1a
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The problem of using fields.Date.today() instead of
fields.Date.context_today() arose with the recent changes in the
account.move._post() method used in the POS tests, around 1 am.
This commit changes all occurences of today to context_today.
closesodoo/odoo#55511
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Task 2227389
The wizards for creating Accrual Entries and Transfer Entries are quite
similar. We are merging them as they share code and business logic.
Entries in the future should not be posted for both wizards, but set to
be auto posted instead.
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
It was removed here https://github.com/odoo/odoo/pull/32303 but readded
later. We still don't want it for the same reasons.
Having it on related (non stored) is enough.
The cash difference line created on a statement using a cash journal should use the loss/profit account.
Then, the line is supposed to be marked as reconciled and then, doesn't appear in the bank reconciliation report.
closesodoo/odoo#55336
X-original-commit: 60e32447cc3fda3650aa718cb0996d29976005d4
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This allows the method to be called in RPC
The nil extension has not been enabled as explained at odoo/odoo#12289closesodoo/odoo#55374
Cla: signature for parveenjangra290
X-original-commit: abac62f35c8cd293143e01c137c79519897eb21c
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Wrong usage of self in for loop
closesodoo/odoo#55334
X-original-commit: 5a0b06ab0447f2b09e71934f2cc3209e6ebe9359
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The first Journal Entry of a tuple (period, journal) has a name set by
default so that the user can change it before posting.
If we changed the date after the name has been given, it never changed
anymore; meaning the number could not be of the same period as the date
of the Journal Entry.
We now always reset the name to the default one if the name has to be
recomputed (change of date/journal)
closesodoo/odoo#55321
X-original-commit: 0c5d71aab8eefb57116a5b93b4c67222a080ddec
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
- Create a vendor bill with amount X
- Register payment of X - 5 and mark as fully paid
=> The vendor bill is not fully paid.
closesodoo/odoo#55271
X-original-commit: 5c729d4cb7dacc46409259850ed7a5620fd6eb64
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Create a vendor bill, post it
- Go to Accounting > Accounting > Journals > Purchases
- Select the items linked to the vendor bill, delete
Nothing prevents from deleting the items while a posted entry cannot be
modified.
opw-2305873
closesodoo/odoo#55187
X-original-commit: 14ef02f73e649b5f8c50f09213f0a0dbddf46217
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
During the migration, it could happen some statement lines are created with a zero amount in company currency or foreign currency.
It this specific case, we can't retrieve the correct amounts by multiplying the statement line conversion rate because X * 0 is always zero.
This commit ensures the amounts are well preserved in such case.
X-original-commit: a75bc7fdf014daf965cad72917ac475cbf83f6ac
This should never happen for someone starting Odoo after saas-13.4 but is happening during migrations.
X-original-commit: b43849032766b95f07d3ac73fc67e4c03138c3b5
When default_get is called, the wanted fields are specified through the
fields_list arg. It is useless to fill the values for unwanted fields.
As default_get is called for nearly all records creation, simplifying
the default_get overrides:
* remove potential wrong side-effects of the values
* remove some useless or wrong defaults computations (searches, refs,
...)
Avoid concatenation of translated strings & raw values and/or other
translated values, and use the new _ API (by providing the formatting
values to ensure the fallback on the english terms in case of wrong
translation).
By including the expected values inside the string to translate, we
ensure that the formatted values are included at the right place in the
resulting translated text.
This also provides more information on the string to translate to
the translators, s.t. the chosen terms for the translations can be more
adapted to the translation context.
closesodoo/odoo#54635
Related: odoo/enterprise#11925
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before, if we had PREFIX/9 and PREFIX/10, the highest number was the
lexicographic order, leading to proposing PREFIX/10 again and again.
Because of performances, we can't execute the regex in the SELECT query
and we need to store it in the database. This will allow to do an
indexed search.
closesodoo/odoo#54811
X-original-commit: 8806f33ef68771834496b764aa4c37b7ccf5841a
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Create a product category with no accounts defined
Create a product [DEMO] in such category with no account defined
Create an invoice with the default journal which will have the default
account
Create an invoice line with [DEMO]
Upon selecting the product the default account taken from the journal
get cleared and there will be no replacement.
Since the account field is mandatory the account should be preserved
opw-2299228
closesodoo/odoo#54751
X-original-commit: f4c41997cfd560ded6d387324e5dbcf1b7183a36
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Bank reconciliation widget allows creating a writeoff with tax lines, in order to simulate both the invoice and the payment into a single entry, from one statement line. Before this fix, the tax repartition used by this feature was always the one defined for invoices. Also, in some cases, the amounts reported in the tax report had the wrong sign, because of the way the tax report applies the sign multiplicator on lines' balances. This multiplicator cannot be computed properly from a payment or miscellaneous operation, so we need to rather impact the sign of the tags directly.
With this fix, we guess whether or not we are refunding something from the data entered by the user, and modify the signs of the tags accordingly so that the tax has the same impact on the report as it would have had with an invoice doing the same operation.
closesodoo/odoo#54691
X-original-commit: ac2662b67c878eb2ef6e9462a0e6c9f1fbdb6adb
Related: odoo/enterprise#11948
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
odoo/odoo#34023 added this override to `postprocess_pdf_report`, which
was apparently missed when odoo/odoo#33770 made a few
methods (including this one) RPC-private.
Fix the override so it's properly called again (probably).
Task 2285894
closesodoo/odoo#54448
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Issue
- Install "Accounting" and "Account Analytic Defaults".
- Create an Analytic Tag and use the distribution (eg.: 60/40)
- Create an Analytic Defaults for a specific partner.
with the Analytc tag just created.
- Create a bill, select the the same partner as the Analytic Defaults and
add a new Invoice Line with a price (eg.: 1000).
The tag is applied to the payable account, which is
wrong and it leads to an analytic inconsistency.
Solution
Apply analytic tags only on move lines not excluded from invoice tab.
opw-2269757
closesodoo/odoo#54410
X-original-commit: 6e0bb7a24cad46891c80ddc384311dd81eca1e82
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
opw-2294930
The tax amount not included in price should be computed in the remaining
balance, even if not included in price.
closesodoo/odoo#54356
X-original-commit: 6a6aefdfac472421b9cf6de043682a6cdc131d85
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before that, since https://github.com/odoo/odoo/commit/71ee252dc43fd0e2b86ba8079c31915544e528eb , negative invoice lines were not supported by thoses taxes. Nor were miscellaneous entries. To make them work, we change the way tags are assigned to cash basis taxes : instead of copying them from the invoice, sign included, we now change their sign when appropriate, so that the resulting cash basis move can be treated like any regular miscellaneous operation by the tax report (so, always applying a factor of 1 to its lines' balance).
Doing that also allows us to re-simplify the code used in the tax report and tax audit computation to manage cash basis entries, and makes the cash basis entry more standard. This is also a usability improvement: now the user does not have to search for the original invoice to understand how the CABA entries are going to impact the report: it's always managed like a misc. operation, so he can just trust the signs of the tags.
v13 version of https://github.com/odoo/odoo/pull/53085closesodoo/odoo#54058
X-original-commit: 20850301f5025ffd1a05e0594f6d26d2a61759ef
Related: odoo/enterprise#11652
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Issue
- Install 'Accounting' app
- Create tax A and tax B for 5%, make sure they are NOT included in price
- Create a tax C as a group that includes Tax A and B
- Go to any bank journal and create a statement line for 100 dlls
- Click Reconcile
- Select Manual Operations
- Select any account
- Add Tax C
- Check on 'Tax Included in Price'
Wrong calculation.
Cause
Not considering forced 'Tax Included in Price'
('force_price_include'),when cumulating tax included
amount.
opw-2280714
closesodoo/odoo#54003
X-original-commit: 523e407e164d96ead0ce836e3dc1a6bb8f258af9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Fields that are shared between account.payment & account.move models are badly set when creating the records.
For example, 'partner_bank_id' in vals will be set on account.payment but not on the account.move.
closesodoo/odoo#53832
X-original-commit: a23c1e30c5b6b28f25c5f76d9fb85f075433b18f
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this, it was impossible to reconcile an invoice with a credit note, as the tax_audit field's computation found two invoice lines while it expected only one, and crashed.
Note that our current tax report does still not handle all the cases properly:
- Invoices with negative lines using cash basis taxes won't work well, as we can't differentiate a credit note from an invoice using only debit and credit.
- Misc entries reconciled together with cash basis taxes on them ("faking" the invoice and payment) won't work well either, as both of them have the 'entry' type.
>> This commit is a temporary fix, essentially made to unlock customers blocked byt this issue. Another, more complete, fix is coming soon.
closesodoo/odoo#53238
X-original-commit: 8ed0ae8ba593c3b636c0b1e8d5bb41549a45a432
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Support two new syntaxes with `_()` method:
_("This is so %s") % 2019
_("Text with %s placeholders", 42)
_("Text with %(num)s placeholders %(symbol)s", num=42, symbol="🧀")
The main benefit is to have a fallback on the source string if formating the
translated string fails (e.g. "Foo %s" translated "Foo s%").
This PR converted most (but not all) calls to _ using placeholders to use the
new syntax. Hopefully, the remaining ones will be converted in the future and
avoid technical debt.
Use named placeholders when needed. If more than one placeholder is present in a
string, using named placeholder can be beneficial to reorder the placehodler
position (for languages like Japanese that do not use the same phrase
construction). On some sentences, it also brings clarity on the meaning of the
placeholders.
closesodoo/odoo#52155
Task-id: 1853119
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Martin Trigaux