EMBarbosa

Dei uma olhada geral sobre o Declaração dos Regimes Específicos (DeRE). Link para documentação e site oficial: http://sped.rfb.gov.br/pagina/show/2919 O formato é XML que será validado por schemas (XSD) e assinado para depois ser transmitido por WebService para um Ambiente Nacional da DeRE. O envio pode acontecer em lotes e o processamento é assíncrono. Notei que as informações e os nomes utilizados se assemelham ao Reinf e e-Social. Por exemplo chamam os arquivos XML de eventos (veja 2.1) e usam uma nomenclatura D-XXXX, por ex. D-1001, D-1011 e D-9001. Assim, talvez esses sejam os componentes mais similares na implementação. Pontos que eu achei de interesse no manual para quem fizer a implementação: Sobre a questão: A legislação que estabelece diz: A DeRE está especificada no Art. 1º § 2º. Então teoricamente, é o mesmo prazo. Relacionado:

Para o Padrão Nacional não existe, como eu disse anteriormente. E até onde eu sei, também não existe uma Norma Técnica definindo isso para outros "provedores". Considerando que tudo é uma questão de legislação municipal e no Brasil temos mais de 5 mil, talvez algum provedor de algum município tenha uma sugestão de leiaute. Mas eu desconheço.

Desculpe... não entendi sua pergunta. Pode elaborar novamente?

Atualmente não existe um padrão nacional definido para a impressão do DANFSe. Por isso cada município pode adotar o formato que considerar adequado. O modelo impresso pelo ACBr já contempla todos os dados previstos no XML, garantindo a integridade das informações e sem trazer prejuízo na utilização. Até o momento, não temos conhecimento de nenhuma legislação municipal que exija um layout específico para o DANFSe. Por isso, embora estejamos avaliando possíveis ajustes, não temos previsão de alterar nossos modelos de impressão para ficar idêntico ou mais semelhante ao modelo GOV no momento. Em tempo, a ACBrLib e o ACBrMonitor não funcionam com o modelo de impressão do Fast Report.

Olá @Light System Software, Por favor, sempre crie um tópico novo para uma dúvida nova conforme as regras. Veja neste link aqui, em especial a "2.2 - Permaneça no assunto". Dessa vez, eu dividi o tópico para você. Sobre sua dúvida: Veja os campos (nessa ordem): NFSe.IBSCBS.finNFSe NFSe.IBSCBS.indFinal NFSe.IBSCBS.IndOpeOne

Eu não sei se isso é possível. Pelo exemplo da documentação, o XML é diferente e por isso teria que modificar a geração dele. Conforme abaixo: <tpNFTS><TipoDocumento>VALOR</TipoDocumento><ChaveDocumento><InscricaoMunicipal>VALOR</In scricaoMunicipal><SerieNFTS>VALOR</SerieNFTS><NumeroDocumento>VALOR</NumeroDocumento></Ch aveDocumento><DataPrestacao>VALOR</DataPrestacao><StatusNFTS>VALOR</StatusNFTS><Tributaca oNFTS>VALOR</TributacaoNFTS><ValorServicos>VALOR</ValorServicos><ValorDeducoes>VALOR</Val orDeducoes><CodigoServico>VALOR</CodigoServico><CodigoSubItem>VALOR</CodigoSubItem><Aliqu otaServicos>VALOR</AliquotaServicos><ISSRetidoTomador>VALOR</ISSRetidoTomador><ISSRetidoI ntermediario>VALOR</ISSRetidoIntermediario><Prestador><CPFCNPJ><CNPJ>VALOR</CNPJ></CPFCNP J><InscricaoMunicipal>VALOR</InscricaoMunicipal><RazaoSocialPrestador>VALOR</RazaoSocialP restador><Endereco><TipoLogradouro>VALOR</TipoLogradouro><Logradouro>VALOR</Logradouro><N umeroEndereco>VALOR</NumeroEndereco><ComplementoEndereco>VALOR</ComplementoEndereco><Bair ro>VALOR</Bairro><Cidade>VALOR</Cidade><UF>VALOR</UF><CEP>VALOR</CEP></Endereco><Email>VA LOR</Email></Prestador><RegimeTributacao>VALOR</RegimeTributacao><DataPagamento>VALOR</Da taPagamento><Discriminacao>VALOR</Discriminacao><TipoNFTS>VALOR</TipoNFTS><Tomador><CPFCN PJ><CPF>VALOR</CPF></CPFCNPJ><RazaoSocial>VALOR</RazaoSocial></Tomador></tpNFTS> Por outro lado, parece que a comunicação é idêntica. Então, se a estrutura for a mesma, com campos correspondentes, seria possível criar um "Provedor" para a NFTS. Aí seria possível alimentar o ACBrNFSeX com os dados e ele gerar e transmitir. A questão seria avaliar se a estrutura é a mesma e ter alguém disponível para fazer a implementação do "Provedor para NFTS".

Boa tarde. Não... A solução ACBr (seja Lib, Monitor ou componente) verifica as configurações do município e do provedor. Com base nessas configurações ela gera o XML que por sua vez deve atender aos schemas. Isso depende do modelo que eles vão utilizar. Se é um modelo próprio então depende de ajustes. A vantagem é que no momento que ajustamos para um município, geralmente fica tudo certo para todos os outros municípios que utilizam o mesmo provedor e modelo. Como o @Diego Foliene mencionou antes, os ajustes já estão sendo feitos para vários provedores. Na verdade pelo tópico que você linkou no início, os ajustes parecem já terem sido feitos. Vocês não precisariam adicionar porque, no tópico que você citou já tem os schemas. Assim, os schemas vão ser disponibilizados juntamente com a Lib. Então quando eles estiverem disponíveis na Lib vocês podem usá-los. Dito tudo isso, uma coisa vocês precisam ajustar. A emissão do lado de vocês precisará seguir o novo modelo. Nesse sentido, veja se esse tópico ajuda: https://www.projetoacbr.com.br/forum/topic/88289-em-01012026-a-sua-aplicação-de-emissão-de-nfs-e-pode-parar/

Obrigado pelo retorno.

Achei essa outra informação. Parece apontar pra coisa diferente porque tem os dois manuais um para NFS-e e outro para NFTS: https://notadomilhao.sf.prefeitura.sp.gov.br/manuais/

@marciost Criei um chamado no nosso backlog, a saber, ACBR-8607. Obrigado pela contribuição. Assim que possível vamos dar um retorno aqui mesmo.

Olá pessoal, Queremos informar que já está disponível o DACTe feito em FPDF. Uma vantagem desse formato é a geração rápida de um arquivo PDF. Já está disponível no ACBrInstall. E com as próximas compilações da ACBrLibCTe e do ACBrMonitor, deverá estar disponível lá também. Abaixo uma imagem para dar uma ideia de como ficou embora esteja devidamente censurado os dados mais sensíveis (como o código de barras): Como sempre, incentivamos a todos a testarem e nos dar retornos sobre esse novo componente. Bom trabalho e até a próxima!

Olá. Não ficou muito claro. Pode especificar quais valores não passam? O que precisa ser corrigido?

Olá. Você pode anexar também o log gerado pela LIB por favor?

Claro. Criei um chamado no nosso backlog, a saber, ACBR-8545. @Fernando Schuch, Muito obrigado pela contribuição. Assim que possível te dou um retorno aqui mesmo.

Criei um chamado no nosso backlog, a saber, ACBR-8540. Obrigado pela contribuição. Assim que possível vamos dar um retorno aqui mesmo.

Isso mesmo. A validação não passou por conta da letra "A" no meio da chave. Veja:

Olá jeffersonjunglaus, Conseguiu algum retorno do provedor?

Tópico fechado por falta de retorno do usuário

Você precisa verificar o manual e passar a configuração de fonte para o componente. No programa exemplo ilustra como fazer isso. O segundo parâmetro da função `ImprimirTexto` é a fonte. Veja a imagem abaixo:

Me parece fazer sentido a correção. Na verdade o FastStringReplace foi implementado pelo Alexandre Machado e tem vários testes unitários e de performance. Seria interessante verificar novamente se temos alterações locais e, em caso positivo, os motivos. https://bitbucket.org/alex7691/delphi/src/master/FastStringReplace/ Não consegui reproduzir no momento, posso tentar verificar depois.

Atualização: As units relacionadas ao ACBrDI foram adicionadas no pacote "ACBr_NFe". Isso permite colocar esse pacote como dependência no Lazarus para especificar o uso dessas units. Também faz com que a geração do arquivo DCU seja feito pelo ACBrInstall.

Subi suas alterações para o SVN na Revisão 42927. Pelo que vi está tudo certo. Favor testar e reportar qualquer problema. Obrigado.

Subi suas alterações para o SVN na Revisão 42926. Pelo que vi está tudo certo. Favor testar e reportar qualquer problema. Obrigado.

Precisamos fazer aqui na pcnConversaoNFe, o mesmo que fizemos com a ACBrDFe.Conversao. Ou seja, fazer os tipos da pcnConversaoNFe apontar para os tipos da ACBrNFe.Conversao. Por conta do evento do Dia do ACBr e dos esforços para a Reforma Tributária, não conseguimos terminar isso antes. Vamos verificar, mas toda ajuda é bem vinda.