Diego Foliene

Foi publicada a versão 25.1.F das tabelas fornecidas pelo IBPT, às quais já se encontram também em nosso SVN. As novas tabelas tem a vigência de 20/05/2025 até 30/06/2025. Para cumprimento da Lei 12.741/12, também conhecida como "De Olho no Imposto", não se esqueça de realizar a atualização de seus clientes. Fonte: De Olho no Imposto

Olá pessoal! Atualmente o Projeto ACBr conta com pelo menos mais de 80 diferentes componentes que podem auxiliar a vida do desenvolvedor (e isso contando somente os nativos para Delphi/Lazarus) ! Portanto, entendemos que buscar um auxílio no momento de tirar alguma dúvida sobre algum desses componentes pode ser confuso a princípio, ficando a dúvida de onde essa dúvida deve ser enviada. Por isso, visando facilitar essa jornada, foram adicionadas descrições nos canais em nosso servidor do Discord, com o objetivo de ajudar a todos para que possam se localizar e saber qual é o canal correto para tirar suas dúvidas. Basta conferir no topo do canal. Vejam alguns exemplos: Essas descrições também foram adicionadas nos canais exclusivos para os membros PRO e também nos canais de atendimento exclusivos dos corporativo.

Olá pessoal! Foi prorrogado novo correio eletrônico prorrogando novamente as datas de ativação das regras de validação. As novas datas agora são 07/07/2025, 04/08/2025 e 01/09/2025: Regra de Validação Descrição da Regra de Validação Data de Ativação no ambiente de Produção N12-85 (NF-e) Se informado CST e não informado código de benefício fiscal: verificar se CST exige código de benefício fiscal (tag: cBenef), conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina 07/07/2025 N12-85 (NFC-e) Se informado CST e não informado código de benefício fiscal: verificar se CST exige código de benefício fiscal (tag: cBenef), conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina. 07/07/2025 N12-94 (NF-e e NFC-e) Se informado CST e informado código de benefício fiscal: verificar se código de benefício fiscal corresponde ao CST informado, conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina 04/08/2025 N12-98 (NF-e e NFC-e) Se informado código de benefício fiscal: verificar se o código de benefício fiscal existe e está vigente, conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina. 04/08/2025 N14a-20 (NF-e) Se CST de ICMS = 51 (diferimento) e informado tag:ICMS51/cBenefRBC (id:N14a): verificar se código de benefício fiscal de redução de BC (cBenefRBC) existe, está vigente e corresponde a um código de benefício de redução de base de cálculo (coluna CST 20 = SIM), conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina (NT 2019.001) 04/08/2025 I05h-10 (NF-e e NFC-e) Se informado código de crédito presumido (tag: cCredPresumido): verificar se código de crédito presumido existe, está vigente e corresponde a um código de crédito presumido, conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina (NT 2019.001). 04/08/2025 N12-86 (NF-e e NFC-e) Se informado CST e informado código de benefício fiscal: verificar se CST não possui código de benefício fiscal (tag: cBenef), conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina. 01/09/2025 N14a-10 (NF-e) Se CST de ICMS = 51 (diferimento) e informado tag:ICMS51/pRedBC (id:N14) maior que zero, é obrigatório informar cBenefRBC (id:N14a) (NT 2019.001). 01/09/2025 Leia o novo correio eletrônico na íntegra AQUI.

Olá pessoal! Foi publicada a versão 1.04 desta nota técnica. Alterações A nova versão não trás modificações no leiaute, mas sim ajustes em regras de validação e mensagens. Foram adicionadas as regras de validação 395, 396 e 397 que rejeitam valor do IBSUF, valor do IBSMun e valor do CBS negativos. Datas Foram mantidas as mesmas datas da versão anterior. E como fica o ACBr? Como essa versão não propõe alterações no leiaute e o componente já está adequado a última versão que trazia alterações, então modificações não são necessárias. Leia a versão 1.04 desta nota técnica na íntegra AQUI.

Olá pessoal! Foi publicada a versão 1.01 desta nota técnica. Alterações Essa versão não traz modificações no leiaute, mas sim correção do schema de eventos para comportar o CNPJ Alfanumérico. Datas Foram mantidas as mesmas datas da versão anterior. Leia a versão 1.01 desta nota técnica na integra AQUI

Olá pessoal! Foi publicada a versão 1.04 desta nota técnica. Alterações A nova versão não trás modificações no leiaute, mas sim ajustes em regras de validação e mensagens. Foram adicionadas as regras de validação 395, 396 e 397 que rejeitam valor do IBSUF, valor do IBSMun e valor do CBS negativos. Datas Foram mantidas as mesmas datas da versão anterior. E como fica o ACBr? Como essa versão não propõe alterações no leiaute e o componente já está adequado a última versão que trazia alterações, então modificações não são necessárias. Leia a versão 1.04 desta nota técnica na íntegra AQUI.

Olá pessoal! Foi publicada a versão 1.04 desta nota técnica. Alterações A nova versão não trás modificações no leiaute, mas sim ajustes em regras de validação e mensagens. Foram adicionadas as regras de validação 395, 396 e 397 que rejeitam valor do IBSUF, valor do IBSMun e valor do CBS negativos. Datas Foram mantidas as mesmas datas da versão anterior. E como fica o ACBr? Como essa versão não propõe alterações no leiaute e o componente já está adequado a última versão que trazia alterações, então modificações não são necessárias. Leia a versão 1.04 desta nota técnica na íntegra AQUI.

Olá pessoal! Foi publicada a versão 1.04 desta nota técnica. Alterações A nova versão não trás modificações no leiaute, mas sim ajustes em regras de validação e mensagens. Foram adicionadas as regras de validação 395, 396 e 397 que rejeitam valor do IBSUF, valor do IBSMun e valor do CBS negativos. Datas Foram mantidas as mesmas datas da versão anterior. E como fica o ACBr? Como essa versão não propõe alterações no leiaute e o componente já está adequado a última versão que trazia alterações, então modificações não são necessárias. Leia a versão 1.04 desta nota técnica na íntegra AQUI.

Olá pessoal! Informamos que novas aulas foram adicionadas ao curso Responsável Técnico na NF-e! São 6 novas aulas (a primeira começa por AQUI) explicando o fluxo desde o cadastro como software house até o aceite do pedido de uso no estado do Paraná com direito a material prático demonstrativo e também explicações sobre as rejeições relacionadas ao responsável técnico! Lembrando que os membros Corporativo e PRO tem acesso a essas aulas. Se você ainda não é membro Corporativo ou PRO, clique AQUI para mais informações!

Bom dia! Este arquivo é utilizado no antigo componente ACBrNFSe, a Lib faz uso do componente ACBrNFSeX, então a rotina responsável por gerar o arquivo XML pode ser encontrada na unit ..\trunk2\Fontes\ACBrDFe\ACBrNFSeX\Provedores\Equiplano.GravarXml; Conferindo no arquivo de schema ..\trunk2\Exemplos\ACBrDFe\Schemas\NFSe\Equiplano\1.00\esRecepcionarLoteRpsEnvio_v01.xsd não encontrei o campo tsDsObservacao sendo utilizado, mas encontrei o tsDsImpostos. No entanto, ao conferir na unit rotina que gera o XML, não encontrei elemento para gerar a informação do DsImpostos no arquivo. Criada a #TK-7137 para análise e possível adição do mesmo. Qualquer novidade a respeito será divulgada aqui neste tópico.

Olá pessoal! Esta rejeição foi introduzida pela Nota Técnica 2025/001 e sua regra de validação é como segue: Como descrito na regra e na rejeição, está mensagem é devolvida quando é feito o envio de forma assíncrona de um lote de NF-e contendo apenas uma nota em seu conteúdo. Portanto, para evitar esta rejeição, sua aplicação precisa fazer o envio de forma síncrona caso haja apenas uma NF-e no lote ou fazer o envio de forma assíncrona com um lote contendo no mínimo duas notas. Veja mais sobre os envios síncrono e assíncrono no tópico abaixo:

Olá pessoal! Foi publicado no dia 27/05/2025 a versão 1.04 desta nota técnica. Alterações Esta versão não traz alterações no leiaute. A nova versão adiciona a seguinte exceção na regra de validação responsável por devolver o cStat 600 e a mensagem "CSOSN incomatível na operação com Não Contribuinte": A mensagem de rejeição das regras que devolvem os cStat 835, 836, 311 e 839 foram atualizadas para devolver o número do item que causou a rejeição. Datas Esta nota técnica altera as datas de entrada em vigor no ambiente de homologação e no ambiente de produção para compatibilizar a disponibilização dos schemas XML em conjunto com a NT2025/002 da Reforma Tributária para NFe/NFCe. Implantação Teste: 01/07/2025 Implantação Produção: 01/10/2025 Essas novas datas valem para a NT como um todo e não somente está última versão. Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar em nosso Discord a publicação da nova versão da NT. Leia a versão 1.04 desta nota técnica na íntegra AQUI.

Olá pessoal! Este tópico visa responder as principais perguntas feitas pela audiência nas edições do Papo PRO ACBr correspondentes. Adeus à velha NFe? Prepare seu ACBr - Parte 01 Os layouts e schemas "Integrados" da versão atual + Layout reforma estão no site da Confaz? R: Os arquivos de schema podem ser encontrados no Portal da Nota Fiscal Eletrônica e também em nosso SVN. Para uso com as soluções ACBr é orientado fazer o uso dos schemas disponíveis em nosso SVN! As notas técnicas também podem ser encontras no portal ou em nossa biblioteca tools. Para quem está construindo NFe/NFCe agora no sistema, qual é a orientação? R: Como ainda estamos no período de transição, será necessário construir considerando a tributação existente e os novos propostos pela Reforma Tributária, é um consenso que a melhor forma de fazer isso é deixando o mais parametrizável possível, evitando ao máximo "chumbar" valores e alíquotas direto no código fonte. Outra dica é buscar sempre se manter informado lendo as notas técnicas relacionadas e acompanhando eventos, podcasts, lives e publicações de profissionais confiáveis da área. Por fim, lembrar que não há problema em pedir ajuda se necessário, existem profissionais que estão se debruçando sobre as mudanças com o objetivo de trazer as mesmas de uma forma mais didática para todos. Como vai ficar o CNPJ que consta na chave da nota fiscal com essa vinda do CNPJ Alfanumérico? R: Apesar de a regex para permitir CNPJ alfanumérico ter sido alterada em liberação de pacote de schemas relacionado a Reforma Tributária, é importante ressaltar que são processos diferentes sendo tratados em notas técnicas diferentes. A Reforma Tributária está sendo tratada na Nota Técnica 2025/002, já o CNPJ Alfanumérico está sendo tratado na Nota Técnica Conjunta 2025/001; A segunda estabelece mudança no regex do arquivo de schema para a chave de acesso e atualização nas regras de validação da chave para permitir o CNPJ Alfanumérico. Para o MDF-e, mesmo que ele não tenha nota técnica própria da reforma tributária, vai mudar a validação das chaves de acesso das NF-es e CT-es que são relacionados no mesmo? R: O regex dos schemas do MDF-e foram atualizados para permitir CNPJ Alfanumérico na Nota Técnica 2025/001 para o MDF-e e as regras de validação serão atualizadas conforme Nota Técnica Conjunta 2025/001, mas nenhuma delas tem relação com a Reforma Tributária. Para as Libs como fica a questão do XML? R: A biblioteca ACBrLibNFe já está adequada as modificações propostas pela nota técnica mais recente da reforma tributária para NF-e/NFC-e e a geração do XML com os novos campos pode ser testada seguindo modelo disponível na documentação. A versão do XML da NF-e será alterada para a Reforma Tributária? R: Não, a versão do XML tanto da NF-e quanto da NFC-e permanece sendo 4.00; Os novos campos da reforma precisam estar no XML em Produção no dia 01/10/2025? R: De acordo com a versão mais recente da nota técnica disponível até o momento da publicação deste tópico, as datas são: Inserção dos campos no XML: Implantação Teste: 01/07/2025 Implantação Produção: 01/10/2025 Aplicação das regras de validação: Implantação Teste: 01/07/2025 Implantação Produção: 01/2026 Quando vai ser de fato extinto o ICMS do XML, ou seja, quando vai começar a devolver rejeição se enviar no XML? R: De acordo com a Lei Complementar 214 o período de transição se estende até o ano de 2033, portanto os campos do ICMS deverão ser informados até lá. Existe possibilidade de voltarem atrás com a Reforma Tributária? R: A reforma tributária é um projeto extenso e amplamente discutido com legislação aprovada na câmara dos deputados e no senado e com regramento já sendo discutido e publicado pelos diversos entes fiscais e regulatórios, o que faz com que a possibilidade de adiamento ou mudanças muito grandes vá diminuindo cada vez mais. Não recomendamos contar com adiamento ou com qualquer tipo de "voltar atrás", quanto antes as aplicações forem adequadas melhor para as software house. A dupla do CST e cClassTrib vai ser string ou enumerado? R: Como ambos são informações com valores fixos definidos em tabela publicada, optou-se por criar um enumerado para cada uma das informações. A base de cálculo do IBS e do CBS vai ser a mesma? R: Sim, conforme pode ser observado na versão mais recente da nota técnica e também dos schemas, o campo da base de cálculo será o mesmo tanto para o IBS quanto para o CBS. Vai haver campos para esses novos impostos no DANFe? R: Até o momento da publicação deste tópico ainda não foi publicado normativa ou novo manual atualizando o leiaute dos impressos para adicionar os novos campos relacionados. Existe um programa exemplo próprio para a NF-e da Reforma Tributária ou é o mesmo? R: É o mesmo programa exemplo. Foi adicionado uma opção para permitir escolher se a rotina que alimenta uma NFe\NFCe com dados fictícios vai alimentar os dados relacionadas a reforma tributária ou não. Adeus à velha NFe? Prepare seu ACBr - Parte 02 O que acontece se ao chegar na data estipulada, não os campos não tiverem sido implementados? R: A partir do momento que elas forem aplicadas você receberá rejeições. A partir de que data os campos serão obrigatórios? R: A versão mais recente das notas técnicas estabelece em seu cronograma que os campos serão obrigatórios no ambiente de homologação a partir de 06/10/2025 e em produção a partir de 01/01/2026. Vide cronograma detalhado: Os schemas atualizados com os novos campos já estão disponíveis no SVN do ACBr? R: Sim, os arquivos de schema mais atuais já estão disponíveis em nosso SVN. Quais documentos serão impactados pela Reforma Tributária? R: Serão impactados a NFe, NFCe, NFSe, NFCom, NF3e, BPe, BPeTM, CTe, CTeOS e GTVe. Se a nota fiscal for de ajuste ou remessa, a mesma não poderá ser de débito ou crédito? R: Correto, pois o campo finalidade de emissão da NF-e ganhou os dois novos tipos nota de crédito e nota de débito e existem rejeições caso seja informado valor para tipo de nota de débito ou crédito com finalidade diferente de débito ou crédito. Existe algum parâmetro no componente ACBrNFe para habilitar a reforma tributária? R: Os programas de exemplo feitos em Delphi e Lazarus ganharam uma opção para definir ser gerado com as tags relacionadas a reforma tributária. Vale mencionar que isso possui apenas finalidade orientativa e selecionar esta opção apenas faz com que as propriedades correspondentes sejam alimentadas. Em suma, para que as tags sejam criadas no arquivo XML, basta alimentar as propriedades correspondentes. Se eu atualizar os schemas e o ACBr antes da data, isso vai impactar o envio em produção? R: Não, os campos relacionados a reforma tributária não serão gerados no arquivo XML a menos que suas propriedades correspondentes sejam preenchidas. Como ficam as tabelas de CST, CRT, NCM, CEST e afins? R: As tabelas de CST, CRT, NCM, CEST e afins permanecem acompanhando e sendo utilizadas para o preenchimento do documento. Mesmo o CST específico para o ICMS vai estar presente no leiaute do documento fiscal até 2032.

Você pode utilizar a dll DEMO para testes, mas como uma limitação, ela consome apenas o ambiente de homologação. Utilizando a Lib Demo é para consultar no ambiente de homologação para todas as cidades mapeadas. Este tópico tem informações conceituais que podem ser importantes.

Olá pessoal! Foi publicado no Diário Oficial do Estado do Ceará no dia 22/05/2025 o Decreto Nº 36633 de 19/05/2025. Este decreto possui dois artigos que estabelecem a obrigatoriedade da vinculação dos meios de pagamento eletrônico ao seu respectivo documento fiscal eletrônico mediante interligação tecnológica com o programa emissor do mesmo para NF-e e NFC-e. É preciso mencionar, no entanto, que os prazos de implementação propriamente ditos não foram definidos no decreto, portanto, é de entendimento geral que uma regulamentação mais detalhada é necessária, então espera se a publicação de uma nova portaria ou ato normativo trazendo informações como previsões de casos de aplicação, os prazos de implementação e outros detalhes. Leia o Decreto na íntegra AQUI. O mesmo pode ser encontrado no Diário Oficial do Estado AQUI, na página 3.

Bom dia! Contribuição enviada ao SVN na Rev-39244

Bom dia! Contribuição enviada ao SVN na Rev-39216. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Olá pessoal! Conforme notícia publicada no portal da Sefaz, a ativação desta nota técnica no estado do Mato Grosso do Sul no ambiente de produção foi adiada para primeiro de setembro de 2025, seguindo agora o mesmo cronograma previsto na NT. Leia a notícia na íntegra AQUI.

Olá pessoal! Foi publicada a versão 1.03 desta nota técnica. A nova versão não traz modificações no leiaute, mas sim ajustes nas regras de validação relacionadas a compra governamental, redução de alíquota e valores de IBS/CBS e correções no schema dos eventos de tipos básicos. Alterações Os campos pAliqEfet que recebem a alíquota efetiva do IBS e do CBS ganharam na observação o seguinte complemento: Foi adicionado regra de validação para validar se é permitido o IBS/CBS para o modelo de DFe. Foram adicionadas regras para validar o cálculo da alíquota efetiva considerando a nova observação para as compras governamentais. A regra relacionada ao grupo de compra governamental que verifica a a alíquota dos outros entes diferente de zero, ganhou 2 observações informando que: A implementação será futura em 2027 e 2028. A partir de 2029 vai considerar o redutor da CBS. Datas Foram mantidas as mesmas datas da versão anterior. Leia a versão 1.03 desta nota técnica na íntegra AQUI.

Olá pessoal! Foi publicada a versão 1.03 desta nota técnica. A nova versão não traz modificações no leiaute, mas sim ajustes nas regras de validação relacionadas a compra governamental, redução de alíquota e valores de IBS/CBS e correções no schema dos eventos de tipos básicos. Alterações Os campos pAliqEfet que recebem a alíquota efetiva do IBS e do CBS ganharam na observação o seguinte complemento: Foi adicionado regra de validação para validar se é permitido o IBS/CBS para o modelo de DFe. Foram adicionadas regras para validar o cálculo da alíquota efetiva considerando a nova observação para as compras governamentais. A regra relacionada ao grupo de compra governamental que verifica a a alíquota dos outros entes diferente de zero, ganhou 2 observações informando que: A implementação será futura em 2027 e 2028. A partir de 2029 vai considerar o redutor da CBS. Datas Foram mantidas as mesmas datas da versão anterior. Leia a versão 1.03 desta nota técnica na íntegra AQUI.

Olá pessoal! Foi publicada a versão 1.03 desta nota técnica. A nova versão não traz modificações no leiaute, mas sim ajustes nas regras de validação relacionadas a compra governamental, redução de alíquota e valores de IBS/CBS e correções no schema dos eventos de tipos básicos. Alterações Os campos pAliqEfet que recebem a alíquota efetiva do IBS e do CBS ganharam na observação o seguinte complemento: Foi adicionado regra de validação para validar se é permitido o IBS/CBS para o modelo de DFe. Foram adicionadas regras para validar o cálculo da alíquota efetiva considerando a nova observação para as compras governamentais. A regra relacionada ao grupo de compra governamental que verifica a a alíquota dos outros entes diferente de zero, ganhou 2 observações informando que: A implementação será futura em 2027 e 2028. A partir de 2029 vai considerar o redutor da CBS. Datas Foram mantidas as mesmas datas da versão anterior. Leia a versão 1.03 desta nota técnica na íntegra AQUI.

Olá pessoal! Foi publicada a versão 1.03 desta nota técnica. A nova versão não traz modificações no leiaute, mas sim ajustes nas regras de validação relacionadas a compra governamental, redução de alíquota e valores de IBS/CBS e correções no schema dos eventos de tipos básicos. Alterações Os campos pAliqEfet que recebem a alíquota efetiva do IBS e do CBS ganharam na observação o seguinte complemento: Foi adicionado regra de validação para validar se é permitido o IBS/CBS para o modelo de DFe. Foram adicionadas regras para validar o cálculo da alíquota efetiva considerando a nova observação para as compras governamentais. A regra relacionada ao grupo de compra governamental que verifica a a alíquota dos outros entes diferente de zero, ganhou 2 observações informando que: A implementação será futura em 2027 e 2028. A partir de 2029 vai considerar o redutor da CBS. Datas Foram mantidas as mesmas datas da versão anterior. Leia a versão 1.03 desta nota técnica na íntegra AQUI.

Olá pessoal! O membro de nossa comunidade @isolopak compartilhou conosco o print abaixo onde é informado que a Sefaz do estado do Mato Grosso do Sul vai adiantar a implementação em homologação e em produção da Nota Técnica 2025/001: Esta notícia encontrada no Portal da Sefaz também confirma a informação. Com esse comunicado as datas são: Implementação no estado do Mato Grosso do Sul: Ambiente de Homologação: Já disponível. Ambiente de Produção: 02/06/2025 Implementação nos demais estados: Ambiente de Homologação: Até 02/06/2025 Ambiente de Produção: Até 01/09/2025 Leia mais sobre a Nota Técnica 2025/001 no tópico abaixo:

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-7090

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-7089