Renaming Rules Apply...But Don't Un-Apply
If I create a renaming rule, then realize it's applying too broadly (it was a mistake), then I change the renaming rule, making it more specific, it looks like things that were renamed stay that way.
If that's so I want a reality check. Is the only way to fix this to go in and hand-fix (manually) all the payees that were wrongly renamed??
If this is so, is there a way to tell Simplifi: Please, please reset everything to the way it was and then reapply all my payee rules. This would fix my problem without my having to manually examine and fix potentially hundreds of transactions!
Comments
-
@AchaarLonache, thanks for posting!
Aside from the 'Undo' prompts that appear after certain actions, there is no way to undo a change that took place. However, selecting to apply a Transaction Rule to past transactions should apply even if the Rule is being edited vs. created. Have you tried deleting and recreating the Rule instead, by chance? You can also do a bulk edit of the transactions in question on the Web App for a fast resolution:
Let us know how it goes!
-Coach Natalie
0 -
I get this. It needs fixing, because the way the product works now, a user can make mistakes that let them accidentally wipe out a lot of information. Sometimes bulk edits can fix the problem.
But the correct solution (and I hope a future enhancement to allow this) is for Simplifi never, ever to destroy or delete information as a result of applying naming rules. At most, it should hide information, so that it can be retrieved. Ideally, I should be able to reset everything to its original values, if I want and then reapply naming rules.0 -
@AchaarLonache You may want to vote on this idea post here
Anthony Bopp
Simplifi User Since July 2022Money talks. But all my paycheck ever says is goodbye0 -
The way developers should conceptualize the fix here is not to back up anything or auto backup.
The original payee value should never be deleted in the first place. It should remain a hidden or otherwise secondary field, so that a rogue naming rule can be undone by simply reapplying rules to the original.
Right now it’s too easy to ruin years of work with a bad rule.0 -
It would also be useful if the original payee should also be included as a column in the csv file when you export transactions. You could use the csv file to help identify a problem if you make a mistake with payee rules or mass editing. (You can open it in a spreadsheet to sort or filter columns and see the severity of your mistake.) An undo option is only useful if you know immediately when you make the mistake, and a "restore backup" option is only useful if you did not want to undo all other edits since you made the mistake.
For some reason, the original payee appears as a link at the top of the Transaction Detail dialog when you edit a transaction, so it must be saved somewhere but there is no way to restore it
0 -
@brokenchord - there is an open feature request for more robust CSV exports. I voted for this. In the meantime, I connected my open accounts to another free app to download the original payee data until Simplifi allows us to export original payees, displayed as "appears on statement as".
Simplifi User Since Nov 2023
Minter 2014-2023
Questionable Excel before 2014 to present
0 -
A workaround for this: If you are bulk editing, export to a CSV before starting the bulk edit process. Then, you can use what you used to have in the CSV to restore any lost information due to mistakes.
Simplifi User Since Nov 2023
Minter 2014-2023
Questionable Excel before 2014 to present
0 -
@UrsulaA , thanks for the reference to the feature request. I voted for it since I do like to keep my transactions backed up in CSV files and would like to capture as much of the data as possible. I'll have to remember to use your tip to save the CSV first if I do any more bulk editing.
0 -
Yes, @UrsulaA, I think the CSV export is clever, for sure. But cleverness like that indicates a fault in the product that should be fixed. Thanks everyone or upvoting the relevant feature request.
0
