[Kmymoney] KBanking plugin transaction dates

[Allan]

On 05/08/12 23:30, Jack wrote:
> 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.

It could be me, and it is getting pretty late, but I see this as needing 
two transactions, with different dates.  You write a check and enter its 
date and payee, as a transfer to virtual account.  Then, a few days 
later, the bank statement's version is entered into the virtual account, 
still showing the payee, and treated as a transfer to your checking 
account.  Admittedly, you lose the category detail, but otherwise it 
does seem to work, as I look at it.  As I say, though, I don't have need 
of such a fine degree of detail.

> 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

Allan