@vtex/faststore-plugin-buyer-portal 1.3.85 → 1.3.86

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -7,6 +7,12 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
7
7
 
8
8
  ## [Unreleased]
9
9
 
10
+ ## [1.3.86] - 2026-05-19
11
+
12
+ ### Added
13
+
14
+ - Add Order Entry Handshake and route
15
+
10
16
  ## [1.3.85] - 2026-05-13
11
17
 
12
18
  ### Added
@@ -23,6 +29,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
23
29
  ## [1.3.83] - 2026-05-05
24
30
 
25
31
  ### Added
32
+
26
33
  - Show Contract ID in AboutDrawer component
27
34
 
28
35
  ## [1.3.82] - 2026-04-29
@@ -41,6 +48,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
41
48
  ## [1.3.80] - 2026-04-29
42
49
 
43
50
  ### Fixed
51
+
44
52
  - Remove the following components/exports to fix broken 1.3.79 build:
45
53
  - CollectionsSettingsDrawer
46
54
  - AddProductAssortmentDrawer
@@ -52,14 +60,17 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
52
60
  ## [1.3.79] - 2026-04-23
53
61
 
54
62
  ### Added
63
+
55
64
  - Add propagation delay message to CRUD success toasts
56
65
 
57
66
  ## [1.3.78] - 2026-04-23
58
67
 
59
68
  ### Changed
69
+
60
70
  - Move addresses list requests from server to client side
61
71
 
62
72
  ### Fixed
73
+
63
74
  - Remove `for` loop from `AddressesClient.getAddressesByUnitId` to prevent failed requests
64
75
 
65
76
  ## [1.3.77] - 2026-04-14
@@ -94,6 +105,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
94
105
  ## [1.3.75] - 2026-04-06
95
106
 
96
107
  ### Changed
108
+
97
109
  - Update validations and empty states visibility for Product Assortments and Payment Methods according with List Type Settings V2 implementations in Contracts Management
98
110
  - Change "Synchronized list" strings to "Shared list" in all respective drawers and toast notifications
99
111
 
@@ -628,7 +640,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
628
640
  - Add CHANGELOG file
629
641
  - Add README file
630
642
 
631
- [unreleased]: https://github.com/vtex/faststore-plugin-buyer-portal/compare/1.3.85...HEAD
643
+ [unreleased]: https://github.com/vtex/faststore-plugin-buyer-portal/compare/1.3.86...HEAD
632
644
  [1.3.55]: https://github.com/vtex/faststore-plugin-buyer-portal/compare/v1.3.54...v1.3.55
633
645
  [1.3.54]: https://github.com/vtex/faststore-plugin-buyer-portal/compare/v1.3.53...v1.3.54
634
646
  [1.3.53]: https://github.com/vtex/faststore-plugin-buyer-portal/compare/v1.3.52...v1.3.53
@@ -711,5 +723,6 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
711
723
  [1.3.72]: https://github.com/vtex/faststore-plugin-buyer-portal/compare/v1.3.71...v1.3.72
712
724
  [1.3.71]: https://github.com/vtex/faststore-plugin-buyer-portal/compare/v1.3.70...v1.3.71
713
725
  [1.3.70]: https://github.com/vtex/faststore-plugin-buyer-portal/compare/v1.3.69...v1.3.70
714
-
715
726
  [1.3.85]: https://github.com/vtex/faststore-plugin-buyer-portal/releases/tag/1.3.85
727
+
728
+ [1.3.86]: https://github.com/vtex/faststore-plugin-buyer-portal/releases/tag/1.3.86
@@ -367,4 +367,276 @@ Implementar soluções robustas para gerenciamento e automação de fabricantes
367
367
 
368
368
  **[Q02] Como vamos resolver a questão de exibir status de pedido de uma organização e seus centros de custos na frente de loja?**
369
369
 
370
- Membros podem facilmente alternar entre os centros de custos pelo cabeçalho da loja. A solução "Gestão de Pedidos Efetuados por Organizações Enterprise" será implementada para oferecer às grandes empresas uma visualização unificada e simplificada de todos os pedidos efetuados.
370
+ Para consultar o status dos pedidos de uma organização e seus centros de custos, membros podem facilmente alternar entre os centros de custos pelo cabeçalho da loja. Por exemplo, ao mudar do status de pedidos da organização Nova York para o centro de custos Miami, os pedidos exibidos se ajustarão para refletir esta seleção. A solução "Gestão de Pedidos Efetuados por Organizações Enterprise" será implementada para oferecer às grandes empresas com múltiplas organizações ou centros de custos uma visualização unificada e simplificada de todos os pedidos efetuados.
371
+
372
+ ---
373
+
374
+ ## Plano e Detalhamento Detalhado da Fase 2
375
+
376
+ A Fase 2 tem como objetivo prover pequenos fabricantes com APIs para gerenciamento completo de organizações, endereços, e centros de custos, e otimizar processos de compra e gestão de pedidos, incluindo personificação por representantes de vendas e integração com o OMS.
377
+
378
+ **Times envolvidos:** Identity, Storage, Catalogo, Checkout, OMS, FastStore
379
+
380
+ ### Objetivos
381
+
382
+ - Implementar APIs e UI para gerenciamento completo de organizações, endereços, e centros de custos na óptica da autogestão da organização compradora.
383
+ - Implementar sistemas de autenticação e permitir a personificação por representantes de vendas.
384
+ - Personalizar o processo de compra e checkout, permitindo a troca de centro de custos.
385
+ - Permitir que membros autorizados visualizem o status de pedidos na frente de loja e que representantes acessem detalhes de pedidos no admin do OMS.
386
+
387
+ ### Proposta de Valor
388
+
389
+ - Capacitar pequenas empresas a gerenciar suas próprias organizações, endereços e centros de custos de forma independente.
390
+ - Facilitar a personalização do processo de compra, permitindo a troca de centros de custos aplicando suas regras comerciais.
391
+ - Permitir que representantes de vendas personifiquem clientes e que membros autorizados tenham acesso visual ao status de pedidos, promovendo uma operação transparente e segura.
392
+ - Garantir que todos os pedidos sejam visíveis e gerenciáveis tanto na interface do cliente quanto nos sistemas administrativos.
393
+
394
+ ### Requisitos de Produto
395
+
396
+ #### API de Gerenciamento de Organizações e Endereços *(unificados pela simplicidade do caso)*
397
+
398
+ - **Objetivo:** Permitir que organizações compradoras existentes gerenciem seus próprios detalhes dentro das permissões concedidas pelo merchant.
399
+ - **Funcionalidade Principal:**
400
+ - Gerenciamento de Endereços: Organizações podem atualizar seus endereços de entrega e faturamento, condicionado à autorização prévia do merchant.
401
+ - Filtragem de Formas de Pagamento: Permitir que a organização defina quais formas de pagamento estarão disponíveis para seus usuários, personalizando a experiência de pagamento conforme suas necessidades e políticas internas.
402
+ - **Caso de Uso:**
403
+ - Uma organização compradora precisa atualizar seu endereço de entrega após mudança de localização. Utiliza a API para modificar o endereço, sujeito a prévia autorização do merchant.
404
+ - A organização opta por limitar as opções de pagamento disponíveis para seus usuários a fim de aderir a políticas de gastos internas, usando a API para configurar as formas de pagamento permitidas.
405
+ - **Flexibilidade e Configuração:** A API deve ser flexível o suficiente para permitir que cada organização personalize as formas de pagamento conforme sua estratégia financeira, sem alterar os dados fundamentais da organização, que são geridos pelo merchant.
406
+ - **Segurança:** Implementar controles de acesso rigorosos para garantir que apenas usuários autorizados dentro da organização possam fazer alterações nos endereços e configurações de pagamento.
407
+
408
+ #### API de Gerenciamento de Centros de Custos e Endereços *(unificados pela simplicidade do caso)*
409
+
410
+ - **Objetivo:** Capacitar centros de custos dentro de organizações compradoras a gerenciar de forma autônoma seus endereços, formas de pagamento e membros, proporcionando flexibilidade e controle detalhado sobre suas operações específicas.
411
+ - **Funcionalidade Principal:**
412
+ - Gerenciamento de Endereços: Permitir que centros de custos atualizem e modifiquem seus endereços de entrega e faturamento conforme necessário para atender às suas operações logísticas e requisitos de negócios.
413
+ - Filtragem de Formas de Pagamento: Habilitar centros de custos a personalizar e filtrar as formas de pagamento disponíveis, assegurando que as transações se alinhem com suas políticas financeiras e orçamentárias.
414
+ - Gerenciamento de Membros: Facilitar a adição, remoção e atualização de membros associados aos centros de custos, permitindo um controle refinado sobre quem pode executar ações em nome do centro.
415
+ - **Caso de Uso:**
416
+ - Um centro de custos precisa mudar seu endereço de entrega devido à realocação de suas operações. Utilizando a API, o administrador do centro de custos atualiza o endereço rapidamente, garantindo que não haja interrupção nas entregas futuras. Deve haver permissão prévia do merchant.
417
+ - Para aderir às novas diretrizes orçamentárias, um centro de custos ajusta as formas de pagamento permitidas para suas compras, utilizando a API para restringir certas opções e promover outras mais viáveis financeiramente.
418
+ - Com mudanças na equipe, o administrador do centro de custos precisa remover um membro que deixou a empresa e adicionar novos membros com as devidas permissões, usando a API para garantir que apenas pessoal autorizado tenha acesso às funcionalidades do centro.
419
+ - **Flexibilidade e Configuração:** A API deve ser flexível o suficiente para permitir modificações rápidas e eficientes em endereços, formas de pagamento e detalhes de membros, adaptando-se facilmente às mudanças organizacionais ou de política interna.
420
+ - **Segurança:** Implementação de controles de acesso baseados em permissões, assegurando que apenas usuários autorizados possam fazer alterações nos centros de custos.
421
+
422
+ #### API de Membros
423
+
424
+ - **Objetivo:** Permitir que as organizações compradoras administrem os detalhes de seus membros, como nome, email, e roles atribuídas, dentro de um conjunto de opções pré-definidas pelo merchant.
425
+ - **Funcionalidade Principal:** Organizações compradoras podem adicionar, atualizar ou remover membros, especificando nome, email, e atribuindo roles definidas pelo merchant.
426
+ - **Caso de Uso:**
427
+ - Uma organização precisa adicionar um novo membro ao seu time de compras. O administrador da organização usa a API para registrar o novo membro, inserindo seu nome, email e atribuindo-lhe uma role específica, como "Buyer Member" ou "Buyer Admin", conforme permitido pelo merchant.
428
+ - A organização precisa atualizar o email de um membro existente ou modificar sua role dentro da organização devido a mudanças internas de função ou responsabilidade.
429
+ - **Flexibilidade e Configuração:** A API deve permitir que a organização ajuste facilmente as informações dos membros e as roles, respeitando as restrições de roles pré-definidas pelo merchant para garantir conformidade e alinhamento com as políticas gerais de gestão.
430
+ - **Segurança:** Controles de acesso devem garantir que apenas administradores autorizados da organização compradora possam gerenciar membros.
431
+
432
+ #### API para Gestão de Permissões dos Membros
433
+
434
+ - **Objetivo:** Permitir que cada organização customize as permissões atribuídas a cada role de membro, garantindo flexibilidade nas operações e na segurança das informações.
435
+ - **Funcionalidade Principal:** Oferecer uma interface para que merchants configurem as permissões para as roles de Buyer Member e Buyer Admin, ajustando a capacidade de cada uma para alterar dados corporativos, adicionar endereços de entrega, gerenciar a própria organização, editar centros de custos, adicionar ou remover usuários em centros de custos, e visualizar pedidos.
436
+ - **Caso de Uso:** Um administrador do merchant utiliza a API para definir e ajustar dinamicamente as permissões de membros dentro de sua organização, garantindo que as atribuições de roles reflitam com precisão a estrutura e as políticas internas da empresa. Isso possibilita, por exemplo, que em uma organização, todos os membros possam ter permissão para editar dados corporativos, enquanto em outra, tal permissão pode ser limitada apenas aos administradores.
437
+ - **Flexibilidade e Configuração:** Suporta a customização detalhada de permissões para roles padrão, possibilitando que organizações ajustem as capacidades de Buyer Members e Buyer Admins de acordo com necessidades específicas e políticas de segurança.
438
+ - **Segurança:** Assegura que as alterações nas permissões dos membros sejam controladas, com acesso restrito a usuários com autoridade administrativa suficiente no nível do merchant. Implementa validações para garantir que as configurações de permissões respeitem as diretrizes de segurança e conformidade estabelecidas.
439
+ - **Detalhamento das Permissões por Role:**
440
+ - **Buyer Member (padrão):**
441
+ - Pode alterar dados corporativos: Permitido de acordo com a configuração do merchant.
442
+ - Ver meus próprios pedidos: Acesso aos detalhes de pedidos realizados pelo membro.
443
+ - **Buyer Admin:**
444
+ - Pode alterar dados corporativos: Total liberdade para modificar informações da empresa.
445
+ - Gerenciar Minha Organização: Capacidade de visualizar e editar informações gerais da organização.
446
+ - Ver todos os pedidos: Acesso irrestrito ao histórico de pedidos da organização.
447
+ - **As duas roles acima não podem por padrão:**
448
+ - Pode adicionar endereço de entrega: Autorização para inserir novos endereços para entrega.
449
+ - Criar e Editar Centros de Custos na Mesma Organização: Autoriza a gestão detalhada de centros de custos.
450
+ - Adicionar Usuários da Organização a qualquer Centro de Custos na Mesma Organização: Permite incluir membros em diferentes centros de custos.
451
+ - Remover Usuários da Organização de qualquer Centro de Custos na Mesma Organização: Faculta a remoção de membros de centros de custos.
452
+
453
+ #### Permissões Aplicadas no Login
454
+
455
+ - **Objetivo:** Assegurar que as permissões de cada membro sejam adequadamente carregadas e aplicadas no momento da autenticação na plataforma, permitindo uma experiência de uso coerente com suas roles e autorizações.
456
+ - **Funcionalidade Principal:** No login, o sistema identifica a role do membro e aplica automaticamente as permissões associadas a essa role, garantindo acesso imediato às funcionalidades permitidas e restringindo aquelas que não são autorizadas.
457
+ - **Caso de Uso:** Um Buyer Member faz login na plataforma e imediatamente recebe acesso apenas às funções que lhe são permitidas, como visualizar seus próprios pedidos, enquanto um Buyer Admin, ao fazer login, ganha acesso a uma gama mais ampla de capacidades, incluindo gestão organizacional e de centros de custos.
458
+ - **Flexibilidade e Configuração:** O sistema de permissões no login é dinâmico, permitindo que alterações nas roles e permissões de membros se reflitam instantaneamente na próxima autenticação, proporcionando flexibilidade na gestão de acessos.
459
+ - **Segurança:** Utiliza práticas robustas de segurança para a autenticação de membros.
460
+
461
+ #### API para Flexibilidade de Compra para Centros de Custos
462
+
463
+ - **Objetivo:** Permitir que membros de uma buyer organization alterem seu centro de custo durante a jornada de compra (discovery), aplicando as regras comerciais específicas do novo centro de custo.
464
+ - **Funcionalidade Principal:** Mudar o centro de custo durante a jornada de compra para aplicar regras comerciais específicas (price table, coleção, sellers, politica comercial, formas de pagamento restritas e endereços específicos) antes do checkout.
465
+ - **Caso de Uso:** Um membro da buyer organization inicia uma compra e, ao selecionar produtos, percebe que precisa utilizar um centro de custo diferente para aproveitar uma política comercial mais vantajosa. O membro altera o centro de custo na área de discovery e continua a compra com as regras do novo centro de custo aplicadas automaticamente.
466
+
467
+ #### Visualização do Status de Pedido
468
+
469
+ - **Objetivo:** Permitir aos membros visualizar o status dos pedidos feitos, exibindo o nome e o e-mail do comprador associado a cada pedido para facilitar a gestão e o acompanhamento.
470
+ - **Funcionalidade Principal:** Oferecer aos membros uma visão detalhada do status de seus pedidos associados à organização ou centro de custos, incluindo os detalhes de contato do comprador responsável.
471
+ - **Caso de Uso:** Um membro necessita acompanhar o progresso de um pedido específico, acessando a plataforma para visualizar o status atual do pedido, juntamente com o nome e o e-mail do comprador, para facilitar comunicações ou ações subsequentes relacionadas ao pedido.
472
+
473
+ #### Integração com OMS
474
+
475
+ - **Objetivo:** Integrar a plataforma com o sistema de gerenciamento de pedidos para refletir precisamente o status de cada pedido, incluindo o nome e e-mail do comprador, otimizando o processo de gestão de pedidos.
476
+ - **Funcionalidade Principal:** Oferecer aos usuários administrativos uma visão detalhada do status de seus pedidos dentro da plataforma, incluindo informações sobre a progressão do pedido e os detalhes de contato do comprador responsável.
477
+ - **Caso de Uso:** O merchant utiliza o OMS para gerenciar eficientemente os pedidos recebidos, necessitando que as informações do pedido, incluindo o status e os detalhes do comprador (nome e e-mail), estejam sincronizadas e disponíveis para consulta rápida e ações de suporte.
478
+
479
+ #### Autogestão por Organizações Compradoras
480
+
481
+ - **Objetivo:** Capacitar organizações compradoras a gerenciar de forma autônoma seus endereços, centros de custos, membros e formas de pagamento, dentro das permissões concedidas pelo merchant.
482
+ - **Funcionalidades Principais:**
483
+ - Gerenciamento de Endereços: Permitir que organizações compradoras atualizem e gerenciem seus endereços de entrega e faturamento, se autorizado pelo merchant.
484
+ - Criação e Gestão de Centros de Custos: Habilitar organizações a criar e gerenciar centros de custos, incluindo a associação de membros e a definição de políticas específicas, caso permitido.
485
+ - Gerenciamento de Membros: Facilitar a adição, atualização e remoção de membros dentro da organização, permitindo definir e ajustar seus níveis de acesso e responsabilidades.
486
+ - Filtragem de Formas de Pagamento: Permitir que organizações configurem e restrinjam as formas de pagamento disponíveis nos centros de custos para alinhar com suas políticas financeiras.
487
+ - **Caso de Uso:**
488
+ - Uma organização compradora necessita reorganizar seus centros de custos e atualizar os endereços de entrega devido a mudanças operacionais. Utiliza a plataforma para fazer essas alterações de forma autônoma, garantindo que as operações continuem sem interrupções.
489
+ - O administrador da organização ajusta as formas de pagamento aceitas em diferentes centros de custos para melhor controle financeiro e conformidade com novas regulamentações fiscais.
490
+ - **Segurança:** Implementar controles rigorosos para assegurar que apenas usuários autorizados dentro da organização possam fazer alterações críticas, especialmente em áreas sensíveis como financeira e operacional.
491
+
492
+ ---
493
+
494
+ ## Plano e Detalhamento Detalhado da Fase 3
495
+
496
+ Implementar soluções robustas para gerenciamento e automação de fabricantes de médio porte, finalizando com a gestão avançada de prospects.
497
+
498
+ **Times envolvidos:** Identity, Storage, Catalogo, Checkout, OMS, Billing, FastStore
499
+
500
+ ### Objetivos
501
+
502
+ - Entregar ferramentas avançadas de gestão de prospects e interfaces para agilizar a aquisição e integração de novas organizações compradoras.
503
+
504
+ ### Proposta de Valor
505
+
506
+ - Maximizar a eficiência na captação e integração de novas organizações compradoras agilizando a aprovação e consistência de novos parceiros do nosso cliente VTEX.
507
+
508
+ ### Requisitos de Produto
509
+
510
+ #### Visualização do Status de Pedido com Autorização
511
+
512
+ - **Objetivo:** Habilitar a visualização controlada do status de pedidos, permitindo que membros autorizados vejam apenas seus próprios pedidos ou todos os pedidos da organização ou centro de custos ao qual estão associados.
513
+ - **Funcionalidade Principal:** Permitir que membros com diferentes níveis de autorização visualizem o status dos pedidos de acordo com sua role específica, seja apenas seus próprios pedidos ou todos os pedidos relacionados à sua organização ou centro de custos.
514
+ - **Caso de Uso:** Um "Buyer Member" com permissões limitadas pode acessar e verificar o status apenas dos pedidos que ele mesmo realizou, enquanto um "Buyer Admin" ou membro com permissões superiores pode visualizar o status de todos os pedidos vinculados à organização ou ao centro de custos específico, facilitando a gestão abrangente e a coordenação logística.
515
+ - **Segurança:** Controles de acesso baseados em roles devem ser aplicados para garantir que informações sobre o status dos pedidos sejam acessadas apenas por membros autorizados.
516
+ - **Observação:** O objetivo desta funcionalidade é implementar a permissão de visualização de pedidos próprios ou visualização de todos os pedidos do centro de custo ou organização. Não é objetivo desta funcionalidade unificar pedidos de múltiplos centros de custos no My Orders. Ou seja, quando um membro precisar acessar outro centro de custo, ele deverá utilizar a funcionalidade de troca de centro de custo.
517
+
518
+ #### API de Prospects
519
+
520
+ - **Objetivo:** Facilitar o registro e a moderação de prospects por organizações de diferentes tamanhos, oferecendo flexibilidade para a gestão interna via admin VTEX e integração com sistemas externos para organizações maiores.
521
+ - **Funcionalidades Principais:**
522
+ - Registro e Listagem de Prospects: Permitir que prospects se cadastrem via site e que suas informações sejam listadas com status inicial 'Pendente'.
523
+ - Moderação e Status: Habilitar administradores a aprovar, rejeitar ou adicionar observações aos registros de prospects.
524
+ - Validação Externa para Organizações Maiores: Oferecer capacidade para organizações maiores receberem dados de prospects em seus próprios sistemas, permitindo que validem esses prospects contra suas regras comerciais ou APIs externas e decidam sobre sua aprovação ou rejeição.
525
+ - Transformação de Prospect em Cliente: Uma vez que um prospect é aprovado, a API deve permitir a associação de políticas comerciais específicas ao novo cliente, incluindo tabelas de preços e catálogos, conforme definido pela organização.
526
+ - **Caso de Uso:**
527
+ - Uma pequena empresa utiliza o admin da VTEX para gerenciar e moderar novos prospects, aprovando ou rejeitando candidaturas com base em avaliações internas.
528
+ - Uma grande organização integra a API de Cadastro de Prospects com seu sistema de CRM para realizar verificações automáticas contra regras comerciais estabelecidas, aprovando prospects que atendem aos critérios e rejeitando aqueles que não.
529
+ - **Flexibilidade e Configuração:** A API deve permitir configurações personalizáveis para adaptar o fluxo de trabalho de moderação de prospects de acordo com o tamanho e as necessidades específicas da organização, tanto para processos internos quanto para integrações externas.
530
+ - **Segurança:** Implementar controles de acesso e segurança rigorosos para garantir que apenas usuários autorizados possam gerenciar informações de prospects e para proteger a transferência de dados para sistemas externos.
531
+
532
+ #### Personificação por Representantes de Vendas
533
+
534
+ - **Objetivo:** Permitir que representantes de vendas personifiquem membros específicos de organizações compradoras durante interações de venda, facilitando processos como pedidos e suporte ao cliente.
535
+ - **Funcionalidade Principal:** Habilitar representantes de vendas a assumir temporariamente a identidade de um membro da organização compradora para realizar ações em seu nome, como colocar pedidos, acessar informações específicas do membro, e gerenciar transações.
536
+ - **Caso de Uso:** Um representante de vendas precisa acessar o sistema como se fosse um membro da organização compradora para entender melhor as necessidades do cliente, ajustar o pedido conforme as preferências registradas, ou resolver uma questão específica relacionada ao status de um pedido.
537
+ - **Flexibilidade e Configuração:** A funcionalidade deve ser flexível o suficiente para permitir a personificação de diferentes membros dentro de uma organização compradora.
538
+ - **Segurança:** Implementação de protocolos de segurança para garantir que apenas representantes de vendas autorizados possam personificar membros, com autenticação e autorização estritas.
539
+
540
+ #### UI Flexibilidade de Compra para Centros de Custos
541
+
542
+ - **Objetivo:** Permitir que membros de uma buyer organization alterem seu centro de custo durante a jornada de compra (discovery), aplicando as regras comerciais específicas do novo centro de custo.
543
+ - **Funcionalidade Principal:** Mudar o centro de custo durante a jornada de compra para aplicar regras comerciais específicas (price table, coleção, sellers, politica comercial, formas de pagamento restritas e endereços específicos) antes do checkout.
544
+ - **Caso de Uso:** Um membro da buyer organization inicia uma compra e, ao selecionar produtos, percebe que precisa utilizar um centro de custo diferente para aproveitar uma política comercial mais vantajosa. O membro altera o centro de custo na área de discovery e continua a compra com as regras do novo centro de custo aplicadas automaticamente.
545
+
546
+ #### Cadastro de Prospects na Frente de Loja
547
+
548
+ - **Objetivo:** Facilitar o cadastro de prospects através de um formulário padrão na frente de loja, permitindo que cada merchant customize o formulário com campos específicos conforme suas necessidades de negócio.
549
+ - **Funcionalidades Principais:**
550
+ - Formulário Padrão de Cadastro: Implementar um formulário básico de cadastro de prospects na frente de loja que coleta informações essenciais como nome da organização, endereço principal e informações do membro principal.
551
+ - Customização do Formulário: Permitir que merchants personalizem o formulário de cadastro para incluir campos adicionais específicos, como faturamento do cliente, segmento de mercado, entre outros.
552
+ - **Caso de Uso:** Um merchant precisa coletar informações detalhadas sobre o faturamento anual e o segmento de mercado de seus prospects para qualificar melhor as oportunidades de vendas e adequar suas estratégias de marketing e vendas às necessidades específicas desses prospects.
553
+ - **Flexibilidade e Configuração:** Deve-se oferecer a capacidade de configurar o formulário de cadastro para incluir ou excluir campos conforme os requisitos do merchant, garantindo que as informações relevantes sejam coletadas sem sobrecarregar o usuário com campos desnecessários.
554
+
555
+ #### Gestão de Prospects no Admin da VTEX
556
+
557
+ - **Objetivo:** Permitir que merchants gerenciem e moderem efetivamente os registros de prospects dentro do admin da VTEX, facilitando a avaliação e a conversão desses prospects em clientes.
558
+ - **Funcionalidade Principal:** Oferecer uma interface no admin da VTEX onde os merchants podem visualizar todos os registros de prospects, revisar detalhes fornecidos e moderar esses registros, decidindo sobre aprovação, rejeição ou solicitação de mais informações.
559
+ - **Caso de Uso:** Um administrador de vendas acessa o admin da VTEX para revisar uma lista de novos prospectos cadastrados. Ele examina as informações submetidas, verifica a conformidade com os critérios de qualificação da empresa e decide aprovar prospectos promissores ou rejeitar aqueles que não atendem aos padrões necessários.
560
+ - **Flexibilidade e Configuração:** A interface de gestão de prospectos deve permitir personalizações no processo de visualização e moderação, como filtros por data de cadastro, status de moderação, nome da organização, nome do contato principal, email do contato principal.
561
+
562
+ #### Gestão das Organizações Compradoras pelo Merchant
563
+
564
+ - **Objetivo:** Equipar merchants com ferramentas completas para gerenciar organizações compradoras, incluindo detalhes organizacionais, endereços, centros de custos, e perfis de membros, além de aplicar regras comerciais customizadas.
565
+ - **Funcionalidade Principal:**
566
+ - Gestão de Organizações: Permitir que merchants visualizem e gerenciem todos os aspectos das organizações compradoras, incluindo dados básicos, endereços, e membros.
567
+ - Aplicação de Pacotes de Regras Comerciais: Facilitar a definição e aplicação de pacotes de regras comerciais específicas para organizações, com um pacote padrão aplicável automaticamente a prospects recém-aprovados.
568
+ - **Caso de Uso:** Um administrador precisa revisar e atualizar as informações de uma organização compradora, ajustar seu pacote de regras comerciais ou modificar o centro de custos e os membros associados, tudo a partir de uma interface centralizada.
569
+ - **Flexibilidade e Configuração:** Permitir personalizações no painel de gestão para incluir filtros por data de cadastro, nome da organização, nome do contato, email principal, e status (ativo, inativo), facilitando a localização rápida de informações específicas. Oferecer a capacidade de configurar e aplicar diferentes pacotes de regras comerciais para atender às necessidades variadas das organizações compradoras, além de um pacote padrão para novos prospects.
570
+ - **Segurança:** Implementar controles de acesso robustos para garantir que apenas pessoal autorizado possa gerenciar as informações das organizações compradoras.
571
+ - **Funcionalidades Adicionais:**
572
+ - Gerenciamento de Endereços e Centros de Custos: Capacidade de editar e atualizar endereços e detalhes de centros de custos, incluindo adição e remoção de endereços e reconfiguração de centros de custos.
573
+ - Gerenciamento de Membros: Administração de membros da organização, incluindo a adição, remoção e atualização de perfis e definição de níveis de acesso.
574
+
575
+ ---
576
+
577
+ ## Plano e Detalhamento Detalhado da Fase 4
578
+
579
+ Implementar soluções robustas para gerenciamento e automação de fabricantes de grande porte, incluindo APIs para administração completa de organizações compradoras enterprise, endereços e centros de custos.
580
+
581
+ **Times envolvidos:** Identity, Storage, Catalogo, Checkout, OMS, Billing
582
+
583
+ ### Objetivos
584
+
585
+ - Permitir a gestão para merchants enterprise com APIs completas para administração de organizações, endereços e centros de custos.
586
+
587
+ ### Proposta de Valor
588
+
589
+ - Garantir conformidade com as exigências de grandes organizações compradoras, possibilitando uma gestão centralizada em múltiplos merchants e oferecendo controle rigoroso sobre operações comerciais e regras de compliance.
590
+ - Simplificar e acelerar a integração de novas organizações compradoras, melhorando o fluxo de entrada no mercado.
591
+
592
+ ### Requisitos de Produto
593
+
594
+ #### API de Gerenciamento de Organizações e Endereços *(unificados pela simplicidade do caso)*
595
+
596
+ - **Objetivo:** Permitir que organizações compradoras existentes gerenciem seus próprios detalhes dentro das permissões concedidas pelo merchant que criou a organização enterprise.
597
+ - **Funcionalidade Principal:**
598
+ - Gerenciamento de Endereços: Organizações podem atualizar seus endereços de entrega e faturamento, condicionado à autorização prévia do merchant.
599
+ - Filtragem de Formas de Pagamento: Permitir que a organização defina quais formas de pagamento estarão disponíveis para seus usuários, personalizando a experiência de pagamento conforme suas necessidades e políticas internas.
600
+ - **Caso de Uso:**
601
+ - Uma organização compradora precisa atualizar seu endereço de entrega após mudança de localização. Utiliza a API para modificar o endereço, sujeito a prévia autorização do merchant.
602
+ - A organização opta por limitar as opções de pagamento disponíveis para seus usuários a fim de aderir a políticas de gastos internas, usando a API para configurar as formas de pagamento permitidas.
603
+ - **Flexibilidade e Configuração:** A API deve ser flexível o suficiente para permitir que cada organização personalize as formas de pagamento conforme sua estratégia financeira, sem alterar os dados fundamentais da organização, que são geridos pelo merchant.
604
+ - **Segurança:** Implementar controles de acesso rigorosos para garantir que apenas usuários autorizados dentro da organização possam fazer alterações nos endereços e configurações de pagamento.
605
+
606
+ #### API de Gerenciamento de Centros de Custos e Endereços *(unificados pela simplicidade do caso)*
607
+
608
+ - **Objetivo:** Capacitar centros de custos dentro de organizações compradoras a gerenciar de forma autônoma seus endereços, formas de pagamento e membros, proporcionando flexibilidade e controle detalhado sobre suas operações específicas.
609
+ - **Funcionalidade Principal:**
610
+ - Gerenciamento de Endereços: Permitir que centros de custos atualizem e modifiquem seus endereços de entrega e faturamento conforme necessário para atender às suas operações logísticas e requisitos de negócios.
611
+ - Filtragem de Formas de Pagamento: Habilitar centros de custos a personalizar e filtrar as formas de pagamento disponíveis, assegurando que as transações se alinhem com suas políticas financeiras e orçamentárias.
612
+ - Gerenciamento de Membros: Facilitar a adição, remoção e atualização de membros associados aos centros de custos, permitindo um controle refinado sobre quem pode executar ações em nome do centro.
613
+ - **Caso de Uso:**
614
+ - Um centro de custos precisa mudar seu endereço de entrega devido à realocação de suas operações. Utilizando a API, o administrador do centro de custos atualiza o endereço rapidamente, garantindo que não haja interrupção nas entregas futuras. Deve haver permissão prévia do merchant.
615
+ - Para aderir às novas diretrizes orçamentárias, um centro de custos ajusta as formas de pagamento permitidas para suas compras, utilizando a API para restringir certas opções e promover outras mais viáveis financeiramente.
616
+ - Com mudanças na equipe, o administrador do centro de custos precisa remover um membro que deixou a empresa e adicionar novos membros com as devidas permissões, usando a API para garantir que apenas pessoal autorizado tenha acesso às funcionalidades do centro.
617
+ - **Flexibilidade e Configuração:** A API deve ser flexível o suficiente para permitir modificações rápidas e eficientes em endereços, formas de pagamento e detalhes de membros, adaptando-se facilmente às mudanças organizacionais ou de política interna.
618
+ - **Segurança:** Implementação de controles de acesso baseados em permissões, assegurando que apenas usuários autorizados possam fazer alterações nos centros de custos.
619
+
620
+ #### API de Membros
621
+
622
+ - **Objetivo:** Permitir que as organizações compradoras administrem os detalhes de seus membros, como nome, email, e roles atribuídas, dentro de um conjunto de opções pré-definidas pelo merchant que criou a organização enterprise.
623
+ - **Funcionalidade Principal:** Organizações compradoras podem adicionar, atualizar ou remover membros, especificando nome, email, e atribuindo roles definidas pelo merchant.
624
+ - **Caso de Uso:**
625
+ - Uma organização precisa adicionar um novo membro ao seu time de compras. O administrador da organização usa a API para registrar o novo membro, inserindo seu nome, email e atribuindo-lhe uma role específica, como "Buyer Member" ou "Buyer Admin", conforme permitido pelo merchant.
626
+ - A organização precisa atualizar o email de um membro existente ou modificar sua role dentro da organização devido a mudanças internas de função ou responsabilidade.
627
+ - **Flexibilidade e Configuração:** A API deve permitir que a organização ajuste facilmente as informações dos membros e as roles, respeitando as restrições de roles pré-definidas pelo merchant para garantir conformidade e alinhamento com as políticas gerais de gestão.
628
+ - **Segurança:** Controles de acesso devem garantir que apenas administradores autorizados da organização compradora possam gerenciar membros.
629
+
630
+ #### Autenticação de Membros de Organizações Enterprise
631
+
632
+ - **Objetivo:** Implementar um sistema de autenticação que permita aos membros de organizações enterprise identificar-se e selecionar entre múltiplas organizações associadas a sua conta no momento do login em determinado merchant.
633
+ - **Funcionalidade Principal:** Capacitar membros de organizações enterprise a autenticar suas identidades e, subsequentemente, escolher de uma lista de organizações associadas a qual desejam acessar durante a sessão.
634
+ - **Caso de Uso:** Um membro pertence a várias organizações enterprise e precisa acessar recursos específicos de uma delas. Após a autenticação inicial, uma tela de seleção permite que o membro escolha qual organização deseja gerenciar naquela sessão, garantindo que o acesso seja concedido somente aos recursos e dados pertinentes à organização selecionada.
635
+ - **Flexibilidade e Configuração:** O sistema de autenticação deve ser flexível o suficiente para suportar membros com múltiplas afiliações organizacionais, permitindo configurações personalizadas que possam ser ajustadas conforme as políticas de segurança da empresa.
636
+ - **Segurança:** Implementar protocolos de segurança robustos para validar a identidade dos membros e proteger a escolha da organização durante o processo de login, incluindo medidas como autenticação de dois fatores (2FA) para uma camada extra de segurança.
637
+
638
+ ---
639
+
640
+ ## Anexos
641
+
642
+ - English Version
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@vtex/faststore-plugin-buyer-portal",
3
- "version": "1.3.85",
3
+ "version": "1.3.86",
4
4
  "description": "A plugin for faststore with buyer portal",
5
5
  "main": "index.js",
6
6
  "scripts": {
package/plugin.config.js CHANGED
@@ -92,6 +92,10 @@ module.exports = {
92
92
  path: "/pvt/organization-account/buyer-organization-manager",
93
93
  appLayout: false,
94
94
  },
95
+ "order-entry": {
96
+ path: "/pvt/organization-account/order-entry",
97
+ appLayout: false,
98
+ },
95
99
  },
96
100
 
97
101
  apis: {
@@ -0,0 +1,139 @@
1
+ import { useEffect, useMemo, useRef } from "react";
2
+
3
+ import { isDevelopment } from "../../shared/utils/environment";
4
+
5
+ const B2B_AGENT_URL = isDevelopment()
6
+ ? "http://localhost:3001/app/order-entry-agent"
7
+ : "https://order-entry-agent.vercel.app/app/order-entry-agent";
8
+
9
+ interface OrderEntryLayoutProps {
10
+ vtexIdclientAutCookie: string;
11
+ vtexIdclientAutCookie_client: string;
12
+ account: string;
13
+ locale?: string;
14
+ customerId?: string;
15
+ userId?: string;
16
+ session?: string;
17
+ segment?: string;
18
+ }
19
+
20
+ const containerStyle: React.CSSProperties = {
21
+ display: "flex",
22
+ flexDirection: "column",
23
+ width: "100%",
24
+ height: "100vh",
25
+ overflow: "hidden",
26
+ };
27
+
28
+ const iframeStyle: React.CSSProperties = {
29
+ flex: 1,
30
+ width: "100%",
31
+ height: "100%",
32
+ border: "none",
33
+ };
34
+
35
+ export const OrderEntryLayout = ({
36
+ vtexIdclientAutCookie,
37
+ vtexIdclientAutCookie_client,
38
+ account,
39
+ locale,
40
+ segment,
41
+ session,
42
+ customerId,
43
+ userId,
44
+ }: OrderEntryLayoutProps) => {
45
+ const iframeRef = useRef<HTMLIFrameElement>(null);
46
+
47
+ const agentOrigin = useMemo(() => new URL(B2B_AGENT_URL).origin, []);
48
+
49
+ useEffect(() => {
50
+ function postAuthToIframe() {
51
+ const targetWindow = iframeRef.current?.contentWindow;
52
+ if (!targetWindow) return;
53
+
54
+ // We send only the token (not the full Cookie header) to reduce exposure.
55
+ targetWindow.postMessage(
56
+ {
57
+ type: "AUTH_TOKEN_UPDATE",
58
+ vtexIdclientAutCookie,
59
+ vtexIdclientAutCookie_client,
60
+ segment,
61
+ session,
62
+ account,
63
+ locale,
64
+ customerId,
65
+ userId,
66
+ },
67
+ agentOrigin
68
+ );
69
+ }
70
+
71
+ function onMessage(event: MessageEvent) {
72
+ // Only accept messages coming from the iframe's origin.
73
+ if (event.origin !== agentOrigin) return;
74
+
75
+ // Ensure the message is from the iframe window we embedded.
76
+ if (event.source !== iframeRef.current?.contentWindow) return;
77
+
78
+ // Handshake: child tells it is ready; parent responds by sending auth.
79
+ if (event.data?.type === "B2B_AGENT_READY") {
80
+ postAuthToIframe();
81
+ }
82
+ }
83
+
84
+ window.addEventListener("message", onMessage);
85
+
86
+ // Fallback: try once after iframe load in case READY was missed.
87
+ const iframe = iframeRef.current;
88
+ let loadFallbackId: ReturnType<typeof setTimeout>;
89
+ const onLoad = () => {
90
+ // Small delay to allow the iframe app to attach its message listener.
91
+ loadFallbackId = setTimeout(() => {
92
+ postAuthToIframe();
93
+ }, 150);
94
+ };
95
+
96
+ if (iframe) iframe.addEventListener("load", onLoad);
97
+
98
+ // If token changes while iframe is already up, proactively resend.
99
+ // This is safe because we still constrain by agentOrigin.
100
+ let resendId: ReturnType<typeof setTimeout>;
101
+ if (iframeRef.current?.contentWindow && vtexIdclientAutCookie) {
102
+ // Delay to avoid racing the initial mount.
103
+ resendId = setTimeout(() => {
104
+ postAuthToIframe();
105
+ }, 1);
106
+ }
107
+
108
+ return () => {
109
+ window.removeEventListener("message", onMessage);
110
+ if (iframe) iframe.removeEventListener("load", onLoad);
111
+ clearTimeout(loadFallbackId);
112
+ clearTimeout(resendId);
113
+ };
114
+ }, [
115
+ vtexIdclientAutCookie,
116
+ vtexIdclientAutCookie_client,
117
+ segment,
118
+ session,
119
+ account,
120
+ locale,
121
+ customerId,
122
+ userId,
123
+ agentOrigin,
124
+ ]);
125
+
126
+ return (
127
+ <section style={containerStyle} data-fs-bp-b2b-agent>
128
+ <iframe
129
+ ref={iframeRef}
130
+ style={iframeStyle}
131
+ data-fs-bp-b2b-agent-iframe
132
+ src={B2B_AGENT_URL}
133
+ title="Order Entry Agent"
134
+ allow="clipboard-read; clipboard-write"
135
+ sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-modals"
136
+ />
137
+ </section>
138
+ );
139
+ };
@@ -105,6 +105,16 @@ export const OrgUnitsDetailsLayout = ({
105
105
 
106
106
  <Dropdown>
107
107
  <DropdownButton asChild>
108
+ {/* TO-DO: Reenable button when agent is made ready for users */}
109
+ {/*
110
+ <Button
111
+ data-fs-order-entry-button
112
+ variant="secondary"
113
+ onClick={() => router.push(buyerPortalRoutes.orderEntry)}
114
+ >
115
+ Order Entry - Agent{" "}
116
+ </Button>
117
+ */}
108
118
  <HeaderInside.Button />
109
119
  </DropdownButton>
110
120
 
@@ -8,6 +8,7 @@
8
8
  @import "../../components/AuthSetupDrawer/auth-setup-drawer.scss";
9
9
 
10
10
  [data-fs-org-units-details-section] {
11
+ @import "@faststore/ui/src/components/atoms/Button/styles.scss";
11
12
  @import "../../../shared/components/BasicCard/basic-card.scss";
12
13
  @import "../../../shared/components/VerticalNav/vertical-nav.scss";
13
14
  @import "../../../shared/components/LetterHighlight/letter-highlight.scss";
@@ -20,16 +21,21 @@
20
21
  padding: var(--fs-bp-margin-0) var(--fs-bp-padding-5);
21
22
  padding-bottom: var(--fs-bp-padding-12);
22
23
 
23
- @include media('>=tablet') {
24
+ @include media(">=tablet") {
24
25
  padding-left: var(--fs-bp-padding-10);
25
26
  padding-right: var(--fs-bp-padding-10);
26
27
  }
27
28
 
28
- @include media('>=notebook') {
29
+ @include media(">=notebook") {
29
30
  padding-left: var(--fs-bp-padding-12);
30
31
  padding-right: var(--fs-bp-padding-12);
31
32
  }
32
33
 
34
+ [data-fs-order-entry-button] {
35
+ border-radius: var(--fs-bp-border-radius-full);
36
+ --fs-button-border-radius: var(--fs-bp-border-radius-full);
37
+ }
38
+
33
39
  [data-fs-bp-header-inside] {
34
40
  [data-fs-org-units-details-header-skeleton] {
35
41
  max-width: 40rem;
@@ -67,40 +73,41 @@
67
73
  [data-fs-card-body] {
68
74
  padding: var(--fs-bp-margin-2) var(--fs-bp-margin-0) var(--fs-bp-margin-5);
69
75
 
70
- @include media('>=tablet') {
71
- padding: var(--fs-bp-margin-5) var(--fs-bp-margin-3) var(--fs-bp-margin-8);
76
+ @include media(">=tablet") {
77
+ padding: var(--fs-bp-margin-5) var(--fs-bp-margin-3)
78
+ var(--fs-bp-margin-8);
72
79
  }
73
80
  }
74
81
 
75
82
  [data-fs-card-footer] {
76
83
  padding: var(--fs-bp-padding-5);
77
84
 
78
- @include media('>=tablet') {
85
+ @include media(">=tablet") {
79
86
  padding-left: var(--fs-bp-padding-8);
80
87
  padding-right: var(--fs-bp-padding-8);
81
88
  }
82
89
 
83
90
  [data-fs-card-footer-link] {
84
91
  color: var(--fs-bp-color-brand);
85
- @include text-style('action');
92
+ @include text-style("action");
86
93
 
87
- @include media('>=tablet') {
88
- @include text-style('emphasis');
94
+ @include media(">=tablet") {
95
+ @include text-style("emphasis");
89
96
  }
90
97
  }
91
98
  }
92
99
 
93
100
  &[data-fs-bp-contracts-settings-card] {
94
101
  [data-fs-bp-letter-highlight] {
95
- @include text-style('body');
102
+ @include text-style("body");
96
103
  margin-top: var(--fs-bp-margin-3);
97
104
  margin-left: var(--fs-bp-margin-5);
98
105
  margin-bottom: var(--fs-bp-margin-0);
99
106
  width: var(--fs-bp-spacing-9);
100
107
  height: var(--fs-bp-spacing-9);
101
108
 
102
- @include media('>=tablet') {
103
- @include text-style('display-6');
109
+ @include media(">=tablet") {
110
+ @include text-style("display-6");
104
111
  margin-bottom: var(--fs-bp-margin-1);
105
112
  width: var(--fs-bp-spacing-12);
106
113
  height: var(--fs-bp-spacing-12);
@@ -112,19 +119,19 @@
112
119
  [data-fs-vertical-nav-menu] {
113
120
  [data-fs-vertical-nav-menu-list] {
114
121
  margin-top: var(--fs-bp-margin-1);
115
- @include media('>=tablet') {
122
+ @include media(">=tablet") {
116
123
  margin-top: var(--fs-bp-margin-5);
117
124
  }
118
125
 
119
126
  [data-fs-vertical-nav-menu-link] {
120
127
  border-radius: var(--fs-bp-border-radius-0);
121
128
 
122
- @include media('>=tablet') {
129
+ @include media(">=tablet") {
123
130
  border-radius: var(--fs-bp-border-radius-full);
124
131
  }
125
132
  }
126
133
  }
127
-
134
+
128
135
  [data-fs-vertical-nav-menu-org-wrapper] {
129
136
  min-height: var(--fs-bp-spacing-9);
130
137
  padding: var(--fs-bp-padding-2) 0;
@@ -16,6 +16,7 @@ export const buyerPortalRoutes = {
16
16
  replaceParams(`${base}/profile/[orgUnitId]/[contractId]`, params),
17
17
 
18
18
  b2bAgent: `${base}/buyer-organization-manager`,
19
+ orderEntry: `${base}/order-entry`,
19
20
 
20
21
  addresses: (params: { orgUnitId: string; contractId: string }) =>
21
22
  replaceParams(`${base}/addresses/[orgUnitId]/[contractId]`, params),
@@ -22,7 +22,7 @@ export const SCOPE_KEYS = {
22
22
  CREDIT_CARDS: "creditCards",
23
23
  } as const;
24
24
 
25
- export const CURRENT_VERSION = "1.3.85";
25
+ export const CURRENT_VERSION = "1.3.86";
26
26
 
27
27
  export const CHANGES_TIMEOUT_MESSAGE =
28
28
  "Changes may take up to 10 minutes to apply.";
@@ -0,0 +1,125 @@
1
+ import storeConfig from "discovery.config";
2
+
3
+ import { OrderEntryLayout } from "../features/order-entry/layouts/OrderEntryLayout";
4
+ import { withErrorBoundary } from "../features/shared/components";
5
+ import {
6
+ withAuthLoader,
7
+ withLoaderErrorBoundary,
8
+ } from "../features/shared/utils";
9
+
10
+ import type { AuthRouteProps, LoaderData } from "../features/shared/types";
11
+
12
+ /**
13
+ * Extracts the VTEX auth token value from a Cookie header string.
14
+ * Returns only the cookie VALUE (JWT), never "CookieName=value".
15
+ */
16
+ const getAuthCookieInfo = (
17
+ cookieHeader: string
18
+ ): {
19
+ token: string;
20
+ accountFromCookie?: string;
21
+ session?: string;
22
+ segment?: string;
23
+ } => {
24
+ if (!cookieHeader) return { token: "" };
25
+
26
+ const session = cookieHeader.match(/vtex_session=([^;]+)/);
27
+
28
+ const segment = cookieHeader.match(/vtex_segment=([^;]+)/);
29
+
30
+ // VtexIdclientAutCookie_<account>=<value>
31
+ const authCookieRegex = cookieHeader.match(
32
+ /VtexIdclientAutCookie_([a-zA-Z0-9-]+)=([^;]+)/
33
+ );
34
+ if (authCookieRegex?.[2])
35
+ return {
36
+ accountFromCookie: authCookieRegex[1],
37
+ token: authCookieRegex[2],
38
+ segment: segment?.[1] ?? "",
39
+ session: session?.[1] ?? "",
40
+ };
41
+
42
+ // fallback: VtexIdclientAutCookie=<value>
43
+ const fallBackAuthCookieRegex = cookieHeader.match(
44
+ /VtexIdclientAutCookie=([^;]+)/
45
+ );
46
+ if (fallBackAuthCookieRegex?.[1])
47
+ return {
48
+ token: fallBackAuthCookieRegex[1],
49
+ segment: segment?.[1] ?? "",
50
+ session: session?.[1] ?? "",
51
+ };
52
+
53
+ return { token: "" };
54
+ };
55
+
56
+ type OrderEntryPageQuery = Record<string, never>;
57
+
58
+ const loaderFunction = async (
59
+ data: LoaderData<OrderEntryPageQuery>
60
+ ): Promise<AuthRouteProps<undefined>> => {
61
+ return withAuthLoader(data, async () => {
62
+ // No business data is returned.
63
+ // The authenticated client context is enough for this page.
64
+ return undefined;
65
+ });
66
+ };
67
+
68
+ export const loader = withLoaderErrorBoundary(loaderFunction, {
69
+ componentName: "OrderEntryPage",
70
+ redirectToError: true,
71
+ });
72
+
73
+ const OrderEntryPage = (props: AuthRouteProps<undefined>) => {
74
+ if (!props.authorized) return null;
75
+
76
+ const cookieHeader = props.clientContext?.cookie ?? "";
77
+ const tokenFromContext = props.clientContext?.vtexIdclientAutCookie ?? "";
78
+
79
+ const {
80
+ token: tokenFromCookie,
81
+ accountFromCookie,
82
+ segment,
83
+ session,
84
+ } = getAuthCookieInfo(cookieHeader);
85
+
86
+ // Prefer a token-like value if available; otherwise extract from cookie header.
87
+ const vtexIdclientAutCookie =
88
+ tokenFromContext && !tokenFromContext.includes("=")
89
+ ? tokenFromContext
90
+ : tokenFromCookie;
91
+
92
+ if (!vtexIdclientAutCookie) {
93
+ throw new Error("Missing VTEX auth token for B2B Agent iframe");
94
+ }
95
+
96
+ // account/locale via discovery.config (recomendado)
97
+ const account = storeConfig?.api?.storeId ?? accountFromCookie ?? "";
98
+ const locale = storeConfig?.session?.locale ?? "en-US";
99
+
100
+ const customerId = props.clientContext?.customerId;
101
+ const userId = props.clientContext?.userId;
102
+
103
+ return (
104
+ <OrderEntryLayout
105
+ vtexIdclientAutCookie={vtexIdclientAutCookie}
106
+ vtexIdclientAutCookie_client={vtexIdclientAutCookie}
107
+ segment={segment}
108
+ session={session}
109
+ account={account}
110
+ locale={locale}
111
+ customerId={customerId}
112
+ userId={userId}
113
+ />
114
+ );
115
+ };
116
+
117
+ export default withErrorBoundary(OrderEntryPage, {
118
+ onError: (error) => {
119
+ console.error("onError", error);
120
+ },
121
+ tags: {
122
+ component: "OrderEntryPage",
123
+ errorType: "order_entry_error",
124
+ },
125
+ });
Binary file