- print_format.json: export Sales Invoice / Delivery Note / Purchase Order
and related Jinja print formats
- translation_markers.py: drop the old tax_article marker, add the deprecated
single-field description marker
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Payment Entry: add the two new Əlavə 3 groups (ƏDV tutulan dövriyyə /
ƏDV tutulan əməliyyat sayılmayan dövriyyə) to the tax_article link filter
- Sales Invoice: allow tax articles on ƏDV 18% lines, filtered to
"ƏDV tutulan dövriyyə barədə məlumat" (301.x). ƏDV daxil 18% stays excluded
(its prefix doesn't match "ƏDV 18%").
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
It is no longer auto-synced (mirror was removed); mark it deprecated and point
to the custom_item_tax_articles multi-select.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Insert custom_tax_articles_display into saved layouts independently instead of
replacing the legacy tax_article column (which is still used by other flows).
Position it after item_tax_template; leave legacy untouched. Idempotent.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Per-user grid layouts (GridView in __UserSettings) saved before this feature
list the legacy tax_article column but not custom_tax_articles_display. Frappe
renders the saved list verbatim and ignores the new in_list_view field, so the
'Tax Articles' cell never appears for those users until added via the grid gear
-- which is why it showed on a fresh user (Administrator) but not on machines
where the user had a saved layout.
Patch replaces the legacy tax_article entry with custom_tax_articles_display in
every saved Sales Invoice Item layout that lacks it. Idempotent; runs on migrate
so every machine converges automatically.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
create_custom_fields() applies only the properties present in each field
def (cf.update(df)). The custom_tax_articles_display def listed
in_list_view=1 but omitted 'hidden', so a site where the field had
hidden=1 would never converge on migrate -> the column showed on one
machine and stayed hidden on another. Make hidden=0 explicit so migrate
force-applies it everywhere.
Verified: forcing hidden=1 then running create_custom_fields() now resets
it to hidden=0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Frappe's money_in_words() produces "AZN Dörd Min Doqquz Yüz yalnız." for
1234.00 AZN — grammatically gettext-friendly but not how Azerbaijani
documents actually look. Native convention is "Min iki yüz otuz dörd
manat 56 qəpik": sentence-case number, lowercase currency word, fraction
as digits, no "only" suffix.
format_in_words_az is hooked as a validate doc_event on every doctype
that carries in_words / base_in_words (11 in total: Sales/Purchase Order,
Sales/Purchase Invoice, Quotation, Delivery Note, etc.). Runs after the
controller's own set_total_in_words has populated the field, then
overwrites it. No-op for any language other than az.
Uses grand_total (not rounded_total) to preserve qəpik precision, since
ERPNext's Rounded Total can round to whole manat per the Currency's
rounding_method.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
migrate_standard_field_codes_to_labels() rewrote Bank Integration Excel Column
Mapping.standard_field from old machine codes to human-readable labels — a
one-time compatibility fix after the storage format changed. The migration has
done its job: the preset fixture already ships labels, and new sites create
mappings via the UI dropdown (labels from the start), so old codes can only
exist on databases that predate the format change. Drop the function, its
code->label map, and the after_migrate call.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The last line of create_custom_fields() was a print() with no code under it —
a leftover heading for setup that was never written. It only produced a
misleading line in the migrate log; VAT calculation is actually wired up by
patch_sales_documents(), an unrelated function.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Importing Bank Transactions via "Import From → Load from Excel" left
the screen darkened and unresponsive after the job finished. Root cause
was the show_progress Bootstrap modal: closing it from JS (we had a
hand-rolled _closeProgress that called .modal('hide').remove() and then
removed .modal-backdrop manually) interrupted Bootstrap's hide animation
mid-flight, leaving the dimmed overlay stuck. Opening a msgprint right
after made it worse — the two modals fought over the same backdrop
node.
Switched to frappe.dom.freeze / unfreeze: a single full-page overlay
managed by Frappe core, with no Bootstrap modal/backdrop juggling. The
freeze message is updated in place as progress events arrive (writes
to #freeze .freeze-message directly to avoid stacking the freeze
counter, which would break unfreeze pairing). unfreeze on completion
cleans up reliably, so the msgprint that opens immediately after lands
on a clean page.
Removed the now-unused _closeProgress helper.
Bank Account is chosen explicitly in the Import dialog before the
parser runs, so the IBAN→Bank Account child table never carried weight
in this flow. Unlike kapital_bank — where the API hands over raw IBANs
and needs a lookup table — jey_erp's Excel import fixes one Bank
Account per file from the dialog and applies it to every row.
Removed surface:
- Bank Statement Importer JSON: Account Mappings subtab (Mappings group)
and Accounts subtab (Data group), plus their child table field
- Bank Integration Account Mapping DocType folder
- matching.py: match_similar_accounts
- creation.py: create_unmapped_accounts
- import_api.py: "accounts" branch of get_bi_reference_data_list
- bank_statement_importer.js: Match/Create buttons in the Accounts
group, _bi_render_accounts renderer, and its load_tab line
Added post_model_sync patch drop_bank_integration_account_mapping that
deletes the DocType and its `tab<Name>` table from existing databases.
Bank Accounts created via the "Create Bank Accounts" button represent
the user's own accounts at the bank — not counterparty accounts — so
they need is_company_account=1. Without it, ERPNext treats them as
external and they don't appear in Bank Reconciliation Tool or as
selectable paid_from/paid_to in Payment Entry / Journal Entry.
Previous approach replaced the Menu Delete item's jQuery click handler,
but Frappe wires the same item through its own event chain that bypassed
.off('click') — both our cascade dialog AND the stock "Permanently
delete X?" prompt fired in sequence.
Form's Delete menu item ends up calling frm.savetrash(); overriding that
method directly is the single point that intercepts every code path that
reaches it. Removed the brittle DOM-walking wireMenuItem helper.
Stock delete on Bank Statement Importer hits Frappe's link-check
(registry rows + Bank Account dynamic-link) and refuses to proceed,
leaving users unable to remove an importer they no longer need without
hand-cleaning every dependent row.
New flow:
- cascade_delete.py adds two whitelisted endpoints: get_dependents
(counts) and cascade_delete (unlink Bank Accounts → delete Customer/
Supplier/Purpose registry rows → delete the importer)
- bank_statement_importer.js overrides the Menu → Delete action: shows
a confirm dialog listing exactly how many records will be deleted vs
just unlinked, with a red primary button to drive the choice home.
After success the user is sent to the list view.
Bank Accounts are intentionally unlinked rather than deleted — they hold
business data (Bank Transactions, reconciliations) that has nothing to
do with the importer being removed.
System is single-company; Default Company on Bank Statement Importer
duplicated what ERPNext already exposes via Global Defaults. Removed
the field and replaced bi.default_company with erpnext.get_default_company()
at the two usage sites (Bank Account creation, Bank Transaction bulk
import). Existing column on tabBank Statement Importer is left in place
— Frappe just ignores it.
The 4-step workflow stepper added in 83a2cb6 was experimental and
turned out to be visual noise on top of the form. Reverting back to
the tab layout speaking for itself.
Users had no way to know the setup is ordered — they would land on
Match/Create buttons before the registries had anything to match, or
go to Load Data before configuring the file format.
A small four-step indicator now sits at the top of the form, with the
current step highlighted and a one-line hint pointing at the next
action. State is read off the form itself (column_mappings filled? any
mapping tables populated?), so the guide moves forward as the user
makes progress and disappears once setup is done as much as the form
can tell.
The four steps:
1. Configure format → File Format tab + sample file
2. Load registries → Load Data button
3. Match & Create → Data tab + Match/Create toolbar buttons
4. Import statements → Bank Transaction list → Import From
Previously a re-upload (clear → re-attach) just refreshed the Excel
Column dropdown and silently kept the existing mapping rows — pointing
the user at the new file but leaving the table tied to the old one. Now
the form asks before overwriting: empty table still auto-detects
silently, populated table prompts with a Confirm dialog before clearing
and re-running.
The validate() hook threw "Amount Mode 'X' requires these Standard
Fields: Reference Number, Debit, Credit" as soon as the user uploaded a
sample file — auto-detect made the form dirty, and any later save
ran into a setup the user hadn't finished yet. The dialog interrupted
the very flow it was supposed to support.
Removed the entire _validate_file_format hook. The same check already
lives in excel_parser.parse_excel — it fires only when the user actually
tries to import a statement, which is the right moment to demand that
the format be complete. Saving a half-configured form is fine: users
can come back and finish later.
Auto-detect inserts a row for every header found in the sample file,
including ones it couldn't match against the synonym list — those rows
went in with an empty standard_field. With Standard Field marked
reqd=1, any subsequent action that triggered a save (Match accounts,
Create customers, etc. routed through the "save first?" prompt) failed
with "Mandatory fields required in table Column Mappings, Row N".
The reqd was already redundant: excel_parser skips column_mappings rows
without a standard_field, and Bank Statement Importer.validate enforces
the actual required-minimum set (Date / Reference + Debit/Credit or
Amount) at the parent level based on amount_mode. Dropping reqd from
the child lets unmapped rows coexist in the table for visibility.
The header → Standard Field dictionary is data, not code, so it now
lives in header_synonyms.json next to its loader. Editing a synonym list
no longer requires touching Python — open the JSON, append a string,
done.
header_synonyms.py is now a thin loader (reads the JSON once at import
time) plus the matcher and the Azərbaycan→Latin transliteration table,
which stay in Python because they're behaviour, not data.
The _HEADER_SYNONYMS dict, the Azərbaycan-to-Latin translation table, and
the matcher helpers were sitting in the middle of excel_parser.py making
the file harder to scan. Moved them to a dedicated header_synonyms.py
with a docstring explaining how to extend it.
Public API of the new module is just guess_standard_field(header) and
HEADER_SYNONYMS — that's the surface excel_parser actually uses.
Two changes that drop the manual step from the column-mapping setup:
- Auto-detect now runs implicitly when the user attaches a Sample Excel
File. The Auto-detect Columns Button field is removed (Preview Sample
stays — it answers a different question). Auto-detect only fires when
the Column Mappings table is empty; a user-edited table is never
overwritten silently.
- Replaced the modal "Auto-detect Complete" / "Sample File Error" /
"Empty Header Row" msgprints with small bottom-right show_alert
toasts. The result is one line — "Auto-mapped 9 of 11 columns" —
with green/orange/red indicator instead of a full-screen dialog.
The synonym dictionary used by detection lives in code at
jey_erp/bank_integration/excel_parser.py (_HEADER_SYNONYMS).
The two helpers used to live in the form toolbar under a 'File Format'
group, which added noise to the already busy header (Match/Create
buttons for accounts/customers/suppliers/purposes plus Load Data are
also there).
They are now native Button fields inside the File Format tab, sitting in
a two-column row directly under the Sample Excel File attach widget:
[ Sample Excel File: ... ]
[ Preview Sample ] [ Auto-detect Columns ]
[ Format / Column Mappings sections ]
Both buttons are gated by depends_on=sample_file, so they only appear
when there's actually a file to operate on — same gating as before, just
contextually placed next to the upload instead of in the global toolbar.
Multi-currency Bank Accounts (one account holding several currencies in
parallel) exist with some western banks like Revolut/Wise, but in AZ the
convention is one Bank Account per currency. The toggle was extra noise
on the File Format tab for every user.
Kept the field and the underlying parse/import logic intact (hidden=1
only). Removing the hidden flag re-exposes it if a real multi-currency
case ever shows up.
Replaces the standalone Bank Statements workspace (incorrect approach —
ERPNext doesn't expose top-level apps as tiles automatically) with a
runtime insertion of a single 'Bank Statement Importer' link into the
existing 'Banking' card on the ERPNext-owned Invoicing workspace.
Editing the workspace at runtime via after_migrate (not by overriding
its JSON) is intentional: ERPNext resyncs that JSON on every `bench
migrate`, so a file-level patch would be reverted. after_migrate runs
AFTER the resync, so the inserted link stays.
The insert is idempotent — it skips when the link is already present,
when the Banking card break isn't there, or when Bank Statement Importer
DocType doesn't exist yet.
User feedback: a standalone top-level workspace doesn't surface inside
the existing ERPNext module tiles. Putting it under Accounting (next to
Financial Reports) matches user mental model — bank statement work is
already a financial activity.
After migrate, Bank Statements shows up as a sub-page in the Accounting
sidebar group, alongside Financial Reports.
A discoverable home for the import flow — until now Bank Statement
Importer, the registries, and the BRT had no workspace entry and were
only reachable by typing URLs.
The workspace groups everything into three cards:
Setup — Bank Statement Importer, Bank, Bank Account
Daily Use — Bank Transaction, Bank Reconciliation Tool
Registry — Counterparties (Customers/Suppliers), Purpose Keywords
Plus three coloured shortcut tiles for the most-used entry points.
The original "Bank Integration" name was too broad — this is specifically
a configurable Excel statement importer, not a generic bank API
integration. The new name lines up with the per-bank, per-format profile
the doctype actually represents.
Scope is narrow on purpose: only the main DocType is renamed. The
internal mapping/registry doctypes (Bank Integration Customer, Supplier,
Purpose, Customer Mapping, Supplier Mapping, Transaction Mapping,
Account Mapping, Standard Field, Excel Preset, Excel Column Mapping)
keep their tech names — they are not directly user-facing and renaming
them would multiply the migration surface for no UX gain.
Changes:
- Folder bank_integration/ moved to bank_statement_importer/, files
renamed alongside; Python class is now BankStatementImporter
- All Python callers (excel_parser, import_api, create_reconcile,
creation, matching, migrations) call frappe.get_doc("Bank Statement
Importer", …); the parenttype string in child-table queries follows
- JS form handler, both list views (Bank Transaction, BRT) updated,
including the "BiType::Name" mapping-source key used by BRT
- Registry doctypes (Customer, Supplier, Purpose) updated to link to
Bank Statement Importer in their parent_bank_integration field
- Bank Account.bank_integration_type custom field options now offer
"Bank Statement Importer"
- pre_model_sync patch renames the existing DocType, rewrites Bank
Account.bank_integration_type stored values, and patches the Custom
Field options in-place so the rest of the migrate run is consistent.
Idempotent: skips when the new name already exists or the old one
doesn't.
The Python module path jey_erp.bank_integration.* is intentionally
unchanged so existing imports (and any external integrations) keep
working without touching every from-import statement.
Two new helpers on the Bank Integration form, shown when a Sample File
is attached:
- "Preview Sample" opens a modal with the header row + first 20 data
rows, with badges on each column showing the currently mapped Standard
Field (or "unmapped"). Helps spot wrong Header Row / column drift
before importing real statements.
- "Auto-detect Columns" reads the sample headers and replaces the
Column Mappings table with a best-effort guess based on a multilingual
synonym list (English, Azərbaycan, Russian). Reports how many of the
total columns matched and lists unmapped headers so the user can fill
the rest manually. Asks for confirmation before overwriting an
existing table.
Both helpers are backed by new whitelisted endpoints
parse_sample_preview and auto_detect_column_mappings in excel_parser.py.
File format settings (header row, amount mode, column mappings, sample
file, direction values, custom date format, currency-from-file) now live
on the Bank Integration record itself under a new "File Format" tab,
removing the extra hop through Bank Integration Excel Preset.
- Bank Integration JSON gains the File Format tab and column_mappings child
- Excel parser and import API read format from Bank Integration directly,
drop the preset_name argument from public endpoints
- Load Data dialog (on Bank Integration) and Load From Excel dialog (on
Bank Transaction list) drop the preset Link field; the chosen Bank
Integration provides everything needed
- after_migrate patch copies fields and column mappings from an existing
preset into each Bank Integration whose File Format is still empty
- Bank Integration Excel Preset doctype kept around for rollback but
marked deprecated (System Manager only, in-form warning), removed from
the fixtures list so fresh installs don't ship the Generic preset
The E-Taxes Obligation Pact doctype is being removed; the in-form
list section + HTML field that hosted it on Company are no longer
needed. Cleanup of leftover Custom Field rows on existing sites is
handled by jey_wizard's v0_1_27 patch.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Drop the conditional Won/Lost Custom Fields and their JS/Python plumbing —
they should never be shown again. Adds a post-migrate patch to delete the
existing Custom Field records (and any stray Property Setters) from the DB.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replaces "Azeri" / "Azerbaijani" / "Azerbaijan" with the native form
"Azərbaycan" in labels, descriptions, comments, app description, and
docs. Field names and Python identifiers are unchanged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two related correctness fixes:
1. Asymmetric Azerbaijani normalization.
consider_azeri_chars was only honoured by match_similar_customers/suppliers
when populating registries. At Create & Reconcile time both the party-name
lookup and the fuzzy purpose matcher compared raw lowercased strings, so a
party matched via "Şirkət" ↔ "Sirket" translit at registry time would not
resolve when the BT arrived, and a purpose rule keyed on "Mədaxil" would
fall short of fuzzy threshold against "Medaxil".
- name_to_party now indexes each row under strict / lowercase / translit /
translit+lowercase variants based on its effective Case Mode + Azeri
Translit (new per-row Select fields that override the globals, same
pattern as case sensitivity).
- _find_mapping_for_txn takes an `az` flag and applies translit to both
keyword cache and txn purpose/party before comparison.
2. Customer / Supplier dedup ignored VOEN.
create_unmapped_customers / create_unmapped_suppliers checked only by
customer_name / supplier_name, so a registry record sharing a VOEN with an
existing party under a slightly different name would create a duplicate.
Now: tax_id is checked first, name as fallback; when an existing party is
found, the mapping row is linked to it (instead of silently `continue`ing
without linking). Response includes linked_count alongside created_count.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Escape t.ref_no / t.counterparty / t.purpose / error fields with
escape_html when rendering the preview and error-detail dialogs. A
malicious bank statement (or counterparty-supplied purpose text)
containing HTML could otherwise execute in the importer's session.
- Parser now refuses to proceed if any standard field required by the
selected Amount Mode is missing from the file headers — instead of
silently dropping every row with reason "amount" / "date".
- Reference Number is now a required mapping for all Amount Modes,
preventing a class of silent duplication on re-import. parse_excel_for_
preview also returns empty_ref_count and the preview surfaces a warning
about future duplicate risk when some rows have an empty Reference
Number on disk.
- Add 'Use Currency From File' checkbox on Excel Preset (default off).
When on, BT.currency uses the parsed Currency column with fallback to
the Bank Account's currency. import_bulk_bt now takes preset_name and
the background job reads the flag.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Delete mapping_resolver.py: dead code (nothing imports it; create_reconcile
builds the indexes it needs directly).
- Simplify _create_journal_entry_for_brt: the if is_pay / else branches were
identical because the matching transaction mapping is scoped by payment_type,
so paid_from / paid_to already encode direction (from = credit side, to =
debit side for both Pay and Receive). Removed the dead conditional, kept a
comment explaining why no swap is needed.
- Add _parse_amount helper in excel_parser: handles currency text in the cell
('AZN 250', '250 AZN'), comma decimals ('250,00'), mixed thousands+decimal
('1,200.50' / '1.200,50'), accounting-style brackets ('(45.50)' → -45.50),
and trailing minus ('250-'). Used for amount/debit/credit cells.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Party-name lookup at Create & Reconcile previously used a strict (strip-only)
key, so a Bank Transaction whose bank_party_name differed in casing from the
registry record would never resolve a party. Now:
- 'Ignore Case in Party Matching' Check on Bank Integration (default ON) sets
the global behaviour: party names are indexed under both their strict and
lowercase forms, and the lookup tries both.
- 'Case Mode' Select on each Customer / Supplier Mapping row overrides the
global for that specific party — blank inherits, "Ignore Case" / "Case
Sensitive" forces the mode regardless of the global setting.
Honours the established "row > global" priority pattern used elsewhere.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Importing into Mode 3 with a preset that had no Amount mapping silently
dropped every row and showed a confusing "No transactions found" message.
Two fixes:
- Preset.validate() now requires the Standard Fields the parser needs for
the chosen mode (Mode 1: Date+Amount; Mode 2: Date+Debit+Credit; Mode 3:
Date+Amount+Direction). Clear error on save lists exactly what's missing.
- When all rows drop due to unreadable amount, the import dialog now opens
a helper modal pointing at the preset, instead of the generic empty
message.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
'Single column + direction column' previously guessed direction from a
hardcoded EN/AZ alias list, silently falling back to "D" on anything
unrecognised. Now the preset exposes two comma-separated fields — Debit
Values and Credit Values — that the user fills with whatever their bank
prints (e.g. "DR, Debit, Məxaric" / "CR, Credit, Mədaxil"). The fields
are only visible/required for this amount mode and validated on save.
Rows with a Direction value that doesn't match either list are now
dropped with reason="direction" and the offending values are surfaced
in the import / Load Data dialogs so the user can copy them straight
into the preset.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Only well-formed files (data rows immediately after the header) are expected;
Header Row alone is enough to point the parser at the start of data.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Sample File on Preset: upload once, headers populate the Excel Column
Autocomplete in the mapping table; Clear Sample button reverts to free text.
- Date format: hidden behind "Use Custom Date Format" checkbox; parser tries
24 common formats (ISO/EU/US × -./\\\\ × with/without time) automatically.
Surfaces a clear "open the preset and enable custom format" dialog on
unparseable dates, instead of silently dropping rows.
- Standard Field options renamed from machine codes (date, reference_number…)
to readable labels (Date, Reference Number…); parser maps labels → codes.
Idempotent migration converts existing rows.
- Header matching is now case- and whitespace-insensitive.
- Direction-column aliases extended with Azerbaijani terms (Mədaxil/Məxaric/
Daxil/Çıxıb/Gəlir/Xərc).
- cost_center in transaction_mappings filtered to is_group:0 in the form.
- Load Data result surfaces dropped_date / dropped_amount counts.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bank Integration Customer/Supplier used generic BIC-####/BIS-#### ids.
Switched to the Kapital Bank scheme: an autoname() controller method
sets the record name to customer_name / supplier_name (truncated to 140,
-N on collision since multiple Bank Integrations can hold the same
counterparty). The after_migrate pass renames any existing BIC-/BIS-/
BIP-#### records to their readable names.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Excel import dialog no longer has the "Also load counterparties &
purposes" checkbox — BT import now only creates Bank Transactions.
Registries (Bank Integration Customer/Supplier/Purpose) are populated
exclusively through the "Load Data" button on the Bank Integration form.
Since BTs are now always imported without a party, Create & Reconcile
resolves it: a BT's bank_party_name (the counterparty text from the
file) is looked up in the customer/supplier mappings, and if that
counterparty is mapped to an ERPNext party, the txn gets that party —
so counterparty-based transaction-mapping rules match and the created
PE/JE carries the party. A safety guard: a party is only attached to a
Payment Entry when one of the GL accounts is Receivable/Payable.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
_find_mapping_for_txn now tries exact-substring purpose matches first
(unchanged), then falls back to a partial-ratio fuzzy match against
similarity_threshold_purpose — so a short/imprecise purpose keyword can
match somewhere inside a long bank-statement description. Order:
purpose+counterparty (exact) > purpose-only (exact) > purpose+
counterparty (fuzzy) > purpose-only (fuzzy) > counterparty-only >
fallback. Set the threshold to 100 to keep the old substring-only
behaviour. This makes similarity_threshold_purpose actually do something
in the BRT path.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bank Integration Purpose used a generic BIP-#### id. Switched to the
Kapital Bank Purpose scheme: an autoname() controller method sets the
record name to the purpose_keyword text (truncated to 140, -N on
collision). A migration in after_migrate renames any existing BIP-####
records to their readable names (Link references update automatically).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Ali