BigWings

Obrigado por reportar. Corrigido no SVN, rev.19883.

Marque a opção de salvar os arquivos de envio e retorno, e analise o XML retornado pelo webservice, se houver.

Por favor, atualize os fontes novamente. Foram enviados alguns ajustes para o tratamento de erros de conexão http.

Não sei se entendi bem o que você quer, mas veja a configuração "Quebrar linhas em detalhe dos itens" na configuração de impressão. Pra ser impresso uma ao lado da outra essa opção deve estar desmarcada.

O que notei de errado que pode estar causando a rejeição: - nSeqEvento deve ser sempre 1 para esse tipo de evento. - No grupo infBanco deve ser informado codBanco e codAgencia ou CNPJIPEF. Nunca as três tags.

No demo foi normal, mesmo definindo MostraSetup = False. A minha versão do Fast é a 6.0 Standard com FastScript. Como o Juliomar disse, pode ser isso, só não temos como testar.

Tem tópicos no fórum pra resolver isso. Pesquise por "FormularioContinuo". Não consegui replicar. Ocorre com qualquer XML? O erro ocorre usando o demo disponível em ACBr\Exemplos\ACBrDFe\ACBrNFe\Delphi DANFe FR? Está usando o Fast Report comercial ou o que vem junto com o Delphi?

Já houve relato no fórum dessa opção causar problemas: Se me lembro ela afeta as declarações do tipo packed record que pode ter comportamento diferente de acordo com a opção de compilação. Então sugiro que mantenha no padrão do Delphi (8).

Os fontes do ACBr são originalmente escritos em Pascal, para Delphi e Lazarus. https://projetoacbr.com.br/fontes/ Para outras linguagens existe o ACBrMonitorPLUS, que é um aplicativo que faz integração via arquivos texto ou socket TCP, e a ACBrLib, que é uma DLL que pode ser instanciada pelas aplicações. A DLL é desenvolvida em Lazarus, tem um demo em C# aqui: https://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/Demos/C%23/Sat/Demo Aqui tem a DLL já compilada (se não me engano está disponível apenas para assinantes do SAC ACBr):

É este que está usando? https://github.com/ACBrNet Esse projeto é paralelo, não é oficial do Projeto ACBr. Sugiro que informe problemas no issues do github.

O nome do arquivo é formado por: - Código do tipo do evento: 110111 - Chave do CTe: 42200504632696000120570010000041671949769479 - Sequencial do evento: 01 - Sufixo -procEventoCTe Aparentemente a chave gerada no nome do arquivo está diferente da chave que está sendo informada no evento. Você tinha algum XML carregado no componente no momento do envio do evento de cancelamento? O ideal é fazer a limpeza antes do envio, chamando. ACBrCTe1.Conhecimentos.Clear; ACBrCTe1.EventoCTe.Evento.Clear;

Se estão atualizados você está na revisão 19796, que foi a última alteração no arquivo GovDigital.ini: Perguntei se você testou com a revisão 19763, que era a versão anterior, onde foram atualizadas as URL. Na revisão 19796 foi alterado o namespace. Nos testes que fiz, na revisão 19763, a assinatura é validada com sucesso no site da receita, já na revisão 19796 a assinatura não é validada. Então se você está usando o .ini da revisão 19796, tente reverter o arquivo para a 19763 e testar.

O mesmo erro da revisão 19796?

Com o .ini da revisão 19763 funciona?

A linha de comando do compilador ultrapassou o limite do Windows de 32000 caracteres. Pra evitar isso você pode tentar reduzir o caminho de instalação dos componentes para algo como C:\Fortes e C:\ACBr. No caso do ACBr existe a opção no instalador de usar arquivo de configuração .cfg que não gera essa linha de compilação extensa, então você também pode remover a instalação do ACBr, deletando os pacotes no Delphi em Component - Install packages e tirando as referências ao ACBr do library path. Após isso instalar o Fortes, depois o ACBr novamente.

Para assinantes do SAC no regime anual tem o chat via Flock.

Informe [Titulo1].

Favor não colar conteúdo extenso no corpo da mensagem, prejudica a leitura. Use a opção de anexar arquivos. Significa que provavelmente você tinha alterações locais no arquivo, e houve conflito no momento de atualizar os fontes do SVN. Você precisa resolver os conflitos (opção "Resolve" do Tortoise) ou reverter os fontes (Revert) pra descartar as tuas alterações locais e usar o código do repositório.

Verifique na sua rotina qual valor passou para a tag vDesc. Se for um valor maior que 0.00 e menor que 0.01 vai acontecer isso, gerar o valor 0.00 que não é aceito pelo layout.

Desde que seja a data de autorização mais alta numa NFCe anterior, emitida em contingência offline, não tem problema. Mas se foi alterada a data de emissão para a data que ela foi retransmitida, não deve acontecer, a SEFAZ pode entender como tentativa de fraude e vir a pedir explicações. Sugiro que converse com o contador da empresa e explique a situação pra que ele tome as providências que julgue necessário.

Veja a propriedade ACBrTEFD.TEFCliSiTef.OperacaoCRT. Informe 3 para crédito e 2 para débito.

O último aviso é da desativação dos protocolos antigos em 21/01/2020: https://receita.fazenda.rs.gov.br/conteudo/11832/df-e%3A-desativacao-imediata-do-protocolo-ssl%2C-e-novas-datas-de-desativacao-dos-protocolos-tls-1.0-e-tls-1.1 Talvez eles tenham atrasado algo no cronograma, como é de praxe... Na verdade isso já devia ter sido feito há anos, de acordo com a documentação da NFe 4.00.

Ainda pode usar Windows XP com OpenSSL para acessar TLS 1.2, desde que o certificado seja o A1.