Neofarma KB

Referência de Mecanismos de Sistema (ERP e Produção)

Leitura de 9 min

Objetivo

Centralizar todos os mecanismos de sistema (automatismos, APIs, webhooks, flags, filtros, travas) que operam no fluxo do pedido. Cada processo individual descreve o que a pessoa faz e o que o sistema faz naquela etapa — este documento é o índice inverso: dado um mecanismo de sistema, onde ele atua e qual processo o detalha.

Serve para responder perguntas como: “o que acontece automaticamente quando eu avanço para Ag. Impressão?”, “como funciona o pintar produto?”, “que flags existem no ERP?“.

Dois sistemas distintos

A Neofarma opera com dois sistemas que se comunicam por campos compartilhados, não por integração direta:

SistemaEscopoQuem usaO que contém
ERP de vendasCiclo comercial do pedido (Criado→Entregue)Atendente, Administrativo, ExpediçãoPedido de venda, cliente, produtos, preços, status, OCR, flags, filtro de previsão
Sistema de produçãoCiclo técnico (REQ→produto manipulado)Atendente (cria REQ), Produção inteiraPedido de produção (REQ), composição técnica, data/hora de retirada, séries

A ponte entre eles é a atribuição de REQ + séries ao pedido de venda (ver Fase 2). A partir dessa atribuição, o casamento é determinístico por reqNumber + reqSerie.

Cada sistema tem filtros próprios que olham datas diferentes. Ver Dois sistemas, dois filtros para a tabela completa.

Mecanismos automáticos (webhooks e triggers)

1. Webhook de pagamento (Liberado → Pago)

  • Trigger: Gateway de pagamento confirma pagamento
  • O que faz: Avança o pedido de Liberado para Pago automaticamente. Neste momento, o ERP calcula a data de previsão de produção com base na hora do pagamento e no tipo de envio
  • Exceção: Pagamento manual pela Gerente de Atendimento (crédito cliente) para urgências — sem webhook
  • Processo que detalha: Cálculo automático da data de previsão de produção

2. Webhook de Ag. Impressão (Pago → Ag. Impressão)

  • Trigger: Atendente avança pedido para Ag. Impressão (avanço manual, mas dispara webhook)
  • O que faz: Dispara a conferência automática dos 3 documentos (OCR × Pedido × REQ). O agente verificador coleta dados, confere em dois níveis, e emite veredito
  • Se aceito: Gera JSON consolidado + PDFs dos rótulos via API createLabel. Pedido permanece em Ag. Impressão
  • Se rejeitado: Pedido volta para Pago com relatório de rejeição
  • Processo que detalha: conferencia-automatica-ag-impressao

3. Avanço automático por produto (“pintar”)

  • Mecanismo: Cada produto do pedido é marcado individualmente no sistema (“pintado”). Quando todos os produtos do pedido estão pintados, o sistema avança automaticamente para a próxima etapa
  • Onde atua:
EtapaO que pintaQuem pintaEfeito quando todos pintados
Ag. Impressão → ImpressoRótulo abertoSetor de ImpressãoAvança para Impresso → Ag. Triagem (automático)
Conferência 1Produto conferido × REQConferenteAvança para Conferência 2
Conferência 2Produto conferido × REQ × PV × OCRConferenteAvança para Produzido (Fechamento)
Ag. Fechamento → FechadoMontagem da caixa confirmadaConferente/Expedição ou Administrativo (12h)Avança para Fechado
  • Regra: Se um produto não confere, não pintar. O pedido trava naquela etapa até todos os produtos serem resolvidos
  • Processos que detalham: conferencia-producao (Conf. 1, 2 e Fechamento), Fase 3 (impressão)

API e geração de documentos

4. API createLabel (geração de rótulos)

  • Input: JSON consolidado (gerado pela conferência automática)
  • Output: PDFs dos rótulos — 1 PDF por unidade de cada produto (se PV tem produto X com quantidade 2, gera 2 rótulos)
  • Dados que o rótulo contém: Nome do paciente (fonte prioritária: OCR), prescritor, composição (da REQ), posologia (do OCR), volume, forma farmacêutica
  • Momento: Etapa Ag. Impressão, após veredito aceito da conferência automática
  • Cristalização: Este é o ponto onde os dados se tornam físicos. Qualquer erro nos dados após esse ponto exige voltar até Pago para corrigir, regenerar JSON, e reimprimir
  • Processo que detalha: Fase 4a

5. JSON consolidado (estrutura de dados verificada)

  • O que é: Estrutura de dados que reúne informações dos 3 documentos (OCR, Pedido, REQ) após conferência automática. Cada campo indica a fonte, se há divergência, e o valor escolhido
  • Quem consome: API createLabel (gera rótulos), Triagem (referência para alertas de data), Conferências 1 e 2 (referência de dados verificados)
  • Estrutura completa: Ver Fase 4a — inclui bloco global (paciente, prescritor, comprador, destinatário, envio, datas, preço, contagem) e bloco por produto (identificação, apresentação, composição, posologia, pessoas, preço)
  • Campos de destaque:
    • envio.conferencia_hora_tipo — resultado da validação hora × tipo de envio
    • datas.alerta — sinaliza divergência entre data de retirada e previsão (consumido pela Triagem)
    • produtos[].composicao.ativos[].conferencia — resultado da comparação ativo a ativo entre OCR e REQ

6. Documentos gerados no PV (disponíveis após Ag. Impressão)

#DocumentoFonteGeraçãoQuantidade
1Prescrição (arquivo da receita)OCR (receita digitalizada)Anexada pelo Atendente1 por pedido
2Validação da assinatura do prescritorSistema de validaçãoGerada da assinatura digital1 por pedido
3Comando de produção (ficha de pesagem)REQGerado dos dados da REQ1 por pedido (cobre todos os dígitos)
4RótulosJSON consolidado → API createLabelGerados automaticamenteN rótulos (1 por unidade de cada produto)
5Registro de entregaSistema (flag por produto)Gerado se flag “registro de entrega” existe1 por produto com flag (só envio 19h)

O Setor de Impressão imprime todos os 5 documentos — é executor puro. Detalhamento completo em Documentos disponíveis no PV após Ag. Impressão.

Flags e travas do ERP

7. Flag de alerta (bloqueio de expedição)

  • Quem marca: Atendente, no pedido de venda dentro do ERP
  • Efeito: Impede o sistema de avançar de Produzido para Postado. Pedido fica visível mas bloqueado na fila da Expedição
  • Uso típico: “Cliente pediu para segurar envio”, “aguardando confirmação de endereço”
  • Quem resolve: Atendente remove o flag após resolver a pendência
  • Processo que detalha: Pré-requisitos para avançar de Produzido para Postado

8. Flag de prioridade

  • Quem marca: Somente Gerente de Atendimento (atribuição exclusiva)
  • Efeito: Previsão de produção automaticamente vira hoje. Exige reimpressão de documentos (rótulo/REQ impressa antes não reflete a prioridade)
  • Uso típico: Pedido com retirada < previsão (antecipação), urgência
  • Processo que detalha: Mecanismo de prioridade

9. Flag de registro de entrega (por produto)

  • Quem marca: Quem cria o PV (Atendente ou Gerente de Atendimento), no campo do item dentro do pedido
  • Efeito: Sistema gera automaticamente guia de transporte para aquele produto
  • Escopo: Por produto (não por pedido) — num mesmo pedido 19h, pode haver produtos com e sem o flag
  • Quem imprime: Setor de Impressão (regra); Conferente na Conf. 2 (fallback se não veio no pacote)
  • Se não marcou: A guia não existe em nenhum lugar — o produto segue sem ela
  • Processo que detalha: Registro de entrega especial (flag por produto, envio 19h)

10. Trava de consistência hora × tipo de envio

  • O que trava: Sistema bloqueia avanço se hora :00 da REQ for inconsistente com tipo de envio do PV (ex: hora 15:00 mas tipo de envio é 12h)
  • Quando desativa: Horas com :30 (esporádicos/extras) — a trava é desativada por definição
  • Trava adicional: Todos os dígitos da REQ devem ter a mesma hora e a mesma data — se diferentes, trava
  • Processo que detalha: Resumo das regras de validação de hora

11. Mecanismo de “segurar” pedido (não é flag)

  • Como funciona: Atendente simplesmente não avança o pedido para Fechado, mesmo com todos os itens conferidos. Como o filtro da Expedição só mostra Fechados, o pedido não aparece na fila
  • Diferença do flag de alerta: O flag bloqueia um pedido que já está em Fechado. O “segurar” impede que chegue a Fechado
  • Processo que detalha: Mecanismo de “segurar” pedido

Filtros e filas de trabalho

12. Filtro padrão da produção

  • Usado por: Triagem, Manipulação, Conferência 1, Conferência 2, Fechamento
  • Lógica: Status = minha etapa + Data de retirada da REQ = hoje + Ordenação por hora (12:00→19:00, :30 intercalados)
  • Sistema: Sistema de produção (não ERP de vendas)
  • Processo que detalha: Como cada etapa enxerga o trabalho do dia

13. Filtro de previsão de produção (Administrativo D-1)

  • Usado por: Administrativo, para preparar etiquetas e NFs do dia seguinte
  • Lógica: Previsão de produção = amanhã (filtro “produção” do ERP de vendas)
  • Sistema: ERP de vendas
  • Diferença do filtro de produção: Olha previsão (calculada no Pago), não retirada (inserida na REQ). Na maioria dos casos coincidem, mas podem divergir
  • Processo que detalha: Fase 1

14. Filtro da Expedição

  • Usado por: Expedição
  • Lógica: Status = Fechado + Sem filtro de data + Ordenação por tipo de envio/hora
  • Sistema: ERP de vendas
  • Diferença: Único filtro sem data — tudo que está Fechado é candidato a despacho
  • Processo que detalha: Como a Expedição encontra o trabalho do dia

Cálculos automáticos

15. Cálculo de previsão de produção

  • Momento: Instante do status Pago (webhook ou manual)
  • Variáveis: Hora do pagamento (antes/depois das 14h) + tipo de envio do PV
  • Resultado: D+1 para 17h/19h pagos antes das 14h; D+2 para 12h/15h pagos antes das 14h; +1 dia adicional se pago depois das 14h
  • Cristalização: Calculada uma única vez. Mudar tipo de envio depois do Pago não recalcula a previsão
  • Processo que detalha: Cálculo automático da data de previsão de produção

16. Numeração da REQ

  • Formato: 6 dígitos sequenciais (ex: 204583). Cada produto do pedido recebe uma série sequencial (204583-1, 204583-2, 204583-3)
  • Gerado por: Sistema de produção, ao criar o pedido de produção
  • Uso: Identificador único do produto em todas as etapas seguintes. O casamento PV ↔ REQ é feito por reqNumber + reqSerie
  • Processo que detalha: Fase 1

Integrações externas

17. Sistema externo de etiquetas

  • Fluxo: Administrativo exporta CSV do ERP de vendas → importa no sistema de etiquetas → gera etiquetas + NFs → imprime
  • Quando: D-1 (dia anterior à produção), antes das 19h
  • Processo que detalha: Fase 1

18. Exportação de romaneio (CSV para transportadora)

  • Fluxo: Expedição filtra Fechados por tipo de envio → exporta CSV do ERP → envia para transportadora
  • Quando: D, fim do dia (19h). Um CSV por tipo de envio (12h, 15h, 17h, 19h). Pedidos :30 ficam fora do romaneio regular
  • Processo que detalha: Fase 3

Gaps de sistema conhecidos

Gap: ausência do status Postado

Hoje “Fechado” é a última etapa no ERP, causando ambiguidade (Fechado hoje = pronto para enviar; Fechado ontem = deveria ter sido enviado). Workaround: voltar para Ag. Fechamento e avançar de novo. Solução futura: status Postado entre Fechado e Entregue. Ver Gap atual: ausência do status Postado.

Gap: previsão cristalizada no Pago

Mudar tipo de envio depois do Pago não recalcula a previsão. Se o tipo muda (ex: de 12h para 19h por pedido do cliente), a previsão continua com base no tipo original. Impacto: Administrativo pode gerar etiqueta baseada em previsão errada.

Relação com outros processos

Este documento é referência transversal para todos os processos da Cadeia 1:

Histórico de evolução

DataMudançaMotivação
2026-04-06Criação do documento centralizando 18 mecanismos de sistema já documentados nos processos individuais: webhooks (2), pintar (1), API (1), JSON (1), documentos PV (1), flags (3), travas (1), mecanismos (1), filtros (3), cálculos (2), integrações (2), gaps (2)Sessão com João — agregar detalhes de sistema na documentação de processos

Visão de gráfico

Backlinks