Módulo determinístico
Gestão de pedidos B2B: Order Management System (OMS, também Seller Center)
A venda foi fechada, e é aí que começa a gestão de pedidos B2B, o trabalho que ninguém mostra em demonstração. O pedido aparece como "em separação" para o comprador, como "faturado" no ERP e como uma dúvida no grupo do WhatsApp do vendedor. Alguém marcou enviado antes de despachar, o cliente liga para o vendedor, o vendedor liga para a expedição, e o custo dessa reconciliação não entra em nenhuma planilha.
Em resumo
Gestão de pedidos B2B é tudo o que acontece com o pedido depois que a venda fecha: aprovação, faturamento, envio, entrega e devolução. Na CWS Platform, o Order Management System (OMS) roda dez estados orientados a evento, e o pedido só avança quando a condição do estágio está comprovada, como o número do pedido no ERP ou o código de rastreio, com um registro só para comprador, seller e ERP.
- Quem pode vender, como as ofertas concorrem e como o valor se divide é definido no módulo de marketplace. Fonte: Marketplace Management Platform (Marketplace Center).
- No marketplace governado, o pedido chega dividido por origem. Fonte: marketplace B2B governado.
- Na rede de concessionárias, um pedido do consumidor pode sair de várias concessionárias e da fábrica. Fonte: portal da concessionária.
- O ERP segue como sistema de registro, integrado por APIs e webhooks. Fonte: APIs e integrações.
Integração com o ERP que você já tem é um dos critérios do guia para escolher uma plataforma de ecommerce B2B.
O que é
O módulo que orquestra o ciclo do pedido depois que ele existe. São dez estados orientados a evento, do pré-pedido ao entregue e concluído, mais os desfechos de cancelado, extraviado e devolvido, e o pedido só muda de estado quando o evento correspondente acontece de verdade. Os estados iniciais são gerados pela própria plataforma e não podem ser alterados pela integração; quando o pedido passa do limite de crédito, a regra da loja decide se ele fica bloqueado, segue para análise ou é finalizado como pago; e pré-pedidos abandonados podem ser cancelados automaticamente depois de um prazo configurável, inclusive por categoria. Ele é a mesma máquina vista de dois lados: o lojista a chama de Canal da Loja, a operação e o ERP a chamam de Order Management System. Quem pode vender, como as ofertas concorrem e como o valor se divide são perguntas do Marketplace Center; aqui a pergunta é onde está este pedido e o que já aconteceu com ele.
A capacidade que ninguém replica
O estado não avança porque alguém clicou, avança porque a condição foi satisfeita
Na maioria dos sistemas o status é um rótulo que alguém troca, e por isso ele mente. Aqui cada estágio tem uma condição de entrada: READY exige o número do pedido no ERP, e os dados da nota fiscal podem ir junto, em READY ou em SHIPPED, ou ser obrigatórios, se a operação configurar assim no processo de venda; SHIPPED exige o código de rastreio, vindo da integração direta com os Correios, de outra transportadora integrada ou do link do sistema próprio, CANCELED exige um motivo, que é comunicado ao cliente, e a modalidade de frete que precisa das dimensões da embalagem não deixa o pedido sair sem elas. O fluxo só anda para a frente: pedido enviado não volta para pronto para envio, e dali só segue para entregue, cancelado ou devolvido. Entregue sem contestação, ele passa sozinho a concluído ao fim do prazo de arrependimento. O status deixa de ser o que a operação diz que fez e passa a ser o que ela comprovou, e é essa diferença que torna o dado confiável o bastante para o financeiro e para o cliente dependerem dele.
O mesmo pedido, três leituras que não podem divergir
O comprador acompanha pelo portal, o lojista opera no Canal da Loja e o ERP consulta e atualiza por API. Não são três cópias sincronizadas de tempos em tempos, é o mesmo registro lido de três lugares, e cada pedido carrega de onde a venda partiu e quem é responsável por entregá-la. Num pedido com vários sellers isso deixa de ser detalhe: sem essa marcação, ninguém sabe de quem cobrar qual parte. Por isso o pedido pai controla o carrinho agregado e se divide em pedidos filhos por loja e por depósito, cada um com produtos, valor, frete, prazo de preparo e nota fiscal próprios; cada fornecedor configura seus pagamentos de forma independente, dentro dos critérios gerais do dono do portal, e só a credencial do seller que vendeu atualiza o status da parte dele. Quando crédito e faturamento precisam sair numa nota só, a loja pode restringir cada pedido a um único depósito ou a uma única loja.
Cancelar um pedido é uma permissão, não um botão
Deixar o seller cancelar sozinho parece uma gentileza operacional, e é a porta de entrada dos piores comportamentos de um marketplace. A plataforma trata isso como decisão de governança e a mantém fechada por padrão, porque conhece o que acontece quando ela é aberta sem critério:
- Estoque que não existe. O item aparece disponível, o pedido entra, e o cancelamento vira o conserto de um anúncio que nunca foi verdadeiro.
- Renegociação depois da venda. O preço combinado no portal vira ponto de partida, e a falta de estoque vira argumento para pedir mais.
- Disputa de pedido. Sellers escolhem os pedidos bons e devolvem os ruins, e o comprador paga a conta em prazo.
- Venda por fora. O pedido é cancelado na plataforma e refeito no particular, com o dado do comprador que a plataforma entregou.
Por isso a permissão não nasce do seller: quem a libera é a loja de origem do pedido, numa configuração dela. Enquanto a loja de origem não habilita, o seller não cancela e quem cancela é ela; o cancelamento exige motivo registrado; e pedido já aprovado no meio de pagamento fica travado mesmo com a permissão ativa. Faz sentido abrir quando não há disputa, como na operação em que cada seller responde por uma área própria. O ponto não é o botão, é quem responde pela consequência dele.
O pedido continua sob gestão
Painel do Vendedor da loja de demonstração, com chips de status e contagens, incluindo Em andamento 4, Pré-encomenda 5 e Em Aprovação Comercial 3.
- Ciclo de vida visívelos chips organizam os pedidos pelos diferentes estados da operação.
- Aprovação comerciala negociação mantém um ponto explícito de decisão humana.
- Filtros operacionaisstatus, data, cliente e outros campos ajudam a localizar pedidos na tabela.
Abaixo, filtros por coluna e uma tabela de pedidos.
O OMS entra neste ponto para provar que a jornada não termina na criação do pedido. Cada negociação segue por estados operacionais visíveis, inclusive pela aprovação comercial, onde o vendedor atua como decisão humana dentro de um fluxo digital mensurável.
Persona · Vendedor de distribuidora
O pedido anda sozinho, e eu só entro quando aparece uma exceção.
No Order Management System (OMS), o pedido só avança com a condição comprovada, e comprador, seller e ERP leem o mesmo registro.
Persona · Fornecedora, seller do marketplace
Cuido só da minha parte do pedido, com frete, prazo e nota próprios.
No Order Management System (OMS), o pedido vira pedidos filhos por loja, e só o seller que vendeu atualiza o status da parte dele.
Em operação
Imdepa · distribuição de autopeças
cerca de 60 mil pedidos
processados em 3 anos de portal B2B, com 153 clientes ativados e cerca de 25 mil sessões por mês.
Volume dessa ordem não se sustenta com status conferido na mão. O ciclo do pedido roda sozinho porque cada avanço tem uma condição objetiva, e o vendedor que antes gastava a maior parte do tempo processando pedido passou a acompanhar exceção, que é o único lugar onde ele é insubstituível.
Ler o caso Imdepa →APIs deste módulo
O que este módulo faz no painel o seu sistema também faz por API. Estes são os grupos dele na referência pública da API.
Webhooks e callbacks
- Webhook de pedidos
Aviso curto de pedido, com id e status.
- Webhook de pedidos, payload completo
O pedido inteiro no corpo da notificação.
Perguntas frequentes
O meu cliente consegue saber onde o pedido está sem ligar para alguém?
Sim, e sem depender de alguém lembrar de avisar. O comprador acompanha o pedido pelo próprio portal, com a etapa atual e o código de rastreio quando a modalidade de frete tem rastreio, e recebe mensagem automática nas viradas que importam: pedido concluído, pagamento confirmado e despacho. Quando a loja opera o pedido pelo painel, cada atualização de status ou de dados gera e-mail ao cliente, que vê a etapa, a loja fornecedora e o prazo na própria conta. O rastreio vem da integração direta com os Correios, de outra transportadora integrada ou do link do sistema próprio da loja no campo de rastreio. Num pedido com itens de sellers diferentes, cada lojista comunica a evolução da parte que é dele, porque cada parte tem prazo e transportadora próprios.
Quem emite a nota fiscal, a plataforma ou o meu sistema?
O seu. A emissão é procedimento fiscal da empresa e continua no sistema que já a emite hoje; a plataforma recebe os dados da nota (número, série e data), que podem ir junto com a atualização de status, em READY ou em SHIPPED, ou ser exigidos, se a operação configurar a nota fiscal como obrigatória no processo de venda, e o XML ou PDF da nota já emitida; pela API, o XML vai pelo endpoint de nota fiscal. Essa fronteira é deliberada, e é o que evita duas verdades fiscais: o Order Management System não disputa a emissão com o seu ERP, ele registra no pedido a nota que o seu sistema emitiu.
O seller pode cancelar um pedido meu por conta própria?
Por padrão não, e essa é uma posição da plataforma, não uma limitação. Quem libera é a loja de origem do pedido, numa configuração dela: enquanto ela não habilita o cancelamento pelo seller, quem cancela é a própria loja de origem. O cancelamento exige motivo registrado. Além disso, pedido já aprovado no meio de pagamento não é cancelável pelo seller de forma alguma: ali só existe o fluxo formal de solicitação, com rastro.
O que é gestão de pedidos B2B?
Gestão de pedidos B2B é o trabalho de levar o pedido da colocação até a conclusão: aprovação, faturamento, separação, envio, entrega, e os cancelamentos e devoluções no caminho. No B2B ela ainda precisa manter um status só para o comprador, o seller e o ERP, porque cada um deles age sobre o mesmo pedido.
Que integrações um sistema de gestão de pedidos B2B precisa ter?
Com o ERP, antes de tudo, porque é ele que emite a nota fiscal e guarda estoque e financeiro; na CWS Platform o ERP consulta e atualiza o pedido por API, recebe o webhook de pedido logo após a geração, para processar sem depender de resposta em tempo real, e o pedido passa a READY com o número do pedido no ERP; os dados da nota fiscal podem ir junto, em READY ou em SHIPPED, e a operação pode configurar a nota fiscal como obrigatória no processo de venda. As modalidades de frete entram também, já que SHIPPED exige o código de rastreio e algumas modalidades exigem as dimensões da embalagem.