By counting the number of customers/suppliers before doing the query and
updating all at once, we can reduce the number of queries done quite a
lot for big batches of invoices.
closesodoo/odoo#56848
X-original-commit: b0e0035b585f976e912e97e7f95f66b525bc8e43
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
Wrong usage of self in for loop
closesodoo/odoo#55334
X-original-commit: 5a0b06ab0447f2b09e71934f2cc3209e6ebe9359
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Add Total Receivable and Total Payable to contacts list view.
Create Vendor Bill for a partner with $0 Receivable and Payable - the
Payable amount is updated in the list view.
Create an invoice for this partner - the Total Payable is changed to $0,
and the Total Receivable is updated in the list view.
Create a Vendor Bill for a partner having a Receivable amount - the
Payable is not updated.
This occured after commit 9920f20e4c
In a situation in which the lines retrieved from the db are arranged
like
|pid| type | val |
|---|-----------|-----|
| 10| payable| 500|
| 14| receivable| 200|
| 14| payable| 300|
line 3 will cancel line 2 because partner credit will be set to false
after the debit update.
Fixing by checking that the same partner has not been processed yet
opw-2250989
closesodoo/odoo#51351
X-original-commit: 0274d61a11c6f5220d6af37a38adafb3e5276224
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Such a change breaks XML-RPC calls. Moreover, it allows the creation of
partners without the accounts set, which will cause inconsistencies
later on.
This reverts commit 29c362b7c3353c2be11ab117f454d04ed9853f75.
opw-2241875
closesodoo/odoo#49982
X-original-commit: f720602ac24246d29de4919f18ae7c32cce2ffc2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
During the onboarding, if Invoicing is installed but no chart of account
is set the field property_account_receivable_id and
property_account_payable_id prevent from validating a new partner
because they are required but not auto-filled, and the fields are not
visible if Invoicing is not installed.
closesodoo/odoo#49732
X-original-commit: 29c362b7c3353c2be11ab117f454d04ed9853f75
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
- Activate multi-currency
Company currency: USD
EUR rate: 0.14
- Set the decimal accuracy of Product Price to 5
- Create the following invoice in EUR:
Name Qty Price Unit Subtotal
A 38.0 38.73553 1471.95
B 222.0 4083.19000 906468.18
C 35.0 49.45257 1730.84
D 1.0 17.99000 17.99
- Save the invoice
- Edit the invoice and set a payment term, e.g. 30 days
- Save
There is a difference in debit and credit of 0.01 coming from the
following:
1471.95 / 0.14 = 10513.93
906468.18 / 0.14 = 6474772.71
1730.84 / 0.14 = 12363.14
17.99 / 0.14 = 128.50
SUM = 6497778.28
But the receivable account:
909688.96 / 0.14 = 6497778.285714286 => 6497778.29
When changing the payment term, all invoice lines are recomputed.
`price_unit` and `tax_ids` are in the list of the updated fields, which
triggers the synchronization of accounting and business fields. During
this synchronization, `_get_fields_onchange_subtotal_model` is called
and recomputes the debit amount, leading to the difference.
We only synchronize if the value of the business fields have changed.
opw-2209543
closesodoo/odoo#49605
X-original-commit: 70bd2c9c7a7c8ec832edd2c158f4f61b78cdeb37
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
There is a default filter on Posted, no need to add it in the domain.
This prevented seeing draft invoices.
closesodoo/odoo#48635
X-original-commit: ca67c83e8d36ececaf97a7579c3ff2529b3e227c
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Create a demo fiscal position with automatic detection enabled and
country group assigned (ex. Europe).
Create a new Vendor with such fiscal position assigned.
Create a product in which the product category has an account which can
be mapped with the demo fiscal position
Create a new Vendor Bill, select the partner, create an invoice line,
fill in the product: no fiscal position will apply
In the process of auto detecting fiscal position the company_id may be
enforced by the context and this would conflict when the fiscal position
company is unset. Adding a default False condition fix
the issue
opw-2192733
closesodoo/odoo#46508
X-original-commit: 57a4038554b00a487bf7b176dd780192654b136a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Pretty straightforward so long as you know `current_company_id` is the
currently active company for the user, which is exactly what we need.
Task 2115472
closesodoo/odoo#41869
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
-install the POS module
-install the Contacts module
-create or use an existing partner as a customer during the pos session
-go to contacts and activate the "customer" filter
-> partners used during the pos session are not showing in the list
The problem was that the 'customer_rank' property
https://github.com/odoo/odoo/blob/d8d7635d6cf2af60791f25201a7bd1c2d5ec238b/addons/account/models/partner.py#L430
was not updated properly after a pos account move was done
Previous behavior
After ending a POS session, partners that are created and/or used
during the session are not showing on the Contacts views when the
'customer' filter is active
Current behavior:
The customer_rank of the partners is increased by one for every sale
during the pos session
Partners created or linked during a POS session are now considered
customers and appear in the contact view when the "customer"
filter is active
opw-2148894
closesodoo/odoo#41792
X-original-commit: 22874376594f94232e0c4ad5a4db3ee76f24b39a
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
-Create a random journal entry affecting the partner A, using a receivable/payable account.
-Let the journal entry in draft.
=> The amount set on the line must not be sum in the partner's amount_due.
closesodoo/odoo#36973
X-original-commit: 3ab4589ff444da9889ac922ac9d7ba6c8e8638bc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before Commit:
The statbutton on partner form does not work properly.
After Commit:
we change the domain because use the wrong domain in filter so
statbutton not work properly on partnerform.
task-id : 2041822
closesodoo/odoo#35290
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Task 1986647
With the reworking of the account_report_followup module, these variables and methods are no longer needed. Now everything is done with followup levels, with only one level by default
Also rename account_report_followup to account_followup.
closesodoo/odoo#35772
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
When making a test import for new users, there don't be present
in DB, so the computation of the customer/supplier rank will raise
an error.
Manage the case when user is not yet present in DB.
closesodoo/odoo#35955
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
To correctly choose in which account a line should be posted,
we have to know if the partner is a customer or a supplier.
Specification
=============
Keep track of the number of account moves "in" and "out"
a partner has. These counts should be based on the posted
account moves. A customer that has been created from the
'Customer' menuitem will have a rank=1. When a customer
invoice will be created for him, the generated account moves
will be taken into account to compute its rank. The most
invoices we have for a partner, the higher his rank is.
Note: To avoid any concurrent update failures on the partner,
if one transaction has already locked a partner row, the count
update will be skipped that time.
This means the values may be approximative in the database!
The exact values will eventually be correctly computed at
the next successfull try.
Known limitation of this approach: The computation ignores
the set of currently selected companies. Actually, storing
context dependent values in the database is a bad practice,
and is avoided in that case by taking all the companies into
account.
Use the stored fields `customer_rank` and `supplier_rank`
to order partners when searching by name. This allows to show
best customers or best suppliers on top.
To choose if best customer or supplier are shown on top,
the context key `res_partner_search_mode` is used.
The context key can take two values: 'customer' or 'supplier'.
This decision partially reverts/revamps 8766f38 to only use
account moves instead of PO and SO
On actions showing partners, set a default filters to menus to
only display customers (customer_rank > 0) if the string is
"Customers", and only suppliers if the string is "Vendors" or
"Suppliers".
TaskID: 2049131
closesodoo/odoo#35942
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
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>
When the many2xxx field relates to a model where company_id is required, set
this domain [('company_id','=',company_id.id)]
When the company_id field of the related model is not required, set this domain
['|',('company_id','=',company_id.id),('company_id','=',False)]
When setting the domain on a field which is in the treeview of a xxx2many field
evaluate against the company_id of the 'parent'.
Some constraints have been added on sereval models. Take a look at the complete
specification for more details.
TaskID: 2024446
Closes: #35266
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
Ivan Yelizariev