Jump to content

2 Dia do ACBr

Ingressos esgotados! Agradecemos a todos os inscritos.
Site do Evento

Nova Loja Oficial
loja.projetoacbr.com.br
Ajude o projeto a crescer, com estilo

Comprar

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Saiba mais

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Saiba mais

Rigotti

ANSWERED NFS-e Caxias do Sul

Recommended Posts

Buenas pessoal!

 

então, verifiquei a estrutura da assinatura digital e percebi que esta faltando a tag X509SubjectName entre as tags X509Data e X509Certificate.

 

provável que seja a solução pro erro de assinatura digital com certificado A3, porem não sei como faço pra preencher essa tag.

 

alguma luz?

Share this post


Link to post
Share on other sites

Boa tarde!

 

após incluir a tag X509SubjectName na assinatura, entrei em contato com o suporte do provedor infisc e passei os dados do certificado A3(Safeweb) que estamos tentando homologar.

 

Resposta:

 

"Boa tarde,

Não temos a sua cadeia certificadora no ambiente de Produção.
Vamos providenciar a inclusão assim que concluído volto a informar.

Obrigado."

 

vou aguardar retorno e confirmo aqui depois se ficou ok.

Share this post


Link to post
Share on other sites

Buenas!

 

então pessoal, quanto ao erro de assinatura com certificado A3 está tudo ok.

o suporte da infisc incluiu a cadeia certificadora em Caxias e Farroupilha.

 

só ainda não sei qual  a maneira correta de incluir a tag X509SubjectName, fiz uma alteração provisória pra ver se era esse o problema mesmo.

 

na rotina que AssinarMSXML na unit ACBrNFSeUtil incluí isso:

 

" DFeUtil.SeSenao((AProvedor in [proInfisc]),'<X509SubjectName>'+Certificado.SubjectName+'</X509SubjectName>','')  "

Share this post


Link to post
Share on other sites

Galera bom dia.

 

1 - Caso eu precise de um Certificado de teste para gerar NFS-e em homologação para "Caxias do Sul", o provedor Infisc disponibiliza algum certificado de teste para isso, ou apenas dependo o certificado do meu cliente, que no caso é o A3?

2 - Alguém está emitindo para Caxias, usando ainda a TRUNK1? Estamos segurando a migração para TRUNK2 devido a problemas com a TECHNOS.

3 - Na TRUNK2 está funcionando para "INFISC" ?

 

 

Share this post


Link to post
Share on other sites
5 horas atrás, Otimizy disse:

Galera bom dia.

 

1 - Caso eu precise de um Certificado de teste para gerar NFS-e em homologação para "Caxias do Sul", o provedor Infisc disponibiliza algum certificado de teste para isso, ou apenas dependo o certificado do meu cliente, que no caso é o A3?

2 - Alguém está emitindo para Caxias, usando ainda a TRUNK1? Estamos segurando a migração para TRUNK2 devido a problemas com a TECHNOS.

3 - Na TRUNK2 está funcionando para "INFISC" ?

 

 

Boa Tarde!

Estamos com os fontes (Trunk2) atualizados até 05/02/2016 - EMISSÃO/CONSULTA/CANCELAMENTO funcionando!!!

Att.

Moro

Share this post


Link to post
Share on other sites
14 horas atrás, Moro disse:

Boa Tarde!

Estamos com os fontes (Trunk2) atualizados até 05/02/2016 - EMISSÃO/CONSULTA/CANCELAMENTO funcionando!!!

Att.

Moro

Obrigado Moro. 

Veremos se existe a possibilidade da migração para TRUNK2 em nosso software.

Enquanto isso não ocorre na "TrUNK1" tenho as tags:

nNFS-e =  {Número da nota, sequencial e crescente}. Numero da Nota

cNFS-e =  {Código numérico aleatório, que faz parte da chave de acesso da NFS-e, servindo para evitar que robots vasculhem todas as notas dos contribuintes.}

                 Esse valor é aleatório gerado pelo software, que será usado na geração da chave de acesso ?

                 Esse valor pode se repetir ?

 

Qual a forma correta de alimentar essas tags: Indiferente da forma usada, em meu caso o XML gerado vem sem estes valores?

Alguma dica:

 

 

Share this post


Link to post
Share on other sites

Otimizy,

Pelo meu entendimento a tag <cNFS-e> não se repete.

Criamos ela da seguinte maneira EX:

Temos wNumNF:= '168';

Logo a tag <nNFS-e>000000168</nNFS-e> sempre 9 digitos!!!

 

Agora para montar o número aleatório:

Depois...

with NotasFiscais.Add.NFSe do begin
               wVarAleatorio:= rtxt(copy(inttostr(abs((strtoint(wNumNF)*12)-strtoint(copy(datetostr(wDtEmiss),4,2)+copy(datetostr(wDtEmiss),7,4)))),1,9),9,'0');
              

              //cod. da UF   +   //cnpj prest   +   //modelo   +   //Serie   +   Num. RPS   +  Num. Aleatório
               ChaveNFSe:=copy(wNFEndEmpresaCodCidade,1,2)
                          + trim(zLimpaNum(wNFEndEmpresaCGC))
                          + '98'
                          + 'S'
                          + '00'
                          + FormatFloat('000000000', zStrToInt(wNumNF))
                          + wVarAleatorio;

.......
Aqui continuamos alimentando o restante dos dados da nota.

Se vc debugar o código na unit pnfsNFSeW_Infisc

vai ter a procedure TNFSeW_Infisc.GerarIdentificacaoRPS e ali dentro vai ter

sChave := NFSe.ChaveNFSe;

cNFSe:= copy(sChave,31,9);

 

Acredito ter clareado as idéias?

 

Att.

Moro

 

 

Share this post


Link to post
Share on other sites

Boa tarde.

 

Eu de novo...

Em pnfsNFSeW_Infisc.pas em que momento estes campos recebem valores:

<taSomenteSeAssinada>

if FOpcoes.GerarTagAssinatura = taSomenteSeAssinada then

NFSe.signature.DigestValue

NFSe.signature.SignatureValue

NFSe.signature.X509Certificate

 

Isso deveria ocorrer no momento de assinar o arquivo correto?

Que é quando é carregado o arquivo xsd, ou estou enganado ?

 

Isso ao final apenas me resulta em um erro em tela, como imagem em anexo.

Apenas salientando, TRUNK2 para Garibaldi - RS.

 

Obrigado.

 

Erro.png

Edited by Otimizy

Share this post


Link to post
Share on other sites

Boa tarde.

Começamos usar a TRUNK2 hoje a fim de usar InFisc para Garibaldi -  RS.

Esse erro ocorreu em nosso caso no momento do envio do lote.

Porém não estou conseguindo fazer a assinatura do lote.

Alguma dica ?

Share this post


Link to post
Share on other sites

O erro é levantado no método em negrito:

 

ACBrNFSe.Enviar(pNroLote, False);

WebServices.Envia(ALote);

FEnviarLoteRPS.Executar;

procedure TNFSeEnviarLoteRPS.DefinirDadosMsg;

function TNotasFiscais.AssinarLote(): String;

function TDFeSSL.Assinar(): String;

function TDFeSSLClass.Assinar(): String;

Share this post


Link to post
Share on other sites

Boa noite colegas, 

Estou implementando a nota pelo provedor Infisc e tentando usar A1 com openssl...

Não passava de jeito nenhum pela function xmlParseDoc,  chamada na function TDFeOpenSSL.XmlSecSign da Unit  ACBrDFeOpenSSL.

Ai descobri um detalhe na procedure TNFSeEnviarLoteRPS.DefinirDadosMsg da Unit ACBrNFSeWebServices

Descobrir que não faz o Parse por causa da variável  TagElemento que no caso do provedor ser Infisc está sendo setada com vazio ('')

 

Trecho dos fontes de hoje, 23 fevereiro de 2016

GerarDadosMsg := TNFSeG.Create;
  try
    case Provedor of
      proInfisc: TagGrupo := 'envioLote';
      proISSDSF: TagGrupo := 'ReqEnvioLoteRPS';
      proEquiplano: TagGrupo := 'enviarLoteRpsEnvio';
    else
      TagGrupo := 'EnviarLoteRpsEnvio';
    end;

    case FProvedor of
      proInfisc: TagElemento := '';   // <<<<<<<< Para "parsear" usando openssl essa variável tem que ter valor. 
    else
      TagElemento := 'LoteRps';
    end;

Alterei conforme abaixo e passou.

    case FProvedor of
      proInfisc: TagElemento := 'infNFSe';    // <<<<<< 
    else
      TagElemento := 'LoteRps';
    end;
 

O que me dizem? Confere minha observação?

 

 

 

Share this post


Link to post
Share on other sites

Boa noite Eraldo,

Muito obrigado pela colaboração é preciso agora testar com o Capicom.

Favor atualizar todos os fontes e realize novos testes.

  • Like 1

Consultor SAC ACBr Italo Jurisato Junior
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

Analista de Sistemas / e-mail: [email protected] / Fone: (16) 9-9701-5030 / Araraquara-SP

Share this post


Link to post
Share on other sites

Bom dia Italo.

Atualizei os fontes agora de manhã ("24.02.2016"), o erro anterior deixou de existir, porém. ('TRUNB2 Garibaldi - RS').

 

Um de uma tag: vOutro que segundo validador site da Prefeitura de Garibaldi não existe: ('https://nfsehomol.garibaldi.rs.gov.br/portal/') 

E o outro de outras tags, que o que me parece, por mais que não tenham valores devem existir no arquivo:

 

Em anexo os arquivos .xml com imagem do erro.

 

Tags.png

Tags.xml

vOutro.png

vOutro.xml

Share this post


Link to post
Share on other sites

Bom dia,

Pelo que pude ver o XML esta sendo criado conforme o schema, veja:

      <!-- Definicao da estrutura de dados para totalizacoes em uma NFSe  -->
      <xs:element name="total">
          <xs:complexType>
              <xs:sequence>
                  <xs:element name="vReemb" type="TDec_1302" minOccurs="0" maxOccurs="1"/>
                  <xs:element name="vServ" type="TDec_1302" minOccurs="0" maxOccurs="1"/>
                  <xs:element name="vDesc"  type="TDec_1302" minOccurs="0" maxOccurs="1"/>
                  <xs:element name="vOutro" type="TDec_1302" minOccurs="0" maxOccurs="1"/>
                  <xs:element name="vtNF" type="TDec_1302" minOccurs="0" maxOccurs="1"/>
                  <xs:element name="vtLiq" type="TDec_1302" minOccurs="0" maxOccurs="1"/>
                  <xs:element name="totalAproxTrib" type="TDec_1302" minOccurs="0" maxOccurs="1"/>
                  <xs:element ref="Ret" minOccurs="0" maxOccurs="1"/>
                  <xs:element ref="fat" minOccurs="0" maxOccurs="1"/>
                  <xs:element ref="ISS" />
              </xs:sequence>
          </xs:complexType>
      </xs:element>

Na primeira imagem de erro que você postou diz que ele encontrou a TAG totalAproxTrib sendo que esperava encontrar Ret, vLiqFaturas ou ISS.

Note que vLiqFaturas não existe no schema e sim fat. E no schema totalAproxTrib vem antes das TAGs mencionadas na mensagem de erro.

A mesma coisa ocorre com a segunda mensagem de erro, note que vOutro realmente vem antes de vtNF, logo o XML foi gerado conforme o schema.

Agora se o schema utilizado pelo web service é outro, então precisamos atualizar o que temos.


Consultor SAC ACBr Italo Jurisato Junior
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

Analista de Sistemas / e-mail: [email protected] / Fone: (16) 9-9701-5030 / Araraquara-SP

Share this post


Link to post
Share on other sites

Italo, referente aos Schemas:

Cada provedor detém apenas de um Schema ? 

Ou as regras de tal Schema varia de cidade a cidade, ambas com mesmo provedor ?

O que é correto, pegar o Schema diretamente com o Provedor ou com o pessoal das Prefeituras ?

 

 

Share this post


Link to post
Share on other sites
15 horas atrás, Italo Jurisato Junior disse:

Boa noite Eraldo,

Muito obrigado pela colaboração é preciso agora testar com o Capicom.

Favor atualizar todos os fontes e realize novos testes.

Boa tarde Italo e colegas,

Avançando ainda no NFSe utilizando A1 com openssl, acredito não ser necessário atribuir  o identificador ID no ATTLIST dos XML´s.

Com Capicom passa, acredito que por não fazer a consistência do dessa informação na estrutura do XML...talvez alguém com mais conhecimento poderá confirmar/refutar isso.  Já com o parser usando openssl a coisa é mais restritiva.

Explico:

Existe na unit ACBrDFeOpenSSL a  a const cDTD, conforme trecho abaixo  

.....

  HTTPSend, ssl_openssl,
  libxmlsec, libxslt, libxml2;

const
  cDTD = '<!DOCTYPE test [<!ATTLIST &infElement& Id ID #IMPLIED>]>';            ///<<-- ME REFIRO A ESSA!

  cErrMngrCreate = 'Erro: Falha ao criar Gerenciador de Chaves "xmlSecKeysMngrCreate"';
  cErrMngrInit = 'Erro: Falha ao inicializar o Gerenciador de Chaves "xmlSecCryptoAppDefaultKeysMngrInit"';
  cErrCertLoad = 'Erro: Falha ao ler informação do Certificado no Gerenciador de Chaves';
  cErrParseDoc = 'Erro: Falha ao interpretar o XML "xmlParseDoc"';
.......

E percebo que não é obrigatório informar o elemento do tipo ID, nem para a geração do XML para envio , e nem para consulta... hoje implementei  a consulta também usando openssl aqui para Caxias do Sul. Mas tive que alterar a constante cDTD.

O que proponho é que, pelo menos com Openssl, não informar ATTLIST. Então a const cDTD seria como abaixo. 

cDTD = '<!DOCTYPE test []>';
 

Nos testes que fiz até esse momento, fiz essa alteração e a geração/envio e consulta da NFSe, usando openssl para o provefor  Infisc funcionou perfeitamente.

Como tem efeito somente em openssl, Capicom não altera nada.

 

Att. Eraldo

 

 

 

 

 

Share this post


Link to post
Share on other sites

Boa tarde Eraldo,

Em uma outra postagem você disse que tinha caminhado ao atribuir o nome da TAG:

 proInfisc: TagElemento := 'infNFSe';

Isso não resolve o problema do DTD ?

Boa tarde Otimizy,

A principio cada provedor possui o seu próprio schema e este é usando para todas as cidades.

A não ser que no seu caso para a cidade em questão o provedor ainda esta usando uma versão antiga do schema, dai os erros.


Consultor SAC ACBr Italo Jurisato Junior
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

Analista de Sistemas / e-mail: [email protected] / Fone: (16) 9-9701-5030 / Araraquara-SP

Share this post


Link to post
Share on other sites
3 horas atrás, Italo Jurisato Junior disse:

Boa tarde Eraldo,

Em uma outra postagem você disse que tinha caminhado ao atribuir o nome da TAG:

 proInfisc: TagElemento := 'infNFSe';

Isso não resolve o problema do DTD ?

Boa tarde Otimizy,

A principio cada provedor possui o seu próprio schema e este é usando para todas as cidades.

A não ser que no seu caso para a cidade em questão o provedor ainda esta usando uma versão antiga do schema, dai os erros.

 

Italo,

Resolve sim, mas para o caso da geração do XML do envio do Lote.

No XML da consulta falha porque não existe atribuição para nenhum provedor.

Para o caso de usar  openssl, acredito que por ser mais restritivo, não acetia um campo ID sem referencia no XML como abaixo

'<!DOCTYPE test [<!ATTLIST id ID #IMPLIED>]>'

acima esta dizendo que o XML possui um elemento chave mas não está passando nada.

No cado do XML do lote você informa que o elemento chave do XML é o "infNFSe"

No caso da consulta, não esta sendo informado nada. E falha no parser do openssl.  

Percebi que esse elemento chave ID não é necessário. Os XML´s já tem os schemas que fazem a validação. Não precisamos dizer que o XML tem um campo chave...

ou seja,  a const cDTD pode ser  apenas :  cDTD = '<!DOCTYPE test []>';

 

Att. Eraldo

Edited by eraldo

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

×
×
  • Create New...