[Kmymoney-devel] Re: Matching Transfers

[allan]

On 01/10/10 09:26, Thomas Baumgart wrote:
> Hi,
>
> on Thursday 30 September 2010 19:53:26 allan wrote:
>
>   
>> On 29/09/10 11:19, allan wrote:
>>     
>>> On 29/09/10 00:51, allan wrote:
>>>       
>>>> On 28/09/10 23:22, allan wrote:
>>>>         
>>>>> I remember there was a problem some time back with the 'big bang' QIF
>>>>> import, where a transfer occurred between two banks - the transactions
>>>>> became duplicated when the the second bank account is imported, showing
>>>>> the other end of the transfer.
>>>>>
>>>>> I still have a bit of an issue with this, and how best to resolve it. 
>>>>> A category can't be assigned because neither an expense nor an income
>>>>> is involved, and if the 'opposite' account is inserted, this causes the
>>>>> duplication.
>>>>>
>>>>> It would seem to me to be best to match the two transactions, but
>>>>> presently this is not possible, because they are both imports.
>>>>>
>>>>> Could someone explain to me, please, why two imports can't be matched?
>>>>> I've never understood the rationale behind this.
>>>>>
>>>>> Allan
>>>>>
>>>>> Back again.  Sorry for this, but there is an issue here.
>>>>>
>>>>> It occurs when importing two bank statements, one from Bank A including
>>>>> a transfer to Bank B, and the other including the opposite end of that
>>>>> same transaction.
>>>>>
>>>>> 1) Import file A.
>>>>> 2) Check that all is correct and accept the transactions.
>>>>> 3) Import File B.
>>>>> 4) Account B, assign the transaction in question to Account A.
>>>>> 5) In Account A, attempt to match the two associated lines.  Matching is
>>>>> not possible.
>>>>>
>>>>> If step 2 is omitted, matching is possible.
>>>>> If step 2 is kept, but step 4 is reversed, so the item in Account A is
>>>>> assigned to Account B,then matching is possible.
>>>>>
>>>>> I think this is why I sometimes have a difficulty, and I suspect it must
>>>>> relate to the status of the transaction getting changed.  In step 2,
>>>>> accepting the import presumably changes the status from imported.
>>>>> Attempting matching against that will now fail.  However, if that
>>>>> transaction is matched against the one in Account B, which has not yet
>>>>> been accepted, then all is well.
>>>>>
>>>>> I don't know if this is a bug, but if it is not, then the user
>>>>> instructions have to be very clear about the steps needed to accomplish
>>>>> what seems a fairly trivial exercise.  There are pitfalls.
>>>>>           
> Yes there are. I noticed that stuff from time to time myself and did not have 
> a clue what was going on. The problem here: I do those two imports in one via 
> online banking. So step 2 is not even possible for me.  I want to revisit the 
> use cases in the matching area but currently have limited time resources 
> available to do so. Here's what I do to get out of this (it's a bit awkward 
> but it works for me):
>
> 1) import both accounts (A comes in first, B second)
> 2) accept all imported transactions in A and B
> 3) simply delete duplicate unmatched transactions in A
> 4) rerun the import
>   
Between 2) and 3), how did the matching occur?  Is that part of the HBCI
import process?  With QIF and CSV, both statements are only 'self-aware'
and don't know what other account/s or institutions may be involved, so
there is a necessary manual matching step needed.

What I'm now doing is:-

1) Import Account A.
2) Identify transfers and assign to them Account B. (A now in order)
3) Import Account B.
4) Matching will occur during import. (B now in order)
5) Accept both accounts.

This seems to be OK, so far.

> explanation:
>
> 1) leaves two transactions in A (one matched and one not) and one in B 
>   
> (matched)
> 2) Not sure, if it's necessary, but I usually do it that way
> 3) This will ensure, that in step 4) the transaction is not detected as 
> duplicate
> 4) This step now matches the transaction against the one that is already 
> present and I am set.
>
>   
>> I'll ask again, my original question.
>>
>> "Could someone explain to me, please, why two imports can't be matched?
>> I've never understood the rationale behind this."
>>     
> I really can't remember, but at some point in the history of the project we 
> kept an import ID with the transactions for detection of duplicates. Later on, 
> we moved that piece of information into the splits. Having the ID with the 
> transaction does not allow to store two of them (which is the case when both 
> transactions are imported). Maybe, the limitation is not valid anymore, but I 
> am not sure about that right now.
>
>   
>> In fact, why can't the user be allowed to match any two transactions he
>>  needs to ?
>>     
> I don't see that right now either. But to avoid breaking anything I suggest to 
> dive into the code and check what is going on behind the scenes before making 
> any promises to change things.
>
>   
I don't suppose it's hugely important.  Perhaps, on some future rewrite!

Thanks for listening.

Allan