Legislação Tributária
ICMS

Ato:Ato COTEPE/ICMS
Número:32
Complemento:/2014
Publicação:08/07/2014
Ementa:Altera o Ato COTEPE/ICMS 10/14, que 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 32, DE 30 DE JULHO DE 2014
· Publicado no DOU de 07.08.14, Seção 1, p. 20.

O Secretário-Executivo do Conselho Nacional de Política Fazendária - CONFAZ, no uso das atribuições que lhe confere o art. 12, XIII, do Regimento da Comissão Técnica Permanente do ICMS - COTEPE/ICMS, de 12 de dezembro de 1997, por este ato, torna público que a Comissão, na sua 157ª reunião ordinária, realizada nos dias 29, 30 e 31 de julho de 2014, em Brasília, DF, decidiu:

Art. 1º Os dispositivos a seguir indicados do Ato COTEPE/ICMS 10/14, de 14 de março de 2014, passam a vigorar com a seguinte redação:

I – o caput do art. 1º:

“Art. 1º Fica aprovada a Especificação de Requisitos composta pelos Anexos I a IV deste ato, na versão 01.00, que deve ser observada pelo Medidor Volumétrico de Combustíveis (MVC) e pelos Anexos V a VII, a ser observada pelo Medidor Volumétrico de Combustíveis de Transição (MVCT)”;

II – o caput do art. 2º:

“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”;

III – o item 3.3.8 do Anexo I:

“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.”

IV - o item 3.7 do Anexo I:

“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”;

V – o item 3.8 do Anexo I:

“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”;

VI – o Anexo III:

“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: envMSGMedicao_v1.00.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-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
<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
<evento>100</evento> 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
<evento>100</evento> 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 </totalizacoes> D04
<saidas> D05
<saida> IO1
<evento>203</evento> J01
<dataEvento>2013-10-01T23:59:00+02:00</dataEvento> J02
<combustivel>320102002</combustivel> J03
<bico>1</bico> J04
<tanque>1</tanque> J04
<encerranteInicio>125</encerranteInicio> J05
<encerranteFim>185</encerranteFim> J06
<volumeBruto>3185</volumeBruto> J07
</saida> I01
</saidas> D05
<eventos> D06
<evento> K01 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 00 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
1Contribuinte001Contribuinte não cadastrado
2MVC002Equipamento não cadastrado
3Assinatura003Assinatura inválida
4XML004XML inválido
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).
B.1.1.2. Leiaute da Mensagem de Retorno Schema XML: retMSG_v1.00.xsd
CampoPaiTipoOcor.Tam.Dec.Descrição/Observação
A01
retEnvMSG
-
-Tag Raiz
A02
versao
A01
N
1-1
1-42Versão do layout
B01
retorno
A01
N
1-1
3Có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-15Numero de recibo gerado pelo web-service
B04
pem
A01
N
1-1
1-15Número do protocolo de envio do equipamento 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
255Url 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 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

Exemplo de mensagem de retorno
<?xml version="1.0" encoding="utf-8"?>
<retEnvMSG xmlns="http://www.sef.sc.gov.br/simcoXMLSchema.xsd" 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>
</tarefa> B05
</retEnvMSG>

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: envMSGAmbiental_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
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
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 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
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 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
texto
G01
C
0-1
255
Informações adicionais sobre o evento registrado pelo equipamento.
A05
signature
A01
1-1Conforme 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
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 00 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
1Contribuinte001Contribuinte não cadastrado
2MVC002Equipamento não cadastrado
3Assinatura003Assinatura inválida
4XML004XML inválido
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 abaixo indicado:
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: retMSG_v1.00.xsd
CampoPaiTipoOcor.Tam.Dec.Descricao/Observação
A01
retEnvMSG
-
-Tag Raiz
A02
Versão
A01
N
1-1
1-42Versão do layout
B01
Retorno
A01
N
1-1
3Có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-15Numero de recibo gerado pelo web-service
B04
Pem
A01
N
1-1
1-15Número do protocolo de envio do equipamento 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"?>
<retEnvMSG versao="1.00" A02> A01
<retorno>100</retorno> B01
<texto>Recebido com Sucesso</texto> B02
<prf>1</prf> B03
<pem>1</pem> B04
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 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>”.

Art. 2º Ficam acrescidos os Anexos V, VI e VII ao ATO COTEPE/ICMS 10/14, de 14 de março de 2014, com a seguinte redação:

“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 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

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