i do not know when this problem appeared but i noticed only now after updating.
i have only one custom field in the tab and i am not sure if any other tabs are affected (i personally did not find problems in Sales Invoice tab which has a similar custom field).
it would be a great help if you can fix the issue without the user requiring to edit all the invoices again and enter the correct info manually.
I cannot reproduce this behavior with version 19.9.48 on purchase invoices or any other type of transaction. Numbers entered into a single line text custom field are treated as text and appear in the tab listing and on completed transactions exactly as entered.
@sharpdrivetek, to clarify, did this happen only to previously existing purchase invoices? Or did it also happen when creating new purchase invoices prior to today, then begin behaving properly? And are the old transactions still misbehaving?
If it was the first situation, I won’t be able to test it, because I had no regular single line text fields into which I had previously entered numbers. I did, however, have some purchase invoices with line-item custom fields containing numbers. They display exactly as expected. So, if the situation is the second one, it seems to be confined to regular custom fields on purchase invoices.
@Tut like i have mentioned in my initial post, new entries created with version 19.9.48 behave properly. only the older transactions are affected.
yes.
yes.
i did not edit and save the older transaction again with the correct numbers to check whether it would behave properly because it would be meaningless if it was a bug and would reoccur again in the future. so i would like a comment from @lubos on this.
below is a screenshot from an earlier backup file which when imported to 19.9.48 shows the correct data.
That is puzzling. The same version of the program produces different results from what were originally the same entries in the database. This suggests that the “installed” version of your data file was corrupted at some point. Using it produces the error for previously stored data. But new transactions with the same program version are not corrupted.
Likewise, an uncorrupted backup shows no errors when imported to the same program version. That seems to rule out a program bug in the current version.
One possibility is that a previous update restructured the database. (Some, but not all, do that.) The corruption might have occurred then, affecting the installed data file. When you import the old backup to v19.9.48, however, you bypass the program version that corrupted the file, and the database is converted properly. Only @lubos will know which versions included database restructuring and whether one of them might have introduced this corruption, then been superseded by a functional conversion process.
You might gain insight on this hypothesis by looking at your application data folder. Superseded versions of data files are not deleted after conversion. They will remain, but their dates of last modification will stop changing.
there are no two versions of my business in the app data folder.
my only option now is to edit and save all the transactions with the correct data as it would be easier than reentering all the recent transactions. but i would like to have a confirmation from @lubos if such errors would reoccur in case it is a bug and is overlooked.
