I use payment and receipt rules to automatically allocate dividends and taxes to the relevant stock (‘division’). This will look like “BAC - Div on” or “BAC - Tax on Div” for example. However, I have the problem that for some stocks, such as ‘Citibank’ (“C”) or ‘Kellogg’ (“K”), I have to do manually, because the software is trying to allocate irrelevant transactions to them. For example, BAC is being allocated to C; VTRS to S etc.
It would be ideal if the software would allocate something to the best match available, rather than the first match available, whilst still not requiring an exact match. So for example I can still have the rule as “BAC - Div on” rather than requiring the rule to be “BAC - Div on X XXX Sh”. So the software may find that “C - Div on” has fewer characters matching than “BAC - Div on” and thus allocate it to BAC as intended.
Can you demonstrate with some screenshots how your payment/receipt rules are configured? Not really sure why you can’t configure your payment/receipt rules so there is no ambiguity.
Sure, below are 3 screenshots. There are other examples where this clash happens. When I import transactions, one example is that it wanted to allocate “BAC - Div on” to “C” division rather than “BAC” division.
Yes, and ideally should not have items of the search string split (as also shown in screenshot) but be “exact” and unique. Also when adding another search line this alsos should be treated as “exact” but where the AND condition allows it to not be adjacent to the first “exact” search string.
I just installed v21.7.8 on Ubuntu server and find it strange that it still picks a single word such as “TO” in addition to the longer string that includes something like:
TRANSFER BETWEEN CUSTOMERS via BANK SALARY from COMPANY LIMITED to NAME
The TO in CusTOmers should not be marked as the Payment rule only uses SALARY from COMPANY LIMITED
to
The “best” match is an ambiguous term as it depends on the user’s interpretation.
In my opinion using rule priority based on rule length results in a decrease in rule power not increase because
rule priority for longer rules could easily be achieved in the past by putting the longer rule first. For example in the above example just drag the “BAC - Div on” above the “C - Div on” rule.
The reverse is not the case though. When the search algorithm uses orders based on one of the character counts, the user can no longer specify which rule is the most specific. The limitation is most obvious for multi-line searches with relatively short individual search term, which can be used to create very specific searches.
@lubos, can you be more specific? Exactly what was “fixed?” How do payment and receipt rules now function differently than before v21.7.8?
I also do not see that @SheldonSwanepoel actually illustrated any problem. Two somewhat vague receipt rules were shown (no bank accounts, no payees). But no results of their application were illustrated. So we do not know if those rules worked or not. The third screen shot in post #3 shows the result of searching the Receipt Rules list. It shows that that the Search function worked exactly as it does when searching any other list in Manager, by finding partial strings. It does not show that the receipt rules depicted failed to find the right transactions or improperly posted any receipts from an imported statement.
I agree with @Patch. More to the point, a receipt or payment rule should require an exact match, not some algorithmic “best match,” whatever that might mean. I don’t want a transaction classified on the basis of “close enough” after defining an exact criteria. And I would think that, particularly in a situation like @SheldonSwanepoel’s, where imported definitions might differ only slightly, the requirement for an exact match would be especially necessary.
I agree with Patch and Tut, rules cannot be best match, it has to be exact match. The only enhancement I can suggest is that we have a priority setting on rules which the User would set, i.e. which rule should be executed first based on User input, not the length of the rule. E.g. if I have two transaction descriptions, Cash Deposit Fee and Cash Deposit where Cash Deposit Fee should be allocated to Bank Charges and Cash Deposit should be allocated Sales, I cannot setup a rule for Cash Deposit as it will allocate Cash Deposit Fee to Sales as well. If we were to have a priority, we would be able to set a rule for Cash Deposit Fee to execute before a rule for Cash Deposit. There may be scenarios where the first rule to be executed should be the one with the shorter description.
Also taking multiple conditions into consideration (which is a wonderful feature) how would you determine length? Only the first condition, or the total number of characters of all conditions? I believe anything that is not an exact match will only create confusion and may result in unwanted allocations.
I am sorry @Lubos but why would it be a problem to implement exact search or at least disallowing a split in search string (see my earlier message about doubling TO)? Additional lines must not only lengten the search string as it does now but prevent other options to appear and thus makes search and application of rule more precise.
The only reason that case selects the most specific is longer sting includes all of the shorter string.
In general that is not how rule searches are written.
The specificity of a search sting depends on how common it is in the data set not how long it is.
For example by far the majority of payments from and ANZ bank account start with the 29 character string
ANZ INTERNET BANKING PAYMENT
so including this is actually a catch all for most business payments.
In contrast many quite specific search strings are about 6 characters long.
In summary string length has a variable correlation with search specificity.
The actual search specificity depends on
the data set being searched
the test string
the alternative test string
Only the user can reliably determine which is the specific entry and which is the catch all remaining.
Yes. That’s the point. Make your rules so they include as much as possible. If they have to include ANZ INTERNET BANKING PAYMENT, they should include it.
But they should be written that way. That is my assumption. The alternative is to ask users to set priority for their rules which for most of them (if not for all) is pointless.
Most systems evaluate rules from the top to the bottom of the list.
When writing rule sets were matching order matters the easiest way of understanding what your rule set actually does is to put related rules together in the list with what the user wants to be the most specific at the top.
Which is why most rule sets can be easily reordered.
It is true only a sub set of users are capable of writing and using rule sets with variable matching.
If you want a claytons rule priority then perhaps the rules should be shown sorted by the priority Manager uses. Total sting length then alphabetical would be readable and informative.
I did not include a screenshot of the rules allocating to the incorrect division/rule because I had already processed the transactions for June. But as stated in the original post, it was trying to allocate “BAC - Div on” to “C - Div on”, and “VTRS - Div on” to “S - Div on”. So the problem described does in fact occur prior to the update. The update seems to have fixed the problem based on the few test imports I just tried, so thanks @lubos. As for ‘best match’, as Lubos interpreted, I was meaning only in the case of a conflict. Obviously nobody would advocate for a ‘close enough’ match. But it is very sensible that where multiple matches exist, you would want some mechanism to pick between the two rather than having no control of that, or else one of your rules is rendered useless. And as for the lack of payee/bank account specified, this is because the descriptions across broker accounts are consistent so this prevents me having to create an exact duplicate of the rule for every broker account when that is not needed.
@Patch, dragging to sort is not an option. Maybe it is different on Windows or the online version, but on Mac that was not. Below is a screenshot from before I updated to the version with the fix. And anyway, Lubos’ solution is much more practical for anyone with any volume of rules. Between receipt and payments, I have 373 rules in one business, and another 242 in another (these were re-done after the split from ‘bank rules’, so they are not duplicates). And I’m sure there are many people with far more rules than that. Manually sorting those would be an absolute nightmare, especially as you add more over time.
