BigWings

Foi enviada uma atualização recente para padronizar as margens entre os vários DFe em Fast e Fortes, e aplicar as margens onde não estavam sendo aplicadas. Agora as margens devem ser informadas em milímetros e não centímetros (como eram para o DANFE em Fast). Se você não quer que o ACBr mexa nas margens, ou seja, usar as margens definidas no .FR3, basta informar, via código, as margens zeradas: ACBrNFeDANFEFR1.MargemEsquerda := 0; ACBrNFeDANFEFR1.MargemDireita := 0; ACBrNFeDANFEFR1.MargemSuperior := 0; ACBrNFeDANFEFR1.MargemInferior := 0;

Pelo PDF anexado os dados do tomador estão sendo mostrados normalmente. Se você se referia ao campo Tomador que indicava se o tomador era o remetente, destinatário, expedidor, recebedor, pelo que indica no manual da versão 3.00a foi, sim, removido esse campo.

Já tive esse problema com o Fast Report mas como disse não consegui simular neste caso. Chegou a testar usando o arquivo que anexei?

Provavelmente na sua rotina você chamou o método NFref.Add ou NFref.New mas não preencheu os dados do documento referenciado. Se não há documento a referenciar não execute o NFref.Add.

Faça via código.

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

Entendo a frustração, mas sua reclamação é injusta. Todas as alterações ficam registradas no log do svn, arquivos *-change-log.txt, posts no fórum... Você tem tudo o que precisa pra decidir enviar atualização para o teu cliente ou não.

Está sendo verificado. Experimente informar 0 para as margens assim serão usadas as margens do fr3.

Veja que o arquivo assinado pelo ACBr não é o mesmo que você está tentando validar: No seu XML a tag cCT é 229 por isso o ACBrMonitorPLUS corrigiu a chave e gerou arquivo diferente.

A versão do Fast que está usando com o Delphi Rio é a que veio junto com o Delphi? Se for, esse é o problema, essa versão não tem suporte a scripts, e causa problemas desse tipo. Precisa instalar ao menos a versão Standard do Fast Report, e instalar também o Fast Script.

Sobre esse assunto veja este tópico:

Basta executar o comando de assinatura: https://acbr.sourceforge.io/ACBrMonitor/CTEAssinarCTe.html

O XML não está assinado. Ao assinar deve gerar também a string do QrCode.

Tem algumas contribuições ainda em análise pra resolver esse problema. Veja: Ou:

Nessa tag você deve informar o CNPJ do autor do evento, que no caso do evento de prestação em desacordo é o próprio tomador do serviço.

Acho que devia aceitar. Faça teste usando outra configuração SSLXmlSignLib.

Você pode usar certificado próprio e usar o ambiente de homologação do Amazonas: http://portalnfce.sefaz.am.gov.br/desenvolvedor/ambiente-de-homologacao-para-desenvolvedores/ Apenas note que algumas regras são opcionais por UF então nos testes estará sujeito apenas àquelas ativadas pelo AM.

Essa tag não é a IE do emitente do CTe?

Pelo que vi o arquivo é criado quando configurado como cryWincrypt e informando o arquivo PFX e senha, a cada carga do certificado. O componente vai carregar o certificado apenas uma vez então se você mantiver o objeto ACBrNFe em memória deve reduzir massivamente a quantidade de arquivos criados. Outra solução seria usar OpenSSL no lugar da WinCrypt.

Qual exatamente o problema que teve com relação as fontes? Não consegui simular. De qualquer forma fiz ajustes nos nomes das fontes do .fr3, por favor faça teste com o arquivo anexo e veja se terá o mesmo problema. DACTE2Vias.fr3

Pode anexar o XML e PDF para ilustrar o problema?

Você não respondeu minha pergunta.

Qual o erro que está tendo? O validador NFe/NFCe não vai validar mesmo um CFe SAT. São layouts diferentes.

A classe TStringList do Delphi que é usada pelo ACBrBoleto não consegue abrir esse arquivo por causa da codificação, o arquivo está em "UCS-2 Little Endian". Se você abrir esse arquivo no bloco de notas e salvar a codificação vai mudar pra "UCS-2 LE BOM" e já vai conseguir ler o retorno, mas pode ter problemas se houver algum retorno com caracteres especiais. Se você recebeu o arquivo dessa forma direto do banco pode tentar contato com eles pra saber se é possível enviar o mesmo com codificação ANSI. Ou tentar algum método de conversão de codificação de arquivos antes do carregamento pro ACBrBoleto.

Parece algum problema nos próprios arquivos de Schema. Está com a pasta de Schemas atualizada?