Automatic creation of partners can require hand work

[sraps (Alistek)]

Automatic creation of partners causes big trouble because it wrongly misidentifies partners and then creates additional partner.

Just one example...

Bank provides us such string as opposite party:
SOME PARTNER AS.OLAINE RĪGAS 21 R ĪGAS LV2114 /ID/40003006993

In our base, this partner is defined like this:
Some Partner

As you can see the remainder is their address and registration ID. The other problem why, it should not create partners on the fly is that as you can observe bank for some unknown reason adds spaces to strings, so there may be differences even though the strings should be identical.

[Pieter J. Kersten (EduSense BV) (pieterj)]

As bank accounts are mandatory tied to partners, there is no way to create bank accounts without a partner object linked.
Apparently your bank provides you with an ID to match a partner with, so what keeps you from extending the logic with ID matching? This way there can be no mistake. You only have to make sure the ID is correctly parsed from the provided bank info...

I see four options:
1. Don't do anything. Hand link the right partner to the bank account and remove the wrong one. This is a one time operation per bank account.
2. Drop the creation of new partners and rely on hand work, either beforehand or from an error log (causing imports to fail).
3. Extend the mechanism to use smarter options available as the one mentioned. Should be a relatively simple addition.
4. Extend the error mechanism to allow wizard like creation of bank accounts. This is not an easy task.

For now, 1 works. My vote goes to 3. I think it should be easiest if you built this yourself, as all test cases are in your hands.

[sraps (Alistek) (erpsraps)]

1. As there is no option to filter out those, that have been created (there is no option to do search on text field). Moreover I would not want to have automatically created partner with the name taken from payment line, which are 90% crippled coming from banks.

2.This one would definitely be better, at least, for the time we do not have better fool proof option. Actually there should not be errors happening, just a not matched transaction. Even more if you do business with order or invoice beforehand, there will not be any problem. Actually I do not like that computer thinks for the human on cases, where the logic is pretty fuzzy. I prefer not to have feature that create problems, only then we will have options to have good improvements be introduced with time.

3.I am not sure I do understand what do you mean by this.

4.Probably this is good option, but it takes some time and work to implement.

So I would better choose 2nd option for now.

[sraps (Alistek) (erpsraps)]

I set this to high importance, because it pollutes database with data that are not easily recognized from the originals, even more without asking users permission to do that...

[Pieter J. Kersten (EduSense BV) (pieterj)]

With option 3 I mean the ID handed to you by your bank import format to uniquely identify your partner. As you know these beforehand or can check these with an online national data bank, you know exactly which partner is causing the bank account mutations. The only problem is that the matching algorithm is not prepared for handling these unique ID's, let alone is able to match these.

By extending the import communication format (memory objects) with more identifiers, there is room for handling these in the matching as well. Which will solve your problem - say - 100%?

[Pieter J. Kersten (EduSense BV) (pieterj)]

The scope of this problem is limited to the initial match. Depending on your business (B2C or B2B) initial matching will be either frequent or only incidental. So high importance is a bit over the top.

Pollution is a matter of perspective - you import data from your bank. If it contains polluted data, it will pollute your data as well. I think you are referring to different data for the same ID's from different origin. However, this is not considered to be pollution but is instead related to the question who is authoritative in which data set. If you consider yourself authoritative, then you should not accept data from other parties and take responsibility for the consequences.

Between the lines I read a need for filtering partners on creation date. Should be a relatively simple addition. If you would be able to do this, would it be sufficient enough to consider this as a work around?

[Pieter J. Kersten (EduSense BV) (pieterj)]

There is a simple work around for this "problem": when walking through the imported statement, all lines that are tied partners are visible as such in the concept bank statement lines.

With new partners, you can simply press F2 in the corresponding line to alter the partner to your preference. Once saved, all later references will point to your changes.

With existing partners, you can view the bank account which led to the creation of the partner (F2, bank account, F2) and type it over or - quicker for batches - open a bank accounts view in parallel and change the partner to the right one. Delete the new partner afterwards, save it and voila.

With intermediate partners, add the imported bank account to the end partner as well. The matching algorithm will recognize this and act accordingly on next imports.

All this manual actions are required only once. In comparison with complete manual work as opted by in #2 sub 1, this saves you a considerable amount of work. With the new identification extensions in the make, chances on false creation of partners will get lower and lower, depending on the quality of the information banks provide their customers with.

As this is no longer a bug but a feature, I'll mark this bug as "invalid".