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
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
Martin Trigaux