I like the code change and especially as it's 'sympathetic' to my code.. So a nice addition, and I have incorporated it..... I almost made no changes, but I think there might be a slight (rare-iso) issue... When on a split record (your file line 6899-6905), we need to check self (txn), and potentially the parent (ParentTxn) rather than .getOtherTxn() - (I agree it's a brain twister)... I have amended this section. Could you take a look and confirm you agree? Perhaps you could run your version and mine on your dataset filtering the same data and confirm it's OK/the same? If so, and it works for you, I will release the amended / updated code....
Thanks for incorporating my changes, I aimed to be as consistent with your style and placement as I could :-)
I compared the number of rows outtputted by your code and by my code and they agree for seven scenarios covering category matching that included single-entry splits and multiple-entry splits.
I'm not sure why you're also checking whether the Parent Txn has a category account type of income/expense though. This is new to me so I'm probably missing something, but I thought that Parent Transactions are the source side of the entry and so the AccountType must be a Bank Account, Credit Card, etc? If a refund is processed resulting in a negative value against an expense category this is still registered on the Split Txn side, rather than the Parent Txn being of income/expense type and the value being made positive - I ran a check to confirm for my own satisfaction.
As a further check, I removed from your code the additional conditionals that include the check against Parent Txn (in two places):
isCategory(parentAccount) and categoriesFilter_EAR in (parentAccount.getFullAccountName().upper().strip()))
and re-ran the seven scenarios - the row counts were consistent with my earlier results. This makes me wonder whether my dataset is missing some types of transactions that yours has.
Can you help me with understanding under what circumstances a ParentTxn passed into isCategory can return true?
Hi Mark. As you probably know, categories are actually accounts. Thus you can actually have a category to category txn. In this case the parent would hold a category.
Now, I agree that the program pre filters txns for selected accounts, so probably a parent will never have a category using this filter. But future proofing in case we decide to also pre filter select categories too.
Given either side of a txn can be a category, it’s best to code for it in all scenarios whether receiving a split or a parent on a filtered txn. But it is also possible that you may not encounter this.
Ps. To test. You can go to the register for a category and enter a (parent) txn with a category set to an account; even with multiple splits. This would therefore be a parent which is a category and splits that are accounts. (In theory).
I'm aware that categories are classed as accounts but hadn't considered that transactions could be made directly between categories, or indeed what sort of scenario this type of transaction would be used for in practice.
Partly because for me it's not immediately obvious that such transactions can be made through the UI. I've now added an expense category to the side bar which has given access to the registry for that category and have now added a category to category transaction. Will try a test later with splits.
Do you know what category to category transactions are used for in practice? This functionality seems a bit hidden away to me, unless I've missed somewhere else they can be accessed through the UI.
My last post seems to have got lost and hasn't added to the thread.
Thanks for the explanation Stuart, what you say makes sense to me.
I hadn't thought that category to category transactions were a 'thing' in Money Dance. I've added an expense category to the sidebar and can now add a category-to-category transaction which I'll have a go testing with splits later on. Seems a bit hidden away this capability, is it achievable elsewhere in the UI?
Do you know what category-to-category transactions would be used for in practice?
Tools>Categories> highlight one > right click > Open in new window.
Create new Txn.
At this point if you use a category of an Account, then you will have a parent which is a category and a split which is an account.
Or just use a category, and thus you have a cat to cat txn.
IMHO - this can be dangerous as you can get 'lost' txns and they are difficult to find.
However, I do use them. I create a sub account under my main bank account called 'allocations' and I use cat>>cat txns to 'move' / 'allocate' costs from one category to another. The total always nets to zero. Hence, I can report on the account and / or include the sub account and include/exclude the allocations...
For what it is worth I do use category to category transfers. As Stuart said categories are really just a type of account, and Also to note as Moneydance is based on Double Entry accounting every transaction is just movement of funds between two accounts.
There are two situations I have used category to category transfers.
The first is for older versions of Moneydance where the Tax date was only used in very few reports. I would use accounting accrual techniques along with categories to ensure transactions were reported during the period when I needed them to rather than when they were actually paid.
Another time I use them are with things like funds and annual tax statements. The figures in the Tax statement are embedded in the data throughout the year, hence they have no value as far as the accounts are concerned but I pass them through the accounts in Moneydance using category to category transfers, so I can generate a Income and Expense report that contains needed information for Tax time.
I do the same thing with capital gains as well.
Moneydance has the flexibility to do this, but I concede you have to understand what is going on to keep everything in order.