Accrued liabilities, or accrued expenses, occur when you incur an expense that you haven’t been billed for (aka a debt).
For example, you receive a good now and pay for it later (e.g., when you receive the invoice). The same opposite approach for sales.
Why do accountants need such entries ?
- Accounting must give a fair view of the financial situation of a company. The loss/profit must be booked regarding the effective deliveries of goods/services, not on the paperwork only.
- On a fiscal point of view, if you want to be allowed to deduct a loss from your taxable basis, it has to be in the right period. If you didn't announce it on time, the loss might be rejected by fiscal authorities. Same goes for the augmentation of the taxable basis, it has to reflect real deliveries and not only paperwork.
was Task: 2555642
was PR #73707
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.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.
- Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal.
- Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal).
- Adapt and simplify the bank reconciliation report.
- Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly.
- Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account.
With invoicing, the payment will do that so the "in_payment" state should never be shown up.
With accounting, only the statement lines have the power to move an invoice to the "paid" state.
- Fix various corner cases about the management of multi-currency in bank statement lines.
- Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one.
- Ensure the 'reconcile' method will raise an error if the involved moves are not posted.
related enterprise PR odoo/enterprise#7019closesodoo/odoo#41301
--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Task 2146469
Rework the name computation:
* It doesn't use ir.sequence anymore
* It is an editable computed field
* Add a renaming tool
This allows the user to tweak the sequences more easily than having to
get through the ir.sequence settings.
The sequence depends on a parameter of the journal: continuous, montly
and yearly restart of the sequence. Everytime a new period is started,
try to make a pattern form another period.
The incrementing is done by taking the previous name, ordered
lexicographically, splitting it by taking the digits at the end, adding
1 and re contstruct with the prefix.
** This means there could be cases where the prefix has a big importance
on the next number. For instance, if you have
INVOICE/2019/0001
INVOICE/2019/0002
and then rename the last one to INV/2019/0002, don't expect the next
number to be INV/2019/0003. It will be INVOICE/2019/0002 (again) because
the highest number was INVOICE/2019/0001.
You will then end up with
INVOICE/2019/0001
INV/2019/0002
INVOICE/2019/0002
closesodoo/odoo#41485
Related: odoo/enterprise#7189
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This wizard also reconciles automatically entries done on reconcilable accounts. It can hence for example be used to "move" the balance of a receivable account into a payable account (or the opposite), using the generated transfer entry to do as if the receivable and payable accounts were directly reconciled together.
[IMP] account: display 'P' as matching number when account.move.line objects are partially reconciled
For this, we introduce a new matching_number field, used in account.move.line's tree views instead of full_reconcile_id, which used to be shown directly.
Was task: 2037318
closesodoo/odoo#39415
Related: odoo/enterprise#6544
Signed-off-by: Laurent Smet <smetl@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>
The onboarding modal for setting up the few base fields of a company
has now been moved to a wizard
It is accessible from the general settings, but also in the onboarding
section of sale and account modules.
The following company settings are editable with that wizard:
- Set report **layout**:
The user can chose the overall look of the report. The current choices
are : *Standard* (default), *Background*, *Boxed* and *Clean*.
- Set company **logo**:
Changes the company logo.
- Set report **colors**:
The user can set the primary and secondary colors of the report through
a newly added widget allowing to pick a custom color.
When changing the **logo**, colors are automatically set to its most dominant
colors.
> A "Reset colors" button also triggers the color calculation.
- Set report **font**:
Changes the overall font of the report. Only Google Fonts are used
for enhanced compatibility.
- Company **tagline**, also called "header"
- **Footer**
- **Paper format**
- Report **preview**:
A mockup of a final report
Automatically updates when changing **layout**, **logo**, **colors** or **font**
Co-authored by: Julien Mougenot <jum@odoo.com>
closesodoo/odoo#33863
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Since the wizard is not shown anymore (skipped to go right to file selection), we can remove it. Small refactoring had to be done for l10n_it in order to upload files with multiple invoices inside and to detect format
closesodoo/odoo#34145
Signed-off-by: Quentin De Paoli (qdp) <qdp@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
- reworked the multi.compose.message model to manage
several documents simultaneously
- Added a letter model for asynchronous processing
- usability improvement of the modal
Add a setup bar on account's dashboard, so that the user can more easily enter the initial data of his Odoo installation, following the steps that are proposed to him.
Was PR #16864
Was task 32119
Removed a code that allows to write a message, using a subtype that
does not exist. This is probably critical for some business, but
as I don't know which ones, let's remove it.
Chatter is sufficient.
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
* Moved 'sign' field from account type to financial report object.
* Changed and added demo data as per the new requirements.
* Replaced the 'Balance Sheet' and 'Profit and Loss' reports with Financial report.
bzr revid: uco@tinyerp.com-20111201115521-g8npi3igpq8dvthu
* the company_id field should be hidden in that chart, if the user doesn't have the useabilty / multi company group
* the chart should display the period sum before the year sum
bzr revid: mra@mra-laptop-20100827103013-ppj8y6loadpw8oz4
jbw