Gabriel Kissel

Boa tarde pessoal, O erro [E0696 - A assinatura deve ser feita com o certificado digital do emitente da DPS.] está sendo retornado, sempre que tento emitir NFSe da loja filial, CNPJ final 0002. As NFSes emitem normalmente quando utilizado o CNPJ da Matriz final 0001. O certificado digital A1 em uso é o mesmo para os 2 CNPJs, e está registrado para o CNPJ matriz. Já revisei o tópico abaixo, mas pelo que verifiquei não se trata do mesmo problema. Dados de PIS/Cofins não estão sendo enviados nem no XML da Matriz, nem no XML da Filial. Comparei o XML gerados pelos 2 CNPJs, ele é idêntico, mudando apenas os campos de número da NFSe, horário, CNPJ do emitente, a chave gerada, e as tags de assinatura. Abaixo os 2 XMLs, o 1º da matriz que emite, e o 2º da filial que dá a rejeição: Alguém pode ajudar?

Boa tarde, em anexo alteração no ACBrPIXCD.pas, que permite alterar o conteúdo do ReqBody antes de enviar a requisição PIX Antes: TACBrQuandoTransmitirHttp = procedure(var AURL: String; var AMethod: String; ReqHeaders: TStrings; ReqBody: AnsiString) of object; Depois: TACBrQuandoTransmitirHttp = procedure(var AURL: String; var AMethod: String; const ReqHeaders: TStrings; var ReqBody: AnsiString) of object; ACBrPIXCD.pas

Boa tarde, Ítalo, O problema é justamente na última versão, que contêm a linha para remover o prefixo s: Quando não tinha essa linha (antes de 27/06) gerava o XML sem alterações. O problema é que ele faz o replace no XML inteiro, incluindo nos campos de dados, como a discriminação do serviço. Pensei nas seguintes soluções: -Via código mesmo, colocar para não usar essa linha do replace se o provedor for BHISS -Configurável no INI, da mesma forma que tem agora para o E comercial. -Alguma forma de ele fazer o replace apenas na parte do envelope SOAP, e não no XML inteiro (não sei se tem como fazer isso).

Italo, bom dia, Testei com a última versão, a princípio tudo ok 100% com o provedor BHISS, tanto na emissão como cancelamento. Apenas aproveitando, já que havíamos comentado na parte da alteração do XML original, quanto ao e comercial, quebra de linha, e "s:", encontrei uma alteração na unit pnfsConversao, function RetirarPrefixos, de 27/06/2018, que inclui o tratamento para retirar o "s:" do XML. Acredito que para o provedor BHISS (não sei dizer se algum outros provedores também), poderia haver um tratamento para não fazer o replace (não sei se o correto é fazer isso no código, ou configurável no .ini, assim como as regras do e comercial e outros). Obrigado.

Bom dia, Ao testar com essa unit no provedor BHISS voltou a cancelar a NFSe voltando para a unit original, volta o erro de arquivo enviado com erro na assinatura.

Italo, bom dia! Atualizei os componentes, pasta de INI de provedores, e pasta Schemas. Ficou resolvida a questão da quebra de linha no bloco da assinatura, e do e comercial. Vi que agora existe configuração no Ini do provedor para isso. Notei que ele remove dentro do XML, os caracteres "s:" que tenham no arquivo (na versão antiga não removia). Talvez esteja confundindo com alguma tag do XML. De qualquer forma, gerei uma NFS-e sem a ocorrência de "s:" ou seja, sem diferenças de geração na nova e na velha versão. Mesmo o XML estando sem diferenças, continua o erro da prefeitura na hora do cancelamento. A principio a única alteração no pedido de cancelamento está no DigestValue e no SignatureValue 201800000000043UNICA-nfse versao nova sem o s.XML 201800000000044-ped-can versao antiga cancelando.xml 201800000000044-ped-can versao nova erro.xml 201800000000044-ped-can-soap versao antiga cancelando.xml 201800000000044-ped-can-soap versao nova erro.xml 201800000000043UNICA-nfse versao antiga com o s.XML

Italo, boa tarde, Abaixo o XML gerado pelo método ConsultarNFSe (que basicamente pega o XML da prefeitura e salva em disco). Pode se ver que o caracter & é alterado nos dois XML, assim como o bloco da assinatura, que quebra linha na versão nova. Ambos os testes estão usando via OpenSSL, os ois estão usando a mesma versão de Schemas, e mesma versão de arquivos INI de configuração do componente. Como a assinatura do evento de cancelamento usa o XML original, acredito que esteja aí o problema, pois no XML de pedido de cancelamento não existem alterações substanciais (tirando o hash e a assinatura, que sempre vai gerar diferente mesmo se o XML for igual). A versão nova está usando o componente atual, enquanto a antiga (que funciona), são do período entre 06/2018 e 08/2018 aproximadamente. 1899123018991230-lista-nfse (versao nova com erro).xml 1899123018991230-lista-nfse-soap (versao nova com erro).xml 201800000000042UNICA-nfse (versao nova com erro).XML 1899123018991230-lista-nfse (versao old funcionando).xml 1899123018991230-lista-nfse-soap (versao old funcionando).xml 201800000000042UNICA-nfse (versao old funcionando).XML

Boa tarde, Também estou com este mesmo problema, apenas no cancelamento de NFS-e, cidade de Porto Alegre, provedor BHISS, em versões anteriores, compiladas com componente ACBr antigo, cancela normalmente. Ao comparar os XML gerados pela versão nova, e gerados pela versão antiga, notei que na versão antiga (que funciona), o XML é salvo em disco em uma única linha. Já na versão nova, os blocos SignatureValue e X509Certificate quebram a linha, a cada 76 caracteres (Caracter LF). Também notei diferença na conversão do carácter especial & (E comercial), novo & e antigo &

Henrique, boa tarde, Qual o contato que tens do suporte da Pronim? A cidade de Triunfo/RS também atualizou para a versão 2.03, mas apenas alterar os dados do XML não adianta. Acredito que possa ser um problema no provedor dessa cidade, pq o mesmo xml que não valida, testei enviar para o link de Pato Branco e deu certo (passou pelas validações das versões)

Bom dia! Conforme a mesma NT, página 53, o campo CNPJ é opcional Também pela mesma NT, a validação para ver se o CNPJ está preenchido e se a forma de pagamento é Cartão de Crédito ou Débito, essa validação é opcional por UF. Seguem abaixo NFC-e emitidas e validadas (UF RS), que permite o CNPJ vazio, e forma de pagamento diferente de 03 (Cart. Crédito) ou 04 (Cart. Débito) 43180904544024000162651050000000911083060881-nfe.xml 43180904544024000162651050000000971085603568-nfe.xml 43180904544024000162651050000001071089841364-nfe.xml

Boa tarde, Notamos que o componente estava validando para apenas gerar o bloco de cartão no XML da NFC-e, se o CNPJ estivesse preenchido, e o tipo de pagamento fosse Cartão de Crédito ou Débito. Identificamos que o campo CNPJ é opcional, assim como no tipo de pagamento, aceita outras formas além de Cartão de Crédito e de Débito. Segue unit alterada com as correções. pcnNFeW.pas

Boa tarde Italo, Em qual seção/tag do ini do provedor é definido se o conteúdo é text/html ou text/xml?

Bom dia! Até pouco tempo atrás, havia deixado funcionando a NFS-e para a cidade de Sarandi/RS, que usa o provedor SafeWeb. Andou tendo umas instabilidades no provedor, que durou umas semanas, afetando tanto a emissão direta pelo aplicativo da SafeWeb, como via ACBr. Quando o provedor voltou, foi necessária atualização no aplicativo da SafeWeb. Já via componente ACBr, não voltou a funcionar, ao utilizar o comando ACBrNFSe1.Enviar(), retorna o seguinte except: Erro: Erro Interno: 0 Erro HTTP: 0 Received content of invalid Content-Type setting: text/html - SOAP expects "text/xml" acredito que seja algo no xml de retorno, ou talvez no de envio que eu precise alterar algo. Na pasta somente grava os xml de envio, os de retorno nem chega a salvar.

Acabei esquecendo que essa alteração precisava ser feita também no ACBrNFSeDANFSeRLRetrato.lfm, como não uso Lazarus, acabei nem lembrando. A alteração é feita manual sempre quando se altera um DFM para LFM, ou existe outro meio?

Boa tarde! Segue alteração no DANFS-e em Fortes, para exibir o Intermediario do Serviço (Nome, CPF/CNPJ e IM) quando existente. Foi ajustada também a parte da impressão da Construção Civil, quando não existiam os mesmos, os componentes eram deixados invisíveis, mas o espaço que eles ficavam continuava, ficando um espaço em branco sem uso. A rotina verifica a presença do Intermediário e/ou da Construção Civil, e sobe os demais itens para evitar espaço sem nada impresso. ACBrNFSeDANFSeRLRetrato.dfm ACBrNFSeDANFSeRLRetrato.pas

Boa tarde, Italo, Estava fazendo outros testes, vi que no provedor Betha, acontece o mesmo comportamento, assim como no provedor BHISS, ao usar OpenSSL + xsXmlSec. Possivelmente este provedor também requer assinatura nos RPS's e no lote. Acredita que é viável eu ajustar o xsXmlSec para conseguir assinar tanto o lote como os RPSs, ou é trabalho desnecessário, já que o xsMsXml já está preparado para assinar corretamente nestes casos?

Prezados, boa tarde! Estamos tentando fazer funcionar a emissão/cancelamento de NFS-e para Porto Alegre/RS (provedor BHISS) através da libOpenSSL/xsXmlSec (com certificado A1). Hoje funciona já 100% através das libs: libCapicom, libCapicomDelphiSoap e libWinCrypt. Ao utilizar o libOpenSSL, acontece as seguintes situações: -Ao emitir [ método ACBrNFSe1.Gerar(); ] retorna o erro "Falha ao localizar o nó de Assinatura" -Ao cancelar [ método ACBrNFSe1.CancelarNFSe(); ] retorna o erro "Falha ao Assinar - Cancelar NFS-e: Erro -1: Falha ao assinar o Documento strdup function failed." Em ambos os casos (gerar e cancelar) gera exceção internamente no componente na unit ACBrDFeXsLibXml2 na function TDFeSSLXmlSignLibXml2.LibXmlFindSignatureNode e também no cancelamento, gera exceção internamente na unit ACBrDFeXsXmlSec na function function TDFeSSLXmlSignXmlSec.XmlSecSign Ao alterar a propriedade SSLXmlSignLib para xsLibXml2, alteram-se as mensagens de erro, tanto ao gerar como ao cancelar. Erros "Arquivo enviado com erro na assinatura" e "Nenhum elemento encontrado" respectivamente. Ao alterar a propriedade SSLXmlSignLib para xsMsXml, aparentemente funciona, nunca usamos esta propriedade, existe alguma particularidade para ela? Ela exige Capicom? Quais as diferenças dela para a xsXmlSec que vem default ao selecionar libOpenSSL? Este mesmo arquivo de certificado, é usado sem problemas em OpenSSL/xsXmlSec para emissão de NF-e e NFC-e no componente ACBrNFe, assim como já usamos o componente ACBrNFSe com libOpenSSL/xsXmlSec sem problemas (com outro certificado e outra cidade/provedor - DBSeller). Acredito ser algo que a combinação OpenSSL + xsXmlSec + provedor BHISS esteja causando isso, sendo isso, gostaria de umas dicas sobre o que eu posso alterar para poder fazer esta combinação funcionar. Obrigado.

Bom dia! Segue em anexo alteração feita em ACBrNFeDANFeRLClass.pas para a impressão do DANF-e em Fortes, considerar corretamente a propriedade PosCanhoto e imprimir no rodapé quando assim configurado. Removidas as propriedades de ACBrNFeDANFeRLClass.pas que já existiam em ACBrNFeDANFEClass.pas ACBrNFeDANFeRLClass.pas

Italo, boa tarde, Segue alteração no pnfsNFSeR.pas, para o provedor Pronimv2, passa a fazer a leitura correta da retenção de ISS (LerNFSe_ABRASF_V1 e LerRPS_ABRASF_V1) e também no LerRPS_ABRASF_V1 passa a calcular o valor líquido e base de cálculo corretamente, que nem no LerNFSe_ABRASF_V1 Atenciosamente. pnfsNFSeR.pas

Boa tarde a todos. Seguem alterações nos fontes e inis da nfse, para serem incluídos no repositório: -Cidades.ini e DBSeller.ini: Alteração para o DBSeller suportar a cidades com https (Sapiranga/RS) -ACBrNFSeWebServices.pas: Libera sem Inscrição Municipal no provedor Betha em produção -pnfsNFSeG.pas: Não gera tag se a I.M. estiver em branco (provedor Betha) Atenciosamente. ACBrNFSeWebServices.pas Cidades.ini DBSeller.ini pnfsNFSeG.pas

Boa tarde. Segue em anexo, alterações nos .ini da NFS-e, com as seguintes alterações, para serem incluídos no repositório: -Inclusão cidade Caçapava do Sul/RS (Pronim) -Inclusão cidade Nova Petrópolis/RS (Pronimv2) -Alteração do provedor da cidade Três Coroas/RS de GovBR para Pronim Atenciosamente. Pronim.ini Pronimv2.ini Cidades.ini

Boa tarde a todos. Referente às mesmas alterações acima, segue alteração na unit pnfsConversao.pas, para que possa ser incluído no repositório, sem perda das demais alterações. Obrigado. pnfsConversao.pas

Boa tarde a todos. Segue em anexo alterações nas units referentes aos componentes Danfs-e / Fortes, com as seguintes alterações: pnfsConversao.pas -função ExigibilidadeISSDescricao - retorna o código antes da descrição, mantendo o padrão ACBrNFSeDANFSeClass.pas -nova propriedade boolean ImprimeSerieRps ACBrNFSeDANFSeRL.pas e ACBrNFSeDANFSeRLClass.pas -inclusão dos parametros ImprimeCanhoto e ImprimeSerieRps ACBrNFSeDANFSeRLRetrato.pas -ocultar canhoto conforme propriedade ImprimeCanhoto -Texto do canhoto - melhorias e ajustes no texto impresso -campo município da prestação - exibe o cód ibge, mantendo o mesmo padrão que o município do prestador e do tomador -campo número do RPS - exibe a série da RPS, conforme campo ImprimeSerieRps -Competência - incluido o dia do mês na data ACBrNFSeDANFSeClass.pas ACBrNFSeDANFSeRL.pas ACBrNFSeDANFSeRLClass.pas ACBrNFSeDANFSeRLRetrato.pas pnfsConversao.pas

Bom dia a todos. Seguem correções nos .ini referentes ao provedor DBSeller, referentes a montagem do NameSpace e da URL, para cidades que fogem do padrão. Cidades.ini DBSeller.ini

Bom dia a todos. Precisei incluir nos INIs do componente NFS-e, as cidades de Taquari/RS e de Charqueadas/RS, ambas do provedor DBSeller. Também foi necessária uma pequena alteração, pois a URL do WebService homologação da cidade de Taquari, foge do padrão (ao invés de "nfse.nomecidade" é "nfse-homologa.nomecidade"). Seguem os .ini com as alterações. Att. Cidades.ini DBSeller.ini