Leonardo Gregianin

Impressão de eventos do MDF-e no motor FPDF + ajustes de layout no DAMDFe Motivação O motor FPDF do DAMDFe (TACBrMDFeDAMDFeFPDF) ainda não tinha ImprimirEVENTO/ImprimirEVENTOPDF implementados — qualquer chamada caía no ErroAbstract da classe base (TACBrMDFeDAMDFeClass). Arquivo alterado: Fontes/ACBrDFe/ACBrMDFe/DAMDFE/FPDF/ACBrMDFeDAMDFeFPDF.pas 1. Impressão de eventos do MDF-e (FPDF) Implementados em TACBrMDFeDAMDFeFPDF: ImprimirEVENTO — segue o padrão já usado no restante do arquivo para a FPDF. ImprimirEVENTOPDF (arquivo e stream) — gera o PDF do evento para cada item de EventoMDFe.Evento, seguindo o mesmo padrão de ImprimirDAMDFePDF. Nova classe TMDFeDAMDFeEventoFPDF, genérica para qualquer tipo de evento (TpcnTpEvento). Blocos comuns: cabeçalho (descrição do evento + aviso sem valor fiscal), identificação do MDF-e (modelo/série/número/data emissão/chave + código de barras), dados do evento (órgão/ambiente/data, tipo/descrição/sequencial/versão, status/protocolo/data de registro). Blocos condicionais, usando campos que já existiam em TDetEvento mas sem nenhuma representação gráfica: Evento Bloco específico Campos Cancelamento (110111) Justificativa xJust Encerramento (110112) / Encerramento Fisco (310112) Dados do encerramento dtEnc, cUF, cMun, indEncPorTerceiro Inclusão de Condutor (110114) Condutor incluído xNome, CPF Os demais tipos (Inclusão de DF-e, Pagamento da Operação, Registro de Passagem BR-Id, Confirmação/Alteração de Pagamento do Serviço) imprimem apenas o cabeçalho comum — sem layout no MOC nem mockup de referência (mesmo critério já usado hoje pela FPDF do DANFE/NFe). 2. Ajustes de layout no cabeçalho (TBlocoDadosMDFe.OnDraw) Alinhamento: logomarca, nome do emitente e QR-Code agora começam na mesma altura (antes a logo começava 12mm acima e o QR-Code 8mm abaixo do nome). Tamanho da logomarca: reduzido de 40x30mm para 24x18mm (mantendo proporção 4:3) — no tamanho anterior, alinhar o topo da logo com o nome fazia a base invadir o título "DAMDFE - Documento Auxiliar...". Esse .pas anexo já tem toda a alteração do DAMDFe e dos eventos. ACBrMDFeDAMDFeFPDF.pas

Ajustes de leiaute e correção de dados no motor FPDF do DAMDFE Contexto O motor FPDF de impressão do DAMDFE (TACBrMDFeDAMDFeFPDF) ainda está em ajuste de leiaute (como já indicado no changelog do componente). Ao usar esse motor em produção, foram identificadas divergências em relação ao leiaute oficial e também bugs de dados incorretos sendo impressos. Este PR corrige ambos, comparando cada campo com o Manual de Orientação do Contribuinte (MOC) — Anexo II: Manual de Especificações Técnicas do DAMDFE, versão 3.00b. Testado com um MDF-e real (modal Rodoviário, emissão normal) e, para os demais modais/contingência, com cópias do mesmo XML alterando manualmente <modal>, <tpEmis> e o bloco de dados do modal (<aereo>/<aquav>/<ferrov>). Resumo 3 bugs de dados corrigidos (Vale-Pedágio, RNTRC do cabeçalho, quebra de linha nas Observações) — o layout estava usando a fonte errada ou a configuração errada do componente TextBox, não um problema visual. 2 bugs de "sempre vazio" corrigidos nos modais Aéreo/Aquaviário/Ferroviário (condição de guarda usando um campo que só existe no modal Rodoviário). Dados fictícios/hardcoded substituídos por dados reais do XML nos modais Aquaviário e Ferroviário (Embarcação, Terminal de Carregamento/Descarregamento, Composição do trem, tabela de vagões). Campo novo: "Valor Total da Carga" foi cogitado e revertido — não faz parte do leiaute oficial do Anexo II. Feature nova: rodapé com a mensagem do sistema (MensagemRodape/Sistema), espelhando o que a DANFE FPDF (ACBrNFeDANFeFPDF.pas, TBlocoRodape) já tem — no MDF-e a propriedade já existia e já era preenchida, mas nenhuma band nunca desenhava esse valor na página. Regra nova: "Informações da Composição da Carga" agora só é adicionada quando Ide.tpEmis <> teNormal (emissão em contingência), conforme os mockups do Anexo II. Linhas separadoras abaixo dos títulos de coluna, presentes nos mockups do manual e ausentes na implementação atual. Bug de leiaute — logomarca sobrepondo o título. A logo era desenhada em Image(x, y, 40, 30, ...) com y = -20, ou seja, com a borda inferior em y = +10 — 10mm além do limite inferior do band do cabeçalho (fixo em y = 0), invadindo visualmente a área do título "DAMDFE..." desenhado no band seguinte. Corrigido deslocando a logo (e o placeholder de "sem logo") 10mm para cima. @Daniel Simões de Almeida acredito que as alterações e a adaptação dos modelos de impressão para fpdf seja útil para retirar dependência de projetos externos como fastreport/fortesreport e necessário para utilizar com API. ACBrMDFeDAMDFeFPDF.pas

Suporte a DANFSe v2.0 (NT 008 SE/CGNFS-e) no motor FPDF Contexto / Motivação O leiaute do DANFSe para o Sistema Nacional NFS-e (Ambiente de Dados Nacional) mudou com a NT 008/SE-CGNFS-e — a versão anterior do ACBr.DANFSeX.FPDFA4Retrato (leiaute municipal/ABRASF) não é compatível com o layout exigido para proPadraoNacional. Este PR adiciona um renderer dedicado, no mesmo motor de relatórios (ACBr_fpdf_report/ACBr_fpdf_ext), sem introduzir dependência de bibliotecas de terceiros. Escopo Arquivo novo: Componentes/ACBr/Fontes/ACBrDFe/ACBrNFSeX/DANFSE/FPDF/ACBr.DANFSeX.FPDFPadraoNacional.pas Nova classe TACBrDANFSeFPDFPadraoNacional = class(TFPDFReport), ~1600 linhas. Segue a mesma convenção arquitetural de TACBrDANFSeFPDFA4Retrato (construtor Create(ANFSe: TNFSe), SalvarPDF overloads), mas com um pipeline de bandas (AddBand) próprio, mapeado 1:1 ao Anexo I da NT 008. Arquivos alterados: ACBrNFSeXDANFSeFPDFClass.pas — ExecutaImpressaoPDFUmaNFSe passa a bifurcar por Configuracoes.Geral.Provedor = proPadraoNacional, delegando para o novo renderer; demais provedores continuam no TACBrDANFSeFPDFA4Retrato (comportamento preservado, zero mudança de rota para quem já usa o leiaute municipal). Pacotes/Delphi/ACBrDFe/ACBrNFSeX/DANFSE/FPDF/ACBr_NFSeXDanfseFPDF.dpk — adicionada a unit nova ao contains. Decisões de design relevantes para revisão 1. Grade de campos sem bordas verticais (fidelidade ao gerador oficial) O PDF gerado pelo Sefin Nacional não desenha grade por célula — só linhas horizontais nos limites de bloco (btPageHeader a btPageHeader) e preenchimento cinza claro (5% K) na célula-título, sem traço vertical algum entre colunas (validado extraindo os page.get_drawings() de um PDF de referência real via PyMuPDF: 22 operações vetoriais na página inteira). A implementação original deste PR desenhava uma TFPDF.Rect completa por campo (~800 operações/página). Foi refeita para reproduzir o padrão oficial: DesenharCampo não desenha borda nenhuma (só preenchimento quando Sombreado=True); um único DesenharLinhaSeparadora (uma PDF.Line horizontal) fecha cada bloco. Cuidado de ordem de desenho: a linha separadora é emitida depois do preenchimento cinza do título de bloco (não antes) — como ambos ocupam Y=0 do banda, desenhar a linha primeiro faz o fill cinza pintar por cima e apagá-la. Resultado final: 24 operações/página (a diferença de 2 vs. o oficial é só o modo de desenho do próprio QR Code, ver item 4). 2. Motor de bandas (TFPDFReport/AddBand) Confirmado por leitura de ACBr_fpdf_report.pas: a altura passada a AddBand é a declarada, não a real desenhada — usada pelo motor para posicionar a próxima banda (DrawBand). Cada CalcAltura* precisa bater exatamente com o que o Banda* correspondente desenha, senão sobra/falta espaço entre blocos. btPageFooter ancora sempre no rodapé da página independente do conteúdo acima (DrawLastBands) — por isso todos os blocos fluem em btPageHeader (sequencial) exceto Informações Complementares (btData, altura dinâmica = espaço livre) e Canhoto (btPageFooter, fixo no rodapé), replicando o comportamento observado no gerador oficial (Informações Complementares estica até o Canhoto). 3. Logomarca — sem asset embutido, seguindo convenção já usada no ACBr LogoNFSe: string (caminho de arquivo ou conteúdo binário bruto) — mesmo nome/tipo já declarado em TACBrNFSeXDANFSeClass.LogoNFSe e mesma semântica de TDFeReportFortes.CarregarLogo (usado por NFe/CTe/MDFe/NF3e/NFCom). Sem valor padrão embutido: se vazio, o espaço do cabeçalho fica em branco. 4. QR Code Conteúdo montado a partir de cURLConsultaPublica + ChaveDeAcesso — TNFSe.Link não é preenchido pelo parser do Padrão Nacional (PadraoNacional.LerXml.pas), então o gate de exibição usa infNFSe.ID/ChaveAcesso, não Link. Desenhado via PDF.QRCode (módulo a módulo, retângulos vetoriais pretos) — diferente do PDF oficial, que parece embutir o QR como imagem rasterizada única. Funcionalmente equivalente (QR válido, testado com leitor), mas gera ~700 operações vetoriais extras por página; não normalizado neste PR — encaminhar como possível otimização futura se ACBr_fpdf_ext ganhar suporte a inserir QR como imagem. 5. Mapeamento de fontes NT 008 item 2.4 exige Arial (labels) e Microsoft Sans Serif (conteúdo) — nenhuma é fonte core do FPDF. Mapeadas para 'Arial' (alias interno resolvido para Helvetica core) até que TTFs sejam embarcadas via AddFont. Sinalizar para revisão: isso é uma aproximação visual, não 100% NT-008-literal; embarcar as TTFs certas teria implicação de licenciamento a avaliar antes. 6. Campos dinâmicos por bloco (Tomador/Destinatário/Intermediário/Tributação Municipal) Cada bloco tem duas formas de renderização: grade completa (quando há dado) ou uma única linha "vazia" central (DesenharLinhaVazia, sem grade, mensagem fixa conforme NT 008 itens 2.3/2.5 — ex. TOMADOR/ADQUIRENTE DA OPERACAO NAO IDENTIFICADO NA NFS-e), replicando o padrão do gerador oficial para blocos suprimidos. Exemplo de uso: program ExemploDANFSeComLogo; {$APPTYPE CONSOLE} uses SysUtils, Classes, ACBrNFSeX, ACBrNFSeXConversao, ACBrNFSeXDANFSeFPDFClass, ACBrNFSeXClass; var iNFSe: TACBrNFSeX; DANFSeFPDF: TACBrNFSeXDANFSeFPDF; begin iNFSe := TACBrNFSeX.Create(nil); DANFSeFPDF := TACBrNFSeXDANFSeFPDF.Create(nil); try iNFSe.DANFSE := DANFSeFPDF; iNFSe.SetProvedor(proPadraoNacional); // LogoNFSe e' herdada de TACBrNFSeXDANFSeClass (mesma propriedade usada // por NFe/CTe/MDFe/etc via TDFeReportFortes.CarregarLogo) - aceita // caminho de arquivo... DANFSeFPDF.LogoNFSe := 'C:\CargoPro\Recursos\logo-nfse-horizontal.png'; // ...ou, se preferir nao depender de um arquivo solto no disco, o // conteudo binario da imagem direto na string (ver CarregarLogoNFSeBytes // em ACBr.DANFSeX.FPDFPadraoNacional.pas: se FileExists falhar, o valor // e' tratado como o proprio conteudo do arquivo, nao um caminho): // // var // LogoBytes: TBytes; // begin // TFile.ReadAllBytes(...) ou carregar de um resource (RCDATA) do exe; // DANFSeFPDF.LogoNFSe := TEncoding.ANSI.GetString(LogoBytes); // cuidado com encoding, ver nota abaixo iNFSe.NotasFiscais.Clear; iNFSe.NotasFiscais.LoadFromFile('C:\CargoPro\exemplos\nfse\minha-nota.xml'); DANFSeFPDF.PathPDF := 'C:\CargoPro\Saida'; DANFSeFPDF.Sistema := 'CargoPro'; DANFSeFPDF.ImprimirDANFSe; WriteLn('OK -> ', DANFSeFPDF.ArquivoPDF); finally DANFSeFPDF.Free; iNFSe.Free; end; end. ACBrNFSeXDANFSeFPDFClass.pas ACBr.DANFSeX.FPDFPadraoNacional.pas ACBr_NFSeXDanfseFPDF.dpk

Boa noite @walter faria, Não há necessidade de informar todas as tags conforme está no "Programa Exemplo" do ACBr. Sugiro utilizar o validador da Reforma Tributária (https://dfe-portal.svrs.rs.gov.br/Cff/ValidadorRTC) filtrando por "CTe" para visualizar exatamente quais campos são necessários implementar.

Não disse que não funciona. (Interpretação também faz parte do suporte). Disse que existem melhorias internas feitas que não são aceitas por vocês.

Olhando a quantidade de pedidos que se tem sobre isso no CTe e MDFe aqui no fórum, acredito que deva ter alguma ponderação. Sugiro que deixe o arquivo oficial como está agora e se crie um novo arquivo com modificações mais detalhadas. Obs.: Estou pensando nos colegas desenvolvedores aqui que só utilizando o ACBr oficial direto no repositório. Minha empresa tem duas versões do ACBr, a oficial e outra como milhares de melhorias internas.

Você pode infromar Mesmo o campo "nAver" sendo não obrigatório, a rejeição 699 obriga a informação. Por isso, tem que ser informado todos os dados da apólice RC-V e o número da averbação do CTe para validar e transmitir corretamente.

@Josafar Nascimento da Silv Talvez você esteja informando a tag tpEmit incorretamente. tpEmit inteiro 1 sim informar tipo do emitente: 1 - Prestador de serviço de transporte; 2 - Transporte de Carga Própria. OBS: Deve ser preenchido com 2 por Emitentes de NF-e e pelas Transportadoras quando estiverem fazendo transporte de carga própria 3 - CTe Globalizado Para os tipos 1 e 3 o seguro é obrigatório, para o tipo 2, que parece ser o seu caso, não é obrigatório.

Felipe, se você informar corretamente o vale-pedágio no XML, ele também aparecerá no grupo específico da impressão. Testei com a impressão do FastReport e está aparecendo.

Tive esse mesmo problema com a AT&M e foi exatamente essa orientação deles.

Na prática, a teoria é outra.

Segue anexo alterações na impressão da DAMDFe para mostrar peso tara e capacidade do veículo. Mesmo não constando no MOC da impressão, quanto mais informações melhor e menos multa. ACBrMDFeDAMDFEFR.pas: https://www.dropbox.com/scl/fi/91ayawkf2jncts72cqcl1/ACBrMDFeDAMDFEFR.pas?rlkey=3avo9dwijm1h7gfqw8ce9kh6s&dl=0 DAMDFe_Retrato.fr3: https://www.dropbox.com/scl/fi/slc3xnbu8xh9tslgpnsa0/DAMDFe_Retrato.fr3?rlkey=5at4f2410hstgyx2b90e38glk&dl=0 Index: ACBrMDFeDAMDFEFR.pas =================================================================== --- ACBrMDFeDAMDFEFR.pas (revision 42933) +++ ACBrMDFeDAMDFEFR.pas (working copy) @@ -393,6 +393,8 @@ Add('RNTRCProp', ftMemo); Add('RENAVAM', ftMemo); Add('CNPJCPFProp', ftMemo); + Add('Tara', ftMemo); + Add('CapacidadeKg', ftMemo); // Condutor Add('xNome', ftMemo); Add('CPF', ftMemo); @@ -1760,6 +1762,8 @@ begin FieldByName('placa').AsString := FormatarPlaca(veicTracao.placa) + ' / ' + veicTracao.UF; FieldByName('RENAVAM').AsString := veicTracao.RENAVAM; + FieldByName('Tara').AsString := IntToStr(veicTracao.tara); + FieldByName('CapacidadeKg').AsString := IntToStr(veicTracao.capKG); FieldByName('RNTRCProp').AsString := IfEmptyThen(veicTracao.prop.RNTRC, FieldByName('RNTRC').AsString); FieldByName('CNPJCPFProp').AsString := veicTracao.prop.CNPJCPF; DAMDFe_Retrato.fr3ACBrMDFeDAMDFEFR.pas

A vigência estabelecida pelo fisco é de guarda de 5 anos, preferencialmente a guarda do XML completo.

Bom dia, Foi incluído nas funções de comparação de código IBGE e código TOM algumas cidades que faltavam informar. A comparação foi feita com base no arquivo oficial do Governo Federal conforme este link. ACBrNFSeXConversao.pas

Vale ressaltar que alguns Estados fizeram leis ou portarias estaduais para que transportes feitos entre cidades metropolitanas não fosse necessário a emissão de MDF-e mesmo sendo um transporte intermunicipal.