Italo Giurizzato Junior

Boa noite, Muito obrigado pela colaboração, já esta no repositório.

Boa noite Farnetani, Se não me falha a memória já devo ter respondido esse questionamento, por favor faça uma pesquisa. Procure por XMLOriginal.

Boa noite Marcio, Com relação ao provedor Infisc, você fez a alteração? Se sim, favor anexar os arquivos alterados para que possamos avaliar.

Herculano, Passe o caso para os demais membros da Equipe ACBr com mais experiencia em Assinatura Digital. Peço que tenha um pouco mais paciência, quem sabe teremos em breve uma solução para o problema.

Boa noite a todos, Favor atualizar todos os fontes de todas as pastas. Refaça os testes.

Boa noite, O componente esta configurado como (libCapicom, libCapicomDelphiSoap ou libOpenSSL) ?

Herculano, Bom o problema pode ser o OpenSSL, se você tiver condições de realizar testes usando o Capicom e de preferencia use o programa exemplo do componente para esse teste. Se funcionar, repita o teste para o OpenSSL e nos de um retorno.

Boa noite Orlando, Muito obrigado pela colaboração, já esta no repositório.

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

Boa noite Caetano, É interessante ao solicitar o cancelamento, carregar antes o XML da NFS-e a ser cancelada. Outra coisa essa propriedade "Situacao" no caso da Consulta a Situação do Lote RPS só serve para informar se o lote enviado foi processado com sucesso ou não. Não informar se a nota foi cancelada ou não.

Herculano, No caso do provedor Betha é necessário assinar o RPS e depois o Lote, logo se for enviado um lote contendo 10 RPS o XML vai conter 11 assinaturas, ou seja, um para cada RPS e mais um do Lote. E tenho informações que o envio para o provedor Betha esta funcionando 100%. Agora tem outra coisa, esse provedor tem uma segunda versão que é usada por algumas cidades. Chamamos de Bethav2, me parece que esta versão que esta com problemas.

Boa noite Herculano, Qual é o provedor?

Boa noite Valdir, Muito obrigado pela colaboração, vou incluir e enviar para o repositório.

Boa noite Arce, Favor anexar a unit alterada, para que possamos avaliar.

Boa noite Dimas, As alterações foram muitas. Verifique se as propriedades: Salvar estão com o valor True. Outra coisa verifica se a propriedade ConsultaLoteAposEnvio esta com o valor True.

Boa noite Marco, Se você perdeu o XML que foi gerado e enviado, a solução é muito simples: 1. Gerar e assinar novamente; 2. Executar o método consultar para obter o protocolo de autorização. 3, Imprimir o DAMDFE (se necessário).

Boa noite Elviro, Se já existe um tópico tratando sobre o assunto, porque você criou outro?

Boa noite Anderson, Não é para gerar mesmo, você informou que o Tipo do Emitente é 1 = Prestador de serviço de transporte. Neste caso só vai aceitar as chaves dos CT-es. Você tem que informar 2 = Transportador de Carga Própria

Boa noite Jairo, Na rotina que alimenta o componente inclua as linhas em negrito: with ACBrCTe.Conhecimentos.Add.CTe do begin if ACBrCTe.Configuracoes.Geral.VersaoDF = ve200 then infCTe.versao := 2.00 else infCTe.versao := 3.00; (...)

Boa noite Fernanda, Neste caso sugiro você ter em mãos o Manual da versão 3.00 do MDF-e para ver como ficou a estrutura do XML no que diz respeito a essas TAGs. E se possível anexo o XML gerado.

Boa noite Gustavo, Já tem alguns no fórum, basta pesquisar.

Boa noite Marcos, Favor atualizar os fontes e testar novamente.

Boa noite Marcos, O seu XML esta correto, com certeza deve ser uma falha nas regras de validação da SEFAZ.

Boa noite Felipe, No que diz respeito o XML, o máximo é 20 caracteres.

Boa noite Marcos, Você esta tentando gerar um CT-e complementar na versão 3.00 ?