b0e2db902e
Despite a `.bs_mktid` ideally being a bijection with `MktPair.fqme` values, apparently some backends (cough IB) will switch the .<venue>` part in txn records resulting in multiple account-conf-file sections for the same dst asset. Obviously that means we can't allocate new `Position` entries keyed by that `bs_mktid`, instead be sure to **update them instead**! Deats, - add case logic to avoid pp overwrites using a `pp_objs.get()` check. - warn on duplicated pos entries whenever the current account-file entry's `mkt` doesn't match the pre-existing position's. - mk `Position.add_clear()` return a `bool` indicating if the record was newly added, warn when it was already existing/added prior. Also, - drop the already deprecated `open_pps()`, also from sub-pkg exports. - draft TODO for `Position.summary()` idea as a replacement for `BrokerdPosition`-msgs. |
||
|---|---|---|
| .. | ||
| README.rst | ||
| __init__.py | ||
| _allocate.py | ||
| _ledger.py | ||
| _mktinfo.py | ||
| _pos.py | ||
| calc.py | ||
| cli.py | ||
README.rst
.accounting
A subsystem for transaction processing, storage and historical measurement.
.pnl
BEP, the break even price: the price at which liquidating a remaining position results in a zero PnL since the position was "opened" in the destination asset.
PPU: price-per-unit: the "average cost" (in cumulative mean terms) of the "entry" transactions which "make a position larger"; taking a profit relative to this price means that you will "make more profit then made prior" since the position was opened.