- Tabela sar.config_empresa (logo em data URL por empresa matriz) com
migration idempotente, espelho no schema SQL e GRANT no provision
- PUT /catalog/company/logo (gerente/admin) e logoBase64 no GET
/catalog/company - vale para a impressao de todos os representantes
- Nova tela /ger/config "Configuracoes" com upload/preview/remocao do
logo (PNG/JPG/WebP ate 500KB)
- Cabecalho da impressao redesenhado: logo a esquerda, dados da empresa
condensados em 3 linhas, numero/status/data compactos a direita -
ocupa ~metade da altura anterior no A4
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Nova tabela sar.regras_desconto (grupo, subgrupo, representante, % e
vigencia; campos nulos = todos) com migration idempotente, espelho no
sar-erp-schema.sql e GRANT no provision-client
- CRUD manager-only em /politicas/regras + aba "Regras de Desconto" na
tela de Politicas Comerciais (selects com nomes de rep/grupo/subgrupo
via /politicas/grupos-produto)
- GET /politicas/regras/vigentes (rep ve so as que o alcancam) e
GET /politicas/promocoes/vigentes para o catalogo
- Regra vigente pre-aplica o desconto no carrinho do novo pedido
- Selos "Promocao"/"Cond. especial" na busca de produto, catalogo do
pedido e pagina de catalogo; secao "Condicoes Comerciais" no modal de
detalhe do produto (descricao, % e validade)
- Empty imageStyle deprecado -> styles.image no carrinho
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Representante abre chamado a partir de um pedido e conversa com a empresa
por thread de mensagens; o gerente responde e resolve.
- API: `SacModule` com 5 rotas do rep (listar, detalhe, criar, responder,
cancelar) e 4 da empresa (/ger/chamados: listar, detalhe, responder,
resolver). Escopo do rep e por cod_vendedor; o da empresa, por id_empresa.
- Modelos `Chamado` + `ChamadoMensagem` e migrations correspondentes.
- O chamado pode referenciar tanto um pedido nascido no SAR (id_pedido +
num_ped_sar) quanto um pedido historico do ERP (num_ped_erp) — dai
id_pedido e num_ped_sar serem nullable. `nome_cliente` fica
desnormalizado para evitar join em toda listagem.
- Web: `ChamadosPage` (rep), `GerChamadosPage` (gerente) e
`AbrirChamadoModal`, acessivel tambem pelo detalhe do pedido. Entradas
"SAC" no menu do rep e do gerente.
- `useOrderErpConsulta` ganha flag `enabled` para a busca de pedido ERP so
disparar quando o modal esta aberto.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Kanban de oportunidades por etapa (lead, proposta, negociacao, ganho,
perdido) com CRUD completo.
- API: `FunilModule` com GET/POST/PATCH/DELETE em /funil, escopado por
id_empresa + cod_vendedor.
- Modelo `Oportunidade` + migration `sar.oportunidades`. Uma oportunidade
referencia um cliente do ERP (id_cliente) ou e um prospect livre
(nome_prospect / empresa_prospect).
- Contrato Zod compartilhado em `funil.contract.ts`.
- Web: `FunilPage` com colunas por etapa, entrada no menu do rep e rota
/funil.
Nota: a UI ainda nao expoe seletor de cliente, entao toda oportunidade
criada pela tela nasce como prospect livre; `idCliente` e `idPedido` ja
sao suportados no backend, mas ficam inalcancaveis pela interface.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Revoga o ADR 0006. O isolamento multi-tenant deixa de ser um banco por
workspace e passa a ser o schema `sar` dentro do proprio banco ERP do
cliente, com `id_empresa` discriminando o tenant em todas as tabelas.
Provisionamento:
- `provision-client.ts` substitui `provision-workspace.ts`. Nao cria mais
banco: aplica schema + views + triggers num banco ERP ja existente.
Trata o encoding LATIN1 dos bancos ERP via `toLatinSafe()`.
- `sar-erp-schema.sql` vira a fonte unica: absorve as views que estavam em
`sarweb_views.sql` e passa a conter tambem `sar.chamados` /
`sar.chamado_mensagens`, que so existiam via migration.
Correcoes necessarias para o provisionamento rodar ponta a ponta:
- `migrate deploy` abortava com P3005, porque o schema SQL roda antes do
Prisma e o schema `sar` nunca esta vazio. O script agora detecta banco
pre-existente e faz o baseline sozinho.
- `_prisma_migrations` ia parar no schema `public` do ERP do cliente; a URL
de migracao agora leva `?schema=sar`.
- `sar.pedidos` nao tinha `end_entrega`, coluna que o schema.prisma ja
declarava desde a feature de endereco de entrega, e que derrubava
GET /orders com 500. Migration adicionada.
- `vw_sitpedido` se perdeu junto com `sarweb_views.sql` e e usada pela
consulta de pedidos ERP. Restaurada.
Remove o seed de dados demo e os fallbacks de DATABASE_URL hardcoded: sem
a variavel configurada a API agora falha explicitamente, em vez de apontar
silenciosamente para um banco de desenvolvimento inexistente.
Verificado ponta a ponta contra um banco ERP real: schema aplicado, 13
tabelas + 20 views, migrations registradas, e segunda execucao idempotente.
BREAKING CHANGE: DATABASE_URL passa a ser obrigatoria. O comando de
provisionamento muda para `pnpm client:provision --host <host> --db <banco>`
(rename efetivado no commit de dependencias).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Triggers SAR→ERP (scripts/sar-triggers.sql):
- trg_pedido_aprovado: ao aprovar (situa 1→2) em sar.pedidos, replica
automaticamente em sig.pedidos + sig.peditens e grava erp_id_pedido
- trg_cliente_novo: INSERT em sar.clientes_novos replica em sig.corrent
com todos os campos obrigatórios; grava id_corrent_erp e flag sincronizado
- Corrige trigger tsvectorupdate do ERP para PG 18 (bpchar→text cast)
- Adiciona coluna erp_id_pedido em sar.pedidos e tabela sar.clientes_novos
Migrations Prisma:
- Remove 5 migrations obsoletas com nomes PascalCase (Order, Client, etc.)
que não batiam com os @@map snake_case do schema atual
- Cria baseline 20260624000000_init_baseline apontando para estado correto
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
FR-6.1/6.2: Sandra recebe push quando pedido entra em pending_approval;
Rafael recebe quando pedido é aprovado ou recusado. Service worker registrado
em background (PWA-ready via public/sw.js).
FR-6.3: Badge na Topbar busca GET /notifications/pending-count (supervisores
veem count de pending_approval; reps veem 0). Intervalo de 30s.
FR-6.4: Botão Compartilhar no OrderDetailPage para pedidos approved/invoiced
(apenas reps). Usa navigator.share() com texto formatado para WhatsApp.
Infra: modelo PushSubscription (Prisma), NotificationsModule (subscribe/
unsubscribe/pending-count + PushService VAPID), VAPID keys em .env,
integração no OrdersService (create → supervisores, approve/reject → repId).
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
GET /dashboard/rep retorna meta mensal, comissão (fixa + FLEX), clientes
inativos >30 dias e pedidos dos últimos 7 dias. RepTarget model com migration.
RafaelPainel conectado à API real via useRepDashboard().
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
