FBA Digital - Fábio

Prezados contribuintes, Informamos que, a partir de 01/06/2026, a emissão das Notas Fiscais de Serviço Eletrônicas (NFS-e) passará a ser realizada exclusivamente pelo Portal Nacional, conforme diretrizes do projeto da NFS-e Nacional instituído pela Receita Federal do Brasil. O acesso ao sistema deverá ser feito pelo portal oficial: https://www.nfse.gov.br/EmissorNacional/Login Formas de acesso: Certificado Digital (e-CNPJ ou e-CPF); Login e senha (disponível para todos os contribuintes, exceto MEI, conforme regras do ambiente nacional). Importante: O Portal Nacional da NFS-e ainda não disponibiliza a emissão de guias de pagamento (ISS). Dessa forma, os seguintes serviços permanecem sendo realizados no sistema municipal (Sigcorp): Encerramento de competência; Geração e emissão de guias; Demais rotinas relacionadas à apuração do ISS. Ou seja: a emissão da nota será realizada no ambiente nacional, enquanto a gestão do imposto permanece no sistema do município. Integração via Web Service: Para contribuintes que utilizam emissão própria (integração via Web Service), os schemas, layouts e documentação técnica estão disponíveis em: https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica Manual de acesso: O guia oficial para cadastro e utilização do emissor nacional está disponível em: Guia do Emissor Público Nacional Web Nota Fiscal Avulsa: O ambiente nacional da NFS-e não possui a modalidade de Nota Fiscal Avulsa. Contribuintes que anteriormente realizavam emissão de Nota Fiscal Avulsa e necessitarem continuar emitindo NFS-e deverão efetuar cadastro como Microempreendedor Individual (MEI) ou como profissional autônomo, conforme o enquadramento da atividade exercida. Dúvidas relacionadas ao cadastro: E-mail: [email protected] WhatsApp: (49) 3319-1028 - opção Alvará/Viabilidade Dúvidas em relação à emissão de notas fiscais de serviço deverão ser tratadas diretamente pelos canais disponibilizados pelo Portal Nacional.

Consegue anexar o XmlRetorno como o exemplo abaixo? XmlRetorno=<EnviarLoteRpsResposta xmlns="http://www.abrasf.org.br/nfse.xsd"> <ListaMensagemRetornoLote> <MensagemRetorno> <IdentificacaoRps> <Numero>1</Numero> <Serie>1</Serie> <Tipo>1</Tipo> </IdentificacaoRps> <Codigo>SCH1</Codigo> <Mensagem>TAG 'cNBS': [facet 'length'] O valor possui o tamanho '4'; this differs from the allowed length of '9'. - CODE: 1</Mensagem> </MensagemRetorno> <MensagemRetorno> <IdentificacaoRps> <Numero>1</Numero> <Serie>1</Serie> <Tipo>1</Tipo> </IdentificacaoRps> <Codigo>SCH2</Codigo> <Mensagem>TAG 'cNBS': [facet 'pattern'] O valor 'null' nâo é aceito pelo padrâo '\d{9}'. - CODE: 1</Mensagem> </MensagemRetorno> <MensagemRetorno> <IdentificacaoRps> <Numero>1</Numero> <Serie>1</Serie> <Tipo>1</Tipo> </IdentificacaoRps> <Codigo>E160</Codigo> <Mensagem>Arquivo em desacordo com o XML Schema. - CODE: 1</Mensagem> </MensagemRetorno> </ListaMensagemRetornoLote></EnviarLoteRpsResposta> em relação ao que estou enviado tente o seguinte: adicionar em (não sei se influencia em algo mas no meu está sendo enviado) [Servico] ResponsavelRetencao=1 <ResponsavelRetencao>1</ResponsavelRetencao> e em (ao incluir CodigoPais=1058 no tomador ele suprime a tag <CodigoPais>1058</CodigoPais> para mim estava dando erro quando essa tag era inclusa) [Tomador] CodigoPais=1058

Você consegue obter esse nível de log? esse é o log que obtenho quando envio usando a lib, pois nesse log você vai ter o xml que esta sendo montado para enviar, fica mais fácil para tentar identificar o que pode estar ocorrendo, assim como obter eventuais erro no envio, caso consiga, lembre-se apenas de suprimir dados confidenciais, mas tente manter a integridade do xml que aí facilita para identificar: [Envio] CodigoVerificacao= Data= Link= Lote=987 MaxRps=50 ModoEnvio=Enviar Lote Assíncrono NumeroNota= Protocolo= Situacao= Sucesso=0 XmlEnvio=<EnviarLoteRpsEnvio xmlns="http://www.abrasf.org.br/nfse.xsd"><LoteRps Id="Lote_987" versao="2.04"><NumeroLote>987</NumeroLote><Prestador>...ensagem> </MensagemRetorno> </ListaMensagemRetornoLote></EnviarLoteRpsResposta> [Erro1] Codigo=EL43 Correcao= Descricao=Número de lote jà informado. Próximo Lote Vàlido: 993 - CODE: 1

Bom dia, envia o log completo da requisição enviada, a que recebe o protocolo para consulta posterior, o envio assíncrono do RPS verificou no portal da prefeitura se alguma das notas chegou a ser emitida? aqui, após eu realizar a emissão, acredito que não deva ter levado mais do que 60 segundos para receber o xml na consulta por protocolo

Veja que anteriormente você recebeu o retorno: Correção: O lote de RPS correspondente ao protocolo informado foi recebido pela Prefeitura, mas ainda não foi processado. Tente implementar conforme comentei no post anterior: Tente fazer o seguinte: Crie uma nota de com o valor do serviço de R$ 0,01 e tente enviar direto para o AMBIENTE DE PRODUÇÃO, não é raro que o ambiente de homologação se comporte diferente do ambiente de produção, então tente testar diretamente no ambiente de produção, incluindo na descrição da nota por exemplo 'teste de emissão de nfse' e depois quando a emissão ocorrer vai lá e cancela ela, ou caso não cancele o valor do imposto será irrisório, verifique se a emissão ocorreu com sucesso direto no portal https://chapeco.meumunicipio.online/ISS/contribuinte/login.php Enviar o lote como assíncrono, e então depois ficar consultando o retorno pelo número do protocolo recebido conforme informei no post anterior: 'Boa tarde, acho que não é instabilidade, acho que é a mecânica de funcionamento mesmo, ou seja, aparentemente enquanto a nota não é enviada para o ambiente nacional ele não devolve o xml, então a mecânica deverá ser criar um loop e ficar consultando a cada por exemplo 30 segundos durante uns 10 minutos até que receba o xml da nota'

Pelo retorno, ao que tudo indica ocorreu um erro na transmissão, envia o log do envio do RPS, provavelmente deve estar retornando algum erro lá o que acaba não gerando a nota e dando o erro em questão

Boa tarde, acho que não é instabilidade, acho que é a mecânica de funcionamento mesmo, ou seja, aparentemente enquanto a nota não é enviada para o ambiente nacional ele não devolve o xml, então a mecânica deverá ser criar um loop e ficar consultando a cada por exemplo 30 segundos durante uns 10 minutos até que receba o xml da nota

Checkout do repositório Recompilado o /acbr/Projetos/ACBrLib/Fontes/NFSe/ACBrLibNFSe.lpr Campos adicionados na geração da nfse (anteriormente funcionava mesmo sem a tag CodigoPais): [Tomador] CodigoPais=1058 [Servico] CodigoNBS=120012000 Resultado: [Envio] CodigoVerificacao= Data=09/01/2026 02:24:58 Link= Lote=987 MaxRps=50 ModoEnvio=Enviar Lote Síncrono NumeroNota= Protocolo=9c37...5UIhfz Situacao= Sucesso=0 XmlEnvio=<EnviarLoteRpsSincronoEnvio xmlns="http://www.abrasf.org.br/nfse.xsd"><LoteRps Id="Lote_987" versao="2.04"><NumeroLote>987</NumeroLote><Prestador><CpfCnpj>...</Signature></EnviarLoteRpsSincronoEnvio> XmlRetorno=<EnviarLoteRpsSincronoResposta xmlns="http://www.abrasf.org.br/nfse.xsd"> <NumeroLote>987</NumeroLote> <DataRecebimento>2026-01-09T02:24:58-03:00</DataRecebimento> <Protocolo>9c3779faadafc3...An1R5UIhfz</Protocolo> <Mensagem>Solicitaçâo recebida! Aguarde a confirmaçâo da Nota Fiscal pelo Sefaz/ADN.</Mensagem></EnviarLoteRpsSincronoResposta> [Erro1] Codigo=X202 Correcao= Descricao=Lista de NFSe nâo encontrada! (ListaNfse) Aparentemente o envio síncrono não retorna mais o xml da nota, então é preciso fazer o envio assíncrono, e com o protocolo fazer a consulta por lote posteriormente acbrNFSe.consultarLoteRps(protocolo, numero); Outra situação é que no site da prefeitura o pdf disponibilizado já é no formato do padrão nacional mas no webservice continua vindo no padrão antigo

Emissões não estão mais funcionando, segue log da tentativa de emissão: [Envio] CodigoVerificacao= Data= Link= Lote=987 MaxRps=50 ModoEnvio=Enviar Lote Síncrono NumeroNota= Protocolo= Situacao= Sucesso=0 XmlEnvio=<EnviarLoteRpsSincronoEnvio xmlns="http://www.abrasf.org.br/nfse.xsd"><LoteRps Id="Lote_987" versao="2.04"><NumeroLote>987</NumeroLote>[...]</EnviarLoteRpsSincronoEnvio> XmlRetorno=<EnviarLoteRpsSincronoResposta xmlns="http://www.abrasf.org.br/nfse.xsd"> <ListaMensagemRetornoLote> <MensagemRetorno> <IdentificacaoRps> <Numero>1</Numero> <Serie>1</Serie> <Tipo>1</Tipo> </IdentificacaoRps> <Codigo>SCH1</Codigo> <Mensagem>TAG 'Servico': Faltando TAG(s) filha(s). O Esperado é um dos ( NumeroProcesso, cNBS ). - CODE: 1</Mensagem> </MensagemRetorno> <MensagemRetorno> <IdentificacaoRps> <Numero>1</Numero> <Serie>1</Serie> <Tipo>1</Tipo> </IdentificacaoRps> <Codigo>E160</Codigo> <Mensagem>Arquivo em desacordo com o XML Schema. - CODE: 1</Mensagem> </MensagemRetorno> </ListaMensagemRetornoLote></EnviarLoteRpsSincronoResposta> [Erro1] Codigo=SCH1 Correcao= Descricao=TAG 'Servico': Faltando TAG(s) filha(s). O Esperado é um dos ( NumeroProcesso, cNBS ). - CODE: 1 [Erro2] Codigo=E160 Correcao= Descricao=Arquivo em desacordo com o XML Schema. - CODE: 1 [Erro3] Codigo=X202 Correcao= Descricao=Lista de NFSe nâo encontrada! (ListaNfse)

Até o momento as emissões estão ocorrendo normalmente via webservice Existe um comunicado informando que ocorrerá migração no sistema entre fim de 2025 e início de 2026 e um aviso ao acessar o portal https://chapeco.meumunicipio.online/ISS/index.php https://sigcorp.com.br/emissao-de-notas-fiscais-a-partir-de-janeiro-de-2026/

Bom dia @Italo Giurizzato Junior Atualmente o município não utiliza o padrão nacional, pelo que deu a entender no comunicado ele passará a utilizar o padrão nacional a partir de 2026, então eles enviaram o link com as informações do padrão nacional https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica e enviaram o arquivo em anexo com os campos específicos que eles irão utilizar

CHAPECÓ Orientações para adequação dos sistemas WebService ao Novo Layout da Nota Fiscal Nacional Prezados(as) Senhores(as), Com o objetivo de assegurar o pleno alinhamento ao Modelo Nacional de Nota Fiscal de Serviços eletrônica (NFS-e), informamos que, a partir de 1º de janeiro de 2026, todas as emissões deverão, obrigatoriamente, seguir o layout nacional definido pela Receita Federal. Reforçamos que essa atualização é essencial para garantir a conformidade com o padrão nacional e evitar impactos futuros na emissão de notas fiscais. Para facilitar a adaptação das empresas que utilizam o WebService, informamos que: A base de testes para validação dos novos campos do WebService será a base de homologação do município, basta acrescentar teste antes do endereço eletrônico. O manual técnico da Receita Federal, também disponível neste link, contém todos os campos necessários para conformidade com o layout nacional. Recomendamos que as equipes técnicas estudem este material previamente. O layout adotado pela equipe da SIGCORP está em anexo a este e-mail. INFORMAÇÕES IMPORTANTES Sujeição a alterações governamentais: A documentação técnica atualmente disponível reflete a estrutura de arquivos, campos, valores, regras de negócio e endpoints da NFS-e vigentes na data de sua publicação, conforme as diretrizes e especificações técnicas divulgadas no Portal Oficial da Nota Nacional. Possibilidade de alterações sem aviso prévio: O padrão da Nota Nacional — incluindo estrutura, schema XML, validações, regras de negócio e disponibilidade de ambientes — poderá ser alterado a qualquer momento, sem aviso prévio, por determinação das autoridades fiscais competentes. Tais alterações são regidas exclusivamente pelas publicações oficiais do referido portal. Responsabilidade de adaptação: A Sigcorp Tecnologia não se responsabiliza por danos, indisponibilidades, falhas de integração ou interrupções de serviço decorrentes de modificações promovidas no padrão da Nota Nacional que impactem a estrutura atualmente documentada. Cabe ao integrador e/ou usuário acompanhar continuamente as atualizações oficiais e promover as adaptações necessárias em seus sistemas, de modo a garantir a conformidade permanente com as versões mais recentes das Especificações Técnicas Nacionais. Em caso de dúvidas ou necessidade de suporte, nossa equipe permanece à disposição por meio do canal de atendimento. Agradecemos a atenção e a colaboração de todos para que essa transição ocorra de forma segura e eficiente. Colocamo-nos à disposição para quaisquer esclarecimentos adicionais. Atenciosamente, GRUPO SOUYESS Este e-mail foi enviado para Você recebeu este e-mail porque se inscreveu em nosso boletim informativo. WebService-CamposAdicionais_SIGCORP.pdf

Compilei a biblioteca usando Fedora 39 e ao tentar utiliza-la no servidor Rocky Linux 8 ocorria o erro abaixo: java.lang.UnsatisfiedLinkError: Unable to load library 'acbrnfse64': /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /lib64/libacbrnfse64.so) A solução foi criar uma máquina virtual Rocky Linux 8, com ambiente gráfico e instalar o lazarus e compilar a lib nela, dessa forma a lib gerada funcionou normalmente no servidor

Ao compilar e executar o exemplo Java ACBrLibNFSe, ocorre o erro abaixo: java -jar "/acbr/acbr-source/acbr/Projetos/ACBrLib/Demos/Java/NFSe/Demo/ACBrLibNFSe.Demo/dist/ACBrLibNFSe.Demo.jar" (java:207086): GLib-GObject-CRITICAL **: 20:39:15.599: cannot register existing type 'GdkDisplayManager' (java:207086): GLib-CRITICAL **: 20:39:15.599: g_once_init_leave: assertion 'result != 0' failed (java:207086): GLib-GObject-CRITICAL **: 20:39:15.599: g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)' failed (java:207086): GLib-GObject-CRITICAL **: 20:39:15.599: invalid (NULL) pointer instance (java:207086): GLib-GObject-CRITICAL **: 20:39:15.599: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed (java:207086): GLib-GObject-CRITICAL **: 20:39:15.599: invalid (NULL) pointer instance (java:207086): GLib-GObject-CRITICAL **: 20:39:15.599: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed (java:207086): GLib-GObject-CRITICAL **: 20:39:15.599: cannot register existing type 'GdkDisplay' (java:207086): GLib-CRITICAL **: 20:39:15.599: g_once_init_leave: assertion 'result != 0' failed (java:207086): GLib-GObject-CRITICAL **: 20:39:15.599: g_type_register_static: assertion 'parent_type > 0' failed (java:207086): GLib-CRITICAL **: 20:39:15.599: g_once_init_leave: assertion 'result != 0' failed (java:207086): GLib-GObject-CRITICAL **: 20:39:15.599: g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)' failed Para solucionar o problema basta remover o código abaixo contido no método 'public static void main(String[] args)' da classe 'public class ACBrLibNFSeDemo ': try { UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); } catch (ClassNotFoundException | InstantiationException | IllegalAccessException | javax.swing.UnsupportedLookAndFeelException ex) { java.util.logging.Logger.getLogger(FrmMain.class.getName()).log(java.util.logging.Level.SEVERE, null, ex); }

Opa, que bom, então já foi corrigido

Perceba que o {$IFNDEF MSWINDOWS} esta dentro do bloco {$ELSE} do {$IFDEF MSWINDOWS} ou seja, ele nunca irá entrar no {$ELSE} do {$IFNDEF MSWINDOWS} e sempre retornará 'libxmlsec1' sendo que o correto seria retornar 'libxmlsec.so' ou 'libxmlsec1.so', ele não deveria retornar somente o nome da lib sem o '.so' {$IFDEF MSWINDOWS} {$IFDEF USE_MINGW} LIBXMLSEC_SO = 'libxmlsec1.dll'; {$ELSE} LIBXMLSEC_SO = 'libxmlsec.dll'; {$ENDIF} {$ELSE} LIBXMLSEC_SO = {$IFNDEF MSWINDOWS}'libxmlsec1'{$ELSE}'libxmlsec.so'{$ENDIF}; {$ENDIF}

Fiz alguns testes (Fedora 28) e as libs estão dispostas da seguinte forma: ls -sal /usr/lib64/libssl* /usr/lib64/libssl3.so /usr/lib64/libssl.so -> libssl.so.1.1.0i /usr/lib64/libssl.so.10 -> libssl.so.1.0.2o /usr/lib64/libssl.so.1.0.2o /usr/lib64/libssl.so.1.1 -> libssl.so.1.1.0i /usr/lib64/libssl.so.1.1.0i ls -sal /usr/lib64/libcrypto* /usr/lib64/libcrypto.so -> libcrypto.so.1.1.0i /usr/lib64/libcrypto.so.10 -> libcrypto.so.1.0.2o /usr/lib64/libcrypto.so.1.0.2o /usr/lib64/libcrypto.so.1.1 -> libcrypto.so.1.1.0i /usr/lib64/libcrypto.so.1.1.0i A função LoadLibHack que é responsável por encontrar as libs, procura primeiro pela lib sem versão nenhuma, então bastou ajustar para que ele procure primeiro pelo '.10' para que fosse realizado o carregamento da lib correta OpenSSLExt DE: DLLVersions: array[1..16] of string = ('', '.1.0.6', '.1.0.5', '.1.0.4', '.1.0.3', '.1.0.2', '.1.0.1','.1.0.0','.0.9.8', '.0.9.7', '.0.9.6', '.0.9.5', '.0.9.4', '.0.9.3', '.0.9.2', '.0.9.1'); PARA: DLLVersions: array[1..17] of string = ('.10','', '.1.0.6', '.1.0.5', '.1.0.4', '.1.0.3', '.1.0.2', '.1.0.1','.1.0.0','.0.9.8', '.0.9.7', '.0.9.6', '.0.9.5', '.0.9.4', '.0.9.3', '.0.9.2', '.0.9.1'); Usando a lib da série 1.0 a assinatura ocorreu corretamente tanto usando xsLibXml2 como xsXmlSec e a conexão com o webservice também funcionou normalmente Fiz alguns testes em C com as duas versões da lib série 1.0.2 e 1.1.0 para o método EVP_DigestInit, que é onde esta ocorrendo o erro usando a versão 1.1 da lib ao tentar assinar usando xsLibXml2. Foi preciso fazer várias pequenas modificações no código em C para funcionar na versão nova. Atualmente estou usando a versão 1.1 da lib OpenSSL para emissão de NFe e esta rodando corretamente, as exceções ficam por conta da xsLibXml2 que pode ser substituída pela xsXmlSec e o bug do tópico em questão no método GetNotAfter, verificando no site https://www.openssl.org/source/ o suporte a versão da série 1.0.2 (LTS) terminará em 31/12/2019 e eles recomendam que todos migrem para a próxima versão LTS 1.1.1 que tem suporte até setembro de 2023

Encontrei o problema, esta na propriedade AutoSize ao selecionar bcCode128C e incluir um código de barras com 44 caracteres ele esta definindo o Width para 286 porém desmarcando a opção AutoSize e definindo manualmente o Width para 289 a renderização ocorre corretamente

Vou reportar o erro no projeto Fortes Report CE, as vezes algum pequeno ajuste resolva o problema, mas de imediato acredito que incluindo uma diretiva para alterar o tipo de código de barras de bcCode128C para bcEAN128C quando a compilação for realizada no Linux resolva o problema

O PDF sai com o código exatamente da mesma forma que o gerado no form, acredito que o que vai para o PDF seja exatamente o mesmo bitmap gerado pelo componente de códigos de barras no form

Ola, você tem razão, ao usar xsLibXml2 quando tenta gerar a NFe ocorre 'ERRO: Access violation', usando a configuração conforme imagem anexa tudo funciona normalmente Vou dar uma olhada no código em relação ao uso da xsLibXml2, as vezes com alguns ajustes seja possível rodar no Linux com a Openssl 1.1

A alteração realizada no arquivo Fontes/ACBrOpenSSL/libxmlsec.pas Alterada a linha: LIBXMLSEC_SO = 'libxmlsec.so'; para: LIBXMLSEC_SO = {$IFNDEF MSWINDOWS}'libxmlsec1'{$ELSE}'libxmlsec.so'{$ENDIF}; Esta alteração esta gerando o erro abaixo ao tentar gerar/assinar o xml da NFe: ERRO: "xmlSecNodeSignature" could not be loaded from the dynamic library libxmlsec1 Uma solução paliativa para contornar o problema foi criar um link simbólico com o nome libxmlsec1 sem a extensão .so ln -s /usr/lib64/libxmlsec1.so.1 /usr/lib64/libxmlsec1 https://github.com/GabrielF7/ACBrTrunk2/commit/c49df5f71c32474ae5caa9b5b32e4485eca5ba5a#diff-315e5578b57ec7910d57ff00a15b02c2