# Solicitação - DasNutri ## 1) Preço de Atacado na Gôndola (Etiqueta) ### Contexto Hoje a etiqueta exibe apenas o preço de varejo. Necessário incluir **preço de atacado** (ou faixa/quantidade mínima) e ajustar o **layout**. ### Escopo / O que será feito - **Backend** - Expor campo(s) de atacado no endpoint de etiquetas (ex.: `GET /api/etiquetas/lote?...`). - Se não houver estrutura: criar **tabela `produto_preco_atacado`** (produtoId, qtdeMin, preco, vigenciaIni/Fim, lojaId opcional). - Regras de negócio: escolher o nível (empresa/loja), vigência, e fallback para varejo se não houver atacado válido. - **Frontend / Serviço de Etiquetas** - Adicionar **variável de template** (ex.: `${precoAtacado}`, `${qtdeMinAtacado}`). - Criar **novo layout** (ZPL/PDF) com campo “**ATACADO X por R$ Y**”. - Visualização/preview no backoffice antes de imprimir (thumb em PDF). - **Integrações/DevOps** - Feature flag “**etiqueta.atacado**” por loja. - Migração de dados de atacado (se necessário). ### Critérios de conclusão (aceite) - Etiqueta mostra claramente **preço varejo** e **preço atacado + quantidade mínima**. - Layout aprovado (tamanho, legibilidade, contraste). - Geração em **lote** e **unitária** funcionando. - Testes: produtos **com e sem** preço atacado; validade expirada; múltiplas lojas. ### Riscos/Dependências - Dados de atacado indisponíveis → exigir **carga inicial**. - Impressoras com memória limitada (ZPL antigos) → otimizar template. ### Estimativa de Esforço (22h) - Backend: **10h** (modelo + endpoint + regras + migração simples) - Frontend/Serviço Etiquetas: **8h** (template, preview, parametrização) - QA/Testes: **3h** - Docs/Alinhamentos: **1h** --- ## 2) Identificação de Vendedor no Self-Checkout ### Contexto Não há mecanismo para identificar o vendedor na venda em self-checkout. Precisa permitir **associação opcional** do vendedor à transação. ### Escopo / O que será feito - **Backend** - Novo endpoint: `POST /api/selfcheckout/sessao/vendedor` (define/atualiza vendedor da sessão). - Validações: vendedor ativo, lotação/loja válida, permissões. - Persistir `vendedorId` no **cabeçalho da venda** e enviar no fluxo fiscal (quando aplicável). - **Frontend (Self-Checkout)** - **Fluxo de leitura do vendedor**: - Modal de identificação no início da sessão **ou** botão “Vendedor” fixo. - Opções: **leitura de código** (ID/QR/CPF) ou busca por nome com autocomplete. - Sinalização visual quando houver vendedor selecionado; opção **trocar/limpar**. - **Relatórios/Backoffice** - Expor `vendedorId` em consulta de vendas (lista/detalhe). - **Segurança/Telemetria** - Auditoria: quem definiu/alterou o vendedor e quando. ### Critérios de conclusão (aceite) - Venda finalizada contém `vendedorId`. - Alterar/limpar vendedor antes do fechamento funciona. - Relatório/consulta exibe vendedor por venda. - UX: fluxo não aumenta fricção do cliente (tempo de passagem). ### Riscos/Dependências - Variação de hardware (leitor de código) — padronizar eventos. - Políticas de comissionamento (fora do escopo, mas contempladas no dado). ### Estimativa de Esforço (20h) - Backend: **8h** (endpoints + persistência + auditoria mínima) - Frontend: **9h** (UI/fluxo + scanner + estados + acessibilidade) - QA/Testes: **2h** - Docs/Alinhamentos: **1h** --- ## 3) Exibição de Imagem do Produto no Self-Checkout ### Contexto Funcionalidade não existente. Requer **servir imagens** com boa performance e **alterar UI** do self-checkout para exibir miniatura/thumbnail durante a compra. ### Escopo / O que será feito - **Backend** - Novo serviço/rota de mídia: `GET /api/produtos/{id}/imagem` retornando URL assinada ou CDN pública. - Se necessário, **processamento de imagens** (thumb 256px/512px, WebP/JPEG) e metadados (hash/etag). - Expandir `GET /api/produtos/{gtin}` para incluir `imageUrl`, `imageLastModified`. - **Cache-Control** e ETag. Rate-limit básico. - **Frontend (Self-Checkout)** - Alterar **card do item** para exibir thumbnail (fallback placeholder). - **Pré-carregamento** de imagem após leitura do código de barras. - Estratégias de cache no cliente (IndexedDB/CacheStorage quando PWA). - Tratamento de rede lenta (mostrar skeleton/loading). - **Backoffice** - Campo para **upload/gestão** de imagem (mínimo viável) **ou** documentar fonte externa. - **Observabilidade** - Métricas: taxa de acerto de cache, latência de imagem, % itens sem imagem. ### Critérios de conclusão (aceite) - Para itens com imagem, thumbnail aparece em ≤ **2,5s** em rede normal. - Sem imagem → placeholder consistente. - Queda de rede não trava fluxo de vendas. - Telemetria coletada e visível (painel básico). ### Riscos/Dependências - Volume e tamanho de imagens (custo/banda). - Direitos de uso de imagens (responsabilidade do cliente ou catálogo proprietário). ### Estimativa de Esforço (38h) - Backend: **16h** (serving, thumbs, cache, headers, ampliação de contrato) - Frontend: **18h** (UI, estados, cache offline, loading, testes manuais em dispositivo) - QA/Testes: **3h** - Docs/Alinhamentos: **1h** --- ## 4) Resumo das Estimativas (Total 80h)
FuncionalidadeBackendFrontendQA/TestesDocs/Alinh.Total
1) Preço atacado na gôndola10h8h3h1h**22h**
2) Vendedor no self-checkout8h9h2h1h**20h**
3) Imagem no self-checkout16h18h3h1h**38h**
**Total****34h****35h****8h****3h****80h**
> Observação: as horas de QA incluem roteiro de teste manual e evidências. Se for desejado teste automatizado (e2e/UI), acrescente ~20–30% no item 2 e 3.