Added documentation about Account Lookup Analyser - #545
Conversation
| `_party_ba_id`. This magic field gets evaluated by several matcher plugins, | ||
| including CreateContribution and ExistingContribution. | ||
|
|
||
| Additionaly, this plugin can look up the CiviCRM BankAccount for the |
There was a problem hiding this comment.
| Additionaly, this plugin can look up the CiviCRM BankAccount for the | |
| Additionaly, this plugin can look up the CiviCRM `BankAccount` for the |
| account reference from the currently analysed transaction, it looks up if this | ||
| account reference already exists as a CiviCRM BankAccountReference. It then | ||
| stores the internal CiviCRM-ID for the BankAccount in a magic field | ||
| `_party_ba_id`. This magic field gets evaluated by several matcher plugins, |
There was a problem hiding this comment.
I thought it's party_ba_id, isn't it?
| including CreateContribution and ExistingContribution. | ||
|
|
||
| Additionaly, this plugin can look up the CiviCRM BankAccount for the | ||
| organization's account reference and store it's id in a magic field `_ba_id`. |
There was a problem hiding this comment.
I thought it's ba_id, isn't it?
|
Thanks for your feedbacks! I will go through it and add some changes. |
|
I did all the corrections. Just for the evaluation of |
Actually the same as with In pseudo code it should be more or less like this: |
|
The part that I don't understand is, what happens with |
As with |
|
ah, ok. I added that. |
dontub
left a comment
There was a problem hiding this comment.
I've noted few more things that came to my mind. Please have a look and see what you think about it.
| example. The second part of the field name (`IBAN` and `NBAN_PP` in this | ||
| example) can be any CiviBanking bank account reference type option value. | ||
| The first part of the field name (`_party_` in this example) can be configured | ||
| in this plugin. It also evaluates the field `_IBAN` and stores the id for the |
There was a problem hiding this comment.
I'm unsure if it's clear that the IBAN in _IBAN can by any bank account reference type option value as above and that _ is a configurable prefix like _party_... Would it make sense to explain it in a way that makes clear that for the configurable prefixes _ and _party the same kind of lookup is performed?
|
|
||
| In a typical setup, your importer plugin writes the account reference to the | ||
| field `_party_IBAN` or `_party_NBAN_PP`. The Account Lookup Analyser | ||
| evaluates the field and writes to a magic field `party_ba_id`, which later is |
There was a problem hiding this comment.
[...] which later is evaluated [...]
Technically correct would be "can be" instead of "is".
| example) can be any CiviBanking bank account reference type option value. | ||
| The first part of the field name (`_party_` in this example) can be configured | ||
| in this plugin. It also evaluates the field `_IBAN` and stores the id for the | ||
| `BankAccount` in a magic field `ba_id`. Later, `ba_id` gets stored in the |
There was a problem hiding this comment.
Actually I'm wondering what "magic" means here (as well as below for party_ba_id). Technically it's just a field of the BankTransaction entity that can be accessed by analysers and matchers like other BankTransaction fields.
| "plugin_type_name": "match", | ||
| "plugin_class_name": "analyser_account", | ||
| "name": "Account Lookup", | ||
| "description": "Provides potential contacts, based on account lookups", |
There was a problem hiding this comment.
Is the description really accurate? Actually the matcher is just about BankAccounts not contacts, isn't it? Should it rather be something like "Associates transaction with bank account"?
|
I added all the corrections. |
No description provided.