Good day,
Is there a way to export my payees and categories to files, then import them into a new calendar year data base?
I would like to see a simple way to do year end reconciliation - copy all unreconciled transactions, along with account balances, payees, categories, recurring transactions, etc. to a new data base.
Thanks in advance
Export Categories and Payees for new Calendar Year: SOLVED
Moderator: Renato
-
- New User
- Posts: 6
- Joined: Thu Jun 13, 2019 4:29 pm
- Are you a spam bot?: No
Export Categories and Payees for new Calendar Year: SOLVED
Last edited by akmmex on Tue Dec 17, 2024 6:20 pm, edited 1 time in total.
-
- Senior User
- Posts: 24
- Joined: Tue Feb 09, 2021 6:08 pm
- Are you a spam bot?: No
Re: Export Categories and Payees for new Calendar Year
Take a look at viewtopic.php?p=23252&hilit=archive#p23252
Might I suggest that you do not _need_ a new database for each future year. But if you feel more confident having one then I would suggest that at the end of the current year that you copy the current MMEX file into an archive for that year - say 2024 - after you do your year end reconciliation and lock the archive file for that year and continue using your current MMEX file. So at some future date there will be archive files for 2024, 2025, .... and the archive files will contain all the transactions, categories, payees, and other entities for for the year associated with that archive and earlier. That is to say that the archive for 2024 has entries for 2024 and earlier, the archive for 2025 has entries for 2025 and earlier, etceteras.
Now when you create an archive file for a given year - say 2024 -you might think that you might save some space by deleting all the transactions earlier than 2024-01-01 and later than 2024-12-31 but you will not because in the case of relational database entities are rarely deleted but rather are marked as deleted and remain in the database but are not visible for normal operations - to actually physically delete items from the database requires SQL update mode processing which would have to take place outside of MMEX and require some SQL expertise and should not be attempted by the inexperienced or the faint of heart.
Best wishes.
Might I suggest that you do not _need_ a new database for each future year. But if you feel more confident having one then I would suggest that at the end of the current year that you copy the current MMEX file into an archive for that year - say 2024 - after you do your year end reconciliation and lock the archive file for that year and continue using your current MMEX file. So at some future date there will be archive files for 2024, 2025, .... and the archive files will contain all the transactions, categories, payees, and other entities for for the year associated with that archive and earlier. That is to say that the archive for 2024 has entries for 2024 and earlier, the archive for 2025 has entries for 2025 and earlier, etceteras.
Now when you create an archive file for a given year - say 2024 -you might think that you might save some space by deleting all the transactions earlier than 2024-01-01 and later than 2024-12-31 but you will not because in the case of relational database entities are rarely deleted but rather are marked as deleted and remain in the database but are not visible for normal operations - to actually physically delete items from the database requires SQL update mode processing which would have to take place outside of MMEX and require some SQL expertise and should not be attempted by the inexperienced or the faint of heart.
Best wishes.
-
- MVP User
- Posts: 866
- Joined: Mon Apr 25, 2011 7:36 pm
- Are you a spam bot?: No
- Location: near Zurich
Re: Export Categories and Payees for new Calendar Year
I would save the database under a different name.to actually physically delete items from the database requires SQL update mode processing which would have to take place outside of MMEX and require some SQL expertise
In this database, select and delete all entries under “All transactions”.
Subsequently, it might be useful to go to Tools/Database/Optimize Database.
Renato Forum Administrator (I'm not a developer)
-
- New User
- Posts: 6
- Joined: Thu Jun 13, 2019 4:29 pm
- Are you a spam bot?: No
Re: Export Categories and Payees for new Calendar Year
Thank you!
Perhaps not the most elegant solution, but it is effective. I am OCD, and prefer to have each year's transactions in a separate data base.
I do notice that after deleting the previous year's transactions, and optimizing the new data base, I can't set the opening date balance in the new data base to this year, it shows 'transactions before opening date' error.
But my main problem is solved.
Thanks again
Perhaps not the most elegant solution, but it is effective. I am OCD, and prefer to have each year's transactions in a separate data base.
I do notice that after deleting the previous year's transactions, and optimizing the new data base, I can't set the opening date balance in the new data base to this year, it shows 'transactions before opening date' error.
But my main problem is solved.
Thanks again
-
- MVP User
- Posts: 866
- Joined: Mon Apr 25, 2011 7:36 pm
- Are you a spam bot?: No
- Location: near Zurich
Re: Export Categories and Payees for new Calendar Year: SOLVED
Have you permanently deleted the bookings under “Deleted Transactions”?
Renato Forum Administrator (I'm not a developer)
-
- New User
- Posts: 6
- Joined: Thu Jun 13, 2019 4:29 pm
- Are you a spam bot?: No
Re: Export Categories and Payees for new Calendar Year: SOLVED
Renato,
I had not deleted them. After deleting and optimizing the data base, it is approx. one-half size.
Thank you again,
Dave
I had not deleted them. After deleting and optimizing the data base, it is approx. one-half size.
Thank you again,
Dave
-
- MVP User
- Posts: 866
- Joined: Mon Apr 25, 2011 7:36 pm
- Are you a spam bot?: No
- Location: near Zurich
Re: Export Categories and Payees for new Calendar Year: SOLVED
This should now also work with the opening balance.
Renato Forum Administrator (I'm not a developer)
-
- New User
- Posts: 6
- Joined: Thu Jun 13, 2019 4:29 pm
- Are you a spam bot?: No