GRC10.0 - Estorno contingência - Ação não permitida

[Former Member]

Boa tarde pessoal!

Estou efetuando o upgrade de um GRC 1.0 para 10.0, e até o momento todos os testes estão sendo efetuados com sucesso. Porém ao testar a contingência, estou enfrentando problemas para estornar o documento comutado. O teste está sendo feito da seguinte forma:

1. Paro os communication channels da SEFAZ;

2. Assim que o status muda para offline, crio uma ordem de venda no ERP;

3. O documento original falha com erro 38: Web Service indisponível;

4. Comuto e gero uma nova ordem de venda em contingência. Também cancelo a fatura original.

5. Retorno a comunicação com a SEFAZ;

6. Reenvio a nota em contingência: Envio com sucesso a SEFAZ, ERP atualizado com sucesso;

7. Tento estornar o documento original.

Ao tentar estornar o documento original, eu recebo o seguinte erro e continua com a engrenagem:

"Solic.elim.p/NF 000xxxxxxxxx não permitida p/stat.documento "Aguardar resposta" e status sistema "Processamento mudado para modo de contingência"

No GRC, ao executar o /XNFE/ERP_UPDATE_STATUS_DIAL, o seguinte erro retorna:

"A NF-e XXXXX com status de documento A não pode ser reenviada ao ERP."

Status no GRC: DOCSTAT = A  / SCSSTAT, STATCOD e AUTHCOD estão vazios

Monitor (nfe_monitor_new) : Lote: Web Service não acessível (38)

No ERP (j1bnfe):

SCS : 5

SSM: A

Comutado p/ contingencia: X   /  Estornado: X  (ele aparece como estornado... mas não atualiza status);

"Etapa do processo", "Status do doc.", "código status": vazios

Alguém já passou por um problema semelhante? Não estou conseguindo efetuar o estorno do documento original, apenas se eu mudar o status na mão no ERP para poder reenviar o documento

Grato pela atenção,

Lucas Santos

[former_member182114 · Accepted solution]

Bom dia Lucas,

Status no GRC: DOCSTAT = A  / SCSSTAT, STATCOD e AUTHCOD estão vazios
Monitor (nfe_monitor_new) : Lote: Web Service não acessível (38)

Reinicie o lote pelo monitor de lote que ele será enviado para Sefaz e autorizado.

Atenciosamente, Fernando Da Rós

[Former Member · Accepted solution]

Oi, bom dia Da Ros,

Então quer dizer que sempre quando comutarmos uma nota em contingência e, posteriormente, quando a SEFAZ retornar, formos cancelá-la na SEFAZ, a nota ficará presa, com erro no lote no GRC ? Daí temos que manualmente reiniciar o lote no GRC ?

Grato,

Ruy

[former_member182114 · Accepted solution]

Bom dia Ruy,

Não é exatamente por causa do comutar pra contingência em si mas pela situação de problema na Sefaz.

Não. Como o ERP passou a "perguntar" ao GRC como está o status da Sefaz e se não estiver 107 nem irá numerar no ERP a nota nem seria enviada ao GRC.

Sim. Se a nota já foi numerada e enviada ao GRC e o status está inativo (diferente do 107) o lote ao ser criado nem será enviado ficando neste status 01/38 precisando ser reiniciado manualmente.

Sim. Mesmo que o status da sefaz no GRC estiver como 107, pode ser que a Sefaz irá parar também precisando ser reiniciado manualmente.

Observação: Se ao reiniciar o lote, o status da Sefaz ainda não estiver ok (107) então o lote não será reiniciado.

Atenciosamente, Fernando Da Rós

[Former Member · Accepted solution]

Ok, obrigado pelo retorno.

Então não tem jeito mesmo, iremos continuar trabalhando com o programa Z e Job, reiniciando o lote quando a SEFAZ tiver on line de novo. Isso evita a intervenção manual do usuário no monitor de lote no GRC.

abraço

Ruy

[former_member182114 · Accepted solution]

Bom dia Ruy,

Sim, para automatizar este processo só via job Z.

Só recomendo que no desenvolvimento Z tenham o cuidado de prever um "timeout" ou "número de tentativas" para restart para evitar um "automático" overflow do sistema impactando os outros lotes de Secretarias que estão bem. Teve essa discussão ano passado por aqui, não achei pra linkar agora.

Atenciosamente, Fernando Da Rós