Implementação Nfse São Paulo

[almp1]

Olá Amigos,

Estou tentando implementar a NFSe São Paulo, estou recebendo a seguinte mensagem

"Falha ao localizar o nó Raiz"

Isso ocorre neste trecho

    { find infElement node }
    infNode := xmlDocGetRootElement(doc);
    while (infNode <> nil) and (infNode.name <> InfElement) do
      infNode := infNode.children;

Que fica na function abaixo do pas ACBrDFeOpenSSL

TDFeOpenSSL.XmlSecSign(const ConteudoXML: AnsiString; SignatureNode,
  SelectionNamespaces, InfElement: AnsiString): AnsiString;

Quando faço o Debug o valor do infNode.Name é 'PedidoEnvioLoteRPS',  enquanto o valor da infElement é 'RPS' o while é executado apenas uma vez com este valores e com isso a infNode fica nil, me retornado a mensagem acima.

Estou usando CentOS 6 32bits, Lazarus 1.4.4 FreePascal 2.6.4 com o ultimo release do ACBr que atualizei hoje. Para testar as configurações de comunicação e certificados as NFe esta implementada e funcionando corretamente.

Alguém pode me ajudar com alguma dica de como resolver isso !?

Abraços,

 

[almp1]

Olá Amigos,

Só para poder reforçar os testes. Obtive o mesmo problema usando Windows 10 com Lazarus 1.4.4 FreePascal 2.6.4.

Assim podemos descartar também as instalações e configurações dos pacotes necessários para xmlsec, libxml2 e libxslt

Se alguém estiver passando por este problema ou tiver uma dica de como podemos ajudar a resolver o problema, estou a disposição

Abraços,

[Italo Giurizzato Junior]

Bom dia,

No seu teste quantos RPS tinha o Lote?

Favor fazer um teste com somente 1 RPS e outro com 2 RPS.

Fico no aguardo do seu retorno.

[almp1]

Bom dia Italo, tudo bem ?

Estou usando o próprio exemplo do Lazarus que vem no pacote ACBr. Fiz os 2 testes como você falou, gerando 1 e 2 RPS(s) o erro é o mesmo.

No primeiro teste é gerado apenas um arquivo 1UNICA-rps.xml no segundo teste são gerados 2 arquivos 1UNICA-rps.xml e 2UNICA-rps.xml

Se houver algo que eu possa fazer para ajuda-lo a diagnosticar este caso conte comigo.

Obrigado

[almp1]

Olá Italo, 

Estive lendo alguns pots sobre a implementação da NFSe-SP aqui no forum, e houve alguns momentos que postaram sobre o limite do uso da CAPICOM. Acredito que isso não seja um limitador, nem a causa do problema que estou tendo, já que uso OpenSSL tanto no linux quanto no windows.

Abraços,

[Italo Giurizzato Junior]

Bom dia,

No caso de SP quando é enviado um lote se temos 3 RPS (por exemplo) no pedido de envio aparece o grupo <RPS> 3 vezes, até ai tudo bem, mas eles não são agrupados, ou seja dentro de um outro grupo, como é no layout da ABRASF.

Notei que o problema ocorre ao tentar assinar, foi por isso que lhe pedir para fazer um teste com apenas 1 RPS, pois me recordo que foram feitos testes com a opção de envio de RPS e funcionou, e nesta opção somente um RPS é enviado.

E se for possível fazer testes com o capicom seria interessante.

Se com capicom funcionar, podemos nos concentrar na rotina de assinatura do OpenSSL.

[almp1]

Olá Italo, obrigado mais uma vez pela ajuda.

Em meus testes ainda com openssl acontece assim na rotina abaixo, sendo que  

infElement = RPS
infNode <> nil 

{ find infElement node }
infNode := xmlDocGetRootElement(doc);
while (infNode <> nil) and (infNode.name <> InfElement) do
  infNode := infNode.children;

1º) infNode.name=PedidoEnvioLoteRPS e infNode.children=Cabecalho //próximo nó
2º) infNode.name=Cabecalho e infNode.children=CPFCNPJRemetente //próximo nó
3º) infNode.name=CPFCNPJRemetente e infNode.children=CNPJ //próximo nó
4º) infNode.name=CNPJ e infNode.children=text /// aqui ele para o laço e retorna o infNode como nil provocando a mensagem "Falha ao localizar o nó Raiz"

O meu XML contem as seguintes informações neste trecho

<?xml version="1.0" encoding="UTF-8"?>
  <PedidoEnvioLoteRPS xmlns="http://www.prefeitura.sp.gov.br/nfe">
    <Cabecalho Versao="1" xmlns="">
      <CPFCNPJRemetente>
        <CNPJ>23183669000161</CNPJ>
      </CPFCNPJRemetente>
      <transacao>true</transacao>
      <dtInicio>2016-06-24</dtInicio>
      <dtFim>2016-06-24</dtFim>
      <QtdRPS>1</QtdRPS>
      <ValorTotalServicos>1685.50</ValorTotalServicos>
      <ValorTotalDeducoes>0</ValorTotalDeducoes>
    </Cabecalho>
    <RPS xmlns="">
      <Assinatura>................

Acredito que este seja um ponto inicial para tentarmos solucionar o problema. O teste acima foi feito em ambiente Linux e Windows usando Lazarus com OpenSSL 

Em relação a CAPICOM somente no Windows

A primeira coisa que ocorreu foi que ao apontar para pasta de Schemas "acbr\Exemplos\ACBrDFe\ACBrNFSe\Schemas\" mesmo reconhecendo que a prefeitura era SP, precisei apontar para pasta "acbr\Exemplos\ACBrDFe\ACBrNFSe\Schemas\SP" para que os xsds fossem encontrados. Imaginei que o ACBr faria isso de forma dinâmica. Se o ACBr não fizer e, eu quiser que seja assim, acredito que a codificação abaixo resolva tomando como base o exemplo do pacote.

 ACBrNFSe1.Configuracoes.Arquivos.PathSchemas := edtSchemas.Text+'/'+ACBrNFSe1.Configuracoes.Geral.xProvedor;

Este sintoma não acontece quando usei o OpenSSL.

Agora, pra finalizar, com a CAPICOM foi sem surpresas, a nota foi transmitida com sucesso.

Deste ponto em diante estou um pouco perdido, não sei que caminho tomar para ajudar numa solução, mas se puder me ajudar com outras dicas, fico a disposição para ajudar a solucionar o problema.

Abraços,

[Daniel Simoes]

Por favor anexe um XML sem a Assinatura, e um XML já assinado pela CAPICOM...

Vou verificar se as modificações recentes no DFeOpenSSL podem funcionar para esse XML

 

[almp1]

Olá Daniel! Tudo bem?

Segue anexo os dois arquivos, caso precise de qualquer outra coisa conte comigo

Abraços,

 

 

 

 

1UNICA-rps.xml

1-env-lot.xml

[Daniel Simoes]

Apliquei uma possível correção no SVN... Favor atualizar e testar...

 

[almp1]

Olá Daniel,

Tudo bem ?

Nem sei como agradecer, fiz a atualização e testei o envio. Funcionou tudo perfeitamente.

Grande abraço,

[Italo Giurizzato Junior]

Bom dia André Medeiros,

Por favor continue com os testes: (Envio, consulta, cancelamento) e nos de um retorno, vamos arredondar o componente para que possamos incluir o provedor SP na lista de provedores funcionando 100&=%

[almp1]

Olá Itlao, 

Nos próximos 15 dias estaremos homologando a prefeitura de SP em nosso sistema. Informo os resultados dos testes aqui.

Abraços,

[cueiogordo]

Boa tarde

Estou realizando notas para SP e o envio funciona sem problemas.

O problema está no Retorno. O componente retorna tudo vazio.

Para contornar o problema, o Componente salva um arquivo chamado <numero do Lote>-rec.xml. Nesse arquivo contem o retorno dos RPS enviado. Neste caso, leio o arquivo e extraio as informações necessárias.

[F Almeida]

11 minutos atrás, cueiogordo disse:

Boa tarde

Estou realizando notas para SP e o envio funciona sem problemas.

O problema está no Retorno. O componente retorna tudo vazio.

Para contornar o problema, o Componente salva um arquivo chamado <numero do Lote>-rec.xml. Nesse arquivo contem o retorno dos RPS enviado. Neste caso, leio o arquivo e extraio as informações necessárias.

Estou com o mesmo problema, como falamos no outro tópico, tentei testar um pouco com as configurações do Arquivo INI do Provedor sem sucesso, peguei uma nota do Trunk1 aqui e notei que tem o prefixo P1, em anexo um envio antigo que tive sucesso ao consultar, para tentarem comparar com o atual gerado pelo Trunk2...

Creio que se acertar as configurações de links, prefixos e tags no arquivo INI talvez se adeque ao provedor, uma vez que eles nem mesmo nos dão o WSDL para verificar a sintaxe...

192950914-con-lot.xml

192950914-con-lot-soap.xml

[Italo Giurizzato Junior]

Boa tarde Bruno,

Foi feita uma alteração para que o componente possa ler o retorno logo após o envio, todos os seus fontes estão atualizados?

De uma olha na function: LerXML_proSP que esta na unit pnfsEnvLoteRpsResposta.pas

 

 

 

[almp1]

Olá amigos !

Apenas para conhecimento dos testes que estou fazendo na prefeitura de SP.

Como faço o envio para outras prefeituras, precisei fazer algumas adequações no meu processo para manter o "cross prefeituras" . Deu um pouco de trabalho, pois tive que considerar as regras de negócio das prefeituras durante o meu processo. Como sugestão, poderíamos colocar isso na construção dos XMLs que não são no padrão ASBRAF. Por exemplo, o provedor de SP não permite que seja informado a inscrição municipal do tomador quando o mesmo esta fora da cidade de SP, acho que isso deveria se considerado na construção do XML. Assim nós podemos preencher todas as propriedades da TNFSe sem se preocupar para qual prefeitura o XML será enviado, e como ele será tratado. Um outro exemplo ainda é a declaração da alíquota, em algumas prefeituras devemos informar 2.00 para 2% já em outras deve-se informar 0.02 para os mesmo 2%, com isso nossos processos começam a ganhar muitas condições. Temos também a variedade no formato da data, enfim. Se este for o caminho a percorrer acredito que podemos abrir um tópico só para tratar disso ... 

Aparentemente o método para o envio do RPS está ok.

Recepcionar=http://www.prefeitura.sp.gov.br/nfe/ws/EnvioLoteRPS

Após o envio neste método já é possível ler o retorno com numero da NFSe e código de verificação. 

Com isso parti para o teste no próximo método 

ConsSit=http://www.prefeitura.sp.gov.br/nfe/ws/consultaInformacoesLote

O retorno é:

Erro Interno: 0
Erro HTTP: 500

Isso ocorre em todos os outros métodos seguintes. Vou iniciar os debugs para tentar verificar o que realmente ocorre. Não sei se isso ocorre somente comigo ou se o mesmo ocorre com outros que estejam usando o Provedor SP

Abraços,

[Daniel Simoes]

Erro 500 ocorre quando servidor :Web não pode ser alcançado.. (Proxy, Firewall, Servirdor offline, etc)...
O endereço está realmente correto ?

[almp1]

Olá Daniel,

Eu não pude testar ainda com capicom os outros métodos.

O método de envio de lote "http://www.prefeitura.sp.gov.br/nfe/ws/EnvioLoteRPS" funciona normalmente, por isso acredito que não tenha influencia de regras de Firewall, mesmo assim fiz testes com a a maquina exposta diretamente na internet. O erro permaneceu.

Acredito que existe algo em relação ao endereço, como você disse, mas nenhum outro colega aqui parece ter tido este problema. Como estou usando Linux+OpenSSL pode ser que haja algo que não esteja correto ainda. Estou tentando identificar.

O próximo método que estou tentando executar é o http://www.prefeitura.sp.gov.br/nfe/ws/consultaInformacoesLote, que faz a consulta do lote.

Se precisar de mais alguma informação conte comigo

Abraços,

 

[Daniel Simoes]

Aparentemente esses endereços não abrem no Navegador... Estão corretos ?

não seria HTTPS ?

[almp1]

Olá Daniel,

No manual do WS da prefeitura informa que são estes endereços mesmo. No método EnvioLoteRps a característica é a mesma, não acessa pelo navegador, mas a comunicação é feita com sucesso, ainda estou relutante quanto a isso e tentando investigar o que ocorre.

Na realidade a url é https://nfe.prefeitura.sp.gov.br/ws/lotenfe.asmx e o SoapAction é http://www.prefeitura.sp.gov.br/nfe/ws/consultaLote

É justamente o SoapAction que esta dando problema

Abraços,

Editado 29 Junho, 2016 por almp1
Correção do texto

[almp1]

Olá Daniel

Fiz alguns testes assim

Ambiente 1
Windows + Capicom + Lazarus 1.4.4 + FPC + 2.6.4

O processo para na instrução abaixo da unit ACBrHTTPReqResp.pas, o método é o TACBrHTTPReqResp.Execute(const DataMsg: String; Resp: TStream);

if HttpSendRequest(pRequest, nil, 0, Pointer(FData), Length(FData)) then

Não houve mais resposta do sistema, aguardei cerca de 15 minutos, e não houve nenhuma resposta, nem de falha ou "time out".

Ambiente 2
Windows + OpenSSL + Lazarus 1.4.4 + FPC + 2.6.4

O processo avança até a linha abaixo da unit ACBrDFeOpenSSL.pas, no método TDFeOpenSSL.Enviar(const ConteudoXML: String; const URL: String;
  const SoapAction: String; const MimeType: String): String;

OK := FHTTP.HTTPMethod('POST', URL);

Neste ponto o httpsend da synalist entra em cena para efetuar o envio e temos o retorno que eu havia reportado acima, 
Erro Interno: 0
Erro HTTP: 500

Este mesmo caso ocorre no ambiente abaixo

Ambiente 3
Linux 32bits + OpenSSL + Lazarus 1.4.4 + FPC + 2.6.4

Entendo que o erro pode ser uma falha no alcance da URL, mas não entendo porque o método de envio do lote funciona, sendo que a url para todos os demais métodos é a mesma só sendo alterado o SoapAction.

Não sei se outros colegas esta conseguindo consumir todos os métodos do WS de SP. Mas no meu caso só o método de envio do lote esta sendo consumido, todos os outros métodos ocorre o mesmo erro acima.

Se alguém puder ajudar com alguma dica, fico grato. 

Abraços,

[Daniel Simoes]

Como todas as "Libs" de criptografia falham nesse cenário e funcionam para o Envio de Lote, podemos descartar uma falha nas rotinas de comunicação segura do ACBr...

Provavelmente é algum problema pontual no WS da prefeitura... tentou entrar em contato com eles ?

[almp1]

Olá Daniel,

A principio me foi enviado um exemplo com XMLs para cada método. Estou enviando anexo para conhecimento.

Percebi que nos exemplos dos xmls o método de envio de lote em geral é assim:

<PedidoEnvioLoteRPS xmlns="http://www.prefeitura.sp.gov.br/nfe" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><Cabecalho xmlns="" Versao="1">

Já os outros métodos os exemplos em geral são assim:

<p1:PedidoConsultaLote xmlns:p1="http://www.prefeitura.sp.gov.br/nfe" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><Cabecalho Versao="1">

Veja que a diferença esta na inclusão do p1: no método e a exclusão do atributo xmls="" no cabeçalho.

Não sei se isso causaria o erro 500. Tentei criar o xml com o "p1", mas depois que o xml é assinado o "p1" é retirado.

Acredito que o exemplo deles deva estar sujo, já que o "p1" é retirado durante o processo de assinatura.

Vou continuar a verificação 

Abraços,

 

exemplos.zip

exemplosV02.zip

[Italo Giurizzato Junior]

Boa tarde,

Tomem cuidado, pois existe duas versões, sendo que uma delas foi desativada em 22/02/2015.

Página 11 - item 3.4.2 do Manual versão 2.4.1 do Web Service da Prefeitura de São Paulo.