1 - Introdução

Este documento apresenta uma visão geral do aplicativo MID-e CLIENT, focando suas funcionalidades e definições de sua arquitetura.

O objetivo desta documentação não é descrever uma especificação funcional, mas oferecer todas as informações necessárias para a compreensão da solução proposta.

O principal objetivo do MID-e CLIENT é realizar a interface de comunicação entre os componentes da loja (PDVs) e o MID-e, contemplando situações de falha de comunicação entre os sistemas.

Para fins de contextualização, o MID-e é um sistema corporativo responsável por realizar transações de autorização e controle entre os componentes de frente de loja e a Secretaria da Fazenda (SEFAZ).

Este processo de autorização é crítico, uma vez que a finalização das operações fiscais no PDV depende do retorno positivo do serviço web da SEFAZ.

Nos cenários em que a interação entre PDV e MID-e esteja online, o MID-e CLIENT resume sua atuação apenas a um canal de comunicação entre os sistemas. Porém, nos casos de falha de comunicação, o MID-e CLIENT deve assumir o controle e prover um serviço de contingência que forneça todos os insumos necessários para realização da operação de forma off-line no PDV.

O serviço de contingência consiste em autorizar a operação off-line do PDV e, posteriormente, enviar as autorizações, no formato XML, para o MID-e.

Esta sincronização é necessária, pois o não envio das operações realizadas de forma off-line acarreta multa para o lojista. Logo, o principal propósito da contingência é reduzir os efeitos de possíveis problemas de comunicação que impeçam a operação de loja e, por conseqüência, acarretem perdas de venda e prejuízos financeiros.

2 - Visão geral deste documento

Esta seção fornece as informações necessárias para que se faça um bom uso deste documento, explicitando seus objetivos e as convenções que foram adotadas no texto, além de conter uma lista de referências para outros documentos relacionados.

As demais seções apresentam as alterações a serem implementadas e estão organizadas como descrito abaixo.

Seção 3 – Convenções, termos e abreviações: detalhamentos de itens para agilizar e facilitar o entendimento do documento.

Seção 4 – Descrição geral do sistema: apresenta uma visão geral do sistema, caracterizando qual é o seu escopo e a arquitetura da solução proposta.

3 - Convenções, termos e abreviações

A correta interpretação deste documento exige o conhecimento de algumas convenções e termos específicos, que são descritos a seguir.

  • MID ou MID-e – Sistema corporativo responsável por realizar comunicação com o Web Service da Secretaria da Fazenda para obter autorizações das operações de loja. Como venda e cancelamento, por exemplo.
  • SAT – Hardware ainda em desenvolvimento que terá a função de substituir as impressoras fiscais no longo prazo. Este componente realizará comunicação direta com o MID-e.
  • API Cliente SAT – Interface de comunicação entre os componentes e o hardware SAT.

          Observação:  Embora consideremos neste documento o componente SAT (para termos de completude da documentação), nenhuma implementação referente ao hardware será mencionada, visto que existem pendências no desenvolvimento deste componente.

  • API Communication – API que oferece serviços de comunicação síncrona e assíncrona entre componentes, permitindo persistência de filas de mensagens, em caso de problemas de comunicação.
  • DANFE (Documento Auxiliar da Nota Fiscal Eletrônica) – Representação gráfica simplificada da Nota Fiscal Eletrônica, em papel comum e em via única. Contém a chave de acesso para consulta da NF-e na Internet e um código de barras que facilita verificação das informações da NF-e pelas unidades fiscais.

4 - Descrição geral do sistema

Nesta seção é apresentada uma visão geral da arquitetura do MID-e CLIENT, bem como um detalhamento de suas funcionalidades, conforme divisão dos tópicos a seguir:

 

  • Arquitetura Geral da Solução;

 

  • Detalhamento da Arquitetura da Solução; e

 

  • Configurações do MID-e CLIENT.


4.1 - Arquitetura Geral da solução

Esta subseção objetiva apresentar a arquitetura geral e distribuída definida para a solução do aplicativo MID-e CLIENT.

A Figura 1 a seguir, ilustra os sub-componentes que formam o MID-e CLIENT, além de detalhar o relacionamento com os outros sistemas que completam o ciclo de comunicação PDV x SEFAZ.

                                            Figura 1 - Arquitetura de Distribuição


Pode-se verificar que o MID-e CLIENT atua como uma interface de comunicação entre o PDV Java e o MID-e, repassando as solicitações de autorização entre esses componentes.

A API Communication presente na arquitetura garante o processo de persistência das mensagens que representam as operações de contingência.

Outra funcionalidade associada à API é o controle da transmissão das mensagens entre fonte e destino.

4.2 - Detalhamento da Arquitetura da Solução

Para facilitar o entendimento da arquitetura, nesta subseção são detalhadas as ações do MID-e CLIENT, além das interações e troca de mensagens entre os componentes da Figura 1.

Para tal, foram adicionados os diagramas de caso de uso e seqüência, respectivamente, Figuras 2 e 3.


                                      Figura 2 - Diagrama de Casos de Uso



A Figura 2 ilustra os casos de uso associados ao componente MID-e CLIENT.

O propósito não é detalhar as funcionalidades (este processo será realizado do documento funcional), mas apresentar de forma geral as operações que o MID-e CLIENT contempla.

O retângulo colorido concentra as funcionalidades que o MID-e CLIENT deve desempenhar quando operar no modo de contingência.

Pode-se observar que no cenário de contingência, o MID-e CLIENT deve realizar as seguintes ações para permitir a conclusão das operações do PDV:

 

  • Gerar autorizações off-line – Objetivo: retornar ao PDV a URL e DANFE para permitir que a operação da loja não seja interrompida;

 

  • Persistir autorizações off-line (Arquivo no formato XML) – Objetivo: enviar operações realizadas off-line na loja para validação na SEFAZ;

 

  • Gerar cópias das autorizações off-line – Objetivo: mitigar riscos de perda de dados, em caso de problemas físicos de hardware;

 

  • Transmitir as autorizações off-line para o MID-e – Objetivo: validar as informações junto à entidade fiscal.


Logo a seguir, o diagrama de seqüencia (Figura 3) detalha a interação entre os componentes da arquitetura.

Através da troca de mensagens podem-se destacar mais algumas considerações:


  • Quando operando no modo de contingência, a arquitetura do MID-e CLIENT prevê a possibilidade de geração de cópias de segurança dos arquivos XML a serem enviados ao MID-e. Obviamente, para aplicar esta característica, o cliente deve prover duas instâncias do MID-e CLIENT em sua aplicação, localizadas em diferentes máquinas. Neste cenário um MID-e CLIENT funciona como autorizador off-line e outro como transmissor das mensagens para o MID-e.
  • Conforme parametrização, o MID-e CLIENT realiza verificação contínua da fila de persistência para repassar autorizações off-line para MID-e. Detalhes da parametrização serão apresentados na próxima subseção.


                                                                                 Figura 3 - Diagrama de Seqüência

4.3 - Configurações do MID-e CLIENT

A arquitetura do MID-e CLIENT permite que o mesmo seja utilizado como API ou como Serviço.

A motivação para esta decisão é a possibilidade deste componente ser utilizado em outros produtos Java de mercado.

Como API, o MID-e CLIENT torna-se uma biblioteca que fornece métodos de acesso para suas funcionalidades.

Nessa categoria, somente será utilizada em outros sistemas Java.

Uma vez configurado como Serviço, o MID-e CLIENT funciona como aplicação independente que recebe as solicitações de outros sistemas para realizar o processamento online ou off-line conforme apresentado nas seções anteriores.

Um importante conceito do MID-e CLIENT é diferenciar as ações: autorização off-line X operação no modo off-line. Entende-se por autorização off-line o processo que o MID-e CLIENT executa caso haja falha de comunicação na solicitação ao MID-e.

Porém, esta autorização não obrigatoriamente conduz o MID-e CLIENT a executar o processo de contingência na próxima solicitação.

Já o conceito de operação no modo off-line força o MID-e CLIENT a nem tentar conexão com o MID-e para evitar onerar a rede com solicitações sem resposta, além de aumentar o tempo de conclusão da operação no PDV enquanto é aguardado o retorno da solicitação (sucesso ou timeout).

Uma vez operando no modelo off-line, o MID-e CLIENT também deve ser configurado por quanto tempo permanecer neste modo de operação, antes de voltar ao modo on-line.

Então, o MID-e CLIENT oferece mais duas configurações:

  • Parametrização para poder desprezar as primeiras X falhas de comunicação antes de operar no modo off-line. Este comportamento permite a liberdade de configuração para cada cliente em função de suas características físicas como: largura de banda, limitações de conexões 3G, entre outras customizações.
  • Parametrização de tempo operando no modo off-line.

Por fim, conforme detalhado nas seções anteriores, o MID-e CLIENT oferece suporte à geração de cópias de segurança das autorizações off-line.

Esta facilidade é opcional, podendo o cliente decidir que apenas uma instância do componente é suficiente em sua estrutura, assumindo o controle de geração e transmissão da contingência.

Caso seja habilitada a criação das cópias, também são parametrizadas as informações de destino (IP/PORTA) do MID-e CLIENT de “backup”.







  • Sem rótulos