NFE 2.0 - XML_ADI - XML_IMP

[Former Member]

Olá Kátia,

Os dados de importação são salvos nas tabelas J_1BNFIMPORT_DI e J_1BNFIMPORT_ADI.

Os dados de origem para você gravar nas estruturas XM_IMP e XML_ADI são dessas tabelas?

Como você está fazendo para buscar essas informações?

Você está fazendo essas atualizações na BADI CL_NFE_PRINT?

Hoje estou gravando os dados OUT_IMP e OUT_AD, buscando os dados de outra origem mas gostaria de pegar da origem standard, mas não estou conseguindo localizar de onde buscar em tempo de execução/criação da NFe.

Agradeceria a ajuda.

Muito obrigado.

André Vilela.

[henrique_pinto · Accepted solution]

O SAP ERP não transnaciona dados de importação no standard.

Ou é desenvolvimento Z ou solução complementar.

BTW: separei sua pergunta em uma nova thread, pois aquela outra era muito antiga (antes de 2010).

Abs,

Henrique.

[eduardohartmann · Accepted solution]

Henrique,

Acho que o André (Dulcimar? ) refere-se à solução dos dados de importação disponibilidada pela Note 1598222 - BR: Integrate Import Tags DI and ADI in NF Writer.

abs

Eduardo

[henrique_pinto · Accepted solution]

Essas são as tabelas que ele mencionou. Mas a origem dos dados ou é manual (writer) ou vindo de tabela Z ou de solução complementar.

[Former Member · Accepted solution]

Bom dia Henrique.

Quando fazemos as notas de importação, elas são writer e temos uma solução Z.

Porém, existe a possibilidade de se preencher essas tabelas standard na aba "Docs.Importação" e ao digitar os dados nessa aba, são gravados nas tabelas mencionadas acima.

A minha pergunta é se seria possível utilizar os dados lançados nessa tabela e gravados nas tabelas do XML durante a execução da BADI de criação do XML.

Esses dados podem ser visíveis ou extraídos de algum lugar da mémoria ou tabela interna?

Muito Obrigado,

André Vilela

(é André mesmo Eduardo. Esse logon é da empresa e a Dulcimar que o representa.)

[henrique_pinto · Accepted solution]

Oi André,

em tempo de execução da BAdI, você deveria já enxergar esses dados na tabela.

A menos que você até hoje não tenha o Decouple ativado.

O ideal seria manter com 1, 2 ou 3. Dê uma verificada no valor do campo CALLRFC na J1BNFE (J_1BNFE_ACTIVE).

[Former Member · Accepted solution]

Bom dia Henrique,

Ele está inativo, este campo está em branco.

Você poderia me dizer do que se trata o decouple?

Eu li algumas informações a respeito, mas não consegui entender realmente qual é a função dele.

Se estiver inativo estarei tendo problemas no meu sistema de NFe?

Obrigado,

Andre Vilela

[Former Member · Accepted solution]

Henrique boa tarde,

Eu já havia verificado as implementações necessárias na nota a serem feitas para o decouple.

Todos os objetos já estão criados.

Pela explicação que tem no anexo da nota, a implementação do decouple seria para corrigir problemas com numeração, delay, validações, etc...

Seria isso mesmo?

Eu ativei o RFC Call com as 3 opções (1/2/3) e testei o seu funcionamento.

Acredito que entendi o funcionamento dessa implementação.

Seria criar o documento fiscal primeiro e depois num segundo momento via J1BNFE (opção 1) ou via programa J_BNFECALLRFC online ou job. (opção 2/3), gravar o número da nota fiscal e executar a RFC que envia a nota para o GRC.

Como não tivemos problemas desses tipos, não vi tanta necessidade de se ativar o decouple.

Entendi agora como eu pegaria os dados de importação, uma vez que as tabelas já estão atualizadas no banco de dados, o seu acesso seria direto, seria isso que você tentou me explicar?

Exceto essa situação do decouple, não há como buscar esses dados de memória durante o processamento, como demais dados que são gravados no XML?

Se não for nada disso, por favor, queira me corrigir.

Obrigado,

Andre Vilela

[henrique_pinto · Accepted solution]

Olá André,

desculpe a demora.

Sim, o decouple veio "desacoplar" a criação da NFe (banco de dados) do momento do envio da NFe para o sistema de mensageria (RFC Destination). O problema mais frequente era de fato gaps de numeracao, mas outros mais criticos tb existiam: no pior caso, uma NFe poderia ser enviada pra SEFAZ, aprovada e nem mesmo ter sido gravada no seu banco de dados (se tivesse dado um dump por exemplo, e o ERP feito um rollback). O conceito principal vc entendeu (ou vc numera e envia manualmente, ou numera manualmente e envia via job, ou envia e numera via job - callrfc 1, 2 ou 3).

Os clientes iniciais do cenário de NFe no SAP ERP enfrentavam vários problemas desse tipo, e daí o decouple foi criado para evitá-los. Estranho você ainda não tê-lo ativado - há um tempo, o Suporte da SAP fez uma iniciativa pra que todos os clientes que ainda não ativessem ativado o decouple o fizessem. Até a um tempo atrás, se você abrisse um chamado e não tivesse o decouple ativado (e o consultor do suporte notasse isso), eles não continuariam o suporte enquanto você não ativasse.

Com relacao a de onde ler os dados na BAdI, o ideal é usar os dados das tabelas, porque se o envio para (e.g. falha de validacao) e você tentar reenviar, se você tiver tentando ler da memória, esse código vai falhar (ou pior, enviar dados diferentes/incosistentes), e daí vc vai ter q fazer um tratamento pra ler dos dois lugares (memoria e DB) anyway, um pro envio inicial, um pros reenvios.

Se ainda assim você quiser manter o modelo de ler dados em memória, eu infelizmente não vou poder ajudar muito, pois não sou um desenvolvedor ABAP. Mas se você fizer uma busca no SCN por "dados badi nfe memoria" ou algo assim, vai ver q a grande maioria das respostas passam por indicar o decouple. 😉

[Former Member · Accepted solution]

Bom dia Henrique,

Agora ficou bem mais claro. Eu achei que fosse algo mais complicado a nível de processo e customização.

Após os objetos criados a ativação do decouple é bem simples.

Vamos analisar o nosso cenário e ver como utilizaremos o decouple.

Já consegui utilizar as informações de importação buscando do banco de dados com o decouple ativo.

Muito obrigado pelos esclarecimentos.

André Vilela.