ATO COTEPE/ICMS 32, DE 30 DE JULHO DE 2014

·    Publicado no DOU de 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:

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.

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

xml version = " 1.0 " encoding = " utf-8 " ?>

< medicao   versao = " 1.00 " ^A02 > ^A01

    < equipamento > D0102140002130000189 equipamento > ^B01

    < cnpj > 11222555000101 cnpj > ^B02

    < ie >250000252 ie > ^B03

    < mensagens > ^B04

        < mensagem pem = " 1000 " ^D01 prf = " 3000 " ^D02 > ^C01

            < medicoes > ^D03

                < medicao > ^E01

                    < 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

            medicoes > ^D03

     < totalizacoes > ^D04

         < medicao > ^G01

             < evento > 102 evento > ^H01

             < dataEvento > 2013-10-01T23:59:00+02:00 dataEvento > ^H02

             < tanque > 1 tanque > ^H03

              < volumeBruto > 7000 volumeBruto > ^H04

             < combustivel > 320102002 combustivel > ^H05

         medicao > ^G01

     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

                    < id > 301 id > ^L01

                    < dataEvento > 2013-10-01T12:00:00-03:00 dataEvento > ^L02

                    < texto > Sump bomba 1 texto > ^L04

                evento > ^J01

            eventos > ^C09

        mensagem > ^B01

    mensagens > ^B04

  < Signature xmlns = " http://www.w3.org/2000/09/xmldsig# " >

    < SignedInfo >

      < CanonicalizationMethod Algorithm = " http://www.w3.org/TR/2001/REC-xml-c14n-20010315 " />

      < SignatureMethod Algorithm = " http://www.w3.org/2000/09/xmldsig#rsa-sha1 " />

      < Reference URI = "" >

        < Transforms >

          < Transform Algorithm = " http://www.w3.org/2000/09/xmldsig#enveloped-signature " />

        Transforms >

        < DigestMethod Algorithm = " http://www.w3.org/2000/09/xmldsig#sha1 " />

        < DigestValue > e7jQRU4xmLaQmWVO9pVovhWSeGU= DigestValue >

      Reference >

    SignedInfo >

    < SignatureValue > iv+l8DQlNmp8EVZvn0Smy/tkcCA2wp9gHg7urm9ZD6RiwzSI+oEAY1JYGw9szP7BsQZyH6areeGyVtoAbkY502VjP892OD1lpNdWRDeCjIja1xHyubdSp38YvHAGNK5eKLPpxVqqWk5ISENFMY4cBk5AP/7lxOkeQs8kfHoU/K0= SignatureValue >

  Signature >
medicao >

B.1.1. Descrição do processo de Recepção de Mensagens

B.1.1.1 Geração da Resposta com o Recibo

Não existindo qualquer erro nas validações, o aplicativo deverá gerar um número de recibo PRF e retornará uma mensagem de confirmação de recebimento para o transmissor com as seguintes informações:

a) a versão do aplicativo;

b) o código 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.

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

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 >1 00 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.

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

xml version = " 1.0 " encoding = " utf-8 " ?>

< ambiental   versao = " 1.00 " ^A02 > ^A01

    < equipamento > D0102140002130000189 equipamento > ^B01

    < cnpj > 11222555000101 cnpj > ^B02

    < ie >250000252 ie > ^B03

    < mensagens > ^B04

       < mensagem pem ="1000" ^D01 prf ="3000" ^D02 > ^C01

           < sensores > ^D03

             < sensor > ^E01

                < evento > 300 evento > ^F01

                < dataEvento > 2013-12-01T18:00:05-02:00 dataEvento > ^F02

                < sensor >2 sensor > ^F03

                    sensor > ^E01

             < sensor > ^E01

                 < evento >122 evento > ^F01

                < dataEvento > 2013-12-01T18:28:05-02:00 dataEvento > ^F02

                < sensor >0 sensor > ^F03

             sensor > ^E01

    < eventos > ^D04

       < evento > ^G01

          < id > 123 id > ^H01

           < dataEvento > 2013-10-01T12:00:00-03:00 dataEvento > ^H02

           < texto > URL alterada para www.meioambiente.com.br texto > ^H03

        evento > ^G01

    eventos > ^D04                       

       mensagem > ^C01

    mensagens > ^B04

    < Signature xmlns = " http://www.w3.org/2000/09/xmldsig# " >

    < SignedInfo >

      < CanonicalizationMethod Algorithm = " http://www.w3.org/TR/2001/REC-xml-c14n-20010315 " />

      < SignatureMethod Algorithm = " http://www.w3.org/2000/09/xmldsig#rsa-sha1 " />

      < Reference URI = "" >

        < Transforms >

           < Transform Algorithm = " http://www.w3.org/2000/09/xmldsig#enveloped-signature " />

        Transforms >

        < DigestMethod Algorithm = " http://www.w3.org/2000/09/xmldsig#sha1 " />

        < DigestValue > e7jQRU4xmLaQmWVO9pVovhWSeGU= DigestValue >

      Reference >

    SignedInfo >

    < SignatureValue > iv+l8DQlNmp8EVZvn0Smy/tkcCA2wp9gHg7urm9ZD6RiwzSI+oEAY1JYGw9szP7BsQZyH6areeGyVtoAbkY502VjP892OD1lpNdWRDeCjIja1xHyubdSp38YvHAGNK5eKLPpxVqqWk5ISENFMY4cBk5AP/7lxOkeQs8kfHoU/K0= SignatureValue >

  Signature >
medicao >

B.2.1. Descrição do processo de Recepção de Mensagens

B.2.1.1. Geração da Resposta com o Recibo

Não existindo qualquer erro nas validações,   o aplicativo deverá gerar um número de recibo PRF e retornará uma mensagem de confirmação de recebimento para o transmissor com as seguintes informações:

a) a versão do aplicativo;

b) o código 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.

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

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 >1 00 retorno > ^B01

    < texto >Recebido com Sucesso texto > ^B02

    < prf > 1 prf > ^B03

       < pem >1 pem > ^B04

    < tarefa > ^B05

        < periodoRemessa > 300 periodoRemessa > ^C01

        < urlRemessa > https://mvc.fatma.sc.gov.br/ urlRemessa > ^C02

        < requisicaoEvento > ^C03

            < dataInicio > 2013-01-01 dataInicio > ^D01

            < dataFim > 2013-01-31 dataFim > ^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

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:

as sondas de medição, que devem estar instaladas em todos os compartimentos dos tanques de armazenamento de combustíveis líquidos;

os sensores ambientais;

as unidades abastecedoras de combustíveis, admitid a 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 se guro, 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, hor a, minutos e segundos d o 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

1. Vide item 2.2.1. inciso II

ANEXO VII

Diagrama de Blocos MVCT

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

MANUEL DOS ANJOS MARQUES TEIXEIRA

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

MANUEL DOS ANJOS MARQUES TEIXEIRA

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

MANUEL DOS ANJOS MARQUES TEIXEIRA