Answers - Configuration Challenge #R1

Answers - Configuration Challenge #R1

Challenge

Here is a link to the original challenge.

Answers

• First code block
  • The business purpose is to exclude transactions whose policy ID is strictly more than 8797.
  • This logic could also be moved to a transaction saved query as an alternative since it's quite simple.
  • The ToDecimal() call ensures 8797 is always compared with a numeric value. 
    • For example, should the field value be NULL, $id would become 0.
    • For example, should the field value be "123", $id would become 123.
    • Without this call, we could get an error comparing a non-numeric value to 8797.
    • The call to ToDecimal() is defensive in nature - it's possible that we'll always get numeric values, but it's best to have some safety.
• Second code block
  • The business purpose is to reduce the number of false positive crediting alerts.
  • Assume that many users are tagged as either "1099" or "W2" but not both.
  • Assume that the current plan is for "1099" users only.
    

• Assume that we have the following crediting alert level.
  

• Each time we encounter a transaction assigned to a "W2 Agent", we are going to generate an alert (ex: "Failed to credit user 'John The W2 Agent' because it is not a target of this plan"). This can be a bit annoying. It's also quite different from a scenario where we cannot credit ANY user (in which case we'd like to have a crediting alert so we can take action).
  
• If we know that the transaction can be credited to a "W2 Agent", we know that this isn't a true crediting problem - the owner field "resolves" to a user.
• So, if the owner is a "W2 Agent", we can skip over the transaction and avoid a false positive crediting alert.
• An improved version would be the following: