Inkapseling gebruiken in Salesforce Spiff-berekeningen

Wat is inkapseling?

Wanneer u een commissieberekening schrijft, is het verleidelijk om één grote expressie samen te stellen die elke voorwaarde, relatie en rekenkundige bewerking combineert. Inkapseling volgt de tegenovergestelde benadering: splits de logica op in de kleinste betekenisvolle eenheden, benoem elke eenheid en stel de definitieve berekening samen op basis van die benoemde stukken.

Inkapseling vindt plaats op het berekende veldniveau. In een goed gestructureerd plan voert elk berekend veld één bewerking uit. Berekeningen op een lager niveau worden opgenomen in berekeningen op een hoger niveau, die worden opgenomen in de definitieve uitbetalingswaarde.

Overweeg een plan dat een vertegenwoordiger commissie betaalt voor gesplitste deals die zijn gesloten in de huidige periode, waarbij het aandeel van de vertegenwoordiger in de jaarlijkse terugkerende omzet (ARR) een drempel overschrijdt. Zonder inkapseling combineert één expressie elke voorwaarde en elke rekenkundige stap.

Calculated field, without encapsulation:

=if(CloseDate >= BeginningOfPeriod
    AND CloseDate <= EndOfPeriod
    AND OwnerId == UserId
    AND ContractLength_Months__c > 12
    AND Split_Percent__c != null
    AND (Split_Percent__c * ARR) >= 20000,
    Split_Percent__c * ARR * CommissionRate,
    0)

Deze expressie is moeilijk te lezen, moeilijk te traceren en kwetsbaar — voor het wijzigen van de naam van een veld moet elke berekening worden gevonden en bewerkt die ernaar verwijst.

Met inkapseling wordt elke voorwaarde en elke berekende waarde een eigen benoemd veld. De definitieve uitbetalingsexpressie leest rechtstreeks uit die benoemde velden.

Het volgende voorbeeld gebruikt zowel filterexpressies als berekende velden. Filterexpressies retourneren true (waar) of false (onwaar) en gebruiken alleen booleaanse logica. Ze ondersteunen geen if(). Berekende velden retourneren waarden en ondersteunen de volledige expressiesyntaxis. Beide profiteren van inkapseling, maar om verschillende redenen: berekende velden krijgen een prestatievoordeel (de engine evalueert elk veld wanneer het resultaat wordt opgeslagen), terwijl filterexpressies een structureel voordeel krijgen (gemakkelijker te lezen, onderhouden en bijwerken).

With encapsulation:

// Step 1 — Qualify the period (filter expression)
ClosedInPeriod = CloseDate >= BeginningOfPeriod
                 AND CloseDate <= EndOfPeriod

// Step 2 — Qualify the rep and deal type (filter expression)
ByRepMultiYear  = OwnerId == UserId
                  AND ContractLength_Months__c > 12

// Step 3 — Compute the split amount (calculated field)
SplitARR        = Split_Percent__c * ARR

// Step 4 — Qualify the threshold (filter expression)
SplitARREligible = Split_Percent__c != null
                   AND SplitARR >= 20000

// Step 5 — Final payout (calculated field)
Payout = if(ClosedInPeriod AND ByRepMultiYear AND SplitARREligible,
            SplitARR * CommissionRate,
            0)

Voor berekende velden evalueert de commissie-engine elk veld eenmaal en slaat het resultaat op — daaropvolgende verwijzingen lezen de opgeslagen waarde in plaats van de logica opnieuw te berekenen. Filterexpressies hebben deze werking niet, omdat filters altijd als één geheel worden uitgevoerd, ongeacht hoe ze zijn gestructureerd.

Het veld Payout leest vier benoemde waarden in plaats van dezelfde rekenkundige en datumvergelijkingen inline opnieuw te berekenen. Als u de naam van Split_Percent__c wijzigt, werkt u alleen SplitARR en SplitARREligible bij. De uitbetalingsexpressie wordt niet beïnvloed.

Voordelen van inkapseling

Inkapseling biedt deze voordelen ten opzichte van monolithische expressies.

• Geheugenefficiëntie. De commissie-engine voert eenmaal per instructie een ingekapselde berekening uit en slaat het resultaat op. Volgende berekeningsverwijzingen lezen het opgeslagen resultaat in plaats van de logica opnieuw te berekenen. Deze benadering is met name waardevol voor berekeningen die verwijzen naar grote gegevenssets of traverserelaties.
• Gemakkelijker probleemoplossing. Wanneer een uitbetaling incorrect is, traceert u elke benoemde berekening afzonderlijk om te achterhalen waar de logica afwijkt van de verwachtingen. In het vorige voorbeeld traceert u ClosedInPeriod, SplitARR en SplitARREligible afzonderlijk om aan te geven welke voorwaarde records uitsluit of onjuist opneemt. Een monolithische expressie is moeilijk te inspecteren omdat de commissie-engine deze als één eenheid evalueert.
• Gestroomlijnde rapportage. Benoemde berekende velden zijn beschikbaar als afzonderlijke gegevenspunten voor Spiff-rapporten. Een monolithische expressie produceert alleen de uiteindelijke uitvoer ervan. Ingekapselde velden bieden zicht op tussentijdse waarden—bijvoorbeeld rapportage over SplitARR onafhankelijk van aanspraak op uitbetaling.
• Verbeterde leesbaarheid. Een definitieve uitbetalingsberekening die SplitARR * CommissionRate leest, is veel gemakkelijker te begrijpen dan een equivalente geneste expressie. Benoemde velden communiceren intent aan iedereen die het plan in de toekomst beoordeelt.
• Uitbreidbaarheid. Wanneer een connectorveld wordt gewijzigd of wanneer u een bedrijfsregel bijwerkt, vereist een goed ingekapselde configuratie een wijziging op één plaats. In het vorige voorbeeld betekent het wijzigen van de aanspraakdrempel van 20.000 in 25.000 dat alleen SplitARREligible moet worden bijgewerkt. Een monolithische expressie die de drempelwaarde inline inbedt, vereist het zoeken en bewerken van elk filter en elke berekening die het bevat.

Inkapseling toepassen op relaties

Relaties tussen objecten zijn een van de plaatsen met de hoogste waarde om inkapseling toe te passen. Telkens wanneer een berekening een relatie doorloopt om een veld op te halen, verbruikt dit geheugen en verwerkingstijd. Het inkapselen van het relatiegesprek betekent dat werk één maal plaatsvindt.

Denk aan de volgende benaderingen bij het werken met gerelateerde objecten.

• Gebruik directe paden indien beschikbaar. Als u gegevens uit Opportunityproduct en Opportunitysplitsing nodig hebt, gebruikt u een directe OppProduct-naar-OppSplit-relatie in plaats van routering via het object Opportunity. Kortere trajecten betekenen minder doorgangen.
• Gebruik zelfverwijzende relaties. In plaats van OppToAccount en AccountToOpps als twee afzonderlijke relaties te maken, maakt u een OppToOpp-relatie met AccountId als unieke sleutel. Deze benadering bereikt hetzelfde resultaat met één relatiedefinitie.
• Berekeningen uitvoeren op het gerelateerde object. In plaats van drie velden uit een gerelateerd object te halen en deze te combineren in de berekening van het huidige object, maakt u een berekend veld voor het gerelateerde object dat de waarde produceert die u nodig hebt. Verwijs vervolgens naar dat ene veld via de relatie. Eén relatiegesprek om één veld op te halen is goedkoper dan één relatiegesprek om meerdere velden op te halen.

In plaats van afzonderlijk naar OppSplit.SplitPercent en OppSplit.ARR te verwijzen via een relatie en deze te vermenigvuldigen in de berekening van de opportunity, maakt u bijvoorbeeld een berekend veld SplitARR voor het object OppSplit. De opportunityberekening voert vervolgens één relatieaanroep uit om één vooraf berekende waarde te lezen.

Less efficient — two relationship traversals per record:
Payout = OppSplit.SplitPercent * OppSplit.ARR * Rate

More efficient — one relationship traversal per record:
// On OppSplit object:
SplitARR = SplitPercent * ARR

// On Opportunity object:
Payout = OppSplit.SplitARR * Rate

Inkapseling toepassen met Vastleggen

Inkapseling en tracering werken samen. Omdat ingekapselde berekeningen afzonderlijke benoemde velden zijn (de velden zijn discreet en expliciet geïdentificeerd), kunt u traceren selectief inschakelen op veldniveau. U kunt traceren uitschakelen voor tussentijdse berekeningen die vertegenwoordigers niet hoeven te zien en waarbij grote gegevenssets zijn betrokken. Schakel traceren in voor de definitieve uitbetalingswaarden en de belangrijkste meetgegevens die vertegenwoordigers beoordelen op hun afschriften.

Als uw uitbetalingslogica bijvoorbeeld een doorlopend totaal van het jaar tot op heden bevat als tussenstap, neemt u dat lopende totaal op als een eigen veld met traceren uitgeschakeld. Voor het Payout dat ernaar verwijst, kan tracering nog steeds zijn ingeschakeld, waardoor de vertegenwoordiger een definitief nummer krijgt zonder de interne accumulatielogica zichtbaar te maken.

// YTDCommissions — turn off trace (large dataset, internal only)
YTDCommissions = amounts_from(beginning_of_year(BeginningOfPeriod),
                               days_ago(BeginningOfPeriod, 1),
                               plan_name)

// CurrentPeriodPayout — turn on trace (rep-facing)
CurrentPeriodPayout = SplitARR * CommissionRate

// YTDTotal — turn on trace (rep-facing summary metric)
YTDTotal = YTDCommissions + CurrentPeriodPayout