Painel de líderes

Conceitos básicos. Apesar da redundância presente na frase, ela não deixa de ser verdadeira. Antes de mergulharmos mais fundo no mundo da NFSe, é importante estabelecer as bases, conceituando termos importantes que vão aparecer com frequência quando falarmos do assunto: RPS: é a sigla para Recibo Provisório de Serviço. Trata-se do documento gerado pelo prestador de serviços e enviado ao web service do Provedor para ser convertido em NFSe. Provedor: é o nome dado à empresa que fornece o web service de emissão de NFSe para o município. Geralmente, essa empresa é escolhida por meio de licitação, tendo um prazo de “vida útil” para disponibilizar o serviço até que a licitação termine e uma nova empresa seja selecionada (quando isso acontecer, você pode seguir os passos que tem [AQUI] para atualizar na solução ACBr). Em alguns casos, a própria prefeitura é responsável pelo web service. NFSe: é a sigla para Nota Fiscal de Serviços Eletrônica. Trata-se do documento fiscal eletrônico gerado pelo web service do Provedor a partir da conversão do RPS recebido, nos casos em que nenhum erro seja encontrado. É o documento que, de fato, representa a operação de prestação de serviços. Leiaute ABRASF: é o nome dado ao leiaute sugerido pela Associação Brasileira das Secretarias de Finanças das Capitais (ABRASF), que pode ou não ser adotado pelos provedores. Ele propõe um padrão para a estrutura do RPS e da NFSe, indicando quais campos e informações cada um deve conter. Além disso, sugere os métodos que devem ser implementados no web service. Leiaute Próprio: é o padrão de estrutura de dados definido individualmente por um município ou provedor para a emissão da NFSe, em vez de seguir integralmente o Leiaute ABRASF. Nesse formato, o município estabelece quais campos, formatos e métodos serão utilizados no RPS e na NFSe, podendo diferir totalmente ou parcialmente das especificações sugeridas pela ABRASF. DPS: é a sigla para Declaração de Prestação de Serviços. Trata-se do documento equivalente ao RPS, utilizado no Padrão Nacional da NFSe. Ele reúne as informações necessárias para emissão da nota fiscal e deve ser transmitido ao ambiente nacional, que valida os dados e gera a NFSe nos casos em que não haja inconsistências. Padrão Nacional: também conhecido e divulgado por alguns como NFSe Nacional (na solução ACBr, o Padrão Nacional é considerado um provedor), é o modelo unificado de emissão da Nota Fiscal de Serviços Eletrônica (NFSe), desenvolvido para padronizar o processo em todos os municípios brasileiros. O uso é obrigatório para prestadores de serviço enquadrados como MEI (Microempreendedor Individual) e opcional para os municípios, que podem adotá-lo de duas formas: Modelo de compartilhamento: as notas são emitidas em leiaute próprio da prefeitura, mas as informações são compartilhadas com o ambiente nacional; Modelo completo: todas as NFSe do município são geradas utilizando integralmente o Padrão Nacional. Onde encontrar os projetos de exemplo. Agora que os conceitos foram definidos, vamos dar o primeiro passo na parte prática e localizar os projetos de demonstração. O exemplo disponível em Delphi pode ser encontrado em: ..\trunk2\Exemplos\ACBrDFe\ACBrNFSeX\Delphi O exemplo disponível em Pascal pode ser encontrado em: ..\trunk2\Exemplos\ACBrDFe\ACBrNFSeX\Lazarus Para a ACBrLib temos exemplos disponíveis nas linguagens: C#: ..\trunk2\Projetos\ACBrLib\Demos\C#\NFSe Harbour: ..\trunk2\Projetos\ACBrLib\Demos\Harbour\NFSe Java: ..\trunk2\Projetos\ACBrLib\Demos\Java\NFSe Node.js: ..\trunk2\Projetos\ACBrLib\Demos\Node.js\NFSe PHP: ..\trunk2\Projetos\ACBrLib\Demos\PHP\NFSe VB6: ..\trunk2\Projetos\ACBrLib\Demos\VB6\NFSe Abrir e analisar o código disponível nesses exemplos, criados para demonstrar o preenchimento das propriedades e as chamadas das funções das soluções ACBr, é um passo importante para entender como elas funcionam e como podem ajudar no seu desenvolvimento. Como testar? Na esmagadora maioria dos casos, é necessário, no mínimo, o uso de um certificado digital e-CNPJ para a comunicação com os web services, sem contar aqueles que exigem o uso de chave ou token. Portanto, é mais simples buscar essa informação junto à cidade onde você reside. Procure descobrir qual é o provedor que fornece o serviço para sua cidade, qual leiaute ele utiliza e quais são os requisitos para comunicação com o web service. Uma vez com essas informações em mãos, você pode utilizar os exemplos para testar o processo de emissão junto à sua cidade, compreendendo o fluxo e, por meio dos erros recebidos e da leitura dos manuais do provedor, identificar quais são os campos necessários, os valores esperados, entre outros detalhes importantes. Quais cidades são atendidas? Atualmente, a solução do ACBr atende a 3.079 das 5.571 cidades do Brasil. Para conferir se um município é atendido, basta procurar pelo código IBGE correspondente no arquivo ACBrNFSeXServicos.ini. Se na seção correspondente houver um nome de provedor atribuído, significa que o município é atendido. [3503208] Nome=Araraquara UF=SP Provedor=GINFES Principais Diferenças entre as Cidades. Todas as diferenças entre o processo de emissão de NFSe no município da cidade A e no município da cidade B se devem ao provedor que fornece o serviço para cada uma delas. Cidades atendidas pelo mesmo provedor raramente apresentam particularidades que diferenciem seu processo de emissão. Isso significa que, se você já homologou para uma cidade atendida pelo provedor ISSNet, na versão 2.04, por exemplo, dificilmente terá dificuldades para homologar em outra cidade atendida pelo mesmo provedor e versão. Por outro lado, isso também significa que uma cidade atendida pelo provedor IPM, em sua versão 1.00, terá diferenças significativas em relação a uma cidade atendida pelo ISSNet na versão 2.04. Portanto, é muito importante identificar qual é o provedor que atende ao município e ficar atento às particularidades dele. Quando usar a NFSe Padrão Nacional O Padrão Nacional deve ser utilizado por todos os prestadores de serviço do Brasil que sejam Microempreendedores Individuais (MEI). Fora desse caso, ele só deve ser utilizado se o município tiver aderido integralmente ao modelo. Caso contrário, a comunicação deve ser feita diretamente com o provedor que atende ao município. Como será com a chegada da Reforma Tributária? A Reforma Tributária sobre o consumo trouxe alterações apenas no leiaute do Padrão Nacional. Até o início de 2026, os municípios deverão escolher entre: Aderir integralmente ao Padrão Nacional, adotando-o como modelo único de emissão; ou Continuar utilizando os web services fornecidos pelos provedores, caso em que esses provedores deverão incluir novos campos em seus leiautes para receber as informações exigidas pela reforma e compartilhá-las com o Padrão Nacional de alguma forma. Vale a leitura. Emissão de NFSe, eliminando todas as dúvidas. Duvidas Frequentes sobre o ACBrNFSeX Algumas mensagens comuns no ACBrNFSeX, o que elas significam e o que você pode fazer. Informar mais de um item de serviço é possível? Consigo consultar e baixar os XMLs das NFSes junto as prefeituras usando as soluções do ACBr? Emissão de NFS-e segundo o Padrão Nacional Primeiros Passos com a Reforma Tributária

Depurando, para cheque da Caixa a linha de impressão do valor por padrão é 1: Nesse caso não tem como reduzir mais, então é o caso de calibrar essa impressora pra iniciar a impressão mais acima.

os fontes estão todos abertos então basta abrir e conferir veja: e no código espero ter ajudado.

A questão é que temos duas soluções, uma feita em DELPHI e outra em Harbour / Clipper. Na solução DELPHI nós usamos os componentes sem problema. A questão está relacionada ao uso da solução que usa o ACBrMonitor (ainda utilizada por muitos de nossos clientes). Enfim, precisamos do ACBrMonitor rodando ok, sem alterar algumas tags do XML conforme antes. Com todo respeito, a questão é: estamos dando volta discutindo o porque usar o ACBrMonitor quando deveríamos estar analisando o motivo desta ferramenta estar alterando o XML de forma indevida.

Olá, pessoal! Foi publicada a Nota Técnica 03/2025 do Reinf. Essa atualização adiciona novos valores possíveis na Tabela 01 – Natureza de Rendimentos do Anexo I dos leiautes e também na Tabela de Natureza de Rendimentos x Código de Receita do Anexo I do Manual de Orientação do Usuário, versão 2.1.2.1, a ser utilizada no registro R-4020. O campo natRendimento já é do tipo string no componente ACBrReinf, portanto, não são necessárias modificações no componente. Leia a Nota Técnica na íntegra [AQUI]

Quem acompanha o Projeto ACBr sabe que sempre recomendamos usar certificados digitais no formato A1. Pois é... o certificado digital A3 ataca mais uma vez!!! Nos últimos dias temos recebido diversos relatos de usuários recebendo mensagens de erro como a mensagem abaixo: Erro Interno: -2146893815 Erro HTTP: 0 URL: https://nfe.svrs.rs.gov.br/ws/NfeStatusServico/NfeStatusServico4.asmx Erro: 2148073481 - E o que aconteceu? Sempre acontece com quem está usando certificado A3? A recomentadação quando usa A1 é configurar com OpenSSL e quando usa A3 com WinCrypt (veja esse tópico aqui para todos os detalhes!) e aí que está uma grande diferença. O A3 acaba dependendo diretamente das configurações, atualizações e permissões do sistema operacional windows. Nas últimas atualizações do windows estão sendo limitados os protocolos de comunicação permitidos e aí que acontece o erro... a sua comunicação acaba não funcionando. Não é um problema novo. Temos um tópico antigo já com orientações de como resolver o problema e quem deu a dica foi o usuário @Jhonatan. Também temos outro tópico que o @Diego Foliene explica tudo detalhadamente. Obrigado aos dois! Vou deixar o tópico do Diego aqui pra você resolver o seu problema!