Salesforce Spiff 계산에 캡슐화 사용

캡슐화란 무엇입니까?

커미션 계산을 작성할 때 모든 조건, 관계, 산술 연산을 결합하는 하나의 대규모 식을 구축하는 것이 유용합니다. 캡슐화는 반대의 접근 방식을 사용합니다. 논리를 가장 작은 의미 단위로 나누고 각 단위의 이름을 지정한 다음, 명명된 해당 조각에서 최종 계산을 작성합니다.

캡슐화는 계산된 필드 수준에서 수행됩니다. 잘 구조화된 계획에서 각 계산된 필드는 단일 작업을 수행합니다. 하위 계산은 최종 지급 값을 제공하는 상위 계산에 피드됩니다.

담당자의 연간 반복 매출(ARR) 점유율이 임계값을 초과하는 현재 기간에 마감된 분할 거래에 대한 커미션을 담당자에게 지불하는 계획을 고려하십시오. 캡슐화하지 않으면 단일 식이 모든 조건과 모든 산술 단계를 결합합니다.

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)

이 식은 읽기 어려우며 추적적으로 디버그하기 어려우며 취약합니다. 필드 이름을 변경하려면 참조하는 모든 계산을 찾고 편집해야 합니다.

캡슐화를 사용하면 각 조건 및 계산된 각 값이 자체 명명된 필드가 됩니다. 최종 지급 식은 해당 명명된 필드에서 직접 판독됩니다.

다음 예에서는 필터 식과 계산된 필드를 모두 사용합니다. 필터 표현식은 true 또는 false를 반환하고 부울 논리만 사용합니다. if() 문은 지원하지 않습니다. 계산된 필드는 값을 반환하고 전체 식 구문을 지원합니다. 두 가지 모두 캡슐화로 인한 혜택은 다릅니다. 계산된 필드는 성능 혜택을 얻습니다(엔진이 결과를 저장할 때 각 필드를 평가하고), 필터 식은 구조적 혜택을 얻습니다(읽기, 유지 관리, 업데이트가 더 쉬워짐).

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)

계산된 필드의 경우 커미션 엔진이 각 필드를 한 번 평가하고 결과를 저장합니다. 후속 참조는 논리를 재계산하는 대신 저장된 값을 읽습니다. 필터 표현식은 구조화 방식에 관계없이 항상 전체로 실행되므로 이 동작은 공유되지 않습니다.

Payout 필드는 동일한 산술 및 날짜 비교를 인라인으로 재계산하는 대신 네 개의 명명된 값을 읽습니다. Split_Percent__c의 이름을 변경하는 경우 SplitARR 및 SplitARREligible만 업데이트할 수 있습니다. 지급 식은 영향을 받지 않습니다.

캡슐화의 이점

캡슐화는 모노리틱 표현식 대신 이러한 장점을 제공합니다.

• 메모리 효율성. 커미션 엔진은 문당 한 번씩 캡슐화된 계산을 실행하고 결과를 저장합니다. 후속 계산 참조는 논리를 재계산하는 대신 저장된 결과를 읽습니다. 이 접근 방식은 특히 대규모 데이터 집합을 참조하거나 관계를 이동하는 계산에 유용합니다.
• 쉬운 문제 해결. 지급이 올바르지 않을 경우 각 명명된 계산을 개별적으로 추적하여 논리가 예상과 다른 지점을 찾습니다. 이전 예에서는 ClosedInPeriod, SplitARR, SplitARREligible를 별도로 추적하여 레코드를 잘못 제외하거나 포함하는 조건을 파악합니다. 커미션 엔진이 단일 단위로 평가하므로 모노리틱 식을 검사하기가 어렵습니다.
• 간소화된 보고. 명명된 계산된 필드는 Spiff 보고서의 개별 데이터 지점으로 사용할 수 있습니다. 모노리틱 식은 최종 출력만 생성합니다. 캡슐화된 필드는 중간 값의 가시성을 제공합니다(예: 지급 자격에 관계없이 SplitARR 보고).
• 읽기 향상. SplitARR * CommissionRate를 읽는 최종 지급 계산은 동등한 중첩된 표현식보다 훨씬 더 쉽게 이해할 수 있습니다. 명명된 필드는 향후 계획을 검토하는 모든 사람에게 의도를 전달합니다.
• 확장성. 커넥터 필드가 변경되거나 비즈니스 규칙을 업데이트하면 완벽하게 캡슐화된 구성을 한 곳에서 변경해야 합니다. 이전 예에서는 자격 임계값을 20,000에서 25,000으로 변경하면 SplitARREligible만 업데이트됩니다. 임계값 인라인을 포함하는 모노리틱 식의 경우에는 임계값을 포함하는 모든 필터와 계산을 찾아 편집해야 합니다.

관계에 캡슐화 적용

개체 간 관계는 캡슐화가 적용되는 가장 중요한 장소 중 하나입니다. 계산이 필드를 검색하기 위해 관계를 이동할 때마다 메모리 및 처리 시간이 소요됩니다. 관계 호출을 캡슐화하면 작업이 한 번 진행됨을 의미합니다.

관련 개체에 대해 작업할 때 다음 접근 방식을 고려하십시오.

• 사용 가능한 경우 직접 경로를 사용하십시오. 기회 제품 및 기회 분할의 데이터가 필요한 경우 기회 개체를 통해 라우팅하는 대신 직접 OppProduct-to-OppSplit 관계를 사용하십시오. 경로가 짧을수록 이동 횟수가 줄어듭니다.
• 자기 참조 관계를 사용하십시오. OppToAccount 및 AccountToOpps를 별도의 두 관계로 만드는 대신 고유 키가 AccountId인 OppToOpp 관계를 만듭니다. 이 접근 방식은 단일 관계 정의로 동일한 결과를 달성합니다.
• 관련 개체에 대한 계산 수행. 관련 개체에서 세 개의 필드를 가져와 현재 개체의 계산에 결합하는 대신 필요한 값을 생성하는 관련 개체에서 계산된 필드를 만듭니다. 그런 다음, 관계를 통해 해당 단일 필드를 참조합니다. 하나의 필드를 검색하는 하나의 관계 호출은 여러 필드를 검색하는 하나의 관계 호출보다 비용이 저렴합니다.

예를 들어, 관계를 통해 별도로 OppSplit.SplitPercent 및 OppSplit.ARR를 참조하고 Opportunity 계산에 곱하는 대신 OppSplit 개체에 SplitARR 계산 필드를 만듭니다. 그런 다음, 기회 계산은 사전 계산된 하나의 값을 읽기 위한 단일 관계 호출을 만듭니다.

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

추적 수집으로 캡슐화 적용

캡슐화 및 추적은 함께 작동합니다. 캡슐화된 계산은 별도의 명명된 필드이므로 필드가 개별적이고 명시적으로 식별되므로 필드 수준에서 선택적으로 추적을 활성화할 수 있습니다. 담당자가 볼 필요가 없고 대규모 데이터 집합과 관련된 임시 계산에 대한 추적을 해제할 수 있습니다. 담당자가 내역서에서 검토하는 최종 지급 값 및 주요 메트릭에 대한 추적을 설정합니다.

예를 들어 지급 논리에 연간 현재 실행 합계가 중간 단계로 포함된 경우 추적이 해제된 상태로 해당 실행 합계를 자체 필드로 캡슐화합니다. 이를 참조하는 Payout 필드에는 여전히 추적이 켜져 있어 내부 누적 논리를 노출하지 않고 담당자에게 최종 번호를 제공할 수 있습니다.

// 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