Exibir código-fonte para BISPDV

O BISPDV é a aplicação utilizada na frente de caixa para realização da venda ao consumidor e de outra funções pertinentes à venda e atendimento do cliente da loja.

= Arquitetura =

O aplicativo apresenta a arquitetura dividia conforme o diagrama abaixo:

[[File:BISPDVArquitetura.png|center]]

== PDVStarter == 

O PDVStarter é a classe inicial da aplicação, a classe que contém o método main(). Ela faz apenas algumas verificações mínimas e necessárias para o funcionamento, como definições do ambiente java, e logo seguida inicializa o '''PDVUI'''.

== PDVUI ==

PDVUI é a responsável pela Interface Gráfica da aplicação. A interface é montada toda com o JavaFX, por isso o método chamado no PDVUI para inicia-lo é o ''launch()''. Ao iniciar, o JavaFX chamará o método ''start(Stage stage)''.

O PDVUI é o responsável por montar as telas e a interface gráfica para o usuário, porém como todo o controle da aplicação é feita através do PDVApp o PDVUI lê os estados do PDVApp para saber que tela montar, que controles exibir, etc. O PDVUI é atualizado através de eventos emitidos pelo PDVApp.

No PDVUI apenas as lógicas de UI são colocadas, como alguma validação de entradas do usuário, formatação e layout de tela, algumas questões de segurança para exibir ou esconder os componentes de tela, etc.

=== PDVScreenInterface ===

A classe PDVUI é a classe de controle geral da interface. Mas a cada estado do PDVState, a tela montada é "sub-controlada" pelas implementações de PDVScreenInterface. Em outras palavras, os únicos componentes que a PDVUI tem como filhas são as implementações dessa interface.

Essas implementações montam uma tela para cada fase do sistema. Por exemplo, ao iniciar a aplicação é utilizada a "StartScreen", que monta a tela para exibir as informações de inicialização e instalação, além da tela de Log-In. Após o login, o usuário é direcionado para a tela administrativa, montado pela "AdminScreen". Caso o usuário entre no modo de vendas, toda a tela de venda ao consumidor (responsável por exibir as fotos de produtos ao fundo) é gerenciada pela "SaleScreen" e assim por diante.

Em geral, a PVDUI troca essa "Screen" para estado do PDVState. Dentro de cada estado do PDVState, seus substados são verificados e controlados por cada Screen.


=== BISPDVFrame ===

Além das Screens que montam a "tela" da aplicação em cada estado, há as janelas chamadas de "Frames". Esses frames são janelas modais que são colocadas por cima da Screen para indagar o usuário para realizar alguma função.

Exemplos de Frames são as telas de configurações de Servidor ou do Sistema de Emissão do Cupom Fiscal, que aparecem por cima da AdminScreen. Ou a tela de identificação do cliente (CPF/Nota Paulista), que aparece por cima da SaleScreen ao começar uma nova venda.



= PDVApp =

Esta classe Singleton é responsável pela inteligência da aplicação. Através desta classe são realizadas todas as as ações de vendas, configurações, validações, segurança etc. Assim como uma camada "CRUD", esta classe faz a ligação entre as partes do sistema (CFSystem, Impressoras, TEF, Banco de Dados, etc.) e a interface do usuário (PDVUI).


Qualquer comando que o PDVUI receba do usuário, deve ser passado e tratado dentro do PDVApp, sincronizado se for o caso. O PDVApp processa e valida o comando.

Abaixo o mapa completo dos estados e "sub-estados" que o PDVApp pode assumir:

[[File:BISPDVFullStateMap.png|center]]

== PDVState ==

O PDVApp pode ser considerado uma máquina de estados se analisar os passos que ele segue, e que ele guia o usuário. O controle do passo em que o PDVApp está é feito através do atributo PDVState dentro do próprio PDVApp.

Assim que aplicação é iniciada, este estado é inicializado com o valor "START", que implica que aplicação está iniciando. Em seguida ela seguirá o fluxo conforme a imagem abaixo:

[[File:BISPDVPDVState.png|center]]

=== PDVStateSales ===

Estes estatus servem como sub-status quando o PDVState está em SALES. Estes estados tem a função de definir em que passo da venda o PDVApp está no momento.

Quando o PDVState entrar no estado "SALES", o PDVStateSales deve iniciar no valor "NONE". Assim como para que o PDVState possa sair do estado "SALES", é obrigatório que o PDVStateSales tenha o valor "NONE".

{{nota|Recuperação de Desligamento|Em caso de recuperação de desligamento incorreto, o sistema pode entrar no modo PDVState "SALES" e o PDVStateSales já ter um valor carregado diferente. Que tenha sido persistido e recuperado junto com o CheckoutDat}}

[[File:BISPDVPDVStateSales.png|center]]


* '''NONE''' - Este estado indica que embora o PDVApp esteja no estado de venda, no momento não há nenhuma venda ocorrendo. Toda vez que o PDVState entrar em '''Selling''', o PDVStateSales inicia neste estado. Assim como, para que o PDVState saia do estado '''Selling''', é necessário que o PDVStateSales já tenha retornado para o NONE.
*: Apenas no caso de recuperação de desligamento incorreto o sistema o PDVState pode entrar em Selling, e já encontrar o PDVStateSale em um estado diferente.

* '''SALE_SELLING''' - Este estado indica que há uma venda ocorrendo neste momento, e que a venda está efetivamente no estado de "venda". Isto é, indica que a venda está no processo de registrar os itens que estão sendo vendidos ao consumidor.

* '''SALE_PAYMENT''' - Após o término do estado anterior, quando todos os itens já estão registrados para venda, passamos para o estado de planejamento dos pagamentos. Neste passo indicamos para o sistema como os pagamentos serão realizados. Só conseguimos passar para o passo seguinte depois de informar pagamentos suficientes para quitar o total dos produtos vendidos no passo anterior.

* '''SALE_FINALIZATION''' - Após informar os produtos e as formas de pagamento, o sistema entra neste passo para finalizar toda a venda. Neste passo o sistema processa toda a informação fornecida nos passos anteriores (itens e pagamentos), e executa tudo o que for necessário. Por exemplo, pagamentos com TEF, Tiquetes e outras operações que envolvam sistemas externos serão notificados e ativados no processamento deste passo.
*: Ao entrar neste passo o usuário não terá mais autonomia para retornar aos passos anteriores. A única condição que permitirá que o usuário volte ao passo anterior será a ocorrência de algum erro durante o processamento E QUE permita esse retrocesso ao passo anterior.

* '''SALE_SHOW''' - Ao terminar o processamento de finalização da venda, o sistema para neste passo. Neste passo o cupom e as informações continuam carregadas no PDVApp mas já estão todas processadas, salvas e finalizadas. Este passo tem apenas a finalidade de permitir que informações sejam exibidas ao usuário pelo UI. Assim que o usuário as confirmar, o sistema descarrega das variáveis esta venda e volta para o passo '''NONE''', preparando-se para outra venda ou outra operação.

== PDVApp Listeners ==

=== PDVSaleEventListener ===

Este listener oferece notificações dos eventos relacionados a operação de venda ao consumidor. Como por exemplo, "Nova venda iniciada" (OPENCUPOM), "Última Venda Cancelada" (CALCELLASTCFX), "Venda atual cancelada" (CANCELHALFCFX), "Item Vendido/Registrado" (ITEMSOLD), e assim por diante....

=== PDVStateChangeListener ===

Este listener é acionado a cada alteração no valor do PDVState.

= StartCheck =

StartCheck é a rotina de inicialização que o PDVApp executa logo após a aplicação ser iniciada, antes que o usuário possa realizar qualquer interação com a aplicação. A rotina do StartCheck segue os passos conforme o Fluxograma abaixo:

[[File:BISPDVStartCheck.png|center]]


* '''INITING''' - é apenas o primeiro estado, o estado inicial de quando a aplicação é carregada. Não há nenhuma execução neste estado, apenas é passado para o próximo.

* '''CHECKING_LOCALDB''' - Este passo é responsável por verificar o banco de dados local. Verifica sua existência e tentativa de conexão. Caso ele não exista, é criado. Caso não seja possível conectar, lança erro avisando o usuário que provavelmente há outra instância da aplicação rodando.

* '''CHECKING_LOCALDB_VERSION''' - Complementar a tarefa anterior, neste passo o sistema verifica a versão do banco de dados atual. Caso a aplicação tenha sido atualizada este passo executará os comandos necessários para atualizar o banco antes que o resto da aplicação tente acessa-lo. Caso a atualização tenha algum problema a aplicação é encerrada para evitar que o uso dos dados de forma incorreta danifiquem os dados.

* '''CHECKING_INSTALLATION''' - Este passo é essencial para a configuração da aplicação. Antes que o usuário possa utilizar a aplicação é necessário que alguma configurações sejam definidas, como por exemplo endereço do servidor, e periféricos pertinentes ao caixa. Caso a verificação perceba que alguma configuração inicial é necessária o StartCheck será interrompido e o sistema entrará no estado '''INSTALLATION_NEEDED'''. 
*: Ao entrar neste estado o PDVUI detecta e exibirá o Wizard de configuração para o usuário. Uma vez que o Wizard seja finalizado ele envia ao PDVApp o comando para tentar o '''CHECKING_INSTALLATION''' novamente. E em caso de sucesso, seguirá para o próximo passo.
*: Note que a maior parte das configurações, principalmente as que são iguais para todos os caixas, é definida pelo servidor e sincronizada para todos os caixas. Não há como altera-las diretamente na aplicação.

* '''INSTALLATION_OK''' - Neste passo não há processamento, é apenas um passo indicativo de que a instalação está OK e que pode continuar. Um estado "contrário" ao '''INSTALLATION_NEEDED''', fazendo que o StartCheck continue sua rotina.

* '''CHECKING_SERVER_ID''' - Durante a primeira inicialização/instalação da aplicação ela se registrará no servidor recebendo um ID único para identificação deste terminal deste ponto em diante. Servindo para rastrear tudo o que acontece em cada caixa/terminal de atendimento.

* '''OK''' - Este é o passo final, que indica para as outras rotinas de que o StartCheck finalizou com sucesso é que o PDVApp está pronto para seguir para o próximo passo.

= CFSystem =

O CFSystem (Sistema de Cupom Fiscal) é o nome dado para o encapsulamento dos diferentes sistemas de emissão de cupom fiscal - SAT, ECF, NFCe, etc. - suportados atualmente ou que venham a existir no futuro. Separando o controle da emissão do cupom fiscal das rotinas do sistema permite que o mesmo app seja reaproveitado para todas as tecnologias existes com pouca ou nenhuma adaptação.

Esse encapsulamento funciona porque embora independente de como a tecnologia da emissão funcione a rotina de venda é sempre a mesma de forma geral: "Inicia a Venda - Registra Produtos - Executa Descontos e Totalizações - Recebe Pagamentos - Finaliza Venda". A cada passo da venda o PDVApp chamará os métodos da interface do CFSystem para notificar os acontecimentos da venda. Devendo o CFSystem traduzir e organizar o funcionamento para cada tecnologia.

O CFSystem é uma interface que permite as implementações das distintas tecnologias. Assim, cada implementação do CFSystem representa um equipamento e modelo de emissão diferentes. Por exemplo, a implementação para suporte do ECF Daruma é uma classe "CFSystemECFDaruma" que implementa a CFSystem.

O CFSystem também apresenta os métodos para impressão de relatórios gerenciais e outros documentos não fiscais.

== CFSystemFactory ==

Esta classe permite que a implementação correta do CFSystem seja retornada de acordo com os parâmetros de configuração passados. Seguindo o pattern "Factory".

= Cupom Fiscal / PDVCupomVO =

Independente do sistema de emissão do cupom fiscal, o cupom fiscal é representado no sistema pelo PDVCupomVO. Para cada tipo de cupom fiscal (emitido por sistemas diferentes) o objeto apresentará um conjunto de atributos obrigatórios.

== Ciclo de Vida do Cupom Fiscal ==

O cupom fiscal segue um ciclo de vida básico representado pela enumeration PDVCUPOMSTATUS, conforme o diagrama abaixo:

[[File:BISPDVCupomStatus.png|center]]


{{nota|Estados Adicionais|Alguns sistemas de emissão, como o NFCe, apresentam mais estados por conta do controle de transmissão e emissão. Esses estados adicionais serão tratados no capítulo próprio do sistema. Vale a pena verifica se esses estados devem continuar utilizando a mesma variável ou se deve ter um conjunto de estados a parte dentro do VO, para não interferir no funcionamento do PDVApp, uma vez que o sistema de emissão é abstraído pela interface CFSystem.}}