Before this commit there are no rollback if raise.
closesodoo/odoo#131490
X-original-commit: 0015662d166f5e07bcbd6c5e9e14f8837ffa58a3
Signed-off-by: John Laterre (jol) <jol@odoo.com>
The _compute_amount_residual method computes residual amounts on reconcilable
account move lines. As it uses an sql query for an efficient computation it
discerns stored records from new records (having a new id) by filtering out
records with a falsy id field (new ids are always falsy). It then proceeds the
computation for stored records only.
The bug arises when the compute method is called on records during an onchange
call, as the records get reassigned a new id as well. This can be seen when
opening the total due followup view and toggling the blocked field on any of
the unreconciled entries. The problem is resolved by including records during
an onchange in the computation: in practice the computation can simply be
carried out on all _origin records.
opw-3388389
closesodoo/odoo#131465
X-original-commit: 3d52fca2979cc4bfe87540122ea7cc979040be4f
Related: odoo/enterprise#45591
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Tom De Caluwé (tdc) <tdc@odoo.com>
Versions:
---------
- 14.0+
Steps to reproduce:
-------------------
1. Settings -> Configure document layout
2. Select the Boxed layout
3. Go to Invoices -> create a new invoice and register payment
4. Click on Preview
5. The field “Amount due” is in the wrong color and barely visible
Issue:
------
The field “Amount due” is in the wrong color and barely visible in
invoice boxed layout
Cause:
------
The issue is happening because we have `<strong>` before the text
”Amount due” and it changes the font color to gray because of the CSS definitions
Solution:
---------
We need to make the text bold in a different way, to do it we can use the bootstrap
class font-weight-bold, this way we keep it bold and do not break the colors
OPW-3374092
closesodoo/odoo#131459
X-original-commit: 6e1b3f2fc36831a94c164ab281c7a6fde535cebf
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Matheus Leal Viana (malv) <malv@odoo.com>
Improve Send & Print general usability by making it more streamlined overall.
Options are not activated but preemptive problematic partners are shown,
and skipped during the sending process.
closesodoo/odoo#131448
Task-id: 3336623
X-original-commit: 4105994e778459c869d885d017118492ffcd2064
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Yosua Nicolaus (yoni) <yoni@odoo.com>
Description of the issue/feature this PR addresses:
When an accountant adds an invoice at another date than the date of the
said invoice, it is that date that is shown on the journal entries and
items views. This makes it impossible to order the lines by invoice date
as the only date field available on those views does not give the proper
piece of information.
Current behavior before the PR:
Prior to this commit, the Journal Entries and Journal Items views show no
column giving the date of the document for every line but only for those
that have been added the same day.
Desired behavior after the PR is merged:
Adding this, the Journal Entries and Journal Items views show a "Document
Date" column which represent the date of the document. The bank
reconciliation widget presents this column too. In each of these three
locations, filters, groups and ordering have been setup to be able to be
applied on this new column.
This allows to search and filter lines using that piece of information.
The column is hidden by default.
task-3388309
closesodoo/odoo#129040
Related: odoo/enterprise#44545
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
The "test_active": False context of the field specifies that this field
will ignore whether a record is active or not when fetching it.
Due to recent changes in the javascript, the "test_active": False
context of the tax_ids field on the account move model is propagated
through into the name_search query. This means that inactive taxes
appear in the dropdown when selecting a tax.
This is an issue as there are a few localisations that hide a number of
their taxes by default (by making them "inactive").
The solution is to add the key, value pair "active_test":False to the
context of the field on the view, effectively overriding the context
that gets used in the name_search query, thus only retrieving active
taxes.
closesodoo/odoo#131212
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Current usage of aliases in 'account.journal' model is a bit low-level and
is done by hand. This is notably due to some specific requirements for
accounting: batch install of journals with aliases with names holding
non-ascii characters, easy support of multi-company when creating aliases
with similar names, specific heuristic to generate alias name to be
understandable if sanitize / encoding leads to stripping lot of name parts.
Inherit from the 'mail.alias.mixin.optional' that automates management of
alias without requiring the "alias_id" field. It handles aliases like other
Odoo models, notably for security, readable / writable field, alias reset
or values synchronization. It allows to remove unwanted sudo().{write/unlink}
and have code more aligned with current standards.
Using this mixin allows to skip the inactive alias creation and instead keep
a void m2o. When having a lot of journals to create for some COA this helps
saving DB space and reduce number of inactive and useless aliases.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Currently there is a constraint on alias name as we allow only a subset of
valid latin characters in it aka `[a-zA-Z0-9!#$%&'*+\-/=?^_`{|}~]`. There
is also an automatic sanitize of alias name at create / write that replaces
any non-word characters by an hyphen. This sanitize is stricter than the
constraint and it is not really coherent.
In this commit we make the sanitize inlined with the constraint, allowing
more characters to go through the 'mail.alias.mixin' cleaning pass notably.
Linking some bug fixes about that subject (notably due to 'account.journal'
model that uses aliases without going through the 'mail.alias.mixin', hence
allowing to see differences between sanitize and constraint):
* odoo/odoo@33bd1a951a : non ascii aliases when installing COA and generating
journals automatic email aliases;
* odoo/odoo@e08ee893d1 : left-part should not begin or end with dots as well
as containing dots sequence;
* odoo/odoo@f1215389e8 : prevent international char in aliases;
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Improve tests related to alias management in 'account.journal' model. In
order to support multi-company based alias domains we are going to cleanup
custom management of aliases in journals, moving towards a standard usage
of 'mail.alias.mixin'. This commit prepares this change by adding more
complete tests about current behavior of aliases.
This notably improve tests from odoo/odoo@339cdffb68 where the purpose is to avoid
issues when installing a COA, aka creating journals in batch.
This also adds tests for odoo/odoo@400b686027 where we ensure alias defaults are
synchronized with journal configuration.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
When a customer requests an invoice in the `point_of_sale`, use the same
flow as in `account`: the "Send & Print" button.
It generates the pdf, the EDI attachments (Factur-X, Peppol Bis 3, etc)
and send it to the customers/governement. Indeed, in some countries, it
is required to sign the invoice to the government upon validation (e.g.
CFDI in Mexico).
closesodoo/odoo#131317
X-original-commit: 2cc9a35860b59063f536eea9234a1e9c5fa2f00e
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps to reproduce:
- Go to Contacts and open any contact (e.g. Contact X)
- Check its configured Account Receivable (e.g. 121000 Account Receivable)
- Configure that account and set a default Sales tax on it (e.g. Tax 15%)
- Create an invoice with Contact X as customer
- Add an invoice line for any amount (e.g. $100) and any tax
- Swith to "Journal Items" tab and display "Taxes" column
A line (with 121000 Account Receivable) has been created automatically to balance the invoice line.
This line has a tax (i.e. Tax 15%): the default one configured on the account.
There should not be a tax for a receivable account.
Another issue is that the tax is set on the aml but not tax line has been created.
- Go back to "Invoice Lines" tab
- Remove the tax on the invoice line
- Save
In "Journal Items" tab, the tax line has been created from the aml with the receivable account.
- Go back to "Invoice Lines" tab
- Add a tax on the invoice line again
- Save
- Remove the tax on the invoice line
- Save
In "Journal Items" tab, there are now 2 tax lines from the aml with the receivable account.
By repeating the previous steps, new tax lines can be created infinitely.
Solution:
To prevent the issue, the default taxes shouldn't be populated on the aml when the account
is a receivable (or payable) one and when the move type is an "invoice" type one.
As "display_type" field of "account.move.line" is set to "payment_term" when the account is
a receivable or a payable one and when "is_invoice" is True on the move, no tax will be set
in "_compute_tax_ids" computed method when "display_type" is "payment_term".
opw-3345953
closesodoo/odoo#131330
X-original-commit: c6076a272cfe997856f3026557900ce9718c45e5
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
In this commit, _t import from import { _t } from
"@web/legacy/js/services/core" and from
web/static/src/legacy/js/core/translation.js are replaced by
@web/core/l10n/translation.js.
task-3292454
closesodoo/odoo#130865
Related: odoo/enterprise#45270
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
before this PR, some legal information were missing from our invoice layout,
for the l10n_cz and l10n_sk localization.
For l10n_cz:
- On move we add a taxable supply date
- On the company we add a trade registry field
- On report template we add the company_registry, the vat number
For l10n_sk:
- On move we add a taxable supply date
- On the company we add a trade registry field and income tax id
- On report template we add the company_registry, the vat number and income tax
id
closesodoo/odoo#126837
Task: 3374969
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
The sum of floating points in not correct when we add a number of lines in payment term. The sum comes up to be 99.999999993 or close to this depending upon the number of lines.
1. Create payment term with 15 lines having percent payment value of 0.166.
2. Keep the last line as calculated by the app.
3. Try to save the payment term.
Current Behavior:
A validation issue would arise stating the sum should be equal to 100.
Expected Behavior:
The payment term should be saved.
OPW-3450723
closesodoo/odoo#131126
X-original-commit: faebcd0fade95dcdbe1b70449ca46cb7e03f9926
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Previously, when account moves were set to auto post, and the cron was triggered to post them, if a single invoice triggered a UserError, none of them were posted (User error might be for example missing required field to post, archived journal, inactive currency, ...). This commit enables to post all valid invoices. The invoices that could not be posted are now visible on the accounting dashboard on their respective journal card with the 'to check' attribute, and a note is written on the chatter of the problematic invoices, describing the reason why the move could not be posted.
For performance reasons, we lowered the number of moves that can be posted in a single batch. This way, if a move among a batch cannot be posted, all moves of this batch must be handled one by one. Doing batch of 100 is already the case in 16.0
task-3244310
closesodoo/odoo#130958
X-original-commit: 5c0ba84d20334f307834113fdea61f04391cbcbe
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Hugo Poncelet (hupo) <hupo@odoo.com>
Miscellaneous improvements:
1. In analytic tags, the percentage is now a prefix.
2. In the widget, 0% accounts are now hidden.
3. In the analytic items list/pivot views, it is now possible to search by:
- Financial Account.
- Cross by.
4. By default, the pivot view is now grouped by plans and then analytic accounts.
5. An "Analytic Reporting" menuitem that opens the pivot view is added in Reporting > Management.
task-3446504
closesodoo/odoo#130971
X-original-commit: adb8ec875c9b4e299147c46dc60a87fd26fff91f
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
`default_get` is bad m'kay?
Reproduce:
* Accounting > Configuration > Taxes > Create
* Just add a name, save.
There are no repartition lines, but there should be at least one line
for the base line.
This happens because `default_get` was only computing the main field
`repartition_line_ids` and it was allowed because the contraint was not
checking that same field.
closesodoo/odoo#129840
X-original-commit: f05457c82af63358c292350ef110f0b18c27f164
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
As introduced here:
https://github.com/odoo/odoo/pull/112611/commits/dce4ec8380aad1a1d1b40c33a50ab5914838ba18,
PdfReadError should be imported conditionally as it is now possible to have dev
environments with different versions of PyPDF2.
We are employing the same strategy done in the mentioned commit to avoid import
error when the environment has python > 3.10 and PyPDF2 v2.12.1
closesodoo/odoo#130892
X-original-commit: 0163edfb16c849eac61fb33b400faedda33f667f
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Rename alias domain and aliases used a test data. This allows to make
them easier to read, follow, grep and understand.
Activate multi-company on alias and gateway tests, ensuring it currently
has few impact on tests.
Task-3453577 (TestMail: Update Alias/Gateway tests for MC)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130768
Implemented domain exclusion to remove Off Balance Accounts from Account
Mapping in Belgian CoA. This decision was motivated by the rarity of use
of these accounts by our target audience, and their potentially
confusing placement at the top of the list due to their prefix '0'. Now,
the Account on Product and Account to use instead fields will not
display these seldom-used accounts, improving usability and efficiency.
closesodoo/odoo#129576
Task-id: 3431420
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Prior to this, when searching for a currency in an invoice or journal entry,
"create" and "create and edit" options would show up to propose the creation
of the currency to the user although the currency already exists but is
inactive by default. This could lead to currency duplicates.
This implementation makes it now impossible to create a currency when
searching in a currency field and forces the user to go through the
settings to activate the currency he wants. In addition, we show the
inactive currencies as well in all journal entries that aren't
a miscellaneous operation.
task-3383375
closesodoo/odoo#127707
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
This commit change /report/barcode/?type= to /report/barcode/?barcode_type
See ee324e8#diff-8f0bbb50491623995fba965c3d64585c6cbfdbbe519ec95473e472826d253826R1977-R1979
similar fix done previously in `l10n_sa`: https://github.com/odoo/odoo/pull/127222
sentry-3983735307
closesodoo/odoo#130604
X-original-commit: 93b6d3f0bad435a413b1b5b44445ddc4a6cd7852
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Set "Cash Discount Tax Reduction" to "Always"
Crete the following taxes:
- fixed136:
- Tax Computation: Fixed
- Amount: 0.1360
- Included in price: False
- Affect Base of Subsequent Taxes: True
- fixed176:
- Tax Computation: Fixed
- Amount: 0.1760
- Included in price: False
- Affect Base of Subsequent Taxes: True
- 6%:
- Tax Computation: Percentage of Price
- Amount: 6
- Included in price: False
- Base Affected by Previous Taxes: True
- 12%:
- Tax Computation: Percentage of Price
- Amount: 12
- Included in price: False
- Base Affected by Previous Taxes: True
Create the following products:
- A:
- Sales price: 116.00
- Customer taxes: 6%
- B:
- Sales price: 0.91
- Customer taxes: 6%
- C:
- Sales price: 194.21
- Customer taxes: fixed136, 12%
- D:
- Sales price: 31.46
- Customer taxes: fixed176, 12%
Create a Payment Term "1/7 Net 30" with 1% discount if paid within 7
days
Create an invoice:
- Add payment term "1/7 Net 30"
- Create the lines
- product A, quantity 6
- product B, quantity 350
- product C, quantity 1
- product D, quantity 5
Save
Issue: An error will block the action
"""
The move (Draft Invoice (* 44)) is not balanced.
The total of debits equals $ 1,483.87 and the total of credits equals
$ 1,483.86.
You might want to specify a default account on journal "Customer
Invoices" to automatically balance each move.
"""
This occurs because we compute the balance amounts for epd without
rounding. Then in `needed` we sum up the amounts, ending up with 3 epd lines,
having respectively the following balance:
- 10.145 -> 10.15 after rounding
- -13.6601 -> 13.66 after rounding
- 3.5151 -> 3.52 after rounding
So, because of the rounding, we will have 1 extra cent in debit amount
and the invoice will result unbalanced
Fixing by rounding the partial epd amounts
opw-3327069
closesodoo/odoo#130596
X-original-commit: c9fc35ad5bb437c6e20ea4244178e4f15b7eeac3
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
This PR will introduce multiple display improvements. Here is the list:
- In the accounting settings, the fiscal localization section has a button that
was oddly placed. This PR solves that issue.
- On the dashboard, when clicking the three dots on a card, the options "remove
from favorites" and "configuration" were not aligned.
- In ir_attachment, the label and field of "datas" will be aligned, and a gap
will be added between the icons.
- In the settings, the button links were inconsistent in terms of padding. This
PR resolves that.
- In the payment providers, two button links had text wrapping issues. By adding
Bootstrap classes, this has been resolved.
closesodoo/odoo#130522
Task-id: 3342969
X-original-commit: d4ba0c1f69212bfb0030036951c2888e935bbdf0
Related: odoo/enterprise#45060
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Fix a minor issue introduced in this commit: https://github.com/odoo/odoo/commit/60465047df56c07e61623c1f7304fede28232581
The issue is that the left bottom section of the invoice layout is constraint on the left side, even if nothing is present on the right part. This caused an issue for example with the Mexican Localization where the text beside a QR code can not reach the full width of the page, making the QR code and the text on top of eachother.
task-3444692
closesodoo/odoo#130456
X-original-commit: 1bbd89cacbbd4fc600eb2da20577d6688392485b
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Hugo Poncelet (hupo) <hupo@odoo.com>
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
Versions:
---------
- saas~16.2+
Steps to reproduce:
-------------------
1. Install Belgium accounting module
2. Switch to the company with the template
2. Go to Accounting -> Bank -> Reconcile Items
Issue:
------
Translations are only being loaded in French
Cause:
------
There is no translation assigned to the other
expected language: English, German and Dutch,
and the field name of `account_reconcile_model`
did not have the parameter translate = True
Solution:
---------
To fix this issue we have to add the respective
translations using name@Lang and add the parameter
`translate = True` in the field name of
`account_reconcile_model` so that the translations
can be loaded to this field.
OPW-3316716
closesodoo/odoo#126542
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When having a cash rounding line on an invoice,
base amount is taken twice into account in the tax
report when grouping by account > tax or tax > account.
Steps:
- Activate cash rounding, and create one with
0.05 rounding, method 'HALF_UP' and
'biggest_tax' strategy
- Create an invoice with a product line with
unit price 1.24$, tax 15% (included in price)
- Select the rounding method created above.
- A rounding line for tax 15.0% and 0.02$ should
have been created
- Go to tax report and group by Account->Tax or
Tax->Account
-> Base amount is 2.48 instead of 1.24
opw-3336398
closesodoo/odoo#130375
X-original-commit: 34721726676dbee8b13dc19f449e5307140b6086
Related: odoo/enterprise#44934
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
- Create a db with account installed (and a random loca)
- Run the test "test_quick_edit_total_amount"
=> The test may fail (undeterministically), especially the first time
The reason is that we don't have an order in "_get_frequent_account_and_taxes"
So, if we have the same number of lines with the same account and with a tax or without one,
we can not guarantee which tax is considered the most frequent.
We now define the order by saying that we should take the taxes into account,
so lines with taxes take precedence on lines without
Linked to runbot error 23385
closesodoo/odoo#130326
X-original-commit: bdb21983371fb62b01275471e8ca7099219e1053
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We need to take care of the `unique(sanitized_acc_number, partner_id)` constraint
and avoid to create a new bank account if already exists in another company.
closesodoo/odoo#130324
Task: 3432443
X-original-commit: bc4cbd0e129d7f9d417752e162397ece5e1bfc0f
Related: odoo/enterprise#44903
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
We need to take care of the `unique(sanitized_acc_number, partner_id)` constraint.
Task: 3432443
X-original-commit: 687bc145c8889d05ee816b0cd8ed0378c301b4e7
Part-of: odoo/odoo#130324
The tour failed as soon as there were several companies installed.
The tax created could be assigned to the wrong company, and as such,
not used in the tour.
Linked to runbot error 22953
closesodoo/odoo#130281
X-original-commit: a4ad0a8f36f4091da5de99c5a54326dce3784817
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
In a previous commit 8bfa76a, _lt() returns _t().
So, in this commit, all usages of _lt() are replaced by _t().
task-3292454
closesodoo/odoo#130179
Related: odoo/enterprise#44906
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Since the relational model was rewritten (PR 114024), the record id is
no longer present in data by default. The correct way to access the id of
a record is to do record.resId.
closesodoo/odoo#130061
Related: odoo/enterprise#44785
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When having a python format in the ref (or memo) of a payment, going to journal
items, select the move and doing an automatic entries, when changing the account
a traceback appears.
In the _format_new_transfer_move_log, we create a format that will be put in
the chatter. In this message we use python format without considering the
possibility that we can have one in the link of the move.
By putting the python format before formatting the link, the issues is solved.
task: 3434131
closesodoo/odoo#130091
X-original-commit: 12e0e6a492a010d61a8a1f763c72e25765654511
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
Since the relational model was rewritten (PR 114024), it is now reactive,
so it is no longer necessary to use model.notify() to render the view.
closesodoo/odoo#130058
Related: odoo/enterprise#44781
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Currently, errors occur when the 'Send invoices automatically' cron
is run this is because the related invoice is deleted and we receive an
empty record in move_to_lock when executing the query.
Step to produce an error:
- Install 'Invoicing'
- Create an invoice e.g. 'INV/2023/00001'
- Click on confirm > Click send & print
- Now in wizard don't click 'Send & print'
- Now go to home screen or close current window
- Open 'INV/2023/00001' invoice and click 'Reset to draft' and delete it
- Go to scheduled action and open 'Send invoices automatically'
- Click on 'Run Manually' >> error occur
This commit fixed the above issue by not the query
from executing when move_to_lock has an empty record.
sentry-4291237277
closesodoo/odoo#130021
X-original-commit: a2c855970ab56f5ef7acf08eeaf8ff45c1eca8c9
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Steps to reproduce:
- Open a kanban view inside the project app
- Click on the "Quick Assign icon"
- Select a user A
- Directly unselect this user
- Close the dropdown and open the edited record
- you can see the user A is still assigned => bug
This bug was occurred by a missing awaiting promise inside the deleteTag
method.
closesodoo/odoo#129996
X-original-commit: b345af5389cd0cc3eb5e373d50ea62afc4e46b22
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
A recent [fix](https://github.com/odoo/odoo/commit/bbcb925f88cbdc34532894918e50fd11afe7a95d) introduced a bug when trying to open
the miscellaneous operations journal from the accounting
dashboard.
A `TypeError: unsupported operand type(s) for +: 'bool' and 'list'`
was raised, which is why an empty list is used when
`action['domain']` is falsy.
Internal bug report.
closesodoo/odoo#129957
X-original-commit: ac6eee7e6c5a32b06ea9f7f21cf13623c5c85d13
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
When you select multiple invoices in List view and use the Send & Print, the invoices
will be sent asynchronously using a cron trigger. This can take some time.
If the user opens one of the to-be-sent invoices, there is nothing telling the
user that this invoice is part of a running batch and will be sent eventually.
This might cause cases where the user will try to trigger the send & print
manually again, causing some concurrency issue.
To at least mitigate the issue, we will display something on the
invoices that are part of a running batch of a Send & Print
task-3360179
closesodoo/odoo#129854
X-original-commit: 9349ae9d44e09f5282f4719c73c3f6b12b04e99c
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Steps to reproduce:
1. Create an invoice with an Invoice Date in the past
2. Confirm the invoice
3. In Journal Items tab, click cut-off and then create journal entries
4. Traceback
opw-3369709
closesodoo/odoo#129689
X-original-commit: 219f9f929bb18f60a85e7fa3eb6868f954931f55
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
Some test may perform a request without being in test_mode
In this case, a check signaling could be called and since the sequence
was incremented the registry may be reloaded.
This is a simple fix to avoid this issue waiting for a stronger check.
closesodoo/odoo#129814
X-original-commit: 41bb17b3046e8f1605d6f893ca1807d77ed21173
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
We are currently able to open the send & print for a vendor bill.
It doesn't make any sense to ask to a vendor to pay its own invoice.
closesodoo/odoo#129793
X-original-commit: b3e8229d16be074a719fa07e3b2d5488ace66492
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
before this commit, upgrade widget was added to the field
display_invoice_amount_total_words in accounting settings,
which decides whether the total amount has to be shown
in words in invoice report.
all its functionality and code is available in community
edition.
after this commit, the upgrade widget which request to
upgrade enterprise edition to access the feature will
be removed from the display_invoice_amount_total_words
field.
closesodoo/odoo#129609
X-original-commit: 94256de52a44273c5ba1653770dd98aa14d9e334
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Steps to reproduce:
-------------------
* Go to Contacts and create two contacts, each with a personalized account receivable;
* Go to Sales and create a quotation for each contact;
* Confirm the quotations and deliver the products;
* From the sale.order view list, select the two SOs and click on Action to create invoices.
* Go to the new invoices -> Journal items
* One of the invoices has wrong account receivable
Issue:
-------------------
When creating two invoices for two different quotations and customers, where each customer has a personalized account receivable, only one of the new invoices assign it correctly.
Cause:
-------------------
When computing the account_id for the move lines, a SQL query selects distinct based on
property.company_id, property.name but since the property.name is the same for both customers “property_account_receivable_id” and they have the same company_id it only consider the first one and the second is discarded.
To fix the issue, we need to ensure that all users are being considered in the computations.
OPW-3376865
closesodoo/odoo#129607
X-original-commit: c66d9ee2a160c3bad745b1394308c3e48f5f2e91
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Matheus Leal Viana (malv) <malv@odoo.com>
This issue occurs while uploading a PDF file and that PDF file has an unexpected
string. So, The trackback will appear.
Step reproduce :
- install the account_accountant Module
- Open Accounting Module
- Click On Customer > Invoices
- Click On Upload Button > Upload PDF file
Error:
Unexpected escaped string: b'~'
When a user uploads a PDF file, PyPDF2 does not recognise the symbol
and character combination as a valid escape sequence, such as (\), (~).
sentry-4304111635
closesodoo/odoo#129556
X-original-commit: ea150a6f4be44ffc6f15837d5febd06fa1b695be
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Florent de Labarre