lmi-commits
[Top][All Lists]
Advanced

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

[lmi-commits] [lmi] master 3b3155c 1/5: Resolve defect markers imported


From: Greg Chicares
Subject: [lmi-commits] [lmi] master 3b3155c 1/5: Resolve defect markers imported with 7702 specifications
Date: Fri, 12 Feb 2021 11:53:49 -0500 (EST)

branch: master
commit 3b3155c6e3482295c296c228e2e6b1410e440c87
Author: Gregory W. Chicares <gchicares@sbcglobal.net>
Commit: Gregory W. Chicares <gchicares@sbcglobal.net>

    Resolve defect markers imported with 7702 specifications
    
    It is better to mark defects in code, where they're likelier to be
    noticed and fixed. Some of the "defects" marked in this document,
    which was copied verbatim from the lmi webpages repository, where it
    had hardly been touched for two decades, don't seem so defective now.
    Disposition of each:
    
      <!-- TODO ?? Move: this should refer to all assumptions ...
    
    That's a valid drafting suggestion, but it pertains to the document only
    and does not indicate any lmi shortcoming. Therefore, changed the marker
    to one less severe.
    
      <!-- TODO ?? Don&rsquo;t permit SA to decrease below the current
           corridor DB? -->
    
    This is a note-to-self from the turn of the century. Presumably it would
    have been dismissed then, had time been taken to talk it through. There
    is no evident need or justification for such a rule, and no realistic
    hope of imposing it anyway.
    
      <!-- TODO ?? But at the moment <tt>lmi</tt> seems to track the
           lowest benefit since ...
    
    Moved to 'ihs_irc7702.cpp', where it's more likely to be addressed; and
    demoted in severity, because its new context suggests that the issue may
    have been resolved in favor of doing what the comment describes.
    
      <!-- TODO ?? merge later reference? -->
    
    This document underwent many cycles of review and revision, of which
    this comment seems to be artifact: page 1438 of the OBRA House Report is
    cited in the immediately preceding footnote (with which it would not
    seem appropriate to merge this one), but nowhere else.
    
      MEC as of the (past) failure date, but [TODO ?? cite
      anticipation rules described elsewhere].
    
    Resolved by citing 7702A(d).
---
 7702.html       | 12 +++---------
 ihs_irc7702.cpp |  4 ++++
 2 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/7702.html b/7702.html
index 00fbd20..fec314c 100644
--- a/7702.html
+++ b/7702.html
@@ -1265,7 +1265,7 @@ treated like any other unilateral change (&para;5/13).
 4 To account for the possibility that current expense
 charges have changed, the admin system must provide the
 current GLP and GSP to the inforce illustration system.
-<!-- TODO ?? Move: this should refer to all assumptions,
+<!-- TAXATION !! Move: this should refer to all assumptions,
 and should also include 7PP (unaffected by expense charges,
 but affected e.g. by smoker-to-nonsmoker changes).
 -->
@@ -2205,8 +2205,6 @@ skip the rest of this
 step<a href="#fn77" name="fr77" title="">[77]</a>.
 </p>
 
-<!-- TODO ?? Don&rsquo;t permit SA to decrease below the current corridor DB? 
-->
-
 <p>
 Calculate a new seven-pay premium as
 <br>
@@ -2836,9 +2834,6 @@ The endowment
 amount is limited, as in &para;3/1, to the specified amount.
 (It&rsquo;s okay if &para;5/5 happens to overstate the endowment amount
 for C, because that is a subtractive term.)
-<!-- TODO ?? But at the moment <tt>lmi</tt> seems to track the lowest benefit 
since
-the issue date and use that value for the endowment benefit of A, B, and C.
--->
 </p>
 <p>
 [<a name="fn14" href="#fr14">14</a>]
@@ -2906,7 +2901,6 @@ so-called computational rules; or second, if the change is
 initiated by the policy over [owner] to alter the amount or
 pattern of the benefits.&rdquo; See also OBRA House Report, page
 1438.
-<!-- TODO ?? merge later reference? -->
 </p>
 <p>
 [<a name="fn21" href="#fr21">21</a>]
@@ -3313,8 +3307,8 @@ material change must be declared.
 <p>
 [<a name="fn78" href="#fr78">78</a>]
 Another interpretation is that it becomes a retrospective
-MEC as of the (past) failure date, but [TODO ?? cite
-anticipation rules described elsewhere].
+MEC as of the (past) failure date; the 7702A(d)
+anticipation-of-failure rule might also apply.
 At any rate, it is
 most likely too late to refund the offending premium.
 </p>
diff --git a/ihs_irc7702.cpp b/ihs_irc7702.cpp
index 9fd23bb..0b15efb 100644
--- a/ihs_irc7702.cpp
+++ b/ihs_irc7702.cpp
@@ -326,6 +326,10 @@ void Irc7702::ProcessAdjustableEvent
 // We changed our interpretation, but it'd be nice to preserve
 // the old functionality, conditional on a behavior flag. And
 // the name is poor: shouldn't it just be 'EndowmentBenefit'?
+//
+// TAXATION !! lmi seems to track the lowest benefit since the
+// issue date and use that value for the endowment benefit of
+// A, B, and C, which conflicts with '7702.html' [4/8].
     LeastBftAmtEver = std::min(LeastBftAmtEver, a_NewBftAmt);
 
     double b_level = CalculateGLP



reply via email to

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