There is no way to associate covered/forwarded transactions and their original transactions

[erfanio]

I use the cover transaction feature to draw down from different pools of money. Recently I've been looking for a way to categorise my uncovered transactions (transactions drawing down from the main transaction account).

The API provides two separate transactions when something is covered but no relationship is provide between them. It would be useful to have a field under relationships to be able to link the two transactions.

My proposal is to add a new field called "coveredTransaction" and include the transaction ID (or transaction's canonical link so it's clear this transaction was covered by another account.

    {
      "type": "transactions",
      ...
      "attributes": {
        "status": "SETTLED",
        "rawText": null,
        "description": "Cover from X",
        ...
        "amount": {
          "currencyCode": "AUD",
          "value": "24.00",
          "valueInBaseUnits": 2400
        },
        ...
      },
      "relationships": {
        "account": { ... },
        "transferAccount": {  ... },
      },
      ...
    },
    {
      "type": "transactions",
      ...
      "attributes": {
        "status": "SETTLED",
        "rawText": "XYZ",
        "description": "XYZ",
        ...
        "amount": {
          "currencyCode": "AUD",
          "value": "-24.00",
          "valueInBaseUnits": -2400
        },
        ...
      },
      "relationships": {
        "account": { ... },
        "transferAccount": { "data": null },
        //
        // Add a new field here called "coveredTransaction" pointing to the other transaction above
        //
      },
      ...
    }

[aleayr]

This issue is something that I'm finding quite challenging not being in the API.

Use case:
I'm pulling out transactions, and then listing whether they're covered or not. In my families world for our budget, all transactions should be covered.

Sometimes, a couple of scenarios happen:

1. We miss a transaction to be covered in the app interface; or
2. An unexpected expense occurs/occurs earlier than expected.

In scenario 2, this means we don't cover the transaction immediately because there aren't the funds in the appropriate saver to cover it, but they will be there within a pay-cycle or two.

In both cases, we want to track via a spreadsheet what transactions haven't been covered.

At the moment - the solution I have is a bit of a hack due to limitations in the filter options as well. I have to attempt to find a match using the amount

1. Pull list of transactions since last query time
2. Store all transactions in a data structure like an array.
3. Initially display all records that are not object.attributes.cardPurchaseMethod = null.
4. Search array for each transaction looking for transactions that contain description starting with "Cover from" and have a value that matches the original transaction.

This test really only infers that the original transaction may have been covered, it's not definitive. I've been tripped up by multiple independent transactions of the same value for previous transactions as well.

It would be much nicer if there was an entry on the original transaction like the roundUp or cashback fields:
covered: true | false

Then a relationship structure entry to link them together (and an associated relationship on the created cover transaction).

Also, if there is another way of achieving this, I'd be all ears.

[aleayr]

Does anyone from Up actively monitor this repo? This feels like a big ommission that there is no linkage/reference that a transaction has been covered and how.

[aleayr]

We're coming up for a year since this really useful enhancement was proposed by @erfanio. Not a single response other than adding a feature request label? Is Github the best place to engage with improving the API or are there better channels? Understand you're busy developing - but why have a public Github if you're going to ignore it?

[aleayr]

@d11wtq and @levibuzolic Tagging Chris and Levi directly as you're pretty much the only Up team who comments/tags/approves anything on Github.

Is there any update on this or any other feature request for the API? Been over 2 years without a response - and not a lot of responses to requests broadly.

Would be really useful to be able to programmatically confirm that a transaction is covered, but also feeling like the API isn't much of a priority.

[markbrown4]

Does anyone from Up actively monitor this repo?

It's been a bit neglected. Sorry for the tumbleweeds @aleayr and thanks for your patience.

Exposing covers / forward is now planned, no ETA but it'll happen. Better late than never.

[aleayr]

@markbrown4 Hey Mark, appreciate the reply. Great to see some love on this.

[aleayr]

@markbrown4 Going to be a bit cheeky, since I saw you updated #133 with some updated attachment relationships to notes, thought I'd nudge this one for a covered relationship ;) Seriously though, pumped to see a change to the API again.

[markbrown4]

It's a bit more involved this one, but it's next on the list of planned features.
Think it'll look something like this.

Transaction

{
  relationships: {
    coverOrForward: {
      type: 'covers',
      id: '1'
    }
  }
}

GET /covers/:id

{
  attributes: {
    status: 'completed',
    direction: 'cover' | 'forward',
    creation_method: 'customer_initiated' | 'interest_forwarding' | 'auto_cover',
  },
  relationships: {
    sourceTransaction: {
      type: 'transactions',
      id: 1
    },
    transferDebitAccount: {
      type: 'accounts',
      id: 1
    },
    transferDebitTransaction: {
      type: 'transactions',
      id: 2
    },
    transferCreditAccount: {
      type: 'accounts',
      id: 2
    },
    transferCreditTransaction: {
      type: 'transactions',
      id: 3
    },
  }
}

[aleayr]

Looks really solid! interest_forwarding as a creation_method is intriguing too. Love your work Mark and team.

[markbrown4]

There's a setting under Round Ups > Combine Monthly Interest which auto-forwards all your interest to 1 saver.