TDF – Persistencia de DF-e
Pessoal vocês já devem ter ouvido falar da badi J_1BNF_ADD_DATA ou como é conhecida… badi NOVA!
Ainda não? Sabe que existe mas não sabe a diferença?
A badi nova é um dos primeiros passos para quem está pensando em implementar o SAP TDF!
Fonte: SAP
Espero que este blog possa esclarecer um pouco mais sobre o assunto e motivá-los a implementarem a mesma na sua empresa ou clientes!
Mas primeiro… Qual a diferença entre a badi nova e a badi antiga (CL_NFE_PRINT~ FILL_HEADER e FILL_ITEM)?
A primeira diferença a se destacar é que a badi nova traz consigo a persistência dos dados. Quando você altera uma informação na geração da NF-e através da badi CL_NFE_PRINT toda informação alterada fica gravada somente no XML! As informações não são salvas no documento da NF-e no ERP! O que é um grande problema; caso precise enviar essa informação para qualquer outro sistema, (ex. sistema fiscal externo para reportar para o SPED), você irá precisar reconstruir a mesma lógica na interface deste!
Com a badi nova, as informações alteradas são atualizadas no ERP, o que facilita consideravelmente a interface com outros sistemas; bem como elimina as diferenças entre o que você visualiza na J1B3N e o XML gerado! Com isso, evitar uma possível multa pela fiscalização quando constatado diferenças e/ou ausência de informações!
Outra diferenca, é o momento em que a mesma é chamada! A badi nova é chamada no momento em que o documento é salvo, ao invés de ser no momento em que o documento é enviado para a mensageria! Uma vantagem disso é que você pode aplicar diversas regras de validação antes mesmo da nota ser numerada e/ou enviada para mensageria!
Fluxo da Persistência antes da Persistência
Fonte: SAP
Fluxo depois da Persistencia
Fonte: SAP
Por fim outra diferença importante a ser destacada e que não deve ser menosprezada é de que nem todas informações que hoje podem ser atualizadas através da badi antiga, estão disponíveis para serem alteradas na badi nova!!! Ou seja, cuidado na migração! Caso encontre alguma necessidade devido a alguma deficiência ou falha no SAP, recomendo abrir um chamado justificando a necessidade! Do contrário, revise seus processos!
A badi nova traz consigo também novos abas e campos na J1B*N! Veja abaixo algumas telas…
Fonte: SAP
Fonte: SAP
Fonte: SAP
Fonte: SAP
Outras perguntas frequentes…
Preciso licenciar o SAP TDF para implementar a badi nova?
Não! A badi nova está coberta pela licença do ERP e não depende do licenciamento do SAP TDF.
A badi nova é pré-requisito para o SAP TDF?
Sim! É fortemente recomendado você implementar a badi nova antes; considere a badi nova como uma melhor prática!
Preciso implementar as notas referente as melhorias nos dados mestres (novos campos)?
Sim. É recomendado que você implemente essas notas!
Além das melhorias em dados mestres existe algum outro pre-requisitos a ser considerado?
Sim, você irá precisar implementar o novo controle de tela para documentos fiscais!
Ao ativar a badi nova, a badi antiga deixa de funcionar?
O compartamento inicial era assim, mas recentemente a SAP liberou uma nota que permite você implementar a badi de nova de forma faseada. Veja mais no blog abaixo: http://scn.sap.com/community/portuguese/sped-and-nf-e/blog/2015/02/12/utiliza%C3%A7%C3%A3o-de-ambas-as-badis-de-nf-e-j1bnfadddata-e-clnfeprint
A badi nova está disponível para todas versões?
Não! Somente a partir do ECC 6 EHP5!
Quais são as principais notas?
1844619 – NF-e: Storing Additional Data – BAdI, derived fields, texts
1844621 – NF-e: Storing Additional Data – Obj.Services & NF Writer
1860433 – NF-e: Storing Additional Data for DANFE & Reporting
1860360 – NF-e: Storing Additional Data – application generated NFs
1860362 – NF-e: Storing Additional Data – outbound NF-e & Reports
1860433 – NF-e: Storing Additional Data for DANFE & Reporting
1869063 – NF-e: send obsCont, obsFisco, procRef to GRC
1865657 – NF-e: Update MM/FI with NF-e number – Credit Memos
1889990 – NF-e: Update MM/FI with NF-e number – Credit Memos
1803009 – Renewal of Screen Controls in Nota Fiscal Writer
1877404 – NF-e: Enhancements NF Writer screen controls
1859126 – NF-e: Storing Additional Data – Enhancement of NF Writer
1882947 – NF-e: Storing Additional Data – Corrections for NF Writer
1923423 – Nota Fiscal: only two tax lines are displayed on the tax screen
1951532 – Nota Fiscal: scroll through items not consistent
Concluindo…
Implementar a badi nova se justifica pelo fato de passar a ter na origem (ECC) as informações conforme o documento autorizado pela SEFAZ e com isso reduzir a manutenção das interfaces com sistemas externos!
Espero que tenham gostado e qualquer dúvida perguntem!
Abraços!!!
Karen Rodrigues
Muito bom! Todos deveriam olhar pra esse assunto, mesmo aqueles que ainda não possuem planos para migrar para o TDF! Com certeza é uma melhor prática!!!
Excelente informação Karen.
Tem sido tópico recorrente nos projetos TDF e realmente vale o planejamento para qualquer empresa.
Quero comentar um pouco sobre isto...
"Por fim outra diferença importante a ser destacada e que não deve ser menosprezada é de que nem todasinformações que hoje podem ser atualizadas através da badi antiga, estão disponíveis para serem alteradas na badi nova!!!"
... e jogar alguma luz sobre o que fizeram da BAdI dita velha.
Ao invés de se adequar processos, realizar implementações funcionais que geram desde o primeiro documento a informação correta pela customização que mais tarde virará uma nota fiscal correta com todos os impostos calculados corretos, e demais informações muitas implementações usavam a BAdI velha para resolver qualquer necessidade.
Ok. Eram outros tempos... a necessidade era implementar a tal da Nota Fiscal Eletronica, então as "mágicas" que eram realizadas no SAP Script migraram para a BAdI naturalmente. Afinal era uma época onde nota fiscal não era problema da empresa... o fiscal que se vire com a auditoria e tal... Quem mandava era o comercial. Vender é o que importava.
Isso sem contar que cada "mágica" feita ali precisava ser refeita para cada obrigação, não havia persistência.
Começaram as multas e multiplicadas por erro cometido, bom... como estava sistematizado a cada faturamento poderia representar uma multa. Opa... olha o dinheiro vazando. Setor Fiscal começou a ser ouvido novamente. Atualmente empresas que adotaram boas práticas adicionam os especialistas fiscais em cada projeto para que não se realize processos não conformes fiscalmente.
Há sete anos atrás, o processo também era novo para SAP, nem ela entendia exatamente toda essa necessidade e não permitia que qualquer campo seja modificado, então tome field-symbol para alterar até o que não era disponível para ser modificado.
O SAP agora tem campos novos cobrindo melhor as necessidades do processo brasileiro, alguns exclusivos para as obrigações que se tem fazer. Ele não se tornou um software fiscal mas com o SAP TDF oferece a base para que parceiros consumam e salvem informação fiscal.
Agora voltando pro blog e fazendo minha conclusão.
É uma excelente oportunidade de faxina.
Cada linha de código da BAdI velha é uma oportunidade de melhoria de processo, no mínimo de obter conhecimento do que existe ali dentro. É engraçado mas nenhum cliente nos soube dizer o que eles "fizeram" ali dentro.
E se por ventura você não tiver como modificar algum campo, abre um chamado para SAP. Mostra seu caso de uso e provavelmente você terá ele em mãos em curto espaço de tempo.
Na pior das hipóteses vocês saem deste processo de visitação com informação vital para se usar no planejamento. Melhor que não mexer porque não sabe o tamanho do buraco.
Tendo o dado correto de ponta a ponta é uma economia muito grande de dinheiro.
Atenciosamente, Fernando Da Rós
Fernando,
Muito obrigada por seus comentários!
Concordo com você, e este é um ponto que tenho trabalhado nos clientes, tentar influencia-los a implantar a dita badi nova e revisarem seus processos para atender a legislação com qualidade e simplificação.
Imagina, alguns clientes chegam a 15.000 linhas de código na badi 😯
Espero que este blog realmente possa ajudar as empresas a reverem seus conceitos!!!
Um abraço,
Kare Rodrigues
15.000???????? 🙁
Sem contar as consultorias que vedem "pacote pronto", tipo plug-in pra BAdI...
Lamentável...
hehehe muito bom Fernando!
Karen, parabéns pela iniciativa do post.
Quando lançamos o TDF eu havia prometido escrever uma série sobre todas as features e no fim nunca consegui.
Realmente o que nos motivou a fazer a nova BAdI foi permitir aos clientes fazer a faxina mencionada pelo Fernando e garantir que os documentos fiscais já nasçam da forma mais consistente possível.
Outra motivação era a de melhorarmos o produto NF-e, criando soluções para as falhas / necessidades encontradas pelos clientes durante a implementação, e que foram solucionadas com "gambiarras" na BAdI antiga. Algumas melhorias foram já implementadas, mas sabemos que os clientes enfrentam uma gama gigante de variações de cenários de negócios em cada estado, e sendo assim, não só a NF-e, mas a Localização como um todo que deve ir se adaptando...
Resumindo, com a BAdI nova quisermos ser estritos para ficar mais fácil de identificar as falhas.
Abraços
Ola Bruno!!!
Comecei a trabalhar com TDF e achei legal compartilhar as minhas experiências na comunidade e fora dela, bom exercício de aprendizado 🙂
Agradeço muito teu depoimento, reforçando o que foi dito pelo Da Ros.
Grande abraço!
Karen Rodrigues
Olá Karen,
Ótimo post para incentivar os clientes a migração, pois a utilização da BADI nova anda bem baixa, mesmo por aqueles que já tem planos concretos de utilizar o TDF.
Atenciosamente,
Gustavo Machado
Olá Karen,
Muito obrigado pelo excelente post esclarecendo este assunto, que no meu ponto de vista é crucial para o futuro de NF-e, SPED's etc no SAP TDF.
Estamos implementando o TDF em um cliente e gostaria de saber se existe alguma documentação da SAP orientando a migração para a a badi J_1BNF_ADD_DATA como melhor prática.
Entendo que para os SPEDs no TDF a implementação da nova badi é essencial entretanto, por conta de todo o esforço que será necessário para essa migração, estamos encontrando certa resistência do cliente para migrar. (apesar de conhecerem todo o benefício)
Muito obrigado.
Atenciosamente,
Gustavo Gonçalves
Que saudades dos objetos J_1B*... NOT!
Eu imagino!!!! 😆
Oi Karen!!!
Ótima postagem... parabens!!!
Estou implantando a nova badi em um cliente e me deparei com uma questão: a BAPI de criação de NF não chama o método ADD_DATA ou ADD_DATA_J1B1N da nova badi? Se for isto, vamos ter que revisar algumas dezenas de programas Z que criam nota por este meio, ou seja, revisar o nosso cronograma rs.
Obrigado pela contribuição!!!
Oi Mariana,
Desculpe por me intrometer, mas posso confirmar que a BAPI de criação de NF não chama a BAdI nova.
O conceito da BAPI é e que quando for realizada a chamada dela já devem ser informados todos os parâmetros necessários para a criação da nota.
att,
Renan Correa
Imagina Renan, obrigado pelo seu retorno.
Acho estranho esta decisão da SAP. Se ela deixou uma opção de processarmos a nova badi via J1B1N (botão de dados adicionais), acho que ela poderia ter deixado também uma opção de acionar o ADD_DATA via BAPI, um flag por exemplo.
Por mais que o conceito é que não é necessário executar a badi quando da criação de nota writer, a realidade de todas as empresas que eu passei até hoje é que mesmo para este tipo de nota, existem lógicas inseridas na BADI. Não é tão simples assim alterarmos todos os programas Z que chamam a BAPI ajustando em cada um as necessidades de persistência que poderíamos encapsular em um único local, no ADD_DATA.
Existe alguma possibilidade da SAP fazer isto? O que você me sugere?
Muito obrigado!
Olá Mariana,
Considerando apenas o seu caso (vários Zs chamando a criação da NF via BAPI) faz sentido que ficasse centralizada a lógica, porém em termos de desenho de solução como um todo, ao usar a BAPI você deveria ter os dados prontos para apenas mandar criar o documento - entre outras coisas isso agiliza o processamento.
Como sugestão, você pode encapsular o código desejado (validações, determinações, etc.) num include/função/etc.que seja chamado antes da BAPI e também dentro da BAdI.
Desta forma, ao ajustar este código, terá efeito para todas as origens (via BAPI ou não).
O ponto de atenção é com o desenho adequado da passagem de parâmetros para que funcione independentemente do momento em que é chamado (na BAdI as informações estão em certas estruturas, via BAPI estará em outras, precisa "normalizar" isso e fazer com que o programa se comporte adequadamente).
O que acha?
Abs,
Eduardo Hartmann
Oi Eduardo!
Eu tinha pensado exatamente isto. Fazer com que a BAPI chame via enhancement point a BADI nova (ou algo como você falou).
Obrigado pelo seu retorno!!
Abs,
Oi Mariana.
Apenas para te ajudar. Os campos necessários para o(s) SPED e para a validação do XML estão todos presentes na BAPI_J_1B_NF_CREATEFROMDATA e, os campos que não estão presentes na mesma são por que deveriam derivar do cadastro da sua filial, ou do material ou do parceiro associado com a criação da nota fiscal writer.
Se você tiver algum campo que seja sensível ao(s) SPED e/ou a autorização do XML que não esteja presente na BAPI_J_1B_NF_CREATEFROMDATA seria legal colocar nesse fórum para discutirmos todos sobre o mesmo.
Abraços
Kyono
Oi Eduardo!!!
Vou averiguar e se encontrar alguma coisa informo por aqui.
Obrigado!
Abs,
Oi Mariana,
Eu entendo essa necessidade, porém não temos nenhuma previsão de desenvolvimento para esta funcionalidade. Existe o Ideas place de NFe e pode ser um canal para solicitar tal necessidade para a SAP: SAP Nota Fiscal Eletronica: Home. (porém não existe nenhuma garantia de que a funcionalidade será desenvolvida posteriormente).
Minha opinião pessoal é de que vocês acabarão tratando isso via projeto nas chamadas da BAPI para conseguir atender ao cliente.
att,
Renan Correa
Oi Renan!
Ótimo, obrigado pelo seu apoio.
Vou seguir suas orientações!
Abs,
Bom dia a todos!
Alguém aqui sabe como manejar o trigger automático para imprimir o DANFE agora com o novo badi?
Porque no antigo badi, estamos usando o método badi CALL_RSNAST00, mas o novo badi não o tem.