Desde o início da situação de Covid, a indústria varejista está passando por uma revolução muito rápida, onde o Cliente está sempre no centro do processo comercial, mas também em diferentes locais físicos. Isso significa que algumas sacolas de compras são preenchidas na loja física e algumas delas são simplesmente uma cesta virtual.
O desafio neste ambiente é sempre manter os preços e promoções sincronizados em todas as diferentes áreas de compras. Com uma estrutura de preços bastante simples, onde os preços são gerenciados em um sistema mestre, como o S/4 Retail, e então distribuídos para diferentes sistemas, seja através de Idoc (no padrão COND_A) ou para o sistema de PDV através da lista de surtido, parece ser direto. Como cereja do bolo, recentemente implementamos uma solução onde o sistema externo chamava os preços no S/4 para calcular preços, subtotais e funcionava muito bem. Posso apenas supor que a razão para isso poderia ser que a SAP melhorou o módulo de PREÇOS (incluindo a opção de chamar o módulo para o número de itens PRICING_MULTI_ITEM) ou que tivemos um desenvolvedor muito bom que projetou e construiu a solução de forma complexa.
O cenário em que há um novo preço promocional ou um simples desconto sobre o preço regular, como descrito, parece bastante normal de lidar. O verdadeiro problema surge quando você ouve do Cliente "também temos a promoção Compre 2 e leve 3 pela metade do preço" e isso deve estar disponível para os Clientes que usam o PDV e qualquer cesta virtual (web, aplicativo, etc.). Para o sistema de PDV, automaticamente você pode pensar nas compras de bonificação disponíveis no sistema varejista, que é uma boa direção. Na transação RDMBBY01, simplesmente mantém-se a informação como um exemplo para comprar 2 e levar 3 pela metade do preço.
A interface do usuário não é a mais recente, mas funciona e devo admitir que é direta. A compra de bonificações armazenada é então distribuída para o PDV, mas infelizmente no caso de integração com o procedimento de preços da SAP, não é mais tão fácil. Para qualquer sistema receptor externo, é necessário construir alguma lógica de integração, mas no caso de integração com, por exemplo, preços usados em pedidos de venda no Varejo, não há uma maneira fácil de integrá-lo, além de implementar sua própria lógica usando cálculos de agrupamento de condições de venda ou itens gratuitos, mas eventualmente você descobrirá que essa solução é simplesmente muito pesada para estender e manter.
Teoria
Dado que sempre chega o novo e a SAP decidiu resolver esse problema com um repositório central para preços e promoções através da ferramenta SAP Omnichannel Promotion Pricing (OPP). Na teoria, o OPP é uma ferramenta central para armazenar preços e promoções em todos os canais e usá-la para calcular o preço de venda por solicitação ou distribuí-lo para o aplicativo relevante.
Entradas
Com a definição do OPP como uma ferramenta central para preços e promoções com a função de cálculo de preços ou distribuição para sistemas relevantes para manter essa área sincronizada em todo o panorama. Para esse propósito, como entrada para o sistema, são necessários os seguintes itens:
- Preço regular: esse preço não é definido no OPP, mas geralmente é distribuído do seu sistema backend (S/4 ou ECC) através de DRF ou importado para o SAP CAR de um sistema externo também através de funções de entrada DRF no CAR.
- Em termos técnicos, o preço de venda é integrado do S/4 como um objeto DRF PSPR ou PMPL (inclui preço de avaliação) e o preço de compra como PSOS. Em seguida, no CAR, respectivamente, são lançados o processamento de objetos de localização de produtos e linhas de transporte.
- Oferta/Promoção: as ofertas são criadas na aplicação Fiori Manage Promotional Offers ou simplesmente importadas de sistemas backend como S/4 (objetos no S/4 são Promoções ou Compras de Bonificação) ou sistemas externos em ambos os casos através da ferramenta DRF.
- Em termos técnicos, as ofertas são armazenadas na tabela /DMF/OFR_TRM_PRD para detalhes dos elementos e então são convertidas em Promoções que seguem o formato da Associação de Padrões Tecnológicos para o Varejo (ARTS) armazenado na tabela /ROP/PROMOTION. Para importar oferta de um sistema externo, utilize a função DRF de /DMF/OPIF_OFFER_INBOUND no SAP CAR. No S/4, a integração pode ser feita através de DRF com objetos POFF e PBBY, respectivamente, para Promoção e Compra de Bonificação.
Até agora, pode-se ver que, para a integração com o sistema backend da SAP, a Fundação de Dados de Demanda (DDF) seria muito apreciada. Para um tipo de solução alternativa simples, seria chamar o módulo de função para o processamento de objetos respectivos no CAR, pois é o caso de integração com uma ferramenta externa, mas não será tão fluido quanto no caso de usar DDF.
Opção de local de cálculo.
O que é muito poderoso do ponto de vista do OPP é o local onde o cálculo é realizado. No passado, sempre foi um obstáculo no backend se você tivesse que integrar promoções com pedidos de venda (possível através de condições de venda), mas as compras de bonificação criadas no sistema backend e integradas no processo de venda eram quase impossíveis. Suponho que esta foi uma das razões pelas quais com o OPP você tem duas opções para a implementação desta ferramenta.
Implantação central: com esta opção, o serviço web reside no sistema CAR (mais precisamente, assumo que é uma espécie de bean de Java). Este serviço pega o preço regular e todas as ofertas que residem no sistema CAR e calcula as cifras necessárias. O bom disso é a integração suave na fixação de preços em seu sistema SAP backend. No lado do S/4, a configuração inclui a configuração da conexão RFC para o serviço seguida da etapa de configurar o que deve ser enviado e recebido do serviço.
Pedro Pascal
Se unió el 07/03/2018