Erro no processo de cancelamento

Caro colegas,
O meu processo para mandar o lote esta funcionando. Porem quando fui solicitar um cancelamento da nota recebi um erro 215 que e erro de schema xml. O validador esta acionado na configuracao.
<?xml version="1.0" encoding="utf-8" ?><ns1:nfeCancelamentoNFResponse xmlns:ns1="http://sap.com/xi/NFE/005a"><ns1:nfeCancelamentoNFResult><ns2:retCancNFe versao="1.07" xmlns:ns2="http://www.portalfiscal.inf.br/nfe"><ns2:infCanc><ns2:tpAmb>2</ns2:tpAmb><ns2:verAplic>SP_NFE_PL_005c</ns2:verAplic><ns2:cStat>215</ns2:cStat><ns2:xMotivo>Rejeição: Falha no schema XML</ns2:xMotivo><ns2:cUF>35</ns2:cUF></ns2:infCanc></ns2:retCancNFe></ns1:nfeCancelamentoNFResult><ns1:NFeID>35090703528802000167550000000000640672996974</ns1:NFeID><ns1:retCancNFeStr><retCancNFe xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.07"><infCanc><tpAmb>2</tpAmb><verAplic>SP_NFE_PL_005c</verAplic><cStat>215</cStat><xMotivo>Rejeição: Falha no schema XML</xMotivo><cUF>35</cUF></infCanc></retCancNFe></ns1:retCancNFeStr></ns1:nfeCancelamentoNFResponse>
Tem como saber o que houve?
Abs,
Phil

Bom dia Phil,
Sim, você deve pegar o XML no SXI_Monitor e pode usar a ferramenta de validação do site da Sefaz RS para validá-lo.
Validador de mensagens do projeto NF-e
Porém, de antemão verifique:
- Se a justificativa de cancelamento tem no mínimo 15 caracteres
- Se a justificativa de cancelamento não possue acentos ou caracteres especiais.
Atenciosamente, Fernando Da Ró

Similar Messages

Erro no processo de cancelamento/inutilização

Amigos,
Configurei os cenários de NFe e está ocorrendo um problema no PI que ainda não havia visto. Recebo a mensagem abaixo na SXMB_MONI:
- <SAP:Error xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="">
<SAP:Category>XIAdapter</SAP:Category>
<SAP:Code area="BPE_ADAPTER">MESSAGE_NOT_USED</SAP:Code>
<SAP:P1 />
<SAP:P2 />
<SAP:P3 />
<SAP:P4 />
<SAP:AdditionalText />
<SAP:ApplicationFaultMessage namespace="" />
<SAP:Stack>Message interface is not used by this process</SAP:Stack>
<SAP:Retry>M</SAP:Retry>
</SAP:Error>
Já refiz os cenários e ainda assim não funcionou. Alguém já passou por um caso semelhante?
Abraços,
Marcos

Bom dia Phil,
Sim, você deve pegar o XML no SXI_Monitor e pode usar a ferramenta de validação do site da Sefaz RS para validá-lo.
Validador de mensagens do projeto NF-e
Porém, de antemão verifique:
- Se a justificativa de cancelamento tem no mínimo 15 caracteres
- Se a justificativa de cancelamento não possue acentos ou caracteres especiais.
Atenciosamente, Fernando Da Ró

NF-e 3.10 - não finaliza o processo de cancelamento

Olá pessoal.
Estamos realizando testes da NF-e 3.10 e estamos com o seguinte problema.
Emitimos a NF-e e a mesma retornou com o erro 234 - Rejeicao: IE do destinatario nao vinculada ao CNPJ.
Fizemos o processo de cancelamento desta NF-, porém agora a NF fica travada no status de processamento (não finaliza o cancelamento).
Alguém já passou por isto?
Obs. quando a NF é aprovada e depois solicitamos o cancelamento, o processamento finaliza normalmente.
Estamos debugando para ver se encontramos algo e também procurando SAP Notes, porém não estamos conseguindo identificar oque está ocorrendo.
Obrigado.
José Claudio.

Jose Claudio,
Estou tento uma situação bizarra aqui também, todas as notas com problema de rejeição de qualquer tipo o GRC está ficando inativo, não apenas para cancelamento também.
Para resolver o problema você vai precisar invocar os poderes do "THORRRRRRRRRRRRRRR" na tabela /XNFE/BATCHHD vai ter um campo chamado "Process Step " veja se o campo abaixo está com status está com "'11 - Step is waiting for asynchronous reply".
Se estiver apaga esse valor para "em branco" e depois vai no monitor do GRC e clinca em FINALIZAR PROCESSO, na realidade o PI recebeu a resposta da Sefaz com processamento do Lote mais não consegue repassar para GRC.
Assim vai "DESTRAVAR" o GRC e continuar o processo de devolução do status da NF-e para SAP ECC.
Eduardo Chagas era isso que estava comentando mais não tive tempo de documentar.
Att,
Viana.

Processo de cancelamento de Nota Fiscal

Pessoal , bom dia!
Mais uma vez estou aqui solicitando um help.
Estamos em produção e nos deparamos com uma situação inusitada de processo de negócio.
Emitimos 2 notas fiscais de serviços e uma ORB indevidamente.
As duas notas de serviço passaram para o GRC e foram enviadas para o SEFAZ por que faltava a configuração no ECC que proibe notas de serviços de serem enviadas ao GRC. Já corrigimos isso.
A ORB foi enviada com caracteres especiais e consequentemente foi recusado o XML pelo SEFAZ.
Nossos usuários solicitaram o cancelamento da Nota porém o GRC não atualizou o Status do ECC.
Descobrimos que estava faltando autorização para o usuário que atualiza o ECC (pela RFC na SM59) e já corrigimos também.
Porém antes de corrigirmos as autorizações o usuário cancelou a fatura (manualmente no ECC) da ORB e agora o JOB UPDATE_ERP_STATUS não está atualizando o ECC. Porém no GRC esta já está com o Status 102 e verde.
Além disso, para as notas de serviço o JOB também não está atualizando o ECC, porém estas não tiveram suas faturas canceladas e já estão com o status 101 ou 102 e verde no GRC.
Agradeço a ajuda desde Já..... Obrigado
Suzano

Bom dia Thiago,
É possível que precise de notas no R/3 ou até desenvolvimento, não conheço bem o processo de negócio neste ponto.
Você pode fazer o seguinte, pelo que você disse, os registros com 102 devem estar na tabela /xnfe/backstatus pois o job /xnfe/update_erp_status não está conseguindo processar com sucesso.
Este ponto de retorno de cancelamento tem estes pontos de atenção:
- idioma do usuário na SM59 do GRC deve estar manualmente setado para o que se loga no dialog do R/3 (ex.: PT)
- direitos deste usuário no R/3 (pode varias conforme processo MM, SD, FI, IS....)
- notas ausentes no R/3 (procure por notas c/ J_1BNFE_CANCEL no market place)
- pré-requisitos de cancelamento (período fechado, sem saldo...)
- standard sem suporte para o tipo de cancelamento
Verifique no GRC na transação RSRFCTRC se tem alguma informação referente a execução da função J_1B_NFE_XML_IN_TAB
Vá eliminando todas estas etapas e por fim, se nada mais funcionar, pegue os dados da /xnfe/backstatus e debug a função J_1B_NFE_XML_IN diretamente no R/3, o ponto de atenção deve estar no call transaction que ele irá executar para cancelar.
Atenciosamente,
Fernando Da Ró

Erro 8B260 (Processo de Entrega Futura)

Bom dia, Pessoal!
Estou com um problema no processo de devolução de entrega futura.
Realizei a entrada da nota de fatura normalmente atraves da MIRO e da nota de remessa atraves da MIGO (mov 801).
O fornecedor nos enviou as notas de Fatura e Remessa como de entrada pois ele ainda não tem a obrigação legal da NFE, porém a empresa aonde estou já está obrigada a utilizar a NFE e ao realizar a devolução o sistema não encontra a referencia da nota de remessa. A mensagem de erro é a 8B 260 (NOTA FISCAL DE REFERÊNCIA XXXXX NÃO FOI ENCONTRADA)
O pedido está somente com a opção de parceiro FO o processo já foi criado sem a opção de parceiro "FM" (Fornecedor da Mercadoria).
As Notas Abaixos já estão aplicadas:
NF:
1055401 Subcontracting Returns doesn't find reference Nota Fiscal
NF-e:
1175538 NF-e Reference between NF and NF-e
1238765 NF-e: Returns for Subcontracting - Error 8B287
1257933 NF-e: Reference NF not found by return for subcontracting
1288925 NF-e: References between NF-e and non NF-e
1356952 NF-e: Returns for Subcontracting - Error 8B260
Estive debugando a função J_1B_NF_DOCUMENT_SELECT_2 e o que pode verificar é que como o processo de fatura/remessa é gerado atraves de uma nota de entrada ele armazena as informações J_1BNFDOC-NFNUM porem ao realizar a devolução, como a empresa que estou é obrigada a emitir a NFE a função realiza a busca no campo J_1BNFDOC-NFENUM com o numero da nota de remessa (NFNUM) por este motivo não é encontrado a nota de referencia e o erro é apresentado.
Eu procurei por alguma nota que pudesse corrigir meu problema porém não encontrei nenhuma aplicavél, alguem tem alguma ideia de como resolver este problema?
Obrigado
Gustavo

Olá xará,
tudo certo?
Esse erro provavelmente está ocorrendo porque existem múltiplos parceiros atribuídos ao Pedido de Compras.
No procesos de entrega futura, contudo, o sistema comporta somente a utilização de um parceiro, do contrário o processo é interpretado como sendo uma operação triangular.
Abraços

Erro no Evento de Cancelamento NFE 3.10

Bom dia a todos.
Estamos realizando testes de estorno de notas já na versão 3.10.
Na transação J1BNFE no SAP ECC, ao solicitar o estorno, estamos recebendo a mensagem abaixo:
" A conexão RFC 0054494302 falhou na transmissão da solicitação"
A chamada está sendo realizada no GRC. Ao debugar o programa no GRC que realiza o envio de cancelamento para a Sefaz, verifiquei que em determinado momento, a tabela /XNFE/PROXY_MAP é lida, com os dados abaixo:
VERSAO = '3.10'
DOCTYPE = 'EVE'
PROXY_GROUP = '110111'.
Esses dados não estão cadastrados na tabela, então retorna SY-SUBRC = 4 e o erro é gerado, conforme expliquei acima.
Essa tabela não deveria já vir preenchida com a aplicação do Support Package da NFE 3.10? Alguém já enfrentou esse problema?
Estamos no Support Package SAPK-90016INSLLNFE do componente SLL-NFE no GRC.
Alguém sabe se existe alguma nota ou se esses dados devem ser cadastrados manualmente? Se sim, quais dados devem ser cadastrados?
Obrigado.
Luis Gustavo dos Santos

Felipe, obrigado pelo retorno.
Identifiquei o erro aqui, na verdade os ABAP Proxy's de eventos da versão 3.1 estão configurados nas tabelas /XNFE/PROXY_MAP e /XNFE/PROXY_GRP como versão 1.0:
Portanto configurei como versão 1.0 mesmo o evento na SPRO:
Com isso o problema foi resolvido.
Att.
Luis Gustavo dos Santos

Cancelamento de NF-e parado (batch status 05, process status 02)

Bom dia pessoal,
Ontem tivemos um problema no GRC/PI de um cliente, onde por alguma razão o certificado estava sendo rejeitado. Depois de vários problemas causados por isso, foi resetado o j2ee e o sistema voltou a operar normalmente.
As sequelas disso foram duas notas para as quais foi solicitado o cancelamento, agora elas estão com status de processamento 02 (Sent to Signature Service) e batch status 05 (Result Received).
Seguindo uma orientação para um caso parecido (),
peguei os MsgIDs das mensagens dessas NFs na /xnfe/acknowledg (ambas com SIGNC), encontrei-as no SXI_MONITOR do PI, onde elas são listadas 2x cada, com os seguintes status
1 - Status = Transfer to Process Engine (, Ack. Status = branco
2 - Status = Processed Successfully, Ack. Status = Still awaiting acknowledgment (bola verde com interrogação)
Ao tentar dar restart nas mensagens, recebo a seguinte mensagem de erro:
You cannot restart XML message E07AFA5FD584CEF1B15C3C4A927627EC with this status/type
Message no. XMS_ADM085
Diagnosis
You want to reschedule an XML message that has already been processed (Restart). However, the XML message status or type does not permit a restart.
System Response
You can only restart asynchronous XML messages.
Furthermore, you can only reschedule XML messages with errors. You cannot restart correctly processed XML messages or XML messages with the status Being Processed.
Tem algo que possa ser feito sem ter que alterar tabelas?
Como a equipe responsável pelo PI/GRC fica fora do BR, é bem complicado conseguir autorização para qquer coisa nesse sentido em PRD.
ps.: Agora cliquei no "Expand all messages", para cada um dos MsgIDs, apareceram 2 novas linhas, uma com status = Scheduled (bandeira verde) e outra com status Scheduled for Outbound Processing (seta preta), ambos com o awaiting ack.
=> SMQ1 e SMQ2 ambas sem entradas.
Obrigado!
Eduardo Hartmann

Eduardo,
O NFe type = 2 (cancelamento)?
Se sim, me parece que o pedido de cancelamento foi enviado pra assinatura e nao teve resposta, provavelmente devido ao fato de o J2EE estar fora. Nesse caso, o batch status é irrelevante (ele só é relevante pro processo de envio de NFe, não pra cancelamento/inutilização).
O "correto" seria vc identificar onde a mensagem de assinatura parou (i.e. se em alguma fila - SMQ1/SMQ2, se tem q restartar o BPM etc.). Mas como o passo de assinatura é stateless, diferentemente do processamento da SEFAZ, vc poderia simplesmente "marretar" um status de erro de assinatura de cancelamento na /xnfe/nfe_hist (verifique o valor apropriado do error status no domínio do campo) e restartar a assinatura do cancelamento pelo monitor de NFe do GRC, aba de erro de assinatura.
Abs,
Henrique.

NFe em processamento no ERP e OK no GRC mas teve erro de atualização do ERP

Boa tarde,
Tem acontecido que ao tentar atualizar a NFe, ocorre o erro de atualização (tabela /XNFE/NFE_HISTconsta 108), porém no monitor GRC a NFe está com status OK (verde).
Ao verificar a tabela /XNFE/NFE_HIST, o registro de wasstat 05 (Result Received) tem o error_erp 108, porém o último registro da tabela é o de wasstat 08 (sent to B2B) e neste o erroe_erp está em branco. Inserindo o erro 108 neste último registro, a NFe aparece agora no monitor GRC com status de erro, e o erro ERP 108, e aparece na aba de "Erro atualização status ERP", permitindo assim o uso da opção Atual. (atualizar o ERP novamante), que após acionado, atualiza o ERP corretamente e volta a NFe para OK no monitor GRC.
Já pesquisei notas e aqui no SCN e não encontrei nada relacionado.
Alguém já passou por isso.
GRC 10.0 sp13
ERP 604 sp11
Abraços
Ricardo Carneiro.

Bom dia Ricardo,
Vamos por partes...
- o 05 significa resultado recebido da Sefaz, e o status 100 diz que foi tudo Ok por lá
- o 05 tenta comunicar com o ERP, e o 108 indica neste status que o ERP não pode processar seu status
- o 08 não comunica com o ERP, então nele não deve ter ERP_ERROR mesmo
Agora as questões:
- Deveria ter o processo parado no 05 já que houve um erro? Para alguns a resposta seria sim sim sim, para outros já que tá tudo OK faz o B2B
- Não deveria ter sido copiado o status 05 para 08? Talvez (pq resolveria a questão manual)
- O que fazer então?
Sobre o 108 ele é sintoma SEMPRE, algo não está bom no processamento ERP. A única coisa esperada de fato na emissão é o lock de processo no ERP, que o SAP NFE trata reenviando via job.
Na emissão muito provavelmente é algo errado seja configuração, seja código e deve estar dentro da BAdI.
Você não postou o que encontrou na RSRFCTRC. Poste por favor.
Com o foco em solução te indicaria investigar o que está errado no ERP, e a questão ERP_ERROR não estar visível no 08 vai ficar menor. De qualquer forma pode ser motivo de chamado para o desenvolvimento avaliar opções, mas é um remédio para sanar sintoma não para curar a doença.
* Se fosse um processo de cancelamento ou skip bem mais coisas poderiam acontecer como fonte de um erro de processamento ERP.
Atenciosamente, Fernando Da Rós

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ó

Consulta de status de lote: erro de sistema PI

Pessoal, bom dia.
Em alguns casos ocorre erro de comunicação na consulta do status do lote. Após o GRC enviar o lote pra SEFAZ, ele fica consultando o status do lote até n vezes (conforme atualizado nas configurações do lote no monitor do GRC), certo?.
Quando ocorre esse erro de comunicação (Consulta de status de lote: erro de sistema PI), o GRC para de ficar consultando o status.
Existe alguma forma de parametrizar/automatizar o GRC para que quando ocorrer esse erro, ele fique solicitando a consulta de status até as n vezes em vez de para a solicitação da consulta?
Ou criar um Z que busque os lotes que estajam com este status e coloca-los em processamento?

Bom dia Fábio,
Não, a configuração de tentativas serve apenas para quando a Sefaz responde de forma clara com um 105 - Em processamento.
Quanto acontece erros, o processo fica parado mesmo e a forma de restart é manual ou através de Z (Cristiane deu uma colaboração colocando o código para referência, veja: Sample code for automatic resend of batches with communication errors não consegui achar a thread que discutimos isso).
Observação: É muito importante garantir que os problemas que estão fazendo seus lotes pararem são realmente externos e solucionáveis pelo job, do contrário você pode gerar sim problema interno no GRC para todas os processos/Sefazes ao insistir num reprocessamento automático.
Sugestão:
- certifique-se que o motivo para o restart é externo
- faça log de todos os restarts em tabela
- determine um número máximo de restarts automáticos
- analise continuamente do que foi restartado sem sucesso para tentar obter regras que impeçam o restart sem sucesso
Atenciosamente, Fernando Da Rós
Edited by: Fernando Ros on Jul 21, 2010 5:41 PM

Processamento de Cancelamentos de Notas no SAP GRC

Bom dia,
Tivemos uma situação no nosso projeto em que foram realizadas alguns cancelamentos massivos onde o GRC sofreu com problemas de performance e algumas notas demoraram grande tempo para terem seu cancelamento homologado.
Depois de algumas análises, verificamos que uma fila de saída do PI estava lotada (mais de 900 mensagens) e as mensagens foram saindo lentamente até que o ambiente se normalizou (referente a uma interface de solicitação de cancelamento).
Diante deste cenário fiquei com algumas dúvidas:
- O processo de cancelamento é realizado em série (ou seja, a primeira nota a ter solicitado o cancelamento é a nota que será cancelada)?
- As notas estavam com status de processo 06 no monitor web. Isto significa que a solicitação já foi feita a SEFAZ e estamos aguardando a homologação do cancelamento?
- Caso eu possua uma configuração distinta de fechamento de lotes por CNPJ do emissor, isto influenciará na solicitação de cancelamento? Caso sim, ele fechará um lote para cada nota que estará na fila única de cancelamento?
Alguém poderia ajudar?
Abraços,
Alberto Almeida

Boas perguntas Alberto,
Depois de algumas análises, verificamos que uma fila de saída do PI estava lotada (mais de 900 mensagens) e as mensagens foram saindo lentamente até que o ambiente se normalizou (referente a uma interface de solicitação de cancelamento).
Sim, tudo no PI acontece em fila, porém é comum que na implementação os processos de assinatura de nota para envio, envio de lote e consulta de lote respectivamente SIGNN, BATCH e BATSR* sejam "tunados" para trabalhar com filas em paralelo podendo então atender ao quesito performance e terminar mais rápido usando do processamento paralelo, mas mesmo estes processos são regidos por filas FIFO (first in first out).
- O processo de cancelamento é realizado em série (ou seja, a primeira nota a ter solicitado o cancelamento é a nota que será cancelada)?
Se não tem paralelismo na interface SIGNC* e CANC* SIM, a primeira a chegar na fila do PI será a primeira a ser cancelada.
- As notas estavam com status de processo 06 no monitor web. Isto significa que a solicitação já foi feita a SEFAZ e estamos aguardando a homologação do cancelamento?
O 06 é do ponto de vista do aplicativo (ABAP entrogou para o PI), só garante que saiu do ABAP e ainda não voltou, o próximo status é o 05 status recebido. Para ter certeza se chegou na Sefaz, deve-se procurar na Sefaz ou então no PI.
{quote|- Caso eu possua uma configuração distinta de fechamento de lotes por CNPJ do emissor, isto influenciará na solicitação de cancelamento? Caso sim, ele fechará um lote para cada nota que estará na fila única de cancelamento?{quote}
Não influencia. A comunicação de cancelamento/inutilização é 1 pra 1 com a NF-e e não existe lote envolvido.
Isto também é um fator que gera baixa performance o GRC tem que fazer 900 assinaturas e 900 envio de cancelamento.
Resumindo: Pra você obter uma performance mais aceitável pode-se colocar um paralelismo pequeno tipo 3 filas para as interfaces de cancelamento (SIGNC* e CANCR*). Veja exemplo na SAP Note 1247831 de performance para assinatura.
Importante: Paralismo faz parte de tunning, tudo que prever com mais filas deve-se ter certeza que o sistema irá conseguir rodar tudo ao mesmo tempo, ou seja Work Process DIALOG (DIA) disponíveis.
Atenciosamente, Fernando Da Ró

Erro na J1BNFE (nota fiscal de entrada - categoria F1)

Bom dia,
Estou com um erro no monitor de nf-e, para uma nota de entrada - categoria F1:
Os erros são:
Erro de validação: Campo 44-Place Access Key: V11 (Campo ID)
Erro de validação: Campo 44-Place Access Key: V06 (Campo ID)
Erro de validação: Campo 44-Place Access Key: V08 (Campo ID)
Verificamos que os campos Nº aleatório e Díg.ctrl. não estão preenchidos, seria essa a causa do erro ?
Obrigada,
Dayana.

Obrigada Jeisson,
É um processo de compra, uma nota fiscal eletrônica de entrada (MIRO), porém neste caso existe uma transação "Z" para não fazer a validação no momento da MIRO, devido a um erro no processo. Dessa forma, como não houve a validação na entrada, o usuário não preencheu todas as informações necessárias na NF-e. E no monitor a nota ficou com os erros citados.
Sempre que ocorrer esse erro, é devido ao campo que não esta preenchido, ou pode ocorrer por outros motivos?
Obrigada!
Dayana.

Serviço de assinatura digital não acessível Status 20

Boa noite Sru2019s.
Estamos passando a NF-e para 2.0 e estamos tendo um pequeno problema no GRC:
A nota chega no GRC e na tabela : /XNFE/NFE_HIST fica com o seguinte status:
MAND     T ID      VERSNUM     TYPE ERTIME            WASSTAT    ERROR_STATUS ERNAME       TPEMIS
412       3511030* 001              1    20.110.323.142.753,3527960 01                     RFCUSER         1
412       3511030* 001              1    20.110.323.142.753,4791950 01      20           RFCUSER         1
No monitor do GRC fica o seguinte erro:
Stat.processo        Status global            Status de erro Status de erro
1      Recebido do sistema back end        20    Serviço de assinatura digital não acessível.
No monitor do PI SXMB_MONI não aparece nenhum log que a interface de Assinatura foi startada.
O certificado esta ok pq foi feito um teste com a NF-e 1.10 e funcionou normal.
Dump ST22 que acredito estar relacionado ao nosso problema:
Erro tempo execução    DYNPRO_SEND_IN_BACKGROUND
O SLD esta ok, pois utiliza os mesmos BS da 1.10
Se eu executar a interface de assinatura pelo RWB passando o XML a nota segue todo o pipeline da NF-e corretamente.
Estamos com o SP15 no GRC.
Obrigado,
Rafael
Edited by: SAP PI GRC on Mar 23, 2011 11:12 PM

Bom dia Rafael,
Segue uma thread com o sofrimento que quem começou com o SP15 (parte dele) NF-e pré-validação erro - XML 2.00 - /XNFE/VERSION 0006, aí tem por final seu erro.
Vá para o SLL-NFE SP17 e XI Content, ou liste todas as notas pós SP15 de SLL-NFE e aplique em seu sistema.
SP15 não funciona sem correção para layout 2.0
A dica é SP17 + SAP Notes do SP18...
Atenciosamente, Fernando Da Rós
Sobre o DYNPRO_SEND_IN_BACKGROUND ele acontece quando uma screen é chamada em um processo sem diálogo, como uma RFC ou uma execução background. Não deveria acontecer no standard, melhor abrir uma thread específica para este com todos os dados que tiver em mãos, como acontece, em que código...
Edited by: Fernando Ros on Mar 24, 2011 5:14 PM

Status de erro: 50 - Cancelamento/inutilização: erro de sistema PI

Boa noite, srs!
Estamos com um problema na inutilização e cancelamento de NFe junto ao SEFAZ.
Foi executado o report J_1BNFECHECKNUMBERRANGES para inutilização de numeração de NFe. A tabela J_1BNFENUMGAP foi preenchida com a numeração, porém a mesma não consta na consulta do site da Fazenda.
Consultando o Monitor GRC com os IDs indicados na tabela, aparece o seguinte erro:
Status de erro: 50 - Cancelamento/inutilização: erro de sistema PI
De fato o processo aparece com erro no monitor do PI. Não consegui diagnosticar o erro na msg xml de retorno. A unica descrição disponível é:
<SAP:AdditionalText>com.sap.aii.af.ra.ms.api.DeliveryException: SOAP: response message contains an error XIAdapter/HTTP/ADAPTER.HTTP_EXCEPTION - HTTP 415 Unsupported Media Type</SAP:AdditionalText>
Reparei que o mesmo erro ocorre para estorno de NFes que já foram aprovadas no SEFAZ.
Verifiquei os canais de comunicação para inutilização e cancelamento de notas e os endereços estão apontando corretamente para os WS da Fazenda. O serviço (Minas Gerais) também aparece como disponível/ativo na SEFAZ.
Estou meio sem norte aqui para identificar o erro.
Alguém já enfrentou este caso ou algo similar?
Obrigado desde já!
Carlos Penteado.

Bom dia, caros!
Obrigado pelas respostas!
Metade dos meus problemas foi solucionado! =|
Henrique e Bernardo, vocês tinham razão, era erro da própria SEFAZ. Tentei o re-envio do estorno da NFe pelo GRC e ela retornou com sucesso!
No entanto, tive que alterar o status da nota no J_1BNFE_ACTIVE para que a nota completasse o estorno na J_1BNFE.
Porém o erro da inutilização da numeração de NFe continua acontecendo. O funcional abriu um chamado na SAP, assim que tiver alguma resposta, replico aqui!
Fernando, verifiquei o canal de comunicação de inutilização (SKIP) e as configurações parecem ok, estão assim como os canais que funcionam.
Nunca utilizei o Visual Administrator. Vou verificar com o Basis a possibilidade...
Obrigado pela ajuda! Atualizarei assim que encontrar mais alguma novidade!
Abs,
Carlos.

Cancelamento/inutilização: erro de sistema PI

Pessoal, bom dia!
Por favor, estamos testando o cenário de Cancelamento de NF e as notas estão ficando com os seguintes status:
Stat. Processo: 06 - Enviado ao Processamento da Nota Fiscal Eletrônica
Status de erro: 50 - Cancelamento/inutilização: erro de sistema PI
Analisando o erro no Monitor do PI, peguei o XML enviado ao Sefaz e testei no endereço http://www.sefaz.rs.gov.br/NFE/NFE-VAL.aspx e os dados estão corretos.
O Erro detalhado no Monitor do PI é (Error in response):
Message processing failed. Cause: com.sap.aii.af.ra.ms.api.RecoverableException: SOAP: response message contains an error XIAdapter/PARSING/ADAPTER.SOAP_EXCEPTION - soap fault: Unexpected Error java.lang.NoSuchMethodError: javax.xml.soap.SOAPFactory.newInstance(Ljava/lang/String;)Ljavax/xml/soap/SOAPFactory; at br.inf.portalfiscal.soapclient.ClientSoap.(TransitoCancelamentoClient.java:56) at br.inf.portalfiscal.nfe.controller.ValidaDadosCanc.verificarRegistroCirculacao(ValidaDadosCanc.java:248) at br.inf.portalfiscal.nfe.controller.ValidaDadosCanc.validaDadosCanc(ValidaDadosCanc.java:214) at br.inf.portalfiscal.nfe.controller.ValidacaoXMLHelper.validaCancelamento(ValidacaoXMLHelper.java:307) at br.inf.portalfiscal.nfe.controller.UtilSession.processarCancelamento(UtilSession.java:509) at sun.reflect.GeneratedMethodAccessor292.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.invocation.Invocation.performCall(Invocation.java:359) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:169) at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168) at org.jboss.ejb.plugins.LogInterceptor.inv
Obrigado,
Danilo

De fato, esse trace é do web service da propria SEFAZ.
Esses objetos referenciados (e.g. ValidaDadosCanc.java) não fazem parte do pacote do SAP NFE.
O status no GRC está como comunicacao de PI (vermelho)?
Se sim, depois de a SEFAZ corrigir o problema, vc consegue restartar o processo pela aba de Erro de Cancelamento/Inutilizacao no Monitor de NFes.
Abs,
Henrique.

Erro no processo de cancelamento

Similar Messages

Maybe you are looking for