All transaction builders should be fully compatible with all readers

[GalmWing]

paycheck.Importer is strongly tied to multitable readers, the dependency on self.alltables is not evident, and it means that certain libreaders are not compatible with it.

In a general sense I think either:

1. Every transaction builder should be compatible with every libreader
2. There should be different base reader/importer categories and importers should adhere to their own category to ensure they are fully compatible

For example, for this combo of paycheck.Importer, csvreader.Importer, I must customize the code enough that I lose a lot of the goodness of the framework.

So far I think there are only 2 ways readers organize data:

1. as a single table/list of values
2. as multiple tables

Perhaps (2) is not strictly necessary to pass to the transaction builders, it could be converted to a single table. There could be ways to deal with any issue like potential name collisions between tables

[redstreet]

Very much agree. The paycheck transaction builder in particular could use some help in conforming. I haven't thought this in a while, but remember thinking a multitable data structure could become the standard output for readers, since single tables are covered by it too. Further design and/or PRs welcome.

[GalmWing]

I'm just getting started with beancount, so likely contributions are not going to be up to par until I have better understanding.
To unblock myself I wedged in a table into the multi table format, it's a hardcoded category, so it's not pretty, but is just a couple of lines of code. Though I did have to peruse the code to figure out there was a raw_rdr

class Importer(paycheck.Importer, csv_multitable_reader.Importer):
    def custom_init(self):
        self.alltables = {}

    def prepare_tables(self):
        self.alltables = {'<category>': self.raw_rdr}

[redstreet]

No worries. I'll leave this ticket open as a long-term improvement item until you or someone else can cook up a PR.