Skip to Content

Recentemente precisei customizar esse cenário na empresa aonde trabalho, e não achei nenhum artigo ou post relacionado à VFRB voltado para Localização Brasil.

Processo

O Faturamento Retroativo é necessário quando o cliente altera seus preços retroativamente. Por exemplo, vamos supor que faturamos várias NF-es do material X pelo preço de R$ 100,00. O Departamento de Vendas vai até o cliente e negocia um aumento de preço retroativo para compensar a inflação dos ultimos meses, então o preço é alterado retroativamente para R$ 120,00. Agora temos que faturar o cliente essa diferença de R$ 20 por cada material ja faturado.

Isso é facil de ser customizado e feito se formos fazer um por um, utilizando a VA01 com referencia a um docto de faturamento, e depois a VF01.

Porém quando precisamos desse cenário geralmente são muitos materiais e inúmeras NF-es.

VFRB

A VFRB possui dentro dela uma tela de configuração, que é mostrada automaticamente a primeira vez que a transação é utilizada.

Os dois campos de cima são referentes a Nota de Crédito, e os de baixo à Nota de Débito. Nesse exemplo iremos utilizar somente o cenário de Nota de Débito.

Os campos da esquerda são para indicar um tipo de documento de faturamento, que deve ser do tipo Nota de Débito. As faturas serão geradas a partir desse documento. Os campos da direita são os Motivos da Nota de Crédito ou Débito. Nesse caso iremos utilizar o 200, que é “Diferença de preço: preço baixo demais”

/wp-content/uploads/2014/02/v1_396549.jpg

O primeiro passo antes do usuário executar a VFRB, é ele alterar a condição de preço retroativamente na VK12, para as datas corretas.

Quando a VFRB é executada, de acordo com os critérios de seleção utilizados, ela irá comparar o valor das faturas do período selecionado versus o valor que seria calculado com o novo preço, e irá nos mostrar as diferenças.

/wp-content/uploads/2014/02/v2_396548.jpg

Nesse caso, rodei a VFRB somente para um material. os ZB01 são as vendas normais, feitas no dia 03.01.2013, e os ZB10 (no caso das duas primeiras linhas) são notas de débito já geradas para as ZB01 correspondentes.

Nos dois primeiros casos, como ja foram geradas, o SAP nos mostra o valor a ser faturado em branco, pois já estão OK.

Nas de baixo, podemos ver exatamente a quantidade que foi faturada, quanto é a diferença que tem que ser faturada para o cliente, e os preços, tanto o antigo como o novo.

Selecionando os checkboxes ao lado de cada fatura, podemos ou Simular ou gerar o Faturamento Retroativo. Será gerada uma Nota de Débito por NF-e já emitida. O cabeçalho da VBRK tem um campo que aponta para a NF-e de referência, e por isso o SAP não faz uma Nota de Débito para muitas NF-es.

Porém, caso o report seja executado com multiplos materiais e uma NF-e foi emitida com vários materiais, será criada uma ND para esse NF-e e todos os materiais selecionados serão incluídos.

Um aspecto interessante de utilizar a VFRB é que o SAP irá colocar ND no fluxo de documentos. Exemplo abaixo do primeiro doc de faturamento da lista da imagem acima:

/wp-content/uploads/2014/02/v3_396569.jpg

Customizing

O ideal nesse caso é ter primeiramente o cenário de Nota de Débito já configurado na maneira convencional, ou seja – manualmente, onde se faz a VA01 e VF01 para cada NF-e individual.

Nesse cenário, criei primeiro esse fluxo e depois aproveitei e utilizei-o para a VFRB

Meu documento de vendas principal nesse exemplo é o ZB01, que foram as faturas emitidas com os preços originais, antes da mudança retroativa.

O ZB10 é o documento para Nota de Débito / Nota Complementar

Abaixo os passos que conferi / customizei

1) Documento de Vendas, chamado de ordem de venda “dummy” na documentação da SAP. É como o documento de faturamento sabe qual tipo de NF utilizar. Por isso ele precisa estar criado e com tudo ok no customizing dele

/wp-content/uploads/2014/02/v4_396923.jpg

/wp-content/uploads/2014/02/v5_396924.jpg

2) Item de vendas que ja existia para o cenário manual via VA01

/wp-content/uploads/2014/02/v6_396925.jpg

/wp-content/uploads/2014/02/v7_396929.jpg

3) Atribuir tipo de Nota Fiscal ao docto de Vendas

/wp-content/uploads/2014/02/v8_396930.jpg

/wp-content/uploads/2014/02/v9_396931.jpg

4) Documento de Faturamento

/wp-content/uploads/2014/02/v10_396935.jpg

/wp-content/uploads/2014/02/v11_396936.jpg

5) A ZB10 -> ZB10 ja tinha feito para o cenário manual, criei a ZB10 -> ZB01, ja que quando a VFRB executa, ela cria o docto de faturamento ZB10 com itens ZB01

/wp-content/uploads/2014/02/v12_396937.jpg

/wp-content/uploads/2014/02/v13_396938.jpg

6) Atualizar controle de cópia para docto de faturamentos

/wp-content/uploads/2014/02/v14_396939.jpg

Controle de cópia: doc.faturamento -> doc.faturamento (VTFF)

/wp-content/uploads/2014/02/v15_396940.jpg

7) Assinalar fatura ZB10 com item ZB01 como relevante para faturamento

/wp-content/uploads/2014/02/v16_396941.jpg

/wp-content/uploads/2014/02/v17_396942.jpg

8) Mais uma atualização no tipo do documento de faturamento

/wp-content/uploads/2014/02/v18_396943.jpg

/wp-content/uploads/2014/02/v19_396944.jpg

9) Tipo de NF-e para Faturamento Retroativo deve ser 2N, para que a tag <finNfe> no XML seja automaticamente preenchida com “2”


/wp-content/uploads/2014/02/retro1_685887.png

/wp-content/uploads/2014/02/retro2_685888.png

10) Na pricing da Nota Complementar, deve existir a condição PDIF para que a diferença entre as duas faturas seja calculada e lançada. Eu utilizei a mesma pricing do ZB01 no ZB10, só adicionei a condição PDIF logo abaixo da condição de preço principal (no meu caso, ZB00).

/wp-content/uploads/2014/02/v20_396945.jpg

/wp-content/uploads/2014/02/v21_396946.jpg

Fiscal

1) Adicionei o código abaixo no programa ZNFE_PRINT_DANFE para incluir informação na DANFE conforme determinação fiscal.

Não fiz via customizing (na opção de mensagens, na parte de Faturamento -> Localização Brasil) porque como copiamos os dados de um Documento de Faturamento e não da Ordem de Venda, esse dado não existe. Só existiria se o processo fosse feito via uma nova VA01, aonde temos um campo Referência que preenchemos com o numero da NF-e referenciada, e que depois é transportado até a hora de emitir a NF-e.

/wp-content/uploads/2014/02/v22_396947.jpg

2) Outro detalhe que inclui foi o numero do Pedido na tag <xPed> do item no XML da NF-e, pois como a VFRB copia do outro faturamento e não da Ordem, o faturamento não tem essa informação. Essa alteração pode ser feita no FILL_ITEM do preenchimento da estrutura do XML, e tem que ser buscada na ordem de venda original.

Conclusão

Obviamente que cada SAP tem cenários diferentes com suas próprias peculiaridades, mas para um cenário de venda básico, essa é a configuração necessária.

Também temos aqui um cenário de vendas onde há Industrialização, ou seja, o cliente nos envia peças que devem ser utilizadas no produto final, e quando vendemos o produto final o mesmo é vendido com CFOP 5124/AA e inclui uma porcentagem de mão de obra.

Para fazer a VFRB nesse cenário foi bem mais difícil, já que a VFRB calculava errado a diferença por causa da porcentagem de mão de obra. Nesse caso precisei criar outras condições e incluir algumas fórmulas.

Espero que o documento acima seja útil e ajude outras pessoas com dificuldades nesse cenário.

_______________________________________________________

EDIT (20/09/2014) – Incluído mais 2 itens na parte Fiscal

To report this post you need to login first.

15 Comments

You must be Logged on to comment or reply to a post.

  1. Eduardo Chagas

    Parabéns pelo blog Gabriel!

    Fico pensando no sujeito que faz uma negociação dessas… ele se preocupou com o lado dele e não com o lado do pessoal interno para gerar notas de combrança tão pouco do lado do cliente que terá que lançar todos esse complementos.

    Ai.. aquele pessoal que poderia estar trabalhando na melhoria de processo, saneando cadastros… fica entulhado documentos pra conferir um a um e lançar no sistema.

    Enfim… nada contra ao processo de vocês até porque não é só vocês que adotam essa prática.

    Abraço

    Eduardo Chagas

    (0) 
    1. Gabriel Andrade Post author

      Obrigado, Eduardo!

      Pois é… esse cenário ocorre mais em empresas do ramo automotivo.

      O que acontece é que é muito dificil reajustar preços rapidamente com a montadora, e leva bastante tempo para renegociar um preço que ficou obsoleto por conta de aumentos no preço do aço, por inflação, etc…

      Então dai é negociado retroativamente e por isso esse cenário acaba sendo muito útil nesses casos!

      Abraço,

      Gabriel

      (0) 
      1. Eduardo Chagas

        Sei bem! Já trabalhei nesse ramo! É uma vida difícil pra quem fornece pra montadora.

        Achei muito legal essa funcionalidade… não sabia que tinha isso em SD.

        Abraço

        Eduardo Chagas

        (0) 
  2. Karen Rodrigues

    Ola Gabriel,

    Interessante este cenário, não imaginava que este tipo de negociação existia…. 😯

    Obrigada por compartilhar seu conhecimento conosco.

    Abraços,

    Karen Rodrigues

    (0) 
      1. Gabriel Andrade Post author

        Olá Karen!

        Então, para cada NF original tem que ser feita uma Complementar. Talvez fiscalmente seja permitido fazer 1 complementar para varias NFs, mas no SAP pela VFRB não.

        O motivo é que o header da VBRK só consegue referenciar 1 NF-e por vez.

        A unica coisa que é possivel fazer é uma Complementar com vários itens, desde que todos constem na NF-e original.

        Abraço,

        Gabriel

        (0) 
        1. Karen Rodrigues

          Oi Gabriel,

          Perfeito!!!

          Fiscalmente é possivel referenciar Varias Nf-e numa Nf-e complementar (se consideramos aspectos fiscais )…mas infelizmente com as novas regras do layout 3.10 trouxe um presente de grego, onde sera possível referenciar 1 para 1….

          Mais uma vez, grata por sua reposta.

          Abraços,

          Karen Rodrigues

          (0) 
  3. Jyoti Prakash

    Hi Gabriel,

    Nice documentation on retro-billing configuration. This standard SAP functionality, is mostly used in automotive industry and event industries where raw materials price to fluctuate often Do or traded on day to-day basis or price negotiation take place in the after sales (like Steel industry). Please refer my post on Retro-billing SD VFRB on Retro-billing is prerequisite and process flow.

    Translated to English using Google Translator.

    Uma boa documentação sobre a configuração de retro-billing. Esta funcionalidade SAP standard, é usado principalmente na indústria automotiva e até mesmo indústrias em que o preço da matéria-prima para muitas vezes flutuam ou comercializado com base no preço ou negociações diárias ocorrem depois que as vendas (como a indústria do aço). Por favor, veja meu post sobre

    Retro-Billing SD (VFRB)

    em Retro-billing para pré-requisito e fluxo do processo.

    Best Wishes, JP

    (0) 
    1. Gabriel Andrade Post author

      Hello Jyoti!

      Thanks for your comments. I read your article and it is really good! Too bad I hadn’t seen it while I was struggling with this scenario 🙂

      I wrote this article more focused on the customizing since I did not find any material on Retro Billing for Brazil, since we have NF-e and makes it a bit more complex.

      Thanks for sharing the link!

      Regards,

      Gabriel

      (0) 

Leave a Reply