BigCommerce com Business Central, onde o ERP atualiza esteja você pronto ou não.

Quase toda afirmação errada sobre o suporte do Business Central vem de responder por um tipo de implantação pensando no outro. Eles são genuinamente diferentes, então comece dizendo em qual você está.

O Business Central online não tem data de fim de suporte publicada. A página de ciclo de vida da Microsoft traz só uma data de início e uma data de aposentadoria, e essa data de aposentadoria diz "In Support". Ali não existem colunas de fim de suporte principal ou estendido, que é exatamente a diferença estrutural em relação às páginas do NAV e do GP, onde essas colunas são a história inteira. Ele segue a Modern Lifecycle Policy, que mantém o produto com suporte enquanto você se mantiver atualizado, licenciado, e a Microsoft continuar oferecendo.

O Business Central local tem data, versão por versão. Esta é a parte que os resumos de parceiros mais erram. Hoje só três versões locais seguem com suporte:

• v26.x acaba em 13 de outubro de 2026. São cerca de sete semanas e é a data viva mais próxima desta página.
• v27.x acaba em 5 de abril de 2027.
• v28.x, a versão atual, acaba em 12 de outubro de 2027.

Tudo abaixo disso já ficou para trás. Treze versões locais passaram da data de fim, incluindo toda a série da v15 à v25 e as mais antigas v13 e v14 listadas na política fixa.

Vale entender o motivo da divisão, mais do que decorá-la. A Microsoft consegue atualizar o serviço online por conta própria, então não precisa datá-lo. No local ela não consegue, porque quem controla a instalação é você. Então ela data cada versão.

Confira qualquer um desses dados nas páginas de ciclo de vida de produtos da Microsoft. Se alguém citar outro número, é ali que se resolve.

O Business Central online recebe uma atualização maior em todo abril e todo outubro, mais atualizações menores na maior parte dos outros meses. A versão atual é a 28.x, que saiu em 1 de abril de 2026.

Dá para adiar, mas só dentro de uma janela, e o formato dessa janela é justamente aquilo para o qual a maioria das integrações não foi construída:

• Um período de atualização de cinco meses, dentro do qual um administrador pode reagendar para qualquer data.
• Um período de carência de um mês depois disso, todo setembro e todo março, durante o qual você já não consegue empurrar a data para mais longe.
• Depois um período de atualização forçada. Nas palavras da Microsoft, extensões que façam a atualização falhar "podem ser desinstaladas automaticamente do ambiente para que a atualização tenha sucesso". Os dados delas não são apagados e voltam quando você instala uma versão compatível, mas a extensão em si é removida para abrir caminho.

Leia esse último ponto como integrador, e não como administrador. Se a sua loja depende de uma extensão por locatário, e essa extensão não compila contra a próxima versão maior a tempo, a resposta da plataforma é remover a sua extensão, não segurar o locatário. Não há versão em que se acomodar nem contrato de suporte que compre a saída.

Então a pergunta deixa de ser quando você tem que se mexer. Passa a ser se a sua integração consegue sobreviver a um abril e a um outubro, todo ano, indefinidamente. Essa é uma pergunta de testes e de propriedade, e é a que de fato decide o custo de operar uma loja sobre o Business Central.

No NAV, no AX e no GP o atalho é sempre o mesmo: ler as tabelas direto. Nossas páginas sobre esses três gastam quase todo o texto argumentando contra. No Business Central online o argumento acabou, porque a porta não está lá.

A Microsoft é incomumente direta a respeito. Para o Business Central online, a única forma suportada de ler dados é por APIs. Acesso direto ao banco não existe como opção, e a Microsoft avisa explicitamente que construir uma integração local que dependa disso vai bloquear a sua mudança para a nuvem depois.

Isso aposenta muita coisa de uma vez e em silêncio. Toda extração por ODBC. Todo relatório contra uma réplica de leitura. Todo SELECT noturno do qual uma loja acabou dependendo. Todo procedimento armazenado no formato eConnect, se você está chegando do GP.

Achamos que é a melhor coisa da plataforma do ponto de vista de integração, e vale dizer isso com clareza porque soa como restrição. Ser obrigado a passar por um contrato publicado é exatamente o desenho que as outras três páginas precisam convencer as pessoas a adotar. Aqui você recebe isso querendo ou não, e a classe de falha em que uma atualização muda uma tabela por baixo de uma integração que funcionava simplesmente não acontece.

Existem três tipos de web service e eles não são equivalentes. Dois deles têm data de remoção atrelada a um padrão muito comum.

• A API REST padrão, v2.0. Continua sendo a versão atual, e não há v3.0 documentada. Serve para as entidades comuns e não exige etapa de publicação. Não cobre tudo, e uma das ausências importa o suficiente para ter a própria seção mais abaixo.
• Páginas de API personalizadas, escritas em AL e entregues numa extensão por locatário. A resposta certa para tudo o que a API padrão não cobre. Elas não podem ser exibidas na interface, e esse é justamente o ponto: existem para ser uma superfície de integração estável, não uma tela que alguém pode redesenhar.
• OData v4 sobre páginas e consultas comuns. Funciona, mas cada endpoint precisa ser registrado à mão na página de Web Services e marcado como publicado, o que faz a sua integração depender de uma configuração do locatário que alguém pode desligar.
• SOAP. Obsoleto. O protocolo em si não tem versão de remoção anunciada, então quem te der uma está chutando.

As duas datas. Expor uma página publicada pela Microsoft, ou seja, qualquer coisa do Base Application ou dos apps próprios, vai deixar de funcionar como endpoint:

• Como endpoint SOAP, removido na versão 29.0, que é a onda 2 de 2026.
• Como endpoint OData, removido na versão 30.0.

Se a sua loja lê páginas padrão do Business Central como web services, esses são dois prazos duros separados por cerca de um ano, e é bem mais provável que afetem você do que qualquer coisa na página de ciclo de vida. A correção é a mesma nos dois casos e vale fazer uma vez só: mude para uma página de API personalizada dentro da sua própria extensão. A orientação da Microsoft diz o mesmo pelos motivos dela, que são que uma página de interface padrão devolve coisas que você não quer e prepara coisas que você nunca pediu, e que quem a alterar não faz ideia de que você estava lendo.

Webhooks existem e funcionam sobre páginas de API. Os eventos de negócio são o mecanismo mais novo e mais interessante, mas continuam documentados como versão prévia, então ainda não colocaríamos o fluxo de pedidos de uma loja em cima deles.

As mesmas seis que toda loja B2B pede ao seu ERP. No Business Central a plataforma já impôs o contrato, então a única pergunta que resta é se esse contrato fala a sua língua ou a da Microsoft.

1. Quem é este cliente. A conta de cliente por trás do login, mais os endereços de entrega. Atenção: o preço resolve contra o cliente de faturamento, que nem sempre é quem fez login.
2. Quanto ele paga. A parte difícil nesta plataforma. Veja abaixo.
3. O que ele pode levar. Disponibilidade por local, líquida de reservas, não só quantidade em estoque.
4. Registrar o pedido. Devolvendo o número de documento real do Business Central, e não um id da loja com a promessa de conciliar depois.
5. Onde está. Status de remessa e de lançamento, com rastreio onde a transportadora fornecer.
6. Quanto ele deve. Faturas lançadas, títulos em aberto e posição de crédito. Continua sendo o motivo pelo qual compradores B2B fazem login, e continua sendo a última coisa a entrar no escopo.

Escreva essas seis no seu próprio vocabulário e deixe as especificidades do Business Central atrás delas. Hoje não custa nada, e é o que transforma a atualização semestral numa rodada de testes em vez de um projeto.

Nestas quatro páginas, é o preço que decide de fato o custo de uma integração. O Business Central parece que deveria ser o fácil e não é. Ele cai mais perto do SAP, onde o ERP precisa calcular, do que do GP, onde um nível de preço costuma sincronizar limpo.

Dois fatos explicam isso, e o segundo ninguém espera.

A API padrão não expõe nenhuma entidade de preços. Não existe endpoint na API v2.0 que devolva um preço resolvido. Preço ao vivo exige uma página de API personalizada ou um codeunit que chame o cálculo de preços diretamente.

O próprio conector de e-commerce da Microsoft não exporta preços, ele calcula. Diante exatamente dessa pergunta para o conector do Shopify, a Microsoft escolheu criar uma cotação de venda temporária para o item e rodar sobre ela a lógica padrão de cálculo de preços. Ela também é franca sobre o limite da abordagem de exportação: esse conector não consegue exportar preços nem descontos que variem por quantidade. Quando o time do próprio fabricante olhou exportar contra calcular para uma loja real, escolheu calcular.

As regras por baixo são pequenas isoladamente e juntas derrotam código ingênuo. O menor preço é delimitado por moeda, e não globalmente. Um grupo de preço pode suprimir um preço menor da ficha do item. A correspondência de unidade de medida é inclusiva, então uma linha com unidade em branco compete como curinga. O acordo é avaliado contra o cliente de faturamento, não contra o comprador. Pedidos resolvem pela data do pedido e faturas pela data de lançamento. E uma linha de preço vencedora com "Permitir Desc. Linha" desligado vai legitimamente cancelar o desconto que o seu carrinho ia aplicar, que é precisamente o erro que uma loja comete quando calcula o melhor preço e o melhor desconto separadamente.

Então a regra prática:

• Você pode sincronizar uma projeção resolvida, um catálogo por perfil de preços, mas só onde não haja faixas por quantidade ou elas sejam enumeráveis, não haja campanhas em jogo, e você conheça a conta de faturamento e a data do documento na hora de montá-la. Segmente por moeda e por preços incluírem ou não impostos, senão você vai precificar errado uma loja com imposto embutido.
• Carrinho e checkout deveriam perguntar ao Business Central, porque assim que qualquer uma dessas condições falha, e faixas por quantidade sozinhas já bastam, um preço projetado é um palpite.
• Sem preço não há adicionar ao carrinho. Desabilite em vez de aceitar um pedido que vai falhar no lançamento.

Mais uma coisa para ficar de olho. A nova experiência de preços de venda continua opcional hoje, mas a Microsoft já a sinalizou uma vez como obrigatória e depois adiou a data. Trate isso como risco vivo no roteiro e não como assunto encerrado, e descubra qual experiência o seu locatário está de fato rodando antes de alguém orçar o trabalho.

No NAV e no GP a loja podia se comportar como um par do banco de dados. No Business Central online ela é um cliente de API com limites publicados, e esses limites são menores do que as pessoas supõem porque são medidos por usuário e não por ambiente.

• 6.000 requisições por janela deslizante de cinco minutos, por usuário. Passando disso você recebe um HTTP 429. Se você já viu 600 por minuto citado, essa é a cifra antiga por ambiente e já foi superada.
• Cinco requisições simultâneas por usuário, com outras 95 em fila e no máximo 100 conexões.

O número de simultaneidade é o que morde. Uma loja que chama o Business Central ao vivo em cada visualização de produto bate no muro das cinco simultâneas muito antes de chegar perto do teto de requisições, e a falha não aparece como um 429 limpo. Ela aparece como requisições paradas na fila, páginas travando na renderização e, no fim, um 503. Acontece durante um pico de tráfego, ou seja, exatamente nos minutos que importavam comercialmente.

Duas consequências que vale desenhar em volta. Primeira, o conselho da Microsoft diante do limite é enfileirar e tentar de novo mais tarde, o que serve para uma rotina noturna e é inviável para a renderização de uma página, então a loja precisa cachear em vez de repetir. Segunda, se você realmente precisa de folga, a própria orientação de escala da Microsoft para um portal de e-commerce é distribuir a carga entre várias identidades de aplicação, porque o limite é por usuário.

Uma correção a um conselho muito repetido: a Microsoft documenta o cabeçalho retry-after em respostas 502 e 503 e deliberadamente não o documenta para 429. Não construa o seu backoff supondo que ele está lá sem testar contra o seu próprio locatário.

O que é todo o argumento a favor da divisão que recomendamos em todo lugar: catálogo e busca servidos de dados em cache, carrinho e checkout perguntando ao ERP.

• A integração lê páginas padrão da Microsoft como web services. Funciona hoje e tem data de remoção: versão 29.0 para SOAP e 30.0 para OData. É a coisa mais comum que esperamos encontrar em instalações existentes.
• Os preços foram exportados em vez de calculados. Vai bem até aparecer uma faixa por quantidade, uma campanha ou um cliente de faturamento diferente do comprador, e então fica confiante e errado, de um jeito que ninguém percebe até uma fatura ser contestada.
• A loja chama o ERP a cada visualização de página. Passa nos testes com pouco tráfego, enfileira e expira no dia em que a promoção entra no ar.
• Uma extensão por locatário que ninguém mantém. Hoje compila. Contra a próxima versão maior não compila, e o remédio da plataforma é desinstalá-la, não atrasar o locatário.
• A disponibilidade ignora as reservas. Sincroniza-se o estoque físico em vez do disponível, então a loja promete o que já está comprometido em outro lugar.
• Os pedidos duplicam. Sem chave de idempotência, uma nova tentativa contra um endpoint limitado cria um segundo documento, descoberto no depósito e não no log.
• Ninguém registrou o que o ERP devolveu. Quando um preço é contestado meses depois, não há resposta sobre o que o Business Central disse na hora.