[14.0][ADD] account_reconciliation_widget #359
Conversation
|
Works OK on a first functional test, although it's very weird all the suspense account + post thing. |
| "company_ids": self.mapped("company_id").ids, | ||
| } | ||
| action_context.update({"suspense_moves_mode": True}) | ||
| action_context.update({"statement_line_ids": ids}) |
There was a problem hiding this comment.
Why use update if you are instantiating the dictionary 2 lines up?
action_context = {
"show_mode_selector": False,
"company_ids": self.mapped("company_id").ids,
"suspense_moves_mode": True,
"statement_line_ids": ids,
}
|
|
||
| :param writeoff_vals: list of dicts containing values suitable for | ||
| account_move_line.create(). The data in vals will be processed to | ||
| create bot writeoff account.move.line and their enclosing |
| "&", | ||
| ("name", "!=", "/"), | ||
| ("name", "ilike", search_str), | ||
| ] |
There was a problem hiding this comment.
I know Odoo never tackled these types of things but the use of ilike can give significant performance hits on large tables. Even more ilikes in the same domain will probably never even return a result.
There was a problem hiding this comment.
I agree about this domain performance... but here it returns desired lines and has been a long time without reported issues. Also, this function can be easy overrided in a custom module.
There was a problem hiding this comment.
@PieterPaulussen This is not really true except for in a very basic untuned postgres installation. pg_trgm is a longstanding solution to openended ilike searches and any integrator who deals in mid sized tables of a few hundred thousand to a few tens of millions will already be monitoring for these and adding appropriate indexes.
The killer in that query with large tables will be more likely the generated IN clauses in non specific searches.
There was a problem hiding this comment.
A trigram index is indeed a good solution in some cases. Unfortunately just adding indexes won't suffice when account.move.line grows even further to roughly 2.5 billion records as we have in of our long running projects.
We solved the 'where id in []' issue a couple of years ago by changing the clause to use a custom stored boolean flag. However, even with that implementation, it was insufficient.
If I remember correctly it was the join operations from AML with account.move and account.account which were even worse.
In the end we replaced the search box with a more elegant solution allowing users to search specific fields with different operators according to their needs.
There was a problem hiding this comment.
@PieterPaulussen OK but that is not typical of any Odoo installation. Extreme outliers in terms of pushing Odoo have always had to rewrite those parts themself. To have that many move lines you have already done extensive customizations, changing the column type of id field, support for either BIGSERIAL or GUID style identifiers. Realistically, to have over 2.5bn records of just the small band of narrow accounts this is pre filtered to, that is way outside normal use.
There was a problem hiding this comment.
Agreed, but I found it at least noteworthy to mention the issue on the PR.
If Odoo keeps growing at their current rate, its only a matter of time before supporting large datasets out of the box becomes mandatory. For OCA modules, should we not try to take it into account as much as possible when we can clearly foresee these types of issues? Solving this uniquely for each customer puts a heavy strain on project budgets, and might push customers away from the ERP.
Thanks for your comments though, you do make a good point.
There was a problem hiding this comment.
If you have any suggestion for solving the performance bottleneck without losing features, please propose it as a new PR.
|
Let's go with this as there are no more comments. Other later PRs can improve anything discovered in real tests: /ocabot merge nobump Thanks @ozono for the hardest work. |
|
On my way to merge this fine PR! |
|
Congratulations, your PR was merged at 26ca324. Thanks a lot for contributing to OCA. ❤️ |
|
@randall-vx ACK. Thanks a lot. Regards. |
|
Thanks for this big work on account_reconcile_widget!
|
|
I'm facing another issue: as you can see in the screenshot above, I have a button "Frais bancaires" (account.reconcile.model). This button has type = 'writeoff_button' and 1 account.reconcile.model.line configured as 100% on an expense account. When I click on that button, nothing happens. Do you face the same pb ? |
|
Remember that the field 'name' of account.bank.statement.line became 'payment_ref' in odoo v14. This is certainly the cause of the first issue I reported. |
@alexis-via Did you find a solution for this problem ? |
|
@moaadbourhim No, because I haven't tried to fix it so far. But we really need to fix it now. |
|
#372 fixes the behavior with reconciliation models of type |
|
@pedrobaeza @alexis-via You can see that in the images Choose for example Asustek - Wood Corner in analytic account :
Check the Cost and Revenue of this Analytic Account :
The list of cost and Revenue :
|
First working alpha version.
Please review and send your comments.
Known issues: