Task 2085023
* Add a field that replaces the context to get the ids of the
entries/invoices
* Remove move_id, we can use move_ids instead
* Add text to explain invioces/bills will create refunds
closesodoo/odoo#38857
Related: odoo/enterprise#6263
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Add new move reversal line in wizard model, those new_move_ids are
usefull for the override in helpdesk.
Currently, we return a form or a list view according to the
number of generated reversed moves.
Now, we link the generated moves on the wizard, so that we can
link the invoice lines correctly to the helpdesk tickets. Now,
the invoice lines are correctly linked only if there is 1 reversed
line.
id=2017554
closesodoo/odoo#39576
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Create a customer without email address, go on the accounting module
create an invoice for this customer.
Go back to the invoices list and select some of them including your
invoice for your customer without email address. Send them by mail.
You will have a traceback and the wizard will be broken.
This bug is caused by a change in the account module, there is no more
reference, they are replaced by the name of the invoice.
OPW-2085837
closesodoo/odoo#39856
X-original-commit: d1feb088228e1fe74c917ecdd5f4c0e87d253263
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- In the sales or accounting module, create some invoices.
- Select them then click on `action > send & print`
- The wizard opens but not in the mass mail mode.
It creates some inconsistency and if you click on send,
the invoices are sent to the wrong customer.
Sometimes, the invoices are not sent at all.
I think the problem comes from the `_compute_composition_mode` method
who set the value of `composition_mode` on the wizard instead of
on the composer.
OPW-2085837
X-original-commit: 2496125f29cf1bd5b7a37384897f49bed86e69d8
Tests can fail when they are run at the moment when `fields.Date.today`
is different from `fields.Date.context_today`.
closesodoo/odoo#39079
X-original-commit: 0405f4a35bcad60fd99b1a05ffc8d9774e9a2829
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Install Accounting, create a journal entry, post it, reverse it with
a date in the future.
The reverse entry will be posted, instead it should stay a draft (with
the appropriate 'auto_post' set to True)
opw-2083121
closesodoo/odoo#38802
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The way the active_id(s) were retrieved made the wizard only take care
of one active_id. This prevented from reverse multiple invoices at the
same time.
closes odoo/odoo#38537
Fixes: #35759
X-original-commit: fe47011c3fdcec0bda5334f10679e853fe41e45a
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
When is created a refund from a invoice, the payment term its cleans,
but not the date due.
In the next case:
1. Create an invoice with date 05/26/2019, with payment term "30 days".
2. Create an invoice refund for invoice in 1, with the same date.
In this case, the payment term in the refund is empty, but the date_due
is the same that in the invoice.
With this change, the date due in the refund is the same that invoice
date.
closesodoo/odoo#38212
X-original-commit: 6828454dc3726d85e4d29b9399d6e8ddd1aaac21
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In an onboarding situation, the company doesn't have a logo
make an invoice, send and print, print
The document layout editor's layout opens, because nothing is set up
on the company
Click Save
Before this commit, it was impossible to make the invoice print
because each time the document layout was displayed
After this commit, the invoice prints when clicking on Save
There is no default external layout for main_company
Also, the heuristic used to evaluate whether a company
has been set up, onboardingly speaking, has changed.
Before we used the existence of the logo, after we check if
a layout has been setup. When saving the document layout
modal, a report layout is written on the company
So, practically, the document layout modal only appears once
when trying to print invoices (or other documents)
closesodoo/odoo#37137
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
en_US may not be activated as it is possible to create a database in
another language using the database manager.
When trying to install a chart of account, the tax return entry tried
to format a date at the installation of the module, with no lang in
the context. The fallback was made on en_US but an error is raised if
that language is not activated.
As it is a very common scenario to retrieve a language from the
context, add a generic tool method to do it.
Replace and closesodoo/odoo#37629closesodoo/odoo#37568
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit sets the call to default method on move field in reversal
wizard as lambda to ensure that the right method
is called when it is inherited (as in helpdesk_account module).
It also changes the form view so other module can use it to refund
invoices (move_id field first in the view as it will determine if refund
method should be visible or not).
Task-2047999
closesodoo/odoo#37635
X-original-commit: bcda50aeca44b292417024a5e422ffb8698e0c99
Signed-off-by: gla-odoo <gla-odoo@users.noreply.github.com>
- Remove the useless domain set on the field.
- Fix the belgium PCMN to work with accrual.
closesodoo/odoo#37560
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Multi-company: Fix domains on wizard / company.
- Multi-currency: Manage multi-currency when generating accrual lines.
- Moves creation: Avoid creating too much moves:
[1-2] moves was created per line before this commit.
[1-2] moves are created per invoice with this commit.
- Invoice type: Allow accrual only one posted journal entries.
closesodoo/odoo#37487
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before, it was possible to select lines from different companies and create a line from a yet different company. This is now forbidden.
Also, add tests to ensure only the account is changed when creating an accrual entry.
closesodoo/odoo#36751
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Install Account, do an invoice, send and print it. Install
snailmail_account, do the same process. The wizard refuses to send the
email because the Compose field is empty.
The `account.invoice.send` model is defined with an `_inherits` to
`mail.compose.message` on the `compose_id` key. When the model is first
created, that `compose_id` key is left unpopulated on the view as the
referenced model is not created yet. Hence posting the view is
impossible as it fails the form validation.
closesodoo/odoo#36715
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
This commit tries to fix the issue in the "Send Invoice" modal.
Because of this issue, the recipients and body are empty.
task-2032586
closesodoo/odoo#35536
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
=======
Purpose
=======
Accruals are revenues and expenses that are incurred during an accounting period for which no invoices or payments were received or made.
=> We suggest a wizard allowing recognizing the Expense/Revenue in a different period keeping tax return in the invoice period.
Example:
A vendor bill received in February which was for the December consumption.
You should recognize the expense in December but the tax return is still due to February.
1) Regular Vendor Bill in february
Account D C
600 ACHAT 10000
411 TVA 2100
440 FOUR 12100
2) Action opening a wizard that allows specifying when we have to move the expense.
- Targeted date, accrued account (expense, revenue, taxes, ...)
- Action from account.move.line ?
3) Wizard result
a) The expense account is replaced by the accrued expense account in the original vendor bill journal entry (february)
Compte D C
444 FAE 10000
411 TVA 2100
440 FOUR 12100
b) A new accrual journal entry is created for the original expense account in december
Compte D C
600 ACHAT 10000
444 FAE 10000
Was task 2006617
closesodoo/odoo#36053
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- no default reason (otherwise the invoice ref is repeated twice)
- rewording of refund types and helper texts
- avoid 'Reversal of: INV/2019/001, False' as reference -_-
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Task 2031686
* Change some labels on the dashboard
* Move the action "Take money In/Out" to a button because it was also dsplayed in bank journals and we only want it for cash journals
* Add reconciliation param on the first account config list, as well as a button to go to the form (it is an editable list)
* Add an action to duplicate accounts in batch
* Smartly detect when a cash statement can be extended instead of creating a new one, making it more obvious to the user that he may need to validate his previous statement(s)
closesodoo/odoo#35137
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Fine-tuning of commit 5621ae3d6b.
While it focused on fixing the 'mass_mail' mode,
it forgot to keep the correct behaviour for the case where only one mail is sent.
In the latter case, it is typical to overwrite the template values, especially
for the body, before sending the mail.
In that case, applying the onchange on the templates overwrites the user input.
Note that in the case where the template is undefined it would set the composer
values to empty ones; while standard use would not allow in mass mail to both
send content and have no template, it could be done via a customisation.
opw 2041631
closesodoo/odoo#35164
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Create an invoice for a customer, send him an email from the chatter, in
the mail template set a specific "Reply to" and send the email. The
"Reply-To" template mail header is ignore and the one generated by
`mail_thread._notify_get_reply_to` is used.
See also 1c57d5e and 7b0806b
opw-2041640
closesodoo/odoo#35127
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Task 2002068
The constraints were executed before the data was written in the database. Therefore, the data was not correclty constrained.
Also add the invoice date in the constraint on duplicated vendor references as sometimes, your vendor uses a numbering that loops over time (each year it restarts at 0 for example) and in this case you may receive two different bills that legitimely have the same reference.
The reference on a refund is now 'Reversal of {name}: {reason}'. Before
the reason was in the payment reference, and it didn't make much sense.
closesodoo/odoo#35046
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Select invoices with partners with different languages.
Execute the 'Send' action, and choose send_mail.
The mails are all sent in the same language.
The composer extracts the template's body to put it as self.body
(note that everything also applies to the subject field).
This is done with one language.
Down the line, mail_compose_message renders the values with the object,
using self.body (which can be manually edited).
Therefore the lang parameter is ignored at this point.
This should ideally be fixed at the mail level, which is riskier in stable,
so it may be fixed either later or in master.
So this fix only intends to fix the consequences for this specific use-case,
in a much safer way, but it could be removed once the true fix is one.
opw 2035525
closesodoo/odoo#34975
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
This reverts commit 7273719b88.
Reply to header of templates should be used only for mass mailing purpose.
It is a known limitation and should not be changed in table without more
in-depth testing.
closesodoo/odoo#35354
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit merges the following models
* account.invoice and account.move
* account.invoice.line and account.move.line
* account.voucher and account.move
* account.voucher.line and account.move.line
It was the opportunity for a big cleanup of the code, so it also restructures the whole account module, its different models/fields, the tests etc. for a better world and a better code readability.
==== Rationale ====
The rationale of this huge change is that we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature and very strategic for the fiduciary companies. For example, changing the account of a journal entry needs to be automatically reflected on the related invoice.
The same reasoning applies to sale/purchase vouchers.
==== Changes made in features =====
When creating an invoice, you are now creating a journal entry directly.
--> The object account.invoice no longer exists.
In the same fashion when creating an invoice line, you're now adding journal items directly in the journal entry representing the invoice. If this invoice line has some tax, it may create additional journal items as well.
--> The models account.invoice.line & account.invoice.tax no longer exist
Identically, when creating a sale/purchase receipt with its lines, you are now creating a journal entry directly and there's no more usability difference between encoding a receipt or an invoice.
--> The object account.voucher no longer exists.
--> The object account.voucher.line no longer exists.
--> The whole account_voucher module no longer exists.
Positive side-effects coming from these changes are
* draft invoices/bills/sale or purchase receipts now create a draft accounting entry. Validate these objects now simply post its journal entry. That means that draft invoices/bills/sale or purchase receipt can straightforwardly be included in reporting or budgets.
* opening a journal entry in form view will now always open the correct view: if it's a sale/purchase journal entry we will have a customer invoice/vendor bill view or a sale/purchase receipt view, whatever the menu we're coming from.
* code & business logic simplification. It is also condensed in a single place instead of being partially duplicated on invoices, vouchers and journal entries.
There should be no feature loss, except the one allowing to group multiple journal items together based on the same product during the invoice validation.
==== Changes made in models =====
* account.invoice: model removed. Instead, now use account.move with following mapping
field (account.invoice) field (account.move)
----------------------- --------------------
name invoice_payment_ref
number name
reference ref
comment narration
user_id invoice_user_id
amount_ total_company_signed amount_total_signed
residual amount_residual
state state + invoice_payment_state /!\ selection changed
date_invoice invoice_date
date_due invoice_date_due
sent invoice_sent
origin invoice_origin
payment_term_id invoice_payment_term_id
partner_bank_id invoice_partner_bank_id
incoterm_id invoice_incoterm_id
vendor_bill_id invoice_vendor_bill_id
source_email invoice_source_email
vendor_display_name invoice_vendor_display_name
invoice_icon invoice_vendor_icon
cash_rounding_id invoice_cash_rounding_id
sequence_number_next invoice_sequence_number_next
sequence_number_next_prefix invoice_sequence_number_next_prefix
'invoices' subset of account.move can be accessed by using the selection field 'type' or one of the many helpers like is_invoice()
* account.move: now has a valid state 'cancel' that has to be excluded from all business logic
* account.move: field 'amount' renamed into 'amount_total'
* account.move: field 'reverse_entry_id' renamed into 'reversed_entry_id'
* account.move.line: now has a field 'display_type' that has to be excluded from all business logic, in order to support invoice layouting
* account.invoice.line: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.line) field (account.move.line)
---------------------------- -------------------------
invoice_id move_id
uom_id product_uom_id
invoice_line_tax_ids tax_ids
account_analytic_id analytic_account_id
'invoice lines' subset of all account.move.line from a journal entry can be accessed by using the boolean field 'exclude_from_invoice_tab'
* account.invoice.tax: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.tax) field (account.move.line)
--------------------------- -------------------------
invoice_id move_id
account_analytic_id analytic_account_id
amount price_unit
base tax_base_amount
'tax lines' subset of all account.move.line from a journal entry can be accessed by using the relational field 'tax_line_id'
* account.invoice.confirm: model removed. Instead, now use the 'post()' function of account.move
* account.invoice.refund: model removed. Instead, now use account.move.reversal to reverse the entries with the same options as we had for invoices
* account.voucher: model removed. Instead, now use account.move of type in ['out_receipt', 'in_receipt]
* account.voucher.line: model removed. Instead, now use account.move.line
==== Changes made in functions ====
* on account.move, method _run_post_draft_to_post() renamed into _autopost_draft_entries()
* on account.move, method action_account_invoice_payment() renamed into action_invoice_register_payment()
* on account.move, method action_invoice_reconcile_to_check() renamed into action_open_matching_suspense_moves()
* on account.move, method _get_domain_edition_mode_available() renamed into _get_domain_matching_supsense_moves()
* on account.move, method _get_intrastat_country_id() renamed into _get_invoice_intrastat_country_id()
* on account.move.line, method _get_domain_for_edition_mode() renamed into _get_suspense_moves_domain()
* in account.bank.statement, contextual key 'edition_mode' renamed into 'suspense_moves_mode'
Was task 1917430
Sending an email wasn't taking the outgoing mail server into account.
Adding it in the 'account_invoice_send_views' to use it in the wizard.
opw-2030717
closesodoo/odoo#34593
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
wan