[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 195
  • Last Modified:

How can I organize this data [lots of variables and outcomes]

Hello,

I have a algorithms for 13 different states on how to calculate insurance premiums.  

For example, part of an algorithm for Nevada could be:

------------------
MANUAL PREMIUM [(Payroll / 100) * RATE]
+ Supplementary Disease [(SUBJECT PAYROLL / 100) * DISEASE RATE]
TOTAL MANUAL PREMIUM
+Waiver of Subrogation factor [% applied to the portion of Total Manual Premium where waiver is applicable]
-----------------

That is just a small portion of an algorithm for a particular state.  Each line can be considered a "Premium Element".  The issue is that different states have differences in Premium Elements (i.e. TN will not have a Waiver of Subrogation factor).  

The first thing I want to do, before even figuring out the best way to configure it, is compare the differences in premium elements for the various states.  

Right now, I can manually look over the data for all 13 states and create 3 columns: Premium Elements, States that have it, and States that don't have it.  However, this seems very tedious and inefficient - there has to be a better way to at least present this data.  

Any tips/suggestions would be appreciated!
0
Kenny537
Asked:
Kenny537
  • 4
2 Solutions
 
BadotzCommented:
I see no reason to combine states' algorithms. Since the differences can be great or small, and doubtless can change on a whim, I'd keep 'em all separate.

If you have a compelling reason to share code between the states, I'd like to hear it.
0
 
Kenny537Author Commented:
Well I didn't mean to necessarily combine the code.  It's more for analysis reasons at this point.
For this type of insurance (worker's compensation), if the customer has employees in multiple states, the policy would still be applicable, however, the algorithms would be calculated differently based on the respective states (as I understand it).
But to consider combining the code or not combining the code is jumping ahead - right now I simply want to present the differences in the algorithms.  

Does that make sense?
0
 
BadotzCommented:
>>right now I simply want to present the differences in the algorithms.  

For your own sanity or...?

If the sections of an algorithm are identifiable, then a column per section and a row per state sounds like a plan.
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
dr_shivanCommented:
Kenny 537,

A small suggestion would be to dissect your algorithm into different cells that contain the same items.
hence you'll get 13 rows. From there, you can have an overview of what is the common/different params from each state and the end result should you have dynamic calculations coded in.
0
 
BadotzCommented:
Delete the question.
0
 
BadotzCommented:
Or not ;-)

No worries - glad to help.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now