Dúvidas - Funcionalidades de um Sistema de Mensageria NON-SAP(GRC)

Bom dia pessoal, tudo bom?
Gostaria de saber da experiência do pessoal sobre as funcionalidades de um Sistema de Mensageria Não-GRC.
Como funciona?
Que tipo de RFC deve ser criada, inclusive até criei um Tópico().
Por exemplo, em especial, deve-se chamar uma função específica, como exemplo: J_1B_NFE_XML_OUT?
Ou não fará diferença, já que ele utilizará o Call_xi. Como fica a chamada da /XNFE/NFE_CREATE?
Desculpe tantas perguntas, caso seja necessário abrir outro tópico, só avisar.
Att,
Léo.

Leonardo,
as interfaces entregues pelo SAP ERP para a integracao com mensagerias de terceiros sao as RFCs J_1B_NFE_XML_OUT (saída) e J_1B_NFE_XML_IN_TAB (retorno). Na verdade existem outras (inutilizacao de gaps, retorno da inutilizacao de gaps, pedido de reenvio, contingencia etc) mas essas sao as principais.
O fato de o form chamar call_xi nao quer dizer nada. Esse nome foi dado pq nos pilotos a ferramenta de integracao sempre era o XI. Mas pode ser JCo tb. O ideal é buscar no SDN por mais detalhes dessa comunicacao, pois nao há nada especifico de NFe no processo, é um cenario RFC (inbound e outbound) comum.
Abs,
Henrique.

Similar Messages

Criação RFC - Sistema de Mensageria Non SAP

FAla, pessoALL, tudo bom com vcs?
Estamos já com alguns clientes de NF-e, e estamos agora no nosso 1º cliente a não usar GRC. Eles utilizarão um Sist. de Mensageria não-sap.
E precisamos criar a RFC para esse Sistema, já que a comunicação será via RFC, pois eles utilizarão JCO para isso.
Daí vem a pergunta, que tipo de RFC devo criar, tem alguma coisa específica para fazer?
Fernando, me adiantou alguns links sobre isso, mas ainda tenho minhas dúvidas.
Type = TCP/IP (sei que deve ser usado esse tipo)
Activation Tye = Registered Server Program;
PogramID = O que eu coloco aqui? O programa que o SAP vai utilizar para criar nf-e(j_1b_nfe_xml_out?) Ou o programa que o cliente vai utilizar(ex: /xnfe/create)???
Gteway Hst = Aqui coloco o gateway onde o Sist. Mensageria será instalado
Gteway Srvice = Aqui coloco o gateway onde o Sist. Mensageria será instalado
Alguém pode me ajudar?
Att,
Léo.

Pessoal, alguém sabe me dizer ou conhece alguém que possa me ajudar?

Al tentativo di istallare boot camp il sistema risponde che non è possibile per un problema del network: che significa ?

Al tentativo di istallare boot camp il sistema risponde che non è possibile per un problema del network: che significa ?

Ciao Uno promo,
Lei escritto e linguale Engletare UK.
Dimaxum

Ativar SCAN com solução de mensageria não GRC

Pessoal bom dia,
Estou em um projeto e o cliente deseja utilizar a contingência da NF-e com o SCAN, porém a mensageria é uma solução de mercado, não é o GRC. Vocês sabem o que fazer para ativar o SCAN quando a mensageria não é o GRC. A comunicação entre o SAP e a solução de mensageria ocorre, no envio, por arquivos texto. Somente o retorno para o SAP ocorre por RFC.
Qualquer dica será bem vinda, desde já agradeço!
Assis Medeiros

Olá a todos!
Nossa instalação tenta combinar o SAP ERP com a mensageria não ERP. Na verdade nem sempre combinam bem, mas dá samba. Para funcionar o SCAN, conforme a dica do Fernando, aplicamos a seguinte solução:
Ao assinalar o campo u201CDeterm.aut.servd.u201D no Local de Negócio (customizing), o SAP automaticamente consultará se é SEFAZ ou SCAN que está ativo, através do método GET_SERVER da implementação da BAdI CL_NFE_PRINT
Neste método, a tabela CT_SERVER_CHECK contem os campos SEFAZ_ACTIVE e SCAN_ACTIVE. Apenas um destes campos de ser assinalado com X. Para cada campo o SAP definirá o formulário a ser utilizado ao fazer a numeração da Nfe, se para SEFAZ ou SCAN, conforme customizing.
Dentro do método GET_SERVER pode-se consultar uma tabela Z que indica quem está ativo, se SCAN ou SEFAZ, assinalando o campo correspondente da tabela CT_SERVER_CHECK.
Uma alternativa automática para saber qual serviço está ativo é consumir via PI o WS do Sefaz que indica o serviço que está ativo.
Valeu Fernando.
Espero ajudar quem está passando por aqui.
Abçs
Heron Caetano
www.hcaetano.blogspot.com

Dúvida no fluxo do processo de rejeição/recusa

Bom dia, pessoal,
Embora tenha participado de alguns projetos de nota fiscal eletrônica, uma coisa nunca ficou muito clara para mim. Estou em um novo projeto agora e eu queria fazer da melhor forma possível.
A primeira dúvida é sobre Recusa/Rejeição. Basicamente qual a diferença entre os dois? Eu sempre entendi que uma nota é rejeitada pela SEFAZ, e recusada pela validação do GRC ou do outro sistema de mensageria. Essa abordagem está correta?
A segunda dúvida é sobre essa mesma validação. Quando o GRC, ou outro sistema encontra erros de sintaxe do arquivo, ou de qualquer informação, qual deve ser o status dessa nota? Ela deve ficar como recusada? E o status de comunicação do sistema?
Quando uma nota fiscal está recusada, qual o melhor fluxo? Considerando que o erro foi apontado pelo sistema de mensageria e não pela SEFAZ, a nota fiscal não pode ser cancelada. O sistema também não permite o estorno da nota, nem mesmo depois de resetar seu status . Uma vez eu debuguei e vi que é porque ela está numerada.
Meu último problema é sobre inutilização. Alem do report, existe alguma outra forma de fazer a inutilização, direto pelo monitor? Penso em fazer isso justamente quando uma nota está recusada/rejeitada sem ter ido para o SEFAZ. Daí usaríamos a própria entrada dela, no monitor, para solicitar a inutilização da numeração.
É Isso...
Obrigado,
Fernando Fussi

Bom dia Fernando,
Esta dúvida é comum principalmente que boa parte dos projetos (no início) não fez a implementação de NF-e por Support Package mas por aplicação de notas, então os termos originais Rejected and Denied foram traduzidos de forma diferente em cada projeto (a SAP só entrega traduções por SP), isso deu margem a boa confusão no tema.
A primeira dúvida é sobre Recusa/Rejeição. Basicamente qual a diferença entre os dois?
Existe rejeição (2xx, 4xx,999) e denegação (301 / 302)
- Na rejeição a Sefaz rejeita por algum dado incorreto e não deixa salvo no banco de dados dela, você deve tentar corrigir e enviar quantas vezes necessário
- Na denegação é uma situação específica que o emissor ou o destinatário estão com irregularidade fiscal junto à Receita, neste caso a NF-e é armazenada na base da Sefaz e não deve ser novamente enviada (o ERP ao receber a denegação dispara o cancelamento automaticamente)
Eu sempre entendi que uma nota é rejeitada pela SEFAZ, e recusada pela validação do GRC ou do outro sistema de mensageria. Essa abordagem está correta?
- Sim, a rejeição da validação é devido a algo que provocaria uma rejeição da Sefaz se enviado você também pode tentar acertar até passar pelo validador/Sefaz
A segunda dúvida é sobre essa mesma validação. Quando o GRC, ou outro sistema encontra erros de sintaxe do arquivo, ou de qualquer informação, qual deve ser o status dessa nota?Ela deve ficar como recusada? E o status de comunicação do sistema?
- Sim, rejeitado pelo validador MSS=V DOCSTAT=vazio (o ERP não considera que a rejeição do validador tem peso igual a validação da Sefaz, porém pro processo é a mesma coisa que no ERP tem status específicos)
Veja detalhes sobre status e situações aqui:
Status do SAP Nota Fiscal Eletrônica (ERP x GRC x PI)
ou em inglês:
NF-e Status on SAP Nota Fiscal Electronica Solution (ERP x GRC x PI)
Quando uma nota fiscal está recusada, qual o melhor fluxo? Considerando que o erro foi apontado pelo sistema de mensageria e não pela SEFAZ
- Em linhas gerais o fluxo básico seria RESET + tentar corrigir o que o GRC ou a Sefaz informaram + NF-e -> Send
, a nota fiscal não pode ser cancelada. O sistema também não permite o estorno da nota, nem mesmo depois de resetar seu status . Uma vez eu debuguei e vi que é porque ela está numerada.
- Em um ERP e GRC corretamente atualizado com os SP's e notas isso não é normal em cada caso a causa raiz deve ser encontrada e sanada com notas ou chamado à SAP
Meu último problema é sobre inutilização. Alem do report, existe alguma outra forma de fazer a inutilização, direto pelo monitor?
- Que report? O de encontrar gaps? Este report é para sanar um side effect quando os clientes não implementaram ainda o decouple. Hoje em dia todos os clientes devem implementar o decouple job para evitar vários transtornos como (gaps (já não dá mais medo), NF-e autorizada no GRC/Sefaz e não existe no ERP (isso é terrível), inconsistência de transmissão (dados obtidos em memória X dados obtidos do banco)....
- Inutilização é direto no monitor, que situação está descrevendo?
Penso em fazer isso justamente quando uma nota está recusada/rejeitada sem ter ido para o SEFAZ. Daí usaríamos a própria entrada dela, no monitor, para solicitar a inutilização da numeração.
- não entendi. Hoje uma nota Rejected seja pela Sefaz ou pelo validador deve ser cancelada pelo monitor J1BNFE. Entendi errado sua pergunta?
- Existe também uma nova funcionalidade "Cancel Prior Authorization" que permite o cancelamento de uma NF-e antes mesmo dela ter sido numerada
Atenciosamente, Fernando Da Ró

Dúvida no cancelamento de uma NFe Rejeitada

Boa tarde a todos,
Estou com uma dúvida quanto ao processo de cancelamento de uma NFe rejeitada e agradeço antecipadamente a colaboração dos colegas aqui do forum que possam ter passado por situação semelhante.
Temos o seguinte cenário: implementação SAP ECC 6.0 (SP13), já foram aplicadas uma série de notas dos SP14, SP15 e SP16 para resolver outros problemas que surgiram ao longo do projeto. O sistema de mensageria não é o GRC SAP, o cliente optou pela solução da Mastersaf.
O problema ocorre quando o usuário cancela uma NFe (opção "Solicitar Estorno") que está rejeitada pela validação da mensageria (NFe sem CPF do cliente, por exemplo). Como esta NFe não foi enviada à SEFAZ, o sistema interpreta o cancelamento como uma inutilização de número. Até este ponto tudo perfeito, o procedimento é correto, segundo nosso entendimento. O problema é que ao consultar a inutilização, tanto no sistema Mastersaf quanto na SEFAZ, o número inutilizado foi o número aleatório (DOCNUM9) e não o número da NFe (NFENUM).
Debugando a rotina, descobrimos que o "problema" está no módulo de função J_1B_NFE_SEND_REQUESTS, onde há uma linha onde a rotina move o número aleatório para a estrutura que irá gerar o XML para a mensageria ("xmlh-nnf = ls_acttab-docnum9.").
A pergunta é se isso está correto ou se é um bug da função? Procurei por alguma nota OSS que tratasse isso mas não encontrei nada.
Vocês já se depararam com essa situação?
Um abraço,
Rinaldo Conte

Bom dia Rinaldo,
Talvez este problema esteja limitado ao R/3 NFe x MasterSAF. Como a interface chamada é a de inutilização, entende-se que já ocorreu uma tentativa de envio ( o que envia o NNF corretamente ). Então ao solicitar a inutilização a mensageria poderia partir deste NNF correto para proceder a inutilização.
De qualquer forma, parece que você encontrou um bug no envio de dados à interface de inutilização.
Discuta este ponto com o fornecedor da mensageria, pode ser necessário abrir chamado à SAP para modificação.
Atenciosamente,
Fernando Da Ró

Inutilização de NFe - J_1BNFE_OUTNFE_CREATE - Mensageria não-sap

Olá pessoal!
Preciso esclarecer uma dúvida:
A SAP disponibilizou a função J_1BNFE_OUTNFE_CREATE para fazer interface com sistemas de mensageria não-sap, para o layout 3.10.
Dúvida:
Nessa função, como eu faço para identificar que a ação do usuário foi uma solicitação de inutilização da nfe e não a solicitação de autorização? Não encontrei nenhum parâmetro que me diga isso.
Na versão 2.0 era utilizada a função J_1B_NFE_XML_OUT, que com a combinação dos parâmetros XML_IN-DOCSTAT, XML_IN-SCSSTAT e XML_IN-TPEMIS era possível determinar qual era a ação a ser realizada (solicitar aprovação, cancelamento [ quando ainda não era por evento] , inutilização...)
Me parece que falta algum parâmetro na nova função que nos diga qual foi a ação realizada...
Notei que para casos de inutilização o parametro IS_NFE_IDE-TP_EMIS, e alguns outros, ficam em branco. Mas não achei seguro fazer a validação dessa forma.
Será que existe alguma nota que corrige isso? procurei, mas não encontrei.
Enfim, agradeço por qualquer ajuda.
Abraços!

Oi,
A diferença entre a autorização e a inutilização pode ser identificada pelos parâmetros em branco. Na solicitação de autorização as estruturas com dados de produto/impostos/destinatário estão preenchidas, na inutilização elas estão em branco.
Além disso algumas informações de header da nota estarão em branco na inutilização, como por exemplo o tpemis.
Acredito que independente da mensageria é possível que eles mapeiem os dados usando essas diferenças como parâmetros para identificação.
att,
Renan

Local onde é gerado o XML, R/3 ou PI ou Mensageria ?

Bom dia pessoal,
Estou lutando para entender onde é gerado o XML quando usa-se o R/3 e o GRC e caso optemos por usar sistema de mensageria externo, o XML é gerado no R/3 ou fora do R/3 para envio ao legado de mensageria ?
Quais funções são usadas no R/3 para gerar o XML , além da BADI ?
grato,
Alessandro

Bom dia Carlos,
se vc for usar um que precise de um arquivo XML, sugiro que vc customize a BADI CL_NFE_PRINT para que ao inves de enviar ao GRC ele gere um arquivo com os dados que vc necessite que não necessariamente precisa ser no ofrmato XML, a vantagem de usar XML é que os dados ficam mais organizado ao inves de virar uma tripa de caracteres com varias linhas por exemplo.
Você pode até fazer funcionar por aí mas não é o ponto de disparo.
O ERP irá sempre chamar a J_1B_NFE_XML_OUT que é uma casca e recebe todos os dados, iguais ao que o GRC recebe.
Este é o ponto correto.
Se esta mensageria de terceiro basear-se no PI, então basta importar a RFC J_1B_NFE_XML_OUT no PI daí todos os dados estarão disponiveis automaticamente.
Em não sendo possível fazer a ligação, o consultor tem a opção de fazer um enhancement implicito nesta função no ERP, fazendo a ponte dos dados conforme você comentou (gravar em arquivo, por exemplo).
Atenciosamente, Fernando Da Rós
PS: Alessandro, apesar do nome esta função não gera, nem passa XML... ele recebe dados e seria onde na mensageria o XML tem a chance de gerar o XML.

Momento de envio do XML

Boa tarde,
Estou em um projeto de implementação e com a seguinte dúvida:
Requerimentos:
Tenho que enviar o XML assim que a Invoice+NF é gerada (VF01/VF04, etc).
Num segundo momento, após a aprovação do XML, eu poderei imprimir a DANFe.
Envio XML:
Sei que a função que mapeia o XML para a versão 2.0 é a J_1B_NF_MAP_TO_XML e a função que envia para o GRC ou outra mensageria (utilizaremos NeoGrid) é a J_1B_NFE_XML_OUT.
A pergunta é: como faço a chamada destas funções? Qual programa devo chamar? Em qual momento? É por customizing ou por uma exit no faturamento?
Obs.: entendo que estas funções já estão configuradas no monitor J1BNFE para solicitar o reenvio da nota, etc.
Impressão DANFe:
Em paralelo, na J1BJ vou ter que configurar somente o programa de impressão do DANFe (J_1BNFPR), correto? Pois assim quando eu gerar e processar o output da NAST ele irá fazer a impressão do documento, correto?
Caso não entendam as perguntas por favor me contestem que eu explico melhor.
Obrigado!
Felipe Brasil Simioni

Olá, Fernando.
Por favor veja se pode nos ajudar.
Estamos tendo o mesmo problema com o envio do XML para a mensageria (não GRC).
Seguindo as parametrizações indicadas acima:
SPRO
   Componentes válidos para várias aplicações
     Funções gerais de aplicação
       Nota Fiscal
         Saída
           Atribuir parametros de numeração e dxed impressão
O local de negócios está configurado como RFC CALL vazio (segue descrição abaixo):
"Execução RFC e atualização banco dados na mesma LUW (padrão)"
Porém, ao tentar enviar a nota fiscal (ex: J1B1N), ocorre um erro na SM58 e o XML não é enviado para o sistema de mensageria.
Analisando o programa SAPLJ_1B_NFE, no include LJ_1B_NFEF42, vemos que para mensagerias não GRC o programa chama a função J_1B_NFE_XML_OUT em background task, o que ocasiona o erro abaixo na SM58.
IF sy-subrc IS INITIAL.
non SAP messaging system                          "V1.10
    if lv_xnfeactive is initial.                    "V1.10
Call function asych. when RFC connection available
gv_callmode can be switched in debbuging to call the RFC synchronous
do not reset gv_callmode direct after the RFC call
      if gv_callmode is initial.
        CALL FUNCTION 'J_1B_NFE_XML_OUT'
IN BACKGROUND TASK
          DESTINATION lv_rfcdest
          EXPORTING
            xml_in                = xmlh
            xml_item_tab          = xmli_tab
            xml_batch             = xmlb_tab
            xml_ref               = xmlr_tab
            xml_dup               = xmld_tab
            xml_vol               = xmlv_tab
            xml_head_tab          = xmlh_tab          "V1.10
            xml_imp               = xml_import_tab    "V1.10
            xml_ext1              = xml_ext1_tab      "V1.10
            xml_ext2              = xml_ext2_tab      "V1.10
            xml_adi               = xml_adi_tab       "V2.00
            xml_reb               = xml_reb_tab       "V2.00
            xml_cane_dia          = xml_cane_dia_tab "V2.00
            xml_cane_ded          = xml_cane_ded_tab. "V2.00
Erro da SM58:
      RfcAbort: Cannot lock transaction
      Nº mensagem SR053
Note que a chamada é feita de forma assincrona porque a variável gv_callmode está como initial, e que segundo o comentário da SAP, essa variável é usada somente para debug, sem qualquer parametrização que controle o modo de chamada.
Obs: se comentarmos a linha IN BACKGROUND TASK, tudo funciona perfeitamente.
Mas obviamente não é o que queremos fazer. Queremos manter o programa original da SAP.
Já pesquisamos notas para esse problema, mas não encontramos nada que se refira a esse problema.
Alguém mais se deparou com essa situação?
Desde já agradeço pela ajuda.
Rodrigo Ferreira

Novo contato para o produto SAP NFE

Caros,
estou colocando esta informação aqui pois ainda existem muitas mensagens e e-mails direcionados/nomeados a mim, com dúvidas sobre escopo e prazos de liberação de funcionalidades do produto SAP GRC NFE.
Como é de conhecimento de alguns, desde 1o de Julho eu saí da área de Localização para perseguir novos desafios na SAP (clichezão, rs) e portanto deixei de ser Product Manager para o NFE. Ainda estou ajudando o pessoal temporariamente num caráter de phase out, mas já não estou mais me envolvendo diretamente em novos tópicos. Meu último "grande" projeto foi a liberação do Layout 2.00.
Contudo, como construímos ao longo dos últimos 3 anos um excelente canal de comunicação (sem trocadilhos ) aqui no fórum, conseguindo trazer de forma mais ágil informações da SAP para a comunidade e vice-versa também, eu não queria deixar isso se perder. Por isso, estou anunciando aqui que a partir de agora, o The specified item was not found. é o novo product manager responsável pelo produto SAP NFE. Ele é partir de agora o ponto de contato para informações sobre prazos, funcionalidades etc., incluindo a próxima versão SAP NFE 10.0 que fará a automação de NFes de entrada. O Bruno tem 5+ anos de experiência na SAP, era responsável no suporte por assuntos de localização, incluindo NF-e e SPED, e com certeza vai ajudar bastante o time. Boa sorte ao Bruno nas novas tarefas!
O The specified item was not found. continua como responsável pelo suporte do produto.
Eu continuarei ainda participando aqui do fórum, sempre que possível, colaborando e compartilhando os conhecimentos adquiridos ao longo desse tempo. Apenas não serei mais a pessoa que poderá falar oficialmente de prazos, escopo de novas funcionalidades etc. Mas no que for possível, continuarei ajudando.
Abraços,
Henrique.

Bom dia Henrique,
Não sei por onde começo mas tenho vários Parabéns para você.
Começando pelo esforço em criar a mensageria para nota fiscal eletrônica da SAP um produto reconhecido pela qualidade, escalabilidade e coerência em seus códigos, comportamentos desde os tempos de Projeto Piloto, passando pelo Acelerador e finalmente o SAP GRC NFE e todos os SP's, ENCATES e SEFAZES no meio do caminho.
Também pelo seu esforço pessoal aqui no SCN, dedicando várias horas livres a criar e dar VIDA a este espaço para nós da comunidade de profissionais em SAP no Brasil nos encontramos e trocarmos idéias seja sobre erros, dúvidas, medos de projeto, problemas comuns entre Sefazes..rsss
E claro pelas excelentes discussões que tivemos, aprendi muito contigo.
Sucesso na nova empreitada, e sempre possível dê uma passadinha por aqui.
Muito Obrigado por tudo.
Atenciosamente, Fernando Da Ró

Ajuda com primeira implementação NFe - ABAP

Bom dia pessoal. Estou participando da primeira implementação de NFe e preciso de uma ajuda para entender melhor. Conversando aqui tenho as informações:
-O sistema que fará o envio e retorno do SEFAZ será o SYNCRO
-Minha parte abap será criar e receber os arquivos em XML em uma pasta no servidor a ser definida.
Minha duvida é:
1-Eu sei efetuar download d arquivos, mas onde que eu faria essa codificação para gerar o arquivo e guardar em uma pasta?
2-No retorno, eu teria que fazer um programa para ler os dados e atualizar no SAP? Como é feito o update no SAP?
Muito obrigado pela ajuda!

Fala Fulvio, blz?
Visto que o sistema de mensageria que você utilizará não é o SAP GRC NFE, você pode fazer a geração do XML via enhancement no módulo de função J_1B_NFE_XML_OUT. Isto pode ser realizado dentro do subprograma CALL_XI que é o responsável por chamar o sistema de mensageria.
O retorno dos sistemas de mensageria para o ERP são realizados através do módulo de função J_1B_NFE_XML_IN_TAB / J_1B_NFE_XML_IN. Através deste módulo de função é retornado o status de processamento da SEFAZ e também o status para que o ERP processe esta nota (realizando o estorno do processo em caso de cancelamento, por exemplo).
Para retornar as informações para o ERP, você pode gerar um job que lê os retornos em um diretório e então chama a função J_1B_NFE_XML_IN_TAB, por exemplo.
At.
David

Entrada da NFe no ERP e arquivamento do XML.

Prezados, bom dia.
Tenho algumas dúvidas que gostaria de dividir com vcs. Alguém saberia responder?
Processo de Entrada de Nfe no ERP (manual)
1.) Quando da entrada de dados da DANFE no ERP (MIGOMIRO), este envia alguma informação pro GRC? Em que momento é validada a DANFE?
2.) Se sim, em que formato são armazenados os dados da NFe no GRC?
Recebimento do arquivo XML do fornecedor
1.) Há alguma consistência entre o XML (recebido do fornecedor) armazenado no GRC e os dados inseridos no ERP (com base na DANFE recebida)?
2.) De quem é a obrigatoriedade em armazenar o XML? Fornecedor, empresa que recebe, SEFAZ, Receita Federal, etc? As informações armazenadas são as mesmas? Por qual período os dados devem permanecer guardados?
Obrigado por qualquer ajudar.
Hyalen.

Obrigado David e Henrique. As respostas ajudaram bastante.
Formatei a discussão em Perguntas e Respostas para facilitar o entendimento.
1- Pergunta:
Quando da entrada de dados da DANFE no ERP, este envia alguma informação pro GRC? Em que momento é validada a DANFE?
Resposta:
Atualmente, quando você entra com as informações da DANFE através do MIRO/MIGO nenhuma informação é enviada ao SAP GRC NFe, logo nenhuma validação destas informações é realizada junto a SEFAZ.
2- Pergunta:
Uma parte do processo de NFe é dar entrada da mercadoria no ERP. O que acontece se eu digitar as informações de recebimento, em relação ao XML armazenado, errada no ERP? Há alguma consistência entre o XML armazenado no GRC e os dados inseridos no ERP?
Resposta:
Quando você receber o XML de um emissor de NF-e através do cenário de B2B do SAP GRC NFe, esta nota será consultada pelo SAP GRC NFe junto ao site da SEFAZ e será armazenada no SAP GRC NFe (dentro do repositório do SPRO), mas nenhuma informação desta NFe (XML recebido) será consistida com as informações inseridas no ERP (baseada na DANFE recebida).
3- Pergunta:
Em que formato são armazenados os dados da NFe no GRC? Melhor dizendo, o GRC decompõe o XML que chega do fornecedor e armazena os dados em tabelas ou grava como XML mesmo?
Resposta:
O GRC armazena o XML sem decomposição alguma e em dois momentos, quando da solicitação do protocolo e após validação do XML pela SEFAZ. No segundo caso o XML será armazenado com o Código de Autorização de Uso.
4- Pergunta:
De quem é a obrigatoriedade em armazenar o XML? Fornecedor, empresa que recebe, SEFAZ, Receita Federal, etc? As informações armazenadas são as mesmas? Por qual período os dados devem permanecer guardados?
Resposta:
Estas informações foram extraídas Portal da Nota Fiscal Eletrônica - Perguntas Frequentes NF-e
A regra geral é que o emitente e o destinatário deverão manter em arquivo digital as NF-es pelo prazo estabelecido na legislação tributária para a guarda dos documentos fiscais, devendo ser apresentadas à administração tributária, quando solicitado. Assim, o emitente deve armazenar apenas o arquivo digital.
No caso da empresa destinatária das mercadorias e da NF-e, e que seja emitente de NF-e , ela também não precisará guardar o DANFE, mas apenas o arquivo digital recebido.
Caso o destinatário não seja contribuinte credenciado para a emissão de NF-e, o destinatário deverá manter em arquivo o DANFE relativo a NF-e da operação pelo prazo decadencial estabelecido pela legislação, devendo ser apresentado à administração tributária, quando solicitado.
Reforçamos que o destinatário sempre deverá verificar a validade e autenticidade da NF-e e a existência de Autorização de Uso da NF-e, tenha ele recebido o arquivo digital da NF-e ou o DANFE acompanhando a mercadoria. Hoje os processos são separados.
1- DANFE -> transporte de mercadoria -> entrada manual MIRO/MIGO.
2- XML -> interface B2B -> armazenamento no GRC.
A funcionalidade de entrada automática dos dados da NFE no ERP (sem necessidade de digitar nada, dados lidos do XML) está prevista pro próximo release do NFE.
Quanto ao requisito legal (armazenar o XML e verificar status da NF-e quando da chegada do XML), a solução já atende. Mas vc continua tendo q fazer a MIRO/MIGO e checar na SEFAZ o status da NF-e quando da chegada do DANFe (pois no meio tempo entre a chegada do XML e da DANFe, a NF-e pode ter sido cancelada pelo emissor). No próximo release, esses passos manuais serão totalmente automatizados, sendo integrados com o processo do XML.

Chave

meu celular não está ativando a chave é um iPhone 4s de 8gb processador de 1.0 GHz iOS 7.0.1

Oi Rodrigo,
Até hoje não vi a SEFAZ alterar dados de um XML de NF-e, essa seria a primeira vez na história.
Na minha opinião há um indício que o seu sistema de mensageria alterou a informação recebida do ERP antes de comunicar com a SEFAZ.
Você consegue verificar o XML que foi enviado para a SEFAZ?
Se a sua mensageria tem alguma lógica que pode modificar o tpemis ou qualquer dado da chave de acesso após o documento ser postado no ERP então você precisará desenvolver um mecanismo de garantir que ambos os sistemas terão os mesmo dados. A interface do ERP espera que o documento enviado para a mensageria não sofra alterações posteriores.
OBS: SVC não é TPEMIS 2, SVC é 6 ou 7.
att,
Renan Correa

Integração PI/XI e JCO

Senhores,
Um sistema Não SAP acessará o SAP ECC via JCO. Entendo que esta conexão é feita diretamente entre o sistema Não SAP e o SAP ECC. A dúvida é se eu posso colocar o PI/XI entre os dois sistemas. E qual adaptador eu devo usar.
Agradeço pela ajuda.
Al

Henrique, boa tarde.
Na verdade não fui muito claro na minha dúvida.
Uma integração como você mencionou esta claro para mim:
Sistema Não Sap <-- WS/JDBC/Java Proxy > PI/XI < ABAP Proxy --> ERP SAP.
A minha dúvida é se entre o sistema Não SAP e o PI/XI posso integra-los via JCO:
Sistema Não SAP <-- JCO (???) > PI/XI < Proxy --> ERP SAP.
Se sim. Qual adaptador usar?
Agradeço mais uma vez a atenção.
Al.

Sugestão para o campo verProc - Versão do processo de emissão da NF-e

Olá a todos !
Gostaria da opnião de todos sobre o campo Versão do processo de emissão da NF-e (verProc), parametrizado no R/3 em J_1BNFE_CUST3_4V campo VERPROC nas configurações de definição do local de negócio, filial CNPJ.
Minha dúvida é sobre a atualização para a vesão 2.0 do layout do XML, como a versão é definida no campo VERSION, tag versao, com qual informação vcs estão utilizando neste campo, já que trata-se de um campo texto ?
Pesquisando no forum, encontrei uma Thread sobre Erro de Validação - IS_NFE_HEADER-VERPROC link: Erro de Validação - IS_NFE_HEADER-VERPROC onde contem a mesma informação de exemplo utilzada aqui (SAP NFE 1.0).
Vcs estão atualizando o campo para SAP NFE 2.0, por exmplo ? Mantendo a informação antiga, pois como não foi modificada a aplicação, ou colocando alguma outra coisa ?
Creio que quanto mais gente postar uma opinião neste caso é melhor.

Bom dia a_cristovao,
Esta informação serve como identificação de produto emissor de NF-e no XML/Sefaz.
Normalmente coloca-se "SAP NFE 1.0" ou "SAP GRC NFE 1.0" ou "SAP NFE 1.0 SP16".
É mais relacionado ao produto que ao layout.
Atenciosamente, Fernando Da Ró

Dúvidas - Funcionalidades de um Sistema de Mensageria NON-SAP(GRC)

Similar Messages

Maybe you are looking for