Bank Rules to Payments/Receipts Rules upgrade problem

Other topics talk about bank import rules not applying correctly when importing bank statement. My issue is slightly different in that I am not doing a bank import right now.

I have upgraded from 21.1.55 to 21.6.76. When I go into Payment Rules or Receipt Rules, I am seeing 58 rules in both tabs. So I am seeing all the payment rules in receipts rules as well as all the receipts rules in payments rules!

I have looked at a couple of rules and they are showing correctly as supplier, accounts payable for payment rules and customer, accounts receivable for receipts rules. So I can’t “fix” it as the rules are correctly, although clearly there is something wrong because the rules are showing in both tabs.

Batch Update doesn’t help either.

I noticed that as well, but I was hoping that that could be a sign of merging the rules back again. The split have doubled the work in many ways.

Guess I will have to wait till Lubos indicates whether this is a bug or not? I will delay upgrading my live version until I have heard back. I have only upgraded the test version to compare the differences.

I believe this was just the result of splitting bank rules without a method of determining which were intended to apply to receipts and which to payments. I believe the existing list was duplicated for both. There should be no harm, as you say customer and supplier allocations are showing correctly.

And why doesn’t Batch Update help? For that matter, if your problem is duplication, why not use Batch Delete? That is faster.

How? A rule that was originally designed to detect and post a receipt is not likely to work on a payment. So it will sit unused.

Maintain two sets of rules, cannot import cash registers in one go, go through two separate lists of uncategorized transactions.

Yes, you can. The program separates uncategorized receipts and uncategorized payments into separate lists. Yes, you now handle the lists separately, but both are readily accessible in the same place. I am not sure why that is more work than going through one list with a random mix of transactions and the potential to create new rules of the wrong type.

When I was looking at batch update, all I could see was the rule and the condition. I was expecting to see a column like payment rule or receipt rule or something.

So are you saying, all I have to do quite literally is delete the payment rules in receipts and vice versa? I don’t need to edit the rules in any way? I just assumed that the rule would have some filter tagging it as a receipt or payment in the backend database?

What is the reason for splitting the rules? I can’t say that I see any purpose to it.

Yes. Since you have a test business, it might be worth experimenting by deleting a couple rules and re-importing the statement, but that is the way I understand it to work. Manager can tell whether to apply receipt or payment rules by whether the transaction is a deposit or withdrawal. So no explicit tag is needed. Personally, I would not fiddle with Batch Update for this purpose.

Two that I see:

  • The tab was split, so it makes sense to split the rules, although I am not sure whether this was technically necessary.
  • The primary benefit is that you can design more specific rules. Previous bank rules had to take into account the fact that a bank might put different content into the statement file for deposits and withdrawals. So it could have happened that the program tried to apply a rule you designed with receipts in mind to a payment, or vice versa. For example, since banks basically put whatever they want onto various lines of the statement export file, the description might include a payee’s name. But you might have created a bank rule targeting online deposits from a payer with the same name. Now there are fewer potential conflicts. Imagine someone doing a both buying and selling on a PayPal account. Much easier now to design intelligent rules without having to consider your entire universe of both customers and suppliers.