Manual de Orientação ao Contribuinte da Declaração de Conteúdo eletrônica

Esta página tem por objetivo a publicação dos conteúdos do Manual de Orientação da Declaração de Conteúdo eletrônica (DCe), modelo 99, versão 1.0 – Visão Geral, já com as atualizações introduzidas pelas Notas Técnicas publicadas até a presente data.

O Manual da Declaração de Conteúdo eletrônica é composto pelos seguintes documentos:

• Manual DCe – Visão Geral;
• Manual DCe – Anexo I – Leiaute DCe e Regras de Validação;
• Manual DCe – Anexo II – Especificações Técnicas da DACE e QR-Code;
• Manual DCe – Anexo III – Manual de Credenciamento.

A versão original do Manual e as Notas Técnicas que o atualizam podem ser encontradas no Portal da DCe da SVRS, onde também se encontram os pacotes de liberação de schemas e demais documentos. Os endereços dos Web Services de distribuição estão disponíveis na área de serviços do Portal da DCe da SVRS.

Esta página não tem por objetivo substituir o Manual, servindo como material de apoio e de fácil consulta.

Ao longo deste documento o acrônimo DCe é utilizado para todas as situações que se aplicam à Declaração de Conteúdo eletrônica.

A Declaração de Conteúdo eletrônica (DCe) é desenvolvida de forma integrada pelas Secretarias de Fazenda dos Estados e está instituída pelo Ajuste SINIEF 05/2021, que autorizou aos Estados a criação do documento em substituição à declaração de conteúdo em papel prevista no Protocolo ICMS 32/2001.

2.1. Objetivos Do Projeto

O Projeto DCe tem como objetivo a implantação de um modelo nacional de declaração de conteúdo eletrônica, visando a substituir a sistemática de utilização da declaração de conteúdo em papel, melhorando a visibilidade dessa declaração e permitindo, ao mesmo tempo, o acompanhamento em tempo real das operações.

2.2. Conceito Da DCe

A Declaração de Conteúdo eletrônica (DCe) é aquela emitida e armazenada eletronicamente, de existência apenas digital, com o intuito de documentar operações para as quais o documento fiscal não é exigido, cuja validade jurídica é garantida pela autorização de uso e pela assinatura digital da administração tributária, da empresa Marketplace ou do usuário emitente, antes do início do transporte.

2.2.1. DACE

O DACE (Declaração Auxiliar de Conteúdo eletrônico) pode ser impresso em papel ou apresentado em formato eletrônico; sua especificação e modelos de leiaute encontram-se disponíveis no documento Anexo II – Manual de Especificações Técnicas do DACE.

O DACE não é a Declaração de Conteúdo eletrônica, nem a substitui, servindo apenas como instrumento auxiliar para consulta da DCe, pois contém a chave de acesso da DCe e o QR-Code, que permitem ao detentor desse documento confirmar, através das páginas da Secretaria de Fazenda, a efetiva existência de uma DCe que tenha tido seu uso regularmente autorizado.

O QR-Code e o código de barras da DACE deverão estar visíveis na embalagem do produto que está sendo enviado.

2.2.2. Modelo Conceitual Da DCe

A DCe deverá ser emitida para substituir a declaração de conteúdo de que trata o § 1º da cláusula terceira do Protocolo ICMS 32/01, de 28 de setembro de 2001, ou por pessoa física ou jurídica, não contribuinte, no transporte de bens e mercadorias na hipótese de não ser exigido documento fiscal.

1. O usuário emitente irá realizar a emissão da DCe, enviando o arquivo XML para autorização (Figura 1).

2. Após a autorização da DCe, o usuário emitente vai até a transportadora e apresenta a DACE. O transportador faz a leitura da DACE para verificar a validade da DCe; sendo válida, ele pode iniciar o transporte (Figura 2).

Durante o transporte, a fiscalização pode realizar uma verificação das mercadorias transportadas e realizar a leitura da DACE para verificar a validade da DCe (Figura 3).

2.2.3. Modelos De Emissão Da DCe

O projeto da Declaração de Conteúdo eletrônica prevê quatro formas de emissão da DCe pelos usuários emitentes:

1. Aplicativo disponibilizado pelo Fisco – nessa modalidade, o usuário emitente fará a emissão da DCe e do DACE pelo aplicativo disponibilizado pelo fisco. Nessa situação, a assinatura digital da DCe e de seus eventos será feita pelo Certificado Digital da SEFAZ.
2. Marketplace – nessa modalidade, os Marketplaces interessados poderão realizar a emissão para os seus clientes (usuário emitente com CPF ou CNPJ de não contribuinte), integrando o serviço de autorização da DCe nos seus módulos de venda. Nessa situação, a assinatura digital da DCe e de seus eventos será feita pelo Certificado Digital do Marketplace.
3. Emissão Própria – nessa modalidade, o usuário emitente que possui CNPJ e for não contribuinte poderá integrar seu próprio sistema ao serviço de autorização da DCe. Nessa situação, a assinatura digital da DCe e de seus eventos será feita pelo Certificado Digital do usuário emitente (CNPJ).
4. Transportadora – nessa modalidade, as Transportadoras interessadas poderão realizar a emissão para os seus clientes (usuário emitente com CPF ou CNPJ de não contribuinte), integrando o serviço de autorização da DCe nos seus módulos de venda. Nessa situação, a assinatura digital da DCe e de seus eventos será feita pelo Certificado Digital da Transportadora.

2.2.4. Chave De Acesso

A Chave de Acesso de identificação da Declaração de Conteúdo eletrônica é um conjunto de 44 caracteres numéricos, formado pela concatenação de campos que se encontram no leiaute da DCe, seguindo a estrutura que pode ser vista na tabela abaixo.

Tabela 2-1 – Chave de Acesso da Versão 1.00 da DCe (com as alterações da NT 2024.001)

Posição	Informação	Caracteres	Campo	Id
1	Código da UF do emitente da DCe	02	cUF	B02
2	Ano e Mês de emissão da DCe	04	AAMM	Extraídos de B07
3	CNPJ da SEFAZ, Marketplace, Transportadora, Usuário emitente ou ECT	14	CNPJ	C02, D02, D09, D13 ou D19
4	Modelo da Declaração (99)	02	mod	B04
5	Série da Declaração	03	serie	B05
6	Número da Declaração	09	nDC	B06
7	Forma de emissão da DCe	01	tpEmis	B08
8	Tipo do emitente da DCe (0-App Fisco / 1-Marketplace / 2-Emissor próprio / 3-Transportadora / 4-ECT)	01	tpEmit	B08a
9	Site do Autorizador que recepcionou a DCe	01	nSiteAutoriz	B08b
10	Código Numérico que compõe a Chave de Acesso	06	cDC	B03
11	Dígito Verificador da Chave de Acesso	01	cDV	B09

O Dígito Verificador (DV) garante a integridade da chave de acesso, protegendo-a principalmente contra digitações erradas. O Código Numérico deve ser uma sequência totalmente aleatória.

2.2.4.1. Cálculo Do Dígito Verificador Da Chave De Acesso Da DCe

O dígito verificador (DV) da chave de acesso da DCe é baseado em um cálculo do módulo 11. O módulo 11 de um número é calculado multiplicando-se cada algarismo pela sequência de números 2, 3, 4, 5, 6, 7, 8, 9, 2, 3, ..., posicionados da direita para a esquerda. A somatória dos resultados das ponderações dos algarismos é dividida por 11 e o DV será a diferença entre o divisor (11) e o resto da divisão:

DV = 11 – (resto da divisão)

Quando o resto da divisão for 0 (zero) ou 1 (um), o DV deverá ser igual a 0 (zero).

Exemplo: consideremos uma chave de acesso com a seguinte sequência de caracteres:

• Somatória das ponderações = 644;
• Dividindo a somatória das ponderações por 11 teremos 644 / 11 = 58, restando 6;
• DV = 11 – (resto da divisão) = 11 – 6 = 5.

Neste caso, o DV da chave de acesso da DCe é igual a “5”, valor este que deverá compor a chave de acesso, formando uma sequência de 44 caracteres.

2.3. Descrição Simplificada Do Modelo Operacional Da DCe

O usuário emitente (CPF) de DCe precisa estar previamente cadastrado no serviço gov.br para começar a emitir a DCe. Após o seu cadastro, o usuário acessa o portal/aplicativo disponibilizado pela administração tributária, no qual irá seguir os passos para gerar a DCe, contendo as informações da operação, transformando esta declaração em um arquivo eletrônico (XML) nos termos da legislação brasileira, de maneira a garantir a integridade dos dados e a autoria do emissor. Este arquivo eletrônico será transmitido pela Internet para a Secretaria de Fazenda, Finanças ou Tributação da unidade federada de jurisdição do usuário emitente, a qual, após verificar a integridade formal, devolverá um protocolo de recebimento denominado “Autorização de Uso”.

Após a Autorização de Uso, que transforma a declaração em Declaração de Conteúdo eletrônica, a Secretaria de Fazenda Estadual disponibilizará consulta, através da Internet, para o destinatário e outros legítimos interessados que conheçam a chave de acesso da declaração.

Para acompanhar o trânsito da mercadoria será impressa uma representação gráfica simplificada da Declaração de Conteúdo eletrônica, intitulada DACE (Declaração Auxiliar de Conteúdo eletrônica), geralmente em papel comum, em única via. O DACE conterá impressos, em destaque:

• a chave de acesso, o QR-Code e o código de barras linear, tomando-se por referência o padrão CODE-128C, para facilitar e agilizar a consulta da DCe na Internet e a respectiva confirmação de informações pelas unidades fiscais e destinatários; e
• o protocolo de autorização de uso.

O DACE não é a Declaração de Conteúdo eletrônica, nem a substitui, servindo apenas como instrumento auxiliar para consulta da DCe, pois contém a chave de acesso da DCe, que permite ao detentor dessa declaração confirmar, através das páginas da Secretaria de Fazenda Estadual, a efetiva existência de uma DCe que tenha tido seu uso regularmente autorizado.

O sistema DCe implementa o conceito de “evento”, que é o registro de uma ação ou situação relacionada com a Declaração de Conteúdo eletrônica, ocorrida após a autorização de uso, como o registro do cancelamento, por exemplo.

2.3.1. Autorização De Uso

O aplicativo disponibilizado pelo fisco, pelo Marketplace ou do próprio usuário emitente gera um arquivo eletrônico com base na declaração e nas informações fornecidas pelo usuário emissor, transformando este arquivo em uma declaração eletrônica nos termos da legislação brasileira, de maneira a garantir a integridade dos dados e a autoria do emissor.

Este arquivo eletrônico será transmitido pela Internet para a Secretaria de Fazenda, Finanças ou Tributação da unidade federada de jurisdição do usuário emitente, a qual, após verificar a integridade formal, devolverá um protocolo de recebimento denominado “Autorização de Uso”.

Após a Autorização de Uso, que dá validade jurídica à Declaração de Conteúdo eletrônica, a Secretaria de Fazenda Estadual disponibilizará consulta, através da Internet, para o destinatário e outros legítimos interessados que conheçam a chave de acesso da declaração eletrônica.

Para acompanhar o transporte do produto, bem ou mercadoria, deve ser impressa a representação gráfica simplificada da Declaração de Conteúdo eletrônica, intitulada DACE.

Um evento é o registro de uma ocorrência relacionada com a Declaração de Conteúdo eletrônica. O evento pode modificar a situação do documento (por exemplo, autorização de uso, cancelamento).

O Sistema de Registro de Eventos da DCe (SRE) é o modelo genérico que permite o registro da ocorrência por ator que pratica ou recepciona qualquer ocorrência que tenha vinculação ou interesse para a DCe. A autorização de uso também é considerada um evento da DCe, ainda que sua estrutura seja diferente dos demais eventos.

Os eventos são mensagens no formato XML geradas por meio dos serviços oferecidos no Portal da Secretaria de Fazenda interessada ou por órgão público que realize atos relacionados com uma DCe.

Existe um único Web Service com a funcionalidade de tratar eventos de forma genérica, para facilitar a criação de novos eventos sem a necessidade de criação de novos serviços, e com poucas alterações na aplicação de Registro de Eventos do Ambiente Autorizador.

O modelo de mensagem de registro de evento possui o seguinte conjunto mínimo de informações comuns:

• Identificação do autor do registro;
• Identificação do evento;
• Identificação da DCe vinculada;
• Informações específicas do evento;
• Assinatura digital da mensagem.

O leiaute da mensagem de Registro de Evento contém uma parte genérica (comum a todos os tipos de evento) e uma parte específica, onde será inserido o XML correspondente a cada tipo de evento, em uma tag do tipo any.

3.1. Tipos De Evento

A DCe somente possui o evento de Cancelamento, que se encontra regrado na Cláusula Décima Primeira do Ajuste SINIEF 05/2021.

Tipos de evento da DCe

tpEvento	Descrição	Observação
110111	Cancelamento	Autor do evento: o emissor da DCe. Prazo: até 24 horas da autorização de uso. Ver Web Service – DCeRecepcaoEvento – Cancelamento.

4.1. Modelo Conceitual

As Secretarias de Fazenda Estaduais irão disponibilizar os seguintes serviços:

1. Software/Aplicativo emissor da DCe;
2. WS Autorização de DCe;
3. WS Consulta da situação atual da DCe;
4. WS Consulta do status do serviço;
5. WS Registro de eventos;
6. Consulta Pública de DCe.

A solicitação de serviço será atendida na mesma conexão. Portanto, os serviços serão síncronos: o processamento da solicitação de serviço é concluído na mesma conexão, com a devolução de uma mensagem com o resultado do processamento do serviço solicitado.

4.2. Padrões Técnicos

4.2.1. Padrão De Documento XML

4.2.1.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:

<?xml version="1.0" encoding="UTF-8"?>

Cada arquivo XML somente poderá ter uma única declaração <?xml version="1.0" encoding="UTF-8"?>. Nas situações em que um documento XML pode conter outros documentos XML, como ocorre com o documento XML de envio da DCe, deve-se tomar cuidado para que exista uma única declaração no início do lote.

4.2.1.2. Declaração namespace

O documento XML deverá ter uma única declaração de namespace no elemento raiz do documento com o seguinte padrão:

<DCe xmlns="http://www.portalfiscal.inf.br/dce">

É vedado o uso de declaração namespace diferente do padrão estabelecido.

Não é permitida a utilização de prefixos de namespace. Essa restrição visa otimizar o tamanho do arquivo XML. Assim, ao invés da declaração <DCe xmlns:dce="http://www.portalfiscal.inf.br/dce">, deverá ser adotada a declaração <DCe xmlns="http://www.portalfiscal.inf.br/dce">.

4.2.1.3. Otimização na Montagem do Arquivo

Na geração do arquivo XML da DCe, excetuados os campos identificados como obrigatórios no modelo, não deverá ser incluída a TAG de campo com conteúdo zero (para campos tipo numérico) ou vazio (para campos tipo caractere).

A regra constante do parágrafo anterior deverá estender-se para os campos onde não há indicação de obrigatoriedade e que, no entanto, seu preenchimento torna-se obrigatório por estar condicionado à legislação específica. Neste caso, deverá constar a TAG com o valor correspondente e, para os demais campos, deverão ser eliminadas as TAG.

Para reduzir o tamanho final do arquivo XML da DCe, 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 (“line-feed”, “carriage return”, “tab”, caractere de “espaço” entre as TAGs);
• não incluir prefixo no namespace das tags de DCe.

4.2.1.4. Validação de Schema

Para garantir minimamente a integridade das informações prestadas e a correta formação dos arquivos XML, deverá ser enviado o arquivo da DCe e as demais mensagens XML para validação pelo Schema do XML (XSD – XML Schema Definition), disponibilizado pela Secretaria de Fazenda Estadual.

4.2.1.5. Tratamento de Caracteres Especiais no Texto de XML

Todos os textos de um documento XML passam por uma análise do “parser” específico da linguagem. Alguns caracteres afetam o funcionamento deste “parser”, não podendo aparecer no texto de uma forma não controlada.

Alguns destes caracteres podem aparecer especialmente no campo de Nome, Endereço e Informação Adicional. Para resolver esses casos, é recomendável o uso de uma sequência de “escape” em substituição ao caractere que causa o problema. Ex.: a denominação DIAS & DIAS LTDA deve ser informada como DIAS & DIAS LTDA no XML, para não afetar o funcionamento do parser.

Nota: a sequência de escape conta como um único caractere para a validação do tamanho do campo pelo Schema.

Tabela 4-1 – Caracteres Especiais no Texto de XML

Caractere	Descrição	Sequência de Escape
<	sinal de menor	&lt;
>	sinal de maior	&gt;
&	e-comercial	&amp;
"	aspas	&quot;
'	sinal de apóstrofe	&#39;

4.2.2. Padrão De Comunicação

A comunicação será baseada em Web Services disponibilizados pelo Sistema de Recepção de Declaração de Conteúdo eletrônica.

O meio físico de comunicação utilizado será a Internet, com o uso do protocolo TLS 1.2 ou superior, 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.

O modelo de comunicação segue o padrão de Web Services definido pelo WS-I Basic Profile.

A troca de mensagens entre os Web Services do ambiente do Sistema de Recepção da DCe e o aplicativo da SEFAZ será realizada no padrão SOAP versão 1.2, com troca de mensagens XML no padrão Style/Encoding: Document/Literal.

A chamada de diferentes Web Services é realizada com o envio de uma mensagem XML através do parâmetro dceDadosMsg.

4.2.3. Padrão De Certificado Digital

O certificado digital utilizado no Sistema Declaração de Conteúdo eletrônica será emitido por Autoridade Certificadora credenciada pela Infraestrutura de Chaves Públicas Brasileira – ICP-Brasil, tipo A1 ou A3, devendo conter o CNPJ da pessoa jurídica titular do certificado digital no campo OtherName OID = 2.16.76.1.3.3.

4.2.4. Padrão De Assinatura Digital

As mensagens enviadas ao Portal da Secretaria de Fazenda Estadual são documentos eletrônicos elaborados no padrão XML e devem ser assinados digitalmente com um certificado digital que contenha o CNPJ da SEFAZ, do Marketplace ou do Usuário emitente (CNPJ) da DCe.

Alguns elementos estão presentes dentro do Certificado, tornando desnecessária a sua representação individualizada no arquivo XML. Portanto, o arquivo XML não deve conter os elementos:

• <X509SubjectName>, <X509IssuerSerial>, <X509IssuerName>, <X509SerialNumber> e <X509SKI>.

Deve-se evitar o uso das TAG abaixo, pois as informações serão obtidas a partir do Certificado do emitente:

• <KeyValue>, <RSAKeyValue>, <Modulus> e <Exponent>.

A DCe utiliza um subconjunto do padrão de assinatura XML definido pelo http://www.w3.org/TR/xmldsig-core/, com o leiaute a seguir.

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

#	Campo	Ele	Pai	Tipo	Ocor.	Descrição/Observação
XS01	Signature	Raiz	-	-	-
XS02	SignedInfo	G	XS01	-	1-1	Grupo da Informação da assinatura
XS03	CanonicalizationMethod	G	XS02	-	1-1	Grupo do Método de Canonicalização
XS04	Algorithm	A	XS03	C	1-1	Atributo Algorithm de CanonicalizationMethod: http://www.w3.org/TR/2001/REC-xml-c14n-20010315
XS05	SignatureMethod	G	XS02	-	1-1	Grupo do Método de Assinatura
XS06	Algorithm	A	XS05	C	1-1	Atributo Algorithm de SignatureMethod: http://www.w3.org/2000/09/xmldsig#rsa-sha1
XS07	Reference	G	XS02	-	1-1	Grupo Reference
XS08	URI	A	XS07	C	1-1	Atributo URI da tag Reference
XS10	Transforms	G	XS07	-	1-1	Grupo do algorithm de Transform
XS11	unique_Transf_Alg	RC	XS10	-	1-1	Regra para o atributo Algorithm do Transform ser único
XS12	Transform	G	XS10	-	2-2	Grupo de Transform
XS13	Algorithm	A	XS12	C	1-1	Atributos válidos Algorithm do Transform: http://www.w3.org/TR/2001/REC-xml-c14n-20010315 e http://www.w3.org/2000/09/xmldsig#enveloped-signature
XS14	XPath	E	XS12	C	0-N	XPath
XS15	DigestMethod	G	XS07	-	1-1	Grupo do Método de DigestMethod
XS16	Algorithm	A	XS15	C	1-1	Atributo Algorithm de DigestMethod: http://www.w3.org/2000/09/xmldsig#sha1
XS17	DigestValue	E	XS07	C	1	Digest Value (Hash SHA-1 – Base64)
XS18	SignatureValue	G	XS01	-	1-1	Grupo do Signature Value
XS19	KeyInfo	G	XS01	-	1-1	Grupo do KeyInfo
XS20	X509Data	G	XS19	-	1-1	Grupo X509
XS21	X509Certificate	E	XS20	C	1-1	Certificado Digital X509 em Base64

A assinatura da SEFAZ na DCe será feita na TAG <infDCe>, identificada pelo atributo Id, cujo conteúdo deverá ser um identificador único (chave de acesso) precedido do literal “DCe” para cada DCe, conforme leiaute descrito no documento Manual – Anexo I – Leiaute DCe. O identificador único precedido do literal “#DCe” deverá ser informado no atributo URI da TAG <Reference>. Para as demais mensagens a serem assinadas, o processo é o mesmo, mantendo-se sempre um identificador único para o atributo Id na TAG a ser assinada.

Tabela 4-2 – Padrões de Assinatura Digital

Parâmetro	Padrão
Padrão de assinatura	“XML Digital Signature”, utilizando o formato “Enveloped” (http://www.w3.org/TR/xmldsig-core/)
Certificado digital	Emitido por AC credenciada no ICP-Brasil (http://www.w3.org/2000/09/xmldsig#X509Data)
Cadeia de Certificação	EndCertOnly (incluir na assinatura apenas o certificado do usuário final)
Tipo do certificado	A1 ou A3
Tamanho da Chave Criptográfica	Compatível com os certificados A1 e A3 (1024 bits)
Função criptográfica assimétrica	RSA (http://www.w3.org/2000/09/xmldsig#rsa-sha1)
Função de “message digest”	SHA-1 (http://www.w3.org/2000/09/xmldsig#sha1)
Codificação	Base64 (http://www.w3.org/2000/09/xmldsig#base64)
Transformações exigidas	Útil para realizar a canonicalização do XML enviado para realizar a validação correta da Assinatura Digital. São elas: Enveloped (http://www.w3.org/2000/09/xmldsig#enveloped-signature) e C14N (http://www.w3.org/TR/2001/REC-xml-c14n-20010315)

4.2.4.1. Geração do QR-Code na DACE

O certificado digital utilizado para a assinatura da DCe deverá ser utilizado para assinar e compor (chave pública) o QR-Code da declaração auxiliar de conteúdo eletrônica nas emissões offline.

4.2.5. Resumo Dos Padrões Técnicos

Tabela 4-3 – Resumo dos Padrões Técnicos

Parâmetro	Padrão
Web Services	Padrão definido pelo WS-I Basic Profile 1.1 (http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html)
Meio lógico de comunicação	Web Services, disponibilizados pelo Portal da Secretaria de Fazenda Estadual
Meio físico de comunicação	Internet
Protocolo Internet	TLS versão 1.2, com autenticação mútua através de certificados digitais
Padrão de troca de mensagens	SOAP versão 1.2
Padrão da mensagem	XML no padrão Style/Encoding: Document/Literal
Padrão de certificado digital	X.509 versão 3, emitido por Autoridade Certificadora credenciada pela ICP-Brasil, do tipo A1 ou A3, devendo conter o CNPJ do proprietário do certificado digital. Para transmissão, utilizar o certificado digital do responsável pela transmissão.
Padrão de assinatura digital	XML Digital Signature, Enveloped, com certificado digital X.509 versão 3, com chave privada de tamanho variável, conforme o padrão da ICP-Brasil (1024, 2048 ou mais bits), com padrões de criptografia assimétrica RSA, algoritmo message digest SHA-1 e utilização das transformações Enveloped e C14N
Validação de assinatura digital	Será validada, além da integridade e autoria, a cadeia de confiança com a validação das LCR
Padrões de preenchimento XML	Campos não obrigatórios do Schema que não possuam conteúdo terão suas tags suprimidas no arquivo XML. Máscara de números decimais e datas estão definidas no Schema XML. Nos campos numéricos inteiros, não incluir a vírgula ou ponto decimal. Nos campos numéricos com casas decimais, utilizar o “ponto decimal” na separação da parte inteira.

4.2.6. Colunas Das Tabelas De Leiaute De Mensagens

As colunas utilizadas nas tabelas que definem as mensagens XML contêm as informações descritas a seguir.

Tabela 4-4 – Colunas das Tabelas de Leiaute de Mensagens

Nome da Coluna	Informação contida
#	Número de referência da tag XML
Campo	Nome da tag XML
Ele	Tipo de elemento: A = Versão; Id = Identificador da TAG a ser assinada; G = Grupo; CG = Grupo exclusivo (Choice Group: somente um dos grupos pode existir); E = Elemento; CE = Elemento exclusivo (Choice Element: somente um dos elementos pode existir)
Pai	Número de referência da tag XML que contém esta tag XML
Tipo	Tipo de dado: C = Caractere (alfanumérico); N = Número; D = Data no formato AAAA-MM-DD; DH = Data e hora no formato UTC (AAAA-MM-DDThh:mm:ssTZD), onde AAAA = ano com quatro dígitos, MM = mês com dois dígitos, DD = dia com dois dígitos, T = letra “T”, HH = hora (de 00 a 23), MM = minuto, SS = segundo e TZD = distância em horas do meridiano de Greenwich (zona horária)
Ocor.	Quantidade de ocorrências: 1-1 elemento obrigatório com no máximo uma ocorrência; 0-1 elemento opcional com no máximo uma ocorrência; 1-n elemento obrigatório com no máximo “n” ocorrências; 0-n elemento opcional com no máximo “n” ocorrências
Tam.	Tamanhos aceitos, conforme notação e exemplos vistos na Tabela 4-5
Descrição/Observação	Comentários explicativos desta tag XML

Tabela 4-5 – Notação e Exemplos de Tamanhos de Elementos em Tabelas de Leiaute XML

Tam	Observação
x	Tamanho do elemento. Ex.: 5 – o campo deve conter um valor com cinco posições.
x-y	Tamanho mínimo de “x”, máximo de “y”. Ex.: 0-10 – o campo pode conter nenhum valor (tamanho “0”) até um valor de até dez posições.
xvn	Campo de valor, com tamanho de “x” posições na parte inteira, seguido pelo “ponto decimal” e com “n” casas decimais. Ex.: 11v4 – número com onze posições no inteiro e quatro casas decimais.
xv(n-m)	Campo de valor, com tamanho de “x” posições na parte inteira, seguido pelo “ponto decimal” e com entre “n” e “m” casas decimais. Ex.: 11v(0-6) – número com onze posições no inteiro, com zero a 6 casas decimais. No caso de “zero” casas decimais, o ponto decimal não deve ser informado.
(x-y)v(n-m)	Campo de valor com tamanho mínimo de “x” e no máximo de “y” posições, com entre “n” e “m” casas decimais. Ex.: 1-11v(0-6) – número deve ter entre uma e onze posições, com zero a seis casas decimais.
Valores separados por vírgulas	O elemento deve ser informado com o tamanho de uma das opções listadas. Ex.: 1, 3, 5, 8 – campo deve ser informado com um dos quatro tamanhos fixos na quantidade de caracteres.

4.3. Modelo Operacional

A solicitação de serviço deverá ser atendida na mesma conexão. Serviços síncronos: o processamento da solicitação de serviço é concluído na mesma conexão, com a devolução de uma mensagem com o resultado do processamento do serviço solicitado.

4.3.1. Número Do Protocolo

O número do protocolo (nProt) é gerado pelo Portal da Secretaria da Fazenda Estadual para identificar univocamente as transações realizadas de autorização de uso e de cancelamento de DCe. A regra de formação do número do protocolo pode ser vista na tabela abaixo.

Tabela 4-6 – Estrutura do Número do Protocolo (16 posições)

Posições	Conteúdo	Observação
1	Tipo de Autorizador	1 = Secretaria de Fazenda Estadual; 3 = SEFAZ Virtual RS
2 a 3	Código da UF	Código da UF do IBGE (Tabela 8-1)
4 a 5	Ano	2 posições para o ano
6	Identificação do Site Autorizador	Número do site que autorizou a DCe (0 para apenas um site)
7 a 16	Sequencial	10 posições para o sequencial no ano

A geração do número de protocolo é única e é utilizada por todos os Web Services que precisam atribuir um número de protocolo para o resultado do processamento.

4.3.2. Ambientes De Homologação E De Produção

As Secretarias de Fazenda Estaduais mantêm dois ambientes para recepção de DCe. O ambiente de homologação é específico para a realização de testes e integração das aplicações durante a fase de implementação e adequação do sistema de emissão de DCe, e nos casos em que este sistema sofre alterações após entrar em regime de operação normal.

A utilização pelo usuário emitente de qualquer um dos dois ambientes fica condicionada à prévia autorização da Secretaria de Fazenda, Finanças ou Tributação de sua UF, através do respectivo processo de credenciamento.

4.3.3. Validação da Estrutura XML das Mensagens dos Web Services

As informações são enviadas ou recebidas dos Web Services através de mensagens no padrão XML definido na documentação de cada Web Service. 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 com êxito ao Schema XML correspondente. Assim, os aplicativos das SEFAZ devem estar preparados para gerar as mensagens no leiaute em vigor, devendo ainda informar a versão do leiaute da estrutura XML da mensagem no campo versaoDados da área de cabeçalho da mensagem.

4.3.4. Schemas XML das Mensagens dos Web Services

Toda mudança de leiaute das mensagens dos Web Services implica na 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”, conforme os exemplos a seguir:

• DCe_v1.03.xsd – Schema XML da DCe, versão 1.03;
• leiauteDCe_v10.15.xsd – Schema XML dos tipos básicos da DCe, versão 10.15.

A maioria dos Schemas XML da DCe utiliza as definições de tipos básicos ou tipos complexos que estão definidos em outros Schemas XML (ex.: tiposBasico_v1.00.xsd). Nestes casos, a modificação de versão do Schema básico será repercutida no Schema principal.

As modificações de leiaute das mensagens dos Web Services podem ser causadas por necessidades técnicas ou em razão da modificação de alguma legislação. As modificações decorrentes de alteração da legislação deverão ser implementadas nos prazos previstos no ato normativo que introduziu a alteração. As modificações de ordem técnica serão divulgadas pela Coordenação Técnica do Sistema e poderão ocorrer sempre que se fizerem necessárias.

4.4. Versão Dos Schemas

4.4.1. Controle De Versão

O controle de versão de cada um dos schemas válidos para o Sistema Declaração de Conteúdo Eletrônica compreende uma definição nacional sobre:

• qual a versão vigente (versão mais atualizada);
• quais são as versões anteriores ainda suportadas por todas as SEFAZ.

Este controle de versões permite a adaptação dos sistemas de informática das SEFAZ participantes do Sistema em diferentes datas.

4.4.2. Liberação Das Versões Dos Schemas

Os schemas válidos para o Sistema da Declaração de Conteúdo eletrônica são disponibilizados no Portal Nacional da DCe, após terem sido liberados pela Coordenação Técnica do Sistema.

A cada nova liberação é disponibilizado um arquivo compactado contendo o conjunto de schemas a serem utilizados pelas SEFAZ para a geração dos arquivos XML. Este arquivo é denominado “Pacote de Liberação” e é numerado sequencialmente. Os pacotes de liberação são identificados pelas letras “PL”, seguidas do número do pacote. Exemplo: o pacote PL_001.zip é o “Pacote de Liberação” nº 1 de schemas da DCe.

O detalhamento de cada Web Service (leiaute das mensagens de entrada e de retorno, descrição do processo, regras de validação e final do processamento) está nas páginas específicas indicadas abaixo:

• Web Service – DCeAutorizacao – recepção de mensagens da DCe (método dceAutorizacao; versão compactada DCeAutorizacaoZip).
• Web Service – DCeConsultaProtocolo – consulta da situação atual da DCe (método dceConsulta).
• Web Service – DCeStatusServico – consulta do status do serviço (método dceStatusServico).
• Web Service – DCeRecepcaoEvento (Parte Geral) – interface genérica de registro de eventos (método dceRecepcaoEvento).
• Web Service – DCeRecepcaoEvento (Cancelamento) – evento 110111.
• Web Services de Distribuição da DC-e – DCeDistNSUAut, DCeDistribuicao e arquivoXMLDCe, conforme o BT 2024.001 (compartilhamento entre a SEFAZ-PR autorizadora, a SVRS e as demais administrações tributárias).

A DCe também dispõe da Consulta Pública, tratada no item 6 desta página.

6.1. Consulta Da DCe

A Consulta, individualmente realizada através da Internet nos portais das Administrações Tributárias, retornará o conteúdo da DCe.

Esta consulta poderá ser efetuada pelo usuário do serviço de duas formas: pela digitação em página web dos 44 caracteres numéricos da chave de acesso constantes impressos da DACE, ou consulta via leitura do QR-Code impresso ou disponibilizado em meio eletrônico, utilizando aplicativos gratuitos de leitura de QR Code, disponíveis em dispositivos móveis como smartphones e tablets.

6.2. Consulta Pública Da DCe Via QR-Code

A aplicação de consulta pública da DCe via QR-Code efetuará validações do conteúdo de informações constantes do QR-Code versus o conteúdo da respectiva DCe.

Nesta hipótese, o usuário deverá apontar o seu dispositivo móvel (smartphone ou tablet) para a imagem do QR-Code gerada no DACE. O leitor de QR-Code se encarregará de interpretar a imagem e efetuar a consulta da DCe da URL recuperada no Portal da SEFAZ.

Como resultado da consulta QR-Code, deverá ser apresentada ao usuário do serviço a validade da DCe/DACE. Eventuais divergências encontradas entre as informações da DCe constantes dos parâmetros do QR-Code deverão ser informadas em área de mensagem a ser disponibilizada na tela de resposta da consulta pública.

Relação de mensagens de validações na consulta da DCe

Código	Regra de Validação	Exibir na Consulta
201	Se a Chave de Acesso da DCe não preenchida ou com menos de 44 caracteres.	Problemas no preenchimento da Chave de Acesso da DCe
202	Se dígito verificador da Chave de Acesso da DCe inválido.	Problemas na Chave de Acesso do DCe (dígito verificador inválido)
203	Se o modelo constante da Chave de Acesso difere de 99 (DCe), ou CNPJ do emitente constante na Chave de Acesso com dígito verificador inválido, ou UF da chave de acesso diferente do código da UF da consulta.	Problemas na Chave de Acesso da DCe (modelo ou CNPJ ou UF inválido)
204	Se o parâmetro tpAmb (Identificação do ambiente) não preenchido ou difere de 1 ou 2 no QR-Code.	Inconsistência de Informações no QR-Code (tipo ambiente)
205	Se a forma de emissão for 1 (normal) e a DCe da chave de acesso não encontrada na base de dados.	DCe inexistente.
206	Se a forma de emissão for de contingência offline e a DCe não for encontrada na base de dados e a assinatura do QR-Code estiver CORRETA.	DCe emitida em contingência e assinatura do QR-Code VÁLIDA, porém não consta na base de dados. Consulte novamente após 24h.
207	Se a forma de emissão for de contingência offline e a DCe não for encontrada na base de dados e a assinatura do QR-Code estiver ERRADA.	DCe inválido. (Assinatura do QR-Code inválida)
208	Se DCe possuir evento de cancelamento.	DCe foi Cancelado – Documento Inválido

Para consultar as URLs por UF utilizadas no QR-Code, acesse: https://www.fazenda.pr.gov.br/dce/qrcode.

O modelo operacional atual da DCe prevê a utilização de “Contingência Offline”.

Nesta modalidade, o emitente que estiver com problemas técnicos para autorização da DCe poderá emiti-la em contingência offline, imprimir o DACE e, depois de superado o problema técnico, transmitir o arquivo XML da DCe para autorização. O prazo estabelecido pelo Fisco, atualmente, é o final do primeiro dia útil subsequente contado a partir de sua emissão.

Todavia, alertamos que as DCe devem ser autorizadas, preferencialmente, em tempo real, antes da ocorrência do transporte, e que as alternativas de contingência somente devem ser acionadas em situações extremas, que interfiram de forma significativa.

Assim, a emissão da DCe em contingência off-line deve ser tratada como exceção, sendo que a regra deve ser a emissão com autorização em tempo real.

O Fisco poderá solicitar esclarecimentos e até mesmo restringir ao emitente a utilização da modalidade de contingência offline, caso seja identificado que o emissor da DCe utiliza a contingência em demasia e sem justificativa aceitável.

7.1. Detalhes técnicos da Contingência off-line

Ao emitir uma DCe em contingência, algumas modificações deverão ser realizadas no arquivo XML, caracterizando esse tipo de emissão.

A primeira providência é selecionar a forma de emissão correta no campo tpEmis com a opção Contingência offline (2).

Na escolha de contingência off-line da DCe não é necessária a adoção de série específica ou a utilização de papel especial. Todavia, deve ser observado o prazo de envio para autorização da DCe até o final do primeiro dia útil subsequente contado a partir de sua emissão em contingência.

A DACE da DCe emitida em contingência deverá conter a informação impressa “EMITIDO EM CONTINGÊNCIA”.

Além disso, o QR-Code impresso na DACE da DCe emitida em contingência conterá o parâmetro sign, assinando a chave de acesso com o certificado digital que efetuou a assinatura da DCe. Isto possibilita que, na consulta via QR-Code pelo usuário, a SEFAZ retorne a informação de que se trata de emissão em contingência e o prazo máximo para o documento fiscal eletrônico constar da base de dados do Fisco, além de garantir a autoria do emitente da DCe pelo certificado digital.

8.1. Tabela De Código De UF Do IBGE

A DCe utiliza a codificação adotada pelo Instituto Brasileiro de Geografia e Estatística (IBGE) para representar o código da UF.

Tabela 8-1 – Tabela de Código de UF do IBGE

Região Norte	Região Nordeste	Região Sudeste	Região Sul	Região Centro-Oeste
11 – Rondônia 12 – Acre 13 – Amazonas 14 – Roraima 15 – Pará 16 – Amapá 17 – Tocantins	21 – Maranhão 22 – Piauí 23 – Ceará 24 – Rio Grande do Norte 25 – Paraíba 26 – Pernambuco 27 – Alagoas 28 – Sergipe 29 – Bahia	31 – Minas Gerais 32 – Espírito Santo 33 – Rio de Janeiro 35 – São Paulo	41 – Paraná 42 – Santa Catarina 43 – Rio Grande do Sul	50 – Mato Grosso do Sul 51 – Mato Grosso 52 – Goiás 53 – Distrito Federal

8.2. Tabela De Código De Município Do IBGE

A DCe utiliza a codificação adotada pelo Instituto Brasileiro de Geografia e Estatística (IBGE) para representar o código de município. Este código é composto de 7 dígitos numéricos, com os dois primeiros representando a UF. Os códigos de município das capitais dos estados podem ser encontrados na tabela abaixo. Os códigos dos demais municípios podem ser encontrados na página daquele Instituto na Internet (https://www.ibge.gov.br).

Tabela 8-2 – Brasília e Capitais de Estado na Tabela de Código de Município do IBGE

Município	Código	Estado	Código
Aracaju	2800308	Sergipe	28
Belém	1501402	Pará	15
Belo Horizonte	3106200	Minas Gerais	31
Boa Vista	1400100	Roraima	14
Brasília	5300108	Distrito Federal	53
Campo Grande	5002704	Mato Grosso do Sul	50
Cuiabá	5103403	Mato Grosso	51
Curitiba	4106902	Paraná	41
Florianópolis	4205407	Santa Catarina	42
Fortaleza	2304400	Ceará	23
Goiânia	5208707	Goiás	52
João Pessoa	2507507	Paraíba	25
Macapá	1600303	Amapá	16
Maceió	2704302	Alagoas	27
Manaus	1302603	Amazonas	13
Natal	2408102	Rio Grande do Norte	24
Palmas	1721000	Tocantins	17
Porto Alegre	4314902	Rio Grande do Sul	43
Porto Velho	1100205	Rondônia	11
Recife	2611606	Pernambuco	26
Rio Branco	1200401	Acre	12
Rio de Janeiro	3304557	Rio de Janeiro	33
Salvador	2927408	Bahia	29
São Luís	2111300	Maranhão	21
São Paulo	3550308	São Paulo	35
Teresina	2211001	Piauí	22
Vitória	3205309	Espírito Santo	32

Informar o código 9999999 e o nome do município “EXTERIOR” para as operações que envolvam localidades do exterior.

Quando a operação envolver regiões administrativas (ex.: cidades-satélites do DF), deve ser considerado o município sede como localidade da operação.