Jump to content

dev botao

  • Este tópico foi criado há 4742 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

  • Membros Pro
Posted

Boa noite, estamos usando o CTe a alguns dias e ja emitimos mais 300 CTes com sucesso.

Mas hoje ocorreu um erro estranho : ao invocar a rotina de envio do arquivo pro Sefaz de SP, ele submeteu o arquivo, mas nao gravou no XML os dados do protocolo e do recibo...

Eu nao sei se deu um erro visivel, segundo o usuario do sistema, nao deu nenhuma mensagem de erro, mas nao posso garantir.

Ao tentar submeter novamente, o sefaz me respode que o CTe ja existia na sua base, mas o XML nao tinha as informacoes do protocolo e nao tinha sido movido para a pasta dos arquivos validados (habilitamos a criacao de diretorio por data).

Para nao ficar com o XML defeituoso, eu consultei ele novamente pelo demo do ACBr e consegui valida-lo, completando ele corretamente.

Alguem ja viu algo parecido com isso? fazem alguma ideia do que pode ter acontecido e como posso prevenir pra isso nao acontecer mais?

Rene Melo

  • Moderadores
Posted

Provavelmente, no momento que o XML foi enviado existia alguma lentidão no processamento por parte do SEFAZ.

O usuário deve ter recebido a mensagem "Lote em Processamento", nestes casos, vc pode salvar o número do recibo do lote e consultar de tempos em tempos até receber a mensagem "Lote Processado" ou então fazer do modo que vc mesmo descreveu.

O problema de apenas consultar pela chave é que caso exista algum erro no XML enviado vc sempre receberá a mensagem de que o CTE não existe e não saberá o motivo, enquanto quando vc consulta pelo número do recibo, caso exista algum erro no XML vc recebrá a mensagem de "Lote Processado" e logo em seguida a mensagem de erro.

djsystem-logo.png
 youtube.png facebook.png instagram.png linkedin.png
André Ferreira de Moraes | Analista de Sistemas
www.djsystem.com.br | www.djpdv.com.br
www.tefhouse.com.br | www.xpos.com.br
  • Consultores
Posted

Bom dia,

Problemas de acesso podem ocorrer sem prévio aviso, sendo assim devemos oferecer alternativas para o usuário.

Solução adotada por mim:

1. na tabela do banco de dados, que contem os dados do conhecimento, tenho tres campos: Enviado Char(1), Protocolado Char(1) e Protocolo Char(15).

Quando o lote de CTe é enviado o campo Enviado recebe o valor S, em seguida consulto o status se igual a 100 atualizo os campos Protocolado com o valor S e o campo Protocolo com o numero do protocolo de autorização.

Desta forma consigo separar os CTe não protocolado dos protocolados que foram enviados.

2. no form utilizado para enviar os CTe tenho um RadioGroup com as seguintes opções (Não Emitidos, Emitidos e Não Protocolados)

ao selecionar a opção:

Não Emitidos, filtro os registros do banco de dados cujo campo Enviado = Não

Ao clicar no botão [Enviar] ocorre o envio dos conhecimentos selecionados (CheckListBox) para a Sefaz e a impressão dos mesmos;

ao selecionar a opção:

Emitidos, filtro os registros do banco de dados cujo campo Enviado = Sim e Protocolado = Sim

Ao clicar no botão [Enviar] ocorre somente a impressão (segunda via) dos conhecimentos selecionados;

ao selecionar a opção:

Não Protocolados, filtro os registros do banco de dados cujo campo Enviado = Sim e Protocolado = Não

Ao clicar no botão [Enviar] ocorre a consulta dos conhecimentos selecionados junto a sefaz, a atualização do XML com as tags do protocolo e a impressão dos mesmos;

3. e não menos importante, ensinar o usuário como proceder quando isso ocorrer.

Espero ter ajudado.

Consultor SAC ACBr

Italo Giurizzato Junior
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

Analista de Sistemas / Araraquara-SP

Araraquara - A era dos Trólebus

  • Membros Pro
Posted

Pessoal, acho que nao consegui ser claro...

Em nosso sistema, nos tratamos o "Lote em processamento". Ao enviar o xml para o Sefaz, nos salvamos as informacoes no BD, independente do resultado (autorizado ou em processamento).

O que acontece é que o sefaz autorizou, e o retorno nao veio..

É como se a rotina que retorna os dados do webservice do sefaz tivesse sido ignorada.

Realmente muito estranho...

Como funciona nosso sistema?

1 - Populamos o Componente

2 - Enviar o XML para o Sefaz

** aqui o componente nao retornou nada, nem erro, como se nao tivesse sido submetido, porem o CTe foi autorizado.

3 - Salvamos o retorno indiferente de autorizado ou processando

4 - Imprimimos caso Autorizado

5 - Se em processamento , consulta, se Autorizado passo 4.

Voces tem noticia de que algo assim tenha acontecido com nenhum usuario do componente?

Rene Melo

  • Membros Pro
Posted

Não sei se posso responder aqui no fórum do SAC, mas vou tentar ajudar:

Nós não usamos ainda o CT-e, porém já ocorreu na emissão de NF-e. Neste caso, quando não recebemos o retorno, nosso sistema envia o documento novamente, onde pegamos o código de retorno. Se o retorno foi o 100 é por que não foi enviado ainda, e se vier o outro código de enviado em duplicidade, então fazemos uma consulta para pegar os dados que faltavam. Espero que lhe ajude.

[]´s

Ivan

  • Moderadores
Posted

Alguem ja viu algo parecido com isso? fazem alguma ideia do que pode ter acontecido e como posso prevenir pra isso nao acontecer mais?

1 - Alguem ja viu algo parecido com isso?

Oi Renemelo, assim como o Ivan eu também não uso CTe, porém já me aconteceu o mesmo problema com a emissão de NFe.

2 - Fazem alguma ideia do que pode ter acontecido?

Como vc comentou que enviou mais de 300 CTes com sucesso, há uma forte possíbilidade de ter ocorrido um erro de comunicação. Imagine a seguinte situação: Você envia o CTe, a SEFAZ recebe e no momento de receber o retorno enviado pela SEFAZ a conexão de internet do cliente falha. Neste caso vc ficará sem o retorno.

3 - Como posso prevenir pra isso nao acontecer mais?

Quanto ao prevenir nas NFe's eu uso uma coluna status aonde gravo o status de retorno. Caso não tenha o status é porque ocorreu algum problema e fica fácil de notar dentro da grade de notas emitidas a falta desta informação em uma delas.

Se o problema for uma falha na conexão eu creio que não tem como evitar, pois isto pode ocorrer, inclusive também já ocorreu do servidor da SEFAZ receber a nota e cair em seguida, sem dar o retorno também. Neste caso como ele demorou para voltar então foi logo identificado o problema, após os servidores da SEFAZ voltar a operar, a nota estava autorizada e o procedimento para corrigir foi uma consulta enviando o XML para recebe-lo com o protoloco de autorização.

Na minha opinião acredito que ocorreu uma falha na conexão.


logoacbr.pngConheça o Portal do Projeto ACBr

Ajude o Projeto ACBr crescer - Assine o SAC ACBr
Assine um dos planos de longa duração do SAC ACBr, obtenha Descontos Especiais, Parcele no Cartão e ainda ganhe Brindes Exclusivos. Saiba mais aqui

Conheça o ACBrLib, o ACBr de forma nativa para qualquer linguagem de programação. Saiba mais aqui

 

 

 

 

  • Moderadores
Posted

renemelo,

Já tive este tipo de problema no envio da NFe. Geralmente ocorre qdo a internet está instável. O problema ocorre qdo enviamos o lote de NFe e antes de receber o número do recibo, por algum problema na internet, o retorno do webservice é perdido, então ficamos sem o recibo do lote e sem saber se o lote foi recebido/autorizado.

A única solução é consultar pela chave mesmo, mas em dia em que o SEFAZ está lento poderemos ter problemas, pois pode ser q seja retornado a msg de que a chave não existe, mas ao enviar um novo lote com a mesma chave pode acontecer de o primeiro envio ser processado no mesmo tempo.

Se vc enviar exatamente o mesmo XML não terá problema, pois ambos conterão a mesma assinatura, assim basta vc adicionar a autorização de uso ao XML e enviá-lo ao cliente.

djsystem-logo.png
 youtube.png facebook.png instagram.png linkedin.png
André Ferreira de Moraes | Analista de Sistemas
www.djsystem.com.br | www.djpdv.com.br
www.tefhouse.com.br | www.xpos.com.br
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.

The popup will be closed in 10 seconds...