Objetivo
Definir como cada etapa do fluxo Pago→Fechado sabe o que tem que fazer no dia: quais pedidos aparecem na fila, em que ordem, e com base em quais datas. Este documento é referência transversal — todos os processos da Cadeia 1 entre Pago e Expedição devem referenciar estas regras.
As três datas de um pedido
Todo pedido no fluxo de produção tem três datas com significados e fontes diferentes. A distinção é crítica porque cada uma responde a uma pergunta diferente:
1. Data de previsão de produção (PV)
- Fonte: Calculada automaticamente pelo ERP a partir da data do status “Pago”
- Onde aparece: No pedido de venda (PV), no filtro “produção” do ERP
- O que responde: “Quando o sistema estima que este pedido será produzido?”
- Quem usa: Atendente (para definir data de retirada), gerente de atendimento (para avaliar prioridades)
- Natureza: Cálculo automático — a Atendente não controla esta data, apenas a consulta
2. Data de retirada (REQ)
- Fonte: Inserida pela Atendente no pedido de produção ao criar a REQ
- Onde aparece: Em todos os dígitos da REQ, no comando de produção do ERP, no filtro de data do sistema de produção
- O que responde: “Quando este pedido deve estar pronto para envio?”
- Quem usa: Toda a produção (Triagem, Manipulação, Conferência 1, Conferência 2, Fechamento) — é a data que organiza o trabalho do dia
- Natureza: Compromisso operacional — a Atendente define com base na previsão mas pode ajustar
Esta é a data que rege a produção. Aparece em todos os dígitos da REQ e vai no comando de produção do ERP. A produção filtra por ela para saber o que iniciar e terminar no dia.
3. Data de produção real (ERP)
- Fonte: Data em que o pedido passa para o status “Fechado” (última etapa atual no ERP)
- Onde aparece: No histórico de status do pedido no ERP
- O que responde: “Quando este pedido foi de fato produzido?”
- Quem usa: Gestão (para medir performance: retirada prometida vs. produção real)
- Natureza: Fato consumado — registro do que aconteceu
Relação causal entre as três datas
Previsão (calculada do Pago)
→ informa a Atendente
→ Atendente define Retirada (≥ Previsão, salvo prioridade)
→ Produção trabalha pela Retirada
→ Produção Real registra o que aconteceu
A distância entre Retirada e Produção Real é um indicador de saúde operacional: se a produção real é consistentemente depois da retirada, a capacidade produtiva está abaixo da demanda. Se é consistentemente antes, há folga.
Cálculo automático da data de previsão de produção
A data de previsão de produção é calculada automaticamente pelo ERP no momento em que o pedido recebe o status Pago. O cálculo depende de duas variáveis: a hora do pagamento e o tipo de envio do PV.
Corte do dia: 14h
O ERP divide o dia em dois:
- Pago antes das 14h → conta como “pago hoje” (D = hoje)
- Pago depois das 14h → conta como “pago amanhã” (D = hoje + 1 dia)
Prazo por tipo de envio
A lógica causal: envios de 17h e 19h são os últimos pacotes do dia — a produção tem mais horas de trabalho disponíveis, então precisa de menos dias. Envios de 12h e 15h saem mais cedo, a produção precisa de mais antecedência.
| Tipo de envio | Pago antes das 14h | Pago depois das 14h |
|---|---|---|
| 17h | D+1 | D+2 |
| 19h | D+1 | D+2 |
| 12h | D+2 | D+3 |
| 15h | D+2 | D+3 |
Esporádico (:30): segue a regra do horário base. 17:30 → regra do 17h. 19:30 → regra do 19h. Se for outro horário :30 com tipo de envio 17h ou 19h no PV, segue a regra do tipo do PV.
Exemplos
- Pedido tipo 19h, pago segunda 10h → previsão: terça (D+1)
- Pedido tipo 12h, pago segunda 10h → previsão: quarta (D+2)
- Pedido tipo 15h, pago segunda 16h → previsão: quinta (D = terça porque passou das 14h, +2 = quinta)
- Pedido tipo 17:30 (esporádico), pago segunda 10h → previsão: terça (segue regra do 17h, D+1)
Momento do cálculo
A previsão é calculada uma única vez, no instante do status Pago (webhook de pagamento). Isso significa que:
- Antes do Pago, o PV não tem previsão de produção calculada
- Mudar o tipo de envio depois do Pago não recalcula automaticamente a previsão (a previsão foi cristalizada)
- Se o tipo de envio muda antes do Liberado para pagamento, o cálculo usará o tipo correto quando o Pago vier
Caso especial: pedido tipo “retirada”
Pedidos que nascem com tipo de envio “retirada” (porque a Neofarma precisa retirar a receita física) não seguem a regra acima. A regra de retirada é: pediu hoje → data de amanhã. Este pedido entra no romaneio de retiradas (filtro previsão de produção com a data). Quando a receita chega, a Atendente muda o tipo de envio para o definitivo (12h, 15h, 17h, 19h) e só então libera para pagamento — o cálculo de previsão acontece com o tipo de envio definitivo. Ver Fase 1 — Recepção da prescrição e criação do pedido para o fluxo completo.
Regra de consistência entre Previsão e Retirada
A data de retirada definida pela Atendente no REQ deve respeitar a seguinte regra:
| Cenário | Retirada vs. Previsão | Ação necessária | Quem resolve |
|---|---|---|---|
| Normal | Retirada = Previsão | Nenhuma — caso padrão | — |
| Postergado | Retirada > Previsão | Legítimo (cliente pediu pra depois, logística) — o pedido aparece no filtro “produção” do ERP antes de aparecer no filtro do sistema de produção | Atendente define, sem aprovação |
| Antecipado | Retirada < Previsão | Requer marcação como prioridade pela gerente de atendimento | Atendente solicita → Gerente de atendimento aprova e marca |
Mecanismo de prioridade
- Quem pode marcar: Somente a Gerente de Atendimento, mediante solicitação da Atendente
- Efeito no ERP: Flag de prioridade na lista de pedidos + o sistema traz a data de previsão de produção para hoje
- Efeito físico: Precisa reimprimir o papel/documento do pedido (o rótulo/REQ impressa antes da marcação não reflete a prioridade)
- Custo operacional: A reimpressão é um custo real que reforça por que a validação de datas no JSON da conferência automática deve pegar esse cenário ANTES da impressão
Fluxo de urgência (pedido sem pagamento)
Urgências entram fora do fluxo normal — o pedido precisa ser produzido hoje, mas ainda não foi pago. A Gerente de Atendimento é quem resolve isso. Exemplo típico: cliente ligou com pedido urgente, não há tempo para esperar o gateway.
Passo a passo da urgência:
- Atendente cria PV e REQ normalmente — PV com tipo de envio, REQ com data de retirada (que pode ser amanhã no caso normal)
- Gerente de Atendimento analisa PV e REQ — avalia se a urgência é legítima e o pedido está correto
- Gerente marca prioridade no PV — previsão de produção automaticamente vira hoje, mesmo que a data de retirada no REQ esteja para amanhã (data de previsão fica inferior à de retirada — coerente)
- Gerente registra pagamento manual — avança o pedido para Pago manualmente, sem passar pelo webhook do gateway. Meio de pagamento: “crédito cliente” (indica que o pagamento será cobrado depois ou o cliente tem crédito)
- JSON consolidado é formado e vai para Triagem — a partir daqui, segue o fluxo normal: conferência automática → Triagem → produção
Por que funciona: a previsão = hoje faz o pedido aparecer nos filtros do dia. A retirada no REQ pode ser amanhã — a produção filtra por retirada, mas a prioridade garante que o pedido é visível e priorizado. Na Triagem, o Farm. Triagista vê que a previsão é inferior à retirada, o que é consistente com prioridade marcada — não questiona.
Quem pode fazer isso: somente a Gerente de Atendimento. A Atendente não tem autonomia para registrar pagamento manual nem marcar prioridade. Ver seção “Papel: Gerente de Atendimento” abaixo.
Papel: Gerente de Atendimento
A Gerente de Atendimento é um papel distinto da Atendente — não é apenas uma Atendente sênior. Suas atribuições exclusivas (ações que a Atendente não pode fazer):
| Atribuição exclusiva | Quando usa | Impacto |
|---|---|---|
| Marcar prioridade no PV | Pedido precisa ser antecipado (urgência) | Previsão de produção vira hoje, requer reimpressão |
| Registrar pagamento manual (crédito cliente) | Urgência sem pagamento do gateway | Pedido avança para Pago sem webhook, cobrança posterior |
⚠️ Este papel tem escopo mais amplo que o documentado aqui — outras atribuições serão detalhadas conforme emergirem de ocorrências.
Tipos de envio e a hora como critério de priorização
A hora da data de retirada no REQ não é apenas um horário — ela codifica o tipo de envio e funciona como critério de priorização dentro do dia. A produção ordena a fila por hora: 12h sai primeiro, 19h sai por último.
Envios regulares (pacotes do dia)
Os quatro tipos de envio regular correspondem a quatro horários de corte. Cada um representa um “pacote” que sai da Neofarma num horário fixo:
| Hora no REQ | Tipo de envio | Posição na fila |
|---|---|---|
| 12:00 | Tipo 12h | Primeiro do dia |
| 15:00 | Tipo 15h | Segundo |
| 17:00 | Tipo 17h | Terceiro |
| 19:00 | Tipo 19h | Último |
Regras de consistência para envios regulares:
- Todos os dígitos da REQ devem ter a mesma hora (12:00, 15:00, 17:00 ou 19:00)
- A hora da REQ deve ser consistente com o tipo de envio do PV
- O sistema trava (bloqueia avanço) se qualquer uma dessas regras for violada
Envios fora do pacote (esporádicos e extras)
Pedidos que não fazem parte dos 4 pacotes regulares do dia usam o marcador :30 nos minutos para se diferenciar. Isso é uma convenção operacional — quando a produção vê :30, sabe que é um envio fora do pacote normal.
| Situação | Tipo de envio no PV | Hora no REQ | Trava hora × tipo | Observação |
|---|---|---|---|---|
| Esporádico puro (não é de nenhum dos 4 tipos) | Esporádico | hh:30 (qualquer hora, com :30) | Desativada | Catch-all para envios avulsos |
| Extra do tipo 17h (fora do pacote regular de 17h) | 17h | 17:30 | Desativada (porque :30) | Diferencia do pacote regular 17:00 |
| Extra do tipo 19h (fora do pacote regular de 19h) | 19h | 19:30 | Desativada (porque :30) | Diferencia do pacote regular 19:00 |
Regras para envios fora do pacote:
- O marcador :30 desativa a trava de consistência hora × tipo de envio (porque o pedido é, por definição, uma exceção)
- Extras 17:30 e 19:30 provavelmente são prioridade (estão sendo forçados fora do fluxo normal), mas não necessariamente — podem ser envios avulsos sem urgência
- Esporádico é o tipo para quando o envio não se encaixa em nenhum dos 4 tipos regulares e também não é 17h nem 19h
- A trava de igualdade de hora entre dígitos do REQ continua valendo (todos :30 ou todos :00 do mesmo horário)
- Pedidos :30 NUNCA entram no romaneio regular de nenhum dos 4 pacotes. São despachados avulsos pela expedição. É como se fossem do tipo “19h/esporádico” — seguem a regra de cálculo de prazo do horário base, mas não fazem parte do pacote de envio regular. O romaneio lista apenas pedidos com hora :00.
Resumo das regras de validação de hora
| Regra | Se hora :00 | Se hora :30 |
|---|---|---|
| Hora igual entre todos os dígitos da REQ | Trava se diferente | Trava se diferente |
| Hora × tipo de envio do PV | Trava se inconsistente | Não trava (esporádico/extra por definição) |
Como cada etapa enxerga o trabalho do dia
Todas as etapas de produção usam a mesma lógica base para montar a fila de trabalho, com variações conforme o foco de cada uma.
Filtro padrão da produção (Triagem → Manipulação → Conferência 1 → Conferência 2 → Fechamento)
- Filtro de status: Só o que está parado na minha etapa
- Filtro de data: Data de retirada da REQ = hoje
- Ordenação: Por hora (12:00 primeiro → 15:00 → 17:00 → 19:00, com :30 intercalados após o :00 correspondente)
Este é o padrão universal. A pessoa da produção abre o sistema, filtra pela sua etapa e pela data de hoje, e trabalha na ordem de hora. Os 12:00 saem primeiro porque o pacote de 12h é o primeiro a sair da Neofarma.
Particularidades por etapa
| Etapa | Filtro | Foco além do filtro padrão | Verifica datas? |
|---|---|---|---|
| Triagem (Ag. Triagem) | Padrão | Viabilidade técnica + consistência de dados do paciente | Sim — observa se retirada < previsão sem prioridade marcada |
| Manipulação (Triado) | Padrão | Separação de MP, pesagem, envase conforme REQ | Não — foco na execução técnica |
| Conferência 1 (Conferência 1) | Padrão | Produto produzido × REQ | Não — foco na conformidade do produto |
| Conferência 2 (Conferência 2) | Padrão | Produto × REQ × PV × OCR | Não — foco na conformidade documental completa |
| Fechamento (Produzido) | Padrão | Montagem da caixa — todos os produtos do pedido prontos | Sim — observa se data de retirada é coerente (se está atrasado, sinalizável) |
A Triagem é o último gate humano antes da produção começar de fato. Além das verificações técnicas (ativos, dosagens, interações), o Farm. Triagista é quem questiona a data: “esse pedido tem retirada anterior à previsão e não tem prioridade — foi intencional?“.
O Fechamento também observa datas porque é o ponto de transição para expedição — se o pedido está atrasado em relação à retirada prometida, isso é informação relevante para a expedição organizar o romaneio.
Filtro da Expedição (diferente do padrão)
A Expedição usa lógica diferente de todas as outras etapas:
- Filtro de status: Somente pedidos em Fechado
- Sem filtro de data explícito: Tudo que está Fechado é candidato a despacho
- Ordenação: Por tipo de envio (12h, 15h, 17h, 19h) — monta romaneio por pacote
- Bloqueio: Flag de alerta da Atendente impede despacho (pedido visível mas bloqueado)
Gap atual: ausência do status Postado
Hoje “Fechado” é a última etapa no ERP. Isso gera ambiguidade na expedição:
| O que está em Fechado | O que significa | Ação |
|---|---|---|
| Fechou hoje | Pronto para enviar | Expedição despacha |
| Fechou ontem | Deveria ter sido enviado ontem | Se foi enviado: deveria estar em Postado (que não existe). Se não foi: problema |
Workaround atual: Assumir que tudo que fechou ontem já foi enviado. Se NÃO foi enviado, voltar o pedido para Ag. Fechamento e alguém avança novamente — fazendo-o aparecer como Fechado hoje na fila da Expedição.
Solução futura: Status Postado entre Fechado e Entregue. Fechado = pronto para enviar. Postado = já saiu. Elimina a ambiguidade.
Dois sistemas, dois filtros — e quem usa cada um
O ERP de vendas e o sistema de produção têm filtros que olham datas diferentes do mesmo pedido. Além disso, o Administrativo usa o filtro do ERP de vendas para um propósito diferente da produção.
| Sistema | Filtro | Data que olha | Quem usa | Para quê |
|---|---|---|---|---|
| ERP de vendas | Filtro “produção” | Previsão de produção (calculada do PV) | Administrativo (D-1) | Gerar etiquetas e NFs para amanhã |
| ERP de vendas | Filtro por status | Status Fechado | Expedição (fim do dia) | Exportar romaneio (CSV) por tipo de envio |
| Sistema de produção | Filtro de data de retirada | Data de retirada (inserida no REQ) | Toda a produção (Triagem→Fechamento) | Montar fila do dia |
Ver faturamento-romaneio-rastreio para o ciclo completo do Administrativo (etiquetas D-1, romaneio, rastreios).
Se a Atendente coloca retirada > previsão, o pedido aparece no filtro do ERP (previsão = hoje) mas NÃO no filtro da produção (retirada = amanhã). A produção não o vê, o que é correto — mas alguém olhando o filtro do ERP pode pensar que a produção está atrasada.
Se a Atendente coloca retirada < previsão (com prioridade), o pedido aparece nos dois filtros no mesmo dia (prioridade traz previsão para hoje).
Mudança proposta: A validação de datas no JSON da conferência automática deve sinalizar divergência entre Retirada e Previsão para que a discrepância seja visível antes de entrar na produção, não depois.
Relação com outros processos
Este documento é referência transversal para:
- geracao-req-producao — onde a Atendente define a data de retirada e a hora/tipo de envio
- conferencia-automatica-ag-impressao — onde a validação de datas e horas acontece (ou deveria acontecer)
- triagem-tecnica — onde o Farm. Triagista questiona inconsistências de data
- manipulacao — onde o Manipulador usa o filtro padrão para montar a fila do dia
- conferencia-producao — onde Conferência 1 e 2 usam o filtro padrão
- expedicao-e-transporte — onde a Expedição usa filtro diferente (Fechado, sem data, por tipo de envio)
- faturamento-romaneio-rastreio — onde o Administrativo usa o filtro de previsão para etiquetas D-1 e a Expedição exporta romaneio CSV
- mapa-responsabilidades-etapas — mapa geral de responsabilidades por etapa
- referencia-sistema-erp — índice de mecanismos de sistema. Este processo é fonte canônica para: webhook pagamento (#1), trava hora×tipo (#10), filtros (#12-14), cálculo previsão (#15)
Histórico de evolução
| Data | Mudança | Motivação |
|---|---|---|
| 2026-04-06 | Criação do documento com: 3 datas, regras de consistência, mecanismo de prioridade, tipos de envio (regular + esporádico + extras com :30), filtros por etapa, dois sistemas/dois filtros, gap do Postado | 2026-04-06-processos-sem-regras-datas-filtros-envio — sessão de detalhamento com João |
| 2026-04-06 | Tabela “Dois sistemas, dois filtros” expandida para 3 linhas: adicionado filtro do Administrativo (previsão D-1 para etiquetas) e filtro da Expedição (Fechado para romaneio CSV). Adicionado link para faturamento-romaneio-rastreio | 2026-04-06-faturamento-rastreio-sem-processo |
| 2026-04-06 | Adicionados: fluxo completo de urgência (Gerente de Atendimento marca prioridade + registra Pago manual com crédito cliente, sem webhook), papel Gerente de Atendimento com tabela de atribuições exclusivas | Detalhamento com João — urgências e papel Gerente de Atendimento |