Legislação Tributária
ICMS

Ato:Ato COTEPE/ICMS
Número:10
Complemento:/2014
Publicação:04/02/2014
Ementa:Dispõe sobre a Especificação de Requisitos do Medidor Volumétrico de Combustíveis (ER-MVC).
Assunto:Especificação de Requisitos do Medidor Volumétrico de Combustíveis (ER-MVC)




Nota Explicativa:
Nota: " Os documentos contidos nesta base de dados têm caráter meramente informativo. Somente os textos publicados no Diário Oficial estão aptos à produção de efeitos legais."

Texto:
ATO COTEPE/ICMS 10, DE 14 DE MARÇO DE 2014
. Publicado no DOU de 26.03.14.
. Consolidado até o Ato COTEPE/ICMS 38/2021.
. Despacho nº 74/2021, publicado no DOU de 20.10.2021, p. 73 - Torna público que transitou em julgado a decisão que estabeleceu como normas válidas as seguintes, tornando sem efeito as anotações em contrário nos referidos atos do Confaz: Ato COTEPE/ICMS nº 10, de 14 de março de 2014, e suas alterações promovidas pelo Ato COTEPE/ICMS nº 32, de 30 de julho de 2014, Ato COTEPE/ICMS nº 6, de 25 de março de 2015, Ato COTEPE/ICMS nº 50, de 25 de novembro de 2015, Ato COTEPE/ICMS nº 35, de 23 de novembro de 2016 e Ato COTEPE/ICMS nº 22, de 12 de junho de 2019.
. Credenciamento de empresa para análise de MVC: Despacho 85/2014, publicado no DOU de 19.05.2014.
. Republicado no DOU de 20.02.2018, por determinação judicial, com as alterações promovidas pelos Atos COTEPE/ICMS 32/2014, 06/2015, 50/2015 e 35/2016, pelo Despacho 25/2018.
(*) Republicado o Despacho 25/2018 do Secretário-Executivo do CONFAZ, no DOU de 08.03.2018, Seção 1, p. 115 a 128, que republica o Ato COTEPE/ICMS 10/2011, por determinação judicial, com as alterações promovidas pelos Atos COTEPE/ICMS 32/2014, 06/2015, 50/2015 e 35/2016, por ter sido publicado com incorreção no DOU de 20.02.2018, Seção 1, p. 09.
. Atribuição de código de fabricante e código de modelo: Despacho 119/2018, publicado no DOU de 21.09.2018, p. 38.
. Alterado pelos Atos COTEPE/ICMS 22/2019, 38/2021.

O Secretário Executivo do Conselho Nacional de Política Fazendária - CONFAZ, no uso de suas atribuições que lhe confere o art. 12, XIII, do Regimento da COTEPE/ICMS, de 12 de dezembro de 1997, por este ato, informa que a Comissão Técnica Permanente do ICMS (COTEPE/ICMS), na sua 212ª reunião extraordinária, realizada no dia 14 de março de 2014, em Brasília, DF, aprovou a Especificação de Requisitos do Medidor Volumétrico de Combustíveis (ER-MVC) prevista no Convênio ICMS 59/11, de 8 de julho de 2011.

Art. 1º Fica aprovada a Especificação de Requisitos composta pelos Anexos I a IV deste ato, na versão 01.01, que deve ser observada pelo Medidor Volumétrico de Combustíveis (MVC).

§ 1º A Especificação de Requisitos a ser observada pelo Medidor Volumétrico de Combustíveis de Transição (MVCT) é composta pelos Anexos V a VII deste ato, na versão 01.00. (Renumerado de p. único para § 1º pelo Ato COTEPE/ICMS 22/19)

§ 2º Para os efeitos dos incisos II e III, do item 3.3.2, do Anexo I ou dos incisos II e III, do item 2.2.4.2, do Anexo V deverá ser publicado Despacho emitido pelo Diretor do Conselho Nacional de Política Fazendária - CONFAZ, indicando o código do fabricante ou importador e o código do modelo do equipamento. (Nova redação dada pelo Ato COTEPE/ICMS 38/2021, efeitos a partir de 1º.08.2021) § 2º Para os efeitos dos incisos II e III, do item 3.3.2, do Anexo I deverá ser publicado Despacho emitido pelo Diretor do Conselho Nacional de Política Fazendária – CONFAZ, indicando o código do fabricante ou importador e o código do modelo do equipamento.

Art. 2º O Diagrama de Blocos constante do Anexo IV corresponde a representação gráfica do funcionamento do Medidor Volumétrico de Combustíveis (MVC), devendo ser analisado em conjunto com os requisitos descritos nos Anexos I a III e o Diagrama de Blocos constante do Anexo VII corresponde a representação gráfica do funcionamento do Medidor Volumétrico de Combustíveis de Transição (MVCT), devendo ser analisado em conjunto com os requisitos descritos nos Anexos V e VI

Art. 3º As Unidades Federadas poderão estabelecer critérios para o uso do Medidor Volumétrico de Combustível.

Art. 4º Para fins deste Ato considera-se:
I – fiscalização: os órgãos responsáveis pela fiscalização de tributos estaduais e os órgãos estaduais responsáveis pela fiscalização do meio ambiente;
II – fiscalização tributária: os órgãos responsáveis pela fiscalização de tributos estaduais;
III – fiscalização ambiental: os órgãos estaduais responsáveis pela fiscalização do meio ambiente.

Art. 5º Este ato entra em vigor na data de sua publicação no Diário Oficial da União, produzindo seus efeitos a partir do primeiro dia do mês subsequente ao de sua publicação.

ANEXO I
ESPECIFICAÇÃO DE REQUISITOS DO MEDIDOR VOLUMÉTRICO DE COMBUSTÍVEIS (ER-MVC)

SUMÁRIO

1. INTRODUÇÃO
1.1. Disposições Gerais
1.2. Da Concepção de Funcionamento
1.3. Da Arquitetura
1.4. Abreviações e Definições

2. DESCRIÇÃO DOS TIPOS
2.1. Medidor Volumétrico de Combustíveis Compacto (MVCC)
2.2. Medidor Volumétrico de Combustíveis Dual (MVCD)
2.3. Requisitos Obrigatórios

3. MÓDULO ÚNICO SEGURO (MUS)

3.1. Descrição dos Componentes do MUS
3.1.1. Unidade Central de Processamento (UCP)
3.1.2. Relógio de Tempo Real (RTR)
3.1.3. Memória de Dados Históricos (MDH)
3.1.4. Módulo de Transmissão de Dados à Fiscalização (MTF)

3.2. Software Básico (SB)
3.3. Identificações e Registros
3.3.1. Número de Identificação do MUS (NIM)
3.3.2. Número de Identificação (NID)
3.3.3. Identificação do Contribuinte Usuário (IC)
3.3.4. Controle de Manutenção Técnica (CMT)
3.3.5. Controle de Variáveis de Medição (CVM)
3.3.6. Parâmetro de Variação de Volume (PVV)
3.3.7. Parâmetro do Tempo de Medidas (PTM)
3.3.8. Registro da Descarga de Combustíveis (RDC)
3.3.9. Registro do Estoque de Combustíveis (REC)
3.3.10. Registro de Saídas dos Bicos (RSB)
3.3.11. Registro de Saídas das Sondas (RSS)
3.3.12. Registro de Situação Operacional (RSO)

3.4. Requisitos Estruturais do MUS
3.4.1. Memória de Dados Históricos (MDH)
3.4.2. Resina de Proteção
3.4.3. Lacração Lógica
3.4.3.1. Requisitos do Acesso Físico
3.4.3.2. Requisitos do Acesso Lógico
3.4.4. Bootloader (BLD)

3.5. Assinatura Digital
3.5.1. Assinatura Digital do AEF
As assinaturas digitais devem ser implementadas utilizando-se o padrão de assinatura digital “XML Digital Signature”, com chave privada de 1024 bits, com padrões de criptografia assimétrica RSA, algoritmo “message digest” SHA-1 e utilização das transformações Enveloped e C14N.
O conteúdo constante do AEF produzido com a utilização deste processo de certificação presume-se verdadeiro em relação aos signatários, na forma do art. 219 da Lei nº 10.406, de 10 de janeiro de 2002.
Para todos os arquivos eletrônicos digitalmente assinados, extraídos de equipamentos MVC, utilizar-se-ão as chaves previamente especificadas, certificadas pelo próprio fabricante, em conformidade com a faculdade prevista no § 2º do art. 10 da Medida Provisória nº 2.200-2, de 24 de agosto de 2001.
As mensagens utilizam o padrão de assinatura XML definido no endereço eletrônico "http://www.w3.org/TR/xmldsig-core/
3.5.2.Assinatura Digital do Software Básico

3.6. Validação pelo Bootloader

3.7. Interface com MDH (IDH)

3.8. Interface de Transmissão a Fiscalização (ITF)

3.9. Inicialização do MUS

3.10. Modo de Intervenção Técnica (MIT)
3.10.1. Atualização do Software Básico
3.10.2. Ajuste do Relógio de Tempo Real

4. MÓDULO DE CONTROLE E MEDIÇÃO (MCM)

4.1. Descrição dos Componentes do MCM
4.1.1. Controlador de Medição (CMD)
4.1.2. Memória de Trabalho (MTR)
4.1.3. Controle de Interface e Sensoriamento (CIS)
4.1.4. Alimentação e Baterias (ALM)
4.1.5. Interface Homem Máquina (IHM)
4.1.6. Interface de Gerenciamento e Manutenção (IGM)

4.2. Conectores com Acesso Externo ao MVC

4.3. Eventos do MVC

5. TRANSMISSÃO À FISCALIZAÇÃO

5.1. Padrões Técnicos
5.1.1. Padrão do documento xml
5.1.1.1. Padrão de Codificação
5.1.1.2. Padrão Schema
5.1.1.3. Montagem do Arquivo
5.1.2. Padrão de Comunicação

5.2.Padrão de Mensagem dos Web Services
5.2.1. Validação da Estrutura XML das Mensagens dos Web Services
5.2.2. Schemas XML das Mensagens dos Web Services

5.3. Ambiente Virtual

5.4. Especificação dos Web Services

6. REQUISITOS DA OPERAÇÃO COM A FISCALIZAÇÃO

6.1. Processo de Envio de Dados à Fiscalização

6.2. Processo de Gravação do DCD

6.3. Alteração de Parâmetros do MVC
6.3.1. Envio de Eventos à Fiscalização
6.3.2. Solicitação de Alteração de endereço URL
6.3.3. Alteração do Parâmetro de Periodicidade de Envio
6.3.4. Alteração do Parâmetro de Variação de Volume
6.3.5. Alteração do Parâmetro de Tempo de Medidas

6.4. Situações Operacionais
6.4.1. Leitura de MDH em Virtude de Troca de MUS
6.4.2. Perda de Conexão

7. NORMAS ATENDIDAS
7.1. Normas MUS
7.2. Normas MCM

1. INTRODUÇÃO

1.1. Disposições Gerais
Este Anexo especifica os requisitos que devem ser atendidos pelo Medidor Volumétrico de Combustíveis (MVC) a que se refere a cláusula terceira do Convênio ICMS 59/11, com a finalidade de estabelecer uma base comum para a sua fabricação e uso, bem como para o entendimento entre os diversos agentes envolvidos com as atividades relacionadas ao equipamento.

1.2. Da Concepção de Funcionamento
O equipamento Medidor Volumétrico de Combustíveis (MVC), para atender suas finalidades, deverá atender as seguintes funções:
I – apurar, com base nas sondas de medições, o volume em litros dos estoques presentes nos compartimentos dos tanques de combustíveis;
II – apurar, com base nas sondas de medições, a variação volumétrica do volume em litros das descargas de combustíveis nos compartimentos dos tanques;
III – apurar, com base nas sondas de medições, a variação volumétrica do volume em litros das saídas de combustíveis nos compartimentos dos tanques;
IV – apurar, com base no concentrador ou unidades abastecedoras, o volume em litros das saídas de combustíveis realizadas por meio dos bicos das bombas de abastecimento;
V – registrar e manter na memória de dados históricos, de forma segura, o registro histórico das operações volumétricas e eventos, nas hipóteses e situações definidas neste Anexo;
VI – transferir informações que possibilitem disponibilizar ao sistema de gestão do contribuinte o registro das operações do equipamento e outras informações gerenciais;
VII – enviar os registros das operações e eventos armazenados na memória de dados históricos aos órgãos fiscalizadores;
VIII - disponibilizar informações que possibilitem ao contribuinte e à fiscalização extrair da memória, de forma local, o histórico dos registros das operações e eventos;
IX- disponibilizar informações ao usuário que possibilitem acompanhar o gerenciamento, parametrização e configuração do equipamento a fim de obter informações gerenciais e de controle.

1.3. Da Arquitetura
O Medidor Volumétrico de Combustíveis constitui-se em uma estrutura de um gabinete único ou dual, conforme diagrama de blocos previsto no Anexo IV, com as seguintes características:
I – Para medição e monitoramento, funcionar integrado e interligado com:
as sondas de medição, que devem estar instaladas em todos os compartimentos dos tanques de armazenamento de combustíveis líquidos, deverão ser reconhecidas pelo MVC por protocolo do fabricante que assegure sua autenticidade e inviolabilidade;
os sensores ambientais;
as unidades abastecedoras de combustíveis, admitido a utilização do concentrador de bombas, caso o MVC não suporte o seu tratamento direto;
II – Para o usuário, funcionar integrado e interligado a diversos dispositivos previstos neste Anexo, disponibilizando interfaces elétricas e lógicas para a realização das funções de interface, de forma local no MVC ou remota via sistemas de gestão, vedada a alteração dos dados previstos neste Anexo após o processamento realizado pelo MVC;
III – Para o contribuinte e fiscalização, disponibilizar de modo seguro, interface e meios que possibilitem extrair os dados históricos dos registros das operações armazenados na memória do equipamento;
IV – Para armazenamento e validação, disponibilizar recursos de armazenamento de registros de forma segura com a capacidade de validar os dispositivos onde está prevista a sua autenticação e validação.

1.4. Abreviações e Definições
AEF – Arquivo Eletrônico da Fiscalização: conjunto de dados capturados pelo MVC, gravado em memória não volátil, a serem disponibilizados à fiscalização de forma local ou remota.
ALM – Módulo de Fonte e Baterias: componente responsável pelo fornecimento de energia ao MVC, possuindo gerenciamento para alimentação em caso de falha de energia elétrica externa.
BLD – Bootloader: conjunto fixo de rotinas residentes no MUS, executadas imediatamente após o hardware reset de inicialização da UCP, que implementa as funções de validação do SB ativo e de controle da substituição de versão do SB, sendo que, após o encerramento da execução das funções do BLD inicia a execução das funções do SB.
CIS – Controle de Interface e Sensoriamento: componente que implementa a interface elétrica ou mecânica, realizando o controle, acesso e interligação dos sensores ambientais, das sondas de medição e do concentrador.
CMD – Controlador de Medição: componente responsável pelo gerenciamento das informações dos dispositivos, realizando toda aquisição de dados necessários para controlar as requisições de medição e sensoriamento.
CMT - Controle de Manutenção Técnica: histórico das manutenções gravadas na MDH.
CON – Concentrador: dispositivo com a capacidade de realizar de forma eletrônica a captura do volume das saídas de combustíveis das unidades abastecedoras, disponibilizando-as ao MVC.
CVM - Controle de Variáveis de Medição: identificação das variáveis que afetem as medições e comportamento do MCM.
DG – Dispositivo de Gestão: elemento responsável por receber informações do MVC necessárias à gestão do Posto de Serviço.
DCD – Dispositivo de Captura de Dados: dispositivo de captura de dados específico e exclusivo com a finalidade de receber as informações gravadas na memória de dados históricos.
EFD – Escrituração Fiscal Digital: na forma do Ato COTEPE/ICMS 09/08
IDH – Interface com MDH: componente responsável pela conexão do DCD de forma local, para captura das informações existentes na MDH para fins de auditoria e fiscalização.
IGM – Interface de Gerenciamento e Manutenção: módulo responsável pelo controle e interface do fluxo de informações a dispositivos de gestão externos.
IHM – Interface Homem Máquina: módulo responsável pela apresentação das informações do MVC ao usuário, podendo controlar uma ou mais interfaces opcionais de apresentação, tais como displays, teclados, telas, dispositivos de posicionamento (mouse), impressoras, entre outros.
ITF – Interface de Transmissão à Fiscalização: define o tipo físico da interface para transmissão de dados pela internet aos órgãos fiscalizadores.
LL – Lacração Lógica: capacidade de monitorar e registrar logicamente as comunicações, com objetivo de controlar acessos, identidade dos dispositivos e garantir a validade da origem dos dados.
MCM – Módulo de Controle e Medição: módulo que realiza as funções de controle, medição e sensoriamento previstos para o MVC, atendendo todos os requisitos de hardware necessários para interligação dos equipamentos que cumprirão estas funções, sendo responsável pela leitura do volume de combustível dos compartimentos, dos sensores ambientais, dos dispositivos associados e do concentrador ou das unidades de abastecimento, implementando os requisitos de software necessários para executar todos os algoritmos e cálculos para determinação das medições, eventos e alarmes do sistema.
MDH – Memória de Dados Históricos: memória responsável pelo armazenamento seguro dos registros e eventos previstos neste Anexo.
MIT – Modo de Intervenção Técnica: estado operacional no qual é possibilitada a realização de manutenções no MVC.
MTR – Memória de Trabalho: componente de armazenamento de informações utilizada pelo MCM para processar os dados necessários ao funcionamento do sistema, sem capacidade de interferir no funcionamento do MUS.
MTF – Módulo de Transmissão de dados à Fiscalização: componente com capacidade de transmitir de forma segura e criptografada as informações armazenadas no MUS aos órgãos fiscalizadores.
MUS – Módulo Único Seguro: módulo que contém os componentes que garantem a inviolabilidade e segurança do recebimento, armazenamento e, quando requerido, o envio de informações.
MVC – Medidor Volumétrico de Combustíveis: equipamento que possui simultaneamente as funções de medição volumétrica de combustíveis e de monitoramento ambiental, que permitem, independente do Programa Aplicativo Fiscal (PAF-ECF), do Emissor de Cupom Fiscal (ECF) ou de qualquer outro equipamento de automação comercial, a captura automática, armazenamento, extração de dados e transmissão aos órgãos fiscalizadores das informações definidas neste Anexo.
NID - Número de Identificação: número que identifica o equipamento.
NIN - Número de Identificação do MUS: número que identifica o MUS.
PAE – Parâmetro de Alteração de Endereço: parâmetro para alteração do endereço URL de envio dos dados.
PAR - Parâmetro de Atualização do Relógio: parâmetro definido pela fiscalização tributária contendo a URL de referência a ser usada para ajuste do RTR.
PEM - Protocolo de Envio do MVC: número gerado pelo próprio MVC que identificará de modo único o bloco de registros enviados.
PHV – Programação do Horário de Verão: data de inicio e fim da vigência do horário de verão, indicando ao MVC que no início deste período o RTR deverá ser adiantado em uma hora e no fim deste período o RTR deverá ser atrasado em uma hora.
PPE - Parâmetro de Periodicidade de Envio: contém o intervalo de tempo, em minutos, que determina a periodicidade de envio aos órgãos de fiscalização de todos os eventos registrados na MDH, pendentes de envio.
PRE - Parâmetro de Requisição de Eventos: parâmetro definido pela fiscalização contendo as datas de início e término de eventos a serem enviados.
PRF - Protocolo de Recebimento da Fiscalização: número gerado pelo órgão de fiscalização que identifica um envio do MVC de maneira única ao sistema do órgão, atestando a confirmação da entrega dos dados.
PTM - Parâmetro de Tempo de Medidas: intervalo de tempo, em minutos, para que o MVC realize uma REC.
PVV - Parâmetro de Variação de Volume: volume, em litros, de variação de estoque que gera um registro de descarga de combustível.
RDC - Registro de Descarga de Combustível: volume em litros da descarga de combustível.
REC - Registro de Estoque de Combustível: volume em litros do estoque de combustível.
RSB - Registro de Saídas dos Bicos: saídas de combustíveis realizadas pelos bicos das bombas de abastecimento.
RSO - Registro de Situação Operacional: indicação de que o equipamento MVC está ativo e em operação com a fiscalização ambiental.
RSS - Registro de Saídas das Sondas: volume de saídas de combustíveis medido pelas sondas de medição.
RTR – Relógio de Tempo Real: dispositivo capaz de fornecer a data e a hora para o funcionamento do MVC.
SB – Sofware Básico: conjunto fixo de rotinas residentes na UCP, que implementa as funções de controle do MVC.
SA – Sensor Ambiental: dispositivo capaz de identificar a presença de líquidos para fins de controle ambiental nos locais monitorados.
SM – Sonda de Medição: dispositivo de medição de nível, instalado nos compartimentos dos tanques de combustíveis líquidos.
TVA – Tentativa de Violação e Acesso: é o registro na MDH da tentativa de acesso físico indevido às partes protegidas pela lacração lógica.
UCP – Unidade Central de Processamento: componente responsável pelo gerenciamento e segurança do MUS.
Web Services – solução utilizada pela fiscalização para integrar seus sistemas com o MVC, com a finalidade de receber e enviar informações em formato XML.

2. DESCRIÇÃO DOS TIPOS
O Medidor Volumétrico de Combustíveis (MVC) compreende dois tipos:

2.1. Medidor Volumétrico de Combustíveis Compacto (MVCC)
Equipamento que reúne em um único gabinete as funções primárias de medição, monitoramento ambiental e de transmissão de dados, possuindo módulos distintos denominados, respectivamente, de Modulo de Controle e Medição (MCM) e Modulo Único Seguro (MUS), conforme diagrama de blocos do Anexo IV.

2.2. Medidor Volumétrico de Combustíveis Dual (MVCD)
Equipamento que reúne em gabinetes distintos o Módulo de Controle e Medição (MCM), com as funções primárias de medição e monitoramento ambiental, e o Módulo Único Seguro (MUS), com a função de transmissão de dados, conforme diagrama de blocos do Anexo IV.

2.3. Requisitos Obrigatórios
O MVC deve ter capacidade mínima de suportar doze compartimentos de estocagem de combustíveis líquidos, todo sensoriamento ambiental associado e registrar como evento todas as aberturas do gabinete que contém o MUS, devendo o Módulo de Controle e Medição (MCM) e o Modulo Único Seguro (MUS), tanto no modelo MVCC quanto no modelo MVCD, ter sua interligação protegida por Lacração Lógica (LL).

3. MÓDULO ÚNICO SEGURO (MUS)
Conjunto de componentes reunidos em um único módulo protegido por Lacração Lógica (LL) com as funções primárias de capturar, registrar, disponibilizar e enviar as informações provenientes do Módulo de Controle e Medição (MCM).

3.1. Descrição dos Componentes do MUS: o MUS deve possuir os seguintes componentes, podendo agregar outros, desde que não conflitem com os requisitos previstos neste Ato.
3.1.1. Unidade Central de Processamento (UCP): recursos de hardware e software programáveis, previstos neste Anexo, responsáveis pela captura das informações provenientes do Módulo de Controle e Medição (MCM), com capacidade de realizar a verificação da autenticidade do seu Software Básico (SB) após reset do processador, conforme previsto no item 3.4.4.
3.1.2. Relógio de Tempo Real (RTR): componente residente no MUS responsável pelo registro da data, hora, minuto e segundos para gravação da estampa de tempo das informações.
3.1.3. Memória de Dados Históricos (MDH): deve possuir requisitos estruturais conforme item 3.4.1, sendo responsável por armazenar, por no mínimo 5 (cinco) anos, os eventos descritos no Anexo II, não sendo permitida sua manutenção e substituição.
3.1.4. Módulo de Transmissão de Dados à Fiscalização (MTF): componente responsável por enviar via Internet aos órgãos fiscalizadores os registros e eventos gravados na MDH, previstos no Anexo II, com endereçamentos de URL configuráveis, sendo que o formato, protocolo e a segurança na transmissão são os definidos no item 5, devendo toda alteração de endereçamento de URL ser registrada como evento.

3.2. Software Básico (SB)
O Software Básico é o conjunto fixo de rotinas que implementa as funções de controle do MUS previstas neste Anexo, sendo que o dispositivo onde está armazenado, instalado e validado, deve permitir acesso para leitura direta do seu conteúdo por meio de dispositivo específico para este fim, durante a realização de análise estrutural ou de perícia técnica solicitada pela fiscalização, bem como via conector de comunicação externa utilizando programa aplicativo específico desenvolvido pelo fabricante do MVC e entregue a fiscalização. A versão do SB pode ser atualizada remota ou localmente e deve ser identificada com 6 (seis) dígitos decimais, no formato XX.XX.XX, em que valores crescentes indicam versões sucessivas do software, obedecendo aos seguintes critérios:
I - o primeiro e o segundo dígitos devem ser incrementados de uma unidade, a partir do valor inicial 01, sempre que houver atualização da versão por motivo de mudança na legislação;
II - o terceiro e o quarto dígitos devem ser incrementados de uma unidade, a partir do valor inicial 00, sempre que houver atualização da versão por motivo de correção de defeito;
III - os dois últimos dígitos podem ser utilizados livremente, a partir do valor inicial 00, excluídas as situações previstas nas alíneas anteriores.

3.3. Identificações e Registros
Deve ficar registrado na MDH, devidamente protegido por Lacração Lógica (LL) do MUS, no mínimo as seguintes identificações e registros:
3.3.1. Número de Identificação do MUS (NIM): o MUS deve possuir identificação única composta por 5 (cinco) caracteres numéricos, devendo ser gravado uma única vez na MDH, não permitindo ao equipamento disponibilizar comandos para apagamento ou alteração deste número de identificação.
3.3.2. Número de Identificação (NID): o MVC deve possuir um número único que permita a identificação individualizada do equipamento, devendo ser gravado uma única vez na MDH, sendo vedado possuir comandos para apagamento ou alteração do NID, sendo permitida a utilização de mais de um MVC por estabelecimento.
O NID deverá ser visualizado na IHM sempre que um DCD for inserido no IDH, sendo representando por um conjunto de 20 (vinte) caracteres alfanuméricos composto da seguinte forma:
I - o caracter “D”;
II - os dois primeiros caracteres: para registro do código do fabricante ou importador, atribuído pela Secretaria Executiva do CONFAZ;
III - o terceiro e o quarto caracteres: para registro do código do modelo do equipamento, atribuído pela Secretaria Executiva do CONFAZ;
IV - o quinto e sexto caracteres: para indicar o ano de fabricação;
V - o sétimo, oitavo, novo, décimo e décimo primeiro caracteres: para o Número de Identificação do MUS conforme item 3.3.1;
VI - os demais caracteres devem ser utilizados pelo fabricante ou importador de forma a individualizar o equipamento.
3.3.3. Identificação do Contribuinte Usuário (IC): o contribuinte usuário será identificado no MVC por meio de seus números de inscrições no CNPJ e Inscrição Estadual, que serão gravados na MDH.
3.3.4. Controle de Manutenção Técnica (CMT): as eventuais manutenções técnicas a serem realizadas no MCM devem ter seu histórico de início e fim registradas na MDH com a respectiva data, hora, minuto e segundos, devendo ser realizado um REC imediatamente posterior ao evento de CMT e, quando o equipamento possibilitar, um REC imediatamente anterior ao CMT.
3.3.5. Controle de Variáveis de Medição (CVM): o MVC deve registrar como evento, de forma automática, todas as alterações de variáveis que afetem as medições e comportamento do MCM, tais como tabelas de arqueamento, medidas de tanque, cadastro de dados do local, entre outras, exceto parâmetros definidos pela fiscalização tributária, contendo data, hora, minuto e segundos da operação, descritivo da alteração realizada e se a operação foi executada pelo fabricante ou contribuinte, devendo ser realizado um REC imediatamente anterior e imediatamente posterior ao evento de CVM.
3.3.6. Parâmetro de Variação de Volume (PVV): volume de variação mínima positiva, em litros, definido pela Unidade da Federação, para que o MVC registre uma RDC, sendo parametrizado pelo fabricante a variação mínima de 200 litros no intervalo inferior a um minuto.
3.3.7. Parâmetro de Tempo de Medidas (PTM): intervalo de tempo definido pela Unidade da Federação para que o MVC realize um REC, sendo parametrizado pelo fabricante o intervalo mínimo de 30 minutos.
3.3.8. Registro de Descarga de Combustível (RDC): volume, em litros, da descarga de combustível, registrada de forma automática, contendo o tipo de combustível, o respectivo compartimento, a temperatura, a data, hora, minutos e segundos da ocorrência, permitindo ao usuário, na impossibilidade do registro automático, realizar o RDC manualmente em situações de contingência, devendo, em qualquer situação, os compartimentos dos tanques seguirem a numeração utilizada na EFD do contribuinte e o volume de descarga ser apurado considerando os abastecimentos realizados durante o período de descarga. O RDC é representado pelo evento 101 da tabela de eventos do Anexo II.
3.3.9. Registro de Estoque de Combustível (REC): volume em litros do estoque de combustível, contemplando os tipos de combustíveis, os números dos compartimentos, a temperatura e a respectiva data, hora, minutos e segundos do instante da medição, devendo os compartimentos dos tanques seguirem a numeração utilizada na EFD do contribuinte. O REC é representado pelos eventos 100 e 103 da tabela de eventos do Anexo II
Nas situações onde a sonda instalada no compartimento não conseguir realizar uma coleta de dados, um evento de alerta deverá ser gerado em substituição ao evento de medição. O evento de alerta será representado pelo evento 104 da tabela de eventos do Anexo II e deverá apresentar volume e temperatura zerados.
Não havendo qualquer sonda registrada no equipamento MVC, o evento 183 da tabela de eventos do Anexo II deve ser gerado.
3.3.10. Registro de Saídas dos Bicos (RSB): totalização do volume diário de saídas de combustíveis, em litros, realizadas no período compreendido entre 0:00h e 23:59h, apurado por bico de abastecimento, contendo a data, hora, minuto e segundo da leitura do dado, o tipo de combustível, o número do bico de abastecimento, o volume, os encerrantes volumétricos inicial e final e o número do compartimento vinculado ao bico, devendo:
I - ser criado um novo RSB sempre que ocorrer quebra ou descontinuidade do encerrante, com a respectiva data e hora da detecção;
II - os bicos e os compartimentos dos tanques seguirem a numeração utilizada na EFD do contribuinte;
III - a vinculação dos bicos aos respectivos compartimentos dos tanques deverão seguir a utilizada na EFD do contribuinte;
IV - o registro ser gravado no primeiro minuto do dia subsequente ao fechamento e, quando o MVC estiver desligado, por ocasião do retorno ao funcionamento do MVC.
O RSB é representado pelo evento 203 da tabela de eventos do Anexo II.
Nas situações onde nenhum bico estiver registrado no equipamento MVC, impossibilitando a totalização de saídas por bico, o evento 184 da tabela de eventos do Anexo II deverá ser gerado.
3.3.11. Registro de Saídas das Sondas (RSS): totalização do volume diário de saídas de combustíveis, em litros, realizadas no período compreendido entre 0:00h e 23:59h, apurada pelas sondas de medição (SM), contendo a data, hora, minuto e segundo da leitura do dado, o tipo de combustível, o volume e o compartimento, observando-se os incisos II e IV do item 3.3.10. O RSS é representado pelo evento 102 da tabela de eventos do Anexo II.
Nas situações onde nenhuma sonda estiver registrada no equipamento MVC, impossibilitando a totalização de saídas, o evento 183 da tabela de eventos do Anexo II deverá ser gerado.
3.3.12. Registro da Situação Operacional (RSO): indicação periódica a fiscalização ambiental que o equipamento MVC está ativo e funcionando em conformidade, composto pela data, hora, minutos e segundos. O RSA é representado pelo evento 307 da tabela de eventos do Anexo II.
O RSO deve ser gerado periodicamente, quando o RTR alcançar um intervalo de tempo entre o momento atual o último evento ambiental for superior ao PPE.

3.4. Requisitos Estruturais do MUS
3.4.1. Memória de Dados Históricos (MDH): deve ser protegida por resina, indissociável do MUS e possuir as seguintes características básicas:
I - ser não volátil;
II - possuir recursos associados de hardware semicondutor configurável ou programável que não permitam o seu apagamento ou a modificação de dados gravados;
não deve estar acessível para programação ou configuração;
III - deve estar programada de forma a permitir a leitura direta de seu conteúdo por meio de dispositivo específico para este fim, durante a realização de análise estrutural ou de perícia técnica solicitada pela fiscalização;
3.4.2. Resina de Proteção: deve possuir as seguintes características:
I - ser termofixa com temperatura de transição térmica igual ou superior a 120ºC;
II - apresentar rigidez dielétrica igual ou superior a 8 KV/mm conforme IEC 243;
III - apresentar dureza igual ou superior a 72 na escala Shore D;
IV - ser opaca;
V - ser insolúvel em água;
VI - não ser hidrofílica.
3.4.3. Lacração Lógica: função que consiste em monitorar, verificar e registrar na MDH os eventos da ausência de integridade do acesso, seja físico, referente a violação das partes internas do MUS ou lógico, referente a autenticação da comunicação dos dispositivos.
3.4.3.1. Requisitos do Acesso Físico:
I - as aberturas desobstruídas na parte externa ao MUS não devem permitir o acesso físico às partes protegidas pela lacração, com objetos metálicos de diâmetro maior ou igual a 0,4mm;
II - deve dispor de mecanismo para detectar, mesmo em situação de falta de energia, um deslocamento de no máximo 5 mm entre as partes do MUS;
III - ocorrendo qualquer um dos acessos físicos previstos nos incisos I e II, o Software Básico (SB) deve reconhecer e registrar na MDH este evento como Tentativa de Violação e Acesso (TVA).
3.4.3.2. Requisitos do Acesso Lógico: deve assegurar que os dispositivos se comuniquem entre si somente se houver recíproco reconhecimento e validação, sendo que o mecanismo de conexão pode ser baseado em protocolo de comunicação por desafio, tipo CHAP, ou outro com as mesmas características, que deve ser testado e identificado no Laudo emitido pelo Órgão Técnico Credenciado, devendo:
I - a validação ocorrer sempre na partida dos equipamentos, nos eventuais casos de interrupção momentânea de comunicação e também de forma aleatória durante a troca de dados.
II - no caso do MUS, somente manter a comunicação com o MCM, e vice-versa, se estiver assegurada a integridade dos dados e a unicidade do MVC.
III - o MUS registrar como evento sempre que o MCM não for autenticado, tiver falha nas funções de medição, estiver desconectado e sempre que retornar às suas funções normais.
3.4.4. Bootloader (BLD): a implementação lógica e física do Bootloader deverá garantir sua autenticidade, a validação do SB de forma inequívoca e a substituição de suas versões, por meio de chaves criptográficas, de conhecimento exclusivo do fabricante e com a utilização de algoritmos criptográficos com padrões de segurança reconhecidos pelo mercado.

3.5. Assinatura Digital
3.5.1. Assinatura Digital do AEF
As assinaturas digitais devem ser implementadas utilizando-se o padrão de assinatura digital “XML Digital Signature”, com chave privada de 1024 bits, com padrões de criptografia assimétrica RSA, algoritmo “message digest” SHA-1 e utilização das transformações Enveloped e C14N.
O conteúdo constante do AEF produzido com a utilização deste processo de certificação presume-se verdadeiro em relação aos signatários, na forma do art. 219 da Lei nº 10.406, de 10 de janeiro de 2002.
Para todos os arquivos eletrônicos digitalmente assinados, extraídos de equipamentos MVC, utilizar-se-ão as chaves previamente especificadas, em conformidade com a faculdade prevista no § 2º do art. 10 da Medida Provisória nº 2.200-2, de 24 de agosto de 2001.
As mensagens utilizam o padrão de assinatura XML definido no endereço eletrônico “ http://www.w3.org/TR/xmldsig-core/ ”.
3.5.2. Assinatura Digital do Software Básico
O SB deve ser assinado digitalmente e as chaves devem observar as seguintes características:
I - a pública, ser armazenada na Memória de Dados Histórico (MDH) e utilizada nas rotinas de verificação de autenticidade do SB;
II - a privada, ser armazenada no MUS e ser de conhecimento exclusivo do fabricante;
III - terem no mínimo 256 bits.

3.6. Validação pelo Bootloader
Sempre que o MUS for energizado, o controle será assumido exclusivamente pelo BLD implementado conforme requisitos estruturais, sendo que:
I - o BLD deverá realizar a validação da assinatura digital da versão do SB instalado e, caso não seja validada, o BLD deve apagar as chaves privadas e o MUS deve ficar inoperante; estando validada, deve proceder a substituição do SB, se houver nova versão disponível, contemplando os requisitos de segurança de verificação de chaves e promover um software RESET.
II - em caso de tentativa mal sucedida de substituição do SB deve ser gravado evento na MDH, mantendo o SB original e válido em funcionamento.
III - o BLD não deve estar acessível para programação ou configuração, devendo estar programado de forma a permitir a leitura direta de seu conteúdo por meio de dispositivo específico para este fim, durante a realização de análise estrutural ou de perícia técnica solicitada pela fiscalização.

3.7. Interface com MDH (IDH)
Interface para exportação dos dados armazenados na MDH para DCD, previsto no inciso II do item 4.2, sendo sua presença na interface reconhecida automaticamente e cujo andamento e conclusão da exportação devem ser informados ao usuário por meio de IHM. Os dados exportados por meio desta interface devem manter identidade com os registros e eventos armazenados no MUS;

3.8. Interface de Transmissão à Fiscalização (ITF)
A comunicação remota entre o MVC e os órgãos de fiscalização se estabelecerá por meio dos dispositivos de interface de comunicação definidos no inciso III do item 4.2.
A ITF estabelecerá comunicação externa por iniciativa própria de forma automática, conforme parâmetros previamente programados para comunicação remota aos órgãos de fiscalização, para acesso das informações.
O protocolo de comunicação e formato dos dados estão estabelecidos no item 5 deste Anexo.
Os dados transmitidos devem manter identidade com os registros e eventos armazenados no MUS e seu formato de exportação deve ser o mesmo da interface prevista no item 3.7.

3.9. Inicialização do MUS
Na inicialização do MUS, que precede a sua entrada em operação normal, deverão ser configuradas as informações necessárias a essa operação, que incluem, entre outras: os identificadores, a data e o instante de tempo correntes, os atributos de usuários, os códigos de acesso, as chaves criptográficas e os parâmetros para o estabelecimento da comunicação remota, devendo esta inicialização ser registrada como evento.

3.10. Modo de Intervenção Técnica (MIT)
O MIT consiste no registro de inicio e término das manutenções realizadas no MUS, tais como atualização de SB, ajuste do RTR e outras manutenções que interfiram na sua operação, devendo ter sua descrição registrada no evento de Alteração de Parâmetro do MUS.
3.10.1. Atualização do Software Básico
Deve seguir procedimento descrito no item 3.2 e registrar na MDH, como evento, as atualizações de SB realizadas e as tentativas mal sucedidas.
3.10.2. Ajuste do Relógio de Tempo Real
O SB deve permitir o ajuste do relógio de tempo real por meio do PAR, a qualquer momento, sendo gravado como evento na MDH, observando as seguintes condições:
I - o avanço ou o recuo para ajuste decorrente de horário de verão, somente é permitido imediatamente após a gravação de dados na MDH e antes do envio qualquer dado via internet;
II - o avanço ou o recuo além cinco minutos é permitido para efeito de correções, sendo registrado na MDH como evento;
III - os valores ajustados de data e hora deverão ser uma data posterior ao conjunto de data e hora do último dado gravado na MDH, sendo obrigatoriamente válidos e executado em MIT, exceto no caso do item IV;
IV - a fiscalização tributária poderá realizar o ajuste do RTR, desde de que provenha de comandos por internet.

4. MODULO DE CONTROLE E MEDIÇÃO (MCM)
O módulo de controle e medição deve ser dotado de características funcionais que observem os modos de operação, interfaces, comunicação, características estruturais e outros detalhes descritos abaixo.

4.1. Descrição dos Componentes do MCM
O MCM deve possuir os seguintes componentes, podendo agregar outros, desde que não conflitem com os requisitos previstos neste Anexo.
4.1.1. Controlador de Medição (CMD)
É o componente responsável pela determinação do volume de combustível e do monitoramento ambiental por meio de algoritmos de controle, a partir das informações recebidas das sondas de medição, dos sensores ambientais, do concentrador, das unidades de abastecimento e de outros dispositivos externos, processando as informações por meio de protocolos específicos, disponibilizando informações para o MUS, a IHM e a IGM.
4.1.2. Memória de Trabalho (MTR)
É o componente que armazena a base de dados gerada pela leitura dos dispositivos de medição, de sensoriamento, programas para processamento das informações, algoritmos de controle e parâmetros de configuração do MVC.
4.1.3. Controle de Interface e Sensoriamento (CIS)
Interface física responsável pela adequação elétrica, processamento de sinais e barreiras de segurança, quando aplicável, e proteção mecânica para atendimento das normas vigentes, possibilitando abrigar todas as proteções elétricas e mecânicas e a lógica eletrônica de interface para o concentrador, unidades de abastecimento, sondas de medição, sensores ambientais, ou outros tipos de sensores e dispositivos utilizados, devendo a comunicação com a sonda de medição possuir lacração lógica, para controlar a autenticidade das informações recebidas.
4.1.4. Alimentação e Baterias (ALM)
Componente que fornece a alimentação ao MVC, gerenciando as baterias, que são os dispositivos acumuladores de energia para fornecimento ininterrupto de energia, capaz de manter o MVC operacional por no mínimo uma hora.
4.1.5. Interface Homem Maquina (IHM)
Componente que controla os dispositivos de interface ao usuário para permitir o acesso às informações de medição, os estados dos sensores, os relatórios gerenciais e possibilitar a configuração do sistema, podendo ser por meio de displays, teclados, mouse, ou outros.
4.1.6. Interface de Gerenciamento e Manutenção (IGM)
Componente responsável pela interface aos Dispositivos de Gestão, realizando o controle e adequação dos protocolos de comunicação necessários para parametrização do MCM, receber e transmitir informações gerenciais de medição e sensoriamento ambiental aos dispositivos de gestão externos.

4.2. Conectores com Acesso Externo ao MVC
Devem atender aos seguintes requisitos:
I - não poderá existir conector externo sem função definida;
II - ser padrão USB (Universal Serial Bus) 1.1 ou superior do tipo “A” para suporte de memória tipo “Pen Drive” com formatação FAT 32 , para o DCD de armazenamento externo do IDH.
III - ser padrão RJ-45 (Ethernet over twisted pair), para conexão Ethernet, de implementação obrigatória para a Interface de Transmissão à Fiscalização (ITF) e de implementação facultativa outra tecnologia que atenda as especificações estabelecidas neste Anexo.

4.3. Eventos do MVC
O MUS deverá registrar na MDH e encaminhar às fiscalizações os eventos do MVC, conforme Anexo II (Tabela de Registros e Eventos).

5. TRANSMISSÃO À FISCALIZAÇÃO
Os órgãos de fiscalização disponibilizarão os seguintes serviços:
I - recepção dos registros e eventos de responsabilidade do órgão de fiscalização tributária assinalados na coluna “Tributária” do Anexo II (Tabela de Registros e Eventos).
II - recepção dos registros e eventos de responsabilidade do órgão de fiscalização ambiental assinalados na coluna “Ambiental” do Anexo II (Tabela de Registros e Eventos).
Os serviços serão atendidos por Web Service específicos e o fluxo de comunicação será iniciado pelo MVC por meio do envio de uma mensagem ao Web Service, conforme configuração pré-estabelecida no equipamento.
Os serviços previstos são síncronos. O processamento da solicitação de serviço é concluído na mesma conexão, com a devolução de uma mensagem. Um protocolo de entrega será enviado nesta mensagem quando as validações apontadas no Anexo III forem satisfeitas.
Os dados gravados na MDH devem ser enviados em ordem cronológica desde a última transmissão bem sucedida.
Opcionalmente na mensagem de resposta o Web Service pode incluir uma tarefa ao equipamento MVC. Esta tarefa será uma mudança nos parâmetros configuráveis do equipamento.

5.1. Padrões Técnicos
5.1.1. Padrão de Documento XML
5.1.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: , sendo que cada arquivo XML somente poderá ter uma única declaração.
A declaração do “namespace” da assinatura digital deverá ser realizada na própria tag .
O layout de cada arquivo está definido na especificação de cada Web Service, no Anexo III.
5.1.1.2. Padrão de Schema
Para garantir a correta formação dos arquivos XML, o equipamento MVC deverá gerar o arquivo de mensagem com Schema do XML (XSD – XML Schema Definition) válido, disponibilizado no site do CONFAZ.
5.1.1.3. Montagem do Arquivo
O arquivo XML de transmissão das informações contidas na MDH às fiscalizações será gerado observando as seguintes regras:
I - não incluir "zeros não significativos" para campos numéricos;
II - não incluir "espaços" no início ou no final de campos numéricos e alfanuméricos;
III - não incluir comentários no arquivo XML;
IV - não incluir anotação e documentação no arquivo XML (TAG annotation e TAG documentation);
V - não incluir caracteres de formatação entre as TAGs no arquivo XML ("line-feed", "carriage return", "tab", e caractere de espaço).
VI - o tamanho dos arquivos enviados não poderá ser superior a 10 Mbytes.
5.1.2. Padrão de Comunicação
A comunicação será baseada em Web Services disponibilizados pelos órgãos de fiscalização dos Estados.
O meio físico de comunicação utilizado será a Internet, com o uso do protocolo SSL versão 3.0, com autenticação do serviço disponibilizado pelo órgão de fiscalização. A autenticidade do emitente será garantida pela assinatura da mensagem pelo MVC com a chave privada registrada no equipamento.
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 dos órgãos de fiscalização e o MVC será realizada no padrão SOAP versão 1.2, com troca de mensagens XML no padrão Style/Encoding: Document/Literal.

5.2. Padrão de Mensagens dos Web Services
5.2.1. Validação da Estrutura XML das Mensagens dos Web Services
As informações são enviadas ou recebidas dos Web Services por meio de mensagens no padrão XML definido na documentação de cada Web Services, conforme Anexo III.
As alterações de leiaute e da estrutura de dados XML realizadas nas mensagens são controladas por meio da atribuição de um número de versão para a mensagem.
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.
5.2.2. 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”, como segue:
I - Medicao_v1.01.xsd (Schema XML do envio de mensagem de medição, versão 1.01);
II - Ambiental_v1.01.xsd (Schema XML do envio de mensagem ambiental, versão 1.01);
III – Retorno_v1.01.xsd (Schema XML do retorno de mensagem do Web Services, versão 1.01);
IV - tiposBasicos.xsd (Schema XML dos tipos básicos).
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 por Ato COTEPE e poderão ocorrer sempre que se fizerem necessárias.
As informações gravadas na MDH deverão manter a versão do Schema usado por ocasião da sua gravação.

5.3. Ambiente Virtual
Os órgãos de fiscalização devem desenvolver seus sistemas próprios de recepção de mensagens, seguindo layout estabelecido neste documento.
Os órgãos de fiscalização estão livres para definir prazos para o estabelecimento dos serviços quem envolvem este sistema.

5.4. Especificação dos Web Services
As URL dos Web Services serão disponibilizadas pelos órgãos de fiscalização. Acessando a URL pode ser obtido o WSDL (Web Services Description Language) de cada Web Services.
Estes Web Services estão definidos no Anexo III.

6. REQUISITOS DA OPERAÇÃO COM A FISCALIZAÇÃO
Descreve-se a seguir a operação de transferência de dados, forma de armazenamento e a análise de contingências para cumprir os requisitos deste Anexo.

6.1. Processo de Envio de Dados à Fiscalização
O MVC deve iniciar a conexão com o Web Service:
I - periodicamente, quando o RTR alcançar um intervalo de tempo entre o momento atual e a última mensagem transmitida maior que o PPE.
II - sempre que o equipamento for energizado e o intervalo de tempo entre o momento atual do RTR e o momento da última mensagem transmitida for maior que o PPE.
Com o equipamento em conexão on-line, devem ser transmitidos os dados registrados na MDH desde a última transmissão bem sucedida.
O arquivo deverá conter em sua estrutura o PEM gerado pelo próprio MVC que identificará de modo único o bloco de registros enviados.
Utilizando a mesma conexão, o Web Service responderá ao MVC conforme disposto no Anexo III e, satisfazendo as regras de validação, devolverá uma resposta contendo o PRF.
O MVC deverá efetuar o armazenamento do PRF associando-o diretamente ao PEM sem realizar a alteração dos registros existentes na MDH.
O MVC deve manter associado aos eventos e registros, que podem ser entregues tanto para a fiscalização tributária como para a fiscalização ambiental, os respectivos protocolos de entrega dos dois órgãos.

6.2. Processo de Gravação do DCD
Para gravação dos dados contidos no MDH, deve ser inserido o DCD na IDH e, a partir deste momento a IHM deverá solicitar se o DCD a ser criado é do tipo DCD de Fiscalização Tributária ou DCD de Fiscalização Ambiental.
O usuário será orientado pela IHM quanto à seleção do período no qual se deseja que as informações sejam gravadas da MDH para o DCD.
Os arquivos gravados no DCD devem seguir o leiaute definido no Anexo III.
Nos casos em que esteja registrado na MDH o PRF dos dados obtidos em uma conexão direta do MVC, a montagem do arquivo deverá apresentar tanto o PEM como o PRF associado em sua estrutura.
Pode ser também transmitido à fiscalização, por meio de uma conexão específica que não utilize a do MVC, os dados gravados no DCD por processo manual. Nesta situação, a fiscalização emitirá protocolo de recebimento.
É dispensada a gravação do número do PRF no MVC quando a remessa às entidades fiscalizadoras for realizada por meio de gravação dos eventos no DCD, hipótese em que a comprovação da entrega das informações se fará por meio do protocolo de recebimento.

6.3. Alteração de Parâmetros do MVC
A fiscalização poderá, a qualquer momento, enviar requisição de alteração de parâmetros utilizando conexão aberta entre MVC e Web Service, conforme definido neste Anexo, permitida também alteração de parâmetros por intermédio do MIT, devendo o MVC registrar na MDH, como evento, toda alteração de parâmetros.
6.3.1 Alteração no Relógio de Tempo Real
A fiscalização poderá requisitar a atualização do RTR por meio do envio de uma URL que indique um serviço de NTP para servir de referência na atualização do mesmo.
A alteração do PRE pelo MVC deve gerar o evento 126 da tabela de eventos do Anexo II.
Parâmetro de Atualização do Relógio (PAR).
6.3.2. Envio de Eventos à Fiscalização
A fiscalização poderá requisitar o envio dos eventos registrados na MDH por meio do Parâmetro de Requisição de Eventos – PRE.
A alteração do PRE pelo MVC deve gerar um evento 165 da tabela de eventos do Anexo II.
6.3.3. Solicitação de Alteração de endereço URL
A fiscalização poderá requisitar a alteração da URL de endereçamento por meio do PAE.
A alteração do PAE pelo MVC deve gerar um evento 122 da tabela de eventos do Anexo II para a fiscalização tributária e um evento 305 da tabela de eventos do Anexo II para a fiscalização ambiental.
6.3.4. Alteração do Parâmetro de Periodicidade de Envio
A fiscalização poderá alterar o PPE devendo o MVC suportar o envio de dados em no mínimo 30 minutos e no máximo em 1.440 minutos.
O parâmetro PPE com valor zero minuto indicará que não haverá transmissão via internet.
A alteração do PPE pelo MVC deve gerar um evento 125 da tabela de eventos do Anexo II para a fiscalização tributária e um evento 306 da tabela de eventos do Anexo II para a fiscalização ambiental.
6.3.5. Alteração do Parâmetro de Variação de Volume
A fiscalização tributária poderá requisitar a alteração do PVV, conforme definido no item 3.3.6.
A alteração do PRE pelo MVC deve gerar um evento 120 da tabela de eventos do Anexo II.
6.3.6. Alteração do Parâmetro de Tempo de Medidas
A fiscalização tributária poderá requisitar a alteração do PTM, conforme definido no item 3.3.7.
A alteração do PTM pelo MVC deve gerar um evento 121 da tabela de eventos do Anexo II.
6.3.7. Programação do Horário de Verão
A fiscalização tributária poderá requisitar a programação do horário de verão (PHV) no equipamento, enviando a data de início e fim de vigência do horário de verão.
É permitido a parametrização de um ou mais períodos sendo que a exclusão de um período informado equivocamente se dá pelo envio de uma programação de horário de verão com início e fim de vigência na mesma data.
A inclusão ou alteração do PHV pelo MVC deve gerar um evento 127 da tabela de eventos do Anexo II.

6.4. Situações Operacionais
6.4.1. Leitura de MDH em Virtude de Troca de MUS
Em caso do MUS estar operacional e ser necessária à troca deste por falta de espaço na MDH, caberá ao usuário do MVC efetuar em um DCD um arquivo de recuperação de dados da MDH do MUS que será trocado.
6.4.2. Perda de Conexão
Em uma situação em que os dados são encaminhados periodicamente ao Web Service e ocorrer uma perda de conexão, o MVC continuará efetuando a gravação das informações na MDH e tentará na frequência determinada pelo PPE a retomada da conexão.
Quando a conexão for restabelecida, caberá ao MVC enviar os dados da MDH que estiverem pendentes de envio, encerrando-se quando todos os dados forem recebidos pelo Web Service.

7. NORMAS ATENDIDAS
O MVC deve seguir as terminologias utilizadas de acordo com a IEC 60050 – 426 Vocabulário Eletrotécnico Internacional (IEV) parte 426 – Equipamentos para atmosferas explosivas, devendo atender também às seguintes normas:

7.1. Normas MUS
IEC 61000-4-2 - Imunidade a Descarga Eletrostática (ESD)
IEC 61000-4-3 - Imunidade a RF Irradiada
IEC 61000-4-4 - Imunidade a Transiente Elétrico Rápido (EFTB) – Transiente de Energia
IEC 61000-4-5 - Imunidade a Surtos – Transiente de Energia
IEC 61000-4-6 - Imunidade a RF Conduzida –Transiente de Energia
IEC 61000-4-11 - Imunidade a Redução e Interrupção de Tensão (DIP).

7.2. Normas MCM
IEC 60079-0 - Atmosferas Explosivas – Parte 0 Requisitos Gerais
IEC 60079 -10-1:2009 Atmosferas Explosivas – Parte 10-1: Classificação de Áreas – Atmosferas Explosivas de gás.
IEC 60079-11:2009 Atmosferas explosivas — Parte 11: Proteção de equipamento por segurança intrínseca "i".
IEC 60079-17:2009 Atmosferas explosivas – Parte 17: Inspeção e manutenção de instalações elétricas.
IEC 60079-19:2008 Equipamentos elétricos para atmosferas explosivas – Parte 19: Reparo, revisão e recuperação de equipamentos utilizados em atmosferas explosivas.
IEC 60079-25:2010 Explosive atmospheres - Part 25: Intrinsically safe electrical systems.
Portaria 179 do INMETRO Regulamentação de uso, comercialização e avaliação de conformidade de equipamentos para atmosferas explosivas no território brasileiro bem como identificação e uso de selos de conformidade do INMETRO.
NBR 13.784 Armazenamento de Líquidos Inflamáveis e Combustíveis – Seleção de Métodos para detecção de vazamentos e ensaios de estanqueidade em sistema de armazenamento subterrâneo.”

ANEXO II
TABELA DE REGISTRO E EVENTOS

TIPO EVENTOIDDescriçãoMVCTributáriaAmbiental
Registro de Medição100Registro de Estoque de CombustívelXX
101Registro da Descarga de ProdutoXX
102Registro de Saídas de SondasXX
103Registro da Descarga de Produto Registrada ManualmenteXX
104Medição inoperanteXX
Registro Alteração Parametrização120Alteração de Parametrização de VolumeXX
121Alteração de Parametrização de Tempo de MedidasXX
122Alteração de URL da Fiscalização TributáriaXX
123Alteração de RelógioXXX
124Alteração de Parametrização do MCM (dados cadastrais)XX
125Alteração do Parâmetro de Periodicidade de EnvioX X
126 Alteração no relógio solicitado pelo órgão de fiscalização X X
127Programação do horário de verãoXX
128Alteração do relógio – entrada/saída do Horário de VerãoXXX
Registros de Ocorrências MUS/MF140Inicio de Operação MUS/MFXXX
141MUS/MF desligadoXXX
143Recurso da MDH esgotado (97%)XX
144MCM/MM Desconectado (Sem Comunicação com o MCM/MM)XXX
145MCM/MM Ativo (retorno da Operação do MCM/MM)XXX
146MCM/MM Inativo (Falha nas funções de Medição)XXX
147MCM Inválido (MCM não foi autenticado)XXX
148Falta de comunicação com a Fiscalização TributáriaXX
150Retorno de comunicação com a Fiscalização TributáriaXX
151MUS/MF Inicio de ManutençãoXXX
152MUS/MF Fim de manutençãoXXX
153Atualização de SBXXX
154SB Não validadoXXX
155Falha do DCD (Não conseguiu transferir dados)XXX
157Transferência Dados Efetuada da MDH ao DCDXXX
158Memória DCD InsuficienteXXX
159MUS Violado (Tentativa de Violação do MUS)XXX
160Falha Interna MUS (Falha Relógio, memória, etc.)XXX
162Cadastro de NID EfetuadoXXX
163Cadastro de NID RecusadoXXX
165Solicitação de requisição de eventos registradaXXX
Registro Ocorrências de Medição180Falha Autenticação SondaXX
181Sonda em FalhaXX
182Sonda em OperaçãoXX
183Nenhuma sonda cadastradaX X
184Nenhum bico cadastrado XX
Registros Ocorrências MCM190Porta do Gabinete abertaXXX
191Porta do Gabinete FechadaXXX
192MCM em Início de ManutençãoXXX
193MCM Fim de ManutençãoXXX
194Falha de Energia MCMXXX
195Retorno de Energia MCMXXX
196Bateria EsgotadaXXX
1
Registros Ocorrências CON200Falha Comunicação Concentrador / Unidade AbastecedoraXX
201Retorno Comunicação Concentrador / Unidade AbastecedoraXX
202Alteração de Bico x produtoXX
203Registro de Saída dos BicosXX
204Quebra ou Descontinuidade do EncerranteXX
1
1
Registros Ocorrências Ambientais300Presença de LiquidoX X
301Sensor NormalX X
302Sensor em FalhaX X
303Falta de Comunicação com a Fiscalização AmbientalX X
304Retorno de Comunicação com a Fiscalização AmbientalX X
305Alteração de URL da Fiscalização AmbientalX X
306Alteração do Parâmetro de Periodicidade de Envio – AmbientalX X
307Comunicação com a Fiscalização Ambiental em conformidadeX X
N.O.* - Requisito não obrigatório

ANEXO III
PADRÕES DO FORMATO XML

B.1. Web Service da fiscalização tributária
Função : serviço destinado à recepção de mensagens de medição do órgão tributário.
Schema XML : Medicao_v1.01.xsd
Descrição: Contém as mensagens de medição, registro de descarga de combustível (RDC), registro de estoque de combustível (REC e RDC), registro de saída de sonda (RSS), registro de saída dos bicos (RSB) e os eventos definidos como Tributários no Anexo II no caso do MVC e no Anexo VI no caso do MVCT - Tabelas de Eventos.

CampoPaiTipoOcor.Tam.Dec.Descrição/Observação
A01Medicao- - Tag Raiz
A02VersaoA01N1-11-42Versão do layout
B01EquipamentoA01C1-120 Identificador único do equipamento. Padrão de numeração: [D|T][\w]{4}[0-9]{7}[\w]{8}
B02CNPJA01C1-114 CNPJ do estabelecimento
B03IEA01C1-114 Inscrição Estadual do contribuinte
B04MensagensA01 1-1 Grupo de mensagens
C01MensagemB04 1-4096- Mensagem de informação gerada pelo equipamento
D01PemC01N1-115 Identificador único da mensagem enviada pelo equipamento MVC.
D02PrfC01N0-115 Identificador único do protocolo de recebimento fornecido pelo órgão.
D03MedicoesC01 0-1 Grupo de eventos de medições registradas para o equipamento.
E01MedicaoD03 1-255 Informações que constituem RDC e REC
F01CodigoE01N1-1 Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
F02DataEventoE01D1-1 Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
F03TanqueE01N1-12 Identificação do tanque, o mesmo utilizado na EFD, registros 1300 e filhos
F04VolumeBrutoE01N1-172Volume bruto calculado pelo equipamento
F05Volume20E01N1-172Volume corrigido a temperatura de 20°C
F06TemperaturaE01N1-120Temperatura no momento da medição
F07CombustivelE01N1-190Código de produto da ANP
D04TotalizacoesC01 0-1 Grupo de informações que constituem RSS
G01TotalizacaoD04 1-255 Informações de um RSS
H01CodigoG01N1-1 Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
H02DataEventoG01D1-1 Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
H03TanqueG01N1-12 Identificação do tanque, o mesmo utilizado na EFD, registros 1300 e filhos
H04VolumeBrutoG01N1-172Volume bruto calculado pelo equipamento
H05CombustivelG01N1-190Código de produto da ANP
D05SaídasC01 0-1 Grupo de informações que constituem um RSB
I01SaídaD05 1-255 Informações de um RSB
J01CodigoI01N1-1 Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
J02DataEventoI01D1-1 Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
J03CombustivelI01N1-190Código de produto da ANP
J04TanqueI01N1-12 Identificação do tanque, o mesmo utilizado na EFD, registros 1300 e filhos
J05BicoI01N1-130Identificação do bico, o mesmo utilizado na EFD, registros 1300 e filhos
J06EncerranteInicioI01N1-1153Leitura inicial do contador (encerrante), no momento do fechamento
J07EncerranteFimI01N1-1153Leitura final do contador (encerrante), no momento do fechamento
J08VolumeBrutoI01N1-172Volume bruto de saída registrada pelo concentrador
D06EventosC01 0-1 Grupo de eventos de controle registrados para o equipamento.
K01EventoD06 1-255 Grupo de informações que constituem um alarme.
L01CodigoK01N1-1 Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
L02DataEventoK01D1-1 Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
L03TextoK01C0-1255 Informações adicionais sobre o evento registrado pelo equipamento.
B05signatureA01 1-1 Conforme layout definido para assinatura

Exemplo de mensagem de medição. Sobrescrito ao lado direito do item está uma referencia ao item no layout da mensagem.

<?xml version="1.0" encoding="utf-8"?>
<Medicao Versao="1.00" A02 >A01
<Equipamento>D0102140002130000189</Equipamento> B01
<CNPJ>11222555000101</CNPJ> B02
<IE>250000252</IE> B03
<Mensagens> B04
<Mensagem Pem="1000" D01 Prf="3000" D02> C01
<Medicoes> D03
<Medicao> E01
<Codigo>100</Codigo> F01
<DataEvento>2013-10-01T12:00:25-03:00</DataEvento> F02
<Tanque>1</Tanque> F03
<VolumeBruto>11250</VolumeBruto> F04
<Volume20>11230</Volume20> F05
<Temperatura>25</Temperatura> F06
<Combustivel>320102002</Combustivel> F07
</Medicao> E01
<Medicao> E01
<Codigo>100</Codigo> F01
<DataEvento>2013-10-01T12:00:25-03:00</DataEvento> F02
<Tanque>2</Tanque> F03
<VolumeBruto>25100</VolumeBruto> F04
<Volume20>24490</Volume20> F05
<Temperatura>25</Temperatura> F06
<Combustivel>320101002</Combustivel> F07
</Medicao> E01
</Medicoes> D03
<Totalizacoes> D04
<Totalizacao> G01
<Codigo>102</Codigo> H01
<DataEvento>2013-10-01T23:59:00+02:00</DataEvento> H02
<Tanque>1</Tanque> H03
<VolumeBruto>7000</VolumeBruto> H04
<Combustivel>320102002</Combustivel> H05
</Totalizacao> G01
</Totalizacoes> D04
<Saidas> D05
<Saida> IO1
<Codigo>203</Codigo> J01
<DataEvento>2013-10-01T23:59:00+02:00</DataEvento> J02
<Combustivel>320102002</Combustivel> J03
<Tanque>1</Tanque> J04
<Bico>1</Bico> J05
<EncerranteInicio>125</EncerranteInicio> J06
<EncerranteFim>185</EncerranteFim> J07
<VolumeBruto>3185</VolumeBruto> J08
</Saida> I01
</Saidas> D05
<Eventos> D06
<Evento> K01
<Codigo>301</Codigo> L01
<DataEvento>2013-10-01T12:00:00-03:00</DataEvento> L02
<Texto>Sump bomba 1</Texto> L04
</Evento> J01
</Eventos> C09
</Mensagem> B01
</Mensagens> B04
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>e7jQRU4xmLaQmWVO9pVovhWSeGU=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>iv+l8DQlNmp8EVZvn0Smy/tkcCA2wp9gHg7urm9ZD6RiwzSI+oEAY1JYGw9szP7BsQZyH6areeGyVtoAbkY502VjP892OD1lpNdWRDeCjIja1xHyubdSp38YvHAGNK5eKLPpxVqqWk5ISENFMY4cBk5AP/7lxOkeQs8kfHoU/K0=</SignatureValue>
</Signature>
</Medicao>

B.1.1. Descrição do processo de Recepção de Mensagens
B.1.1.1 Geração da Resposta com o Recibo
Não existindo qualquer erro nas validações, o aplicativo deverá gerar um número de recibo PRF e retornará uma mensagem de confirmação de recebimento para o transmissor com as seguintes informações:
a) a versão do aplicativo;
b) o código 100 e a mensagem “Recebido com Sucesso”;
c) o número do recibo.
Caso ocorra algum erro de validação, o Web Service não fornecerá número de recibo PRF e deverá retornar uma mensagem com as seguintes informações:
a) a versão do aplicativo;
b) o código contido na tabela de erros com a respectiva mensagem de erro
Sobre as mensagens enviadas pelo equipamento poderão, a critério da fiscalização, retornar erros conforme tabela abaixo.

Tabela de Erros
#ValidaçãoCódigoMensagem
1XML243XML de Dados Mal Formado
2Validação da assinatura digital297Valor da assinatura (SignatureValue) difere do valor calculado
3Validação da assinatura digital298Assinatura difere do padrão do Sistema:

B.1.1.2. Leiaute da Mensagem de Retorno
Estrutura XML com a mensagem do resultado da transmissão. Além de devolver uma mensagem com a indicação de sucesso ou erro na mensagem, a fiscalização tributária pode opcionalmente enviar parâmetros de configuração ou programar tarefas para serem executadas pelo equipamento:
São elas:
a) Parâmetro de Atualização do Relógio (PAR).
b) Parâmetro de Periodicidade de Envio (PPE).
c) Parâmetro de Alteração de Endereço (PAE).
d) Parâmetro de Variação de Volume (PVV).
e) Parâmetro de Tempo das Medidas (PTM).
f) Parâmetro de Requisição de Eventos (PRE).
g) Parâmetro de Programação do Horário de Verão (PHV)
Schema XML: retorno_v1.01.xsd
CampoPaiTipoOcor.Tam.Dec.Descricao/Observação
A01RetornoMensagem- - Tag Raiz
A02VersaoA01N1-11-42Versão do layout
B01RetornoA01N1-13 Código de status da resposta, valores da Tabela de Erros conforme item B.1.1.1
B02TextoA01C1-1255 Mensagem explicativa do código de retorno
B03PrfA01N1-11-15 Numero de recibo gerado pelo web-service
B04PemA01N1-11-15 Número do protocolo de envio do MVC referente a mensagem de retorno
B05TarefaA01 0-1 Grupo de tarefas que podem ser enviadas ao equipamento, solicitando uma alteração de configuração ou transmissão de novos dados.
C01RelogioB05C0-1255 Url de referência para alteração do RTR
C02PeriodoRemessaB05N0-11-4 Periodicidade das remessas de dados ao órgão de fiscalização
C03UrlRemessaB05C0-1255 URL de remessa de dados do orgão de fiscalização
C04VariacaoVolumeB05N0-172Volume mínimo, em litros, que dispara um evento de medição
C05TempoMedidaB05N0-11-4 Tempo, em minutos, entre cada medição periódica
C06RequisicaoEventoB05 0-1 Parâmetro que permite solicitar ao equipamento o envio da memória de determinado período
D01DataInicioC06D1 Data inicial para transmissão da memória de dados
D02DataFimC06D1 Data final para transmissão da memória de dados
C07HorarioVeraoB05 0-1 Grupo de informações que compõe a programação do horário de verão
E01DataInicioC06D1 Data de início do horário de verão
E02DataFimC06D1 Data de fim do horário de verão

Exemplo de mensagem de retorno
<?xml version="1.0" encoding="utf-8"?>
<RetornoMensagem Versao="1.00" A02> A01
<Retorno>100</retorno> B01
<Texto>Recebido com Sucesso</Texto> B02
<Prf>3</Prf> B03
<Pem>1</Pem> B04
<Tarefa> B05
<Relogio>200.20.186.75:123</Relogio> C01
<PeriodoRemessa>300</PeriodoRemessa> C02
<UrlRemessa>https://mvc.tributario.sef.sc.gov.br/</UrlRemessa> C03
<VariacaoVolume>100</VariacaoVolume> C04
<TempoMedida>30</TempoMedida> C05
<RequisicaoEvento > C06
<DataInicio>2013-01-01</DataInicio> D01
<DataFim>2013-01-31</dataFim> D02
</RequisicaoEvento>
<HorarioVerao > C07
<DataInicio>2016-10-16</DataInicio> E01
<DataFim>2017-02-27</dataFim> E02
</HorarioVerao> C07
</Tarefa> B05
</RetornoMensagem>

B.2. Web Service da fiscalização ambiental
Função : serviço destinado à recepção de mensagens de medição do órgão ambiental.
Schema XML : Ambiental_v1.00.xsd
Descrição: Definir as mensagens de ocorrências ambientais e os eventos definidos como Ambientais no Anexo II no caso do MVC e no Anexo VI no caso do MVCT - Tabelas de Eventos.
CampoPaiTipoOcor.Tam.Dec.Descrição/Observação
A01Ambiental- - Tag Raiz
A02VersaoA01N1-11-42Versão do layout
B01EquipamentoA01C1-120 Identificador único do equipamento
B02CNPJA01C1-114 CNPJ do estabelecimento
B03IEA01C1-114 Inscrição Estadual do contribuinte
B04MensagensA01 1-1 Grupo de mensagens
C01MensagemB04 1-4096- Mensagem de informação gerada pelo equipamento
D01PemC01N1-115 Identificador único da mensagem enviada pelo equipamento MVC.
D02PrfC01N0-115 Identificador único do protocolo de recebimento fornecido pelo órgão.
D03SensoresC01 0-1 Grupo de eventos dos sensores ambientais.
E01SensorD03 1-255 Informações que constituem um sensor ambiental.
F01CodigoE01N1-1 Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
F02DataEventoE01D1-1 Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
F03NumeroSensorE01N1-12 Identificação sensor no contribuinte.
D04EventosC01 0-1 Grupo de eventos de controle registrados para o equipamento.
G01EventoD04 1-255 Grupo de informações que constituem um alarme.
H01CodigoG01N1-1 Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
H02DataEventoG01D1-1 Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
H03TextoG01C0-1255 Informações adicionais sobre o evento registrado pelo equipamento.
A05signatureA01 1-1 Conforme layout definido para assinatura

Exemplo de mensagem ambiental. Sobrescrito ao lado direito do item está uma referência ao item no layout da mensagem.
<?xml version="1.0" encoding="utf-8"?>
<Ambiental Versao="1.00" A02 >A01
<Equipamento>D0102140002130000189</equipamento> B01
<CNPJ>11222555000101</CNPJ> B02
<IE>250000252</IE> B03
<Mensagens> B04
<Mensagem Pem="1000" D01 Prf="3000" D02> C01
<Sensores> D03
<Sensor> E01
<Evento>300</Evento > F01
<DataEvento>2013-12-01T18:00:05-02:00</DataEvento> F02
<Sensor>2</Sensor> F03
</Sensor> E01
<sensor> E01
<evento>122</evento> F01
<dataEvento>2013-12-01T18:28:05-02:00</dataEvento> F02
<sensor>0</sensor> F03
</sensor> E01
<eventos> D04
<evento> G01
<id>123</id> H01
<dataEvento>2013-10-01T12:00:00-03:00</dataEvento> H02
<texto>URL alterada para www.meioambiente.com.br </texto> H03
</evento> G01
</eventos> D04
</mensagem> C01
</mensagens> B04
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>e7jQRU4xmLaQmWVO9pVovhWSeGU=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>iv+l8DQlNmp8EVZvn0Smy/tkcCA2wp9gHg7urm9ZD6RiwzSI+oEAY1JYGw9szP7BsQZyH6areeGyVtoAbkY502VjP892OD1lpNdWRDeCjIja1xHyubdSp38YvHAGNK5eKLPpxVqqWk5ISENFMY4cBk5AP/7lxOkeQs8kfHoU/K0=</SignatureValue>
</Signature>
</medicao>

B.2.1. Descrição do processo de Recepção de Mensagens
B.2.1.1. Geração da Resposta com o Recibo
Não existindo qualquer erro nas validações, o aplicativo deverá gerar um número de recibo PRF e retornará uma mensagem de confirmação de recebimento para o transmissor com as seguintes informações:
a) a versão do aplicativo;
b) o código 100 e a mensagem “Recebido com Sucesso”;
c) o número do recibo.
Caso ocorra algum problema de validação, o aplicativo deverá retornar uma mensagem com as seguintes informações:
a) a versão do aplicativo;
b) o código e a respectiva mensagem de erro conforme tabela de erros
Sobre as mensagens enviadas pelo equipamento poderão, a critério da fiscalização, retornar erros conforme tabela abaixo.

Tabela de Erros
#ValidaçãoCódigoMensagem
1XML243XML de Dados Mal Formado
2Validação da assinatura digital297Valor da assinatura (SignatureValue) difere do valor calculado
3Validação da assinatura digital298Assinatura difere do padrão do Sistema:

B.2.1.2 Leiaute Mensagem de Retorno
Estrutura XML com a mensagem do resultado da transmissão. Além de devolver uma mensagem com a indicação de sucesso ou erro na mensagem, a fiscalização ambiental pode opcionalmente enviar os parâmetros de configuração ou programar tarefas para serem executas pelo equipamento.
São elas:
a) Parâmetro de Periodicidade de Envio (PPE).
b) Parâmetro de Alteração de Endereço (PAE).
c) Parâmetro de Requisição de Eventos (PRE).
Schema XML: retorno_v1.00.xsd

CampoPaiTipoOcor.Tam.Dec.Descricao/Observação
A01RetornoMensagem- - Tag Raiz
A02VersaoA01N1-11-42Versão do layout
B01RetornoA01N1-13 Código de status da resposta, valores da Tabela de Erros conforme item B.2.1.1
B02TextoA01C1-1255 Mensagem explicativa do código de retorno
B03PrfA01N1-11-15 Numero de recibo gerado pelo web-service
B04PemA01N1-11-15 Número do protocolo de envio do MVC referente a mensagem de retorno
B05TarefaA01 0-1 Grupo de tarefas que podem ser enviadas ao equipamento, solicitando uma alteração de configuração ou transmissão de novos dados.
C01PeriodoRemessaA05N0-11-4 Periodicidade das remessas de dados ao órgão de fiscalização
C02UrlRemessaA05C0-1255 URL de remessa de dados do orgão de fiscalização
C03RequisicaoEventoA05 0-1 Parâmetro que permite solicitar ao equipamento o envio da memória de determinado período
D01DataInicioB03D1 Data inicial para transmissão da memória de dados
D02DataFimB03D1 Data final para transmissão da memória de dados

As mensagens recebidas com erro geram uma mensagem de erro. Nas demais hipóteses será retornado uma mensagem com um número de recibo.
Exemplo de mensagem de retorno
<?xml version="1.0" encoding="utf-8"?>
<RetornoMensagem Versao="1.00" A02> A01
<Retorno>100</retorno> B01
<Texto>Recebido com Sucesso</Texto> B02
<Prf>3</Prf> B03
<Pem>1</Pem> B04
<Tarefa> B05
<PeriodoRemessa>300</PeriodoRemessa> C01
<UrlRemessa>https://mvc.tributario.sef.sc.gov.br/</UrlRemessa> C02
<RequisicaoEvento > C03
<DataInicio>2013-01-01</DataInicio> D01
<DataFim>2013-01-31</dataFim> D02
</RequisicaoEvento>
</Tarefa> B05
</RetornoMensagem>
B.3. Assinatura do XML
As mensagens utilizam o padrão de assinatura XML definido pelo http://www.w3.org/TR/xmldsig-core/ conforme abaixo:
Schema XML: xmldsig-core-schema.xsd

CampoPaiTipoOcor.TamDec.Descrição/Observação
XS01Signature-- - Tag Raiz
XS02SignedInfoXS01-1-1 Grupo da Informação da assinatura
XS03CanonicalizationMEthodXS02-1-1 Grupo do Método de Canonicalização
XS04AlgorithmXS03C1-1 Atributo Algorithm de CanonicalizationMethod: http://www.w3.org/TR/2001/REC-xml-c14n-20010315
XS05SignatureMethodXS02-1-1 Grupo do Método de Assinatura
XS06AlgorithmXS05C1-1 Atributo Algorithm de SignatureMethod: http://www.w3.org/2000/09/xmldsig#rsa-sha1
XS07ReferenceXS02-1-1 Grupo Reference
XS08URIXS07C1-1 Atributo URI da tag Reference
XS09TransformsXS07-1-172Grupo do algorithm de Transform
XS10TransformXS09-2-2 Grupo de Transform
XS11AlgorithmXS10C1-1 Atributos válidos Algorithm do Transform:
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
http://www.w3.org/2000/09/xmldsig#enveloped-signature
XS12DigestMethodXS07-1-1 Grupo do Método de DigestMethod
XS13AlgorithmXS12C1-1 Atributo Algorithm de DigestMethod:http://www.w3.org/2000/09/xmldsig#sha1
XS14DigestValueXS07C1 Digest Value (Hash SHA-1 – BASE 64)
XS15SignatureValueXS01-1-1 Grupo do Signature Value
XS16KeyInfoXS01-1-1 Grupo das Propriedades da Chave
XS17X509DataXS16- Grupo do Certificado X509
XS18X509IssuerSerialXS17-1-1 Informação do Emissor-Fabricante
XS19X509CertificateXS17-1-1 Certificado do Equipamento
Segue abaixo um exemplo:

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> XS01
<SignedInfo> XS02
<CanonicalizationMethod XS03 Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" XS04 />
<SignatureMethod XS05 Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" XS06 /> XS04
<Reference XS07 URI="" XS08>
<Transforms> XS09
<Transform XS010 Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" XS11 />
</Transforms>
<DigestMethod XS12 Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" XS13 />
<DigestValue>e7jQRU4xmLaQmWVO9pVovhWSeGU=</DigestValue> XS14
</Reference>
</SignedInfo>
<SignatureValue>iv+l8DQlNmp8EVZvn0Smy/tkcCA2wp9gHg7urm9ZD6RiwzSI+oEAY1JYGw9szP7BsQZyH6areeGyVtoAbkY502VjP892OD1lpNdWRDeCjIja1xHyubdSp38YvHAGNK5eKLPpxVqqWk5ISENFMY4cBk5AP/7lxOkeQs8kfHoU/K0=</SignatureValue> XS15
</Signature>

ANEXO IV
Diagrama de Blocos MVC


ANEXO V
ESPECIFICAÇÃO DE REQUISITOS DO MEDIDOR VOLUMÉTRICO DE COMBUSTÍVEIS DE TRANSIÇÃO (ER-MVCT)
SUMÁRIO
1. INTRODUÇÃO
1.1. Disposições Gerais
1.2. Da Concepção de Funcionamento
1.3. Da Arquitetura
1.4. Abreviações e Definições
2. DESCRIÇÃO DO MVCT
2.1. Módulo de medição (MM)
2.2. Módulo Fiscal (MF)
2.2.1. Requisitos do Acesso Monitorado
2.2.2. Memória de Dados Históricos (MDH)
2.2.3. Software Básico (SB)
2.2.4. Identificações e Registros
2.2.4.1. Número de Identificação do MF (NIM)
2.2.4.2. Número de Identificação do MVCT (NID)
2.2.4.3. Identificação do Contribuinte Usuário (IC)
2.2.4.4. Parâmetro de Variação de Volume (PVV)
2.2.4.5. Parâmetro do Tempo de Medidas (PTM)
2.2.4.6. Registro da Descarga de Combustíveis (RDC)
2.2.4.7. Registro do Estoque de Combustíveis (REC)
2.2.4.8. Registro de Saídas dos Bicos (RSB)
2.2.4.9. Registro de Saídas das Sondas (RSS)
2.2.5. Requisitos Estruturais
2.2.5.1. Requisitos Estruturais da MDH
2.2.5.2. Requisitos Estruturais dos Dispositivos Lógicos Programáveis (DLP)
2.2.6. Relógio de Tempo Real (RTR)
2.2.7. Assinatura Digital do AEF
2.2.8. Módulo de Transmissão de Dados à Fiscalização (MTF)
2.2.9. Interface de Transmissão à Fiscalização (ITF)
2.2.10. Inicialização do MF
2.2.11. Modo de Intervenção Técnica (MIT)
2.2.11.1. Atualização do Software Básico (SB)
2.2.11.2. Ajuste do RTR
3. TRANSMISSÃO À FISCALIZAÇÃO
3.1. Padrões Técnicos
3.1.1. Padrão do Documento XML
3.1.1.1. Padrão de Codificação
3.1.1.2. Padrão Schema
3.1.1.3. Montagem do Arquivo
3.1.2. Padrão de Comunicação
3.2. Padrão de Mensagem dos Web Services
3.2.1. Validação da Estrutura XML das Mensagens dos Web Services
3.2.2. Schemas XML das Mensagens dos Web Services
3.3. Ambiente Virtual
3.4. Especificação dos Web Services
4. REQUISITOS DA OPERAÇÃO COM A FISCALIZAÇÃO
4.1. Processo de Envio de Dados à Fiscalização
4.2. Alteração de Parâmetros do MF
4.3. Envio de Eventos à Fiscalização
4.4. Solicitação de Alteração do Endereço de URL
4.5. Alteração do Parâmetro de Periodicidade de Envio
4.6. Alteração do Parâmetro de Tempo de Medidas
4.7. Alteração do Parâmetro de Variação de Volume
4.8. Situações Operacionais
4.8.1. Leitura da MDH em Virtude de Troca do MF
4.8.2. Perda de Conexão
5. NORMAS ATENDIDAS
5.1. Normas do MF
5.2. Normas do MM

1. INTRODUÇÃO

1.1. Disposições Gerais
Este anexo especifica os requisitos mínimos a serem atendidos pelos Medidores Volumétricos de Combustíveis de Transição (MVCT), com a finalidade de estabelecer uma base comum para a sua fabricação e uso, bem como para o entendimento entre os diversos agentes envolvidos com as atividades relacionadas ao equipamento que poderá ser utilizado pelos postos revendedores de combustíveis líquidos que, cumulativamente:
I. já tenha adquirido e utilize equipamentos para medição volumétrica de combustíveis e monitoramento ambiental até a data do início da obrigatoriedade de uso do MVC ainda que as funções estejam implementadas em equipamentos distintos;
II. não cometa infração relacionada à comercialização ou qualidade de combustíveis; e
III. observe as demais obrigações estabelecidas pela unidade da federação de sua jurisdição, relativas ao MVC.
Os requisitos especificados neste Anexo são de implementação obrigatória, salvo aqueles considerados opcionais, condição esta explicitada no texto.”.

1.2. Da Concepção de Funcionamento
O equipamento Medidor Volumétrico de Combustíveis de Transição (MVCT), para atender suas finalidades, deverá atender as seguintes funções:
I. Apurar, com base nas sondas de medições, o volume em litros dos estoques presentes nos compartimentos dos tanques de combustíveis;
II. Apurar, com base nas sondas de medições, a variação volumétrica do volume em litros das descargas de combustíveis dos compartimentos dos tanques;
III. Apurar, com base nas sondas de medições, a variação volumétrica do volume em litros das saídas de combustíveis dos compartimentos dos tanques;
IV. Apurar, com base no concentrador ou unidades abastecedoras, o volume em litros das saídas de combustíveis realizadas por meio dos bicos das bombas de abastecimento;
V. Registrar e manter na memória de dados históricos, de forma segura, o registro histórico das operações volumétricas e eventos, nas hipóteses e situações definidas neste Anexo;
VI. Transferir informações que possibilitem disponibilizar ao sistema de gestão do contribuinte o registro das operações do equipamento e outras informações gerenciais;
VII. Enviar os registros das operações e eventos armazenados na memória de dados históricos aos órgãos fiscalizadores;
VIII. Disponibilizar informações que possibilitem ao contribuinte e à fiscalização extrair da memória, de forma local, o histórico dos registros das operações e eventos;
IX. Disponibilizar informações ao usuário que possibilitem acompanhar o gerenciamento, parametrização e configuração do equipamento a fim de obter informações gerenciais e de controle.

1.3. Da Arquitetura
O Medidor Volumétrico de Combustíveis de Transição (MVCT) constitui-se em uma estrutura, conforme diagrama de blocos previsto no Anexo VII, com as seguintes características:
I. Para medição e monitoramento, funcionar integrado e interligado com:
as sondas de medição, que devem estar instaladas em todos os compartimentos dos tanques de armazenamento de combustíveis líquidos;
os sensores ambientais;
as unidades abastecedoras de combustíveis, admitida a utilização do concentrador de bombas, caso o MVCT não suporte o seu tratamento direto;
II. Para o usuário, funcionar integrado e interligado a diversos dispositivos previstos neste Anexo, disponibilizando interfaces elétricas e lógicas para a realização das funções de interface, de forma local no MVCT ou remota via sistemas de gestão, vedada a alteração dos dados previstos neste Anexo após o processamento realizado pelo MVCT;
III. Para o contribuinte e fiscalização, disponibilizar de modo seguro, interface e meios que possibilitem extrair os dados históricos dos registros das operações armazenados na memória do equipamento;
IV. Para armazenamento seguro, disponibilizar recursos de armazenamento de registros de forma segura.

1.4. Abreviações e Definições
AEF – Arquivo Eletrônico da Fiscalização: conjunto de dados capturados pelo MVCT, gravado em memória não volátil, a serem disponibilizados à fiscalização de forma local ou remota.
CON – Concentrador: dispositivo com a capacidade de realizar de forma eletrônica a captura do volume das saídas de combustíveis das unidades abastecedoras, disponibilizando-as ao MVCT.
DLP - Dispositivos Lógicos Programáveis: hardware configurável ou programável utilizado para construir circuitos digitais;
EFD – Escrituração Fiscal Digital: na forma do Ato COTEPE ICMS 09/08.
ITF – Interface de Transmissão à Fiscalização: define o tipo físico da interface para transmissão de dados pela internet aos órgãos fiscalizadores.
MM – Módulo de Medição: módulo responsável pela leitura das sondas de medição e sensores ambientais.
MF – Módulo Fiscal: módulo que contém os componentes que garantem a segurança do armazenamento e sua inviolabilidade, com envio de forma criptografada dos dados e registros do MVCT aos órgãos fiscalizadores.
MDH – Memória de Dados Históricos: memória responsável pelo armazenamento seguro dos registros e eventos previstos neste Anexo.
MIT – Modo de Intervenção Técnica: estado operacional no qual é possibilitada a realização de manutenções no MVCT.
MTF – Módulo de Transmissão de dados à Fiscalização: componente com capacidade de transmitir de forma segura e criptografada as informações armazenadas no MF aos órgãos fiscalizadores.
MVCT – Medidor Volumétrico de Combustíveis de Transição: equipamento de medição volumétrica e monitoramento ambiental que permite, independente do Programa Aplicativo Fiscal (PAF-ECF), do Emissor de Cupom Fiscal (ECF) ou de qualquer outro equipamento de automação comercial, a captura automática, armazenamento, extração de dados e transmissão aos órgãos fiscalizadores das informações definidas neste Anexo.
NID - Número de Identificação: número que identifica o equipamento.
NIN - Número de Identificação do MF: número que identifica o MF.
PAE – Parâmetro de Alteração de Endereço: parâmetro para alteração do endereço URL de envio dos dados.
PAR - Parâmetro de Atualização do Relógio: parâmetro definido pela fiscalização tributária contendo a URL de referência a ser usada para ajuste do RTR.
PEM - Protocolo de Envio do MVCT: número gerado pelo próprio MVCT que identificará de modo único o bloco de registros enviados.
PPE - Parâmetro de Periodicidade de Envio: contém o intervalo de tempo, em minutos, que determina a periodicidade de envio aos órgãos de fiscalização de todos os eventos registrados na MDH, pendentes de envio.
PRE - Parâmetro de Requisição de Eventos: parâmetro definido pela fiscalização contendo as datas de início e término de eventos a serem enviados.
PRF - Protocolo de Recebimento da Fiscalização: número gerado pelo órgão de fiscalização que identifica um envio do MVCT de maneira única ao sistema do órgão, atestando a confirmação da entrega dos dados.
PTM - Parâmetro de Tempo de Medidas: intervalo de tempo para que o MVC realize uma REC.
PVV - Parâmetro de Variação de Volume: volume de variação de estoque que gera um registro de descarga de combustível.
RDC - Registro de Descarga de Combustível: volume em litros da descarga de combustível.
REC - Registro de Estoque de Combustível: volume em litros do estoque de combustível.
RSB - Registro de Saídas dos Bicos: saídas de combustíveis realizadas pelos bicos das bombas de abastecimento.
RSS - Registro de Saídas das Sondas: volume de saídas de combustíveis medido pelas sondas de medição.
RTR – Relógio de Tempo Real: dispositivo capaz de fornecer a data e a hora para o funcionamento do MVCT.

SB – Sofware Básico: conjunto fixo de rotinas residentes no MF, que implementa as funções de controle do MVCT.
SA – Sensor Ambiental: dispositivo capaz de identificar a presença de líquidos para fins de controle ambiental nos locais monitorados.
SM – Sonda de Medição: dispositivo de medição de nível instalado nos compartimentos dos tanques de combustíveis líquidos.
Web Services – solução utilizada pela fiscalização para integrar seus sistemas com o MVCT com a finalidade de receber e enviar informações em formato XML.

2. DESCRIÇÃO DO MVCT
Medidor Volumétrico de Combustíveis de Transição é o equipamento de medição volumétrica e monitoramento ambiental que permite, independente do Programa Aplicativo Fiscal (PAF-ECF), do Emissor de Cupom Fiscal (ECF) ou de qualquer outro equipamento de automação comercial, a captura automática, armazenamento, extração de dados e transmissão aos órgãos fiscalizadores das informações definidas neste Anexo, desenvolvido conforme diagrama de blocos do Anexo VII, sendo composto pelo módulo de medição (MM) e módulo fiscal (MF) conectados entre si.
As analises estrutural e funcional previstas no parágrafo único da clausula decima quinta do Convênio ICMS 59/11 aplicam-se somente ao módulo fiscal (MF).

2.1 Módulo de medição (MM)
Conjunto de dispositivos de hardware e software, com capacidade, quando ativo, de disponibilizar a medida calculada de forma indireta do volume de combustíveis líquidos existentes nos compartimentos de combustíveis e de realizar a função de monitoramento ambiental, podendo ser composto de um ou mais equipamentos para realizar tais funções.

2.2. Módulo Fiscal (MF)
Conjunto de dispositivos de hardware e software dotado de conexão de alimentação de energia independente, com capacidade quando ativo de:
I. monitorar, capturar e gravar os registros e eventos previstos neste Anexo, provenientes do Módulo de Medição (MM) e do concentrador (CON) de bombas, na Memória de Dados Históricos (MDH);
II. disponibilizar e transmitir, os registros e eventos armazenados na Memória de Dados Históricos (MDH), por meio da Internet, em formato definido no Anexo III;
III. permitir a leitura, por elemento computacional, utilizando-se de programa desenvolvido pelo fabricante do MF, dos dados armazenados na Memória de Dados Históricos (MDH), por porta de comunicação padrão USB 1.1 ou superior do tipo A.
2.2.1. Requisitos do Acesso Monitorado
O MF deve ser capaz de monitorar e registrar como evento as seguintes situações:
I. desconexão da interligação entre o MF e o MM;
II. desconexão da sonda de medição, em equipamentos que identificam esta ocorrência;
III. desconexão do sensor ambiental;
IV. desconexão do concentrador (CON).
2.2.2. Memória de Dados Históricos (MDH)
Recursos de hardware, residentes no Módulo Fiscal (MF), devendo possuir requisitos estruturais conforme item 2.2.5.1, sendo responsável por armazenar pelo prazo mínimo de 5 (cinco) anos os registros e eventos previstos neste Anexo.
2.2.3 Software Básico (SB)
O Software Básico é o conjunto fixo de rotinas que implementa as funções de controle do MF previstas neste Anexo, sendo que o dispositivo onde está armazenado, instalado e validado, deve permitir acesso para leitura direta do seu conteúdo por meio de dispositivo específico para este fim, durante a realização de análise estrutural ou de perícia técnica solicitada pela fiscalização, bem como via conector de comunicação externa utilizando programa aplicativo específico desenvolvido pelo fabricante do MVCT e entregue a fiscalização. A versão do SB pode ser atualizada remota ou localmente e deve ser identificada com 6 (seis) dígitos decimais, no formato XX.XX.XX, em que valores crescentes indicam versões sucessivas do software, obedecendo aos seguintes critérios:
I. o primeiro e o segundo dígitos devem ser incrementados de uma unidade, a partir do valor inicial 01, sempre que houver atualização da versão por motivo de mudança na legislação;
II. o terceiro e o quarto dígitos devem ser incrementados de uma unidade, a partir do valor inicial 00, sempre que houver atualização da versão por motivo de correção de defeito;
III. os dois últimos dígitos podem ser utilizados livremente, a partir do valor inicial 00, excluídas as situações previstas nas alíneas anteriores.
2.2.4. Identificações e Registros
Deve ficar registrado na MDH no mínimo as seguintes identificações e registros:
2.2.4.1. Número de Identificação do MF (NIM): o MF deve possuir identificação única composta por 5 (cinco) caracteres numéricos, devendo ser gravado uma única vez na MDH não permitindo ao equipamento disponibilizar comandos para apagamento ou alteração deste número de identificação.
2.2.4.2. Número de Identificação do MVCT (NID): o MVCT deve possuir um número único que permita a identificação individualizada do equipamentos. Este número deve ser gravado uma única vez na MDH não devendo o equipamento disponibilizar comandos para apagamento ou alteração do NID, sendo permitida a utilização de mais de um MVCT por estabelecimento.
O NID do MVCT deve possuir um conjunto de 20 (vinte) caracteres alfanuméricos composto da seguinte forma:
I. o caracter “T”;
II. os dois primeiros caracteres: para registro do código do fabricante ou importador, atribuído pela Secretaria Executiva do CONFAZ;
III. o terceiro e o quarto caracteres: para registro do código do modelo do equipamento, atribuído pela Secretaria Executiva do CONFAZ;
IV. o quinto e sexto caracteres: para indicar o ano de fabricação;
V. o sétimo, oitavo, novo, décimo e décimo primeiro caracteres: para o Número de Identificação do NIM;
VI. os demais caracteres devem ser utilizados pelo fabricante ou importador de forma a individualizar o equipamento.
2.2.4.3. Identificação do Contribuinte Usuário (IC): o contribuinte usuário será identificado no MVCT por meio de seus números de inscrições no CNPJ e Inscrição Estadual, que serão gravados na MDH.
2.2.4.4. Parâmetro de Variação de Volume (PVV): é o volume de variação mínima positiva, em litros, definido pela Unidade da Federação, para que o MVCT registre uma RDC, sendo inicialmente parametrizado pelo fabricante, no equipamento, a variação mínima de 200 litros no intervalo inferior a um minuto.
2.2.4.5. Parâmetro do Tempo de Medidas (PTM): Intervalo de tempo definido pela Unidade da Federação para que o MVCT realize uma REC, sendo inicialmente parametrizado pelo fabricante, no equipamento, o intervalo de 30 minutos. É opcional ao MVCT atender a um PTM de valor menor do que 30 minutos entre as medidas.
2.2.4.6. Registro da Descarga de Combustíveis (RDC): Volume em litros da descarga de combustível, contendo o tipo de combustível, o respectivo compartimento, a data, hora, minutos e segundos da ocorrência, devendo os compartimentos dos tanques seguirem a numeração utilizada na EFD do contribuinte. É opcional ao MVCT registrar a temperatura e realizar o RDC de forma automática.
2.2.4.7. Registro do Estoque de Combustíveis (REC): Volume em litros do estoque de combustível, contemplando os tipos de combustíveis, os números dos compartimentos e a respectiva data, hora, minutos e segundos do instante da medição, devendo os compartimentos dos tanques seguirem a numeração utilizada na EFD do contribuinte. É opcional ao MVCT registrar a temperatura a cada REC.
2.2.4.8. Registro de Saídas dos Bicos (RSB): totalização do volume diário de saídas de combustíveis, em litros, realizadas no período compreendido entre 0:00h e 23:59h, apurado por bico de abastecimento, contendo a data, hora, minuto e segundo da leitura do dado, o tipo de combustível, o número do bico de abastecimento, o volume, os encerrantes volumétricos inicial e final e o número do compartimento vinculado ao bico, devendo:
I. ser criado um novo RSB sempre que ocorrer quebra ou descontinuidade do encerrante, com a respectiva data e hora da detecção;
II. os bicos e os compartimentos dos tanques seguirem a numeração utilizada na EFD do contribuinte;
III. a vinculação dos bicos aos respectivos compartimentos dos tanques deverão seguir a utilizada na EFD do contribuinte;
IV. o registro ser gravado no primeiro minuto do dia subsequente ao fechamento e, quando o MVCT estiver desligado, por ocasião do retorno ao funcionamento do MVCT.
2.2.4.9. Registro de Saídas das Sondas (RSS): totalização do volume diário de saídas de combustíveis, em litros, realizadas no período compreendido entre 0:00h e 23:59h, apurada pelas sondas de medição (SM), contendo a data, hora, minuto e segundo da leitura do dado, o tipo de combustível, o volume e o compartimento, observando-se os incisos II e IV do item 2.2.4.8.
2.2.5. Requisitos Estruturais
2.2.5.1. Requisitos Estruturais da MDH
A Memória de Dados Histórico (MDH) deve seguir os seguintes requisitos estruturais:
I. ser não volátil;
II. possuir recursos associados de hardware semicondutor configurável ou programável que não permitam o seu apagamento ou a modificação de dados;
III. o dispositivo de MDH deve ser iniciado com a gravação de um número único de fabricação do MF, sendo este um procedimento de fabricação de responsabilidade exclusiva do fabricante;
IV. devem estar completamente protegidos por resina, evitando qualquer contato para reprogramação;
V. deve ser utilizada resina de proteção com as seguintes características:
a) ser termofixa com temperatura de transição térmica igual ou superior a 120ºC;
b) apresentar rigidez dielétrica igual ou superior a 8 KV/mm conforme IEC 243;
c) apresentar dureza igual ou superior a 72 na escala Shore D;
d) ser opaca;
e) ser insolúvel em água;
f) não ser hidrofílica.
2.2.5.2. Requisitos Estruturais dos Dispositivos Lógicos Programáveis (DLP)
O DLP ou outro hardware configurável ou programável, integrante dos recursos de hardware associados ao dispositivo de armazenamento da MDH:
I. devem ser afixados sem utilização de soquete ou conector;
II. não devem estar acessíveis para programação, configuração ou alteração dos dados e registros gravados;
III. devem estar programados de forma a permitir a leitura direta de seu conteúdo por meio de dispositivo específico para este fim, durante a realização de Análise Estrutural ou de perícia técnica solicitada pela fiscalização;
IV. não devem conter instruções que sejam executadas a partir das chamadas de rotinas específicas de comando previsto no “firmware” do equipamento;
2.2.6. Relógio de Tempo Real (RTR)
Componente residente no MF responsável pelo registro da data, hora, minuto e segundos para gravação da estampa de tempo das informações.
2.2.7. Assinatura Digital do AEF
As assinaturas digitais devem ser implementadas utilizando-se o padrão de assinatura digital “XML Digital Signature”, com chave privada de 1024 bits, com padrões de criptografia assimétrica RSA, algoritmo “message digest” SHA-1 e utilização das transformações Enveloped e C14N.
O conteúdo constante do AEF produzido com a utilização deste processo de certificação presume-se verdadeiro em relação aos signatários, na forma do art. 219 da Lei nº 10.406, de 10 de janeiro de 2002.
Para todos os arquivos eletrônicos digitalmente assinados, extraídos de equipamentos MVCT, utilizar-se-ão as chaves previamente especificadas, em conformidade com a faculdade prevista no § 2º do art. 10 da Medida Provisória nº 2.200-2, de 24 de agosto de 2001.
As mensagens utilizam o padrão de assinatura XML definido no endereço eletrônico “http://www.w3.org/TR/xmldsig-core/”.
2.2.8. Módulo de Transmissão de Dados à Fiscalização (MTF)
Componente responsável por transmitir via Internet aos órgãos fiscalizadores os registros e eventos gravados na MDH, previstos no Anexo VI, com endereçamentos de URL configuráveis, sendo que o formato, protocolo e a segurança na transmissão são os definidos no item 3 deste Anexo. Toda alteração de endereçamento de URL o MVCT deverá ser registrada como evento.
2.2.9. Interface de Transmissão à Fiscalização (ITF)
A comunicação remota entre o MVCT e os órgãos de fiscalização se estabelecerá por meio dos dispositivos de interface de comunicação tipo Ethernet, de implementação obrigatória, utilizando conector RJ-45 (Ethernet over twisted pair), sendo de implementação facultativa outra tecnologia que atenda as especificações estabelecidas neste Anexo.
A ITF estabelecerá comunicação externa por iniciativa própria de forma automática, conforme parâmetros previamente programados para comunicação remota aos órgãos de fiscalização, para acesso das informações.
O protocolo de comunicação adotado e formato dos dados estão estabelecidos no item 3 deste Anexo.
Os dados transmitidos por meio desta interface devem manter identidade com os registros e eventos armazenados no MF e seu formato de exportação deve ser o mesmo da interface prevista no item 2.2.8.
2.2.10. Inicialização do MF
Na inicialização do MF, que precede a sua entrada em operação normal, deverão ser configuradas todas as informações necessárias a essa operação, que incluem, entre outras: identificadores, data e instante de tempo correntes, identificação e atributos do contribuinte usuário e parâmetros para o estabelecimento da comunicação remota, devendo esta inicialização ser registrada como evento.
2.2.11. Modo de Intervenção Técnica (MIT)
O MIT consiste no registro de início e término das manutenções realizadas no MF, tais como atualização de SB, ajuste do RTR e outras manutenções que interfiram na sua operação, devendo ter sua descrição registrada no evento de Alteração de Parâmetro do MF.
2.2.11.1. Atualização do Software Básico (SB)
Deve seguir procedimento descrito no item 2.2.3 e registrar na MDH, como evento, as atualizações de SB.
2.2.11.2. Ajuste do RTR
O SB deve permitir o ajuste do relógio de tempo real por meio do PAR, a qualquer momento, sendo gravado como evento na MDH, observando as seguintes condições:
I. o avanço ou o recuo para ajuste decorrente de horário de verão, somente é permitido imediatamente após a gravação de dados na MDH e antes do envio qualquer dado via internet;
II. o avanço ou o recuo além cinco minutos é permitido para efeito de correções, sendo registrado na MDH como evento;
III. os valores ajustados de data e hora deverão ser uma data posterior ao conjunto de data e hora do último dado gravado na MDH, sendo obrigatoriamente válidos e executado em MIT, exceto no caso do item IV;
IV. a fiscalização tributária poderá realizar o ajuste do RTR, desde de que provenha de comandos por internet.

3. TRANSMISSÃO À FISCALIZAÇÃO
Os órgãos de fiscalização disponibilizarão os seguintes serviços:
I. recepção dos registros e eventos de responsabilidade do órgão de fiscalização tributária assinalados na coluna “Tributária” do Anexo VI (Tabela de Registros e Eventos).
II. recepção dos registros e eventos de responsabilidade do órgão de fiscalização ambiental assinalados na coluna “Ambiental” do Anexo VI (Tabela de Registros e Eventos).
Os serviços serão atendidos por Web Service específicos e o fluxo de comunicação será iniciado pelo MVCT por meio do envio de uma mensagem ao Web Service, conforme configuração pré-estabelecida no equipamento.
Os serviços previstos são síncronos. O processamento da solicitação de serviço é concluído na mesma conexão, com a devolução de uma mensagem. Um protocolo de entrega será enviado nesta mensagem quando as validações apontadas no Anexo III forem satisfeitas.
Os dados gravados na MDH devem ser enviados em ordem cronológica desde a última transmissão bem sucedida.
Opcionalmente na mensagem de resposta o Web Service pode incluir uma tarefa ao equipamento MVCT. Esta tarefa será uma mudança nos parâmetros configuráveis do equipamento.

3.1. Padrões Técnicos
3.1.1. Padrão de Documento XML
3.1.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"?>, sendo que cada arquivo XML somente poderá ter uma única declaração.
A declaração do “namespace” da assinatura digital deverá ser realizada na própria tag <Signature>.
O layout de cada arquivo está definido na especificação de cada Web Service, no Anexo III.
3.1.1.2. Padrão de Schema
Para garantir a correta formação dos arquivos XML, o equipamento MVCT deverá gerar o arquivo de mensagem com Schema do XML (XSD – XML Schema Definition) válido, disponibilizado no site do CONFAZ.
3.1.1.3. Montagem do Arquivo
O arquivo XML de transmissão das informações contidas na MDH às fiscalizações será gerado observando as seguintes regras:
I. não incluir "zeros não significativos" para campos numéricos;
II. não incluir "espaços" no início ou no final de campos numéricos e alfanuméricos;
III. não incluir comentários no arquivo XML;
IV. não incluir anotação e documentação no arquivo XML (TAG annotation e TAG documentation);
V. não incluir caracteres de formatação entre as TAGs no arquivo XML ("line-feed", "carriage return", "tab", e caractere de espaço).
VI. o tamanho dos arquivos enviados não poderá ser superior a 10 Mbytes.
3.1.2. Padrão de Comunicação
A comunicação será baseada em Web Services disponibilizados pelos órgãos de fiscalização dos Estados.
O meio físico de comunicação utilizado será a Internet, com o uso do protocolo SSL versão 3.0, com autenticação do serviço disponibilizado pelo órgão de fiscalização. A autenticidade do emitente será garantida pela assinatura da mensagem pelo MVCT com a chave privada registrada no equipamento.
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 dos órgãos de fiscalização e o MVCT será realizada no padrão SOAP versão 1.2, com troca de mensagens XML no padrão Style/Encoding: Document/Literal.

3.2. Padrão de Mensagens dos Web Services
3.2.1. Validação da Estrutura XML das Mensagens dos Web Services
As informações são enviadas ou recebidas dos Web Services por meio de mensagens no padrão XML definido na documentação de cada Web Services, conforme Anexo III.
As alterações de leiaute e da estrutura de dados XML realizadas nas mensagens são controladas por meio da atribuição de um número de versão para a mensagem.
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.
3.2.2. 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”, como segue:
I. envMSGMedicao_v1.00.xsd (Schema XML do envio de mensagem de medição, versão 1.00);
II. envMSGAmbiental_v1.00.xsd (Schema XML do envio de mensagem ambiental, versão 1.00);
III. retMSG_v1.00.xsd (Schema XML do retorno de mensagem do Web Services, versão 1.00);
IV. simcoXMLSchema_v1.00.xsd (Schema XML dos tipos básicos, versão 1.00).
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 por Ato COTEPE e poderão ocorrer sempre que se fizerem necessárias.
As informações gravadas na MDH deverão manter a versão do Schema usado por ocasião da sua gravação.

3.3. Ambiente Virtual
Os órgãos de fiscalização devem desenvolver seus sistemas próprios de recepção de mensagens, seguindo layout estabelecido neste documento.
Os órgãos de fiscalização estão livres para definir prazos para o estabelecimento dos serviços quem envolvem este sistema.

3.4. Especificação dos Web Services
As URL dos Web Services serão disponibilizadas pelos órgãos de fiscalização. Acessando a URL pode ser obtido o WSDL (Web Services Description Language) de cada Web Services.
Estes Web Services estão definidos no Anexo III.

4. REQUISITOS DA OPERAÇÃO COM A FISCALIZAÇÃO
Descreve-se a seguir a operação de transferência de dados, forma de armazenamento e a análise de contingências para cumprir os requisitos deste Anexo.

4.1. Processo de Envio de Dados à Fiscalização
O MVCT deve iniciar a conexão com o Web Service, periodicamente, quando o RTR alcançar um intervalo de tempo entre o momento atual e a última mensagem transmitida maior que o PPE.
Com o equipamento em conexão on-line, devem ser transmitidos os dados registrados na MDH desde a última transmissão bem sucedida.
O arquivo deverá conter em sua estrutura o PEM gerado pelo próprio MVCT que identificará de modo único o bloco de registros enviados.
Utilizando a mesma conexão, o Web Service responderá esta solicitação conforme Anexo III e, satisfazendo as regras de validação, devolverá uma resposta contendo o PRF.
O MVCT deverá efetuar o armazenamento do PRF associando-o diretamente ao PEM sem realizar a alteração dos registros existentes na MDH.
O MVCT deve manter associado aos eventos e registros, que podem ser entregues tanto para a fiscalização tributária como para a fiscalização ambiental, os respectivos protocolos de entrega dos dois órgãos.
No caso em que esteja registrado na MDH o PRF dos dados obtidos em uma conexão direta do MVCT, a montagem do arquivo deverá apresentar tanto o PEM como o PRF associado em sua estrutura.

4.2. Alteração de Parâmetros do MF
A fiscalização poderá enviar uma requisição de alteração de parâmetros utilizando uma conexão aberta entre o MVCT e o Web Service, conforme definido neste Anexo.

4.3. Envio de Eventos à Fiscalização
A fiscalização pode a qualquer momento requisitar o envio dos eventos registrados na MDH por meio do Parâmetro de Requisição de Eventos – PRE.

4.4. Solicitação de Alteração do endereço de URL
A fiscalização pode a qualquer momento requisitar a alteração da URL de endereçamento por meio do PAE.

4.5. Alteração do Parâmetro de Periodicidade de Envio
A fiscalização poderá alterar o PPE devendo o MVCT suportar o envio de dados em no mínimo 30 minutos e no máximo em 1.440 minutos.
O parâmetro PPE com valor zero minuto indicará que não haverá transmissão via internet.

4.6. Alteração do Parâmetro de Tempo de Medidas
A fiscalização tributária pode a qualquer momento requisitar a alteração do PTM conforme definido no item 2.2.4.5.

4.7. Alteração do Parâmetro de Variação de Volume
A fiscalização tributária pode a qualquer momento requisitar a alteração do PVV conforme definido no item 2.2.4.4.

4.8. Situações Operacionais
4.8.1. Leitura de MDH em Virtude de Troca de MF
Em caso do MF estar operacional e ser necessária a troca deste por falta de espaço na MDH caberá ao usuário do MVCT criar um arquivo de recuperação de dados da MDH do MF que será trocado.
4.8.2. Perda de Conexão
Em uma situação em que os dados são encaminhados periodicamente ao Web Service e ocorrer uma perda de conexão, o MVCT continuará efetuando a gravação das informações na MDH e tentará na frequência determinada pelo PPE a retomada da conexão.
Quando a conexão for restabelecida, caberá ao MVCT enviar os dados da MDH que estiverem pendentes de envio, encerrando-se quando todos os dados sejam recebidos pelo Web Service.

5. NORMAS ATENDIDAS
5.1. Normas do MF
As normas a serem atendidas pelo MF estão descritas no item 7.1 - Normas MUS do Anexo I
5.2. Normas do MM
As normas a serem atendidas pelo MM estão descritas no item 7.2 - Normas MCM do Anexo I

ANEXO VI
Tabela de Registros e Eventos

TIPO EVENTOIDDescriçãoMVCTTributáriaAmbiental
Registro de Medição100Registro de Estoque de CombustívelXX
101Registro da Descarga de ProdutoXX
102Registro de Saídas de SondasXX
Registro Alteração Parametrização120Alteração de Parametrização de VolumeXX
121Alteração de Parametrização de Tempo de MedidasXX
122Alteração de URL FiscoXXX
123Alteração de RelógioXXX
Registros de Ocorrências MF140Início de Operação MFXXX
141MF desligadoXXX
143Recurso da MDH esgotado (97%)XX
144MM Desconectado (Sem Comunicação com o MM)XXX
145MM Ativo (retorno da Operação do MM)XXX
146MM Inativo (Falha nas funções de Medição)1XXX
148Falta de Comunicação com Web ServiceXXX
150Retorno Comunicação com Web ServicesXXX
151MF Inicio de ManutençãoXXX
152MF Fim de manutençãoXXX
153Atualização de SBXXX
162Cadastro de NID EfetuadoXXX
163Cadastro de NID RecusadoXXX
164Alteração de Parâmetro do MFXXX
Registros Ocorrências CON200Falha Comunicação Concentrador / Unidade AbastecedoraXX
201Retorno Comunicação Concentrador / Unidade AbastecedoraXX
202Alteração de Bico x produtoXX
203Registro de Saída dos BicosXX
204Quebra ou Descontinuidade do EncerranteXX
Registros Ocorrências Ambientais300Presença de LiquidoX X
301Sensor NormalX X
302Sensor em FalhaX X
303Falta de Comunicação com a Fiscalização AmbientalX X
304Retorno de Comunicação com a Fiscalização AmbientalX X
305Alteração de URL da Fiscalização AmbientalX X
1. Vide item 2.2.1. inciso II

ANEXO VII
Diagrama de Blocos MVCT
BRUNO PESSANHA NEGRIS

(*) Republicado por ter sido publicado com incorreção DOU de 20.02.2018, Seção 1, página 09.

Republicação anterior.
ATO COTEPE/ICMS 10, DE 14 DE MARÇO DE 2014
. Republicado, por determinação judicial, pelo Despacho 25/18 do Secretário-Executivo do CONFAZ, no DOU de 20.02.2018, Seção 1, p. 9. O Secretário Executivo do Conselho Nacional de Política Fazendária - CONFAZ, no uso de suas atribuições que lhe confere o art. 12, XIII, do Regimento da COTEPE/ICMS, de 12 de dezembro de 1997, por este ato, informa que a Comissão Técnica Permanente do ICMS (COTEPE/ICMS), na sua 212ª reunião extraordinária, realizada no dia 14 de março de 2014, em Brasília, DF, aprovou a Especificação de Requisitos do Medidor Volumétrico de Combustíveis (ER-MVC) prevista no Convênio ICMS 59/11, de 8 de julho de 2011.
Art. 1º Fica aprovada a Especificação de Requisitos composta pelos Anexos I a IV deste ato, na versão 01.01, que deve ser observada pelo Medidor Volumétrico de Combustíveis (MVC).”;
Parágrafo único A Especificação de Requisitos a ser observada pelo Medidor Volumétrico de Combustíveis de Transição (MVCT) é composta pelos Anexos V a VII deste ato, na versão 01.00
Art. 2º O Diagrama de Blocos constante do Anexo IV corresponde a representação gráfica do funcionamento do Medidor Volumétrico de Combustíveis (MVC), devendo ser analisado em conjunto com os requisitos descritos nos Anexos I a III e o Diagrama de Blocos constante do Anexo VII corresponde a representação gráfica do funcionamento do Medidor Volumétrico de Combustíveis de Transição (MVCT), devendo ser analisado em conjunto com os requisitos descritos nos Anexos V e VI
Art. 3º As Unidades Federadas poderão estabelecer critérios para o uso do Medidor Volumétrico de Combustível.
Art. 4º Para fins deste Ato considera-se:
I – fiscalização: os órgãos responsáveis pela fiscalização de tributos estaduais e os órgãos estaduais responsáveis pela fiscalização do meio ambiente;
II – fiscalização tributária: os órgãos responsáveis pela fiscalização de tributos estaduais;
III – fiscalização ambiental: os órgãos estaduais responsáveis pela fiscalização do meio ambiente.
Art. 5º Este ato entra em vigor na data de sua publicação no Diário Oficial da União, produzindo seus efeitos a partir do primeiro dia do mês subsequente ao de sua publicação.

Redação anterior consolidada até o Ato COTEPE/ICMS 50/15.
ATO COTEPE/ICMS 10, DE 14 DE MARÇO DE 2014
· Publicado no DOU de 02.04.14, Seção 1, p. 27 a 33.
. Alterado pelos Atos COTEPE/ICMS 32/14, 6/15, 50/15 O Secretário Executivo do Conselho Nacional de Política Fazendária - CONFAZ, no uso de suas atribuições que lhe confere o art. 12, XIII, do Regimento da COTEPE/ICMS, de 12 de dezembro de 1997, por este ato, informa que a Comissão Técnica Permanente do ICMS (COTEPE/ICMS), na sua 212ª reunião extraordinária, realizada no dia 14 de março de 2014, em Brasília, DF, aprovou a Especificação de Requisitos do Medidor Volumétrico de Combustíveis (ER-MVC) prevista no Convênio ICMS 59/11, de 8 de julho de 2011.
Art. 1º Fica aprovada a Especificação de Requisitos composta pelos Anexos I a IV deste ato, na versão 01.01, que deve ser observada pelo Medidor Volumétrico de Combustíveis (MVC). (Nova redação dada ao caput pelo Ato COTEPE/ICMS 50/15) Parágrafo único A Especificação de Requisitos a ser observada pelo Medidor Volumétrico de Combustíveis de Transição (MVCT) é composta pelos Anexos V a VII deste ato, na versão 01.00 (Parágrafo único acrescentado pelo Ato COTEPE/ICMS 50/15)
Art. 2º O Diagrama de Blocos constante do Anexo IV corresponde a representação gráfica do funcionamento do Medidor Volumétrico de Combustíveis (MVC), devendo ser analisado em conjunto com os requisitos descritos nos Anexos I a III e o Diagrama de Blocos constante do Anexo VII corresponde a representação gráfica do funcionamento do Medidor Volumétrico de Combustíveis de Transição (MVCT), devendo ser analisado em conjunto com os requisitos descritos nos Anexos V e VI ; (Nova redação dada ao caput do art. 2º pelo Ato COTEPE/ICMS 32/14) Art. 3º As Unidades Federadas poderão estabelecer critérios para o uso do Medidor Volumétrico de Combustível.
Art. 4º Para fins deste Ato considera-se:
I – fiscalização: os órgãos responsáveis pela fiscalização de tributos estaduais e os órgãos estaduais responsáveis pela fiscalização do meio ambiente;
II – fiscalização tributária: os órgãos responsáveis pela fiscalização de tributos estaduais;
III – fiscalização ambiental: os órgãos estaduais responsáveis pela fiscalização do meio ambiente.
Art. 5º Este ato entra em vigor na data de sua publicação no Diário Oficial da União, produzindo seus efeitos a partir do primeiro dia do mês subsequente ao de sua publicação.
ANEXO I
ESPECIFICAÇÃO DE REQUISITOS DO MEDIDOR
(Nova redação dada ao ANEXO I pelo Ato COTEPE/ICMS 50/15)
SUMÁRIO
1. INTRODUÇÃO
1.1. Disposições Gerais
1.2. Da Concepção de Funcionamento
1.3. Da Arquitetura
1.4. Abreviações e Definições
2. DESCRIÇÃO DOS TIPOS
2.1. Medidor Volumétrico de Combustíveis Compacto (MVCC)
2.2. Medidor Volumétrico de Combustíveis Dual (MVCD)
2.3. Requisitos Obrigatórios
3. MÓDULO ÚNICO SEGURO (MUS)
3.1. Descrição dos Componentes do MUS
3.1.1. Unidade Central de Processamento (UCP)
3.1.2. Relógio de Tempo Real (RTR)
3.1.3. Memória de Dados Históricos (MDH)
3.1.4. Módulo de Transmissão de Dados à Fiscalização (MTF)
3.2. Software Básico (SB)
3.3. Identificações e Registros
3.3.1. Número de Identificação do MUS (NIM)
3.3.2. Número de Identificação (NID)
3.3.3. Identificação do Contribuinte Usuário (IC)
3.3.4. Controle de Manutenção Técnica (CMT)
3.3.5. Controle de Variáveis de Medição (CVM)
3.3.6. Parâmetro de Variação de Volume (PVV)
3.3.7. Parâmetro do Tempo de Medidas (PTM)
3.3.8. Registro da Descarga de Combustíveis (RDC)
3.3.9. Registro do Estoque de Combustíveis (REC)
3.3.10. Registro de Saídas dos Bicos (RSB)
3.3.11. Registro de Saídas das Sondas (RSS)
3.3.12. Registro de Situação Operacional (RSO)
3.4. Requisitos Estruturais do MUS
3.4.1. Memória de Dados Históricos (MDH)
3.4.2. Resina de Proteção
3.4.3. Lacração Lógica
3.4.3.1. Requisitos do Acesso Físico
3.4.3.2. Requisitos do Acesso Lógico
3.4.4. Bootloader (BLD)
3.5. Assinatura Digital
3.5.1. Assinatura Digital do AEF
3.5.2. Assinatura Digital do Software Básico
3.6. Validação pelo Bootloader
3.7. Interface com MDH (IDH)
3.8. Interface de Transmissão a Fiscalização (ITF)
3.9. Inicialização do MUS
3.10. Modo de Intervenção Técnica (MIT)
3.10.1. Atualização do Software Básico
3.10.2. Ajuste do Relógio de Tempo Real
4. MÓDULO DE CONTROLE E MEDIÇÃO (MCM)
4.1. Descrição dos Componentes do MCM
4.1.1. Controlador de Medição (CMD)
4.1.2. Memória de Trabalho (MTR)
4.1.3. Controle de Interface e Sensoriamento (CIS)
4.1.4. Alimentação e Baterias (ALM)
4.1.5. Interface Homem Máquina (IHM)
4.1.6. Interface de Gerenciamento e Manutenção (IGM)
4.2. Conectores com Acesso Externo ao MVC
4.3. Eventos do MVC
5. TRANSMISSÃO À FISCALIZAÇÃO
5.1. Padrões Técnicos
5.1.1. Padrão do documento xml
5.1.1.1. Padrão de Codificação
5.1.1.2. Padrão Schema
5.1.1.3. Montagem do Arquivo
5.1.2. Padrão de Comunicação
5.2. Padrão de Mensagem dos Web Services
5.2.1. Validação da Estrutura XML das Mensagens dos Web Services
5.2.2. Schemas XML das Mensagens dos Web Services
5.3. Ambiente Virtual
5.4. Especificação dos Web Services
6. REQUISITOS DA OPERAÇÃO COM A FISCALIZAÇÃO
6.1. Processo de Envio de Dados à Fiscalização
6.2. Processo de Gravação do DCD
6.3. Alteração de Parâmetros do MVC
6.3.1. Envio de Eventos à Fiscalização
6.3.2. Solicitação de Alteração de endereço URL
6.3.3. Alteração do Parâmetro de Periodicidade de Envio
6.3.4. Alteração do Parâmetro de Variação de Volume
6.3.5. Alteração do Parâmetro de Tempo de Medidas
6.4. Situações Operacionais
6.4.1. Leitura de MDH em Virtude de Troca de MUS
6.4.2. Perda de Conexão
7. NORMAS ATENDIDAS
7.1. Normas MUS
7.2. Normas MCM
1. INTRODUÇÃO
1.1. Disposições Gerais
Este Anexo especifica os requisitos que devem ser atendidos pelo Medidor Volumétrico de Combustíveis (MVC) a que se refere a cláusula terceira do Convênio ICMS 59/11, com a finalidade de estabelecer uma base comum para a sua fabricação e uso, bem como para o entendimento entre os diversos agentes envolvidos com as atividades relacionadas ao equipamento.
1.2. Da Concepção de Funcionamento
O equipamento Medidor Volumétrico de Combustíveis (MVC), para atender suas finalidades, deverá atender as seguintes funções:
I – apurar, com base nas sondas de medições, o volume em litros dos estoques presentes nos compartimentos dos tanques de combustíveis;
II – apurar, com base nas sondas de medições, a variação volumétrica do volume em litros das descargas de combustíveis nos compartimentos dos tanques;
III – apurar, com base nas sondas de medições, a variação volumétrica do volume em litros das saídas de combustíveis nos compartimentos dos tanques;
IV – apurar, com base no concentrador ou unidades abastecedoras, o volume em litros das saídas de combustíveis realizadas por meio dos bicos das bombas de abastecimento;
V – registrar e manter na memória de dados históricos, de forma segura, o registro histórico das operações volumétricas e eventos, nas hipóteses e situações definidas neste Anexo;
VI – transferir informações que possibilitem disponibilizar ao sistema de gestão do contribuinte o registro das operações do equipamento e outras informações gerenciais;
VII – enviar os registros das operações e eventos armazenados na memória de dados históricos aos órgãos fiscalizadores;
VIII - disponibilizar informações que possibilitem ao contribuinte e à fiscalização extrair da memória, de forma local, o histórico dos registros das operações e eventos;
IX- disponibilizar informações ao usuário que possibilitem acompanhar o gerenciamento, parametrização e configuração do equipamento a fim de obter informações gerenciais e de controle.
1.3. Da Arquitetura
O Medidor Volumétrico de Combustíveis constitui-se em uma estrutura de um gabinete único ou dual, conforme diagrama de blocos previsto no Anexo IV, com as seguintes características:
I – Para medição e monitoramento, funcionar integrado e interligado com:
a) as sondas de medição, que devem estar instaladas em todos os compartimentos dos tanques de armazenamento de combustíveis líquidos, deverão ser reconhecidas pelo MVC por protocolo do fabricante que assegure sua autenticidade e inviolabilidade;
b) os sensores ambientais;
c) as unidades abastecedoras de combustíveis, admitido a utilização do concentrador de bombas, caso o MVC não suporte o seu tratamento direto;
II – Para o usuário, funcionar integrado e interligado a diversos dispositivos previstos neste Anexo, disponibilizando interfaces elétricas e lógicas para a realização das funções de interface, de forma local no MVC ou remota via sistemas de gestão, vedada a alteração dos dados previstos neste Anexo após o processamento realizado pelo MVC;
III – Para o contribuinte e fiscalização, disponibilizar de modo seguro, interface e meios que possibilitem extrair os dados históricos dos registros das operações armazenados na memória do equipamento;
IV – Para armazenamento e validação, disponibilizar recursos de armazenamento de registros de forma segura com a capacidade de validar os dispositivos onde está prevista a sua autenticação e validação.
1.4. Abreviações e Definições
AEF – Arquivo Eletrônico da Fiscalização: conjunto de dados capturados pelo MVC, gravado em memória não volátil, a serem disponibilizados à fiscalização de forma local ou remota.
ALM – Módulo de Fonte e Baterias: componente responsável pelo fornecimento de energia ao MVC, possuindo gerenciamento para alimentação em caso de falha de energia elétrica externa.
BLD – Bootloader: conjunto fixo de rotinas residentes no MUS, executadas imediatamente após o hardware reset de inicialização da UCP, que implementa as funções de validação do SB ativo e de controle da substituição de versão do SB, sendo que, após o encerramento da execução das funções do BLD inicia a execução das funções do SB.
CIS – Controle de Interface e Sensoriamento: componente que implementa a interface elétrica ou mecânica, realizando o controle, acesso e interligação dos sensores ambientais, das sondas de medição e do concentrador.
CMD – Controlador de Medição: componente responsável pelo gerenciamento das informações dos dispositivos, realizando toda aquisição de dados necessários para controlar as requisições de medição e sensoriamento.
CMT - Controle de Manutenção Técnica: histórico das manutenções gravadas na MDH.
CON – Concentrador: dispositivo com a capacidade de realizar de forma eletrônica a captura do volume das saídas de combustíveis das unidades abastecedoras, disponibilizando-as ao MVC.
CVM - Controle de Variáveis de Medição: identificação das variáveis que afetem as medições e comportamento do MCM.
DG – Dispositivo de Gestão: elemento responsável por receber informações do MVC necessárias à gestão do Posto de Serviço.
DCD – Dispositivo de Captura de Dados: dispositivo de captura de dados específico e exclusivo com a finalidade de receber as informações gravadas na memória de dados históricos.
EFD – Escrituração Fiscal Digital: na forma do Ato COTEPE/ICMS 09/08
IDH – Interface com MDH: componente responsável pela conexão do DCD de forma local, para captura das informações existentes na MDH para fins de auditoria e fiscalização.
IGM – Interface de Gerenciamento e Manutenção: módulo responsável pelo controle e interface do fluxo de informações a dispositivos de gestão externos.
IHM – Interface Homem Máquina: módulo responsável pela apresentação das informações do MVC ao usuário, podendo controlar uma ou mais interfaces opcionais de apresentação, tais como displays, teclados, telas, dispositivos de posicionamento (mouse), impressoras, entre outros.
ITF – Interface de Transmissão à Fiscalização: define o tipo físico da interface para transmissão de dados pela internet aos órgãos fiscalizadores.
LL – Lacração Lógica: capacidade de monitorar e registrar logicamente as comunicações, com objetivo de controlar acessos, identidade dos dispositivos e garantir a validade da origem dos dados.
MCM – Módulo de Controle e Medição: módulo que realiza as funções de controle, medição e sensoriamento previstos para o MVC, atendendo todos os requisitos de hardware necessários para interligação dos equipamentos que cumprirão estas funções, sendo responsável pela leitura do volume de combustível dos compartimentos, dos sensores ambientais, dos dispositivos associados e do concentrador ou das unidades de abastecimento, implementando os requisitos de software necessários para executar todos os algoritmos e cálculos para determinação das medições, eventos e alarmes do sistema.
MDH – Memória de Dados Históricos: memória responsável pelo armazenamento seguro dos registros e eventos previstos neste Anexo.
MIT – Modo de Intervenção Técnica: estado operacional no qual é possibilitada a realização de manutenções no MVC.
MTR – Memória de Trabalho: componente de armazenamento de informações utilizada pelo MCM para processar os dados necessários ao funcionamento do sistema, sem capacidade de interferir no funcionamento do MUS.
MTF – Módulo de Transmissão de dados à Fiscalização: componente com capacidade de transmitir de forma segura e criptografada as informações armazenadas no MUS aos órgãos fiscalizadores.
MUS – Módulo Único Seguro: módulo que contém os componentes que garantem a inviolabilidade e segurança do recebimento, armazenamento e, quando requerido, o envio de informações.
MVC – Medidor Volumétrico de Combustíveis: equipamento que possui simultaneamente as funções de medição volumétrica de combustíveis e de monitoramento ambiental, que permitem, independente do Programa Aplicativo Fiscal (PAF-ECF), do Emissor de Cupom Fiscal (ECF) ou de qualquer outro equipamento de automação comercial, a captura automática, armazenamento, extração de dados e transmissão aos órgãos fiscalizadores das informações definidas neste Anexo.
NID - Número de Identificação: número que identifica o equipamento.
NIN - Número de Identificação do MUS: número que identifica o MUS.
PAE – Parâmetro de Alteração de Endereço: parâmetro para alteração do endereço URL de envio dos dados.
PAR - Parâmetro de Atualização do Relógio: parâmetro definido pela fiscalização tributária contendo a URL de referência a ser usada para ajuste do RTR.
PEM - Protocolo de Envio do MVC: número gerado pelo próprio MVC que identificará de modo único o bloco de registros enviados.
PHV – Programação do Horário de Verão: data de inicio e fim da vigência do horário de verão, indicando ao MVC que no início deste período o RTR deverá ser adiantado em uma hora e no fim deste período o RTR deverá ser atrasado em uma hora.
PPE - Parâmetro de Periodicidade de Envio: contém o intervalo de tempo, em minutos, que determina a periodicidade de envio aos órgãos de fiscalização de todos os eventos registrados na MDH, pendentes de envio.
PRE - Parâmetro de Requisição de Eventos: parâmetro definido pela fiscalização contendo as datas de início e término de eventos a serem enviados.
PRF - Protocolo de Recebimento da Fiscalização: número gerado pelo órgão de fiscalização que identifica um envio do MVC de maneira única ao sistema do órgão, atestando a confirmação da entrega dos dados.
PTM - Parâmetro de Tempo de Medidas: intervalo de tempo, em minutos, para que o MVC realize uma REC.
PVV - Parâmetro de Variação de Volume: volume, em litros, de variação de estoque que gera um registro de descarga de combustível.
RDC - Registro de Descarga de Combustível: volume em litros da descarga de combustível.
REC - Registro de Estoque de Combustível: volume em litros do estoque de combustível.
RSB - Registro de Saídas dos Bicos: saídas de combustíveis realizadas pelos bicos das bombas de abastecimento.
RSO - Registro de Situação Operacional: indicação de que o equipamento MVC está ativo e em operação com a fiscalização ambiental.
RSS - Registro de Saídas das Sondas: volume de saídas de combustíveis medido pelas sondas de medição.
RTR – Relógio de Tempo Real: dispositivo capaz de fornecer a data e a hora para o funcionamento do MVC.
SB – Sofware Básico: conjunto fixo de rotinas residentes na UCP, que implementa as funções de controle do MVC.
SA – Sensor Ambiental: dispositivo capaz de identificar a presença de líquidos para fins de controle ambiental nos locais monitorados.
SM – Sonda de Medição: dispositivo de medição de nível, instalado nos compartimentos dos tanques de combustíveis líquidos.
TVA – Tentativa de Violação e Acesso: é o registro na MDH da tentativa de acesso físico indevido às partes protegidas pela lacração lógica.
UCP – Unidade Central de Processamento: componente responsável pelo gerenciamento e segurança do MUS.
Web Services – solução utilizada pela fiscalização para integrar seus sistemas com o MVC, com a finalidade de receber e enviar informações em formato XML.
2. DESCRIÇÃO DOS TIPOS
O Medidor Volumétrico de Combustíveis (MVC) compreende dois tipos:
2.1. Medidor Volumétrico de Combustíveis Compacto (MVCC)
Equipamento que reúne em um único gabinete as funções primárias de medição, monitoramento ambiental e de transmissão de dados, possuindo módulos distintos denominados, respectivamente, de Modulo de Controle e Medição (MCM) e Modulo Único Seguro (MUS), conforme diagrama de blocos do Anexo IV.
2.2. Medidor Volumétrico de Combustíveis Dual (MVCD)
Equipamento que reúne em gabinetes distintos o Módulo de Controle e Medição (MCM), com as funções primárias de medição e monitoramento ambiental, e o Módulo Único Seguro (MUS), com a função de transmissão de dados, conforme diagrama de blocos do Anexo IV.
2.3. Requisitos Obrigatórios
O MVC deve ter capacidade mínima de suportar doze compartimentos de estocagem de combustíveis líquidos, todo sensoriamento ambiental associado e registrar como evento todas as aberturas do gabinete que contém o MUS, devendo o Módulo de Controle e Medição (MCM) e o Modulo Único Seguro (MUS), tanto no modelo MVCC quanto no modelo MVCD, ter sua interligação protegida por Lacração Lógica (LL).
3. MÓDULO ÚNICO SEGURO (MUS)
Conjunto de componentes reunidos em um único módulo protegido por Lacração Lógica (LL) com as funções primárias de capturar, registrar, disponibilizar e enviar as informações provenientes do Módulo de Controle e Medição (MCM).
3.1. Descrição dos Componentes do MUS: o MUS deve possuir os seguintes componentes, podendo agregar outros, desde que não conflitem com os requisitos previstos neste Ato.
3.1.1. Unidade Central de Processamento (UCP): recursos de hardware e software programáveis, previstos neste Anexo, responsáveis pela captura das informações provenientes do Módulo de Controle e Medição (MCM), com capacidade de realizar a verificação da autenticidade do seu Software Básico (SB) após reset do processador, conforme previsto no item 3.4.4.
3.1.2. Relógio de Tempo Real (RTR): componente residente no MUS responsável pelo registro da data, hora, minuto e segundos para gravação da estampa de tempo das informações.
3.1.3. Memória de Dados Históricos (MDH): deve possuir requisitos estruturais conforme item 3.4.1, sendo responsável por armazenar, por no mínimo 5 (cinco) anos, os eventos descritos no Anexo II, não sendo permitida sua manutenção e substituição.
3.1.4. Módulo de Transmissão de Dados à Fiscalização (MTF): componente responsável por enviar via Internet aos órgãos fiscalizadores os registros e eventos gravados na MDH, previstos no Anexo II, com endereçamentos de URL configuráveis, sendo que o formato, protocolo e a segurança na transmissão são os definidos no item 5, devendo toda alteração de endereçamento de URL ser registrada como evento.
3.2. Software Básico (SB)
O Software Básico é o conjunto fixo de rotinas que implementa as funções de controle do MUS previstas neste Anexo, sendo que o dispositivo onde está armazenado, instalado e validado, deve permitir acesso para leitura direta do seu conteúdo por meio de dispositivo específico para este fim, durante a realização de análise estrutural ou de perícia técnica solicitada pela fiscalização, bem como via conector de comunicação externa utilizando programa aplicativo específico desenvolvido pelo fabricante do MVC e entregue a fiscalização. A versão do SB pode ser atualizada remota ou localmente e deve ser identificada com 6 (seis) dígitos decimais, no formato XX.XX.XX, em que valores crescentes indicam versões sucessivas do software, obedecendo aos seguintes critérios:
I - o primeiro e o segundo dígitos devem ser incrementados de uma unidade, a partir do valor inicial 01, sempre que houver atualização da versão por motivo de mudança na legislação;
II - o terceiro e o quarto dígitos devem ser incrementados de uma unidade, a partir do valor inicial 00, sempre que houver atualização da versão por motivo de correção de defeito;
III - os dois últimos dígitos podem ser utilizados livremente, a partir do valor inicial 00, excluídas as situações previstas nas alíneas anteriores.
3.3. Identificações e Registros
Deve ficar registrado na MDH, devidamente protegido por Lacração Lógica (LL) do MUS, no mínimo as seguintes identificações e registros:
3.3.1. Número de Identificação do MUS (NIM): o MUS deve possuir identificação única composta por 5 (cinco) caracteres numéricos, devendo ser gravado uma única vez na MDH, não permitindo ao equipamento disponibilizar comandos para apagamento ou alteração deste número de identificação.
3.3.2. Número de Identificação (NID): o MVC deve possuir um número único que permita a identificação individualizada do equipamento, devendo ser gravado uma única vez na MDH, sendo vedado possuir comandos para apagamento ou alteração do NID, sendo permitida a utilização de mais de um MVC por estabelecimento.
O NID deverá ser visualizado na IHM sempre que um DCD for inserido no IDH, sendo representando por um conjunto de 20 (vinte) caracteres alfanuméricos composto da seguinte forma:
I - o caracter “D”;
II - os dois primeiros caracteres: para registro do código do fabricante ou importador, atribuído pela Secretaria Executiva do CONFAZ;
III - o terceiro e o quarto caracteres: para registro do código do modelo do equipamento, atribuído pela Secretaria Executiva do CONFAZ;
IV - o quinto e sexto caracteres: para indicar o ano de fabricação;
V - o sétimo, oitavo, novo, décimo e décimo primeiro caracteres: para o Número de Identificação do MUS conforme item 3.3.1;
VI - os demais caracteres devem ser utilizados pelo fabricante ou importador de forma a individualizar o equipamento.
3.3.3. Identificação do Contribuinte Usuário (IC): o contribuinte usuário será identificado no MVC por meio de seus números de inscrições no CNPJ e Inscrição Estadual, que serão gravados na MDH.
3.3.4. Controle de Manutenção Técnica (CMT): as eventuais manutenções técnicas a serem realizadas no MCM devem ter seu histórico de início e fim registradas na MDH com a respectiva data, hora, minuto e segundos, devendo ser realizado um REC imediatamente posterior ao evento de CMT e, quando o equipamento possibilitar, um REC imediatamente anterior ao CMT.
3.3.5. Controle de Variáveis de Medição (CVM): o MVC deve registrar como evento, de forma automática, todas as alterações de variáveis que afetem as medições e comportamento do MCM, tais como tabelas de arqueamento, medidas de tanque, cadastro de dados do local, entre outras, exceto parâmetros definidos pela fiscalização tributária, contendo data, hora, minuto e segundos da operação, descritivo da alteração realizada e se a operação foi executada pelo fabricante ou contribuinte, devendo ser realizado um REC imediatamente anterior e imediatamente posterior ao evento de CVM.
3.3.6. Parâmetro de Variação de Volume (PVV): volume de variação mínima positiva, em litros, definido pela Unidade da Federação, para que o MVC registre uma RDC, sendo parametrizado pelo fabricante a variação mínima de 200 litros no intervalo inferior a um minuto.
3.3.7. Parâmetro de Tempo de Medidas (PTM): intervalo de tempo definido pela Unidade da Federação para que o MVC realize um REC, sendo parametrizado pelo fabricante o intervalo mínimo de 30 minutos.
3.3.8. Registro de Descarga de Combustível (RDC): volume, em litros, da descarga de combustível, registrada de forma automática, contendo o tipo de combustível, o respectivo compartimento, a temperatura, a data, hora, minutos e segundos da ocorrência, permitindo ao usuário, na impossibilidade do registro automático, realizar o RDC manualmente em situações de contingência, devendo, em qualquer situação, os compartimentos dos tanques seguirem a numeração utilizada na EFD do contribuinte e o volume de descarga ser apurado considerando os abastecimentos realizados durante o período de descarga. O RDC é representado pelo evento 101 da tabela de eventos do Anexo II.
3.3.9. Registro de Estoque de Combustível (REC): volume em litros do estoque de combustível, contemplando os tipos de combustíveis, os números dos compartimentos, a temperatura e a respectiva data, hora, minutos e segundos do instante da medição, devendo os compartimentos dos tanques seguirem a numeração utilizada na EFD do contribuinte. O REC é representado pelos eventos 100 e 103 da tabela de eventos do Anexo II
Nas situações onde a sonda instalada no compartimento não conseguir realizar uma coleta de dados, um evento de alerta deverá ser gerado em substituição ao evento de medição. O evento de alerta será representado pelo evento 104 da tabela de eventos do Anexo II e deverá apresentar volume e temperatura zerados.
Não havendo qualquer sonda registrada no equipamento MVC, o evento 183 da tabela de eventos do Anexo II deve ser gerado.
3.3.10. Registro de Saídas dos Bicos (RSB): totalização do volume diário de saídas de combustíveis, em litros, realizadas no período compreendido entre 0:00h e 23:59h, apurado por bico de abastecimento, contendo a data, hora, minuto e segundo da leitura do dado, o tipo de combustível, o número do bico de abastecimento, o volume, os encerrantes volumétricos inicial e final e o número do compartimento vinculado ao bico, devendo:
I - ser criado um novo RSB sempre que ocorrer quebra ou descontinuidade do encerrante, com a respectiva data e hora da detecção;
II - os bicos e os compartimentos dos tanques seguirem a numeração utilizada na EFD do contribuinte;
III - a vinculação dos bicos aos respectivos compartimentos dos tanques deverão seguir a utilizada na EFD do contribuinte;
IV - o registro ser gravado no primeiro minuto do dia subsequente ao fechamento e, quando o MVC estiver desligado, por ocasião do retorno ao funcionamento do MVC.
O RSB é representado pelo evento 203 da tabela de eventos do Anexo II.
Nas situações onde nenhum bico estiver registrado no equipamento MVC, impossibilitando a totalização de saídas por bico, o evento 184 da tabela de eventos do Anexo II deverá ser gerado.
3.3.11. Registro de Saídas das Sondas (RSS): totalização do volume diário de saídas de combustíveis, em litros, realizadas no período compreendido entre 0:00h e 23:59h, apurada pelas sondas de medição (SM), contendo a data, hora, minuto e segundo da leitura do dado, o tipo de combustível, o volume e o compartimento, observando-se os incisos II e IV do item 3.3.10. O RSS é representado pelo evento 102 da tabela de eventos do Anexo II.
Nas situações onde nenhuma sonda estiver registrada no equipamento MVC, impossibilitando a totalização de saídas, o evento 183 da tabela de eventos do Anexo II deverá ser gerado.
3.3.12. Registro da Situação Operacional (RSO): indicação periódica a fiscalização ambiental que o equipamento MVC está ativo e funcionando em conformidade, composto pela data, hora, minutos e segundos. O RSA é representado pelo evento 307 da tabela de eventos do Anexo II.
O RSO deve ser gerado periodicamente, quando o RTR alcançar um intervalo de tempo entre o momento atual o último evento ambiental for superior ao PPE.
3.4. Requisitos Estruturais do MUS
3.4.1. Memória de Dados Históricos (MDH): deve ser protegida por resina, indissociável do MUS e possuir as seguintes características básicas:
I - ser não volátil;
II - possuir recursos associados de hardware semicondutor configurável ou programável que não permitam o seu apagamento ou a modificação de dados gravados;
não deve estar acessível para programação ou configuração;
III - deve estar programada de forma a permitir a leitura direta de seu conteúdo por meio de dispositivo específico para este fim, durante a realização de análise estrutural ou de perícia técnica solicitada pela fiscalização;
3.4.2. Resina de Proteção: deve possuir as seguintes características:
I - ser termofixa com temperatura de transição térmica igual ou superior a 120ºC;
II - apresentar rigidez dielétrica igual ou superior a 8 KV/mm conforme IEC 243;
III - apresentar dureza igual ou superior a 72 na escala Shore D;
IV - ser opaca;
V - ser insolúvel em água;
VI - não ser hidrofílica.
3.4.3. Lacração Lógica: função que consiste em monitorar, verificar e registrar na MDH os eventos da ausência de integridade do acesso, seja físico, referente a violação das partes internas do MUS ou lógico, referente a autenticação da comunicação dos dispositivos.
3.4.3.1. Requisitos do Acesso Físico:
I - as aberturas desobstruídas na parte externa ao MUS não devem permitir o acesso físico às partes protegidas pela lacração, com objetos metálicos de diâmetro maior ou igual a 0,4mm;
II - deve dispor de mecanismo para detectar, mesmo em situação de falta de energia, um deslocamento de no máximo 5 mm entre as partes do MUS;
III - ocorrendo qualquer um dos acessos físicos previstos nos incisos I e II, o Software Básico (SB) deve reconhecer e registrar na MDH este evento como Tentativa de Violação e Acesso (TVA).
3.4.3.2. Requisitos do Acesso Lógico: deve assegurar que os dispositivos se comuniquem entre si somente se houver recíproco reconhecimento e validação, sendo que o mecanismo de conexão pode ser baseado em protocolo de comunicação por desafio, tipo CHAP, ou outro com as mesmas características, que deve ser testado e identificado no Laudo emitido pelo Órgão Técnico Credenciado, devendo:
I - a validação ocorrer sempre na partida dos equipamentos, nos eventuais casos de interrupção momentânea de comunicação e também de forma aleatória durante a troca de dados.
II - no caso do MUS, somente manter a comunicação com o MCM, e vice-versa, se estiver assegurada a integridade dos dados e a unicidade do MVC.
III - o MUS registrar como evento sempre que o MCM não for autenticado, tiver falha nas funções de medição, estiver desconectado e sempre que retornar às suas funções normais.
3.4.4. Bootloader (BLD): a implementação lógica e física do Bootloader deverá garantir sua autenticidade, a validação do SB de forma inequívoca e a substituição de suas versões, por meio de chaves criptográficas, de conhecimento exclusivo do fabricante e com a utilização de algoritmos criptográficos com padrões de segurança reconhecidos pelo mercado.
3.5.1. Assinatura Digital do AEF (Nova redação dada pelo Ato Cotepe/ICMS 35/16, efeitos a parir de 01.01.17)
As assinaturas digitais devem ser implementadas utilizando-se o padrão de assinatura digital “XML Digital Signature”, com chave privada de 1024 bits, com padrões de criptografia assimétrica RSA, algoritmo “message digest” SHA-1 e utilização das transformações Enveloped e C14N.
O conteúdo constante do AEF produzido com a utilização deste processo de certificação presume-se verdadeiro em relação aos signatários, na forma do art. 219 da Lei nº 10.406, de 10 de janeiro de 2002.
Para todos os arquivos eletrônicos digitalmente assinados, extraídos de equipamentos MVC, utilizar-se-ão as chaves previamente especificadas, certificadas pelo próprio fabricante, em conformidade com a faculdade prevista no § 2º do art. 10 da Medida Provisória nº 2.200-2, de 24 de agosto de 2001.
As mensagens utilizam o padrão de assinatura XML definido no endereço eletrônico "http://www.w3.org/TR/xmldsig-core/ ". 3.5.2. Assinatura Digital do Software Básico
O SB deve ser assinado digitalmente e as chaves devem observar as seguintes características:
I - a pública, ser armazenada na Memória de Dados Histórico (MDH) e utilizada nas rotinas de verificação de autenticidade do SB;
II - a privada, ser armazenada no MUS e ser de conhecimento exclusivo do fabricante;
III - terem no mínimo 256 bits.
3.6. Validação pelo Bootloader
Sempre que o MUS for energizado, o controle será assumido exclusivamente pelo BLD implementado conforme requisitos estruturais, sendo que:
I - o BLD deverá realizar a validação da assinatura digital da versão do SB instalado e, caso não seja validada, o BLD deve apagar as chaves privadas e o MUS deve ficar inoperante; estando validada, deve proceder a substituição do SB, se houver nova versão disponível, contemplando os requisitos de segurança de verificação de chaves e promover um software RESET.
II - em caso de tentativa mal sucedida de substituição do SB deve ser gravado evento na MDH, mantendo o SB original e válido em funcionamento.
III - o BLD não deve estar acessível para programação ou configuração, devendo estar programado de forma a permitir a leitura direta de seu conteúdo por meio de dispositivo específico para este fim, durante a realização de análise estrutural ou de perícia técnica solicitada pela fiscalização.
3.7. Interface com MDH (IDH)
Interface para exportação dos dados armazenados na MDH para DCD, previsto no inciso II do item 4.2, sendo sua presença na interface reconhecida automaticamente e cujo andamento e conclusão da exportação devem ser informados ao usuário por meio de IHM. Os dados exportados por meio desta interface devem manter identidade com os registros e eventos armazenados no MUS”;
3.8. Interface de Transmissão à Fiscalização (ITF)
A comunicação remota entre o MVC e os órgãos de fiscalização se estabelecerá por meio dos dispositivos de interface de comunicação definidos no inciso III do item 4.2.
A ITF estabelecerá comunicação externa por iniciativa própria de forma automática, conforme parâmetros previamente programados para comunicação remota aos órgãos de fiscalização, para acesso das informações.
O protocolo de comunicação e formato dos dados estão estabelecidos no item 5 deste Anexo.
Os dados transmitidos devem manter identidade com os registros e eventos armazenados no MUS e seu formato de exportação deve ser o mesmo da interface prevista no item 3.7.
3.9. Inicialização do MUS
Na inicialização do MUS, que precede a sua entrada em operação normal, deverão ser configuradas as informações necessárias a essa operação, que incluem, entre outras: os identificadores, a data e o instante de tempo correntes, os atributos de usuários, os códigos de acesso, as chaves criptográficas e os parâmetros para o estabelecimento da comunicação remota, devendo esta inicialização ser registrada como evento.
3.10. Modo de Intervenção Técnica (MIT)
O MIT consiste no registro de inicio e término das manutenções realizadas no MUS, tais como atualização de SB, ajuste do RTR e outras manutenções que interfiram na sua operação, devendo ter sua descrição registrada no evento de Alteração de Parâmetro do MUS.
3.10.1. Atualização do Software Básico
Deve seguir procedimento descrito no item 3.2 e registrar na MDH, como evento, as atualizações de SB realizadas e as tentativas mal sucedidas.
3.10.2. Ajuste do Relógio de Tempo Real
O SB deve permitir o ajuste do relógio de tempo real por meio do PAR, a qualquer momento, sendo gravado como evento na MDH, observando as seguintes condições:
I - o avanço ou o recuo para ajuste decorrente de horário de verão, somente é permitido imediatamente após a gravação de dados na MDH e antes do envio qualquer dado via internet;
II - o avanço ou o recuo além cinco minutos é permitido para efeito de correções, sendo registrado na MDH como evento;
III - os valores ajustados de data e hora deverão ser uma data posterior ao conjunto de data e hora do último dado gravado na MDH, sendo obrigatoriamente válidos e executado em MIT, exceto no caso do item IV;
IV - a fiscalização tributária poderá realizar o ajuste do RTR, desde de que provenha de comandos por internet.
4. MODULO DE CONTROLE E MEDIÇÃO (MCM)
O módulo de controle e medição deve ser dotado de características funcionais que observem os modos de operação, interfaces, comunicação, características estruturais e outros detalhes descritos abaixo.
4.1. Descrição dos Componentes do MCM
O MCM deve possuir os seguintes componentes, podendo agregar outros, desde que não conflitem com os requisitos previstos neste Anexo.
4.1.1. Controlador de Medição (CMD)
É o componente responsável pela determinação do volume de combustível e do monitoramento ambiental por meio de algoritmos de controle, a partir das informações recebidas das sondas de medição, dos sensores ambientais, do concentrador, das unidades de abastecimento e de outros dispositivos externos, processando as informações por meio de protocolos específicos, disponibilizando informações para o MUS, a IHM e a IGM.
4.1.2. Memória de Trabalho (MTR)
É o componente que armazena a base de dados gerada pela leitura dos dispositivos de medição, de sensoriamento, programas para processamento das informações, algoritmos de controle e parâmetros de configuração do MVC.
4.1.3. Controle de Interface e Sensoriamento (CIS)
Interface física responsável pela adequação elétrica, processamento de sinais e barreiras de segurança, quando aplicável, e proteção mecânica para atendimento das normas vigentes, possibilitando abrigar todas as proteções elétricas e mecânicas e a lógica eletrônica de interface para o concentrador, unidades de abastecimento, sondas de medição, sensores ambientais, ou outros tipos de sensores e dispositivos utilizados, devendo a comunicação com a sonda de medição possuir lacração lógica, para controlar a autenticidade das informações recebidas.
4.1.4. Alimentação e Baterias (ALM)
Componente que fornece a alimentação ao MVC, gerenciando as baterias, que são os dispositivos acumuladores de energia para fornecimento ininterrupto de energia, capaz de manter o MVC operacional por no mínimo uma hora.
4.1.5. Interface Homem Maquina (IHM)
Componente que controla os dispositivos de interface ao usuário para permitir o acesso às informações de medição, os estados dos sensores, os relatórios gerenciais e possibilitar a configuração do sistema, podendo ser por meio de displays, teclados, mouse, ou outros.
4.1.6. Interface de Gerenciamento e Manutenção (IGM)
Componente responsável pela interface aos Dispositivos de Gestão, realizando o controle e adequação dos protocolos de comunicação necessários para parametrização do MCM, receber e transmitir informações gerenciais de medição e sensoriamento ambiental aos dispositivos de gestão externos.
4.2. Conectores com Acesso Externo ao MVC
Devem atender aos seguintes requisitos:
I - não poderá existir conector externo sem função definida;
II - ser padrão USB (Universal Serial Bus) 1.1 ou superior do tipo “A” para suporte de memória tipo “Pen Drive” com formatação FAT 32 , para o DCD de armazenamento externo do IDH.
III - ser padrão RJ-45 (Ethernet over twisted pair), para conexão Ethernet, de implementação obrigatória para a Interface de Transmissão à Fiscalização (ITF) e de implementação facultativa outra tecnologia que atenda as especificações estabelecidas neste Anexo.
4.3. Eventos do MVC
O MUS deverá registrar na MDH e encaminhar às fiscalizações os eventos do MVC, conforme Anexo II (Tabela de Registros e Eventos).
5. TRANSMISSÃO À FISCALIZAÇÃO
Os órgãos de fiscalização disponibilizarão os seguintes serviços:
I - recepção dos registros e eventos de responsabilidade do órgão de fiscalização tributária assinalados na coluna “Tributária” do Anexo II (Tabela de Registros e Eventos).
II - recepção dos registros e eventos de responsabilidade do órgão de fiscalização ambiental assinalados na coluna “Ambiental” do Anexo II (Tabela de Registros e Eventos).
Os serviços serão atendidos por Web Service específicos e o fluxo de comunicação será iniciado pelo MVC por meio do envio de uma mensagem ao Web Service, conforme configuração pré-estabelecida no equipamento.
Os serviços previstos são síncronos. O processamento da solicitação de serviço é concluído na mesma conexão, com a devolução de uma mensagem. Um protocolo de entrega será enviado nesta mensagem quando as validações apontadas no Anexo III forem satisfeitas.
Os dados gravados na MDH devem ser enviados em ordem cronológica desde a última transmissão bem sucedida.
Opcionalmente na mensagem de resposta o Web Service pode incluir uma tarefa ao equipamento MVC. Esta tarefa será uma mudança nos parâmetros configuráveis do equipamento.
5.1. Padrões Técnicos
5.1.1. Padrão de Documento XML
5.1.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: , sendo que cada arquivo XML somente poderá ter uma única declaração.
A declaração do “namespace” da assinatura digital deverá ser realizada na própria tag .
O layout de cada arquivo está definido na especificação de cada Web Service, no Anexo III.
5.1.1.2. Padrão de Schema
Para garantir a correta formação dos arquivos XML, o equipamento MVC deverá gerar o arquivo de mensagem com Schema do XML (XSD – XML Schema Definition) válido, disponibilizado no site do CONFAZ.
5.1.1.3. Montagem do Arquivo
O arquivo XML de transmissão das informações contidas na MDH às fiscalizações será gerado observando as seguintes regras:
I - não incluir "zeros não significativos" para campos numéricos;
II - não incluir "espaços" no início ou no final de campos numéricos e alfanuméricos;
III - não incluir comentários no arquivo XML;
IV - não incluir anotação e documentação no arquivo XML (TAG annotation e TAG documentation);
V - não incluir caracteres de formatação entre as TAGs no arquivo XML ("line-feed", "carriage return", "tab", e caractere de espaço).
VI - o tamanho dos arquivos enviados não poderá ser superior a 10 Mbytes.
5.1.2. Padrão de Comunicação
A comunicação será baseada em Web Services disponibilizados pelos órgãos de fiscalização dos Estados.
O meio físico de comunicação utilizado será a Internet, com o uso do protocolo SSL versão 3.0, com autenticação do serviço disponibilizado pelo órgão de fiscalização. A autenticidade do emitente será garantida pela assinatura da mensagem pelo MVC com a chave privada registrada no equipamento.
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 dos órgãos de fiscalização e o MVC será realizada no padrão SOAP versão 1.2, com troca de mensagens XML no padrão Style/Encoding: Document/Literal.
5.2. Padrão de Mensagens dos Web Services
5.2.1. Validação da Estrutura XML das Mensagens dos Web Services
As informações são enviadas ou recebidas dos Web Services por meio de mensagens no padrão XML definido na documentação de cada Web Services, conforme Anexo III.
As alterações de leiaute e da estrutura de dados XML realizadas nas mensagens são controladas por meio da atribuição de um número de versão para a mensagem.
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.
5.2.2. 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”, como segue:
I - Medicao_v1.01.xsd (Schema XML do envio de mensagem de medição, versão 1.01);
II - Ambiental_v1.01.xsd (Schema XML do envio de mensagem ambiental, versão 1.01);
III – Retorno_v1.01.xsd (Schema XML do retorno de mensagem do Web Services, versão 1.01);
IV - tiposBasicos.xsd (Schema XML dos tipos básicos).
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 por Ato COTEPE e poderão ocorrer sempre que se fizerem necessárias.
As informações gravadas na MDH deverão manter a versão do Schema usado por ocasião da sua gravação.
5.3. Ambiente Virtual
Os órgãos de fiscalização devem desenvolver seus sistemas próprios de recepção de mensagens, seguindo layout estabelecido neste documento.
Os órgãos de fiscalização estão livres para definir prazos para o estabelecimento dos serviços quem envolvem este sistema.
5.4. Especificação dos Web Services
As URL dos Web Services serão disponibilizadas pelos órgãos de fiscalização. Acessando a URL pode ser obtido o WSDL (Web Services Description Language) de cada Web Services.
Estes Web Services estão definidos no Anexo III.
6. REQUISITOS DA OPERAÇÃO COM A FISCALIZAÇÃO
Descreve-se a seguir a operação de transferência de dados, forma de armazenamento e a análise de contingências para cumprir os requisitos deste Anexo.
6.1. Processo de Envio de Dados à Fiscalização
O MVC deve iniciar a conexão com o Web Service:
I - periodicamente, quando o RTR alcançar um intervalo de tempo entre o momento atual e a última mensagem transmitida maior que o PPE.
II - sempre que o equipamento for energizado e o intervalo de tempo entre o momento atual do RTR e o momento da última mensagem transmitida for maior que o PPE.

Com o equipamento em conexão on-line, devem ser transmitidos os dados registrados na MDH desde a última transmissão bem sucedida.
O arquivo deverá conter em sua estrutura o PEM gerado pelo próprio MVC que identificará de modo único o bloco de registros enviados.
Utilizando a mesma conexão, o Web Service responderá ao MVC conforme disposto no Anexo III e, satisfazendo as regras de validação, devolverá uma resposta contendo o PRF.
O MVC deverá efetuar o armazenamento do PRF associando-o diretamente ao PEM sem realizar a alteração dos registros existentes na MDH.
O MVC deve manter associado aos eventos e registros, que podem ser entregues tanto para a fiscalização tributária como para a fiscalização ambiental, os respectivos protocolos de entrega dos dois órgãos.

6.2. Processo de Gravação do DCD
Para gravação dos dados contidos no MDH, deve ser inserido o DCD na IDH e, a partir deste momento a IHM deverá solicitar se o DCD a ser criado é do tipo DCD de Fiscalização Tributária ou DCD de Fiscalização Ambiental.
O usuário será orientado pela IHM quanto à seleção do período no qual se deseja que as informações sejam gravadas da MDH para o DCD.

Os arquivos gravados no DCD devem seguir o leiaute definido no Anexo III.
Nos casos em que esteja registrado na MDH o PRF dos dados obtidos em uma conexão direta do MVC, a montagem do arquivo deverá apresentar tanto o PEM como o PRF associado em sua estrutura.
Pode ser também transmitido à fiscalização, por meio de uma conexão específica que não utilize a do MVC, os dados gravados no DCD por processo manual. Nesta situação, a fiscalização emitirá protocolo de recebimento.
É dispensada a gravação do número do PRF no MVC quando a remessa às entidades fiscalizadoras for realizada por meio de gravação dos eventos no DCD, hipótese em que a comprovação da entrega das informações se fará por meio do protocolo de recebimento.

6.3. Alteração de Parâmetros do MVC
A fiscalização poderá, a qualquer momento, enviar requisição de alteração de parâmetros utilizando conexão aberta entre MVC e Web Service, conforme definido neste Anexo, permitida também alteração de parâmetros por intermédio do MIT, devendo o MVC registrar na MDH, como evento, toda alteração de parâmetros.

6.3.1 Alteração no Relógio de Tempo Real
A fiscalização poderá requisitar a atualização do RTR por meio do envio de uma URL que indique um serviço de NTP para servir de referência na atualização do mesmo.
A alteração do PRE pelo MVC deve gerar o evento 126 da tabela de eventos do Anexo II.
Parâmetro de Atualização do Relógio (PAR).

6.3.2. Envio de Eventos à Fiscalização
A fiscalização poderá requisitar o envio dos eventos registrados na MDH por meio do Parâmetro de Requisição de Eventos – PRE.
A alteração do PRE pelo MVC deve gerar um evento 165 da tabela de eventos do Anexo II.

6.3.3. Solicitação de Alteração de endereço URL
A fiscalização poderá requisitar a alteração da URL de endereçamento por meio do PAE.
A alteração do PAE pelo MVC deve gerar um evento 122 da tabela de eventos do Anexo II para a fiscalização tributária e um evento 305 da tabela de eventos do Anexo II para a fiscalização ambiental.

6.3.4. Alteração do Parâmetro de Periodicidade de Envio
A fiscalização poderá alterar o PPE devendo o MVC suportar o envio de dados em no mínimo 30 minutos e no máximo em 1.440 minutos.
O parâmetro PPE com valor zero minuto indicará que não haverá transmissão via internet.
A alteração do PPE pelo MVC deve gerar um evento 125 da tabela de eventos do Anexo II para a fiscalização tributária e um evento 306 da tabela de eventos do Anexo II para a fiscalização ambiental.

6.3.5. Alteração do Parâmetro de Variação de Volume
A fiscalização tributária poderá requisitar a alteração do PVV, conforme definido no item 3.3.6.
A alteração do PRE pelo MVC deve gerar um evento 120 da tabela de eventos do Anexo II.

6.3.6. Alteração do Parâmetro de Tempo de Medidas
A fiscalização tributária poderá requisitar a alteração do PTM, conforme definido no item 3.3.7.
A alteração do PTM pelo MVC deve gerar um evento 121 da tabela de eventos do Anexo II.

6.3.7. Programação do Horário de Verão
A fiscalização tributária poderá requisitar a programação do horário de verão (PHV) no equipamento, enviando a data de início e fim de vigência do horário de verão.
É permitido a parametrização de um ou mais períodos sendo que a exclusão de um período informado equivocamente se dá pelo envio de uma programação de horário de verão com início e fim de vigência na mesma data.
A inclusão ou alteração do PHV pelo MVC deve gerar um evento 127 da tabela de eventos do Anexo II.

6.4. Situações Operacionais

6.4.1. Leitura de MDH em Virtude de Troca de MUS
Em caso do MUS estar operacional e ser necessária à troca deste por falta de espaço na MDH, caberá ao usuário do MVC efetuar em um DCD um arquivo de recuperação de dados da MDH do MUS que será trocado.

6.4.2. Perda de Conexão
Em uma situação em que os dados são encaminhados periodicamente ao Web Service e ocorrer uma perda de conexão, o MVC continuará efetuando a gravação das informações na MDH e tentará na frequência determinada pelo PPE a retomada da conexão.
Quando a conexão for restabelecida, caberá ao MVC enviar os dados da MDH que estiverem pendentes de envio, encerrando-se quando todos os dados forem recebidos pelo Web Service.

7. NORMAS ATENDIDAS
O MVC deve seguir as terminologias utilizadas de acordo com a IEC 60050 – 426 Vocabulário Eletrotécnico Internacional (IEV) parte 426 – Equipamentos para atmosferas explosivas, devendo atender também às seguintes normas:

7.1. Normas MUS
IEC 61000-4-2 - Imunidade a Descarga Eletrostática (ESD)
IEC 61000-4-3 - Imunidade a RF Irradiada
IEC 61000-4-4 - Imunidade a Transiente Elétrico Rápido (EFTB) – Transiente de Energia
IEC 61000-4-5 - Imunidade a Surtos – Transiente de Energia
IEC 61000-4-6 - Imunidade a RF Conduzida –Transiente de Energia
IEC 61000-4-11 - Imunidade a Redução e Interrupção de Tensão (DIP).

7.2. Normas MCM
IEC 60079-0 - Atmosferas Explosivas – Parte 0 Requisitos Gerais
IEC 60079 -10-1:2009 Atmosferas Explosivas – Parte 10-1: Classificação de Áreas – Atmosferas Explosivas de gás.
IEC 60079-11:2009 Atmosferas explosivas — Parte 11: Proteção de equipamento por segurança intrínseca "i".
IEC 60079-17:2009 Atmosferas explosivas – Parte 17: Inspeção e manutenção de instalações elétricas.
IEC 60079-19:2008 Equipamentos elétricos para atmosferas explosivas – Parte 19: Reparo, revisão e recuperação de equipamentos utilizados em atmosferas explosivas.
IEC 60079-25:2010 Explosive atmospheres - Part 25: Intrinsically safe electrical systems.
Portaria 179 do INMETRO Regulamentação de uso, comercialização e avaliação de conformidade de equipamentos para atmosferas explosivas no território brasileiro bem como identificação e uso de selos de conformidade do INMETRO.
NBR 13.784 Armazenamento de Líquidos Inflamáveis e Combustíveis – Seleção de Métodos para detecção de vazamentos e ensaios de estanqueidade em sistema de armazenamento subterrâneo.”
Redação original
ANEXO I
ESPECIFICAÇÃO DE REQUISITOS DO MEDIDOR VOLUMÉTRICO DE COMBUSTÍVEIS (ER-MVC)
SUMÁRIO
ANEXO II
Tabela de Registros e Eventos
(Nova redação dada ao ANEXO II pelo Ato COTEPE/ICMS 50/15)
TIPO EVENTO
IDDescriçãoMVCTributáriaAmbiental
Registro de Medição
100Registro de Estoque de CombustívelXX
101Registro da Descarga de ProdutoXX
102Registro de Saídas de SondasXX
103Registro da Descarga de Produto Registrada ManualmenteXX
104Medição inoperanteXX
Registro Alteração Parametrização
120Alteração de Parametrização de VolumeXX
121Alteração de Parametrização de Tempo de MedidasXX
122Alteração de URL da Fiscalização TributáriaXX
124Alteração de Parametrização do MCM (dados cadastrais)XX
125Alteração do Parâmetro de Periodicidade de EnvioX X
126 Alteração no relógio solicitado pelo órgão de fiscalização X X
127Programação do horário de verãoXX
128Alteração do relógio – entrada/saída do Horário de VerãoXXX
Registros de Ocorrências MUS/MF
140Inicio de Operação MUS/MFXXX
141MUS/MF desligadoXXX
143Recurso da MDH esgotado (97%)XX
144MCM/MM Desconectado (Sem Comunicação com o MCM/MM)XXX
145MCM/MM Ativo (retorno da Operação do MCM/MM)XXX
146MCM/MM Inativo (Falha nas funções de Medição)XXX
147MCM Inválido (MCM não foi autenticado)XXX
148Falta de comunicação com a Fiscalização TributáriaXX
150Retorno de comunicação com a Fiscalização TributáriaXX
151MUS/MF Inicio de ManutençãoXXX
152MUS/MF Fim de manutençãoXXX
153Atualização de SBXXX
154SB Não validadoXXX
155Falha do DCD (Não conseguiu transferir dados)XXX
157Transferência Dados Efetuada da MDH ao DCDXXX
158Memória DCD InsuficienteXXX
159MUS Violado (Tentativa de Violação do MUS)XXX
160Falha Interna MUS (Falha Relógio, memória, etc.)XXX
162Cadastro de NID EfetuadoXXX
163Cadastro de NID RecusadoXXX
165Solicitação de requisição de eventos registradaXXX
Registro Ocorrências de Medição
180Falha Autenticação SondaXX
181Sonda em FalhaXX
182Sonda em OperaçãoXX
183Nenhuma sonda cadastradaX X
184Nenhum bico cadastrado XX
Registros Ocorrências MCM
190Porta do Gabinete abertaXXX
191Porta do Gabinete FechadaXXX
192MCM em Início de ManutençãoXXX
193MCM Fim de ManutençãoXXX
194Falha de Energia MCMXXX
195Retorno de Energia MCMXXX
196Bateria EsgotadaXXX
Registros Ocorrências CON
200Falha Comunicação Concentrador / Unidade AbastecedoraXX
201Retorno Comunicação Concentrador / Unidade AbastecedoraXX
202Alteração de Bico x produtoXX
203Registro de Saída dos BicosXX
204Quebra ou Descontinuidade do EncerranteXX
Registros Ocorrências Ambientais
300Presença de LiquidoX X
301Sensor NormalX X
302Sensor em FalhaX X
303Falta de Comunicação com a Fiscalização AmbientalX X
304Retorno de Comunicação com a Fiscalização AmbientalX X
305Alteração de URL da Fiscalização AmbientalX X
306Alteração do Parâmetro de Periodicidade de Envio – AmbientalXX
307Comunicação com a Fiscalização Ambiental em conformidadeXX
N.O.* - Requisito não obrigatório”
Redação Original
ANEXO II
Tabela de Registros e Eventos
TIPO EVENTO
ID
Descrição
MVC
Tributária
Ambiental
Registro de Medição
100
Registro de Estoque de Combustível
X
X
101
Registro da Descarga de Produto
X
X
102
Registro de Saídas de Sondas
X
X
103
Registro da Descarga de Produto Registrada Manualmente
X
X
Registro Alteração Parametrização
120
Alteração de Parametrização de Volume
X
X
121
Alteração de Parametrização de Tempo de Medidas
X
X
122
Alteração de URL Fisco
X
X
X
123
Alteração de Relógio
X
X
X
124
Alteração de Parametrização do MCM (dados cadastrais)
X
X
Registros de Ocorrências MUS/MF
140
Inicio de Operação MUS/MF
X
X
X
141
MUS/MF desligado
X
X
X
143
Recurso da MDH esgotado (97%)
X
X
144
MCM/MM Desconectado (Sem Comunicação com o MCM/MM)
X
X
X
145
MCM/MM Ativo (retorno da Operação do MCM/MM)
X
X
X
146
MCM/MM Inativo (Falha nas funções de Medição)
X
X
X
147
MCM Inválido (MCM não foi autenticado)
X
X
X
148
Falta de Comunicação com Web Service
X
X
X
150
Retorno Comunicação com Web Services
X
X
X
151
MUS/MF Inicio de Manutenção
X
X
X
152
MUS/MF Fim de manutenção
X
X
X
153
Atualização de SB
X
X
X
154
SB Não validado
X
X
X
155
Falha do DCD (Não conseguiu transferir dados)
X
X
X
157
Transferência Dados Efetuada da MDH ao DCD
X
X
X
158
Memória DCD Insuficiente
X
X
X
159
MUS Violado (Tentativa de Violação do MUS)
X
X
X
160
Falha Interna MUS (Falha Relógio, memória, etc.)
X
X
X
162
Cadastro de NID Efetuado
X
X
X
163
Cadastro de NID Recusado
X
X
X
164
Alteração de Parâmetro do MUS/MF
X
X
X
Registro Ocorrências de Medição
180
Falha Autenticação Sonda
X
X
181
Sonda em Falha
X
X
182
Sonda em Operação
X
X
Registros Ocorrências MCM
190
Porta do Gabinete aberta
X
X
X
191
Porta do Gabinete Fechada
X
X
X
192
MCM em Inicio de Manutenção
X
X
X
193
MCM Fim de Manutenção
X
X
X
194
Falha de Energia MCM
X
X
X
195
Retorno de Energia MCM
X
X
X
196
Bateria Esgotada
X
X
X
Registros Ocorrências CON
200
Falha Comunicação Concentrador / Unidade Abastecedora
X
X
201
Retorno Comunicação Concentrador / Unidade Abastecedora
X
X
202
Alteração de Bico x produto
X
X
203
Registro de Saída dos Bicos
X
X
204
Quebra ou Descontinuidade do Encerrante
X
X
Registros Ocorrências Ambientais
300
Presença de Liquido
X
X
301
Sensor Normal
X
X
302
Sensor em Falha
X
X
303
Falta de Comunicação com a Fiscalização Ambiental
X
X
304
Retorno de Comunicação com a Fiscalização Ambiental
X
X
305
Alteração de URL da Fiscalização Ambiental
X
X
ANEXO III
(Nova redação dada ao ANEXO III pelo Ato COTEPE/ICMS 50/15)
PADRÕES DO FORMATO XML
B.1. Web Service da fiscalização tributária
Função : serviço destinado à recepção de mensagens de medição do órgão tributário.
Schema XML : Medicao_v1.01.xsd
Descrição: Contém as mensagens de medição, registro de descarga de combustível (RDC), registro de estoque de combustível (REC e RDC), registro de saída de sonda (RSS), registro de saída dos bicos (RSB) e os eventos definidos como Tributários no Anexo II no caso do MVC e no Anexo VI no caso do MVCT - Tabelas de Eventos.
Campo
Pai
Tipo
Ocor.
Tam.
Dec.
Descrição/Observação
A01
Medicao
-
-
Tag Raiz
A02
Versao
A01
N
1-1
1-4
2
Versão do layout
B01
Equipamento
A01
C
1-1
20
Identificador único do equipamento. Padrão de numeração: [D|T][\w]{4}[0-9]{7}[\w]{8}
B02
CNPJ
A01
C
1-1
14
CNPJ do estabelecimento
B03
IE
A01
C
1-1
14
Inscrição Estadual do contribuinte
B04
Mensagens
A01
1-1
Grupo de mensagens
C01
Mensagem
B04
1-4096
-
Mensagem de informação gerada pelo equipamento
D01
Pem
C01
N
1-1
15
Identificador único da mensagem enviada pelo equipamento MVC.
D02
Prf
C01
N
0-1
15
Identificador único do protocolo de recebimento fornecido pelo órgão.
D03
Medicoes
C01
0-1
Grupo de eventos de medições registradas para o equipamento.
E01
Medicao
D03
1-255
Informações que constituem RDC e REC
F01
Codigo
E01
N
1-1
Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
F02
DataEvento
E01
D
1-1
Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
F03
Tanque
E01
N
1-1
2
Identificação do tanque, o mesmo utilizado na EFD, registros 1300 e filhos
F04
VolumeBruto
E01
N
1-1
7
2
Volume bruto calculado pelo equipamento
F05
Volume20
E01
N
1-1
7
2
Volume corrigido a temperatura de 20°C
F06
Temperatura
E01
N
1-1
2
0
Temperatura no momento da medição
F07
Combustivel
E01
N
1-1
9
0
Código de produto da ANP
D04
Totalizacoes
C01
0-1
Grupo de informações que constituem RSS
G01
Totalizacao
D04
1-255
Informações de um RSS
H01
Codigo
G01
N
1-1
Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
H02
DataEvento
G01
D
1-1
Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
H03
Tanque
G01
N
1-1
2
Identificação do tanque, o mesmo utilizado na EFD, registros 1300 e filhos
H04
VolumeBruto
G01
N
1-1
7
2
Volume bruto calculado pelo equipamento
H05
Combustivel
G01
N
1-1
9
0
Código de produto da ANP
D05
Saídas
C01
0-1
Grupo de informações que constituem um RSB
I01
Saída
D05
1-255
Informações de um RSB
J01
Codigo
I01
N
1-1
Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
J02
DataEvento
I01
D
1-1
Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
J03
Combustivel
I01
N
1-1
9
0
Código de produto da ANP
J04
Tanque
I01
N
1-1
2
Identificação do tanque, o mesmo utilizado na EFD, registros 1300 e filhos
J05
Bico
I01
N
1-1
3
0
Identificação do bico, o mesmo utilizado na EFD, registros 1300 e filhos
J06
EncerranteInicio
I01
N
1-1
15
3
Leitura inicial do contador (encerrante), no momento do fechamento
J07
EncerranteFim
I01
N
1-1
15
3
Leitura final do contador (encerrante), no momento do fechamento
J08
VolumeBruto
I01
N
1-1
7
2
Volume bruto de saída registrada pelo concentrador
D06
Eventos
C01
0-1
Grupo de eventos de controle registrados para o equipamento.
K01
Evento
D06
1-255
Grupo de informações que constituem um alarme.
L01
Codigo
K01
N
1-1
Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
L02
DataEvento
K01
D
1-1
Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
L03
Texto
K01
C
0-1
255
Informações adicionais sobre o evento registrado pelo equipamento.
B05
signature
A01
1-1
Conforme layout definido para assinatura

Exemplo de mensagem de medição. Sobrescrito ao lado direito do item está uma referencia ao item no layout da mensagem.
<?xml version="1.0" encoding="utf-8"?>
<Medicao Versao="1.00" A02 >A01
<Equipamento>D0102140002130000189</Equipamento> B01
<CNPJ>11222555000101</CNPJ> B02
<IE>250000252</IE> B03
<Mensagens> B04
<Mensagem Pem="1000" D01 Prf="3000" D02> C01
<Medicoes> D03
<Medicao> E01
<Codigo>100</Codigo> F01
<DataEvento>2013-10-01T12:00:25-03:00</DataEvento> F02
<Tanque>1</Tanque> F03
<VolumeBruto>11250</VolumeBruto> F04
<Volume20>11230</Volume20> F05
<Temperatura>25</Temperatura> F06
<Combustivel>320102002</Combustivel> F07
</Medicao> E01
<Medicao> E01
<Codigo>100</Codigo> F01
<DataEvento>2013-10-01T12:00:25-03:00</DataEvento> F02
<Tanque>2</Tanque> F03
<VolumeBruto>25100</VolumeBruto> F04
<Volume20>24490</Volume20> F05
<Temperatura>25</Temperatura> F06
<Combustivel>320101002</Combustivel> F07
</Medicao> E01
</Medicoes> D03
<Totalizacoes> D04
<Totalizacao> G01
<Codigo>102</Codigo> H01
<DataEvento>2013-10-01T23:59:00+02:00</DataEvento> H02
<Tanque>1</Tanque> H03
<VolumeBruto>7000</VolumeBruto> H04
<Combustivel>320102002</Combustivel> H05
</Totalizacao> G01
</Totalizacoes> D04
<Saidas> D05
<Saida> IO1
<Codigo>203</Codigo> J01
<DataEvento>2013-10-01T23:59:00+02:00</DataEvento> J02
<Combustivel>320102002</Combustivel> J03
<Tanque>1</Tanque> J04
<Bico>1</Bico> J05
<EncerranteInicio>125</EncerranteInicio> J06
<EncerranteFim>185</EncerranteFim> J07
<VolumeBruto>3185</VolumeBruto> J08
</Saida> I01
</Saidas> D05
<Eventos> D06
<Evento> K01
<Codigo>301</Codigo> L01
<DataEvento>2013-10-01T12:00:00-03:00</DataEvento> L02
<Texto>Sump bomba 1</Texto> L04
</Evento> J01
</Eventos> C09
</Mensagem> B01
</Mensagens> B04
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>e7jQRU4xmLaQmWVO9pVovhWSeGU=</DigestValue>
</Reference>
</SignedInfo> <SignatureValue>iv+l8DQlNmp8EVZvn0Smy/tkcCA2wp9gHg7urm9ZD6RiwzSI+oEAY1JYGw9szP7BsQZyH6areeGyVtoAbkY502VjP892OD1lpNdWRDeCjIja1xHyubdSp38YvHAGNK5eKLPpxVqqWk5ISENFMY4cBk5AP/7lxOkeQs8kfHoU/K0=</SignatureValue>
</Signature>
</Medicao>
B.1.1. Descrição do processo de Recepção de Mensagens
B.1.1.1 Geração da Resposta com o Recibo
Não existindo qualquer erro nas validações, o aplicativo deverá gerar um número de recibo PRF e retornará uma mensagem de confirmação de recebimento para o transmissor com as seguintes informações:
a) a versão do aplicativo;
b) o código 100 e a mensagem “Recebido com Sucesso”;
c) o número do recibo.
Caso ocorra algum erro de validação, o Web Service não fornecerá número de recibo PRF e deverá retornar uma mensagem com as seguintes informações:
a) a versão do aplicativo;
b) o código contido na tabela de erros com a respectiva mensagem de erro
Sobre as mensagens enviadas pelo equipamento poderão, a critério da fiscalização, retornar erros conforme tabela abaixo.
B.1.1.2. Leiaute da Mensagem de Retorno de Retorno Estrutura XML com a mensagem do resultado da transmissão. Além de devolver uma mensagem com a indicação de sucesso ou erro na mensagem, a fiscalização tributária pode opcionalmente enviar parâmetros de configuração ou programar tarefas para serem executadas pelo equipamento:

São elas:
a) Parâmetro de Atualização do Relógio (PAR).
b) Parâmetro de Periodicidade de Envio (PPE).
c) Parâmetro de Alteração de Endereço (PAE).
d) Parâmetro de Variação de Volume (PVV).
e) Parâmetro de Tempo das Medidas (PTM).
f) Parâmetro de Requisição de Eventos (PRE).
g) Parâmetro de Programação do Horário de Verão (PHV)
Schema XML: retorno_v1.01.xsd

Campo
Pai
Tipo
Ocor.
Tam.
Dec.
Descricao/Observação
A01
RetornoMensagem
-
-
Tag Raiz
A02
Versao
A01
N
1-1
1-4
2
Versão do layout
B01
Retorno
A01
N
1-1
3
Código de status da resposta, valores da Tabela de Erros conforme item B.1.1.1
B02
Texto
A01
C
1-1
255
Mensagem explicativa do código de retorno
B03
Prf
A01
N
1-1
1-15
Numero de recibo gerado pelo web-service
B04
Pem
A01
N
1-1
1-15
Número do protocolo de envio do MVC referente a mensagem de retorno
B05
Tarefa
A01
0-1
Grupo de tarefas que podem ser enviadas ao equipamento, solicitando uma alteração de configuração ou transmissão de novos dados.
C01
Relogio
B05
C
0-1
255
Url de referência para alteração do RTR
C02
PeriodoRemessa
B05
N
0-1
1-4
Periodicidade das remessas de dados ao órgão de fiscalização
C03
UrlRemessa
B05
C
0-1
255
URL de remessa de dados do orgão de fiscalização
C04
VariacaoVolume
B05
N
0-1
7
2
Volume mínimo, em litros, que dispara um evento de medição
C05
TempoMedida
B05
N
0-1
1-4
Tempo, em minutos, entre cada medição periódica
C06
RequisicaoEvento
B05
0-1
Parâmetro que permite solicitar ao equipamento o envio da memória de determinado período
D01
DataInicio
C06
D
1
Data inicial para transmissão da memória de dados
D02
DataFim
C06
D
1
Data final para transmissão da memória de dados
C07
HorarioVerao
B05
0-1
Grupo de informações que compõe a programação do horário de verão
E01
DataInicio
C06
D
1
Data de início do horário de verão
E02
DataFim
C06
D
1
Data de fim do horário de verão

Exemplo de mensagem de retorno
<?xml version="1.0" encoding="utf-8"?>
<RetornoMensagem Versao="1.00" A02> A01
<Retorno>100</retorno> B01
<Texto>Recebido com Sucesso</Texto> B02
<Prf>3</Prf> B03
<Pem>1</Pem> B04
<Tarefa> B05
<Relogio>200.20.186.75:123</Relogio> C01
<PeriodoRemessa>300</PeriodoRemessa> C02
<UrlRemessa>https://mvc.tributario.sef.sc.gov.br/</UrlRemessa> C03
<VariacaoVolume>100</VariacaoVolume> C04
<TempoMedida>30</TempoMedida> C05
<RequisicaoEvento > C06
<DataInicio>2013-01-01</DataInicio> D01
<DataFim>2013-01-31</dataFim> D02
</RequisicaoEvento>
<HorarioVerao > C07
<DataInicio>2016-10-16</DataInicio> E01
<DataFim>2017-02-27</dataFim> E02
</HorarioVerao> C07
</Tarefa> B05
</RetornoMensagem>

B.2. Web Service da fiscalização ambiental
Função : serviço destinado à recepção de mensagens de medição do órgão ambiental.
Schema XML : Ambiental_v1.00.xsd
Descrição: Definir as mensagens de ocorrências ambientais e os eventos definidos como Ambientais no Anexo II no caso do MVC e no Anexo VI no caso do MVCT - Tabelas de Eventos.
Campo
Pai
Tipo
Ocor.
Tam.
Dec.
Descrição/Observação
A01
Ambiental
-
-
Tag Raiz
A02
Versao
A01
N
1-1
1-4
2
Versão do layout
B01
Equipamento
A01
C
1-1
20
Identificador único do equipamento
B02
CNPJ
A01
C
1-1
14
CNPJ do estabelecimento
B03
IE
A01
C
1-1
14
Inscrição Estadual do contribuinte
B04
Mensagens
A01
1-1
Grupo de mensagens
C01
Mensagem
B04
1-4096
-
Mensagem de informação gerada pelo equipamento
D01
Pem
C01
N
1-1
15
Identificador único da mensagem enviada pelo equipamento MVC.
D02
Prf
C01
N
0-1
15
Identificador único do protocolo de recebimento fornecido pelo órgão.
D03
Sensores
C01
0-1
Grupo de eventos dos sensores ambientais.
E01
Sensor
D03
1-255
Informações que constituem um sensor ambiental.
F01
Codigo
E01
N
1-1
Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
F02
DataEvento
E01
D
1-1
Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
F03
NumeroSensor
E01
N
1-1
2
Identificação sensor no contribuinte.
D04
Eventos
C01
0-1
Grupo de eventos de controle registrados para o equipamento.
G01
Evento
D04
1-255
Grupo de informações que constituem um alarme.
H01
Codigo
G01
N
1-1
Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
H02
DataEvento
G01
D
1-1
Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
H03
Texto
G01
C
0-1
255
Informações adicionais sobre o evento registrado pelo equipamento.
A05
signature
A01
1-1
Conforme layout definido para assinatura

Exemplo de mensagem ambiental. Sobrescrito ao lado direito do item está uma referência ao item no layout da mensagem.

<?xml version="1.0" encoding="utf-8"?>
<Ambiental Versao="1.00" A02 >A01
<Equipamento>D0102140002130000189</equipamento> B01
<CNPJ>11222555000101</CNPJ> B02
<IE>250000252</IE> B03
<Mensagens> B04
<Mensagem Pem="1000" D01 Prf="3000" D02> C01
<Sensores> D03
<Sensor> E01
<Evento>300</Evento > F01
<DataEvento>2013-12-01T18:00:05-02:00</DataEvento> F02
<Sensor>2</Sensor> F03
</Sensor> E01
<sensor> E01
<evento>122</evento> F01
<dataEvento>2013-12-01T18:28:05-02:00</dataEvento> F02
<sensor>0</sensor> F03
</sensor> E01
<eventos> D04
<evento> G01
<id>123</id> H01
<dataEvento>2013-10-01T12:00:00-03:00</dataEvento> H02
<texto>URL alterada para www.meioambiente.com.br </texto> H03
</evento> G01
</eventos> D04
</mensagem> C01
</mensagens> B04
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>e7jQRU4xmLaQmWVO9pVovhWSeGU=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>iv+l8DQlNmp8EVZvn0Smy/tkcCA2wp9gHg7urm9ZD6RiwzSI+oEAY1JYGw9szP7BsQZyH6areeGyVtoAbkY502VjP892OD1lpNdWRDeCjIja1xHyubdSp38YvHAGNK5eKLPpxVqqWk5ISENFMY4cBk5AP/7lxOkeQs8kfHoU/K0=</SignatureValue>
</Signature>
</medicao>

B.2.1. Descrição do processo de Recepção de Mensagens
B.2.1.1. Geração da Resposta com o Recibo

Não existindo qualquer erro nas validações, o aplicativo deverá gerar um número de recibo PRF e retornará uma mensagem de confirmação de recebimento para o transmissor com as seguintes informações:
a) a versão do aplicativo;
b) o código 100 e a mensagem “Recebido com Sucesso”;
c) o número do recibo.

Caso ocorra algum problema de validação, o aplicativo deverá retornar uma mensagem com as seguintes informações:
a) a versão do aplicativo;
b) o código e a respectiva mensagem de erro conforme tabela de erros

Sobre as mensagens enviadas pelo equipamento poderão, a critério da fiscalização, retornar erros conforme tabela abaixo.
B.2.1.2 Leiaute Mensagem de Retorno
Estrutura XML com a mensagem do resultado da transmissão. Além de devolver uma mensagem com a indicação de sucesso ou erro na mensagem, a fiscalização ambiental pode opcionalmente enviar os parâmetros de configuração ou programar tarefas para serem executas pelo equipamento.

São elas:
a) Parâmetro de Periodicidade de Envio (PPE).
b) Parâmetro de Alteração de Endereço (PAE).
c) Parâmetro de Requisição de Eventos (PRE).
Schema XML: retorno_v1.00.xsd

Campo
Pai
Tipo
Ocor.
Tam.
Dec.
Descricao/Observação
A01
RetornoMensagem
-
-
Tag Raiz
A02
Versao
A01
N
1-1
1-4
2
Versão do layout
B01
Retorno
A01
N
1-1
3
Código de status da resposta, valores da Tabela de Erros conforme item B.2.1.1
B02
Texto
A01
C
1-1
255
Mensagem explicativa do código de retorno
B03
Prf
A01
N
1-1
1-15
Numero de recibo gerado pelo web-service
B04
Pem
A01
N
1-1
1-15
Número do protocolo de envio do MVC referente a mensagem de retorno
B05
Tarefa
A01
0-1
Grupo de tarefas que podem ser enviadas ao equipamento, solicitando uma alteração de configuração ou transmissão de novos dados.
C01
PeriodoRemessa
A05
N
0-1
1-4
Periodicidade das remessas de dados ao órgão de fiscalização
C02
UrlRemessa
A05
C
0-1
255
URL de remessa de dados do orgão de fiscalização
C03
RequisicaoEvento
A05
0-1
Parâmetro que permite solicitar ao equipamento o envio da memória de determinado período
D01
DataInicio
B03
D
1
Data inicial para transmissão da memória de dados
D02
DataFim
B03
D
1
Data final para transmissão da memória de dados

As mensagens recebidas com erro geram uma mensagem de erro. Nas demais hipóteses será retornado uma mensagem com um número de recibo.

Exemplo de mensagem de retorno
<?xml version="1.0" encoding="utf-8"?>
<RetornoMensagem Versao="1.00" A02> A01
<Retorno>100</retorno> B01
<Texto>Recebido com Sucesso</Texto> B02
<Prf>3</Prf> B03
<Pem>1</Pem> B04
<Tarefa> B05
<PeriodoRemessa>300</PeriodoRemessa> C01
<UrlRemessa>https://mvc.tributario.sef.sc.gov.br/</UrlRemessa> C02
<RequisicaoEvento > C03
<DataInicio>2013-01-01</DataInicio> D01
<DataFim>2013-01-31</dataFim> D02
</RequisicaoEvento>
</Tarefa> B05
</RetornoMensagem>

B.3. Assinatura do XML (Nova redação dada pelo Ato Cotepe/ICMS 35/16, efeitos a partir de 01.01.17)
As mensagens utilizam o padrão de assinatura XML definido pelo http://www.w3.org/TR/xmldsig-core/ conforme abaixo:
Schema XML: xmldsig-core-schema.xsd
Campo
Pai
Tipo
Ocor.
Tam
Dec.
Descrição/Observação
XS01
Signature
-
-
-
Tag Raiz
XS02
SignedInfo
XS01
-
1-1
Grupo da Informação da assinatura
XS03
CanonicalizationMEthod
XS02
-
1-1
Grupo do Método de Canonicalização
XS04
Algorithm
XS03
C
1-1
Atributo Algorithm de CanonicalizationMethod: http://www.w3.org/TR/2001/REC-xml-c14n-20010315
XS05
SignatureMethod
XS02
-
1-1
Grupo do Método de Assinatura
XS06
Algorithm
XS05
C
1-1
Atributo Algorithm de SignatureMethod: http://www.w3.org/2000/09/xmldsig#rsa-sha1
XS07
Reference
XS02
-
1-1
Grupo Reference
XS08
URI
XS07
C
1-1
Atributo URI da tag Reference
XS09
Transforms
XS07
-
1-1
7
2
Grupo do algorithm de Transform
XS10
Transform
XS09
-
2-2
Grupo de Transform
XS11
Algorithm
XS10
C
1-1
Atributos válidos Algorithm do Transform:
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
http://www.w3.org/2000/09/xmldsig#enveloped-signature
XS12
DigestMethod
XS07
-
1-1
Grupo do Método de DigestMethod
XS13
Algorithm
XS12
C
1-1
Atributo Algorithm de DigestMethod:http://www.w3.org/2000/09/xmldsig#sha1
XS14
DigestValue
XS07
C
1
Digest Value (Hash SHA-1 – BASE 64)
XS15
SignatureValue
XS01
-
1-1
Grupo do Signature Value
XS16
KeyInfo
XS01
-
1-1
Grupo das Propriedades da Chave
XS17
X509Data
XS16
-
Grupo do Certificado X509
XS18
X509IssuerSerial
XS17
-
1-1
Informação do Emissor-Fabricante
XS19
X509Certificate
XS17
-
1-1
Certificado do Equipamento
Segue abaixo um exemplo:
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> XS01
<SignedInfo> XS02
<CanonicalizationMethod XS03 Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" XS04 />
<SignatureMethod XS05 Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" XS06 /> XS04
<Reference XS07 URI="" XS08>
<Transforms> XS09
<Transform XS010 Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" XS11 />
</Transforms>
<DigestMethod XS12 Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" XS13 />
<DigestValue>e7jQRU4xmLaQmWVO9pVovhWSeGU=</DigestValue> XS14
</Reference>
</SignedInfo>
<SignatureValue>iv+l8DQlNmp8EVZvn0Smy/tkcCA2wp9gHg7urm9ZD6RiwzSI+oEAY1JYGw9szP7BsQZyH6areeGyVtoAbkY502VjP892OD1lpNdWRDeCjIja1xHyubdSp38YvHAGNK5eKLPpxVqqWk5ISENFMY4cBk5AP/7lxOkeQs8kfHoU/K0=</SignatureValue> XS15
</Signature>
Campo
Pai
Tipo
Ocor.Tam.Dec.Descrição/Observação
A01
medicao
-
-Tag Raiz
A02
versao
A01
N
1-11-42Versão do layout
B01
equipamento
A01
C
1-1
20
Identificador único do equipamento
B02
Cnpj
A01
C
1-1
14
CNPJ do estabelecimento
B03
Ie
A01
C
1-1
14
Inscrição Estadual do contribuinte
B04
mensagens
A01
1-1Grupo de mensagens
C01
mensagemB04
1-4096
-
Mensagem de informação gerada pelo equipamento
D01
Pem
C01
N
1-1
15
Identificador único da mensagem enviada pelo equipamento.
D02
Prf
C01
N
0-1
15
Identificador único do protocolo de recebimento fornecido pelo órgão.
D03
medicoes
C01
0-1
Grupo de eventos de medições registradas para o equipamento.
E01
Medicao
D03
1-255
Informações que constituem RDC e REC
F01
Evento
E01
N
1-1
Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabelas de eventos.
F02
dataEvento
E01
D
1-1
Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
F03
Tanque
E01
N
1-1
2
Identificação do tanque, o mesmo utilizado na EFD, registros 1300 e filhos
F04
volumeBruto
E01
N
1-1
7
2
Volume bruto calculado pelo equipamento
F05
volume20
E01
N
1-1
7
2
Volume corrigido a temperatura de 20°C
F06
temperatura
E01
N
1-1
2
0
Temperatura no momento da medição
F07
combustivel
E01
N
1-1
9
0
Código de produto da ANP
D04
totalizacoes
C01
0-1
Grupo de informações que constituem RSS
G01
Medicao
D04
1-255
Informações de um RSS
H01
Evento
G01
N
1-1
Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabelas de eventos.
H02
dataEvento
G01
D
1-1
Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
H03
Tanque
G01
N
1-1
2
Identificação do tanque, o mesmo utilizado na EFD, registros 1300 e filhos
H04
volumeBruto
G01
N
1-1
7
2
Volume bruto calculado pelo equipamento
H05
combustivel
G01
N
1-1
9
0
Código de produto da ANP
D05
Saídas
C01
0-1
Grupo de informações que constituem um RSB
I01
Saída
D05
1-255
Informações de um RSB
J01
Evento
I01
N
1-1
Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabelas de eventos.
J02
dataEventoI01
D
1-1
Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
J03
combustivel
I01
N
1-1
9
0
Código de produto da ANP
J04
bico
I01
N
1-1
3
0
Identificação do bico, o mesmo utilizado na EFD, registros 1300 e filhos
J05
encerranteInicio
I01
N
1-1
15
3
Leitura inicial do contador (encerrante), no momento do fechamento
J06
encerranteFim
I01
N
1-1
15
3
Leitura final do contador (encerrante), no momento do fechamento
J07
volumeBruto
I01
N
1-1
7
2
Volume bruto de saída registrada pelo concentrador
D06
eventos
C01
0-1
Grupo de eventos de controle registrados para o equipamento.
K01
evento
D06
1-255
Grupo de informações que constituem um alarme.
L01
id
K01
N
1-1
Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabelas de eventos.
L02
dataEvento
K01
D
1-1
Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
L03
texto
K01
C
0-1
255
Informações adicionais sobre o evento registrado pelo equipamento.
B05
signature
A01
1-1Conforme layout definido para assinatura
Tabela de Erros
#ValidaçãoCódigoMensagem
1Contribuinte001Contribuinte não cadastrado
2MVC002Equipamento não cadastrado
3Assinatura003Assinatura inválida
4XML004XML inválido
Redação original.
ANEXO III
PADRÕES DO FORMATO XML
Campo
Pai
Tipo
Ocor.
Tam.
Dec.Descrição/Observação
A01
medicao
-
-
Tag Raiz
A02
versao
A01
N
1-1
1-4
2Versão do layout
B01
equipamento
A01
C
1-1
20
Identificador único do equipamento
B02
Cnpj
A01
C
1-1
14
CNPJ do estabelecimento
B03
Ie
A01
C
1-1
14
Inscrição Estadual do contribuinte
B04
mensagens
A01
1-1
Grupo de mensagens
C01
mensagem
B04
1-4096
-
Mensagem de informação gerada pelo equipamento
D01
Pem
C01
N
1-1
15
Identificador único da mensagem enviada pelo equipamento MVC.
D02
Prf
C01
N
0-1
15
Identificador único do protocolo de recebimento fornecido pelo órgão.
D03
medicoes
C01
0-1
Grupo de eventos de medições registradas para o equipamento.
E01
Medicao
D03
1-255
Informações que constituem RDC e REC
F01
Evento
E01
N
1-1
Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
F02
dataEvento
E01
D
1-1
Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
F03
Tanque
E01
N
1-1
2
Identificação do tanque, o mesmo utilizado na EFD, registros 1300 e filhos
F04
volumeBruto
E01
N
1-1
7
2
Volume bruto calculado pelo equipamento
F05
volume20
E01
N
1-1
7
2
Volume corrigido a temperatura de 20°C
F06
temperatura
E01
N
1-1
2
0
Temperatura no momento da medição
F07
combustivel
E01
N
1-1
9
0
Código de produto da ANP
D04
totalizacoes
C01
0-1
Grupo de informações que constituem RSS
G01
Medicao
D04
1-255
Informações de um RSS
H01
Evento
G01
N
1-1
Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
H02
dataEvento
G01
D
1-1
Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
H03
Tanque
G01
N
1-1
2
Identificação do tanque, o mesmo utilizado na EFD, registros 1300 e filhos
H04
volumeBruto
G01
N
1-1
7
2
Volume bruto calculado pelo equipamento
H05
combustivel
G01
N
1-1
9
0
Código de produto da ANP
D05
Saídas
C01
0-1
Grupo de informações que constituem um RSB
I01
Saída
D05
1-255
Informações de um RSB
J01
Evento
I01
N
1-1
Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
J02
dataEvento
I01
D
1-1
Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
J03
combustivel
I01
N
1-1
9
0
Código de produto da ANP
J04
bico
I01
N
1-1
3
0
Identificação do bico, o mesmo utilizado na EFD, registros 1300 e filhos
J05
encerranteInicio
I01
N
1-1
15
3
Leitura inicial do contador (encerrante), no momento do fechamento
J06
encerranteFim
I01
N
1-1
15
3
Leitura final do contador (encerrante), no momento do fechamento
J07
volumeBruto
I01
N
1-1
7
2
Volume bruto de saída registrada pelo concentrador
D06
eventos
C01
0-1
Grupo de eventos de controle registrados para o equipamento.
K01
evento
D06
1-255
Grupo de informações que constituem um alarme.
L01
id
K01
N
1-1
Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
L02
dataEvento
K01
D
1-1
Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
L03
texto
K01
C
0-1
255
Informações adicionais sobre o evento registrado pelo equipamento.
B05
signature
A01
1-1
Conforme layout definido para assinatura
Campo
Pai
Tipo
Ocor.
Tam.
Dec.
Descrição/Observação
A01
medicao
-
-
Tag Raiz
A02
versao
A01
N
1-1
1-4
2
Versão do layout
B01
equipamento
A01
C
1-1
20
Identificador único do equipamento
B02
cnpj
A01
C
1-1
14
CNPJ do estabelecimento
B03
ie
A01
C
1-1
14
Inscrição Estadual do contribuinte
B04
mensagens
A01
1-1
Grupo de mensagens
C01
mensagem
B04
1-4096
-
Mensagem de informação gerada pelo equipamento
D01
pem
C01
N
1-1
15
Identificador único da mensagem enviada pelo equipamento MVC.
D02
prf
C01
N
0-1
15
Identificador único do protocolo de recebimento fornecido pelo órgão.
D03
sensores
C01
0-1
Grupo de eventos dos sensores ambientais.
E01
sensor
D03
1-255
Informações que constituem um sensor ambiental.
F01
evento
E01
N
1-1
Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
F02
dataEvento
E01
D
1-1
Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
F03
sensor
E01
N
1-1
2
Identificação sensor no contribuinte.
D04
eventos
C01
0-1
Grupo de eventos de controle registrados para o equipamento.
G01
evento
D04
1-255
Grupo de informações que constituem um alarme.
H01
id
G01
N
1-1
Tipo de evento ocorrido no sistema de medição e monitoramento, conforme tabela Anexo A
H02
dataEvento
G01
D
1-1
Data do evento. Formato “AAAA-MM-DDTHH:MM:SS-TZD”, onde TZD = +hh:mm ou -hh:mm
H03
texto
G01
C
0-1
255
Informações adicionais sobre o evento registrado pelo equipamento.
A05
signature
A01
1-1
Conforme layout definido para assinatura
ANEXO IV
Diagrama de Blocos MVC


ANEXO V
ESPECIFICAÇÃO DE REQUISITOS DO MEDIDOR VOLUMÉTRICO DE COMBUSTÍVEIS DE TRANSIÇÃO (ER-MVCT)
SUMÁRIO
(Acrescentado pelo Ato COTEPE/ICMS 32/14)

1. INTRODUÇÃO
1.1. Disposições Gerais
1.2. Da Concepção de Funcionamento
1.3. Da Arquitetura
1.4. Abreviações e Definições
2. DESCRIÇÃO DO MVCT
2.1. Módulo de medição (MM)
2.2. Módulo Fiscal (MF)
2.2.1. Requisitos do Acesso Monitorado
2.2.2. Memória de Dados Históricos (MDH)
2.2.3. Software Básico (SB)
2.2.4. Identificações e Registros
2.2.4.1. Número de Identificação do MF (NIM)
2.2.4.2. Número de Identificação do MVCT (NID)
2.2.4.3. Identificação do Contribuinte Usuário (IC)
2.2.4.4. Parâmetro de Variação de Volume (PVV)
2.2.4.5. Parâmetro do Tempo de Medidas (PTM)
2.2.4.6. Registro da Descarga de Combustíveis (RDC)
2.2.4.7. Registro do Estoque de Combustíveis (REC)
2.2.4.8. Registro de Saídas dos Bicos (RSB)
2.2.4.9. Registro de Saídas das Sondas (RSS)
2.2.5. Requisitos Estruturais
2.2.5.1. Requisitos Estruturais da MDH
2.2.5.2. Requisitos Estruturais dos Dispositivos Lógicos Programáveis (DLP)
2.2.6. Relógio de Tempo Real (RTR)
2.2.7. Assinatura Digital do AEF
2.2.8. Módulo de Transmissão de Dados à Fiscalização (MTF)
2.2.9. Interface de Transmissão à Fiscalização (ITF)
2.2.10. Inicialização do MF
2.2.11. Modo de Intervenção Técnica (MIT)
2.2.11.1. Atualização do Software Básico (SB)
2.2.11.2. Ajuste do RTR
3. TRANSMISSÃO À FISCALIZAÇÃO
3.1. Padrões Técnicos
3.1.1. Padrão do Documento XML
3.1.1.1. Padrão de Codificação
3.1.1.2. Padrão Schema
3.1.1.3. Montagem do Arquivo
3.1.2. Padrão de Comunicação
3.2. Padrão de Mensagem dos Web Services
3.2.1. Validação da Estrutura XML das Mensagens dos Web Services
3.2.2. Schemas XML das Mensagens dos Web Services
3.3. Ambiente Virtual
3.4. Especificação dos Web Services
4. REQUISITOS DA OPERAÇÃO COM A FISCALIZAÇÃO
4.1. Processo de Envio de Dados à Fiscalização
4.2. Alteração de Parâmetros do MF
4.3. Envio de Eventos à Fiscalização
4.4. Solicitação de Alteração do Endereço de URL
4.5. Alteração do Parâmetro de Periodicidade de Envio
4.6. Alteração do Parâmetro de Tempo de Medidas
4.7. Alteração do Parâmetro de Variação de Volume
4.8. Situações Operacionais
4.8.1. Leitura da MDH em Virtude de Troca do MF
4.8.2. Perda de Conexão
5. NORMAS ATENDIDAS
5.1. Normas do MF
5.2. Normas do MM

1. INTRODUÇÃO

1.1. Disposições Gerais (Nova redação dada ao subitem 1.1 pelo Ato COTEPE/ICMS 6/15)
Este anexo especifica os requisitos mínimos a serem atendidos pelos Medidores Volumétricos de Combustíveis de Transição (MVCT), com a finalidade de estabelecer uma base comum para a sua fabricação e uso, bem como para o entendimento entre os diversos agentes envolvidos com as atividades relacionadas ao equipamento que poderá ser utilizado pelos postos revendedores de combustíveis líquidos que, cumulativamente:
I. já tenha adquirido e utilize equipamentos para medição volumétrica de combustíveis e monitoramento ambiental até a data do início da obrigatoriedade de uso do MVC ainda que as funções estejam implementadas em equipamentos distintos;
II. não cometa infração relacionada à comercialização ou qualidade de combustíveis; e
III. observe as demais obrigações estabelecidas pela unidade da federação de sua jurisdição, relativas ao MVC.
Os requisitos especificados neste Anexo são de implementação obrigatória, salvo aqueles considerados opcionais, condição esta explicitada no texto.
1.2. Da Concepção de Funcionamento
O equipamento Medidor Volumétrico de Combustíveis de Transição (MVCT), para atender suas finalidades, deverá atender as seguintes funções:
I. Apurar, com base nas sondas de medições, o volume em litros dos estoques presentes nos compartimentos dos tanques de combustíveis;
II. Apurar, com base nas sondas de medições, a variação volumétrica do volume em litros das descargas de combustíveis dos compartimentos dos tanques;
III. Apurar, com base nas sondas de medições, a variação volumétrica do volume em litros das saídas de combustíveis dos compartimentos dos tanques;
IV. Apurar, com base no concentrador ou unidades abastecedoras, o volume em litros das saídas de combustíveis realizadas por meio dos bicos das bombas de abastecimento;
V. Registrar e manter na memória de dados históricos, de forma segura, o registro histórico das operações volumétricas e eventos, nas hipóteses e situações definidas neste Anexo;
VI. Transferir informações que possibilitem disponibilizar ao sistema de gestão do contribuinte o registro das operações do equipamento e outras informações gerenciais;
VII. Enviar os registros das operações e eventos armazenados na memória de dados históricos aos órgãos fiscalizadores;
VIII. Disponibilizar informações que possibilitem ao contribuinte e à fiscalização extrair da memória, de forma local, o histórico dos registros das operações e eventos;
IX. Disponibilizar informações ao usuário que possibilitem acompanhar o gerenciamento, parametrização e configuração do equipamento a fim de obter informações gerenciais e de controle.

1.3. Da Arquitetura
O Medidor Volumétrico de Combustíveis de Transição (MVCT) constitui-se em uma estrutura, conforme diagrama de blocos previsto no Anexo VII, com as seguintes características:
I. Para medição e monitoramento, funcionar integrado e interligado com:
a) as sondas de medição, que devem estar instaladas em todos os compartimentos dos tanques de armazenamento de combustíveis líquidos;
b) os sensores ambientais;
c) as unidades abastecedoras de combustíveis, admitida a utilização do concentrador de bombas, caso o MVCT não suporte o seu tratamento direto;
II. Para o usuário, funcionar integrado e interligado a diversos dispositivos previstos neste Anexo, disponibilizando interfaces elétricas e lógicas para a realização das funções de interface, de forma local no MVCT ou remota via sistemas de gestão, vedada a alteração dos dados previstos neste Anexo após o processamento realizado pelo MVCT;
III. Para o contribuinte e fiscalização, disponibilizar de modo seguro, interface e meios que possibilitem extrair os dados históricos dos registros das operações armazenados na memória do equipamento;
IV. Para armazenamento seguro, disponibilizar recursos de armazenamento de registros de forma segura.

1.4. Abreviações e Definições
AEF – Arquivo Eletrônico da Fiscalização: conjunto de dados capturados pelo MVCT, gravado em memória não volátil, a serem disponibilizados à fiscalização de forma local ou remota.
CON – Concentrador: dispositivo com a capacidade de realizar de forma eletrônica a captura do volume das saídas de combustíveis das unidades abastecedoras, disponibilizando-as ao MVCT.
DLP - Dispositivos Lógicos Programáveis: hardware configurável ou programável utilizado para construir circuitos digitais;
EFD – Escrituração Fiscal Digital: na forma do Ato COTEPE ICMS 09/08.
ITF – Interface de Transmissão à Fiscalização: define o tipo físico da interface para transmissão de dados pela internet aos órgãos fiscalizadores.
MM – Módulo de Medição: módulo responsável pela leitura das sondas de medição e sensores ambientais.
MF – Módulo Fiscal: módulo que contém os componentes que garantem a segurança do armazenamento e sua inviolabilidade, com envio de forma criptografada dos dados e registros do MVCT aos órgãos fiscalizadores.
MDH – Memória de Dados Históricos: memória responsável pelo armazenamento seguro dos registros e eventos previstos neste Anexo.
MIT – Modo de Intervenção Técnica: estado operacional no qual é possibilitada a realização de manutenções no MVCT.
MTF – Módulo de Transmissão de dados à Fiscalização: componente com capacidade de transmitir de forma segura e criptografada as informações armazenadas no MF aos órgãos fiscalizadores.
MVCT – Medidor Volumétrico de Combustíveis de Transição: equipamento de medição volumétrica e monitoramento ambiental que permite, independente do Programa Aplicativo Fiscal (PAF-ECF), do Emissor de Cupom Fiscal (ECF) ou de qualquer outro equipamento de automação comercial, a captura automática, armazenamento, extração de dados e transmissão aos órgãos fiscalizadores das informações definidas neste Anexo.
NID - Número de Identificação: número que identifica o equipamento.
NIN - Número de Identificação do MF: número que identifica o MF.
PAE – Parâmetro de Alteração de Endereço: parâmetro para alteração do endereço URL de envio dos dados.
PAR - Parâmetro de Atualização do Relógio: parâmetro definido pela fiscalização tributária contendo a URL de referência a ser usada para ajuste do RTR.
PEM - Protocolo de Envio do MVCT: número gerado pelo próprio MVCT que identificará de modo único o bloco de registros enviados.
PPE - Parâmetro de Periodicidade de Envio: contém o intervalo de tempo, em minutos, que determina a periodicidade de envio aos órgãos de fiscalização de todos os eventos registrados na MDH, pendentes de envio.
PRE - Parâmetro de Requisição de Eventos: parâmetro definido pela fiscalização contendo as datas de início e término de eventos a serem enviados.
PRF - Protocolo de Recebimento da Fiscalização: número gerado pelo órgão de fiscalização que identifica um envio do MVCT de maneira única ao sistema do órgão, atestando a confirmação da entrega dos dados.
PTM - Parâmetro de Tempo de Medidas: intervalo de tempo para que o MVC realize uma REC.
PVV - Parâmetro de Variação de Volume: volume de variação de estoque que gera um registro de descarga de combustível.
RDC - Registro de Descarga de Combustível: volume em litros da descarga de combustível.
REC - Registro de Estoque de Combustível: volume em litros do estoque de combustível.
RSB - Registro de Saídas dos Bicos: saídas de combustíveis realizadas pelos bicos das bombas de abastecimento.
RSS - Registro de Saídas das Sondas: volume de saídas de combustíveis medido pelas sondas de medição.
RTR – Relógio de Tempo Real: dispositivo capaz de fornecer a data e a hora para o funcionamento do MVCT.
SB – Sofware Básico: conjunto fixo de rotinas residentes no MF, que implementa as funções de controle do MVCT.
SA – Sensor Ambiental: dispositivo capaz de identificar a presença de líquidos para fins de controle ambiental nos locais monitorados.
SM – Sonda de Medição: dispositivo de medição de nível instalado nos compartimentos dos tanques de combustíveis líquidos.
Web Services – solução utilizada pela fiscalização para integrar seus sistemas com o MVCT com a finalidade de receber e enviar informações em formato XML.

2. DESCRIÇÃO DO MVCT
Medidor Volumétrico de Combustíveis de Transição é o equipamento de medição volumétrica e monitoramento ambiental que permite, independente do Programa Aplicativo Fiscal (PAF-ECF), do Emissor de Cupom Fiscal (ECF) ou de qualquer outro equipamento de automação comercial, a captura automática, armazenamento, extração de dados e transmissão aos órgãos fiscalizadores das informações definidas neste Anexo, desenvolvido conforme diagrama de blocos do Anexo VII, sendo composto pelo módulo de medição (MM) e módulo fiscal (MF) conectados entre si.
As analises estrutural e funcional previstas no parágrafo único da clausula decima quinta do Convênio ICMS 59/11 aplicam-se somente ao módulo fiscal (MF).

2.1 Módulo de medição (MM)
Conjunto de dispositivos de hardware e software, com capacidade, quando ativo, de disponibilizar a medida calculada de forma indireta do volume de combustíveis líquidos existentes nos compartimentos de combustíveis e de realizar a função de monitoramento ambiental, podendo ser composto de um ou mais equipamentos para realizar tais funções.

2.2. Módulo Fiscal (MF)
Conjunto de dispositivos de hardware e software dotado de conexão de alimentação de energia independente, com capacidade quando ativo de:
I. monitorar, capturar e gravar os registros e eventos previstos neste Anexo, provenientes do Módulo de Medição (MM) e do concentrador (CON) de bombas, na Memória de Dados Históricos (MDH);
II. disponibilizar e transmitir, os registros e eventos armazenados na Memória de Dados Históricos (MDH), por meio da Internet, em formato definido no Anexo III;
III. permitir a leitura, por elemento computacional, utilizando-se de programa desenvolvido pelo fabricante do MF, dos dados armazenados na Memória de Dados Históricos (MDH), por porta de comunicação padrão USB 1.1 ou superior do tipo A.
2.2.1. Requisitos do Acesso Monitorado
O MF deve ser capaz de monitorar e registrar como evento as seguintes situações:
I. desconexão da interligação entre o MF e o MM;
II. desconexão da sonda de medição, em equipamentos que identificam esta ocorrência;
III. desconexão do sensor ambiental;
IV. desconexão do concentrador (CON).
2.2.2. Memória de Dados Históricos (MDH)
Recursos de hardware, residentes no Módulo Fiscal (MF), devendo possuir requisitos estruturais conforme item 2.2.5.1, sendo responsável por armazenar pelo prazo mínimo de 5 (cinco) anos os registros e eventos previstos neste Anexo.
2.2.3 Software Básico (SB)
O Software Básico é o conjunto fixo de rotinas que implementa as funções de controle do MF previstas neste Anexo, sendo que o dispositivo onde está armazenado, instalado e validado, deve permitir acesso para leitura direta do seu conteúdo por meio de dispositivo específico para este fim, durante a realização de análise estrutural ou de perícia técnica solicitada pela fiscalização, bem como via conector de comunicação externa utilizando programa aplicativo específico desenvolvido pelo fabricante do MVCT e entregue a fiscalização. A versão do SB pode ser atualizada remota ou localmente e deve ser identificada com 6 (seis) dígitos decimais, no formato XX.XX.XX, em que valores crescentes indicam versões sucessivas do software, obedecendo aos seguintes critérios:
I. o primeiro e o segundo dígitos devem ser incrementados de uma unidade, a partir do valor inicial 01, sempre que houver atualização da versão por motivo de mudança na legislação;
II. o terceiro e o quarto dígitos devem ser incrementados de uma unidade, a partir do valor inicial 00, sempre que houver atualização da versão por motivo de correção de defeito;
III. os dois últimos dígitos podem ser utilizados livremente, a partir do valor inicial 00, excluídas as situações previstas nas alíneas anteriores.
2.2.4. Identificações e Registros
Deve ficar registrado na MDH no mínimo as seguintes identificações e registros:
2.2.4.1. Número de Identificação do MF (NIM): o MF deve possuir identificação única composta por 5 (cinco) caracteres numéricos, devendo ser gravado uma única vez na MDH não permitindo ao equipamento disponibilizar comandos para apagamento ou alteração deste número de identificação.
2.2.4.2. Número de Identificação do MVCT (NID): o MVCT deve possuir um número único que permita a identificação individualizada do equipamentos. Este número deve ser gravado uma única vez na MDH não devendo o equipamento disponibilizar comandos para apagamento ou alteração do NID, sendo permitida a utilização de mais de um MVCT por estabelecimento.
O NID do MVCT deve possuir um conjunto de 20 (vinte) caracteres alfanuméricos composto da seguinte forma:
I. o caracter “T”;
II. os dois primeiros caracteres: para registro do código do fabricante ou importador, atribuído pela Secretaria Executiva do CONFAZ;
III. o terceiro e o quarto caracteres: para registro do código do modelo do equipamento, atribuído pela Secretaria Executiva do CONFAZ;
IV. o quinto e sexto caracteres: para indicar o ano de fabricação;
V. o sétimo, oitavo, novo, décimo e décimo primeiro caracteres: para o Número de Identificação do NIM;
VI. os demais caracteres devem ser utilizados pelo fabricante ou importador de forma a individualizar o equipamento.
2.2.4.3. Identificação do Contribuinte Usuário (IC): o contribuinte usuário será identificado no MVCT por meio de seus números de inscrições no CNPJ e Inscrição Estadual, que serão gravados na MDH.
2.2.4.4. Parâmetro de Variação de Volume (PVV): é o volume de variação mínima positiva, em litros, definido pela Unidade da Federação, para que o MVCT registre uma RDC, sendo inicialmente parametrizado pelo fabricante, no equipamento, a variação mínima de 200 litros no intervalo inferior a um minuto.
2.2.4.5. Parâmetro do Tempo de Medidas (PTM): Intervalo de tempo definido pela Unidade da Federação para que o MVCT realize uma REC, sendo inicialmente parametrizado pelo fabricante, no equipamento, o intervalo de 30 minutos. É opcional ao MVCT atender a um PTM de valor menor do que 30 minutos entre as medidas.
2.2.4.6. Registro da Descarga de Combustíveis (RDC): Volume em litros da descarga de combustível, contendo o tipo de combustível, o respectivo compartimento, a data, hora, minutos e segundos da ocorrência, devendo os compartimentos dos tanques seguirem a numeração utilizada na EFD do contribuinte. É opcional ao MVCT registrar a temperatura e realizar o RDC de forma automática.
2.2.4.7. Registro do Estoque de Combustíveis (REC): Volume em litros do estoque de combustível, contemplando os tipos de combustíveis, os números dos compartimentos e a respectiva data, hora, minutos e segundos do instante da medição, devendo os compartimentos dos tanques seguirem a numeração utilizada na EFD do contribuinte. É opcional ao MVCT registrar a temperatura a cada REC.
2.2.4.8. Registro de Saídas dos Bicos (RSB): totalização do volume diário de saídas de combustíveis, em litros, realizadas no período compreendido entre 0:00h e 23:59h, apurado por bico de abastecimento, contendo a data, hora, minuto e segundo da leitura do dado, o tipo de combustível, o número do bico de abastecimento, o volume, os encerrantes volumétricos inicial e final e o número do compartimento vinculado ao bico, devendo:
I. ser criado um novo RSB sempre que ocorrer quebra ou descontinuidade do encerrante, com a respectiva data e hora da detecção;
II. os bicos e os compartimentos dos tanques seguirem a numeração utilizada na EFD do contribuinte;
III. a vinculação dos bicos aos respectivos compartimentos dos tanques deverão seguir a utilizada na EFD do contribuinte;
IV. o registro ser gravado no primeiro minuto do dia subsequente ao fechamento e, quando o MVCT estiver desligado, por ocasião do retorno ao funcionamento do MVCT.
2.2.4.9. Registro de Saídas das Sondas (RSS): totalização do volume diário de saídas de combustíveis, em litros, realizadas no período compreendido entre 0:00h e 23:59h, apurada pelas sondas de medição (SM), contendo a data, hora, minuto e segundo da leitura do dado, o tipo de combustível, o volume e o compartimento, observando-se os incisos II e IV do item 2.2.4.8.
2.2.5. Requisitos Estruturais
2.2.5.1. Requisitos Estruturais da MDH
A Memória de Dados Histórico (MDH) deve seguir os seguintes requisitos estruturais:
I. ser não volátil;
II. possuir recursos associados de hardware semicondutor configurável ou programável que não permitam o seu apagamento ou a modificação de dados;
III. o dispositivo de MDH deve ser iniciado com a gravação de um número único de fabricação do MF, sendo este um procedimento de fabricação de responsabilidade exclusiva do fabricante;
IV. devem estar completamente protegidos por resina, evitando qualquer contato para reprogramação;
V. deve ser utilizada resina de proteção com as seguintes características:
a) ser termofixa com temperatura de transição térmica igual ou superior a 120ºC;
b) apresentar rigidez dielétrica igual ou superior a 8 KV/mm conforme IEC 243;
c) apresentar dureza igual ou superior a 72 na escala Shore D;
d) ser opaca;
e) ser insolúvel em água;
f) não ser hidrofílica.
2.2.5.2. Requisitos Estruturais dos Dispositivos Lógicos Programáveis (DLP)
O DLP ou outro hardware configurável ou programável, integrante dos recursos de hardware associados ao dispositivo de armazenamento da MDH:
I. devem ser afixados sem utilização de soquete ou conector;
II. não devem estar acessíveis para programação, configuração ou alteração dos dados e registros gravados;
III. devem estar programados de forma a permitir a leitura direta de seu conteúdo por meio de dispositivo específico para este fim, durante a realização de Análise Estrutural ou de perícia técnica solicitada pela fiscalização;
IV. não devem conter instruções que sejam executadas a partir das chamadas de rotinas específicas de comando previsto no “firmware” do equipamento;
2.2.6. Relógio de Tempo Real (RTR)
Componente residente no MF responsável pelo registro da data, hora, minuto e segundos para gravação da estampa de tempo das informações.
2.2.7. Assinatura Digital do AEF
As assinaturas digitais devem ser implementadas utilizando-se o padrão de assinatura digital “XML Digital Signature”, com chave privada de 1024 bits, com padrões de criptografia assimétrica RSA, algoritmo “message digest” SHA-1 e utilização das transformações Enveloped e C14N.
O conteúdo constante do AEF produzido com a utilização deste processo de certificação presume-se verdadeiro em relação aos signatários, na forma do art. 219 da Lei nº 10.406, de 10 de janeiro de 2002.
Para todos os arquivos eletrônicos digitalmente assinados, extraídos de equipamentos MVCT, utilizar-se-ão as chaves previamente especificadas, em conformidade com a faculdade prevista no § 2º do art. 10 da Medida Provisória nº 2.200-2, de 24 de agosto de 2001.
As mensagens utilizam o padrão de assinatura XML definido no endereço eletrônico “http://www.w3.org/TR/xmldsig-core/”.
2.2.8. Módulo de Transmissão de Dados à Fiscalização (MTF)
Componente responsável por transmitir via Internet aos órgãos fiscalizadores os registros e eventos gravados na MDH, previstos no Anexo VI, com endereçamentos de URL configuráveis, sendo que o formato, protocolo e a segurança na transmissão são os definidos no item 3 deste Anexo. Toda alteração de endereçamento de URL o MVCT deverá ser registrada como evento.
2.2.9. Interface de Transmissão à Fiscalização (ITF)
A comunicação remota entre o MVCT e os órgãos de fiscalização se estabelecerá por meio dos dispositivos de interface de comunicação tipo Ethernet, de implementação obrigatória, utilizando conector RJ-45 (Ethernet over twisted pair), sendo de implementação facultativa outra tecnologia que atenda as especificações estabelecidas neste Anexo.
A ITF estabelecerá comunicação externa por iniciativa própria de forma automática, conforme parâmetros previamente programados para comunicação remota aos órgãos de fiscalização, para acesso das informações.
O protocolo de comunicação adotado e formato dos dados estão estabelecidos no item 3 deste Anexo.
Os dados transmitidos por meio desta interface devem manter identidade com os registros e eventos armazenados no MF e seu formato de exportação deve ser o mesmo da interface prevista no item 2.2.8.
2.2.10. Inicialização do MF
Na inicialização do MF, que precede a sua entrada em operação normal, deverão ser configuradas todas as informações necessárias a essa operação, que incluem, entre outras: identificadores, data e instante de tempo correntes, identificação e atributos do contribuinte usuário e parâmetros para o estabelecimento da comunicação remota, devendo esta inicialização ser registrada como evento.
2.2.11. Modo de Intervenção Técnica (MIT)
O MIT consiste no registro de início e término das manutenções realizadas no MF, tais como atualização de SB, ajuste do RTR e outras manutenções que interfiram na sua operação, devendo ter sua descrição registrada no evento de Alteração de Parâmetro do MF.
2.2.11.1. Atualização do Software Básico (SB)
Deve seguir procedimento descrito no item 2.2.3 e registrar na MDH, como evento, as atualizações de SB.
2.2.11.2. Ajuste do RTR
O SB deve permitir o ajuste do relógio de tempo real por meio do PAR, a qualquer momento, sendo gravado como evento na MDH, observando as seguintes condições:
I. o avanço ou o recuo para ajuste decorrente de horário de verão, somente é permitido imediatamente após a gravação de dados na MDH e antes do envio qualquer dado via internet;
II. o avanço ou o recuo além cinco minutos é permitido para efeito de correções, sendo registrado na MDH como evento;
III. os valores ajustados de data e hora deverão ser uma data posterior ao conjunto de data e hora do último dado gravado na MDH, sendo obrigatoriamente válidos e executado em MIT, exceto no caso do item IV;
IV. a fiscalização tributária poderá realizar o ajuste do RTR, desde de que provenha de comandos por internet.
3. TRANSMISSÃO À FISCALIZAÇÃO
Os órgãos de fiscalização disponibilizarão os seguintes serviços:
I. recepção dos registros e eventos de responsabilidade do órgão de fiscalização tributária assinalados na coluna “Tributária” do Anexo VI (Tabela de Registros e Eventos).
II. recepção dos registros e eventos de responsabilidade do órgão de fiscalização ambiental assinalados na coluna “Ambiental” do Anexo VI (Tabela de Registros e Eventos).
Os serviços serão atendidos por Web Service específicos e o fluxo de comunicação será iniciado pelo MVCT por meio do envio de uma mensagem ao Web Service, conforme configuração pré-estabelecida no equipamento.
Os serviços previstos são síncronos. O processamento da solicitação de serviço é concluído na mesma conexão, com a devolução de uma mensagem. Um protocolo de entrega será enviado nesta mensagem quando as validações apontadas no Anexo III forem satisfeitas.
Os dados gravados na MDH devem ser enviados em ordem cronológica desde a última transmissão bem sucedida.
Opcionalmente na mensagem de resposta o Web Service pode incluir uma tarefa ao equipamento MVCT. Esta tarefa será uma mudança nos parâmetros configuráveis do equipamento.

3.1. Padrões Técnicos
3.1.1. Padrão de Documento XML
3.1.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"?>, sendo que cada arquivo XML somente poderá ter uma única declaração.
A declaração do “namespace” da assinatura digital deverá ser realizada na própria tag <Signature>.
O layout de cada arquivo está definido na especificação de cada Web Service, no Anexo III.
3.1.1.2. Padrão de Schema
Para garantir a correta formação dos arquivos XML, o equipamento MVCT deverá gerar o arquivo de mensagem com Schema do XML (XSD – XML Schema Definition) válido, disponibilizado no site do CONFAZ.
3.1.1.3. Montagem do Arquivo
O arquivo XML de transmissão das informações contidas na MDH às fiscalizações será gerado observando as seguintes regras:
I. não incluir "zeros não significativos" para campos numéricos;
II. não incluir "espaços" no início ou no final de campos numéricos e alfanuméricos;
III. não incluir comentários no arquivo XML;
IV. não incluir anotação e documentação no arquivo XML (TAG annotation e TAG documentation);
V. não incluir caracteres de formatação entre as TAGs no arquivo XML ("line-feed", "carriage return", "tab", e caractere de espaço).
VI. o tamanho dos arquivos enviados não poderá ser superior a 10 Mbytes.
3.1.2. Padrão de Comunicação
A comunicação será baseada em Web Services disponibilizados pelos órgãos de fiscalização dos Estados.
O meio físico de comunicação utilizado será a Internet, com o uso do protocolo SSL versão 3.0, com autenticação do serviço disponibilizado pelo órgão de fiscalização. A autenticidade do emitente será garantida pela assinatura da mensagem pelo MVCT com a chave privada registrada no equipamento.
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 dos órgãos de fiscalização e o MVCT será realizada no padrão SOAP versão 1.2, com troca de mensagens XML no padrão Style/Encoding: Document/Literal.

3.2. Padrão de Mensagens dos Web Services
3.2.1. Validação da Estrutura XML das Mensagens dos Web Services
As informações são enviadas ou recebidas dos Web Services por meio de mensagens no padrão XML definido na documentação de cada Web Services, conforme Anexo III.
As alterações de leiaute e da estrutura de dados XML realizadas nas mensagens são controladas por meio da atribuição de um número de versão para a mensagem.
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.
3.2.2. 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”, como segue:
I. envMSGMedicao_v1.00.xsd (Schema XML do envio de mensagem de medição, versão 1.00);
II. envMSGAmbiental_v1.00.xsd (Schema XML do envio de mensagem ambiental, versão 1.00);
III. retMSG_v1.00.xsd (Schema XML do retorno de mensagem do Web Services, versão 1.00);
IV. simcoXMLSchema_v1.00.xsd (Schema XML dos tipos básicos, versão 1.00).
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 por Ato COTEPE e poderão ocorrer sempre que se fizerem necessárias.
As informações gravadas na MDH deverão manter a versão do Schema usado por ocasião da sua gravação.

3.3. Ambiente Virtual
Os órgãos de fiscalização devem desenvolver seus sistemas próprios de recepção de mensagens, seguindo layout estabelecido neste documento.
Os órgãos de fiscalização estão livres para definir prazos para o estabelecimento dos serviços quem envolvem este sistema.
3.4. Especificação dos Web Services
As URL dos Web Services serão disponibilizadas pelos órgãos de fiscalização. Acessando a URL pode ser obtido o WSDL (Web Services Description Language) de cada Web Services.
Estes Web Services estão definidos no Anexo III.

4. REQUISITOS DA OPERAÇÃO COM A FISCALIZAÇÃO
Descreve-se a seguir a operação de transferência de dados, forma de armazenamento e a análise de contingências para cumprir os requisitos deste Anexo.
4.1. Processo de Envio de Dados à Fiscalização
O MVCT deve iniciar a conexão com o Web Service, periodicamente, quando o RTR alcançar um intervalo de tempo entre o momento atual e a última mensagem transmitida maior que o PPE.
Com o equipamento em conexão on-line, devem ser transmitidos os dados registrados na MDH desde a última transmissão bem sucedida.
O arquivo deverá conter em sua estrutura o PEM gerado pelo próprio MVCT que identificará de modo único o bloco de registros enviados.
Utilizando a mesma conexão, o Web Service responderá esta solicitação conforme Anexo III e, satisfazendo as regras de validação, devolverá uma resposta contendo o PRF.
O MVCT deverá efetuar o armazenamento do PRF associando-o diretamente ao PEM sem realizar a alteração dos registros existentes na MDH.
O MVCT deve manter associado aos eventos e registros, que podem ser entregues tanto para a fiscalização tributária como para a fiscalização ambiental, os respectivos protocolos de entrega dos dois órgãos.
No caso em que esteja registrado na MDH o PRF dos dados obtidos em uma conexão direta do MVCT, a montagem do arquivo deverá apresentar tanto o PEM como o PRF associado em sua estrutura.
4.2. Alteração de Parâmetros do MF
A fiscalização poderá enviar uma requisição de alteração de parâmetros utilizando uma conexão aberta entre o MVCT e o Web Service, conforme definido neste Anexo.
4.3. Envio de Eventos à Fiscalização
A fiscalização pode a qualquer momento requisitar o envio dos eventos registrados na MDH por meio do Parâmetro de Requisição de Eventos – PRE.
4.4. Solicitação de Alteração do endereço de URL
A fiscalização pode a qualquer momento requisitar a alteração da URL de endereçamento por meio do PAE.
4.5. Alteração do Parâmetro de Periodicidade de Envio
A fiscalização poderá alterar o PPE devendo o MVCT suportar o envio de dados em no mínimo 30 minutos e no máximo em 1.440 minutos.
O parâmetro PPE com valor zero minuto indicará que não haverá transmissão via internet.
4.6. Alteração do Parâmetro de Tempo de Medidas
A fiscalização tributária pode a qualquer momento requisitar a alteração do PTM conforme definido no item 2.2.4.5.
4.7. Alteração do Parâmetro de Variação de Volume
A fiscalização tributária pode a qualquer momento requisitar a alteração do PVV conforme definido no item 2.2.4.4.
4.8. Situações Operacionais
4.8.1. Leitura de MDH em Virtude de Troca de MF
Em caso do MF estar operacional e ser necessária a troca deste por falta de espaço na MDH caberá ao usuário do MVCT criar um arquivo de recuperação de dados da MDH do MF que será trocado.
4.8.2. Perda de Conexão
Em uma situação em que os dados são encaminhados periodicamente ao Web Service e ocorrer uma perda de conexão, o MVCT continuará efetuando a gravação das informações na MDH e tentará na frequência determinada pelo PPE a retomada da conexão.
Quando a conexão for restabelecida, caberá ao MVCT enviar os dados da MDH que estiverem pendentes de envio, encerrando-se quando todos os dados sejam recebidos pelo Web Service.

5. NORMAS ATENDIDAS
5.1. Normas do MF
As normas a serem atendidas pelo MF estão descritas no item 7.1 - Normas MUS do Anexo I
5.2. Normas do MM
As normas a serem atendidas pelo MM estão descritas no item 7.2 - Normas MCM do Anexo I
ANEXO VI
Tabela de Registros e Eventos
(Acrescentado pelo ATO COTEPE/ICMS 32/14)

TIPO EVENTOIDDescriçãoMVCTTributáriaAmbiental
Registro de Medição
100Registro de Estoque de CombustívelXX
101Registro da Descarga de ProdutoXX
102Registro de Saídas de SondasXX
Registro Alteração Parametrização
120Alteração de Parametrização de VolumeXX
121Alteração de Parametrização de Tempo de MedidasXX
122Alteração de URL FiscoXXX
123Alteração de Relógio XXX
Registros de Ocorrências MF
140Início de Operação MFXXX
141MF desligadoXXX
143Recurso da MDH esgotado (97%)XX
144MM Desconectado (Sem Comunicação com o MM)XXX
145MM Ativo (retorno da Operação do MM)XXX
146MM Inativo (Falha nas funções de Medição)1 XXX
148Falta de Comunicação com Web ServiceXXX
150Retorno Comunicação com Web ServicesXXX
151MF Inicio de ManutençãoXXX
152MF Fim de manutençãoXXX
153Atualização de SBXXX
162Cadastro de NID EfetuadoXXX
163Cadastro de NID RecusadoXXX
164Alteração de Parâmetro do MFXXX
Registros Ocorrências CON
200Falha Comunicação Concentrador / Unidade AbastecedoraXX
201Retorno Comunicação Concentrador / Unidade AbastecedoraXX
202Alteração de Bico x produtoXX
203Registro de Saída dos BicosXX
204Quebra ou Descontinuidade do EncerranteXX
Registros Ocorrências Ambientais
300Presença de LiquidoXX
301Sensor NormalXX
302Sensor em FalhaXX
303Falta de Comunicação com a Fiscalização AmbientalXX
304Retorno de Comunicação com a Fiscalização AmbientalXX
305Alteração de URL da Fiscalização AmbientalXX
1. Vide item 2.2.1. inciso II

ANEXO VII
Diagrama de Blocos MVCT
(Acrescentado pelo ATO COTEPE/ICMS 32/14)