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.

Similar Messages

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

Erro "B2B: erro de sistema PI"

Olá a todos. Aplicamos a versão 2.0 do GRC, Support Package 15 e após isso, quando uma Nota Fiscal é cancelada, o cliente não recebe o XML desse cancelamento, apresentando um erro no GRC como: B2B: erro de sistema PI. Nessa nova versão esse envio é obrigatório. Alguém já passou por esse erro? Tem alguma idéia do que pode ser?
Obrigado a todos que puderem ajudar
Marcos Cristiano Ickert
Basis

Marcos,
Alem de configurar o Cenário para o novo namespace 006, no Design para o Produto/SWCV usado o B2B você precisa alterar o Interface Mapping(7.0)/Operation Mapping(7.1) de Envio(NTB2B_procNFe_TO_procNFe)/Cancelamento(CTB2B_procCancNFe_TO_procCancNFe) para o namespace 006, assim como já deve estar para a versão 005a.
(isso apenas para os objetos do seu produto/swcv)
OBS.: caso vocês utilizem a solução igual ou parecida com o que Henrique postou no forum.
E caso você precise reiniciar esse erro de B2B no GRC, como você está SPK 15 será necessário aplicar a nota 1512936 para tirar o dump que gera.
Espero que ajude.
Abraço,
Bruno Lima

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

Status de erro 36 - Lote: erro de sistema PI

Prezados, bom dia.
Durante as chuvas de ontem em São Paulo caiu a conexão de internet da empresa e ficamos com alguns lotes de notas com status de processo incorreto.
Status de lote 02 - Enviado ao PI
Status de erro 36 - Lote: erro de sistema PI
Já tentei reinicializar a atualizar os lotes no GRC porém nenhum resultado.
Alguem pode ajudar ?
R3 6.0 e ainda NÃO estamos na NFe 2.0
Tks,
Rodrigo Vieira

Olá Rodrigo,
no monitor de lotes, aba "erro de envio", os lotes aparecem disponíveis para reenvio?
Selecione-os e clique em reenviar (ou restart, ou whatever).
Abs,
Henrique.

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ó

ERRO NO SISTEMA , NÃO CARREGA

O Sistema Não Carrega, e quando consegue desconecta-se Sozinho, as pessoas não conseguem conectarse ao formulário,fica carregando o tempo todo ?? O que eu faço ??? estou o dia todo com este problema.

Olá,
Nós ter corrigido o problema. Por favor, tente novamente. Pedimos desculpas por quaisquer incoveniences que isso pode ter causado.
Lucia

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.

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.

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ó

Cancelamento Extemporâneo NF-e MS

Pessoal, boa tarde!
Estou enfrentando o seguinte problema em um cliente:
A NF-e foi emitida e autorizada em 01/2014. A mercadoria não circulou e a solicitação é que o cancelamento seja feito neste mês.
Informaram a SEFAZ e, inclusive, pagaram a taxa e obtiveram autorização para este cancelamento.
O problema acontece no momento de tentar solicitar o estorno via monitor J1BNFE. Pelo fato do período contábil de janeiro já encontrar-se encerrado, o sistema não permite o envio deste cancelamento (Mensagem de erro: Período de lançamento 001 2014 já está encerrado).
Minha sugestão foi para que fizessem uma NF-e de Devolução à esta saída. No entanto, eles me informaram que a consultoria tributária que presta serviço para a empresa proibiu esta prática. Disseram que este procedimento não é legal e que o cancelamento extemporâneo é o que deve ser feito neste caso.
Diante disso, tenho alguns questionamentos:
1) Existe alguma maneira de solicitar este cancelamento via monitor J1BNFE, sem a necessidade de se mexer no período contábil?
2) O processo de Devolução à Saída realmente não é uma boa prática?
Agradeço desde já a ajuda!
Att.

Boa noite, Karen!
Obrigado pelo retorno.
Pelo que pesquisei mesmo após o prazo de 24 horas ainda é possível realizar o cancelamento. Não sei se isto se aplica em todos os estados. Em SP, por exemplo, a regra é a seguinte:
Após o prazo regulamentar de 24 horas da autorização de uso da NF-e, os Pedidos de Cancelamento de NF-e transmitidos à Secretaria da Fazenda serão recebidos via sistema até 480 horas da Autorização de Uso da NF-e, porém neste segundo caso o emitente fica sujeito à penalidade prevista no item z1 do Inciso IV do artigo 527 do Regulamento do ICMS.
Após este prazo de 480 horas da autorização de uso da NF-e, a NF-e pode ser cancelada somente com a aprovação do Posto Fiscal de vinculação. O pedido deve ser acompanhado da:
1. chave de acesso da NF-e a ser cancelada extemporaneamente;
2. folha do livro Registro de Saídas e/ou Entradas, correspondente ao lançamento da operação ou prestação ou declaração de que faz uso da EFD (Escrituração Fiscal Digital);
3. comprovação de que a operação não ocorreu:
declaração firmada pelo representante legal do destinatário/remetente paulista da NF-e de que faz uso da Escrituração Fiscal Digital ou, não sendo este o caso, declaração firmada pelo representante legal do destinatário/remetente paulista da NF-e que não ocorreu a operação e de que não utilizou como crédito o valor do imposto registrado no documento fiscal ou;
tratando-se de pedido que envolva estabelecimento situado em outra unidade da Federação, cópia de correspondência entregue pelo destinatário à repartição fiscal do seu domicílio, em que declare que não utilizou como crédito, ou que estornou, a quantia restituenda ou compensada.
A resposta do pedido será enviada via Domicílio Eletrônico do Contribuinte - DEC.
Após a autorização do Posto Fiscal de vinculação, o emitente da NF-e deve transmitir o cancelamento da NF-e como evento, via sistema, dentro do prazo de 15 dias.
No caso de MS, eles também permitem o cancelamento desta maneira. O Fiscal, inclusive, informou a SEFAZ sobre o caso, efetuou o pagamento da taxa (DAEMS) e já obteve a autorização para o cancelamento.
No entanto, a dúvida está mesmo por conta do erro no momento de solicitar o estorno via monitor. Ao realizar este procedimento, o erro de período encerrado barra o envio para o GRC e SEFAZ. Para enviar o cancelamento, o período de janeiro terá de ser aberto, e meu receio está justamente neste ponto.
De qualquer maneira, agradeço as informações. Vou alinhar melhor com o pessoal do Fiscal/Contábil e verificar a melhor maneira de resolver o problema. Assim que tiver uma definição, compartilharei aqui para ajuda-los caso passem por situações semelhantes no futuro.
Abs!

Descrição dos Erros de Lote.

Boa tarde a todos.
Gostaria de sugestões e opiniões.
Atualmente esta cadastrado no domínio /XNFE/ERROR_STATUS as seguintes descrições para os erros:
36 - Lote: erro de sistema PI
37 - Lote: erro de aplicativo PI
40 - Consulta de status de lote: erro de sistema PI
41 - Consulta de status de lote: erro de aplicativo PI
etc...
Problema é que, para usuarios inexperientes (muito comum), tudo é problema de PI - o que gera inumeras reclamações/duvidas/chamados.....quando o problema é, em 99,9% das vezes, na SEFAZ.
É desaconselhado alterar estas descrições? Por exemplo: para erro 40 colocar: Consulta de status de lote: erro na SEFAZ
At.,
Bernardo Tavares Braga

Bom dia Bernardo,
Sim, é desaconselhável modificar estas descrições. A cada suporte package você teria que analisar as mudanças feitas no standard (podem existir) e refazê-las em seu sistema (inclusive as traduções).
Sobre o erro a mensagem está correta ao informar que o erro "está" no PI não que seja do PI. O que acontece é que o GRC (aplicativo) não tem como saber o que aconteceu de errado dentro do PI.
Solução: Treinamento e paciência. Faça um guia (pps ou pdf ou intranet) ilustrando o que fazer para os principais problemas explicando possíveis causas.
Espero ter ajudado.
Atenciosamente, Fernando Da Ró

Cancelamento/inutilização: erro de sistema PI

Similar Messages

Maybe you are looking for