MedusaJS · eCommerce B2B componible
MedusaJS para eCommerce B2B: o motor é metade do projeto
Montar o motor de commerce é a parte que todo mundo pressuposta. Metade difícil —que o preço que o seu cliente vê é o que fatura o seu ERP— é a que ninguém te contou ainda. Essa é a nossa.
15 +
anos em eCommerce B2B e integração
100 +
integrações ERP em produção
middleware
próprio de sincronização e tarifas
A plataforma
Por que MedusaJS para operações B2B complexas
MedusaJS é um motor de commerce open source sobre Node.js, modular e API-first. Para um negócio B2B com ERP consolidado, isso se traduz em seis vantagens concretas.
Código aberto, controlo total
Sem licenças por uso ou caixa preta. O motor é seu, corre em sua infraestrutura e evolui ao seu ritmo.
Arquitetura modular
Cada domínio — preços, inventário, encomendas — é um módulo substituível. Ideal para injetar lógica B2B própria sem forks.
API-first real
Toda a operação exposta pela API. O frontend, o ERP e os canais consomem o mesmo contrato, sem atalhos ocultos.
Preços por linha de pedido
O mecanismo para injetar um preço personalizado em cada linha existe de série. A base correta para tarifas negociadas.
Multi-almacén e multi-mercado
Inventário por localização, divisas e regras por região. Pensado para distribuidores que vendem em vários países.
Frontend desacoplado
A experiência de compra é construída para além, com a tecnologia que decida sua equipe. O motor não condiciona o design.
Nosso posicionamento
A camada que o commerce componible não traz de série
Qualquer agência pode colocar um motor headless. O que não vem em nenhuma documentação é a integração com o seu ERP e o motor de tarifas B2B: a parte que decide se o projeto fatura bem ou gera incidências.
O motor de commerce escolhe você. Nós nos ocupamos de que o preço que o seu cliente vê é o que fatura o seu ERP.
Os seis blocos técnicos
O que separa ter integrado de ter lido sobre integrar
Estes seis blocos aparecem em todo projeto B2B sério sobre MedusaJS. Nenhum vem resolvido de fábrica. Todos os construímos.
01 · As duas arquitecturas de preço
Tarifa replicada frente à tarifa calculada. Quando escolher cada uma e por que a replicada se quebra aos dezoito meses quanto aparecem contratos por cliente. É a primeira decisão do projeto e a mais cara de rectificar.
02 · Preço personalizado por linha de pedido
O mecanismo existe nos motores modernos. O que não vem é a cache, o contrato de latência e o plano de degradação quando o ERP não responde. Isso é o que há que projetar e o que ninguém orça.
03 · A matriz de tarifas
Tipologias de cliente em um eixo, categorias de produto no outro; a intersecção define o grupo de preço. É método próprio, explica-se em dois minutos e é o entregable do primeiro workshop de trabalho.
04 · Sincronização com compensação e idempotência
O que acontece quando o pedido entra no ERP e falha o passo seguinte. Reintentos, desfazer, pedidos duplicados. Aqui se separa quem integrou na produção de quem leu sobre integrar.
05 · Fonte de verdade e PIM
Que dado vive no ERP, qual no PIM e qual no CMS. A regra: nenhum dado que exista no ERP entra no CMS. O conteo de documentos e o custo por assento castigam quem a incumple.
06 · Dados normalizados como requisito para agentes
Um agente da IA — ou um servidor MCP — sobre um catálogo sujo não responde. A normalização do dado é o trabalho prévio, não a guinda. Sem ela, qualquer iniciativa de IA sobre seu catálogo nasce morta.
Para quem
A quem falamos
Esta abordagem destina-se a endereços de TI e tecnologia que já sabem o que custa um dado mal sincronizado.
Industrial ou distribuidor multimarca
Com catálogo amplo, várias famílias de produto e venda a profissionais como núcleo do negócio.
ERP consolidado
SAP, Business Central, Odoo, Sage ou A3 como coluna vertebral. O ERP não se toca: o commerce se adapta a ele.
Tarifas negociadas por cliente
Preços por contrato, por volume ou por tipologia. A tarifa plana ficou pequena há anos.
Avaliando sair de PrestaShop ou Magento
Vários países, vários canais, e uma plataforma monolítica que começa a travar. O salto para componível está sobre a mesa.
Software, não slides
Qualquer um gera uma apresentação em minutos. Nós ensinamos software funcionando
O teste de que temos estado dentro não é este texto: é um conector de referência entre nosso middleware e MedusaJS, com loja de demonstração operacional e dados reais.
✓Tarifas por grupo de cliente resolvidas em tempo real
✓Preço calculado em um ERP e servido ao checkout
✓Injeção de preço por linha de pedido
✓Caché com contrato de latência medido
✓Plano de degradação quando o ERP não responde
✓Sincronização de pedidos com compensação
// preço por linha: o ERP decide, o motor serveConst price = await pricing.resolve({ customer group: "distribuidor-a", sku: "VLV-2040-INOX", qty: 240, fallback: "cached tier" // degradação se o ERP não responder});
Por que nós
Critérios de produção, não em folhetos
✓ Mais de 15 anos integrando eCommerce com ERP em ambientes industriais e de distribuição.
✓ Mais de 100 integrações ERP em produção: SAP, Business Central, Odoo, Sage, A3.
✓ Middleware próprio de sincronização, tarifas e orquestração de dados entre sistemas.
✓ Aliados das agências de implantação, não sua competência: elas montam o motor, nós o conector.
✓ Suporte e evolução contínua: A integração não é entregue e deixada; opera-se.
Perguntas frequentes
O que nos perguntam antes de começar
MedusaJS encaixa no meu negócio B2B?
Se você tem tarifas negociadas, multi-almacén e necessidade de controle sobre o código, é um candidato sério. Se sua operação é padrão e sem ERP de por meio, provavelmente uma plataforma SaaS te resolva antes. Nós te diremos na primeira conversa, em qualquer um dos dois sentidos.
Posso conectar Medusa com o meu ERP?
Sim. Trabalhamos com SAP, Microsoft Business Central, Odoo, Sage e A3, entre outros. A conexão cobre catálogo, estoque, tarifas, clientes e encomendas, com sincronização em tempo real onde o negócio o exige e por lotes onde não contribui.
Tarifa replicada ou tarifa calculada: qual me convém?
Depende do número de contratos por cliente e da lógica de descontos do seu ERP. A replicação é mais simples e suficiente para tarifas por grupo; a calculada é obrigatória quando o preço depende de condições que apenas o ERP conhece. Escolher mal aqui é o que quebra os projetos aos dezoito meses.
O que acontece se o ERP não responde quando um cliente consulta preços?
É desenhado um plano de degradação: cache de preços com validade definida, preço de apoio por grupo e regras claras sobre o que pode ser mostrado e o que não. O cliente nunca vê um erro nem um preço inventado. Este projeto faz parte do projeto desde o primeiro dia, não é um adesivo posterior.
Posso migrar de PrestaShop ou Magento de forma progressiva?
Sim, e é recomendável. A arquitetura componível permite conviver: o catálogo ou o checkout podem migrar por fases enquanto a plataforma atual continua operando. O corte total em uma noite é um risco que não precisa assumir.
Que dado vive no ERP, qual no PIM e qual no CMS?
Regra geral: o ERP governa preço, estoque e cliente; o PIM governa o prontuário de produto enriquecido; o CMS governa conteúdo editorial. E nenhum dado no ERP é duplicado no CMS: o conteo de documentos e o custo por assento acabam punindo quem incumple esta regra.
Está isto preparado para agentes da IA?
Só se o dado estiver normalizado. Um agente ou um servidor MCP sobre um catálogo sujo não responde com fiabilidade. É por isso que a normalização faz parte do projeto de integração: é o pré-requisito de qualquer camada de IA que queira montar depois.
Falemos da metade difícil do seu projeto MedusaJS
Conte-nos que ERP você tem e como são suas tarifas. Em uma sessão de trabalho, dizemos-lhe que arquitectura de preço te corresponde e o que implica a sua integração.
Integrado · Automação · Rentável
