[Kmymoney] KBanking plugin transaction dates

[Thomas Baumgart]

On Monday 06 August 2012 00:12:44 Allan wrote:
> On 05/08/12 22:53, Jack wrote:
> > On 2012.08.05 18:35, Allan wrote:
> >> On 05/08/12 20:58, Rob Tongue wrote:
> >>> On 08/05/2012 08:55 AM, Jack wrote:
> >>>> I have the same issue.  For credit cards, the bank uses the posted
> >>>> date, not the actual transaction date.  I prefer the transaction
> >>>> date,
> >>>> so I know when I actually purchased something or ate the meal. 
> >>>> For
> >>>> checking account, I want the ledger to have when I wrote the
> >>>> check,
> >>>> not when it cleared the bank.  I suppose it would be an
> >>>> enhancement
> >>>> request (low priority) to actually keep both dates - original
> >>>> transaction date and institution cleared/posted date.
> >>>> 
> >>>> Jack
> >>> 
> >>> Jack, I agree. Maybe put the date the bank gives in the comment
> >>> section
> >>> of the transaction and keep the manually entered date?
> >> 
> >> To some extent, this is actually a more general issue than just
> >> KBanking.

Yes, somehow.

> >> A similar situation arises with many transactions.  For instance, you
> >> mey have a scheduled transaction that gets entered on one date, but
> >> the QIF/CSV imported date is different.  A while ago, someone was
> >> actually dealing with it, or thinking of, having another virtual
> >> account, acting as an intermediary account, enabling both dates to be
> >> kept.
> >> 
> >> Allan
> > 
> > Yes - this affects any import where you match a transaction entered
> > manually or by a schedule.  I'm not sure I understand why a virtual
> > account would help.  In the long run (which would require a modification
> > to the underlying transaction object) KMM could keep both dates.  In the
> > short run (just a modification to the matching code, but beyond what I
> > could do) if the two dates were different, the one not used could be
> > added to the memo.  A bit better would be to add a configuration item
> > (or even just a pop-up on import) asking which date to keep.  I suppose
> > I'll think about writing it up as an enhancement request.
> > 
> > Jack
> 
> This is one of those things where it comes down to personal
> preference/requirement.
> 
> For my own, simple, purposes, it doesn't really matter one way or the
> other.  However, another user might have a real need to know when a sum
> has been transferred out of his account, but the bank statement differs.


That should not happen. Why would a bank statement show one date for the 
transaction, but the bank has processed it at a different date? I've never 
seen that happen. Does anyone else has noticed that happen?


>   So, he transfers that sum to the virtual account, and he knows that
> his real account contains a lesser amount.  When (s)he gets the
> statement, that gets matched against the virtual account.  And the
> converse for a scheduled/manual income event.  It could be that the
> there are tax implications too, but that's not something I am bothered
> about.

Another solution that I am using to some extent is to setup a one-time 
scheduled transaction in those cases that I don't know when the transaction 
will really happen and let it sit there running into the overdue status. Once 
I get an update from the bank the date will be correct.

This of course requires to watch the balance including the scheduled 
transactions.

> Again, I've not thought this through in any depth as I don't have any
> real issue.

+1, I just threw in a single cent of my own. There might be another one to 
come to get to the total of my 0.02 ;)

-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
My software never has bugs.
It just develops random features ... -- anonymous
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 225 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kmymoney/attachments/20120806/18af10a0/attachment.sig>