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ó

Similar Messages

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ó

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.

Cancelamento/inutilização: erro de sistema PI - SEFAZ MG - Erro: 50

Bom dia,
Estamos com problemas para relizar o cancelamento de notas junto ao SEFAZ de MG.
Todos os cancelamentos retornam da seguinte forma:
Status de Processo: 06 - Enviado ao Processamento da Nota Fiscal Eletrônica
Status de Erro: Cancelamento/inutilização: erro de sistema PI
Fizemos várias tentativas de reenvio, mas todas retornaram com o mesmo erro.
Também alteramos o status de erro, através da tabela de histório de status, mas também continua retornando o mesmo erro.
Aparentemente isso está acontecendo desde segunda-feira (03/10).
Verificamos na sxi_monitor e não há registro de erro (sem bolinha vermelha), os precessos ficam "bandeirados", mas com o erro NEGATIVE_ACKNOWLEDGEMENT.
Ao que tudo indica é algum problema no SEFAZ de MG, mas como podemos verificar isso?
Alguém está tendo o mesmo problema?
Desde já obrigada!
Gilmara Silva

Boa tarde.
Estamos tendo o mesmo problema.
Na verdade o problema começou na SEFAZ MG dia 30.09.2011. Algumas (muito poucas) empresas estão conseguindo cancelar. Acredito que depende de qual servidor da SEFAZ o pedido é processado.
Depois de diversos contatos com SEFAZ via chamados, telefonemas, etc....recebemos o seguinte retorno:
"Este é um problema intermitente e pela análise da STI deve estar ocorrendo apenas em uma das máquinas utilizadas no processamento. Alguns contribuintes estão conseguindo a autorização quando do reenvio da solicitação de cancelamento.
Ainda não podemos precisar a disponibilidade da solução."
SEF/MG - SAIF/DINF/DED
Ou seja, sem previsão.
At.,
Bernardo Braga

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.

NF-e com Status Proc. 06, erro 50 e status 212 no GRC e no R/3 processando

Bom dia!
Gostaria de pedir seu auxílio com o seguinte problema:
Duas notas foram geradas na madrugada de hoje (25/02) e receberam rejeição 212 da SEFAZ.
Na sequencia, o usuário tentou inutilizá-las pelo monitor J1BNFE, e ambas ficaram com o seguinte erro no GRC: Status de Erro 50 (Cancelamento/inutilização: erro de sistema PI) e status 212 (Rejeição: Data de emissão NF-e posterior a data de recebimento). Ao verificar os batchs, ambos estão com status de lote 05 (Resultado recebido) e código de status 104 (Lote processado). Entretanto, no R/3, as notas estão em processamento, e não atualizam.
Ao tentar executar o programa XNFEUPDATE_ERP_STATUS_DIAL, é exibido o erro "NFe XXX with document status C is not permitted to be resend to ERP".
Alguma ideia do que posso fazer para ter o processamento finalizado no R/3 ou qual é o motivo da rejeição?
Muito obrigada,
Daniella

... complementando...
2) Algumas considerações à título de exclarecimento:
> Duas notas foram geradas na madrugada de hoje (25/02) e receberam rejeição 212 da SEFAZ.
Fizeram uma NF-e com data posterior e a Sefaz recusou, talvez fosse até questão de 1 dia (vc disse madrugada) então esperar virar meia noite fazer um RESET e Enviar resolveria. Verifique as datas/horas que estão sendo geradas as notas talvez isso seja a causa raiz do seu problema. (Ex.: NF-e gerada no relógio às 23:10, o sistema entende que a nota foi criada no dia seguinte 00:10).
> Na sequencia, o usuário tentou inutilizá-las pelo monitor J1BNFE, e ambas ficaram com o seguinte erro no GRC: Status de Erro 50 (Cancelamento/inutilização: erro de sistema PI)
Esta é uma das opções do usuário e foi correta, o problema foi no processamento no GRC/Sefaz. Deve-se investigar: veja 1)
status 212 (Rejeição: Data de emissão NF-e posterior a data de recebimento).
Esta foi a última resposta recebida da Sefaz, porém não é relativa ao processo de Inutilização e sim ao de envio.
Ao verificar os batchs, ambos estão com status de lote 05 (Resultado recebido) e código de status 104 (Lote processado).
05 - O resultado foi de fato recebido, uma rejeição. Tá normal isso, rejeição é resultado
104 - Lote processado, mesmo que o anterior.
Observação: O lote só deve ser verificado nas situações de envio de NF-e, como a NF-e já está "noutra", inutilização, então deve-se focar somente no status da NF-e. Veja 1)
Entretanto, no R/3, as notas estão em processamento, e não atualizam.
Após recebeu o resultado do envio (rejeição), o usuario disparou um novo processo (inutilização) que está parado no GRC. Veja 1)
> Ao tentar executar o programa XNFEUPDATE_ERP_STATUS_DIAL, é exibido o erro "NFe XXX with document status C is not permitted to be resend to ERP".
Este report serve para retransmitir situações finais (status 05) para o ERP, porém esta NF-e encontra-se travada no processo de inutilização, sem resposta recebida. Veja 1).

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ó

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ó

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

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

Erro no processo de cancelamento/inutilização

Similar Messages

Maybe you are looking for