[Kmymoney-devel] Re: Matching Transfers

[Thomas Baumgart]

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
> >>
> >> I'll have another go at this tomorrow/today.  Things may not be as they
> >> seemed.
> >>
> >> Allan
> >
> > After a night's sleep, and going slowly, there is no problem.  These
> > matching transactions can be matched, as, after adding the transfer
> > account name, the new transaction that appears in the other account is
> > not an import, and therefore can be matched.
> >
> > Sorry for the noise.
> >
> > 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

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.


-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
The beauty of standards is that there are so many to choose from.
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 225 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kmymoney-devel/attachments/20101001/e17983c2/attachment.sig