There's a demo vendor bill that is fixed on the 2018, while it
sure should be set at more than an year ago, but not in a fixed
point in time that keeps getting further away from the present moment.
Task link: https://www.odoo.com/web#id=2732449&model=project.taskclosesodoo/odoo#107112
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Analytic distributions that contain mandatory plans should be blocked from posting.
However, automatic flows (for example subscription invoices) should not be blocked.
For this reason, the context is used to determine whether the distribution should be validated.
closesodoo/odoo#102720
X-original-commit: 7b11af76598c0782ac2097d3cbeb718962be2537
Signed-off-by: William André (wan) <wan@odoo.com>
In order to better display the functionalities, we will change how
the demo data for bank statement are created. There will now be one
bank statement and multiple bank transactions not linked to a statement.
Also rewords one error to be clearer.
closesodoo/odoo#101466
X-original-commit: 5e14b28905fc00bad2c2ccd40328c676d049917d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Bank statements are now optional in accounting. The users add statements directly and can assign statements for control reasons.
The users can enter end date and end balance real for the statements and attach the bank statement scan.
The system checks if there is a gap (lines without statement) before current statement and warns the user
with decoration, also we check if the ending balance match the accumulated balance of the last line.
Bank statement lines now show an accumulated balance and can be sorted by drag and drop in the same date, if the user drags a line
to a position with lines of another date, it simply doesn't have any effect.
Rename accumulated balance to cumulative balance, a better name
closesodoo/odoo#99092
Task: 2879904
Related: odoo/upgrade#3906
Related: odoo/enterprise#30824
Signed-off-by: Laurent Smet <las@odoo.com>
This commit improves the payment terms by:
- making the payment terms lines editable on-the-fly removing the need for a wizard
- refactoring the computation of the payment terms
- adds new demo data for payment terms
- adds an example section where the user can test and preview the due dates and amount of its payment terms
- adding a new parameter "Display terms on invoice". If set, the payment deadlines and respective due amounts will be detailed on invoices.
The refactoring:
- adds a field `months` (months to add after the invoice date)
- adds a field `end_month` (if True, switch to the end of the month after having added months or days)
- renames the field `day_of_the_month` to `days_after` (days to be added after the switching to the end of the month, only if `end_month` is set)
- deletes the field `option` which was too restrictive
- modifies the calculation of the payments terms taking into account these new fields
This allows some combinations that were not possible before.
Example: The French payment terms "30 jours fin de mois le 10" (which should be interpreted as "10 days after the end of the next month") can be encoded as
```
months = 1
days = 0
end_month = True
days_after = 10
```
Task id 2852814
closesodoo/odoo#91490
Related: odoo/enterprise#29661
Related: odoo/upgrade#3524
Signed-off-by: Laurent Smet <las@odoo.com>
Improve the demo data for bank statement in account by formatting the
payment_ref amounts using the company currency, and fixing the due
amount in one payment_ref to match the statement line amount.
Task id #2855485closesodoo/odoo#98510
X-original-commit: 4b23d11184be9bac5ef9790cc7f38bc4d637b47a
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
to improve perfs.
_______________________________________________________________________
The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
`write`
* by saving when switching tabs on the Invoice form, to synchronize
before showing the values
This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
intercompany, ...)
* the performance for invoices with many lines improves drastically, going
from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
which was unexpected and needed to be managed manually in all the
onchange methods
This means that:
* Some fields need to be exclusively computed on journal entries values
or invoice values, more specifically the Tax Summary widget.
It is now
- computed from entry lines, when opening the view
- computed from invoice lines when changing those, because the tax lines
will need to be recomputed anyways, erasing previously set values
- set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
(i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
This is because such a behavior was undefined (how is changing the balance going
to affect the unit price? How is the amount currency going to affect it?)
_______________________________________________________________________
Implementation Details
----------------------
The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.
Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)
By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`
The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.
Performances
------------
You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.
```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
self.env['account.move'].create([
{
'move_type': 'out_invoice',
'partner_id': random.choice(partners),
'invoice_line_ids': [
Command.create({
'name': f'line{i}',
'product_id': random.choice(products),
'tax_ids': [Command.set([random.choice(taxes)])],
})
for i in range(nline)
]
}
for j in range(nmove)
])
# After | Before
print(timeit("create(1, 1)", globals=globals(), number=1)) # 0.11 | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76 | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56 | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03 | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99 | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44 | 79.55
```
Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)
Why this commit title?
----------------------
Someone told me that this was the perfect way of naming your commits.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
The demo data created by account did not call _onchange_price_subtotal
on the created account_lines, making the total debit
and credit not matching the state of the lines.
closesodoo/odoo#85188
X-original-commit: 403939ea7b460b95cc31993613f5cba5f5fefcfa
Related: odoo/enterprise#24651
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
The test is running in sudo mode, so we need to specify the company in
the search.
Also do not load the demo data when installing as we would do the work
twice for most localization.
closesodoo/odoo#67235
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Task 2124952
Extract all the demo data from `l10n_generic_coa` to a new way of
generating the demo data for accounting modules.
Because the data needs to be created multiple times, and right after the
chart template instanciation, it cannot be done the usual way. Instead,
we use python generators to declare the data. It allows us to reference
data that was not created yet at the start of the creation of the demo.
An xml_id is given, prefixed with the id of the company it is created
for (just like the instanciation of the chart template)
To find the correct accounts, a helper method has been added to
`account.account`. It will look for an account with the correct xml_id
(which is the one of the l10n_generic_coa, that we have to put on the
other l10n modules too, in the future). If it didn't find the xml_id, it
will look for an account with the correct type. If it still didn't find
one, just take any account.
- This commit moves the Payment Term "End of Following Month" from
demo data to data and adds two new Payment Terms: "21 Days" and
"30% Now, Balance 60 Days".
It allows the customer to define less Payment Terms
task-2032586
Purpose of the task is some demo data values are not matching with the products
mentioned so update the demo data values with matching product.
Task: 1892754
closesodoo/odoo#28573
* Replace payment term lines options 'last_day_following_month' and 'last_day_current_month' by two new less specific ones allowing choosing the day directly, and thus not limited to the last one anymore (semantically different).
* Rename payment term line option value 'fix_day_following_month' into 'after_invoice_month' for more clarity (no semantic change).
Was task 24239. Was PR #15487
Account demo data try to add lines to payment terms. However when
reinitializing the module similar lines are added and a constraint
raises as there should not have duplicates. This commit voids
payment terms before refilling them.
With multiple companies defined, ensure consistency in demo data in case a localization reusing the ones defined in account module is installed. Before that, the demo data used several hardcoded values to reference the company, but some models relied on the default company, which lead to crash when the active company was not the one hardcoded in demo data and such a new localization got installed.
In details:
* account.operation.template object renamed into account.reconcile.model
* account.reconcile.model.template object created
* added some records for l10n_be
Was PR 11230
Numbering of statements is not anymore automated, sequence of the journal is now only used for the numbering of account.move (for consistancy with payments). Name of statements now appears as 'reference'.
Cancelling of a statement line keeps in memory the old move's name to reuse it in the same fashion as for account.invoice (avoiding gaps in numbering).
Cancelling of a payment now keeps in memory the old move's name to reuse it in the same fashion as for account.invoice (avoiding gaps in numbering)
[IMP] account: d'ont create journal items for invoice lines with quantity 0 (not amount because of tax)
[IMP] crm: usability kanban view and schedule an activity
[FIX] crm: schedule an activity bug when no activity yet
[IMP] website: app for website (not a menu in website admin)
Remaining products :
- product_product_0 becomes service_order_01
- product_product_1b becomes service_cost_01
- product_product_43 becomes product_order_01
- product_product_47 becomes product_delivery_01
- prodcut_product becomes product_delivery_02
- Replace product_product_56 by service_delivery
- Replace product_product_59 by consu_delivery_01
- Replace product_product_58 by consu_delivery_02
- Replace product_product_57 by consu_delivery_03
Removed products :
- product_product_53, product_product_57, product_product_55, product_product_54, product_product_52,
product_product_51, product_product_50, product_product_48, product_product_46, product_product_32,
product_product_33, product_product_28, product_product_38, product_product_39, product_product_40,
product_product_41, product_product_34, product_product_29, product_product_30, product_product_44,
product_product_31, product_product_35, product_product_36, product_product_37, product_product_42,
product_product_45, product_product_49, product_product_26, product_product_14, product_product_15,
product_product_18, product_product_19, product_product_21, product_product_23
Removed corresponding binaries.
Removed all Bill of Materials demo data, that were ridiculous and replace them by 2 bom: A complete
computer, and a kit computer. Rewritten the tests accordingly.
Fixed tests :
- sale_mrp/test/cancellation_propagated.yml : The yaml ref function return a id, not a dictionnary
- sale_stock/tests/test_sale_stock.py : The service product invoiced on the delivered quantity was
in fact not invoiced on delivery on the test. As we are in sale_stock, Without timesheet, we
manually set the delivered qty for the product serv_del. If we don't do this, the invoice will
never be fully invoiced.
- The pricelist rules choice is not based on the sequence anymore (Seems to be a bug, reported to
online). By the way, I changed the product to avoid the overlap.
- sale_mrp/test/sale_mrp.yml: The yaml ref function return a id, not a dictionnary
- mrp : Rewritten the tests to be coherent with the new bom data
The invoice date of demo data is changed to match the current
month/year. The original issue is the following:
- install accounting, keep default configuration (company currency: USD)
- add a payment for Agrolait in USD (e.g. $10,000)
- go to customer invoice demo_invoice_2 (which is in EUR)
- the system proposes you to add a outstanding payment to pay the
invoice -> do it
The invoice is not shown as fully paid, but on the other hand if you
click again to add an outstanding payment, nothing happens.
The reason of this bug is because for this specific bill, the currency
rate has changed between the invoice date and the payment date. The
amount used to pay the bill: this is the price in USD, at the rate
corresponding to the date of the invoice (i.e., what you were supposed
to pay at the time of invoicing). The fact that is does not mark your
bill as paid is also correct: the payment is written with the rate at
the date of the payment, and in this case, the invoice is not fully
paid. You should therefore reconcile the invoice and create a write-off
afterwards to register the exchange rate difference.
This unusual situation (pay an invoice in a different currency, and
moreover the rate has changed) has not been taken into account for v9,
and there is no clean solution which can be foreseen for a stable
version.
However, since this situation arises right away with the demo data, this
can be very misleading for a new user. The fix simply changes the date
of the invoices, so that there will be no rate change between the
invoice date and the payment date with the demo data.
opw-657151
Major changes:
- No use of UoS anymore
- No analytic journal (journal_id) on account move lines
Reason: complete rewrite of the Sale module.
Responsible: fp, dbo, nim
- [REM] account_budget: removal of field 'validating _user_id' on account.crossovered.budget, which is now replaced by inheritance with mail.thread
- [REM] account_budget: removal of field 'code' of account.crossovered.budget, which was not used and redondant with its name
- [REM] account_asset: removal of field 'note' of account.asset.category, which was not used and redondant with its name
- [REM] account: removal of field 'to_check' of account.move, which was redondant with state == 'draft'
- [REM] account_voucher: removal of field 'audit' of account.voucher, which was a fields.related on move_id.to_check
code improvement
code improvement
payment_method to payment_method_id
writeoff_account to writeoff_account_id
property_account_receivable to property_account_receivable_id
property_account_payable to property_account_payable_id
property_account_expense_categ to property_account_expense_categ_id
property_account_income_categ to property_account_income_categ_id
property_account_expense to property_account_expense_id
property_account_income to property_account_income_id
property_account_expense_categ fix
sale_tax to sale_tax_id and default_sale_tax to default_sale_tax_id
purchase_tax to purchase_tax_id and default_purchase_tax to default_purchase_tax_id
ref_companies to ref_companies_ids
property_account_position to property_account_position_id
property_payment_term to property_payment_term_id
property_supplier_payment_term to property_supplier_payment_term_id
bank_accounts_id to bank_accounts_ids
payment_method fix after rebase
user_type after rebase
payment_method fix after rebase
after rebase
invoice to invoice_id
fix payment_method_id after rebase
code improvement
[IMP]user_type to user_type_id
[IMP]property_stock_account_input_categ, property_stock_account_output_categ to _id
[IMP]improve after rebase
[IMP]fix type
[IMP]Account: code improvement
Paolo (pgi)