When we send checks, we don't have a check document anywhere (for
security reasons), we just note the check number. Update the
validation to match. RT#10507.
The main impetus of this change is to rename accounts that were outside
Beancount's accepted five root accounts, to move them into that
structure. This includes:
Accrued:*Payable: → Liabilities:Payable:*
Accrued:*Receivable: → Assets:Receivable:*
UneanedIncome:* → Liabilities:UnearnedIncome:*
Note the last change did inspire in a change to our validation rules. We no
longer require income-type on unearned income, because it's no longer
considered income at all. Once it's earned and converted to an Income
account, that has an income-type of course.
This did inspire another rename that was not required, but
provided more consistency with the other account names above:
Assets:Prepaid* → Assets:Prepaid:*
Where applicable, I have generally extended tests to make sure one of each
of the five account types is tested. (This mostly meant adding an Equity
account to the tests.) I also added tests for key parts of the hierarchy,
like Assets:Receivable and Liabilities:Payable, where applicable.
As part of this change, Account.is_real_asset() got renamed to
Account.is_cash_equivalent(), to better self-document its purpose.
Because these are the classes that get instantiated many times while
iterating transactions, the performance benefit of defining __slots__
is worth the development overhead.
The main motivation for this change is to make sure that higher-level
code deals with the fact that self.units.number can be None, and has
an easy way to do so.
I'm not sure all our code is *currently* doing the right thing for this
case, because I'm not sure it will ever actually come up. It's possible
that earlier Beancount plugins fill in decimal amounts for postings
that are originally loaded with self.units.number=None. I'll have to see
later whether this case comes up in reality, and then deal with it if so.
For now the safest strategy seems to be that most code should operate
when self.units.number is None.
I'm getting to ready to extend this hook to deal with income receipts as
well as expense receipts. These changes let me write the tests in a more
declarative style, so I don't have to duplicate them all again to test
credits as well as debits.
Note that we're only testing debits right now, just like the existing tests,
because the default check_type for check() is PostType.DEBIT. Part of making
the changes will be changing that to PostType.BOTH.
These were tightened up by running mypy with --disallow-any-generics
and cleaning up reported errors.
There are still a couple of cases I don't know how to deal with
right now that prevent me from setting that option permanently:
* plugin/__init__.py sets up a dict where the key is a Directive
and its value is a set of hooks that correspond to that type
of directive. The relationship between key and value is not
expressable through the type system, and any other solution would
make the code way more involved and less dynamic.
* The type variable used in _GenericRange still isn't quite right,
in the sense that specifying a value for CT creates more errors
I don't know how to deal with. Protocols seem like the right
solution for that but they apparently didn't land for Python 3.7
that I can see.
Mostly this meant giving annotations to low-value functions like
the error classes and __init_subclass__, but it's worth it for
the future strictness+documentation value.
This just returns a constant for now, but we know it may need to be
configurable in the future. Other code can start using this now
to be configurable in the future.
I wasn't too worried about this earlier because the cache mainly stores
a bunch of numbers, but there's a little more than that: the generated
URLs also include original attachment filenames, which might be sensitive
(referencing people's names, bank names, etc.). Tighten security
accordingly.
