on 08-10-2010 2:37 PM
Bom dia pessoal.
Existe alguma configuração ou desenvolvimento que podemos fazer para que as notas fiscais geradas sejam automaticamente colocadas em contingência? Por exemplo, no caso da SEFAZ no MT, precisaria que todas as notas geradas para os centros dentro do MT fossem geradas automaticamente em contingência quando a SEFAZ estiver fora do ar. Alguma solução?
Pra MT nao seria justamente o contrario, ir automaticamente pro SCAN e nao pro formulario?
Se o SCAN tiver ativo, isso vai acontecer automaticamente, pois o GRC vai dizer pro ERP usar a serie SCAN.
Abs,
Henrique.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Então Henrique, sobre o SCAN, o GRC estaria verificando constantemente qual servidor estaria ativo, sendo eles a SEFAZ ou SCAN?? Ou a cada emissão de nota, ele verificaria o disponibilidade de qual servidor deve realizar o envio e assim retornar ao ERP?? Este processo não pode deixar mais lento o ERP, no caso da emissão da NFe??
Se a SEFAZ cai, o GRC automaticamente passa a checar o SCAN para aquela UF, e quando o SCAN estiver disponivel, dai ele fala pro ERP que ele pode numerar a nota com a serie 9xx.
Nao é exatamente a cada nota que o ERP verifica essa informacao no GRC, mas a cada processo de faturamento.
Ex. se vc estiver fazendo faturamento em lote (VF04) e processar 100 notas, o ERP só vai fazer a verificacao de status 1 vez.
Mas se vc fizer 100 vezes a VF01, para cada vez ele vai verificar.
Abs,
Henrique.
Deixe-me esclarecer melhor a necessidade. Meu cliente trabalha com varejo, e possui 20 lojas espalhadas pelo centro-oeste. Quando temos uma instabilidade na SEFAZ ou na comunicação com a SEFAZ, as notas param de ser impressas nas lojas devido a falta de autorização.
É inviável para as lojas logarem no SAP e ficarem indicando contingência e solicitando a reimpressão, não só pelo tempo as também pela quantidade de usuários que seriam necessário.
O SCAN não atende porque nem sempre o problema é na SEFAZ, e também ocorrem instabilidades momentâneas em que o SCAN não é ativado. Porém, estes momentos já chegaram a durar mais de meia-hora, o que causou um estresse grande nas lojas.
Sendo assim, se houvesse alguma configuração que pudesse ser feita para gerar em contingência as notas automaticamente eu poderia manter a impressão automática. Existe algo desta maneira?
por isso que estamos te indicando o processo de SCAN, ele é feito automaticamente, e estavel, já que é de ambiente nacional, entendo a sua duvida, mas a contigencia normal nao funcionaria automatica, além do que, é altamente custosa para a empresa, afinal, papel moeda com logo olografico é caro.
Edson,
o desenvolvimento que sugeri nao era substituto ao SCAN, pelo contrario.
O SCAN deve com certeza ser avaliado e implementado, vai minimizar seus casos de contingencia.
O que eu quis dizer é que mesmo com SEFAZ e SCAN, vao haver alguns periodos em que nenhum dos ambientes estarao disponiveis. Como eu sei que existem alguns negocios em que tempo é muito critico (e Retail é um deles), entao sugeri que vc fizesse um desenvolvimento extra, para ativacao da contingencia quando nem SEFAZ nem SCAN estiverem disponiveis. Claro, apenas se necessario.
Abs,
Henrique.
Um exemplo simples seria, no ERP, apois a consulta da funcao /XNFE/RFC_SRVSTA_READ, se nenhum dos ambientes estiver disponiveis, vc poderia automaticamente numerar a nota com a serie normal e tpEmis = 2/5 (ou seja, forcar o flag de posted under contingency) + setar o flag de Central Contingency para que as proximas jah saiam assim. Assim, a nota em vez de parar no monitor sem numeracao, jah eh numerada e posta em contingencia.
Abs,
Henrique.
Bom dia Pessoal,
Um ponto onde esta intervenção pode ser feita é na BAdI CL_NFE_PRINT, método GET_SERVER, que é justamente após a comunicação com o GRC para obter as informações de status atual da Sefaz.
Caso CT_SERVER_CHECK-SEFAZ_ACTIVE e CT_SERVER_CHECK_SCAN_ACTIVE ambos vazios, daí setar a contingência na J_1BNFE_CONTIN2, porém existem cuidados que devem ser levados em consideração:
- locks para evitar que dois processos façam a entrada em contingência
- check locks para evitar que o processo intervenha quando o usuário está na view de customizing
- tabelas de controle Z para evitar que o processo force contingência quando na verdade nem existe formulário de segurança disponível
- deixem rastreabilidade dos TURN ON AUTO contingency para investigação
- talvez um controle de tempo/tentativas para que ele só entre automaticamente após X tempo ou N tentativas.
- documentem a melhoria
Atenciosamente, Fernando Da Rós
PS: Apesar de discutirmos isto com naturalidade aqui, tenham em mente que uma implementação/intervenção mal feita poderá levar a comportamentos inesperados e não suportados pelo support standard.
Bom dia Pessoal,
Li os comentários nesta thread e tem algumas coisas que podem ajudar na situação problemática, pois a questão 30 minutos parado que li numa das respostas pode remeter à um problema no customizing.
Isto acontece por que a informação de Status Check não é online. O ERP busca no GRC (bando de dados), que por sua vez é atualizado pelo job do programa /xnfe/check_srv_status de acordo com intervalo do job + customizing do serviço.
Imagine que na configuração SPRO de verificação, sua Sefaz está com intervalo 1800 segundos (30 minutos). A Sefaz pode até ter voltado mas seu status no GRC teria que aguardar este tempo até ser atualizado, ou seja, você fica com a informação defasada.
Uma forma que pode ser utilizada na configuração é colocar o JOB para 1 em 1 minuto, porém na SPRO variar os tempos de acordo com a criticidade da Sefaz. Ex.: Uma Sefaz com muito uso pode ser verificada de 3 em 3 minutos (180 segundos), outra com pouca criticidade pode ter um tempo maior, e caso seja ambiente de homologação em produção, daí você pode colocar 24 horas nele (86400 segundos).
Obs.: O job de 1 em 1 minuto não quer dizer que alguma Sefaz será chegada, apenas que ele de 1 em 1 minuto irá verificar se tem alguma Sefaz para ser verificada (conforme teste última verificação feita + intervalo do customizing < agora).
Ações:
- verificar o intervalo do job
- verificar o tempo de verificação no customizing
Atenciosamente, Fernando Da Ró
User | Count |
---|---|
14 | |
4 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.