lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Supplemental report with zero-percent columns


From: Greg Chicares
Subject: Re: [lmi] Supplemental report with zero-percent columns
Date: Tue, 29 Jan 2019 22:54:13 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 2009-09-28 13:01, Greg Chicares wrote:
[...weird "0%" supplemental-report columns...]
> 
> It seems plain now that adding these columns to the GUI was a
> mistake. The objective is just to provide a supplemental report,
> when general- and separate-account balances are both nonzero,
> with a particular set of columns on these bases:
>   "curr charges and genacct int, zero sepacct int"
>   "guar charges and genacct int, zero sepacct int"
> Adding columns on those bases to the GUI creates problems for
> non-variable policy forms, for which those bases are undefined.
> Except to comply with a regulatory requirement, no end user would
> ever wish to use any such column in a supplemental report.

All such columns have been liquidated.

> Because the desired supplemental report contains a particular
> fixed set of columns, it would seem better to implement it in the
> appropriate '.xsl' file, as was done in this 'nasd.xsl' template:
>   <xsl:template name="supplemental-illustration-report">

With XSL-FO, that just wasn't practical.

With MST, it wasn't too terrible, or at least Vadim made it seem so;
and I was able to make some revisions myself, more easily than I
could write specifications for those revisions.

> That's easier for end users and less prone to manual error. This
> special hard-coded supplemental report should appear if and only
> if a particular condition is met. I'm not exactly sure what that
> condition is, but it might be either (or both) of these:
>  (a) 'GenAcctAllocation' is neither one nor zero; or
>  (b) 'AVGenAcct' and 'AVSepAcct' are both nonzero.
> (a) is fairly straightforward because it uses only a scalar.
> (b) is harder (in xslt) because it involves two vectors.

We're using LedgerInvariant::SplitFundAllocation, which is even
better than either (or both) of those.

Now that this report is fully automated, I've removed the "weird"
columns from the GUI, conserving backward compatibility of course.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]