I just compiled a fresh version, and the first time I saved, the consistency check came up with over 4000 problems. ALL are in investment accounts, several of which have been closed for many years. I suspect it's an unintended side effect of the recent work on storing prices for add/remove share transactions.

Just the first example:
* Sum of splits in transaction 'T000000000000000004' posted on 4/16/2001 is not zero.
    Account: Asset:ML Overall:ML Stock (Brokerage), Amount: $-8,005.00
Account: Asset:ML Overall:ML 55741 CMA:Pfizer Common, Amount: PFE1,402.0000

That was the initial Buy shares transaction in that account, and as the fourth transaction in my file, it was clearly LONG ago.

Extracting the transaction gives:
<TRANSACTION id="T000000000000000004" postdate="2001-04-16" memo="" entrydate="2009-08-24" commodity="USD">
    <SPLITS>
<SPLIT id="S0001" payee="" reconciledate="2009-12-31" action="" reconcileflag="2" value="-8005/1" shares="-8005/1" price="1/1" memo="Grant 08251994 0428" account="A000133" number="" bankid=""/> <SPLIT id="S0002" payee="" reconciledate="" action="Buy" reconcileflag="2" value="400271/50" shares="1402/1" price="571/100" memo="Grant 08251994 0428" account="A000153" number="" bankid=""/>
    </SPLITS>
</TRANSACTION>

but extracting it from a backup from before I first save it today gives:
<TRANSACTION id="T000000000000000004" postdate="2001-04-16" memo="" entrydate="2009-08-24" commodity="USD">
    <SPLITS>
<SPLIT id="S0001" payee="" reconciledate="2009-12-31" action="" reconcileflag="2" value="-400271/50" shares="-400271/50" price="1/1" memo="Grant 08251994 0428" account="A000133" number="" bankid=""/> <SPLIT id="S0002" payee="" reconciledate="" action="Buy" reconcileflag="2" value="400271/50" shares="1402/1" price="571/100" memo="Grant 08251994 0428" account="A000153" number="" bankid=""/>
    </SPLITS>
</TRANSACTION>

Split 2 (in the security account) is the same before and after, but split 1 (in the brokerage account) has had the value and shares converted from 8005.42 (400271/50) converted 8005 (8005/1.) It looks like the new save has a rounding problem of some sort, or possibly a truncation in writing the number.

Jack

Reply via email to