Painel de líderes

Caso você não tenha se atentado como eu que deveria salvar o ID do boleto CORA e salvou apenas o Nosso Numero, segue um programinha simples para ler os Logs do AcbrBoleto onde fica salvo essas informações, minha sorte que não apaguei os Logs, rs rs rs. LerLogCora.rar

Boa tarde @João Antônio, Já esta no SVN.

Esse método vai servir apenas para o XML da NFe, não dos eventos. Criada a TK-7517 para avaliar a possibilidade de implementação do método ObterEventoXML Assim que tivermos uma definição informamos aqui.

@BigWings e @Juliomar Marchetti o @Italo Giurizzato Junior respondeu a minha dúvida nesse outro tópico. . Como a resposta dele esclareceu todas as minhas dúvidas, agradeço a todos.

Ahhh entendi. Sim, no meu caso é para a SEFAZ-SP mesmo. Vou aguardar mais um tempo para ver se eles corrigem isso. Muito obrigado!

Bom dia @mregiani e @Info-House, Se a nota esta sendo emitida e enviada para a SEFAZ-SP, temos informações que a mesma esta realizando um calculo diferente do que esta especificado na Nota Técnica. Na NT consta que devemos usar o SHA1 e a SEFAZ-SP esta usando o MD5 para calcular o Hash da assinatura. A SEFAZ-SP tem que corrigir isso.

@Juliomar Marchetti Obrigado pela resposta, É verdade! A gente quer agradar o cliente mas tem certas coisas que são perda de tempo. Vou fazer um espelho aqui mas não vou fazer uma cópia de NF como a da imagem não. O uso do documento é por conta do cliente é claro, mas não quero dores de cabeça no futuro se é que me entende.

Oi Juliomar, obrigada pelo retorno! Sim, eles disponibilizaram exemplos de xml, encontrei no site deles, vou deixar aqui o link se vc puder verificar: https://iss.ajuda.betha.cloud/e-nota-cloud/ajuda/outros-conteudos/web-service, está na parte do layout da Betha sistema na versão 1.0. Coloquei aqui em anexo o arquivo deles de exemplo com mais de um item. Nele consta a informação que deve ir na tag <Discriminacao>: <Discriminacao>{[[DESCRICAO= SERVIÇO 1][ITEMSERVICO=0101][ALIQUOTA=0.03][QUANTIDADE=1][VALORUNITARIO=325.60][DEDUCOES=0.00][DESCONTOCONDICIONADO=0.00][DESCONTOINCONDICIONADO=0.00]][[DESCRICAO= SERVIÇO 2][ITEMSERVICO=0102][ALIQUOTA=0.02][QUANTIDADE=1][VALORUNITARIO=296.00][DEDUCOES=0.00][DESCONTOCONDICIONADO=0.00][DESCONTOINCONDICIONADO=0.00]]}</Discriminacao> Este é um caso especifico do provedor Betha, SubVersao:1, eu entendi que devemos adicionar tbm "[DEDUCOES=0.00]" para cada item. Conforme o teste que fiz enviando, o valor de deduções constou corretamente. 3 - RecepcionarLoteRpsPopulado (mais de um serviço no RPS).xml

Boa tarde @Diego Reckziegel, Já esta no SVN.

Olá Pessoal, Depois de analises junto com a comunidade ACBr, decidimos que os campos referente ao Código de Classificação Tributária (cClassTribIS, cClassTribReg e cClassTrib) deve ser do tipo string em vez de um tipo enumerado. A motivação para essa mudança é que esses códigos podem no decorrer do tempo alguns podem deixar de existir, outros podem ser adicionados e outros códigos podem ser alterados mas mantendo a sua finalidade original, exatamente o que ocorre com os NCM dos produtos. Com essa mudança basta o desenvolver atualizar a sua tabela de códigos no banco de dados sem a necessidade de atualização da aplicação. Vale também ressaltar que no Portal da SEFAZ-Virtual do RS temos as tabelas de CST e cClassTrib e é possível baixa-las no formato CSV, Excel e Json. Esperamos contar com a compreensão de todos. Os fontes dos componentes afetados com essa mudança vão ser enviados para o SVN na data de 19/08/2025. Componentes afetados com essa mudança: ACBrBPe, ACBrCTe, ACBrNF3e, ACBrNFCom, ACBrNFe e ACBrNFSeX e consequentemente as Libs e o ACBrMonitor. Na minha aplicação o que eu devo mudar? Se você atribui diretamente o enumerado aos campos cClassTrib mencionados vai ter que fazer essa alteração: ==> Se você usa as funções de conversão para converter de string para o enumerado uma vez que no seu banco de dados o código esta como string, basta remover as funções de conversão e atribuir diretamente o conteúdo do campo do banco de dados ao campo do componente. Para quem utiliza as Lib ou o Monitor não vai precisar se preocupar com essa mudança.

Recebi um Email como resposta da sefaz de PE, me informando Bom dia! Segue abaixo retorno da nossa equipe técnica. Verificamos que consta no XML informações de IBS-CBS. Nosso ambiente de homologação ainda não está preparado para tratar essas informações. Estamos finalizando testes para atualizar a versão breve. Aproveito e informo que essa versão já será liberada com as alterações da versão 1.20 da Nota Técnica 2025.002-RTC. Validando o XML em desenvolvimento verifiquei que está na versão 1.10. Para o caso em questão, faltou informar a tag: IBSCBS/gIBSCBS/vIBS Atenciosamente, Equipe Documentos Fiscais Eletrônicos SEFAZ-PE nao consegui colocar essa tag vibs nao vai pra o xml tanto pra nfc-e q ja atualizei o acebr e o shemas mais nao foi. alguem puder ajudar. grato

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Olá pessoal, A partir de 01/01/2026 os prestadores de serviços devem obrigatoriamente emitirem suas notas através do portal nacional da NFS-e Padrão nacional ou através de uma aplicação que consuma a API do SERPRO que visa a emissão da NFS-e segundo o Padrão Nacional. Leia o comunicado da prefeitura através do link abaixo. NOTA CARIOCA - Nota Fiscal de Serviços Eletrônica - NFS-e - Prefeitura da Cidade do Rio de Janeiro

Olá Pessoal, Quanto mais eu rezo mais assombração aparece. Lá vamos nós ler a versão 1.20 da NT 2025/002 referente a Reforma Tributária da NF-e/NFC-e. Vamos a um resumo dela: Consta que somente a partir de 2027 as empresas do Simples Nacional e MEI ao emitir suas notas vão ter que informar as informações do IBS e CBS. Em uma nova NT vai ser detalhado essa obrigatoriedade para as empresas do SN e MEI. O campo tpNFCredito passa a ter um novo valor: 03 - Retorno. O grupo gIBSCBS passa a ter o campo vIBS que é o resultado de vIBSUF mais vIBSMun. O grupo gIBSCBSMono continha muitos campos, só que agora os campos foram distribuídos dentro dos grupos: gMonoPadrao, gMonoReten, gMonoRet e gMonoDif. Varias regras de validação foram alteradas. Já estamos trabalhando para deixar o componente ACBrNFe, a DLL ACBrLibNFe e o ACBrMonitor em conformidade com essa Nota Técnica.

Olá pessoal! Informamos que o componente ACBrNFe foi compatibilizado com a versão 1.10 desta nota técnica na review 39718. Versões do ACBrMonitorPLUS e da ACBrLibNFe compiladas depois das 11/06/2025 deverão engloba as modificações.

Olá pessoal! Foi publicado no dia 09/06/2025 a versão 1.10 desta nota técnica. Alterações Informações Esta versão reforça que as informações de tributação do IS, CBS e IS serão opcionais em 2025, mas serão validadas caso informadas no ambiente de produção. Enquanto que em homologação os campos serão obrigatórios em 2025 e as regras de validação serão aplicadas conforme previsto nas datas de implementação da NT. É ressaltado que a tabela de cClassTrib pode sofrer alterações visando aperfeiçoamentos ou adequações a novidades estabelecidas. Leiaute Adiciona para o tipo de nota de débito os novos valores: 06 - Pagamento antecipado 07- Perda em estoque Define os valores para o tipo de nota de crédito, sendo eles: 01 - Multa e juros 02 - Apropriação de crédito presumido de IBS sobre o saldo devedor na ZFM. Adiciona no grupo para compras governamentais (gCompraGov) um campo para definir o tipo de operação com o ente governamental (tpOperGov) com os possíveis valores: 1 - Fornecimento 2 - Recebimento do pagamento conforme fato gerador do IBS/CBS Inclui o grupo gPagAntecipado para referenciar notas de antecipação de pagamento. Incorpora no grupo de produtos e serviços o indicador de fornecimento de bem móvel usado (indBemMovelUsado). Acrescenta novo grupo de informações da composição do valor do IBS e da CBS em compras governamentais (gTribCompraGov). Adiciona novo grupo para transferências de crédito (gTransfCred). Inclui novo grupo para informações do crédito presumido de IBS para ZFM (gCredPresIBSZFM). Regras de validação Adiciona novas regras para verificar e validar os novos campos adicionados nesta versão. Incrementa a mensagem de algumas regras de validação estabelecidas em versão anterior para trazer o número do item que ocasionou a rejeição. Atualiza observação de algumas regras de validação adicionando como devem ser os cálculos dos valores. Eventos Esclarece que os eventos serão recepcionados pela Sefaz do Virtual do Rio Grande do Sul - SVRS. Adiciona os eventos: 112120 - Importação em ALC/ZFM não convertida em isenção. 112130 - Perecimento, perda, roubo ou furto durante o transporte contratado pelo fornecedor. 112140 - Não ocorrência de fornecimento com pagamento antecipado. 211124 - Perecimento, perda, roubo ou furto durante o transporte contratado pelo adquirente. Remove o evento 211124 - Perecimento, perda, roubo ou furto. Datas Implantação de novo schema com os campos para apuração do IBS, CBS e IS com preenchimento opcional²³: Implantação Teste: De 07/07/2025 até 28/07/2025¹ Implantação Produção: 06/10/2025 Aplicação das regras de validação²³: Implantação Teste: De 07/07/2025 até 11/08/2025¹ Implantação Produção: 06/10/2025 Inicio da obrigatoriedade da informação dos novos tributos²³: Implantação Teste: 06/10/2025 Implantação Produção: 05/01/2026 Implantação dos eventos para utilização na apuração do IBS, CBS e IS: Implantação Teste: 04/08/2025 Implantação Produção: 06/10/2025 ¹ Implantação em teste pode variar de acordo com a UF. ² As regras de validação para o IBS, CBS e IS serão aplicadas somente se os valores forem preenchidos no arquivo XML. ³ A validade jurídica se dará conforme datas previstas na legislação. Detalhamento Julho/2025: Homologação: Preenchimento dos campos IBS/CBS é facultativo. Se preenchidos, as RV serão aplicadas. Produção: Campos do IBS/CBS ainda não implantados. Caso informados, ocasionará erro de schema. Outubro/2025: Homologação: Preenchimento dos campos IBS/CBS passa a ser obrigatório para as NF-e com data de emissão maior ou igual a 06/10/2025 e as RV serão aplicadas. Produção: Preenchimento dos campos IBS/CBS é facultativo. Se preenchidos, as RV serão aplicadas. Sem valor jurídico para os novos tributos Janeiro/2026: Homologação: Preenchimento dos campos IBS/CBS passa a ser obrigatório para as NF-e com data de emissão maior ou igual a 06/10/2025 e as RV serão aplicadas. Produção: Preenchimento dos campos IBS/CBS passa a ser obrigatório para as NF-e com data de emissão maior ou igual a 05/01/2026 e as RV serão aplicadas. Com valor jurídico para os novos tributos a partir de 01/01/2026. E como fica o ACBr? O componente ACBrNFe já está passando por processo de adequação as modificações propostas por esta versão portanto assim que concluídas e disponibilizadas as alterações, será avisado neste tópico. Leia a versão 1.10 desta nota técnica na íntegra AQUI.

Olá Pessoal, É com grande alegria que informo a todos que o componente ACBrNFe já esta em conformidade com a NT 2025/002 versão 1.01 referente a Reforma Tributária. Já se encontra no SVN os fontes, os Schemas e o programa exemplo em Delphi que exemplifica como alimentar os novos campos. Quero deixar bem claro que o ambiente de homologação só vai estar liberado em 01/07/2025 para recepcionar os XML com os novos campos referente a Reforma Tributária. Portanto nem adianta tentar enviar que o XML vai ser rejeitado.

Olá pessoal! Foi publicada a versão 1.01 desta nota técnica. Alterações Padrões de numeração A nova versão traz mais detalhes sobre a modificação do tamanho do campo cStat. Nela é explicado que o sistema da nota fiscal está atingindo alguns limites e por isso foi necessária a ampliação dos campos do código de status de resposta (cStat) e do número do protocolo de autorização (nProt). O cStat foi aumentado para comportar até 4 posições, com essa faixa sendo utilizada para as rejeições exclusivas dos novos impostos IBS, CBS e IS. O número de protocolo de autorização é composto pelos seguintes elementos: 1 dígito para Tipo Autorizador; 2 dígitos para o código da UF; 2 dígitos para o ano; 10 dígitos para o número sequencial dos documentos autorizados para o mesmo modelo de DF-e; Como algumas UFs estão próximas de atingir o limite dos 10 dígitos sequenciais para NFC-e, o campo foi aumentado podendo ter 12 posições, fazendo com que o número do protocolo possa ter agora até 17 caracteres. Mudanças no leiaute do documento fiscal No grupo gCompraGov o elemento tpCompraGov foi renomeado para tpEnteGov. A observação dos campos CSTIS e cClassTribIS foi alterada para deixar explicito que utilize tabela própria para cada campo respectivo. O tamanho do campo vBC do grupo gIBSCBS foi alterado de 3v2-4 para 13v2 efetivamente permitindo agora um valor de até 15 dígitos com 2 casas decimais. Remove o campo vTribOp do grupo gIBSUF. Remove o grupo gTribRegular do dos grupos gIBSUF e gIBSMun e adiciona no grupo gIBSCBS. Altera o grupo que totaliza as informações dividindo em um totalizador somente para o IS e um somente para o IBSCBS. Regras de Validação Adiciona regras de validação para: Validar o IBS/CBS não informado. Validar IBS/CBS Monofásico preenchido. Validar se os valores das alíquotas do IBS/CBS e IS estão corretos. Impedir o uso do crédito presumido para NFC-e. Validar os totais do IBS/CBS monofásico. Validar se o item referenciando quando nota de débito está correto. Validar informações relacionadas ao IS. Eventos Adiciona no evento "Solicitação de Apropriação de crédito presumido" grupo para as informalões do gCBS. Deixa explícito que o evento "Perecimento, perda, roubo ou furto" é relacionado as mercadorias em estoque e não relacionadas ao trânsito. Datas Aplicação das regras de Validação. Implantação Teste: 01/07/2025 Implantação Produção: 01/2026 E como fica o ACBr? As soluções do ACBr, sejam componentes nativos, ACBrMonitorPLUS e ACBrLib estão sendo revistos e serão adequados as alterações propostas em tempo hábil para que possam realizar seus testes em homologação. Leia a versão 1.01 desta nota técnica na íntegra AQUI.

Olá pessoal! Na tarde do dia 18/11/2024 o Sebrae promoveu junto aos auditores fiscais da Receita, Carlos Nacif e Hermano Toscano, uma Live para detalhar duas mudanças previstas para 2026 para todos os empreendedores. Dentre as mudanças mencionadas, uma delas se refere a unificação da emissão de NFS-e em todo o país utilizando o Padrão Nacional. Está mudança está prevista para Janeiro de 2026, sem uma data específica. As informações acima foram retiradas de notícia originalmente publicada pelo Sebrae e que pode ser lida na íntegra AQUI. Relembrando. No contexto da NFS-e, não há um leiaute único. Cada administração municipal pode optar por contratar através de licitação uma empresa que fornece o web service de emissão de notas de serviço (nós do ACBr chamamos esta empresa de "provedor"). Este web service pode ser implementado seguindo um leaiute da maneira que o provedor preferir, causando assim, no cenário da NFS-e, uma falta de padrão. O Padrão Nacional, como o nome diz, é um padrão que foi criado com o objetivo de centralizar isso, acabando com os padrões próprios utilizados. No entanto, apesar do nome Padrão, sua adesão até o momento desta publicação, é obrigatória apenas para os MEIs com adoção opcional para os outros casos. Nesta adesão opcional, até o momento, 1.140 cidades estão conveniadas, sendo 22 capitais. (Você pode conferir a lista completa AQU). O que se espera é que em 2026 todos estejam emitindo pelo Padrão Nacional. Também é importante lembrar! O componente nativo para Delphi/Lazarus e consequentemente o ACBrMonitorPLUS e a ACBrLib já estão adequados ao Padrão Nacional e podem ser utilizados para emissão de nota no mesmo. O tópico abaixo traz mais informações a respeito:

Olá pessoal! Foi publicado no Diário Oficial da União de 16/01/2025 a Lei Complementar Nº 214, de 16 de Janeiro de 2025. Dentre os diversos artigos presentes destaca-se para o tema deste tópico, o artigo 62: Que efetivamente estabelece que os municípios devem providência adequação de seus sistemas emissores de NFS-e para permitir a informação do IBS e CBS e o compartilhamento destas informações a partir de 01/01/2026 valendo esta obrigatoriedade até 31/12/2032. A lei complementar pode ser lida na íntegra AQUI.

Olá pessoal! Em uma demonstração do movimento para a adoção do Padrão Nacional como padrão único para NFS-e. Temos um Projeto de Emenda Constitucional ao Projeto de Lei Complementar Nº68/2024 que institui os novos grupos de impostos do CBS e do IBS criados para o Projeto da Reforma Tributária. Está Emenda propõe adicionar os §§ 8º e 9º ao art. 61 do PLP68/2024. Destaca-se o inciso 8º: E também a justificativa da emenda: O Projeto de Emenda Constitucional pode ser lido na íntegra AQUI.

Olá pessoal! Nos últimos dias temos recebidos diversos relatos de membros de nossa comunidade com problemas para realizar o processo de Manifestação do Destinatário, seja realizando o envio de evento ou a consulta de DistribuicaoDFe. Todos os relatos tinham em comum o fato de estarem conseguindo consumir os webservices de transmissão da NF-e normalmente, mas estarem recebendo as mensagens: Erro Interno: -2146893815 Erro HTTP: 0 URL: https://www.nfe.fazenda.gov.br/NFeRecepcaoEvento4/NFeRecepcaoEvento4.asmx Erro: 2148073481 Ou: Erro: WebService Distribuição DFe: - Inativo ou inoperante tente novamente. Erro interno: -2146893815 Erro HTTP: 0 URL: https://www1.nfe.fazenda.gov.br/NFeDistribuicaoDFe/NFeDistribuicaoDFe.asmx Erro: 2148073481 - Em casos assim, é sempre válido abrir um Fale Conosco junto ao fisco para que o mesmo fique ciente de que há algo errado. Abaixo reproduzido na íntegra temos a resposta que foi fornecida pelo membro de nossa comunidade @Jhonathan na qual ele demonstra um passo a passo que executou para resolver um erro semelhante que havia enfrentado anteriormente com NFC-e e que também de acordo com múltiplos relatos de colegas da comunidade resolveu o problema agora com a manifestação do destinatário: 1- Vá até o Painel de Controle do Windows. 2- Escolha a Opção "Opções da Internet"; 3- Vá até a aba “Avançadas”; 4- No bloco “Configurações”, vá até as últimas opções e deixe configurado como na imagem abaixo: 5- Vá em executar, digite certlm.msc para abrir a interface de certificados, caso esse comando não funcione, utilize o comando certmgr.msc. Remova estes certificados listados na imagem abaixo: 6- Execute como Administrador o InstaladorCadeias_1.0.2.0.exe, clique em Instalar e aguarde até que o processo seja finalizado. 7- Execute o FixCrypto_TLS1_2_Windows.reg. 8- Descompacte o CA.zip e execute o ac soluti ssl ev.cer e o Raiz-icp-brasil v10.cer. 9- Reinicie a máquina e teste novamente a comunicação com a Sefaz.

Olá Pessoal, Notei que diversos desenvolvedores estão fazendo perguntas repetitivas tanto no Fórum quanto no Discord sobre a NFS-e Padrão Nacional, compilei algumas dessas perguntas e suas respectivas respostas. 1. Para emitir NFS-e Padrão Nacional precisa de certificado digital? Resp.: Depende, se a nota for emitida pelo Portal Nacional da NFS-e só é necessário ter um usuário e senha, por outro lado se for emitida por uma aplicação de terceiro vai ser necessário sim, pois a API Rest (webservice) requer que o XML do DPS (Declaração de Prestação de Serviço) seja assinada. 2. O certificado digital tem que ser do prestador? Resp.: Sim. 3. O certificado digital tem que ser um e-CNPJ ou pode ser um e-CPF? Resp.: Vai depender do prestador ser uma pessoal jurídica ou física. 4. O MEI é pessoa jurídica ou física? Resp.: MEI é um Micro Empresário Individual portanto uma pessoa jurídica (possui CNPJ), logo o certificado é um e-CNPJ. 5. A partir de 01/09/2023 só o MEI vai poder emitir suas notas segundo o Padrão Nacional? Resp.: Quem é MEI a partir de 01/09/2023 é obrigatório a emitir a sua nota pelo Padrão Nacional independente se a sua cidade ter aderido ou não ao projeto do Padrão Nacional, por outro lado quem não é MEI vai depender da cidade ter aderido a Emissão da NFS-e. 5. Existem cidades que já aderiram ao projeto? Resp.: Sim, para saber quais são basta acessar o link abaixo e procurar as cidades que na coluna Aderente Emissor Nacional contem a palavra SIM (exemplo a cidade de Bujari/AC). https://www.gov.br/nfse/pt-br/municipios/municipios-aderentes 6. É possível emitir a NFS-e Padrão Nacional usando o ACBr? Resp.: Sim, através do componente ACBrNFSeX, ACBrLibNFSe e ACBrMonitor Plus (Lib e Monitor usar sempre a ultima versão). Com o componente antigo ACBrNFSe não é possível, pois não damos mais manutenção a ele. Para isso, basta alterar a propriedade LayoutNFSe para o valor lnfsPadraoNacionalv1. A mesma fica na aba Geral do programa exemplo para o componente nativo. No caminho DFe > WebServices > NFSe no MonitorPLUS e na seção [NFSe] no arquivo ACBrLib.ini. 7. Ao tentar emitir uma nota no Padrão Nacional usando o componente ou a Lib ou o Monitor estou recebendo alguns erros de internet. Resp. Isso é possível de estar ocorrendo pois a RFB e o SERPRO não esperavam um volume gigantesco de emissões, eles estão trabalhando para sanar esses problemas. 8. Posso usar o certificado A3 ou tem que ser A1? Resp.: Pode sim usar o A3, mas a Equipe ACBr recomenda o uso do A1, pois o A3 possui conexão física com o computador essa conexão pode falhar, já o A1 é um arquivo (PFX) que é salvo no disco ou no banco de dados e pode ser instalado no Windows. Outra é que com o certificado A1 e o componente ou Lib ou Monitor configurado para usar o OpenSSL a aplicação vai funcionar independente da versão do Windows e se ele esta atualizado ou não, já o A3 não tem como usar o OpenSSL. 9. "RNG9999 Erro não catalogado" e agora? Este erro é um indicativo de que ocorreu no meio do processo, no entanto, o erro em questão não é um dos que foram mapeados. Pensem nele como o "último else" das validações. Ao receber este erro, revise todas as informações que estão configuradas e que estão sendo enviadas no DPS para se certificar que não esteja sendo enviado algo errado.

Edição do Papo PRO relacionada ao tema: