Status erro: 46 - NF-e 2.0

Masters of Sap Universe,
Estou com o seguinte problema com o GRC...
Aqui estamos com ambiente de GRC com SP15
No monitor do GRC:
Status do processo:05
Status erro 46 - Lote rejeitado pelo Processamento da Nota Fiscal Eletrônica /
Não existe erros na SXMB_MONI
Na tentativa de reiniciar o Lote, eles não aparecem nas abas de erro para tentar reinicalizar
Alguma ideia ?

Bom dia Fernando,
Estou com o mesmo problema.
No GRC apresenta o status do erro (46) que o lote foi rejeitado pelo processamento da NFe.
No monitor J1BNFE apresenta o erro 215 - Rejeição: Falha no Schema XML.
Ja fiz o procedimento no validador XML do RS e apareceu que o erro era o sinal na primeira linha. Com isso eu apaguei o sinal e validou.
O que devo fazer para resolver isso?
Obrigado
Júlio Meireles

Similar Messages

Duvida erros NFE

Olá,
Preciso de uma ajuda ,
Até ontem estava tudo rodando normal, porem hoje aconteceu o seguinte problema, temos configurado dois sefaz para envio de NFe PE e AL, porem hoje quando fomos tentar enviar notas para PE começaram a aparecer alguns problemas, o batch fica com o erro "42 - Nº máximo de consultas atingido" e a nota " 90 - Verificação de status: erro de sistema PI" e se tentar reenviar muitas vezes alguns lotes ficaram com "70 - Erro do Processamento da Nota Fiscal Eletrônica" e a nota destes "46 - Lote rejeitado pelo Processamento da Nota Fiscal Eletrônica"
fui na sxmb_moni procurar o erro que poderia ser lá, em apenas 1 dos 5 lotes que deram erro achei
SAP:Stack>Multiple receivers are not permitted in synchronous calls</SAP:Stack>
os demais lotes não tinham erro nenhum,
ja revi todas as configurações do directory e não encontrei nada estranho lá.
Bom... Isso foi mais ou menos umas 3 da tarde até umas 18 horas,
agora as 19 horas tentei reenviar os lotes pra ver de novo, e todos deram certo! e o erro não aparece mais, tudo isso aconteceu para o ambiente de homologação, será que tem algo configurado errado? ou pode ser alguma instabilidade que aconteceu aqui ou no sefaz?
Obrigado.

Pitoshi,
acho que a msg de erro que vc achou na MONI e os sintomas apresentados por vc sao relacionados a problemas distintos, pelo simples motivo de que se a causa do erro fosse a reportada pela msg da MONI, isto deveria estar causando um erro permanente e nao algo intermitente.
Provavelmente era erro da SEFAZ sim.
Qto à msg de erro, verifique para qual cenario ela aconteceu (BATCH, BATSR, SRVSC etc) e dai vá no Integration Directory e verifique o Receiver Determination que determina qual eh a SEFAZ recebedora relativo a esse cenario (a interface é algo que termina com "_SYNC"). Verifique se todas as conditions (baseadas em tpAmb e cUF) estao mapeadas corretamente; ele está reclamando que há mais de um possivel receiver para uma interface sincrona, entao pode ser que esteja faltando condicao para algum receiver.
Abs,
Henrique.

B2B - Cliente e Transportadora

Fizemos uma alteração na solução standard do B2B.
Na função que chama o Proxy, eu criei um enhancement-point para manipular o campo CNPJ para identificar qual o tipo de mensagem será enviada, no meu caso EMAIL Ou WebService, até ai OK.
O problema é que assim que manda o XML para o cliente eu estou também mandando para a Transportadora o XML, usando o mesmo Proxy e interface PI, repliquei a lógica standard para o envio para a transportadora. Quando ocorre algum erro no envio por email para o Cliente ou para a Transportadora, ex: email não cadastrado, e para o outro envio vai com sucesso o status no monitor do GRC fica com sucesso e eu não consigo reprocessar a mensagem que deu erro. Se os dois cadastros estão OK, ele manda com sucesso para os dois sem problemas.
Existe a possibilidade de caso der erro em algum, deixar com mensagem de erro no monitor do GRC para ser reprocessado posteriormente? Mesmo que uma das duas mensagens tenha ido com sucesso, melhor mandar duas vezes do que não mandar.
Como o cadastro do cliente é mais dinâmico do que o da transportadora, clientes temos mais de 2.000 e transportadoras 3, pensei em assim que executasse a Proxy da interface para o Cliente, tentar identificar se deu erro no Ack, se deu erro eu nem continuo o processo para a transportadora, porém não consegui identificar no código quando deu erro ou não.
Alguém tem alguma idéia?
Desde já, muito obrigado.

Olá Maicon,
sim, esse report é executado via job (schedulando o /xnfe/process_reports, que chama ele via submit).
Nao vai adiantar vc fazer o =>get_acknowledgement() logo depois de manda pois demora um pouco pra mensagem ser executada pelo Integration Engine, Mapping Runtime, Adapter Engine etc.; até dar o erro, vai ter um deltaT considerável. E fazer um while ack() vazio, wait 5seconds, é sacanagem, eheehehehe.
Por isso sugeri, se quiser modificar, que pense em modificar o proprio form get_acknow, pois ele é executado via job, e uma hora vc pega o ack.
Mas note que não necessariamente vc quer que o usuário restarte o B2B manualmente. Como vc mesmo observou, por ser uma interface ***íncrona, o próprio Adapter Engine faz retries automáticos de envio depois de 5 minutos do ultimo erro. Somente em caso de erro permanente é q faz sentido fazer o restart; esse "erro permante" vc pode observar vendo o status da mensagem no Mesage Monitoring do RWB (componente Adapter Engine). Infelizmente nao sei dizer se esse nível de detalhamento do erro volta no ack que vai pro Integration Engine, se voltasse seria o mundo perfeito, e daí vc poderia fazer um IF status = vai tentar de novo, nao joga erro no monitor (talvez faça sentido um status novo, algo do tipo "erro mas vai retentar enviar sozinho"), else status = erro permanente, daí vc joga erro no monitor pro usuário poder restartar.
Se nao vier no ack, daí vc ainda pode tentar pensar numa maneira de ler isso das tabelas do Adapter Engine, que eu pessoalmente nao manjo mas que deve ter alguma coisa no forum de PI.
Abs,
Henrique.
PS: pensei que seu 1o nome fosse Rosa, rs... Desculpe.

Error in submitting a new request on concurrent process managers

Hi
When I try to submit a new request 'Active Users' or 'Active Responsibilites and Users' , I get the phase as "completed" and the status "Erro"
I checked the log and found the following message:
Xlib: connection to "nmcretek01:0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
REP-3000: Internal error starting Oracle Toolkit.
REP-0069: Internal error
REP-57054: In-process job terminated:Terminated with error:
Program exited with status 1
Concurrent Manager encountered an error while running Oracle*Report for
your concurrent request 321832.
Some info about my platform and Server:
EBS R12 on AIX 5L, server name 'nmcretek01'
sigle node,single user Installation
Please advise what should be done!
thank you in advance

Jane,
Please verify the DISPLAY on the server as follows:
- Issue "xhost +" as root user
- Issue "xclock" as applmgr user --> Make sure you can display the clock
If the above does not work, please set the DISPLAY properly in the application context file and run AutoConfig.
More details can be found in the following notes:
Note: 364838.1 - Quick Checks for REP-3000: Internal Error Starting Oracle Toolkit
https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=364838.1
Note: 200474.1 - Comprehensive REP-3000 Troubleshooting and Overview Guide
https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=200474.1

SAP NFe GRC XML 3.10 - Erro no envio do lote - Status 2

Pessoal, bom dia!
Configuramos os cenários para a versão do xml 3.10 da NFe porem ao criarmos a NFe (saída) o lote foi gerado porem ficou parado no status 2 (Enviado ao PI) com o erro 38 (Web Service não acessivel) ao clicarmos na descrição do erro é exibida a seguinte mensagem:
"Service Status not identified: Job /XNFE/NFE_CHECK_SRV_STATUS is not running or customizing is mi"
O job /XNFE/NFE_CHECK_SRV_STATUS está agendado a cada 2 minutos para teste com o estado 29 (BA) e foi configurado na SPRO NF-e: definir consulta para status de serviço das autoridades (SEFAZ) conforme abaixo:
Foram agendados os seguintes jobs para a versão 3.10
/XNFE/EVENT_BATCH_SEND
/XNFE/GET_ACKNOWLEDGMENT
/XNFE/NFE_B2B_SEND
/XNFE/NFE_BATCH_CREATE
/XNFE/NFE_BATCH_REQUEST
/XNFE/NFE_CHECK_SRV_STATUS
/XNFE/NFE_CONTINUE_PROCESS
/XNFE/NFE_SKIP_SEND
/XNFE/PROCESS_REPORTS
/XNFE/UPDATE_ERP_STATUS
Alguem já passou por este problema no lote? Alguma dica para soluciona-lo?
Abraços,
Halsen Nagasawa

Alan,
Realmente o erro era na SEFAZ BA, o XML de envio e retorno do serviço NfeStatusServico difere das outras SEFAZ.
Para solucionar criei um ZSLL-NFE e inclui um javamapping no request e outro no response do operation mapping SRVSC_nfeStatusServicoNF2_TO_nfeStatusServicoNF2SoapIn para modificar as tags conforme o modelo de XML informado pelo pessoal de desenvolvimento da SEFAZ BA.
Abaixo o modelo informado pela SEFAZ BA.
O XML do cabeçalho para utilização dos WebServices da SEFAZ-BA na versão 3.00/3.10 é o seguinte:
<?xml version="1.0" encoding="UTF-8"?>
<nfeCabecMsg xmlns="http://www.portalfiscal.inf.br/nfe" versao="3.10">
<versaoDados>3.10</versaoDados>
<cUF>29</cUF>
</nfeCabecMsg>
E o XML da solicitação ao WebService de StatusServico na versão 3.00/3.10 é o seguinte:
<?xml version="1.0" encoding="UTF-8"?>
<consStatServ xmlns="http://www.portalfiscal.inf.br/nfe" versao="3.10">
<tpAmb>2</tpAmb>
<cUF>29</cUF>
<xServ>STATUS</xServ>
</consStatServ>
Att.
Halsen Nagasawa

NF-e 3.10 - Erro 204 - Duplicidade - Botão consulta status

Boa tarde a todos.
Estamos em fase de testes do projeto de implementação do XML 3.10.
Eu tive algumas notas no meu ambiente de teste integrado com rejeição 204 (duplicidade de nota).
Eu preciso realizar a consulta de status para essas notas, porém no botão Outras Funções, não aparece a opção Verificar Status (conhecido como Consulta de Status no monitor 2.00).
Eu encontrei o seguinte post relacionado ao meu problema:
NFe V3.10 Erro 204 - Duplicidade - Botão Consulta Status sumiu
Porém, o procedimento de "Continuar Processo" descrito no post acima não resolveu meu problema (quando dou um Continuar Processo, o GRC tenta enviar novamente a nota para aprovação).
Alguém sabe como faço para o botão de consulta de status aparecer? Seria algo de perfil?
Att,
Matheus Goulart

Então Ricardo, na verdade não tem botão de consulta de status no detalhe.
Acebei de descobrir que o Continuar Processo funcionou, o problema é que a consulta de status foi rejeitada pela SEFAZ (sefaz MG).
E o motivo que no monitor não atualizou os status das notas, é porque deu um erro no proxy inbound.
Mensagem da SPROXY:
Falta elem.'{http://www.portalfiscal.inf.br/nfe}dhRecbto'
XML (retorno):
<?xml version="1.0" encoding="utf-8" ?>
- <nfeConsultaNFResponse xmlns="http://sap.com/xi/NFE/008">
- <nfeConsultaNF2Result>
- <retConsSitNFe xmlns="http://www.portalfiscal.inf.br/nfe" versao="3.10">
<tpAmb>2</tpAmb>
<verAplic>13_2_28</verAplic>
<cStat>217</cStat>
<xMotivo>Rejeicao: NF-e nao consta na base de dados da SEFAZ</xMotivo>
<cUF>31</cUF>
<chNFe>31140940432544011262550160000014241463324953</chNFe>
</retConsSitNFe>
</nfeConsultaNF2Result>
<n0:mode xmlns:n0="http://sap.com/xi/NFE/008">O1</n0:mode>
</nfeConsultaNFResponse>

Erro retorno do status do lote

Boa tarde a todos.
Estou passando pela seguinte situação, ao emitir uma NFE a mesma é enviada para a SEFAZ e retornada com o erro 215 - Rejeição: Falha no esquema XML. O problema é que este erro fica apenas no monitor do lote da nota, ele não é atualizado no monitor da nota(a nota fica esperando resposta do lote) e consequentemente não retorna ao ECC. O estado de emissão é PE - Pernambuco e ambiente de Homologação. Alguem já passou por esse problema? Segue em anexo um arquivo com os prints.
Algumas verificações já realizadas.
- JOBs estão todos OK
- Filas (SMQ1 e SMQ2) estão OK
Muito Obrigado a todos
Raphael Trivelati

Existem varios problemas que podem acarretar esse erro, cada um diferente para cada etapa de "gestao" da mensagem do lote.
Uma solução que vc poderia verificar é se as NFes contidas nesse lote estao aprovadas no SEFAZ, se estao, basta vc finalizar o processamento do lote e em cada uma das NFes que nele estavam contidas solicitar a verificacao do status da nota.
O que esta ocorrendo muito após o dia 01/04, são falhas na interpretação do cabeçalho da nfe por parte da SEFAZ.
Vc precisa verificar também se o seu cenario BATCH e BATSR estao configurados para a versao 3.1

Erro - Verificação de Status do Serviço

Bom Dia a Todos,
Está ocorrendo o seguinte erro ao solicitar a verificação do status do serviço no ambiente de homologação da SEFAZ-MG:
<SAP:Code area="PARSING">ADAPTER.SOAP_EXCEPTION</SAP:Code>
<SAP:P1 />
<SAP:P2 />
<SAP:P3 />
<SAP:P4 />
<SAP:AdditionalText>soap fault: Unexpected Error java.lang.NoClassDefFoundError at br.inf.portalfiscal.nfe.controller.ValidaDadosStatusServico.validaDadosStatusServico(ValidaDadosStatusServico.java:19) at br.inf.portalfiscal.nfe.controller.ValidacaoXMLHelper.validaDadosStatusServico(ValidacaoXMLHelper.java:324) at br.inf.portalfiscal.nfe.controller.UtilSession.processaNfeStatusServico(UtilSession.java:1558) at sun.reflect.GeneratedMethodAccessor134.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.invoke(LogInterceptor.java:205) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136) at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:648) at org.jboss.ejb.Container.invoke(Container.java:954) at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:430) at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103) at $Proxy73.processaNfeStatusServico(Unknown Source) at br.inf.portalfiscal.nfe.wsdl.nfestatusservico.NfeStatusServicoImpl.nfeStatusServicoNF(NfeStatusServicoImpl.java:73) at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.xfire.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:59) at org.codehaus.xfire.service.invoker.ObjectInvoker.invoke(ObjectInvoker.java:45) at org.codehaus.xfire.service.binding.ServiceInvocationHandler.sendMessage(ServiceInvocationHandler.java:320) at org.codehaus.xfire.service.binding.ServiceInvocationHandler$1.run(ServiceInvocationHandler.java:86) at org.codehaus.xfire.service.binding.ServiceInvocationHandler.execute(ServiceInvocationHandler.java:134) at org.codehaus.xfire.service.binding.ServiceInvocationHandler.invoke(ServiceInvocationHandler.java:109) at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131) at org.codehaus.xfire.transport.DefaultEndpoint.onReceive(DefaultEndpoint.java:64) at org.codehaus.xfire.transport.AbstractChannel.receive(AbstractChannel.java:38) at org.codehaus.xfire.transport.http.XFireServletController.invoke(XFireServletController.java:304) at org.codehaus.xfire.transport.http.XFireServletController.doService(XFireServletController.java:129) at org.codehaus.xfire.transport.http.XFireServlet.doPost(XFireServlet.java:116) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at br.inf.portalfiscal.nfe.util.manipulaXml.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:106) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595)</SAP:AdditionalText>
Alguém já passo por essa situação e pode por favor esclarecer qual o motivo deste erro?
Agradeço antecipadamente!

Bom dia Guilherme,
Este erro foi gerado pela Sefaz MG, repare que as classes não são do PI (jboss, apache, tomcat, catalina). Contacte a Sefaz para maiores detalhes, deve ser algum erro temporário.
De sua parte é importante você se certificar que estava funcionando.... e parou de funcionar, ou melhor, que você está fazendo o pedido corretamente. Veja no SXI_MONITOR sua mensagem saindo pra Sefaz se está tudo ok.
Atenciosamente,
Fernando Da Ró

ERP STATUS 109 - Erro de Validação

Boa Noite ,
Estamos Implementando NF-e no Cliente e estamos com problema no momento de inutilizar qualquer NFE que foi reprovada pelo validador interno do GRC (Bandeira Vermelha e Engrenagem na J1BNFE) , no ambiente de DEV esta funcionando OK , em QAS ocorre o problema. Estamos a alguns dias do Go-Live e esse é o unico erro critico que estamos encontrando no Projeto.
O Fluxo de aprovação da inutilização esta ok , retorna para o GRC , mas nao atualiza a tabela J_1BNFE_ACTIVE no ECC, acusando o erro ERP 105 ou 109 no monitor do GRC
Ja haviamos realizado a aplicação das notas abaixo , conforme indicaçao do Henrique Pinto e Fernando Ros em outros Threads.
1413636 - Status bandeira vermelha após Skip NFe. (Nãqo lembro da descrição correta)
1376324 - NF-e: Skip for NF-e with validation error
1298283 - NF-e: Skip for NF-e with validation error
1376901 - Skip for validation error
Alguem ja teve que brigar com esse problema ??? Poderiam nos ajudar ???
Grande abraço a todos,
Rafael Medice

Bom dia Rafael,
Ao que parece está faltando algumas coisas na sua implementação:
105 - refere-se aos objetos NF-e estarem bloqueados no R/3 quando o GRC envia a resposta do processamento, então é provável que vocês não tenham implementado o decouple. Verifique na J_1BNFE_ACTIVE se estão com CALLRFC=vazio, se estiver não está implementado. Solução: Procure pelas notas e no fórum tem vasto material sobre isso.
109 - quando o status que o GRC está enviando é incompatível com o status que o ERP aguarda. Isto pode até estar associado ao anterior, mas o mais comum é a falta de tratamento na impressão automática ou qq coisa que implementaram no método CALL_RSNAST00 da BAdI CL_NFE_PRINT. A SAP Note 1470484 evita o 109 numa retransmissão do mesmo status de Sefaz, porém você deve revisar seus códigos. Procure por exemplos de código aqui no fórum também.
Observação: Verifique TODAS as notas XX-CSC-BR-NFE para o seu ambiente, TODAS são necessárias. Sendo que as mais recentes deve-se planejar pois envolvem também o layout 2.0.
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.

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 NF-e: Status do Processo: 04 / Status de erro: 38

Senhores(as);
No meu cliente estava com erro de certificado digital:
Stat.processo: 02 Enviado ao serviço de assinatura digital / Status de erro: 25 Assinatura digital NF-e: erro de aplicativo PI
Verifiquei o Certificado Digital e havia expirado. Instalei o novo e agora as NFe estão:
Stat.processo:04 Incluído no lote / Status de erro: 38 Lote: Web Service não acessível
Suspeitei de erro no endereço da webservice, mas aqui me garantiram que antes de chegar ninguém mexeu em nada, e como funcionava antes...
Alguém poderia me ajudar ? Pois esta ocorrendo em produção
ECC 6.0 SPK 9
VIRSAHR     530_700     0016     SAPK-53316INVIRSAHR     SAP GRC Access Controls 5.3 for 700 HR S
VIRSANH     530_700     0018     SAPK-53318INVIRSANH     SAP GRC Access Controls 5.3 for 700 HR a
SAP NetWeaver 2004s
SLL-NFE     100     0020     SAPK-10020INSLLNFE     xNFE 1.0
Desde já agradeço a todos...

Olá José Aguilar,
Verique primeiramente se o seu certificado está ok.
Veja o wiki indicado pelo Nanim_es na outra thread sobre outro assunto:
Erro busca Status SEFAZ
Att,
Bruno Xavier.
Edited by: Bruno Xavier on Jan 26, 2012 4:36 PM

GRC NF-e 2.0 - Status de Serviço com Erro

Boa noite Srs,
Estamos recebendo um erro no cenário SRVSC_WebAS_Outbound_ServiceStatusCheck.
No NF-e Monitor o Status de Erro é 70 (Error from the authorities). Verifiquei a MONI e encontrei a seguinte mensagem:
/CPACache/refres...
CPA cache refresh (mode=full) successfully executed in 1607 milliseconds.*
Estamos no SLLNFE 16 do XI Content e SAP_APPL 604/07 do ERP; Nossa versão do PI é a 7.0.
Alguém teria alguma dica que pudesse nos ajudar a resolver este erro.
Grato,
Ricardo

Marlo, obrigado por sua resposta!
Refiz novamente todo o cenário de StatusServico, e todos os conditions estão perfeitamente setados, conforme exemplo de São Paulo abaixo:
Condition Homologation: (/p1:nfeStatusServicoNF2/p1:cUF = 35 AND /p1:nfeStatusServicoNF2/p1:tpAmb = 2)
Condition Production: (/p1:nfeStatusServicoNF2/p1:cUF = 35 AND /p1:nfeStatusServicoNF2/p1:tpAmb = 1)
Para todos os outros estados utilizei a mesma regra citada, com exceção ao cenário BATCH, que segui conforme o PDF da nota 1465726 que utiliza o tpEmis (diferente de 3).
Estou fazendo um refresh no sld e reiniciando o server para ver o que acontece...rs
Mais alguma outra dica?
Grato,
Ricardo

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).

105 lote esta processando - Erro 40 de sistema de PI - Batch Status Query

Prezados,
Nós temos um lote em GRC com os detalhes seguintes código de estado - 105 lote esta processando.
Nós temos um lote em GRC com os detalhes seguintes:
- Código de estado: 105 "lote esta processando"
- Estado de lote: 04 "pedido enviou"
- Estado de Error: 40 questão de estado de lote: Erro de sistema de PI"
Reiniciando o lote por monitor de GRC resulta em um erro "Erro processo inicial Envie Lote (lote ID 000000000013825)"
Algumas ideas ou sugestoes para proceder?
Obrigado
Marc de Ruijter
Key words for thread search:
- Error status 40 Batch status query: PI system error
- Batch status 04 request sent
- Status code 105 batch being processed

Creio que estou com o mesmo problema,
Estou com um lote com erro no status 5 mensagem "Consulta de status de lote: erro de sistema PI" e ao reiniciar o lote encontro a mensagem a abaixo:
"Erro ao inicializar o processo Enviar lote (nº de lote 000000000000XXX)".
Na sxi_monitor do PI não apresenta erro nenhum!! eu conferi a tabela citada na thread e tinham vários registros e um deles referente ao meu lote. Apaguei apenas o referente ao meu lote porem ainda não reinicia.

Status erro: 46 - NF-e 2.0

Similar Messages

Maybe you are looking for