Re: [lmi] Special "split funds" supplemental report

[Greg Chicares]

On 2019-01-21 21:46, Vadim Zeitlin wrote:
> On Sat, 19 Jan 2019 01:30:23 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> A special supplemental report is required in a certain circumstance.
> GC> Today, this is done manually. Vadim, would you please consider
> GC> automating it?
> 
>  I'm sorry for a probably very stupid question, but how exactly do you do
> it manually and how should this be automated? I.e. I understand (almost)

Today, end users must ask themselves whether The Circumstance holds,
for each illustration they produce; and, iff it does, they must go
to the "Reports" tab, check "Create supplemental report", and manually
select the exact set of columns specified below. It's an onerous process,
and there's clearly room for human error.

The desired alternative is that lmi detects whether The Circumstance
holds, and, iff it does, inserts the required supplemental report,
automatically, every time. This new report isn't quite identical to
the one manually produced, because it doesn't use the "Reports" tab or
the general facility underlying that tab: instead, it'll all be hard
coded, just like class finra_supplemental for example (thus, we can
hard-code customized widths, which users can't do on the "Reports" tab).

> all the details below, but I have trouble seeing the bigger picture: what
> exactly would end users do to generate this report? Do I understand it
> correctly that they won't have to do anything at all but that, if The
> Circumstance below holds, it will be generated automatically and
> unavoidably?

Yes, exactly. It's much like the extra report produced by class
finra_supplemental: they don't have to do anything; whenever The
Circumstance holds, it is always generated automatically, and users
cannot prevent it from being generated; and...

> But even if so, it's not clear to me if generating it means an
> extra page in illustrations for some (or all?) ledger types or a completely
> new illustration kind or something else entirely?

...it causes an extra page (or set of pages) to be inserted into
an illustration. Otherwise, it's the same kind of illustration;
the only difference is the extra set of pages. IOW, at the top
level the change is only this:

        // Add all the pages.
        add<cover_page>();
        numbered_page::start_numbering();
        add<finra_basic>();
        add<finra_supplemental>();
+       add<finra_fund_split>();
        add<standard_page>("finra_column_headings");
        add<standard_page>("finra_notes1");
        add<standard_page>("finra_notes2");

if The Circumstance is detected in new class finra_fund_split, or

+       if(TheCircumstance) {add<finra_fund_split>();}

if it's better to detect that at this level.

> GC> The circumstance: This report is required iff
> GC>   Input::InforceGeneralAccountValue      ;
> GC>   Input::InforceSeparateAccountValue     ;
> GC> are both nonzero:
> 
>  Out of curiosity, is "split funds" the same as "split fund allocation"?
> I'm asking this because I see that in ledger_variant_init.cpp the
> apparently related field SplitFundAllocation is set to true if either this
> condition or if "0.0 != GenAcctAllocation && 1.0 != GenAcctAllocation" one
> is true? Possibly more importantly, should I use exactly the condition
> above or test SplitFundAllocation in the code that we will write to
> generate this report?

Fascinating. I can't remember exactly why a misspelled SplitFundAllocaction
field was added in 2015, but it was presumably intended for automating this
long-deferred project--which was rather less practicable in our XSL-FO era,
and that explains why this field's name was apparently never mentioned in
any XSL template.

Yes, this field should now be used for its originally contemplated purpose.

I'll double check this enhanced Circumstance once we've recovered from the
latest ice storm, but I think we'll decide it's the One True Circumstance.
The code:

    SplitFundAllocation =
            (0.0 != GenAcctAllocation && 1.0 != GenAcctAllocation)
        ||
            (  0.0 != b->yare_input_.InforceGeneralAccountValue
            && 0.0 != b->yare_input_.InforceSeparateAccountValue
            )
        ;

may be translated thus into English:

  If the (future) allocation to the general account is neither 0% nor 100%,
  of if the (present) balances in the general and separate accounts are
  both nonzero

which in effect means

  If, in any current or future year, the balances in the general and
  separate accounts could both be nonzero

which I think is the true intention.

> GC> The report: The columns are these...
[...]
> GC> in the case documented as follows in class finra_supplemental:
> GC> 
> GC>     // When invar.SplitMinPrem is true
> GC> 
> GC> in which case, as that comment describes in detail, we may need to make
> GC> certain columns narrower so that all fit. When 'SplitMinPrem' is not
> GC> true, these two columns:
> GC> 
> GC>     <SupplementalReportColumn02>ErGrossPmt</SupplementalReportColumn02>
> GC>     <SupplementalReportColumn03>EeGrossPmt</SupplementalReportColumn03>
> GC> 
> GC> are to be omitted, and 'Outlay' inserted.
[...]
>  I think I understand this. But I still have another question here too: as
> we're now going to have fewer columns, should we make some of them wider?

I don't think it matters. But if it does matter, we can easily adjust the
widths later.