Italo Giurizzato Junior

Luciano, Não faça isso, esta errado. Nunca consulte antes de enviar, simplesmente envia. Se após o envio você obter o Status igual a zero, significa que o CT-e OS não foi autorizado, não foi denegado e muito menos rejeitado. Sendo assim, você deve carregar o XML no componente e consultar, pois ocorreu um erro. Se não a consulta for bem sucedida, você terá uma das 3 situações apresentadas acima. Se foi autorizado ou denegado imprima o DACTE. Se foi rejeitado, o usuário tem que fazer as devidas correções e enviar novamente. Lembre-se que uma das rejeições é: Documento Inexistente na Base de Dados, neste caso fica claro que ao enviar o problema ocorreu no envio e não no retorno. Se você ficar consultando toda vez antes do envio, a SEFAZ poderá bloquear o emitente do CT-e OS por um período, por consumo indevido do Web Service.

Bom dia ALA, Veja bem, após o envio do lote temos como resposta o numero do protocolo (entenda como sendo o numero do recibo quando enviamos o lote de NF-e). Essa informação é utilizada para consultar a situação do lote enviado (método ConsultarSituacao) e consultar o resultado do lote processado (método ConsultarLoteRps). Ao consultar a situação de um lote é retornado apenas uma informação (um numero), que se ser 1 significa que o lote não foi recebido, 2 = lote em processamento, 3 = lote processado com falhas, 4 = lote processado com sucesso. Sendo assim as propriedades NomeArq e Numero apontadas pelas últimas duas setas estão vazias mesmos, só serão preenchidas quando o componente obter o retorno do provedor com o XML da NFS-e, isso ocorre quando realizamos a Consulta ao Lote de RPS.

Luciano, Eu não faria isso. Se utilize da consulta quando algo der errado, ou seja, enviou e o XML ficou sem o protocolo de autorização, ai sim devemos realizar uma consulta. Lembre-se que ao enviar pode ocorre falha no envio ou falha no retorno. Se ocorreu uma falha, para saber se foi no envio ou no retorno, basta se utilizar do método consultar. Se não ocorreu nenhuma falha, o CT-e OS poderá ser Autorizados, Denegado ou Rejeitado. Se ele for Rejeitado devemos efetuar as devidas correções nos dados incorretos e enviar novamente, uma vez que um documento rejeitado não é armazenado na base de dados da SEFAZ. Simplifique a vida do usuário, coloque apenas um botão [Emitir] que faça tudo, ou seja, alimente o componente com os dados do CT-e OS, gere, assina, valida, envia e imprima o DACTE (caso autorizado ou denegado).

Bom dia Luciano, Você esta fazendo errado, o correto não é tentar enviar novamente, pois você não sabe se o problema ocorreu no envio ou no retorno do protocolo. Sendo assim, após detectar que ocorreu um problema e o CT-e OS enviado esta sem o protocolo de autorização, o correto é realizar uma consulta, se o CT-e OS foi enviado com sucesso ao realizar a consulta será retornado o protocolo de autorização (lembre-se carregar o componente com o dados do CT-e OS em questão antes da consulta) e o XML será atualizado. Caso o problema foi no envio, será retornado a mensagem que o CT-e OS não consta na base de dados, ai sim você envia novamente.

Bom dia Edmar, Muito obrigado pela colaboração, assim que possível estarei enviando para o repositório.

Boa noite Edmar, Favor fazer as alterações que você julga necessário e faça os testes, estando tudo OK, anexe a unit aqui mesmo, para que possamos analisar e estando tudo OK, enviaremos para o repositório.

Boa noite, Muito obrigado pela colaboração, vamos analisar e estando tudo OK, enviaremos para o repositório.

Boa noite, É um pouco complicado, pois a detecção é feita através do código do município do emitente da nota e isso é feito na unit que faz a leitura do XML.

Boa noite a todos, Pelo que pude ver através do link que o Diego postou, não segue o padrão ABRASF.

Boa noite ALA, Entre em contato para sabermos a resposta deles.

Boa noite Heto, Muito obrigado, vou analisar estando tudo Ok, mando para o repositório.

Boa noite Jimmy, Estranho, pois a URL de homologação: http://testewebserver.averba.com.br/index.soap?wsdl ainda esta funcionando.

Boa noite Rogério, Existe os eventos de Manifestação do Destinatário e existe a Manifestação de Documentos Fiscais Eletrônicos - MDF-e, documento este emitido pelas transportadoras e pelas empresas que realizam o transporte de carga própria.

Bom dia Heto, Você uma alteração no componente ou na sua aplicação? Se foi no componente favor anexar a unit alteração para que possamos avaliar.

Bom dia Pedro, Favor entrar em contato com o provedor e solicitar a forma correta de informar esse campo. Pois essa informação pode variar de uma cidade para outra.

Boa noite ALA, No retorno não consta a informa referente ao protocolo é por isso que na tela não é mostrado.

Boa tarde Leandro, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde Joceandro, Favor atualizar os fontes e faça um novo teste.

Boa tarde Léo, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde ALA, Favor anexar o XML de retorno ao realizar a consulta.

Boa tarde Felipe, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde Filipe, Muito obrigado pela colaboração, já enviei para o repositório. Observação, os seus fontes estão desatualizados.

Boa tarde Augusto, Não consegui abrir o seu RAR.

Boa tarde Adriano, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde Carlos, Muito obrigado pela colaboração, já fiz a alteração e enviei para o repositório.