Italo Giurizzato Junior

Boa tarde Michel, Na Unit ACBrNFSeWebServices qual foi a alteração que você realizou?

Sim, O recibo, não pois ele não faz parte do XML do CT-e, mas o protocolo sim, desde que o XML esteja protocolado. sProtocolo := ACBrCTe.Conhecimentos.Items[0].CTe.procCTe.nProt;

Bruno, Tente usando a propriedade RetWS ela contem o retorno do Web Services já tratado.

Boa tarde Galegobr, Porque não postar aqui no fórum? O que poderia ser a solução não só para o nosso amigo Markapollo e sim para todos que estão passando ou vão passar por esse problema.

Boa tarde Bruno, Depois que o XML do CT-e é gerado, independente se ele foi enviado ou não, você pode obter a chave da seguinte forma: sChave := Copy(ACBrCTe.Conhecimentos.Items[0].CTe.inFCTe.ID,4,44); Caso o componente tenha mais de 1 conhecimento adicionado basta variar o indice do items[X], 0, 1, 2, ... ********************************** A principio o XML é gerado e assinado, correto? Se ocorrer algum problema e o XML ficar sem o protocolo de autorização, basta realizar a consulta como já mostrada nesse tópico. Carrega-se para o componente o XML do CTe em questão, executa-se o Consultar, zera o componente com o Clear e carrega novamente o XML desta forma você vai poder ter acesso ao numero do protocolo, status, data e hora da autorização, bem como imprimir o DACTE com o protocolo.

Boa tarde, Cidade Incluida.

Poste como anexo o XML que ficou sem a chave.

Thaine, Como dito anteriormente a Chave é o componente que gera, ela não é retornada pela SEFAZ. O que a SEFAZ retorna é o recibo de entrega do lote e depois que o CT-e é autorizado, é retornado o numero do protocolo. Você só envia novamente quando ocorre uma rejeição, digamos por erro, por exemplo, rejeitado por estar faltando os dados da seguradora. Neste caso basta fazer a correção e enviar novamente. Agora Rejeitar por uso indevido, não significa que existe erro, a SEFAZ recebeu o lote e vai processar, mas você deve aguardar alguns minutos. Esse tipo de rejeição ocorre porque esta ocorrendo muitas chamadas ao webservice em curto espaço de tempo, principalmente no webservice do status de serviço. No caso de rejeição por uso indevido, você faz da forma que eu já lhe mostrei, ou seja realizando uma consulta (vejas os postes anteriores).

Boa tarde Thaine, A chave que você se refere é a chave de 44 digitos? Se sim, esta é gerada pelo componente, ela faz parte do XML que é gerado e enviado para SEFAZ.

Bom dia Thaine, Simples, quando isso acontece, primeiro você tenta realizar uma consulta, se você obter o protocolo de autorizãção, isso significa que o envio foi realizado e o lote foi processado com sucesso. Caso contrario você envia novamente. Como realizar essa consulta: // Carrega no Componente o CTe salvo em Arquivo XML ACBrCTe.Conhecimentos.Clear; ACBrCTe.Conhecimentos.LoadFromFile(NomeArquivo); ACBrCTe.Consultar; ACBrCTe.Conhecimentos.Clear; ACBrCTe.Conhecimentos.LoadFromFile(NomeArquivo); Status := ACBrCTe.Conhecimentos.Items[0].CTe.procCTe.cStat; sProtocolo := ACBrCTe.Conhecimentos.Items[0].CTe.procCTe.nProt; // Status é uma variável Integer e sProtocolo é String Se Status = 100 significa que ocorreu o envio e foi processado com sucesso e o CT-e esta autorizado. Espero ter ajudado

Bom dia Helderlr, Vou dar uma olhada com calma, neles.

Bom dia Jackson, Sim, vai sair a versão 2.0 do CT-e, mas quando e o que vai mudar ainda não sei, mas na NT 2013/001 já traz a inclusão da tag vTotImp - Valor Total dos Impostos na versão 1.04 como opcional e vai se tornar obrigatório na versão 2.0 Agora se tem mais alterações por vir, ainda não sei. Detalhe importante o componente já contem a tag vTotImp como opcional. E a tag RENAVAM aceita tamanho 9 ou 11 para atender os dois ambientes homologação e produção, visto que, em homologação o tamanho já é 11 e em produção continua 9, só vai mudar no dia 15/05/2013, conforme NT 2013/001. Junto com o programa exemplo esta disponivel o schema que atende o ambiente de produção, favor baixar do Portal Nacional do CT-e os novos schemas para fins de teste em ambiente de homologação.

Boa noite Eduardo, Apesar do puxão de orelha, fique a vontade em reportar os erros. Alguns erros são provocados por alimentar o componente com dados errados e outros são falhas no componente. No caso que você postou se tratava de dados errados.

Pode até ser Cláudio.

Boa tarde Jackson, Página 119 do Manual versão 1.04c do CT-e. Note que o grupo <seg> é opcional, mas na observação do elemento <respSeg> temos: "Dados obrigatórios apenas no Rodoviário, depois da lei 11.442/07. Para os demais modais de transporte esta informação é opcional." Antes a SEFAZ não estava aplicando a regra de validação no seu Web Services, mas agora vai aplicar. Uma vez que se trata de uma lei de 2007.

Boa tarde Volmir, NT 2013/001 publicada no Portal Nacional do CT-e.

Boa tarde Juliana, Os fontes estão atualizados? A tag que você se refere é ValorDeducoes? se sim, esta marcado para gerar não importa o valor.

Boa tarde, No ambiente de homologação a partir de 15/04/2013 o XML do CT-e devemos informar o RENAVAM com 11 digitos. Só a partir de 15/05/2013 essa regra vai ser aplicada no ambiente de produção.

Boa tarde Eduardo, A sua sorte é que estas quilêmetros de distancia, caso contrario eu iria lhe puxar as orelhas. A mensagem de erro esta dizendo que foi informado o valor "1" para o elemento "NaturezaOperacao" e este valor não é valido e lhe fornece uma lista de valores validos: 51|52|58|...|78|79 Eu sei que a mensagem esta em inglês, é estranha, mas vamos fazer um pouquinho de esforço e tentar interpreta-la?

Boa tarde Cláudio, Simples, ao realizar a consulta para obter o Retorno da Recepção a SEFAZ não respondeu, sendo assim o componente esta avisando que o WebService esta Inativo ou Inoperante e pede para tentar novamente. Mas lembre-se o envio foi realizado.

Boa tarde Rafael, Quando enviamos um lote de RPS para o Web Services ocorrem 3 acessos: 1. Envio; temos como retorno o protocolo de recebimento do lote. 2. Consultar a Situação do Lote; temos como retorno a situação do lote (1=Não Recebido, 2=Não Processado, 3=Processado com Erro, 4=Processado com Sucesso). 3. Consultar o Lote; temos como retorno o xml da NFS-e. No segundo acesso "Consultar a Situação do Lote" o componente pode realizar até 18 ( WebServices.Tentativas ) consultas com intervalos de 10 segundos. O que pode ser feito: 1. Configurações no componente: WebServices.AguardarConsultaRet := 1000; // equivale a 1 segundo WebServices.IntervaloTentativas := 10000; // 10 segundos 2. checar se o ConsultarLoteRps não esta sendo executado logo após o Enviar, pois esse procedimento é executado automaticamente pelo Enviar a não ser que a propriedade WebServices.ConsultaLoteAposEnvio tenha o valor False. Acredito que com essas medidas, não teremos mais problemas.

Bom dia Thaine, Poste como anexo o XML que foi rejeitado.

Bom dia André, Notei que foi removida a linha que dependendo do código do pais ele mantem a UF, código do municipio, não teria como identificar se a nota é de importação ou não ? Se for em vez de pegar o código do pais do destinatário usariamos o código do Brasil.

Bom dia ncc, Você já tentou entrar em contato com o provedor? e expor o problema: Assinatura do Hash nao confere Se não, aproveite e solicite o XML de envio completo ou seja com as TAGs do envelope.

Ricardo, Sendo assim a rotina que gera o XML vai ter que tratar essas duas situações, quando é de importação e quando não é.