<!-- NB any links not defined as aboslute will not resolve on PyPI page -->
# beanahead
[](https://pypi.org/project/beanahead/)  [](https://github.com/psf/black)
Beanahead administers future transactions for [beancount][beancount] ledgers.
It let's you:
- Generate regular expected transactions.
- Define ad hoc expected transactions.
- Reconcile expected transactions against imported transactions.
It's useful to:
- Forecast account balances based on expected income and payments.
- Add transactions between updating accounts.
## Installation
`$ pip install beanahead`
The only direct dependencies are `beancount`, `beangulp` and `pandas` (pandas could be made optional, see [#1](https://github.com/maread99/beanahead/issues/1)).
Beanahead is compatible with both beancount v2 and v3.
## Really briefly, how it works
- Expected transactions are defined on separate ledgers.
- Newly imported entries are reconciled against expected transactions before being included to the main ledger (**beanahead does not need to touch your main ledger**).
## Briefly, how it works
- Regular Expected Transactions (electicity bill, rent, etc) are defined by including a single transaction to a dedicated beancount file, by convention 'rx_def.beancount'.
- The `addrx` command is used to populate a Regular Expected Transactions ledger with transactions. This ledger, by convention 'rx.beancount', is 'included' to your main .beancount ledger.
- ad hoc Expected Transactions are added to the Expected Transactions ledger, by convention 'x.beancount'. This ledger is also 'included' to your main .beancount ledger.
- The `recon` comamnd offers a cli to reconcile newly imported transactions with transactions on the expected transactions ledgers.
- Newly imported transactions are updated to reflect any missing narration, tags, meta and 'other side' postings defined on the corresponding expected transactions.
- Reconciled expected transactions are removed from their respective ledgers.
In keeping with the `beancount` spirit, `beanahead` provides all its functionality via a CLI (the underlying functions are available within the codebase should you prefer). There are five commands, all subcommands of `beanahead`.
```
$ beanahead --help
usage: beanahead [-h] [--version] {make,addrx,recon,exp,inject} ...
subcommands:
{make,addrx,recon,exp,inject}
make make a new beanahead file.
addrx add Regular Expected Transactions.
recon reconcile new transactions.
exp administer expired expected transactions.
inject inject new transactions.
```
> :information_source: Wherever this README shows the output from a `--help` option, only an abridged version of the output is shown. Run the command at the command line for the full help, e.g. `beanahead --help`. For subcommands the help includes the documentation of the underlying function.
# Using beanahead
## Index
* [Making beanahead files](#making-beanahead-files)
* [Regular Expected Transactions](#regular-expected-transactions)
* [Defining regular transactions](#defining-regular-transactions)
* [freq](#freq)
* [Postings](#postings)
* [roll](#roll)
* [final](#final)
* [Updating definitions](#updating-definitions)
* [Adding regular transactions](#adding-regular-transactions)
* [ad hoc transactions](#ad-hoc-transactions)
* [Defining the payee](#defining-the-payee)
* [Reconciling](#reconciling)
* [Matching](#matching)
* [Updating](#updating)
* [Injection](#injection)
* [Expired expected transactions](#expired-expected-transactions)
* [Worth remembering](#worth-remembering)
* [Options](#options)
* [Print to stderr](#print-to-stderr)
* [Custom account root names](#custom-account-root-names)
* [Alternative packages](#alternative-packages)
* [beancount recommendations](#beancount-recommendations)
* [Licence](#license)
## Making beanahead files
First off, you'll need to use the `make` command to create a new `.beancount` file or three.
> :information_source: You'll probably want these files to be in the same directory as your exisitng main ledger. The following examples assume you want to create the files in the current working directory. Pass the --dirpath (or -d) option to specify a different directory.
If you want to include Regular Expected Transactions you'll need to create a definitions file and a dedicated ledger....
```
$ beanahead make rx_def -f rx_def
$ beanahead make rx -f rx
```
...and add the following line towards the top of your main ledger.
```
include "rx.beancount"
```
If you want to include ad hoc Expected Transactions you'll need to create a separate dedicated ledger...
```
$ beanahead make x -f x
```
...and add the following line towards the top of your main ledger.
```
include "x.beancount"
```
So, if you want to include both regular and ad hoc expected transactions then you should have created three new `.beancount` files and added two 'include' lines to top of your main ledger.
> :information_source: The -f option provides for defining the filename (`make` will add the `.beancount` extension). If -f is not passed then default names will be used which are as those explicitly passed in the examples.
> :information_source: The quoted file in the 'include' lines should reflect the path to the expected transactions ledger from the directory in which your main ledger is located. The above examples assume that the expected transactions ledgers have the default filenames and are located in the same directory as the main ledger.
The [examples/new_empty_files](./examples/new_empty_files) folder includes a sample of each of the above newly created files.
- [Regular Expected Transaction Definitions file](./examples/new_empty_files/rx_def.beancount)
- [Regular Expected Transactions Ledger](./examples/new_empty_files/rx.beancount)
- [Expected Transactions Ledger](./examples/new_empty_files/x.beancount)
NB If you're not using the default account root names (e.g. 'Assets', 'Income', 'Expenses' etc) then you'll also need to use the optional --main argument to provide the path to a ledger from which beanahead can read the customised name options. Example:
```
$ beanahead make x -f x --main my_ledger
```
## Regular Expected Transactions
Regular expected transactions are defined on the Regular Expected Transaction _Definitions_ file. The `addrx` command can then be used to populate the Regular Expected Transactions _Ledger_ with transactions generated from these definitions.
### Defining regular transactions
A new regular transaction can be defined at any time by adding a single transaction to the definitions file (the 'initial definition'). The date of this transaction will serve as the anchor off which future transactions are evaluated.
The following initial definition would generate regular transactions on the 5th of every month, with the first generated transaction dated 2022-10-05.
```beancount
2022-10-05 * "EDISON" "Electricity, monthly fixed tarrif"
freq: "m"
Assets:US:BofA:Checking -65.00 USD
Expenses:Home:Electricity
```
Each initial definition must:
- have a **unique [payee](#defining-the-payee)**.
- include the [freq](#freq) meta field to define the transaction frequency.
- include at least two [postings](#postings) of which at least one should be to a balance sheet account ("Assets" or "Liabilities").
Initial definitions can optionally include:
- the [roll](#roll) meta field to define if transactions falling on weekends should roll forwards.
- the [final](#final) meta field to define the last transaction date.
- additional [postings](#postings).
- custom meta fields.
- tags
[rx_defs.beancount][rx_defs_initial] offers an example of a new definitions file before any transactions have been generated. The initial definitions there cover a variety of circumstances, based loosely on selected sampling of beancount's [example.beancount][beancount_example] ledger.
#### freq
The **freq** meta field is used to specify the frequency with which regular transactions should be generated.
A **simple frequency** can be specified as "w", "m" and "y", respectively for weekly, monthly and yearly. The unit can be prefixed with a value to specify a multiple, for example "2w" for fortnightly or "3m" for quarterly.
Alternatively, the frequency can be specified with a **[pandas frequency](https://pandas.pydata.org/docs/user_guide/timeseries.html#offset-aliases)**. For example "BAS-MAR" defines the frequency as the first business day of every March.
#### Postings
Each definition must include a posting to an account which the regular transactions will appear on the statements of. This can be an "Assets" account (for example, for Direct Debits) or a "Liabilities" account (for example, for regular charges to a credit card). If the amount is variable then just stick in an estimate or the amount that you wish to budget for.
At least one posting to an account on the 'other side' must be included (e.g. to an "Expenses" account). Any number of other postings can be included.
When the regular expected transactions are later reconciled with transactions imported from your statements, the `recon` command will update the imported transactions with these 'other-side' postings (see [reconciling](#reconciling)).
> :information_source: If the transaction is balanced with only one 'other-side' posting then you're better off not including an amount for it. (By including an amount, if the imported transaction has a different amount then you'll need to manually amend the posting on the updated imported transaction.)
> :information_source: If the transaction is split between various 'other-side' postings then it will be necessary to define an amount for at least all but one of these. In this case, if the imported transaction value differs from the expected transaction value then you may want to revise the amounts of those postings for which estimates were included.
#### Roll
By default, any generated transaction that would be dated on a weekend will be rolled forward to the following Monday. This behaviour can be overriden by the 'roll' meta field.
```
2022-11-13 * "ETrade Transfer" "Transfering accumulated savings to other account"
freq: "3m"
roll: FALSE
Assets:US:BofA:Checking -4000 USD
Assets:US:ETrade:Cash
```
The above initial definition is dated 2022-11-13, which is a Sunday. By specifying roll as FALSE the first transaction generated will be dated 2022-11-13 regardless that this is a Sunday. Thereafter transactions will be defined on the 13th of each month regardless of whether these dates represent weekdays or weekends.
> :warning: the roll field's value must be in captials and NOT quoted.
> :information_source: initial definitions should always be dated on the 'usual' payment day even if that falls on a weekend. For example...
> ```
> 2022-10-16 * "Verizon" "Telecoms, monthly variable"
> freq: "m"
> Assets:US:BofA:Checking -55.00 USD
> Expenses:Home:Phone
>```
> This initial definition is dated 2022-10-16 which is a Sunday. The first generated transaction will be automatcially rolled forward to 2022-10-17. All transactions thereafter will be dated as the 16th of each month whenever the 16th is a weekday or otherwise rolled forward to the following Monday.
#### Final
The 'final' meta field can be used to define a final transaction date. No transactions will be generated that would be dated later than this date (as evaluated prior to any rolling).
```
2022-10-31 * "Chase" "Chase Hire Purchase"
freq: "BME"
final: 2022-11-30
Liabilities:US:Chase:HirePurchase 322.00 USD
Assets:US:BofA:Checking
```
> :warning: the final field's value should NOT be quoted.
A definition will be automaticaly removed from the definitions file after any final transaction has been generated.
### Updating definitions
The `addrx` command updates the definitions file whenever the ledger is populated with new transactions:
- any definition for which a new transaction was generated will be updated to reflect the transaction that would immediately follow the last transaction that was added to the ledger.
- Defintions are grouped by balance sheet account* and type of account(s) of the 'other side', for example 'Income', 'Expenses' etc. Each group is introduced with a title row. Within each group definitions are sorted by payee. (*The balance sheet account is assumed as the first "Assets" or "Liabilities" account defined in the postings.)
> :information_source: New definitions can be added at any time anywhwere under the line ```;; Enter definitions after this line...``` - they'll find their way to the corresponding section when the file is next updated.
[rx_def_updated.beancount][rx_def_updated] is the updated [rx_def.beancount][rx_defs_initial] file after adding regular transactions to the ledger through to 2022-12-31. :warning: Notice that all comments are lost when a definitions file is updated.
### Adding regular transactions
The `addrx` command is used to populate a Regular Expected Transactions Ledger with transactions evaluated from a definitions file.
```
$ beanahead addrx --help
usage: beanahead addrx [-h] [-e] defs rx-ledger main-ledger
positional arguments:
defs path to Regular Expected Transactions Definition file.
rx-ledger path to Regular Expected Transactions Ledger file.
main-ledger path to main Ledger file.
optional arguments:
-h, --help show this help message and exit
-e , --end date to which to create new transactions, iso format,e.g. '2020-09-30'. Default 2023-01-11.
```
For example...
```
$ beanahead addrx rx_def rx ledger -e 2022-12-31
```
The above command:
- Gets the definitions from the file `rx_def.beancount` in the current working directory.
- For each definition, generates transactions from the defintion date through to '2022-12-31' (both inclusive).
- Adds transactions to the `rx.beancount` ledger.
- Updates the `rx_def.beancount` file (as [Updating definitions](#updating-definitions)).
- Verifies that the main ledger, `ledger.beancount`, loads without errors. The path to the main ledger is passed as the third positional argument (this ledger should be the main ledger to which the 'insert "rx.beancount"' line was added). `addrx` requires this file only to verify that no errors have arisen as a result of introducing the new transactions to the Regular Expected Transactions Ledger.
- In the event the main ledger loads with errors then changes made to the definitions file and Regular Expected Transactions Ledger are reverted and advices printed.
If the command is executed as above with the files in the [examples/defs](./examples/defs) folder then the empty rx ledger there will be populated with transactions. The rx ledger would end up as [rx_updated.beancount](./examples/defs/rx_updated.beancount) whilst the definitions file would be updated as [rx_def_updated.beancount][rx_def_updated].
## ad hoc transactions
Creating ad hoc expected transactions is as simple as adding transactions to an Expected Transactions Ledger created via `$ beanahead make x <filename>`. The [x.beancount][x_ledger] file offers an example (again, loosely based on selected sampling of beancount's [example.beancount][beancount_example] ledger).
Jotting down ad hoc transactions is useful to record transaction details 'in the moment' when you have in mind the 'other-side' postings and maybe know the narration or tag that you might forget by the time you next get round to downloading statements and updating your main ledger.
Transactions can be listed on the ledger in any order. Whenever a transaction on the ledger is reconciled with an imported transaction (extracted from a statement) the ledger is rewritten and any remaining transactions are reordered.
> :warning: Any comments will be lost whenever an Expected Transactions Ledger is rewritten.
## Defining the **payee**
The reconciliation of imported transactions with expected transactions ([reconciling](#Reconciling)) can be greatly aided by judiciously naming the expected transactions payee.
Beanahead will treat each 'word' defined in the expected payee as a separate string. An expected payee will match with the payee of any new transaction that includes **any** of those strings. So:
- Do not include short words that represent common syllables.
For example, "Top of the World" will match with "The corner shop", "Another Day" and "Super Offers".
- Use few unambiguous words. For example "Top World". Even just "Top" might be a better choice.
> :information_source: The transaction that ends up on your main ledger will have the payee as defined on the statement, not "Top"!
> :information_source: matches are case-insensitive
## Reconciling
The `recon` command provides for reconciling imported transactions with expected transactions.
```
$ beanahead recon --help
usage: beanahead recon [-h] [-o OUTPUT] [-k] [-r] new ledgers [ledgers ...]
positional arguments:
new path to new transactions beancount file. Can be
absolute or relative to the current working directory.
ledgers paths to one or more Regular Expected Transactions
Ledgers against which to reconcile incoming
transactions.
optional arguments:
-h, --help show this help message and exit
-o OUTPUT, --output OUTPUT
path to which to write updated new entries. Can be
absolute or relative to the current working directory.
By default will overwrite 'incoming'.
-k, --keep, --no-remove
flag to not remove reconciled transactions from ledgers.
(By default reconciled transactions will be removed.)
-r, --reverse flag to write updated entries in descending order. By
default will be written in ascending order.
```
For example...
```
$ beanahead recon extraction rx x -o injection
```
The above command:
- Gets beancount entries from the file `extraction.beancount` located in the current working directory. This file should contain only new entries as returned by the beancount `extract` command and destined for your beancount ledger.
- Gets the expected transactions from the ledger files `rx.beancount` and `x.beancount`, also located in the current working directory.
- [Matches](#Matching) expected transactions with new transactions.
- The user is requested to confirm or reject each propsosed match.
- Where an expected transaction matches more than one new transaction, the user is requested to select which of the new transactions to match (or none).
- [Updates](#Updating) matched new transactions with information gleaned from the corresponding expected transaction.
- Outputs the updated entries. By default overwrites the file passed as the `new` argument (`extraction.beancount` above). Alternatively, a path can be passed to the `--output` option, as in this case where output will be written to `injection.beancount` in the current working directory.
- Entries are by default sorted in ascending order. Pass the `-r` flag or `--reverse` option to sort in descending order.
- Removes reconciled expected transactions from their respective ledgers. (The `-k` flag can be passed to 'keep' the expected transactions.)
If the command is executed as above with the files in the [examples/recon](./examples/recon) folder and the matches are confirmed then:
- an `injection.beancount` file will be created that looks like [this](./examples/recon/expected_injection.beancount).
- reconciled transactions will be removed from [rx.beancount](./examples/recon/rx.beancount), such that it ends up like [this](./examples/recon/rx_updated.beancount).
- reconciled transactions will be removed from [x.beancount](./examples/recon/x.beancount), such that it ends up like [this](./examples/recon/x_updated.beancount).
### Matching
Beanahead matches expected with imported transactions based on:
- payee (see [Defining the payee](#defining-the-payee))
- similarity in accounts
- closeness of dates
- closeness of amounts
As a bare minimum, matches require that the new and expected transactions:
- are dated within 5 days of each other
- include a posting to the same Asset account
- either have matching payee or the imported transaction amount is no more than 2% different from the expected
If you want a better insight into how matches are evaluated, check out the [reconcile](./src/beanahead/reconcile.py) module to get under-the-bonnet.
### Updating
Beanahead will update the following fields of matched imported transactions to include any values specifed for the corresponding expected transaction. Any existing values on the imported transaction will **not** be overwritten.
- **narration**
- **tags** (excluding #rx_txn and #x_txn)
- **meta** (excluding beanahead meta fields such as 'final', 'roll' etc)
- **postings**
- postings on the expected transactions will be added to the imported transaction if the imported transaction does not otherwise include a posting to the corresponding account.
- if the imported and expected transactions include postings to the same account and only the expected transaction defines a number, the imported transaction's posting will be updated to reflect the value as defined on the expected transaction.
## Injection
The output from `recon` can be copied directly into your main ledger. If you're happy to append the full contents 'as is' to the end of your ledger then the `inject` command will do it for you.
```
$ beanahead inject --help
usage: beanahead inject [-h] injection ledger
positional arguments:
injection path to beancount file containing the new entries to be
injected. Can be absolute or relative to the current
working directory.
ledger path to beancount ledger to which new entires are to
be appended. Can be absolute or relative to the current
working directory.
```
So...
```
$ beanahead inject injection my_ledger
```
...would append the updated entires in the `injection.beancount` file to the end of the `my_ledger.beancount` file (both files in the current working directory).
## Expired expected transactions
Now that your main ledger has been updated with the new entries it'll be necessary to `bean-check` it to see if all's well. Chances are you'll have to enter some manual postings to balance some transactions.
It's also possible that your balance checks are failing because some expected transactions were included in the new entries although weren't matched (and so now are duplicated), or simply didn't come in (that credit you were waiting for). Beanahead can't chase your debtors but the `exp` command can at least deal with any expired expected transactions.
```
$ beanahead exp --help
usage: beanahead exp [-h] ledgers [ledgers ...]
positional arguments:
ledgers paths to one or more Regular Expected Transactions Ledgers
against which to administer expired transactions.
```
For example:
```
$ beanahead exp rx x
```
The above command:
- Gets the transactions on the expected transactions ledger files 'rx.beancount' and 'x.beancount' (both in the current working directory).
- Offers the user the following options for each transaction that is dated prior to 'today'.
- Move transaction forwards to 'tomorrow'.
- Move transaction forwards to a user-defined date.
- Remove transaction from ledger.
- Leave transaction as is.
- Rewrites the expected transactions ledgers (if applicable) to reflect the requested changes.
With a bit of luck and perhaps a tweak or two to your ledger, your `bean-check` should now be checking out.
> :information_source: An alternative to using `exp` is to manually redate / remove transactions on the expected transactions ledgers.
## Worth remembering
> :warning: Whenever an expected transactions ledger or the regular expected transaction definition files are updated the entries are resorted and the file is overwritten - anything that is not a directive (e.g. comments) will be lost.
## Options
### Print to stderr
If you are employing a workflow that directs output through `sys.stdout` then this will merge with Beanahead's own output to this stream. To avoid such conflicts `beanahead` provides for directing its output to `sys.stderr`. This can be set from the command line by preceeding any subcommand with --print_stderr, for example...
```
$ beanahead --print_stderr exp rx x
```
The same effect can be achieved with the flag -p.
```
$ beanahead -p exp rx x
```
If using the underlying functions directly in the codebase then the print stream can be set via the following methods of the `beanahead.config` module:
- `set_print_stderr()`
- `set_print_stdout()`
### Custom account root names
If you're not using the default account root names (e.g. 'Assets', 'Income', 'Expenses' etc) then beanahead will need to know the values that you are using.
The subcommands of the cli that require these names get them from a ledger ('addrx' will read them from the main ledger which is a required argument, 'make' will read them from any ledger passed to its optional --main argument).
If using the underlying functions directly in the codebase then the names can be set either by passing a dictionary to `config.set_account_root_names` or by passing a ledger that contains these options to `utils.set_account_root_names`.
The currently set names can be inspected via `config.get_account_root_names()` and reset to the default values with`config.reset_account_root_names()`.
## Alternative packages
The beancount community offers a considerable array of add-on packages, many of which are well-rated and maintained. Below I've noted those I know of with functionality that includes some of what `beanahead` offers. Which package you're likely to find most useful will come down to your specific circumstances and requirements - horses for courses.
* [beancount-import](https://github.com/jbms/beancount-import) - an importer interface. Functionality provides for adding expected transactions directly to the main ledger and later merging these with imported transactions via a web-based UI. It requires implementing the importer interface and doesn't directly provide for regular expected transactions. But, if that import interface works for you then you'll probably want to be using `beancount-import`. (If you need the regular trasactions functionality provided by `beanahead`, just use `beanahead` to generate the transactions, copy them over to your ledger and let `beancount-import` handle the subsequent reconcilation.)
If you can recommend any other alternative package please raise a PR to add it here.
## `beancount` recommendations
If you don't already, it worth trying out a beancount syntax-highlighter extension. Have a look at the ['Editor Support' section of the Awesome Beancount](https://github.com/siddhantgoel/awesome-beancount#editor-support) repo to see if there's one available for your prefered editor.
More broadly, [awesome-beancount][awesome] is a great refrence for all things beancount. FWIW, these are my most-awesome of awesome-beancount:
* [Siddharnt Goel's blog post](https://sgoel.dev/posts/how-you-can-track-your-personal-finances-using-python/) uses `beancount` examples to explain Plain Text Accounting and double-entry accounting. A great introduction to these concepts.
* The [beancount mailing list](https://groups.google.com/g/beancount) is the place to look for answers and raise questions.
* [reds-rants](https://reds-rants.netlify.app/personal-finance/the-five-minute-ledger-update/) offers a comprehensive set of blogs on everything importing. It's tremendous.
* [smart_importer](https://github.com/beancount/smart_importer) offers import hooks that include one for auto-completion of postings based on machine-learning trained on past entries. Smart stuff indeed.
* [beancount-import](https://github.com/jbms/beancount-import) is an importer interface. If it works for you to be locked into an importer interface, this is a great one to be locked into.
## License
[MIT License][license]
[beancount]: https://github.com/beancount/beancount
[license]: https://github.com/maread99/beanahead/blob/master/LICENSE.txt
[rx_defs_initial]: ./examples/defs/rx_def.beancount
[beancount_example]: https://github.com/beancount/beancount/blob/master/examples/example.beancount
[rx_def_updated]: ./examples/defs/rx_def_updated.beancount
[x_ledger]: ./examples/recon/x.beancount
[awesome]: https://github.com/siddhantgoel/awesome-beancount
Raw data
{
"_id": null,
"home_page": null,
"name": "beanahead",
"maintainer": null,
"docs_url": null,
"requires_python": "~=3.9",
"maintainer_email": null,
"keywords": "accounting, beancount, ledger, finance",
"author": "Marcus Read",
"author_email": "marcusaread.prog@proton.me",
"download_url": "https://files.pythonhosted.org/packages/3c/3b/956ad2883f4536789d8d3c558bb40e61a91c88206cddcc1a677c69f1477d/beanahead-0.4.tar.gz",
"platform": null,
"description": "<!-- NB any links not defined as aboslute will not resolve on PyPI page -->\n# beanahead\n\n[](https://pypi.org/project/beanahead/)  [](https://github.com/psf/black)\n\nBeanahead administers future transactions for [beancount][beancount] ledgers.\n\nIt let's you:\n- Generate regular expected transactions.\n- Define ad hoc expected transactions.\n- Reconcile expected transactions against imported transactions.\n\nIt's useful to:\n- Forecast account balances based on expected income and payments.\n- Add transactions between updating accounts.\n\n## Installation\n\n`$ pip install beanahead`\n\nThe only direct dependencies are `beancount`, `beangulp` and `pandas` (pandas could be made optional, see [#1](https://github.com/maread99/beanahead/issues/1)).\n\nBeanahead is compatible with both beancount v2 and v3.\n\n## Really briefly, how it works\n\n- Expected transactions are defined on separate ledgers.\n- Newly imported entries are reconciled against expected transactions before being included to the main ledger (**beanahead does not need to touch your main ledger**).\n\n## Briefly, how it works\n- Regular Expected Transactions (electicity bill, rent, etc) are defined by including a single transaction to a dedicated beancount file, by convention 'rx_def.beancount'.\n- The `addrx` command is used to populate a Regular Expected Transactions ledger with transactions. This ledger, by convention 'rx.beancount', is 'included' to your main .beancount ledger.\n- ad hoc Expected Transactions are added to the Expected Transactions ledger, by convention 'x.beancount'. This ledger is also 'included' to your main .beancount ledger.\n- The `recon` comamnd offers a cli to reconcile newly imported transactions with transactions on the expected transactions ledgers.\n - Newly imported transactions are updated to reflect any missing narration, tags, meta and 'other side' postings defined on the corresponding expected transactions.\n - Reconciled expected transactions are removed from their respective ledgers.\n\nIn keeping with the `beancount` spirit, `beanahead` provides all its functionality via a CLI (the underlying functions are available within the codebase should you prefer). There are five commands, all subcommands of `beanahead`.\n```\n$ beanahead --help\nusage: beanahead [-h] [--version] {make,addrx,recon,exp,inject} ...\n\nsubcommands:\n {make,addrx,recon,exp,inject}\n make make a new beanahead file.\n addrx add Regular Expected Transactions.\n recon reconcile new transactions.\n exp administer expired expected transactions.\n inject inject new transactions.\n```\n\n> :information_source: Wherever this README shows the output from a `--help` option, only an abridged version of the output is shown. Run the command at the command line for the full help, e.g. `beanahead --help`. For subcommands the help includes the documentation of the underlying function.\n\n# Using beanahead\n\n## Index\n* [Making beanahead files](#making-beanahead-files)\n* [Regular Expected Transactions](#regular-expected-transactions)\n * [Defining regular transactions](#defining-regular-transactions)\n * [freq](#freq)\n * [Postings](#postings)\n * [roll](#roll)\n * [final](#final)\n * [Updating definitions](#updating-definitions)\n * [Adding regular transactions](#adding-regular-transactions)\n* [ad hoc transactions](#ad-hoc-transactions)\n* [Defining the payee](#defining-the-payee)\n* [Reconciling](#reconciling)\n * [Matching](#matching)\n * [Updating](#updating)\n* [Injection](#injection)\n* [Expired expected transactions](#expired-expected-transactions)\n* [Worth remembering](#worth-remembering)\n* [Options](#options)\n * [Print to stderr](#print-to-stderr)\n * [Custom account root names](#custom-account-root-names)\n* [Alternative packages](#alternative-packages)\n* [beancount recommendations](#beancount-recommendations)\n* [Licence](#license)\n\n## Making beanahead files\n\nFirst off, you'll need to use the `make` command to create a new `.beancount` file or three.\n\n> :information_source: You'll probably want these files to be in the same directory as your exisitng main ledger. The following examples assume you want to create the files in the current working directory. Pass the --dirpath (or -d) option to specify a different directory.\n\nIf you want to include Regular Expected Transactions you'll need to create a definitions file and a dedicated ledger....\n```\n$ beanahead make rx_def -f rx_def\n$ beanahead make rx -f rx\n```\n...and add the following line towards the top of your main ledger.\n```\ninclude \"rx.beancount\"\n```\nIf you want to include ad hoc Expected Transactions you'll need to create a separate dedicated ledger...\n```\n$ beanahead make x -f x\n```\n...and add the following line towards the top of your main ledger.\n```\ninclude \"x.beancount\"\n```\nSo, if you want to include both regular and ad hoc expected transactions then you should have created three new `.beancount` files and added two 'include' lines to top of your main ledger.\n\n> :information_source: The -f option provides for defining the filename (`make` will add the `.beancount` extension). If -f is not passed then default names will be used which are as those explicitly passed in the examples.\n\n> :information_source: The quoted file in the 'include' lines should reflect the path to the expected transactions ledger from the directory in which your main ledger is located. The above examples assume that the expected transactions ledgers have the default filenames and are located in the same directory as the main ledger.\n\nThe [examples/new_empty_files](./examples/new_empty_files) folder includes a sample of each of the above newly created files.\n- [Regular Expected Transaction Definitions file](./examples/new_empty_files/rx_def.beancount)\n- [Regular Expected Transactions Ledger](./examples/new_empty_files/rx.beancount)\n- [Expected Transactions Ledger](./examples/new_empty_files/x.beancount)\n\nNB If you're not using the default account root names (e.g. 'Assets', 'Income', 'Expenses' etc) then you'll also need to use the optional --main argument to provide the path to a ledger from which beanahead can read the customised name options. Example:\n```\n$ beanahead make x -f x --main my_ledger\n```\n\n## Regular Expected Transactions\nRegular expected transactions are defined on the Regular Expected Transaction _Definitions_ file. The `addrx` command can then be used to populate the Regular Expected Transactions _Ledger_ with transactions generated from these definitions.\n\n### Defining regular transactions\nA new regular transaction can be defined at any time by adding a single transaction to the definitions file (the 'initial definition'). The date of this transaction will serve as the anchor off which future transactions are evaluated.\n\nThe following initial definition would generate regular transactions on the 5th of every month, with the first generated transaction dated 2022-10-05. \n```beancount\n2022-10-05 * \"EDISON\" \"Electricity, monthly fixed tarrif\"\n freq: \"m\"\n Assets:US:BofA:Checking -65.00 USD\n Expenses:Home:Electricity\n```\n\nEach initial definition must:\n- have a **unique [payee](#defining-the-payee)**.\n- include the [freq](#freq) meta field to define the transaction frequency.\n- include at least two [postings](#postings) of which at least one should be to a balance sheet account (\"Assets\" or \"Liabilities\").\n\nInitial definitions can optionally include:\n- the [roll](#roll) meta field to define if transactions falling on weekends should roll forwards.\n- the [final](#final) meta field to define the last transaction date.\n- additional [postings](#postings).\n- custom meta fields.\n- tags\n\n[rx_defs.beancount][rx_defs_initial] offers an example of a new definitions file before any transactions have been generated. The initial definitions there cover a variety of circumstances, based loosely on selected sampling of beancount's [example.beancount][beancount_example] ledger.\n\n#### freq\nThe **freq** meta field is used to specify the frequency with which regular transactions should be generated.\n\nA **simple frequency** can be specified as \"w\", \"m\" and \"y\", respectively for weekly, monthly and yearly. The unit can be prefixed with a value to specify a multiple, for example \"2w\" for fortnightly or \"3m\" for quarterly.\n\nAlternatively, the frequency can be specified with a **[pandas frequency](https://pandas.pydata.org/docs/user_guide/timeseries.html#offset-aliases)**. For example \"BAS-MAR\" defines the frequency as the first business day of every March.\n\n#### Postings\nEach definition must include a posting to an account which the regular transactions will appear on the statements of. This can be an \"Assets\" account (for example, for Direct Debits) or a \"Liabilities\" account (for example, for regular charges to a credit card). If the amount is variable then just stick in an estimate or the amount that you wish to budget for.\n\nAt least one posting to an account on the 'other side' must be included (e.g. to an \"Expenses\" account). Any number of other postings can be included.\n\nWhen the regular expected transactions are later reconciled with transactions imported from your statements, the `recon` command will update the imported transactions with these 'other-side' postings (see [reconciling](#reconciling)).\n\n> :information_source: If the transaction is balanced with only one 'other-side' posting then you're better off not including an amount for it. (By including an amount, if the imported transaction has a different amount then you'll need to manually amend the posting on the updated imported transaction.)\n\n> :information_source: If the transaction is split between various 'other-side' postings then it will be necessary to define an amount for at least all but one of these. In this case, if the imported transaction value differs from the expected transaction value then you may want to revise the amounts of those postings for which estimates were included.\n\n#### Roll\nBy default, any generated transaction that would be dated on a weekend will be rolled forward to the following Monday. This behaviour can be overriden by the 'roll' meta field.\n```\n2022-11-13 * \"ETrade Transfer\" \"Transfering accumulated savings to other account\"\n freq: \"3m\"\n roll: FALSE\n Assets:US:BofA:Checking -4000 USD\n Assets:US:ETrade:Cash\n```\nThe above initial definition is dated 2022-11-13, which is a Sunday. By specifying roll as FALSE the first transaction generated will be dated 2022-11-13 regardless that this is a Sunday. Thereafter transactions will be defined on the 13th of each month regardless of whether these dates represent weekdays or weekends.\n\n> :warning: the roll field's value must be in captials and NOT quoted.\n\n> :information_source: initial definitions should always be dated on the 'usual' payment day even if that falls on a weekend. For example...\n> ```\n> 2022-10-16 * \"Verizon\" \"Telecoms, monthly variable\"\n> freq: \"m\"\n> Assets:US:BofA:Checking -55.00 USD\n> Expenses:Home:Phone\n>```\n> This initial definition is dated 2022-10-16 which is a Sunday. The first generated transaction will be automatcially rolled forward to 2022-10-17. All transactions thereafter will be dated as the 16th of each month whenever the 16th is a weekday or otherwise rolled forward to the following Monday.\n\n#### Final\nThe 'final' meta field can be used to define a final transaction date. No transactions will be generated that would be dated later than this date (as evaluated prior to any rolling).\n```\n2022-10-31 * \"Chase\" \"Chase Hire Purchase\"\n freq: \"BME\"\n final: 2022-11-30\n Liabilities:US:Chase:HirePurchase 322.00 USD\n Assets:US:BofA:Checking\n```\n\n> :warning: the final field's value should NOT be quoted.\n\nA definition will be automaticaly removed from the definitions file after any final transaction has been generated.\n\n### Updating definitions\nThe `addrx` command updates the definitions file whenever the ledger is populated with new transactions:\n- any definition for which a new transaction was generated will be updated to reflect the transaction that would immediately follow the last transaction that was added to the ledger.\n- Defintions are grouped by balance sheet account* and type of account(s) of the 'other side', for example 'Income', 'Expenses' etc. Each group is introduced with a title row. Within each group definitions are sorted by payee. (*The balance sheet account is assumed as the first \"Assets\" or \"Liabilities\" account defined in the postings.)\n\n> :information_source: New definitions can be added at any time anywhwere under the line ```;; Enter definitions after this line...``` - they'll find their way to the corresponding section when the file is next updated.\n\n[rx_def_updated.beancount][rx_def_updated] is the updated [rx_def.beancount][rx_defs_initial] file after adding regular transactions to the ledger through to 2022-12-31. :warning: Notice that all comments are lost when a definitions file is updated.\n\n### Adding regular transactions\nThe `addrx` command is used to populate a Regular Expected Transactions Ledger with transactions evaluated from a definitions file.\n```\n$ beanahead addrx --help\nusage: beanahead addrx [-h] [-e] defs rx-ledger main-ledger\n\npositional arguments:\n defs path to Regular Expected Transactions Definition file.\n rx-ledger path to Regular Expected Transactions Ledger file.\n main-ledger path to main Ledger file.\n\noptional arguments:\n -h, --help show this help message and exit\n -e , --end date to which to create new transactions, iso format,e.g. '2020-09-30'. Default 2023-01-11.\n```\nFor example...\n```\n$ beanahead addrx rx_def rx ledger -e 2022-12-31\n```\nThe above command:\n- Gets the definitions from the file `rx_def.beancount` in the current working directory.\n- For each definition, generates transactions from the defintion date through to '2022-12-31' (both inclusive).\n- Adds transactions to the `rx.beancount` ledger.\n- Updates the `rx_def.beancount` file (as [Updating definitions](#updating-definitions)).\n- Verifies that the main ledger, `ledger.beancount`, loads without errors. The path to the main ledger is passed as the third positional argument (this ledger should be the main ledger to which the 'insert \"rx.beancount\"' line was added). `addrx` requires this file only to verify that no errors have arisen as a result of introducing the new transactions to the Regular Expected Transactions Ledger.\n - In the event the main ledger loads with errors then changes made to the definitions file and Regular Expected Transactions Ledger are reverted and advices printed.\n\nIf the command is executed as above with the files in the [examples/defs](./examples/defs) folder then the empty rx ledger there will be populated with transactions. The rx ledger would end up as [rx_updated.beancount](./examples/defs/rx_updated.beancount) whilst the definitions file would be updated as [rx_def_updated.beancount][rx_def_updated].\n\n## ad hoc transactions\nCreating ad hoc expected transactions is as simple as adding transactions to an Expected Transactions Ledger created via `$ beanahead make x <filename>`. The [x.beancount][x_ledger] file offers an example (again, loosely based on selected sampling of beancount's [example.beancount][beancount_example] ledger).\n\nJotting down ad hoc transactions is useful to record transaction details 'in the moment' when you have in mind the 'other-side' postings and maybe know the narration or tag that you might forget by the time you next get round to downloading statements and updating your main ledger.\n\nTransactions can be listed on the ledger in any order. Whenever a transaction on the ledger is reconciled with an imported transaction (extracted from a statement) the ledger is rewritten and any remaining transactions are reordered.\n\n> :warning: Any comments will be lost whenever an Expected Transactions Ledger is rewritten.\n\n## Defining the **payee**\n\nThe reconciliation of imported transactions with expected transactions ([reconciling](#Reconciling)) can be greatly aided by judiciously naming the expected transactions payee.\n\nBeanahead will treat each 'word' defined in the expected payee as a separate string. An expected payee will match with the payee of any new transaction that includes **any** of those strings. So:\n - Do not include short words that represent common syllables.\n For example, \"Top of the World\" will match with \"The corner shop\", \"Another Day\" and \"Super Offers\".\n - Use few unambiguous words. For example \"Top World\". Even just \"Top\" might be a better choice.\n\n> :information_source: The transaction that ends up on your main ledger will have the payee as defined on the statement, not \"Top\"!\n> :information_source: matches are case-insensitive\n\n## Reconciling \n\nThe `recon` command provides for reconciling imported transactions with expected transactions.\n\n```\n$ beanahead recon --help\nusage: beanahead recon [-h] [-o OUTPUT] [-k] [-r] new ledgers [ledgers ...]\n\npositional arguments:\n new path to new transactions beancount file. Can be\n absolute or relative to the current working directory.\n ledgers paths to one or more Regular Expected Transactions\n Ledgers against which to reconcile incoming\n transactions.\n\noptional arguments:\n -h, --help show this help message and exit\n -o OUTPUT, --output OUTPUT\n path to which to write updated new entries. Can be\n absolute or relative to the current working directory.\n By default will overwrite 'incoming'.\n -k, --keep, --no-remove\n flag to not remove reconciled transactions from ledgers.\n (By default reconciled transactions will be removed.)\n -r, --reverse flag to write updated entries in descending order. By\n default will be written in ascending order.\n```\nFor example...\n```\n$ beanahead recon extraction rx x -o injection\n```\nThe above command:\n- Gets beancount entries from the file `extraction.beancount` located in the current working directory. This file should contain only new entries as returned by the beancount `extract` command and destined for your beancount ledger.\n- Gets the expected transactions from the ledger files `rx.beancount` and `x.beancount`, also located in the current working directory.\n- [Matches](#Matching) expected transactions with new transactions.\n - The user is requested to confirm or reject each propsosed match.\n - Where an expected transaction matches more than one new transaction, the user is requested to select which of the new transactions to match (or none).\n- [Updates](#Updating) matched new transactions with information gleaned from the corresponding expected transaction.\n- Outputs the updated entries. By default overwrites the file passed as the `new` argument (`extraction.beancount` above). Alternatively, a path can be passed to the `--output` option, as in this case where output will be written to `injection.beancount` in the current working directory.\n - Entries are by default sorted in ascending order. Pass the `-r` flag or `--reverse` option to sort in descending order.\n- Removes reconciled expected transactions from their respective ledgers. (The `-k` flag can be passed to 'keep' the expected transactions.)\n\nIf the command is executed as above with the files in the [examples/recon](./examples/recon) folder and the matches are confirmed then:\n- an `injection.beancount` file will be created that looks like [this](./examples/recon/expected_injection.beancount).\n- reconciled transactions will be removed from [rx.beancount](./examples/recon/rx.beancount), such that it ends up like [this](./examples/recon/rx_updated.beancount).\n- reconciled transactions will be removed from [x.beancount](./examples/recon/x.beancount), such that it ends up like [this](./examples/recon/x_updated.beancount).\n\n### Matching\nBeanahead matches expected with imported transactions based on:\n- payee (see [Defining the payee](#defining-the-payee))\n- similarity in accounts\n- closeness of dates\n- closeness of amounts\n\nAs a bare minimum, matches require that the new and expected transactions:\n- are dated within 5 days of each other\n- include a posting to the same Asset account\n- either have matching payee or the imported transaction amount is no more than 2% different from the expected\n\nIf you want a better insight into how matches are evaluated, check out the [reconcile](./src/beanahead/reconcile.py) module to get under-the-bonnet.\n\n### Updating\nBeanahead will update the following fields of matched imported transactions to include any values specifed for the corresponding expected transaction. Any existing values on the imported transaction will **not** be overwritten.\n- **narration**\n- **tags** (excluding #rx_txn and #x_txn)\n- **meta** (excluding beanahead meta fields such as 'final', 'roll' etc)\n- **postings**\n - postings on the expected transactions will be added to the imported transaction if the imported transaction does not otherwise include a posting to the corresponding account.\n - if the imported and expected transactions include postings to the same account and only the expected transaction defines a number, the imported transaction's posting will be updated to reflect the value as defined on the expected transaction.\n\n## Injection\nThe output from `recon` can be copied directly into your main ledger. If you're happy to append the full contents 'as is' to the end of your ledger then the `inject` command will do it for you.\n```\n$ beanahead inject --help\nusage: beanahead inject [-h] injection ledger\n\npositional arguments:\n injection path to beancount file containing the new entries to be\n injected. Can be absolute or relative to the current\n working directory.\n ledger path to beancount ledger to which new entires are to\n be appended. Can be absolute or relative to the current\n working directory.\n```\nSo...\n```\n$ beanahead inject injection my_ledger\n```\n...would append the updated entires in the `injection.beancount` file to the end of the `my_ledger.beancount` file (both files in the current working directory).\n\n## Expired expected transactions\nNow that your main ledger has been updated with the new entries it'll be necessary to `bean-check` it to see if all's well. Chances are you'll have to enter some manual postings to balance some transactions.\n\nIt's also possible that your balance checks are failing because some expected transactions were included in the new entries although weren't matched (and so now are duplicated), or simply didn't come in (that credit you were waiting for). Beanahead can't chase your debtors but the `exp` command can at least deal with any expired expected transactions.\n```\n$ beanahead exp --help\nusage: beanahead exp [-h] ledgers [ledgers ...]\n\npositional arguments:\n ledgers paths to one or more Regular Expected Transactions Ledgers\n against which to administer expired transactions.\n```\nFor example:\n```\n$ beanahead exp rx x\n```\nThe above command:\n- Gets the transactions on the expected transactions ledger files 'rx.beancount' and 'x.beancount' (both in the current working directory).\n- Offers the user the following options for each transaction that is dated prior to 'today'.\n - Move transaction forwards to 'tomorrow'.\n - Move transaction forwards to a user-defined date.\n - Remove transaction from ledger.\n - Leave transaction as is.\n- Rewrites the expected transactions ledgers (if applicable) to reflect the requested changes.\n\nWith a bit of luck and perhaps a tweak or two to your ledger, your `bean-check` should now be checking out.\n\n> :information_source: An alternative to using `exp` is to manually redate / remove transactions on the expected transactions ledgers.\n\n## Worth remembering\n> :warning: Whenever an expected transactions ledger or the regular expected transaction definition files are updated the entries are resorted and the file is overwritten - anything that is not a directive (e.g. comments) will be lost. \n\n## Options\n### Print to stderr\nIf you are employing a workflow that directs output through `sys.stdout` then this will merge with Beanahead's own output to this stream. To avoid such conflicts `beanahead` provides for directing its output to `sys.stderr`. This can be set from the command line by preceeding any subcommand with --print_stderr, for example...\n```\n$ beanahead --print_stderr exp rx x\n```\nThe same effect can be achieved with the flag -p.\n```\n$ beanahead -p exp rx x\n```\nIf using the underlying functions directly in the codebase then the print stream can be set via the following methods of the `beanahead.config` module:\n- `set_print_stderr()`\n- `set_print_stdout()`\n\n### Custom account root names\nIf you're not using the default account root names (e.g. 'Assets', 'Income', 'Expenses' etc) then beanahead will need to know the values that you are using.\n\nThe subcommands of the cli that require these names get them from a ledger ('addrx' will read them from the main ledger which is a required argument, 'make' will read them from any ledger passed to its optional --main argument).\n\nIf using the underlying functions directly in the codebase then the names can be set either by passing a dictionary to `config.set_account_root_names` or by passing a ledger that contains these options to `utils.set_account_root_names`.\n\nThe currently set names can be inspected via `config.get_account_root_names()` and reset to the default values with`config.reset_account_root_names()`.\n\n## Alternative packages\nThe beancount community offers a considerable array of add-on packages, many of which are well-rated and maintained. Below I've noted those I know of with functionality that includes some of what `beanahead` offers. Which package you're likely to find most useful will come down to your specific circumstances and requirements - horses for courses.\n* [beancount-import](https://github.com/jbms/beancount-import) - an importer interface. Functionality provides for adding expected transactions directly to the main ledger and later merging these with imported transactions via a web-based UI. It requires implementing the importer interface and doesn't directly provide for regular expected transactions. But, if that import interface works for you then you'll probably want to be using `beancount-import`. (If you need the regular trasactions functionality provided by `beanahead`, just use `beanahead` to generate the transactions, copy them over to your ledger and let `beancount-import` handle the subsequent reconcilation.)\n\nIf you can recommend any other alternative package please raise a PR to add it here.\n\n## `beancount` recommendations\nIf you don't already, it worth trying out a beancount syntax-highlighter extension. Have a look at the ['Editor Support' section of the Awesome Beancount](https://github.com/siddhantgoel/awesome-beancount#editor-support) repo to see if there's one available for your prefered editor.\n\nMore broadly, [awesome-beancount][awesome] is a great refrence for all things beancount. FWIW, these are my most-awesome of awesome-beancount:\n* [Siddharnt Goel's blog post](https://sgoel.dev/posts/how-you-can-track-your-personal-finances-using-python/) uses `beancount` examples to explain Plain Text Accounting and double-entry accounting. A great introduction to these concepts.\n* The [beancount mailing list](https://groups.google.com/g/beancount) is the place to look for answers and raise questions.\n* [reds-rants](https://reds-rants.netlify.app/personal-finance/the-five-minute-ledger-update/) offers a comprehensive set of blogs on everything importing. It's tremendous.\n* [smart_importer](https://github.com/beancount/smart_importer) offers import hooks that include one for auto-completion of postings based on machine-learning trained on past entries. Smart stuff indeed.\n* [beancount-import](https://github.com/jbms/beancount-import) is an importer interface. If it works for you to be locked into an importer interface, this is a great one to be locked into.\n\n## License\n\n[MIT License][license]\n\n\n[beancount]: https://github.com/beancount/beancount\n[license]: https://github.com/maread99/beanahead/blob/master/LICENSE.txt\n[rx_defs_initial]: ./examples/defs/rx_def.beancount\n[beancount_example]: https://github.com/beancount/beancount/blob/master/examples/example.beancount\n[rx_def_updated]: ./examples/defs/rx_def_updated.beancount\n[x_ledger]: ./examples/recon/x.beancount\n[awesome]: https://github.com/siddhantgoel/awesome-beancount\n",
"bugtrack_url": null,
"license": "MIT License",
"summary": "Beancount extension for future transactions",
"version": "0.4",
"project_urls": {
"Issue Tracker": "https://github.com/maread99/beanahead/issues",
"Source Code": "https://github.com/maread99/beanahead",
"documentation": "https://github.com/maread99/beanahead",
"homepage": "https://github.com/maread99/beanahead"
},
"split_keywords": [
"accounting",
" beancount",
" ledger",
" finance"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "5f78391f85456a2759818f09a6bff2ae797a46375d8d7cc1c547c7204d3bb3b7",
"md5": "c5dbd79be4d4551a074fe0e777b96f11",
"sha256": "598d3c570c77b5f1cc5fe9b0b709a45551f2eed5c58dbc52ac9d2f4ed8c3a603"
},
"downloads": -1,
"filename": "beanahead-0.4-py3-none-any.whl",
"has_sig": false,
"md5_digest": "c5dbd79be4d4551a074fe0e777b96f11",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": "~=3.9",
"size": 39579,
"upload_time": "2024-11-07T18:04:20",
"upload_time_iso_8601": "2024-11-07T18:04:20.911531Z",
"url": "https://files.pythonhosted.org/packages/5f/78/391f85456a2759818f09a6bff2ae797a46375d8d7cc1c547c7204d3bb3b7/beanahead-0.4-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "3c3b956ad2883f4536789d8d3c558bb40e61a91c88206cddcc1a677c69f1477d",
"md5": "d57946af32200e02b596ac7415b4e3ce",
"sha256": "054d3e1d5992a73f31db5dc930c35d5bb6ee903c34ab9519e1b50d572a1cf826"
},
"downloads": -1,
"filename": "beanahead-0.4.tar.gz",
"has_sig": false,
"md5_digest": "d57946af32200e02b596ac7415b4e3ce",
"packagetype": "sdist",
"python_version": "source",
"requires_python": "~=3.9",
"size": 55726,
"upload_time": "2024-11-07T18:04:21",
"upload_time_iso_8601": "2024-11-07T18:04:21.993525Z",
"url": "https://files.pythonhosted.org/packages/3c/3b/956ad2883f4536789d8d3c558bb40e61a91c88206cddcc1a677c69f1477d/beanahead-0.4.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-11-07 18:04:21",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "maread99",
"github_project": "beanahead",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"requirements": [
{
"name": "beancount",
"specs": [
[
"==",
"3.0.0"
]
]
},
{
"name": "beangulp",
"specs": [
[
"==",
"0.1.1"
]
]
},
{
"name": "beautifulsoup4",
"specs": [
[
"==",
"4.12.3"
]
]
},
{
"name": "chardet",
"specs": [
[
"==",
"5.2.0"
]
]
},
{
"name": "click",
"specs": [
[
"==",
"8.1.7"
]
]
},
{
"name": "colorama",
"specs": [
[
"==",
"0.4.6"
]
]
},
{
"name": "lxml",
"specs": [
[
"==",
"5.2.2"
]
]
},
{
"name": "numpy",
"specs": [
[
"==",
"2.0.0"
]
]
},
{
"name": "pandas",
"specs": [
[
"==",
"2.2.2"
]
]
},
{
"name": "python-dateutil",
"specs": [
[
"==",
"2.9.0.post0"
]
]
},
{
"name": "pytz",
"specs": [
[
"==",
"2024.1"
]
]
},
{
"name": "regex",
"specs": [
[
"==",
"2024.5.15"
]
]
},
{
"name": "six",
"specs": [
[
"==",
"1.16.0"
]
]
},
{
"name": "soupsieve",
"specs": [
[
"==",
"2.5"
]
]
},
{
"name": "tzdata",
"specs": [
[
"==",
"2024.1"
]
]
}
],
"lcname": "beanahead"
}
JSON
