/XNFE/UPDATE_ERP_STATUS

[Former Member]

Pessoal estou com um problema, minhas notas não estao recebendo resposta do grc. No grc aprova mais no ERP fica a (catraca) meu job esta rodando normal /XNFE/UPDATE_ERP_STATUS, so da certo quando eu vou manual e coloco o ID, se eu rodar sem o ID nao atualiza no ERP, alguem pode me ajudar ????

atenciosamente

Gustavo

[Former Member · Accepted solution]

Claro Fernando, não vou mandar nota para o sefaz PROD, por isso mesmo eu mandei uma que ja existia, queria apenas verificar se o sistema estava comunicando perfeitamente, mais ja que vc falou q o 204 a menssagem não vai automatica para o ERP era essa a confirmação, pois n tem como fazer um teste pois o ambiente é de PRD a não ser q eu aumente o range mando uma nota e depois cancelo a nota que vc acha ????

[former_member182114 · Accepted solution]

Se você mandar uma nota para Sefaz produtiva neste ambiente deixando autorizada ou cancelando, esta nota não existe no seu sistema ATUAL, então como o seu sistema atual vai conseguir reportar esta nota nos livros fiscais?

Não faça isso, até por que você já testou o envio de nota, este 204 é uma resposta válida... Só não deu 100 pq já existe. Pelo que você comentou seu sistema está comunicando 100%, afinal você testou SIGNN, BATCH, BATSR, SRVST, NFESC... só faltou os cancelamentos... Do ponto de vista comunicabilidade está tudo ok, inclusive ao ERP que funcionou sem problemas com o report de retransmissão.

Do ponto de vista mensageria rejeição também é uma resposta OK.

Se você quiser simular o OK no ERP, para testar DANFE e post processing, simule o retorno com a autorização 100 e o MSGTYP=1 + protocolo de autorização na J_1BNFE_XML_IN_TAB.

Atenciosamente, Fernando Da Ró

[Former Member]

Uma Dica Pessoal.

Se o seu ERP está em Portugues...mesmo que seu Usuário RFC esteja como PT em Idioma de Logon,

Você deve preencher o PT na tela da SM59 na RFC tambem.

Pois se não pode dar erro nos campos de valores das tabelas.

Pois é pessoal eu sofri com isso abraço a todos.....

[Former Member]

Desculpa, é a correria aqui queria apenas agradecer ao pessoal que me ajudou.

[henrique_pinto]

Tranquilo.

Abs,

Henrique.

[Former Member]

OBRIGADO A TODOS.

[henrique_pinto]

Reinaldo,

evite a utilizacao de caps lock no fórum, por favor, pode parecer rude a quem lê.

Abs,

Henrique.

[Former Member]

Entao, so para finalizar É NORMAL ENTAO FICAR COM A CATRAQUINHA, NESTE CASO ???POIS A NOTA JA EXISTE NE.....MAIS BLZ ENTAO, QUANDO FOR A DATA DO MOVE DO DATACENTER VOU RESTAURAR OS BACKUPS JA COM A PLENA CERTEZA Q NOSSO GRC ESTA BLZ.

[former_member193386]

Sim é normal.

[Former Member]

BLZ, JA VEJO Q VCS JA ENTEDERAM MEU PROBLEMA, PQ ESTOU APENAS TESTANDO E QUERIA TER A CERTEZA DE QUANDO EU FOR RESTAURAR OS BKPS NESSE AMBIENTE AQUI N VAI TER NENHUM PERIGO DE N FUNCIONAR, VOU FAZER ISSO, VOU MUDAR O RANGE E VOU MANDAR UMA NOTA PARA LA PARA VER SE VAI AUTORIZAR E VAI MANDAR PARA O ERP SEM PRECISAR FAZER MANUAL AE RESPONDO PARA VCS.

[Former Member]

Fernando, vc tem msn ???ae te passaria acesso para vc dar uma olhada se Possivel.

Edited by: Reinaldo Carletti on Jul 26, 2010 4:39 PM

[former_member182114]

Bom dia Reinaldo,

Nem precisa acessarmos, já tá tudo explicado. O 204 é normal não ter resposta ao ERP.

Não sei até onde você quer chegar com o teste, se estiver mandado para produtivo é melhor parar por aqui e fique tranquilo que as comunicações e funcionalidades estão todas corretas.

Se estiver mandando pra homologação da Sefaz, siga a dica do Carlos para gerar a nota com outro número ou série diferente da que o outro sistema (original) gera, se não sempre irá ter colisão.

Isto acontece pq apesar de você ter outro ambiente, o destino é um só SEFAZ e lá só tem dois ambientes um HOMOLOG e outro PRODUCAO. Quando temos mais de um HOMOLOG, devemos manter nossos ranges de forma a não replicar os números. Porém se o destino é Sefaz PRODUCAO.... PARE POR Aí. Se não pode ocorrer incorrer em problemas fiscais.

Atenciosamente, Fernando Da Ró

[Former Member]

RESPONDENDO A OUTRA PERGUNTA, EU ESTOU FAZENDO O PROCESSO NOVO, MAIS COMO O NUMERO JA EXISTE NA SEFAZ ELA VEM COM O STATUS DE NUMERO DUPLICADO, MAIS A MENSSAGEM PARA NO GRC N VAI PARA O ERP SO VAI QUANDO EU EXECUTO O /XNFE/UPDATE_ERP_STATUS manual com o ID.

QUANDO DISSE (O que não está voltando?) É A RESPOSTA DO GRC PARA O ERP DIZENDO Q A NOTA ESTA DUPLICADA AE SO FICA A CATRAQUINHA, SE EU EXECUTAR O /XNFE/UPDATE_ERP_STATUS SEM COLOCAR PARAMETRO NAO ATUALIZA AE SE EU COLOCAR O PARAMETRO(ID) AE ATUALIZA.

[former_member182114]

Show de bola, aí está a resposta.

O 204 é SEMPRE represado pelo GRC, o procedimento nestes casos é ir no detalhe da NF-e e clicar no Status Query button para ele obter o resultado de lá, no caso é provável que você receba outra rejeição pois a chave de acesso em que a nota foi aprovada deve ser diferente da "nova" pois o número aleatório provavelmente está diferente.

Ou seja, tá tudo certo com o ambiente, o comportamento e a rejeição são previstas.

Atenciosamente, Fernando Da Ró

[former_member193386]

calma calma, vamos conseguir resolver o seu problema, primeiro, tenta muda o range de numeracao de nfe para recomecar de uma numeracao coerente, acho que na SNUM lá no seu ECC, provavelmente ele nao esta atualizando por esse motivo, pq ele entende que já está ok

[Former Member]

Tem algum dump ST22?

R = N TEM ERROS

Tem algum erro SM21?

R = N TEM ERROS

Qual é a versão de SP do seu GRC?

R =

SAP_ABA 700 0018 SAPKA70018 Componente válido para várias aplicações

SAP_BASIS 700 0018 SAPKB70018 Componentes de base SAP

PI_BASIS 2005_1_700 0018 SAPKIPYJ7I PI_BASIS 2005_1_700

ST-PI 2008_1_700 0000 - SAP Solution Tools Plug-In

SAP_BW 700 0020 SAPKW70020 SAP NetWeaver BI 7.0

SLL-NFE 100 0009 SAPK-10009INSLLNFE xNFE 1.0

ST-A/PI 01L_BCO700 0000 - Servicetools for other App./Netweaver 04

Já verificou se o XML está disponível no KPro?

R = JA SIM ESTA OK

Vocês tem algum enhancement nas funções standard do GRC?

R = NÃO

Vocês utilizam-se de B2B?

No GRC antes de você rodar pela chave de acesso, tem alguma entrada na tabela /XNFE/BACKSTATUS?

R = N TEM

No ERP existe alguma entrada na tabela J_1BNFE_INVALID?

R = N TEM

[Former Member]

Este procedimento esta tudo normal tambem, minha duvida é base do ERP esta na data de 07/07/2010 e a do GRC esta na data de 02/07/2010 sera q é por isso que esta contecendo este problema ???

[former_member193386]

poderia sim, mas vou dar uma verificada.

Aparentemente não haveria problema com a data, mas creio que seria melhor vc arrumar isso ai. Corrija e veja se resolve seu problema, mas ainda acho que vc deveria olhar mais coisas do ambiente.

De uma olhada na SMQ1 e SMQ2 e veja se nao existe nenhum processo com erro

Edited by: Carlos Rodrigo Pereira on Jul 26, 2010 4:13 PM

[former_member182114]

Reinaldo,

Sobre a diferença de datas das cópias, a princípio não tem problema, porém quando você diz que não está voltando. O que não está voltando? Você está fazendo um processo NOVO no ERP ou está aguardando resposta dos velhos?

Além disso poderia responder as perguntas anteriores do post anterior?

Atenciosamente, Fernando Da Ró

[Former Member]

Ja olhei isso tudo, na teoria ele esta igual o PRD que esta funcionado hj aqui perfeitamente, agora na pratica as maquinas clonadas esta dando este problema.

[Former Member]

As maquinas clonadas estao em ambientes diferentes, e ja foi confirmada toda a parte de RFC ja foi mudada.....é muito estranho ela consegue enviar a nota para o GRC e o GRC manda para a sefaz na volta do GRC para o ERP n ta atualizando ae tenho q ir manual pela /XNFE/UPDATE_ERP_STATUS colocar o ID, ae ela atualiza na J1BNFE

[former_member182114]

Bom dia Reinaldo,

Outra suspeita.... O processo normal não está sendo concluido no GRC:

Tem algum dump ST22?

Tem algum erro SM21?

Qual é a versão de SP do seu GRC?

Já verificou se o XML está disponível no KPro?

Vocês tem algum enhancement nas funções standard do GRC?

Vocês utilizam-se de B2B?

No GRC antes de você rodar pela chave de acesso, tem alguma entrada na tabela /XNFE/BACKSTATUS?

No ERP existe alguma entrada na tabela J_1BNFE_INVALID?

Atenciosamente, Fernando Da Ró

[former_member193386]

Aproveite, complementando o que o Fernando falou e verifique se vc esta com os Jobs agendados corretamente na SM36 ou Sm37

verifique se vc tem o /xnfe/process_reports agendado.

os jobs que vc precisa ter alem dele sao:

/xnfe/check_srv_status

/xnfe/RSXMB_RESTART_MESSAGES

[Former Member]

Mais, eu nem fiz o system copy apenas clonei as maquinas, vc acha que não tem nada a ver o ERP esta com a base mais atualizada n ne ???

[former_member182114]

Bom dia Reinaldo,

O que é estranho mesmo é NÃO conseguir atualizar o ERP ao final do processo normal, e conseguir com o /xnfe/update_erp_status que é uma retransmissão do resultado que o ERP recusou antes.

Ou seja, ao que parece seu "novo" ERP está processando tão lentamente a gravação que a resposta da Sefaz chega e ele ainda nem conseguiu terminar de gravar, daí a "falha" na entrega automática e a necessidade do report para retransmitir.

Se fosse ligações ou problema nos dados a retransmissão não funcionaria.

De qualquer forma, como disse seu GRC parece estar bem defasado, e se a minha suspeita estiver correta seu ERP não está usando a funcionalidade do decouple (CALLRFC <> vazio) que evitaria este sintoma/problema.

Atenciosamente, Fernando Da Ró

[former_member193386]

Essas duas maquinas estão na mesma rede, ou seja, os dois ambientes de sap se conectam, ou seja, a maquina clonada e a maquina original, pois se isso acontece as duas estao com as mesmas definicoes, e isso pode estar dando o problema que esta relatando, ou seja, vc consegue mandar a nota para o GRC pelo seu ambiente de testes, mas ele esta tentando devolver para outra maquina diferente do seu landscape de testes.

uma boa forma de verificar é conferindo as configuracoes de RFC destination ( SM59 ) e as configs de integracao ( BD54 e BD97 ).

verifique se os jobs agendados nao estao sendo executados ou se eles nao estao mais agendados.

[Former Member]

Entao, vou tentar te explicar....temos um ambiente GRC e ERP funcionando em goiania, so q vamos mudar para Sao Paulo ae clonamos as maquinas e mandamos, ligamos o ambiente la e estamos fazendo teste so q esta acontecendo isso aqui em goiania esta funcionando legal, a unica coisa q fiz de diferente foi testar o restore no ERP, ae queria saber se este problema estaria relacionado com esse restore q fiz.O ERP MANDA CERTINHO PARA O GRC SO NA HORA DE VOLTAR A INFORMAÇAO Q N ESTA CONSEGUINDO SO SE EU COLOCAR MANUAL E COLOCAR O ID AE ATUALIZA

[henrique_pinto]

Deve ter algum erro de configuracao de Logical System, revise as configs de BD54 / BD97 e se o ERP novo tá mandando o logical system correto (isso vc vê no campo LOGSYS da /XNFE/NFEHD).

Outra coisa, homogeneous system copy sempre ferra alguma coisa em ambiente dual stack. É comum casos em que o stack Java da nova instancia fica apontando pro stack ABAP da instancia antiga e vice versa.

Abs,

Henrique.

[Former Member]

Isto ae é um teste que estou fazendo e preciso tirar essa duvida a base do ERP esta na data de 07/07/2010 e a do GRC esta na data de 02/07/2010 sera q é por isso que esta contecendo este problema ???quando eu restaurar as bases como esta em PRD vai ficar normal ???

[former_member182114]

Bom dia Reinaldo,

Sua pergunta não está clara. O que aconteceu com este ERP e GRC com datas diferentes? São cópias? E por que "vão virar PRD"?

O /xnfe/update_erp_status é somente usado para RE-transmissão por job, ou seja, uma tentativa de entregar ao ERP já falhou logo ao chegar o status do PI/Sefaz.

Este report atualmente lê apenas da tabela /xnfe/backstatus, para informar a chave de acesso foi criado outro programa o /xnfe/update_erp_status_dial e foi lançado no SP10. Tá na hora de dar um upgrade no seu sistema.

Este comportamento parece ser por conta da falta dos jobs de decouple (separaçao entre gravação no DB e numeracao/transmissao ao GRC)

Atenciosamente, Fernando Da Ró