Skip to main content

Canal Omni

Pedido criado pelo vendedor na loja física com entrega em domicílio ou retirada em outra unidade.

Implementação recente Canal adicionado em maio de 2026 — commit 2b74ab7 ("IMPLEMENTACAO VENDA OMNI"). É o canal com a lógica mais complexa do endpoint, usando 4 CTEs e um SELECT final.

Fluxo do pedido omni

Cliente na loja atendimento presencial Pedido pelo site vendedor cria pedido no sistema integrado Orçamento omni tipo_estoque = ORCAMENTO id_grupo_operacao = 192 id_tipo_movimentacao = 6 fulfillment do pedido Venda vinculada movimentacao_movimentacao Retirada outra unidade pedido transita entre lojas JSON omni[] retirada entrega Figura 7 - Fluxo completo de um pedido omni-channel.

O cliente vai fisicamente até a loja. O vendedor, usando o sistema, cria o pedido pelo site (plataforma de e-commerce VTEX). A partir daí, existem duas possibilidades de fulfillment:

  • Cliente vai à loja
    Vendedor atende o cliente presencialmente e registra o pedido no sistema via plataforma web.
  • Pedido criado pelo site
    O sistema gera um orçamento (tipo_estoque = 'ORCAMENTO') com id_tipo_movimentacao = 6 e id_grupo_operacao = 192.
  • Fulfillment: Entrega em domicílio
    O produto é despachado para o endereço do cliente — a venda real é registrada como saída no sistema e vinculada ao orçamento via movimentacao_movimentacao.
  • Fulfillment: Retirada em outra unidade
    O cliente retira o produto em uma loja diferente da que realizou a venda — o pedido transita entre unidades antes de ser entregue.

Identificadores do canal omni

Identificamos os pedidos omni pela combinação de três campos em movimentacao:

Campo Valor Significado
id_grupo_operacao 192 Grupo de operação exclusivo do canal omni
id_tipo_movimentacao 6 Tipo de movimentação omni
tipo_estoque 'ORCAMENTO' Registrado como orçamento — não movimenta estoque diretamente
situacao 'Confirmado' ou 'Finalizado' Buscamos apenas pedidos que resultaram em venda real

Estrutura da query (4 CTEs)

CTEs em ordem de execução
  1. e — filtra a entidade (loja) pelo CNPJ
  2. orcamento — busca orçamentos omni confirmados/finalizados no período
  3. mm — busca vínculos em movimentacao_movimentacao para localizar a venda real (SAIDA)
  4. i — busca os itens do orçamento via movimentacao_detalhe na implementação atual
  5. SELECT final — une orçamento + vendedor + itens

Retorno da API

// Um elemento do array "omni"
{
  "id_cliente":      456,
  "cod_vendedor":    "V007",
  "cnpj_emp":        "12345678000190",
  "data_documento":  "2026-05-20 16:45:00",        // Data da venda vinculada, sem conversão ISO no método atual
  "id_pessoa":       88,                             // ID do vendedor em pessoa
  "identificador":   3001,                           // ID da movimentação de venda vinculada
  "transacao":       3001,
  "usuario":         42,
  "documento":       "ORÇ-00321",
  "vendedor":        "João Silva",                   // Nome completo do vendedor
  "cancelado":       "N",
  "itens": [
    {
      "cod_produto":        "PROD-099",
      "descricao_produto":  "Tênis Running 42",
      "cod_barra":          "7896543219870",
      "quantidade":         1,
      "preco_unitario":     349.90,
      "valor_total":        349.90
    }
  ]
}
Itens e cabeçalho vêm de fontes diferentes Na implementação atual, o cabeçalho usa a movimentação vinculada pela tabela movimentacao_movimentacao, mas a CTE i busca os itens do orçamento (i.id_movimentacao = orcamento.id_movimentacao). Como o join com os itens é interno, se o orçamento não tiver itens ativos o registro omni não é retornado.