Gabriel Kissel
-
Total de ítens
33 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Gabriel Kissel
-
-
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; -
35 minutos atrás, Italo Jurisato Junior disse:
Boa tarde Gabriel,
Você deve ter feito alguma alteração na pnfsConversao e o tortoise não esta atualizando ela.
Pois essa unit que se encontra no repositório já tem a linha para remover o prefixo s:
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).
-
18 horas atrás, Italo Jurisato Junior disse:
Boa tarde a todos,
Favor fazer uma copia dessa unit em seguida atualiza os fontes, reinstale os componentes e por fim façam novos testes.
Fiz um pouco diferente, espero que agora funcione.
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.
-
1
-
-
Em 14/12/2018 at 15:31, awendisch disse:
Boa tarde,
Atualizei os fontes hoje a tarde e comecei a receber o mesmo erro de assinatura inválida apenas ao cancelar NFSe..
Fiz a substituição da unit ACBrNFSeWebServices.pas pelo arquivo enviado pelo colega "augelias" e voltou a funcionar..
OBS: Meus testes foram no provedor SystemPro.
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
-
1
-
-
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
-
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 &
-
Em 26/09/2018 at 11:17, Henrique Sandri Zimermam disse:
Italo, segue resposta que obtive do suporte da Pronim.
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
-
1
-
-
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.
-
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.
-
1
-
-
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
-
2
-
-
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.
-
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.
-
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.
-
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.
-
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ãoACBrNFSeDANFSeClass.pas
-nova propriedade boolean ImprimeSerieRpsACBrNFSeDANFSeRL.pas e ACBrNFSeDANFSeRLClass.pas
-inclusão dos parametros ImprimeCanhoto e ImprimeSerieRpsACBrNFSeDANFSeRLRetrato.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 -
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.
-
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.
NFS-e Padrão Nacional - Porto Alegre/RS - Erro: E0696 - A assinatura deve ser feita com o certificado digital do emitente da DPS.
em ACBrNFSe
Postado
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?