Painel de líderes

Bom dia pessoal, Estamos recebendo relatos de instabilidade nos servidores da SEF de MG desde ontem a tarde (11/06/2024) e isso parece estar atingindo os webservices, principalmente de NF-e/NFC-e. Por exemplo, nesse exato momento (12/06/2024 09:43) o site SPED MG está fora do ar. Em alguns momentos o próprio site da Sec. Fazenda de MG estava fora do ar, mas agora parece ter retornado. No entanto até o momento desta publicação ainda não foram ativados o serviço de contingência. Talvez seja uma indisponibilidade momentânea. Então fique atento.

Olá pessoal, A Receita Federal publicou em 30/04/2024 a NT 03.2024 que visa a inclusão do evento S-2221 - Exame Toxicológico do Motorista Profissional Empregado. Seguem links para a NT e a Nota Orientativa. https://www.gov.br/esocial/pt-br/centrais-de-conteudo/agenda/30-04-2024-publicada-nota-orientativa-v-s-1-2-07-2024 https://www.gov.br/esocial/pt-br/centrais-de-conteudo/agenda/30-04-2024-publicada-nota-tecnica-v-s-1-2-03-2024 Conforme a NT, o evento será disponibilizando pela Receita: * Em produção restrita a partir de 30/06/2024 * Em produção a partir de 01/08/2024 A implementação já está no nosso backlog e atualizaremos este tópico quando houverem novidades. Até mais,

Boa tarde a todos, Por ser outra cidade seria bom criar um novo tópico só para ela. Mas se esta aparecendo o erro 404 isso significa que eles divulgaram a URL mas ela ainda não foi criada ou ativada. O Pronim é do GovBr. As cidades que são atendidas pelo GovBr o layout do XML é somente a versão 1 da ABRASF. Já o Pronim tem tanto a versão 1 quanto a versão 2.02, 2.03 da ABRASF. Vou fechar este tópico.

Boa tarde, na proxima compilação da lib já irá contemplar

Obrigado @Daniel InfoCotidiano!

Obrigado no svn a correção

Teria como testar em um maquina com o sistema operacional mais novo, vi que vc esta usando o Windows 7, recomendo também usar o componente ACBRescpos.

Boa tarde, vou fazer a reinstalação e testar novamente

Olá Pessoal, A resposta para o título do tópico é muito simples: Sim e Não. Hoje temos provedores que seguem a versão 1 ou 2 do layout da ABRASF, provedores que tem o seu próprio layout e o layout do Padrão Nacional. Segundo os manuais da ABRASF (Versão 1 ou 2) bem como do Padrão Nacional não existe a possibilidade de informar 2 ou mais itens, só é possível informar somente um item, portanto não existe uma lista de serviços. Já os provedores que tem layout próprio alguns permitem outros não. Como saber se o provedor permite informar mais de um item de serviço? É muito simples, através do programa exemplo, você o configura para a cidade deseja na aba Emitente, salve a configuração, clique no botão [Informações sobre o Provedor] que esta na aba Geral. Do lado direito temos uma aba chamada Log, vai ser apresentado as informações sobre o provedor que atende a cidade que foi configurada, informações estas como Autenticação, Serviços Disponibilizados e Particularidades. Em Particularidades se aparecer escrito: Permite mais de um serviço, isso significa que o provedor permite que você informe um ou mais itens de serviços. Como faço para informar mais de um item caso o provedor permita? with Servico.ItemServico.New do begin Descricao := 'Desc. do Serv. 1'; ItemListaServico := '09.01'; Quantidade := 10; ValorUnitario := 5; (...) end; with Servico.ItemServico.New do begin Descricao := 'Desc. do Serv. 2'; ItemListaServico := '09.01'; Quantidade := 1; ValorUnitario := 15; (...) end; Vide o programa exemplo do componente ACBrNFSeX para ver os demais campos que podem ser informados além dos 4 mostrados nesse exemplo acima. Mais precisamente procure pela procedure: Alimentar_Componente_layout_Proprio. Então quer dizer que se o provedor que atende a cidade para o qual a NFS-e vai ser emitida não permite não tem como? A resposta é: a principio não tem como, mas o componente ACBrNFSeX vai dar uma mãozinha para você. Como eu faço para enviar uma lista de itens de serviço se o provedor não permite? 1. Você vai informar todos os itens conforme mostrado acima; 2. Configure a propriedade de configuração FormatoDiscriminacao com um dos valores: fdJson ou fdTabulado (vide figura abaixo) Essa propriedade tem os seguintes valores: fdNenhum = Valor padrão da propriedade e faz com que o componente não execute nenhuma ação referente a lista de itens. fdConsolidado = o componente vai totalizar os valores e quantidades e concatenar as descrições dos itens e popular os campos padrões usados pelo provedor para as informações tais como Discriminacao, valor, etc. fdJson = o componente vai montar um Json com as informações (Descrição, Valor Unitário, Quantidade e Valor do Serviço) dos itens e popular o campos padrões usados pelo provedor. fdTabulado = o componente vai montar uma Tabela com as informações (Descrição, Código do Item, Quantidade, Valor Unitário, Valor do Serviço, Base de Calculo e Alíquota) dos itens e popular o campos padrões usados pelo provedor. Desta forma ao imprimir o DANFSE no quadro: Discriminação do Serviço em vez de aparecer um texto, vai aparecer a lista dos itens. Espero que tenham gostado dessa dica.

entao, eu nao entendi muito bem porque tem milhares de cidades la que tem esse mesmo novo endereço mas estao com o provedor pronim quer ver busca no arquivo outras cidades com esse mesmo endereço todas estao como pronim

Olá Comunidade do Projeto ACBr, temos uma novidade para vocês !! O Projeto ACBr esta trabalhando no desenvolvimento de uma nova biblioteca, ACBrLibAbecsPinpad.. Após a criação do componente ACBrAbecsPinpad para Delphi e Lazarus, percebemos que grande parte dos desenvolvedores que utilizam o ACBrLib demonstraram muito interesse em usar este componente.. por isso, podemos dizer que sim, estamos trabalhando no desenvolvimento desta nova biblioteca. Posso dizer também que o nível de desenvolvimento esta bem avançado e que logo teremos noticias sobre seu lançamento.. com documentação e programa exemplo disponíveis para uso. Para quem ainda não conhece o componente ACBrAbecsPinpad, veja o vídeo abaixo:

Contextualizando Se você está tentando emitir uma nota fiscal de serviços eletrônica para o provedor Ginfes, um dos possíveis retornos que pode receber é: <Codigo>E160</Codigo> <Mensagem>Arquivo enviado fora da estrutura do arquivo XML de entrada.</Mensagem> <Correcao>Envie um arquivo dentro do schema do arquivo XML de entrada.</Correcao> A mensagem parece ser alto explicativa e indica que o arquivo que foi enviado está com erro na estrutura, certo? Infelizmente, não é tão simples assim. Os arquivos gerados pela solução ACBr estão de acordo com os schemas e o leiaute fornecido pelo provedor. Na verdade este erro parece ser devolvido pelo Ginfes não só para problemas de leiaute, mas também para "situações genéricas". Vejam alguns exemplos: Erro E160 - Arquivo enviado fora da estrutura do arquivo XML de entrada: Neste tópico um colega relata que resolveu o problema ao corrigir o número do lote que não estava alimentando no componente. Ginfes - Franca = Erro E160: Neste tópico um colega confirma que conseguiu resolver o problema ao corrigir os dados que preencheu no componente para geração da nota. Formatação do campo Aliquota da NFSe: Neste tópico o colega confirma que o CPF do tomador estava incorreto e após correção conseguiu emitir. Erro E160 - Arquivo enviado fora da estrutura do arquivo XML de entrada: Neste tópico um colega conseguiu superar este erro após corrigir um valor que estava indo negativo no XML. Esse erro também pode ocorrer caso você não seja prestador da cidade que esteja fazendo testes, em vez do provedor retornar que o seu CNPJ não consta no cadastro deles, o retorno é esse erro E160 que acusa que o arquivo enviado esta fora da estrutura. Mas então o que eu posso fazer? Caso você tenha recebido este erro ao tentar emitir uma nota para uma cidade que é atendida pelo provedor Ginfes, revise todas as informações presentes no XML gerado. Se mesmo depois disso o problema persistir, entre em contato com o provedor e questione o por quê de estar recebendo esta rejeição. Ao fazer isso, o provedor pode apontar se alguma informação presente no XML está em desacordo com o cadastro da base de dados mantida pelo mesmo.

Boa tarde Comunidade, As alterações do Informe Técnico já foram aplicadas ao componente, Monitor e ACBrLib. A previsão da SEFAZ para vigência Homologação / Produção é 01/07/2024, nesse momento você pode testar os novos meios de pagamento na geração do XML e deixar uma flag no seu sistema para quando chegar a hora de utilizar a nova tabela o seu sistema já está pronto. As classes do ACBr já fazem a escrita do XML, Leitura e impressão. Exemplo : Caso receber a rejeição 436 : Código do meio de pagamento inexistente, é porque ainda não está liberado a nova tabela para o uso. Uma observação ao Meio de Pagamento 05 fpCreditoLoja, que teve sua descrição alterada de Credito Loja para Private Label, isso devido ao fato de agora temos o enumerador 21 fpCreditoEmLojaPorDevolucao Crédito em Loja, que tem a finalidade "Crédito em loja decorrente de valor pago anteriormente, de devolução de mercadoria etc.". Eles possuem nomenclaturas parecidas, mas possuem finalidades diferentes, o que foi alterado foi a descrição e não código ou enumerador dos mesmos. De forma mais explicativa, o enumerador CreditoEmLojaPorDevolucao associa de forma mais clara as ocorrências relacionadas a esta forma de pagamento, tais como quando o cliente teve um crédito gerado por uma devolução de uma compra feita anteriormente, já o já existente CreditoLoja visa ser utilizado nas situações onde de fato é utilizado crediário ou cartão próprio da loja, ou seja, o chamado private label.

Olá Comunidade do Projeto ACBr !! Depois de alguns dias trabalhando no desenvolvimento do ACBrLibAbecsPinpad, posso dizer que finalizamos ! Como citado no post acima, temos o Componente ACBrAbecsPinpad, onde o mesmo é utilizado por desenvolvedores Delphi e Lazarus. Agora com ACBrLibAbecsPinpad você pode fazer uma integração comunicando diretamente com o Pinpad, utilizando qualquer linguagem de programação possível de se consumir uma dll (Windows) ou .so (Linux). Utilizando o ACBrLibAbecsPinpad, é possível, saber quais a capacidades do Pinpad, enviar textos para o display do pinpad e também exibir uma imagem no display.. é claro que o pinpad precisa ter suporte para envio de imagens. //-------------------------------- Exemplo ACBrLib C# --------------------------------------// Parâmetros: sResposta - Usado pelo retorno, contem as informações retornadas pela consulta. esTamanho - Usado pelo retorno, contem o tamanho da string (sResposta). AbecsPinpad.PinPadCapabilities(); Exemplo de resposta: [Resposta] DisplayGraphicPixelsCols=240 DisplayGraphicPixelsRows=320 DisplayIsColor=1 DisplayIsGraphic=1 DisplayTextModeDimensionsCols=16 DisplayTextModeDimensionsRows=8 Manufacturer=GERTEC MediaGIFisSupported=0 MediaJPGisSupported=1 MediaPNGisSupported=1 Memory=192MB Model=PPC-930 PartNumber=PPC-930 SerialNumber=7200642206000208 SpecificationVersion=2,12 SupportContactless=1 //-------------------------------- Exemplo ACBrLib C# --------------------------------------// Parâmetros: sMensagem - Mensagem a ser exibido no display do pinpad. AbecsPinpad.DSP("ACBrAbecsPinpad"); //-------------------------------- Exemplo ACBrLib C# --------------------------------------// Parâmetros: sNomeArquivo - Nome do arquivo salvo na memória do pinpad. AbecsPinpad.DSI("LOGOACBR"); Obs: Esperamos ansiosos pelo feedback de todos, e sabemos que podem surgir necessidades de ajustes, por este motivo fique atento aos commits e atualização dos Manuais e Programas de Exemplo. Até o próximo lançamento !!

Boa tarde! Confirmei junto aos membros que atuaram diretamente na construção do ACBrAbecsPinPad. O TEF bloqueia o PinPad devido ao processo de comunicação com a DLL. Infelizmente esta é uma limitação. Pois ambos partilham da mesma porta COM. Então você tem que liberar o TEF, iniciar a comunicação com o PinPad, fazer as operações com o PinPad, liberar o PinPad e iniciar a comunicação com TEF. Um outra alternativa seria exibir o QrCode via PIX direto pelo TEF, mas para isso seria necessário uma parceria junto a PayGo.

Olá Pessoal, É sabido que existem provedores que possuem layout próprio e neste caso as vezes não tem todas as informações que são impressas no DANFSE. Até o momento foi detectado o campo Opção Simples Nacional. O provedor que não tem essa informação no XML da NFS-e é o IPM (layout próprio). Como não tem a informação não devemos imprimir. Para resolver essa questão foi criado uma propriedade de parametrização no componente chamada: ImprimirOptanteSN que do tipo boolean. Por padrão essa propriedade possui o valor True, ou seja, a informação vai ser impressa. Caso o provedor (como é o caso do IPM) não tenha essa informação no XML da NFS-e, basta fazer a seguinte alteração na unit Provider do provedor. Na procedure Configuracao, acrescentar a linha: ConfigGeral.ImprimirOptanteSN := False; Feita a alteração, devemos salvar a unit alterada, reinstalar o componente e fazer novos testes. Não esqueça de nos comunicarem dessa alteração para que possamos envia-la para o SVN. Vejam como foi feito na unit IPM.Provider.

Olá pessoal! O provedor ISSBarueri possui leaiute próprio e realiza a validação de dois campos de identificação, o campo "IdentificacaoRemessa" e o campo "NumeroRPS". Caso estejam recebendo o retorno: É necessário que o valor de identificação correspondente seja implementado. Uma dica compartilhada pelo membro de nossa comunidade @cueiogordo é que se você receber algum outro erro, o mesmo número de RPS pode ser utilizado se o IdentificacaoRemessa for incrementado.

Olá pessoal! Compartilhando mais uma dica, agora do colega @Sidney_Navis: Se você estiver recebendo o erro ao fazer uma consulta de lote usando o número de protocolo que recebeu no retorno do envio: <Codigo>R0404</Codigo> <Mensagem>Não há informações disponíveis com os parâmetros fornecidos</Mensagem> Isso ocorre porque provedor ISSBarueri diferente dos demais provedores que adotam o envio assíncrono e usam o mesmo número de protocolo na consulta de situação e de lote, o ISSBarueri gera um número de protocolo para cada etapa do processo. Ou seja: Você envia o XML do RPS e recebe um número de protocolo. Você consulta a situação do lote usando o protocolo que recebeu no retorno do envio e recebe um novo número de protocolo. Você consulta o Lote do RPS usando o novo número que recebeu no retorno da consulta situação.

Correção usar esse aqui, segue como vc tem que configurar o equipamento. ps: foi a melhor a config que encontrei para esse equipamento.

Bom dia Amigos, Passando só para deixar um feedback - Eles responderam dizendo que realmente havia um problema na validação da nova regra implantada em 24/04. Corrigiram, reenviamos o evento e já foi aprovado.

Olá pessoal! Como muitos sabem, quando falamos de nota de serviço, a falta de padronização é algo comum. Com diversos provedores implementando de diversas formas o seus web services para recepção e geração das NFSes. O provedor SmarAPD é um exemplo disso. Analisando, pois descobrimos que a versão 2.04 pode ser implementada de formas diferentes. Como o ACBr trata isso? Para atender a esta nova demanda foi criado um novo parâmetro SubVersao que pode ser adicionado no arquivo ACBrNFSeXServicos.ini. Veja um exemplo: [3551702] ; Atualizado em 02/04/2024 Nome=Sertaozinho UF=SP Provedor=SmarAPD Versao=2.04 Params=SubVersao:1 ProRecepcionar=https://pmsertaozinho.smarapd.com.br/tb/services/Abrasf24 [3522703] ; Atualizado em 06/04/2023 Nome=Itapolis UF=SP Provedor=SmarAPD Versao=2.04 ProRecepcionar=https://notafiscal.itapolis.sp.gov.br:8090/tbw/services/nfseSOAP HomRecepcionar=https://tributacao.smarapd.com.br/tbwhomolog/services/nfseSOAP ProLinkURL=http://suporte.itapolis.sp.gov.br:9083/tbw/loginWeb.jsp?execobj=NFENotaFiscalBuscarDireto&cnpj=%Cnpj%&numero=%NumeroNFSe%&chave=%ChaveAcesso% HomLinkURL=http://suporte.itapolis.sp.gov.br:9083/tbw/loginWeb.jsp?execobj=NFENotaFiscalBuscarDireto&cnpj=%Cnpj%&numero=%NumeroNFSe%&chave=%ChaveAcesso% Note que ambas as cidades são atendidas pelo mesmo provedor, na mesma versão do layout, no entanto, a cidade de Sertaozinho faz uso do Params SubVersao, indicando que a forma como o provedor implementou o web service para esta cidade, difere da forma como foi feito para Itapolis. Com a adição do Params, ambas as implementações são atendidas pela solução ACBr sem que uma interfira ou prejudique a outra.

Olá Pessoal, Na versão 2 do layout da ABRASF temos o método SubstituirNFSe que tem por finalidade cancelar uma determinada nota e emitir outra que vira a ser a nota substituirá a que foi cancelada. Por outro lado na versão 1 do layout da ABRASF não temos esse método, mas existe uma outra maneira de se fazer isso. No programa exemplo do componente ACBrNFSeX na procedure Alimentar_Componente_layout_ABRASF temos o seguinte fragmento de código: {========================================================================= Numero, Série e Tipo do Rps que esta sendo substituido por este =========================================================================} { RpsSubstituido.Numero := FormatFloat('#########0', i); RpsSubstituido.Serie := 'UNICA'; // TnfseTipoRPS = ( trRPS, trNFConjugada, trCupom ); RpsSubstituido.Tipo := trRPS; } Esta previsto no layout do RPS da versão 1 do layout da ABRASF um grupo chamado RpsSubstituido e dentro dele temos 3 campos: Numero, Serie e Tipo. Ao alimentar o componente com os dados de um novo RPS e alimentarmos esses 3 campos conforme exemplo acima com o numero/serie/tipo de um RPS que já foi convertido em NFS-e, teremos um RPS com um "pedido de substituição". Ao enviar esse RPS e o mesmo for processado com sucesso, ou seja, se transformou em uma NFS-e o provedor providenciará o cancelamento da nota referente ao RPS informado no grupo RpsSubstituido. É dessa forma que realizamos a substituição de uma NFS-e por outra quando o provedor segue a versão 1 do layout da ABRASF. Para quem utiliza o ACBrMonitor no arquivo INI basta incluir a seção: [RpsSubstituido] Numero=<numero do rps a ser substituido> Serie=<serie do rps a ser substituido> Tipo=1 A dica acima também pode ser utilizada para quem utiliza o arquivo INI juntamente com o ACBrLibNFSe.

Olá Pessoal, Encontra-se disponível o novo provedor Elmar. Para mais informações favor ler o tópico abaixo.

Olá Pessoal, Muitos desenvolvedores ainda utilizam o componente antigo (ACBrNFSe) para emitir as NFS-e e noto uma resistência em mudar para o novo (ACBrNFSeX). Resistência essa pelo desconhecido, pelo tempo, uma vez que já dissemos que muitas coisas mudaram do antigo para o novo. Ai vem a grande pergunta, devemos ou não migrar para o componente novo? A resposta é: Sim. Vou listar alguns motivos: 1. O código do novo componente ficou muito mais limpo, consequentemente a sua manutenção e correção se tornou muito mais fácil. 2. A implementação de novos provedores também ficou muito fácil. Por exemplo, se o provedor segue a versão 1 ou 2 da ABRASF é possível implementar em apenas 1 hora. Se ele tem um layout próprio em 1 ou 2 dias. 3. O componente novo atende todos os provedores do antigo e vários provedores novos. Ou seja, o componente novo é mais completo. 4. No componente novo foi utilizado novas units (rotinas) para a leitura e escrita do XML. Estas são mais rápidas em relação as utilizadas pelo componente antigo. Ou seja, o componente novo é mais rápido que o antigo. 5. O novo componente foi disponibilizado em 24/05/2021. Dessa data em diante não demos mais manutenção no antigo. Assim diversas correções e melhorias vem sendo aplicadas somente no componente novo. 6. Por fim, mas não menos importante a emissão da NFS-e Padrão Nacional que só existe no componente novo. Acredito ser conhecimento de todos que desde de 01/09/2023 o prestador de serviço que é MEI (Micro Empreendedor Individual) é obrigado a emitir as suas notas segundo o layout da NFS-e Padrão Nacional. Caso você desenvolvedor venha amanhã conquistar um cliente novo que é MEI, será obrigado a usar o componente novo, uma vez que o antigo não tem essa possibilidade. Temos cidades que já estão aderindo ao projeto da NFS-e Padrão Nacional. Essa adesão pode se dar de duas formas: 1. Aderir somente ao compartilhamento das notas com a Receita Federal. 2. Além de aderir o compartilhamento, aderir também a emissão da NFS-e segundo o Padrão Nacional. Como funciona a emissão da NFS-e nessas duas situações? Na primeira situação quando a prefeitura adere somente o compartilhamento, o prestador de serviço que não é MEI continua emitindo as suas notas através do provedor contratado pela prefeitura e esta por sua vez compartilha a nota com a Receita Federal. Na segunda situação quando a prefeitura adere o compartilhamento e a emissão, o prestador de serviço que não é MEI passa a emitir suas notas através da API da Receita Federal. Algumas cidades estão migrando por etapas como é o caso de Porto Alegre/RS que até o momento somente os prestadores que são Simples Nacional foram migrados, ou seja, devem emitir suas notas segundo o Padrão Nacional, os que não são Simples Nacional devem aguardar mais um pouco portanto devem continuar a emitir as suas notas pelo provedor contratado pela prefeitura. A Receita Federal esta conversando com todas as prefeituras, mostrando as vantagens delas de pelo menos aderir o compartilhamento. Uma das cidades que vai aderir o compartilhamento é Uberlândia/MG e que esta mudando de um provedor com layout próprio para outro que segue a versão 2 do layout da ABRASF, segundo funcionários da prefeitura com o layout da ABRASF fica muito mais fácil realizar o compartilhamento. Detalhe, esse novo provedor de Uberlândia/MG não existe no componente antigo. Depois de tudo que foi exposto acima, você vai continuar com o componente antigo? Não deixe para amanhã o que você deve fazer agora.

Olá pessoal! Como muitos sabem, no dia 01/04/2023 terá início a obrigatoriedade da vinculação dos meios de pagamento ao documento fiscal eletrônico no Mato Grosso. O objetivo deste tópico é reforçar pontos de importância e esclarecer dúvidas a respeito desse processo. Legislação O estabelecimento desta obrigatoriedade veio com o Decreto Nº 599-2023 que trouxe os incisos 11-A, 11-B, 15-A e 15-B que de forma resumida em uma transcrição livre estabelecem que: § 11-A: O comprovante de pagamento deve ser vinculado a NFe mediante integração com o sistema emissor quando o pagamento for por meio de cartão de crédito, débito, pix ou outra maneira de pagamento eletrônica. § 11-B: Fica vedado o uso de equipamento que para processar as operações de pagamento de NFe que não permitam vinculação do comprovante de pagamento mediante integração com sistema emissor. § 15-A: O comprovante de pagamento deve ser vinculado a NFCe mediante integração com o sistema emissor quando o pagamento for por meio de cartão de crédito, débito, pix ou outra maneira de pagamento eletrônica. § 15-B: Fica vedado o uso de equipamento que para processar as operações de pagamento de NFCe que não permitam vinculação do comprovante de pagamento mediante integração com sistema emissor. Na prática o que isso quer dizer? A partir de 01/04/2024, as NFes/NFCes emitidas deverão conter no arquivo a informação que identifique o pagamento, vinculando o mesmo ao respectivo DFe esse processo deverá ser feito de forma integrada na aplicação emissora, ou seja, caso o documento fiscal se encaixe nas categorias que passa a ser obrigatório, não será mais permitido, por exemplo, processar a venda no sistema, pagar na maquininha do cartão e colocar a via no famoso espeto de papel para conferir e contabilizar no sistema no final do dia depois. Agora quando for feita a venda, o software emissor deve enviar o comando de recebimento para o equipamento que vai ser usado para processar o pagamento e deve receber o retorno do mesmo, tratando a informação e vinculando a mesma no documento fiscal. Ou resumindo esse processo em uma palavra TEF. Atividades Obrigadas A princípio, estarão obrigados a realizar a vinculação do meio de pagamento ao documento fiscal eletrônico os estabelecimentos que possuam um dos CNAEs apresentados na lista abaixo, seja ele primário ou secundário: SUBCLASSE CNAE DENOMINAÇÃO DATA INÍCIO OBRIGATORIEDADE 1091-1/02 Fabricação de produtos de padaria e confeitaria com predominância de produção própria (padarias tradicionais) 1°/04/2024 4721-1/02 Padaria e confeitaria com predominância de revenda 1°/04/2024 4752-1/00 Comercio varejista especializado de equipamentos de telefonia e comunicação 1°/04/2024 4755-5/02 Comércio varejista de artigos de armarinho 1°/04/2024 4755-5/03 Comércio varejista de artigos de cama, mesa e banho 1°/04/2024 4763-6/01 Comércio varejista de brinquedos e artigos recreativos 1°/04/2024 4763-6/02 Comércio varejista de artigos esportivos 1°/04/2024 4774-1/00 Comércio varejista de artigos de óptica 1°/04/2024 4781-4/00 Comércio varejista de artigos do vestuário e acessórios 1°/04/2024 4782-2/01 Comércio varejista de calçados 1°/04/2024 5611-2/01 Restaurantes e similares 1°/04/2024 5611-2/02 Bares e outros estabelecimentos especializados em servir bebidas 1°/04/2024 5611-2/03 Lanchonetes, casas de chá, de sucos e similares 1°/04/2024 5611-2/04 Bares e outros estabelecimentos especializados em servir bebidas, sem entretenimento 1°/04/2024 5611-2/05 Bares e outros estabelecimentos especializados em servir bebidas, com entretenimento 1°/04/2024 5620-1/01 Fornecimento de alimentos preparados preponderantemente para empresas 1°/04/2024 5620-1/04 Fornecimento de alimentos preparados preponderantemente para consumo domiciliar 1°/04/2024 A lista pode ser atualizada adicionando novos CNAEs a critério da Sefaz. FAQ - Perguntas e Respostas Algumas das perguntas do FAQ já foram respondidas em explicação acima. Portanto, abaixo segue o reforço de algumas dúvidas pertinentes. Caso ainda haja dúvidas, consulte o material original citado no final. Com a identificação do meio de pagamento, necessária a informação do CPF do consumidor? A legislação da vinculação de pagamentos ao programa emissor não trouxe modificações relacionadas, portanto, no estado, vendas cujo valor seja igual ou maior a R$1.000,00 com entrega em domicílio deverão deverão ter a identificação do consumidor. Um varejista que possua um dos CNAEs listados como obrigados a vinculação dos meios de pagamento ao DFe como atividade secundária deverá adotar a vinculação por integração via software emissor para ambas atividades ou somente as do CNAE secundário? A vinculação dos meios de pagamento com a NFe/NFCe está restrita ao CNAE correspondente da lista, seja ela a atividade primária ou secundária. No entanto, a para esses casos, a adesão do processo de vinculação para ambas atividades é recomendada, visto que a Sefaz MT pode adicionar novos CNAEs na lista a qualquer momento. Em quais operações será obrigatória a observância da vinculação dos pagamentos? Operações de venda ou revenda, cujo pagamento seja feito através de cartão de crédito, débito, PIX ou outro meio eletrônico. Operações realizadas em site ou plataforma digital própria e teleatendimento também devem observar a obrigatoriedade legal. Em ambos os casos, o comprovante da transação, seja impresso ou digital, deve conter: CNPJ e Nome do estabelecimento que está sendo usado o equipamento. Código de autorização ou identificação do pedido. Data, hora e valor da operação. Identificador do terminal que ocorreu a operação nos casos que se aplica. Em quais operações não será obrigatória a observância da vinculação dos pagamentos? Como a legislação trás uma lista de CNAEs em que se dará a obrigação, entende-se que os CNAEs que não se encontram na lista, não precisam adotar esse novo processo(embora como já citado, recomenda-se a movimentação para adequação, visto que a Sefaz MT pode ampliar a lista). Além disso, a determinação legal não se aplica para: operações com a emissão da NFC-e através do Regime Especial da Nota Fiscal Fácil – NFF. operações de venda não presencial intermediada em site ou plataforma de terceiros;(Lembrando que quando for site ou plataforma próprios, a obrigação é observada). Delivery com pagamento no domicílio do consumidor.(Ainda assim, o nome e o endereço do estabelecimento devem ser impressos no comprovante). Contribuintes enquadrados como MEI. Como deverá ser observada a legislação nos casos de pagamentos de venda a prazo ou pagamentos que não estão atrelados à circulação de mercadorias (recarga de celular, vale-presente, pagamento de energia elétrica, pagamentos de carnê/crediário, dentre outros)? A referida legislação se aplica a operações de venda e revenda de mercadorias, portanto operações que não se enquadrem nesta categoria, como por exemplo, o pagamento de uma conta de energia ou uma recarga de celular não se aplicam a legislação em questão. O ECONF deverá ser usado nos casos da pergunta anterior? O ECONF ainda se encontra em análise e deve ser tratado em NT com previsão de lançamento futura. Na venda a crediário/carnê o cliente recebe a NFC-e no momento da compra. Quando ele paga, nos próximos meses, as parcelas com cartão de débito, como proceder? Pois a NFC-e já foi emitida meses antes. Ele pode pagar no cartão de débito, sem emissão da NFC-e, uma vez que ela já foi emitida anteriormente? Caso a parcela seja paga via cartão ou PIX, quando for disponibilizado, deverá ser usado o ECONF para o caso citado. Como ficam os pagamentos realizados através de nota fiscal de serviço que são geradas no site da prefeitura? A legislação citada se aplica a Nota Fiscal Eletrônica(NFe) e a Nota Fiscal de Consumidor Eletrônica(NFCe), não tendo efeito sobre a Nota Fiscal de Serviço Eletrônica(NFSe). Caso seja possível que o "POS" gerar um QrCode e o sistema faça a leitura para inserção das informações no XML da NF-e/NFC-e? A interligação via leitura de QrCode será admitida como interligação tecnológica? O QrCode com as informações do pagamento eletrônico efetuado, desde que devidamente capturado pelo sistema de automação e preenchido no XML é sim considerado uma interligação válida. É obrigatória a impressão do comprovante de pagamento eletrônico no mesmo dispositivo que irá imprimir o DANFE da NF-e/NFC-e? A legislação do MT não prevê isso, portanto, não. Como proceder em casos que o pagamento no ato, mas dividido. Por exemplo, quando amigos dividem a conta em um restaurante? O documento fiscal eletrônico permite a vinculação de até 99 pagamentos, portanto, caso opte-se por emitir apenas uma nota, ambos pagamentos deverão ser vinculados. Mas não há nada que impeça a emissão de uma nota para cada pagamento também. Como proceder nos casos em que o documento fiscal for emitido em contingência devido a problemas locais como falta de internet? O equipamento que vai recepcionar as operações de pagamento eletrônico deve estar vinculado ao programa emissor do documento fiscal. Sendo assim em caso de falhas de integração, existe possibilidade técnica de interligação sistêmica através de bluetooth, wi-fi ou link de internet alternativo para o correto fluxo da operação. Na prática, quais campos devem ser preenchidos nas operações? Pagamento com cartão de débito ou crédito. Meio de pagamento (tPag) correspondente ao cartão utilizado campo . Valor do pagamento (vPag) preenchido com o valor da operação. Tipo da Integração (tpIntegra) preenchido com o valor 1 que corresponde a "Pagamento Integrado com o Sistema de Automação". No campo CNPJ informar o valor homônimo da Instituição de Pagamento, seja adquirente ou subadiquirente. No Número de autorização da operação com cartões, PIX, boletos e outros pagamentos eletrônicos (cAut) deve ser informado o Código de Autorização da Transação. No campo CNPJReceb informar o CNPJ do estabelecimento beneficiário. No campo idTemPag informar o Id do terminal em que foi feito o pagamento. Pagamento com PIX. Meio de pagamento (tPag) correspondente ao PIX. Valor do pagamento (vPag) preenchido com o valor da operação. Tipo da Integração (tpIntegra) preenchido com o valor 1 que corresponde a "Pagamento Integrado com o Sistema de Automação". No Número de autorização da operação com cartões, PIX, boletos e outros pagamentos eletrônicos (cAut) deve ser informado o Código de Identificação do PIX, ou seja, o endToEndId. No campo CNPJReceb informar o CNPJ do estabelecimento beneficiário. No campo idTemPag informar o Id do terminal em que foi feito o pagamento. Nas operações não presenciais, em site ou plataforma de terceiros. No campo Indicador de Presença do Comprador (indPres) informar o valor equivalente a operação em questão, podendo ser 2 para operação não presencial pela internet, 3 para operação não presencial teleatendimento ou 4 para NFCe com entrega em domicílio. Em CNPJ, informar o do intermediador da transação. Em idCadIntTran informar o identificador cadastrado oo intermediador da transação. Como o ACBr pode me ajudar? Clique AQUI para entender as vantagens e benefícios de se tornar um parceiro ACBr TEF x PayGo. Disclaimer Este tópico foi construído se baseando nas informações do Portal do Conhecimento Sobre a Integração entre NFC-e e Meios de Pagamento Eletrônicos que foi construído em uma parceria entre a Sefaz MT e a AFRAC. Recomendamos também a leitura das informações no Portal para um entendimento mais amplo da situação.

As soluções ACBr para emissão de Nota Fiscal de Serviço Eletrônica abstraem ao máximo as diferenças entre as implementações dos diversos provedores. Mesmo fazendo isso, alguns padrões precisam ser determinados. Por exemplo, a solução espera enviar e receber um arquivo no formato XML. Mas existem provedores por exemplo que devolvem simplesmente. <?xml version="1.0" encoding="UTF-8"?>You do not have permission to view this directory or page. Vejam que isso não é um arquivo XML válido. Em casos como esse a solução tenta ler o retorno esperando um XML válido, encontra isso e devolve o erro: Mas então o que eu posso fazer neste caso? A primeira coisa a se fazer ao receber este erro é conferir qual é o conteúdo do arquivo de retorno, pois é alta probabilidade de que o mesmo tenha um conteúdo em formato inválido ou erro não previsto. O mais indicado é que se confira no arquivo -soap, que é o retorno completo devolvido pelo web service. No tópico abaixo tem orientações de como configurar para que seja gerado estes arquivos: Conferindo nesses arquivos, fica mais fácil para você e também para a equipe ACBr entender qual foi o erro e determinar qual é o curso de ação a ser tomado.

RPS/DPS O que é RPS e DPS? A sigla RPS significa Recibo Provisório de Serviço. Diferente do processo de emissão de outros DFes, onde é gerado o XML do respectivo DFe e o mesmo é enviado para validação e aceitação do web service, na emissão de Nota Fiscal de Serviço(NFSe), é o web service quem gera o XML da NFSe. Ou seja: No caso do Padrão Nacional, é chamado de "Declaração de Prestação de Serviço" (DPS). E apesar da diferença no nome, sua função e lógica é basicamente a mesma do RPS, ou seja, o prestador gera um XML de DPS, envia o mesmo para a API do Padrão Nacional e em caso de sucesso, o DPS é convertido em NFSe e o XML da mesma é devolvido para o prestador. Por que não existe quando emito direto pela prefeitura? O RPS só faz parte do processo de emissão quando o mesmo é feito através de um web service. Quando a emissão é feita pelo site da prefeitura(quando existe a opção), o RPS é inexistente. É importante entender que o processo de emissão para NFSe é diferente quando feito através do site da prefeitura e quando feito via web service. Muitas vezes, são usuários diferentes para o site e para o web service, existindo casos em que mesmo no web service os usuários dos ambientes de homologação e produção são diferentes. PROVEDORES O que é um provedor? Provedor é nome dado as empresas que fornecem o web service com o serviço de emissão de nota para as administrações municipais. Diferente de outros DFes, a nota de serviço tem sua tributação em nível municipal. Por isso, não há, por exemplo, uma Sefaz para cuidar dos serviços de emissão. Para se ter uma ideia, já passamos da marca de 130 provedores implementados na solução de emissão de nota de serviço do ACBr. Leiaute ABRASF e Leiaute do próprio? Devido ao fato de ser algo a nível municipal, não há uma padronização de leiaute na formação dos arquivos XML de RPS e de NFSe. O leiaute ABRASF foi uma sugestão de padronização feita pela entidade no início do projeto da Nota de Serviço. Alguns provedores implementaram seus web services seguindo tal padrão, no entanto, ainda assim existem provedores que apesar de seguir o leiaute, implementaram particularidades próprias. Há também provedores que não seguiram a sugestão e criaram um leiaute próprio completamente diferente. Temos provedores em que é possível enviar um lote de até 50 RPS e temos provedores em que o envio é unitário. É importante lembrar que apesar desta falta de padronização por parte dos provedores no que diz respeito a implementação da emissão de NFSe, as soluções ACBr procuram abstrair ao máximo essas particularidades, simplificando o processo de emissão da melhor forma possível. HOMOLOGAÇÃO Como saber se minha cidade é atendida? Para verificar se sua cidade é atendida basta buscar pela mesma no arquivo ACBrNFSeXServicos.ini que acompanha todas as soluções de emissão de Nota de Serviço do ACBr. Caso haja informação de provedor atribuída, é possível realizar emissão para a mesma. Vejam um exemplo: [3550308] Nome=Sao Paulo UF=SP Provedor=ISSSaoPaulo ProRecepcionar=https://nfe.prefeitura.sp.gov.br/ws/lotenfe.asmx ProLinkURL=https://nfe.prefeitura.sp.gov.br/nfe.aspx?ccm=%InscMunic%&nf=%NumeroNFSe%&cod=%CodVerif% HomLinkURL=https://nfe.prefeitura.sp.gov.br/nfe.aspx?ccm=%InscMunic%&nf=%NumeroNFSe%&cod=%CodVerif% Se minha cidade não for atendida, o que fazer? Mesmo que não haja informação de provedor atribuída para a sua cidade, a adição da mesma é bem simples. Basta entrar em contato com a prefeitura questionando qual é o provedor que atende a cidade para emissão de notas de serviço, quais são suas URLs e adicionar estas informações no arquivo ACBrNFSeXServicos.ini. Veja o tópico abaixo para uma explicação do procedimento para realizar essa inclusão é explicado em detalhes. Recebi os erros "Não informada a URL de Homologação, entre em contato com a prefeitura" e "Serviço não implementado para este provedor". E agora, o que eu faço? Conforme foi citado anteriormente, não há uma padronização por parte dos provedores na forma como implementam seus web services de emissão de nota de serviço. Isso significa que nem todos os métodos implementados por um provedor estarão disponíveis para outro. Até mesmo a existência do ambiente de homologação não é uma constante. Veja o tópico abaixo para uma explicação mais detalhada sobre ambas as mensagens(e mais algumas outras) com sugestões do que pode ser feito caso se deparem com elas. Quais são as formas de homologar? Por mais estranho que possa parecer, a falta de uma URL de homologação, nem sempre significa que não é possível fazer testes de emissão e que se tenha de partir direto para produção. Alguns provedores usam uma informação enviada no XML do RPS para diferenciar o ambiente, enquanto outros possuem método específicos para teste. Confira o tópico abaixo para uma explicação detalhada das diferentes possíveis formas de se homologar uma nota fiscal de serviço. É importante entender que mesmo que a princípio as soluções ACBr não atendam a uma cidade específica a adição da mesma é um processo simples de ser efetuado. Ainda que não haja ambiente de homologação para testar a emissão de notas, existem outras formas de se testar. FLUXO DE ENVIO O que é o parâmetro do modo de envio e para que ele serve? A emissão de uma nota de serviço via web service pode ser feita de maneira síncrona ou assíncrona dependendo de como foi implementado pelo provedor. O parâmetro modo de envio define para a solução ACBr qual dos dois será utilizado. Uma dica para este caso é fazer uso do parâmetro meAutomatico, para que a própria solução se encarregue de decidir qual é o modo mais apropriado. Qual é o exemplo de um fluxo de emissão? Para o envio de forma síncrona o retorno da tentativa de emissão já é o XML da NFSe em caso de sucesso e os erros caso alguma coisa precise ser corrigida. Para o envio de forma assíncrona, podemos definir em: Emissão No retorno da emissão é devolvido um número de protocolo. Consulta da situação do lote. É devolvido um número representando a situação atual, sendo: 1 - Protocolo consultado inválido, 2 - Lote em processamento, 3- Lote processado com erros e 4 - Lote processado com sucesso. Quando a situação for 3 ou 4 é feita a consulta do lote. Consulta do lote para pegar os erros em caso de falha ou o XML da NFSe em caso de sucesso. O fluxograma abaixo também demonstra o envio de forma assíncrona. E se der TimeOut no meio disso? Em caso de erro de Time Out, antes de fazer novo envio, correndo risco de uma emissão duplicada, é importante realizar consulta pelo RPS para ter certeza de que a nota foi emitida e o Time Out não ocorreu no retorno. Erros começando em E, L e X? Erros iniciados em X são próprios da solução ACBr e geralmente são referentes a validações prévias, alertando sobre informações obrigatórias que não foram preenchidas ou erros internos. Erros iniciados em L ou E são devolvidos pelo web service do provedor. É importante levar em consideração essa diferença de fluxo entre os modos de envio quando for implementar sua rotina de emissão de nota. IMPRESSÃO Tentei imprimir um XML de RPS e não saiu todas as informações, por que? A rotina de leitura e impressão esperam receber um XML de NFSe para o seu correto funcionamento. Como o XML do RPS é posteriormente convertido para o da NFSe algumas das tags lidas coincidem em nome e por isso não ocorre erro na rotina, mas como o XML do RPS não tem todas as informações, o impresso também não vai ter. O leiaute de impressão da solução ACBr é diferente do que vem no site da prefeitura? O impresso da solução ACBr foi idealizado visando atender ao máximo possível as diversas demandas, no entanto, são mais de 5.000 municípios brasileiros e não a nada que impeça que cada um crie um impresso próprio. Por isso é impossível atender a todas as demandas. PADRÃO NACIONAL O que é? Quem deve usar? Quem pode usar? O Padrão Nacional é uma iniciativa que visa trazer ordem a este ambiente caótico de diversos provedores. Nele, o ambiente nacional é o responsável único por fornecer um web service de emissão e os XMLs são criados seguindo leiaute único independente da cidade. Desde o dia 01/09/2023, os prestadores de serviço que são MEI estão obrigados a emitir suas NFSes pelo Padrão Nacional, independente da cidade. Fora isso, para que um prestador possa emitir utilizando o Padrão Nacional, a administração tributária a qual faz parte precisa ter optado pela completa adesão. Na "Lista de Municípios Aderentes" encontram se as cidades que aderiram e qual foi o tipo de adesão. Como emitir nota no Padrão Nacional usando as soluções ACBr? Para emitir NFSe no Padrão Nacional usando as soluções ACBr, basta configurar a cidade, o leiaute para a opção Padrão Nacional e seguir o processo de emissão normalmente. Este tópico tem mais detalhes: Este tópico foi montado baseado a seguinte edição do Papo PRO:

Olá pessoal! Nosso amigo @Pablo.ferreirax fez o processo de homologação para uma cidade atendida pelo provedor ISSNet e compartilhou conosco as seguintes informações. As informações de homologação na ISSNET diferem das informações de produção. Por exemplo, vários códigos em [Serviço] e [IdentificacaoRps] precisaram ser ajustados para garantir o funcionamento correto, como CodigoMunicipio, CodigoTributacaoMunicipio, Serie, Tipo e Numero. Para entender quais valores devem ser inseridos, foi necessário contatar o suporte da ISSNET. Não é possível realizar testes de homologação na ISSNET sem solicitar a alteração da chave interna para o ambiente de homologação. Ao retornar para o ambiente de produção, é necessário entrar novamente em contato com o suporte para solicitar a mudança. Consultar os schemas da ISSNET foi de grande ajuda. Ao procurar o arquivo xsd e verificar os campos relacionados à obrigatoriedade, máximo de caracteres, entre outros detalhes, conseguimos garantir a conformidade dos dados.

Sabemos que uma aplicação 32 bits, deve apenas carregar DLLs de 32 bits (mesmo que o Sistema Operacional, seja de 64 bits) Já se você compila sua aplicação em 64 bits, deverá sempre utilizar DLLs de 64 bits. Porém, infelizmente algumas DLLs possuem o mesmo nome, mesmo tendo arquiteturas diferentes, e isso pode levar o desenvolvedor a ficar confuso, na hora de saber qual é a DLL com a arquitetura correta. É o caso da PGWebLib.dll, a versão 32 e 64 tem o mesmo nome de arquivo em disco... Esse artigo lhe dá algumas dicas de como descobrir qual é a DLL correta a ser carregada, conforme a compilação do seu Binário 1 - Através das váriáveis de ambiente da PGWebLib 4.1.25.x ou superior A partir da versão 4.1.25.x, a PGWebLib ganhou uma proteção de segurança e após a execução do instalador do Client Windows, você poderá encontrar as DLLs nas variáveis de ambiente: PathPGWebLib e PathPGWebLib_x64 PathPGWebLib=C:\Program Files (x86)\PayGo\PGWebLib\PGWebLib.dll PathPGWebLib_x64=C:\Program Files (x86)\PayGo\PGWebLib\x64\PGWebLib.dll Saiba mais sobre a nova DLL PGWebLib, Segura, no tópico abaixo: 2 - Inspecionando o arquivo em Disco Isso é um pouco mais difícil.. você precisa abrir o binário da DLL e examinar o conteúdo dele... Nesse exemplo usamos o programa NotePad++ com o PlugIn HEX-Editor 64 Bits 32 Bits Fonte: https://superuser.com/questions/358434/how-to-check-if-a-binary-is-32-or-64-bit-on-windows

Olá Pessoal, Algumas duvidas frequentes dos desenvolvedores que estão iniciando seus projetos de emissão de NFS-e. 1. O provedor XYZ já esta implementado no componente ACBrNFSeX? Resp.: É muito simples de obter essa resposta, dentro da pasta: ...\Fontes\ACBrDFe\ACBrNFSeX temos o arquivo: Provedores-Implementados.txt e seu conteúdo contem a lista em ordem alfabética de todos os provedores implementados no componente, se o nome do provedor estiver nessa lista então a resposta é Sim. 2. Usando o componente ACBrNFSeX consigo emitir notas para a cidade ABC? Resp.: Na mesma pasta da resposta anterior temos o arquivo: ACBrNFSeXServicos.ini, seu conteúdo contem todas as cidades brasileiras em ordem por código IBGE, se a cidade contem um provedor associado a cidade desejada a resposta é SIM. 3. Procurei no arquivo ACBrNFSeXServicos.ini e a cidade desejada não contem um provedor associado a ela, isso significa que não é possível emitir NFS-e para esta cidade? Resp.: A principio não vai ser possível, mas você pode entrar em contato com a prefeitura e questionar sobre a empresa (provedor) contratada para implementar a emissão de NFS-e por aplicação de terceiros. Precisamos saber qual é o provedor bem como as URLs de homologação e produção do webservice para a cidade em questão (atenção: não serve as URLs usadas para emissão via site/portal da prefeitura). 4. Eu mesmo posso alterar o arquivo ACBrNFSeXServicos.ini para realização de testes antes de criar um tópico sugerindo a inclusão do provedor a uma cidade que ainda não tenha ou alteração de URL ou troca de provedor? Resp.: Sim, toda colaboração é bem vinda, você pode seguir as orientações constantes no inicio do arquivo ACBrNFSeXServicos.ini, elas vão lhe ajudar nessa tarefa que é muito simples. 5. Qual é procedimento correto para emissão de NFS-e quando o prestador de serviço for MEI? Resp.: Observe que na aba "Geral" do programa exemplo temos o campo: Layout da NFSe com as seguinte opções: Se for selecionado a opção lnfsProvedor o componente vai usar o layout adotado pelo provedor, por outro lado se for selecionado a opção lnfsPadraoNacionalv1 o componente vai usar o layout da NFS-e Padrão Nacional que é utilizado obrigatoriamente por todos os prestadores MEI. 6. Então não preciso altear o provedor para PadraoNacional no arquivo ACBrNFSeXServicos.ini ? Resp.: Não, porque no momento somente quem é MEI é obrigado a emitir suas notas no Padrão Nacional os demais prestadores continuam emitindo segundo o layout do provedor contratado pela prefeitura. 7. Quando é que devemos alterar o provedor para PadrãoNacional de um cidade? Resp. O dia que a prefeitura dessa cidade aderir a emissão da NFS-e Padrão Nacional para todos os prestadores. 8. Como eu descubro o layout utilizado por um provedor? Resp.: Executando o programa exemplo do componente ACBrNFSeX e selecionando a cidade desejada e clicando no botão [Salvar Configurações], na aba "Emitente", será apresentado o provedor, layout e versão. 9. Como eu sei se a cidade aderiu ou não a emissão da NFS-e Padrão Nacional? Resp.: No programa exemplo na aba "Emitente" selecione a cidade desejada e clique no botão [Salvar Configuração], depois na aba "Geral" altere o layout para Padrão Nacional e clique novamente no botão para salvar a configuração. Note que a direita as abas vão mudar. Por fim clique no botão [Convenio] que esta na aba "Consultar Parâmetros Municipais", se a cidade aderiu vai constar o valor 1 (Sim) para "Aderente ao Emissor Nacional". 10. Como eu sei se o provedor exige certificado digital e quais os serviços disponibilizados pelo provedor? Resp.: Novamente com o programa exemplo temos essa resposta clicando no botão [Informações sobre o Provedor] que esta na aba "Geral". Você notou que eu respondi varias perguntas usando o programa exemplo? Quando nós consultores e moderadores orientamos estudar o programa exemplo é porque você vai encontrar muitas respostas para as suas duvidas. Nas perguntas acima foi necessário apenas executar o programa exemplo e o configurar para obter as respostas. Estudando o código do programa exemplo você vai saber como utilizar os diversos métodos implementados no componente. Por fim mas não menos importante, sempre utilize o programa exemplo para realizar os testes, pois é a única aplicação em comum entre nós do Projeto ACBr e você Desenvolvedor.

segue pra quem for de ajuda. tabela em sql firebird do enquadramento do IPI CEnq.sql