Ir para conteúdo
  • Cadastre-se

Painel de líderes

Conteúdo popular

Showing content with the highest reputation on 25-09-2025 em todas as áreas

  1. Introdução Não há como negar que a Reforma Tributária, como uma onda, já afetou e continuará afetando todo o cenário de emissão de documentos fiscais eletrônicos no Brasil pelo menos até 2032. Trata-se de um verdadeiro chacoalhão para desenvolvedores e empresas, trazendo novos campos, grupos e regras de validação que precisam ser observados atentamente. As soluções do Projeto ACBr vêm sendo constantemente atualizadas conforme cada novidade publicada, permitindo que os desenvolvedores as utilizem para facilitar o processo de emissão desses documentos sem grandes dores de cabeça. O objetivo deste tópico é centralizar quais são os documentos fiscais impactados e apresentar como está a situação das respectivas soluções do Projeto ACBr diante das mudanças Documentos afetados Nota Fiscal Eletrônica / Nota Fiscal de Consumidor Eletrônica Última atualização dessas informações: 24/11/2025; Abreviação: NF-e / NFC-e; Modelo: 55 / 65; Solução nativa: ACBrNFe Implementada no ACBrMonitorPLUS: Possui ACBrLib: Ultima Nota Técnica da Reforma Tributária: Nota Técnica 2025/002 v1.31 Adequado a última nota técnica: Observação: Novos eventos estão sendo implementados gradativamente. Nota Fiscal de Serviços Eletrônica Última atualização dessas informações: 24/11/2025; Abreviação: NFS-e Modelo: -- Solução nativa: ACBrNFSeX Implementada no ACBrMonitorPLUS: Possui ACBrLib: Ultima Nota Técnica da Reforma Tributária: Nota Técnica 005 - v1.00 Adequado a última nota técnica: Observação: Os novos campos foram adicionados, mas os arquivos de schema ainda não foram disponibilizados e o ambiente de homologação não foi liberado. Nota Fiscal de Fatura de Serviços de Comunicação Eletrônica Última atualização dessas informações: 24/11/2025; Abreviação: NFCom Modelo: 62 Solução nativa: ACBrNFCom Implementada no ACBrMonitorPLUS: Possui ACBrLib: Ultima Nota Técnica da Reforma Tributária: Nota Técnica 2025/001 v1.10 Adequado a última nota técnica: Observação: -- Nota Fiscal de Serviços de Energia Elétrica Última atualização dessas informações: 24/11/2025; Abreviação: NF3e Modelo: 66 Solução nativa: ACBrNF3e Implementada no ACBrMonitorPLUS: Possui ACBrLib: Ultima Nota Técnica da Reforma Tributária: Nota Técnica 2025/001 v1.10 Adequado a última nota técnica: Observação: -- Bilhete de Passagem Eletrônico / Bilhete de Passagem Eletrônico Transporte Metropolitano Última atualização dessas informações: 24/11/2025; Abreviação: BP-e / BP-e TM Modelo: 63 Solução nativa: ACBrBPe Implementada no ACBrMonitorPLUS: Possui ACBrLib: Ultima Nota Técnica da Reforma Tributária: Nota Técnica 2025/001 v1.10 Adequado a última nota técnica: Observação: Bilhete de Passagem Eletrônico para Transporte Aéreo (BP-e TA) ainda não implementado. Conhecimento de Transporte Eletrônico / Guia de Valores de Transporte Eletrônico / Conhecimento de Transporte Eletrônico Outros Serviços Última atualização dessas informações: 24/11/2025; Abreviação: CT-e / GTV-e / CT-e OS Modelo: 57 / 64 / 67 Solução nativa: ACBrCTe Implementada no ACBrMonitorPLUS: Possui ACBrLib: Ultima Nota Técnica da Reforma Tributária: Nota Técnica 2025/001 v1.10 Adequado a última nota técnica: Observação: -- Nota Fiscal da Água e Saneamento Última atualização dessas informações: 24/11/2025; Abreviação: NFAg Modelo: 75 Solução nativa: -- Implementada no ACBrMonitorPLUS: Possui ACBrLib: Ultima Nota Técnica da Reforma Tributária: -- Adequado a última nota técnica: Observação: Documento publicado apenas em formato de minuta, sem publicação definitiva.
    4 pontos
  2. a questão do PipeLine isso é só tu passar no controle referente aos demais pontos se houverem mudanças. informe somente os arquivos alterados e sem formatações
    2 pontos
  3. Publicada Nota Técnica Nº 004 que trata da adequação da Nota Fiscal de Serviços Eletrônica no layout do Padrão Nacional. Este documento é a 4ª versão dos novos agrupamentos e campos relacionados ao IBS e ao CBS. Ele substitui a Nota Técnica Nº003 publicada anteriormente. Alterações Adiciona novos campos no grupo infDPS para receber informação do tipo de compra governamental e referenciar chaves de outras NFSes. Modifica a descrição e cardinalidade de alguns campos. Remove o grupo que recebe as informações relativas ao adquirente. E como fica o ACBr? As soluções ACBr já foram adequadas a estas mudanças. Leia a esta versão da Nota Técnica na completa [AQUI]
    2 pontos
  4. Olá pessoal! Foi publicada a Nota Técnica 2025/001 trazendo adequações do CT-e/GTVe/CTeOS para a Reforma Tributária do Consumo. No âmbito do CT-e/GTVe/CTeOS esta nota técnica substitui a NT mencionada no tópico abaixo: Vale reforçar que como as discussões envolvendo a implantação da Reforma Tributária ainda estão em curso, está NT pode sofrer ajustes ao longo do período. Alterações Tipos básicos de tributação Visando padronização entre os diversos documentos fiscais eletrônicos esta NT acrescenta o arquivo DFeTiposBasicos_v1.00.xsd ao conjunto padrão de arquivos de schema para todos os DFes. O arquivo define a estrutura dos novos campos adicionados. Criação do grupo Compras Governamentais no grupo Ide No grupo de identificação do documento fiscal (ide), foi adicionado um grupo para identificar compra governamental (gCompraGov). O grupo possui 2 campos, um para indicar o tipo de compra governamental (tpCompraGov) e um para indicar o percentual de redução de alíquota em compra governamental (pRedutor). Inclusão de campos do IBS\CBS São adicionados campos para informar o IBS e o CBS além de totalizadores para os mesmos. Alteração em Regra do CTe Simplificado Altera a regra que devolve a rejeição 371 para validar se o CTe Simplificado possui apenas um município para terminar a prestação do serviço. Alterações no leiaute do Modal Dutoviário Cria os campo os seguintes campos no grupo que recebe as informações do modal dutoviário: Classificação Dutoviário - classDuto Tipo de Contratação do Serviço de Transporte - tpContratacao Código do Ponto de Entrada - codPontoEntrada Código do Ponto de Saída - codPontoSaida Número do Contrato de Capacidade - nContrato. Adição de regras para verificar e validar os novos campos Criação do grupo de Informações da Declaração de Conteúdo Eletrônica nos documentos originários Adiciona um grupo para referenciar a chave de DCe. Exceção para Substituição sem exigência do evento de prestação em desacordo para Tomador Exterior Adiciona exceção na regra de validação que devolve a mensagem "O CTe substituído deve possuir evento de Prestação do Serviço em Desacordo" para que a mesma não se aplique para CTe com tomador exterior. Elimina as opções de contingência SVC da GTVe. Considerando que a GTVe já aceita a contingência off-line, não há necessidade do schema e do ambiente de autorização suportar contingência SVC, por isso a mesma foi removida. Nova regra para CTeOS de Transporte de Valores Adiciona regra de validação que obriga o preenchimento da UF e Município Fim da prestação do serviço quando transporte de valores devido a apuração de impostos na reforma ser em razão da UF e município de destino. Preparação para o CNPJ alfanumérico A expressão regular que valida todos os campos de CNPJ passa a ser [A-Z0-9]{12}[0-9]{2} A expressão regular que valida a chave de acesso do BP-e que é composta dentre outras informações pelo CNPJ passa a ser [0-9]{6}[A-Z0-9]{12}[0-9]{26} Ampliação do cStat O código do status de retorno (cStat) passa a ter a seguinte regex [0-9]{3,4} aceitando na prática até 4 dígitos agora. Regras de validação Adiciona regras para validar as informações de compra governamental além dos novos campos de IBS, CBS e seus respectivos totalizadores. Datas Implantação Homologação: 07/2025 Implantação Produção: 10/2025 E como fica o ACBr? Os componentes do ACBr já vem passando por um processo de adequação as mudanças propostas pela reforma, mesmo assim a nota técnica será revista e quaisquer modificações necessárias serão efetuadas em tempo hábil para que possam ser disponibilizadas para vocês e possam testar. Leia essa Nota Técnica na íntegra AQUI.
    1 ponto
  5. Pessoal, boa tarde, já estou com meus fontes atualizados com os itens da reforma tributária, caso alguém tenha interesse em uma consultoria sobre quais campos criar, em quais tabelas criar, o que muda em qual situação, apesar de ainda haver um longo caminho para a implantação final da reforma como um todo, em ambiente de homologação já faço o envio dos DF-es que foram liberados (NF-e, NFC-e, CT-e, ...). E nesse trabalho, também faço o refatoramento de fontes legados, que já estão funcionando a vários anos com vários IFs que poderiam ser substituídos por rotinas do próprio ACBR. Quem estiver interessado, me contatem por mensagem privada, obrigado a todos.
    1 ponto
  6. Como sempre, uma luz na escuridão! muito obrigado. Estava faltando a tag <protNFe versao="4.00"></ProtNFe>.
    1 ponto
  7. Boa tarde @Fabiano Hoffmann, Já esta no SVN.
    1 ponto
  8. Olá pessoal, esse tópico já faz bastante tempo, mas me deparei com esse tipo de emissão hoje. Uma NF-e de Bem Imobilizado, solicitada pela contabilidade de um cliente Configurações: CFOP 5551, CSOSN 900, BC ICMS e valor de ICMS, destinatário sendo Cliente Pessoa Física A solução encontrada para conseguir transmitir foi colocar 1 - Consumidor final na tag <indFinal> 2 - Contribuinte isento de Inscrição no cadastro de Contribuintes do ICMS na tag <indIEDest> A própria contabilidade realizou emissão antes dessa solicitação usando a mesma configuração
    1 ponto
  9. Boa tarde @Sandro Andre Reghelin, Já esta no SVN.
    1 ponto
  10. @Marco Moreira, Obrigado pela sua contribuição e testes... Commit [r41728]
    1 ponto
  11. Bom dia @Sandro Andre Reghelin, Muito obrigado pela colaboração, já foi criado a tarefa ACBR-8107 para realizar a alteração.
    1 ponto
  12. Massa, dos males o menor... haha
    1 ponto
  13. As tags estão erradas. O Correto seria pPIS e vPIS (em maiúsculo) Revise todas as tags, pois teve alterações na geração do xml.
    1 ponto
  14. Entendi. Provavelmente o problema parece ser mais do lado da API que a sua requisição, a rejeição é que a inscrição 12162318 não está cadastrada para a Curitiba (4106902), mas pode ser que seja um problema do ambiente de homologação que não tenha o cadastro ou precisa que o dono dessa inscrição faça um cadastro. Tente logar la no ambiente de homologação para ver o que acontece: https://www.producaorestrita.nfse.gov.br/EmissorNacional/Login?ReturnUrl=%2fEmissorNacional%2f
    1 ponto
  15. tu está com o fortes report ce desatualizado baixa do github e instala novamente e depois o acbr
    1 ponto
  16. Foi disponibilizada a versão 1.1 desta nota técnica. Alterações Esta versão apenas modifica o nome do arquivo que contempla o layout e as regras de validação da NFSe Nacional mudando sua versão e também modifica a cardinalidade do campo tpOper tornando o mesmo opcional. E o ACBr como fica? A solução ACBr já está adequada a está versão. Leia esta versão da Nota Técnica completa [AQUI]
    1 ponto
  17. Boa tarde, tudo bem? O ACBRTEFD não suporta o AutoTef, somente o ACBR TEF API. Nesse trecho você deve parametrizar qual a plataforma de exibição do QRCode na configuração inicial: TACBrTEFAPIExibicaoQRCode = ( qrapiNaoSuportado, qrapiAuto, qrapiExibirPinPad, qrapiExibirAplicacao ); Em seguida, nos pagamentos deve-se enviar "carteira virtual": TACBrTEFModalidadePagamento = ( tefmpNaoDefinido, tefmpCartao, tefmpDinheiro, tefmpCheque, tefmpCarteiraVirtual ); <--- Att.
    1 ponto
  18. Bom dia @joemil, Já esta no SVN a sua contribuição.
    1 ponto
  19. Boa noite, Criada a tarefa ACBR-8090 para avaliação. Assim que tivermos um retorno informamos aqui. Obrigado pela contribuição.
    1 ponto
  20. Olá pessoal! No dia 15/09/2025 foi publicada a versão 1.09 desta nota técnica. A nova versão não traz alterações no leiaute, mas modifica regras de validação e datas. Alterações Adiciona uma observação para que seja utilizada a pAliqEfet caso o grupo de redução (gRed) seja preenchido nas regras de validação que verificam se o valor do diferimento municipal e estadual diferem do calculado. Altera algumas datas conforme observação reproduzida na íntegra: Datas Implantação Homologação: Até 28/07/2025 Implantação Produção: 06/10/2025 E como fica o ACBr? Como não houve alteração no leiaute, modificações nos fontes do ACBr não se fazem necessárias. Leia a versão 1.09 desta nota técnica na íntegra [AQUI]
    1 ponto
  21. Olá Pessoal, Essa é uma boa pergunta. E a resposta é muito simples esta pronto e não esta pronto. Como assim? Até o momento temos a NT 2025/004 que traz as alterações no layout da NFS-e Padrão Nacional para a Reforma Tributária, mas não temos Manuais dos provedores que seguem a versão 1 do layout da ABRASF nem dos que seguem a versão 2 e nem dos provedores que tem layout próprio. O que temos pronto no ACBrNFSeX? Implementação dos novos grupos e campos visando a Reforma Tributária para o Padrão Nacional. Sendo assim através do programa exemplo é possível gerar o XML do DPS (Declaração de Prestação de Serviço), mas ao fazer isso vai ocorrer erro de validação. O motivo do erro é que os Schemas que temos não contempla os novos grupos e campos da Reforma Tributária. E o ambiente de homologação que a Receita Federal chama de Produção Restrita não foi alterado para aceitar os novos grupos e campos. Resumindo. Já esta no SVN as alterações no componente ACBrNFSeX para gerar o XML do DPS (Padrão Nacional) com os novos campos. Não vai ser possível validar e nem enviar para o ambiente de homologação. Assim que tivermos mais noticias sobre a Reforma Tributária na NFS-e, vamos divulgar.
    1 ponto
  22. Juliomar, descobri o erro que ocorreu. Não era os schemas, mas sim um campo não informado, que me esclareceu foi o seu print. Desde já agradeço e muito a sua atenção. Obrigado
    1 ponto
  23. o campo é obrigatorio, abre o manual do MDFe e confere então volta a conferir seus schemas. exclua e baixa novamente do svn
    1 ponto
  24. Olá pessoal! Foi publicada a versão 1.08a desta nota técnica. Alterações Esta versão não traz alterações de leiaute, ela apenas altera a redação de algumas regras de validação corrigindo obrigatoriedade da aplicação, campo a ser validado e cálculo. Datas Foram mantidas as mesmas datas da versão anterior. E como fica o ACBr? Modificações não são necessárias na solução ACBr, visto que não houve modificação de leiaute. Leia a versão 1.08a desta nota técnica na íntegra [AQUI]
    1 ponto
  25. Olá pessoal! Foi publicada a versão 1.07 desta nota técnica. Alterações A nova versão torna o campo vIBS obrigatório no schema. Ela também adiciona a seguinte observação detalhando os prazos e disponibilidade dos campos: Datas Foram mantidas as mesmas datas da versão anterior. E como fica o ACBr? O campo já foi adicionado no componente sendo sempre gerado no XML conforme arquivos de schema, portanto modificações não serão necessárias. Leia a versão 1.07 desta nota técnica na íntegra AQUI.
    1 ponto
  26. Olá pessoal! No dia 18/07/2025 foi publicada a versão 1.06 desta Nota Técnica. Alterações Leiaute do documento fiscal eletrônico Esta versão adiciona um novo campo vIBS para receber a soma do vIBSMun e do vIBSUF. Regras de validação Adiciona uma regra para validar se o valor do novo campo adicionado está correto. Inclui uma regra que valida se a tributação regular foi informada indevidamente de acordo com a classificação tributária. Acrescenta regras para verificar se a classificação tributária informada e também se o crédito presumido são permitidos para o modelo de documento. Incrementa as observações e textos de algumas regras de validação já definidas em versões anteriores da NT. CNPJ Alfanumérico Incrementa a regex do QrCode para permitir CNPJ Alfanumérico. Datas Implantação em homologação: Até 28/07/2025 Implantação em produção: 06/10/2025 E como fica o ACBr? Como a nota técnica adiciona um novo campo, será necessário adicionar o mesmo ao componente. Foi criada a #TK-7370 para esta finalidade. Leia a versão 1.06 desta Nota Técnica na integra AQUI.
    1 ponto
  27. Olá pessoal! Foi publicada a versão 1.05b desta nota técnica. A nova versão corrige os nomes de alguns campos citados nas regras de validação e nas observações. Alguns exemplos seriam: A observação de pAliqEfet que está usando "pAliqEfet = pIBSUF*(1 – pRedAliq)*(1 - gCompraGov/pRedutor)" foi corrigida para refletir o imposto a que se refere a pAliqEfet em questão. A regra de validação que devolve "400 - Rejeição: Somas dos valores de IBS e CBS em compras governamentais divergente" foi corrigida para "Verificar se a soma dos valores de IBS e CBS do grupo gTribCompraGov (vTribIBSUF + vTribIBSMun + vTribCBS)(...)" As datas permanecem as mesmas da versão anterior e modificações no ACBr não se fazem necessárias. Leia a versão 1.05b na íntegra AQUI.
    1 ponto
  28. Olá pessoal! Foi publicada no dia 06/06/2025 a versão 1.05 desta nota técnica. Esta nova versão traz a adição de um novo grupo de compras governamentais e também ajustes em regras de validação. Alterações Foi adicionado um novo grupo para compras governamentais no IBSCBS chamado gTribCompraGov. O mesmo é composto pelos seguintes campos: pAliqIBSUF: Alíquota IBS da UF utilizada vTribBSUF: Valor do tributo do IBS da UF que seria devido sem aplicação do Art. 473 da LC 214/2025; pAliqIBSMun: Alíquota IBS do município utilizado. vTribIBSMun: Valor do tributo do IBS do município que seria devido sem aplicação do Art. 473 da LC 214/2025; pAliqCBS: Alíquota do CBS utilizada. vTribCBS: Valor da CBS Adiciona a seguinte exceção as regras de validação que validam a presença do grupo IBSCBS e seu respectivo CST: Se o CRT informado pelo emitente for 1 Simples Nacional ou 4 -MEI, o grupo gIBSCBS NÃO será exigido Adiciona regras de validação que verificam a presença ou a ausência do novo grupo gTribCompraGov e também a somatória do IBS e do CBS presentes no mesmo. Datas Implantação Homologação: Até 28/07/2025 Implantação Produção: 06/10/2025 E como fica o ACBr? Como foi adicionado um novo grupo no leiaute, modificações no componente respectivo serão necessárias. Criada a #TK-7190 para adequação do componente. Leia a versão 1.05 desta nota técnica na íntegra AQUI.
    1 ponto
  29. 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.
    1 ponto
  30. 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.
    1 ponto
  31. Olá pessoal! Foi publicada a versão 1.02 desta nota técnica. A nova versão não traz modificações no leiaute, mas sim ajustes em algumas regras de validação. Dentre essas destacam-se: Observação na regra cStat 310 Rej. IBS / CBS não informado dizendo que a mesma será aplicada em ambiente de homologação a partir de 06/10/2025 e em produção a partir de 05/01/2026. Inclusão das regras de validação 367, 368, 381, 382, 385, 386 e 387 que validam e rejeitam a CTe/CTeOS/GTVe caso tenha sido adicionado informação não permitida pelo CST, pelo cClassTrib ou no período que a CTe/CTeOS/GTVe tentou ser autorizada. Observação de que as regras 386, 338, 339 e 340 só serão aplicadas a partir de 2033. Observação de que as regras 387, 343, 344 e 345 só serão aplicadas a partir de 2027. Datas A nova versão traz a data mais detalhada em comparação a versão anterior que trazia apenas o mês. Implantação Homologação: 07/07/2025 Implantação Produção: 06/10/2025 Observação: No ambiente de produção as Regras de Validação serão aplicadas somente em 05 de janeiro de 2026. Leia a versão 1.02 desta nota técnica na íntegra AQUI.
    1 ponto
  32. Olá pessoal! Informamos que as alterações no componente ACBrCTe para adequá-lo as alterações propostas pela reforma tributária foram concluídas. Como o ambiente de homologação ainda não foi ativado, não é possível transmitir o CT-e, mas já é possível gerar o arquivo XML com as novas tags.
    1 ponto
  33. Olá pessoal! Foi publicada a versão 1.01 desta nota técnica. Alterações Renomeia o elemento tpCompraGov para tpEnteGov. Remove o grupo gTribRegular dos grupos gIBSMun e gIBSUF e o adiciona no gIBSCBS. Renumera algumas regras de validação. Altera regra de validação que verifica se a chave de acesso referenciada em CTe Complementar é muito antiga para que em caso de modal ferroviário ou multimodal(antes era ferroviário) permita até 24 meses da data de autorização. Datas Foram mantidas as mesmas datas da versão anterior. Implantação Homologação: 07/2025 Implantação Produção: 10/2025 Observação: As regras de Validação serão aplicadas somente Janeiro de 2026 no ambiente de produção. E como fica o ACBr? As soluções do ACBr incluindo componente nativo para Delphi/Lazarus, ACBrMonitorPLUS e ACBrLib estão sendo revistas e serão disponibilizadas em tempo hábil para que possam testar em homologação. Leia a versão 1.01 desta nota técnica na íntegra AQUI.
    1 ponto
  34. Experimente configurar Pag.Código para pceNone
    1 ponto
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...
The popup will be closed in 10 segundos...