[Kmymoney] KBanking plugin transaction dates

[Allan]

On 06/08/12 07:57, Thomas Baumgart wrote:
> 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?

Sorry, Thomas, I didn't express myself clearly enough.

What I meant was that the user may need to know that that amount has 
been 'spent', so needs to be taken into account when considering his 
further spending.  However, that would be catered for by the actual date 
he enters on the transaction initially.  His possible concern would only 
come once the bank statement is matched and his date has gone.

I don't know if that is a real issue to do with his accounting or tax 
needs, but not for my personal case.  It may really just be a personal need.

Allan

>
>>    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 ;)
>
>
>
> _______________________________________________
> KMyMoney mailing list
> KMyMoney at kde.org
> https://mail.kde.org/mailman/listinfo/kmymoney
>