BigCommerce com Dynamics NAV ou AX, quando o ERP já tem sucessor.

Estas vieram uma a uma das próprias páginas de ciclo de vida da Microsoft, porque as versões se separam por meses e os resumos que circulam pelo ecossistema de parceiros erram.

• Dynamics NAV 2016: o suporte estendido terminou em 14 de abril de 2026. Já ficou para trás.
• Dynamics NAV 2017: o suporte estendido termina em 11 de janeiro de 2027. É a data viva mais próxima desta página.
• Dynamics NAV 2018, a última versão do NAV: o suporte estendido termina em 11 de janeiro de 2028.
• Dynamics AX 2012 R3, a última versão on-premise do AX: o suporte estendido terminou em 10 de janeiro de 2023.

Duas delas merecem destaque.

Se você está no NAV 2017, restam meses e não anos. Não é uma emergência, mas está perto o bastante para que qualquer trabalho de integração planejado para este ano seja planejado já contando com a migração, e não depois dela.

Se você está no AX, já está sem suporte, qualquer que seja a versão. O AX 2012 R3 foi a última versão a levar o nome AX e saiu de suporte em janeiro de 2023. O sucessor, Dynamics 365 Finance and Operations, é a mesma linha de código com outro nome, e a Microsoft de fato suporta uma atualização para ele a partir do AX 2012 R2 ou R3, trazendo o X++ personalizado por um serviço de atualização de código e todo o seu histórico transacional por uma atualização de dados. O que você não tem é um AX com suporte para ficar enquanto planeja isso, e vale ser direto: nada parou de funcionar, mas nada está sendo corrigido também.

Confira qualquer um desses dados nas páginas de ciclo de vida de produtos da Microsoft. Se um parceiro citar outra data, é ali que se resolve.

O instinto quando um ERP tem data de fim é congelar tudo em volta até a migração terminar. Normalmente essa é a escolha cara, porque a migração atrasa e a loja passa dois anos sem render o que poderia.

A loja e o ERP são decisões separadas. O que a data de fim muda de verdade é uma coisa só: o quanto da sua integração tem permissão de saber que está falando com NAV ou AX.

Construa de modo que a loja fale com a sua própria camada de integração, e essa camada fale com o ERP. Quando o NAV virar Business Central, ou o AX virar Finance and Operations, você reescreve um adaptador e roda uma suíte de testes. Construa do jeito que quase todas foram construídas, com nomes de campo e tipos de documento do ERP espalhados pelo código da loja, e a migração do ERP arrasta junto uma reconstrução completa da loja.

Esse é todo o argumento, e ele deixa o projeto menor em vez de maior, o que vale dizer considerando quem está fazendo o argumento.

O NAV é o mais fácil dos dois para integrar e também para migrar depois, porque o Business Central é genuinamente a mesma linhagem, e não outro produto usando o sobrenome da família.

As portas de entrada:

• Web services de páginas e codeunits. A resposta certa. O NAV expõe páginas e codeunits como SOAP e, a partir do NAV 2013, expõe páginas e consultas como OData. No NAV os codeunits são só SOAP; chamar um por OData é uma capacidade do Business Central, não do NAV. Publicar um codeunit escrito para a finalidade é muito melhor do que expor uma página padrão e torcer para o formato não mudar.
• OData para leituras. Direto, cacheável, e o mais próximo de uma superfície moderna que o NAV tem. Prefira para ler catálogo, preços e disponibilidade.
• Leituras por SQL direto. Funcionam, com a cautela de sempre: a estrutura de tabelas do NAV não é um contrato público e muda entre versões.
• Escritas por SQL direto. Não. A lógica de negócio do NAV vive no código, não no banco, então escrever por fora dela produz registros que contabilizam errado ou não contabilizam.

Por que a migração é mais gentil aqui: o Business Central manteve o mesmo modelo de dados e a mesma lógica de contabilização, e a mudança é em boa parte de C/AL para extensões AL. Uma integração de NAV construída contra web services publicados, e não contra as entranhas das tabelas, migra para o Business Central com o adaptador reescrito e os contratos intactos. Isso não vale para o caminho do AX.

O AX é o caso mais difícil, dos dois lados. As superfícies de integração são mais antigas e o destino está mais longe.

As portas de entrada:

• AIF, o Application Integration Framework. O caminho oficial no AX 2012, com document services e serviços personalizados sobre vários transportes. Verboso de trabalhar, e respeita a lógica de negócio do AX, o que importa mais que a ergonomia.
• Serviços personalizados. Normalmente a escolha pragmática: escreva um serviço que responda à pergunta específica que a loja faz, em vez de dobrar um document service até esse formato.
• O .NET Business Connector. Presente em muitas integrações antigas, obsoleto, e não é algo sobre o que construir trabalho novo.
• Leituras por SQL direto. Comuns, e mais arriscadas que no NAV porque o layout de tabelas do AX é genuinamente hostil para quem vem de fora, com chaves substitutas e separação de dados por empresa que é fácil errar de forma sutil.

Por que a migração é mais difícil: a Microsoft tem ferramentas para ela, com um serviço de atualização de código que converte o X++ existente e uma atualização de dados que carrega todo o histórico transacional. Ainda assim é um projeto de atualização e não uma troca de versão, e a própria Microsoft diz isso: descreve as ferramentas como um framework e não como uma solução completa, empresas virtuais e partições de dados bloqueiam a atualização por completo, e o AX 2012 RTM nem é um ponto de partida suportado. O modelo de dados foi bastante reelaborado e o AIF deu lugar a OData e ao Data Management Framework, então a superfície de integração que você construiu não vai junto. Uma integração de AX tem, portanto, vida útil mais curta que uma de NAV, o que reforça manter a parte específica do ERP tão pequena e isolada quanto der.

Se isso soa como o mesmo argumento que fazemos sobre aplicações .NET legadas em geral, é o mesmo argumento. Escrevemos sobre ele em modernização de .NET legado, e empresas com AX costumam carregar também vários dos outros sistemas descritos ali.

As mesmas seis que toda loja B2B pede ao seu ERP. Escrevê-las no seu vocabulário, e não no do NAV ou do AX, é a forma concreta de tudo o que está acima, e hoje não custa nada.

1. Quem é este cliente. A conta de cliente por trás do login, mais os endereços de entrega. No AX, também qual entidade legal, porque a separação de dados por empresa vai te morder se não.
2. Quanto ele paga. Preços de venda e descontos de linha no NAV, ou acordos comerciais no AX. Mais abaixo.
3. O que ele pode levar. Disponibilidade por local ou depósito, líquida de reservas, não só quantidade em estoque.
4. Registrar o pedido. Devolvendo o número de pedido real do ERP, e não um id da loja com a promessa de conciliar depois.
5. Onde está. Status de remessa e de contabilização, com rastreio onde a transportadora fornecer.
6. Quanto ele deve. Faturas contabilizadas, 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 ser dimensionada.

Entre as três páginas deste conjunto, é o preço que decide de fato o custo da integração, e NAV e AX ficam no meio.

O NAV usa preços de venda e descontos de linha de venda, e eles não se resolvem pela mesma coisa. Preços resolvem por cliente, grupo de preço de cliente, campanha, todos os clientes e data. Descontos de linha resolvem por cliente, grupo de desconto de cliente, campanha e data, contra um item ou um grupo de desconto de itens. Grupo de preço de cliente e grupo de desconto de cliente são campos diferentes no cadastro do cliente, e tratá-los como um só é a configuração errada de preços mais comum que encontramos no NAV. Faixas por quantidade, unidade de medida e moeda estão todas na conta, e o NAV pega o menor preço com o maior desconto de linha permitido. Isso é mais que uma consulta simples e bem menos que um cálculo completo. Para uma configuração simples, sincronizar com as listas de preços do BigCommerce funciona. Assim que campanhas e descontos sobrepostos entram em jogo, pergunte ao NAV.

O AX usa acordos comerciais, os mais capazes dos dois: diários de preço, de desconto de linha, de desconto multilinha e de desconto total, ligados a um cliente, a um grupo de preço ou de desconto de cliente, ou a todos os clientes, com intervalos de data e faixas por quantidade. As combinações não são intercambiáveis, e é aí que o escopo erra. Um preço precisa nomear um item específico, porque um preço é um valor absoluto e não uma regra. Descontos multilinha funcionam só no nível de grupo. Descontos de linha e multilinha podem se combinar, dependendo de como o parâmetro de descontos de contas a receber estiver configurado. Trate o preço do AX mais como tratamos o do SAP: pergunte ao ERP na hora do carrinho e guarde a resposta em cache.

A regra que vale para os dois, e para o GP:

• Catálogo e busca podem mostrar um preço em cache ou indicativo. Ninguém é faturado a partir de uma página de listagem.
• Carrinho, cotação e checkout precisam ser o número vivo do ERP, porque é ele que será contabilizado.
• Sem preço resolvido, não tem botão de adicionar ao carrinho. Nem o NAV nem o AX recusam um pedido quando não existe preço específico para aquele cliente. O NAV cai no preço unitário do cadastro do item e o AX no preço base do produto liberado, ou em zero se nunca foi configurado. Esses pedidos são lançados sem problema e aparecem como problema de margem meses depois, e por isso a loja deve bloquear em vez de deixar o ERP adivinhar.

• A integração foi construída contra as entranhas das tabelas. Vai bem até uma atualização, e depois fica silenciosamente errada. É também a única coisa que transforma uma migração para Business Central ou F&O de reescrita de adaptador em reconstrução.
• O contexto de empresa no AX é implícito. Alguém assumiu uma única entidade legal, e a segunda produz preços e estoques errados com toda a confiança.
• 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 cria um segundo pedido, descoberto no depósito e não no log.
• Tudo passa por um único job de middleware envelhecido que uma só pessoa entende, num agendamento que ninguém revisa desde que foi configurado.
• Ninguém registrou o que o ERP devolveu. Quando um preço é contestado meses depois, não há resposta sobre o que o NAV ou o AX disse na hora.