Pricing CBT de SD com preço bruto

Origem da discussão

Numa discussão com um grupo do Whatsapp de consultores apareceu um colega perguntando sobre como fazer uma pricing preço bruto em SD usando CBT o e o que considerar para fazê-la.

Reflexões filosóficas (ou não) sobre o preço

O primeiro ponto para confirmar com o cliente nesse caso é o entendimento de preço bruto. Mas preço bruto é uma obviedade, não? Nãão, acreditem, já vi discussão de que preço bruto é o com ICMS sem IPI, outro caso era com ICMS e IPI, outro com ICMS-ST e IPI, então sempre é bom garantir o que o cliente quer primeiro.

Passado esse ponto da discussão, precisa analisar o que fazer no SAP.

Como é a pricing RVABRA de SD

Na pricing normal RVABRA do SAP (e nas pricings no resto do mundo todo diga-se de passagem) o preço comumente usado é PR00, que é líquido (ou seja sem considerar impostos).

No caso de países com VAT isso não é um problema pois “valor líquido do item x alíquota do IVA” vai ser o valor do imposto, mas, porém, contudo, entretando, todavia no BR temos vários impostos e cada um com uma base diferente e que incidem com regras diferentes que um ser humano sozinho dificilmente conseguiria lembrar.

O mais próximo que temos de consolidação das regras tributárias no BR é o livro abaixo:

Devido a essa complexidade surge a necessidade de algumas empresas quererem um preço bruto na Ordem de Vendas, até para que não precisem ficar calculando em excel o preço líquido a partir do bruto e inserir o líquido no SAP (e enlouquecer com as diferenças de arredondamento de 0,01 centavo).

A Moral da história é que o standard da SAP não faz sozinho o cálculo usando o preço bruto.

Isso quer dizer que para fazer essa pricing desse jeito precisa de um desenvolvimento? SIIIIIIMMM.

E tem um jeito só de fazer esse desenvolvimento? NNNNNÃÃÃOOOO.

Tem uma “pá de jeitos” de fazer isso, pode usar fórmula, enhancement ou outras técnicas e cada um tem vantagens e desvantagens. Já vi comentários de que faria para fazer via configuração, mas nunca vi como seria e quais cenários seriam atendidos.

Solução via fórmula – Vantagens e desvantagens

Um dos jeitos mais comuns que eu conheço para fazer esse desenvolvimento é via fórmula na pricing substituindo a fórmula 320 na condição ICMI. Até a condição ICMI só temos condições de preparação para o cálculo, que começa efetivamente ali.

Tem gente que vai dizer: aahhh Renan, mas se eu botar uma fórmula 9** na pricing eu vou perder o suporte do standard da SAP! Por favor não digam perder a garantia, SAP não é uma geladeira comprada na internet com garantia extendida.

Minha resposta: E tu acha que se se tu fizer uma pricing ZVABRA com enhancement nos métodos da classe CL_TAX_CALC_BR a SAP vai dar suporte nos erros causados pelo teu enhancement na pricing Z*? É claro que não.

Então a polêmica fórmula ou enhancement é só isso?

Não, tem outras diferenças:

• Fórmulas tem um mecanismo próprio de ativação/transporte.

• Fórmulas customizadas não são atualizadas por notas. Por curiosiade até olhei a fórmula 320 e achei uma nota de 2019, 3 de 2018 e 2 de 2015, ou seja, não foram muitos mudanças nos últimos 7 anos. Além disso nada te impede de chamar a 320 de dentro da tua fórmula 9**.

O enhancement tem as suas vantagens?

Sim, claro que tem e uso/recomendo em vários casos. Talvez eu apenas não tenha achado um jeito legal de fazer isso na pricing, mas estou aberto a sugestões nos comentários.

Exemplo de Preço Bruto com ICMS/PIS/COFINS em SD:

No meu exemplo vou criar uma fórmula customizada (para este caso criei a 975, mas podia ser 920 ou 9**).

A fórmula abaixo executa a fórmula 320 ( carrega em pricing várias estruturas básicas ) e depois disso sobrescreve o valor XKWERT com o valor bruto ( copiado do step 198 da pricing ).

Aqui tem um exemplo de uma fórmula. Isso aqui atende todos os requisitos possíveis? Nããoooo.

Por exemplo ICMS ST e IPI são adicionados, nesse caso aqui ia ficar errado pois precisaria tirar elas da ICMI.

No lugar do step 198 hardcoded dá para usar outras coisas? Sim, pode usar substotais da pricing por exemplo.

Aqui tá o exemplo da pricing com a fórmula customizada 975 no lugar da fórmula 320 (não atribuo a chave ERL nesse passo). Reparem também que as outras condições continuam com a fórmula 320.

Cálculo na pricing em si na ordem de venda:

O Preço Bruto fica na condição de preço (que no exemplo é uma Z* e não a PR00):

Aqui aparece a ICMI usando a fórmula 975 do exemplo, nota-se que o valor bruto aparece aqui (e não o preço líquido + ICMS):

O valor net aparece calculado aqui (Bruto – ICMS/PIS/COFINS):

Vamos olhar como ficou na nota?

Nota Fiscal gerada com o preço bruto da pricing:

Só para mostrar que o valor da pricing é o mesmo da NF:

Exemplo do lançamento da nota fiscal com o valor total na linha do cliente. O formato do lançamento em FI também vária conforme o local onde estão as chaves ERL, de impostos e as redutoras de receita.

Você tem outros jeitos de fazer um cálculo com preço bruto na pricing? Posta aí nos comentários. Achou ruim a solução, dá umas sugestões de melhorias aí.

Você quer compartilhar uma solução diferente? Me contata e abro espaço no blog para você fazer um post detalhando a sua forma de solução.

Valeu Gurizada!

Renan Correa

Quer ficar ligado nas novidades de localização? Entra no grupo da S4CN no Telegram e segue a gente no canal do Youtube.

Mais infos sobre a localização Brasil no ERP, direto da sap, vocês podem conferir no SAP community na tag de S/4HANA logistics for Brazil

Outros posts sobre Localização você pode conferir filtrando pela categoria NFE/CTE ou Localização BR Geral.