Bruke oppslagstabeller og dynamisk logikk i Salesforce Spiff

Bruke oppslagstabeller i stedet for nestede IF-setninger

Når kommisjonslogikk krever samsvar mellom en inndata og en frekvens eller et nivå – for eksempel en kvoteoppnåelsesprosent som er tilordnet en akseleratorrate – er en vanlig første tilnærming å skrive en serie med if(). Denne løsningen fungerer for et lite antall nivåer. Det blir imidlertid vanskelig å håndtere etter hvert som antall betingelser øker, og hver endring i et sjikt krever redigering av formelen direkte.

Oppslagstabeller løser dette problemet ved å lagre tilordningen som data. Beregningen refererer til tabellen, slår opp på den aktuelle raden basert på inndataverdien og returnerer de tilknyttede utdataene. Å legge til, fjerne eller endre et sjikt betyr å oppdatere tabellen, ikke formelen.

Bruk oppslagstabeller i disse situasjonene.

• Kommisjonslogikken krever flere betingede grener.
• Satser eller terskler bestemmes av datoer, områder, produktfamilier eller andre attributter som endres mellom perioder.
• Flere planer deler samme frekvensstruktur og en enkelt sannhetskilde.

Lagre variabelbeløp i regnearkfelt

Hardkodede tall i kommisjonsformler oppretter skjulte avhengigheter. Når en frekvens, en terskel eller et kvotebeløp endres, må motoren finne og oppdatere alle formler som inneholder verdien. Manglende forekomster fører til feil utbetalinger.

Lagre variabelbeløp i regnearkfelt og referer til disse feltene i formlene. Når en verdi endres, oppdaterer du regnearkfeltet på ett sted. Alle formler som refererer til den, beregnes automatisk på nytt ved neste setningskjøring.

Regnearkfelt er egnet for disse typene verdier.

• Flat kommisjonssatser eller multiplikatorer som gjelder på tvers av en plan.
• Tærskelbeløp, som minimumsavtalestørrelser eller kvotemål.
• Korte lister over verdier, som kvalifiserte produktfamilier eller områdekoder.

Tips Gi regnearkfelt tydelige, beskrivende navn som kommuniserer formålet med dem. Et felt med navnet Q1MinDealSizeThreshold er enklere å finne og kontrollere enn et felt med navnet Threshold1.

Bruke deklarasjonsperioder til nøkkeldatoer

Kommisjonsberegninger refererer ofte til datoer som begynnelsen av et kvartal, slutten av et regnskapsår eller en bestemt skjæringsdato for en ny planstruktur. Hvis du hardkoder disse datoene, krever hver periode manuelle formeloppdateringer før beregningskjøringen.

Bruk uttalelsesperiodedatoer og regnearkberegninger til å gjøre datologikk dynamisk.

• Lagre nøkkeldatoer – som begynnelsen av kvartal, slutten av kvartal, begynnelsen og slutten av første halvdel og begynnelsen og slutten av andre halvdel – i ett enkelt, dedikert regneark. Referer til disse feltene fra en beregning som trenger datoen.
• Unngå å opprette individuelle regnearkberegninger for hver månedlig verdi i en serie. Det anbefales for eksempel ikke å opprette separate JanARR-, FebARR- og MarARR-felt. Returner disse verdiene dynamisk fra et datafilter, og bruk datoområdebetingelser i stedet.
• Bruk de innebygde forklaringsperiodevariablene (BeginningOfPeriod, EndOfPeriod) som grunnlag for beregning av datoer der det er mulig, slik at logikken automatisk tilpasses når det genereres setninger for forskjellige perioder.

Velge riktig nivå for beregningene

Vurder om en beregning tilhører regnearknivået eller regnearknivået før du bygger den.

Hvert nivå har forskjellige formål i kommisjonsplanen.

• Arkettberegninger. Best for verdier som gjelder for hele setningen – flatsatser, totaler på tvers av avtaler, kvoter på periodenivå og andre verdier som ikke er knyttet til individuelle poster. Beregninger av regneark produserer ett enkelt utdata for setningskonteksten.
• Datasjettberegninger. Best for verdier som krever beregning post for post – kommisjonsbeløp på avtalenivå, flagg for berettigelse per post eller hvilken som helst beregning der utdataene varierer på tvers av individuelle poster. Når en endelig utbetaling er summen av beløp på postnivå, utfører du beregningen i dataarket og aggregerer resultatet i regnearket.

Bruke hjelperfunksjoner for enklere syntaks

Spiff har hjelpefunksjoner som erstatter komplekse standardfunksjoner med flere argumenter med enklere, mer lesbar syntaks. Hjelperfunksjoner kan byttes ut med sine standardekvivalenter og produserer de samme utdataene, men de reduserer risikoen for syntaksfeil og gjør det enklere å lese formler under implementering og revisjon.

Når du støter på en kompleks funksjon som krever mange argumenter eller nestede kall, kontrollerer du om en hjelperfunksjon er tilgjengelig for dette bruksområdet. Hjelperfunksjoner er spesielt verdifulle under en første bygging når hastighet og lesbarhet er viktigst.