Desenvolvedor WebService

Consulte aqui informações importantes para o desenvolvimento de web services para integração de sistemas próprios com o sistema da NFS-e da Prefeitura do Município de São Paulo.

Por meio do Web Service é possível automatizar o processo de emissão, consulta e cancelamento de NF-e e emissão de guia de pagamento.

WebService síncronoWebService assíncrono
Envio de RPSEnvio de Lote de RPS – Assíncrono
Envio de Lote de RPSConsulta Situação de Lote de RPS
Teste de Envio de Lote de RPSTeste de Envio de Lote de RPS – Assíncrono
Consulta de NFS-eEmissão de Guia – Assíncrono
Consulta de NFS-e RecebidasConsulta Situação
Consulta de NFS-e EmitidasEmissão de Guia
Consulta de LoteConsulta Guia
Consulta de Informações de Lote
Cancelamento de NFS-e
Consulta de CNPJ

Baixe aqui os Schemas XML (arquivo XSD) correspondentes a cada uma das mensagens XML de pedido e de retorno utilizadas pelo WebService LoteNFe  :

a) NFS-e emitidas até 22/02/2015

b) NFS-e emitidas a partir de 23/02/2015 (fato gerador até 31/12/2025)

c) NFS-e emitidas pelo serviço assíncrono

d) NFS-e – Reforma tributária 2026 (serviços síncronos e assíncronos)

Consulte aqui as principais dúvidas sobre a utilização do WebService

MANUAIS

PERGUNTAS E RESPOSTAS:

1 – Estou recebendo erro 403 – forbidden, o que pode ser?

O webservice utiliza autenticação mútua de certificados, dessa forma, é necessário utilizar o certificado digital no uso de qualquer serviço do webservice.

Verifique na linguagem de programação utilizada, como fazer requisição HTTP com autenticação de cliente via certificado digital.

2 – Estou recebendo erro código 1102 – Mensagem XML de Pedido do serviço sem conteúdo.

Erro decorrente da inclusão do XML de pedido sem tratamento na tag MensagemXML do envelope SOAP.

Enviar o pedido do XML no envelope SOAP conforme manual de webservice, item “3.4.5 – Tratamento de caracteres especiais no texto de XML” ou conforme descrito no item “4.3.1 – Regras Gerais”, conforme destacado abaixo:

“Observações do parâmetro MensagemXML: basicamente existem duas formas mais comuns de informar a mensagem XML neste parâmetro:

1) Informar o XML com os caracteres especiais tratados conforme item 3.4.5 deste manual;  ou,
2) Informar o XML dentro de uma seção CDATA: Exemplo: <MensagemXML><![CDATA[<Pedido>…</Pedido>]]></MensagemXML> “

3 – Estou recebendo erro código 1057 – Rejeição: Assinatura difere do calculado.

Verifique se está aplicando todas as transformações necessárias no XML antes da assinatura, seguindo todas as orientações do manual, não modificando nenhum valor do XML após a assinatura, ou realizando indentação no XML.

4 – A assinatura do RPS é feita antes da assinatura do XML?

Sim, a assinatura do RPS é feita antes, incluída no XML na tag correspondente, e por último é feito a assinatura do XML.

Segue exemplo de código em C# para a assinatura do RPS:

public static byte[] AssinarPedidoRPS(X509Certificate2 x509)

{

……………

string s = null;

// monta uma string com os dados do RPS (86 caracteres)

s = “671590441    00000000001120240103TNN00000000000100000000000000000002692257385833000135”

byte[] assinatura = CreateSignaturePKCS1(x509, System.Text.Encoding.ASCII.GetBytes(s));

return assinatura;

}

// Gera o HASH (array de bytes) utilizando SHA1

//  Assina o HASH (array de bytes) utilizando RSA-SHA1

public static byte[] CreateSignaturePKCS1(X509Certificate2 x509, byte[] Value)

{

       RSACryptoServiceProvider rsa = (RSACryptoServiceProvider)x509.PrivateKey;

       RSAPKCS1SignatureFormatter rsaF = new RSAPKCS1SignatureFormatter(rsa);

       SHA1CryptoServiceProvider sha1 = new SHA1CryptoServiceProvider();

       byte[] hash = null;

       hash = sha1.ComputeHash(Value);

       rsaF.SetHashAlgorithm(“SHA1”);

       return rsaF.CreateSignature(hash);

}

5 – Erro na assinatura do RPS.

Erro código 1206 – Assinatura Digital do RPS incorreta.

Verifique se a string de assinatura que está utilizando está igual a que é apresentada no erro da assinatura do RPS.

Verifique se o texto do campo serieRPS contém 5 posições, e caso seja menor que 5, completar com espaços em branco à direita até ficar 5 posições na string de assinatura do RPS.

A string de assinatura do RPS é representada pela concatenação dos campos do RPS e deve conter:

– 86 caracteres (sem os dados do intermediário do serviço)

Ou

– 101 caracteres (com os dados do intermediário do serviço no final da string)

6 – A assinatura do XML é do XML todo ou só do Pedido?

Somente do pedido, sem o XML do envelope SOAP. Ou seja, somente do XML que será incluído no envelope SOAP.

A assinatura é a última etapa, depois de ter preenchido todo o XML de pedido, incluído as assinaturas adicionais nos casos que são exigidos (Exemplo: Pedido de envio de RPS), feitas as transformações do XML (Enveloped e C14N), então é feita a assinatura do XML. Com o XML assinado, é incluído no envelope SOAP, com os parses dos caracteres ou dentro da seção CDATA, conforme descrito no manual item “3.4.5 – Tratamento de caracteres especiais no texto de XML” ou  “4.3.1 – Regras Gerais”

7 – O que é o Envelope SOAP?

É a estrutura XML padrão na qual é incluído o XML de pedido do serviço solicitado. A analogia é realmente de um envelope, no qual será incluída uma mensagem para envio.

8 – Como saber se a assinatura do XML está correta?

Utilizar o site https://validar.iti.gov.br/ e enviar seu XML assinado – somente o XML assinado, sem o envelope SOAP.

Se o site acima resultar como validado, então o webservice da Nota Fiscal Paulistana também validará.

9 – A sequência dos campos do RPS, pode ocasionar rejeição da assinatura digital do RPS?

Sim, é necessário informar os campos na sequência que consta no “Manual de Utilização Web Service”, na seção “Passos básicos para assinatura de um RPS”.

10 – O campo “SerieRPS”  deve ser informado com espaços à direita também no XML?

Não, informar os espaços apenas na string para a assinatura digital do RPS.