Novo provedor NFS-e Chapecó - SC

[Cesar Balbinott]

@João Paulo Müller Sim, está sem a rotina de cancelamento por enquanto, como tenho poucos clientes utilizando, peço para cancelarem no site por hora.

[João Paulo Müller]

1 hora atrás, Cesar Balbinott disse:

@João Paulo Müller Sim, está sem a rotina de cancelamento por enquanto, como tenho poucos clientes utilizando, peço para cancelarem no site por hora.

Você está com os fontes do ACBR atualizados, ou está rodando naquela revision sem as implementações do Italo?

[Cesar Balbinott]

Estou rodando sem as implementações, como o pessoal reportou que estava com alguns problemas eu não atualizei, você está com algum problema além do cancelamento?

[João Paulo Müller]

2 minutos atrás, Cesar Balbinott disse:

Estou rodando sem as implementações, como o pessoal reportou que estava com alguns problemas eu não atualizei, você está com algum problema além do cancelamento?

Se atualizar os fontes está com problema na consulta da situação do lote, também não funciona em CAPICOM pois da "Erro não especificado", se trocar pra OPENSSL funciona. E também tem o erro do cancelamento.

[Rafael D'Lima]

Bom dia, estão utilizando a opção GerarNfse? 

Quando uso a opcao Gerar do acbr, acontece este erro: 

 

---------------------------
Aviso
---------------------------
Falha na validação dos dados do lote: 64827

1871 - Element '{http://www.w3.org/2000/09/xmldsig#}Signature': This element is not expected.

---------------------------
OK   
---------------------------



Em a opcao de Envio normal o Xml vai normalmente, porem demora D+ o retorno do lote. 
 

[everson.turossi]

30 minutos atrás, Rafael D'Lima disse:

1871 - Element '{http://www.w3.org/2000/09/xmldsig#}Signature': This element is not expected.

Tive esse problema na NF-e, mas foi corrigido atualizando pra ultima revisão (toda via a ultima revisão para NFS-e não está funcional para este provedor a consulta de situação do lote)

Quanto a demora ai é um caso crítico, tem vezes que processa o lote em 3 segundos e as vezes demora mais de 1 minuto.

[João Paulo Müller]

Essa demora é comum no provedor Pública. Tenho implementado para o município de Mafra e é a mesma situação, tem casos que demora quase  1 minuto para processar.

 

Pessoal conseguem me ajudar com essa questão, talvez conseguimos resolver o problema do cancelamento:

Em 11/01/2019 at 15:39, João Paulo Müller disse:

Boa tarde Pessoal,

Estou me batendo aqui pra tentar assinar o XML, realizei algumas alterações, deixei o arquivo semelhante ao arquivo de exemplo, porém, recebo erro de Access Violation na Unit ACBrDFeXsMsXml, linha 204:

// Assinando com MSXML e CryptoLib //
      signedKey := xmldsig.sign(dsigKey, CERTIFICATES);

Realizei as seguinte alterações:

1) Definir id no elemento <InfPedidoCancelamento> (<InfPedidoCancelamento id="C201900000000005">)

Ao invés de comentar essa linha sugeria fiz a seguinte alteração:

proPublica: FURI := 'C'+FNumeroNFSe;

Ou seja, vamos deixar a URI conforme o exemplo 'C'+NumeroNFs.

2) Atribuir ID no <Reference> herdada da TAG <Signature> (<Reference URI="#C201900000000005">).

Na unit ACBrDFeUtil é construída a TAG:

 Result :=
  '<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"' + IdSignature + '>' +
    '<SignedInfo>' +
      '<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />' +
      '<SignatureMethod Algorithm="'+MethodAlgorithm+'" />' +
      '<Reference URI="' + IfThen(URI = '', '', '#' + URI) + '">' +
        '<Transforms>' +
          '<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />' +
          '<Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />' +
        '</Transforms>' +
        '<DigestMethod Algorithm="'+DigestAlgorithm+'" />' +
        '<DigestValue></DigestValue>' +
      '</Reference>' +
    '</SignedInfo>' +
    '<SignatureValue></SignatureValue>' +
    '<KeyInfo>' +
    IfThen(AddX509Data,
      '<X509Data>' +
        '<X509Certificate></X509Certificate>'+
      '</X509Data>',
      '')+
    '</KeyInfo>'+
  '</Signature>';

É utilizado o parâmetro URI para definir o ID. Esse parâmetro é definido na função ExtraiURI, unit ACBRDFeUtil:

function ExtraiURI(const AXML: String; IdAttr: String): String;
var
  I, J: integer;
begin
  Result := '';
  if IdAttr = '' then
    IdAttr := 'Id';

  I := PosEx(IdAttr+'=', AXML);
  if I = 0 then       // XML não tem URI
    Exit;

  I := PosEx('"', AXML, I + 2);
  if I = 0 then
    raise EACBrDFeException.Create('Não encontrei inicio do URI: aspas inicial');

  J := PosEx('"', AXML, I + 1);
  if J = 0 then
    raise EACBrDFeException.Create('Não encontrei inicio do URI: aspas final');

  Result := copy(AXML, I + 1, J - I - 1);
end;

A função busca no XML o atributo 'Id', pois atualmente o parâmetro IdAttr vem vazio, então é definido fixo o IdAttr := 'Id' (Note que está com o I MAIÚSCULO), já no elemento <InfPedidoCancelamento id="C201900000000005"> está minusculo, ou seja, não é encontrado o id, por isso não seta a TAG <Reference> com o ID necessário.

Para fazer os testes defini de forma fixa o 'id' (minusculo) na chamada da assinatura unit ACBrNFSeWebServices:

// O procedimento recebe como parametro o XML a ser assinado e retorna o
  // mesmo assinado da propriedade FPDadosMsg
  if (FPConfiguracoesNFSe.Geral.ConfigAssinar.Cancelar) and (FPDadosMsg <> '') then
    AssinarXML(FPDadosMsg, FdocElemento, FinfElemento, 'Falha ao Assinar - Cancelar NFS-e: ','','','id');

Para funcionar também alterei a chamada de assinatura na unit ACBRDFeWebService: (Adicionei o parâmetro vazio '')

FPDadosMsg := FPDFeOwner.SSL.Assinar(AXML, docElement, infElement,
                     SignatureNode, SelectionNamespaces,'', IdSignature);

LEMBRANDO FIZ ESSES ALTERAÇÕES APENAS PARA TESTE.

Feito isso, consegui gerar o XML (em anexo) igual o exemplo, exceto a assinatura devido o erro de AV.

Porém, conforme relatei no inicio, recebo o erro de Access Violation,.

Lembro de ter visto algo aqui no fórum referente a esse Id, alguém tem alguma sugestão de como resolver?

Exemplo Publica.xml

Contruido-NãoAssinado.xml

 

[Henrique Sandri Zimermam]

Boa tarde a todos,

Estive enfrentando alguns problemas relacionados ao envio das NFS-e através do webservices. Ao tentar realizar a assinatura do arquivo de envio, era retornado a mensagem "Erro Desconhecido" no metodo TDFeSSLXmlSignMsXmlCapicom.Assinar.

Para contornar este problema, precisei comentar a linha 650 do arquivo ACBrNFSeConfiguracoes que a principio havia sido inserida no fonte na revision16254. Estou anexando ao meu comentário o arquivo alterado. Utilizamos libCapicomDelphiSoap.

ACBrNFSeConfiguracoes.pas

[Italo Giurizzato Junior]

Boa tarde Henrique,

Em vez do libCapicomDelphiSoap ou libCapicom, tentou usar o libWinCrypt ou libOpenSSL?

[Henrique Sandri Zimermam]

18 horas atrás, Italo Jurisato Junior disse:

Boa tarde Henrique,

Em vez do libCapicomDelphiSoap ou libCapicom, tentou usar o libWinCrypt ou libOpenSSL?

Bom dia Italo,

Não utilizamos o libOpenSSL pois alguns clientes nossos utilizam certificados A3. Realizei um teste mudando para libWinCrypt e ao tentar realizar o envio da NFS-e foi retornado a seguinte mensagem:
 

Falha na validação dos dados do lote: 0

1871 - Element
'{http://www.w3.org/2000/09/xmldsig#}Signature': This element is not expected.

 

Creio que será necessário mais alguns ajustes no fonte para passarmos a utilizar o libWinCrypt.

[everson.turossi]

21 minutos atrás, Henrique Sandri Zimermam disse:

1871 - Element

 

'{http://www.w3.org/2000/09/xmldsig#}Signature': This element is not expected.

Seus fontes estão atualizados até qual Revisão?

[Henrique Sandri Zimermam]

14 minutos atrás, everson.turossi disse:

Seus fontes estão atualizados até qual Revisão?

Bom dia Everson, estão na revisão 16299.

[Italo Giurizzato Junior]

Boa tarde Henrique,

A mensagem de erro diz que o elemento Signature é inesperado, logo algo esta sendo assinado e não deveria.

No arquivo Publica.ini que se encontra no repositório a configuração de assinatura é a seguinte:

[Assinar]
RPS=0
Lote=1
URI=0

Assinar somente o Lote.

[Henrique Sandri Zimermam]

23 horas atrás, Italo Jurisato Junior disse:

Boa tarde Henrique,

A mensagem de erro diz que o elemento Signature é inesperado, logo algo esta sendo assinado e não deveria.

No arquivo Publica.ini que se encontra no repositório a configuração de assinatura é a seguinte:

[Assinar]
RPS=0
Lote=1
URI=0

Assinar somente o Lote.

Boa tarde Italo,

Realmente era isso mesmo, o arquivo estava sendo assinado quando não deveria. Após alterar o parametros conforme o sugerido, os arquivos foram enviados com sucesso, inclusive utilizando a libCapicomDelphiSoap. Estou anexando o arquivo Publica.ini que está sendo utilizado nos clientes, além do Lote, o Cancelamento também está sendo assinado.

 

Muito obrigado pelo auxílio!

Publica.ini

[João Paulo Müller]

3 minutos atrás, Henrique Sandri Zimermam disse:

Boa tarde Italo,

Realmente era isso mesmo, o arquivo estava sendo assinado quando não deveria. Após alterar o parametros conforme o sugerido, os arquivos foram enviados com sucesso, inclusive utilizando a libCapicomDelphiSoap. Estou anexando o arquivo Publica.ini que está sendo utilizado nos clientes, além do Lote, o Cancelamento também está sendo assinado.

 

Muito obrigado pelo auxílio!

Publica.ini

Bom dia Henrique, esses teste é com o ACBr atualizado na ultima revision?

[Henrique Sandri Zimermam]

7 minutos atrás, João Paulo Müller disse:

Bom dia Henrique, esses teste é com o ACBr atualizado na ultima revision?

Sim João, com a última.

[everson.turossi]

Vou me dar ao trabalho de atualizar novamente os fontes e testar com Capicom, porque com WinCrypt não tem jeito a consulta da situação do lote (testado ontem inclusive)

[João Paulo Müller]

3 horas atrás, Henrique Sandri Zimermam disse:

Boa tarde Italo,

Realmente era isso mesmo, o arquivo estava sendo assinado quando não deveria. Após alterar o parametros conforme o sugerido, os arquivos foram enviados com sucesso, inclusive utilizando a libCapicomDelphiSoap. Estou anexando o arquivo Publica.ini que está sendo utilizado nos clientes, além do Lote, o Cancelamento também está sendo assinado.

 

Muito obrigado pelo auxílio!

Publica.ini

Atualizei aqui e testei o cancelamento, mas nada.. Falha no hash da assinatura.

Tenho a seguinte configuração do componente aqui:

ACBrNFSe.SSL.SSLHttpLib := httpWinHttp;
  ACBrNFSe.SSL.SSLCryptLib   := cryWinCrypt;

  if Certificado.OpenSSL = 'S' then
  begin
    ACBrNFSe.SSL.SSLXmlSignLib := xsXmlSec;
    ACBrNFSe.SSL.ArquivoPFX    := BMDir+'Certificados\'+Certificado.ArquivoPFX;
  end
  else
  begin
    ACBrNFSe.SSL.SSLXmlSignLib := xsMsXml;
    ACBrNFSe.SSL.NumeroSerie := Certificado.NumSerie;
end;

Permito o  usuário a configurar em OpenSSL (Apontamento do PFX) ou instalação do certificado no windows para A1 e A3 com xsMSXML.

[Henrique Sandri Zimermam]

1 minuto atrás, João Paulo Müller disse:

Atualizei aqui e testei o cancelamento, mas nada.. Falha no hash da assinatura.

Tenho a seguinte configuração do componente aqui:

ACBrNFSe.SSL.SSLHttpLib := httpWinHttp;
  ACBrNFSe.SSL.SSLCryptLib   := cryWinCrypt;

  if Certificado.OpenSSL = 'S' then
  begin
    ACBrNFSe.SSL.SSLXmlSignLib := xsXmlSec;
    ACBrNFSe.SSL.ArquivoPFX    := BMDir+'Certificados\'+Certificado.ArquivoPFX;
  end
  else
  begin
    ACBrNFSe.SSL.SSLXmlSignLib := xsMsXml;
    ACBrNFSe.SSL.NumeroSerie := Certificado.NumSerie;
end;

Permito o  usuário a configurar em OpenSSL (Apontamento do PFX) ou instalação do certificado no windows para A1 e A3 com xsMSXML.

João,

Apenas para esclarecer, o problema da mensagem do hash ao cancelar também está ocorrendo aqui. Eu mencionei que deixei habilitado o parametro de assinatura no cancelamento pois se desativasse o erro apresentado ao cancelar era diferente, retornava problemas com a estrutura do arquivo.

Creio que essa mensagem de hash que aparece ao tentar cancelar seja algo relacionado com o provedor, pois não está ocorrendo apenas na cidade de Chapecó.

[João Paulo Müller]

Acredito que não teve alterações no provedor, pois tenho clientes rodando com antigas versões do modulo NFs para o município de Mafra sem compilar nas ultimas revision e está funcionando normal (Pelo menos não houve ralatos de problemas) .

Fiz novos testes aqui e rodando com a configuração 

 ACBrNFSe.SSL.SSLXmlSignLib := xsXmlSec;

Ocorre erro de HASH na assinatura.

Já com a configuração

ACBrNFSe.SSL.SSLXmlSignLib := xsMsXml;

ocorre Access Violation (Ainda não rodei em debug pra localizar em qual linha);

Editado 18 Janeiro, 2019 por João Paulo Müller

[Rafael D'Lima]

Bom dia. 

Alguem consegue pegar o numero do protocolo, usando a opção Gerar? 
Aqui para mim está retornando Zero. 

 

   protocolo := ACBrNFSe1.NotasFiscais.Items[0].NFSe.protocolo;

[Italo Giurizzato Junior]

Bom dia Rafael,

O numero do protocolo normalmente é retornado quando usamos o método Enviar pois usamos o numero do protocolo para Consultar a Situação do Lote (Versão 1 do layout da ABRASF) e para Consultar o Lote.

Já os métodos EnviarSincrono e Gerar vai depender do provedor retornar ou não essa informação.

[Rafael D'Lima]

Entendi, obrigado. 

[Rafael D'Lima]

Olá, só uma pergunta, o retorno do provedor é 201900000NUMERO , tem como eu pegar apenas o numero, sem o 20190000 ? 

[everson.turossi]

35 minutos atrás, Rafael D'Lima disse:

Olá, só uma pergunta, o retorno do provedor é 201900000NUMERO , tem como eu pegar apenas o numero, sem o 20190000 ? 

É uma String jovem, usa a criatividade (Copy, Delete...).