InsClaimItemService:calculateCoverages

Tjenesten vurderer gjeldende maksimumsbeløp for fradragsbeløp, kopiering, medforsikring og utsolgt beløp når justeringer opprettes.

Denne tjenesten evaluerer formelen for beregning av dekning hvis en er definert i dekningsspesifikasjonen.

Klasse: InsClaimItemService

Metode: calculateCoverages

Slik virker det

Tjenesten bruker objektgrensesnittfeltnavn som standardinndata og -utdata for felles felt i både Vlocity (ClaimLineItem__c) og Salesforce FSC (ClaimCoveragePaymentDetail)-datamodeller.

Denne tjenesten fungerer forskjellig avhengig av om det finnes en formel for beregning av dekning i dekningsspesifikasjonen.

Når det ikke finnes noen formel for beregning av dekning, gjør denne tjenesten følgende:

1. Bruker følgende informasjon til å hente kravposten, den tilknyttede poliseposten og attributtverdiene for både kravet og policyen.

   • claimId

   • claimCoverageId

   • claimItemId (hvis tilgjengelig)

   • claimAmount

2. Kaller opp InsPolicyTermsService: prosess service.

   Denne tjenesten beregner alle forsikrede forpliktelsesbeløp (forpliktelsesbeløp/forsikring, fradragsbeløp og maksimalt antall fradrag) og returnerer disse dataene.

3. Trekker fra de forsikrede forpliktelsesbeløpene fra kravbeløpet hvis det finnes ett eller flere forsikrede forpliktelsesbeløp.

4. Returnerer utdataene inkludert det endelige justerte beløpet og underordnede kravelementer (hvis noen).

Når det finnes en dekningsberegningsformel i dekningsspesifikasjonen, gjør denne tjenesten følgende:

• Bruker følgende informasjon til å hente kravposten, den tilknyttede poliseposten og attributtverdiene for både kravet og policyen.

  • claimId

  • claimCoverageId

  • claimItemId (hvis tilgjengelig)

  • claimAmount

• Kompilerer følgende objekter (inkludert AttributeSelectedValues <productcode.key>) for å gjøre dem tilgjengelig for formelen for beregning av dekning i dekningsspesifikasjonen:

  • Krav

  • Policy

  • PolicyCoverage (policydekning)

  • InsuredParty

  • Forsikredetegn

  • InvolvedInjury

  • InvolvedProperty

• Kjører dekningsberegningsformelen.

• Kaller opp InsPolicyTermsService: prosess service.

  Denne tjenesten beregner alle forsikrede forpliktelsesbeløp (forpliktelsesbeløp/forsikring, fradragsbeløp og maksimalt antall fradrag) og returnerer disse dataene.

• Trekker fra de forsikrede forpliktelsesbeløpene fra kravbeløpet hvis det finnes ett eller flere forsikrede forpliktelsesbeløp.

• Returnerer utdataene inkludert det endelige justerte beløpet og underordnede kravelementer (hvis noen).

Eksterne alternativer

Dette alternativet bruker grensesnittfeltnavnene som er beskrevet i denne tabellen, i inndata og utdata for vanlige felt i Vlocity ClaimLineItem__c- og Salesforce FSC ClaimCoveragePaymentDetail-datamodeller:

For felt som ikke er oppført her, bruker du feltets fullstendig kvalifiserte navn.

Attributter med ClaimLineItem-prefiks som har kravlinjeelementets API, lagres i kravlinjeelementet som opprettes.

Inndata-JSON og utdata-JSON

Hvis forhåndsdefinerte metoder for å bestemme justert beløp for en betalingsdetalj oppfyller forretningsbehovene dine, kan du hoppe over denne delen. Men hvis du vil justere betalingsdetaljbeløp på måter som ikke støttes ferdig, er denne delen for deg.

Disse forhåndsdefinerte brukstilfellene er vanligvis for scenarier som ikke dekkes av power-attributtklasser, som:

• Betinget fradrag, der to fradrag finnes i samme dekningsspesifikasjon. Utledelig A gjelder for eksempel for et brannskadetap, og Utledelig B gjelder for et flomskadetap. Du vil at systemet skal bestemme hvilket fradrag som skal gjelde for betalingsdetaljene ved kjøretid.

• Copay/Coinsurance-bestillingsrekkefølge. Coinsurance og copay finnes for eksempel begge i samme dekningsspesifikasjon, og du vil bruke coinsurance før du bruker copay på en betalingsdetalj.

• Beregning av et utbetalingsbeløp for en fordelstype. For en Tjenestebesøk-fordelstype vil du for eksempel at systemet skal beregne et beløp på 50 USD for betalingsdetaljene.

Når du har forstått JSON-formatet for InsClaimItemService: calculateCoverages-utdata, kan du implementere virkemåte som ligner på et power-attributt for å beregne utbetalingsbeløp og justeringer uten å ha en underliggende power-attributtklasse.

Før vi går foran oss selv, la oss bruke et enkelt eksempel for å illustrere utdata JSON forventes å bli returnert av InsClaimItemService: calculateCoverages. Vurder et enkelt bruksområde som støttes av den forhåndsdefinerte attributtklassen Utledbar effekt.

Eksempel: 5000 USD i kravbeløp i en polise med et fradrag på 1000 USD

Her er JSON-koden for InsClaimItemService: calculateCoverages.

{ 
	"claimId": "01t000000000000001",
	"claimCoverageId": "01t000000000000002",
	"claimItemId": "01t000000000000003",
	"additionalInput": {
		"ClaimLineItem.claimAmount": 5000
		"ClaimLineItem.description": "first party claim payment"
		"ClaimLineItem.recipientId": "01t000000000000004"
	}
}

Her er JSON-koden som returneres av InsClaimItemService: calculateCoverages.

{  
	"claimItem": {
		"adjustedAmount": 4000 // loss item adjusted amount
	},
	"claimLineItemAdjustment": {
		"attributeClass": "Deductible", // policy terms attribute class
		"adjustedAmount": 1000, // policy terms tracking entry postedAmount
		"assetTermId": "a6ERN00000000dg2AA", // policy terms id
		"remainingAmount": 0 // policy terms tracking entry remainingAmount
	}
}

Slik kaller brukerinteraksjoner i Financials-fanen opp tjenester, hvordan InsClaimItemService: calculateCoverages henter data og hva som skjer med dataene etterpå.

• (1) På Financials-fanen for et krav klikker en bruker på Ny tapselement og skriver inn et kravbeløp på $5,000. Når du trykker på Tab for å gå fra Kravbeløp til neste felt, kalles det opp InsClaimItemService: calculateCoverages. I dette eksemplet inkluderer JSON-utdataene som returneres fra InsClaimItemService: calculateCoverages, disse verdiene.

  • claimLineItem: adjustedAmount Beløpet som er betalt til betalingsmottakeren etter at fradragsbeløpet er trukket fra kravbeløpet: $5,000-$1,000=$4,000. Denne verdien vises tilbake til brukeren i feltet Justeret beløp i skjemaet Ny tapselement.

  • claimLineItemAdjustment:adjustedAmount Beløpet for justeringen av betalingsdetaljer for kravdekning, i dette tilfellet de 1000 dollar som kan trekkes fra kravbeløpet.

  • claimLineItemAdjustment:attributeClass Årsaken til at beløpet som skal utstedes til betalingsmottakeren, er forskjellig fra det kravte beløpet. I vårt eksempel reduseres det krevede beløpet med USD 1000 fordi det gjelder et deduktibeløp på USD 1000 (attributeClass = Deductible).

  • claimLineItemAdjustment:assetTermId Policy-perioden som det opprettes en policy term tracking-oppføring for. I vårt eksempel er det ID-en til Utledbare-policybegrepet.

  • claimLineItemAdjustment:remainingAmount Beløpet som skal angis i sporingsoppføringen for polisebegrepet, i dette tilfellet kr 0, fordi det ikke gjenstår noen fradrag etter denne transaksjonen.

• (2) Når du klikker på Legg til for å lagre det nye tapselementet, kalles InsClaimItemService: add opp, som bruker returnerte JSON-utdata fra InsClaimItemService: calculateCoverages til å beholde data i ClaimCoveragePaymentDetail-, ClaimCoveragePaymentAdjustment- og InsurancePolicyTermTrackingEntry-poster. (InsClaimItemService: update fungerer på samme måte.) Hver post inneholder verdier relatert til eksempelet vårt:

  • ClaimCoveragePaymentDetail-posten har en ClaimCoveragePaymentDetail.ClaimedAmount på USD 5000 og en ClaimCoveragePaymentDetail.AdjustedAmount på USD 4000.

  • ClaimCoveragePaymentAdjustment-posten har en ClaimCoveragePaymentAdjustment.AdjustedReason of Deductible og en ClaimCoveragePaymentAdjustment.AdjustedAmount på $1000.

  • InsurancePolicyTermTrackingEntry-posten har en InsurancePolicyTermTrackingEntry.PostedAmount på $1000 og en InsurancePolicyTermTrackingEntry.remainingAmount på $0.

Med en forståelse av den grunnleggende strukturen til utdata-JSON kan du konfigurere et mer avansert bruksområde ved å introdusere logikk i formelen for beregning av dekning i en dekningsspesifikasjon.

Eksempel: På Detaljer-fanen i en dekningsspesifikasjon skriver du inn en dekningsberegningsformel som denne, med samme ClaimLineItem-syntaks som brukes til additionalInput.

InvokeIP('ClaimCoverage_ClaimCoverageFormula', , INPUT('claimId', ClaimLineItem.claimId) INPUT('benefitType', ClaimLineItem.benefitType), INPUT('quantityCount', ClaimLineItem.unitCount), 'resultat')

Ved kjøretid kaller denne formelen opp en integrasjonsprosedyre kalt ClaimCoverage_ClaimCoverageFormula. Denne integrasjonsprosedyren forventer inndata for claimId, benefitType og quantityCount, som vist i dette JSON-eksempelet for inndata for testing av integrasjonsprosedyren:

{ 
	"claimId": "a2b4W000007W2pQQAS",
	"benefitType": "Ambulance - Air",
	"quantityCount": "1",
}

Dekningsberegningsformelen angir at utdata-JSON-koden for ClaimCoverage_ClaimCoverageFormula-integreringsprosedyren er i en node kalt result. Så lenge JSON-strukturen i denne result-noden samsvarer med det forventede JSON-formatet for InsClaimItemService: calculateCoverages-utdata, fungerer systemet nøyaktig som om det bruker en underliggende power-attributtklasse: vise justert beløp til brukeren og vedvarende data i ClaimCoveragePaymentDetail-, ClaimCoveragePaymentAdjustment- og InsurancePolicyTermTrackingEntry-poster etter at Legg til-knappen har blitt klikket på.

I dette utdata-JSON-eksempelet for en $50 utbetaling for et Wellness-besøk, får result-noden InsClaimItemService: add til å utføre en innsetting på 50 i ClaimCoveragePaymentDetail.AdjustedAmount.

{  
	"result": {
		"claimLineItem": {
			"adjustedAmount": "50"
			}
	},
}

Her er noen tips for konfigurering av beregningen.

• Hvis bruksområdet involverer eksisterende power-attributtklasser, kan du bruke InsurancePolicyTerms: getCurrentStandings til å finne ut hvor mye som gjenstår i en policyperiode før du bruker en justering. Dette trinnet lar deg bruke den riktige justeringen og overføre tilbake den riktige assetTermId. I disse brukstilfellene konfigurerer du JSON-strukturen som returneres av integrasjonsprosedyren, til å inkludere både claimLineItem- og claimLineItemAdjustment-nodene.

  Pass på at du gjør følgende i claimLineItemAdjustment-noden:

  • Inkluder assetTermId.

  • Inkluder attributeClass.

  InsClaimItemService: add trenger begge disse verdiene for å bestemme hvordan du oppretter posten for sporing av forsikringsbetingelse for det spesifikke power-attributtet i policyen. En dekningsspesifikasjon med en betinget utledbar verdi har for eksempel to Utledbare effektattributter: Utledbar A for brann og Utledbar B for flom. Integrasjonsprosedyren i dekningsberegningsformelen kan bruke InsurancePolicyTerms: getCurrentStandings til å bestemme at Utledelig A for denne policyen er 1000 USD og Utledelig B er 500 USD. Deretter kan integrasjonsprosedyren, basert på årsaken til tapet for dette kravet, finne ut hvilket utledelig beløp som skal brukes. Når du returnerer JSON-koden for utdata, må du passe på å returnere riktig assetTermId basert på det utledbare elementet som ble brukt.

• Enkelte brukstilfeller involverer ikke de forhåndsdefinerte power-attributtklassene, men krever likevel en justering av betalingsdetaljene. Hvis en leverandør for eksempel fakturerer mer enn en avtalt kurs, trenger du en ClaimCoveragePaymentAdjustment-post for å forklare hvorfor det justerte betalingsbeløpet er mindre enn det kravede beløpet. I disse brukstilfellene konfigurerer du JSON-strukturen som returneres av integrasjonsprosedyren, til å inkludere både claimLineItem- og claimLineItemAdjustment-nodene.

  I claimLineItemAdjustment-noden:

  • Utelate assetTermId fordi det ikke er noen power-attributtklasse som definerer denne justeringen.

  • Inkluder attributeClass som justeringsårsak (for eksempel Overforstyrringsjustering).

  InsClaimItemService: add bruker attributeClass-strengen til å fylle ut ClaimCoveragePaymentDetail.AdjustedReason-feltet selv om det ikke er noe relatert attributeClass.

• Hvis et brukstilfelle involverer et utbetalingsbeløp for en fordelstype, er det ingen avvik mellom kravte og justerte beløp. En flat avgift på 100 USD per dag gjelder for eksempel for sykehusopphold. I disse tilfellene lar du hele claimLineItemAdjustment-noden være ute av JSON-koden.