Why do this?

[Thomas Baumgart]

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


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
-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
If debugging is the process of removing bugs, then programming
must be the process of putting them in. -- Edsger W. Dijkstra
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 225 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20161205/e1dea124/attachment.sig>