Partilhar via


Gestão dos preços de venda a retalho

O Grupo de Interesse de Varejo do Dynamics 365 Commerce mudou do Yammer para o Viva Engage. Se você não tiver acesso à nova comunidade Viva Engage, preencha este formulário (https://aka.ms/JoinD365commerceVivaEngageCommunity) para ser adicionado e mantenha-se envolvido nas últimas discussões.

Este artigo fornece informações sobre o processo de criação e gestão de preços de venda no Dynamics 365 Commerce. Centra-se nos conceitos envolvidos neste processo e nos efeitos das várias opções de configuração para os preços de venda.

Terminologia

Os seguintes termos são utilizados neste artigo.

Prazo Definição, utilização e notas
Preço O montante unitário único pelo qual um produto é vendido num cliente de ponto de venda (POS) ou numa ordem de venda. Neste artigo, o termo preço refere-se sempre ao preço de venda, não ao preço de inventário ou preço de custo.
Preço base O preço definido no campo Preço num produto lançado.
Preço do acordo comercial O preço que é definido num produto ou variante ao usar um acordo comercial do tipo Preço (vendas).
Melhor preço Quando mais de um preço ou desconto pode ser aplicado a um produto, o menor montante de preço e/ou o maior montante de desconto que produz o menor valor líquido possível que o cliente deve pagar. Neste artigo, o conceito de melhor preço é sempre referido como "o melhor preço". Este melhor preço difere e não deve ser confundido com o valor de enumeração Melhor preço para o modo de simultaneidade de um desconto.

Grupos de preços

Os grupos de preços estão no centro da gestão de preços e descontos no Commerce. Os grupos de preços são utilizados para atribuir preços e descontos a entidades do Commerce (ou seja, canais, catálogos, afiliações e programas de fidelização). Como os grupos de preços são utilizados para todos os preços e descontos, é muito importante planear a sua utilização antes de começar.

Por si só, um grupo de preços é apenas um nome, uma descrição e, opcionalmente, uma prioridade de preços. O ponto principal a ter em conta sobre os grupos de preços é que são utilizados para gerir as relações de muitos para muitos que os descontos e os preços têm com as entidades do Commerce.

A ilustração seguinte mostra como os grupos de preços são utilizados. Nesta ilustração, repare que o "Grupo de preços" está literalmente no centro da gestão de preços e descontos. As entidades do Commerce que podem ser utilizadas para gerir preços e descontos diferenciais estão à esquerda, e os registos de preços e descontos reais estão à direita.

Grupos de preços.

Quando se criam grupos de preços, não se deve utilizar um único grupo de preços para vários tipos de entidades do Commerce. Caso contrário, pode ser difícil determinar a razão pela qual um preço ou desconto específico está a ser aplicado a uma transação.

Como mostra a linha tracejada vermelha na ilustração, o Commerce apoia a funcionalidade principal do Microsoft Dynamics 365 de um grupo de preços que é definido diretamente num cliente. No entanto, neste caso, apenas se obtêm acordos comerciais de preços de venda. Para quiser aplicar preços específicos do cliente, é recomendável não definir grupos de preços diretamente no cliente. Em vez disso, deve utilizar as afiliações.

Se o grupo de preços estiver definido no cliente, este grupo de preços é associado ao cabeçalho da ordem de venda das encomendas criadas para este cliente. Se o utilizador alterar o grupo de preços no cabeçalho da encomenda, o grupo de preços antigo é substituído pelo novo grupo de preços apenas para a encomenda atual. Por exemplo, o grupo de preços antigo não afeta a encomenda atual, mas continua associado ao cliente para futuras encomendas.

As secções seguintes fornecem mais informações sobre as entidades do Commerce que podem ser utilizadas para definir preços distintos quando os grupos de preços são utilizados. A configuração de preços e descontos para todas estas entidades é um processo em dois passos. Estes passos podem ser feitos em qualquer encomenda. No entanto, a ordem lógica é definir primeiro os grupos de preços nas entidades, porque este passo é provavelmente uma configuração única que é feita durante a implementação. Depois, à medida que os preços e descontos são criados, é possível definir os grupos de preços nesses preços e descontos individualmente.

Canais

No sector comercial, é habitual ter preços diferentes em canais diferentes. Os dois principais fatores que afetam os preços específicos do canal são os custos e as condições do mercado local.

  • Custos – Quanto mais distante um canal estiver da origem do produto, mais custa o stock de um produto. Por exemplo, os produtos frescos têm uma duração em armazenamento limitada e requisitos de produção específicos (por exemplo, uma época de crescimento). Durante o inverno, é provável que a alface fresca custe mais nos climas do norte do que nos climas do sul. Se estiver a definir preços para canais numa grande área geográfica, é provável que queira definir preços diferentes em canais diferentes.
  • Condições do mercado local – Uma loja que tem um concorrente direto do outro lado da rua é muito mais sensível ao preço do que uma loja que não tem um concorrente direto nas proximidades.

Afiliações

A definição geral de uma afiliação é uma ligação ou associação a um grupo. No Commerce, as afiliações são grupos de clientes. As afiliações são uma ferramenta muito mais flexível para a definição de preços e descontos para os clientes do que o conceito principal do Microsoft Dynamics 365 de grupos de clientes e grupos de desconto. Em primeiro lugar, uma afiliação pode ser utilizada tanto para preços como para descontos, enquanto os preços não retalhistas têm um grupo diferente para cada tipo de desconto e preço. Em seguida, um cliente pode pertencer a várias afiliações, mas só pode pertencer a um grupo de preços não retalhista de cada tipo. Por último, embora as afiliações possam ser configuradas de forma a estarem ligadas a um cliente, não têm de estar. Pode ser utilizada uma afiliação ad-hoc para clientes anónimos no POS. Um exemplo típico de desconto por afiliação anónima é um desconto para idosos ou estudantes, em que um cliente pode receber um desconto apenas por mostrar um cartão de membro do grupo.

Embora as afiliações estejam mais frequentemente associadas a descontos, também podem ser utilizadas para definir preços diferenciados. Por exemplo, quando um retalhista vende a um colaborador, pode querer alterar o preço de venda em vez de aplicar um desconto sobre o preço normal. Como outro exemplo, um retalhista que vende tanto a clientes particulares como a clientes empresariais pode oferecer aos clientes empresariais melhores preços, com base no seu volume de compras. As afiliações permitem estes dois cenários.

Programas de fidelização

Em relação aos preços e descontos, os programas de fidelização são uma afiliação que tem um nome especial. Tanto os preços como os descontos podem ser definidos para um programa de fidelização, tal como podem ser definidos para uma afiliação. No entanto, a forma como os clientes obtêm os preços de fidelização durante uma transação ou encomenda é diferente da forma como obtêm os preços de afiliação. Os clientes só podem obter preços de fidelização se for adicionado um cartão de fidelização a uma transação. Quando um cartão de fidelização é adicionado a uma transação, o programa de fidelização também é adicionado. O programa de fidelização permite então obter preços e descontos especiais.

Os programas de fidelização podem ter várias camadas e os descontos podem ser diferentes para as diferentes camadas. Desta forma, os retalhistas podem dar aos clientes frequentes prémios maiores sem terem de os colocar manualmente num grupo especial.

Os programas de fidelização têm outras funcionalidades para além dos preços e descontos. No entanto, da perspetiva dos preços e descontos, são o mesmo que afiliações.

Catálogos

Alguns retalhistas utilizam catálogos físicos ou virtuais para comercializar produtos e fixar preços para grupos específicos de clientes. Como parte do seu modelo comercial de marketing direcionado através de um catálogo, estes retalhistas podem estabelecer preços diferenciados nos seus vários catálogos. O Microsoft Dynamics 365 suporta esta capacidade ao permitir definir descontos e preços específicos do catálogo, tal como é possível definir descontos específicos do canal ou da afiliação. Ao editar um catálogo, é possível associar grupos de preços ao catálogo, da mesma forma que é possível associá-los a um canal, afiliação ou programa de fidelização.

Melhores práticas para grupos de preços

Não utilize um grupo de preços para vários tipos de entidades. Em vez disso, utilize um conjunto de grupos de preços para canais, um conjunto diferente de grupos de preços para afiliações ou programas de fidelização, e assim por diante. Pode utilizar um prefixo ou sufixo no nome do grupo de preços para agrupar visualmente os vários tipos de grupos de preços que está a utilizar.

Evite fixar grupos de preços diretamente a um cliente. Em vez disso, utilize uma afiliação. Desta forma, é possível atribuir todos os tipos de preços e descontos aos clientes, e não apenas acordos comerciais de preços de venda.

Prioridade de preços

Por si só, uma prioridade de preços é apenas um número e uma descrição. As prioridades de preços podem ser aplicadas a grupos de preços ou podem ser aplicadas diretamente a descontos. Quando as prioridades de preços são utilizadas, permitem que um retalhista se sobreponha ao princípio do melhor preço ao controlar a ordem pela qual os preços e descontos são aplicados aos produtos. Um número de prioridade de preços maior é avaliado antes de um número de prioridade de preços menor. Além disso, se um preço ou desconto for encontrado em qualquer número de prioridade, todos os preços ou descontos que tenham números de prioridade inferiores são ignorados.

O preço e um desconto podem vir de duas prioridades de preços diferentes, porque as prioridades de preços aplicam-se a preços e descontos independentemente.

Para utilizar a prioridade de preços para os preços, é necessário atribuir uma prioridade de preços a um grupo de preços e, em seguida, criar um acordo comercial de preço de venda para esse grupo de preços.

A caraterística de prioridade de preços foi introduzida para apoiar o cenário em que um retalhista pretende aplicar preços mais elevados num conjunto específico de lojas. Por exemplo, um retalhista definiu preços regionais para a costa leste dos Estados Unidos, mas quer preços mais elevados para alguns produtos nas lojas da cidade de Nova Iorque, porque custa mais vender alguns produtos na cidade e/ou porque o mercado local suporta um preço mais elevado.

Tal como foi descrito na secção "Melhor preço" deste artigo, o motor de preços seleciona normalmente o mais baixo de dois preços. Por conseguinte, o retalhista é impedido de utilizar o mais elevado dos dois preços numa loja que tenha os grupos de preços da costa leste e de Nova Iorque. Para resolver este problema antes da introdução da funcionalidade de prioridade de preços, o retalhista tinha de definir os preços de cada produto duas vezes e não atribuir ambos os grupos de preços. Em alternativa, o retalhista teve de criar grupos de preços adicionais para isolar os produtos que têm preços mais elevados dos produtos que têm os preços habituais, mais baixos.

Entretanto, a funcionalidade de prioridade de preços permite que o retalhista crie uma prioridade de preços para preços de loja que seja mais alta do que a prioridade de preços para preços regionais. Como alternativa, o retalhista pode criar uma prioridade de preços apenas para os preços de loja e deixar os preços regionais na prioridade de preços predefinida, que é 0 (zero). Ambas as configurações ajudam a garantir que os preços de loja são sempre utilizados antes dos preços regionais.

Exemplo de prioridade de preços

Vejamos um exemplo em que os preços de loja se sobrepõem a outros preços.

Um retalhista nacional/regional fixa a maioria dos preços por região e tem quatro regiões: Nordeste, Sudeste, Centro-Oeste e Oeste. Identificou vários mercados de custos elevados que podem suportar preços mais elevados. Estes mercados situam-se em Nova Iorque, Chicago e na zona da Baía de São Francisco.

Este exemplo utiliza a região Nordeste. A loja 1 situa-se em Boston e a loja 2 em Manhattan. Para a loja de Boston, dois grupos de preços estão ligados ao canal: Nordeste e Loja 1. Para a loja de Manhattan, três grupos de preços estão ligados ao canal: Nordeste, NYC e Loja 2.

O retalhista define duas prioridades de preços: Alto custo tem um número de prioridade 5, e Preços de loja tem um número de prioridade 10. (Lembre-se que, por predefinição, a prioridade de preços é 0 [zero], e um preço ou desconto que tenha um número de prioridade mais elevado é utilizado antes de um preço ou desconto que tenha um número de prioridade mais baixo). Para o grupo de preços Nordeste, a prioridade de preços é deixada no valor predefinido de 0 (zero). Para o grupo de preços NYC, a prioridade de preços é definida como 5, porque Cidade de Nova Iorque é um mercado de custos elevados. Para os grupos de preços da Loja 1 e da Loja 2, a prioridade de preços é definida como 10.

Dois produtos que o retalhista vende são o produto 1, uma T-shirt de mercadoria, e o produto 2, umas calças de ganga de marca específica.

Produto Preço do Nordeste Preço de NYC Preço de loja
T-shirt 15 $ Não definido Não definido
Calças de ganga da moda 50 $ 70 $ Não definido

A T-shirt é vendida pelo mesmo preço (ou seja, 15 $) nas lojas de Boston e de Manhattan, porque apenas um preço é definido no grupo de preços do Nordeste que está ligado a ambos os canais. As calças de ganga da moda são vendidas por 50 $ na loja de Boston, porque esse é o único preço disponível nessa loja. No entanto, na loja de Manhattan, estão disponíveis dois preços: 50 $ e 70 $. Como a prioridade de preços de 5 para o grupo de preços NYC é maior do que a prioridade de preços de 0 (zero) para o grupo de preços Nordeste, o preço é registado como 70 $ no sistema POS.

Nota

Para cada prioridade de preços, é necessário um pass through completo pela lógica do moto de preços de retalho. Portanto, para ajudar a manter o desempenho do cálculo de preços e descontos, deve utilizar as prioridades de preços com moderação.

Tipos de preços

No Microsoft Dynamics 365, pode definir o preço de um produto em três locais:

  • Diretamente no produto (preço base)
  • Num acordo comercial de preço de venda
  • Numa revisão de preços

O preço base e o preço do acordo comercial fazem parte do essencial do Dynamics 365 e estão disponíveis mesmo que não utilize o Commerce. A funcionalidade de revisão de preços está disponível apenas no Commerce. A secção seguinte fornece mais informações sobre cada uma destas opções de definição de preços e explica como as opções funcionam em conjunto.

Definir preços

Preço base

O local mais fácil para definir o preço de um produto é diretamente no produto. O valor definido diretamente num produto é muitas vezes referido como o preço base do produto. Pode definir o preço base no campo Preço no separador Vender da página Detalhes do produto lançado. O valor que introduzir está na moeda da empresa. Por defeito, o preço é para uma quantidade de 1 da unidade de medida (UM) que está definida no campo Unidade no separador Vender. O preço unitário real de um produto baseia-se na UM, na quantidade de preço e na moeda.

Se um produto tiver um preço único para todos, o preço base oferece a forma mais eficiente de gerir o preço desse produto. Mesmo que se utilizem acordos comerciais para fixar preços, também se pode fixar o preço base de um produto. Depois, se não utilizar um acordo comercial Todos, tem um preço de contingência que é utilizado quando não se aplica nenhum acordo comercial.

Se a moeda de um canal for diferente da moeda da empresa, o preço base nesse canal é determinado ao utilizar a conversão de moeda no preço que está definido no produto.

Embora a unidade de preço não seja um cenário comum, o motor de preços suporta-o. Se a unidade de preço for definida como um valor diferente de 0 (zero), o preço unitário é igual a Preço ÷ Unidade de preço. Por exemplo, se o preço de um produto for 10 $ e a unidade de preço for 50, o preço para uma quantidade de 1 é 0,2 $ (= 10 $ ÷ 50).

Acordo comercial sobre o preço de venda

Ao utilizar o diário de acordos comerciais, é possível criar acordos comerciais de preços de venda para cada produto. No Microsoft Dynamics 365, existem três âmbitos de clientes para acordos comerciais de preços de venda: Tabela, Grupo e Todos. O âmbito do cliente determina os clientes a que se aplica um determinado acordo comercial de preço de venda.

Um acordo comercial de preço de venda Tabela destina-se a um único cliente que é definido diretamente no acordo comercial. Este cenário não é um cenário típico empresa-consumidor (B2C). No entanto, se isto ocorrer, o motor de preços usa acordos comerciais Tabela quando determina o preço.

Um acordo comercial de preço de venda Grupo é o tipo mais frequentemente utilizado Fora do Commerce, os acordos comerciais de preços de venda Grupo são para um grupo de clientes simples. No entanto, no Commerce, o conceito de grupo de clientes foi alargado, passando a ser um grupo de preços mais genérico. Um grupo de preços pode ser associado a um canal, afiliação, programa de fidelização ou catálogo. Para obter informações detalhadas sobre os grupos de preços, consulte a secção "Grupos de preços" no início deste artigo.

Nota

Um preço de acordo comercial é sempre utilizado antes do preço base.

Revisão de preços

Como o nome indica, uma revisão de preços é utilizado para modificar o preço que foi fixado diretamente no produto ou fixado através de um acordo comercial. Uma revisão de preço pode ser utilizada para baixar ou aumentar o preço. Uma revisão de preços é a forma recomendada para os retalhistas criarem, acompanharem e gerirem as reduções de preços dos seus produtos ao longo do tempo.

Existem três tipos de revisões de preço: Percentagem deduzida, Montante deduzido e Preço unitário. Uma revisão de preço do tipo Percentagem deduzida ou Montante deduzido é sempre aplicada a uma transação de venda. No entanto, uma revisão de preços do tipo de preço só é aplicada se o preço revisto for inferior ao preço que foi estabelecido utilizando o preço base ou o preço do acordo comercial. Portanto, se o preço definido numa revisão de preços for maior do que o preço não revisto, a revisão de preços não será utilizada.

Determinar o preço de um produto numa transação

O cálculo do preço e do desconto numa transação utiliza o princípio de encontrar o melhor preço para o cliente. Segundo este princípio, se for encontrado mais do que um preço, é utilizado o preço mais baixo. Além disso, é utilizada a combinação de descontos que produz o maior montante de desconto para toda a transação. Em alguns casos, é necessário utilizar um desconto mais pequeno num único produto para que possam ser aplicados mais descontos a outros produtos da transação.

A única exceção ao princípio de encontrar o melhor preço para o cliente é a opção de misturar e combinar descontos mais baratos. Esta opção permite descontos menos dispendiosos que favorecem o retalhista quando os produtos são selecionados e agrupados. Assim, quando uma transação inclui mais produtos do que o necessário para se qualificar para o desconto mais barato, o mecanismo de preços seleciona os produtos que produzem o menor valor de desconto possível para o cliente.

O motor de preços devolve três preços para cada produto: o preço base, o preço do acordo comercial e o preço ativo.

O preço base é apenas a propriedade do produto e é o mesmo para todos em todo o lado.

No acordo comercial sobre o preço de venda, se a opção Localizar seguinte estiver definida como Sim, o preço mais baixo que for encontrado para os acordos comerciais de preços de venda aplicáveis é utilizado como preço do acordo comercial. Os acordos comerciais podem ser encontrados através de grupos de preços ou do código de conta TODOS. Em alternativa, os acordos comerciais podem ser atribuídos diretamente a um cliente. Se a opção Localizar seguinte estiver definida como Não, será utilizado o primeiro preço do acordo comercial encontrado. Se não forem encontrados acordos comerciais de preços de venda, então o preço do acordo comercial é definido como igual ao preço base.

O preço ativo é calculado ao assumir o preço do acordo comercial e ao aplicar a maior revisão de preços aplicável ao produto. Se não forem encontradas revisões de preços, ou se o preço ativo calculado for superior ao preço do acordo de comércio, o preço ativo é definido como igual ao preço do acordo de comércio. As revisões de preços aplicáveis só podem ser encontradas usando grupos de preços atribuídos a um canal, catálogo, afiliação ou programa de fidelização.

Regras de preço de categoria

A funcionalidade de regras de preços de categoria no Commerce oferece uma forma fácil de criar novos acordos comerciais para todos os produtos de uma categoria. Esta funcionalidade também permite encontrar automaticamente acordos comerciais existentes para os produtos da categoria e expirá-los.

Quando seleciona a opção para expirar acordos comerciais existentes, o sistema cria um novo diário de acordos comerciais para os produtos na categoria que têm um acordo comercial ativo. No entanto, o diário tem de ser lançado manualmente. Além disso, as regras de preços da categoria podem encontrar acordos comerciais existentes apenas se estiver a utilizar a mesma regra de preços (ou seja, se criar uma nova regra de preços que utilize a mesma categoria que existia anteriormente). Se não estiver a utilizar a mesma regra de preços, os acordos comerciais existentes não expiram.

Os preços podem ser aumentados ou diminuídos através dos campos Regra de preço e Preço base das regras de preços da categoria.

  • No campo Regra de preço, selecionar o tipo de alteração de preço a utilizar:

    • Margem de lucro – É utilizada uma percentagem da base de preços para calcular o preço de venda. Por exemplo, um produto que custa 10 e é vendido por 15 tem uma margem de lucro de 50%.
    • Margem – Uma percentagem do preço de venda é utilizada para calcular o montante do lucro. Por exemplo, um produto que custa 10 e é vendido por 15 tem uma margem de 33,3%.
    • Montante fixo – Um montante que é adicionado à base do preço é utilizado para calcular o preço de venda. Por exemplo, um produto que custa 10 e é vendido por 15 tem um montante fixo de 5.
  • No campo Base de preços, selecionar o tipo de alteração de preço a modificar:

    • Custo base – O montante que o retalhista pagou ao fornecedor.
    • Preço base – O preço de venda antes da aplicação de acordos comerciais e revisões de preços.
    • Preço atual – O preço de venda após a aplicação de acordos comerciais e revisões de preços.

Para atualizar facilmente os preços de vários produtos de diferentes categorias de produtos, é possível utilizar as categorias de produtos suplementares juntamente com as regras de preços da categoria.

Melhores práticas

O Microsoft SQL Server Express é utilizado frequentemente para bases de dados de canais devido ao seu custo (gratuito). Tenha em atenção que o SQL Server Express tem limitações de hardware e limites de tamanho de dados. Se não planear corretamente, pode atingir rapidamente os limites de tamanho de dados do SQL Server Express. Esta consideração aplica-se não só aos preços, mas também a outras áreas do produto. Seguem-se algumas melhores práticas que podem ajudá-lo a reduzir o tamanho dos seus dados:

  • Se estiver a utilizar acordos comerciais e os seus preços mudarem, deve expirar os acordos comerciais antigos ao definir uma data de fim. Com o tempo, esta abordagem ajuda a reduzir o número de acordos comerciais que são mantidos nas bases de dados dos canais. Também ajuda a reduzir o montante de dados com que o algoritmo de cálculo de preços tem de trabalhar.

  • Se os seus preços variam consoante a variante de produto, considere utilizar o preço base do produto como o preço da variante mais comum. Em seguida, utilize os acordos comerciais apenas para as variantes de preços que constituem exceções. Esta abordagem ajuda a reduzir o número de registos de acordos comerciais. Como é tão fácil importar dados para o Microsoft Dynamics 365, pode sentir-se tentado a importar um acordo comercial para cada variante de cada produto. No entanto, esta abordagem pode dar origem a muitos acordos comerciais com o mesmo valor. Assim, pode aumentar desnecessariamente o tamanho dos seus dados.

  • O Commerce processa os preços específicos de variantes por ordem do mais específico para o menos específico. Se uma dimensão do produto não afetar o preço, não é necessário definir acordos comerciais para essa dimensão. Por exemplo, um produto está disponível em três cores e quatro tamanhos, mas o preço só varia consoante o tamanho. Se for definido um acordo comercial para cada variante, são criados 12 registos. Em vez disso, é possível definir um acordo comercial apenas para cada tamanho e deixar a dimensão Cor em branco. Neste caso, produz apenas quatro registos.

    Alternativamente, se nem todos os valores de uma dimensão produzirem um preço diferente, é possível definir um acordo comercial para o produto principal e deixar todas as dimensões do produto em branco. Em seguida, defina um acordo comercial separado apenas para cada valor de dimensão que produz um preço diferente. Por exemplo, se o tamanho XXL tiver um preço mais alto, mas todos os outros tamanhos tiverem o mesmo preço, são necessários apenas dois acordos comerciais: um para o produto principal e outro para o tamanho XXL.

Preços que incluem impostos vs. preços que não incluem impostos

Quando define preços de venda no Dynamics 365, não especifica se o valor do preço que está a definir inclui ou exclui impostos. O valor é apenas o preço. No entanto, a definição O preço inclui imposto sobre vendas nos canais permite configurar os canais de modo a incluírem ou excluírem o imposto dos preços. Esta definição é estabelecida no canal e pode mudar mesmo numa única empresa.

Se trabalhar com tipos de imposto inclusivos e exclusivos, é muito importante definir os preços corretamente, porque o montante total que o cliente paga muda se a definição O preço inclui imposto sobre vendas no canal for alterada.

Diferenças entre preços do Commerce e preços sem ser do Commerce

É utilizado um único motor de preços para calcular os preços em todos os canais: call center, loja de retalho e lojas online. Isto ajuda a permitir os cenários unificados do Commerce.

Os preços são concebidos para funcionar com entidades do Commerce em vez de entidades sem ser do Commerce. Especificamente, foi concebido para definir os preços por loja e não por armazém.

O motor de preços do Commerce não suporta as seguintes funcionalidades de preços:

  • Os preços baseado em atributos não são suportado.

  • O pass-through de desconto do fornecedor não é suportado.

  • A funcionalidade de moeda genérica não é suportada. Por outras palavras, mesmo que um acordo comercial tenha o botão de alternar Incluir moeda genérica ativado, o acordo comercial continua a ser considerado válido apenas para a moeda nele definida.

  • O motor de preços padrão do Supply Chain Management suporta o cálculo de preços baseado na data de envio solicitada e na data de receção solicitada, juntamente com a data atual. No entanto, os preços de retalho atualmente não suportam estes valores. A razão é que, nos cenários B2C, os clientes não esperam que a data de entrega solicitada afete o preço do artigo. Em alguns casos, os retalhistas têm operações B2B e B2C. Para as operações B2B, é comum alterar os preços com base nas datas de entrega. Estes retalhistas podem utilizar os preços do Supply Chain Management para o seu negócio B2B e os preços de retalho para o seu negócio B2C. Os preços de retalho só entra em vigor se o utilizador da aplicação for adicionado como um utilizador de call center para os retalhistas poderem atribuir utilizadores específicos que trabalhem com os preços do Supply Chain Management e também atribuir alguns que trabalhem com preços de retalho. Por outras palavras, estes utilizadores devem ser adicionados como utilizadores de call center. Além disso, a propriedade Use today's date for calculating prices tem de ser ativada na secção Diversos no separador Preços e descontos da página Parâmetros de comércio. Desta forma, os utilizadores podem continuar a utilizar o valor do parâmetro Contas a receber para a data de envio solicitada ou data de receção solicitada para os preços do Supply Chain Management. No entanto, o preço de retalho continua a utilizar a data de hoje para os preços.

  • Para os acordos comerciais, são suportadas as seguintes dimensões no motor de preços do Commerce:

    • Dimensões do produto: Tamanho, Estilo, Cor e Configuração
    • Dimensões de inventário: Local e Armazém
    • Dimensões de acompanhamento: Número de série

Além disso, o motor de preços do Commerce suporta as seguintes funcionalidades de preços:

  • O preço baseia-se nas dimensões do produto, por ordem do preço da variante mais específica para o preço da variante menos específica e para o preço do produto principal. Um preço definido ao utilizar duas dimensões do produto (por exemplo, cor e tamanho) é utilizado antes de um preço definido ao utilizar apenas uma dimensão do produto (por exemplo, tamanho).
  • O mesmo grupo de preços pode ser utilizado para controlar preços e descontos.

Melhorias da API de preços

O preço é um dos fatores mais importantes que controlam as decisões de compra de muitos clientes, e muitos clientes comparam os preços em vários sites antes de fazerem uma compra. Para ajudar a assegurar a oferta de preços competitivos, os retalhistas observam cuidadosamente os seus concorrentes e fazem frequentemente promoções. Para ajudar estes retalhistas a atrair clientes, é muito importante que a pesquisa de produtos, a funcionalidade de navegação, as listas e a página de detalhes do produto apresentem os preços mais exatos.

A interface de programação de aplicações (API) GetActivePrices no Commerce devolve preços que incluem descontos simples (por exemplo, descontos de linha única que não dependem de outros itens no carrinho). Desta forma, os preços apresentados estão próximos do montante real que os clientes pagam pelos artigos. Esta API inclui todos os tipos de descontos simples: descontos baseados na afiliação, na fidelização, no catálogo e no canal. Além disso, a API devolve os nomes e a informação de validade dos descontos aplicados para os retalhistas poderem fornecer uma descrição mais detalhada do preço e criar um sentido de urgência se a validade do desconto expirar em breve.