Why do this?

[aga]

On 05/12/16 11:16, Thomas Baumgart wrote:
> Hi Allen,
> 
> I try to find an answer to your question. The problem here is, that the 
> importer (actually any of them, maybe except QIF in some circumstances) does 
> not provide enough information and KMyMoney tries to add the missing pieces 
> from data found in the transactions already on file.
> 
> Here's what happens: you import data from the bank. This will lead to one 
> split of the transaction. The other side is yet unknown. The statement reader 
> now goes ahead and tries to find some more information based on the payees 
> name. In your case it finds a split transaction assigned to that payee. It 
> takes the other splits of the stored transaction and adds a copy of them to 
> the imported transaction. Since the amounts are different, it shows the 
> unbalanced results you see. There is no way for KMyMoney to determine what to 
> do with the difference without user intervention. If the amount of the 
> imported transaction is the same as the one on file (e.g. my monthly paycheck 
> has 17 splits) this works like a charm.
> 
> If the transaction found on file is one that has only two splits it is easy: 
> KMyMoney takes the account information of the second split on file and assigns 
> the negated value of the imported split to it.
> 
> Hope that clarifies things.
> 
> Thomas
> 

Hi Thomas

Yes, that is more or less what I'd deduced, and I can see that it might
be helpful to pick up information from other transactions, but I can't
see how it helps to include the value of some other, arbitrary
transaction.  I've seen this and been confused in the past by strange
values being assigned.

If there are multiple splits in the 'other' transaction, they could well
be unchanging amounts that would need to be kept, but if there is only a
single split, presumably that amount would have to balance the primary
split, so that has little relevance in the new transaction, so why not
use the second split, as now, but use the negated value that came with
the new transaction?  I must say though that having the same payee name
presumably doesn't mean that that category will always be the same, so
has that any relevance?

I'm not really sure that trying to match in such cases is going to
produce a correct result.  Why not not have a second, possibly
irrelevant, split, and leave the user to do what he knows is needed,
without any distraction?

Allan



> On Sunday 04 December 2016 18:56:19 aga wrote:
> 
>> I'm puzzled again, or perhaps, just curious.
>>
>> Sometimes, when I import a CSV checking transaction, the ledger shows
>> the correct amount, but also shows the transaction as unbalanced.
>>
>> When I open the transaction, it shows as a split, but the amount is
>> different, and the difference shows as unassigned.  In fact, this new
>> amount is from another transaction for the same payee, but in this case
>> occurring four months later.
>>
>> If I edit the amount shown in the split dialog, all now appears as
>> correct, but why is this necessary, when the correct amount is already
>> at hand?
>>
>> In mymoneystatementreader.cpp(), from circa line 1076, there is a comment, -
>> "Fill in other side of the transaction (category/etc) based on payee..."
>> and -
>> "We'll search for the most recent transaction in this account with
>>       // this payee.  If this reference transaction is a simple 2-split
>>       // transaction, it's simple.  If it's a
>> completransactionUnderImportx split, and the amounts
>>       // are different, we have a problem.  Somehow we have to balance the
>>       // transaction.  For now, we'll leave it unbalanced, and let the user
>>       // handle it."
>>
>> So, it's not difficult for the user to correct, but why?  It just seems
>> to be unnecessary work.  What has been achieved?
>>
>> Allan