Italo Giurizzato Junior

Boa tarde Luís, Esse erro esta ocorrendo no ambiente de homologação ou de produção? Ele ocorre na sua maquina ou na maquina do seu cliente? Se é na maquina do seu cliente, verifica se na pasta do EXE ou em outra configurada pela sua aplicação não tem o arquivo ACBrCTeServicos.ini antigo. Caso afirmativo delete o arquivo. Cheklist: Você tem fontes com alterações locais? Verifica se não tem nenhuma unit do ACBr com uma bolinha vermelha em seu ícone, caso afirmativo delete a unit. Atualize todos os fontes de todas as pastas. Reinstale o ACBr com a opção de apagar arquivos antigos marcada. Compile a aplicação com a opção Build.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Edmilson, Qual é o formato das datas dos XMLs retornados, seja o XML da nota ou não. Pois podemos tratar isso nas units do provedor, evitando assim um efeito colateral com os demais provedores. Me desculpa mas da forma que você fez passa a impressão da tentativa e erro, ou seja, o componente tenta ler a data em um formato se ocorrer erro tenta com outro formato.

Boa tarde a todos, Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Boa tarde, Já esta no SVN. Favor atualizar os fontes, reinstalar o ACBr e faça novos testes.

Boa tarde Tiago, Já esta no SVN.

Boa tarde Tiago, Já esta no SVN.

Boa tarde Gomes, Por favor anexe aqui a alteração que você fez na cidade em questão, não precisa anexar o arquivo INI inteiro somente as linhas referente a cidade. Desde já muito obrigado pela colaboração.

Bom dia Gibran, Conversando com a Equipe ACBr a remoção dos caracteres #13 e #10 do XML é uma etapa chamada canonicalização, isso é realizado antes do XML ser assinado. No lugar desses caracteres usei a sequencia: ConfigGeral.QuebradeLinha := '
'; Fiz um teste usando o programa exemplo do componente. O XML do Rps que é assinado bem como o de envio do lote que tem 2 assinaturas (do Rps e a do Lote) foram submetidos no site da Receita Federal que valida a assinatura. Receita Federal do Brasil - Validador de Assinaturas (fazenda.gov.br) Os dos XML (do Rps e de envio do lote) estão com as assinaturas validas. O problema é o webservice do provedor que não aceita essa sequencia escape e acusa que a assinatura esta invalida. Solução para o problema: 1. Usar o caractere ";" (ponto e virgula) mesmo que a impressão do DANFSE via site a discriminação saia bagunçada. 2. Entrar em contato com o provedor, expor o problema, mostrar para eles que o uso dos caracteres #13 e #10 da forma que eles estão usando ao gerar o XML da NFS-e esta fora das normas, quem sabe eles façam as adequações necessárias no webservice. Resumindo: Se ficar o bicho come, se correr o bicho pega.

Bom dia Gledston, Não, porque a assinatura depende do provedor, alguns requer que o Rps seja assinado, outros não. Logo a assinatura é realizada se necessário automaticamente pelo componente.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Elisângela, Lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente antigo: ACBrNFSe não está mais tendo manutenção. Faça os testes usando o programa exemplo do novo componente. Manual de Migração

Bom dia Pablo, Muito obrigado pelos arquivos, já inclui na minha lista de tarefas para analise. TK-4152

Bom dia, Muito obrigado, já inclui na minha lista de tarefas. TK-4151

Boa tarde Elisangela, Pelo que eu notei essa empresa Intertec trabalha da mesma forma que o provedor Giap. As URLs são muito parecidas, veja: URL da Intertec: http://webservice.intertecsolucoes.com.br/WSNfsesPsjv/nfseresources/ws/v2/emissao/simula URL da Giap: http://webservice.giap.com.br/WSNfsesAmparo/nfseresources/ws/v2/emissao/simula Acredito que possamos usar o mesmo provedor, bastando informar a URL da Intertec.

Você concorda que a mensagem retornada pelo webservice contradiz o que esta no manual? Retorno do webservice: <Correcao>Informe o código do município gerador com sete dígitos. Consulte tabela de Municípios do IBGE.</Correcao> Deixa claro que deve ser informado o código IBGE do município com 7 dígitos. Já o código 999 que consta no manual, para começar não tem 7 dígitos. Esse provedor é uma piada.

Gomes, Veja se com essa ocorre o mesmo erro. IPM.Provider.pas

Gledston, Confirma para mim se para a cidade de Carazinho a versão mudou para 2.04, pois o componente esta gerando como sendo a versão 1.00

Brajan, Ficou confuso. O cliente que estava com problema no enviar o evento de cancelamento para a SEFAZ-MG, agora esta funcionando, correto? Esse outro cliente também é de MG? É o mesmo evento de cancelamento?

Boa tarde, Mas nesse XML não consta a chave do CTe de Complementação de Valores.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Brajan, Já estamos ciente desse problema e é na SEFAZ-MG, favor entrar em contato com eles e relatar o problema.

Boa tarde Adriano, Essa alteração já foi realizada a alguns dias. BluData, muito origado pela contribuição, já esta no SVN. Favor atualizar os fontes, reinstale o ACBr e façam novos testes.

Boa tarde Felipe, Chegou a ler essa postagem?

Boa tarde Gomes, Em qual linha ocorre o erro? Pois não tenho como testar.