{"section":"tutorials","requestedLocale":"pt","requestedSlug":"escolher-entre-arquitetura-multiloja-ou-ambiente-adicional","locale":"pt","slug":"escolher-entre-arquitetura-multiloja-ou-ambiente-adicional","path":"docs/pt/tutorials/gerenciamento-da-conta/contas/escolher-entre-arquitetura-multiloja-ou-ambiente-adicional.md","branch":"main","content":"A plataforma VTEX permite a criação de arquiteturas diferentes para a sua loja, começando com a criação de uma conta principal, ou [account name](/pt/docs/tutorials/o-que-e-account-name). É possível evoluir sua conta principal com outras opções de conta.\n\nEste artigo apresenta as diferenças entre arquitetura multiloja e ambiente adicional para que você identifique qual a mais adequada para diferentes cenários. \n\n> ℹ️ Para arquiteturas de marketplace, também é possível [ Escolher entre Conta Franquia, Seller Portal ou Conta Padrão](/pt/docs/tutorials/escolher-entre-conta-padrao-conta-franquia-ou-seller-portal), ou utilizar a configuração de [Multilevel Omnichannel Inventory ](/pt/docs/tutorials/multilevel-omnichannel-inventory).\n\n## Arquitetura multiloja (subconta / store)\n\n* O Admin VTEX será o mesmo, mas com [stores](/pt/docs/tutorials/o-que-e-store-name) diferentes, e portanto com frentes de loja distintas na visão do comprador final.  \n* Esse recurso geralmente é utilizado quando a loja tem outras marcas mas existe uma similaridade de logística e métodos de pagamento ou quando a loja precisa de outro ambiente, por exemplo para diferentes públicos. \n* Todos os módulos são compartilhados entre as stores, desde catálogo, promoções, sitemap, preços, configurações de pagamento e outros módulos, porém podem ser segmentados para condições de venda diferentes usando [políticas comerciais](/pt/tutorial/como-funciona-uma-politica-comercial--6Xef8PZiFm40kg2STrMkMV?) e [bindings](/pt/tutorial/o-que-e-binding--4NcN3NJd0IeYccgWCI8O2W#).\n\n## Ambiente adicional (account)\n\n* Dois ambientes VTEX com [accounts](/pt/docs/tutorials/o-que-e-account-name), ou contas principais, totalmente separadas entre si, onde cada um deles terá todos os seus módulos configurados de forma independente, expandindo as possibilidades de configuração e segmentação de condições de venda e experiência de compra. \n* Note que o ambiente adicional mencionado neste artigo não é o mesmo que [conta franquia](/pt/docs/tutorials/o-que-e-conta-franquia), que possui catálogo compartilhado com a conta principal mas não tem storefront próprio, por mais que a conta franquia também opere como um Admin VTEX à parte.\n\n## Comparação entre arquitetura multiloja e ambiente adicional\n\nA tabela abaixo apresenta como as diferentes arquiteturas se relacionam com módulos e funcionalidades da plataforma VTEX.\n\n| Aspecto | Arquitetura multiloja (store) | Arquitetura de ambientes adicionais |\n| - | - | - |\n| Arquitetura | Um único Admin VTEX ([account](/pt/docs/tutorials/o-que-e-account-name)), com múltiplas subcontas ([stores](/pt/docs/tutorials/o-que-e-store-name)). | Dois ambientes ([accounts](/pt/docs/tutorials/o-que-e-account-name)) separados do Admin VTEX. |\n| Segmentação de condições de venda | É possível segmentar as aplicações de catálogo, preços, pagamentos, promoções, entre outros módulos, usando [políticas comerciais](/pt/docs/tutorials/como-funciona-uma-politica-comercial) e [bindings](/pt/docs/tutorials/o-que-e-binding). | Pelo fato de serem dois ambientes separados, com configurações independentes, o lojista tem muito mais controle sobre as possibilidades de segmentação de condições de venda em diferentes cenários. |\n| Tipo de equipe | Recomendado quando uma mesma empresa e mesma equipe gerencia dois ou mais ecommerces com catálogos similares e itens em comum, mas que desejam oferecer storefronts diferentes para seus compradores acessarem experiências com marcas diferentes. | Recomendado quando equipes distintas da mesma empresa lidam com ecommerces diferentes. |\n| Storefront | Storefronts são diferentes para cada store, mas gerenciado por um mesmo Admin VTEX.Caso a intenção seja somente mudar o idioma do site, mas a operação da loja for a mesma, é possível utilizar o [multibinding](/pt/docs/tutorials/gerenciando-conteudo-por-binding) e [internacionalização do catálogo](https://developers.vtex.com/docs/guides/catalog-internationalization) para configuração em um mesmo ambiente VTEX.<br />Note que essa arquitetura é diferente de uma [conta-franquia](/pt/docs/tutorials/o-que-e-conta-franquia), pois essa conta não possui um site próprio. Os consumidores navegam diretamente no site da conta principal, que atua como marketplace nessa situação. | Cada account gerencia seus próprios storefronts em Admins VTEX separados, podendo utilizar todas as opções disponíveis de segmentação de storefronts. |\n| Performance do Admin VTEX | A performance do Admin VTEX pode ser afetada quanto mais [políticas comerciais](/pt/docs/tutorials/como-funciona-uma-politica-comercial) forem associadas a uma mesma conta principal, ficando mais lento o uso das funcionalidades na plataforma, uma vez que a informação precisa ser atualizada em cada política comercial. <br />Impactos na performance do Admin também são esperadas se o catálogo de produtos for muito extenso, com mais de 2 milhões de produtos, aumentando o tempo de indexação. | É possível criar múltiplas [políticas comerciais](/pt/docs/tutorials/como-funciona-uma-politica-comercial), separadas para cada ambiente.<br />A performance do Admin VTEX pode ser afetada quanto mais políticas comerciais forem associadas a uma mesma conta principal, ficando mais lento o uso de certas funcionalidades na plataforma.<br />Porém, dado que são ambientes separados, a necessidade de cadastrar múltiplas políticas comerciais diminui. |\n| Custos | Apesar da adição de uma store não ter custo adicional, é necessário [contratar uma política comercial adicional](/pt/docs/tutorials/contratacao-de-politica-comercial-adicional), caso deseje diferenciar as regras de negócio. Saiba mais sobre políticas comerciais e segmentação das configurações disponíveis em [Como funciona uma política comercial](/pt/tutorial/como-funciona-uma-politica-comercial--6Xef8PZiFm40kg2STrMkMV?). | É necessário [contratar um ambiente adicional](/pt/tutorial/contratar-novo-ambiente--tutorials_2542?&utm_source=autocomplete) com custo adicional previsto no contrato com a VTEX. <br />Caso deseje, também é possível [contratar uma política comercial adicional](/pt/docs/tutorials/contratacao-de-politica-comercial-adicional), caso deseje segmentar as configurações de cada ambiente para condições diferentes. Saiba mais sobre políticas comerciais e segmentação das configurações disponíveis em [Como funciona uma política comercial](/pt/tutorial/como-funciona-uma-politica-comercial--6Xef8PZiFm40kg2STrMkMV?). |\n| Operação | Ao utilizar esse tipo de arquitetura, avalie a complexidade de gestão de catálogo, promoções, preços, estoque, pedidos e pagamentos pensando em diferentes stores, uma vez que todos os dados estarão no mesmo Admin. É possível configurar [internacionalização do catálogo](https://developers.vtex.com/docs/guides/catalog-internationalization), para a venda em países diferentes. | Recomendamos essa arquitetura em casos de operações em dois países distintos, quando há necessidade de separação de idiomas diretamente no catálogo, para facilitar a operação de equipes que se comunicam em idiomas diferentes também. |\n| Master Data | Cada subconta possui seu próprio [Master Data](/pt/docs/tutorials/master-data), configurado de forma independente da conta principal.<br /><br />É possível realizar um apontamento para que os dados das entidades padrão (CL, AD e OD) da subconta sejam salvos no Master Data da conta principal, mediante solicitação ao [Suporte](/pt/docs/tutorials/abrir-chamados-para-o-suporte-vtex). O apontamento não é uma migração de dados, pois funciona somente como um redirecionamento para que os dados das entidades padrão da subconta possam ser armazenados na conta principal. Essa solução não se aplica a entidades customizadas — elas permanecem visíveis apenas na conta em que foram criadas.<br /><br />O Suporte não atua em cenários de migração de dados. Para esses casos, recomendamos utilizar a [Master Data API](https://developers.vtex.com/docs/guides/extracting-data-from-master-data-with-search-and-scroll) ou a [interface do Master Data](/pt/docs/tutorials/exportando-dados) para extrair os dados da conta principal e importá-los para a subconta. |  Cada conta terá seu [Master Data](/pt/docs/tutorials/master-data) independente. |\n| Segurança da informação | Todos os módulos são compartilhados entre as stores, como catálogo, promoções, preços, configurações de pagamento, etc. <br />É importante levar esse ponto em consideração ao lidar com diferentes times de uma mesma empresa tendo acesso ao Admin VTEX. Por exemplo, funcionários da Marca B poderão visualizar catálogo, preços e pedidos da Marca A - sendo Marca A e Marca B duas stores separadas. | A separação de ambientes faz com que os dados e configurações de catálogo, promoções, preços, configurações de pagamento, entre outros módulos, não sejam acessados por funcionários de times diferentes.<br />Por exemplo, funcionários da Marca B não poderão visualizar catálogo, preços e pedidos da Marca A  - sendo Marca A e Marca B ambientes VTEX separados.      |\n| License Manager | O mesmo [License Manager](/pt/tutorial/visao-geral-do-modulo-license-manager) gerencia todos os usuários. | Cada Admin terá o seu próprio [License Manager](/pt/tutorial/visao-geral-do-modulo-license-manager), com gerenciamento de usuários separados. |\n| Giftcard | As subaccounts terão acesso ao mesmo gerenciamento de giftcards, sendo possível usar os giftcards em storefronts diferentes. | Cada Admin terá o seu gerenciamento de Giftcard único, não sendo possível usar o giftcard gerado em um ambiente, no outro ambiente. |\n| Estrutura de marketplace | Uma estrutura de marketplace não se aplica entre as stores diferentes, uma vez que que já compartilham catálogo, preços e estoque. | É possível que um ambiente seja seller no outro ambiente e vice e versa, tendo os produtos sendo vendidos nos dois sites baseados na relação seller-marketplace. Saiba mais em [Configurar marketplace VTEX](/pt/docs/tutorials/configurar-marketplace-vtex) e [Configurar seller para vender em marketplace VTEX](/pt/docs/tutorials/configurar-seller-para-vender-em-marketplace-vtex). <br />Também é possível criar contas-franquia, para que operem como sellers white label, já que possuem preços, estoques e logística diferentes. Saiba mais em [Escolher entre Conta Franquia, Seller Portal ou Conta Padrão](/pt/docs/tutorials/escolher-entre-conta-padrao-conta-franquia-ou-seller-portal).<br />Isso pode ser feito contratando ambiente adicional (caso tenham itens no catálogo em comum, mas não todos) ou conta-franquia (em casos de catálogos exatamente iguais). Saiba mais em Escolher entre Conta Franquia, Seller Portal ou Conta Padrão. |\n| Sitemap | Haverá um [sitemap](/pt/docs/tutorials/rastreamento-google-search-console-sitemap) único para a account principal, que será compartilhado entre as stores. | Cada account possui seu [sitemap](/pt/docs/tutorials/rastreamento-google-search-console-sitemap) independente. |\n| B2B: Catálogo  | Não é possível mudar a unidade de medida registrada no catálogo para cada [política comercial](/pt/docs/tutorials/como-funciona-uma-politica-comercial#catalogo). Ex: lojas B2B vendem em atacado, enquanto B2Cs vendem por pequenas quantidades. <br />O storefront B2B com catálogo centralizado terá a página de produto com uma unidade apenas. Dependendo do negócio, será preciso customizar o storefront para permitir um mínimo de unidades daquele SKU. <br />É possível ampliar o catálogo com a criação de kits, mas seriam kits criados para a maioria dos produtos, gerando um catálogo praticamente duplicado. | Como os catálogos de cada ambiente são independentes, as restrições presentes no ambiente multiloja não se aplicam.É possível adaptar um dos catálogos somente para vendas B2B. |\n| B2B: configurações do orderForm   | Ao seguir por uma arquitetura multiloja, todas as stores compartilharão o mesmo [orderForm configuration](https://developers.vtex.com/docs/api-reference/checkout-api#get-/api/checkout/pvt/configuration/orderForm), no Checkout.<br />Existem sistemas que podem ser integrados ao Admin da VTEX e dependem deste tipo de configuração para realizar a integração, como é o caso de Tax Providers por exemplo.<br />Na prática, na integração de um Tax provider, ele será chamado tanto no B2C quanto no B2B em um ambiente multiloja, o que é danoso para a operação do cliente. | É possível criar uma configuração distinta do [orderForm](https://developers.vtex.com/docs/api-reference/checkout-api#get-/api/checkout/pvt/configuration/orderForm) para cada ambiente, suprindo as necessidades de integrações externas no checkout de uma loja B2B. |\n\n## Saiba mais\n\n- [Configurar marketplace para multiloja](/pt/docs/tutorials/como-configurar-bridge-para-multiloja)    \n- [Criar multiloja / multidomínio](/pt/docs/tutorials/gerenciando-uma-multiloja)"}