BigCommerce e Dynamics GP, construído para a migração que você já sabe que vem.

Vale dizer sem rodeios, porque os resumos que circulam na comunidade GP se contradizem e pelo menos uma data muito citada já foi revisada.

Se você está no GP 18.x, a versão atual sob a Modern Lifecycle Policy:

• 31 de dezembro de 2029. Fim das melhorias de produto, atualizações regulatórias e fiscais, service packs e suporte técnico. Foi adiada em relação aos 30 de setembro de 2029 anunciados originalmente, para que os clientes pudessem fechar um ano fiscal e de folha completo.
• 30 de abril de 2031. Fim das atualizações de segurança, e fim do faturamento por assinatura e do uso SPLA.

Se você está numa versão mais antiga, sob a Fixed Lifecycle Policy, as datas estão bem mais perto e duas já passaram:

• GP 2016 e 2016 R2: o suporte estendido terminou em 14 de julho de 2026. Isso já ficou para trás. Se for o seu caso, você já está fora de suporte.
• GP 2018 e 2018 R2: o suporte estendido termina em 11 de janeiro de 2028.
• GP 2015 e anteriores: passaram do fim de suporte há muito tempo.

Um detalhe que pega as pessoas de surpresa: instalar qualquer release fiscal ou hotfix atual sobre o GP 2018 leva você para 18.5 ou posterior, o que o coloca na Modern Lifecycle e dá as datas de 2029 e 2031. Não existe forma suportada de aplicar essas atualizações e permanecer no ciclo fixo.

Fonte: a própria documentação de ciclo de vida do Dynamics GP da Microsoft. Se um parceiro citar outra data, confira ali.

Três anos ou mais é muito tempo neste ramo. Uma loja sobre GP que funciona, fatura e atende um negócio cuja forma não mudou não precisa ser empurrada para nada, e não vamos fingir o contrário para vender um projeto.

Mas a pergunta da loja é genuinamente diferente da pergunta do ERP, e é justamente essa que as pessoas erram. Se você integrar o BigCommerce colado no GP do jeito que se construíam integrações em 2016, então quando o GP for substituído você não migra um ERP: migra um ERP e ainda reconstrói uma integração de loja que pagou duas vezes.

Então a decisão que importa agora não é quando sair do GP. É como construir a costura. Bem feita, a eventual mudança para o Business Central, ou para o que você escolher, toca um adaptador e uma rodada de testes. Feita do jeito de sempre, vira um segundo projeto que ninguém orçou.

Esse é o argumento inteiro desta página, e ele vale mais para você do que para nós, porque deixa o trabalho menor.

O BigCommerce é a ponta simples: APIs REST e GraphQL documentadas, webhooks, listas de preços e grupos de clientes, e o B2B Edition soma contas de empresa e hierarquias.

O GP oferece mais rotas que o SAP, e elas diferem bastante em quão bem sobrevivem a uma migração:

• eConnect. A resposta correta para escrever no GP. Transacional, validado, e respeita a lógica de negócio do GP em vez de contorná-la. Se pedidos são criados no GP, normalmente é por aqui.
• Leituras por SQL direto. Rápidas, fáceis e legítimas para ler estoque, preços e dados de clientes. Convenientes o bastante para as pessoas começarem a escrever com elas também, e aí deixam de ser legítimas.
• Escritas por SQL direto. Não. Pular a lógica de negócio do GP produz registros que parecem certos e se comportam errado, e o estrago costuma aparecer no fechamento do mês, não no momento em que você o causou.
• Web Services for Dynamics GP. Era SOAP, ainda aparece em campo, raramente a escolha certa para algo novo.
• SmartConnect e similares. As ferramentas da eOne são bastante difundidas no mundo GP e resolvem boa parte do mapeamento e do agendamento. Razoável, com custo de operação real, e vale saber que é mais uma coisa a migrar depois.

A visão consciente da migração: eConnect e SQL direto têm formato de GP, e nenhum dos dois conceitos existe no Business Central, que usa OData e extensões AL. Então, escolha o que escolher, o objetivo é manter essa escolha contida em um só lugar e não deixá-la se espalhar pela loja.

As mesmas seis que toda loja B2B pede ao seu ERP. Escrevê-las nos seus termos, e não nos do GP, é a coisa mais barata que você pode fazer hoje para deixar a eventual migração entediante.

1. Quem é este cliente. O ID de cliente no GP por trás do login, mais os endereços de entrega, que no GP são um conceito separado que as pessoas rotineiramente esquecem de mapear.
2. Quanto ele paga. O nível de preço dele, ou a folha de Extended Pricing se você usa esse módulo. Mais sobre isso abaixo, porque o GP é genuinamente mais fácil aqui do que o SAP.
3. O que ele pode levar. Quantidade disponível por site, não apenas quantidade em mãos; e a diferença entre alocado e em mãos importa no momento em que dois pedidos disputam.
4. Registrar o pedido. No Sales Order Processing via eConnect, devolvendo um número de documento real do GP e não a promessa de sincronizar depois.
5. Onde está. Status de separação e remessa, com rastreio onde a transportadora devolve.
6. Quanto ele deve. Histórico de faturas, contas a receber em aberto e limite de crédito no Receivables Management. É a parte por que os compradores B2B realmente entram, e consistentemente a última que alguém dimensiona.

Se você leu nossa página de BigCommerce e SAP, a seção de preços de lá é um alerta. Aqui ela é mais uma tranquilização, e a diferença é real, não retórica.

O preço padrão do GP são níveis de preço: o cliente recebe um, e os itens têm preços por nível e por unidade de medida. Isso é uma consulta, não um cálculo, e uma consulta pode ser sincronizada com segurança para listas de preços e grupos de clientes do BigCommerce. Para muitos negócios com GP essa é a história inteira, e a integração sai proporcionalmente mais barata que a equivalente em SAP.

Deixa de ser simples quando o Extended Pricing está ligado. Ele traz folhas de preço, preços com vigência por data, faixas por quantidade e promoções, e começa a parecer um cálculo em vez de uma consulta. Ainda é bem mais simples que a técnica de condições do SAP, mas já é o bastante para uma exportação plana de preços errar as exceções.

A regra com que trabalhamos:

• Só níveis de preço padrão? Sincronize. Mantenha a sincronização frequente e orientada a eventos, e reconcilie de forma agendada para que o desvio seja detectado em vez de descoberto por um cliente.
• Extended Pricing, preço por contrato ou exceções por cliente? Pergunte ao GP no momento do carrinho e faça cache da resposta, a mesma disciplina que a página do SAP descreve.
• De qualquer forma, sem preço não há adicionar ao carrinho. Se o GP não tem preço para aquele cliente e item, desabilite em vez de aceitar um pedido que vai falhar lá na frente.

Vale saber para depois: o modelo de preços do Business Central é mais próximo do GP do que do SAP, então uma integração de GP construída de forma limpa em torno de “me dê o preço para este cliente e item” migra sem repensar nada.

Esta é a seção para agir mesmo que você não contrate ninguém.

• Ponha uma camada de integração no meio. A loja fala com a sua camada. Sua camada fala com o GP. Quando o ERP mudar por baixo, você reescreve um adaptador em vez de uma loja.
• Defina os seis contratos na sua própria linguagem. “Obter o preço para cliente e item” é uma ideia estável que vai sobreviver ao GP. “Chamar este procedimento do eConnect” não é.
• Mantenha o vocabulário do GP fora da loja. Nada de IDs de cliente com formato de GP, códigos de tipo de documento ou IDs de site vazando para o código de front-end. Mapeie na fronteira. Hoje é quase de graça e depois é caro.
• Registre o que o ERP devolveu, não só o que você enviou. Quando alguém contestar um preço daqui a dezoito meses, e vai contestar, a pergunta é o que o GP disse no momento em que aquela pessoa olhou.
• Escreva os testes de integração contra os contratos. Eles viram sua suíte de aceitação para a migração ao Business Central, que é a maior economia disponível naquele projeto.

Nada disso é exótico nem caro na hora de construir. Tudo é caro de acrescentar depois, e é por isso que vale levantar antes de alguém escrever uma proposta.

• Alguém escreveu no GP com SQL. O problema sério mais comum desta categoria. Funciona nos testes e produz registros com os quais os relatórios e o fechamento do mês discordam em silêncio.
• Pedidos duplicam. Sem chave de idempotência no envio, uma retentativa ou um clique duplo cria dois documentos no Sales Order Processing, e ninguém percebe até a separação perceber.
• O estoque promete o que não consegue enviar. Sincroniza-se o que há em mãos em vez do disponível por site, então as alocações ficam invisíveis para a loja.
• Desvio de preço. Níveis sincronizados à noite, alterados no GP às dez da manhã, e a loja vende pelo número de ontem até a próxima rodada.
• A integração é uma tarefa agendada no computador de alguém. Mais comum do que se admite no mundo GP, e para de funcionar no dia em que aquela máquina é trocada.
• Suposições com formato de GP dentro do código da loja. Invisíveis até o dia da migração, quando transformam a troca de um adaptador numa reconstrução.