Hello Dawid,

> woob doesn't really work as my bank isn't supported and having double factor authentication, I'm not sure it can work out.

woob certainly does support 2FA/OTP authentication, you should be able to find plenty examples both real and in documentation.

I might take another look at it, but frankly it looks more complex than learning KMymoney plugins! I also like to learn a bit more the internal of KMyMoney since I did want to contribute to it for a long time, just hard to find time these days, so this is kind of a first step into it for me.


Also, you may find this interesting: https://invent.kde.org/office/kmymoney/-/issues/25
That's for sure a great solution to my feature request and would be happy to see that coming in the software.


On Wed, Jul 27, 2022 at 4:52 AM Jonatan Cloutier via KMyMoney-devel <kmymoney-devel@kde.org> wrote:

    Thank for the follow-up

    Le 2022-07-26 à 15 h 55, Thomas Baumgart a écrit :

    Jonatan,

    On Dienstag, 26. Juli 2022 04:57:31 CEST Jonatan Cloutier via 
KMyMoney-devel wrote:

    Hello, I'm looking at a way of automatically pulling data in my KMyMoney
    files. I already have the source data, but I'm now trying to find a way
    to get it automatically into the KMyMoney file. The main requirement is
    that I would highly prefer not to take manual action from KMyMoney.
    Which source format does your data have?

    The original src is a bit of anything, mainly web scraping, but
    might be REST API calls as well if I get this working, then I can
    produce whatever format fit my need. As a quick workaround I'm
    doing csv, but that still needs a lot of manual processing to
    avoid duplicate transaction.

    All in all the reason for this is that my bank is getting worse
    every year at producing meaningful ofx files that just need way
    too many manual fix after import (more info available in that
    feature request: https://bugs.kde.org/show_bug.cgi?id=452392 ) and
    furthermore, there is no export feature for loans and investments
    which are quite cumbersome to manually update, in particular the
    later. And to put a cherry on top, exports are limited to 30 days,
    which I frequently miss the dead line!

    woob doesn't really work as my bank isn't supported and having
    double factor authentication, I'm not sure it can work out.

    After all that being said, two main questions: 1. Is it possible to run
    a background listener/task in a plugin as described above? 2. Any other
    suggestion on how to script custom data modification automatically?
    I don't know how much knowledge of programming in C++/Qt you bring along.
    The background listener is probably not so easy to implement. A way to solve
    your problem might be to construct a KMyMoney statement file in an external
    tool. It's XML formatted and used internally by KMyMoney by all the 
importers.
    AFAIR, there is a mechanism to start KMyMoney with an importer file as 
argument
    and it will import it into the last opened KMyMoney file. If KMyMoney is 
already
    running it will use the so called WebConnect feature to import it into the
    already running process. In any case, you would need to have KMyMoney 
running
    and this is only supported with a graphical user interface.

    So, maybe you can elaborate a bit about your (programming) skills and the 
operating
    system you are using.

    I'm on archlinux, been developing for years mainly in java and
    pythons but do have a bit of experience in c++ and did use QT for
    some very old project.

    I've seen the webconnect features from the main, since it's not
    limited to just the ofx importer I've been thinking that a custom
    importer could do the job, but haven't really thought of using the
    statement format as it doesn't seem documented. But if that enable
    doing the transaction import without modal, I suppose it could
    work. Closest to documentation I found is MyMoneyStatement::read
    function and its surroundings. I also see that there is a write
    method, is it possible to export in that format? It would just be
    quicker to get all the right xml structure.

    I will investigate more on that possibility, might be easier than
    creating a new importer and in the end, I think it could be close
    to my hopes in terms of usability.

    Quickly looking at that read method, I do have two questions:

    * Are the m_accountId in the statement and in the split required
    to be internal KMyMoney id or they can be inferred like from ofx?
    I suppose they are the internal Id

    * Similarly, are both part of the split needed to be filled or is
    there a way in the import that the automatching of paye and
    categories and scheduled transaction would work like an ofx import?

    Thanks again.



--
Best Regards,
Dawid Wrobel

Reply via email to