BigWings

Pegue uma NFe emitida e veja a chave da NF-e, são 44 caracteres, compostas pelos campos: nNF é o Número da NF-e. cNF é o Código Numérico. O código numérico deve ser um número aleatório, ele existe para que terceiros não consigam adivinhar a chave de outra nota da mesma empresa. Se o código numérico for igual ao número da NF-e, seu sistema está vulnerável. Entre em contato com o suporte deles.

Poste a mensagem de erro completa.

Parece que não está encontrando o gcc.exe que deveria estar na pasta do compilador, ou ele está corrompido. Pode ser preciso reinstalar o fpc.

O erro indica a falta de assinatura no XML ao tentar fazer a validação do mesmo. Pelo que vi nos fontes o comando Assinar está sendo chamando antes do comando Validar, então não deveria acusar erro. Você está com os fontes atualizados?

Tem vários tópicos abertos sobre isso. Siga o link que o Sérgio postou.

Estão fazendo a configuração do componente para usar a SVC-RS? ACBrNFe1.Configuracoes.Geral.FormaEmissao := teSVCRS; Vejam o que diz o Manual de Orientações, na página 155: Por esse texto, entende-se que no tipo de emissão SVC-RS só se pode consultar NFe também emitidas em contingência.

Caso você carregue um XML não assinado mas já autorizado e execute o método Consultar, vai acontecer isso. Veja se não está gerando novamente o XML sem assinar antes de executar a consulta. Também ative a configuração ValidarDigest para impedir que o protocolo seja incluído em um XML diferente do autorizado.

É na unit blcksock.pas que está definido o tipo TSSLType.

Não existe. Apenas destinatário, transportador e terceiros autorizados no XML podem baixar o arquivo. Para evitar esse caso, as sugestões seriam: - Gravar o XML no banco de dados, como o @Wess sugeriu, em servidor protegido contra tais ataques. - Ter backup dos arquivos Se nada disso foi feito você pode: - Tendo as chaves das notas, baixar uma a uma pelo Portal Nacional da NFe. Há serviços que fazem isso, mas cuidado para que eles retornem o XML assinado e juridicamente válido. O ACBr não tem nada nesse sentido. - Entrar em contato com a SEFAZ e informar o ocorrido, solicitando os XML armazenados por eles.

Favor não duplicar tópicos.

Não tenho certificado de SC pra testar, mas o estado usa a SVRS que aqui está funcionando normalmente. Você ativou a TLS 1.2? Testou com o demo do ACBr? Poste as configurações usadas no demo do ACBr. Está com o fontes atualizados? Veja se está usando o ACBrNFeServicos.ini do svn.

No caso da consulta de cadastro, é usado a UF da IE a ser consultada como referência.

Caso o tpEmit seja igual a 1 (Prestador de serviço de transporte) deve existir um dos seguintes - CPF ou CNPJ do Contratante - Responsável pela geração do CIOT - Responsável pelo pagamento do vale-pedágio. Veja a regra de validação G085:

Parece que finalmente corrigiram o SOAP Action dos serviços para ficar de acordo com o padrão da NT2016.002. Tentem comentar as duas linhas que modificavam o SOAP Action no arquivo ACBrNFeServicos.ini: [NFe_SP_H] {...} ;WSDL=WSDL_V4_SP ;SoapAction=SOAP_V4_SP Depois copiar o .ini para o diretório da aplicação e testar.

ACBrNFe1.NotasFiscais[0].NFe.procNFe.nProt

Não existe diferença na liberação da memória em usar Objeto.Free ou FreeAndNil(Objeto). A única diferença é que o FreeAndNil atribui nil à variável depois de liberar a memória, o que é desnecessário, a não ser que você precise testar o valor da variável novamente, e se você precisa fazer isso, quer dizer que está usando variáveis globais para instanciar objetos, o que é uma prática ruim, na minha opinião. Quanto ao consumo de memória, mesmo que você não esteja tendo vazamentos ao finalizar a aplicação, pode ser que esteja instanciando objetos e não se preocupando em liberar, deixando a aplicação cuidar disso, exemplo: var obj: TMinhaClasse; begin obj := TMinhaClasse.Create(Application); end; Esse código não vai acusar vazamento de memória, pois ao finalizar, o objeto Application que é o Owner do obj se encarrega de finalizá-lo. Mas apenas ao finalizar a aplicação.

Qual erro aparece usando CAPICOM?

Quanto a esse assunto, veja o seguinte tópico:

Usando CAPICOM, pode ser necessário: - Usar Windows 7 ou superior - Estar com as atualizações do Windows instaladas - Atualizar cadeias de certificados atualizadas (consulte o site da certificadora e da SEFAZ) - Marcar a opção "Usar TLS 1.2" nas configurações avançadas do IE.

Inseriu esse código no demo do ACBr?

Esse XML foi gerado pelo ACBrMDFe? Ele tem quebras de linhas e tabulações, isso causa rejeição.

Altere aqui para: [infCIOT001] CIOT=123456789112 CNPJCPF=04467870000126

Eu acho que é, já que é o mesmo erro... Tentou fazer o que resolveu lá pra ele?

Caso deseje contribuir, os fontes estão em: https://svn.code.sf.net/p/acbr/code/ACBrFramework