leolabs/you-need-a-parser

Format request/Question: YNAB 4 transaction export

Closed this issue · 3 comments

Proposal

Add YNAB 4 transaction exports as supported format. I'll happily provide a PR for it if you think it's worth adding support here, @leolabs.

Context

We (meaning @malfynnction and me) are working on Envelope Zero, an envelope & zero based budget tooling that is self-hostable.

As we want to support many banks to import from without reimplementing all parsing logic, we did some research into existing parsers. Since I remembered ynap from earlier tries to finally migrate away from YNAB 4, I looked into it more.

We think using the ynap-parsers package in the Envelope Zero frontend is a good idea since it will enable us to support many different banks instantly.

It will allow us to focus on writing only two parsers in Envelope Zero (one for the YNAB 4 Budget format to import past budgeting and one for the YNAB CSV import format) while also contributing any new formats we want to support to YNAP.

Sounds good, feel free to open a PR for the YNAB 4 format!

@leolabs While preparing to implement this, I noticed a key difference in the YNAB 4 export and the YNAB (Cloud) CSV import format: The YNAB 4 export has a Cleared field showing the cleared/reconciliation status of a transaction.

As this concept also exists in Envelope Zero, we'd want to preserve this field. This is obviously not supported by YNAP as it does not make sense for bank imports and would probably even break compatibility for the YNAB (Cloud) import.

I have an educated guess that you'll want to stick with the YNAB (Cloud) CSV import format as the only supported format to keep the YNAP code as simple as possible. Am I right with this guess?

In that case, I'd close this issue and keep it around for documentation (as well as implement the import support directly in Envelope Zero).

I attached an export of my YNAB 4 testing budget for anyone interested to inspect.

Test as of 2022-09-22 918 PM-Register.csv

I dug deeper into this and came to the conlusion that it would indeed not be viable to add support for YNAB4, as it would only parse a subset of the information that is needed to import YNAB4 exports to other tools.