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?

15replies 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.

    Reply Like
    • 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: 

      /budgets/{budget_id}/payees?match=payee
      Reply Like
    • 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.

      Reply Like
  • 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.

    Reply Like
    • 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 api@youneedabudget.com with these details so we can dig it on it? Thanks!

      Reply Like
    • 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!

      Reply Like
    • 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 :)

      Reply Like 1
    • Gerben Meijer Glad it's working!

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

      Reply Like
      • George
      • Developer
      • george_ynab
      • 7 mths 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?

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

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

    Reply Like
    • 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!

      Reply Like
    • 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. 

      Reply Like
    • 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.

      Reply Like
Like Follow
  • 7 mths agoLast active
  • 15Replies
  • 626Views
  • 4 Following