Very strange problem. Could be the result of the QIF import, though. The opening balance transaction should not have a payee assigned (which seems to be the case in your environment). Which version of KMyMoney are you using?

Try the following:
a) open the ledger of the account
b) edit the opening balance transaction and remove the payee information
c) save the transaction
d) try changing the date again via the account edit dialog

(In reply to Thomas Baumgart from comment #1)
> Very strange problem. Could be the result of the QIF import, though. The
> opening balance transaction should not have a payee assigned (which seems to
> be the case in your environment). Which version of KMyMoney are you using?
> 
> Try the following:
> a) open the ledger of the account
> b) edit the opening balance transaction and remove the payee information
> c) save the transaction
> d) try changing the date again via the account edit dialog

Thanks for your prompt response.
None of the transactions carried any payee information from the QIF import, so there is no payee information to remove for the opening balance transactions.
The strange things is out of the 200+ accounts that were created, only some have this problem and others seem to reflect the opening dates/balance/behavior fine.
The only common thing I have identified so far is they are all part of the split transactions. So I have also tried to 're-assign' the parts of transactions referencing these trouble accounts to newly created ones, but for some reason it still won't let me save the transaction, giving the error that the date of the transaction predates the account opening.
I'm using the Version 5.1.80-b29cd34c4 on a Windows workstation/desktop.

First, or those accounts which show this problem, do you actually see a transaction in the ledger prior to the account opening date?  

Next, when you reassign a split in one of these suspect transactions, is there a correct/real payee in all of the splits?  Is that transaction date prior to the account opening date?

(In reply to Jack from comment #3)
> First, or those accounts which show this problem, do you actually see a
> transaction in the ledger prior to the account opening date?  
> 
> Next, when you reassign a split in one of these suspect transactions, is
> there a correct/real payee in all of the splits?  Is that transaction date
> prior to the account opening date?

All the problem accounts have the opening date equal to the date of the import, resulting in all transactions in that account technically falling prior to the account opening date. The transactions appear in the ledger but I'm unable to edit them in the corresponding ledgers giving me the error that the date of the transaction is prior to the opening date.

For the second question, like I mentioned, the QIF import did not import any of the payees. All ledgers display the following columns (No, Date, Description, Increase, Decrease, Balance) i.e. No Payee column. Not sure if that's the default/normal behavior. While I would ideally liked to have the payee information transferred, I'm OK if that's not possible.

Also, if it helps since the error has the same reference number as the original error relating to account modification, any time I try to duplicate ANY transactions, I get the following error:
Unable to duplicate transaction(s)
Details
Unknown payee ID: P000258 C:\_\9b0777e7\kmymoney\kmymoney\mymoney\mymoneyfile.cpp: 1742

I want to mention two things here (which may not solve the problem but may be important):

a) 5.1.80-b29cd34c4 is drawn from the (currently unstable) master branch and
b) the QIF importer is rather old code which has not seen any changes lately and may need a bit of overhaul.

On top of that, one needs to keep in mind that QIF is not standardized and there are many interpretations. This could lead to some interesting scenarios (which we have seen already in the past).

What puzzles me is the fact, that there seemed to be information about payees but now they are gone. This could be a problem of the unstable branch but I am not sure about it.

@Hamdsa: It would be cool if you can craft a demo QIF file based on your existing data (just a few transactions would be enough) that show the problem, anonymize the data contained and attach it to this bug. This way, we can try to analyze and hopefully resolve the problem. Also, it would be very helpful if you can check if the stable version 5.1.2 behaves differently wrt to your specific data. BTW, the payee's name will show up in the detail column as the first item if present. What does the transaction form contain in the payee field when a transaction is selected in the ledger?

(In reply to Thomas Baumgart from comment #5)
> I want to mention two things here (which may not solve the problem but may
> be important):
> 
> a) 5.1.80-b29cd34c4 is drawn from the (currently unstable) master branch and
> b) the QIF importer is rather old code which has not seen any changes lately
> and may need a bit of overhaul.
> 
> On top of that, one needs to keep in mind that QIF is not standardized and
> there are many interpretations. This could lead to some interesting
> scenarios (which we have seen already in the past).
> 
> What puzzles me is the fact, that there seemed to be information about
> payees but now they are gone. This could be a problem of the unstable branch
> but I am not sure about it.
> 
> @Hamdsa: It would be cool if you can craft a demo QIF file based on your
> existing data (just a few transactions would be enough) that show the
> problem, anonymize the data contained and attach it to this bug. This way,
> we can try to analyze and hopefully resolve the problem. Also, it would be
> very helpful if you can check if the stable version 5.1.2 behaves
> differently wrt to your specific data. BTW, the payee's name will show up in
> the detail column as the first item if present. What does the transaction
> form contain in the payee field when a transaction is selected in the ledger?

I can definitely try alternative versions. Is 5.2 available for Windows platform as that's what I currently have. It seems for Windows I have the following options to choose from:
kmymoney 5.1-1122 (Stable)
kmymoney-master 1240 (Currently using I believe)
ksmoney 5.0.6.8.1

Let me know which version do you recommend me to do my testing and I'll get back. I'll work on the sample file and will upload it once I test it on the different version that you recommend. Thanks for your help.

(In reply to Hamdsa from comment #6)
> (In reply to Thomas Baumgart from comment #5)
> > I want to mention two things here (which may not solve the problem but may
> > be important):
> > 
> > a) 5.1.80-b29cd34c4 is drawn from the (currently unstable) master branch and
> > b) the QIF importer is rather old code which has not seen any changes lately
> > and may need a bit of overhaul.
> > 
> > On top of that, one needs to keep in mind that QIF is not standardized and
> > there are many interpretations. This could lead to some interesting
> > scenarios (which we have seen already in the past).
> > 
> > What puzzles me is the fact, that there seemed to be information about
> > payees but now they are gone. This could be a problem of the unstable branch
> > but I am not sure about it.
> > 
> > @Hamdsa: It would be cool if you can craft a demo QIF file based on your
> > existing data (just a few transactions would be enough) that show the
> > problem, anonymize the data contained and attach it to this bug. This way,
> > we can try to analyze and hopefully resolve the problem. Also, it would be
> > very helpful if you can check if the stable version 5.1.2 behaves
> > differently wrt to your specific data. BTW, the payee's name will show up in
> > the detail column as the first item if present. What does the transaction
> > form contain in the payee field when a transaction is selected in the ledger?
> 
> I can definitely try alternative versions. Is 5.2 available for Windows
> platform as that's what I currently have. It seems for Windows I have the
> following options to choose from:
> kmymoney 5.1-1122 (Stable)
> kmymoney-master 1240 (Currently using I believe)
> ksmoney 5.0.6.8.1
> 
> Let me know which version do you recommend me to do my testing and I'll get
> back. I'll work on the sample file and will upload it once I test it on the
> different version that you recommend. Thanks for your help.

Further Update.
I went ahead and downgraded to KMyMoney Version 5.1.2-499b3cfc7.
Got much better results. About 1900 consistency checks errors related to posting date being earlier than account opening dates, vs. over 3000 with the latest version. The big change was that I am able to modify the account opening dates and proceed with the clean up now vs. before where it was stuck. It also imported a number of payees, doesn't seem like it's everything but still better than none which was the case with prior version. I'm going to manually start cleaning up the data.
Thanks for your help.