Can we support option for CSV export without multiple lines per split?

[whalley]

https://forum.moneymanagerex.org/viewtopic.php?p=23470

I am using MMEX since 2012 and I am very grateful for it as it has all the features I need.

However, this is my problem. I usually export the transactions as CSV at the end of every month and then run a python script to check them against that months bank statement (CSV) to see if I did not forget to input any spending. It used to work like a charm but at some moment in the past MMEX started to export not the whole sum but individual items (e.g. shopping for groceries, bought bread for 1, eggs for 1 and butter for 2, before I had date - 4, now I have date-1, date-1, date-2). I think it was around version 1.3.5

I solved this by exporting the database using the older version of mmex, but as the db is modernized now, it does not work anymore.

Is there a way how to export the database in the old way? I could probably revert to the old db and use the older version but it is not neat.

Thanks for any tips

[whalley]

Think this change in v1.5.3 https://github.com/moneymanagerex/money ... ssues/3319 improved the output to handle split transactions.

Perhaps what we could do, if CATEGORY AND SUBCATEGORY are not required in the CSV output then we could output a single line. I guess this is probably a logic thing to do.

[n-stein]

Can we just in general aggregate by the fields selected for output, e.g. you select just Date, Payee, Amount it will aggregate all transactions by those three fields only?

[whalley]

Can we just in general aggregate by the fields selected for output, e.g. you select just Date, Payee, Amount it will aggregate all transactions by those three fields only?

Not sure what you are saying by 'aggregate all transactions by those three fields only' what are you aggregating?

[n-stein]

Sorry, that was unclear. Basically, my thought is to aggregate $ fields on all non-$ fields selected for export.

Consider these transactions. Note that Transaction ID 2 is a split:

Suppose I choose ID, Date, Payee, Category, and Amount to export. With the current export, I would get 7 lines

You can see that some of the lines are identical, just with different amounts. I propose these identical lines should be aggregated:

So my export would actually have 5 rows:

As in the case of this issue, I still have a split transaction for ID 2. If I remove Category then the Amount would aggregate over ID, Date, and Payee leaving me with 4 lines (and no more split transaction):

Going further if you remove ID then you would aggregate on just Date and Payee leaving with only 3 lines:

And so on. Basically for the fields selected for export you should only see one unique line for each combination of attributes.

[whalley]

Understood. However we then lose the concept of a transaction, and I don't think we should be losing that.

E.g. if we think of the originators issue with reconciling the output from the CSV export with their bank account then the 3x Paycheck/Taxes transactions are lost.

[n-stein]

Isn't the whole point of the split transaction that it is truly a single transaction, just covering multiple categories? So the 3x Paycheck/Taxes transactions are already 1 transaction in their bank account, otherwise they would (or should) have entered 3 separate individual transactions instead of 1 split transaction. Aggregating by ID should 1-to-1 match the number & value of transactions in their bank account.

[tactilis]

I'd hazard a guess that, exporting CSV from MMEX and cross checking that with a CSV from the bank using your own script is a pretty niche way of doing things.

The OP could easily include the ID field in their CSV export and then do the aggregation in their Python script before comparing with the bank's CSV.

I'd venture that a much more common approach is for users to periodically (i.e. monthly/weekly/daily?) download a CSV or QIF from the bank and import the transactions into MMEX. You are then guaranteed to get all the transactions rather than having to make sure that your manual entry of transactions in MMEX matches the reality in the bank. Much less work overall IMO.

This latter approach will be even more popular if MMEX ultimately gets the ability to connect to bank feeds, which we have discussed elsewhere.

[whalley]

So the 3x Paycheck/Taxes transactions are already 1 transaction in their bank account

No I was thinking of the scenario like.... . I go the bar, buy a glass of wine using my debit card, then feel like another (they never give you enough!), so buy another on my card. Two transactions - same date, same payee, same category. I think what you are suggesting would aggregate these. Unless I'm missing something. This would not then match the bank transactions.

I'd hazard a guess that, exporting CSV from MMEX and cross checking that with a CSV from the bank using your own script is a pretty niche way of doing things.

Agreed.

The OP could easily include the ID field in their CSV export and then do the aggregation in their Python script before comparing with the bank's CSV.

Aggregating by ID should 1-to-1 match the number & value of transactions in their bank account.

Yes, I think with hindsight the best action would be for the user to aggregate by ID if they want a an aggregated amount.

[n-stein]

Two transactions - same date, same payee, same category. I think what you are suggesting would aggregate these.

Same date, same payee, same category but unique IDs since they are two real transactions, so if you include ID in your export they would not be aggregated.

[whalley]

Closing as originator is going to aggregate using the ID.