A new field on tax groups makes it now possible for this group to be displayed under a subtotal label. If not set, this defaults instead to "Untaxed Amount", keeping the traditional behavior. This is intended for withholding taxes, which can now be implemented with negative taxes and a tax group with this field set.
To do that, this commit entirely refactors the way amount_by_group worked, and replaces it with a more complete json field called tax_totals_json. It also streamlines the way taxe totals are displayed on invoices, PO and SO and makes it so that a common code is called instead of copy-pasting the same block 3 times as before.
[IMP] purchase: always display tax totals by groups on purchases orders
Before, tax totals on purchase.order's form were not shown by group, and were instead all aggregated in a single "Taxes" category. The same went for the pdf export. The portal view, though, did show the totals by group. We now display the tax groups in the same way all the time.
closesodoo/odoo#74138
Task: 2457374
Related: odoo/enterprise#19802
Related: odoo/upgrade#2670
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The tax_exigible field of account.move.line made it impossible to mix 'on_payment' and 'on_invoice' taxes on the same invoice line, as the base line couldn't be be tax exigible and non-tax exigible at the same time. However, this use case is needed by some countries in order to implement withholding taxes.
To solve that, we totally remove the tax_exigible field from account.move.line and instead compute it on the fly with a domain (also passed to the query_get for SQL queries). An 'always_tax_exigible' stored computed field is also added on account.move, in order to still allow (like before) putting cash basis taxes on a miscellaneous operation without any payable/receivable line and still see it become exigible without needing any payment.
[IMP] account: improve cash basis traceability
A smart button is now available on invoices generating cash basis entries, so see them all at once. The move originally creating cash basis entries is also shown as a field on them.
Task: 2457374
Part-of: odoo/odoo#74138
Refactor the tax group widget with the new JavaScript Odoo Framework:
OWL. This widget has 2 different components, one representing a tax group
and one representing the list of tax groups.
Task ID: #2312900
Initial Task ID: #1986412
Part-of: odoo/odoo#74138
The goal is to remove confusion between Invoicing and Accounting.
The current setting "Show Full Accounting Features" is confusing
and leads users to believe they have a full accounting package
in community, which is not true.
closesodoo/odoo#73977
Task: 2578997
Signed-off-by: William André (wan) <wan@odoo.com>
Purpose of the task is, to use our awesome website builder instead of
pad when creating a website page for terms & condition.
Also suggest default T&C to save user time when user enable the feature
So in this commit did the below changes:
* Added new indicational text below "Terms as note" & "Terms as web page"
* After enabling "Term as web page', user should be able to see the
term page url
* For Terms editing:
- User that have 'website' or 'ecommerce' module should edit the page
directly using the website builder with link "edit in website builder" link.
- User that don't have nor website not ecommerce module should update
the text in the pad but in a pop-up window.
* Also added the dynamic default term for company when term type is html.
PS: changed website_sale pre_init_hook to post_init_hook because
invoice_terms_html is compute field which depends on term_type so
when term_type is changed from init_hook it will give the key error
for the invoice_terms_html as it's not loaded to registry.
closesodoo/odoo#68225
Taskid: 2414659
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This task aims to both explain supported reconciliation cases and improve the reconciliation model form view.
The form improvement is mainly about label wording and make the options more self speaking.
Also, disable bypass of the matching amount we do in case the statement line's label exactly matches the payment reference.
It can be replaced by just making a final model that is applied whatever the amount and will do the partial reconciliation on everything that wasn't matched by others.
That's cleaner, as users can way more predict what models can do and debug their config.
closesodoo/odoo#73043
Task: 2427089
Related: odoo/upgrade#2729
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Steps to repodruce:
- Install 'Accounting' module
- Set user language to French
- Create journal entry
- Set a date before 2000. Example : 01/01/1999
- Insert some journal items
- Save the journal entry
Issue:
Error message is raised :
```The journal entry cannot be saved : "The Date (01/01/1999) doesn't match the Numéro (OPD/1999/01/0001).```
Cause:
Incomplete regex: parsing only years who begin with 20 or 21.
https://github.com/odoo/odoo/commit/26a43f23ec2b2490aec0731e25568703729581f0#diff-67b6f8b23970c1b18fc5e7f82b7585ad82e7bace885cdd78274837a4876a6a9fL24-R25
Solution:
Add 19 to regex to allow years like '19XX'.
opw-2616575
closesodoo/odoo#75755
X-original-commit: da9a2fab230c07cd0ce069bc7832ffcce4b8e988
Signed-off-by: William André (wan) <wan@odoo.com>
This commit makes some major changes in the Point of Sale module
when posting journal entries which allowed the following new features:
1. Show that the invoice generated is paid unlike before where invoice
doesn't appear to be paid (both in the pdf and in the backend).
2. User can create a 'Pay Later' payment method (created by default as
'Customer Account') to allow the customers to make credit in their
purchases.
3. An extension possibility where POS can settle customers dues.
The above is accomplished by doing the following:
1. Invoices are now reconciled to created account moves by POS using
the pos payments registered to the pos order. And this is done
right after the order is synced to the backend.
2. A new type of pos payment called 'pay_later' is introduced.
- When an order is invoiced and is paid with 'pay_later' payment,
the customer in the invoice will have `due` in his account which is
immediately reflected when the order is synced.
- When an order is not invoiced and is paid with 'pay_later' payment,
the customer's 'due' reflects when the session is closed.
3. When the session is closed, POS payments from cash payment methods
are moved to the default account of the cash journal specified in the
payment method via creation of `account.bank.statement.line`s. (This is
already the case but it is mentioned this is for the purpose of
transparency.)
4. As for the bank pos payments, `account.payment` records are created
to move the payments to the specified `outstanding_account_id` in the
pos payment method. The `account.payment` records are written the bank
journal specified in the payment method.
5. As for the `pay_later` payments, we keep the behavior when no
journal is specified in the payment method where payments become
receivables to the customer who made the payments.
Other notable changes:
- The default POSS journal is changed to have 'general' type in order
to able to view the journal entries written in it.
- `pos.payment.method` can now be categorized as 'cash', 'bank' or 'pay_later'.
- `account_default_pos_receivable_account_id` can now be configured from
the Point of Sale general settings.
- `pos_invoice_report` is removed in favor of `account.account_invoices`
- disallow creating new payment method from `pos.config` form
- 'Journal Items' button in the `pos.session` form are now always visible.
- This allows seeing the list of invoices (and their payment moves)
to be accessible thru this button.
See test cases from the following spreadsheet:
https://docs.google.com/spreadsheets/d/1mt2jRSDU7OONPBFjwyTcnhRjITQI8rGMLLQA5K3fAjo/edit?usp=sharing
Part-of: odoo/odoo#74870
With this commit, it will check if the tax name is given by external method and take that name if any.
For example,
vals = {'rate': 5.2, 'name': 'Odoo New Tax'}
tax_template = self.env['account.tax'].search(domain, limit=1)
new_tax = tax_template.copy(default=vals)
Current Behavior:
new_tax.name => 'Odoo New Tax (Copy)'
Instead of 'Odoo New tax'
closesodoo/odoo#75406
X-original-commit: 10a5ecceead2f450822387c6f1f2d98f98317a15
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
`result` might be a Markup object (eg during tests) or a bytes-like object.
Step to reproduce: click on "Send by Mail" on a SO -> Traceback
Step to reproduce (2):
- Install website_sale
- Add something to the cart
- Go through checkout and click on Pay Now
- Crash, 500 error page, as this step is trying to generate the SO PDF to send
by mail to the customer, which tries to encode a bytes-like object.
```
AttributeError: 'bytes' object has no attribute 'encode'
```
But if you do that flow during a test, eg
```
./odoo-bin -d mydb --test-tags=.test_02_admin_checkout
```
You have a Markup object, thus you had to encode it.
Now, even during test, we return a bytes-like object.
Related to #68299
Community: https://github.com/odoo/odoo/pull/75377
Enterprise: https://github.com/odoo/enterprise/pull/20449
Part-of: odoo/odoo#75377
When creating from python or toying around with the onchange in the UI, it is possible that the user tries adding values in tax_tags_ids or tax_line_id that are not consistent with the tax_country of the move. The constraint didn't check that, and it should, as those cases are not legit at all and lead to incorrect amounts in the tax report.
closesodoo/odoo#75407
X-original-commit: a63bd4a033dbb8874c07ce0b30984d04a24e7215
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Step to follow
- Trigger the Print > Invoices action
- An error is displayed but the PDF is still attached
Cause of the issue
> The PDF is generated before the error
Solution
> Show an error earlier
opw-2625480
closesodoo/odoo#75379
X-original-commit: b324ba12b4af2d00c696bc5c42896c7c431d863c
Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>
Issue: With a custom tax computation that depends on the quantity, when
the price of the item is 0, when changing the quantity,
the taxes are not changed
Steps to reproduce :
1) Install Accounting, and account_tax_python
2) Accounting > Configuration > Accounting > Taxes : create
a task :
Tax Computation: Python Code
Python code : `result = quantity * 0.3`
3) Accounting > Customer Invoices > New Invoice
4) Add a line with a product, unit price = 0, quantity = 2
5) Change the quantity, the tax does not change
Why is that a bug:
When the price is 0, changing the quantity doesn't affect
the price so the onchange is not triggered even though the
line changed
opw-2559200
closesodoo/odoo#75348
X-original-commit: 44403a6c266313a167b88b2c72c0eb9c70a2b4a4
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>
[FIX] account: tax details: correct taxes computation when using taxes affecting base with repetition
1) Let's consider then following taxes
- tax 1, 42%, affecting the base
- tax 2, 10%
2) Create an invoice with the following lines, and post it:
- price=100, taxes=tax1
- price=100, taxes=tax2
- price=100, taxes=tax1+tax2
=> The tax details should compute the following amounts:
- base amount of tax 1: 200
- tax amount for tax 1: 84
- base amount of tax 2: 242
- tax amount for tax 2: 24.2
Before this fix, the base amount for tax 1 wasn't computed properly, and gave 300 instead of 200. This was because the same tax line (the one from tax1 with no tax_ids) was matching two different base lines: the one with tax1 and tax2, and the one with only tax1.
closesodoo/odoo#75317
Related: odoo/enterprise#20356
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
If the analytic account have not company then the analytic entrie
would have the company of the account move
closesodoo/odoo#75275
X-original-commit: 3d3e6ddd3383f2e35c254744c9ee5b90c224251b
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
This reverts the following commits:
- 164409b00106a5f91d8b84ac698f4cf2aebedb91
- f11c807217cccd96fa18fe24c0cbb436bb1830d1
- c92ebc91e261827dfafa602eae5408de2a072609
The fix we initially made did not cover every possible scenario,
and applied to every fiscal position, which was not required.
It requires a more in depth rework that is under way
and will come in a future PR.
closesodoo/odoo#75284
X-original-commit: d470f2b4fbc7440d19d07268980394909c47ee22
Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>
In a multi-company environment, with l10n_es_reports installed,
a tab was added to the invoice form view.
That tab was also visible in other localizations as well,
which was not desired.
closesodoo/odoo#74701
Task: 2611256
Related: odoo/enterprise#20042
Signed-off-by: William André (wan) <wan@odoo.com>
Automatically activate `group_multi_currency` if there is more than one active currency,
deactivate it if there is only one active currency
retain sale/pos feature of activating group_product_pricelist
adapt tests accordingly
Task 2610735
closesodoo/odoo#74396
Related: odoo/enterprise#20106
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, It was setting first available account as default regardless
of it is deprecated or not.
With this commit, we are excluding deprecated account as default.
Fixes#74280closesodoo/odoo#74901
X-original-commit: fa07151785d9a3b3cbaddba34bea072eceda0e81
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
If we have a reconciliation model having a rule using a regex, we are extracting
the balance from the label, but we should not raise an error in case the regex
is matching an incorrect float value, and just set a zero balance instead.
closesodoo/odoo#74853
X-original-commit: a8d65794cfe6c7c64e03b13b8cbaa52a67b25b70
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Problem: The journal dashboard show wrong values for the late invoices.
Background details: The filter for the "Late" invoices is not in sync with the sql query in the dashboard python code. The filter searchs for the invoice_date_due field while the sql searchs for the date field.
closesodoo/odoo#73992
X-original-commit: f1e9e756b8806aca92fda4d528fd0b23842e967a
Signed-off-by: William André (wan) <wan@odoo.com>
At the moment, it is possible to archive a journal for which some
entries are still waiting to be auto-posted in the future.
Add a constrains to avoid make sure that it is no longer possible,
since it shouldn't.
Task id #2585454closesodoo/odoo#74690
X-original-commit: 850eb5100d6405d3a7293e06910a1c5355fdb8d8
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Nicolas Viseur <vin-odoo@users.noreply.github.com>
Remove an unnecessary default search when opening the journal entries
of a bank statement.
closesodoo/odoo#74802
X-original-commit: e9f6bbb9093a4c2bf6e728d2882f6dab65658c01
Signed-off-by: William André (wan) <wan@odoo.com>
Set the payment method line to cascade when deleting a journal.
This way, we do not keep unneeded lines, and it is not an issue
since we cannot delete journals linked to a payment/move anyway.
Also add a check on the journal id in the constrains checking their
name to avoid taking into account lines without journals.
closesodoo/odoo#74767
X-original-commit: e5cff1af3b8d407c7f0f0d2c9f9c021dcea41512
Signed-off-by: William André (wan) <wan@odoo.com>
In some reports, we need to detail the taxes for each journal items.
This is the case of all EDIs, the SAFT-report, l10n_in etc.
This task adds an SQL view mapping each tax lines with their corresponding base lines and computing the tax_amount and base_amount.
closesodoo/odoo#70866
Task: 2352524
Related: odoo/enterprise#18344
Related: odoo/upgrade#2686
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Using the new carryover feature, improve the french tax report to properly carryover the values from the tax grid 27 to the tax grid 22 of the next period.
Also slightly improve the carryover itself
to support total lines, and disallow to
carry over to lines from another report.
Task id #2452451closesodoo/odoo#69887
Related: odoo/upgrade#2708
Related: odoo/enterprise#17953
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The field is supossed to point to account.bank.statement but is pointing to account.move
Now is working because the field is only used in button_open_statements method where the model is defined,
but if you want to use this field to report it will get information from account.move with that ID or an error if the move do not exist
closesodoo/odoo#74673
X-original-commit: 21b076d5dcd99f369bc745906cf94ce337539bcd
Signed-off-by: William André (wan) <wan@odoo.com>
In order to limit encoding decoding, the _render method returns a
unicode string in the markup safe object instead of a MarkupSafeBytes
closesodoo/odoo#68299
Related: odoo/upgrade#2454
Related: odoo/enterprise#17270
Signed-off-by: Antony Lesuisse (al) <al@openerp.com>
The error message when resetting a payment to draft and changing the date is not adequate. This aims to guide the user to the appropiate journal entry where changes are required.
part 2 of task [2533660]
closesodoo/odoo#73470
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Payments that are modified have no real traceability. It would be useful to see a list of modified fields in the chatter, therefore tracking was added to a number of fields.
Date changes on journal entries (account.move) are also tracked in the chatter
part 1 of task 2533660
The goal is to take into consideration that in case the TAX ID
is issued by the same member state as the vendor's,
then VAT charge is not reversed.
The VAT ID must be foreign as from the vendor's point of view.
closesodoo/odoo#74566
Task: 2596204
X-original-commit: c92ebc91e261827dfafa602eae5408de2a072609
Signed-off-by: William André (wan) <wan@odoo.com>
Remove the custom messages and replace with the default odoo tracking message that uses tracking_value_ids as parameters
Journal Items will log all changes of tracked fields in the chatter of the associated Entry - including one2many and many2many fields (by overriding _mail_track)
references original task 2061399
closes task 2469621
closesodoo/odoo#72023
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the bug:
- Install Accounting and Expense app
- Go to accounting settings > enable cash basis option
- Go to accounting > configuration > accounting > taxes
- Create a new tax or choose an existing one e.g “Tax abc”:
Tax Computation = `”Percentage of Price”`
Tax Type = `”Purchases”`
Choose any value for amount
Select "Based on Payment" in tax due
choose an account with the "Allow Reconciliation" option activated in the Cash Basis Transition Account field
Save
- Go to expenses > Expense Reports > All reports > Create a new one :
- Add 2 expense and for both set up the taxes to "Tax abc" and unit price > 0
- Submit to manager
- Approve
- Post journal entries
- Register a payment
Problem:
A user error with the following message is triggered: “You are trying to reconcile some entries that are already reconciled”
In the use case we have two expenses and for each, an `" account.partial.reconcile "` will be created,
so we will loop twice and therefore add twice all the `”account.move.line”` linked to the taxes
in the dict `" to_reconcile_after "`: https://github.com/odoo/odoo/blob/beccf82e09d536255d9d9cb9bfe58ebae2559843/addons/account/models/account_partial_reconcile.py#L585
Then we loop to reconcile all the `" account.move.line "` which are in the dict `" to_reconcile_after "`,
but since we added them all twice, at each turn of the loop we give them all as a parameter
of the “reconcile” function without checking whether they are already reconciled or not.
opw-2565934
closesodoo/odoo#74432
X-original-commit: fb2b1482f5d3dec924b08e08dc915d6608c7d6b3
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
A tax line affecting the base of subsequent taxes is a line having some values in 'tax_ids' & 'tag_ids'.
When creating a refund, tags was wrongly computed in this case.
closesodoo/odoo#74307
Issue: 2596368
X-original-commit: 49d1dbbb74ea97e4337fe1af3b8074dc9146143c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Explain the situation when a manual change has been done to the sequence
of `account.move`. This was needed because some user didn't realize that
they changed the sequence, and when they realized it, it had polluted
multiple numbers after that.
closesodoo/odoo#74326
X-original-commit: 56f7afb253da6560cddae121f5b6cdab3e3b1c6e
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
When sending the same invoice from Invoices > list view > select an invoice > action > Send and print, the email received by the client does not contain the header and the link to the invoice
This PR adds the custom_layout attribute to the context of "Send & Print" action
opw-2544654
closesodoo/odoo#74311
X-original-commit: 8bb27b88326d6298a03a5fa3978ac99b0e1ee7e0
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
action_invoice_sent() triggers two onchanges which normally don't happen at the same time. Added a check to one of them (onchange_is_email()), so that on action_invoice_sent(), only one of them calls the computationally expensive onchange_template_id_wrapper(), effectively halving the time taken.
Time for executing the action for one invoice dropped from over 3 seconds to a bit over 1.
closesodoo/odoo#74160
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit:
When there is too much records to post and it's take time more than 15 minutes then server was restarted.
So scheduler action will do the process with the same records again and again.
After this commit:
post record in batch of 1000
opw-2451446
closesodoo/odoo#70831
X-original-commit: 819321c3a129613890ce49e3efe9a903c3218070
Signed-off-by: rrt-odoo <rrt-odoo@users.noreply.github.com>
Currently, the payment method lines are only ordered
base on their sequences. This could lead an issue if
the sequences are all the same, where they would be
returned in a random order.
Add a second ordering on the id to avoid such random
issues.
closesodoo/odoo#73984
X-original-commit: ac700908a80f67e5fd15fa242cc111d57abd4aa9
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Nicolas Viseur <vin-odoo@users.noreply.github.com>
There is an issue when computing the suitable payment token ids making it impossible to
open a payment for a user without access to payment acquirers.
Also, the default computation of payment token was wrong and would never set it
correctly.
The compute for the method lines in payment would not filter unavailable acquirers
line and thus select them by default if they were first in line.
Also fix an issue with the ordering of payment method lines
X-original-commit: 73410a0fd76a70e1730883d35b79fc603741b59c
oco-odoo