本文へ移動
cccskills
無料GitHub で公開

rebate-management-setup

Rebate Management setup: rebate types, payout calculations, accruals, partner rebates, program setup, compliance reporting. NOT for Sales Agreements or channel revenue management — use integration/manufacturing-cloud-setup. NOT for CPQ discounts on quotes — use admin/cpq-pricing-rules.

PranavNagrecha/AwesomeSalesforceSkills
インストール方法を見る

含まれるファイル（7）

  • SKILL.md8.6 KB
  • references/examples.md5.9 KB
  • references/gotchas.md6.4 KB
  • references/llm-anti-patterns.md3.2 KB
  • references/well-architected.md5.6 KB
  • scripts/check_rebate_management_setup.py4.0 KB
  • templates/rebate-management-setup-template.md633 B

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Rebate Management Setup

Activate when configuring Salesforce Rebate Management for channel incentive programs: volume rebates, growth rebates, market-development funds (MDF), SPIFs, and partner co-op programs. Rebate Management is a distinct feature from CPQ discounting — it calculates after-the-fact incentives based on transactions, not at quote time.

Before Starting

  • Confirm Rebate Management license and edition. It is a paid add-on: "Rebate Management is available in Lightning Experience. Available in: Enterprise, Unlimited, and Developer Editions." The object model ships as standard objects (RebateProgram, ProgramRebateType, TransactionJournal, …) that appear only when the feature is provisioned — none of them are custom objects and none carry a __c suffix.
  • Identify the source of transactions. Rebates calculate against TransactionJournal records — sourced from Orders, Invoices, a POS feed, or a data warehouse extract. This source drives the ingestion pipeline.
  • Know the finance control requirements. Most rebate programs require accounting sign-off before payout. Approval routing and GL integration must be designed before program go-live.

Core Concepts

Program → Rebate Type → Benefit → Payout

RebateProgram (API 51.0+) is the top-level container — "The rebate program your organization runs with a single account, all accounts, or specific list of accounts." ProgramRebateType is what is measured: "Provide the rebate types that are part of this program. For example, volume rebate, revenue rebate, or rebate on every transaction." ProgramRebateTypeBenefit "Defines the benefit matrix for the rebate type. For example, 5% or $200." RebateProgramMemberPayout is "The payout calculated for a member for the period," and RebateProgramPayoutPeriod is "The period of the payout calculation."

Eligibility and scope hang off the rebate type: ProgramRebateTypEligibility (note the truncated API name) holds "the rules and criteria to determine rebate type eligibility and terms for calculating payouts," ProgramRebateTypeFilter is "The definition that filters the transaction journals eligible for a rebate type," and ProgramRebateTypeProduct is "a junction between a program rebate type and a product."

Accrual accounting

Between the period start and close, Rebate Management posts accruals — estimates of the liability as transactions come in. On period close, accruals reconcile to actual payouts. Accrual frequency (daily, weekly, monthly) is a finance decision.

Transaction ingestion

TransactionJournal records are the fuel — "The transactions that need to be processed for a rebate program." They come from CG Cloud orders, Revenue Cloud invoices, Data Cloud feeds, CSV loads (ReceivedDocument "Allows partners to upload .CSV document"), or custom integrations. Schema matters — amount, participant, product, and date are what the calculation aggregates. Results land in RebateMemberProductAggregate, which "Stores the post calculation summary of journal transactions by member, period, and rebate type," with RebateMemberAggregateItem as the junction back to each contributing TransactionJournal.

Common Patterns

Pattern: Volume-tier rebate with quarterly payout

RebateProgram with a volume ProgramRebateType, and ProgramRebateTypeBenefit rows defining tier thresholds (1–1000 units → 2%, 1001–5000 → 3%, 5000+ → 5%). TransactionJournal records accumulate through the quarter. At period close, calculation runs against the RebateProgramPayoutPeriod, RebateProgramMemberPayout rows are generated, approval routes to finance, then GL posts via RebatePayment, which "Tracks if the payment has been generated for this member for back end processing."

Pattern: Growth rebate vs prior period

Benefit tied to % growth vs the same participant's prior quarter. Requires reference data on prior period baseline. Flow or a scheduled Apex sets the baseline at period start.

Pattern: MDF with manual claim approval

Participant submits an MDF claim (via portal LWC). The manual, off-calculation amount is a RebatePayoutAdjustment — "Rebate amount adjustment that needs to be given manually" — rather than a calculated RebateProgramMemberPayout. Approval + receipt review before payout. (RebateClaim and RebateClaimAdjustment are the ship-and-debit claim objects, a different program shape.)

Decision Guidance

SituationRecommended ApproachReason
Quote-time discountCPQ discount schedulesApplied before deal signs
After-sale volume rebateRebate ManagementCalculates against delivered transactions
MDF / co-op claimsRebate Management with manual payoutShipped claim workflow
Loyalty point rewardsLoyalty ManagementDistinct product
Simple referral SPIFRebate Management flat benefitOverkill for ad-hoc, use Rebate anyway for audit

Recommended Workflow

  1. Provision the license; confirm Rebate Management objects are visible in Object Manager.
  2. Map transaction source systems; build the TransactionJournal ingestion job (daily recommended).
  3. Design programs: volume, growth, MDF — one RebateProgram per program for auditability, with a ProgramRebateType per measure.
  4. Configure ProgramRebateTypeBenefit thresholds and ProgramRebateTypEligibility criteria; validate with sample journals through a scratch-org dry run.
  5. Set accrual cadence and validate with finance; set up GL posting integration.
  6. Build partner visibility: Experience Cloud page showing year-to-date accrued rebate, tier progress.
  7. Run a full period-close dry run: accruals → calculation → approval → payout → GL post.

Review Checklist

  • Rebate Management license provisioned and objects visible
  • Transaction ingestion validated end-to-end
  • RebateProgram → ProgramRebateType → ProgramRebateTypeBenefit structure matches contract
  • Accrual cadence signed off by finance
  • Approval routing in place before first payout
  • Partner portal shows accurate year-to-date figures
  • Audit report: traceable from payout back to source transactions

Salesforce-Specific Gotchas

  1. Rebate recalculation is not retroactive unless forced. Fixing a Benefit threshold after accruals have posted requires a manual recalc job; partners may see shifting balances.
  2. Transaction date drives period assignment. Out-of-order backfills can hit closed periods — either reopen for recalc or post as a next-period adjustment.
  3. Experience Cloud rebate widgets depend on the Benefit Accrual snapshot. If the snapshot job fails, partner portals show stale numbers with no obvious error.

Output Artifacts

ArtifactDescription
Rebate program catalogActive programs, benefit structures, participants
Transaction ingestion specSource, schema, schedule, error handling
Accrual and payout runbookPeriod open/close procedure
Partner visibility pageLWC / Experience Cloud layout showing YTD rebate

Related Skills

  • admin/cpq-pricing-rules — quote-time discount sibling
  • admin/experience-cloud-site-setup — partner portal host
  • admin/integration-pattern-selection — transaction ingestion

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

acceptance-criteria-given-when-then

無料

Use this skill when writing test-first, behavior-driven acceptance criteria in Given/When/Then format for a Salesforce user story. Covers happy path, edge cases, negative paths, permission boundaries, and data-state preconditions so the AC block can drive UAT scripts and Apex test design downstream. Trigger keywords: given when then, gherkin, behavior driven AC, test first acceptance criteria, scenario outline, BDD acceptance criteria. NOT for the user-story format itself (use admin/user-story-writing-for-salesforce). NOT for UAT script writing (use admin/uat-test-case-design). NOT for Apex test method generation (use agents/test-class-generator). NOT for high-level UAT planning (use admin/uat-and-acceptance-criteria). More triggers: acceptance criteria record, ac_id, req_id on a criterion, artefact under test, negative case for a rule-type requirement, no-match fall-through criterion, oracle for a Then clause, test type apex flow manual, criteria linter, check_ac_format.py, --manifest-dir.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

activity-and-task-patterns

無料

Task and Event objects: polymorphic WhatId/WhoId, Activity object model, ActivityHistory vs OpenActivity, activity timeline customization, bulk task creation, Einstein Activity Capture boundaries. NOT for turning on EAC or calendar sync — use admin/einstein-activity-capture-setup. NOT for Email-to-Case — use admin/case-management-setup. Covers ActivitiesSettings metadata, enableActivities, shared Task/Event custom fields and FLS, TaskStatus value sets, Shared Activities and TaskRelation/EventRelation, recurring and child activities, and partial-success bulk DML on Task.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

agent-action-error-handling

無料

Design Invocable Apex actions that return deterministic, agent-friendly errors instead of surfacing raw exceptions to the LLM. NOT for authoring the action itself — @InvocableMethod schema, labels, security context — use agentforce/custom-agent-actions-apex. NOT for the Apex tests that force each error branch — use agentforce/agent-action-unit-tests.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

agent-action-input-slot-extraction

無料

Use when designing how an Agentforce agent extracts structured input parameters (slots) from a user's natural-language utterance to invoke an action. Triggers: 'agent extract date from user', 'agent action argument extraction', 'agentforce slot filling', 'agent invocable input mapping', 'agent fails to fill required parameter'. NOT for action authoring (use agentforce/agent-actions) or for prompt-template variable binding (use agentforce/prompt-builder-templates).

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

agent-action-unit-tests

無料

Apex test patterns for @InvocableMethod agent actions: per-reason-code branch coverage, bulk safety, callout mocking, deterministic assertions. NOT for testing whether the agent routes to the right topic or answers well — use agentforce/agent-testing-and-evaluation. NOT for designing the error envelope the tests assert on — use agentforce/agent-action-error-handling.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

agent-actions

無料

Designing or reviewing Agentforce actions: Flow actions, Apex invocable actions, prompt-template actions, action naming, input and output contracts, confirmation requirements, and safe error behavior. Triggers: 'agent actions', 'build an agent that can look up an order', 'make the agent able to check order status', 'give the agent a capability', 'agent that can retrieve a record', 'flow action for agent', 'agent invocable action', 'action schema design'. NOT for writing the Apex class itself — use agentforce/custom-agent-actions-apex. NOT for the reason_code error envelope that stops an agent retry loop — use agentforce/agent-action-error-handling.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

PranavNagrecha のスキルをすべて見る

このスキルの問題を報告する