HOG Invest

Definições da Arquitetura Organização do Projeto

Resumo de Regras para GPT

• Nomes de Classes, métodos e variáveis devem sempre estar escritas em inglês e no formato de CamelCase, não utilizar _ para separar palavras;
• Ao implementar métodos e classes sempre documente a funcionalidade e detalhes dos parâmetros recebidos.

Organização do Projeto

• etc/ - Documentos e Outros arquivos relacionados ao Projeto
  • DBModel/ - Modelos do Banco de Dados
• run/ - Script para execução de comandos e rotinas por linha de comando.
• src/ - Códigos do Sistema
  • crud - Classes com código de CRUD (Core) da aplicação.
    • vo - Classes que representam objetos (Value Objetcs)
  • lib - Classes utilitárias utilizada por diversas classes do sistema, como Log, DAO, etc..
  • modules/ - Classes e módulos específicos, como os de comunicação com outro sistemas e APIs (Como comunicação com BCB, B3, WebCrawlers, etc.).
• root/ - UI do Sistema, pasta publicada pela URL

Operações do Banco de Dados

• Persistência e Exclusão - Os métodos de persistência e exclusão dos objetos devem ser concentrados dentro da classe DAO.
• Consultas - Consutla ao banco de dados deve ser feita diretamente da classe que precisar dos dados, apesar de descentralizar a manutenção, fica mais fácil e dinâmico a programação de obtenção de dados, joins, etc.

Requisitos e Defnições

Ativos stock

Requisitos

• Os ativos podem ser de diversos tipos (ações, BDRs, FIIs, etc.) desde que negociados em Bolsa, e podem ser de diversos países.
• Além do país, deve ter a referência para a bolsa de valores em que é negociado. Há países com mais de uma bolsa de valores.
• O tipo do ativo (Ação, ADR, FII, BDR, etc.) deve ser definido para realizar filtros nas carteiras.
• Data inicial e final em que o ativo foi negociado. Nada final nula indica que o ativo ainda está ativo e continua sendo negociado.
• O sistema deve salvar a data em que o registro foi criado e em que data foi atualizado pela última vez para referência e outras funcionalidades futuras.
• Uma vez que o ativo deixe de ser negociado a data fim deve ser definida para evitar lançamentos errados, além de evitar que tickers reutilizados no futuro causem confusão na carteira.
• Todos os ativos que tenham sua data fim definida devem ter seu status definido como INATIVO, para o gerenciamento desses ativos pelo código.

Arquitetura

• Campos do stock:
  • ticker: define o ticker do ativo, embora a B3 tenha um padrão de nome as americanas permitem ativos com até uma letra.
  • exchange: Enumeration com as bolsas de valores suportadas pelo sistema
    • B3 - Bolsa de Valores brasileira
  • startDate: Data de início das negociações
  • endDate: Data de fim das negociações, ou nulo se ainda for negociada.
  • fullName: Nome completo da empresa.
  • shotName: Nome curto de identificação da empresa.
  • assetType: Enumeration do tipo do ativo
    • STOCK - ação negociada na própria bolsa
    • ADR - ações de outras bolsas negociadas por recibo (identifica também os BDR quando a bolsa for 'B3')
    • REITS - ativos de fundos imobiliários
  • createAt - Data/hora de quando o registro foi criado no sistema
  • updateAt - Data/hora de quando o registro foi atualizado pela última vez

Lançamento das Operações stockOperation

Requisitos

• Deverão ser lançadas (ou importadas) as operações realizadas pelo usuário, como compra, venda, subscrição, doação (donatário ou doador), etc.. Operações compulsórias como bonificações, resgates, mudanças de tickers, incorporações, etc., deverão ser tratadas automaticamente pelo sistema com base em 'conhecimento público' e não lançadas manualmente.
• O sistema deve permitir um lançamento de 'ajuste', tanto para aumentar quanto para decrementar a quantidade de ativos da carteira, talvez para lançar operações que o sistema ainda não contemple.
• Em caso de troca de ticker, incorporação, merge e outras operações em que o ticker troque por algum motivo, o lançamento deve conter a referência para o ticker atual e para o ticker original da operação, para efeitos de rastreabilidade.

Arquitetura

• Campos do stockOperation:
  • idUser: Referência à tabela de user - Para saber de quem é o lançamento
  • idStock: Referência à tabela de stock - Deve sempre estar relacionado com o ticker em que a quantidade atual pertence, mesmo que a operação tenha sido realiza com outro ticker ou stock (casos de merge, incorporação, troca de ticker, etc)
  • idStockOriginal: Referência à tabela de stock - Segundo relacionamento para manter o relacionamento com a Stock original da operação (antes de qualquer migração). Quando não há alterações do ticker em que a operação foi realizada deve ter o mesmo valor de idStock.
  • date: Data em que a operação foi realizada.
  • operation: Enumeração que indica a operação realizada:
    • BUY - Compra
    • SELL - Venda
    • SUBSCRIPTION - Subscrições (mesmo efeito que a compra, mas registra que não há nota de corretagem)
  • quantity - Quantidade de ativos envolvidos na operação
  • grossValue - Valor Bruto (Calculado somente pela quantidade de ativos * seu preço unitário), não considera corretagem, impostos, emolumentos, etc.
  • netValue - Valor Líquido (calculado considerando o valor efetivamente movimentado, incluindo as taxas, emolumentos, etc. - NÃO DEVE INCLUIR OS IMPOSTOS DE RENDA RETIDOS)
  • irrf - Valor do Imposto de Renda retido na fonte nas operações de venda.

UI

Componentes

Toggle Theme

Para trocar o tema entre claro e escuro pode-se incluir o comando:

<button id="theme-toggle" class="btn btn-secondary" onclick="HOGInvest.toggleTheme()">Alternar Tema</button>

que chama o script dentro da biblioteca principal da aplicação hoginvest.js.