No Payee matching for API-created transactions

Or whatever that's called... Here, have a screenshot:

 I'll admit I haven't tried specifying Import ID yet (since the function is originally for import, maybe it's only working with import id?), but I believe it should work anyways?

19replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Dmitriy Kartashev - Payee Renaming Rules are only processed for imported transactions.  A transaction is only considered imported if it has an import_id specified.  So, if you want these to be used, you'll want to specify an import_id.  This is indicated in the spec, although it is a bit tricky to find.  If you click 'Model' to view the model details, you'll see the description on the payee_name field.

    • Brady I do want to implement Import_Id generation later, but it's really not on the short list of features I have yet to implement (god, even such a simple app as mine requires a LOT of work, and spare time is really scarce).  You probably remember from a neigbouring topic that I develop an SMS-based import.

      I would ideally want to match YNAB rules (so other imports could work in parallel with mine), and the last number of the format is the hard part - on Android you'll have to persist the map of amount-number to disk, so it's kept between reboots and things like that. Not really hard, but sort of time consuming. Also, will have to think about potential conflicts with other types of import.

      I also found that import_id persists through deleted transactions - so if I imported a transaction, deleted it from UI, and then reimported it, it won't show - I'm not sure if there's a real use case for that, but it certainly messes real-life testing up.

      So, while import_id is a feature with low benefit (my app doesn't really create doubles) and high bug potential, the payee-name matching is highly desirable - without it the SMS-import automatization  is not that different from manual work, since I have to rename and categorize every transaction by hand (BURGER KING 007 is really not what i want to see in my budget). I already have an app version suitable for my personal use - my bank's setting are hardcoded while I work on the UI, so that's my actual pain right now :)

      Maybe you would implement a Payees endpoint parameter? Like that: 

    • Dmitriy Kartashev If you don't need to worry about duplicates (and it sounds like you don't), you could just use a simple unique id for import_id for now.  Maybe just a UUID.  This way the transaction would be treated as imported and Renaming rules would be used.  Then you could circle back later and change the implementation so that import_id is deterministic (i.e. YNAB:-294230:2015-12-30:1), to prevent duplicates.

      Thanks for the suggestion for adding support for Renaming Rules through the API, so that they can be looked up.  I'll add that to our list for consideration.

  • Brady sorry to resurrect an older thread, but I'm doing exactly this and matching doesn't seem to work entirely correct with API created transactions, or I'm running into a different but similar bug.

    Here's an example transaction (uses a Python lib for YNAB):

                      {'account_id': 'XXXXXXX-YYYY-AAAA-BBBB-CCCCCCCC',
                       'amount': -10750,
                       'approved': None,
                       'category_id': None,
                       'cleared': None,
                       'date': '2018-12-31',
                       'flag_color': None,
                       'import_id': 'YNAB:-10750:2018-12-31:1',
                       'memo': 'Ikea REDACTED '
                               '19:30 Transaction: REDACTED Term:REDACTED  ',
                       'payee_id': None,
                       'payee_name': 'Ikea REDACTED'},

    It imports fine, and the import ID works too - manually imported CSV transactions are not getting duplicated using my code.

    When I edit the imported unapproved transaction by double-clicking it, setting a category and hitting Approve, it works just as if it's a CSV import.

    But when a transaction is already properly categorised (so I guess it does some matching), and i click the (C) icon to the right of it to clear it without editing it,  the Payee gets cleared out and is blank for the cleared transaction. I then have to edit the transaction and fill in the payee that it just cleared out.

    Same thing happens if i select an imported unapproved transaction and go Edit > Approve.

    This is not good obviously because if matching is working well, all I would have to do is just to approve a transaction without editing it. But now I have to edit every single transaction to ensure it's not clearing out the Payee.

    • Gerben Meijer That's strange. It does sound like there might be a bug that is happening with some combination of data. Since this looks like it might be specific to your budget, can you send an email to [email protected] with these details so we can dig it on it? Thanks!

    • Brady I've noticed it doesn't happen with the Android app. Pretty weird.

      I'll shoot an email when I can find some time to reproduce, thanks!

    • Brady I've tried to reproduce just now, but it's not happening anymore in the web gui. So either something was fixed or it's spooky action at a distance :)

      Like 1
    • Gerben Meijer Glad it's working!

    • Brady It's returned. I've recorded a video, will email a link.

      • George
      • Developer
      • george_ynab
      • 2 yrs ago
      • Reported - view

      Gerben Meijer Brady recently found and fixed an issue affecting transactions created via the API. The fix will go out in tomorrow's (Thursday, 3/28) push to production. After that, could you test it out again and let us know what you find?

    • George Tested, still reproducable. Will mail Brady directly with some json excerpts from my budget :)

      Like 1
  • Brady Sorry for also bringing up an old thread. I'm creating an integration that will import pending transactions into YNAB based on certain criteria. The thing I'd like to have happen is that my imported transactions act like user imported transactions, so that when they clear the bank, the bank import matches them and marks them as cleared after I approve. Now, I understand this is a capability that already exists, but like the original poster, I don't want BURGER KING #466 as a payee in my budget. I'd like the renaming rules to get applied when I import. I don't want to have to use an import_id because that makes the bank import stop working correctly. It no longer matches from bank import when there is an import_id. Therefore, I have to either A) Turn off bank import for this bank and just check if all my transactions have cleared after the month OR B) Manually match the transactions to the ones that I import through the API.

    • Heisenberg I understand what you are trying to achieve there and I think you have at least a couple of more options to consider:

      1) Leave the payee blank for the transactions you create through the API.  Or, you could use the memo field to keep track of the "pending" payee.  When the transactions are imported on the linked account the payee will be set based upon your rules.

      2) You could pull your payees from /budgets/{id}/payees and then do some logic on your side to decide which existing payee(i.e. BURGER KING rather than BURGER KING #466) to use for the transactions you are creating through the API via the payee_id value.

      I hope this helps!

    • Brady I suppose the first one is viable other than just being a tad confusing when looking at the imported transactions. The second one is a lot of work and a lot of maintenance. It would be nice to just use the logic for renaming that I already have built up over time in YNAB. 

    • Heisenberg - This is an interesting use case and I think what you're doing is pretty clever.  But, I think most users that create transactions through the API are not also relying upon YNAB importing them as well (Linked accounts) so it might be a bit of an edge use-case.  I'll give this some thought about how we might be able to accommodate something like this but I would recommend using one of the above work-arounds in the meantime.

    • Brady I'm also doing this, and I don't really like the suggested workarounds.  I'm guessing since this is 2 years old there's no chance something could be implemented to make this work better?  I'd even take an endpoint to get a matching payee id given a string before submitting the transaction.

    • Aaron Smith Payee rename rules are only processed for imported transactions (import_id specified).  This is how the web and mobile clients work as well.  My understanding is that you want to use the API to create transactions but also still allow transactions to automatically import from your bank and to use the payee rename rules rather than the using the payee you originally specified when creating the transaction through the API.  Is that right?  If so, yes, this is not supported.  But, we can add a request item to create a new endpoint for the payee rename rules.

    • Brady Yes, this is what I wanted.  Just having access to the payee name rules either through a search or included on the payee object would work.  Do I need to submit a request in a form somewhere or will you be creating it based on this forum post?

    • Aaron Smith You can submit a request here.

Like2 Follow
  • 7 mths agoLast active
  • 19Replies
  • 718Views
  • 5 Following