Erro no retorno criação do lote

[Former Member]

Pessoal, necessito de um help.

Estou com o seguinte problema no GRC com XML 2.0

Ao enviar uma nota para assinatura, as mensagens de assinatura são disparadas pelo PI, mas depois o processo simplesmente para sem fornecer nenhum tipo de erro. Na moni eu tenho retorno que a NFe foi assinada, mas o processo não continua, ou seja, os lotes não são criados.

A tabela /XNFE/HIST não é atualizada como assinada fica com o status 02, não retorna nenhum erro.

Já atualizei para o SP 16. O job de criação do lote está sendo executado sem poblema e a moni retorna o XML como assinado, o validador do GRC está ativado e os erros já foram corrigidos, o canal de comunicação informa que a mensagem foi entregue assinada.

Alguém tem alguma outra sugestão.

Desde já agradeço.

Nei

[former_member193386 · Accepted solution]

isso me cheira que nao foi configurada a numeracao de lotes na SNUM, va na transacao SNUM e veja se existe um range cadastrado p/ /XNFE/BAID

se nao houver cadastre um range de 000000000000001 a 999999999999999

Edited by: Carlos Rodrigo Pereira on Oct 22, 2010 3:58 PM

Edited by: Carlos Rodrigo Pereira on Oct 22, 2010 3:59 PM

[Former Member · Accepted solution]

E complementando o Carlos... se atentar ao indentificar do Range na SNUM, pois já vi N casos que foi cadastradado com 1 e não 01 como está buscando no /XNFE/PROCESS_REPORTS

...

CALL FUNCTION 'NUMBER_GET_NEXT'

EXPORTING

nr_range_nr = '01'

...

SNUM

01 000000000000001 999999999999999

Bruno

[Former Member]

Galera,

Muito obrigado pela ajuda e pelas dicas de todos.

Instalei o SP 16 e recriei as conexões da SM59 e tudo funcionou certinho.

Valeu galera.

Nei

[Former Member]

Fernando,

Acredito que essa duplicidade seja o problema, só não consegui encontrar sua origem ainda.

As RFC estão corretas, apontando para os destinos corretos, não tem nenhum dump na ST22.

Quanto ao certificado digital, o que o cliente me passou é que é um certificado do tipo ACBC. Instalei esse certificado na minha máquina e acessei o site da sefaz sem problemas.

Conforme vc pediu, segue o XML com o erro que está acontecendo.

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

- <!-- Call Adapter

-->

- <SAP:Error xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="1">

<SAP:Category>XIProtocol</SAP:Category>

<SAP:Code area="MESSAGE">DUPLICATE_DETECTED</SAP:Code>

<SAP:P1>35C0C04C0B4C4868E10000000A000013</SAP:P1>

<SAP:P2>CENTRAL</SAP:P2>

<SAP:P3 />

<SAP:P4 />

<SAP:AdditionalText />

<SAP:ApplicationFaultMessage namespace="" />

<SAP:Stack>Message ID 35C0C04C0B4C4868E10000000A000013 already exists in called system (pipeline CENTRAL)</SAP:Stack>

<SAP:Retry>N</SAP:Retry>

</SAP:Error>

Muito obrigado pela ajuda

Nei

[former_member193386]

Estranho esse fato porque eu não vejo situação de dar uma duplicidade ou mesmo executar duas vezes a interface de assinatura digital, vc tem certeza que existe apenas uma unica configuração de cenario para o serviço de assinatura ( Cancelamente / Inutilização e Criação ) ?

Mesmo porque, caso houvesse mais de uma configuração provavelmente haveria erro de Receiver se eu nao me engano!

[former_member182114]

Bom dia Claudinei,

Tinha imaginado que talvez estivesse em loop as suas ligações, ao dar uma olhada no SDN geral, encontrei esta dica que peço teste e nos dê feedback.

Confirme se no CC está como XI 3.0 no Message Protocol.

Atenciosamente, Fernando Da Ró

[Former Member]

Bruno,

Essa é uma instalação do zero do GRC, já estamos iniciando com a versão 2.0 do XML,com o namespace 006, não tenho o 005a configurado.

Pelo que tenho aqui do visual administration o KeyStorage View e Entries estão corretos na Spro. Só se ocorreu algum erro na instalação.

Eu tenho essa dúvida de que o certificado pode não estar assinando a nota, mas na SXMB_MONI, tenho a mensagem SIGNN_signIn_doc_SYNC_IB com os dados da nota mais a seguinte tag no final:

<ns2:Status>0</ns2:Status>

<ns2:StatusDescription>Successful XML Signature.</ns2:StatusDescription>

</ns2:SignedNFe>

Carlos,

Executei o programa e o mesmo criou uma linha na tabela, mas mesmo assim o campo ID continua em branco, debugando verifique que ele é utilizado no programa /XNFE/PROCESS_REPORTS para selecionar a tabela /XNFE/NFEHD onde essa tabela está preenchida.

[Former Member]

Olá Pessoal,

Verifiquei tudo o que vcs me passaram.

Não existe nenhuma mensagem presa nas filas. Os cenários de assinatura como os demais estão apontando para o namespace http://sap.com/xi/NFE/006.

O certificado também está correto está como pede o manual da SAP.

O /XNFE/BAID da numeração também está correto, executei a função NUMBER_GET_NEXT, na SE37, com os parâmetros que o programa /XNFE/PROCESS_REPORTS e a função está executando corretamente pegando a numeração correta.

O que eu notei de diferente debugando o programa /XNFE/PROCESS_REPORTS é o seguinte:

Dentro do programa /xnfe/collect_batch, existe um select na tabela /xnfe/nfebat que não está retornando nada, por isso que não consegue criar o Lote.

Outra coisa que eu encontrei é que no momento que executa as interfaces de assinatura, as mensagems SIGNN_SignNFe_OB e SRVSC_nfeStatusServicoNF_SYNC_OB estão sendo executadas duas vezes, com isso a interface SIGNN_SignedNFe reclama de objetos duplicados.

Será que pode ser essas mensagens duplicadas que não estão atualizando as tabelas e a criação dos lotes ?

Obrigado pessoal.

Nei

[former_member193386]

rode o programa /XNFE/GENERATE_DEFAULT_BATCUS isso resolvera o seu problema provavelmente

[Former Member]

Claudinei,

As notas enviadas para assinatura na versão http://sap.com/xi/NFE/005a estão passando?

Pelo que você descreveu pode ser até algum "pelô" na configuração dos cenários que esteja passando batido.

E como você mencionou que não está chegando na /xnfe/nfebat achoooo que não está pegando retorno da assinatura, só está enviado e se perdendo. O nome do Certificado na SPRO está idem ao que está no Keystorage no Visual Admin ?

Abcs,

Bruno

[former_member193386]

se fosse erro de certificado estaria gerando erro na sxi_monitor ao menos.

Vc usa HSM ? Perguntei isso no começo da thread

[former_member182114]

Bom dia Claudinei,

Lote ainda não é problema visto que só será criado após a mensagem retornar com sucesso ao ABAP, momento em que a /XNFE/NFE_HIST é atualizado para status 03 (assinado) e é criada a linha na tabela /XNFE/NFEBAT daí que o programa /XNFE/COLLECT_BATCH vai "detectar" que tem que criar o lote.

Você comentou que a mensagem foi assinada com sucesso então talvez não é o assinador, porém você comentou:

Outra coisa que eu encontrei é que no momento que executa as interfaces de assinatura, as mensagems SIGNN_SignNFe_OB e SRVSC_nfeStatusServicoNF_SYNC_OB estão sendo executadas duas vezes

- A duplicidade em si pode ser devido a sua configuração CENTRAL INSTANCE e coisas assim

com isso a interface SIGNN_SignedNFe reclama de objetos duplicados.

- Aí que deve estar o problema. Que duplicidade é essa ?

- Qual a mensagem de erro e onde você a captura ? (cola aqui pra vermos)

- Tem algum dump na ST22 ?

- A RFC de retorno do PI para o GRC está apontando realmente para o client do GRC ?

- Na mensagem SIGNN*IB qual o ID de retorno ? É o mesmo que existe na tabela ?

Atenciosamente, Fernando Da Ró

[former_member193386]

Da uma olhada na SMQ2 se tem alguma fila parada, e na st22 se nao esta dando algum dump. VC usa HSM ou o assinador digital da SAP?

[Former Member]

Claudinei,

Você verificou smq1, smq2 se não tem nada parado? (apesar que você iria ver algo diferente das bandeirinhas quadriculada na moni)

Os cenário de assinatura estão configurados para o namespace http://sap.com/xi/NFE/006 ?

Acredito que você tenha isso funcionando para versão 1.1 do XML, mas já tive um caso idem ao seu que o problema era no Security Provider Service no Java Visual Admin.

A permissão no dominio precisa ser sensitive-case XiSecurityRuntimePermission como está no help http://help.sap.com/saphelp_grcnfe10/helpdata/en/93/cc40a6f0434083a64e23823175a8ff/frameset.htm

e no meu caso estava assim XISecurityRuntimePermission

Talvez te ajude em algo...

Abraço,

Bruno