STUDY VLOCITY 🚀

Velocity (Salesforce Industries)

O Vlocity é um pacote gerenciado no Salesforce

Fornece software móvel e em nuvem específico para as principais organizações:

Vlocity CPQ

CPQ: Configure, Price, Quote

Sistema de quote-and-order-capture (captura de cotação e pedido) baseado cloud-based

(em nuvem) que é construído de forma nativa e aditiva na plataforma Salesforce.

⁃ Configura ofertas de produtos adequadas ao cliente.

⁃ Impulsiona dados subjacentes de produto-serviço-recurso (PSR)

⁃ Oferece captura de pedidos e vendas guiadas.

OSS: Operating Support Systems- abrange o lado das operações e da rede da empresa de
telecomunicações.

Exemplo:

• Configuração
• Garantia de serviço
• Planejamento de rede

BSS: Business Support Systems - abrange o lado comercial e do cliente.

Exemplo:

• Cobrança
• Ordens de clientes
• Assinaturas
• Notificações de clientes
• Cumprimento do serviço

Vlocity CPQ (agora industries CPQ) é um dos componentes da plataforma.

Automatiza o processo de geração de cotações e os fluxos de vendas.

Communications Cloud

O que é?

É um conjunto abrangente de CRM omnichannel, varejo, catálogo de produtos

corporativos, configuração de cotação de preço (CPQ), gerenciamento de contratos e
aplicativos de gerenciamento de pedidos.

-> O Communications Cloud se integra ao Salesforce Marketing, Sales e Service Clouds,

fornecendo funcionalidades específicas para o setor de comunicações.

⁃ Realiza análises e inteligência artificial (IA) para oferecer uns serviços guiados e
personalizado aos seus clientes.

⁃ Aprimora a experiência do cliente B2B e B2C.

Salesforce Communications Customer 360

Communications Cloud: Capturar cotações e pedidos e, decompor os pedidos com a

poderosa plataforma Industries Order Management
Dados não centralizados: São considerado todos os dados de negócios e clientes
necessários para resolver os problemas subjacentes que afetam a qualidade dos dados e
garantir o pedido perfeito.

A cloud de communications está de acordo com o TM-forum (regras de comunicação e

processos de indústrias de telecom)

Usando o data model de communication, esses são os componentes para solução de

problemas:

• Industries Configure, Price, Quote (CPQ)

• Enterprise Product Catalog (EPC)
• Contract Lifecycle Management (CLM)
• Industries Order Management (IOM)

Lead-to-cash - Fluxo de Processo Típico

Um fluxo de lead-to-cash típico envolve cada uma das etapas mostradas abaixo.

O diagrama mostra o fluxo típico de tarefas desde a geração de um lead até o início do
ciclo de faturamento do cliente e o atendimento ao cliente subsequente.

Order-capture (Captura de Pedidos usando Indústrias CPQ)

Order-capture é um recurso do Industries CPQ.

Seu objetivo é garantir perfect order (pedido perfeito) para o cliente.

⁃ Controlling the selling process (controlando o processo de venda) usando o

Carrinho e um sistema de pedidos Asset-based (baseado em ativos).

-> (CSRs) - Customer service representatives - Representante de atendimento ao cliente.

-> Sales teams - Equipes de vendas

Ambos acima podem realizar uma variedade de tarefas de negócios por meio de vendas
guiadas para capturar o pedido perfeito do cliente.

O (PSR) product-service-resource são dados do Enterprise Product Catalog (EPC).

⁃ É considerado o catálogo mestre de produto.

⁃ Sustentam a solução industries CPQ.

Fluxo de Orden Capture

• Oportunidade, Cotação, Pedido e ativo são objetos padrão do Salesforce.

-> Dois tipos de fluxos de processo incluem:

• Business to business (B2B), que começa em uma conta comercial.

• Business to consumer (B2C) , que começa em uma conta de consumidor.
CART

⁃ É a interface do usuário do carrinho de compras.

⁃ Você pode modificar a aparência e o comportamento

O Vlocity Card Framework fornece cartões, layouts e modelos configuráveis

⁃ São blocos de construção de IU prontos para uso no Industries CPQ.

Feature take-me-there (Leve-me lá):

⁃ Mostra onde são necessários mais detalhes para concluir o pedido

O Cart CPQ NÃO é um componente OmniScript

Cart Technology

⁃ Arquitetura aberta e estrutura extensível

⁃ Baseado em Angular JS, HTML 5 e SMACSS
⁃ Construído na plataforma Salesforce

Basic Layout:
• Cart Header

O Cart Header mostra a conta, pedido, cotação ou nome da oportunidade, lista de preços
relevante e botões de ação do OmniStudio.

⁃ Products, Promotions, and Discounts lists - exibem os produtos, promoções e

descontos disponíveis para o cliente. 

• Product list

Lista de Produtos que inclui as guias Produtos, Promoções e Descontos.

⁃ Price lists and rules determinam quais produtos são exibidos na lista Produtos.

⁃ Qualified: exibe itens que você pode adicionar ao Carrinho.

⁃ Disqualified: lista todos os itens que não podem ser adicionados. (indisponibilidade
ou inelegibilidade do cliente)

• Cart View and Total Bar

Cart View - Exibição de carrinho:

⁃ Mostra os itens no carrinho de compras como line items.

⁃ Você pode configurar produtos e serviços.

* Guia PROMOTIONS: todas as promoções atualmente aplicadas aos itens de linha

do carrinho.

* Guia DESCONTOS: todos os descontos atualmente aplicados aos itens de linha do

carrinho.

Total Bar - Barra total:

⁃ Mostra o preço total dos itens na área Carrinho, incluindo cobranças únicas e
cobranças recorrentes.
Ações OmniStudio

Com a ação de botões do OmniStudio, você implementa botões para uma variedade de
diferentes tarefas de captura de pedidos.

Rules
As regras ajudam a garantir que cada pedido seja perfeito.

Duas estruturas de regras trabalham em conjunto para filtrar a lista de produtos, para que
seja aplicada ao cliente.

Começa no EPC -> FILTRA no Context Rules Framework -> faz o refinamento final no
Advanced Rules Framework -> e apresenta no carrinho.

O diagrama mostra como as duas estruturas de regras funcionam juntas no Carrinho.

• Business rules, compatibility, configuration, and validation rules

⁃ Verificam a compatibilidade e o preço dos produtos.

• Configurable validation

⁃ Permite que o botão de enviar permaneça desabilitado e mostra "Incompleto" até

que o pedido seja válido.
TM Forum

TMForum, o principal fórum de normatização de padrões de arquiteturas de Telco no

mundo:

https://www.tmforum.org/

Associação global do setor para provedores de serviços e seus fornecedores no setor de

telecomunicações.

⁃ É o padrão de modelagem para o setor de comunicações.

⁃ EPC é flexível, adaptável e compatível com o modelo SID/TM Forum Frameworx

Camadas PSR

Product-Service-Resource Layers

"PSR": Produto, serviço, recurso

Guided Selling - Venda guiada

Permite interagir com a funcionalidade do Industries CPQ em uma experiência digital

omnichannel.

⁃ Consiste em etapas para orientar o usuário pelo processo de recomendação, seleção

e pedido de produtos.

⁃ Baseada no OmniScript.

Os OmniScripts permitem que você crie interações envolventes com o cliente usando uma
ferramenta de design.

⁃ Recuperar produtos selecionáveis, incluindo fotos de produtos.

Guided CPQ - CPQ guiado

Use o OmniScript Designer para criar processos guiados de captura de pedidos.

Asset - Ativo

É um item de valor que uma conta ou contato possui (ativos como produtos ou serviços)

• No Salesforce, os ativos são produtos ou serviços capturados durante o processo

de captura de pedidos.

Asset object oferece suporte a descontos, preços especiais e preferências do cliente.

⁃ A sua criação depende do fluxo do processo.

Asset-based

Permite gerenciar produtos e serviços em todo concept-to-care process (processo do

conceito ao atendimento) para:

⁃ Comprar novos produtos ou serviços

⁃ Adicionar um serviço ou produto.
⁃ Atualizar um serviço
⁃ Desconectar um serviço

Asset-Based Ordering

Customer Lifecycle
• No primeiro estágio da captura de pedidos, uma oportunidade passa para uma
cotação e depois para um pedido.

• Com a finalização do pedido, o pedido se torna um assets.

• Em algum momento, pode ser necessário reverter o assets de volta ao status do

orders.

⁃ Depois que um asset estiver em uma quotes ou orders, você pode realizar uma
atualização MACD (move-add-change-delete)

Podendo querer alterações seus asset de várias maneiras.

⁃ Adicionando um serviço
⁃ Atualizando um serviço
⁃ Desconectando um serviço

• Criar um pedido de um asset existente, o status do item de linha será Existing

Reverting asset

Reverter ativos é um recurso para alteração.

Exemplo:

⁃ Um ano depois de ter adquirido o produto inicial ou serviço o cliente deseja fazer
alteração de serviço. (Ex: Se o cliente mudar de residência)

Moving Assets - Guided Process

É uma ação de mover acionada por um processo de interação guiado por OmniScript.

O botão de ação mover aciona o OmniScript de Moving Assets para guiá-lo pelo processo
de movimentação, no qual você define as datas e locais de movimentação de saída e de
entrada.
OBS: Processo guiado NÃO permite criar pacotes de produtos no carrinho.

Order Cancellation

Não é apenas um ajuste MACD (mover-adicionar-alterar-excluir) é o cancelamento de um

pedido que foi capturado, mas não totalmente cumprido.

CPQ e Industries Order Management (iOM) precisam trabalhar juntos para dar suporte em:

• Cancelar parte de um pedido

• Cancelando todo o pedido

“E se um cliente fizer um pedido, mas precisar cancelá-lo antes de concluí-lo?”

R: Isso requer Industries Order Management (iOM)

Terminologia no cancelamento de pedidos e as comunicações entre as Indústrias

CPQ/OM

• In-flight order - Pedido em andamento - Um pedido que foi enviado (do CPQ para
o iOM), mas não concluído.

• Supplemental order - Pedido suplementar - Um pedido criado pela Industries CPQ

para revisar um pedido em andamento. Pedidos suplementares substituem o pedido
original em voo.

• Point of no return (PONR) - Ponto no processo de orquestração de pedidos que,
uma vez passado, o cancelamento do pedido não é mais possível ou permitido.

⁃ Se o PONR não for aprovado - as tarefas concluías são revertidas (ou “desfeitas”)
com base na conf. anterior.

⁃ Se o PONR for aprovado - OM rejeita a solicitação de cancelamento do CPQ, ou

parte dela.

OBS: Se o OM aceitar a solicitação de cancelamento, o CPQ gera automaticamente o

pedido suplementar com base no pedido original e atualiza o status do pedido.
Quotes

Preços propostos dos produtos e serviços da sua empresa

⁃ No salesforce você cria uma cotação de uma oportunidade e seus produtos. (Tag
Quotes)

⁃ Criar cotações de um ativo existente como parte do processo de pedido baseado

em ativos.

Change to Quote

⁃ Inicia uma ação CPQ Create Quote OmniScript, que cria uma cotação para os ativos
selecionados e abre a cotação no carrinho. (Button).

• Os itens criados a partir do botão terão o status "Existing".

Field Mapper

É uma ferramenta de mapeamento declarativa.

⁃ Objeto de origem e o objeto de destino. source object / destination object

Objetos para conversão:

• Opportunities to quotes
• Quotes to orders
• Orders to assets
• Assets back to orders
• Assets back to quotes

Commercial Assetization - Ativo Comercial

⁃ Armazena instâncias de produtos comerciais no Salesforce. (produtos ou serviços que

o cliente comprou.)

imobilização comercial

⁃ Definir um produto como ativo, é o produto rastreado como um ativo na conta do

cliente.

⁃ Defina produtos comerciais como não ativáveis, no app do SF.

⁃ Apenas produtos de um determinado valor são

⁃ Commercial assetization é diferente de technical assetization.

Product as not assetizable

Caso não quiser rastrear o valor comercial de um ativo do cliente, deverá configurar o
produto como não ativo.

Exemplo:

Produto: Capa de iPhone 8

Acima mostra a opção Not Assetizable na configuração do produto.

Not Assetizable

Campo personalizado (Custom Field)

⁃ Salesforce Edit Order Product Custom Field

Field Information:

• Field Label: Not Assetizable

• Field Name: IsNotAssetizable (using Pascal case)

Fórmula Options:

• Fórmula Return Type: Checkbox

• Not Assetizable (Checkbox) =:
vlocity__cmt__Product2Id_r.vlocity_cmt__IsNotAssetizable__c

Order Products é Objeto Salesforce (sObjects) e é preciso criar manualmente o campo Not
Assetizable.
Industries Order Management (iOM)

Intermediação entre dados necessários para atender os produtos e serviços em um pedido.

⁃ Controla as interações com o sistema externo de atendimento

O gerenciamento é feito por dois processos:

1. Decomposition - Decomposição - Mapeia produtos comerciais para produtos

técnicos

⁃ Mapeia informações de pedidos comerciais em informações técnicas de pedidos

necessários para vários sistemas de atendimento.

2. Orchestration - Orquestração - Comunica informações técnicas com sistemas de

atendimento downstream

Produtos comerciais: são o que o cliente vê e entende (ex: telefones e pacotes)

Produtos técnicos: contêm os sistemas de atendimento de informações necessários (ex:

faturamento, provisionamento, ativação…)

OBS: Os clientes são protegidos dos detalhes dos produtos técnicos.

(O cliente não se importa com detalhes como liberar recursos da porta para receber
internet doméstica.)

A saída do processo de decomposição é usada como entrada para o processo de

orquestração

Orchestration Plan

⁃ São gerados dinamicamente, sequenciamos e monitorados de acordo com o

contexto do pedido.
Order Management simplifica a visualização dos estados de relance.

• O States do plano em si é "Em andamento".

Existem mais 2 States comuns para Orders Cancelled

• Cancelado/Cancelled - Tarefa que foi cancelada.

• Descartado/Discarded - Task não foi executada quando uma ordem suplementar

exigiu que ela fosse cancelada.

• O Status das tasks individuais são codificados por cores:

• Concluído/Completed (OC2 Start) (verde)

• Pronto/Ready (OC2 Pause) (azul)

• Pendente/Pending (OC2 Stop) - A tarefa está pronta para ser executada, mas ainda
não foi iniciada. (Ele está aguardando a conclusão de uma dependência de tarefa antes de
ser executado.) (cinza)

OBS: quando você passa o mouse sobre uma tarefa, o status é exibido.
Shared Catalog (EPC) - Catálogo Compartilhado (EPC)

Armazena toda informação necessária para realizar pedidos e serviços oferecidos.

Um único catálogo de produto em um só lugar, com vários assinantes e sistemas que

consomem os dados

Principais recursos:

“Centro de Comando EPC”

Itens contidos no catálogo compartilhado:

⁃ Produto técnico
⁃ Produto comercial
⁃ Relação de decomposição

• Experiência de usuário unificada para gerenciar elementos EPC em uma única

interface contextual.

• Produtos
• Atributos
• Listas de opções
• Tipos de objeto de produto

• Criando "Office Internet Solution" no console do produto

1. Criar listas de opções de atributos.

2. Crie atributos e associe-os às listas de opções de atributos.
3. Criar tipos de objeto.
4. Criar um pacote de produtos para a solução Office Internet.
5. Revise o novo produto no carrinho.

Managing the Shared Catalog

⁃ Quando são feitas alterações no catálogo compartilhado, os administradores do

catálogo precisam determinar quando executar cada tarefa.

Exemplo:

Se você executar os trabalhos Product Hierarchy Maintenance ou Refresh Platform Cache

enquanto os usuários estão utilizando o CPQ, poderá causar problemas na API.

Delete Old Data

Permite limpar dados antigos ou mantê-los.

⁃ Para mantê-lo, as APIs executarão os dados antigos até que os novos dados
estejam em vigor.
Cache nas Indústrias CPQ

Técnica de otimização de desempenho para situações em que os mesmos dados serão

necessários em várias transações.

“CPQPartition”

⁃ É instalado junto com o manage pack, mas você precisa habilitá-lo e garantir que
ele tenha espaço suficiente alocado.

⁃ O cache da organização executa essa função armazenando propriedades de

hierarquia de produtos (pares de valores-chave JSON), regras, preços e propriedades
de itens de linha para toda a sua organização.

Exemplo:

Quando um usuário cria um pacote de produtos contendo produtos filhos, a organização

armazena em cache a hierarquia do produto. Assim, quando qualquer usuário adiciona
o pacote de produtos ao carrinho, o carrinho realmente recupera os dados da hierarquia
do produto do cache.
EPCProductAttribJSONBatchJob

É usado para calibrar os atributos do produto

É um lote do Apex chamado EPCProductAttribJSONBatchJob para reprocessar esses

atributos de produto e salvar o campo JSONAttribute com os IDs de registro de atributo
de sua nova organização.

⁃ Sempre que você girar uma organização ou importar dados que contenham
atributos de produto, como a criação de um ambiente de sandbox, você deverá corrigir os
IDs de registro de atributo do produto.

Picklists

• Projetadas para serem reutilizáveis em atributos, produtos e ofertas.

• Propriedades de nome, código e tipo de dados são obrigatórios.

• O nome da lista é apenas um design e não em execução. Isso significa que não é
visível para os clientes.

• Recomendamos (mas não aplicamos):

• Use a convenção de nomenclatura PKL_[code]

• Definindo o sinalizador ativo e a data efetiva de

Product Attributes

É uma maneira flexível de estender entidades de produtos.

Antes de criar um atributo de produto é necessário criar o attribute category.

Os atributos do produto podem ser atribuídos diretamente a um produto ou a um tipo de

objeto de produto, o que permite que ele seja herdado.
• Filtrar produtos em tempo de execução.
• Configure as especificações do produto em tempo de execução.
• Altere o preço do produto usando regras de preço baseadas em atributos.
• Em Industries OM, para mapear produtos comerciais para produtos técnicos.

Propriedades Gerais

⁃ Attribute Name: é obrigatório e visível em tempo de execução.

⁃ Attribute Code: é obrigatório, mas não é visível em tempo de execução.

(OBS: Recomenda-se a convenção de código de nomenclatura: ATT_[código]. Isso facilita

a identificação do tipo de elemento EPC.)

⁃ Attribute Category: é obrigatória e é criada por meio de Categorias de Atributo no

Console do Produto.
⁃ Picklist: Opcionalmente, você pode designar valores para seu atributo.
⁃ Filterable: Pode ser usado para filtrar lista de produtos e pedidos de itens no
carrinho.
⁃ encrypted: O atributo pode ser criptografado se ele contiver informações
confidenciais.

https://vlocity-university.litmos.com/course/2200192/module/5008402/Scorm?LPId=81825

Qual item criar?

Field:

• Se o elemento de dados for comum a todos os produtos em todo o catálogo de

produtos, crie um campo no objeto Produto.

Attribute:

• Se o elemento de dados for específico de um produto ou classe de produto, crie

um atributo de produto.

Antes de criar um atributo de produto, crie o tipo de objeto

Attribute Binding

⁃ Vincula um atributo ao campo de quantidade de uso para que, ao alterar o valor

do atributo, você também altere o valor do campo.

Picklists e Attributes

⁃ São objetos que trabalham juntos para fornecer os valores válidos para um
determinado atributo.

Object Types

Entidade reutilizável que define propriedades, como campos e atributos e layouts para todas
as instâncias do produto.

⁃ São como os tipos de registro do Salesforce, mas com recursos aprimorados.

⁃ Usado para agrupar produtos com semelhanças e garantir comportamento

consistente para aplicação de regras.

⁃ Oferece suporte à herança de hierarquia. (Permite criar esses objetos como um

dispositivo móvel)

⁃ São projetados como uma arquitetura de herança "Is A”.

EPC - Product Object Types

Recomendado a criação de um “Base Product” durante a configuração inicial.

Base Product sera o pai de todos os subtipos, podendo ser criado um tipo de objeto filho

⁃ Este será o “objeto primordial” do seu catálogo de produtos e deve incluir todos os
campos do catálogo de produtos.
• Object Type para classes de produtos específicos podem ser criados para herdar o
layout, os campos e quaisquer atributos do Produto Base.

• Atributos e campos herdados não podem ser excluídos. (São removidos do supertipo
de objeto.)

• Novos atributos e campos atribuídos a um tipo de objeto serão herdados

dinamicamente por seus subtipos.

Facet and sections:

⁃ Facetas são páginas com links correspondentes que aparecem no menu de

navegação à esquerda.

⁃ Elementos de layout, como campos ou elementos personalizados baseados em URI,

são agrupados em seções.

(OBS: No Vlocity Product Designer, apenas a faceta Propriedades gerais é exibida e

editável.)

O que é uma faceta no Product Console?

⁃ Uma entidade composta por seções e elementos que aparece no menu de

navegação à esquerda no Console do produto

Product Life Cycles

Processo pelo qual cada produto passa desde a sua introdução até a sua retirada.

Existem quatro estágios:

• Introdução
• Crescimento
• Maturidade
• Declínio
O catálogo de produtos compartilhado oferece suporte a ciclos de vida de
produtos comerciais, permitindo que você defina:

• Produto atual (está atualmente disponível)

• Produto futuros (será vendido no futuro) - relógio verde
• Produtos anterior (não está mais à venda) - relógio amarelo
• Produtos aponsentados (não tem mais suporte) - relógio vermelho

Product Selling Period Dates

Os campos do período de venda do produto têm um tipo de dados de data/hora e destinam-

se apenas a produtos comerciais.

-> Datas do período de venda do produto são definidas na faceta Propriedades gerais do
produto.

• Start Date: (quando o prod. Comercial pode ser encomendado ou vendido)

• End Date: (Não está mais disponível p/ pedido)
• Fulfilment Star Date: (Quando o prod. Comercial está pronto ser atend.)
• End of Life Date: (O produto não é mais suportado)

Regra que válida todas as datas e horários inseridos no Product Console

SellingStartDate < = FulfilmentStartDate < = SellingEndDate < = EndOfLifeDate

Os dados do período de venda do produto são armazenados no cache da plataforma.

⁃ Após alterar algum campo você deve atualizar os dados da hierarquia do produto no
cache da plataforma.

Find References button

Localizar referências a um determinado produto.

⁃ Ajuda a determinar o efeito da alteração do período de venda do produto e das datas

de fim de vida.
⁃ Para cada objeto de referência é retornado 20 linhas padrão. (Config. Até 1000)

Products and Product Bundles

EPC Product

⁃ Todos os produtos devem ser criados com um tipo de objeto.

⁃ Atributos e campos podem ser atribuídos diretamente a um produto.
⁃ Produtos comerciais devem ter um preço, ser Encomendáveis e Ativos.
⁃ Produtos são agrupados usando um relacionamento (“Has-A”)
⁃ Usar Specification Type para designar Produtos, Ofertas, Recursos e Serviços.

Creating Products in the Product Console

1. Criar pacote de produtos

2. Defina os atributos
3. Adicionar produtos filhos
4. Adicionar à lista de preços

Create a New Order and Invoke the Cart

1. Create a New Order

2. Invoke the Cart
3. Add New Product to the Cart
4. Configure Product Attributes
Pricing

O Industries CPQ oferece um sistema de preços baseado em componentes com itens

reutilizáveis, como cobranças, descontos, ajustes e penalidades.

⁃ Componentes de preços são independentes dos produtos.

⁃ Permite transição para novas estruturas de preços.

Industries Solutions

⁃ Criar, configurar e gerenciar componentes de definição de preço.

⁃ Pode ter preços diferentes, como preço base, multas, cobranças e ajustes nas
cobranças.

⁃ Como será cobrado por sua compra.

⁃ Permitem definir mais de um preço base para um produto e pacotes de produtos.

⁃ Reusabilidade: sistema orientado a componentes com itens reutilizáveis

⁃ Atualização mais fácil: capacidade de transição de preços mais antigos para

preços mais recentes

Pricing Model

• métodos diferentes (Reutilizado, escalável).

• Atribuir mais de um preço base a um produto
• Preços separados para necessidades de negócios, como descontos para funcionários
ou acordos de nível de serviço ao cliente

Assigning Prices to Products

É um conjunto de componentes de precificação atribuídos a um produto.

Ao atribuir um preço a um produto, você está criando uma entrada de lista de preços.

⁃ Para garantir que um produto apareça na lista de PRODUTOS do Carrinho, atribua

um preço a ele.

⁃ Se um produto não tiver entradas na lista de preços marcadas como base price, os
preços na lista PRODUTOS serão exibidos como zero.

Pricing Components

Atribuir preços a produtos e ajustar os preços base por uma porcentagem ou valor. Os
componentes de preço são reutilizáveis.

Para precificar um produto, você deve criar listas de preços, variáveis de precificação e
elementos de precificação.

⁃ Criar planos de tempo e políticas de tempo conforme necessário.

Componentes de preços necessários:

• As listas de preços contêm as entradas da lista de preços e os elementos de preço.

⁃ Quando usamos várias listas de preços pode atribuir mais de um preço base ao
mesmo produto.

⁃ Para múltiplas entradas de lista de preço é necessário o intervalo de datas de

vigência, para que os preços não interfiram.

• As variáveis de preço indicam o tipo de preço.

• Os elementos de preço contêm o valor.

Componentes de preços que podem ser necessários:

• Os planos de tempo limitam a duração do preço.

• As políticas de tempo especificam quando o preço começa e termina.

Pricing Elements

Tipos básicos de elementos de precificação:

• Encargos para atribuir um preço base

• Ajustes para ajustar um preço base
• Substituições para substituir um preço base

Altere preços de qualquer produto ou produto filho em pacote, sem alterar o preço base,
com;

-> Adjust/ Ajustar: usa o preço base para calcular um desconto percentual ou um
desconto de valor.

⁃ Requer um cálculo que usa o preço base.

⁃ Ajustar o preço de um produto filho, a alteração do preço base pode ser uma
porcentagem ou um valor.

-> Override/ Substituir: substitui o preço base.

⁃ Quando criamos um ajuste ou uma substituição ao preço base de um produto,

estamos criando uma entrada de lista de preços que é armazenada na mesma lista de
preços que o preço base.

⁃ Ajustes e substituições são criados na estrutura do produto do pacote.

Pricing Bundles

Um pacote é um agrupamento lógico de produtos em um "pacote".

O nível superior do pacote é considerado o Parent products.

Todos os produtos abaixo deste nível são considerados Child products.

⁃ Para mostrar um preço inicial para um pacote com produtos filhos opcionais,
precisamos alterar o texto de exibição para mostrar o preço inicial.

Time Plan

É o período para que o preço seja aplicado a um produto.

Exemplo:

Uma assinatura de 2 anos do serviço celular tem um plano de 24 meses.

Configuração:

• Duração total do tempo

• As unidades de medida para a duração: Dia, Semana, Mês, Ano

Time Policy

Indica quando o preço começa e para de ser aplicado.

Exemplo:

Uma assinatura que começa na data da compra e termine no final do ciclo.

Configuração:

Start Policy

• Data de compra: Envia o pagamento e assina o contrato.

• Data de início do ciclo: Próximo ciclo de cobrança começa.
• Primeiro dia do mês.
• Início da ativação: Data da ativação do serviço.

End Policy

• Fim do plano: o último dia de duração do plano.

• Término do ciclo: o último dia do ciclo de cobrança.
• Definido pelo Gerenciamento de Pedidos.
• Último dia do mês.

Type

• Iniciar proporcional (ligado/desligado)

• Final proporcional (ligado/desligado)

Start Time Delayed

• Hora de início atrasada (ligado/desligado)

• Delay Offset: Valor, suportando números positivos e negativos
• Unidade de medida de compensação de atraso: dia, semana, mês ou ano
•

Promotions and Discounts

Adicionar várias ofertas promocionais (produtos e clientes qualificados) e atribuir descontos
especiais.

Advantages of Promotions

Oferece flexibilidade e funcionalidade automatizada para projetar e implantar promoções e

descontos.

• Você pode criar promoções em produtos e pacotes de produtos existentes.

⁃ As promoções são separadas e distintas dos produtos.

Quaisquer promoções que você criar podem ser aplicadas a produtos sem alterar os
produtos.”

⁃ Promoções desqualificadas podem ser vistas no carrinho.

-> A funcionalidade automatizada pode ser baseada em:

1. Time plan/commitment duration - Plano de tempo/duração do compromisso da

promoção.

Exemplo:

⁃ Multa pela rescisão antecipada de uma assinatura.

⁃ Promoção subsequente, começa automaticamente quando a anterior termina.

⁃ Você pode usar uma Context rule para emitir uma penalidade.

2. Service continuation - Continuação do serviço

⁃ As assinaturas podem ser canceladas automaticamente ou continuar após o

término de uma promoção.
⁃ Se a promoção estiver definida como Manually Opt Out, - Desativar Manualmente, o
cliente entrará em contato para solicitar o término da assinatura.

⁃ Pode ser aplicada a ativos e itens do carrinho.

Qual é a diferença entre um produto e uma promoção?

Produto:

Podem ser agrupados com os preços dos produtos filhos totalizados (ou “acumulados”) e
adicionados ao preço do produto pai.

• Pode ser usado continuamente e normalmente não expira em breve

• Pode conter vários pacotes

• Um produto é útil quando não há limitações.

Promoção:

São produtos individuais ou pacotes de produtos que você cria para um número limitado
de:

• Tempo
• Grupo de clientes
• Subconjunto de produtos

Crie uma promoção quando:

• Oferecer descontos por tempo limitado.

• Um grupo limitado de produtos para vender.
• Para um conjunto limitado de clientes que deseja alcançar
Adjusting the Prices of Products in a Promotion

Alterar o preço de qualquer produto em uma promoção ajustando o preço por uma
porcentagem ou valor, podendo também definir quanto tempo o preço ajustado durará.

⁃ Não é necessário executar tarefas Manutenção da hierarquia do produto, limpar

cache da plataforma ou atualizar cache.

Overriding the Prices of Products in a Promotion

Substituir o preço de um produto em uma promoção em vez de ajustá-lo por uma

porcentagem ou valor.

Exemplo:

Em vez de ajustar o preço para 20% de desconto em US$ 34,99 por 3 meses, você substitui
o preço de US$ 34,99 por US$ 24,99.

⁃ Não é necessário executar tarefas Manutenção da hierarquia do produto, limpar

cache da plataforma ou atualizar cache.

Refining Promotions

Update Scope

Controla como a promoção é aplicada ao pacote no carrinho.

Há duas opções de configuração para o campo Update Scope ao criar uma promoção para
um pacote de produtos.

Update Item Only: o produto pai é o único produto atualizado.

Update Item and Child Items: o produto pai e seus produtos filhos são atualizados.

Deleting Promotions

Existem duas configurações para excluir promoções no carrinho.

Deep Delete

⁃ Exclusão profunda remove a promoção e suas alterações junto com os produtos

pertencentes à promoção.

⁃ Configuração padrão para DeleteServices.

Shallow Delete

⁃ Exclui apenas a promoção e suas alterações (descontos e cardinalidade).

⁃ Produtos em que a promoção se aplica permanecem no carrinho.

⁃ Edite a configuração no DeleteServices.

Vlocity CMT Administration tab -> CPQ Configuration Setup.

• No = shallow delete
• Default/Yes = deep delete

Multiple Promotions for a Bundle

Criar mais de uma promoção para aplicar a um único pacote de produtos.

Exemplo:
Promoção 1 desconta o produto filho A.
Promoção 2 desconta os produtos filho B e C.

(OBS: Ative a Shallow Delete, se a Deep Delete estiver ativada, você não poderá excluir
várias promoções)

Contextual Discounts

É uma forma de reduzir o preço de um produto

⁃ Permitem a redução do preço de um catálogo de vendas (coleção de produtos), ou

de todos os produtos do Carrinho, e podem ser aplicados em compras atuais ou futuras.

⁃ É de Natureza contratual (associados a uma conta ou contrato).

⁃ Esses descontos persistem durante a vigência do contrato.

⁃ Descontos podem ser definidos no Console do produto e criados de forma ad-hoc

no Carrinho.

Contextual Discount Types

Os três tipos de desconto:

1. Order-Based
2. Account-Based
3. Contract-Based

Order-Based

⁃ Desconto único aplicado no momento da compra.

⁃ Desconto pode especificar em porcentagem (10% de desconto) ou um valor absoluto

($10 de desconto).

⁃ Desconto do tipo contratual.

(Pode ser aplicado em um catálogo e itens do carrinho)

Exemplo:

Um cliente está pensando em atualizar seu iPhone hoje, o CSR pode oferecer um desconto
pré-construído de 20% em todos os acessórios do iPhone na tentativa de fechar a venda.

-> (CSRs) - Customer service representatives - Representante de atendimento ao cliente.

Account-Based

Faz tudo que Order-Based faz, porém:

⁃ Pode ser salvo em uma conta para descontos futuros.

⁃ Permitem que você aplique uma redução no preço de produtos e/ou serviços no
futuro.

Exemplo:

ABC Company negocia um desconto de 15% em todos os serviços de internet. O desconto

negociado fica armazenado na conta da Empresa ABC. Quaisquer pedidos futuros para
a ABC Company receberão um desconto de 15% nos serviços de internet.
Contract-Based

Faz tudo que Account-Based faz, porém:

⁃ Aplica um desconto negociado especificado em um contrato a um produto ou

catálogo de vendas.

Exemplo:

Um executivo de contas negocia e estabelece um desconto de 5% em todos os acessórios

para funcionários da empresa XYZ que adquiriram produtos iPhone. O desconto de 5% é
armazenado na empresa XYZ. Quando um novo funcionário ingressa na empresa XYZ, o
desconto de 5% é aplicado ao adicionar qualquer acessório do iPhone ao carrinho.

Creating a New Discount

Existem duas maneiras de criar um desconto

1. Product Console

2. Representante de vendas/CSR

⁃ O campo Duração do desconto determina por quanto tempo o desconto estará

disponível para o cliente e se aplica apenas a descontos baseados em conta e contrato.

⁃ Por padrão, os descontos são definidos para serem aprovados automaticamente.

⁃ A desativação de descontos se aplica a descontos baseados em contas ou

contratos.

Submit Order: botão no carrinho que ativa um pedido ou desconto baseado em conta.

⁃ Quando nenhum dos descontos pré-definidos de pedido, conta ou contrato atende

aos critérios que o CSR precisa.
Discount vs Promotion

Interfaces e Implementações

Implementação e Interface

Permitem alterar a maneira como o aplicativo funciona alterando as implementações ativas de

cada interface.

O núcleo da arquitetura aberta da Salesforce Industries é a interface e o paradigma de

implementação.

(COM) - Component Object Model

Oferece:

60 interfaces
100 implementação

Para uma abordagem aberta, reutilizável, extensível e modular para COM.

Interface

⁃ Uma interface é uma chamada para a lógica de negócios.

implementação

- A implementação é essa lógica de negócios.

A interface faz a pergunta e a implementação fornece a resposta

Exemplo:

A interface de preços se comunica com o sistema para perguntar “quanto custam esses
itens?” A implementação responde com a lógica de negócios apropriada para precificar os
produtos.

⁃ Salesforce Industries usam interfaces e implementações intercambiáveis e

reutilizáveis.

⁃ Personalizar as interfaces, substituí-las ou preservar sua lógica de negócios

existente.

⁃ Escolher a implementação que melhor se adapta.

⁃ Criar sua própria implementação.

Implementações de CPQ

⁃ Industries CPQ faz chamadas de API para as interfaces apropriadas para implementar
a lógica de negócios usando classes do Apex.
⁃ Necessário ativar a implementação e a interface corretas.
⁃ Pode ter apenas uma implementação ativa por interface.

• Implementação Padrão: Não há lógica, apenas um stub que permite que o carrinho
funcione sem nenhuma regra. (“sem operação”)

⁃ Cada interface tem uma implementação “padrão”

• Implementação Personalizado: Você escreve sua própria interface usando o

código Apex.

• Implementação Salesforce Industries: Variedade de implementações out-of-the-

box (OOTB) para cada interface. (Escolher a que melhor se adapta).

out-of-the-box (OOTB): Solução onde terá de desenvolver e personalizar completamente.

• Implementação hibrida:

⁃ Usa algumas implementações do Salesforce Industries e algumas implementações

personalizadas.

Cada interface e implementação tem um ponto de disparo.

Ponto de acionamento: Chamar um sistema externo e retornar informações desse

sistema

⁃ A implementação cria a saída e a envia de volta para a interface.

Business Process Logic and Rules

Como lógica de negócios, uma regra é definida usando o paradigma de interfaces e

implementações.
Context Rule

Qualification rules

⁃ São executadas antes que o Carrinho exiba produtos e promoções que os clientes
podem selecionar.

Penalty rules

⁃ São executadas quando um cliente atualiza o status de um pedido enviado.

Advanced rules

Availability and eligibility rules

⁃ São executadas antes que o Carrinho exiba produtos e promoções que os clientes
podem selecionar.

Configuration rules

⁃ Executado para verificar a compatibilidade do produto.

Pricing rules

⁃ Verificar o preço do produto.

Todas as regras são executadas novamente para validação quando o pedido é enviado.

Context Rules

A Salesforce Industries fornece duas estruturas de regras para atingir seus objetivos de
negócios: Context Rules and Advanced Rules.

⁃ Conjunto para executar regras de negócios em seu ambiente de CPQ de Indústrias.

Context Rules

⁃ Qualificam produtos, promoções, listas de preços, entradas de listas de preços e

ajustes de preços no Carrinho.

⁃ Pode ser usada para o Salesforce Industries API Caching (Comércio digital).

⁃ NÃO pode ser aplicar regras de contexto aos itens de linha do pedido.

Advanced Rules

É a estrutura de regras original da Salesforce Industries.

⁃ Usada para criar regras para compatibilidade ou configuração de produtos.

Context Rules Framework and Rule Types

A Estrutura de context rules permite que você crie regras de contexto para aplicar regras
de qualificação e penalidade.

⁃ O Context Rules Framework usa o cache da organização para obter alto desempenho.

⁃ O cache da organização é atualizado pelo botão CLEAR MANAGED PLATFORM

CACHE na página CMT Administration.

Context Rule Types

Qualification rules

⁃ Qualificam produtos, promoções, listas de preços, entradas de listas de preços e

ajustes de preços no Carrinho.

⁃ São executadas antes que o Carrinho exiba produtos e promoções que os clientes
podem selecionar.
Penalty rules

⁃ Determina penalidades para um cliente que cancela contratos ou promoções já

solicitados.

⁃ São executadas quando um cliente atualiza o status de um pedido enviado.

Qualification rules

Utilizada para filtrar as listas de Produtos e Promoções no Carrinho para que os clientes
vejam apenas os produtos que estão qualificados.

Exemplo:

Um produto ou promoção só está disponível para compra por clientes de longo prazo.

⁃ Determinar listas de preços qualificadas e entradas de lista de preços para um

produto ou promoção no carrinho.

Exemplo:

Um cliente na CA é elegível para preços da lista de preços da Costa Oeste.

⁃ Controlar quais ajustes de preços podem ser aplicados e em quais circunstâncias.

Os product para os quais um usuário atende aos critérios de qualificação são exibidos na aba
Qualified.
As promotion para as quais um usuário atende aos critérios de qualificação são exibidas
na guia Qualified.

Penalty Rules

Aplicam-se a promoções já encomendadas pelo cliente ou a contratos cancelados

durante o período do contrato.

Promotion

⁃ Se o cliente cancelar a promoção durante o período do contrato, as regras

determinam se uma penalidade se aplica à conta do cliente.

⁃ Se uma penalidade for aplicada, a regra define a cobrança da penalidade (uma taxa
específica).

Exemplo:

Um serviço tem uma assinatura de 12 meses. Se os clientes cancelarem o serviço antes

do final de 12 meses, uma multa será aplicada à sua conta.

As regras de penalidade se aplicam apenas a ordens MACD ou com Assets.

Interface Implementations for Context Rules

Quais interfaces e implementações são usadas na estrutura de context rule;

ContextRuleService

• Essa implementação deve ser a implementação ativa e padrão para que as regras de
contexto sejam habilitadas.

⁃ Tem apenas uma implementação (ContextRuleService).

OBS: Não há interface semelhante para regras de contexto para promoções. Ele é incluído
apenas como parte do ContextRuleService.

Qualification Rules for Products

ProductAvailabilityOpenInterface

• Chamada quando o aplicativo deve fornecer uma lista de produtos que estão
disponíveis para o cliente selecionar.

⁃ Tem duas implementações:

1. DefaultAvailabilityOpenImplementation

⁃ Retorna a lista de produtos sem regras de contexto em execução.

⁃ Usada quando você não tivesse nenhuma regra de contexto para aplicar.

1. CtxRules ProductsOpenImplementation

⁃ Retorna apenas os produtos que atendem ao conjunto de regras de contexto.

⁃ Deve ser a implementação ativa e padrão para implementar regras de contexto para
produtos.

Qualification Rules for Price List Entries

TightestMatchInterface

⁃ Chamada quando o aplicativo deve precificar um produto no carrinho.

TightestMatchServiceImplementation
⁃ Usa pesos para determinar qual entrada da lista de preços selecionar.

(apenas se estiver ativo e padrão)

FirstMatchImplementation

⁃ Essa interface ignorará esses pesos e selecionará a primeira correspondência

encontrada.

(apenas se estiver ativo e padrão)

Context Rules Interfaces (adicional)

PricingManAdjEligibilityInterface

⁃ Contexto rule de qualificação para ajustes de preços.

RepricingManAdjEligibilityInterface

⁃ Contexto rule de qualificação para ajustes de preços usados em um trabalho em lote

de reprecificação.

Context Rules Framework

A Estrutura de Regras de Contexto permite que você crie regras de contexto para aplicar
regras de qualificação e penalidade.

Elementos da estrutura;

⁃ Trigger events: Executam uma interface do Salesforce Industries, que então chama
a implementação de interface ativa.

⁃ Rule sets: Executam uma ou mais regras de contexto

⁃ Context rule: Inclui uma dimensão de contexto, escopo de contexto e mapeamentos
de contexto.

O context rule age como filtros de entidade, decidindo quando um rule sets se aplica ao
carrinho.

Rule sets

É uma coleção de uma ou mais regras de contexto aplicadas a um produto, promoção,

lista de preços ou entradas de lista de preços.

⁃ São avaliadas como um todo ao realizar uma

verficação em relação a um produto ou
promoção.

⁃ Aplica-se Rules sets a produtos ou promoções,

em vez de regras de contexto individuais.

⁃ Rules sets são armazenados como object Vlocity

Rule.

Creating a Rule Set

Vlocity Product Console Dashboard

clique em + ao lado de Rule Set

1. Tipo de Regra: 
As opções são Qualificação, Penalidade.

1. Objetivo da regra: 
Este campo atualmente não está funcional, mas está planejado para
uso futuro.

1. Modo de Expressão: 
As opções And, Or, Custom, If Else If, If.
(Consulte "Custom
Expression Modes" abaixo)
1. Mensagem de falha: 
Esta mensagem será exibida na subguia Desqualificado do
Carrinho.

1. Regra de cabeçalho: 
use para otimizar o desempenho de várias regras no processo

de avaliação. Essa regra é avaliada primeiro e, se falhar, todo o conjunto de regras falha.

Você pode selecionar uma ou mais regras como regras filhas de um rule sets.

Expression Modes

A Rule evaluation usa um modo de expressão (por exemplo, And, Or, Custom) para
compilar condições em uma expressão lógica.

⁃ Determina a qualificação ou desqualificação de produtos ou promoções.

Um modo de expressão de conjunto de regras é baseado nas seguintes condições.

• And: Requer que todas as regras no conjunto de regras sejam aprovadas

⁃ É o padrão e é usado apenas com regras de qualificação.

• Or: Requer que pelo menos uma das regras no conjunto de regras seja aprovada.

• Custom: Requer uma expressão personalizada para avaliar o conjunto de regras.

Exemplo:

Definir as condições como ((RuleA AND RuleB) OR (RuleC AND RuleD)).

• If Else If: Testa a primeira regra no conjunto de regras e testa a regra subsequente
somente se a primeira regra não for aprovada.

• If: Testa a primeira regra no conjunto de regras.

⁃ Geralmente usa as regras If e If Else If para penalidades.

Context Rules and Conditions

Um context rules contém as informações necessárias para determinar quando um conjunto

de regras deve ser executado

• Rule condition
• Context dimension
• Context scope
• Context mapping

Creating a Context Rule

Vlocity Product Console Dashboard

clique em + ao lado de Rule

1. General Properties: 
O Rule Code pode ser qualquer valor único. Não pode conter
espaços devido aos requisitos do mecanismo de regras.

2. Rule Info: 
Expression Mode são END, OR, Custom. Se você escolher o modo de
expressão personalizada, será necessário inserir os detalhes no Fielder Expression.

3. Effectivity: 
embora não sejam aplicadas no momento, recomendamos que você

selecione o sinalizador Ativo e selecione a data atual como a data Efetiva. 
A seção
Efetividade é comum a muitos registros que você cria no Painel do console do produto.

Adding Rule Conditions

Adicionando condições para regras.

Simple: Permite selecionar uma dimensão de context.

Function: Permite selecionar uma Função.

Code: não pode haver espaços

Context dimensions: Localize e selecione um contexto de dimensão.

Operator: Use != para o operador NOT.

OBS: Se estiver criando regra que será usada nas APIs de comercio digital, é suportado
apenas o operado ==.

Deploying a Context Rule

⁃ Localizar o produto, a promoção, a lista de preços ou a entrada da lista de preços

à qual deseja aplicar a regra no Product Console e, em seguida, adicionar o RULES SETS
na faceta CONTEXT RULES.

• É importante observar que você só pode adicionar RULES SETS.

Context Dimensions

É uma variável que descreve os valores possíveis a serem usados em uma condição de
regra.

⁃ Reutilizada em várias condições de regra.

⁃ Inclui valores possíveis em uma lista de opções ou digitados.

O serviço de context rules compara a context dimensions com os dados;

Exemplo:

Um sObject, uma função ou um valor estático definido no mapeamento de contexto.

Domain Types:
⁃ Picklist
⁃ Object lookup
⁃ Type in

Data Type:

⁃ Text
⁃ Number
⁃ Date
⁃ Date/time
⁃ Boolean

Picklist Selection Mode:

⁃ Single
⁃ Multiple

Context Scopes

Descreve o caminho relacional de um sObject raiz, como um Pedido, para sObjects

relacionados, definindo os limites para a função de regra.

⁃ Representa um sObject.

• Recuperando dados do sistema usando evaluation logic of rules para determinar a

saída.

Supported Context Scopes (compatíveis)

O Salesforce Industries oferece suporte aos context scope raiz:

• Order
• Opportunity
• Quote
• Asset
• Any (qualquer)
• Account
• Contact

Observação: Context Scopes do Assets só pode ser usado para regras invocadas durante
a redefinição de preços.

The Any Context Scope

É um escopo de contexto curinga que representa todos os escopos de contexto raiz.

• Maneira flexível e eficiente de definir escopos.

• Permite que você crie escopos de conta e contrato independentes.

Exemplo:

Em vez de criar escopos Order.Account e Quote.Account separados, você pode criar um

único escopo Any.Account que localiza a conta associada para todas as entidades raiz,
incluindo pedidos e cotações.

• Se o context scope for Any.Account, o mecanismo de regras associado recuperará

os campos de todas as entidades raiz: Order, Opportunity, Quote e Assets.

Crie context scope antes de definir context rules.

⁃ É uma configuração única que é necessária como parte da configuração inicial.

Virtual Context Scopes

Permitem que você crie mapeamentos de contexto para objetos virtuais.

⁃ Avalia dados inseridos pelo usuário em tempo de execução que são armazenados
apenas na memória, como dados de ajuste de preço.

⁃ Não definimos caminhos de entidade para escopos raiz.

Context Mappings

Permite mapear context scope, como sObjects, com context dimension, como fields ou
fórmulas calculadas.

⁃ Inclui um context scope para extrair dados do SF, função ou infor. digitada

⁃ Cria-se um caminho para os dados do mecanismo de serviço context rules, que forma
um link mágico entre os dados e o mecanismo de regras.

⁃ Os mapeamentos de contexto são mantidos no cache da organização.

⁃ Você pode configurar mapeamentos de contexto do context scope ou do context

dimension.

⁃ Rastreia a hierarquia de objetos usando expressões de origem para acessar dados

em objetos relacionados.

Using Context Rules with Price Lists

Podemos utilizar context rule de qualificação para controlar a exibição de listas de preços
e atribuir context rules a listas de preços filhas.

Context rule - Price list parent (pai)

⁃ Controla quais price list o usuário verá no menu suspenso.

⁃ Prince list qualificadas serão exibidas como listas de preços disponíveis

Context rule - Price list child (filho)

⁃ Determinar qual preço aplicar aos produtos no carrinho com base nos critérios de
condição da regra.

⁃ A entrada da price list para a lista de preços filho será aplicada automaticamente
ao item de linha.

Context Rules for Price List Entries

Usar context rule para determinar qual entrada da lista de preços aplicar quando o produto
for adicionado ao carrinho.

Exemplo:

1. Os consumidores veem apenas a Lista de Preços B2C.

2. Novos clientes recebem determinados preços.
3. Pedidos feitos pela web recebem determinados preços.

Tightest Match - Partida mais apertada

TightestMatchInterface é uma interface fornecida como parte do pacote gerenciado

⁃ É chamado pelo PricingInterface ao usar as implementações

PricingElementServiceImplementation ou PricingPlanService.

⁃ Não é chamado ao usar PricingRulesImplementation.

TightestMatchInterface inclui duas implementações de interface:

• FirstMatchImplementation: ignora quaisquer pesos de condição e seleciona a
primeira entrada da lista de preços que encontra.

• TightestMatchServiceImplementation: usa pesos de condição para determinar o

preço de “tightest match”.

Experiência do usuário

⁃ Quando há apenas uma correspondência mais justa “vencedora”, a experiência do

usuário é a mesma de uma entrada de PRICE LIST padrão.

⁃ Quando houver várias correspondências mais justas “vencedoras”, a entrada da

PRICE LIST mais recente é selecionada e as entradas da lista de preços não selecionadas
são exibidas na janela DETAILS do preço.

Advanced Rules

The Advanced Rules Framework inclui os seguintes elementos:

• Um evento acionador, como uma alteração de evento

no carrinho ou a seleção de uma lista de preços.

• Uma interface e implementação.

• Uma regra avançada baseada em um filtro de entidade

e uma ação condicional

Advanced Rule Types

Types of advanced rules:

Availability

⁃ Filtre a lista de Produtos para mostrar apenas os produtos disponíveis.

Eligibility

⁃ Filtre a lista de Produtos para mostrar apenas os itens para os quais o cliente é
elegível.

Compatibility (AKA Configuration/Validation):

⁃ Defina os produtos relacionados a serem adicionados quando um produto for

adicionado ao carrinho.

⁃ Pode adicionar, remover ou recomendar produtos automaticamente com base em

outros produtos no carrinho.

Pricing

⁃ Altere o preço padrão e opere em itens de linha de pedido no carrinho.

⁃ PricingRulesImplementation: permite criar regras avançadas para implementar

regras de precificação que chamam procedimentos de cálculo como ações.

Availability Rules

Filtram a lista Produtos para mostrar apenas os itens disponíveis para o cliente.

Exemplo:

• O iPhone dourado não está disponível em Nova York.

• O Office Internet Solution não está disponível no Alasca ou no Havaí.
• O Office Internet Solution está disponível apenas na Califórnia.
⁃ As regras de disponibilidade usam o ProductAvailabilityInterface e implementações
associadas.

ProductAvailabilityInterface

Chamada quando uma solicitação é feita para fornecer uma lista de produtos que estão
disponíveis para o cliente selecionar.

Eligibility Rules

Filtram a lista Produtos para mostrar apenas os itens para os quais o cliente está qualificado.

Exemplo:

• A oferta de instalação gratuita está disponível para clientes com contas com mais de
12 meses.

• As contas de cobrança não estão qualificadas para comprar a solução Office Internet.

• As contas Bronze e Silver não são elegíveis para adquirir a solução Office Internet.

As regras de elegibilidade usam ProductEligibilityInterface e implementações associadas.

ProductEligibilityInterface

⁃ Chamada imediatamente após a interface e implementação ProductAvailability.

Compatibility Rules (também conhecidas como regras de

configuração/validação)

Define a relação entre os produtos para garantir que uma combinação válida de produtos
seja adicionada ao carrinho.

• Usando product relationships, você pode definir que quando um produto é adicionado
ao Carrinho, produtos relacionados são adicionados a ele.
• Certifica se os produtos e pedidos no carrinho sejam compatíveis com base nas
condições dos itens de linha do pedido e objetos relacionados.

• Executa em objetos Item de linha de pedido — Item de linha de oportunidade, Item de

linha de cotação ou Item de linha de pedido. As ações de regra envolvem relacionamentos de
produtos.

Uma compatibility (configuration) advanced rule é necessária quando a regra depende de:

⁃ Context

⁃ Multiple Criteria

⁃ Product Attributes

• Regras de configuração/validação avançadas são executadas em objetos de item de

linha de pedido.

Pricing Rules

Alteram o preço padrão e operam em itens de linha de pedido no carrinho.

-> As regras avançadas de precificação utilizam o PricingRulesImplementation como

catálogos de preços, em vez de listas de preços. (Regra usada em implantação antiga)

-> As implantações mais recentes usam preços baseados em atributos usando planos de
preços e regras de contexto para entradas de listas de preços

As regras avançadas se aplicam no processo de captura de pedidos em;

⁃ Lista de produtos do carrinho com regras de elegibilidade e disponibilidade.

⁃ Carrinho com regras de compatibilidade aplicadas.

⁃ Envio de pedidos e a criação de ativos reaplicam as regras para garantir que o pedido
seja perfeito.

Interface Implementations for Advanced Rules

Product Validation / Compatibility Rules

ProductValidationInterface

⁃ Implementa regras de compatibilidade, também conhecidas como regras de

configuração ou regras de validação.

⁃ Valida a compatibilidade dos produtos em uma oportunidade, pedido ou cotação.

⁃ É acionada quando um produto é adicionado, modificado ou excluído de uma

oportunidade, pedido ou cotação.

⁃ Implementações:

• ProductRelationshipValidationImpl(obsoleto)

⁃ Implementação legada que não é mais compatível.

• Implementação de Regras de Validação

⁃ Executa todos os relacionamentos de produtos e regras de compatibilidade ativas.

(oportunidade, pedido ou cotação)

• DefaultProductValidationImplementação

⁃ Retorna qualquer entrada que receber como saída, sem nenhuma alteração. (não
implementa suas regras de validação/compatibilidade.)
Compatibility Rules

⁃ Especificam os relacionamentos entre os produtos.

⁃ Usam relacionamentos de produtos como sua ação de regra.

Exemplo:

Um produto pode exigir, recomendar ou excluir outro produto.

Pricing Rules & PricingInterface

Regras de precificação usam PricingInterface e implementações associadas para calcular

a precificação correta.

⁃ Permite que você crie regras avançadas que chamam procedimentos de cálculo
como ações.

⁃ PricingInterface e a implementação são acionadas quando um produto é

adicionado, excluído ou modificado em uma oportunidade, pedido ou cotação.

As implementações de regras de preços incluem:

• DefaultPricingImplementation

⁃ Pricing rules padrão que não dependem de nenhum fator externo.

• PricingRulesImplementation

⁃ Permite criar regras avançadas para implementar regras de precificação que chamam
procedimentos de cálculo como ações.

• PricingElementServiceImplementation

⁃ Recuperar as cobranças e os ajustes dos produtos das listas de preços.

⁃ Calcula os ajustes de preços com base em promoções também definidas no Vlocity
Product Console.

• PricingPlanService

⁃ Usado quando existe preços em uma implementação que cruza vários domínios de
aplicativo.

Product Relationships

São usados para determinar se uma combinação de produtos é válida.

⁃ Product relationship é acionado usando regras avançadas de

configuração/validação.

⁃ Definir quando um produto é adicionado ao Carrinho, produtos relacionados são

adicionados a ele.

⁃ Adicionar, remover ou recomendar automaticamente produtos com base em outros

produtos do carrinho.

Rule Builder

Vlocity Rule Builder é uma ferramenta de design de arrastar e soltar disponível na guia Vlocity
Rules.

⁃ Permitem que você crie regras de disponibilidade, elegibilidade, configuração e

preços.

⁃ Aplicar uma ou mais ações de regra a cada item qualificado pelo filtro de entidade.
Entity Filters

São utilizadas quando desejamos criar regras que sejam acionadas apenas quando
surgirem certas condições.

Existem dois tipos de Filtros de Entidade: Avaliação e Qualificação.

• Avaliação— Determina se um conjunto de registros de objetos corresponde a

condições específicas. Retorna verdadeiro ou falso.

⁃ São filtros internos.

Os filtros de entidade de avaliação aceitam uma lista de itens como entrada e retornam
verdadeiro ou falso como saída.

Exemplo:

Um filtro de avaliação é avaliado como verdadeiro se algum dos produtos filhos tiver uma
quantidade máxima menor que 10 e uma quantidade mínima maior que 2.

• Qualificação— Determina se um conjunto de registros se qualifica para ação. Retorna

itens de linha qualificados.

Os Filtros de Entidade de Qualificação, a entrada é uma lista de itens e a saída é uma lista
de itens qualificados.

Exemplo:

Você pode retornar apenas as contas em que o estado de envio é o Alasca ou o Havaí.

-> Quando você encadeia um filtro de qualificação com um filtro de avaliação, ele é
chamado de filtro composto.
Com os filtros de entidade, podemos;

⁃ Criam contexto para regras avançadas filtrando itens de linha de pedido e

pesquisando por condições definidas.

⁃ Consistem em uma ou mais condições que avaliam campos ou atributos em um

objeto e, se verdadeiras, aplicam uma ação de regra.

⁃ Ação de regra pode ser; relação de produto, matriz, cálculo ou procedimento.

⁃ As regras podem conter um ou mais filtros.

⁃ Os filtros são reutilizáveis e aditivos.

⁃ O filtro fica disponível para uso em qualquer regra.

Um único filtro de entidade pode ter uma ou mais condições.

Tipos disponíveis de condição de filtro são:

• Atributo: selecione produtos com base em atributos.

• Campo: selecione produtos com base em campos em um objeto.

• Filtro: o sistema procura outro filtro e faz outra coisa com ele. Para esse tipo, você
fornece um caminho delimitado por vírgulas para a lista de objetos a serem passados para o
filtro interno.

• Função: Em vez de criar um filtro, você pode usar uma função que oferece conjuntos
de dados predefinidos para passar ao filtro de avaliação, para que você não precise
especificá-los.

Creating Product Configuration Procedures

Procedimento de configuração de produto para determinar os parâmetros de ação JSON.

Ao salvar o procedimento de configuração do produto, você pode visualizar o código Action
Parameters em sua guia Details.

Código de parâmetros de ação

Creating an Auto-Add Product Relationship

Exemplo:

Contas de alta prioridade sediadas na Califórnia compram o iPhone X, elas recebem

automaticamente uma capa de telefone gratuita.

Em Product Relationship, vamos criar a o relacionamento de produto;

1. Product - Adicionamos o produto que possui o atributo (iPhone X).

2. Relationship type - o tipo de relacionamento que este produto tera (automático).

3. Related Product - o produto no qual vamos relacionar (Capa iPhone X).

4. AddMode - de que modo esse produto é adicionado? Filho, irmão ou raiz. (Irmão).

5. Default quantity - Quantidade padrão (1 capa).

Creating an Entity Filter for High Priority Accounts

Exemplo:

Se quisermos que nossa capa de telefone gratuita seja adicionada apenas aos clientes que
identificamos como de alta prioridade, que moram na CA e têm um contrato de serviço de
nível platinum.

Precisamos criar um Filtro de Entidade para a regra, para especificar onde ela se aplica.

1. Guia Filtro de entidade e clique no botão New

2. Coloque o tipo de entidade Qualificação
3. Crie 3 Condições de Filtro de Entidade
Exemplo de condição:

• Filtre contas de alta prioridade.

• Filtre por contas na Califórnia. (CA)
• Filtre por contas que tenham um acordo de nível de serviço (SLA) Platinum.

Combining the Product Relationship and Entity Filter

Combinar o filtro de entidade é escolhe quais clientes recebem a capa de telefone grátis.

Relacionamento do produto é oque determina os produtos e a ação a ser tomada (regra)

1. Guia Vlocity Rules e clique no botão New (para criar uma nova regra)

2. Insira o nome, a descrição e a definição da regra no cabeçalho da regra. (Capa de

iPhone X gratis, para contas de alta prioridade CA)

3. Clique em Filtros para exibir a lista de filtros disponíveis. Selecione Order Account is
High Priority + in CA.

4. Clique em Ações para exibir a lista, em seguida Adicionar à ação da regra para aplicar
a ação a esta regra. Neste caso vamos adicionar o produto relacionado criado
anteriormente. (Apple iPhone X Auto-Adds a Free iPhone Case)
Reviewing the Rule in the Cart

Quando você adiciona o produto Apple iPhone X ao Carrinho, o produto Incipio Canvas
Tecido Wrap Case - iPhone X é adicionado automaticamente.

Rules

Por que você precisa desta regra?

Qual objeto está regra se aplicará?

Em que estágio está regra se aplicará?

Como será administrada ou gerenciada esta regra?

Guided Selling

É uma experiência de compra consistente que inclui etapas para orientar o usuário pelo
processo de recomendação, seleção e pedido de produtos.
Industries CPQ + OmniScript = Guided Selling

Com o OmniStudio, você pode criar experiências de vendas guiadas usando industries
CPQ e OmniScript.

Industries CPQ

⁃ Mecanismo de regras e preços criado na plataforma Salesforce que garante que as

cotações e pedidos sejam válidos antes do envio

⁃ O CPQ do setor começa onde o CRM termina, fornecendo produtos, preços e regras
de negócios.

OmniScript

⁃ Ferramenta de script declarativa.

⁃ Cria todos os tipos de interações guiadas, incluindo vendas guiadas.

Venda guiada e OmniScript

OmniScripts pode ser configurado para incluir:

• Uma série de etapas a serem tomadas durante a interação.

• Uma lista de produtos do seu catálogo compartilhado.

• Configurar itens antes de adicioná-los ao carrinho.

• Resumo do pedido e uma barra total em execução na parte inferior da página do

carrinho.

Existem duas abordagens para construir uma experiência de venda

guiada.
Experiências de venda guiada baseadas em carrinho.

• Usam APIs baseadas em carrinho e modelos angular JS para apresentar um

carrinho visualmente persistente à medida que o usuário navega pelo processo de
pedido.

• Dá suporte a processos de negócios internos e microsserviços para

usuários conhecidos.

• Desenvolver um fluxo de venda com OmniScript, DataRaptors e APIs baseadas em

carrinho.

Experiências de vendas guiadas de comércio digital (Industries Digital

Commerce Gateway)

O comércio digital atende às necessidades dos provedores de serviços de comunicação

e dos assinantes e é construído em uma plataforma omnicanal integrada que permite
cenários de design, captura de pedidos, gerenciamento de pedidos e gerenciamento de
clientes em todos os canais e dispositivos.

• Projetado desde o início para suportar os maiores volumes de navegação e

transações de comércio digital.

• Usam APIs que podem ser armazenadas em cache e componentes da Web do

Lightning para criar um processo de pedido passo a passo.
• Cria sites onde usuários anônimos podem navegar, configurar e adicionar produtos
ou pacotes ao carrinho.

• Os usuários não precisam registrar uma conta. (Ideal para comércio externo)

• Possibilita personalizar sua solução de comércio digital para servidores dentro ou

fora da plataforma. (Ex: AWS)

Digital Commerce

Industries Digital Commerce Components

1. Lightning web components

⁃ Os componentes Web do Digital Commerce Lightning são usados para criar

experiências de comércio digital e estão disponíveis no pacote gerenciado.

2. Web components

⁃ Os componentes da Web são normalmente usados no comércio digital fora da

plataforma, enquanto os componentes da Web do Lightning são usados na plataforma.

⁃ Pode ser usado para criar tags HTML personalizadas, reutilizáveis e encapsuladas
para usar em suas páginas da Web ou aplicativos.

3. Digital Commerce SDK

⁃ Biblioteca JavaScript pura que abstrai e simplifica o uso de APIs de comércio

digital.

⁃ SDK melhora a usabilidade e reduz o esforço para desenvolver interfaces de usuário

atraentes, ocultando semânticas de API.
4. Digital API Caching

⁃ Pré-gera chamadas de API de alto volume antecipadas.

⁃ Respostas da API são armazenadas em cache na plataforma ou fora da plataforma.

5. Digital Commerce cacheable APIs

⁃ Estendem o Catálogo Compartilhado aos canais digitais, permitindo a navegação,

seleção e configuração de produtos para usuários anônimos e logados.

Using Sales Catalogs in Digital Commerce

Os catálogos de vendas são usados para organizar grupos de produtos e promoções

selecionados do Catálogo Compartilhado em ofertas de comércio digital.

• Ideais para sites de comércio digital porque podem ser selecionados para
estratégias de marketing de produtos específicos.

Os catálogos de vendas são compostos por Relacionamentos de Produtos do

Catálogo que definem os produtos e promoções incluídos no catálogo.

Digital Commerce API Cache

Esse cache armazena respostas de API pré-preenchidas dentro do Salesforce para

soluções na plataforma.

Tarefas para manter o cache atualizado para o comércio digital;

1. Load API MetaData

Vlocity CMT Administration tab.

⁃ Executado ao configurar o comércio digital pela primeira vez.

⁃ Cria os registros de metadados de API necessários para o Digital Commerce no
sObject de metadados de API.

2. Populate API Cache job

Vlocity CMT Administration tab.

⁃ Preenche o cache com produtos, pacotes de produtos e promoções definidos nos

catálogos de vendas.

⁃ Preenche regras de contexto, preços, detalhes de ofertas e outros dados.

⁃ São rmazenados para garantir tempos de resposta rápidos.

3. Regenerating the cache

Vlocity CMT Administration tab.

⁃ Sempre que você fizer alterações em seus produtos, promoções, regras ou

preços em seus catálogos, precisará atualizar o cache da API de comércio digital.
⁃ Você deve excluir os registros existentes no cache.

(Depois de excluir você pode preencher novamente o cache executando o POPULATE API
CACHE)

Você pode fazer isso no Developer Console ou no Workbench usando o comando abaixo.

delete [SELECT Id FROM vlocity_cmt__CachedAPIResponse__c];

Digital Commerce Lightning Web Components

Referem-se aos componentes da Web do Lightning que foram criados especificamente

para criar experiências de comércio digital.
Exemplo:

dcCatalog para renderizar uma determinada lista de catálogos.

• Os componentes web da Digital Commerce Lighting utilizam o SDK do Digital

Commerce para executar uma variedade de funções.

Exemplo:

Você pode colocar funções JavaScript personalizadas em um componente Web

estendido do Digital Commerce Lightning e ele usará o SDK para fazer coisas como excluir
produtos do carrinho.

User Experience Model

Existem quatro fases distintas de uma experiência de comércio digital.

Browse , Configure , Cart e Checkout .

1. Os usuários navegam pelas ofertas disponíveis no catálogo.

⁃ Essa fase fornece a página inicial e os componentes da Web do catálogo do

Lightning para recuperar e exibir ofertas de catálogo e detalhes de ofertas

2. Os usuários podem selecionar uma oferta e configurá-la, o que pode alterar o preço
e a disponibilidade.
⁃ Os componentes da Web do Digital Commerce oferecem suporte a essa fase
oferecendo maneiras de renderizar preços de oferta, cores, outros atributos e mídia.

3. Os usuários podem adicionar a oferta configurada ao carrinho (um contêiner de

itens de linha salvos)

⁃ Os componentes web do Digital Commerce aqui permitem ao usuário essas funções,

bem como renderizar o próprio carrinho (cesta virtual).

⁃ O carrinho mostrará o preço total e permitirá que o usuário prossiga para o checkout.

4. Quando o usuário estiver pronto para revisar seu pedido, inserir ou recuperar
informações de envio, cobrança e pagamento e, finalmente, enviar seu carrinho para que
ele se torne um pedido.

⁃ Suportam a integração OmniScript para facilitar a implementação de fluxos de

checkout e bibliotecas de processos.

A fase Checkout consiste nas seguintes subfases:

1. Login: identificar o usuário. (aplicável se o usuário ainda não estiver logado)

2. Informações do usuário: revise o carrinho, insira as informações de envio e utilize o

gateway de pagamento.

3. Envio de pedido: crie um pedido do Salesforce.

LWC OmniScripts

Permitem que você aprimore um elemento OmniScript existente ou adicione

funcionalidade personalizada ao OmniScript por meio do uso de componentes Web do
Lightning personalizados.
É possível alternar um OmniScript para um LWC OmniScript ou um Angular OmniScript a
qualquer momento.

⁃ Angular OmniScript e LWC OmniScript não suportam os mesmos componentes e

funcionalidades.

App Lightning Web Components

Componentes da Web do Lightning que alimentam as fases de Browser, Configure, and

Cart.

Browse:

⁃ dcCatalog e dcChildCatalog: Renderizam a interface do usuário a partir de seus

respectivos modelos.

⁃ dcOffersList: Único componente nesta fase a invocar o Digital Commerce SDK e as

APIs para recuperar produtos do catálogo de vendas em cache do Cache da API Digital.

⁃ Usa um código de catálogo filho para chamar as APIs e obter uma resposta com os
produtos apropriados.

(As APIs então enviam a resposta de volta ao SDK, e o SDK analisa a resposta e a fornece
de volta ao componente)

Configure:

⁃ dcOfferConfig: Chama a pilha de tecnologia de comércio digital para recuperar

detalhes e atributos do produto para que o usuário possa configurar o produto.

Cart:

⁃ dcShoppingCart: Renderiza os produtos que foram adicionados ao carrinho,

permitindo o usuário a fazer modificações.
The Set Values OmniScript Component

Permite adicionar pares chave/valor ao JSON do OmniScript, a partir do qual lemos e

escrevemos valores para os componentes OmniScript.

⁃ Set Values depende do uso de campos de mesclagem para acessar o JSON de

dados do OmniScript.

Use a ação Set Values para:

• Acesse e renomeie dados JSON usando campos de mesclagem.

• Preencher Elementos com valores.

• Concatenar valores.

• Definir valores enviados para o JSON de dados de uma resposta ou parâmetro.

• Definir dados com fórmulas e funções.

• Crie valores determinados por funções OmniScript e operadores de fórmulas

compatíveis.

API Parameters

As chamadas de API que podem ser armazenadas em cache e modificadas com

muitos parâmetros diferentes.

Parâmetros possíveis que podem ser usados com a API em cache Get Offers.

Sem parâmetro

⁃ API simplesmente retorna uma lista de ofertas para o catálogo de vendas “Phone”.

⁃ API não tem parâmetros aplicados a ela.

Exemplo:

Especifique um contexto

⁃ API está especificando a dimensão de contexto de “Status” e o valor de “Active”.

⁃ Ela recuperará todas as ofertas com status ativo.

Exemplo:

Especifique um tamanho de página

⁃ API retorna uma lista de ofertas com tamanho de página 20

⁃ Até 20 ofertas serão carregadas no carregamento de página inicial do usuário.

⁃ Se existirem mais de 20 ofertas no catálogo “Phone”, o usuário precisará clicar em

um botão para carregar o restante.

Exemplo:

Especifique um usuário logado específico

⁃ API recupera uma lista de ofertas específicas para um determinado usuário.

Exemplo:

Checkout with Digital Commerce and OmniScript

O Checkout é composto por vários procedimentos de integração e componentes web do

Lightning.

⁃ É onde o usuário precisará criar uma conta ou fazer login.

⁃ A criação e a busca de detalhes da conta são tratadas por meio de procedimentos

de integração e componentes da Web do Lightning.

dcUpdateBillingAddress

⁃ Permite que o usuário insira seus endereços de cobrança e envio.

• Os campos são atualizados na página de registro do cliente por meio de

Procedimentos de Integração e DataRaptors.

dcCheckoutPayment

⁃ Permite que o usuário insira detalhes de pagamento e os envie com um gateway de

pagamento fora da plataforma.

⁃ Utiliza o URL de pagamento especificado no componente Set Values do OmniScript

pai para renderizá-lo em um iFrame.
dcReviewOrder

⁃ Permite que o usuário revise suas informações de contato, endereço de

cobrança/envio e informações de pagamento antes de enviar seu pedido.

The Integration Procedures of the Checkout OmniScript

Quatro procedimentos de integração usados pelo Checkout OmniScript.

⁃ O método de checkout requer o cartId (ID do pedido).

1. FetchAccountDetails

Autenticação do usuário

⁃ Criar uma nova conta ou buscar detalhes de um usuário conhecido.

⁃ Por meio do uso de DataRaptors.

CreateAccount: É uma ação de postagem do DataRaptor e é usada para criar contas.

⁃ Podemos invocá-lo como um componente DataRaptor Post Action no OmniScript.

2. updateAddressVIP

⁃ Inserir detalhes de cobrança e temos que garantir que eles estejam atualizados em
sua conta.
3. saveCartVIP

⁃ Ação remota do Apex para criar um pedido para os produtos no carrinho do usuário.

⁃ Usuário clicar no botão salvar carrinho na página do carrinho

4. SubmitOrderVIP

⁃ Mesmo procedimento de integração saveCartVIP, criar um pedido, valida o pedido

com a classe SubmitOrderService e o envia com a classe CPQAppHandler.

Navigate action

Levar o usuário a um aplicativo especificado, componente do Lightning, página de objeto,

página de registro e muito mais .

⁃ A ação navegar usará o valor %cartId% recuperado pela Ação

Extrair DRExtractCartId DataRaptor para levar o usuário à página do pedido.

Guided selling OmniScripts

Podem usar todos os componentes de dados padrão para mover dados para dentro e
para fora do script:

• DataRaptor
• REST actions
• Remote actions
A venda guiada de OmniScripts precisa de uma grande ajuda de lógica de negócios com
uma ordem paralela de dados. A lógica de negócios contém o molho secreto para uma
experiência de venda guiada eficaz.

Business Logic

A lógica e regras de negócios governem quais produtos estão disponíveis para quais
clientes e a que preços.

⁃ CPQ do setor define a lógica e as regras de negócios.

⁃ Acessar dados de produtos e preços usando o CPQ, você deve solicitar os dados
usando uma interface do CPQ.

⁃ Carrinho e os OmniScripts de venda guiada usam CpqAppHandler .

CpqAppHandler

É uma classe global do Apex que inclui vários métodos para executar a funcionalidade
do CPQ.

⁃ Esses métodos estão disponíveis como uma API RESTful, chamada de APIs
baseadas em carrinho.

(As APIs RESTful baseadas em carrinho são usadas para invocar a interface CPQ de fora
do Salesforce )

⁃ Método CpqAppHandler para criar um pedido - creatCart