DatawebDev

Obrigado pela ajuda Juliomar! As DLL libeay32.dll e ssleay32.dll está na versão 1.0.2.21. Configurei as libs de acordo com as configurações padrão do ACBrNFSeX_Exemplo, quando se altera a SSLLib para libWinCrypt: ACBrNfseX1.Configuracoes.Geral.SSLLib := libWinCrypt; ACBrNfseX1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; ACBrNfseX1.Configuracoes.Geral.SSLHttpLib := httpWinHttp; ACBrNfseX1.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; Nenhum desses usa os *OpenSSL. Mesmo assim a versão do OpenSSL interfere?

Funcionou Italo! Seguindo essa abordagem, achas necessário criar um param extra no provedor (ex.: Param=SoapDadosMsgCdata:), para setar somente para POA/RS? Ou faço a alteração para todos os provedores? Verifiquei no arquivo INI, e esse provedor é usado por Porto Alegre/RS e Belo Horizonte/MG.

Italo, após configurar WinCrypt + LibXml2, e configurar o certificado digital pelo seu número de série, quando chamo o método ACBrNFSeX.Emitir(), ele dispara duas Exception seguidas com a mensagem "CryptExportKey - len", e em seguida dispara o erro abaixo. Com CAPICOM não temos esse erro, somente o problema de assinar XML que já contenha um campo <Signature> interno. Já corrigimos esse problema no arquivo anexado. Poderiam reconsiderar nossa proposta de alteração?

Oi @Italo Giurizzato Junior, obrigado por responder rapidamente. Usamos OpenSSL+LIBXML2 na maioria dos clientes, quando podemos carregar o arquivo do certificado digital. Essa combinação de CAPICOM+MSXML é usada em alguns clientes que ainda tem certificado digital em dongle USB ou smartcard, e precisa instalá-lo na certstore do Windows, para ser obtido pelo número de série.

Obrigado pelo retorno rápido pessoal! Perdão se não fui claro... Diego, esse tratamento de escape está funcionando corretamente, na composição do XML do <GerarNfseEnvio>. O problema é na composição do SOAP envelope, onde esse XML é escapado (ou melhor dizendo, codificado) novamente, convertendo os "<" e ">" em "&lt;" e "&gt;", mas não convertendo o "&" em "&amp;". Minha alteração adiciona essa conversão do "&amp;" no XML do GerarNfseEnvio escapado, que fica contido na tag <nfseDadosMsg> do <soapenv:Body>. É ao compor o XML do SOAP envelope, conforme descrevi acima. Eis um exemplo de dois XML GerarNfseRequest, de um RPS com discriminação do serviço "TREINAMENTO P&D". O XML da esquerda foi gerado com a minha correção. O XML da direita foi gerado sem ela. Quando o webservice tenta decodificar o XML da direita, ele converte o "&amp;" para "&", e o parser do XML interpreta aquele "&" como se fosse o início de uma sequência de escape do XML (ex.: &nbsp;), mas na verdade é só o &.

Prezados boa tarde. Ao enviar um lote de RPS para prefeitura de Porto Alegre/RS, onde a razão social do tomador contém "&" (E comercial), o webservice do provedor retorna o erro: <MensagemRetorno> <Codigo>0</Codigo> <Mensagem>Ocorreu um erro Inesperado. (Unexpected character ' ' (code 32) (missing name?) at [row,col {unknown-source}]: [1,882])</Mensagem> </MensagemRetorno> O problema aqui é que o conteúdo do campo <nfseDadosMsg> é escapado, onde os caracteres "<" e ">" são substituídos por "&lt;" e "&gt;", mas o caractere "&" não é escapado, e portanto causa erro na desserialização do XML no servidor. Encontramos um erro semelhante sendo reportado para o ACBrNFSe em 2014: Corrigimos o problema na unit BHISS.Provider.pas, em anexo. Para não afetar outros municípios (ex.: BH), deixamos retrocompatível com a introdução do param EscaparSoapDadosMsg, configurado no ACBrNFSeXServicos.ini (em anexo) para Porto Alegre/RS. Caso achem esse param desnecessário, e preferirem que o caractere & seja sempre escapado nesse provedor, me avisem que eu removo o param. Poderiam avaliar e integrar as alterações no trunk, por gentileza? ACBrNFSeXServicos.ini BHISS.Provider.pas

Prezados, bom dia. Ao tentar emitir NFSe em Porto Alegre/RS, usando o ACBrNFSeX com CAPICOM + MSXML, o webservice nos retorna o erro abaixo: Código: E175 Descrição: Lote sem assinatura. Como diz a mensagem, o problema está na assinatura do lote de RPS, que já contém um RPS assinado. O método TDFeSSLXmlSignMsXmlCapicom.Assinar() detecta que o XML já está assinado (por causa do RPS) e não assina o lote. Corrigi esse problema, na unit ACBrDFeXsMsXmlCapicom.pas em anexo. Agora o método Assinar() busca pelo <Signature> no XML, com base no elemento pai da assinatura. E se não encontra, cria o template e recarrega o XML. Testei com o provedor BHISS, e também com o SisPMJP, apesar do SisPMJP não assinar seu XML. Poderiam validar a alteração e incorporar no trunk, por favor? ACBrDFeXsMsXmlCapicom.pas

Prezados, boa tarde. No tópico abaixo, alteramos o SisPMJP para que não fosse gerada a tag ValorIss. Funcionou, prefeitura parou de rejeitar os RPS do nosso cliente de João Pessoa/PB. Essa alteração quebrou a emissão de NFSe para o @leonard.miranda, que corrigiu o seu problema no tópico abaixo. Nosso problema voltou depois disso. Pensando em uma alternativa que solucione ambos os casos, proponho a alteração em anexo, que passa a tratar o param NaoGerarTag:ValorIss para o provedor SisPMJP. Além disso, configurei o ACBrNFSeXServicos.ini, para que o município de João Pessoa/PB com esse param. Precisamos ver com o @leonard.miranda se o problema dele era em João Pessoa/PB ou outro município, porque se for em João Pessoa, a alteração proposta quebrará a emissão dele novamente. ACBrNFSeX-SisPMJP-ParamValorIss.patch SisPMJP.GravarXml.pas ACBrNFSeXServicos.ini

Prezados, boa tarde. Tive de alterar o método TNFSeW_Pronim202.GerarXml da unit Pronim.GravarXml.pas (em anexo), para resolver os erros E282 e E292, de um cliente de Vacaria/RS (4322509). Alterações foram baseadas na documentação do provedor, disponível em https://vacaria.rs.gov.br/nfse. Abaixo o código depois da alteração. Segue também no arquivo anexado. function TNFSeW_Pronim202.GerarXml: Boolean; const CODIGOMUNICIPIO_EXTERIOR = '9999999'; begin if NFSe.OptanteSimplesNacional = snSim then NrOcorrAliquota := 1; // Solução para o erro "Responsável/Retentor informado indevido. (E282)" quando ISSQN não é retido na fonte if NFSe.Servico.Valores.IssRetido <> stRetencao then NrOcorrRespRetencao := -1; // Solução para o erro "País do tomador do serviço indevido. (E292)" quando tomador não é estrangeiro if NFSe.Tomador.Endereco.CodigoMunicipio <> CODIGOMUNICIPIO_EXTERIOR then NrOcorrCodigoPaisTomador := -1; Result := inherited GerarXml; end; Poderiam incorporar nos fontes do ACBr, por gentileza? Pronim.GravarXml.pas

Desculpem a demora no retorno. Testei e funcionou! Muito obrigado pela solução.

Bom dia Italo! Desculpe a demora no retorno, estava ocupado. Testei tua solução e funcionou! Muito obrigado.

Muito obrigado @Italo Giurizzato Junior! Estou aguardando a solução de outro problema no ACBrNFSeX, descrito no tópico abaixo. Em seguida eu testo a alteração no SisPMJP e marco aqui como solucionado.

Obrigado pela rápida resposta Diego! Sobre manter o padrão dos outros DFe, usamos o ACBrNFe da mesma forma, com o INI em outro diretório (%APP_DIR%\ACBr\NFe\ACBrNFeServicos.ini), e configurando seu caminho após instanciar o componente. E nele não temos esse problema. Que tal manter o estado de "CidadesLidas" no ACBrNFSeX, e disparar exceção ao usuário, quando tentar usar um método que dependa das cidades, caso não tenha chamado o LerCidades()? A abordagem de chamar um método que dispara exceção no constructor pode acarretar em outros problemas também. Mas entendo a decisão de vocês, de tentar simplificar o processo.

Recentemente foi feita uma alteração em TACBrNFSeX, que passou a chamar seu método LerCidades() em seu constructor. Isso quebrou compatibilidade com a nossa integração, e gostaríamos que revisassem a abordagem, ou a necessidade de chamar LerCidades() ao instanciar o componente. O problema é que o LerCidades() depende da configuração do INI, feita em ACBrNFSeX.Configuracoes.Arquivos.IniServicos. Mas só se pode configurar o caminho para o arquivo INI depois de instanciar o componente. Na nossa aplicação, o INI fica em %APP_DIR%\ACBr\NFSeX\ACBrNFSeXServicos.ini, enquanto o executável fica em %APP_DIR%. Até então, instanciávamos o componente, configurávamos o caminho para o INI, e depois chamávamos explicitamente o método LerCidades(). Com a alteração recente, ao chamar TACBrNFSeX.Create(), é chamado LerCidades(), que tenta ler o INI do diretório do executável, e como não existe, tenta ler o arquivo ACBrNFSeXServicos.res, que também não existe, e acaba gerando o erro Resource ACBrNFSeXServicos not found Poderiam reconsiderar essa abordagem de chamar o LerCidades() na criação do componente? Com ela, a configuração ACBrNFSeX.Configuracoes.Arquivos.IniServicos fica sem utilidade, porque não será usada por LerCidades(), que sempre buscará o INI do diretório do executável. Se for indispensável chamar LerCidades() para algum caso, poderiam fazer um overload no constructor, implementando um Create() alternativo que não chame LerCidades()?

Prezados, boa tarde. Durante testes de emissão e cancelamento de NFSe, em um cliente de João Pessoa/PB, encontramos problemas no envio de RPS, e na leitura do XML de NFSe retornado pela prefeitura. No envio do RPS, ocorreram os erros "Formato percentual incorreto (L5)" e "Valor do ISSQN devido inválido (E164)".Resolvemos os problemas configurando o provedor, no método TNFSeW_SisPMJP202.Configuracao. No cancelamento de NFSe, nossa implementação importa o XML da NFSe a ser cancelada, para extrair os dados necessários no request de cancelamento, similar ao projeto de exemplo do ACBr. Isso funciona com os outros provedores que testamos, mas com o SisPMPJ não funcionou. Leitura do XML falha silenciosamente, sem disparar exceção, e também sem desserializar o XML no componente. Encontramos o problema, na detecção de tipo de leitura do XML, que estava interpretando o XML de NFSe como se fosse um RPS. Isso porque o XML retornado pela prefeitura é diferente (prefixa namespace "nfse") do padrão ABRASFv2 , esperado pela implementação do provedor no ACBrNFSeX. Resolvemos o problema implementando a detecção adequada no método TNFSeR_SisPMJP202.TipodeXMLLeitura. Segue em anexo os arquivos alterados, para que possam revisar e incorporar no código do ACBr. SisPMJP.GravarXml.pas SisPMJP.LerXml.pas

Boa tarde Victor. Esse XML foi extraído dos XML de comunicação com o web service, gerado pelo ACBr. Fomos nós quem salvamos em utf8-bom. Nas primeiras tentativas de carga do XML, salvamos com charset win1252, e depois utf8 (sem BOM), mas o método TNotasFiscais.LoadFromFile dava um erro de "charset desconhecido" em inglês, que esquecemos de capturar para relatar. Por fim testamos com charset utf8-bom, e então o método LoadFromFile parou de reclamar de charset explicitamente. Estávamos testando com ACBrTrunk2 atualizado até segunda-feira 27/03 (r25068). Atualizei os componentes do ACBr aqui, e consegui carregar os arquivos com charset win1252 e utf8, sem nenhum erro. Muito obrigado pela ajuda!

Ao tentar carregar XML de NFSe no componente, ocorre o erro Start tag expected, '<' not found. Consegui reproduzir no ACBrNFSeX_Exemplo, ao carregar o XML em anexo para Imprimir DANFSe. nfse.xml Poderiam me ajudar por gentileza?

Olá Italo! Desculpe a demora na resposta, só agora consegui testar as alterações. Consegui emitir NFSe pelo método GerarNFSe do provedor, usando a última versão do ACBrNFSeX. Muito obrigado pela correção! Porém precisei atualizar a URL de homologação no ACBrNFSeXServicos.ini. Peguei a URL atualizada no manual da prefeitura do Rio de Janeiro/RJ. Nova URL: https://notacariocahom.rio.gov.br/WSNacional/nfse.asmx Poderia atualizar nos fontes por gentileza?

Em nenhuma situação, nem na minha aplicação, e nem no TEFAPIDemo. Isso definitivamente seria um erro. Mais uma evidência de que deve ter sido um bug/estado errado no backend DEMO do Pay&Go, conforme sugerido por ti. Sair do evento, sem resolver a pendência, foi uma forma que encontrei para reproduzir o estado que eu tinha ao abrir o tópico. Não é a forma como funciona minha aplicação e nem o TEFAPIDemo. Outra forma de reproduzir seria: efetuar um pagamento; deixar ele pendente; fechar a aplicação; apagar o diretório de trabalho do componente; iniciar a aplicação; componente não terá mais seus backups, para detectar a pendência, e não chamará QuandoDetectarTransacaoPendente durante a inicialização. Não quis testar assim para não perder o diretório de trabalho. Posso sim, só vou demorar a ter tempo pra fazer isso.

Tentei reproduzir o problema no TEFAPIDemo, mas precisei alterar ele demais para que chegasse no estado de pendência do meu problema. Consegui reproduzir na minha aplicação, de forma consistente. O problema ocorre quando a pendência não é resolvida no evento QuandoDetectarTransacaoPendente, disparado no método Inicializar, e em seguida se chama o método LimparRespostasTEF. Mas o meu estado de erro original, que motivou a abertura esse tópico, não parece ter sido causado pela minha aplicação, e sim por algum estado de pendência errado no ambiente de testes do Pay&Go. Um detalhe que indica estado diferente no backend do Pay&Go é que, enquanto estava no estado de pendência, e tentávamos realizar um pagamento, o Pay&Go não retornava a rede autorizadora DEMO, que sempre usamos. Retornava somente ITI e REDE, como se pode ver nos logs da primeira postagem do tópico. Depois de desfeita a transação pendente, voltou a retornar a autorizadora DEMO, e segue retornando. Enquanto tentava reproduzir o problema no TEFAPIDemo, vi que o parâmetro MsgErro, do evento QuandoDetectarTransacaoPendente, retorna o NSU da transação pendente no backend do Pay&Go. Com isso, mais o tratamento que fizemos para desfazer esse tipo de pendência, e mais a explicação sobre o método LimparRespostasTEF e o ambiente de homologação, podemos encerrar esse tópico. Muito obrigado pela ajuda.

Obrigado pela resposta rápida @Daniel Simoes. Havia testado com a revision 24534 do SVN, e agora atualizei para a revision 24639 e testei novamente. Mesmo resultado. Sendo uma situação que só ocorre em homologação, tratarei esses casos na aplicação, desfazendo as transações pendentes desse tipo. Sobre essa dúvida: Esse estado de pendência pode ter sido causado por chamarmos LimparRespostasTEF() depois de chamar Inicializar()?

Usamos o ACBrTEFAPI sem confirmação automática, em uma nova aplicação nossa, ainda em fase de desenvolvimento. Ao tentar autorizar um pagamento em cartão de crédito, componente solicita seleção da Rede Autorizadora, depois pede cartão e senha. Em seguida o Pay&Go retorna TRANSACAO PENDENTE. Implementamos um tratamento de pendências no evento QuandoDetectarTransacaoPendente. Nossa aplicação espera que, durante a inicialização do componente, esse evento seja disparado, caso exista alguma transação pendente. Nesse caso, o componente inicializa, não detecta pendência (não dispara evento), e então aplicação prossegue com a autorização de pagamento. Depois do retorno de TRANSACAO PENDENTE do Pay&Go, componente dispara o evento QuandoDetectarTransacaoPendente, mas o parâmetro RespostaTEF, passado pelo evento, vem vazio. Em anexo o trecho do nosso event handler (TForm1.ACBrTEFAPI1QuandoDetectarTransacaoPendente.pas), escrevendo os dados de RespostaTEF para um arquivo texto, e o arquivo texto contendo os dados de RespostaTEF (dadostransacao.txt). Pelo que parece, o componente não conseguiu manter seu estado de "transação pendente" sincronizado com o Pay&Go, ou o ambiente de teste do Pay&Go está com algum problema, reportando pendência inexistente. Componente só dispararia o evento QuandoDetectarTransacaoPendente, na sua inicialização, quando tiver esse estado de pendência em seus arquivos temporários, correto? Método LimparRespostasTEF() limpa esse estado? Seguindo ACBrTEFAPI_Demo, estamos chamando LimparRespostasTEF() depois do método Inicializar(). Deveríamos fazer isso? Queria saber se esse estado de "pendência no Pay&Go", que não é detectada na inicialização do ACBrTEFAPI, é um bug no ambiente de testes do Pay&Go, ou se devemos tratar esse caso em produção. Se for para tratar, como devemos fazer? Com RespostaTEF retornando vazio, não temos como decidir se a transação deve ser confirmada ou desfeita. Deveríamos desfazer sempre? Em anexo os logs presentes nos diretórios de trabalho do componente e da PGWebLib.dll. Testei com a revision 24534 do ACBr (de 06/02/2022), e PGWebLib.dll v4.1.15.1 . Aplicação feita no Delphi 10.4. TForm1.ACBrTEFAPI1QuandoDetectarTransacaoPendente.pas dadostransacao.txt ACBRTEFAPI.log comms_220216.log ppsers_220216.log

Ao tentar emitir NFSe na prefeitura do Rio de Janeiro/RJ, usando ACBrNFSeX, encontramos dois erros: Serialização da alíquota de ISS ao enviar lote de RPS Web service espera que a alíquota seja uma fração de 1, mas o componente coloca em percentual, ao serializar o TNFSe para XML. Por causa disso, web service retorna erro E928: O valor da alíquota informada para o Código do Serviço Prestado (120801) deve ser superior(ou igual) a 2,00% e inferior (ou igual) a 5,00%. Corrigi esse erro, editando a unit ISSRio.GravarXml.pas. Em anexo a unit editada, e arquivos XML contendo exemplos de como estava antes da correção, e como ficou após. XML inválido em relação ao XSD do web service da prefeitura, ao gerar NFSe Mesmo com a solução do problema anterior no formato da alíquta, método GerarNFSe retorna o erro E160: The element 'Rps' in namespace 'http://notacarioca.rio.gov.br/WSNacional/XSD/1/nfse_pcrj_v01.xsd' has invalid child element 'InfRps' in namespace 'http://notacarioca.rio.gov.br/WSNacional/XSD/1/nfse_p. Testei com e sem a alteração que fiz para a alíquota. Para tentar resolver o problema, baixei a documentação de integração do site da prefeitura, e comparei o XML de exemplo do GerarNFSeEnvio com o gerado pelo componente (imagem abaixo). Notei que os namespaces estavam diferentes, além do XML do exemplo estar assinado, e o gerado pelo componente não estava assinado. Em anexo os arquivos XML gerados pelo componente, e o de exemplo. Tentei corrigir esse problema, mas não consegui. Poderiam me ajudar com esse erro no GerarNFSe? ISSRio.GravarXml.pas ACBrNFSeX-ISSRio-BugAliquotaIss.zip ACBrNFSeX-ISSRio-BugGerarNFSe.zip