BigWings

Veja que a validação está falhando em uma tag chamada Codigo. O tipo no RPS está correto. Pode estar com erro em outro campo.

try ... except on E:Exception do ShowMessage('O erro retornado foi: ' + E.Message); end;

Verifique as cadeias de certificado. Alguns webservices estão exigindo o certificado "Autoridade Certificadora Raiz Brasileira v5" instalado. No caso do WinCrypt, experimente mudar a propriedade SSLType, para usar TLS 1.2. No CAPICOM, veja as configurações avançadas do IE.

var NF: TNFSe; begin NF := ACBrNFSe1.NotasFiscais.Add.NFSe; NF.Servico.CodigoMunicipio := IntToStr(ACBrNFSe1.Configuracoes.Geral.CodigoMunicipio);

O tipo da propriedade está definido na unit ACBrDFeSSL.pas, então você precisa incluir ela no uses.

Algum erro no código? Mande salvar os arquivos de envio e retorno e analise.

A melhor forma é abrir o arquivo Cidades.ini. Se a cidade estiver lá, é grande a chance de o componente atender.

Pode ser um erro no Manual, o texto é exatamente igual ao do grupo anterior (ICMSUFFim).

De que alteração está falando? O ICMS para a UF de destino é apenas em operações interestaduais para consumidor final não contribuinte. Então, assim como na NFe, no CTe também só deve ser informado quando indIEToma = 9 (Nâo contribuinte).

OpenSSL não funciona com certificados A3, como você diz que está usando, na sua primeira mensagem. Com A3 você pode usar WinCrypt e CAPICOM. Apenas CAPICOM exige registro das DLLs. Depois de ativar a diretiva {$DEFINE DFE_SEM_CAPICOM}, você recompilou o ACBr e a sua aplicação? Para usar as DLLs da pasta MinGW também é preciso ativar a diretiva, recompilar o ACBr, etc.. e são usadas apenas no OpenSSL. Se ainda não conseguir, poste o retorno do instala.bat do Capicom.

Achei que seria o mesmo problema que ocorria na NFe, que aceitava unidades com três caracteres, e não com dois. Sendo assim, parece não ser o mesmo caso.

Se informar mais que dois caracteres no campo, passa na validação?

Qual é exatamente o erro?

Você precisa instalar os componentes, execute o ACBrInstall_Trunk2.exe. Acredito que não funcionará no D6, alguns usuários ainda conseguem usar no D7, mas o recomendado é Delphi 2009 em diante.

Tem no fonte: procedure TACBrNFeFRClass.PintarQRCode(QRCodeData: String; APict: TPicture); var QRCode: TDelphiZXingQRCode; QRCodeBitmap: TBitmap; Row, Column: Integer; begin QRCode := TDelphiZXingQRCode.Create; QRCodeBitmap := TBitmap.Create; try QRCode.Data := QRCodeData; QRCode.Encoding := qrUTF8NoBOM; QRCode.QuietZone := 1; //QRCodeBitmap.SetSize(QRCode.Rows, QRCode.Columns); QRCodeBitmap.Width := QRCode.Columns; QRCodeBitmap.Height := QRCode.Rows; for Row := 0 to QRCode.Rows - 1 do begin for Column := 0 to QRCode.Columns - 1 do begin if (QRCode.IsBlack[Row, Column]) then QRCodeBitmap.Canvas.Pixels[Column, Row] := clBlack else QRCodeBitmap.Canvas.Pixels[Column, Row] := clWhite; end; end; APict.Assign(QRCodeBitmap); finally QRCode.Free; QRCodeBitmap.Free; end; end;

Que eu saiba o ACBrBoleto apenas gera o código de barras, e não tem método para fazer o inverso. Você pode estudar o método de geração do código para cada banco e deduzir o inverso.

Pelo que entendi você tem um XML já cancelado na SEFAZ mas sem o protocolo de autorização no arquivo, e na consulta quer obter o protocolo de autorização. Entendi? Seria um caso a se analisar, qual o protocolo retornado na consulta. Sendo apenas o de cancelamento, ficaria difícil...

Bom dia, Veja que essas opções só são usadas na impressão EscPos. Se estiver usando impressão em Fortes, elas não se aplicam.

Qual versão do Delphi está usando? O FastMM é integrado ao Delphi desde o Delphi 2006.

Uma nova instância do ACBrNCM é criada a cada alteração do NCM, vazamento de memória. Coloque no Create da classe. Você não está tratando o resultado do método Validar pra saber se o NCM é válido ou não, e tratando apenas uma classe de exceção, inclua a on E:Exception do aí.

As impressoras fiscais da primeira geração (matriciais) faziam isso. A integração era por meio da DLL de comunicação com a ECF mesmo. Isso está em desuso, já que é bem mais simples emitir um recibo na impressora não fiscal, mas pelo jeito, ainda se encontra equipamentos do tipo. Fiz uma busca e encontrei esta: https://www.zipautomacao.com.br/impressora-nao-fiscal/termica/impressora-nao-fiscal-termica-im453hu-diebold

Não. O valor impresso no DANFe é o valor da tag vPag do XML.

Você tem retorno dos dois modos, apenas no modo síncrono é feita apenas uma chamada ao WebService, o retorno é obtido imediatamente. No modo assíncrono, na primeira chamada você só recebe um número de recibo que é usado em uma segunda chamada (de consulta do recibo) para obter o resultado do envio. Não entendi que "garantia" você pode ter usando o assíncrono. A vantagem no modo assíncrono é a possibilidade de envio em lotes de notas, no modo síncrono a velocidade por chamar apenas um webservice é o diferencial. Eu tenho usado apenas modo síncrono.

Creio que o componente DANFe ainda não está carregando a tag troco do XML 4.00, precisa informar diretamente na propriedade vTroco. Observação correta, a meu ver. Segundo o manual: Precisa apenas ter cuidado de fazer a alteração para todos os tipos de impressão.

Bom dia, Na minha interpretação o XML válido é o com o protocolo de autorização ou denegação. Cancelamento é um evento vinculado à nota e tem seu XML próprio. A atualização do XML no cancelamento é uma prática que vem do tempo da NFe 1.0, e por comodidade para importação do XML foi mantido no ACBr. Para desativar esse comportamento, configure a opção: ACBrNFe1.Configuracoes.Geral.AtualizarXMLCancelado := False;