(Revogado pela Instrução Normativa RFB Nº 1998 DE 10/12/2020):

O Secretário da Receita Federal do Brasil, no uso das atribuições que lhe conferem os incisos III e XVI do art. 280 do Regimento Interno da Secretaria da Receita Federal do Brasil, aprovado pela Portaria MF nº 203, de 14 de maio de 2012, e tendo em vista o disposto no art. 50 da Lei nº 8.212, de 24 de julho de 1991, no art. 226 do Decreto nº 3.048, de 6 de maio de 1999, e no § 1º do art. 391 da Instrução Normativa RFB nº 971, de 13 de novembro de 2009,

Resolve:

Art. 1º Fica aprovado o Manual Web Service SisobraPref, constante do Anexo Único, que estabelece padrões técnicos de comunicação (leiaute) para a transmissão, entre os municípios, inclusive as administrações regionais do Governo do Distrito Federal (GDF), e a Secretaria da Receita Federal do Brasil (RFB), dos dados relativos a alvarás para construção civil e a documentos de habite-se concedidos, bem como das informações relativas à não emissão desses documentos.

§ 1º O leiaute de que trata o caput destina-se a entes federativos que possuam ou estejam desenvolvendo sistema próprio de controle de alvará, habite-se e declaração de inexistência de movimentação fiscal no período de competência (declaração sem movimento) e poderá ser utilizado para realização de testes até a substituição do leiaute especificado na Portaria INSS/DRP nº 53, de 9 de junho de 2004, e republicado pela Portaria MPS/SRP nº 160, de 21 de junho de 2005. (Redação do parágrafo dada pela Instrução Normativa RFB Nº 1641 DE 13/05/2016).

§ 2º As atualizações do leiaute de que trata o caput serão disponibilizadas no sítio da RFB, na Internet, no endereço < http://rfb.gov.br.> (Parágrafo acrescentado pela Instrução Normativa RFB Nº 1641 DE 13/05/2016).

§ 3º Para a transmissão dos arquivos digitais contendo os dados e as informações a que se refere o caput, é necessária prévia adesão do ente federativo ao Domicílio Tributário Eletrônico (DTE). (Parágrafo acrescentado pela Instrução Normativa RFB Nº 1641 DE 13/05/2016).

§ 4º A transmissão de arquivos na fase de testes não exime o ente federativo da entrega de arquivos digitais na forma estabelecida na Portaria INSS/DRP nº 53, de 2004, e republicada pela Portaria MPS/SRP nº 160, de 2005. (Parágrafo acrescentado pela Instrução Normativa RFB Nº 1641 DE 13/05/2016).

Art. 2º Esta Instrução Normativa entra em vigor na data de sua publicação no Diário Oficial da União.

JORGE ANTONIO DEHER RACHID

ANEXO ÚNICO

Manual

Web Service

SisobraPref

Padrões técnicos de comunicação

versão 1.00

Maio 2015

Sumário

1. Introdução

2. Objetivo do Projeto

3. Descrição Simplificada do Modelo Operacional

4. Arquitetura de Comunicação com a Prefeitura

4.1. Modelo Conceitual

4.2. Padrões Técnicos

4.2.1. Padrão de Codificação

4.2.2. Otimização na Montagem do Arquivo

4.2.3. Validação de Schema

4.2.4. Padrão de Comunicação

4.2.5. Padrão de Certificado Digital

4.2.6. Padrão de Assinatura Digital

4.2.7. Resumo dos Padrões Técnicos

4.3. Modelo Operacional

5. Web Service

5.1. Validação da Estrutura XML das Mensagens do Web Service

5.2. Schemas XML das Mensagens dos Web Services

5.3. Versão dos Schemas

5.4. Web Service

5.4.1. RecepcaoLote

5.4.1.1. Leiaute da Mensagem de Entrada

5.4.1.2. Leiaute da Mensagem de Retorno

5.4.1.3. Leiaute Alvará

5.4.1.4. Leiaute Habite-se

5.4.1.5. Leiaute Altera Situação

5.4.2. RecepcaoDeclaracaoSemMovimento

5.4.2.1. Leiaute do Arquivo de Declaração sem Movimento

5.4.2.2. Leiaute do Resultado do Processamento da Declaração de sem Movimento

5.4.3. ConsultaDocumento

5.4.3.1. Leiaute do Arquivo de Consulta Documento

5.4.3.2. Leiaute do Resultado do Processamento da Consulta

5.5. Validação de Regra de Negócio para Certificado Digital de Transmissão

5.6. Validação de Regra de Negócio para Certificado Digital de Assinatura

5.7. Validação de Regra de Negócio para Assinatura

5.8. Final do Processamento

5.9. Número de Protocolo

6.0. Categorias da Obra

7.0. Tabela de Códigos e Descrições de Mensagens

1. Introdução Este documento tem por objetivo a definição das especificações e critérios técnicos necessários para a integração entre os serviços da Secretaria da Receita Federal do Brasil (RFB) e os sistemas de informações das prefeituras que possuem sistema próprio de controle de alvará, habite-se e declaração de sem movimento.

2. Objetivo do Projeto Tem por objetivo o cadastramento de dados de alvarás e/ou habite-se de obras de construção civil para a transmissão dessas informações à base da RFB. Até meados de 1997, as prefeituras municipais devido à existência de dispositivo na Lei nº 8.212, de 24 de julho de 1991, eram obrigadas a exigir dos responsáveis pela execução de obras de construção civil, a comprovação da matrícula da obra no Instituto Nacional do Seguro Social (INSS) para a emissão de alvarás, bem como de certidão de regularização para a emissão de habite-se. A partir de então, em virtude de mudança na referida Lei, acabou-se essa obrigatoriedade, substituindo-se pela exigência de informar mensalmente a relação de alvarás e habite-se emitidos no mês anterior. Como, resolveu-se uniformizar e atualizar a forma de os órgãos públicos transmitirem essas informações à RFB, por força do art. 2º da Lei nº 11.457, de 16 de março de 2007, se faz necessário desenvolver novo sistema que propicie essa uniformização e controle das informações dos documentos, sistema adequado ao Programa de Unificação do Crédito Fazendário e Previdenciário e com o objetivo, também, de aumentar a quantidade de inscrições de obras, principalmente daqueles de responsabilidade de pessoas físicas.

3. Descrição Simplificada do Modelo Operacional A prefeitura emissora de alvará, habite-se e declaração de sem movimento gera um arquivo eletrônico contendo as informações da obra, o qual deverá ser assinado digitalmente, transformando esse arquivo em um documento eletrônico de maneira a garantir a integridade dos dados e a autoria do emissor. Esse arquivo eletrônico será transmitido pela Internet para a RFB, a qual, após verificar a integridade formal e regras de negócio, devolverá um número de protocolo para cada documento enviado no lote.

Para utilizar esse serviço da RFB a prefeitura deverá ser optante pelo Domicílio Tributário Eletrônico (DTE).

4. Arquitetura de Comunicação com a Prefeitura

4.1. Modelo Conceitual A RFB irá disponibilizar os seguintes serviços:

1) Recepção de alvará e habite-se:

Recepção de lotes contendo alvará e habite-se ou alteração de situação de alvará e habite-se. A alteração de situação envolve o cancelamento ou reativação de um determinado alvará e/ou habitese.

2) Recepção de declaração de sem movimento.

Recepção de lotes de declaração de sem movimento.

3) Consulta de alvará e habite-se.

Consulta individual de alvará e habite-se.

Existirá um Web Service contendo esses serviços. O fluxo de comunicação é sempre iniciado pelo aplicativo da prefeitura através do envio de uma mensagem ao Web Service com a solicitação do serviço desejado.

Toda prefeitura que utilizar a solução Web Service deverá obrigatoriamente estar habilitada no Domicílio Tributário Eletrônico (DTE).

4.2. Padrões Técnicos

4.2.1. Padrão de Codificação

A especificação do documento XML adotada é a recomendação W3C para XML 1.0, disponível em www.w3.org/TR/REC-xml e a codificação dos caracteres será em UTF-8, assim todos os documentos XML serão iniciados com a seguinte declaração:

Cada arquivo XML somente poderá ter uma única declaração .

4.2.2. Otimização na Montagem do Arquivo

Para reduzir o tamanho final do arquivo XML alguns cuidados de programação deverão ser assumidos:

não incluir "zeros não significativos" para campos numéricos;

não incluir "espaços" no início ou no final de campos numéricos e alfanuméricos;

não incluir comentários no arquivo XML;

não incluir anotação e documentação no arquivo XML (TAG annotation e TAG documentation);

não incluir caracteres de formatação no arquivo XML ("linefeed", "carriage return", "tab", caractere de "espaço" entre as TAGs).

4.2.3. Validação de Schema

Para garantir minimamente a integridade das informações prestadas e a correta formação dos arquivos XML, a prefeitura deverá submeter o arquivo XML para validação pelo Schema do XML (XSD - XML Schema Definition), disponibilizado pela RFB.

4.2.4. Padrão de Comunicação

A comunicação será baseada em Web Services disponibilizados pela RFB.

O meio físico de comunicação utilizado será a Internet, com o uso do protocolo SSL versão 3.0, com autenticação mútua, que além de garantir um duto de comunicação seguro na Internet, permite a identificação do servidor e do cliente através de certificados digitais, eliminando a necessidade de identificação do usuário através de nome ou código de usuário e senha.

A troca de mensagens entre o Web Services e o aplicativo da prefeitura será realizada no padrão SOAP versão 1.2 e WSDL 1.2.

4.2.5. Padrão de Certificado Digital

O certificado digital utilizado no SisobraPref será emitido por Autoridade Certificadora credenciada pela Infraestrutura de Chaves Públicas Brasileira - ICP-Brasil, tipo A1 ou A3, devendo conter o número de Cadastro Nacional de Pessoa Jurídica (CNPJ) da pessoa jurídica titular do certificado digital.

Os certificados digitais serão exigidos em 2 (dois) momentos distintos:

a) Assinatura do aquivo XML: O certificado digital utilizado para essa função deverá conter o CNPJ da prefeitura. O certificado digital deverá ter o "uso da chave" previsto para a função de assinatura digital, respeitando a Política do Certificado.

b) Transmissão (durante a transmissão das mensagens entre o servidor da prefeitura e a RFB): O certificado digital utilizado para identificação do aplicativo da prefeitura deverá conter o CNPJ do responsável pela transmissão das mensagens, devendo ter a extensão Extended Key Usage com permissão de "Autenticação Cliente".

4.2.6. Padrão de Assinatura Digital

As mensagens enviadas à RFB são documentos eletrônicos elaborados no padrão XML e devem ser assinados digitalmente com um certificado digital que contenha o CNPJ prefeitura emissora do alvará, habite-se ou declaração de sem movimento.

O SisobraPref utiliza um subconjunto do padrão de assinatura XML definido pelo http://www.w3.org/TR/xmldsig-core/, com o seguinte leiaute:

Schema XML: xmldsig-core-schema_v1.01.xsd

Observação

Legenda para a coluna Ele:

A - indica que o campo é um atributo do Elemento anterior;

E - indica que o campo é um Elemento;

CE - indica que o campo é um Elemento que deriva de uma Escolha (Choice);

G - indica que o campo é um Elemento de Grupo;

CG - indica que o campo é um Elemento de Grupo que deriva de uma Escolha (Choice);

RC - indica que o campo é uma key constraint (Restrição de Chave) para garantir a unicidade e presença do valor;

A assinatura dos documentos será conforme tabela abaixo.

Para o processo de assinatura a prefeitura não deve fornecer a Lista de Certificados Revogados, já que a mesma será montada e validada pela RFB no momento da conferência da assinatura digital.

A assinatura digital do documento eletrônico deverá atender aos seguintes padrões adotados:

a) Padrão de assinatura: "XML Digital Signature", utilizando o formato "Enveloped" (http://www.w3.org/TR/xmldsig-core/);

b) Certificado digital: Emitido por AC credenciada no ICPBrasil (http://www.w3.org/2000/09/xmldsig#X509Data);

c) Cadeia de Certificação: EndCertOnly (incluir na assinatura apenas o certificado do usuário final);

d) Tipo do certificado: A1 ou A3;

e) Tamanho da Chave Criptográfica: compatível com os certificados A1 e A3 (1024 bits);

f) Função criptográfica assimétrica: RSA (http://www. w3. org/2000/09/xmldsig# rsa- sha1);

g) Função de "message digest": SHA-1 (http://www. w3. org/2000/09/xmldsig# sha1);

h) Codificação: Base64 (http://www.w3.org/2000/09/xmldsig#base64);

i) Transformações exigidas: útil para realizar a canonicalização do XML enviado para realizar a validação correta da Assinatura Digital. São elas:

1) Enveloped (http://www.w3.org/2000/09/xmldsig#enveloped-signature)

2) C14N (http://www.w3.org/TR/2001/REC-xml-c14n-20010315)

4.2.7. Resumo dos Padrões Técnicos

A tabela a seguir resume os principais padrões de tecnologia utilizados:

4.3. Modelo Operacional

A forma de processamento no sistema SisobraPref será síncrona, isto é, o resultado do processamento é obtido na mesma conexão.

Etapas do processo:

O aplicativo da prefeitura inicia a conexão enviando uma mensagem de solicitação de serviço para o Web Service;

O Web Service recebe a mensagem de solicitação de serviço que irá processar o serviço solicitado;

Realiza o processamento, devolvendo uma mensagem de resultado do processamento do aplicativo da prefeitura;

O aplicativo da prefeitura recebe a mensagem de resultado do processamento e encerra a conexão.

5. Web Service O Web Service disponibiliza os serviços que serão utilizados pelo aplicativo da prefeitura. O mecanismo de utilização do Web Service segue as seguintes premissas:

a) Será disponibilizado um Web Service com um método para cada tipo de serviço. Temos três tipos de serviços:

envio de lote de alvará e habite-se;

envio de lote de declaração de sem movimento;

consulta documento (alvará e habite-se).

b) O envio da solicitação e a obtenção do retorno serão realizados na mesma conexão através de um único método.

c) O processo de utilização do Web Service sempre é iniciado pela prefeitura enviando uma mensagem nos padrões XML e SOAP, através do protocolo SSL com autenticação mútua.

d) A ocorrência de qualquer erro na validação dos dados recebidos interrompe o processo com a disponibilização de uma mensagem contendo o código e a descrição do erro.

Existirá um Web Service XXXXX contendo três web métodos:

recepcaoAlvaraHabitese: recepção de alvará e habite-se

recepcaoDSM: recepção de declaração de sem movimento

consultaDocumento: consulta alvará e habite-se

A mensagem será descartada se o tamanho exceder o limite previsto de 500 KB. A aplicação da prefeitura não poderá permitir a geração de mensagem com tamanho superior a 500 KB. Caso isto ocorra, teremos a devolução da mensagem de rejeição ER201.

5.1. Validação da Estrutura XML das Mensagens do Web Service

As informações são enviadas ou recebidas do Web Service através de mensagens no padrão XML definido na documentação.

As alterações de leiaute e da estrutura de dados XML realizadas nas mensagens são controladas através da atribuição de um número de versão para a mensagem.

Um Schema XML é uma linguagem que define o conteúdo do documento XML, descrevendo os seus elementos e a sua organização, além de estabelecer regras de preenchimento de conteúdo e de obrigatoriedade de cada elemento ou grupo de informação.

A validação da estrutura XML da mensagem é realizada por um analisador sintático (parser) que verifica se a mensagem atende as definições e regras de seu Schema XML.

Qualquer divergência da estrutura XML da mensagem em relação ao seu Schema XML provoca um erro de validação do Schema XML.

A primeira condição para que a mensagem seja validada com sucesso é que ela seja submetida ao Schema XML correto.

Assim, os aplicativos da prefeitura devem estar preparados para gerar as mensagens no leiaute em vigor.

5.2. Schemas XML das Mensagens dos Web Services

Toda mudança de leiaute das mensagens do Web Service implica a atualização do seu respectivo Schema XML.

A identificação da versão dos Schemas será realizada com o acréscimo do número da versão no nome do arquivo precedida do literal "_v?, como segue:

- LoteAlvaraHabitese_v100.xsd (Schema XML na versão 1.00)

5.3. Versão dos Schemas

A cada nova versão será disponibilizado um arquivo compactado contendo o conjunto de schemas a serem utilizados pelas prefeituras para a geração dos arquivos XML. Este arquivo será denominado "SisobraPref" e será numerado sequencialmente.

Exemplificando: O arquivo SisobraPref_001.zip representa o conjunto de schemas nº 1.

5.4. Web Service

5.4.1 RecepcaoLote

Função: serviço destinado a recepção de lotes de alvará e habite-se

Método: recepcaoAlvaraHabitese

5.4.1.1. Leiaute da Mensagem de Entrada

Entrada: Estrutura XML com alvarás e habite-se.

Schema XML: LoteAlvaraHabitese_v100.xsd

5.4.1.2. Leiaute da Mensagem de Retorno

Retorno: Estrutura XML com a mensagem do resultado do processamento.

Schema XML: retornoLoteAlvaraHabitese_v100.xsd

5.4.1.3. Leiaute Alvará

Schema XML: LeiauteAlvara_v100.xsd

5.4.1.4. Leiaute Habite-se Schema XML: LeiauteHabitese_v100.xsd

5.4.1.5 Leiaute Altera Situação

Schema XML: LeiauteAlteraSituacao_v100.xsd

Objetivo: realizar a operação de cancelar e reativar alvará e/ou habite-se

5.4.2. RecepcaoDeclaracaoSemMovimento

Função: serviço destinado à recepção de declaração de sem movimento Método: recepcaoDSM

5.4.2.1. Leiaute do Arquivo de Declaração sem Movimento

Entrada: Estrutura XML com declaração de sem movimento.

Schema XML: DSM_v100.xsd

5.4.2.2. Leiaute do Resultado do Processamento da Declaração de sem Movimento

Retorno: Estrutura XML com a mensagem do resultado.

Schema XML: retornoDSM_v100.xsd

5.4.3. ConsultaDocumento

Função: serviço destinado à consulta de alvará e habite-se

Método: consultaDocumento

5.4.3.1. Leiaute do Arquivo de Consulta Documento

Entrada: Estrutura XML de consulta de documento.

Schema XML: LeiauteConsultaDocumento_v100.xsd

5.4.3.2. Leiaute do Resultado do Processamento da Consulta

Retorno: Estrutura XML com a mensagem do resultado.

Schema XML: retornoConsultaDocumento_v100.xsd

5.5. Validação de Regra de Negócio para Certificado Digital de Transmissão

5.6. Validação de Regra de Negócio para Certificado Digital de Assinatura

5.7. Validação de Regra de Negócio para Assinatura

5.8. Final do Processamento

O final do processamento dos documentos (Alvará, Habite-se ou Declaração de sem movimento) enviados poderá resultar em:

Rejeição: o documento será descartado, não sendo armazenado no banco de dados. Pode ser corrigido e enviado novamente.

Sucesso: o documento será armazenado no banco de dados.

Para cada documento com "Sucesso" será atribuído um número de protocolo (vide regra de formação no item 5.9).

5.9. Número de Protocolo

Todo documento processado com "Sucesso" terá um protocolo que será enviado no arquivo de retorno para as prefeituras.

O número de protocolo tem a seguinte formação:

Código do município: Código do município da tabela TOM

Tipo do documento: Alvará, Habite-se ou DSM

Ano: ano da data do momento do cadastro

Mês: mês da data do momento do cadastro

Dia: dia da data do momento do cadastro

ID do documento: número sequencial gerado automatica- mente pelo sistema

DV: dígito verificador baseado em um cálculo do módulo 11

6.0. Categorias da Obra

Para Área Principal e Área Complementar existem as seguintes categorias de obras:

Obra nova, Acréscimo, Reforma, Demolição e Existente que serão possíveis nas seguintes combinações:

1 - Obra Nova

2 - Acréscimo e Existente

3 - Acréscimo, Reforma e Existente

4 - Acréscimo, Demolição e Existente

5 - Acréscimo, Reforma, Demolição e Existente

6 - Reforma e Existente

7 - Reforma, Demolição e Existente

8 - Demolição e Existente

9 - Obra Nova, Demolição e Existente*

* Apenas se a área de demolição for igual à existente.

7.0. Tabela de Códigos e Descrições de Mensagens