Sana Commerce sobre Business Central, além do folheto.

Toda página que você leu abre com a mesma afirmação: tempo real, sem sincronização, sem middleware. Ela é exata para o lado do pedido e não é o quadro completo para o catálogo, e o próprio guia de administração da Sana é onde isso aparece.

A Sana publica uma tabela de cache padrão para dados do ERP. Os dados em cache são, nas palavras da Sana, "product details, prices and stock". Detalhes de produto, listas de produto, dados em massa de produto, o carrinho e o histórico de pedidos vêm por padrão em vinte minutos. O menu do site, em sessenta.

À parte disso, o catálogo da loja não é lido do ERP de jeito nenhum. Ele é construído por uma tarefa agendada de importação de produtos que mantém um índice, e a Sana afirma que "Webstore search functionality, sorting and filtering of products, phonetic search and product sets configuration depends on the product information that is indexed."

Então o modelo correto é este. Preços específicos por cliente, impostos, encargos, crédito e validação do pedido são calculados ao vivo no Business Central no momento do carrinho e do checkout. Tudo o que você navega, busca e filtra é um índice atualizado por agendamento. As duas metades importam, e só uma está no folheto.

A Sana é franca sobre o porquê, e essa parte vale citar inteira porque diz que tipo de decisão você está tomando: "Performance of your application will drop when the duration is set less. This is because the amount of calls to your ERP system will increase, which is much slower then retrieving the cache." A grafia é deles.

Isso reformula a pergunta do seu projeto. Não é se a integração é em tempo real. É o quão fresca a sua exibição de estoque e preço precisa ser, porque isso é um botão com um custo de desempenho documentado do outro lado. Se você vende estoque escasso onde um número de estoque de vinte minutos causa problema real, essa é uma conversa para antes do contrato, e não para os testes de aceitação.

O Sana Commerce Cloud é descrito como SaaS que se atualiza sozinho, e separadamente como customizável. A própria documentação da Sana diz que são alternativas, não companheiras: "Customizing Sana Commerce Cloud using the SDK means abandoning SaaS and thus no automatic upgrades."

A linha cai em onde o trabalho acontece. A Sana afirma que "custom projects cannot be automatically updated to a newer Sana version because customizations are done in the Sana core code", e que "If all customizations can be done using the extension points of Sana, you can still receive updates automatically."

O que torna uma pergunta a mais consequente de qualquer conversa de escopo com a Sana, e ela deve ser feita para cada requisito da lista:

• Você vai para um branch de suporte de longo prazo que não recebe atualizações automáticas.
• Começa um relógio de suporte. A Sana suporta ativamente uma versão do framework por três anos a partir do lançamento, e depois passivamente por mais dois, com o suporte passivo limitado a hotfixes de problemas críticos e, nas palavras da Sana, "always on time and material".
• Você perde a administração self-service. Em projetos customizados, os usuários "need to contact their Sana Commerce representative" para instalar um app que um cliente padrão instala sozinho no Sana Admin.

A Sana não documenta nenhum caminho de volta de um projeto customizado para a trilha padrão. Não temos conhecimento de um, e gostaríamos disso por escrito antes de alguém assinar.

Você não é dono de nenhum dos dois calendários de versões, e há mais deles do que a maioria dos projetos planeja.

• O framework da Sana sai a cada duas semanas mais ou menos, com o rollout levando até duas semanas depois da data de lançamento. Isso não é você quem agenda.
• O conector de ERP da Sana vai no próprio trem, mais ou menos trimestral.
• Os apps da Sana são versionados separadamente de novo.
• A Microsoft lança uma atualização maior do Business Central todo abril e outubro, e avança à força a extensão instalada. Não existe configuração que fixe um app do AppSource durante uma onda maior.

A Sana entrega uma configuração de Compatibility Level dentro do Business Central justamente para absorver o descompasso entre o conector dela e a versão da Microsoft embaixo, o que diz que o descompasso é esperado e não excepcional.

Há também uma obrigação contratual que normalmente não aparece na fase comercial, e vale ler inteira: "All standard Sana Commerce Cloud customers have the obligation in their license agreement to update the Sana ERP connector at least every two years." A Sana não documenta nenhuma consequência por descumprimento em lugar nenhum que tenhamos encontrado, então não vamos inventar uma. Mas é uma obrigação que você está assinando, e ela existe porque a direção sem suporte é um conector velho contra um framework mais novo.

Uma correção a algo que talvez você tenha lido, incluindo um rascunho anterior da nossa própria análise. Uma atualização forçada do Business Central não joga um cliente Cloud num estado sem suporte. Há uma exceção para o Business Central Cloud, e a obrigação de atualizar o conector a cada dois anos é exatamente o mecanismo que previne a falha que as pessoas temem. Os fatos operacionais reais são mais estreitos e ainda assim valem planejamento: uma onda aplicada com sucesso não pode ser revertida, extensões que bloqueiam uma atualização forçada podem ser desinstaladas automaticamente, e o ensaio realista contra os seus próprios dados não começa até a disponibilidade geral, a menos que o seu parceiro tenha licença de Partner Sandbox, que dá acesso antecipado.

Estar no AppSource se lê como self-service. A extensão sozinha não faz nada: um sistema funcionando precisa de um ambiente Sana contratado à parte, e no Business Central on-premises a extensão não pode ser obtida sem um parceiro Sana.

O que de fato cai no seu tenant vale saber antes que o administrador do Business Central descubra por um chamado.

• Conjuntos de permissão têm que ser concedidos a gente que nunca toca na loja. A Sana adiciona campos personalizados à tabela de Itens, e sem o conjunto de permissão esses campos impedem o pessoal de financeiro e de depósito de editar itens. Isso é um rollout no tenant inteiro caindo no seu administrador de BC, e não no projeto de e-commerce.
• Produtos podem estar faltando no site sem erro nenhum em lugar nenhum. Itens e clientes com caracteres que a Sana não permite são excluídos silenciosamente. Só aparecem em duas janelas de visão geral do Business Central, que ninguém confere a não ser que saiba que deve.
• A detecção disso tem custo de desempenho. As verificações automáticas de indexabilidade da Sana "can significantly impact performance, especially when there is a large number of items", e atualizações frequentes do cadastro de itens "may cause session locks". O remédio da própria Sana é desativar as verificações, o que significa escolher entre um problema de desempenho no ERP e perder a detecção de produtos excluídos em silêncio.
• Linhas de pedido que a Sana não reconhece são ignoradas, não bloqueadas. Isso inclui linhas de Conta Contábil, prática comum no Business Central para frete e encargos. Se o total do site tem que bater com o total no BC sem conciliação manual, prove isso antes do contrato.

Nada disso é defeito. Tudo está documentado. Só está numa página diferente daquela onde a decisão de compra é tomada.

Duas coisas restringem funcionalidade de um jeito que aparece no meio do projeto, e não durante a avaliação.

A edição. A própria documentação de Business Central da Sana marca como indisponível na edição de entrada uma lista de recursos: cadastro de clientes B2B, representar um cliente (um agente de vendas pedindo em nome de um cliente), pedidos de devolução, pedidos guarda-chuva, prospects, e mostrar estoque na loja. As configurações de agente de vendas dentro das estratégias de processamento de pedidos existem só nos planos superiores. É perfeitamente possível receber cotação de um plano que não faz aquilo pelo que você está comprando uma loja B2B, então cruze a sua lista de requisitos com a edição antes de a conversa comercial fechar.

Não publicamos preços nem comparativos de planos aqui, porque a Sana publica nomes de planos sem lista de preços e a tabela de planos é uma página de marketing renderizada que não conseguimos ler com confiabilidade suficiente para citar. Peça à Sana a matriz de disponibilidade de recursos por escrito.

A estratégia de processamento de pedidos. Existe um modo feito para carrinhos com muitas linhas, e costuma ser o que um distribuidor precisa. Sob ele, a Sana não suporta acordos de venda, conversão de cotação em pedido, edição de pedido (o botão de editar some), descontos mix and match, textos estendidos em linhas de pedido, explosão de lista de materiais, nem cupons no Business Central.

Essa é uma bifurcação de verdade, e não uma opção de ajuste. Se o seu fluxo precisa de carrinhos grandes e também de qualquer coisa dessa lista, a plataforma obriga a escolher, e sai muito mais barato descobrir isso no escopo do que nos testes de aceitação.

"O seu ERP é a fonte única da verdade" é vendido como benefício, e é. Também é uma restrição de governança, e a Sana diz isso claramente no assunto onde mais dói: "All taxes must be configured in ERP. Sana Commerce Cloud has no influence on tax calculation as it all done by ERP." A Sana pode mudar como o imposto é apresentado no carrinho, e nada além disso.

Generalize e você tem o previsor mais confiável de surpresa de escopo num projeto Sana sobre Business Central:

A mesma linha atravessa o suporte. O acordo de serviço da Sana mira uma correção em um dia útil para problemas críticos, e afirma que "Sana Commerce cannot guarantee a 1 business day fix time for show stoppers caused by 3rd parties (ERP, PSP, etc.)". Numa arquitetura cuja característica definidora é que o ERP serve a loja, a classe mais provável de incidente grave é justamente a sem prazo garantido. Isso não é crítica ao SLA. É razão para orçar um parceiro de Business Central junto com o orçamento de e-commerce, e não depois.

Se os seus dados de ERP ou a sua configuração de preços estão bagunçados, o site herda isso, e a correção é um projeto de Business Central. Escrevemos à parte sobre limpar o cadastro de clientes antes de um replatform, e nesta arquitetura esse trabalho não é preparação opcional, ele é a loja.

Esta é a parte sobre a qual mais nos perguntam, porque é onde um briefing de design encontra um limite de produto. Nós construímos lojas, então preferimos alinhar a expectativa cedo em vez de descobri-la na aprovação do design.

O editor de temas trabalha com tokens: logo, favicon, fundo, cores de cabeçalho e rodapé, cores de elementos, tipografias, imagens de placeholder. Além disso você entra em injeções de HTML, que a Sana não suporta e das quais se isenta, e que ficam mais restritas quando a renderização no servidor está desligada, um interruptor que projetos padrão não controlam. A página de detalhe do produto vem com dois layouts, e escolher a matriz de variantes remove o elemento de escrever avaliação.

Se o briefing visual é cosmético, o editor de temas é genuinamente bom e rápido. Se é estrutural, você está olhando para a rota do SDK, e a seção acima sobre a bifurcação é a que importa.

Sobre headless, a própria nota de arquitetura da Sana é incomumente direta sobre o que você está assumindo: a Sana "will not be able to provide support for your custom storefront (web store)", "might be very expensive in terms of money and time", "your project becomes custom", e você "may miss out on the benefits of the standard Sana Commerce Cloud product, including regular updates". Também não há referência pública de API de loja de primeira mão para avaliar antes de se comprometer, então peça à Sana diretamente em vez de supor que estará lá.

Uma observação de enumerar a documentação pública da Sana, oferecida como observação e não como declaração da Sana: a Sana publica páginas consolidadas de Limitações para SAP Business One, Dynamics GP, AX Retail e D365 Commerce, e páginas de Versões de ERP Suportadas para vários ERPs. Para o Business Central não existe nenhuma das duas. Essa ausência é a maior parte da razão de esta página existir.

Cada item aqui remonta a algo que a Sana documenta. Quase todos se resolvem com outro plano, outro escopo ou outra ordem de trabalho, então leia como condições de encaixe e não como razões para não comprar. Nós construímos sobre Sana, e ainda assim preferimos que você descubra isso agora.

• Você precisa do básico de B2B e está sendo cotado na edição de entrada. Ver acima. A distância entre o que a edição inclui e o que um comprador B2B assume ser o produto é a surpresa comercial mais comum.
• Você precisa de carrinhos grandes e de edição de pedido, cotações ou promoções. O modo de pedidos grandes e esse conjunto de recursos são mutuamente exclusivos.
• As suas regras comerciais precisam diferir online do que o Business Central faz. O imposto é o caso documentado e a regra geral vem daí.
• O seu catálogo depende de conteúdo de merchandising que o ERP não guarda. Descrições ricas, imagens, vídeo, atributos de marketing. Isso significa um segundo sistema mestre na arquitetura, e a gestão de informação de produto é uma decisão de plano ou add-on, não algo incluído por padrão. Escrevemos sobre quando você realmente precisa de um PIM.
• Você precisa de uma loja dirigida por design. Se o briefing é estrutural e não cosmético, orce a rota do SDK e leia antes a seção da bifurcação.
• Você quer um front end headless. Se é requisito e não preferência, esta não é a plataforma sobre a qual comprá-lo.
• Você tem exigências de hospedagem, residência de dados ou isolamento de rede. Self-hosting, nuvens privadas virtuais e o toolkit de upgrade da Sana foram todos retirados na mudança para o Sana Commerce Cloud.
• O seu controle de mudanças não aceita atualizações agendadas pelo fornecedor. Nenhuma configuração fixa um app do AppSource durante uma onda maior, uma onda aplicada com sucesso não é revertida, e o momento do ensaio depende da licença do seu parceiro.
• Você opera um catálogo grande e legado com cadastro de itens movimentado. As verificações de indexabilidade e os bloqueios de sessão acima tornam isso um trade-off real, e não um exercício de ajuste.
• Seus pedidos de venda carregam rotineiramente linhas de frete, taxa ou encargo de outros add-ons. Tipos de linha não suportados são ignorados em vez de bloqueados.
• Você está no Business Central on-premises e quer controlar a própria aquisição. A extensão só pode ser baixada por parceiros Sana registrados, é implantada por PowerShell manual, e a informação de compatibilidade fica atrás de um login de parceiro que você não pode auditar.
• Você ainda está no Sana 9.3. Não há toolkit de upgrade para a mudança ao Sana Commerce Cloud, o que faz disso uma reimplementação e não uma atualização. Essa é uma conversa diferente da renovação que você talvez ache que está tendo, e cobrimos o lado do suporte em suporte ao Sana 9.3.