Lucas de Freitas Roberto

Eu também estou tendo o problema "ERRO: Servico %s nao implementado para este provedor." ao executar NFSe.CancelarNFSe(..) Eu já atualizei o meu ACBr, já atualizei schemas, já fiz tudo que podia e ainda estou tendo este problema. Alguém já conseguiu fazer o cancelamento sem ter este erro?

31713032203005347000115000000000000825125815880645-nfse.xml

Boa tarde, Realizei a emissão de NFS-e no ambiente de homologação, porém não estou conseguindo identificar a chave/protocolo da autorização. Município: Viçosa No provedor anterior (eReceita), o protocolo era obtido normalmente através da propriedade: FACBrNFSeX.WebService.Emite.CodigoVerificacao. Entretanto, ao utilizar o Padrão Nacional, esse campo não está sendo preenchido. Poderiam, por gentileza, informar qual é a forma correta de obter o protocolo/código de verificação da NFS-e no Padrão Nacional? Desde já, agradeço.

Estou tento um erro na emissão de homologação para proPadraoNacional, e estou na versão 1.01 - LayoutNFSe := TLayoutNFSe.lnfsPadraoNacionalv101; Porem estou com este erro; 'Erro ao enviar NFSe: - Conteúdo do identificador informado na DPS difere da concatenação dos campos correspondentes. '. <DPS xmlns="http://www.sped.fazenda.gov.br/nfse" versao="1.01"> <infDPS Id="DPS317130320300534700011500900000000002293594"> <tpAmb>2</tpAmb> <dhEmi>2025-12-12T00:00:00-03:00</dhEmi> <verAplic>SistemaNacional</verAplic> <serie>900</serie> <nDPS>2293594</nDPS> <dCompet>2025-12-12</dCompet> <tpEmit>1</tpEmit> <cLocEmi>4314902</cLocEmi> <prest> <CNPJ>03005347000115</CNPJ> <IM>818</IM> <regTrib> <opSimpNac>1</opSimpNac> <regEspTrib>0</regEspTrib> </regTrib> </prest> <toma> <CPF>07873792633</CPF> <xNome>FREITAS</xNome> <end> <endNac> <cMun>3171303</cMun> <CEP>36570172</CEP> </endNac> <xLgr>RUA ALMEIDA RIBEIRO</xLgr> <nro>155</nro> <xBairro>CENTRO</xBairro> </end> </toma> <serv> <locPrest> <cLocPrestacao>3171303</cLocPrestacao> </locPrest> <cServ> <cTribNac>140201</cTribNac> <xDescServ>ANALISE DE DADOS</xDescServ> <cNBS>009700500</cNBS> </cServ> </serv> <valores> <vServPrest> <vServ>130.00</vServ> </vServPrest> <trib> <tribMun> <tribISSQN>1</tribISSQN> <tpRetISSQN>1</tpRetISSQN> </tribMun> <totTrib> <indTotTrib>0</indTotTrib> </totTrib> </trib> </valores> </infDPS> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#DPS317130320300534700011500900000000002293594"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>bh/bGQdlj3NE/tDfA3UTOlWTGtU=</DigestValue> </Reference> </SignedInfo> <SignatureValue>w0MeY9lwfChmivQKoCqEcoN301lVdyJK5KCU98OcdbDDig+JwjhgkYdl7S+N0FQTzoV+1EY6pbXbKELLvBJvhlfh1mkdgH4AGT/Ad5BvoTR5vKthGv5xgrcxqBrneXXM83uksGLhrZ00yfJpoiaxnSu8loNPdgm/sasMRfKJknrYlAdMFjLNe7oBouYsEeAGnXfvcnmgFJrTK7sbwqEBH9KyCaODYejlrQZXs+WHiK6NfNfIqePmqzXO9V84BzRUzEXpgeQ74IScl7ZhEaftn7b90yoh+grs+fnVco3yM4Oaek3SKkcWTsRafpEqyRvJdKUPlbPRwnoYRlJ9hghAug==</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>MIIH2DCCBcCgAwIBAgIIfLtDhOrxDRUwDQYJKoZIhvcNAQELBQAwdjELMAkGA1UEBhMCQlIxEzARBgNVBAoTCklDUC1CcmFzaWwxNjA0BgNVBAsTLVNlY3JldGFyaWEgZGEgUmVjZWl0YSBGZWRlcmFsIGRvIEJyYXNpbCAtIFJGQjEaMBgGA1UEAxMRQUMgU0FGRVdFQiBSRkIgdjUwHhcNMjUxMDA3MTc1OTUxWhcNMjYxMDA3MTc1OTUxWjCB8TELMAkGA1UEBhMCQlIxEzARBgNVBAoTCklDUC1CcmFzaWwxCzAJBgNVBAgTAk1HMQ8wDQYDVQQHEwZWSUNPU0ExNjA0BgNVBAsTLVNlY3JldGFyaWEgZGEgUmVjZWl0YSBGZWRlcmFsIGRvIEJyYXNpbCAtIFJGQjEWMBQGA1UECxMNUkZCIGUtQ05QSiBBMTEXMBUGA1UECxMOMTMwMzY1OTIwMDAxNDMxGTAXBgNVBAsTEHZpZGVvY29uZmVyZW5jaWExKzApBgNVBAMTIk9SSU9OIFNJU1RFTUFTIExUREE6MDMwMDUzNDcwMDAxMTUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDbp17HcWOqiIMK2Snnq54BZ6w7hzYsxVoiGYhUGbe0CsBrnTFjuhjYqtrI5z/fxwR319BAFU2fxJGBjhYFfJj1973nNPdvBnRUOMbmXXzxPnV2A0ETiw91kio+7HcgaRP2s2PCluMP5LTwHfla36696NkyTi2ogksEw6CNXrG3GuCnvRNcjCrnw76Dy+ouDv7pq/Zp6BzJFFn+xxig35UfneD/IESKZ3gyG77sMo+wQy93h0+tyQTu/LNe2YwkG67XMQX+8nvGIrJjoOmwbCUkELV5WkZyr19pJ1wVKLvJvQc02FX1WpEI84ucnFXfmK3wYo/Hv9QgJ4Ip+QdGXcIhAgMBAAGjggLsMIIC6DAfBgNVHSMEGDAWgBQpXkvVRky7/hanY8EdxCby3djzBTAOBgNVHQ8BAf8EBAMCBeAwaQYDVR0gBGIwYDBeBgZgTAECATMwVDBSBggrBgEFBQcCARZGaHR0cDovL3JlcG9zaXRvcmlvLmFjc2FmZXdlYi5jb20uYnIvYWMtc2FmZXdlYnJmYi9kcGMtYWNzYWZld2VicmZiLnBkZjCBrgYDVR0fBIGmMIGjME+gTaBLhklodHRwOi8vcmVwb3NpdG9yaW8uYWNzYWZld2ViLmNvbS5ici9hYy1zYWZld2VicmZiL2xjci1hYy1zYWZld2VicmZidjUuY3JsMFCgTqBMhkpodHRwOi8vcmVwb3NpdG9yaW8yLmFjc2FmZXdlYi5jb20uYnIvYWMtc2FmZXdlYnJmYi9sY3ItYWMtc2FmZXdlYnJmYnY1LmNybDCBtwYIKwYBBQUHAQEEgaowgacwUQYIKwYBBQUHMAKGRWh0dHA6Ly9yZXBvc2l0b3Jpby5hY3NhZmV3ZWIuY29tLmJyL2FjLXNhZmV3ZWJyZmIvYWMtc2FmZXdlYnJmYnY1LnA3YjBSBggrBgEFBQcwAoZGaHR0cDovL3JlcG9zaXRvcmlvMi5hY3NhZmV3ZWIuY29tLmJyL2FjLXNhZmV3ZWJyZmIvYWMtc2FmZXdlYnJmYnY1LnA3YjCBtAYDVR0RBIGsMIGpgRVFVVRFUkBPUklPTlRFQy5DT00uQlKgIgYFYEwBAwKgGRMXQU5UT05JTyBMQVpBUk8gTU9OVEFOSEGgGQYFYEwBAwOgEBMOMDMwMDUzNDcwMDAxMTWgOAYFYEwBAwSgLxMtMjMxMTE5NjI1MTQ3OTM5NzY4NzAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwoBcGBWBMAQMHoA4TDDAwMDAwMDAwMDAwMDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIwADANBgkqhkiG9w0BAQsFAAOCAgEAWQru9afWO1AdOVnErthU8WSpAUu2Fpy3ybb/lqsjfj9Y29QGbFdF/4n+UvjR9ItI0XKZmuBoMQr2NSq/taGeC9fQgFtaczhxBrg02hI93c6H6iVxCthY6Np5MpY03Vsa7MK4i820LWMsmUyd6OPlbt2FCpTwICfw1kN1BBuWGjjqwEHNj0TGZ7jid4QHVPEf+Y6KHGqEG9n3+yFWRQzL4EZHu+qQC6I+rWsxC2Hy6F2pK6gRxxlvztZeVXQC/ELhD2hEsHH5yI4Cr/WjxH6ggR6mveX1Wx3wPs2HGtMeDGt77Qumx3U5i8/xIBrECG1NKO01Eat5S3LRwobbe2ZoFElI2238HYiIIb91U5JIEq9THKkaJiaJv84Bucn0c0i4RlSQZe4J0ZpEPk5LWd/+65BYdx3RhWoJIUWcS/zmgIaLTgECT9tvgKyV1d+fM8CGNTWRJpdxlrtDPQ9MqKP69+mU3GlDRzY+uZ952i6rIromWq+ikKvYiCXh/+BGBs1bDaj1+k5iMtSiHn0EqfAF/s1FaX6y6YfkiLuQm5Bk3I0Nx3xClaItZKU6mlURLG2tpvgx25kaz23j2Y6THnhcQY6kaTakSh+i8DNI9iYxtN8XanIBybwURHWdH0vrP7U3tZOZFcWuVPKIQRgRGcuypUIuKdAC1rEXSro+gKfqm0U=</X509Certificate> </X509Data> </KeyInfo> </Signature> </DPS> 2293554-rps.xml

Estou sim, atualizei hoje

Bom dia, estou tento um erro na emissão de homologação para proPadraoNacional 'Erro ao enviar NFSe: - Conteúdo do identificador informado na DPS difere da concatenação dos campos correspondentes. '. Alguém consegue da essa força ?

Como e feita esta verificação ? estou com um problema parecido por aqui; Atualmente e : [3171303] Nome=Vicosa UF=MG Provedor=eReceita Versao=2.02 ProRecepcionar=https://webservice.ereceita.net.br/ws/vicosa/wsProducao.php HomRecepcionar=https://www3.ereceita.net.br/ws/vicosa/wsHomologacao.php ProLinkURL=https://server21.vicosa.mg.gov.br/nfse/VisualizarXMLdaNota.aspx?Prestador=&Numero=%NumeroNFSe%&Codigo=%CodVerif%&page=default.aspx&origin=ConAut&pdf=true HomLinkURL=https://server21.vicosa.mg.gov.br/nfse/VisualizarXMLdaNota.aspx?Prestador=&Numero=%NumeroNFSe%&Codigo=%CodVerif%&page=default.aspx&origin=ConAut&pdf=true Porem eu configurei para: [3171303] Nome=Vicosa UF=MG Provedor=PadraoNacional para poder testar antes de virar; Como e feito esta verificação ?

Pessoal, boa tarde! Estou com uma dúvida sobre a futura migração do município de Viçosa/MG (IBGE 3171303) do provedor eReceita para o Padrão Nacional na emissão de NFSe usando o ACBrNFSe. Atualmente está funcionando normalmente com o provedor eReceita, com o INI assim: [3171303] Nome=Vicosa UF=MG Provedor=eReceita Versao=2.02 ProRecepcionar=https://webservice.ereceita.net.br/ws/vicosa/wsProducao.php HomRecepcionar=https://www3.ereceita.net.br/ws/vicosa/wsHomologacao.php ProLinkURL=https://server21.vicosa.mg.gov.br/nfse/VisualizarXMLdaNota.aspx?Prestador=&Numero=%NumeroNFSe%&Codigo=%CodVerif%&page=default.aspx&origin=ConAut&pdf=true HomLinkURL=https://server21.vicosa.mg.gov.br/nfse/VisualizarXMLdaNota.aspx?Prestador=&Numero=%NumeroNFSe%&Codigo=%CodVerif%&page=default.aspx&origin=ConAut&pdf=true Minha dúvida é: quando o provedor migrar para o Padrão Nacional, eu conseguiria realizar testes apenas ajustando o INI, trocando: Provedor=PadraoNacional Ou seja, ficando: [3171303] Nome=Vicosa UF=MG Provedor=PadraoNacional O problema é que, ao fazer essa troca “forçada” no INI, no método de envio o ModoEnvio acaba caindo no meUnitario (no else) e eu recebo erro de: Erro ao enviar NFSe: - Falha Schema Xml Tenho esse trecho no envio: case EmiteResponse.ModoEnvio of meLoteAssincrono: begin AService := CriarServiceClient(tmRecepcionar); AService.Prefixo := EmiteResponse.NumeroLote; EmiteResponse.ArquivoRetorno := AService.Recepcionar(ConfigMsgDados.DadosCabecalho, EmiteResponse.ArquivoEnvio); end; meTeste: begin AService := CriarServiceClient(tmTeste); AService.Prefixo := EmiteResponse.NumeroLote; EmiteResponse.ArquivoRetorno := AService.TesteEnvio(ConfigMsgDados.DadosCabecalho, EmiteResponse.ArquivoEnvio); end; meLoteSincrono: begin AService := CriarServiceClient(tmRecepcionarSincrono); AService.Prefixo := EmiteResponse.NumeroLote; EmiteResponse.ArquivoRetorno := AService.RecepcionarSincrono(ConfigMsgDados.DadosCabecalho, EmiteResponse.ArquivoEnvio); end; else // meUnitario begin AService := CriarServiceClient(tmGerar); AService.Prefixo := EmiteResponse.NumeroLote; EmiteResponse.ArquivoRetorno := AService.GerarNFSe(ConfigMsgDados.DadosCabecalho, EmiteResponse.ArquivoEnvio); EmiteResponse.HtmlRetorno := AService.HtmlRetorno; end; end; Além disso, se tento usar outros modos, em alguns casos recebo: “Serviço Recepcionar Síncrono não implementado para este provedor.” Então minhas dúvidas são: É válido tentar testar a migração para o Padrão Nacional apenas trocando Provedor=PadraoNacional no INI, mesmo que atualmente o município ainda esteja com eReceita? Ou isso inevitavelmente vai gerar falha de schema/serviços por serem layouts e endpoints diferentes? Qual seria o procedimento correto no ACBr para testar/ajustar essa migração? Existe alguma forma de validar apenas a geração do XML do Padrão Nacional (ex.: validar schema local) sem “quebrar” a integração atual que está funcionando com eReceita? Para Viçosa/MG, o ACBr já possui mapeamento/implementação pronta do Padrão Nacional (URLs, métodos e operações), ou isso depende de disponibilização oficial do município/provedor?

Boa tarde, Município: Viçosa/MG Provedor : eReceita Contexto: o município iniciará migração obrigatória e que a emissão passará a ser exclusivamente no Padrão Nacional a partir de 01/01/2026, com o portal eReceita ficando para consulta/histórico. Fonte: https://primeiroasaber.com.br/2025/11/03/vicosa-inicia-migracao-obrigatoria-para-nota-fiscal-de-servico-eletronica-no-padrao-nacional/ Necessidade: preparar/testar no ACBr o fluxo do Padrão Nacional (ambiente de testes / Produção Restrita) para contribuintes de Viçosa. Dúvida/solicitação: Existe alguma orientação/configuração recomendada no ACBrNFSeX para forçar Padrão Nacional (sem resolver automaticamente por município via ACBrNFSeXServicos.ini)? Há algum checklist de campos/fluxos específicos (DPS, autorização, consulta, cancelamento) já implementados e prontos para uso? o ACBr pretende manter eReceita apenas para consulta/legado e indicar o Nacional como caminho principal? Acompanhamento de adesões oficial (dashboard): https://www.gov.br/nfse/pt-br/municipios/monitoramento-adesoes https://app.powerbi.com/view?r=eyJrIjoiNGQ4YTcxNmMtMzdhNC00Mzc5LTllM2EtMjY1MTM3NWQyZDgyIiwidCI6IjZmNDlhYTQzLTgyMmEtNGMyMC05NjcwLWRiNzcwMGJmMWViMCJ9&pageName=608609c2e0a53d7a3c6e Alteração realizada no arquivo ACBrNFSeXServicosRTC.ini

Obrigado

Bom dia, Houve alguma modificação no Projeto Manifesto Eletrônico de Documentos Fiscais na nova Nota Técnica 2025.001 v1.03 (Versão 1.03 – agosto de 2025) ?

SOAP-ENV:Server - Class 'NFSeServer\versao_202\GerarNfse' not found Pois é. Recentemente, o provedor da Futurize realizou a troca de servidor, porém não estou conseguindo contato com eles. Mais alguém também está enfrentando problemas com a Futurize?

Retorno deles <?xml version="1.0" encoding="UTF-8"?>'#$A'<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body><SOAP-ENV:Fault><faultcode>SOAP-ENV:Server</faultcode><faultstring>Class ''NFSeServer\versao_202\GerarNfse'' not found</faultstring></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>

Boa tarde, Alguém poderia auxiliar nesta questão relacionada à troca de servidores do Futurize, considerando o erro informado acima?

Boa tarde, pessoal! Estou enfrentando um problema com o provedor Futurize após a troca de servidor realizada hoje. A comunicação está funcionando apenas através do método síncrono, porém, ao realizar a requisição, é retornada a seguinte mensagem de erro: Erro E238: O parâmetro nomeado (método) informado não existe – consulte o manual da NFS-e para saber quais são os métodos disponíveis. Abaixo seguem os dados da cidade configurada: [3155801] Nome=Rio Pomba UF=MG Provedor=Futurize Versão=2.02 ProRecepcionar=https://riopombamg.futurize-nfse.com.br/webservice/prod HomRecepcionar=https://riopombamg.futurize-nfse.com.br/webservice/homo Caso alguém tenha passado por algo semelhante ou saiba de alguma atualização recente necessária para esse provedor, agradeço qualquer orientação!

O parâmetro nomeado (método) informado não existe Erro E238: O parâmetro nomeado (método) informado não existe - Consulte o Manual da NFS-e para saber quais são os métodos disponíveis.

Boa tarde, Gostaria de saber se existe alguma previsão para que essa modificação, permitindo o uso direto do certificado A1 (.pfx) na comunicação via API/WebService no ACBrBoleto, seja incorporada oficialmente. Estou avaliando essa possibilidade para resolver problemas de autenticação que ainda estou enfrentando. No momento, ao tentar autenticar com a API do Sicoob, estou tento alguns problemas. Falha na Autenticação: HTTP_Code=500 Erro=client_id=06a662d3-9a60-424c-b0c1-69ec7106756c &scope=boletos_inclusao boletos_consulta boletos_alteracao &grant_type=client_credentials Além disso, precisei alterar algumas configurações de segurança para conseguir avançar na comunicação. Estava utilizando cryOpenSSL, mas mesmo com as DLLs libssl-1_1 e libcrypto-1_1 na pasta correta, não conseguia a conexão

Boa tarde, pessoal. Estou com uma dúvida em relação à utilização de certificados digitais na integração via WebService com o ACBrBoleto, em especifico na nova versão do Sicoob V3. Vi diversos exemplos (como neste tópico: https://projetoacbr.com.br/forum/topic/57991-acbrboleto-via-webservice/#comment-465974) onde a comunicação é feita utilizando SSLCryptLib := cryOpenSSL, passando os arquivos: ACBrBoleto.Configuracoes.WebService.ArquivoCRT := 'caminho\cert.crt'; ACBrBoleto.Configuracoes.WebService.ArquivoKEY := 'caminho\chave.key'; Porem existem as propriedades:ACBrBoleto.Configuracoes.WebService.CertTipo := tpcA1; ACBrBoleto.Configuracoes.WebService.Certificado := '...'; ACBrBoleto.Configuracoes.WebService.CertTipo := tpcA1; ACBrBoleto.Configuracoes.WebService.Certificado := '...'; Minha dúvida é: É possível realizar a comunicação diretamente com o certificado digital no formato .PFX, preenchendo apenas as propriedades correspondentes (ArquivoPFX, Senha, etc), sem a necessidade de extrair os arquivos .CRT e .KEY? Se sim, quais seriam as configurações corretas nesse cenário? E há alguma limitação em relação ao uso com determinados bancos (como Banco do Brasil, Sicoob, etc)? Agradeço desde já pela atenção! Att.,

Olá, @EliasCesar Agradeço pelo retorno! Tenho interesse na implementação de pagamentos via API para o Sicoob, pois é uma demanda estratégica para nosso projeto. Vou verificar a disponibilidade da documentação oficial da API do banco e, assim que possível, anexo aqui no tópico para avaliação. Caso já haja alguma diretriz ou modelo ideal para facilitar a integração com o ACBrPagamentosAPI, fico à disposição para seguir e colaborar da melhor forma possível. E obrigado.

Boa tarde, Existe alguma previsão para a disponibilização da implementação de pagamentos para outros bancos via API utilizando o ACBrPagamentosAPI? Recentemente, tivemos a disponibilidade do ACBrPagamentosAPIBB. TOP ! Gostaria de saber, apenas para nível estratégico, se há alguma estimativa para a liberação de algum outro banco. Desde já, agradeço pela atenção.