Task 1930403
Purpose:
A suspense account is an account in the general ledger that temporarily stores any transactions for which there is uncertainty about the account in which they should be recorded. Once the accounting staff investigates and clarifies the purpose of this type of transaction, it shifts the transaction out of the suspense account and into the correct account(s). An entry into a suspense account may be a debit or a credit.
The Chosen Odoo approach (macro) for this case is
1) from bank statement -> reconciliation widget -> reconciliation model
2) create move that have a dedicated checkbox
3) be able to reopen the bank statement line "like if there is no linked account move" and finally reconcile the transaction with the good invoice/bill (we can reprocess account move "to check")
4) when we reprocess, Instead of creating an account move : Check if there is an "to check" existing linked account move and remove all the account move lines then replace them by the good ones --> we want to keep the sequence
closesodoo/odoo#30486
There is nothing preventint to remove this line
The second FIXME is preserved to keep the tests running, as the account functionality of the function may be removed
closesodoo/odoo#30323
purpose:
when creating a writeoff from the manual reconciliation widget (invoices & payment matching), there's no way to specify the date of the writeoff journal entry
specs:
in v12, add a date field in the js and set the date of the writeoff entry accordingly
Was PR #29794
Was OPW 1896593
closesodoo/odoo#30676
OPW 1929160
A filter prevented from selecting a partner in the reconciliation widget if it had a parent company but a company with a parent company should be selectable
closesodoo/odoo#30270
Create a vendor payment of 100€
Create a bank statement line with an amount lower than the payment
Open bank reconciliation view
Reconcile the bank statement line with the blue line of 100€, the triangle for partial reconcile appear.
Current behavior:
If you click the triangle, you can reconcile this payment with the statement line but it becomes unbalanced.
Expected behavior:
The triangle should not appear.
Fixes odoo#29654
closesodoo/odoo#29718
to ControlPanel/Search view refactoring.
The ControlPanel being now inside the DOM of client actions, those
existing widgets needed to be adapted (in the way they define if
and how they want a ControlPanel, and in the way the manipulate
their DOM as it slightly changed). Tests needed to be adapted as
well.
Part of task 1893568
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
In case there is a large amount of data to display, the 'Manual
Reconciliation' widget suffers from high CPU consumption, and therefore
slowness.
This is mainly due to the line rendering (function `_renderLines`).
Indeed, unlike the 'Bank Statement Reconciliation' widget which
retrieves the data partially, the 'Manual Reconciliation' widget
retrieves and renders all the data. No offset is implemented in this
case, neither for data retrieval nor rendering.
With this commit, we implement a partial rendering of the data
retrieved. This means that all data are fetched when loading the widget,
but only a part of it is rendered. We make use of the existing 'Load
More' mechanism to display more data. By default, 30 accounts or
partners are loaded.
By combining this with PR #28958, we aim to make the widget more usable
for large data volumes.
opw-1903575
closesodoo/odoo#28959
Before we could only make a partial payment that was equal to the value of the statement line if the payment was greater than the statement line.
Now we can modify the value of any line (black line) used in the statement reconciliation widget. This allow to have the following:
Statement line of 500
Payment 1 of 500
Payment 2 of 500
We can reconcile the statement line with 250 from payment 1 and 250 from payment 2.
Task: 1870895
closesodoo/odoo#27805
Install the accounting module, create a new payment for a customer
go to payment matching, reconcile the payment for the account
'Account recievable' and select a tax. There is a traceback
because of a incomplete implementation of the tax computation.
This commit complete the implementation and add the missing tests.
opw-1903172
closesodoo/odoo#28591
This rev. introduces robust helpers to use in the JS tests suite to
interact with DOM and components, and starts using them (almost)
everywhere.
All the helpers are exposed though testUtils.js.
There are 2 kinds of helpers:
1. Assertions
-------------
* assert.containsNone, containsN, containsOnce check that the DOM
(or a specific part of the DOM) contains a `selector`. It
generates a correct error message automatically.
ex: assert.strictEqual(form.$('.o_form_editable'), 1, "msg");
-> assert.containsOnce(form, '.o_form_editable');
* assert.isVisible, isNotVisible check that the DOM has an element
visible or not. They also check that the element is actually in
the DOM (before most tests didn't verify this).
* assert.hasClass, doesNotHaveClass, hasAttrVAlue, check specific
properties of a DOM element, and also validate that it is
applied on a single existing DOM element (before most tests
didn't verify this).
ex: assert.notOk(form.$('button').hasClass('btn-primary'));
-> assert.doesNotHaveClass(form.$('button'), 'btn-primary');
2. Utilities
------------
The goal of the utilities is to centralize the definition of many
standard components and interactions, ensuring that when we
refactor the JS framework, we do not need to change all the tests.
Existing mock utilities (addMockEnvironment, intercept, path,
patchDate, unpatch and fieldsViewGet) are moved to
'testUtils.mock.*'.
Existing DOM utilities are moved to 'testUtils.dom.*'.
New dom utilities are created for opendDatePicker, click,
clickFirst and clickLast. Helper `click` verifies that there is
exactly 1 element visible in the DOM you click on, `clickFirst`
and `clickLast` verify that there are more than one element on the
DOM.
ex: form.$('button').click();
-> testUtils.dom.click(form.$('button'));
New Form utilities: (testUtils.form.*)
clickEdit, clickSave, clickCreate, clickDiscard, all clicks on
the control panel buttons of the form.
`reload` reloads the form data.
New modal, graph, kanban and pivot utils (testUtils.pivot.*,
testUtils.kanban.*, etc.).
New fields utils: (testUtils.fields.*)
* editInput, editSelect: allow to change the value of a field,
using a selector to identify it. They validate that the input
exists and trigger the change event automatically.
* editAndTrigger: allow to modify a field and trigger specific
events after the value change
* many2one (testUtils.fields.many2one.*)
clickOpenDropdown, clickHighlightedItem, clickItem,
searchAndClickItem: use a field name instead of a selector and
do all the complex mechanism to open, filter and highlight
many2one fields.
Joint work with aab, dam, ged, mge, svs and vsc.
Bank statement lines need to be matched with entries; We have to automate this operation as much as possible.
At the same time, create an algorithm that fit everyone needs is quite impossible.
For that reason we will let users choose the rules they want with the improvement of reconciliation models.
Note that we did it only for bank statement reconliation, not for manual reconciliations.
Was task: 1877375
Was PR #26669
Remove part in service_mixins who hide this error. Queries must be able
to be canceled for better performance. Also in the case of longpolling,
if the request is not canceled, wait for a server message or the maximum
time (30 sec) to add or delete channels.
Suggestions made to reconcile bank statement lines are now more accurate (based on communication and amount)
There's no automatic mode anymore (button + <CTRL+ENTER> shortcut removed)
Partners are set automatically when selecting a line in the widget (that will help the creation of a res.partner.bank for him, for a better partner detection next time)
Was task: 1847703
Was PR #25438
Have a statement line with multiple pages of propositions
Go to the last page
Add everything
Before this commit, after clicking on the last item of the list,
a write-off creation was displayed, without any means to come back to the other
propositions
After this commit, we display the page before
In manual reconciliation, have an accound with no direct proposal.
An empty line should be present
Click on it
Before this commit, there was a traceback
After this commit, a write-off creation appears
In manual reconciliation (but probably automatic too)
Have 3 lines for one account
2 of them are balanced
the third is of an amount X
Add the three lines to the reconciliation
A write-off proposal of -X should appear
Now, remove the third line by clicking on it
Click on Reconcile
Before this commit, the values sent to the server were wrong, as the write-off
was still included
After this commit, we make sure we don't send lines that are not displayed
Have two invoices
Make a bank statement with one line, which amount is:
Amount[Bank] < Amount[Inv1] + Amount[Inv2]
AND
Amount[Bank] > Amount[Inv1]
Click on on the reconcile button on the form view of the bank statement
On the reconciliation widget:
Click on the first invoice to fully reconcile it with the payment
Click on the second to partially reconcile it with the payment
Before this commit, there was no way to let the second invoice open
and partially reconciled.
The only possibility was to make a write-off
V10.0 allowed to to do such a flow
After this commit, this use case is dealt with again
OPW 1864689
closes#25721
- JS Modals were not correctly built anymore, their .modal-body element
was duplicated and many without-effect JS lines were introduced (as a
side effect, the form view design was broken when inside modals)
- Tests were changed to make bugs go unnoticed. For example, the media
dialog functionnality was entirely broken because the .modal-dialog
element was not receiving the correct class anymore.
- The JS translation function is _t, not _
- Do not use the <title/> tag as a regular DOM element, it is meant to
be unique, in the <head/> section
- CSS rules were added to the utils.scss file, which is meant to contain
functions and mixins, otherwise, the rule is duplicated in every asset
- Some icons were still broken, as missed by https://github.com/odoo/odoo/commit/f90cf060a3cfeb37a67bec83264c0aaab8892b56
- Tests were changed to use [role="dialog"]/footer/header in their
selectors without any reason, this commit restores some of that to
avoid rebase conflicts with the BS4 work.
- ...
Note: other elements should still be discussed, like the direct use of
the 'o_form_label' class in views definition... but those do not cause
direct problems.
Christophe Simonis