Bug 247528

This value is updated on KMyMoneyApp::slotAccountReconcileFinish(void)
I don't see anything in the code why it should update all accounts. Plus, I checked my file and the lastStatementDate is different or empty for all accounts.

The value is used at the beginning of the reconciliation wizard to get a date for the previous statement balance.

Tony, were you able to confirm whether this is a DB backend-only problem? 
I don't see any issues running thel XML backend.

Sorry, Alvaro, I missed your previous comment. It's the 'lastModified' date that's getting updated, not the 'lastStatementDate' (and not 'lastUpdated' as I said in the original bug). I haven't checked with XML yet, I keep forgetting! I'll try to remember next time...

I can confirm that this problem exists with XML files too. To reproduce:

1. unzip a kmy file and run
grep lastmodified=\"2010-09-01\" xyz.kmy (using today's date)

2. run kmm 4.0 against the file and only reconcile an account with a number of transactions

3. repeat step 1 - all category accounts involved in the reconcile have the lastmodified date updated; only the account being reconciled should be updated.

Actually, if a transaction within an account is modified, the lastModified date is updated.
According to the code, this is by design.

Then I would say the design is incorrect. This should be done at the level of the individual split, as was the case in the KDE3 version.

If I transfer money from Bank A to Bank B, I reconcile Bank A when I receive their statement, Bank B when I get theirs, so the accounts are actually last modified on different dates.

Tony, what I meant is that it is done at the split level, and it doesn't have anything to do with the reconciliation.

If a transaction is modified (added, modified, removed, etc), then all the splits accounts are modified. That's what I see in the code. I don't care why it is like this, but it seems to be this way from the KDE3 days.

I can confirm it was this way since KDE3.

This is an example of some of the relevant code in KDE3, which is similar in KDE4:

// adjust the balance of all affected accounts
  for(it_s = transaction.splits().begin(); it_s != transaction.splits().end(); ++it_s) {
    MyMoneyAccount acc = m_accountList[(*it_s).accountId()];
    acc.adjustBalance(*it_s);
    if(!skipAccountUpdate) {
      acc.touch();  <--- this updates the lastModified date of the account
      invalidateBalanceCache(acc.id());
    }
    m_accountList.modify(acc.id(), acc);
  }

Well I'm running KDE3 and KDE4 versions in parallel, and I definitely see a difference whenever I do a reconcile. Perhaps I'm misinterpreting what I'm seeing; I'll do a more careful check next time.

However, I still think it's incorrect in this instance to update all accounts in the splits. A reconciliation process affects only the account being reconciled (i.e. only the split relative to that account has its status changed). Also, reconciliation does not affect the account balance, so the above code should not be invoked (?)

AFAICT, that code doesn't have to do with reconciliation. 
The lastModified date is updated whenever a split belonging to the account is added, modified, removed.

That's exactly my point. Only the split relevant to the account being reconciled gets updated (status changed) so only that account should be touch()-ed. What I'm seeing is that accounts in all splits are being updated.

However, as I said originally, the lastModified date doesn't seem to be used anywhere in the application, so maybe it's not urgent.

This is up to Thomas to decide. 

Right now, all splits are touched. Since we don't have a granular way to track changes (yet), I'd say leave it the way it is for the moment.

Changing to wishlist, as this is working as designed.

If it is as designed, the design has changed since the KDE3 version. I agree that it's minor, but you must admit that it's incorrect; the only account that gets modified during reconciliation is the account being reconciled.

For the vast majority of transactions ('account' to 'category') it probably doesn't matter, since the lastModified date probably isn't relevant to categories. But for inter bank transfers, it could be relevant. As an example, some banks in the UK will freeze your account if you haven't used it for 2 years (and I know from experience that it's a PITA to get it unfrozen). So knowing when it really was modified could be relevant if someone were to write a plugin to flag the situation.

I'll say no more about it.

Tony, I've already shown you the KDE3 code where it does the same thing. I don't know when it was introduced, but it was before the port. That's something I want to make clear.

Then, in your example, the important date is the postDate, not the lastModified. The bank don't care when you last reconciled at home, but when the last transaction occurred according to the bank, which is represented by the post date. There is only a few situations where the entry date (when you entered the transaction in the application) actually matters.

Bug requested over 5 years ago.  Bug closed.