[Kmymoney] KBanking plugin transaction dates

[Jack]

On 2012.08.05 19:12, 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.
>>> 
>>> 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.  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.

I see that the virtual account can be used to track money in a  
"pending" state, which can certainly be useful.  However, once the  
amount does clear, or definitely ends up where it is going, you still  
have the problem of only a single date on the transaction, which  
doesn't help if you want to track both actions.  I don't think it would  
count as good bookkeeping to allow different dates on the different  
splits of a single transaction.  For a check, the payee split would  
have when I wrote the check, and the checking account would have when  
the bank actually released the money.  However, the transaction would  
no longer be "atomic" and I don't think that is allowed in proper  
double entry bookkeeping.

I think this really comes down to a "wishlist" and will wait until it  
either gets lots of votes,  or my coding in C++ gets much much better.

Jack