Ir para conteúdo
  • Cadastre-se

Gabriel Kissel

Membros
  • Total de ítens

    33
  • Registro em

  • Última visita

Últimos Visitantes

O bloco dos últimos visitantes está desativado e não está sendo visualizado por outros usuários.

Gabriel Kissel's Achievements

Contributor

Contributor (5/14)

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

Recent Badges

6

Reputação

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

    NFS-e Sarandi/RS

    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.
  14. 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?
  15. 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
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...