- Reactivate module
- move files in views and models dirs
- create README.rst from description
- make list of contributors
- remove change for invoice created on picking as it doesn't exist
anymore in Odoo Community
- move overrides in bank statement as logic moved in move lines
- adapt view inheritance to not depends on string attribute
- Fix definition of javascript customization in reconciliation
- Fix display transaction_ref label on move line view
- Fix move proposition for reconcile. search with transaction_ref
- Use short headers
- Update README for bug tracking
Add the field inside the group instead of after a field. In another module, I
add a button right after 'payment_term' and it must be right after it. Adding
the field in the group prevent it to be placed between the payment_term field
and the button.
In order to get visibility on https://www.odoo.com/apps the OCA board has
decided to add the OCA as author of all the addons maintained as part of the
association.
- Use the 'data' key instead of 'update_xml'
- Use the new api for account.invoice as the base model use it
- The module now depends on 'sale_stock' and 'stock_account'
- Avoid to write 2 times on the invoice by using the method that
prepares the values before the write
- Empty the transaction id of a sale order on copy
- Some cleaning
- Indent xml with 2 spaces
- Cleaning of the views
- Add the transaction ref field to the form view of the move lines
- Adapt import to fit last recomandation
- Import osv for osv.except
- pep8, pylint, eyeballing
- standardize the naming of the argument 'cr' instead of 'cursor'
- Remove the active key in the __openerp__.py
account_statement_ext -> provide profile per bank statement, remove period, choose to use balance check or not,...
account_statement_base_completion -> provide a completion rule system to fullfill the bank statement (partner, account,...)
account_statement_base_import -> provide a base to create your own file parser for each bank/office and link it to a profile
account_statement_transactionid_completion and account_statement_transactionid_import to use the transaction ID recorded in th SO
account_advanced_reconcile -> An advanced way to setup reconciliation rules on every account
account_financial_report_webkit -> some little fixes
(lp:c2c-financial-addons/6.1 rev 63)
Reconciliation model use case:
- No auto-validate
- No Match Invoice/bill fields set.
Expected result:
- The amls suggested should be as expected, i.e., do not filter for data that
is not defined in the reconciliation model.
TT52146
Related to 1db826b3c4
Backport of odoo/enterprise#64754.
This commit adds a CTE at the beginning of the invoice matching
amls candidate to speedup the whole query. More info and speedup
in PR above
Related to f396bc2f1f
Before, when using reconcile models that wanted to match invoice/bills
to statement based on the Label and/or Note and/or Reference, if there
is no real match with the statement label, the bank reco model would
mount/suggest another entry from the same partner.
This is misleading as we expect to be suggested with lines that actually
match with the statement, as stated in the reconciliation model.
Now, if any of the Invoices/bills matching rule is toggled, it will
suggest *only* matching amls. If no rule is toggled, it will behave like
before (mounting a match if any, or an aml from the same partner).
Related to 8948b31407
The orm doesn't match monetary amounts using the related currency.
It means, -208.73 != 208.730000000000002.
Let's match the amount using an sql query instead.
Related to ae848e9981
It seems some people are getting an "unassigned variable 'balance'".
This shouldn't happen with the standard code because _get_write_off_move_lines_dict is only
called from the manual reconciliation widget in which, you only have access to models having
strictly lines being percentage or fixed (see get_reconcile_modelds_for_manual_reconciliation).
This method is not called from the bank reco widget pointed by "RECONCILE x ITEMS" on the accounting dashboard.
It probably comes from some customization but I don't know which ones.
Related to 99525f8dac
Fix a decimal issue on reconciliation.
Steps:
- Set a reconciliation model with payment tolerance of 2%
- Create an invoice for $1210
- Create a bank stmt with a line for $1185.80
-> Reconciliation model is not apply
This is because of a decimal issue when calculating
the residual balance after reconciliation, leading to
the difference being 2.000000000000004% instead of 2%.
Related to d33e98b141
When the payment label is a single word, we try to match the full value and not only the alphanumeric values.
However, the matching was made on the token that was already sanitized using the [0-9a-zA-Z\s] regex.
Instead, let's match the full value.
Related to bccc0ae0e8
It can be that the name field on the account_move_line is an empty
string (as opposed to NULL). This can happen, for instance, when
generating the payment term line for Switzerland without the appropriate
fields on the company.
Since there are instances when the payment term's name is an empty
string, we can retrieve these lines and automatically match them with
payments from the bank reconciliation model. This can happen
automatically, with exact matches between a payment with a near-empty
reference (when the payment ref is just "/" or "?", this is sanitized
and ends up as an empty string for the purposes of comparison), and
these empty string payment term invoice lines.
The query that fetches the candidate lines for exact matches already
excludes those lines with a NULL move_line name, move ref, move name.
The natural extension of this behav
Related to ee22c02b1f
Making `SUBSTRING(REGEXP_REPLACE(LOWER(...), '[^0-9a-z\s]', '', 'g'), '\S(?:.*\S)*')` is costly in sql.
To avoid that, the tokens are computed python-side to avoid this extra processing.
Also, we want to avoid extra conditions on the tokens before executing the queries (and avoid it if necessary).
For example, we want to execute the query matching the sale orders only if at least one token is prefixed correctly by 'SO'.
Related to 76da4b055f
Some behavior were incorrect with reconciliation
rules:
1) Whit invoice_matching rule, no match_text_location
and no match partner set. Nothing was matching, even
by filling the right fields.
2) We were taking into account only the digits of the
payment reference of the invoice, by removing all
non digits characters. It has been decided to also
taking non digit strings from 'payment_ref' and 'ref'
into account, as long as they don't exceed one word.
Steps for point 1:
- Reco model with invoice_atching rule, payment_tolerance 0%,
no match_text_location and no match_partner
- An invoice for 100$ with name of the invoice as payment reference
(eg 'INV/2023/00001')
- A statement line of 100$ with either 'payment_ref, 'ref' or 'narration'
set as 'INV/2023/00001', and no partner
-> No match
Steps for point 2:
- Same reco model but with match_text_location_label set to True
- An invoice for 100$ with eg 'abcdef' as payment reference
- A statement line of 100$ with payment_reference (label) set
as 'abcdef' and no partner
-> No match
Related to cddea14954
* Create a reconciliation model that matches partners that have a
category `C`
* Create a bank statement and a partner that has *multiple* categories,
including C.
* Validate and reconcile
The reconciliation model you created should be used, but it is not.
Related to a0016fc6c9
Yannick Vaucher
OCA Transbot
Denis Leemann
Alexis de Lattre
Pedro M. Baeza
Stéphane Bidoul
Guewen Baconnier
Alexandre Fayolle
Lorenzo Battistini
Joel Grand-Guillaume
OCA-git-bot
Víctor Martínez
oca-ci
mymage
Weblate
Jordi Ballester Alomar