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: Vadim Zeitlin
Subject: Re: [lmi] Supplemental report with zero-percent columns
Date: Wed, 30 Jan 2019 02:51:05 +0100

On Tue, 29 Jan 2019 22:54:13 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2009-09-28 13:01, Greg Chicares wrote:

 When I saw it arrive, I suspected that my MUA has mis-threaded this
message by mistakenly assuming that, just because of the same subject, this
email was a continuation of some ancient thread. But it turns out it was
right and it's really part of a discussion started 10 years ago. I find it
very impressive that you somehow still remembered about it, and it must
be pretty satisfying to finally bring this thread to the close.

GC> All such columns have been liquidated.

 This does sound final enough.

GC> > Because the desired supplemental report contains a particular
GC> > fixed set of columns, it would seem better to implement it in the
GC> > appropriate '.xsl' file, as was done in this 'nasd.xsl' template:
GC> >   <xsl:template name="supplemental-illustration-report">
GC> 
GC> With XSL-FO, that just wasn't practical.
GC> 
GC> With MST, it wasn't too terrible, or at least Vadim made it seem so;

 It really was quite simple once I understood what needed to be done
(except that I hadn't understood it quite correctly, see below). Of course,
the complicated part had been already done before when we wrote all the
code allowing to produce reports with any set of columns and dynamically
showing/hiding some of them.

GC> and I was able to make some revisions myself, more easily than I
GC> could write specifications for those revisions.

 This is good news too, but I'm afraid one of the changes might be
incomplete: as I had mistakenly decided that this report wasn't needed for
composite illustrations, I have not only added the wrong is_composite()
check which you removed in b6757ef621435de853fbc28fa06d5cd8bd5bf6d6, but I
also did _not_ add the logic for removing the "AttainedAge" column, which
doesn't make sense for them, from the composites. So I think the following
change needs to be done:

---------------------------------- >8 --------------------------------------
diff --git a/pdf_command_wx.cpp b/pdf_command_wx.cpp
index 020265bee..5d6c3735b 100644
--- a/pdf_command_wx.cpp
+++ b/pdf_command_wx.cpp
@@ -2724,6 +2724,10 @@ class finra_split_fund_report : public 
page_with_tabular_report
         // premiums case or a single premium outlay column otherwise.
         switch(column)
             {
+            case column_end_of_year_age:
+                // This column doesn't make sense for composite ledgers.
+                return ledger_.is_composite();
+
             case column_er_gross_payment:
             case column_ee_gross_payment:
                 // These columns only appear in split premiums case.
@@ -2734,7 +2738,6 @@ class finra_split_fund_report : public 
page_with_tabular_report
                 return invar.SplitMinPrem;
 
             case column_policy_year:
-            case column_end_of_year_age:
             case column_guar0_cash_surr_value:
             case column_curr0_cash_surr_value:
             case column_guar0_account_value:
---------------------------------- >8 --------------------------------------

I can create a PR for it, of course, but this is probably simple enough to
be applied even without one.

 Unfortunately I still don't see any good way to fix the "PDF !! Most
overrides have exactly this function body:" comment in table_mixin class in
pdf_command_wx.cpp, so I can't propose any way to handle the "AttainedAge"
column generically and we will just need to remain careful to not forget to
handle it in all should_hide_column() overloads that can be used in
composite illustrations.


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

 Congratulations with finally getting rid of them!
VZ


reply via email to

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