Jump to content

click.png

click.png

click.png

click.png

click.png

click.png

click.png click.png click.png

click.png

click.png

click.png

click.png

click.png

click.png

Gabriel Kissel

Membros
  • Posts

    31
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Gabriel Kissel's Achievements

Contributor

Contributor (5/14)

  • First Post
  • Collaborator Rare
  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

6

Reputation

  1. 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).
  2. 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.
  3. 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.
  4. 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
  5. 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
  6. 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 &
  7. 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)
  8. 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
  9. 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
  10. Boa tarde Italo, Em qual seção/tag do ini do provedor é definido se o conteúdo é text/html ou text/xml?
  11. 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.
  12. 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?
  13. 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
  14. 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?
  15. 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.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.