Sent to signature service e Sent to PI

[Former Member]

Senhores, gostaria de por em pauta um assunto:

Ontem a stack java do meu GRC travou, foi necessário fazer um shutdown dela.

Consequentemente, todas as notas emitidas durante este período não foram assinadas, ficaram com status "sent to signature service".

Acontece que, depois da stack java ja estar no ar, eu tive que alterar as notas uma a uma, adicionando um status de erro de assinatura, para então poder reprocessa-las. O problema era que eram quase 200 notas e tive que alterar na mão (marretaço na SE11), uma a uma. Enquanto isso, os caminhões estavam parados, aguardando essas notas.

Minha questão é: Seria possível a SAP criar um mecanismo que alterasse o status dessas notas automaticamente? Tipo como acontece quando o governo está fora, que ele tenta 5 vezes e depois muda o status para erro.

O mesmo poderia ser feito com as notas que ficam com status sent to PI e não são encontradas na SMQ2(Neste caso, poderia ser feita uma validação do tipo, notas que estão com status Sent to PI há mais de 30 minutos, troca o status para erro de PI.

E a mesma solução acima também poderia ser utilizada para notas que travam com status result received.

O que acham?

[Former Member]

Pessoal boa noite,

Sei que faz muito tempo esse assunto mas estou com esse problema, a NFE esta com Sent to Signature Service e não gerou o batch como posso resolver isso, ja verifique no monitor e aparentemente esta ok.

Aguardo

Heliton

[Former Member]

Bom dia.

Verifique se o JOB que executa o programa /XNFE/PROCESS_REPORTS esta em execução no GRC.

• Alessandro, não esqueça de marcar a thread como respondida *** apesar de não ser bem uma pergunta.

At.,

Bernardo Braga

[Former Member]

Bernardo bom dia,

Sim esta executando normal, nenhum log de erro.

At.

Heliton

[former_member182114]

Bom dia Heliton,

Por favor cria uma nova thread, e descreva tudo que você já verificou e como está o problema agora.

@Alessandro, poderia encerrar esta sua thread.

Atenciosamente, Fernando Da Ró

[henrique_pinto]

Alessandro,

sao coisas diferentes.

O GRC só faz retry da verificacao do lote caso volte um status 105 (= "lote em processamento") da SEFAZ.

Ou seja, é um status previsto pela aplicacao, e nao é erro, pois é uma msg repassada com sucesso (vc nao vê bandeira vermelha no PI).

Caso haja um erro na aplicacao (nesse caso, entenda-se SEFAZ ou assinador, depende do cenario), entao o GRC consegue sim identificar que houve um erro e propagar essa informacao de volta ao requester (o GRC), através de um negative acknowledgement. Isso seria um "application error".

Já o caso que vc citou, seria um "system error", relacionado a problema da instancia, banco etc. Neste caso, é impossível prever o comportamento do sistema, pois dependendo do erro ele nao vai conseguir nem mais inserir entradas num banco (e atualizar status = inserir/updatar entradas no banco). Note que, no exemplo que vc deu, se o erro no stack Java acontecesse no momento da comunicacao com a SEFAZ, vc tb nao teria nenhum retorno pro lote, e ficaria com um lote no status 02 ou 04 no limbo, e teria que da mesma maneira atualizar os status de lote na mao, pra poder reprocessar..

Um "system error" é um processo mais complicado de resolver de maneira standard todas as situacoes possíveis de acontecer.

De qq maneira, um report que atualizasse duma vez uma pancada de nota seria interessante.

Mas isso vc pode desenvolver na mao, mas é sempre perigoso ter essas coisas pois acabam acomodando. Rs...

O ideal é evitar as causas de tais problemas (fazendo um melhor housekeeping em seu PI).

Mas isso tudo é apenas a minha humilde opiniao de consultor...

Abs,

Henrique.

[former_member182114]

Bom dia Alessandro,

O que o Henrique mostrou é recorrente entre os utilizadores de GRC NFE, algumas vezes por não existir uma cultura PI / Java na empresa e leva um tempo até acostumar.

Mas a idéia é essa mesmo, da mesma forma que o ERP fica esperando o GRC, o GRC fica esperando o PI, que por sua vez fica esperando o Java. Então o problema tem SEMPRE que ser buscado e concertado no ponto onde deu o problema e não antes.

Quando tiver que fazer shutdown/restart procura deresgistrar as filas e aguadar o fim dos processamentos. No caso da instância ABAP do GRC também é interessante parar o job decouple no R/3 para represar as transmissões.

Detalhes aqui: 870864 Starting and Stopping an XI 3.0 / PI 7.0 System

Para o seu caso, é bem provável que o trabalho manual tivesse sido evitado.

Atenciosamente, Fernando Da Ró

[Former Member]

Blza, concordo com vocês com relação aos passos a serem tomados na hora de resolver um problema, com certeza o que deve ser atacada é a raiz do problema, não adianta nada eu alterar o status de um nota e amanhã enfrentar a mesma situação.

Mas minha preocupação é com o tempo que essas tarefas tem demandado(tempo este que muitas vezes não temos), pois vejam bem, quando tive este problema, tive que colocar a equipe PI para trabalhar na stack java, enquanto eu voltava os status um a um. Se essas notas já possuissem um status de erro, o próprio usuário poderia reprocessá-las assim que o sistema voltasse ao normal, com isso, eles saberiam exatamente quais notas tem prioridade e minimizariam o prejuizo. Claro que isso não resolve 100% do problema, mas estamos falando de sistemas eletrônicos e problemas sempre ocorrerão, portanto não adianta ficar lamentando um atraso, temos é que tentar minimiza-los ao máximo.

Não sei se é uma regra geral, mas minhas notas não levam mais que 5 minutos para serem processadas. Não seria uma boa idéia a criação de um job que verificasse notas que estão paradas há mais de 10 minutos e mudasse o status dela para erro? Possibilitando ao usuário reprocessá-las via monitor do GRC?

Att

Alessandro La Rocca Silveira

[Former Member]

Estimado,

as sugestões são boas. Isto facilitaria muito em algumas situações. Mas vou deixar o fernandão responder esta, pois ele é o GRC guy!!!

Abraços