🏦 Sistema Financeiro Interno

Plataforma web para gestão financeira centralizada — contas a pagar e receber, conciliação bancária, fluxo de caixa, aprovações e relatórios gerenciais.

📋 Sumário

Visão Geral
Stack Tecnológica
Arquitetura
Estrutura de Pastas
Roadmap de Desenvolvimento
Módulos
Banco de Dados
Autenticação e Permissões
Como Rodar Localmente
Variáveis de Ambiente
Padrões de Código
Testes
Deploy
Time e Contato

Visão Geral

O sistema substitui o controle financeiro em planilhas por uma aplicação centralizada com:

Controle de contas a pagar e receber com workflow de aprovação
Conciliação bancária automática via OFX e PIX
Fluxo de caixa previsto vs. realizado em múltiplos recortes
Relatórios gerenciais exportáveis em PDF e Excel
Auditoria completa de todas as ações financeiras
Suporte a múltiplas empresas / unidades com centros de custo

Estimativa total: ~32 semanas com 2–3 devs fullstack.

Stack Tecnológica

Backend

Camada	Tecnologia
Linguagem	Node.js (TypeScript) ou Python (FastAPI)
Banco de dados	PostgreSQL 15+
ORM	Prisma (Node) ou SQLAlchemy (Python)
Autenticação	JWT + Refresh Token
Upload de arquivos	AWS S3 ou MinIO (self-hosted)
Filas / Jobs	BullMQ (Node) ou Celery (Python)
Cache	Redis
Email	Nodemailer + SMTP ou SendGrid
Parser OFX	Implementação própria ou lib `ofx-parser`

Frontend

Camada	Tecnologia
Framework	React 18+ ou Next.js 14+
Estado global	Zustand ou Redux Toolkit
Requisições	TanStack Query (React Query)
UI	Tailwind CSS + shadcn/ui
Gráficos	Recharts ou Chart.js
Formulários	React Hook Form + Zod
Tabelas	TanStack Table
Exportação	ExcelJS (frontend) + Puppeteer (backend PDF)

Infraestrutura

Camada	Tecnologia
Containerização	Docker + Docker Compose
CI/CD	GitHub Actions
Reverse proxy	Nginx
Monitoramento	Sentry (erros) + Prometheus/Grafana (métricas)

Arquitetura

┌─────────────────────────────────────────────────────────┐
│                        Frontend                         │
│            React / Next.js  ·  Tailwind CSS             │
└─────────────────────┬───────────────────────────────────┘
                      │  REST API (JSON)
┌─────────────────────▼───────────────────────────────────┐
│                      Backend API                        │
│                  Node.js / FastAPI                      │
│                                                         │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐             │
│  │  Auth    │  │ Modules  │  │  Jobs    │             │
│  │  RBAC    │  │  CRUD    │  │  Queue   │             │
│  └──────────┘  └──────────┘  └──────────┘             │
└──────┬──────────────┬──────────────┬────────────────────┘
       │              │              │
┌──────▼──────┐ ┌─────▼──────┐ ┌────▼────┐
│ PostgreSQL  │ │   Redis    │ │   S3    │
│  (dados)    │ │  (cache)   │ │(arquivos│
└─────────────┘ └────────────┘ └─────────┘

A API segue o padrão RESTful com versionamento via path (/api/v1/...). Toda comunicação é autenticada via Bearer Token JWT.

Estrutura de Pastas

sistema-financeiro/
├── backend/
│   ├── src/
│   │   ├── modules/
│   │   │   ├── auth/
│   │   │   ├── cadastros/
│   │   │   │   ├── usuarios/
│   │   │   │   ├── fornecedores/
│   │   │   │   ├── categorias/
│   │   │   │   └── contas-bancarias/
│   │   │   ├── contas-pagar/
│   │   │   ├── contas-receber/
│   │   │   ├── aprovacoes/
│   │   │   ├── fluxo-caixa/
│   │   │   ├── conciliacao/
│   │   │   ├── relatorios/
│   │   │   └── auditoria/
│   │   ├── shared/
│   │   │   ├── database/
│   │   │   ├── storage/
│   │   │   ├── mailer/
│   │   │   ├── queue/
│   │   │   └── middlewares/
│   │   └── main.ts
│   ├── prisma/
│   │   ├── schema.prisma
│   │   └── migrations/
│   ├── tests/
│   └── Dockerfile
│
├── frontend/
│   ├── src/
│   │   ├── app/              # Next.js App Router (ou pages/)
│   │   ├── components/
│   │   │   ├── ui/           # shadcn/ui base components
│   │   │   ├── financeiro/   # componentes de domínio
│   │   │   └── layout/
│   │   ├── hooks/
│   │   ├── lib/
│   │   │   ├── api/          # fetch wrappers
│   │   │   └── utils/
│   │   ├── store/            # estado global
│   │   └── types/
│   └── Dockerfile
│
├── docker-compose.yml
├── docker-compose.prod.yml
├── .env.example
└── README.md

Roadmap de Desenvolvimento

Visão Geral das Fases

Semana:  1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32
         ├───────────────────────────────────────────────────┤
Fase 1   │  FUNDAÇÃO — Cadastros, Pagar, Receber, Dashboard  │
         └───────────────────────┬───────────────────────────┘
                                 ├───────────────────────────────────────────────────┤
Fase 2                           │  PROCESSAMENTO — Fluxo, Aprovações, Conciliação   │
                                 └───────────────────────┬───────────────────────────┘
                                                         ├───────────────────────────────────────────────────┤
Fase 3                                                   │  CONTROLE — Relatórios, Auditoria, Administração  │
                                                         └───────────────────────────────────────────────────┘

Fase 1 — Fundação (Semanas 1–10)

Estabelece a base do sistema. Todos os outros módulos dependem desta fase.

🗂️ Módulo 1: Cadastros Base

Prioridade: Base obrigatória | Estimativa: 2–3 semanas | Dependências: nenhuma

O alicerce do sistema. Deve ser o primeiro a ser implementado.

Funcionalidades:

Usuários internos com perfis de acesso (Admin, Financeiro, Gestor, Diretor, Auditor)
Plano de contas e categorias financeiras (receita, despesa, imposto, folha)
Centros de custo e departamentos
Contas bancárias (banco, agência, conta, tipo)
Empresas e unidades do grupo
Clientes e fornecedores (nome, CNPJ/CPF, contato, banco para pagamento)

Técnico:

CRUD completo com soft delete (deleted_at) em todas as entidades
Auth: JWT com refresh token, blacklist via Redis
RBAC: tabela permissions com granularidade por módulo + ação (create, read, update, delete)
Migrations versionadas com rollback
Seed de dados iniciais para desenvolvimento
Testes unitários nas regras de negócio

POST   /api/v1/auth/login
POST   /api/v1/auth/refresh
GET    /api/v1/usuarios
POST   /api/v1/usuarios
GET    /api/v1/categorias
GET    /api/v1/centros-custo
GET    /api/v1/contas-bancarias
GET    /api/v1/fornecedores
GET    /api/v1/clientes

📤 Módulo 2: Contas a Pagar

Prioridade: Alta | Estimativa: 3–4 semanas | Dependências: Cadastros Base

Funcionalidades:

Lançamento manual de despesas (fornecedor, valor, vencimento, categoria, centro de custo)
Tipos: despesa fixa, variável, imposto, folha de pagamento
Upload de boletos e notas fiscais (PDF/imagem → S3)
Aprovação simples (um nível) para habilitar pagamento
Baixa de pagamento com comprovante anexado
Pagamento parcial com controle de saldo restante
Alertas de vencimento: 3 dias antes, 1 dia antes, no dia, após vencimento

Técnico:

Upload para S3 com validação de tipo e tamanho (max 10MB)
State machine de status: rascunho → pendente → aprovado → pago | cancelado
Cron job diário às 07h para alertas de vencimento (fila BullMQ)
Suporte a parcelamento (gera N registros vinculados por parcelamento_id)
Índices em vencimento, status, fornecedor_id, categoria_id

GET    /api/v1/contas-pagar
POST   /api/v1/contas-pagar
PATCH  /api/v1/contas-pagar/:id/baixar
PATCH  /api/v1/contas-pagar/:id/aprovar
POST   /api/v1/contas-pagar/:id/anexos

💰 Módulo 3: Contas a Receber

Prioridade: Alta | Estimativa: 3–4 semanas | Dependências: Cadastros Base

Funcionalidades:

Lançamentos manuais e avulsos
Recorrência configurável (semanal, mensal, anual) com geração automática
Mensalidades e contratos com valor fixo
Baixa total e parcial de recebimento
Controle de inadimplência com cálculo de juros e mora
Crédito disponível por cliente
Notificação de vencimento para clientes (opcional)

Técnico:

Recorrência: ao criar, gera N registros para o período configurado (ou usa job mensal)
Cálculo de mora: valor × taxa_mora_diaria × dias_atraso
Estado: aberto → recebido_parcial → recebido | cancelado | vencido
Job semanal para marcar como vencido após data de vencimento
View materializada inadimplencia_mv para relatório de inadimplentes

GET    /api/v1/contas-receber
POST   /api/v1/contas-receber
PATCH  /api/v1/contas-receber/:id/baixar
GET    /api/v1/contas-receber/inadimplencia

📊 Módulo 4: Dashboard Interno

Prioridade: Alta | Estimativa: 2 semanas | Dependências: Contas a Pagar, Contas a Receber

Funcionalidades:

Saldo previsto e realizado do dia
Entradas e saídas do mês (total e variação vs. mês anterior)
Contas vencidas e a vencer nos próximos 7 e 30 dias
Resultado mensal (receita − despesa)
Gráfico de barras: entradas × saídas por semana
Filtro por empresa / unidade

Técnico:

Queries pré-agregadas com cache Redis de 1 minuto (invalidado em novos lançamentos)
Endpoint único /api/v1/dashboard/resumo retorna tudo em uma chamada
Frontend usa polling a cada 60s (ou WebSocket se real-time for requisito)
Formatação monetária server-side (BRL, sem cálculo no cliente)

GET    /api/v1/dashboard/resumo?empresa_id=&periodo=mensal
GET    /api/v1/dashboard/grafico-semanal?empresa_id=

Fase 2 — Processamento (Semanas 11–20)

Inteligência do sistema: visão temporal, workflow de aprovação e conciliação automática.

📈 Módulo 5: Fluxo de Caixa

Prioridade: Média | Estimativa: 2–3 semanas | Dependências: Contas a Pagar, Contas a Receber

Funcionalidades:

Previsto vs. realizado nos recortes diário, semanal e mensal
Filtro por conta bancária e centro de custo
Projeção futura com base nos lançamentos agendados
Drill-down por categoria de receita/despesa
Exportação CSV e Excel

Técnico:

Agregações temporais com date_trunc('month', vencimento) no PostgreSQL
Cache por período com chave fluxo:{empresa_id}:{recorte}:{mes} — invalidado em novos lançamentos
Projeção: soma de contas abertas com vencimento futuro + recorrências calculadas
Limite de 24 meses de histórico na query padrão (paginação por período)

GET    /api/v1/fluxo-caixa?recorte=mensal&de=2025-01&ate=2025-12&empresa_id=
GET    /api/v1/fluxo-caixa/projecao?meses=3
GET    /api/v1/fluxo-caixa/exportar?formato=excel

✅ Módulo 6: Aprovações

Prioridade: Média | Estimativa: 2 semanas | Dependências: Cadastros Base, Contas a Pagar

Funcionalidades:

Solicitação de pagamento criada pelo solicitante
Aprovação por gestor (valores médios — limite configurável)
Aprovação por diretoria (valores altos — limite configurável)
Recusa com motivo obrigatório e retorno ao solicitante
Histórico imutável de todas as decisões
Notificação por e-mail em cada transição de estado
Limite de aprovação configurável por perfil (ex: gestor até R$ 10.000)

Técnico:

State machine: solicitado → aguardando_gestor → aguardando_diretoria → aprovado → pago | recusado
Tabela aprovacao_log com usuario_id, acao, motivo, created_at, ip — imutável (sem UPDATE/DELETE)
Roteamento automático por valor: se valor > limite do gestor, pula direto para diretoria
Notificações em fila assíncrona (não bloqueia a resposta da API)

POST   /api/v1/aprovacoes/solicitar
PATCH  /api/v1/aprovacoes/:id/aprovar
PATCH  /api/v1/aprovacoes/:id/recusar
GET    /api/v1/aprovacoes/pendentes
GET    /api/v1/aprovacoes/:id/historico

🔄 Módulo 7: Conciliação Bancária

Prioridade: Média | Estimativa: 3–4 semanas | Dependências: Contas a Pagar, Contas a Receber

O módulo mais complexo da Fase 2. Reserve tempo extra para testes com extratos reais.

Funcionalidades:

Importação de extrato OFX e CSV (múltiplos bancos)
Conciliação automática por correspondência de valor + data ± 2 dias + descrição
Reconhecimento de PIX (chave, E2E ID) e boletos pagos
Marcação manual de divergências com justificativa
Baixa automática dos lançamentos conciliados
Relatório de itens não-conciliados para revisão

Técnico:

Parser OFX: biblioteca ofx-parser ou implementação própria (formato SGML-like)
Match scoring: pontos por valor exato (+40), faixa de data ±2d (+30), similaridade de descrição (+30)
Match com score ≥ 80 → conciliação automática; < 80 → fila de revisão manual
Suporte a múltiplas importações do mesmo extrato (idempotência por fit_id do OFX)
Transação atômica: importar + conciliar + baixar em uma única transação de banco

POST   /api/v1/conciliacao/importar          (multipart/form-data — arquivo OFX/CSV)
GET    /api/v1/conciliacao/pendentes
PATCH  /api/v1/conciliacao/:id/conciliar     (manual)
PATCH  /api/v1/conciliacao/:id/divergencia
GET    /api/v1/conciliacao/relatorio

Fase 3 — Controle e Saída (Semanas 21–32)

Camada de visibilidade: relatórios gerenciais, rastreabilidade e administração.

📋 Módulo 8: Relatórios

Prioridade: Depende das fases anteriores | Estimativa: 3–4 semanas | Dependências: Fluxo de Caixa, Conciliação

Funcionalidades:

Recebimentos e pagamentos por período
Despesas por setor e fornecedor
Fluxo de caixa consolidado
Resultado mensal com comparativo
Fornecedores pagos e pendentes
Exportação PDF (layout A4) e Excel com filtros

Técnico:

PDF: Puppeteer headless renderizando template HTML → PDF (melhor controle visual)
Excel: ExcelJS com formatação de células, totais e cabeçalhos fixos
Filtros disponíveis: data de/até, empresa, categoria, centro de custo, fornecedor
Geração assíncrona para relatórios grandes: endpoint retorna job_id, frontend faz polling
Cache de relatórios gerados por 1h (chave baseada nos filtros aplicados)

POST   /api/v1/relatorios/gerar           (body: tipo, filtros)
GET    /api/v1/relatorios/status/:job_id
GET    /api/v1/relatorios/download/:job_id
GET    /api/v1/relatorios/historico

🔍 Módulo 9: Auditoria

Prioridade: Depende das fases anteriores | Estimativa: 2 semanas | Dependências: Aprovações, Conciliação

Funcionalidades:

Log de acesso: login, logout, IP, horário, user agent
Registro de quem criou, editou, aprovou ou excluiu cada registro
Histórico imutável de valores anteriores e posteriores (JSON diff)
Busca por usuário, período, tipo de entidade e ação
Exportação de logs para compliance (CSV)
Permissão exclusiva de leitura para perfil Auditor

Técnico:

Tabela audit_log: id, usuario_id, acao, entidade, entidade_id, valor_antes (JSONB), valor_depois (JSONB), ip, created_at
Populada via middleware / hooks do ORM — nunca por chamada manual
Imutável: sem UPDATE ou DELETE na tabela (constraint via trigger no PostgreSQL)
Índices compostos em (entidade, entidade_id), (usuario_id, created_at), (created_at)
Retenção: logs com mais de 5 anos arquivados em S3 e removidos do banco (job anual)

GET    /api/v1/auditoria?usuario_id=&entidade=&acao=&de=&ate=
GET    /api/v1/auditoria/:entidade/:entidade_id   (histórico de um registro)
GET    /api/v1/auditoria/exportar

⚙️ Módulo 10: Administração

Prioridade: Base | Estimativa: 1–2 semanas | Dependências: Cadastros Base

Funcionalidades:

Gestão de perfis e permissões por módulo e ação (CRUD granular)
Configurações financeiras: moeda padrão, taxa de mora, tolerância de conciliação
Parâmetros de aprovação: limites de valor por nível
Visualização de sessões ativas e revogação remota
Configuração de backup automático e retenção

Técnico:

RBAC persistido em banco: tabelas perfis, permissoes, perfil_permissoes
Interface de configuração in-app (sem editar arquivos de config)
Backup: pg_dump agendado via cron, upload para S3 com retenção de 30 dias
Revogação de sessão via blacklist de tokens no Redis

Banco de Dados

Tabelas principais

-- Base
usuarios              (id, nome, email, senha_hash, perfil_id, empresa_id, ativo, created_at, deleted_at)
perfis                (id, nome, descricao)
permissoes            (id, perfil_id, modulo, acao)
empresas              (id, nome, cnpj, created_at)
centros_custo         (id, empresa_id, nome, codigo)
categorias            (id, empresa_id, nome, tipo [receita|despesa|imposto|folha])
contas_bancarias      (id, empresa_id, banco, agencia, conta, tipo)
clientes              (id, empresa_id, nome, cpf_cnpj, email, telefone)
fornecedores          (id, empresa_id, nome, cpf_cnpj, dados_bancarios, deleted_at)

-- Financeiro
contas_pagar          (id, empresa_id, fornecedor_id, categoria_id, centro_custo_id, valor, vencimento,
                       status, descricao, parcelamento_id, parcela_num, created_by, updated_at)
contas_receber        (id, empresa_id, cliente_id, categoria_id, valor, vencimento,
                       status, descricao, recorrencia_id, created_by)
anexos                (id, entidade, entidade_id, nome, url_s3, mime_type, tamanho, created_by, created_at)

-- Aprovações
aprovacoes            (id, conta_pagar_id, solicitante_id, status, valor, created_at)
aprovacao_log         (id, aprovacao_id, usuario_id, acao, motivo, ip, created_at)  -- imutável

-- Conciliação
extrato_importado     (id, conta_bancaria_id, fit_id, data, valor, descricao, importado_em)
conciliacao           (id, extrato_id, conta_pagar_id, conta_receber_id, score, status, created_at)

-- Auditoria
audit_log             (id, usuario_id, acao, entidade, entidade_id, valor_antes, valor_depois, ip, created_at)
sessoes               (id, usuario_id, token_hash, ip, user_agent, expires_at, revogado_em)

Convenções

Todos os IDs são UUID v4
Datas sempre em TIMESTAMPTZ (fuso horário do servidor: America/Sao_Paulo)
Valores monetários em NUMERIC(15,2) — nunca FLOAT
Soft delete via deleted_at TIMESTAMPTZ NULL (registros excluídos mantêm histórico)
Toda tabela tem created_at e updated_at populados automaticamente via trigger

Autenticação e Permissões

Fluxo de autenticação

1. POST /auth/login → retorna access_token (15min) + refresh_token (7d)
2. Toda requisição envia: Authorization: Bearer <access_token>
3. Ao expirar: POST /auth/refresh com refresh_token → novo par de tokens
4. Logout: adiciona refresh_token na blacklist (Redis, TTL de 7d)

Perfis disponíveis

Perfil	Contas a Pagar	Contas a Receber	Aprovações	Relatórios	Auditoria	Admin
Admin	✅ Total	✅ Total	✅ Total	✅ Total	✅ Total	✅ Total
Diretor	✅ Total	✅ Total	✅ Aprovar	✅ Total	👁️ Leitura	❌
Gestor	✅ Total	✅ Total	✅ Aprovar (limite)	✅ Total	❌	❌
Financeiro	✅ Total	✅ Total	➡️ Solicitar	✅ Total	❌	❌
Auditor	👁️ Leitura	👁️ Leitura	👁️ Leitura	✅ Total	✅ Total	❌

Como Rodar Localmente

Pré-requisitos

Node.js 20+ (ou Python 3.11+)
Docker e Docker Compose
Git

Passos

# 1. Clonar o repositório
git clone https://github.com/sua-org/sistema-financeiro.git
cd sistema-financeiro

# 2. Copiar variáveis de ambiente
cp .env.example .env
# editar .env com suas configurações locais

# 3. Subir serviços de infraestrutura
docker compose up -d postgres redis minio

# 4. Backend
cd backend
npm install
npx prisma migrate dev     # aplica migrations
npx prisma db seed         # dados iniciais
npm run dev                # http://localhost:3001

# 5. Frontend (novo terminal)
cd frontend
npm install
npm run dev                # http://localhost:3000

Acessos locais

Serviço	URL	Credenciais padrão
Frontend	http://localhost:3000	—
API	http://localhost:3001	—
API Docs	http://localhost:3001/docs	—
PostgreSQL	localhost:5432	ver `.env`
Redis	localhost:6379	—
MinIO Console	http://localhost:9001	minioadmin / minioadmin

Variáveis de Ambiente

# Banco de dados
DATABASE_URL=postgresql://user:password@localhost:5432/financeiro

# Redis
REDIS_URL=redis://localhost:6379

# JWT
JWT_SECRET=sua-chave-secreta-aqui
JWT_EXPIRES_IN=15m
JWT_REFRESH_EXPIRES_IN=7d

# Storage (S3 / MinIO)
STORAGE_ENDPOINT=http://localhost:9000
STORAGE_BUCKET=financeiro-arquivos
STORAGE_ACCESS_KEY=minioadmin
STORAGE_SECRET_KEY=minioadmin

# Email
SMTP_HOST=smtp.mailtrap.io
SMTP_PORT=587
SMTP_USER=
SMTP_PASS=
EMAIL_FROM=noreply@sistema-financeiro.com.br

# App
NODE_ENV=development
PORT=3001
FRONTEND_URL=http://localhost:3000

# Aprovações (limites em reais)
LIMITE_APROVACAO_GESTOR=10000
LIMITE_APROVACAO_DIRETOR=100000

Padrões de Código

Commits (Conventional Commits)

feat(contas-pagar): adiciona suporte a parcelamento
fix(auth): corrige renovação de token expirado
refactor(conciliacao): extrai lógica de match para service
docs(readme): atualiza endpoints da fase 2
test(aprovacoes): adiciona testes de state machine

Branches

main          → produção (proteção: require PR + review)
develop       → integração contínua
feat/nome     → novas funcionalidades
fix/nome      → correções
release/x.y   → preparação de release

Convenções de API

Recursos no plural e em kebab-case: /contas-pagar, /centros-custo
Listagens com paginação: ?page=1&limit=20
Filtros via query string: ?status=aprovado&de=2025-01-01
Erros padronizados:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Valor não pode ser zero",
    "field": "valor"
  }
}

Testes

# Rodar todos os testes
npm test

# Apenas unitários
npm run test:unit

# Integração (requer banco de dados)
npm run test:integration

# Cobertura
npm run test:coverage

Estratégia de testes

Tipo	O que cobre	Ferramenta
Unitário	Rules de negócio, state machines, cálculos financeiros	Jest / Pytest
Integração	Endpoints da API com banco real	Supertest / httpx
E2E	Fluxos críticos (login → criar conta → aprovar → baixar)	Playwright

Cobertura mínima exigida: 80% nos módulos financeiros (pagar, receber, aprovações).

Deploy

Produção

# Build das imagens
docker compose -f docker-compose.prod.yml build

# Aplicar migrations
docker compose -f docker-compose.prod.yml run --rm backend npx prisma migrate deploy

# Subir
docker compose -f docker-compose.prod.yml up -d

CI/CD (GitHub Actions)

push → develop:
  └─ testes unitários + integração
  └─ lint e type-check
  └─ deploy automático em staging

pull_request → main:
  └─ testes completos (incluindo E2E)
  └─ revisão obrigatória de 1 dev

merge → main:
  └─ deploy em produção com aprovação manual
  └─ migrations aplicadas automaticamente
  └─ smoke test pós-deploy

Time e Contato

Papel	Responsabilidade
Tech Lead / Backend	Arquitetura, banco de dados, módulos de negócio
Dev Frontend	UI, componentes, integração com API
Dev Fullstack (opcional)	Suporte em ambas as frentes, relatórios, deploy

Dúvidas sobre o sistema: abrir uma issue com a label correspondente ao módulo (módulo/contas-pagar, módulo/conciliacao, etc.)

Última atualização: Junho de 2025

Name		Name	Last commit message	Last commit date
README.md		README.md
index.html		index.html

Latest commit

History

Folders and files

Repository files navigation

🏦 Sistema Financeiro Interno

📋 Sumário

Visão Geral

Stack Tecnológica

Backend

Frontend

Infraestrutura

Arquitetura

Estrutura de Pastas

Roadmap de Desenvolvimento

Visão Geral das Fases

Fase 1 — Fundação (Semanas 1–10)

🗂️ Módulo 1: Cadastros Base

📤 Módulo 2: Contas a Pagar

💰 Módulo 3: Contas a Receber

📊 Módulo 4: Dashboard Interno

Fase 2 — Processamento (Semanas 11–20)

📈 Módulo 5: Fluxo de Caixa

✅ Módulo 6: Aprovações

🔄 Módulo 7: Conciliação Bancária

Fase 3 — Controle e Saída (Semanas 21–32)

📋 Módulo 8: Relatórios

🔍 Módulo 9: Auditoria

⚙️ Módulo 10: Administração

Banco de Dados

Tabelas principais

Convenções

Autenticação e Permissões

Fluxo de autenticação

Perfis disponíveis

Como Rodar Localmente

Pré-requisitos

Passos

Acessos locais

Variáveis de Ambiente

Padrões de Código

Commits (Conventional Commits)

Branches

Convenções de API

Testes

Estratégia de testes

Deploy

Produção

CI/CD (GitHub Actions)

Time e Contato

About

Topics

Resources

Stars

Watchers

Forks

Contributors

Languages