When reconciliating manually, it may be possible to filter between
`All`, `Customers`, `Suppliers`, `Others`.
When changing this mode, we could end up in a situation such as:
1)
- reconciliation widget X is available
- reconciliation widget line XB is being loaded
- mode is changed -> reconciliation widget X is removed
- reconciliation widget line XB loading finishes
-> error because the parent reconciliation widget exists no more.
2)
having no (or less than the expected) or too few results because
removing reconciliation items (when for example we switch from supplier
to customer mode) can be done asynchronically. But the code expected it
to be done synchronically. Also all elements displayed were removed
instead of only the ones of other types.
thus instead of displaying the expected number of reconciliation items:
MIN({num of record to display}, 10)
the records displayed were:
MIN({num of record to display}, 10 - {num records displayed before})
which could amount to 0 event if there was thousands available ones.
This commit solves these two issues:
1) by not adding line to a reconciliation item without error,
2) by counting and removing displayed items correctly
opw-725796
opw-728309
Fine tuning of this commit: 69c41c7
When cancelling a payment, the remove_move_reconcile function was called and
it removed the payment from the invoice and in the payment history, only the
validated payments were kept.
This commit keeps the behavior before this commit: 69c41c7
opw:691692
The css clear was using jquery ui class for enterprise which now may
not be available on the given part. This commit replace it with class
defined in account_reconciliation.
With this the style could have issues such as not displaying the
congratulation message after reconciliation.
fixes#14743
In the reconciliation widget, create a counterpart line. No domain is
applied on the "Account" field regarding the company, meaning that we
can select an account from any company.
opw-694149
For the field "tax_ids", a command must be written in the the returned dictionary.
In this way, the ids of the tax will be set on the account move line.
opw:689806
Change color #a24689 to #875A7B
Commit https://github.com/odoo/enterprise/commit/8ac1c19fac7615fecd51e670f798d13158a4e53c
changed the odoo interface violet by changing the main LESS variable
but forgot there was many direct occurences in XML/HTML/... (for
example for the mobile browser color).
Even if it's community the odoo interface violet is used at many places
(module description, XML demo data, ...).
An issue arises in the following use case:
- Company rounding policy in "round globally"
- Tax excluded of 20 %
- Create a statement of 3.80 EUR
- Reconcile the statement thanks to the reconciliation widget
- Click on "Choose counterpart" in order to manually create a line to
reconcile with the 3.80 EUR statement
- Add an amount of 3.17 EUR, and choose the 20 % tax
The widget creates an extra line of 0.00EUR . This is because the
remaining amount is 0.004.
The reason lies in the `monetaryIsZero` function. There is a hardcoded
decimal precision of 4, while it should be 2 for EUR.
We add an extra parameter to the function so it is possible to adjust
the decimal precision required. Only the problematic calls are modified
to avoid unnecessary intrusive modification.
Closes#13452
opw-688399
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
========
Purpose
========
The graphs on the accounting dashboard give the impression that we had $0 in the bank because the graph is at the bottom of the kanban kard.
==========
Specification
==========
The bottom should be zero, the top should be the maximum of the visible period, and the rest of the graph should be proportionate.
* This new button is a behavior change, but this is needed for big databases with a lot of statement lines to process. Indeed, in that case we prefer to load the widget as soon as possible and thus let the user process the lines manually or click on that button (but at that time he knows why it takes time).
* Opimization of various method in order to speed reconciliation and view opening : added indexes, direct use of sql queries...and also removed the code that was looping on open debit/credit to propose a sum of entries to match the statement line's amount, because it was a little greedy and wouldn't give accurate results most of the time.
In the account invoice the payments are shown and a popover with more
information is displayed when clicking on an (i) icon.
In this popover two buttons are available, but the used type of popover
disappear immediately when clicking on them, thus the buttons were
directly removed and would not work.
This commit add a delay when hiding the popover so the buttons
functionnality is not lost.
opw-680095
Currently there is a selection field 'account_type' on the
account.analytic.account model with 2 values : Active or Archived
Let's use an active field instead and add a Archive stat button on the
form. That way, we can remove all the domain ('account_type','=','normal')
which are implicit with the generic active field behavior
A similar protip has been added in the enterprise 'account_reports' module.
We took this opportunity to rename the class protip into o_protip and to apply
this kind of style with standard attributes and classes + to correct typos
Since monetary values are stored as float, use the method intented for float
comparison using the maximum number of digits a currency can use.
Until V9, the number of digits used was fetched from table decimal.precision,
but as of V9, the accounting module stopped using it in favour of the digits
number defined on currencies.
It is using an already existing field that wasn't used anymore ('account_type') but as a lot of domains on analytic accounts were
- wrong (still using old fields state and type that have been removed as well in the same commit),
- or defined directly in the views
so, an update of some modules may be needed in order to avoid further problems.
This commit was necessary to fix weird problems in 9.0-nightly.
Phantomjs and the old nvd3 implementations did not play well together.
* transitionDuration() replaced by duration()
* tooltips() & tooltipContent replaced by tooltip.enable and tooltip.contentGenerator
* remove useless less for tooltip
Thanks to mge for his help
The only difference between payment matching and reconciliation is that
in the former the reconciliation was already made while in the latter we
do it at bank statement reconciliation time.
So they behave the same in the interface except that partial reconciliation
is not proposed for payment matching.
Nicolas Lempereur