# Pedidos do portal vs. pedidos do vendedor — como se relacionam

> Um pedido pode nascer em dois lugares — o portal do cliente ou o CRM — e, uma vez dentro do CRM, os dois seguem o mesmo ciclo de vida. Aqui explicamos a diferença e o processo que eles compartilham.

## Passos

1. Um pedido pode ter duas origens: (1) um vendedor o monta dentro do CRM (Vendas / Devoluções → Pedidos → Novo pedido), ou (2) um cliente o envia pelo portal web. Os dois acabam sendo o mesmo tipo de documento (um pedido de venda) na mesma lista.

   ![Passo 1](https://www.selbuk.com/img/help/order-portal-vs-crm/1.webp)

2. Diferencie-os pela ORIGEM do documento, não pelo cliente. Os pedidos do portal levam um selo turquesa «Portal», usam o prefixo de numeração WebO- e ficam em nome do usuário do sistema «WEB». Os pedidos do CRM usam sua numeração normal (por exemplo SO-) e ficam em nome do vendedor que os criou.
3. Ponto-chave: o selo «Portal» indica DE ONDE veio o documento, NÃO se o cliente tem acesso ao portal. Um cliente pode ter o portal habilitado e ainda assim ter pedidos ou orçamentos que um vendedor montou para ele no CRM — esses são documentos do CRM e NÃO mostram o selo Portal. Só os documentos que o cliente realmente enviou on-line (prefixos WebO- / WebE-) são marcados como Portal. O mesmo vale para o status «Pendente de revisão»: ele só aparece em documentos que de fato chegaram do portal.
4. O status INICIAL é diferente. Um pedido que você monta no CRM começa como «Não faturado» (um pedido de trabalho normal, pronto para despachar ou converter). Um pedido do portal que acabou de chegar e que ninguém viu aparece como «Pendente de revisão» — uma marca âmbar que só existe no CRM e que significa «um pedido do portal que ninguém revisou». Por baixo, continua sendo um pedido não faturado no banco de dados.
5. Revisar um pedido do portal: abra-o e confirme linha por linha as quantidades que você realmente consegue atender. Se não conseguir cobrir tudo, a falta fica pendente de entrega. Depois de revisado, ele deixa de estar «Pendente de revisão» e se comporta como qualquer outro pedido não faturado. (Os pedidos do CRM pulam esse passo: foi você que os montou, então não há nada para revisar.)
6. Daqui em diante, o ciclo de vida é IDÊNTICO para as duas origens. Você o conduz com botões de ação, não com um seletor livre de status: Marcar como despachado (registra o despacho e o passa para Despachado quando tudo já saiu), Registrar pagamento (→ Pago), Converter em fatura ou Cancelar. O sistema faz cumprir as regras (só um pedido não faturado pode ser editado).
7. O portal se mantém sincronizado sozinho. Cada mudança de status que você faz no CRM se reflete no portal do cliente, então ele vê Aceito / Despachado / Faturado sem que você precise enviar nada. No portal, o status é somente leitura — só o CRM o altera.
8. O imposto é o mesmo seja qual for a origem: tanto os pedidos do portal quanto os do CRM são tributados conforme o modo de imposto da conta (veja «Imposto nos pedidos»). Um pedido do portal não tem «outro imposto» — ele simplesmente usou essa mesma configuração compartilhada quando o cliente o fez.
9. Se parecer que estão faltando pedidos do portal, é o filtro de usuário (por padrão mostra você). Escolha «Todos os usuários» ou «WEB», ou ative a Visão mestra. Veja «Pedidos e orçamentos que chegam do portal do cliente» e «Revise um pedido do portal linha por linha».

Abrir no SELBUK: https://webai.selbuk.com/sales-orders
Source: https://www.selbuk.com/pt/help/order-portal-vs-crm
