Re: [lmi] Life insurance begins at inception

[Greg Chicares]

On 2015-09-24 18:41, Greg Chicares wrote:
> If a contract has been in force for a day or two, is it an inforce contract
> (as opposed to new business)?

For lmi illustrations, it is neither: it is a precondition violation that
 - is always tested before an illustration can be produced;
 - produces a diagnostic; and
 - causes an exception to be thrown.
See the explanation here:

http://svn.savannah.nongnu.org/viewvc/lmi/trunk/input_harmonization.cpp?root=lmi&r1=6354&r2=6391&diff_format=c

To create a test case:

  File | New | Illustration
  "Inforce as-of date": increase day by one
  OK
  dismiss diagnostic messagebox
  File | Save as /opt/lmi/eraseme/inforce_one_day.ill | Save
  File | Exit

Two different diagnostics can be shown. The first (dismissed above)...

/opt/lmi/bin[1]$./lmi_cli_shared --accept --ash_nazg --data_path=/opt/lmi/data 
--file=../eraseme/inforce_one_day.ill
Input inforce-as-of date, 2015-11-07, should be an exact monthiversary date.
It would be interpreted as 2015-11-06, which is 0 full years and 0 full months
after the 2015-11-06 effective date.
[file /lmi/src/lmi/input_harmonization.cpp, line 1163]

...can be inhibited (at least for now) by adding a "pyx" option as follows
(because we want to discover errors in data extracts from other systems,
but we don't want to risk obstructing inforce production):

/opt/lmi/bin[1]$./lmi_cli_shared --accept --ash_nazg --data_path=/opt/lmi/data 
--file=../eraseme/inforce_one_day.ill --pyx=off_monthiversary
Inforce illustrations not permitted during month of issue.
[file /lmi/src/lmi/input_harmonization.cpp, line 1174]

That shows the second diagnostic, which cannot be inhibited (see the
explanation cited above; if this arises in production, we most definitely
do want to obstruct it).

> Consider this code in 'ledger_invariant.cpp', which sets the 'IsInforce'
> field used by '*.xsl' for formatting illustrations:
> 
>     IsInforce = 0 != b->yare_input_.InforceYear || 0 != 
> b->yare_input_.InforceMonth;

[better in 'ihs_basicval.cpp':]

>     IsInforce = yare_input_.EffectiveDate < yare_input_.InforceAsOfDate;

I found two equivalent but different ways of writing "not issued today"
in terms of whole months and years:

     !(0 == InforceYear && 0 == InforceMonth)
      (0 != InforceYear || 0 != InforceMonth)

and another that is not equivalent, but is accompanied by a comment
explaining that this doesn't matter...except in cases we haven't tested:

    // Casual, but strictly correct for all testdeck cases:
    IsIssuedToday = 0 == Input.InforceYear;

I intend to clean this up by restricting all code to these two idioms:

    EffectiveDate == InforceAsOfDate
    EffectiveDate != InforceAsOfDate

(now that 'EffectiveDate <= InforceAsOfDate' is always asserted before
an illustration can be produced) with a documented exception that is
easily found by examining the changes.

> Many years ago, 'InforceYear' and 'InforceMonth' were GUI input fields,
> and we had no 'InforceAsOfDate'; comparing both year and month to zero was
> the best we could do in that era. We didn't update the test when we added
> 'InforceAsOfDate'. Probably we should update it...all in good time.
> 
> But not right now.

Now.

> We're busy with other things. But that's not what's
> worrying me--it's how to do it. These things must be done delicately,
> or you hurt the spell. Thorough testing would be needed. Meanwhile, I
> tried running a one-day-old case, and got an assertion failure in some
> taxation code, so I guess our exposure is not great if it can't be run
> anyway. Still, I can't wait forever to get those shoes....

I broke it into several separate commits of increasing complexity.