Italo Giurizzato Junior

Boa Noite Jonatan, Fiz algumas alterações no componente e inclui a configuração para Belo Horizonte no Arquivo Config_Municipios.ini Favor baixar as atualizações e testar.

Boa noite Cleiver, Pela imagem é possível ver que você não habilitou a opção para assinar o lote. Para o GINFES: Assinar Lote = Sim Assinar RPS = Não

Boa tarde Rogério, Verifique se no final do arquivo ACBr.inc (...\Fontes\ACBrComum) contem a definição das diretivas de compilação PL_103 e PL_104, pela mensagem de erro não tem. Favor atualizar todos os arquivos fontes do ACBr, pois o ACBrCTe utiliza fontes de varias pastas.

Boa tarde Neguta, De uma olhada no arquivo Cancelar.TXT que encontra-se na pasta: ...\Exemplos\ACBrCTe

Gustavo, Você esta usando o programa exemplo ou a sua aplicação? Você esta executando direto o ACBrNFSe.NotasFiscais.Assinar após alimentar o componente com os dados ? Se sim utilize o comando Enviar, dependendo do provedor não se deve assinar o RPS e sim o Lote e outra coisa, na NFSe não tem schema para validar RPS somente o lote.

O Windows 7 não é 64 bits ou é ?

Qual é a versão do Windows, Delphi que você esta utilizando ?

Bom dia Gorn, Fiz algumas alterações no componente visando resolver o problema da funcionalidade: Cancelar NFSe com relação ao provedor GINFES. Atenção fiz alterações no fonte do componente, no arquivo de configuração Config_Schemas.ini e acrescentei os schemas da versão 2. Favor baixar as atualizações e testar. Independente do resultado do teste favor postar o arquivo de envio e de retorno do Cancelar NFSe.

Bom dia Gustavo, Você copiou as DLLs e as registrou? ...\DLLs\Capicom dentro desta pasta econtam-se as DLLs e o Instala.Bat que realiza a copia e as registra.

Boa tarde Gorn, Eu tinha montado a rotina para atender a versão 3 no caso do cancelamento. Como o GINFES não implementou o Cancelar na versão 3 o jeito é solicitar a eles como tem que ser montado o xml completo de envio.

Boa tarde, Correções feitas, favor baixar e testar novamente.

Bom dia Gustavo, Atualiza os fontes, inclusive os arquivos de configuração: Config*.ini e realize os testes novamente.

Bom dia Gorn, Atualize os seus fontes e tente novamente.

Bom dia Felipe, O DACTe foi desenvolvido em Quick Report 3 e pode ser utilizado nas versões posteriores do QR, e esta atualizado para suportar as versões 1.03 e 1.04 do CT-e. Quanto ao Fast Report temos o DACTe (desenvolvido por Jeickson Gobeti) não sei em qual versão e acredito que não esteja atualizado para suportar a versão 1.04 do CT-e.

Boa noite Toni, Sem previsão, pois não foi liberado os schemas e URLs para o envio.

Boa tarde tenco, Com relação ao problema do componente gerar 2 código aleatórios diferentes, um ao gerar o XML e outro ao gerar o lote de envio, foi resolvido. Encontrei onde estava o bug, favor atualizar os seus fontes, compilar a sua aplicação com a opção Build e realizar os testes, passando o valor ZERO ao campo cCT para que o próprio componente gere de forma aleatória o referido código.

Bom dia a todos, Lembrem-se que alguns pacotes devem ser apenas compilados, outros compilados e instalados, o ACBrComum deve ser apenas compilado. Vide Arquivo de Instalacao.txt -Procure pela pasta Pacotes\Delphi e abra o arquivo synapse.dpk e clique em compile. Procure pela pasta Pacotes\Delphi e abra o arquivo ACBrComum.dpk e clique em compile. Procure pela pasta Pacotes\Delphi e abra o arquivo ACBrDiversos.dpk e clique em compile e depois clique em Install. Procure pela pasta Pacotes\Delphi e abra o arquivo ACBrCapicom.dpk e clique em compile. Procure pela pasta Pacotes\Delphi\ACBrNFe2 e abra o arquivo PCN2.dpk e clique em compile. Procure pela pasta Pacotes\Delphi\ACBrNFe2 e abra o arquivo ACBr_NFe2.dpk e clique em compile e depois clique em Install.

Bom dia Graça, Verifiquei a estrutura do xml com os schemas, não encontrei nada de errado. Acredito que o problema seja a chave, como foi alterada (seguindo agora a mesma estrutura da NFe) as rotinas de checagem da SEFAZ não devem estar 100% dai o erro. Mas vamos continuar realizando as verificações.

Boa noite Graça, Sim, o colega Janis de Uberlândia, tambem esta com o mesmo problema.

Realmente se deixar o campo cCT com o valor zero o componente vai gerar um código aleatório para ele. Vou checar esse problema de estar gerando um outro código ao montar o lote de envio.

Boa tarde, Eu procedo de forma diferente, a minha aplicação é que gera o código aleatório e atribui ao campo: CTe.ide.cCT, desta forma nunca tive problemas com a chave. Outro detalhe na tabela do banco de dados que utilizo para armazenar os dados do conhecimento, é salvo também o código aleatório, a chave completa (com o código aleatório e digito verificador), data de emissão, numero do protocolo de autorização, data de cancelamento, justificativa, protocolo de cancelamento, claro se ocorrer o cancelamento. Uma duvida: Após alimentar o componente com os dados, esta sendo executado apenas o comando Enviar ou esta sendo executado os comandos: Assinar, Validar e Enviar ? O comando Assinar, gerar o XML (inclusive a chave) assina e salva em disco. O comando Validar, executa o comando Assinar e depois valida o XML gerado. O comando Enviar, executa os comandos Assinar e Validar e depois gera o lote e o envia, se a sefaz não rejeitar, o XML assinado recebe o protocolo de autorização e o DANFe é impresso no papel.

Reveja as suas rotinas, você esta atribuindo duas vezes o valor zero a: CTe.ide.cCT A primeira ao gerar o XML e assinar e a outra ao enviar.

Bom dia, Compare a chave do CTe que consta no arquivo: -cte.xml com o 1-env-lot.xml Note que o final esta diferente: CTe35111104947886000136570010000051012089026832 CTe35111104947886000136570010000051017992715225 A tua aplicação esta gerando uma nova chave no momento do envio, favor rever a sua rotina. Espero ter ajudado.

Bom dia Juliano, A falha foi minha. Obrigado por informar sobre a falha no componente, já esta disponivel a correção tanto no fonte pcteCTeW quanto no pcteCTeR.

Boa tarde Juliano, Sim, de uma olhada no manual, página 116.