Utilização de ambas as BAdI’s de NF-e ( J_1BNF_ADD_DATA e CL_NFE_PRINT )
Olá Pessoal,
A SAP liberou hoje a nota “2112507 – Additional Data x Mapping BAdI Enablement” que permite a utilização de ambas as BAdI’s da NF-e simultaneamente.
Esta flexibilização foi desenvolvida para facilitar a transição da BAdI de mapeamento clássica (CL_NFE_PRINT) para a BAdI de persistência (J_1BNF_ADD_DATA).
A decisão de qual BAdI será executada para um determinado documento será feita com base na implementação e utilização de ambas as BAdI’s em tempo de execução dos programas.
Por exemplo, se a BAdI J_1BNF_ADD_DATA está ativa e as estruturas de exportação foram modificadas na execução do código implementado em um método (ADD_DATA por exemplo), então o sistema irá assumir que esta BAdI foi utilizada e não executará os métodos equivalentes da BAdI CL_NFE_PRINT ( FILL_HEADER e FILL_ITEM ).
Se nenhuma ativação foi encontrada e/ou nenhuma mudança ocorreu, então a BAdI CL_NFE_PRINT será chamada.
Abaixo criei um exemplo para mostrar que agora é possível implementar o método ADD_DATA da BAdI J_1BNF_ADD_DATA, verificar o NF type e baseado nisso você pode decidir se um determinado NF type utilizará a BAdI nova ou a antiga. No meu exemplo estou usando NF Type, porém nos cenários de vocês podem ser utilizados outros parâmetros.
-Exemplo utilizando o método ADD_DATA e um cenário a partir da fatura de SD via VF01:
Ao salvar a fatura o programa irá passar pela BAdI nova:
Na minha implementação do método (uma simplificação apenas para exemplo) eu adicionei um check por NF Type, desta maneira a BAdI só irá fazer a alteração do ID_DEST para as notas fiscais com NF type NE.
Após a execução do método ADD_DATA, da BAdI J_1BNF_ADD_DATA, há um método standard que verifica se houve alteração entre os parâmetros antes e depois do método ADD_DATA.
Nos casos em que houve alteração o programa preenche o campo IND_BADI_CTRL com o X.
Essa informação é persistida na tabela J_1BNFDOC para o documento que foi criado.
No meu exemplo a numeração e envio foram feitos manualmente na J1BNFE:
Neste momento o programa irá realizar o mapeamento dos dados da NFe para as estruturas que serão passadas via RFC para a mensageria.
Notem que o programa irá verificar se o campo IND_BADI_CTRL está preenchido na tabela J_1BNFDOC.
Neste momento se este campo estiver preenchido o programa irá limpar o parâmetro obj_ref.
O parâmetro obj_ref será verificado antes da execução dos métodos FILL_HEADER e FILL_ITEM da CL_NFE_PRINT. Se ele estiver vazio então o programa não entrará na execução desses métodos.
att,
Renan Correa
Muito bom o seu material Renan!!!
Estamos num projeto onde justamente estamos fazendo a mudança da BADI.
Valeu!!!
Kyono
Oi Renan
Se eu entendi uma vez que você alterar qualquer campo pela badi nova a badi antiga não será chamada! É isso mesmo?
Estou tentando ver essa alteração com a mente aberta mas confesso que não consigo entender alguém implementando essa conversão de forma parcial.
Isso tem haver com a limitação dos campos disponíveis para alteração na badi nova?
Abraço
Eduardo Chagas
Oi,
Sim, exatamente isso. Se o documento teve qualquer campo modificado pela J_1BNF_ADD_DATA os métodos FILL_HEADER e FILL_ITEM da CL_NFE_PRINT não serão chamados.
Se o cliente já tem implementações na CL_NFE_PRINT em que ele usava NF type como parâmetro para modificar ou não campos, essas mesmas regras podem ser migradas facilmente para a J_1BNF_ADD_DATA tendo como vantagem a persistência dos dados nas tabelas.
Também acho complicado migrar parcialmente, porém essa é uma flexibilização que a SAP criou para este cenário. Além disso, outro "problema" é que ter alguns cenários na BadI nova e alguns na antiga acaba por criar mais complexidade para a TI na hora de dar suporte/manutenção.
att,
Renan
Oi Renan.
Eu queria mitigar mais uma dúvida sobre o assunto. Estamos com um projeto de implementação do TDF. Nisso estamos dizendo que o EFD e o ECD agora serão no ambiente HANA e não mais no ERP. Com isso, se eu migrar todo o processo para a J_1BNF_ADD_DATA, eu já terei os campos standard mapeados de forma automática para os campos requeridos. Se eu manter parte do processo pela CL_NFE_PRINT eu terei que fazer um esforço adicional para completar os dados necessários ao EFD e ECD que a CL_NFE_PRINT não completa de forma standard correto?
Abraços
Kyono
Olá Kyono.
O TDF vai criar modelos virtuais sobre as tabelas estendidas, quer dizer, uma view HANA do C100 vai, por exemplo, ler um campo novo persistido na J_1BNFDOC.
Se esse campo não estiver preenchido o output do C100 vai ser vazio.
Para alterar esse comportamento então seria necessário esse esforço adicional que você comentou.
Então, principalmente para clientes TDF, a migração para a nova BADI é extremamente recomendada, até talvez vital.
abs
André
Oi Eduardo,
Sim. Se você utilizar a CL_NFE_PRINT para preencher/alterar informações que posteriormente são reportadas no SPED você terá que fazer ajustes no EFD e ECD para que eles reportem essas informações corretamente.
att,
Renan Correa
Olá Renan Correa,
Saindo um pouco da NT3... estamos avaliando o uso BAdI nova justamente como preparativo para o TDF.
Uma questão que surgiu foi sobre contranota de Produtor Rural. Como fazer para informar os dados da NF referenciada (NFP) sendo que a mesma não é registrada no SAP? Assim não temos o docnum e precisamos informar os dados manualmente de outra forma - isso ocorre também em casos de NF-es registradas em sistemas legados, quando precisamos fazer uma devolução (referenciada), por exemplo.
Qual a recomendação para este caso?
Obrigado,
Eduardo Hartmann
Boa tarde Renan,
Estava vendo essa material de exportação e tenho cenário e duvida aqui no cliente.
Estamos na 3,10 / Nf-e ( EHP6 ) funcionando normalmente e agora fizemos o upgrade da versão EHP6 para EHP7, agora nas nossas notas de exportação não esta aparecendo o popup na j1BNFE ao enviar a nota,
Quando enviamos fica em timeout até cair a tela, e a nota fica como não enviado status 3, você já viu esse cenário ?
Obrigado.
Renato
Boa tarde Renan,
A minha dúvida é a seguinte:
Quando eu executar o método add_data da nova badi J_1BNF_ADD_DATA,o método fill_cte_200 da badi antiga CL_NFE_PRINT continuará sendo executado,
ou a execução da badi J_1BNF_ADD_DATA anula a execução de todos os métodos da badi CL_NFE_PRINT?
Olá Eduardo.
Após várias iterações com clientes e testes dos novos layouts no SAP Labs a imensa maioria dos clientes (talvez todos) reforçaram que não poderiam mover toda a lógica e processos da BADI antiga para a nova.
Então, de forma a garantir que ela fosse usada pela maior quantidade de clientes e se adequasse aos cenários apresentados, foi incluída essa flexibilidade.
Não muda para quem consegue migrar tudo de uma vez, mas facilita para quem planeja migração parcial, win-win 😉
abs
André
Oi André.
Muito obrigado pelas suas duas respostas. Me ajudaram bastante para defender a nossa posição no projeto.
Para outros projetos onde ainda não esteja sendo realizada a implementação do TDF eu até entendo que seria uma possibilidade viável o uso compartilhado das duas BADI´s devido principalmente ao requisito de tempo de projeto, mas os consultores tem que ter em mente que se o cliente usa o SPED no ECC eles devem tomar atenção com essa parte do processo.
Obrigado pela ajuda!!!
Kyono
Olá Kyono.
Fico feliz em saber que consegui contribuir.
Mas então me permita elaborar um pouco melhor isso já que procuras por informações à serem utilizadas em decisão de projeto.
Para o caso de não persistires a informação na origem, todas soluções possíveis para contornar isso tem sérios pontos negativos no TDF:
1) Você poderia utilizar rotinas que preencham as tabelas SHADOW do sistema com a informação completa. Com isso você (a) duplica todas entradas o que necessita de mais espaço no HANA e (b) aumenta consideravelmente a carga e materialização necessária para o "merge" nas views do SPED. É praticamente inviável, a memória necessária para o processamento seria muito grande. Então as SHADOW não devem ser utilizadas para essa finalidade.
2) Você poderia construir suas próprias views, juntando informação da view da SAP com alguma outra fonte de dados replicada no HANA. Aqui você (a) pode ter problema de performance e memória por um filtro de dados não descer até a fonte, ter todo um trabalho de avaliação/otimização e (b) precisar adaptar suas views para correções, alterações legais e suporte a múltiplas versões de layout.
3) Você pode complementar as tabelas do próprio esquema replicado no HANA mas isso (a) pode ser perdido quando algum delta de documento é enviado pela SLT e (b) com certeza vai ser perdido se você reiniciar a SLT.
Quer dizer, para o TDF, o uso da nova BADI é praticamente a única solução viável já que ela não possui nenhum dos pontos negativos que citei. É também a única recomendada, todas as outras tem um TCO muito maior que um projeto de migração da BADI antiga pra nova.
abs
André
Oi Andre
(minha opinião) Pra mim faria sentido se você pudesse usar as duas simultaneamente, ou seja o que uma altera a outra sobre-escreve. Ou então, se o controle fosse por campo, por exemplo se atualizou o campo XYZ pela add_data o mesmo não será mais alterado pelo fill_header mas os demais sim.
Já vi clientes com cerca de 2600 linhas de código na cl_nfe_print em um dos métodos somente!
Abraço
Eduardo
Olá Eduardo.
De forma simplificada:
A ideia da persistência é ter o dado como enviado no XML, então habilitar as 2 BADIs ao mesmo tempo não me garante a consistência da informação.
O mesmo problema vale para ter o dado parcial na persistência.
Trabalhar com as 2 BADIs, mesmo que independentes, é uma facilitação da migração, exatamente pelo complexidade que você mencionou, não deveria ser a solução de longo prazo. Por isso também não tornar a flexibilização mais complexa de ser criada e mantida, através de controle por campo, por exemplo.
Nessa linha também que não restringimos o uso de uma ou outra badi por algum parâmetro, como customizar por nftype qual BADI usar, fica a critério e flexível dentro de desenvolvimento das BADIs.
A decisão foi nessa direção.
abs
André
Renan
Somente não entendi como você fez para a CL_NFE_PRINT ignorar o fato da J_1BNF_ADD_DATA já ter sido usada e portanto o campo IND_BADI_CTRL estar marcado com um X no registro que está sendo processado.
Abs
Marcos
Oi Marcos.
Na verdade não é ignorado. O que acontece: primeiro quando você está criando o documento de faturamento o sistema passa pela BAdI J_1NF_ADD_DATA. Se não ocorrer nenhuma alteração de dado pela J_1BNF_ADD_DATA o sistema passa pela CL_NFE_PRINT (se ela estiver ativa) e; consequentemente pelos métodos FILL_ITEM e FILL_HEADER. Se você deseja usar a BAdI nova somente para determinado cenário, então no começo da sua implementação da BAdI nova você coloca a sua regra para ignorar a mesma.
Abraços
Kyono
Kyono
Obrigado. Na verdade eu tinha interpretado o texto erroneamente. Tinha entendido que era possível complementar os dados na NFe com as duas opções ao mesmo tempo, mas na verdade você só pode usar a CL_NFE_PRINT se não tiver feita nenhuma alteração pela BADI.
Olá Renan,
Parabéns pelo post! Excelente.
Estou com uma dúvida, hoje utilizamos a BADI CL_NFE_PRINT, porém, gostaria de usar a BADI persistência para popular alguns campos de exportação que foram liberados na J_1BNFDOC. Eu consigo utilizar as duas BADIs? Minha intenção neste caso era usar a persistência apenas para estes campos de exportação e continuar utilizando a CL_NFE_PRINT para as demais regras deste processo.
Muito Obrigada
Cristina
Olá Cristina,
O standard não permite, pois tem o controle de que se a nota foi alterada pela BAdI ADD_DATA ela não será alterada pela CL_NFE_PRINT.
Porém, se você tem certeza de que os dados alterados pela ADD_DATA não serão sobrescritos pela CL_NFE_PRINT, você pode fazer um "controle específico" (via enhancement, preferencialmente) fazendo com que a nota sempre passe na CL_NFE_PRINT mesmo tendo passado na ADD_DATA para tratar a parte de exportação que você deseja.
Lembre que seguir nessa linha não é o ideal e pode introduzir dificuldades de identificação de problemas... como é desvio do standard, fica por sua conta e risco.
abs,
Eduardo Hartmann
Olá Eduardo,
Muito obrigada pelo seu retorno. Irei avaliar se consigo alguma outra alternativa para enviar estes dados de exportação, neste momento não conseguimos migrar para a ADD_DATA, usar as duas seria o ideal, mas como destacou este risco, prefiro seguir pelo recomendado.
Abs
Cristina
Olá!
Estou fazendo um trabalho para ativar a nova Badi J_1BNF_ADD_DATA em função da atualização da NF-e 4.0.
Todas as notas SAP, referente a criação da Badi J_1BNF_ADD_DATA foram aplicadas e transportadas para o ambiente Produtivo em 2015/2016. Porém até o momento ainda estávamos usando os métodos FILL_HEADER e FILL_ITEM da Badi CL_NFE_PRINT.
Ao debugar a VF01, não está caindo no ponto de parada CALL BADI bd_j_1bnf_add_data->add_data (linha 151 da include LJ1BGF06).
Também não consegui achar quais são os programas/classes que possam chamar o FORM badi_fill_additional_fields.
Alguém sabe me dizer se precisa se ativado algo a mais?
Ou se tem alguma outra forma de fazer a chamada do método IF_J_1BNF_ADD_DATA~ADD_DATA.
No meu cenário atual está seguindo a sequencia:
Executando o programa: J_BNFECALLRFC. Dentro da rotina: NOTA_FISCAL_SEND é chamada a função: J_1B_NF_MAP_TO_XML. Dentro da função é chamada a rotina: BLOCK_H, onde é realizado um loop na tabela interna WK_ITEM, e chama outra rotina: CALL_BADI_ITEM, que chama os métodos abaixo:
Desde já obrigado pela atenção!
[]s
Identifiquei que ao aplicarem a Nota SAP: 1860360 ocorreu algum erro, ou a nota estava incompleta (ou algo do gênero) onde na Include: LJ1BGF02 faltou a instrução:
PERFORM badi_fill_additional_fields TABLES xt_vbfa. “184462
Após inserir a linha, começou a passar no
FORM badi_fill_additional_fields da Include: LJ1BGF06, onde executa:
CALL BADI bd_j_1bnf_add_data->add_data, para o tipo de documento BI.
Abraços!
Boa tarde Renan, tudo bem?
Não encontrei na nova BAdI o método para determinar o e-mail do BP vinculado ao processo (grupo de dados do destinatário).
Poderia me auxiliar?
Obrigado!
Lucas.
Boa Tarde
Como faço para não enviar a TAG -<comb> , visto que na nossa empresa não vendemos combustível mas todas as notas que geramos a tag -<comb> esta sendo criada com isso esta dando erro na sefaz.
Esta gerando assim . E queria tirar essa TAG COMB
-<comb>
<cProdANP>000000000</cProdANP>
<descANP/>
<UFCons/>
</comb>
Muito obrigado.
Atc.
Parabens pelo Post!