User Tools

Site Tools


Sidebar

Telus TPM Documentation

claim_contract_resolution

This is an old revision of the document!


Claim Contract Resolution in Eclaim

The Eclaim process takes the following steps when it attempts to resolve a contract.

  1. EXACT_CONTRACT_ECLAIM_PASSTHROUGH
  2. XREF_CONTRACT_PAID_CLAIM/XREF_USER_CONTRACT_SEQUENCE
  3. CLAIMANT_CONTRACTEE_MATCH
  4. PAID_CLAIM (Deprecated)
  5. CLAIMANT_CONTRACTEE_MATCH_RELAXED
  6. SAME_CONTRACT_NAME_AS_RESOLVED_LINE

NOTE: Any contracts with a type of AUTOPAY will not be part of the auto matching process for claims to contract.


EXACT_CONTRACT_ECLAIM_PASSTHROUGH

Assign the exact contract sequence a user mapped in the Eclaim file if the exact contract indicator is set on the Eclaim by the load process. This bypasses all other logic and is only used if this specific flag is set on the Eclaim and the row’s Claimant Contract Identifier contains an exact match to a contract sequence in the application.

For example, if there is a mapped column in the eclaim file to Contract Sequence and the value in the file is 1001000, that eclaim row will be mapped to contract family ID 1001000 in the application.


XREF_CONTRACT_PAID_CLAIM/XREF_USER_CONTRACT_SEQUENCE

If a match for the exact claimant company, contract hint, and product exist in the new paid claim contracts and alias lookup table, we will resolve to that contract.

For a key to make it to the table, there must be at least one line paid for this product/claimant/hint against the contract in the last X days (system configurable), and no lines paid against another contract for the same product/claimant/contract hint in the same period.

Internal users may add records to this table for any product/claimant/hint that either create a new mapping or exclude a given contract for ever auto matching for that product/claimant/contract hint. New lines paid are added to this lookup table nightly, and system-created mappings for contracts that have not been paid again within the timeframe are deactivated.


All the resolutions detailed below first require the resolution of a single contractee company (or group) based on mapped claimant contractee xrefs.


CLAIMANT_CONTRACTEE_MATCH

If there is one and only one contract found for the line item’s product and time period where the contractee is the resolved company or group from the Claimant Contractee Xref, then we resolve to that contract.


PAID_CLAIM (Deprecated)

The system will look for a paid claim driven by the claimant contractee mapping and claimant contract name. If there are multiple contracts only found for the contractee, then a contract would not be matched.


CLAIMANT_CONTRACTEE_MATCH_RELAXED

If we did not find a match previously, relax the requirement that the product be eligible on the contract and that the timeframe matches. If there’s only one valid contract for the resolved contractee (either company or group), match to it.


SAME_CONTRACT_NAME_AS_RESOLVED_LINE

If one or more lines on an invoice resolved to a single contract, match all other lines with that same Claimant Contract Name to that contract. (Exception is if a specific Exclusion exists for this product/claimant/hint for the resolved contract we will NOT resolve those specific SKUs).


Lines that Did Not Resolve get coded one of two ways.

1. MULTIPLE_MATCHING_CONTRACTS

There was no paid claim xref or user-created alias, and the Contractee Match steps found multiple matching contracts, and thus we could not resolve this line to a single contract. (These will be significantly reduced over time by the paid xrefs and user-created aliases resolving before we get to the “old” process).

2. NO_MATCHING_CONTRACTS

No matching contracts were found in any of our steps for the given line item. Check the contractee mapping to ensure that is the correct contractee.


On the claim header, hover over the Contract Title to view how the contract was resolved.


Splitting Claims

Invoice Consolidation

When multiple records share the same invoice number, the system consolidates them under a single invoice identifier to maintain data integrity and streamline processing.

Claim Generation Framework

Claims are systematically generated based on the invoice structure and associated contract family relationships.

Contract Family-Based Claim Splitting

Single Contract Family Scenario

Condition: All line items within an invoice resolve to the same contract family Result: One consolidated claim is created for the entire invoice

Multiple Contract Family Scenario

Condition: Line items within an invoice resolve to different contract families Result: The system creates separate claims for each distinct contract family represented

Line Item Validation Process

Each line item within a generated claim undergoes comprehensive validation based on the following criteria:

Contractee Identifier Verification

The system validates that the contractee identifier associated with each line item is accurate and properly mapped to the corresponding contract.

Eligibility Assessment

Each line item is evaluated for eligibility across two primary categories:

  • SKU-Level Eligibility: Verification that the product/SKU is covered under the applicable contract terms
  • Lumpsum-Level Eligibility: Confirmation that any lumpsum components are authorized and properly allocated within the contract framework

Processing Workflow Summary

  1. Invoice Consolidation: Group records by invoice number under single invoice ID
  2. Contract Family Analysis: Determine contract family associations for all line items
  3. Claim Segmentation: Create claims based on contract family groupings
  4. Line Item Validation: Verify contractee identifiers and eligibility for each claim component
claim_contract_resolution.1755702236.txt.gz · Last modified: 2025/08/20 15:03 by tina.robles