Price waterfall no Revenue Cloud: por que o Net Unit Price não bate (e onde procurar antes de abrir chamado)

O sintoma que todo arquiteto de Revenue Cloud já viu

Conta contratada renova e o sistema traz preço de lista. Rep edita o campo Discount na quote line e o Net Unit Price simplesmente não se mexe. Você publica uma tier nova no price book e a linha existente finge que ela não existe. Quote e order, na mesma oportunidade, calculam valores diferentes para o mesmo produto.

São sintomas diferentes, mas a causa raiz é sempre a mesma: a quote está discordando do que a própria pricing procedure, rodando através de decision tables e price books, foi configurada para produzir. Não é mágica, não é bug fantasma. É uma cadeia de quase 50 elementos rodando em ordem de Rank, cada um usando a saída do anterior como entrada, e algum ponto dessa cadeia está quebrado, mal mapeado ou lendo um snapshot desatualizado.

Uma observação de nomenclatura que confunde muita gente: o Revenue Cloud hoje é comercializado como Agentforce Revenue Management. Se você trabalha em orgs mais antigas ou segue documentação anterior, o nome antigo ainda aparece em vários caminhos de clique, principalmente no console de operações. Vou usar o nome atual, mas aviso quando o caminho depende do nome anterior.

Antes de debugar: quatro instrumentos que expõem o trace real

Não adianta ficar chutando qual elemento quebrou. Existem quatro formas documentadas de ver exatamente o que a pricing procedure fez, e cada uma serve para um cenário diferente.

• Hover no Net Unit Price da quote line: mostra o price waterfall direto na Transaction Line Editor. Só funciona se o elemento Pricing Setting tiver a output variable Price Waterfall mapeada para price_water_fall. Se estiver faltando esse mapeamento, o tooltip não mostra nada, nem dado parcial. É um known issue documentado, não um problema de renderização. Para corrigir: desative a pricing procedure ativa, abra o elemento Pricing Setting inicial, configure a output variable e reative.
• Revenue Cloud Operations Console (antigo Pricing Operations Console, renomeado no Spring '26): ative Price Logs Capture em Salesforce Pricing Setup e abra a view Pricing API Executions. Ali você vê, por line item, cada input, cada output e a sequência exata de elementos que rodou. Vale conhecer as quatro categorias de Advanced Logging: Attribute-Based Price Logs, Derived Price Logs, Price Propagation Logs e Pricing Promotion Logs.
• Pricing Procedure Simulator: dentro do Pricing Procedure Builder, botão Simulate. Aceita input via formulário simplificado ou JSON avançado, e você pode carregar a simulação a partir de uma quote real usando o Id, o que economiza muito tempo. Só a effective date precisa ser digitada manualmente, no formato exato esperado (esse detalhe já me custou uns bons minutos perdidos). O retorno é um JSON completo, elemento por elemento.
• Pricing Connect API: para chamadas headless, runSalesforceHeadlessPricing tem o input isSkipWaterfall, que controla se aquela chamada específica gera dado de waterfall. Se uma integração não está trazendo waterfall, esse é o primeiro lugar a checar, antes de suspeitar de bug. Já para inspeção posterior, o endpoint GET de Pricing Waterfall só retorna algo se a persistência estiver ligada em Salesforce Pricing Setup. Os dois não são intercambiáveis: um depende de persistência, o outro é inline e depende do flag de skip.

A lógica de debug é sempre a mesma nos quatro casos: comece no número errado e ande para trás, Rank por Rank, até achar o elemento que produziu o valor incorreto. Elementos downstream fazem o trabalho deles corretamente em cima de um input errado, por isso o número final está errado e nenhum erro é levantado em lugar nenhum.

As cinco causas que realmente valem a pena checar primeiro

1. Decision table nunca foi atualizada

Este é, de longe, o mais comum em projeto real. Decision tables não são queries ao vivo contra price book ou contrato. São snapshots sincronizados, atualizados só quando você roda Sync Pricing Data no nível de org ou clica Refresh na tabela específica. A pricing procedure lê o snapshot, não o objeto de origem.

Exemplo prático: um plano de suporte custa $400 por unidade. Você cria uma Price Adjustment Tier dando 12% de desconto a partir de 25 unidades, alimentando a tabela Volume Discount Entries. Um rep cota 30 unidades. O esperado é $400 x 30 x 0,88, ou seja $10.560. Antes do refresh da tabela, o sistema entrega $12.000, uma diferença de $1.440 sem nenhum erro visível. Depois do refresh, o hover no Net Unit Price mostra o desconto aplicado e o total corrige sozinho.

Checagem: vá em Setup, Decision Tables, abra a tabela relevante (Volume Discount Entries, Contract Pricing Entries, Price Book Entries) e olhe o Last Refreshed Date. Se não atualizar mesmo depois do refresh, dá um F5 na aba antes de assumir que a sincronização falhou, às vezes é só lag de display.

2. A procedure nunca foi conectada ao campo que o rep está editando

Rep muda Sales Price ou digita direto no campo Discount, o valor salva, mas o Net Unit Price não reage. O campo está visível e editável na interface, só que a pricing procedure nunca foi configurada para ler ele. Uma procedure minimalista, que só mapeia List Price e Quantity, reage certinho a mudança de quantidade e ignora completamente qualquer outro campo.

A correção passa por abrir a procedure no Pricing Procedure Builder e rastrear a definição de contexto para ver quais campos de QuoteLineItem cada elemento realmente lê (na aba Context Tags e depois Map Data, embora os nomes possam variar conforme a versão da sua org). Falta um List Group com List Operation, seguido de um Assignment element mapeando Sales Price para UnitPrice do QuoteLineItem, alimentando o Net Unit Price.

3. Contracted pricing nunca foi verificado

Conta com contrato ativo, Contract Item Price existente para o produto, e mesmo assim a quote traz o preço padrão do price book. A pricing de contrato passa por elementos dedicados de List Price e Volume Discount, cada um com um checkbox "Use contract-based pricing". Se qualquer um dos dois estiver desmarcado, aquele elemento resolve o preço padrão, sem contrato.

O diagnóstico rápido é olhar no waterfall (via hover) o campo IsContracted, que o elemento contract-aware escreve como output mapping. Se estiver false quando deveria ser true, marque o checkbox nos dois elementos e depois atualize as tabelas Contract Pricing Entries e Contract Pricing Volume Tiers. Vale o hábito: sempre que criar ou ativar um contrato, refresh nessas duas tabelas antes de testar.

4. A seleção de procedure andou divergindo entre duas telas de setup

Você atualiza a pricing procedure em um lugar, mas quote ou order continuam resolvendo outra procedure, ou uma versão antiga dela. Salesforce permite selecionar a procedure padrão em dois lugares diferentes: Salesforce Pricing Setup e Revenue Settings. Os dois seletores não são automaticamente vinculados.

O mecanismo oficial por trás disso: skipOrgSttPricing ignora a procedure padrão e qualquer procedure de sales-transaction-type em favor do roteamento por procedure plan, mas isso só entra em vigor se enableRevUnifiedSetup já estiver ativo. Também vale checar PricingProcedureResolution para ver se existe uma janela EffectiveFrom/EffectiveTo que já expirou. Alinhe as duas telas de seleção, confirme a combinação dos dois flags, e confirme no Revenue Cloud Operations Console qual procedure de fato disparou na execução.

5. Um setting está escondendo o aviso de preço desatualizado

Rep salva uma quote ou cria uma order em cima de preços já defasados, e nenhum aviso aparece pedindo para reprecificar. hidePriceRefreshNtfcn é um boolean em RevenueManagementSettings, default false, que oculta a notificação que Salesforce mostra quando os preços de quote ou order ficaram desatualizados. Se em algum momento alguém setou isso como true para