This new tag, for use in Expense accounts, will assist in collecting
data for filing Form 990 Schedule I (for USA domestic grants) and
Schedule F (for foreign grants).
An example of an invoice for a conference where the income type is split
between RBI and Donations. Include a ledger reporting example that
shows the total of donations, and explain in the documentation why
that's useful.
We've concluded that the top-of-hierarchy account name for Expenses
should be Expenses, not Expense. This change normalizes the tutorial
text and examples to Expenses.
This now enforces what was said in the documentation in the previous commit:
The `TaxImplication:` tag is used for all `Asset:` accounts when the
transaction includes a payment of $10.00 or more leaving the
account. .... An [`Entity:` tag](entity-tag) should always go along with a
TaxImplication tag.
Thus, I factored the text regarding the linking to documents that was in the
Expense account section into the section on describing the tags themselves,
and then merely linked back to that.
Since this system relies so heavily on tagging, even though we assume the
reader is generally familiar with Ledger CLI, it's worth ensuring they know
the basics of how tagging works.
Also added herein is the example used in the text over to the Ledger file
itself.
I realized that it makes more sense, even if it does create extra files, for
the accounts, commodities and tags declarations of the project to be
carefully split into different files. It's definitely more didactic to have
separate files for these declarations, to note that they are, in fact,
separable.
More to that point, users who cut-and-paste from this project into their own
setup will likely be least interested in the chart of accounts, which is
likely to be the longest file by far. The tags will probably be the most
interesting, so it's important they are in a stand-alone file that can be
easily found.
The Statement, Receipt, and Invoice tags' values should always a be a
relative path names. Note that we "check", but do not "assert" that the file
name match a standard Unix-like path syntax, without spaces in the file name.
