matching transactions

[Thomas Baumgart]

On Freitag, 28. Februar 2020 19:45:56 CET Thomas Baumgart wrote:

> 
> On Freitag, 28. Februar 2020 18:38:52 CET Jack wrote:
> 
> > On 2020.02.28 03:29, Thomas Baumgart wrote:
> > > On Donnerstag, 27. Februar 2020 22:16:51 CET Jack wrote:
> > > > On 2020.02.27 14:54, Michael Hirmke wrote:
> > >>> as the manual states, "The values of both transactions must be the  
> > >>> same for the match to work" when manually matching transactions.  
> > >>> The same seems to be the case when kmymoney tries to match  
> > >>> automatically. So there is no way to match scheduled transactions  
> > >>> with transactions from my bank where the amount differs every time  
> > >>> like my loan? If so what is the preferred way? Deleting the  
> > >>> scheduled transaction after the record has been received from the  
> > >>> bank?
> > > > >
> > >> I have my scheduled transactions set to not enter automatically, and  
> > >> I generally adjust the amount for the current value when I do enter  
> > >> it, so it does match.  You can also change the amount after both  
> > >> transactions are entered/downloaded and then match them manually.  
> > >> However, I don't think the end result would be much different from  
> > >> deleting the scheduled transaction once the bank transaction has  
> > >> been imported.
> > > 
> > > It might make a difference when the scheduled transaction contains  
> > > splits (assignments to multiple categories).
> > > 
> > > KMyMoney should be able to cope with varying amounts during the match  
> > > operation. I know that my phone bill has varying amounts and it  
> > > matches perfectly well every month. One requirement for that to work  
> > > is that you mark the option "Amount is an estimate because it varies  
> > > for each payment" for the schedule.
> > I've actually always wondered what the practical effect of this option  
> > was for, since if you manually add the transaction, you have to make  
> > the change in amount yourself.
> > > 
> > > The trick might be to not enter the scheduled transaction (manually  
> > > or automatically) but let the import do it (not sure if that is  
> > > documented). In case no match was found in the ledger of the account  
> > > during the imported, KMyMoney searches for (over-) due schedules and  
> > > if one of them matches it enters it directly while performing the  
> > > match.
> > So my new understanding is that if this option is checked, and the  
> > import finds the (over)due  scheduled transaction, it will add the  
> > transaction and match it to the amount of the imported transaction.  If  
> > you manually add the scheduled transaction prior to the import, it will  
> > fail to match because the amounts are different.  If that is the case,  
> > then I can certainly improve the description in the handbook.
> 
> I can certainly verify that (a few transactions are ahead during the beginning of the month.

Just did that:

Yes, that's exactly what happens. I have a schedule over 35,59 (even split
into expense and VAT - 29.90 and 5.69). Now the transaction is downloaded
from the bank with an actual amount of 35.82. The match happens and the splits are
adjusted to 30.10 and 5.72 since the auto VAT assignment with 19% VAT
takes place. I know, 5.69 is not 19% of 29.90 but that does not matter
here. All automatic and no manual intervention. The amount in the schedule
is not changed, just the date of the next occurrence.

Hope that makes sense and is understandable.

-- 

Regards

Thomas Baumgart

https://www.signal.org/       Signal, the better WhatsApp
-------------------------------------------------------------
If you're watching an Apple store being robbed,
does that make you an iWittness? - unknown source
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 868 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kmymoney/attachments/20200228/8364be9b/attachment.sig>