Re: [lmi] Group premium quotes

[Greg Chicares]

On 2015-07-16 15:11, Vadim Zeitlin wrote:
> On Mon, 22 Jun 2015 01:34:50 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Think first of the xml, then grep to see where the data come from in the
> GC> ledger classes. Take "SpecAmt" for example:
> ...
> GC>         << Invar.value_str("SpecAmt"              ,d) << '\t'
> 
>  Hello again,
> 
>  While I was able to find the provenance of some fields in the report using
> the (snipped) instructions above, I'm afraid I'll have to return to this
> 
> GC> I'll be your safari guide, so no hippopotamus will become your 
> sarcophagus.
> 
> and ask you for help with the remaining ones. Here is the list of fields
> whose source I couldn't find on my own:
> 
> - Several fields of the plan details summary:

That was drafted by the client's Sales department, who were thinking in terms
of a standalone spreadsheet, in which they'd edit this area freely. What we're
working on here is no standalone spreadsheet, but rather an auxiliary report
added onto an illustration system to which no new input fields will be added.
That's why I said we might accommodate this section by letting them type its
entire contents into lmi's "Comments" field as a long string with line
separators. But let's postpone any further code refinements here because the
client's Compliance department is challenging this section, which means that
some of these fields may be moved into a system-generated array (like the
"Prepared date" and "Prepared by" section you've already coded), while others
may be expunged, and perhaps this whole boxed "Summary" vanishes.

>  . "Guarantee Issue Max"

This is presumably specified in a separate cover letter that conveys the
formal offer, so it seems purely redundant here. If were were to add such an
input field to lmi, we would necessarily enforce it as a maximum limit on
Input::SpecifiedAmount. But, to keep the project cost low, it has already
been agreed that no new input field will be added--and certainly not one
that necessitates extra logic and complexity that would be unwelcome to most
users. Ergo, either this is expunged, or it gets the "Comments" treatment.

>  . "Available Riders"

If this is moved outside the present "Summary" box, it will be a new field
akin to LedgerInvariant::ProductDescription. The alternative, for this item
as well as those following, is the "Comments" treatment, or expunction.
(It's not possible for lmi to deduce this otherwise: some riders are not
illustrated, so lmi is not and should not be aware of them.)

>  . "Number of Eligibles"

If this is moved outside the present "Summary" box, it will be the
cardinality of the census--the number of LedgerInvariant objects--and
its label will be changed to something less misleading.

>  . "Plan Type(s)"

This represents various nuanced sales concepts that are unknown to lmi:
"Comments" treatment, or expunction.

>  . "Premium Mode"

If this is moved outside the present "Summary" box, it will be the value
of LedgerInvariant::ErMode, which we will "assert" to be the same across
all LedgerInvariant objects. (I write "assert" in quotes because it's
unnecessarily severe to use the standard 'assert' macro here.)

>  . In addition, I'm not quite sure if "Contract State" is really
>    LedgerInvariant::StatePostalAbbrev that I used for it so far.

That is correct. It's initialized thus:
    StatePostalAbbrev       = mc_str(b->GetStateOfJurisdiction());
so it corresponds to Input::StateOfJurisdiction.

> - Numbers in all 4 "Quarterly premium" columns.

Four new fields to be added to class LedgerInvariant. I could assign names
now for your use, but I'd rather wait until the compliance review is complete
in case any more columns are needed.

Oh...in case it's unclear, the "Quarterly" part of these headers isn't
fixed text--instead, it's LedgerInvariant::ErMode, "Capitalized Thus"
instead of its native lower case.

> - Text of the footer at the very end of the document, below the company logo.

A new field akin to LedgerInvariant::ProductDescription. Here, again, I'm
waiting for compliance review before coding anything concrete.

> - The name of the files for the logo itself and the header background image
>   also need to come from somewhere, instead of being hardcoded as they are
>   now.

Any nonproprietary name is good enough for now, and might be good enough
forever.

>  And, while not quite a field, I'd also like to ask which date format
> should be used for the three places in which dates occur in the document:
> 
> - The report header in the top left (currently hardcoded as "%B %d, %Y").

I would prefer the OS-specific user default format--is that easy to do?

> - The effective date in the summary (currently hardcoded as "%m/%d/%Y").

Any field that receives the "Comments" treatment is to be passed through
literally, even if it says "Ides of July".

> - The dates in the DOB column (currently using "DateOfBirth" field, which
>   seems to be always in ISO 8601 format).

In addition to these ISO-8601-formatted strings:
    std::string     EffDate;
    std::string     DateOfBirth;
Class LedgerInvariant seems to provide:
    double          EffDateJdn;
    double          DateOfBirthJdn;
so, for consistency with the answer to the question preceding the last,
I would prefer the OS-specific user default format.

> GC> Let me suggest:
> GC> 
> GC>     if(emission & mce_emit_group_roster)
> GC>         {
> GC>         LMI_ASSERT(!tsv_filepath.empty());
> GC>         PrintRosterTabDelimited
> GC>             (ledger
> GC>             ,   tsv_filepath.string()
> GC>             +   ".roster"
> GC>             +   
> configurable_settings::instance().spreadsheet_file_extension()
> GC>             );
> GC>         if(contains(ledger.GetLedgerInvariant()..value_str("Comments"), 
> "TeStInG"))
> GC>             WritePremiumQuotePdfFile();
> GC>         }
> 
>  After thinking more about this I really couldn't find any good reason to
> use this hack and so added mce_emit_group_premium to mcenum_emission enum.
> This can, of course, be changed later but this is the simplest solution
> compatible with the emit_ledger refactoring I did, so I'd like to keep it
> if there are no strong arguments to the contrary.

Sounds okay--I think you've since posted a patch that I'll look at soon.

>  But for now the main stumbling block for me are the unknown fields above,
> thanks in advance for any guidance about where should I go hunting for
> them.

Perhaps they'll see the light and not choose the "Comments" treatment.