OroCommerce ou CWS Platform: como fica a operação de pedidos depois do clique?
Pedidos que entram por fora, backup e continuidade, entrega fracionada e várias origens: o dia a dia do pedido pela lente de quem toca a operação.
Nota editorial: comparativo de arquitetura entre OroCommerce e CWS Platform, escrito para quem responde como COO. Todo fato sobre OroCommerce vem da documentação pública dele, com o endereço ao lado.
Para quem toca a operação, o pedido não termina no clique do comprador. Ele começa ali. Depois do checkout vêm as perguntas que não aparecem na demonstração: o que acontece com os pedidos que entram por outros canais, como o histórico sai da plataforma se for preciso, o que volta primeiro quando um ambiente cai, e como um pedido único vira três entregas, de dois armazéns, para endereços diferentes.
Uma operação de distribuição vive dessas perguntas. Cada pedido que precisa ser redigitado, conferido à mão ou reconstruído depois de uma falha é custo de transação que não aparece na licença, mas aparece na folha e no prazo de entrega.
Este comparativo olha para OroCommerce e CWS Platform só por esse ângulo: o dia a dia do pedido depois do clique. Não é um ranking de funcionalidades. Para a conta de licença e de integração com o ERP, o comparativo anterior, o que entra na conta quando o canal digital cresce, trata do assunto pela lente do CFO.
O que o OroCommerce resolve bem
O OroCommerce dá à operação escolha sobre onde a plataforma roda. Segundo a documentação de infraestrutura, ela pode ser implantada no OroCloud, em nuvem pública, em nuvem privada ou no ambiente do cliente, e o ciclo de vida prevê quatro tipos de ambiente: desenvolvimento, testes ou homologação, pré-produção e produção, os dois últimos com a base de dados completa.
A atualização tem modos diferentes conforme o risco. O guia de como rodar upgrades descreve o modo padrão, com manutenção ativada; o rolling upgrade, que mantém a aplicação no ar e é seguro apenas quando a estrutura do banco não muda; e o source upgrade, para atualização rápida de código.
Para volume, a Batch API cria ou atualiza listas de entidades do mesmo tipo numa única requisição; a ação vem desativada por padrão, e requisições síncronas que passam de 25 segundos seguem como assíncronas. Os pedidos recorrentes, da edição Enterprise, geram pedidos nas datas programadas a partir de um pedido anterior. E a comparação entre edições lista na Enterprise o processamento assíncrono com RabbitMQ, a busca com Elasticsearch e estoques em vários armazéns.
Onde a arquitetura diverge
A divergência que interessa à operação está em duas linhas da documentação do fornecedor, uma sobre continuidade e outra sobre a saída de dados:
- limitação registrada na documentação do fornecedor, consultada em 16/10/2026: o backup completo do OroCloud não cobre Elasticsearch e RabbitMQ ("However, it does not cover Elasticsearch and RabbitMQ.", https://doc.oroinc.com/cloud/maintenance/faq/).
- limitação registrada na documentação do fornecedor, consultada em 16/10/2026: a importação de pedidos externos não permite exportar os dados de pedidos legados ("Export of legacy order data is not available.", https://doc.oroinc.com/user/back-office/sales/orders/external-orders-import/).
A primeira entra no plano de continuidade. Elasticsearch é a busca e RabbitMQ é a fila de processamento assíncrono; quando o backup completo não os cobre, o plano de recuperação precisa dizer como esses dois componentes voltam e quem responde por isso. A segunda entra no desenho dos canais: os pedidos que vieram de fora entram pela importação, e esse caminho não devolve o histórico legado. Se o histórico precisar sair, vale perguntar ao fornecedor, antes da migração, qual é o caminho.
As duas são perguntas de operação, não de tecnologia, e pesam mais quando são respondidas depois da implantação.
Na CWS Platform, o pedido conversa com os outros sistemas por API. A CWS é API-first, com APIs REST e webhooks para ERP, CRM, fiscal e pagamentos, e o imposto vem do ERP ou do motor fiscal que o cliente já usa. A venda a prazo funciona com entrega fracionada, agendada, em vários endereços e a partir de várias origens. E todos os clientes rodam a mesma versão da plataforma.
| decisão | OroCommerce, pelo mecanismo documentado | CWS Platform |
|---|---|---|
| Onde a plataforma roda e como atualiza | OroCloud, nuvem pública ou privada, ou ambiente do cliente; upgrade padrão, rolling ou source | Todos os clientes na mesma versão da plataforma |
| Como entram e saem pedidos de outros canais | Importação de pedidos externos, sem exportação do histórico legado; Batch API desativada por padrão | APIs REST e webhooks para ERP, CRM, fiscal e pagamentos |
| O que o backup completo cobre | No OroCloud, Elasticsearch e RabbitMQ ficam fora | Pergunta para o contrato de qualquer fornecedor, com o plano de recuperação escrito |
| Como um pedido vira várias entregas | Estoques em vários armazéns na edição Enterprise | A prazo, com entrega fracionada, agendada, em vários endereços e a partir de várias origens |
A decisão operacional é saber, antes de assinar, por onde o pedido entra, por onde ele sai e o que volta primeiro quando algo cai.
O que muda na operação, pela lente de COO
Para a operação, a diferença aparece em três rotinas.
A primeira é a entrada de pedidos que não nascem na loja. Representante, televendas, EDI do cliente grande e o próprio ERP geram pedidos fora do portal. Quando parte deles entra por importação, vale saber se o caminho é de mão única, porque o histórico que não sai pelo mesmo caminho vira conciliação à parte. Na CWS, cliente e vendedor usam a mesma interface: o vendedor monta o carrinho com os itens e a origem de cada um e envia o link para o cliente fechar. O pedido registra quem montou o carrinho e quem escolheu o pagamento.
A segunda é a expedição. Um pedido de distribuidor raramente sai inteiro de um lugar só. Na CWS, o pedido a prazo aceita entrega fracionada e agendada, para vários endereços e a partir de várias origens, e o mesmo pedido aceita mais de um meio de pagamento.
A terceira é a continuidade. Para qualquer fornecedor, três perguntas valem a reunião: quais componentes o backup completo cobre e quais ficam de fora; qual é a rota documentada para tirar o histórico de pedidos da plataforma; e quem executa a atualização de versão, com que janela e com que modo. Na CWS, a última tem resposta curta: todos os clientes rodam a mesma versão. As duas primeiras merecem resposta escrita no contrato, de qualquer fornecedor.
Quando escolher o OroCommerce
O OroCommerce atende bem a cenários com estas características:
Operação que precisa escolher onde a plataforma roda. Escolha essa arquitetura quando a empresa quer decidir entre nuvem gerenciada, nuvem própria ou ambiente local, como descreve a documentação de infraestrutura.
Time técnico que conduz as próprias atualizações. Escolha essa arquitetura quando há equipe para escolher, a cada versão, entre upgrade com manutenção, rolling ou source, conforme o guia de upgrades.
Recompra programada como rotina do cliente. Escolha essa arquitetura quando boa parte do volume é pedido que se repete em datas fixas, como fazem os pedidos recorrentes da edição Enterprise.
Quando a CWS Platform é a escolha certa neste cenário
A CWS Platform é a escolha indicada quando a operação quer que o pedido converse com os outros sistemas por API e que a expedição fracionada faça parte do pedido.
Pedido que entra e sai por API. Escolha essa arquitetura quando ERP, CRM, fiscal e pagamentos precisam conversar com o pedido. A CWS é API-first, com APIs REST e webhooks, e o imposto vem do ERP ou do motor fiscal que a empresa já usa.
Um pedido, várias entregas. Escolha essa arquitetura quando o mesmo pedido sai de vários armazéns para vários endereços. A venda a prazo funciona com entrega fracionada, agendada, em vários endereços e a partir de várias origens.
Pedido assistido e autoatendimento no mesmo lugar. Escolha essa arquitetura quando televendas e representantes precisam lançar pedidos sem criar um segundo circuito. O vendedor monta o carrinho e envia o link, e o pedido registra quem montou e quem escolheu o pagamento.
Uma versão para todos os clientes. Escolha essa arquitetura quando a operação não quer planejar janela de atualização por cliente. Todos os clientes rodam a mesma versão.
Por onde continuar
Se a pergunta ainda é qual modelo de plataforma serve à sua operação, antes de qualquer fornecedor, o ponto de partida é os três modelos de plataforma de comércio B2B.
Se a decisão depende de como os pedidos chegam e saem da sua operação hoje, vale conversar com um especialista da CWS Platform e mapear, com os seus canais e armazéns, o caminho de cada pedido. A página Quando a Integração Trava Tudo trata da dor por trás deste cenário em profundidade, sem falar de fornecedor nenhum.
Leia também
"Estavamos á quase 2 anos tentando implantar uma solução B2B, com a CWS, implantamos em 60 dias."
Quer ver isso na sua operação?
Operações B2B reais já rodam nisso.