Apontamentos do time de negócio organizados item a item: o que foi pedido, o que entendemos, como a tela está hoje (verificado no código) e o que muda — campo a campo. Nada foi alterado nos protótipos ainda.
Exatamente como vieram no e-mail, com quem levantou e quem respondeu. Clique em qualquer ponto para ir ao detalhe da alteração.
Os originais foram preservados. Cada tela ganhou uma cópia -rev1 com os ajustes. 98 mudanças no total, verificadas no código por um revisor independente.
Contrato SAP + código do produto · número do protocolo ao salvar · “Semana desejada” removida · CPF/CNPJ e IE sob o cooperado · modal de contratos (busca ampliada, SAP, IE removida) · cooperado (IE + endereço, busca por IE/cidade) · cadastro com os 4 campos · 3 casas decimais · texto do modal corrigido · selo “Em cadastro”
2ª linha do contrato removida (CNPJ, IE, preço, vigência) · dados do COOPERADO/PROTOCOLO no lugar (nome, CNPJ/CPF, IE, cidade/UF, valor unitário do protocolo, nº NF) · Recebedor = Cooperado · Contrato SAP · 3 casas decimais
Contrato SAP · Recebedor da mercadoria · nome do Ship to · CNPJ e IE rotulados como do Ship to · modal de contratos (busca por CNPJ/CPF, SAP e cidade) · 3 casas decimais
Descrição da filial do cliente (código · descrição) · coluna Contrato SAP · 3 casas decimais em saldos e quantidades
Coluna Roteiro de Entrega · 3 casas decimais · colunas de totais mantidas como estão (decisão da Alessandra: ficam só no Excel)
Pontos que não dá para resolver sozinho: ou o e-mail se contradiz, ou falta informação. Levar nesta ordem para a próxima conversa com o PO.
O bloco 2 (Selecionar Contratos) manda retirar a informação de IE. O bloco 11 (Agendar Contratos Normais) define que CNPJ/CPF e IE devem ser do Ship to. No código é a mesma linha do mesmo componente — não dá para executar os dois.
Encaminhamento: Leitura provável (a confirmar): o bloco 2 se refere ao modal em Criar Protocolo (print da Inara) e o bloco 11 ao contexto de Agendar Contratos Normais. Se for isso, remove-se a IE em Criar Protocolo e mantém-se a IE (do Ship to) em Agendar Contratos Normais.
O menu do portal aponta para agendar-contrato-normal.html, mas a documentação do projeto trata a v5 como versão final. Os dois têm o mesmo modal, com código idêntico.
Encaminhamento: Se mexermos só na v5, a alteração não aparece para quem abre pelo menu. Precisamos eleger um canônico (e apontar o menu para ele) antes de executar.
O e-mail pede “trazer o número do Contrato SAP” no bloco GERAL — logo, vale para todas as telas. Não há definição de formato nem de como conviverá com o identificador Q- exibido hoje.
Encaminhamento: Tratar como um item transversal (TR-01) e definir posicionamento + máscara de uma vez, para as telas não ficarem divergentes entre si.
A tela já mostra a filial de forma descritiva. Não está claro se o pedido é renomear/ajustar o que existe ou acrescentar um campo novo (ex.: código + descrição).
Encaminhamento: Confirmar com a Inara qual das duas leituras é a correta antes de mexer.
Ficou decidido reutilizar o cadastro atual do MD e trazer o Master Data para validar os obrigatórios — mas não temos a tela nem a lista.
Encaminhamento: Obter print/link da tela atual e a lista de campos obrigatórios antes de ajustar o formulário do protótipo.
“Temos status de acompanhamento, caso o cooperado apareça em tela antes de concluir?” — @Victor Dias e @Luiz Ribas. Já está definido que o cooperado aparece em andamento mas não pode ser selecionado para criar protocolo.
Encaminhamento: Proposta de UX a validar: exibir o cooperado com selo “Em cadastro”, desabilitado para seleção, com tooltip explicando que ficará disponível ao concluir.
Cada item traz o pedido original, o entendimento, o estado atual verificado no código e a mudança proposta com os campos afetados.
“Trazer Número do Contrato SAP” — listado no bloco GERAL do e-mail, portanto transversal a todas as telas.
Exibir o número do contrato no SAP em todas as telas que hoje mostram apenas o número Q- (cotação). Deve ser tratado como um item único, não como quatro itens de tela isolados.
Zero ocorrências de “SAP” em qualquer protótipo. Todas as telas exibem apenas o identificador Q- (ex.: Q-20303).
grep -i sap em DEV/*.html → 0 ocorrências.Definir com o PO: (a) o SAP convive com o Q- ou substitui na exibição principal; (b) qual a máscara (ex.: 10 dígitos). Depois aplicar o mesmo padrão em todas as telas listadas, de uma só vez, para não gerar inconsistência.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Número do Contrato SAP | incluir | SAP | Consolida G1-01, G2-02 e G5-04, que hoje propõem posicionamentos divergentes. |
"Sempre deixar 3 casas decimais em TODOS os campos de quantidades, para termos todos os ambientes no mesmo formato." (Alessandra) — Impacto declarado no apontamento: saldo, volume desejado, volume total, quantidades em relatórios, modais e rodapés.
Padronizar a formatação de exibição e de entrada de TODA quantidade (tonelada) em 3 casas decimais, em tela, modais e rodapés/totalizadores, alinhando ao formato do SAP. Valores monetários (R$) não foram citados e permanecem em 2 casas.
O protótipo NÃO usa 3 casas em nenhum campo de quantidade. Há três padrões conflitantes hoje: (a) 2 casas fixas; (b) formatação padrão pt-BR sem casas forçadas (inteiro quando o valor é inteiro); (c) inteiro forçado com 0 casas. Massas de dados de saldo também estão gravadas com 2 casas.
criar-protocolo.html:5955 `statVolume ... toLocaleString('pt-BR', {minimumFractionDigits: 2, maximumFractionDigits: 2})` e :6788 `<span>Volume total</span><strong>${totalVolume.toLocaleString("pt-BR", {minimumFractionDigits: 2, maximumFractionDigits: 2})} t</strong>` (2 casas). agendar-contrato-normal.html:5123 e :6014 `totalVolume.toLocaleString("pt-BR")` (sem casas forçadas). agendar-protocolo.html:2498 e :2600 idem. relatorio-status-agendamento.html:3303 `return Number(n).toLocaleString("pt-BR", { maximumFractionDigits: 0 });` e :3308 `fmtDiff ... maximumFractionDigits: 0` (ZERO casas). relatorio-protocolos.html:3873 `${p.saldo.toLocaleString("pt-BR")}<span class="unit">t</span>`, :3886/:3920 `Máximo ${p.saldo.toLocaleString("pt-BR")} t (saldo disponível)`, :3658 `Só pode reduzir · mínimo ${minVol.toLocaleString("pt-BR")} t (qtd. agendada)`, :2798/:2931/:2970/:3047 células numéricas com `toLocaleString("pt-BR")`. Dados-fonte com 2 casas: agendar-protocolo.html:1906 `saldo: "1.500,00"`, :1944 `saldo: "203,13"`, :1963 `saldo: "4,64"`, :2001 `saldo: "32,00"`; criar-protocolo.html:5543 e agendar-contrato-normal.html:4766 `saldo: "1.000,00"`. Inputs numéricos com step incompatível: relatorio-status-agendamento.html:4165 `<input type="number" id="rsaEditQty" min="0" step="0.1" />`, manutencao-protocolos.html:1241 `<input type="number" id="np_volume" ... step="0.01" />`, manutencao-protocolo-detalhe.html:1866/1869 `<input type="number" step="0.01" ...>`. Formatador genérico de volume sem casas: manutencao-protocolo-detalhe.html:1721 `function fmtVolume(v) { ... Number(v).toLocaleString("pt-BR") + " t"; }` e :1714 `return Number(v).toLocaleString("pt-BR");`.Criar um formatador único de quantidade — `fmtQtd(n) = Number(n).toLocaleString('pt-BR', {minimumFractionDigits: 3, maximumFractionDigits: 3})` — e substituí-lo em TODOS os pontos de exibição de tonelagem listados na evidência (células de tabela, cards/resumos, hints de validação, toasts, rodapés/totalizadores e modais). Ajustar os inputs numéricos de quantidade para `step="0.001"` (rsaEditQty, np_volume, inputs inline de manutenção, input de volume de Criar Protocolo/Agendar) e exibir o valor já com 3 casas ao sair do campo. Atualizar as massas de mock de `saldo` para 3 casas (ex.: "1.000,000", "203,130", "4,640") para o protótipo demonstrar o formato. Manter R$ em 2 casas (precoTon, precoNf, valor unitário) — o pedido é explicitamente sobre quantidades. Reservar largura de coluna: 3 casas alargam as colunas numéricas; revisar `.col-volume { min-width: 100px; }` (criar-protocolo.html:4084) e as colunas `col-total` do Relatório de Status.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Saldo (do contrato) | alterar | contrato (SAP) | criar-protocolo.html:5208 e :6491 ("Saldo / Vigência"), agendar-contrato-normal.html:4605, agendar-protocolo.html:2331. Hoje vem da massa como string "1.000,00" (2 casas). |
| Volume desejado | alterar | input do usuário | criar-protocolo.html:6493 ("Volume desejado") e :5782 ("Volume"); agendar-contrato-normal.html:4967; agendar-protocolo.html:2337. Input precisa aceitar 3 decimais (step=0.001). |
| Volume Total (rodapé/barra de resumo) | alterar | cálculo (soma das linhas) | criar-protocolo.html:5094 + :5955 (statVolume, hoje 2 casas); agendar-contrato-normal.html:4491 + :5123 (sem casas); agendar-protocolo.html:1732 + :2498 (sem casas). |
| Volume total (modal de confirmação) | alterar | cálculo | criar-protocolo.html:6788 (2 casas); agendar-contrato-normal.html:6014 (sem casas); agendar-protocolo.html:2600 (sem casas). Três formatos diferentes para o mesmo campo. |
| Qtd. Protocolo | alterar | protocolo | relatorio-protocolos.html:2269 (header) e :2970/:3047 (célula, `p.qtdProtocolo.toLocaleString("pt-BR")`); editar-protocolo.html:721 "Quantidade do Protocolo" com `value="300"` (:723). |
| Qtd. Agendada | alterar | agendamentos (SAP) | relatorio-protocolos.html:2270; editar-protocolo.html:740. |
| Saldo Agendar / Saldo a Agendar / Saldo (calc.) | alterar | cálculo (qtd. protocolo - qtd. agendada) | relatorio-protocolos.html:2271, :2329, :2569 ("Saldo disponível"); editar-protocolo.html:744; manutencao-protocolo-detalhe.html:1264 ("Saldo Disponível"). |
| Qtd. Faturada | alterar | faturamento (SAP) | relatorio-protocolos.html:2272; editar-protocolo.html:748. |
| Qtd. a Faturar | alterar | cálculo | relatorio-protocolos.html:2273; editar-protocolo.html:752. |
| Quantidades do Relatório de Status de Agendamento (Plan./Real./Δ, Total e quebra diária) | alterar | agendamentos (SAP) | relatorio-status-agendamento.html:3303 e :3308 — hoje forçado a ZERO casas (`maximumFractionDigits: 0`), o desvio mais grave. Inclui `Total Plan. (t)` / `Total Real. (t)` (:3272-3273) e a weekly-breakdown. |
| Volume (t) — cadastro de novo protocolo em Manutenção | alterar | input do usuário | manutencao-protocolos.html:1240 (label) e :1241 (`step="0.01"`). |
| Quantidades inline do detalhe do protocolo | alterar | protocolo | manutencao-protocolo-detalhe.html:1721 `fmtVolume` e :1866/:1869 inputs `step="0.01"`. |
| Hints e toasts de validação de quantidade | alterar | cálculo | relatorio-protocolos.html:3658 ("Só pode reduzir · mínimo X t"), :3886/:3920 ("Máximo X t (saldo disponível)"), :3504 (toast); relatorio-status-agendamento.html:3698 (toast "... atualizado para X t"). |
| Preço/Ton, Preço NF, Valor unitário (R$) | manter | contrato / protocolo | NÃO são quantidade. Mantêm 2 casas: manutencao-protocolos.html:1956 `parseFloat(precoNf).toFixed(2)`, manutencao-protocolo-detalhe.html:1710. Só alterar se o PO confirmar o contrário. |
“Vamos reutilizar o cadastro de cooperado atual do MD.” / “Será utilizada a mesma tela que hoje é feito o cadastro.” / “Trazer Master Data para validar os campos obrigatórios de preenchimento para cadastro de Cooperado.”
O cadastro de cooperado NÃO será redesenhado: reaproveita-se a tela que já existe no MD hoje. O protótipo deve refletir a tela real, e os campos obrigatórios vêm do Master Data.
O protótipo tem um formulário próprio de cadastro que não corresponde à tela real do MD e não exibe CNPJ/CPF, IE, Nome da Propriedade/Fazenda nem Bairro/Número.
Drawer “Cadastrar Cooperado” em criar-protocolo.html; a Alessandra confirma: “Hoje temos esses campos, são os campos básicos para cadastro, mas no protótipo eles não aparecem.”Antes de mexer no formulário, obter a tela/campos reais do cadastro atual do MD e a lista de obrigatórios do Master Data. Só então ajustar o protótipo — caso contrário corremos o risco de desenhar um cadastro que não existe.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| CNPJ/CPF | incluir | cadastro atual do MD | |
| Inscrição Estadual | incluir | cadastro atual do MD | |
| Nome da Propriedade/Fazenda | incluir | cadastro atual do MD | |
| Bairro/Número | incluir | cadastro atual do MD |
Incluir os campos: Número do Contrato SAP e Código do produto.
Na tela de criação de protocolos, exibir o número do contrato no SAP (além do número Q- já mostrado) e o código do produto (além da descrição já mostrada), para permitir conferência/rastreabilidade com o SAP.
Não existe nenhum campo de contrato SAP nem de código de produto. O grep por 'sap', 'contratoSAP', 'numeroSAP' em criar-protocolo.html retorna zero ocorrências. O dataset de contratos (linhas 5543-5553) tem apenas: contrato, item, refCliente, produto, embalagem, frete, planta, enviarPara, cnpj, ie, precoTon, status, dataInicio, dataFim, saldo. O produto aparece só como descrição, sem código.
Linha 5543: `{ contrato: "Q-20303", item: "10", refCliente: "474663", produto: "EXCLN 24 05 24 UR", ... }` — o campo `contrato` guarda o número Q-, e `produto` guarda apenas a descrição. Cabeçalhos da tabela (linhas 6488-6490): `<th>Contrato / Item</th>` e `<th>Produto / Embalagem / Origem</th>` — nenhum SAP, nenhum código.Adicionar `contratoSAP` e `produtoCodigo` ao dataset SEARCH_RESULTS (linhas 5543-5553). Na coluna 'Contrato / Item', acrescentar uma linha secundária com o nº do contrato SAP (ex.: `Contrato SAP 4500123456`). Na coluna 'Produto / Embalagem / Origem', exibir o código do produto junto/antes da descrição (ex.: `100234 · EXCLN 24 05 24 UR`). Incluir ambos no haystack de busca do drawer (linha 6193-6196). Como o apontamento é transversal (item 1 do e-mail: 'Trazer Número do Contrato SAP'), o mesmo par de campos deve ser refletido no modal Selecionar contratos.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Número do Contrato SAP | incluir | contrato (SAP) | Item 1 do e-mail marca como transversal; PO encaminhou ao Luiz p/ ajustar épico/estórias. Não definido no thread se substitui ou convive com o nº Q-. |
| Código do produto | incluir | contrato / cadastro de material (SAP) | Hoje só existe a descrição do produto. |
| Contrato (Q-) | manter | contrato | Nada no thread pede remoção. |
| Produto (descrição) | manter | contrato | Código é adição, não substituição. |
Mostrar o número do protocolo gerado ao salvar.
Após confirmar a criação, o usuário precisa ver o(s) número(s) de protocolo gerado(s) na própria tela de retorno, sem precisar ir ao Relatório de Protocolos.
O modal de sucesso não exibe nenhum número de protocolo — apenas uma mensagem genérica e dois botões de navegação. Não há geração de identificador de protocolo em lugar algum do arquivo.
Linha 5316: `<h3 id="successTitle">Protocolos criados</h3>`; linha 5328: `<p class="confirm-v2-text"><strong>Seus protocolos foram criados com sucesso.</strong><br/>Acompanhe o status pelo Relatório de Protocolos.</p>`; linhas 5330-5331: botões 'Ver Relatório de Protocolos' e 'Agendar Protocolos'. Nenhuma referência a número gerado.No modal `#successModal`, entre a mensagem e os botões, inserir a lista dos protocolos gerados. Para 1 protocolo: exibir o número em destaque com ação de copiar. Para N protocolos: lista compacta (com scroll) relacionando cada protocolo ao seu contrato/item de origem — ex.: `PR-000123 · Q-20303 item 10 · AGUINADO GOMES`. Gerar os números na função de confirmação (linha 6805, `openModal("successModal")`) e guardá-los no state para renderização.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Número do protocolo gerado | incluir | backend/SAP no momento do salvamento | No protótipo será mock. Um número por linha de protocolo criada. |
| Contrato / Item de origem (na lista de sucesso) | incluir | linha da tela de criação | Necessário para o usuário associar cada número ao respectivo item quando há múltiplos protocolos. |
Retirar a 'Semana desejada' — os agendamentos serão feitos separadamente. DECISÃO (PO): 'aqui não teremos mais a funcionalidade de criar o agendamento automaticamente a partir da criação de protocolos.'
Remover completamente o campo/coluna 'Semana desejada' da criação de protocolo, junto com sua validação e o datepicker associado, porque o agendamento deixa de ser disparado a partir da criação. O protocolo passa a ser criado 'seco' e agendado depois em tela própria.
'Semana desejada' existe como coluna na tabela (com input de data + datepicker), como field-block na visão em cards, tem regra de validação própria, entra no resumo colapsado do card e é inicializada no state ao adicionar linhas.
Linha 6499 (cabeçalho da tabela): `<th class="col-date">Semana desejada</th>`; linhas 6617-6619 (célula): `value="${r.semana || ''}" ... data-field="semana"`; linha 5841 (visão cards): `<label>Semana desejada</label>`; linha 5923 (validação): `if (d && d < todayStart()) errs.semana = "Semana desejada não pode ser passada";`; linha 7006 (datepicker): `const blockPast = dataField === "semana";`; linha 6221 (state inicial): `semana: "",`; linha 6664 (resumo do card): `${r.semana || 'sem data'}`.Remover: (a) o `<th class="col-date">Semana desejada</th>` (linha 6499) e a respectiva `<td>` com datepicker (linhas ~6615-6622); (b) o field-block 'Semana desejada' da visão em cards (linhas 5840-5849); (c) a regra de validação `errs.semana` (linhas 5921-5923) e o comentário na linha 5903; (d) a menção a `semana` no resumo colapsado (linha 6664), substituindo por outro dado relevante ou apenas removendo o segmento; (e) `semana: ""` da inicialização das linhas (6221 e 6328); (f) o ramo `blockPast` do datepicker (linha 7006), que hoje só serve à 'semana'; (g) `semana` da lista de campos opcionais na linha 5937 e da checagem `anyTouched` na linha 5642. Revisar também os larguras de coluna do CSS (comentário na linha 3165 cita 'semana 9%') para redistribuir o espaço liberado.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Semana desejada | remover | entrada do usuário | Remoção total: coluna da tabela, campo no card, validação, datepicker e state. |
| Validação 'Semana desejada não pode ser passada' | remover | regra de front | Fica órfã com a remoção do campo (linha 5923). |
| Resumo colapsado do card (segmento de data) | alterar | derivado | Linha 6664 exibe `${r.semana || 'sem data'}` — precisa sair ou ser substituído. |
| Larguras das colunas da tabela | alterar | CSS | Comentário na linha 3165 distribui 9% para 'semana'; redistribuir. |
Adicionar CPF/CNPJ e IE abaixo da caixa de seleção de Cooperado (facilitar conferência).
Depois que o usuário seleciona um cooperado, o CPF/CNPJ e a Inscrição Estadual desse cooperado devem ficar visíveis logo abaixo do botão de seleção, na própria linha do protocolo, para conferência sem reabrir o modal.
O botão de seleção de cooperado exibe apenas o nome (e um badge 'Pendente' quando aplicável). Não há CPF/CNPJ nem IE abaixo dele, nem na tabela nem na visão em cards. Os dados existem no dataset e só são vistos dentro do modal — e lá aparece CPF/CNPJ, mas não a IE.
Linhas 6560-6562 (tabela): `<button class="coop-pick-btn ..."><span class="coop-text">${coopName || 'Selecionar cooperado'}${coopPendingBadge}</span>${ICON_SEARCH}</button>` — só o nome. Linha 6532: `const coopName = r.cooperado ? r.cooperado.nome : "";`. Linhas 5776-5779 (cards): mesma estrutura, `'Selecionar'`. O dado existe: linha 5566 — `{ id: "C001", nome: "AGUINADO GOMES", ie: "785.208.958.045", doc: "618.281.300-87", ... }`. No modal (linhas 7245-7249) exibe-se `<strong>CPF/CNPJ</strong> ${c.doc}` e `<strong>Cidade</strong> ${c.cidade}/${c.uf}` — a IE não é exibida.Na célula do Cooperado (tabela, linhas 6558-6564) e no field-block equivalente da visão em cards (linhas 5774-5780), renderizar abaixo do botão de seleção uma linha secundária com CPF/CNPJ e IE do cooperado selecionado — no mesmo padrão de `stack-secondary`/`v5-meta-label` já usado nas demais colunas, ex.: `<div class="stack-secondary"><span class="v5-meta-label">CPF/CNPJ</span> 618.281.300-87 · <span class="v5-meta-label">IE</span> 785.208.958.045</div>`. Exibir só quando `r.cooperado` estiver preenchido (estado vazio permanece só com o botão). Ajustar a largura da coluna `col-coop` para acomodar a segunda linha.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| CPF/CNPJ do cooperado | incluir | cooperado (campo `doc`, já existente no dataset) | Exibição apenas leitura, abaixo do seletor. |
| IE do cooperado | incluir | cooperado (campo `ie`, já existente no dataset) | Existe no dataset mas hoje não é exibido em nenhum ponto desta tela, nem no modal. |
| Nome do cooperado (botão seletor) | manter | cooperado | Permanece como rótulo principal do botão. |
| Largura da coluna Cooperado | alterar | CSS | Coluna passa de uma para duas linhas de conteúdo. |
SELECIONAR COOPERADO (modal) — "Incluir os campos de Inscrição Estadual e Endereço completo."
Cada linha de resultado do drawer de seleção de cooperado deve exibir, além do que já mostra, a Inscrição Estadual e o endereço completo (logradouro/número/bairro, cidade/UF, CEP), para o usuário conferir o cooperado antes de selecionar.
O drawer existe e lista os cooperados, mas cada item exibe apenas 4 blocos: nome (+ badge Pendente), fazenda, CPF/CNPJ e Cidade/UF. IE e endereço NÃO são renderizados, embora os dados já existam no mock (campos ie, rua, cep no array COOPERADOS).
criar-protocolo.html L7239-7253 (renderCoopDrawerList): `<div class="coop-name">${c.nome}...`, `<div class="coop-fazenda">${c.fazenda}...`, `<div class="coop-doc"><strong>CPF/CNPJ</strong> ${c.doc}`, `<div class="coop-loc"><strong>Cidade</strong> ${c.cidade}/${c.uf}` — nenhuma referência a `c.ie`, `c.rua` ou `c.cep` no HTML do item. Dados existem em L5566-5572: `{ id: "C001", nome: "AGUINADO GOMES", ie: "785.208.958.045", doc: "618.281.300-87", fazenda: "FAZENDA 132", rua: "ESTRADA MUNICIPAL SLT 170 SN", cidade: "LIMEIRA", uf: "SP", cep: "18440-000" }`.Adicionar ao template do item do drawer os blocos "IE" e "Endereço" (rua + bairro/número, cidade/UF, CEP). Isso exige rever o grid CSS do item, hoje fixo em 4 colunas — sugestão: manter coluna 1 = radio, coluna 2 = nome/fazenda/endereço empilhados, coluna 3 = CPF/CNPJ + IE, coluna 4 = Cidade/UF + CEP, evitando estourar a largura do drawer. Bairro e Número não existem no mock e precisam ser acrescentados ao objeto COOPERADOS para que "endereço completo" seja de fato completo (coerente com o G4-03).
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Inscrição Estadual (IE) | incluir | cadastro do cooperado (Salesforce / Master Data) — já existe no mock como `c.ie` | Exibir no item da lista, rotulado "IE". Atenção: o item 2 dos apontamentos manda RETIRAR a IE do modal de Selecionar Contratos — são telas diferentes, não confundir. |
| Endereço — Logradouro/Rua | incluir | cadastro do cooperado — já existe no mock como `c.rua` | |
| Endereço — Número | incluir | cadastro do cooperado | Não existe no objeto COOPERADOS hoje; precisa ser criado no mock. |
| Endereço — Bairro | incluir | cadastro do cooperado | Não existe no objeto COOPERADOS hoje; precisa ser criado no mock. |
| CEP | incluir | cadastro do cooperado — já existe no mock como `c.cep` | Existe no dado, mas não é renderizado. |
| Nome do cooperado | manter | cadastro do cooperado | |
| CPF/CNPJ | manter | cadastro do cooperado | Já exibido. |
| Cidade/UF | manter | cadastro do cooperado | Já exibido; passa a compor o bloco de endereço completo. |
| Nome da Propriedade/Fazenda | manter | cadastro do cooperado | Já exibido como `coop-fazenda`. |
SELECIONAR COOPERADO (modal) — "Opção de pesquisar também por IE e Cidade."
A busca do drawer de cooperado deve aceitar Inscrição Estadual e Cidade como critérios, além dos já suportados.
PARCIALMENTE ATENDIDO. A função de filtro JÁ pesquisa por IE e por Cidade — o array de campos varridos inclui `c.ie` e `c.cidade`. Porém o placeholder do input NÃO anuncia esses critérios, dizendo apenas "Buscar por nome, CPF/CNPJ ou fazenda…", o que faz o comportamento parecer inexistente para quem revisa o protótipo.
Filtro em criar-protocolo.html L7223-7226: `const filtered = COOPERADOS.filter(c => { if (!q) return true; return [c.nome, c.doc, c.ie, c.fazenda, c.cidade].some(v => v.toLowerCase().includes(q)); });` — IE e cidade já contemplados. Placeholder em L5383: `<input type="text" id="coopDrawerSearch" placeholder="Buscar por nome, CPF/CNPJ ou fazenda…" autocomplete="off" />` — não cita IE nem Cidade.Atualizar o placeholder para explicitar os critérios, ex.: "Buscar por nome, CPF/CNPJ, IE, cidade ou fazenda…". Nenhuma mudança na lógica de filtro é necessária. Opcionalmente, destacar (highlight) o trecho correspondente no resultado para tornar visível qual campo casou com a busca — sobretudo quando o casamento ocorre em IE, que hoje nem sequer aparece na lista (ver G4-01: sem exibir a IE, buscar por IE devolve resultados sem justificativa visível).
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Campo de busca — placeholder | alterar | UI (texto estático) | De "Buscar por nome, CPF/CNPJ ou fazenda…" para incluir IE e Cidade. |
| Busca por IE | manter | cadastro do cooperado (`c.ie`) | Já implementado no filtro; só não está comunicado. |
| Busca por Cidade | manter | cadastro do cooperado (`c.cidade`) | Já implementado no filtro; só não está comunicado. |
| Busca por Nome / CPF-CNPJ / Fazenda | manter | cadastro do cooperado |
CADASTRAR COOPERADO — "Faltam informações de: CNPJ/CPF; IE; Nome da Propriedade/Fazenda; Bairro/Número." DECISÃO (Alessandra): "Hoje temos esses campos, são os campos básicos para cadastro, mas no protótipo eles não aparecem."
O formulário de cadastro de cooperado do protótipo está incompleto frente ao cadastro real do MD/Salesforce, que já possui esses campos. Não é criação de campo novo no sistema — é refletir no protótipo o que já existe hoje na tela real, que será reutilizada.
CONFIRMADO: os quatro campos estão ausentes do formulário. O drawer de cadastro tem exatamente 11 campos: Tipo de cliente (select PF/PJ), Nome do agricultor, Telefone de contato, E-mail de contato, Rua, Código Postal, Linha de endereço 2 (opcional), Cidade, País, Estado/Província e Instruções de entrega (opcional). Não há input de CPF/CNPJ, IE, Fazenda, Bairro nem Número. Consequência funcional: ao salvar, o novo cooperado é criado com IE, documento e fazenda literalmente preenchidos com traço.
criar-protocolo.html L5401-5514 (bloco `cad-coop-grid`): labels existentes são `Tipo de cliente`, `Nome do agricultor`, `Telefone de contato`, `E-mail de contato`, `Rua`, `Código Postal`, `Linha de endereço 2 (opcional)`, `Cidade`, `País`, `Estado/Província`, `Instruções de entrega (opcional)`. Prova do buraco no salvamento — L7376-7385: `const newCoop = { id: ..., nome: nome.toUpperCase(), ie: "—", doc: "—", fazenda: "—", rua: end + (end2 ? ", " + end2 : ""), ... }`. Validação de obrigatórios em L7353-7361 cobre apenas `tipo, nome, rua, cep, cidade, pais, estado`.Incluir no formulário os campos CPF/CNPJ, Inscrição Estadual, Nome da Propriedade/Fazenda, Bairro e Número, e passar a gravá-los no objeto do novo cooperado (substituindo os literais "—" em `ie`, `doc` e `fazenda`), para que apareçam na lista do drawer de seleção (G4-01) e nas telas que consomem o cooperado. Sugestão de comportamento condicionado ao "Tipo de cliente": PF → CPF, PJ → CNPJ; e IE possivelmente com opção "Isento". A obrigatoriedade de cada campo NÃO deve ser inventada aqui — depende do retorno do Master Data ("Trazer Master Data para validar os campos obrigatórios de preenchimento").
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| CPF/CNPJ | incluir | cadastro de cooperado do MD/Salesforce (campo já existente hoje — confirmado pela Alessandra) | Máscara e validação condicionadas ao Tipo de cliente (PF/PJ). Hoje o save grava `doc: "—"`. |
| Inscrição Estadual (IE) | incluir | cadastro de cooperado do MD/Salesforce (já existe hoje) | Hoje o save grava `ie: "—"`. Avaliar tratamento de "Isento" — não pedido pelo PO, apenas sinalizado. |
| Nome da Propriedade/Fazenda | incluir | cadastro de cooperado do MD/Salesforce (já existe hoje) | Hoje o save grava `fazenda: "—"`, embora a lista de seleção já renderize esse campo (`coop-fazenda`). |
| Bairro | incluir | cadastro de cooperado do MD/Salesforce (já existe hoje) | Hoje inexistente; o endereço se apoia em Rua + "Linha de endereço 2 (opcional)". |
| Número | incluir | cadastro de cooperado do MD/Salesforce (já existe hoje) | Hoje inexistente. |
| Tipo de cliente | manter | formulário | Deve passar a condicionar a máscara de CPF/CNPJ. |
| Nome do agricultor | manter | formulário | Ver dúvida sobre nomenclatura (agricultor/cliente vs. cooperado). |
| Rua, Código Postal, Cidade, Estado/Província, País | manter | formulário | Já existem e são obrigatórios. |
| Telefone, E-mail, Linha de endereço 2, Instruções de entrega | manter | formulário | Opcionais hoje. |
CRIAÇÃO COOPERADO — comportamento/status. "Quando aparece para o cliente? → A partir do momento do cadastro." / "Aparece em andamento ou só concluído? → Aparece o cooperado em andamento porém não permite selecionar para criar o protocolo." / "Temos Status de acompanhamento, caso apareça em tela antes de concluir?" → PERGUNTA DIRECIONADA A @Victor Dias e @Luiz Ribas — ainda sem resposta.
Duas partes distintas. (a) Regra de comportamento — JÁ DECIDIDA: o cooperado recém-cadastrado aparece na lista imediatamente, marcado como em andamento, e fica bloqueado para seleção até a aprovação cadastral. (b) Pergunta em aberto — se haverá um status de ACOMPANHAMENTO do processo de aprovação (onde o usuário consulta em que etapa está o cadastro), direcionada ao Victor Dias e ao Luiz Ribas, sem resposta no thread.
A parte (a) JÁ ESTÁ IMPLEMENTADA no protótipo. Ao salvar, o novo cooperado entra na lista com `pending: true` e um prazo simulado de 10 minutos; na lista aparece com badge "Pendente", texto "aguardando aprovação", opacidade reduzida, cursor `not-allowed`, `aria-disabled="true"`, clique ignorado e botão "Selecionar" desabilitado. O badge "Pendente" também aparece na célula Cooperado da tabela e no card. A parte (b) NÃO existe: não há nenhuma tela, etapa, timeline ou indicador de status de acompanhamento do cadastro — o único sinal é o badge binário Pendente/liberado, e o desbloqueio é um timer de 10 minutos (simulação de protótipo, não uma regra de negócio).
Criação com pendência — L7383-7384: `pending: true, /* lock for ~10 min (approval pending) */ pendingUntil: Date.now() + 10 * 60 * 1000`. Renderização bloqueada — L7236-7243: `<span class="coop-pending-tag" title="Aguardando aprovação cadastral">Pendente</span>` e `${c.fazenda}${isPending ? ' · <em style="color:var(--status-orange)">aguardando aprovação</em>' : ''}`, com `${isPending ? 'aria-disabled="true"' : ''}`. Bloqueio efetivo do clique — L7263: `if (item.classList.contains("is-pending")) return;` e L7256: `elCoopSelectBtn.disabled = !coopPickContext.tempSelected || isCoopPending(coopPickContext.tempSelected);`. Regra do pendente — L7405-7412 (`isCoopPending`): libera automaticamente quando `Date.now() > c.pendingUntil`. CSS do estado em L4257-4264 (`opacity: 0.6; cursor: not-allowed`).NÃO ALTERAR a regra de comportamento — o protótipo já reflete a decisão da Alessandra (aparece em andamento, não permite selecionar). Duas frentes a tratar: (1) responder a pergunta pendente sobre status de acompanhamento (é uma resposta do Victor/Luiz, não uma alteração de tela) e, se a resposta for positiva, desenhar a exibição desse status — o desenho só deve começar depois da definição dos estados reais do fluxo de aprovação. (2) Independente disso, substituir o timer de 10 minutos por um estado controlado ao integrar, e revisar o texto do badge, que hoje diz apenas "Pendente / aguardando aprovação" sem informar prazo, etapa ou responsável.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Badge "Pendente" no item da lista de cooperados | manter | estado local do protótipo (`c.pending` / `c.pendingUntil`) | Já implementado e coerente com a decisão. Só evolui se a pergunta pendente exigir estados adicionais. |
| Badge "Pendente" na célula Cooperado (tabela e card) | manter | estado do cooperado selecionado | L5745-5746 (card) e L6533-6534 (tabela). Observação: como um cooperado pendente não pode ser selecionado, esse badge só apareceria se o cooperado ficasse pendente APÓS a seleção — verificar se o caminho é alcançável. |
| Bloqueio de seleção do cooperado pendente | manter | regra de negócio decidida | Clique e botão Selecionar já bloqueados. |
| Status de acompanhamento da aprovação cadastral | incluir | A DEFINIR — depende do fluxo de aprovação (Master Data / Salesforce) | NÃO desenhar antes da resposta. Não há hoje nenhum campo, etapa ou timeline no protótipo. |
| Timer de 10 minutos (`pendingUntil`) | alterar | simulação do protótipo | Artefato de mockup; na integração deve virar o estado real retornado pelo backend. Não é um requisito do PO — registrado como nota técnica. |
Opção de pesquisar por CNPJ/CPF; Contrato SAP; Cidade.
A busca do modal de seleção de contratos deve aceitar, além dos critérios atuais, CNPJ/CPF, número do Contrato SAP e Cidade — e isso precisa estar visível/comunicado ao usuário, não apenas funcionar por acaso.
O drawer tem UM único campo de busca livre. O placeholder anuncia apenas 'contrato, item, produto, planta, frete'. O haystack do filtro já inclui r.cnpj e r.enviarPara (que hoje carrega a cidade, ex. 'Sertãozinho/SP'), então CNPJ e Cidade JÁ filtram de fato, mas não são anunciados. Contrato SAP NÃO é pesquisável porque o campo não existe no dataset. Não há CPF no mock (todos os registros têm CNPJ de filial). Não existem filtros/selects separados por critério.
criar-protocolo.html:5135 e agendar-contrato-normal-v5.html:4548 — `placeholder="Buscar por contrato, item, produto, planta, frete..."`. Filtro: criar-protocolo.html:6076-6080 e agendar-contrato-normal-v5.html:5264-5268 — `const haystack = [r.contrato, r.item, r.refCliente, r.produto, r.embalagem, r.frete, r.planta, r.enviarPara, r.cnpj, r.ie || '', r.precoTon || '', r.dataInicio, r.dataFim, r.saldo].join(" ").toLowerCase();`Manter o campo de busca livre único (padrão do design system) e: (1) incluir o novo campo `contratoSap` no haystack; (2) atualizar o placeholder para anunciar os critérios pedidos, ex.: 'Buscar por contrato SAP, cotação, item, produto, CNPJ/CPF, cidade, planta...'; (3) remover `r.ie` do haystack, coerente com o G2-03. Aplicar identicamente nos dois arquivos.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Busca (input drawerSearch) — placeholder | alterar | UI (texto) | Anunciar CNPJ/CPF, Contrato SAP e Cidade |
| contratoSap (no haystack do filtro) | incluir | contrato (SAP) | Depende da criação do campo em G2-02 |
| cnpj (no haystack) | manter | contrato / filial do cliente | Já filtra hoje |
| enviarPara / cidade (no haystack) | manter | contrato (ship-to) | Cidade hoje vem embutida em 'Sertãozinho/SP' |
| ie (no haystack) | remover | contrato | Coerente com a retirada da IE (G2-03) |
Incluir número do contrato SAP.
Cada resultado da lista de contratos deve exibir o número do contrato SAP, hoje ausente — o número mostrado em destaque é o da cotação (Q-…), não o do contrato SAP.
O identificador em destaque na 1ª linha do item é `r.contrato`, cujos valores no mock são 'Q-20303', 'Q-20385', 'Q-20392', 'Q-38542', 'Q-85721', 'Q-39742' — padrão de COTAÇÃO. Nos relatórios do mesmo protótipo, 'Contrato SAP' usa outro padrão ('C-001-2024') e 'Cotação' usa 'Q-12345', confirmando que são dois números distintos. Não existe nenhuma propriedade de contrato SAP no dataset SEARCH_RESULTS nem qualquer label 'Contrato SAP' no drawer.
criar-protocolo.html:6110 e agendar-contrato-normal-v5.html:5298 — `<span class="drawer-item-contract">${highlightMatch(r.contrato, q)}</span>`. Dataset: criar-protocolo.html:5543 / agendar-contrato-normal-v5.html:4782 — `{ contrato: "Q-20303", item: "10", ... }`. Comparativo: relatorio-protocolos.html:2252 `<th ... data-sort="contrato">Contrato SAP` com dados `contrato: "C-001-2024"` (linha 2651) e `cotacao: "Q-12345"` (linha 2652).Adicionar a propriedade `contratoSap` (ex.: 'C-001-2024') a cada registro de SEARCH_RESULTS nos dois arquivos e exibi-la no item do drawer. Sugestão de posicionamento: na 1ª linha, como identificador principal rotulado 'Contrato SAP', mantendo a cotação (Q-…) rotulada como 'Cotação' — ou, se o PO preferir menos ruído na linha 1, colocar 'Contrato SAP' como primeiro item do bloco `drawer-item-meta`. Também refletir o campo no card/linha adicionada ao grid, para não perder o dado após a seleção.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Contrato SAP | incluir | contrato (SAP) | Novo campo `contratoSap` no dataset e no template do item |
| Contrato (Q-…) → rótulo 'Cotação' | alterar | cotação (Salesforce) | Renomear/rotular para não confundir com o SAP; o valor já existe |
| Item | manter | contrato |
Retirar informação IE.
A Inscrição Estadual exibida na 2ª linha (bloco de metadados) de cada resultado do modal de seleção de contratos deve deixar de aparecer.
A IE é exibida condicionalmente no bloco `drawer-item-meta`, entre 'CNPJ Filial' e 'Preço/Ton', exatamente como no print image007 (`CNPJ Filial · IE · Preço/Ton · Vigência`). O código é idêntico nos dois arquivos. A IE também alimenta o filtro de busca.
criar-protocolo.html:6125 e agendar-contrato-normal-v5.html:5313 — `${r.ie ? `<span><strong>IE:</strong> ${highlightMatch(r.ie, q)}</span>` : ''}`. Sequência confirmada nas linhas 6124-6127 (criar-protocolo) / 5312-5315 (v5): CNPJ Filial → IE → Preço/Ton → Vigência.Remover a linha que renderiza o `<span><strong>IE:</strong> …</span>` do `drawer-item-meta` nos dois arquivos e remover `r.ie` do array `haystack` do filtro. Manter a propriedade `ie` no dataset é opcional — pode ficar (inofensiva) ou ser removida; recomendo manter no dado e remover só da UI e do filtro, para não impactar outros trechos.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| IE (Inscrição Estadual) — exibição no resultado | remover | contrato / filial do cliente | Remover do template do item do drawer |
| IE — critério de busca | remover | contrato | Retirar de `haystack` para coerência |
| CNPJ Filial | manter | contrato / filial do cliente | |
| Preço/Ton | manter | contrato | Não foi pedida remoção NESTE modal (a remoção de preço/IE/vigência é do modal de Selecionar Protocolo, seção 3) |
| Vigência | manter | contrato | Idem acima |
Manter a primeira linha com informações do contrato: Ref. cliente; Embalagem; Planta; Enviar para.
A primeira linha de metadados do item na lista de seleção de protocolos permanece como está, sem alteração de conteúdo.
A 1ª linha já existe exatamente com esses 4 campos no bloco .drawer-item-meta do drawer de seleção de protocolos (renderDrawerList), linhas 2148-2151.
linha 2148-2151: '<span><strong>Ref. Cliente:</strong> ' ... '<strong>Embalagem:</strong>' ... '<strong>Planta:</strong>' ... '<strong>Enviar para:</strong>'Nenhuma alteração de conteúdo. Apenas confirmar que os 4 campos permanecem após a remoção da 2ª linha (G3-02), reagrupando o layout do .drawer-item-meta para não deixar espaço vazio.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Ref. Cliente | manter | contrato (p.refCliente) | |
| Embalagem | manter | contrato/item (p.embalagem) | |
| Planta | manter | contrato/item (p.planta) | |
| Enviar para | manter | contrato/item (p.enviarPara) |
Retirar informações da segunda linha (referentes ao contrato): CPF/CNPJ; IE; Preço; Vigência.
Remover da lista de seleção os 4 dados que hoje vêm do contrato, porque não são do protocolo.
A 2ª linha existe no drawer de seleção com exatamente esses 4 campos vindos do contrato. Os mesmos dados também reaparecem fora do drawer: Vigência no header do card (renderCardsView) e na tabela; CNPJ Filial na coluna Produto/Embalagem da tabela.
linha 2152-2155: '<strong>CNPJ Filial:</strong>' / '<strong>IE:</strong>' / '<strong>Preço/Ton:</strong> R$ ' / '<strong>Vigência:</strong>'. Também: linha 2312 (card) 'proto-meta-label">Vigência'; linha 2429 (tabela) stack-tertiary com vigenciaInicio → vigenciaFim; linha 2434 (tabela) 'De ' + planta + ' · CNPJ ' + cnpjFilial.Remover as 4 spans da 2ª linha do .drawer-item-meta (linhas 2152-2155). Consequentemente, os campos cnpjFilial, ie e precoTon do objeto PROTOCOLS deixam de ser exibidos no drawer; avaliar removê-los também do haystack de busca (linhas 2113-2117 e 2211-2215) para não haver match em dado invisível.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| CNPJ Filial (rotulado assim no protótipo; PO chama de CPF/CNPJ) | remover | contrato (p.cnpjFilial) | divergência de rótulo entre e-mail e protótipo |
| IE | remover | contrato (p.ie) | não confundir com p.ieRecebedor, que deve ser mantido/trazido (G3-04) |
| Preço/Ton | remover | contrato (p.precoTon) | substituído pelo Valor unitário do protocolo em G3-05 |
| Vigência | remover | contrato (p.vigenciaInicio/vigenciaFim) |
Manter Recebedor = Cooperado.
O bloco 'Recebedor' permanece na tela; o dado exibido nele é o Cooperado (no fluxo de protocolo, recebedor e cooperado são a mesma entidade).
O bloco Recebedor existe em 3 pontos e já é populado com dados que funcionam como cooperado (JOSE DA SILVA, CARLOS ALVES, MARIA BEZERRA, TEREZA AKEMI). Porém a palavra 'Cooperado' NÃO aparece em nenhum lugar do arquivo — o rótulo é sempre 'Recebedor'.
linha 2156 (drawer): '<strong>Recebedor:</strong> ' + p.nomeRecebedor + ' · ' + p.cidadeRecebedor; linha 2329 (card): 'proto-meta-label">Recebedor</span><strong>' + r.nomeRecebedor; linha 2398 (tabela): '<th>Recebedor / Destino</th>'. Busca por 'cooperado' no arquivo: 0 ocorrências.Manter a seção. Definir se o rótulo continua 'Recebedor' ou passa a 'Recebedor (Cooperado)' / 'Cooperado' — o pedido literal é de manutenção, não de renomeação, então por padrão manter o rótulo atual e apenas enriquecer o conteúdo conforme G3-04.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Recebedor (bloco/rótulo) | manter | cooperado do protocolo |
Trazer informações do Cooperado: Nome do Cooperado; CNPJ/CPF; IE; Cidade/UF; Valor unitário do protocolo; Número da NF.
A 2ª linha removida (dados do contrato) dá lugar a uma linha com os dados do cooperado e do protocolo. Dos 6 campos, 4 já existem no modelo de dados e 2 são novos.
PARCIAL. Nome, CNPJ/CPF, IE e Cidade/UF do recebedor já existem no objeto PROTOCOLS (nomeRecebedor, cnpjRecebedor, ieRecebedor, cidadeRecebedor), mas só são exibidos completos na visão TABELA. No drawer de seleção aparecem apenas Nome e Cidade; no card aparecem apenas Nome e Cidade. 'Valor unitário do protocolo' e 'Número da NF' NÃO existem — nem no modelo de dados nem em tela.
modelo, linhas 1908-1911: nomeRecebedor / cnpjRecebedor / ieRecebedor / cidadeRecebedor. Exibição completa só na tabela, linhas 2437-2439: stack-tertiary 'CNPJ ' + r.cnpjRecebedor + ' · IE ' + r.ieRecebedor. Drawer (2156) e card (2329) mostram apenas nome + cidade. Busca por 'NF', 'nota fiscal', 'valorUnit' no arquivo: 0 ocorrências.1) Adicionar ao objeto PROTOCOLS os campos valorUnitProtocolo e numeroNF (dados mock). 2) Substituir a 2ª linha do drawer (removida em G3-02) por uma linha de cooperado: Nome · CNPJ/CPF · IE · Cidade/UF · Valor unitário · Nº NF. 3) Propagar CNPJ/CPF, IE, Valor unitário e Nº NF também para o card (linha 2329) e para a coluna Recebedor/Destino da tabela (2437-2439), mantendo o padrão cell-stack.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Nome do Cooperado | manter | cooperado do protocolo (p.nomeRecebedor) | já exibido no drawer, card e tabela |
| CNPJ/CPF do Cooperado | incluir | cooperado do protocolo (p.cnpjRecebedor) | campo já existe no modelo; hoje só aparece na tabela — incluir no drawer e no card |
| IE do Cooperado | incluir | cooperado do protocolo (p.ieRecebedor) | campo já existe no modelo; hoje só aparece na tabela — incluir no drawer e no card |
| Cidade/UF do Cooperado | manter | cooperado do protocolo (p.cidadeRecebedor) | já exibido nos 3 lugares |
| Valor unitário do protocolo | incluir | protocolo (campo novo, ex: valorUnitProtocolo) | não existe no protótipo; substitui o Preço/Ton do contrato removido em G3-02 |
| Número da NF | incluir | protocolo (campo novo, ex: numeroNF) | não existe no protótipo, nem no modelo nem em tela |
DECISÃO (Alessandra): 'Precisa trazer as informações do protocolo que foi criado e não do contrato. No protótipo estava puxando por exemplo o preço do contrato e não do protocolo.'
Regra geral que rege todo o item 3: a origem dos dados exibidos na tela de agendamento passa a ser o PROTOCOLO criado, não o contrato de origem. O preço é o exemplo citado, mas a regra é abrangente.
CONFIRMADO. O objeto PROTOCOLS mistura dados de contrato e de protocolo, e a tela exibe os do contrato. O preço exibido é literalmente o campo do contrato: precoTon, com valores idênticos (2.450,00) em 5 dos 6 protocolos mock, todos de contratos diferentes — evidência de que o valor está atrelado ao contrato, não ao protocolo.
modelo, linha 1904/1923/1942/1961/1980/1999: precoTon; render do drawer, linha 2154: '<strong>Preço/Ton:</strong> R$ ' + escapeHtml(p.precoTon). Também cnpjFilial e ie (linhas 1902-1903) são explicitamente da FILIAL do contrato, não do cooperado.Renomear/substituir a origem do preço: descontinuar precoTon (contrato) e usar valorUnitProtocolo (protocolo) no lugar, conforme G3-04. Revisar cada campo restante da tela classificando a origem (contrato x protocolo x cooperado) e ajustar rótulos para que fique explícito de onde vem o dado. Nos dados mock, diferenciar os valores unitários entre protocolos para deixar visível que não é mais o preço do contrato.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Preço/Ton | remover | contrato (p.precoTon) | |
| Valor unitário do protocolo | incluir | protocolo | substitui o anterior; mock deve variar entre protocolos |
| Saldo | manter | a confirmar — se é saldo do contrato ou quantidade do protocolo | não citado no e-mail; ver dúvida |
Trazer Descrição da Filial do cliente.
O relatório deve exibir a descrição (nome) da filial do cliente, não apenas identificadores da filial (CNPJ/cidade).
O relatório JÁ possui uma coluna de filial com valor descritivo. Existe a coluna `Filial do Cliente` (data-sort="filial"), acompanhada de `CPF/CNPJ da Filial`, `Cidade da Filial` e `UF`. O mock preenche essa coluna com textos descritivos ("Filial São Paulo", "Filial Curitiba", "Filial Porto Alegre", "Filial Londrina"). Também há filtro `Filial do Cliente` (#filterFilial) e a ficha de detalhe (#efViewFilial). NÃO existe campo separado de código da filial em lugar nenhum da tela.
relatorio-protocolos.html L2254: `<th class="sortable" data-sort="filial">Filial do Cliente</th>`; L2653: `filial: "Filial São Paulo"`; L2182-2184: `<label for="filterFilial">Filial do Cliente</label>` com data-options '["Filial São Paulo","Filial Curitiba",...]'; L2428-2429: `<div class="lbl">Filial do Cliente</div><div class="val" id="efViewFilial">`; L3227-3228 (export CSV): headers incluem "Filial do Cliente".Duas leituras possíveis, a decidir com o PO antes de mexer: (a) se "Descrição da Filial" é o mesmo dado já exibido, o ajuste é apenas de rótulo — renomear a coluna/filtro/ficha de `Filial do Cliente` para `Descrição da Filial`; (b) se no SAP/Salesforce a filial tem código + descrição e o relatório hoje mostra só o código, então incluir a coluna `Descrição da Filial` ao lado do identificador. Como o protótipo hoje não tem código de filial, a hipótese (a) é a mais provável e o esforço é praticamente nulo. Em qualquer cenário, replicar o campo em: cabeçalho da tabela, linha de dados, ficha de detalhe (#efViewFilial) e header do export CSV (L3227).
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Descrição da Filial | alterar | cadastro do cliente (filial) — SAP/Salesforce | Hoje existe como `Filial do Cliente` com conteúdo descritivo. Ajuste provável é de rótulo; só vira 'incluir' se o PO confirmar que hoje se exibe código e não descrição. |
| Filial do Cliente (coluna atual) | manter | cadastro do cliente (filial) | Coluna já existente na tabela, no filtro e na ficha de detalhe. |
| CPF/CNPJ da Filial | manter | cadastro do cliente (filial) | Não foi pedida alteração. |
| Cidade da Filial / UF | manter | cadastro do cliente (filial) | Não foi pedida alteração. |
Trazer Roteiro de Entrega.
O relatório de status de agendamento deve exibir o Roteiro de Entrega associado a cada solicitação/agendamento.
NÃO existe Roteiro de Entrega neste relatório — nem como coluna, nem no modelo de dados, nem no export. As 20 colunas construídas em buildThead() vão de `Solicitação` até `UF` e não incluem roteiro. O registro criado por mkRow() traz sol, protocolo, tipo, semana, status, cotacao, contrato, itemContrato, ov, pedidoCliente, codProduto, descProduto, embalagem, frete, planta, recebedorNome, recebedorCnpj, recebedorIe, cidade, uf, qtdSolicitada, qtdConfirmadaOV, qtdFaturada — sem campo de roteiro. As únicas ocorrências da palavra "roteiro" no arquivo são regras de CSS órfãs herdadas da tela de agendamento (.roteiro-btn, .roteiro-drawer), sem nenhum HTML que as use.
relatorio-status-agendamento.html L3245-3264 (buildThead): lista de colunas termina em `{ l: "Cidade" }, { l: "UF" }` — nenhum item "Roteiro"; L3142-3149 (mkRow): registro sem chave de roteiro; L4040-4046 (export CSV): header vai de "Solicitacao" a "UF" + quantidades, sem "Roteiro"; grep "roteiro" retorna apenas CSS (L720 `.roteiro-btn`, L1319 `.roteiro-drawer`), sem marcação correspondente.Incluir a coluna `Roteiro de Entrega` na grade (posição sugerida: junto ao bloco de destino, após `Planta` ou após `UF`), adicionar o campo ao mock de dados em mkRow(), incluir no header e nas linhas do export CSV, e avaliar filtro por roteiro. Atenção: o COLSPAN da linha de breakdown semanal está fixo em 24 (L3557) e precisa ser incrementado ao adicionar coluna, senão o expandir/colapsar quebra o alinhamento.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Roteiro de Entrega | incluir | agendamento / cadastro de roteiro (mesma origem do campo Roteiro da tela Agendar Contrato Normal) | Novo: coluna na grade + chave no registro + coluna no export CSV. |
| COLSPAN do breakdown semanal | alterar | código do protótipo | Constante fixa `const COLSPAN = 24` (L3557) precisa acompanhar a nova coluna. |
Revisar colunas de totais: faltaria coluna definida no refinamento. DECISÃO (Alessandra): "as colunas estão quando exportamos para o excel, apenas em tela que não mostra, podemos seguir dessa forma para sermos mais práticos com os dados em tela."
As colunas de totais do template (Quantidade Solicitada, Quantidade Confirmada em Ordem de Vendas, Quantidade Faturada) permanecem apenas no arquivo exportado. A tela segue como está. SEM MUDANÇA EM TELA.
O protótipo JÁ está exatamente conforme a decisão. Os três campos existem no modelo de dados e são gravados apenas no export CSV, não sendo renderizados na grade. Em tela, além das 20 colunas principais, só aparecem três totalizadores de semana: `Total Plan. (t)`, `Total Real. (t)` e `Δ Total (t)`. As chaves qtdSolicitada / qtdConfirmadaOV / qtdFaturada aparecem uma única vez fora do bloco de dados: na montagem das linhas do CSV.
relatorio-status-agendamento.html L4044 (header do export): `"Qtd Solicitada (t)","Qtd Confirmada OV (t)","Qtd Faturada (t)"`; L4054 (linha do export): `r.qtdSolicitada, r.qtdConfirmadaOV, r.qtdFaturada,` — única ocorrência dessas chaves fora da massa de dados; L3272-3274 (tela): apenas `Total Plan. (t)`, `Total Real. (t)`, `Δ Total (t)`; L3148: `qtdSolicitada: 300, qtdConfirmadaOV: 150, qtdFaturada: 50`.NENHUMA mudança em tela. Item fechado — registrar como 'sem mudança em tela'. O comportamento pedido já está implementado no protótipo. Se algo for feito neste item, é apenas garantir na especificação/estória que o Excel exportado mantenha as três colunas com os rótulos do template (`Quantidade Solicitada`, `Quantidade Confirmada em Ordem de Vendas`, `Quantidade Faturada`) — hoje o CSV usa rótulos abreviados.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Quantidade Solicitada | manter | agendamento (SAP) | Só no export. Rótulo atual no CSV: "Qtd Solicitada (t)"; template do refinamento usa "Quantidade Solicitada". |
| Quantidade Confirmada em Ordem de Vendas | manter | SAP (ordem de vendas) | Só no export. Rótulo atual no CSV: "Qtd Confirmada OV (t)". |
| Quantidade Faturada | manter | SAP (faturamento) | Só no export. Rótulo atual no CSV: "Qtd Faturada (t)". |
| Total Plan. (t) / Total Real. (t) / Δ Total (t) | manter | cálculo do agendamento (planejado x realizado da semana) | Totalizadores já exibidos em tela; não são as colunas do template e não foram questionados. |
Incluir número de contrato SAP.
A tela de Agendar Contratos Normais deve exibir o número do contrato no SAP, que hoje não aparece (o identificador mostrado tem formato de cotação).
NÃO existe número de contrato SAP na tela. A busca por "SAP" nos dois arquivos não retorna nenhuma ocorrência. O único identificador de contrato é o campo `contrato`, cujos valores no mock são "Q-20303", "Q-20385", "Q-20392", "Q-38542", "Q-85721", "Q-39742" — padrão de cotação (prefixo Q-), não de contrato SAP (que no relatório de status aparece como numérico, ex.: "20084782"). Esse campo é rotulado como `Contrato` no modal de seleção e como `Contrato / Ref. / Vigência` na tabela de agendamento.
grep -i "sap" em agendar-contrato-normal-v5.html e agendar-contrato-normal.html: nenhuma ocorrência. agendar-contrato-normal.html L4594: `<th>Contrato</th>`; L4766: `{ contrato: "Q-20303", item: "10", refCliente: "474663", ... }`; L5715: `<th>Contrato / Ref. / Vigência</th>`; L5761: `<span class="cell-strong">${r.contrato}</span>`. Comparação: relatorio-status-agendamento.html L3145 usa `contrato: "20084782"` sob a coluna `Contrato SAP` (L3251).Incluir o número do contrato SAP como campo próprio (`contratoSAP`) no modelo de dados e exibi-lo em: (1) coluna nova ou linha secundária no modal de seleção de contratos, (2) célula `Contrato / Ref. / Vigência` da tabela de agendamento, e (3) resumo/confirmação do agendamento. Definir se o SAP substitui o identificador Q- atual ou convive com ele. Item transversal — o mesmo pedido aparece no bloco GERAL dos apontamentos e foi encaminhado ao Luiz para ajuste de épico/estórias.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Número do Contrato SAP | incluir | SAP (documento de contrato) | Novo campo. Hoje inexistente na tela; mock usa identificador com prefixo Q- (cotação). |
| Contrato (Q-xxxxx) atual | manter | cotação / contrato no Salesforce | Manter até o PO definir se o SAP substitui ou complementa este identificador. |
| Item do contrato | manter | contrato | Já existe (`item`), exibido no modal e como 'Item NN' na linha secundária. |
Trazer informações do Recebedor da Mercadoria.
A tela deve exibir os dados de quem recebe fisicamente a mercadoria (o ship-to / recebedor), e não apenas o destino genérico do contrato.
NÃO existe nenhuma noção de Recebedor da Mercadoria na tela. A busca por "recebedor" nos dois arquivos não retorna nenhuma ocorrência. O que existe hoje é apenas um destino textual: o campo `enviarPara`, preenchido somente com Cidade/UF ("Sertãozinho/SP", "Bebedouro/SP", "Limeira/SP", "Alfenas/MG") — sem nome, sem endereço, sem identificação do recebedor. Ele aparece como coluna `Enviar Para` no modal e como `Destino / CNPJ Filial` na tabela de agendamento. Para comparação, o Relatório de Status de Agendamento já modela esses dados (recebedorNome, recebedorCnpj, recebedorIe).
grep -i "recebedor" em agendar-contrato-normal-v5.html e agendar-contrato-normal.html: nenhuma ocorrência. agendar-contrato-normal.html L4601: `<th>Enviar Para</th>`; L4766: `enviarPara: "Sertãozinho/SP"`; L5290: `<span><strong>Enviar para:</strong> ${highlightMatch(r.enviarPara, q)}</span>`; L5775-5779: bloco `<!-- Destino / CNPJ Filial -->` com `stack-primary` = `${r.enviarPara}` e `stack-secondary` = CNPJ. Contraste: relatorio-status-agendamento.html L3146 já traz `recebedorNome: "Carlos Alves", recebedorCnpj: "71.320.915/0006-37", recebedorIe: "ISENTO"`.Modelar o bloco Recebedor da Mercadoria na tela: adicionar ao registro os campos de nome, documento e IE do recebedor, e exibi-los na célula de destino da tabela de agendamento (hoje `Destino / CNPJ Filial`) e no card/linha de resultado do modal de seleção. Reaproveitar a estrutura já existente no Relatório de Status de Agendamento (recebedorNome / recebedorCnpj / recebedorIe) para manter consistência de nomenclatura entre telas.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Nome do Recebedor da Mercadoria | incluir | ship-to do contrato (SAP) | Novo. Hoje só existe Cidade/UF em `enviarPara`. |
| Cidade/UF do Recebedor | manter | ship-to do contrato (SAP) | Já existe via `enviarPara`, mas hoje não está vinculado explicitamente a um recebedor. |
| CPF/CNPJ do Recebedor | incluir | ship-to (SAP) | Detalhado em G5-07 — hoje o CNPJ exibido é o da Filial (sold to). |
| IE do Recebedor | incluir | ship-to (SAP) | Detalhado em G5-07 — hoje a IE exibida vem do contrato/filial. |
Nome do ship to.
Exibir o nome (razão social/descrição) do ship-to, além do local de entrega, para o usuário identificar para quem está agendando.
NÃO existe nome de ship-to na tela. A busca por "ship" nos dois arquivos não retorna nenhuma ocorrência. O destino é representado exclusivamente por Cidade/UF no campo `enviarPara`, tanto na coluna `Enviar Para` do modal quanto na coluna `Destino / CNPJ Filial` da tabela de agendamento, onde a linha principal da célula é apenas o texto da cidade/UF.
grep -i "ship" em agendar-contrato-normal-v5.html e agendar-contrato-normal.html: nenhuma ocorrência. agendar-contrato-normal.html L4766: `enviarPara: "Sertãozinho/SP"` (todos os 10 registros do mock seguem o padrão Cidade/UF); L5776-5778: `<div class="stack-primary cell-strong">${r.enviarPara}</div>` seguido de `<div class="stack-secondary"><span class="v3-meta-label">CNPJ</span> ${r.cnpj || '—'}</div>`; L4601: `<th>Enviar Para</th>`.Adicionar o campo `Nome do Ship to` ao registro e promovê-lo a linha principal da célula de destino, rebaixando Cidade/UF para linha secundária — passando de 'Sertãozinho/SP' para algo como 'NOME DO SHIP TO' / 'Sertãozinho/SP' / documento. Refletir a mesma informação na coluna `Enviar Para` do modal de seleção e no card de resultado da busca. Avaliar tornar o nome do ship-to pesquisável no modal (a função de busca hoje filtra por refCliente, produto e demais campos).
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Nome do Ship to | incluir | ship-to do contrato (SAP) | Novo. Deve virar a informação principal do bloco de destino. |
| Enviar Para (Cidade/UF) | alterar | ship-to do contrato (SAP) | Mantém o conteúdo, mas passa a ser informação secundária abaixo do nome do ship to. |
| Rótulo da coluna 'Destino / CNPJ Filial' | alterar | — | Rótulo atual cita 'Filial'; com os dados passando a ser do ship to, o cabeçalho precisa ser revisto. |
Pergunta do PO: "Confirmar se CNPJ/CPF e IE são do Sold ou do Ship to". DECISÃO (Alessandra): "Deve ser do Ship to."
O CNPJ/CPF e a Inscrição Estadual exibidos na tela de Agendar Contratos Normais devem ser os do Ship to (recebedor da mercadoria), substituindo os dados do Sold to / filial que aparecem hoje.
Hoje a tela exibe o documento da FILIAL (sold to), não do ship to. O campo é literalmente rotulado `CNPJ Filial` em três lugares: cabeçalho do modal de seleção, meta do card de resultado e cabeçalho da tabela de agendamento. O valor no mock é idêntico em TODOS os 10 registros — `cnpj: "71.320.915/0006-37"` — inclusive em contratos com destinos diferentes (Sertãozinho/SP, Bebedouro/SP, Limeira/SP, Alfenas/MG), o que confirma tratar-se de um único CNPJ do cliente/filial e não do recebedor. A IE (`ie`) existe no dado e é exibida apenas no card de resultado do modal (com rótulo `IE:`), variando por referência de cliente — mas está vinculada ao contrato/filial, não ao ship to. Na tabela de agendamento a IE não é exibida.
agendar-contrato-normal.html L4602: `<th>CNPJ Filial</th>`; L5715: `<th>Destino / CNPJ Filial</th>`; L5291: `<span><strong>CNPJ Filial:</strong> ${highlightMatch(r.cnpj || '—', q)}</span>`; L5292: `${r.ie ? `<span><strong>IE:</strong> ${highlightMatch(r.ie, q)}</span>` : ''}`; L4766-4776: `cnpj: "71.320.915/0006-37"` repetido nos 10 registros com `enviarPara` distintos; L5777-5778: `<!-- Destino / CNPJ Filial -->` com `<span class="v3-meta-label">CNPJ</span> ${r.cnpj || '—'}`. Mesmos trechos em agendar-contrato-normal-v5.html (L4618, L5736).Trocar a origem do dado: o CNPJ/CPF e a IE exibidos passam a ser os do Ship to. Concretamente: (1) renomear os rótulos `CNPJ Filial` para `CPF/CNPJ do Ship to` (ou 'do Recebedor') no cabeçalho do modal, no card de resultado e no cabeçalho da tabela; (2) apontar o campo para o documento do ship-to no mock, com valores DISTINTOS por destino (hoje são todos iguais, o que mascara o erro); (3) exibir a IE do Ship to também na tabela de agendamento, não apenas no card do modal; (4) revisar o rótulo da coluna `Destino / CNPJ Filial`. Atenção: no item 2 dos apontamentos foi pedido RETIRAR a IE do modal Selecionar Contratos — validar com o PO se essa remoção afeta este modal, para não haver conflito entre os dois pedidos.
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| CPF/CNPJ do Ship to | alterar | ship-to (SAP) | Substitui o `CNPJ Filial` (sold to) exibido hoje. Mock precisa de valores distintos por destino. |
| IE do Ship to | alterar | ship-to (SAP) | Hoje a IE vem do contrato/filial e só aparece no card do modal; passa a ser do ship to e deve constar também na tabela de agendamento. |
| CNPJ Filial (sold to) | remover | sold to / filial do cliente (SAP) | Deixa de ser o documento exibido nesta tela. Confirmar se deve sumir totalmente ou apenas ceder o lugar principal. |
| Rótulos 'CNPJ Filial' / 'Destino / CNPJ Filial' | alterar | — | Três ocorrências: L4602 (modal), L5291 (card) e L5715 (tabela) em agendar-contrato-normal.html. |
DECISÃO (PO): "O Cliente também pode editar e cancelar." Regras: "Podemos ter cancelamento e edição do protocolo. Cancelamento só se não tiver agendamentos e edição da quantidade até o limite do que já foi agendado." O modal "Confirmar criação de protocolos" traz o texto grifado "Após o envio, eles entrarão em processamento e não poderão ser editados", que contradiz a decisão.
O cliente passa a ter permissão de editar e cancelar protocolo, com duas travas: cancelar apenas se não houver agendamento vinculado; editar a quantidade apenas até o piso do que já foi agendado. O texto do modal de confirmação de criação precisa deixar de afirmar o oposto.
A CONTRADIÇÃO EXISTE E ESTÁ CONFIRMADA no texto do modal. Porém — e isso é importante — as REGRAS de negócio pedidas pelo PO já estão implementadas no Relatório de Protocolos: edição de quantidade com piso na qtd. agendada e cancelamento bloqueado quando há agendamentos. Ou seja, o problema é apenas de COPY do modal, que descreve um comportamento que o próprio protótipo já não pratica.
TEXTO CONTRADITÓRIO — criar-protocolo.html:5299: `<p class="confirm-v2-text">Você está prestes a criar todos os seus protocolos. Após o envio, eles entrarão em processamento e não poderão ser editados.</p>` (título em :5287 `<h3 id="submitTitle">Confirmar criação de protocolos</h3>`, botão em :5303 "Confirmar criação"). Mesma frase em agendar-protocolo.html:1855 (`Você está prestes a agendar <strong id="confirmCount">0</strong> protocolos. Após o envio, eles entrarão em processamento e não poderão ser editados.`) e agendar-contrato-normal.html:4696 (agendamentos). REGRAS JÁ IMPLEMENTADAS — relatorio-protocolos.html:2820 `minVolume(p) { return p.qtdAgendada; }, // proxy de "active requests in SAP"`; :2825 `canCancel(p) { return STATUS_ACTIVE.has(p.status) && p.qtdAgendada === 0 && p.qtdFaturada === 0; }`; :2828 `if (p.qtdAgendada > 0) return "Há requests ativas vinculadas — cancele as requests antes.";`; :3651-3658 `const minVol = rules.minVolume(p); elProto.min = minVol; ... "Só pode reduzir · mínimo ${minVol.toLocaleString("pt-BR")} t (qtd. agendada)"`. AFFORDANCES JÁ EXISTENTES — relatorio-protocolos.html:2306 `<h2 id="efModalTitle">Editar protocolo</h2>`, :2499 `<h2>Cancelar protocolo</h2>`, :3312 botão "Cancelar protocolo"; manutencao-protocolo-detalhe.html:1243 `<button ... id="btnCancel">Cancelar protocolo</button>` e :1455 `<h2 id="cancelModalTitle">Cancelar protocolo?</h2>`; manutencao-protocolos.html:1166 `<h2 id="massCancelTitle">Cancelar protocolos?</h2>` com nota em :1310 `- hasActiveRequests: tem agendamentos ativos (impede cancelamento)`.Reescrever o parágrafo de criar-protocolo.html:5299 para refletir a decisão, sem inventar regra nova. Sugestão: "Você está prestes a criar todos os seus protocolos. Após o envio, eles entrarão em processamento. Você poderá editá-los ou cancelá-los pelo Relatório de Protocolos — o cancelamento só é permitido enquanto não houver agendamentos, e a quantidade só pode ser reduzida até o total já agendado." Alternativa mais enxuta se o PO preferir modal curto: remover a oração "e não poderão ser editados" e adicionar o link/menção ao Relatório de Protocolos. Como as regras já existem no código do Relatório de Protocolos (rules.canCancel / rules.minVolume), não há trabalho de lógica nesta mudança — é texto. Verificar também se o mesmo texto deve mudar nos modais de AGENDAMENTO (agendar-protocolo.html:1855 e agendar-contrato-normal.html:4696): a decisão do PO fala de protocolo, não de agendamento, e o item 8 do apontamento cita apenas o modal "Confirmar criação de protocolos".
| Campo | Ação | Origem do dado | Observação |
|---|---|---|---|
| Texto do modal "Confirmar criação de protocolos" (.confirm-v2-text) | alterar | copy estática do protótipo | criar-protocolo.html:5299. Remover "e não poderão ser editados" e informar que edição/cancelamento ficam disponíveis no Relatório de Protocolos, com as duas travas. |
| Ação "Editar protocolo" | manter | protocolo | Já existe — relatorio-protocolos.html:2306 e :3299; manutencao-protocolo-detalhe.html:1422; tela dedicada editar-protocolo.html:548. Nenhuma mudança pedida. |
| Ação "Cancelar protocolo" | manter | protocolo | Já existe — relatorio-protocolos.html:2499/:3312; manutencao-protocolo-detalhe.html:1243. Nenhuma mudança pedida. |
| Regra: cancelamento só sem agendamentos | manter | agendamentos vinculados (SAP) | Já implementada — relatorio-protocolos.html:2825 `canCancel` exige `p.qtdAgendada === 0`. Observação: a implementação atual exige TAMBÉM `p.qtdFaturada === 0` (:2830 "Já existe faturamento neste protocolo."), condição que o PO não mencionou — ver dúvidas. |
| Regra: edição de quantidade até o limite já agendado | manter | cálculo (qtd. agendada) | Já implementada — relatorio-protocolos.html:2820 `minVolume(p) { return p.qtdAgendada; }` e :3652 `elProto.min = minVol`, com hint "Só pode reduzir · mínimo X t (qtd. agendada)" em :3658. |
| Texto dos modais de confirmação de AGENDAMENTO | manter | copy estática do protótipo | agendar-protocolo.html:1855 e agendar-contrato-normal.html:4696 têm a mesma frase, mas se referem a agendamentos, não a protocolos. Marcar como manter até o PO confirmar — ver dúvidas. |
Como este backlog foi produzido: o e-mail foi decomposto em 11 blocos; 6 auditorias independentes cruzaram cada apontamento com o código real dos protótipos (labels, campos e linhas); e uma revisão final conferiu cobertura, precisão, escopo e contradições. As correções da revisão estão marcadas como “Nota da revisão”. Nenhum protótipo foi alterado.