The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
Steps to reproduce:
- create two products
- create two analytic accounts
- create two new analytic rules by assigning an account to a product
- Create a new PO and select on of the product
- On the same line, change the product to the other one
Issue:
- The analytic account won't be updated
Cause:
Bypass of the `account_analytic_id` whenever there is already on defined
Solution:
For the `Sale` fix, I added the `line.state == 'draft'`.
The reason? Because the compute is triggered after confirmation of the order due to:
https://github.com/odoo/odoo/blob/14.0/addons/sale/models/sale.py#L931-L935
Therefore, the compute won't also be triggered after confirmation of the SO.
opw-2948950
closesodoo/odoo#99858
X-original-commit: 61604e18128c1cfd0e6d4e510852f780491d6e4e
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Install purchase
- Go to Settings and activate `Variant Grid Entry`
- Create a new Requests for Quotation
- Add a customer and add a product that has a variant min 2 variant
- Wizard should ask for the variant
- Select 1 variant by increasing quantity in the grid and confirm
- Confirm order
- Add again a product variant with the wizard
Issue:
Price unit is not set on the new line.
Cause:
In `_onchange_quantity` (triggered by the purchase_product_matrix
module), we do not update price unit if order line
is in state `purchase` or `done`.
Solution:
Replace condition to not perform `_onchange_quantity` if order line
has an invoice line.
opw-2956755
closesodoo/odoo#99522
X-original-commit: 8f92146b2d4996be724213345567291f045aad85
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- Create a sale order with a product that's invoiced on delivered
quantities.
- Set delivered quantity (partial delivery) and create an invoice based
on the delivered quantity. Set the "Invoice Date" to sometime in the
past.
- Go to the settings and set "Invoicing Switch Threshold" to any date
in the future (so that the invoice you created has a date BEFORE the
new threshold)
- The invoice will get the label "invoicing app legacy".
- Go back to the sales order and change the delivered quantity.
You should see that the invoiced quantity is automatically set to 0.
A similar behavior can be observed with purchase orders.
Why this is happening:
When a new “Invoicing Switch Threshold” is set, all posted invoices
before the threshold are marked as `canceled`. In v15, changing the
delivered quantities triggers the invoiced quantities to be
recalculated as well. However, computing invoiced quantities doesn't
take into account invoices that are marked as `canceled`. This mean
that the newly computed invoiced quantities won't include invoices
posted before threshold.
opw-2896797
closesodoo/odoo#98909
X-original-commit: cc979734bd7ef3f2a94b411cb7b4f3e782b7ddab
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Add a new subtype_id for 'RFQ Sent' state. This removes
the need to join on mail.tracking.value when computing
'all_sent_rfqs'. Since mail.tracking.value is usually
a big table, removing this join leads to a substantial
speedup when loading the purchase.order dashboard on big
databases.
closesodoo/odoo#96921
Signed-off-by: Arnold Moyaux (arm) <arm@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>
The user executing the test is changing the UOM
while the field was invisible because the user
did not have the multi uom group.
Therefore, add the group to the user for the test
so the field is visible in the form.
This is related to revision
odoo/odoo@5ccc32fcf7
```
2022-07-12 11:59:39,526 22 ERROR master odoo.addons.purchase.tests.test_purchase: FAIL: TestPurchase.test_with_different_uom
Traceback (most recent call last):
File "/home/odoo/src/odoo/master/addons/purchase/tests/test_purchase.py", line 268, in test_with_different_uom
po_line.product_uom = uom_dozens
File "/home/odoo/src/odoo/master/odoo/tests/common.py", line 2179, in __setattr__
assert not self._get_modifier(field, 'invisible'), \
AssertionError: can't write on invisible field product_uom
```
closesodoo/odoo#95841
Signed-off-by: Denis Ledoux (dle) <dle@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>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This allows to create a purchase.order record without
the need to call the onchanges to set the suggested packaging
and quantity.
For instance, this makes easier to create purchase orders
with suggested packaging using XMLRPC.
closesodoo/odoo#95306
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
If we use the auto-complete feature to add PO's lines to an bill or we select multiple PO's then use
'create bill' button, the generated invoice line will copy the sequence line from the PO's line. This
can lead to situation where we will have all the first lines of each PO then all the second, etc, ending
with a mix of all PO's in the bill.
Example:
Purchase order 1
- seq 10 line A
- seq 11 line B
- seq 12 line C
Purchase order 2
- seq 10 line A'
- seq 11 line B'
- seq 12 line C'
Invoice created from those PO's
- seq 10 PO1:line A
- seq 10 PO2:line A'
- seq 11 PO1:line B
- seq 11 PO2:line B'
- seq 12 PO1:line C
- seq 12 PO2:line C'
After this PR this PR the lines from the same PO's will be contiguous like:
Invoice created from those PO 1 and 2
- seq 10 PO1:line A
- seq 11 PO1:line B
- seq 12 PO1:line C
- seq 13 PO2:line A'
- seq 14 PO2:line B'
- seq 15 PO2:line C'
opw-2749682
closesodoo/odoo#95343
X-original-commit: cafe5c1aff1ca1632ce4924a6b027629c283a5e9
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Beckers Thomas (tbs) <tbs@odoo.com>
This commit contains the following:
1) Added sudo to product record when adding supplier info during PO confirm, so that
supplier info is created regardless of who is confirming the PO.
2) the test test_multicompany_partner_bank was removed since it was creating two
res partner banks with the same partner and setting company_id to two seperate companies
while currently the company_id is related to the company partner thus this can no longer
happen.
3) test_message_qty_already_received was changed to not set the company_id explicitly as
it caused unexpected cache miss in the runbot.
task : 2764771
Part-of: odoo/odoo#91640
Step to reproduce:
Install purchase
Create a purchase order
Set a vendo and a product that has this vendor in its
vendor list
Set a product name in the line of the vendor in the product
purchase section (you will need to add the field)
Change the description of the product
Change the quantity of the product
Expected behavior:
The description stay the custom input you just set
Current behavior:
The description is reset to its default value
Explanation:
When changing the quantity the vendor from the product vendors can change.
Then its vendor product name and code can change and thus the default
description in the purchase order. To solve that we need to differentiate
a custom description from a default one and only update the descritpion
when the quantity changes if the descritpion is a default one (and not a
sutom one)
opw-2827667
closesodoo/odoo#90923
X-original-commit: 96bbe252ecbb94600632a1a5cb449b8d2810d2c0
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Fixed the TestPurchaseInvoice.test_double_validation and the setupClass
to use test accounting data in setupClass instead of the demo data.
closesodoo/odoo#89370
X-original-commit: a7546aead36c5d56809fcd9c46b2a552991b5449
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
How to reproduce the bug ?
- install the accounting, contacts and purchase apps
- create several companies and enable the checkboxes of all
these companies
- create a new contact and add a bank account for each company
- switch to a company different than the first one
- create a request for quotations in the purchase apps and
confirm it
- in the accounting app, create a new vendor bill and use the
auto-complete field to select the RFQ created earlier.
The bug:
When you try to create a vendor bill from a request for quotations,
the recipient bank is wrongly chosen. Because of that, there will be
2 issues. The first one is when you want to create the bill from the
RFQ: you will get an error and the invoice won't be created. The second
one is when you create an invoice then use the auto-complete field. In
this case, there won't be any error but the recipient bank will
be wrong.
opw-2731264
closesodoo/odoo#86078
X-original-commit: 074fee2e19547f4145ae0aa93d68741ab4aa9bae
Signed-off-by: Adrien Minet <admi@odoo.com>
Signed-off-by: Minet Adrien (admi) <admi@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
When consulting the Purchase Analysis, the measure "Days to Confirm" may
not be easily understandable
To reproduce the issue:
1. Create a purchase order PO:
- Order Deadline: <today + 10 days>
- Add 2 products
2. Confirm PO
3. Purchase > Reporting:
- Measures: Days to Confirm
- Group By: Order
Error: For PO, the value of "Days to Confirm" is -20, it should be -10
The report computes the sum of the delay (i.e., "Days to Confirm") of
each purchase order line. Computing an average seems more relevant
A similar flow could be reproduce with the measure "Days to Receive"
(i.e., the difference between the Order Deadline and the Receipt Date)
OPW-2678673
closesodoo/odoo#81053
X-original-commit: da3fa1f8887e06e7a86e761ef844f79cc0d06e6f
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Reproduce :
1. Add a default analytical rule: if Coin Gourmand partner then Administrative analytical account
2. Create a PO at the Coin Gourmand supplier, add a product, and select the Internal analytical account.
3. Bill for this product.
Result :
Internal analytical account has disappeared from the invoice line. It has been replaced by Administrative.
Issue :
AccountMove.create() computes an account in the move and this causes the analytic account to be reset at its default value from the rule.
Fix :
Since the account pocalypse in 13.0, account.move is making magic things during the creation of the invoice to create dynamically the invoice lines like account.invoice did before this huge refactoring.
The create is making a 'New' record to simulate the onchange but this code is a hack triggering unexpected recomputation like the analytic account.
To avoid that, we ensure to assign the minimum number of fields to preserve fields like the analytic account.
closesodoo/odoo#79321
X-original-commit: 876e2d1073312fe65cb6b2e3038235aeaa082c8a
Related: odoo/enterprise#22074
Signed-off-by: Laurent Smet <las@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
- Fix typo in accrued_orders.py
- Remove fields.Date.today() from purchase test
- Make more use of common resources
closesodoo/odoo#79159
X-original-commit: 31570e185dcb36145e28e42cda765284dc373294
Signed-off-by: Laurent Smet <las@openerp.com>
* order lines are now not grouped anymore by account. That allows a more detailed label on the accrual entry line, as it's now directly related to a single order line
* we now create a single accrual entry counterpart, instead of one per order previously. That reduces the 'noise' in the accrual entry, at the cost of not having the sum per ordre anymore easilly but it doesn't seem to be important to audit that account
closesodoo/odoo#76037
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This allows to solve the following use case:
* we are in March
* a SO created during January shows currently a delivered quantity (timesheet on service or delivered goods on storable products): timesheets/pickings were done in February
* creating the accrued entry for January 31 should display accordingly an amount of 0 by default since everything was done in February
Invoices invoice_dates are also taken into account:
* day 0 : delivered 10
* day 2 : 5 invoiced
* accrued entries for 10 if accrual date = day 1, accrued entries for 5 if accrual date = day 3,
followup of task 2255642
closesodoo/odoo#75886
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
A new field on tax groups makes it now possible for this group to be displayed under a subtotal label. If not set, this defaults instead to "Untaxed Amount", keeping the traditional behavior. This is intended for withholding taxes, which can now be implemented with negative taxes and a tax group with this field set.
To do that, this commit entirely refactors the way amount_by_group worked, and replaces it with a more complete json field called tax_totals_json. It also streamlines the way taxe totals are displayed on invoices, PO and SO and makes it so that a common code is called instead of copy-pasting the same block 3 times as before.
[IMP] purchase: always display tax totals by groups on purchases orders
Before, tax totals on purchase.order's form were not shown by group, and were instead all aggregated in a single "Taxes" category. The same went for the pdf export. The portal view, though, did show the totals by group. We now display the tax groups in the same way all the time.
closesodoo/odoo#74138
Task: 2457374
Related: odoo/enterprise#19802
Related: odoo/upgrade#2670
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
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>
When the Product Price precision is greater than the currency precision,
it can lead to incorrect data
To reproduce the error:
(Enable debug mode)
1. Settings > Technical > Database Structure > Decimal Accuracy, edit
Product Price:
- Digits: 3
2. Create a PO
- Add a product:
- Quantity: 12
- Unit Price: 0.001
3. Save, Confirm, Edit the PO:
- Qty Received: 12
- (Note that the total is $0.01)
4. Create a bill:
- Add the PO to the field "Auto-Complete"
Error: The unit price is $0.000 and so does the total
The rounding of the unit price should be based on the Product Price
precision, not the currency precision.
OPW-2601867
closesodoo/odoo#74813
X-original-commit: 1123856c77cce4b69059b63c2bcbb382c7f0719e
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
When adding several PO to a bill, if they don't have the same currency,
it will lead to incorrect amounts
To reproduce the error:
1. In Settings, enable "Multi-Currencies"
2. Invoicing > Configuration > Currencies:
- EUR: Active, Current Rate = 2
- USD: Active, Current Rate = 1
3. Create a PO:
- Currency: USD
- Products:
- One product, no taxes, unit price 1000
4. Confirm PO
5. Edit PO:
- Qty Received: 1
6. Repeat 3 -> 5 with EUR instead of USD
7. Open a new Bill
8. Add the first PO to the field "Auto-Complete"
9. Add the second PO to the field "Auto-Complete"
Error: Both invoice lines are now expressed in EUR and both subtotals
are equal to 1000 even though the exchange rate isn't 1
This commit suggests not to change the currency of the account move if
the latter already has some AML. Moreover, the amounts must be converted
if they come from a PO that uses another currency
OPW-2573748
closesodoo/odoo#73483
X-original-commit: b299e880417026688b2fbde23307bd011de8c44d
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
On a product form, if the purchase UoM is different from the default
UoM, this will lead to an error when creating a RfQ.
To reproduce the error:
(Need stock)
1. In Settings, enable "Unit of Measures"
2. Create a product P:
- Cost: 100
- UoM: Units
- Purchase UoM: Dozens
3. Create a RfQ:
- Add P
Error: The quantity is 1 and UoM is Dozens, however the unit price is
$14400. The ratio has been applied twice.
When setting the product, an onchange method computes the unit price.
However, the computation is wrong: it first converts the product's
standard price using the purchase UoM of the product. Then, it converts
the result, this time using the UoM of the PO line.
OPW-2519294
closesodoo/odoo#72139
X-original-commit: b37a13d7763e4a69695fdb1567dce5d0f69ff78a
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
1. add packaging to PO lines
2. packaging on PO/SO lines can be propagate to MO
3. add package type to packaging
4. on picking types, we can choose to only reserve full packaging. That
means if you want 1 pallet(100 units) and you have 50 units in stock. It
won't be reserved.
5. suggest suitable packaging for PO/SO/MO line according to the product
qty
Task-2357259
PR #68654
UPG PR odoo/upgrade#2444
For customer invoices:
* do not set default date because if you prepare an invoice (and it gets
a default date), then validate it the next day, the date will be wrong
* set the date when posting if it wasn't set, because why not?
For vendor bills:
* do not set default date because you rarely encode a bill at the bill
date. Forcing the user to enter it reduces risks of user error
(duplicated vendor bill)
* do not set it when posting, same reason.
opw-2492862
Related #68368Closes#68367closesodoo/odoo#69639
X-original-commit: 41041d8016d11f017d92d28f32ab2cf42f1349a9
Related: odoo/enterprise#17866
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2301180m
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon bec
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts
- is run sometimes at-install.
--task: 2301180
1. Show only date not datetime on update portal. When update the
scheduled date, set it to be the last minute of that date.
2. Send updated date immediately when user pick a date.
3. If an activity for update the date already exist, update the
note instead of creating a new one.
Task #2265912
PR 52809
Some change to imporve reminder mail usability:
1. Scheduled date on POL of the PO form now is always editable.
2. Improve tooltip for the reminder email
3. don't show number of days when reminder email not checked on
both PO and partner form.
4. only show "confirm receipt date" button in debug model
5. In the mail, format date by partner.lang
6. Add button to send preview reminder mail
7. On default, receipt_reminder_email on res.partner is False
8. merge expected_date with date_planned (done by FP)
Task 2265912
PR #52693
1. automatically send a reminder mail to vendor to confirm the receipt
date. If confirmed, (confirmed by vendor) will be added next to the
receipt date. If not, vendor can update the date on the portal website.
An warning activity will be set for the purchase representative for this
update.
2. Vendor can also comfirm recieption of the PO when we 'send PO by mail'.
If confirm, (confirmed by vendor) will be added next to the confirmation
date. An filter is added in the PO search view to show all unconfirmed
PO.
Task 2230811
PR #49921
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Adds "Expected Date" and "Effective Date" fields to purchase orders to
match what exists in sales orders. "Effective Date" mirrors sales logic
(= first completed stock move). "Expected Date" has simplier logic due
to simplier nature of receiving stock vs shipping (= earliest "Scheduled
Date" of all PO lines). Form view has been updated to include these new fields.
Additionally code was changed to not have PO 'order_line.date_planned' be
overwritten by the 'purchase_order.date_planned' value. Previous behavior
was both confusing and made it so info was lost. Also logic for related
stock move picking line expected date values has been updated to now consider
'purchase_order.date_planned' value if set. Related changes include:
- not overwriting when PO is edited+saved (this only occurred in write()
logic, not create() which caused inconsistent behavior anyways.),
- updating related tests,
- removing PO line date_planned editing restriction when PO date_planned
is set
- updating of relevant stock moves/picking expected date due to
PO.line.propogate_date = True ('purchase_order.date_planned' if
exists, otherwise 'order_line.date_planned')
This change also includes some small related improvements:
- Removal of outdated code comment.
- Addition of Help strings to better explain fields.
- Prevent copy of 'date_planned' value into new POs (now mirrors sales
logic).
This change corresponds to "Receipt Date on PO's" subsection of Purchase
KPIs task.
Task #2198420
========
Purpose
========
Currently, purchase missing some billing functions that we have in sale
invoicing:
- Create credit note when necessary
- Create vendor bill in batch in list view
========
Spec
========
- In case of retures, when create a bill for a purchase order, we check
the total amount we want to bill to decide whether it's a vendor bill or
a credit note.
- In the list view, add a new action to create vendor bill/credit note
for all selected order.
========
Links
========
Task 2170715
PR #44210
Related: odoo/upgrade#919
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The 'vendor bills' stat button on purchase order, once clicked, will
have a specific behavior depending on the invoice count :
0 : open a new invoice with pre filled fields (not saved yet)
1 : open the form view of the invoice
2+: open the list view of the invoices.
Before this commit, the invoice count was computed with an environment on
the current user. That means a record rule could make the invoice count
lower than the real count and so give an unwanted behavior. Ex: create a
new invoice even if there is already one created because the user cannot
see the other people's invoices.
After this commit, the action_view_invoice with make an explicit read()
in database to fill the cache with all the purchase order's invoices and
make sure the count is the real one.
Task : 2206969
closesodoo/odoo#48274
X-original-commit: e3101d92187946b2bd539e05956e4e83cd9c9097
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this patch, the purchase users get an access violation error
at the invoice creation from a purchase order. This was due to
some missing ACL between v12 and v13.
Task : 2206969
X-original-commit: 4c4fb33e4bbc78a85ad309baf5df906cf16566ea
if product have taxes and taxes_id field is empty
then it will fill the 'taxes_id', so price_total field
have taxed Total.
Task- 2093205
closes- #41681
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
**Steps to reproduce**
* Define "Purchase Order" sequence for using date ranges checking "Use subsequences per date_range".
* Change sequence prefix to "PO/%(year)s/".
* Create a purchase order with order date in 2020 (a different year than current one).
**Current behavior**
Got a purchase order with 2019 (current year) number.
**Expected behavior**
Got a purchase order with 2020 number.
closesodoo/odoo#38468
X-original-commit: ce423e6adb6659a1d5885bad158c59b882cb4565
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
