<!ELABORAÇÃO: Equipe Técnica da "AFISCOM">

ATO COTEPE/ICMS Nº 32, DE 30-07-14 – DOU 07-08-14

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).

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:

Artigo 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º:
“Artigo 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-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.
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	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 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-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 B01
< cnpj>11222555000101 B02
< ie>250000252 B03
< mensagens> B04
< mensagem pem="1000" D01 prf="3000" D02> C01
< medicoes> D03
< medicao> E01
< evento>100 F01
< dataEvento>2013-10-01T12:00:25-03:00 F02
< tanque>1 F03
< volumeBruto>11250 F04
< volume20>11230 F05
< temperatura>25 F06
< combustivel>320102002 F07
< /medicao> E01
< medicao> E01
< evento>100 F01
< dataEvento>2013-10-01T12:00:25-03:00 F02
< tanque>2 F03
< volumeBruto>25100 F04
< volume20>24490 F05
< temperatura>25 F06
< combustivel>320101002 F07
< /medicao> E01
< /medicoes> D03
< totalizacoes> D04
< medicao> G01
< evento>102 H01
< dataEvento>2013-10-01T23:59:00+02:00 H02
< tanque>1 H03
< volumeBruto>7000 H04
< combustivel>320102002 H05
< /medicao> G01
< /totalizacoes> D04
< saidas> D05
< saida> IO1
< evento>203 J01
< dataEvento>2013-10-01T23:59:00+02:00 J02
< combustivel>320102002 J03
< bico>1 J04
< tanque>1 J04
< encerranteInicio>125 J05
< encerranteFim>185 J06
< volumeBruto>3185 J07
< /saida> I01 D05
< eventos> D06
< evento> K01
< id>301 L01
< dataEvento>2013-10-01T12:00:00-03:00 L02
< texto>Sump bomba 1 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=
< /Reference>
< /SignedInfo>
< SignatureValue>iv+l8DQlNmp8EVZvn0Smy/tkcCA2wp9gHg7urm9ZD6RiwzSI+oEAY1JYGw9szP7BsQZyH6areeGyVtoAbkY502VjP892OD1lpNdWRDeCjIja1xHyubdSp38YvHAGNK5eKLPpxVqqWk5ISENFMY4cBk5AP/7lxOkeQs8kfHoU/K0=
< /Signature>
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ção	Código	Mensagem
1	Contribuinte	001	Contribuinte não cadastrado
2	MVC	002	Equipamento não cadastrado
3	Assinatura	003	Assinatura inválida
4	XML	004	XML 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).
Schema XML: retMSG_v1.00.xsd

	Campo	Pai	Tipo	Ocor.	Tam.	Dec.	Descricao/Observação
A01	retEnvMSG	-			-		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 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	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 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 B01
< texto>Recebido com Sucesso B02
< prf>3 B03
< pem>1 B04
< tarefa> B05
< relogio>200.20.186.75:123 C01
< periodoRemessa>300 C02
< urlRemessa>https://mvc.tributario.sef.sc.gov.br/ C03
< variacaoVolume>100 C04
< tempoMedida>30 C05
< requisicaoEvento > C06
< dataInicio>2013-01-01 D01
< dataFim>2013-01-31 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.

	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.
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-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 B01
< cnpj>11222555000101 B02
< ie>250000252 B03
< mensagens> B04
< mensagem pem="1000" D01 prf="3000" D02> C01
< sensores> D03
< sensor> E01
< evento>300 F01
< dataEvento>2013-12-01T18:00:05-02:00 F02
< sensor>2 F03
< /sensor> E01
< sensor> E01
< evento>122 F01
< dataEvento>2013-12-01T18:28:05-02:00 F02
< sensor>0 F03
< /sensor> E01
< eventos> D04
< evento> G01
< id>123 H01
< dataEvento>2013-10-01T12:00:00-03:00 H02
< texto>URL alterada para www.meioambiente.com.br 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=
< /Reference>
< /SignedInfo>
< SignatureValue>iv+l8DQlNmp8EVZvn0Smy/tkcCA2wp9gHg7urm9ZD6RiwzSI+oEAY1JYGw9szP7BsQZyH6areeGyVtoAbkY502VjP892OD1lpNdWRDeCjIja1xHyubdSp38YvHAGNK5eKLPpxVqqWk5ISENFMY4cBk5AP/7lxOkeQs8kfHoU/K0=
< /Signature>
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ção	Código	Mensagem
1	Contribuinte	001	Contribuinte não cadastrado
2	MVC	002	Equipamento não cadastrado
3	Assinatura	003	Assinatura inválida
4	XML	004	XML 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

	Campo	Pai	Tipo	Ocor.	Tam.	Dec.	Descricao/Observação
A01	retEnvMSG	-			-		Tag Raiz
A02	Versão	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 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 B01
< texto>Recebido com Sucesso B02
< prf>1 B03
< pem>1 B04
< tarefa> B05
< periodoRemessa>300 C01
< urlRemessa>https://mvc.fatma.sc.gov.br/ C02
< requisicaoEvento> C03
< dataInicio>2013-01-01 D01
< dataFim>2013-01-31 D02
< /requisicaoEvento> C03
< /tarefa> A05
< /retEnvMSG>
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

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

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

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

1-1

Atributo URI da tag Reference

XS09

Transforms

XS07

1-1

Grupo do algorithm de Transform

XS10

Transform

XS09

2-2

Grupo de Transform

XS11

Algorithm

XS10

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

1-1

Atributo Algorithm de DigestMethod:http://www.w3.org/2000/09/xmldsig#sha1

XS14

DigestValue

XS07

Digest Value (Hash SHA-1 – BASE 64)

XS15

SignatureValue

XS01

1-1

Grupo do Signature Value

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= XS14
< /Reference>
< /SignedInfo>
< SignatureValue>iv+l8DQlNmp8EVZvn0Smy/tkcCA2wp9gHg7urm9ZD6RiwzSI+oEAY1JYGw9szP7BsQZyH6areeGyVtoAbkY502VjP892OD1lpNdWRDeCjIja1xHyubdSp38YvHAGNK5eKLPpxVqqWk5ISENFMY4cBk5AP/7lxOkeQs8kfHoU/K0= XS15
< /Signature>”.

Artigo 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: , 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.
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 EVENTO	ID	Descrição	MVCT	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
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
Registros de Ocorrências MF	140	Início de Operação MF	X	X	X
	141	MF desligado	X	X	X
	143	Recurso da MDH esgotado (97%)	X	X
	144	MM Desconectado (Sem Comunicação com o MM)	X	X	X
	145	MM Ativo (retorno da Operação do MM)	X	X	X
	146	MM Inativo (Falha nas funções de Medição)	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	MF Inicio de Manutenção	X	X	X
	152	MF Fim de manutenção	X	X	X
	153	Atualização de SB	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 MF	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

1. Vide item 2.2.1. inciso II
ANEXO VII
Diagrama de Blocos MVCT

Artigo 3º - Este ato entra em vigor na data de sua publicação no Diário Oficial da União