PMIS Account Reconcile OCA - Reconciliation Assistance
Table of contents
Reconciliation filters
This module adds Posted and Posted + Not Reconciled statement-line search filters. The journal reconciliation action and the reconciliation action opened from a journal entry default to Posted + Not Reconciled. These are removable search defaults, not access restrictions.
The All and To Check actions retain OCA's behavior. In particular, already reconciled lines awaiting review remain visible in To Check.
Partner-dependent candidate filters are provided by the dependency account_reconcile_oca_add_default_filters. When a statement line has a partner, OCA defaults to that partner and Trade Payable OR Trade Receivable OR Outstanding Payments/Receipts. The outstanding-payment filter selects payment-linked journal items on Current Asset accounts. PMIS also activates these defaults for an unassigned card entry with a usable remembered-merchant mapping, as described below. Without an assigned or suggested partner, these defaults are inactive. PMIS extends the candidate widget context and refresh behavior while retaining OCA's reconciliation engine.
Partner alignment on reconciliation
When a statement line has no partner, successful reconciliation fills it from the matched journal items if they identify one partner. The statement's journal entry and liquidity item are synchronized through OCA's normal partner update. Existing partners are preserved, and matches involving different partners leave an empty statement partner unchanged. For a manual counterpart without matched items, a single selected partner is used instead. Partners must be shared or belong to the statement's company.
This applies to all payment categories, both reconciliation modes, and automatic reconciliation. Selecting candidates alone does not assign a partner; the update happens only after reconciliation succeeds.
CAMT reconciliation assistance
The CAMT importer preserves structured additional remittance information, proprietary bank codes, and mandate IDs. Additional remittance becomes the label when the parser has no meaningful label; existing labels and payment references remain intact. CAMT Remittance, Card Merchant, and Payment Category are visible beside the partner selector in Manual operation. Bank codes, mandate IDs, and backfill provenance remain in Other Info.
Enable Structured CAMT Payment Hints on the bank journal before importing files from a bank using the following profile. The option is disabled by default; these proprietary conventions must not be assumed for every bank:
DP01 with an EL- remittance prefix identifies a card transaction. The merchant is taken from the description before the final comma and location. The structured bank recipient and its account are retained in the imported notes, but are not used to identify the merchant. Processor-prefixed merchant names can be resolved using explicit OCA partner mappings.
A debit with code NOTPROVIDED and the exact description Plačilna transakcija s SEPA direktno obremenitvijo identifies the confirmed direct-debit transaction fee. Descriptions matching Nadomestilo za ... paket identify package fees. Other descriptions and credits do not become bank costs merely because they share the code or amount.
Other payments remain separate, including direct debits with mandate data. A missing partner is independent of the payment category.
With the profile enabled and CAMT remittance present, partner lookup requires a unique exact account, case-insensitive full partner name, or an applicable explicit OCA mapping. Card transactions use the extracted merchant name, not the structured bank recipient. Matching respects the statement company and shared partners; ambiguous matches remain unassigned. Explicitly assigned partners are preserved. The profile does not create partners, assign expense accounts, or enable automatic reconciliation.
Use Bank Costs, Card Payments, Missing Partner, and Card Payments Without Partner in the statement search. Payment-category filters can be combined with Missing Partner and the existing posted/unreconciled filters.
To suggest the bank-cost account, create an OCA reconciliation model of type Rule to suggest counterpart entry, select the bank journal, outgoing amounts, and Payment Category: Bank Costs. Set a counterpart line to 100 percent of the balance and select your company's bank-cost account and applicable taxes. Keep automatic validation disabled while reviewing results. Card payments should normally match existing bills or the appropriate clearing entries; their category alone does not determine the expense account. Use unique matching for invoice rules so repeated amounts do not select an arbitrary invoice.
For label-based rules, use the existing reconciliation model partner mappings, scoped to the company and journal. Map the full imported label as needed, for example ^EL-Synthetic Merchant,. Conflicting mappings within one model return no partner. Conflicting applicable models also return no partner during lookup.
Remembering card merchants
Version 18.0.1.2.0 adds Remember Merchant beside the partner selector in Manual operation. Select a partner and click the button, or choose the partner in the confirmation dialog. Save Mapping and Apply explicitly associates the extracted merchant with that partner for this bank journal. For example, Synthetic Tools can map to Synthetic Tools s.r.o. without renaming the partner or writing a regular expression. Canceling the dialog saves no mapping.
The confirmation updates only the current unreconciled card entry, synchronizes its journal-entry partners, and resets its unvalidated widget suggestions. Amounts, accounts, references, and journal-item IDs remain unchanged. Neither confirmation nor backfill automatically reconciles entries. The candidate list refreshes its partner filter when the selected partner changes.
Existing card entries without an assigned partner also use an active saved mapping as the default Partner filter in Reconcile, together with the standard payable, receivable, and outstanding-payment filters. This suggests journal items without changing the entry's partner. An assigned partner always takes priority. You can remove the filter to search other entries.
Type a remembered merchant name, or part of it, in the Partner search or selector to find its associated partner. Alias searches apply only to the current bank journal with structured CAMT hints enabled. Archived mappings, inactive partners, and mappings outside the journal's company are excluded. Other partner searches keep their normal behavior.
Future imports with the journal profile enabled use the saved association before full-name matching or OCA mapping rules. Merchant keys ignore letter case and repeated whitespace; punctuation and legal suffixes are not guessed or stripped. Explicitly assigned partners are still preserved. Unknown merchants retain the existing strict matching behavior. An active mapping with an inactive or invalid partner is not reused and does not silently fall back to a different partner. Archived mappings are excluded from normal lookup, so the remaining name/account/rule matching can still apply.
Mappings are visible in the bank journal's Card Merchant Mappings tab. Editing or archiving them there requires normal journal-management permissions. Only one mapping per journal and normalized merchant is allowed, including archived mappings; the confirmation never overwrites a conflicting association. Mappings and partners respect company boundaries.
Saving a mapping does not bulk-update existing statements. For already imported entries, run Backfill CAMT Details, enable Correct Imported Card Bank Partners, and review the preview. This also applies saved mappings to previously backfilled entries whose bank partner was cleared and whose imported partner name is now the extracted merchant. Existing source matching, reconciliation, foreign-currency, and conflict safeguards remain in effect.
Previously imported descriptions that were discarded by the old parser cannot be recovered by the upgrade alone. Enabling hints recomputes categories and merchants from metadata already stored on existing lines, including posted or reconciled lines; it does not replace assigned partners. Use the controlled correction below for an incorrectly assigned bank partner. Do not reimport old statements merely to obtain the new metadata, as that may duplicate entries.
Controlled backfill of existing imports
Version 18.0.1.2.0 adds Backfill CAMT Details to the bank statement form, next to its attachments. Accounting users can select an original attached CAMT.053 XML file, click Preview, review the proposed details and skipped entries, and then click Apply Backfill. No backfill runs during module upgrade.
The source must match the statement name, journal bank account, and currency. Transactions match by booking date, signed amount, and the transaction ID preserved in the imported notes. A meaningful payment reference is used only when there is no transaction ID. Repeated or missing identities are skipped; the tool never guesses from an amount or list position alone.
Only missing CAMT remittance, bank code, and mandate details are filled. The source attachment is recorded on each updated entry. Existing conflicting details, reconciled or partially reconciled entries, and foreign-currency transactions are skipped. Statements with a mixture of reconciled and pending entries are supported; only eligible pending entries change. Repeating the backfill makes no changes when details are already present.
Labels, notes, references, amounts, dates, journal items, and assigned partners are preserved. Payment categories and merchant hints are recomputed from the recovered details when the journal profile is enabled. An incorrectly assigned bank partner requires the explicit correction option below. The default backfill does not create or reimport statements, assign partners, or reconcile entries.
Version 18.0.1.2.0 adds Correct Imported Card Bank Partners (off by default). Enable it and preview again, even if metadata was already backfilled. With the journal profile enabled, confirmed card entries are eligible when the assigned partner matches the source recipient's full name or uniquely matches its bank account. A different current account or a partner matching the merchant is left alone. Other assigned partners and bank-cost entries are preserved. The source cannot prove whether a matching bank partner was selected manually, so review every proposed correction before applying.
Corrected entries use a saved merchant mapping, unique merchant name, or applicable OCA partner mapping; missing or ambiguous merchants remain unassigned. The source-bank account is cleared from matching fields, but original notes and the attachment remain. Unassigned entries still showing the source recipient's name are corrected too; manually edited names on unassigned entries are preserved. The preview shows the old and new partner. OCA synchronizes only the partner on the existing liquidity/suspense items and journal entry; amounts, accounts, and entry IDs stay unchanged. Unvalidated widget suggestions on corrected entries are reset without applying reconciliation rules or automatically reconciling. Close and reopen reconciliation after applying to refresh the widget. All source matching, reconciliation, conflict, and currency safeguards still apply.
Applying rechecks the preview under record locks. A changed source or statement requires another preview; busy records produce a retry message. Original files must already be attached to the statement. ZIP archives and attachments larger than 10 MB are not supported by the backfill. If a source file or matching reference is missing, restore verified provenance separately instead of using the import wizard to recreate transactions.
Installation and upgrade
Make account_reconcile_oca_add_default_filters and its dependencies available on the server's addons_path before upgrading. It brings in account_reconcile_oca, account_reconcile_model_oca, and base_view_inheritance_extension through its dependency chain.
Version 18.0.1.2.0 also requires account_statement_import_camt from OCA's bank-statement-import repository. The parser extension and reconciliation logic remain inside this PMIS addon. A normal module upgrade creates the new fields and views; journal profiles start disabled and no accounting rules are created automatically.
Install or upgrade this addon through the normal Odoo module workflow after making its dependency sources available. Odoo does not download missing addon source code. No manual dependency installation or nested registry upgrade is implemented in this addon's migration.
Version 18.0.1.1.0 removes the two duplicated PMIS views through Odoo's normal obsolete-data cleanup. A post-migration restores the original OCA contexts for All and To Check, including when only PMIS is upgraded. Repeating that migration sets the same contexts. No migration manually installs modules or starts another registry upgrade.
The other OCA reconciliation addons are optional workflow features and are not required by this module.
Bug Tracker
Bugs are tracked on PMISuite Repository Issues. In case of trouble, please check there if your issue has already been reported. If you spotted it first, help us smashing it by providing a detailed and welcomed feedback.
Credits
Contributors
Matjaž Mozetič
Maintainers
Current maintainer:
Luxim is an independent R&D and deployment company focused on solving complex problems in the Odoo ecosystem.
Luxim is an active member of OCA (Odoo Community Association).






