Ideally, but that wasn’t the case until just a few days ago.
OP never had this information before his work was ruined.
Anyway, @lubos the biggest issue facing manager right now is an update or a feature ruining virtually unlimited amount of work, and the perpetual setup is only making things worse in this regard.
I really feel for @ibdek right now. Regardless of whether his original entry was erroneous or not, no one should ever suffer for a mistake that didn’t use to be a mistake a day ago. Your government cannot illegalize cigarettes in 2021 and then lock you up for all the cigarettes you smoked since 2000, that’s unfair.
Anyway, I hope some measure are put in place such as:
Preserving the integrity of user input (Cannot overstress this). The new validations should only work on the entry form level and NO CHANGES should ever be made unless the user deliberately presses Update. Manager needs to be more robust.
If an update renders a previously entered transaction invalid, the transaction should remain invalid untill the user changes it themselves. Manager should only warn the users of existing invalid entries (something like Recurring Transactions notifications would do).
Every update that changes the data structure, object relationships, validations or forms should come with an auto-backup. That should remain available untill all issues are fixed.
Keep the columns or fields that should have been deleted as redundant backup for a while. They shouldn’t be used but they should be available just in case something goes wrong. Much like a recycle bin for columns.
In case manager cannot provide any data security measures, I believe the perpetual concept should be dropped in favor a periodic setup that allows the user to split and archive previous periods so they never have redo everything with every major update.
The way I see it is that you should look into previous exports or batch update files and perform a batch update.
Another possible solution is to find most recent backup before this situation took place and download a compatible previous desktop version. You can correct for inconsistent customer discrepancies in the receipts and payments in that file and use them to batch update you live accounts. This should save you a great deal of time.
Idk if there’s any better solutions at the moment.
I’m thinking what should have upgrade script done differently. Change customer on receipt to Other where different customer is used on receipt and different on line items?
This way customer on receipt would not override customer on line items. Anyway, upgrade scripts are not deleting any information and everything is preserved and correctable.
This is probably a good time to review that policy.
I backup my data files automatically every 15 minutes with intra daily backups keep for 2 weeks, daily backups for 1 month, weekly backup for 6 months, monthly backups indefinitely. Test data restore is done less often.
You will loose your data at some time. Work out how much it will cost you when it happens then spend wisely to minimise long term cost.
Thanks. Please Is there a faster way to get the list of receipts with different customer in the receipt and on the line items? It is not easy to be opening every receipt and change to others for numerous customers with thousands of transactions from Aug. 2020! If I can generate only receipts entries with different customers in line, then I can possibly work it out.
There are many more aspects to running a computer system than just installing user programs. A backup system is one component, contingency plan for when some thing fails, layers of malware protection is another.
To back up your data files you need back up software. Many packages are available depending if you run virtual of physical servers or a stand alone desktop system. Available software varies with operating system, operation complexity and required functionality. Local and off-site backup is strongly advised (three copies is the minimum).
Map old data to any new data structure in a manner which avoids (or at least minimises) any change to account balances
Alert the user where changes to existing record has been required (eg enter an error message in a custom field for that record).
Ideally historical results of published reports should be saved (static values) then the history tab on reports could then be used to display differences to the current dynamic data. So behave a bit like a reconciliation but for a report. I would mostly use this to quantify user changes but the mechanism would also pick up program changes.
A possible way of achieving that in this instance maybe
In practice thinking of all potential changes, providing a translating to any new implementation and reporting all potential error for all program updates, is only ever going to be partially achievable. The difficulty of this task is exacerbated by the creative ways some uses will exploit program idiosyncrasies.
A difficult balance. Really to only way to be sure no changes adversely effect any user is to not make any program changes.
I don’t think that that would be possible because no one really wants to put a ceiling on manager’s growth. There’s going to be changes and there’s going to be incompatibilites.
However, you can help the users adapt as painlessly as possible by doing a few things:
Preserving user inputs as much as possible.
Ensuring backward compatibility for at least 1 month back. So users can reopen their data in previous version and make any necessary changes.
Manager should identify invalid data entered which clash with any default or calculated values or have been overriden. These invalid entries should be tracked and prompted to the user.