Adiciona o frontend Next.js em frontend/ (setup, design system, autenticação/tema, layout/navegação, área master, área tenant completa: clientes, produtos, vendas, recebimentos, whatsapp, e-mail, alertas, equipe e perfil). Estende o backend de forma aditiva e autorizada: cookie httpOnly para refresh token (Etapa 13) e CRUD de equipe + edição de perfil do tenant (Etapa 18, módulo src/modules/equipe/ novo e PUT /tenant/perfil). Detalhes completos em Etapas/V2/*. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3.8 KiB
3.8 KiB
Etapa 16 — Área Tenant: Dashboard, Clientes e Produtos
Contexto do projeto
Continuação do frontend do SeConectai Vendas. Já existem: setup,
design system, autenticação/tema, layout/navegação e a área master
completa. Esta etapa inicia as telas de negócio da área /app (o
painel que os seus clientes usam), consumindo os endpoints das Etapas 5
e 6 (parte de dashboard) do backend.
Objetivo desta etapa
Dashboard inicial do tenant, e os cadastros de clientes (customers) e produtos/serviços — a base de dados que toda venda vai referenciar.
Tarefas
-
/app/dashboard- Cards de resumo: total recebido no mês, total a receber (pendente+atrasado, com o atrasado destacado visualmente, ex: cor de alerta), quantidade de vendas no mês.
- Gráfico de resumo semanal/mensal de vendas (Recharts), consumindo as views de dashboard do backend.
- Lista das próximas parcelas a vencer (top 5–10), com link direto
para
/app/recebimentos. - Grid responsivo: 2–3 colunas no desktop, coluna única no mobile, gráfico sempre com largura total.
-
/app/clientes- Listagem (
Table, vira cards no mobile) com busca por nome/documento, filtro por ativo/inativo, paginação. - Colunas/cards mostrando: razão social, documento, telefone/e-mail, status.
- Botão "Novo cliente" →
/app/clientes/novo.
- Listagem (
-
/app/clientes/novoe/app/clientes/:id- Formulário completo: dados cadastrais (razão social, nome fantasia, documento, e-mail, telefone/WhatsApp, endereço, cidade, UF, observações).
- No detalhe (
:id), usarTabs: Dados cadastrais (editável), Contatos (CRUD aninhado — lista decustomer_contactscom indicação clara de qual é o principal e ação de marcar principal), Histórico de vendas (lista somente leitura das vendas desse cliente, com link para o detalhe de cada venda — mesmo que a tela de vendas só seja construída na próxima etapa, deixar o link já apontando para a rota correta). - Ação de desativar (soft delete) com confirmação, mantendo o registro visível no histórico.
-
/app/produtos- Listagem com filtro por tipo (
produto/servico) e por ativo, busca por nome/SKU. - Colunas/cards: nome, tipo (
StatusPillou badge simples), valor de venda, SKU, status.
- Listagem com filtro por tipo (
-
/app/produtos/novoe/app/produtos/:id- Formulário: tipo (produto/serviço), nome, descrição, SKU (opcional, validar unicidade — mostrar erro claro se a API retornar conflito), valor de venda, valor de custo (opcional), unidade, flag "recorrente".
- Ação de desativar (soft delete) com confirmação.
-
Validação e limites de plano
- Ao tentar criar cliente ou produto além do limite do plano do tenant, a API retorna erro — o frontend deve mostrar essa mensagem de forma clara (ex: banner ou toast explicando o limite atingido), não travar silenciosamente o formulário.
Critérios de aceite
- Dashboard do tenant mostra números batendo com dados de teste conhecidos
- CRUD completo de clientes funciona, incluindo contatos aninhados e regra de contato principal único
- Histórico de vendas no detalhe do cliente lista corretamente (mesmo que a tela de destino ainda não exista até a próxima etapa)
- CRUD completo de produtos/serviços funciona, incluindo validação de SKU duplicado
- Tentar exceder limite do plano (clientes ou produtos) mostra mensagem clara ao usuário
- Desativar cliente/produto pede confirmação e reflete corretamente na listagem (sai da lista de ativos, mas seria visível com filtro "inativos")
- Todas as listagens com busca, filtro, paginação e estados de loading/vazio
- Todas as telas testadas em 375px, 768px e 1280px