Data Lider

Cidade/UF: Linhares-ES, Vila Valério - ES, São Mateus - ES, João Neiva - ES Previsão de Mudança: a partir de Janeiro de 2026 Tipo de Mudança: E&L Novo Layout Fonte/Documentação: https://s3.us-east-1.amazonaws.com/el.com.br/nfse/Layout_EL_DPS_Nacional_V1.zip Url Homologação Linhares : https://notafiscal-backend.linhares.es.gov.br/producao/api/nacional/homologacao/nfse Url Homologação Vila Valério: https://es-vilavalerio-pm-nfs-backend.cloud.el.com.br/producao/api/nacional/homologacao/nfse Url Homologação São Mateus:https://es-saomateus-pm-nfs-backend.cloud.el.com.br/producao33/api/nacional/homologacao/nfse Url Homologação João Neiva: https://es-joaoneiva-pm-nfs-backend.cloud.el.com.br/producao12/api/nacional/homologacao/nfse Alteração realizada no arquivo ACBrNFSeXServicosRTC.ini

Recentemente João Neiva saiu do padrão próprio do provedor E&L e foi para o 2.04 ABRASF do mesmo provedor. ANTES: [3203130] ; Incluído em 16/10/2023 Nome=Joao Neiva UF=ES Provedor=EL ProRecepcionar=https://es-joaoneiva-pm-nfs.cloud.el.com.br/RpsServiceService ProLinkURL=https://es-joaoneiva-pm-nfs.cloud.el.com.br/paginas/sistema/autenticacaoNota.jsf?cpfCnpj=%Cnpj%&chave=%CodVerif% HomLinkURL=https://es-joaoneiva-pm-nfs.cloud.el.com.br/paginas/sistema/autenticacaoNota.jsf?cpfCnpj=%Cnpj%&chave=%CodVerif% DEPOIS: [3203130] ; atualizado em 30/10/2025 Nome=Joao Neiva UF=ES Provedor=EL Versao=2.04 ProRecepcionar=https://es-joaoneiva-pm-nfs-backend.cloud.el.com.br/producao12/NfseWSService ProLinkURL=https://es-joaoneiva-pm-nfs.cloud.el.com.br/paginas/sistema/autenticacaoNota.jsf#/autenticacao?documento=N&cpfCnpj=%Cnpj%&chave=%CodVerif% Um detalhe com o qual não vou poder ajudar agora, mas talvez no futuro, é que o ProLinkUrl de praticamente todos os municípios na versão 2.04 com provedor EL está incorreto. O que funciona é este atual: paginas/sistema/autenticacaoNota.jsf#/autenticacao?documento=N&cpfCnpj=%Cnpj%&chave=%CodVerif%.

Prezados, ao migrar a MDF-e para o FPDF vimos que a impressão aparece com boa parte dela cortada. vide imagem abaixo: Porém por obviedade ele deve estar funcionando em várias outras plataformas, mas no nosso caso que é VCL + Windows + Compilador 35.0 não. Depois do nossos ajustes o relatório ficou corretamente impresso: O que foi alterado no código? Adicionado uma constante global para o posicionamento vertical do conteúdo do relatório. O relatório mesmo sem a logomarca, ficava o espaço em branco escrito Logo. A constante global por padrão está definida com o valor original para não afetar quem já usa, mas se o compilador for igual ao nosso, com VCL e Windows, vai alterar para o alinhamento esperado. implementation const {$IFDEF DELPHI} {$IF Defined(MSWINDOWS) AND Defined(VCL) AND (CompilerVersion >= 35.0)} globalY: integer = 30; {$ELSE} globalY: integer = 0; {$ENDIF} {$ELSE} globalY: integer = 0; {$ENDIF} ACBrMDFeDAMDFeFPDF.pas

Prezados depois de algumas ligações para o nosso suporte verificamos que a cidade de São Mateus no Espírito Santo migrou da versão do layout próprio do provedor E&L para a versão ABRASF da E&L. Fizemos os testes com os seguintes valores e o problema foi resolvido: [3204906] Nome=Sao Mateus UF=ES Provedor=EL Versao=2.04 ProRecepcionar=https://es-saomateus-pm-nfs-backend.cloud.el.com.br/producao33/NfseWSService ProLinkURL=https://es-saomateus-pm-nfs.cloud.el.com.br/#/autenticacao?cpfCnpj=%CnpjComMascara%&chave=%CodVerif%&numero=%NumeroNFSe% HomLinkURL=https://es-saomateus-pm-nfs.cloud.el.com.br/#/autenticacao?cpfCnpj=%CnpjComMascara%&chave=%CodVerif%&numero=%NumeroNFSe%

A EL está na maioria das cidades atendendo o padrão ABRASF agora, porém algumas cidades que não atualizam para a versão nova do provedor E&L ainda acabam usando o padrão deles, vai depender da cidade. A questão da observação você está correto, não estava saindo com o XML que mandei, acontece que a EL não permite usar o campo <OutrasInformacoes> durante a transmissão do XML, esse campo ficou exclusivamente para a prefeitura preencher com informações internas deles, ai o XML que te mandei está com o campo <InformacoesComplementares>, antes da impressão quando o provedor é E&L nosso sistema copia as informações para sair também na parte de baixo alimentando o campo OutrasInformacoes do DANFE. No XML que mandei agora eu troquei o campo InformacoesComplementares por OutrasInformacoes assim irá funcionar nos seus testes. E também fiz um teste usando a demo da AcbrNFSeX + Fast e consegui testar com sucesso fazendo assim. Eu anexei o XML alterado. teste.xml

Segue o xml para teste do problema, devido o texto ser repetido tente selecionar com o mouse para ver que ele está por trás da imagem. (Alguns dados troque por zeros e xxxx) Então, a respeito disso, como mencionado no tópico, o evento foi transferido para o BeforePrint da banda PageFooter1, logo essa abordagem fixa não funcionou mais, não sei explicar o motivo, mas basta trocar o local do evento e deixar o mesmo código que você vai confirmar o problema. o evento foi transferido para o BeforePrint da banda PageFooter1. teste.xml

Prezados, tivemos algumas ocorrências de clientes ligando devido algumas partes cortadas da observação na DANFSe do arquivo "DANFSeNovo.fr3". Conforme pode ser observado abaixo O Problema Nós identificamos que esse problema já foi tratado em algum momento dentro do próprio arquivo "DANFSeNovo.fr3", porém o tratamento pode funcionar diferente a depender do versão do FastReport (assim nós imaginamos). No AfterPrint da do componente imgQrCode, foi adicionado um código que fixa o width do campo Memo34 para 16. O problema de fazer dessa forma, é que isso não garante que a observação já não tenha sido "processada" antes pelo relatório, fazendo que o código do AfterPrint do imgQrCode não altere a observação, além de dificultar o teste porque hora o Fast pode processar o imgQrCode depois do Memo34, gerando aquele problema que uma hora da certo, e outra hora da errado. Como resolvemos O evento foi removido do AfterPrint de imgQrCode, e adicionado no BeforePrint da banda PageFooter1, e o código ajustado para funcionar no novo local. // Código anterior dentro do relatório if imgQrCode.Visible then memo34.Width := 16; Depois: // Código depois da alteração if imgQrCode.Visible then memo34.Width := memo34.Width - imgQrCode.Width; Resultado: DANFSeNovo.fr3

Prezados, segue dados do provedor dos municípios de Sooretama e João Neiva no Espírito Santo, já suportados pela ACBR. Sooretama: [3205010] Nome=Sooretama UF=ES Provedor=EL Versao=2.04 ProRecepcionar=https://es-sooretama-pm-nfs-backend.cloud.el.com.br/producao20/NfseWSService HomRecepcionar= ; ProLinkURL=https://es-sooretama-pm-nfs.cloud.el.com.br/paginas/sistema/login.jsf#/autenticacao?cpfCnpj=%Cnpj%&chave=%CodVerif% HomLinkURL= João Neiva: [3203130] Nome=Joao Neiva UF=ES Provedor=EL ProRecepcionar=https://es-joaoneiva-pm-nfs.cloud.el.com.br/RpsServiceService HomRecepcionar= ; ProLinkURL=https://es-joaoneiva-pm-nfs.cloud.el.com.br/paginas/sistema/autenticacaoNota.jsf?cpfCnpj=%Cnpj%&chave=%CodVerif% HomLinkURL=https://es-joaoneiva-pm-nfs.cloud.el.com.br/paginas/sistema/autenticacaoNota.jsf?cpfCnpj=%Cnpj%&chave=%CodVerif% Todos dois testados em produção. Arquivo na revisão 30965 ACBrNFSeXServicos.ini

Prezados, existem outros tópicos de pessoas que questionaram, pediram ou sugeriram a adição da possibilidade de impressão de NFE com o componente ACBrNFeDANFeESCPOS. No último tópico a respeito disso foi sugerido que fosse alterado ACBrNFeDANFeESCPOS para ACBrNFCeDANFeESCPOS, e que o ACBrNFeDANFeESCPOS fica-se apenas para NF-e. Eu alterei o código ACBrNFeDANFeESCPOS e adicionei apenas duas propriedades (que podem ser renomeadas talvez para algo mais adequado) para determinar a adoção da "NT2020.004 - DANFE_SIMPLIFICADO v1.00" que prevê a DANFE em modelo reduzido. Como a NT não determinar um layout, mas sim apenas campos obrigatórios, eu preservei o máximo do layout atual do arquivo atual, bem como do código. Algumas impressoras ESCPOS não consegue imprimir códigos de barras c128 com 44 dígitos, o que teoricamente (questão de interpretação talvez da NT?) inviabiliza o uso do modelo, mas mesmo assim adicionei uma propriedade para desativer a impressão do código de barras c128 da chave de acesso. ACBrNFeDANFeESCPOS.pas

Prezados, estamos tendo problemas com algumas notas de entrada de telecomunicações, não sei constatar se era uma problema com versões antigas do PVA que não validavam corretamente, ou se ninguém mesmo estava lançando notas de telecomunicações de entrada no componente da ACBR, falo isso porque olhando em guias antigos da EFD o campo TP_ASSINANTE é antigo, e a não obrigatoriedade para entrada também é. Mas fato é que o arquivo texto está indo com zero quando informado o valor TP_ASSINANTE := TACBrTpAssinante.assNenhum; no registro D500, e como zero não está previsto nem mesmo quando obrigatório, acontece um problema de validação, pelo menos nessa versão do PVA atual. Segue a correção em anexo, junto com algumas imagens para auxílio na verificação. A relação de obrigatoriedade Os valores válidos A correção Arquivo: ACBrEFDBloco_D_Class.pas Linha: 1618 ACBrEFDBloco_D_Class.pas

Prezados, hoje ao realizar alguns testes em produção restrita em preparação para maio, verifiquei que o evento R-9000 deixou de funcionar. Depois de um bom tempo, verifiquei que na versão do SVN 21191 foi adicionado o novo schema do evento 2055, aumentando o tamanho da array TReinfSchemaStr, porém na implementação do arquivo pcnConversaoReinf.pas, na função StringXMLToTipoEvento está fixo o tamanho da iteração com o FOR usando essa Array. A função StringXMLToTipoEvento é usada para descobrir de qual schema de evento se trata o xml que está sendo assinado pelas LIB de Assinatura de XML, logo como o evento de exclusão é o último da array, a assinatura dele passou a não ser possível mais (Provável que afete a produção também). Segue a correção, eu já fiz o envio de um r-9000 e foi normalmente. pcnConversaoReinf.pas

Não, erro meu mesmo. Obrigado! Edição do Post: Na verdade, eu não subiu a alteração para a NFC-e, ai ficou assim (igual ao primeiro), vou carregar aqui, e desculpa. (TACBrNFeDANFCEFR) ficou sem o Thread Safe. ACBrNFeDANFEFR.pas

Segue os arquivos novamente, faltou adicionar a NFCe também. Olhando aqui a classe, se não quiserem implementar essa sugestão, pelo menos então se puderem deixar o objeto do tipo TACBrNFeFRClass em protected or public das classes TACBrNFeDANFEFR/TACBrNFeDANFCEFR para quem precisar dessa implementação. ACBrNFeDANFEFR.pas ACBrNFeDANFEFRDM.pas

No código está condicionado a uma variável estar True, e a versão testada foi a Emb Edition. No help do componente, essa propriedade existe desde o FR4. Na versão de teste de vocês, com vários ambientes diferentes, talvez pode acontecer de algum não compilar por não existir em componentes antigos, ai seria o caso então, de condicionar também no ACBR.inc acredito.