feat: Auto set Party in Bank Transaction

[marination]

Resolves part of #34477
Ref: alyf-de/banking#17
Docs: https://docs.erpnext.com/docs/v14/user/manual/en/accounts/bank-reconciliation

Issue

• Bank Transaction holds almost no information about the Counter Party (the party we are paying/receiving from) as per the Bank Statement.
• This counter party information is not likely to exactly match the Party in the system
• Due to which the fields Party Type and Party are almost always blank. This makes identification hard in the Bank Reconciliation Tool
• Bank Transactions are usually bulk imported, hence setting these values manually are painful

Enhancement

Note: This matching is done fairly conservatively. It's better to not have a match than to have multiple wrong matches.

This PR adds an optional automatic Party matcher.

1. Enable it in Accounts Settings. Fuzzy matching can be optionally enabled
   

2. Register primary/most used bank details like Account Number & IBAN against Customer, Supplier & Employee via Bank Account or Employee DocType (for Employees). This is optional and will make the match more accurate if set by users.

3. Added fields to hold Counter party information in Bank Transaction.(The population of these values will depend on integrations that import transactions or the users that upload the bank statement )
   

4. If Account details are absent in the Bank Transaction, fuzzy matching is optionally done using the Party Name (Bank Statement) or Description. These are matched against Customer/Supplier/Employee names.

5. The matching is done and values are set on Submit if auto matching is enabled

6. Users can correct the Party & Party Type, if incorrect, after submission. This will only impact the edited transaction.
   

Working

Expand to view the working

• If more than one match was found against a description/party name, with the same score, we skip matching and do not set a party in the bank transaction. We do not want to automate close calls, the user must decide these.

TODO:

• Provision for user to correct mapping
• Provision for users to create a mapping (they can manually set the party in the transaction & also create a Bank Party Mapper)
• Test
• Docs
• Description
• Use old bank fields to get party against bank data. Don't introduce new ways of storing bank data.
• Optional fuzzy matching + If multiple similar matches, skip automatching

For the reviewer: Hit me up for test data

[codecov]

Codecov Report

Merging #34675 (8ab8230) into develop (b26d70b) will increase coverage by 0.04%.
The diff coverage is 91.58%.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #34675      +/-   ##
===========================================
+ Coverage    64.12%   64.17%   +0.04%     
===========================================
  Files          810      811       +1     
  Lines        61899    62006     +107     
===========================================
+ Hits         39695    39793      +98     
- Misses       22204    22213       +9     

Impacted Files	Coverage Δ
...ounts/doctype/bank_transaction/bank_transaction.py	68.75% <90.00%> (+1.28%)	⬆️
...ounts/doctype/bank_transaction/auto_match_party.py	91.75% <91.75%> (ø)

[marination]

@deepeshgarg007 Docs and description has been updated. The latest changes resolve the following ambiguities:

Why add bank details to Customer and Supplier instead of fetching linked Bank Accounts?

Bank details are searched for in Bank Account now. In the case of Employee, the Bank Account is searched and then the Employee doctype as it has bank account fields in it historically.
No new ways to store bank details

@vorasmit's concern: "For a client, we did the recent implementation, they have over 20k customers. Many are similar and need suffixes as to from which area they belong."

I did brainstorm this quite a bit and discussed this with @barredterra. Smit suggested rules but that would cause users to create way too many rules to match their plethora of parties. Could not really come up with anything else that wasn't bad UX.

So fuzzy matching is optional. In the docs, users are encouraged to test the feature out first. The matching might be a wee bit problematic where extremely similar names exist (e.g. Adithya Medical& Surgical vs Adithya Medical & Surgical vs Adithya Medical And Surgical) but will work great for data where there is not so much similarity.

I also increased the match score cutoff to 80.

Additionally fuzzy matching does not set any value if multiple matches with the same score were obtained for a query.
E.g. if the query in the Bank Transaction is "A.K. Medical" and two parties exist such as "A.K. Medical Hall" and "A.K. Medical Store", both will be accurate matches. In this case we do not make the system decide between close calls and leave it blank for the user to set it themselves or not set it at all.

[barredterra]

Tested matching by party name, description and IBAN. LGTM.

Todo: Update docs and PR description (to not confuse future readers).

[marination]

@barredterra docs and PR description updated ✅