Agenda 01 · Kickoff · Setup do Projeto — Bel Recife + Salvador + São Paulo
Kickoff / Primeira Agenda do Projeto
Caminhos de incorporação societária
- (1) Venda de ativos
- (2) Big Bang — recomendado pelo parecer jurídico para capturar ágio; ~70 lojas tombadas no mesmo dia em 14-17 estados
- (3) Stack tecnológico primeiro, decidindo depois entre Big Bang vs. ondas por estado
- Caminho escolhido: multi-empresa (opção A), priorizando estados de maior faturamento (SP, RJ, Salvador, PE)
Estrutura organizacional e liderança
- Empresas ainda em processo de integração — diretorias já centralizadas, mas a operação ainda não
- Lideranças: Tani (Operações, Comercial, E-commerce, Marketing/CRM) · Flávio (Financeiro, RH, Jurídico, TI)
- 65 lojas Mundo + 72 lojas Bell — Recife = base Mundo, Salvador = base Bell, São Paulo = comercial/diretoria
Escopo e governança do projeto
- Framework de avaliação: 18 áreas e 153 controles (visão de risco de negócio, não só tecnologia)
- Diligência prévia: 66 perguntas de TI + 36 de cibersegurança
- 4 entregáveis: desenho da transição sistêmica/roadmap/valores · arquitetura futura (to-be) · cyber security · D.Org
- Governança: reunião semanal de status + comitê quinzenal + comitê de estratégia/integração mensal
BC Piedade, mais de 80 CNPJs, PDV também Proton — ambiente on-premise/data center. Obrigação de manter histórico por 5 anos; recomendação de manter licença em nuvem em vez de migrar o histórico (sem garantia da TOTVS).
Decisão já definida de tombar o Proton da Bel para o Winthor do Mundo, com troca de PDV correspondente. Infra Mundo 100% cloud na SkyOne, Fortgate como padrão de conectividade/segurança, Algar como provedor de link (~90% das lojas), NOC/SOC + firewall + antivírus já em operação.
Fechamento fiscal terceirizado na Silveira Contabilidade via sistema Domínio.
Nível 1 (obrigatório) = cadastros mestres + estoque por filial · Nível 2 (recomendado) = + saldos financeiros · Nível 3 = + históricos (alta complexidade, sem garantia TOTVS).
🔗 Decisão estrutural que orienta o projeto
Esta reunião definiu a premissa que orienta todas as demais entrevistas de mapeamento: o ambiente tecnológico prevalente será o do Mundo (Winthor/SkyOne), com a Bel migrando integralmente para esse stack — ERP, PDV e infraestrutura. Todas as agendas seguintes (Supply, SAC, Jurídico, Operações de Loja, Comercial, Gente e Gestão) partem dessa decisão.
Fonte: Setup Agenda - Bel Cosméticos (03/08) + Primeira Agenda - Bel Cosméticos (10/08/2026) — Consultoria Peers
Agenda 02 · Bel Recife + Salvador
Supply, Cadastros e Logística
Processos cobertos (Cristiane)
- Abastecimento, cadastro e recebimento fiscal de notas
- Recebimento fiscal centralizado em Recife (5 pessoas), cobre todo o MDC
- Bel Salvador ainda não incluída — opera no sistema próprio da Bel
- Cadastro presta serviço para comercial, notas e abastecimento
- Ocorrências com fornecedor: BEL não usa portal (só e-mail); Mundo acessa portais (ex.: L'Oréal) com usuário/senha próprios, sem integração com o ERP
- Gap de BI: faltas detectadas no recebimento não aparecem no BI — só no fluxo fiscal/GLPI
Logística e inventário (Cícero)
- Recebimento por volume, não por SKU (exceto lojas 8 e 55 — Doca/e-commerce, 100% conferido)
- Sem agendamento de recebimento — fornecedores chegam sem hora marcada
- Avarias bloqueadas como estoque virtual; baixa só no inventário anual
- Inventário anual (jan.) → expectativa de virar semestral pós-integração
- GLPI é usado especificamente para furtos/perdas em loja — fluxo distinto do fiscal/Winthor, que trata faltas no recebimento
Próximos passos da reunião
- Agendar sessão individual com Ivana (Bel Salvador)
ERP central de gestão do MDC — a equipe de cadastro/abastecimento se refere a ele internamente como "Winthor". Mesmo sistema já mapeado no Blueprint (Winthor/TOTVS).
Recebe vendas do Winthor, processa sugestões de compra e devolve pedidos integrados. Parâmetros estratégicos (cobertura de estoque, arredondamento) ficam no UNOUS; parâmetros estruturais (embalagem, faturamento mínimo, fornecedor) ficam no ERP. Já constava no Blueprint como "SAAM, UNOUS" — confirmado como o mesmo sistema que a equipe chama de "Nous".
Captura XMLs contra os CNPJs do MDC e integra ao ERP — equivalente ao sistema já usado na Bel Salvador. Controle gerencial de notas ainda depende de planilha Excel (extração manual diária).
Confirma o ERP legado da Bel já mapeado no Blueprint — ex.: campo "produto ativo/inativo" não existe no Proton, gerando retrabalho de cadastro na migração.
🔗 Achado crítico — modelo EAN × Produto (novo pilar "Cadastro & Dados Mestres" no Blueprint)
MDC historicamente usa 1 produto = 1 EAN; Bel usa N EANs para 1 produto — na prática, há casos como 1 código interno com 56 EANs vinculados na BEL. Decisão tomada: o MDC vai reverter para o modelo da Bel (EAN N:1) — toda a base atual do MDC precisa ser reconstruída (estoque, vendas, histórico, carteira de pedidos). Regra de negócio: fusão de EANs só é permitida se mesmo NCM e mesma gramatura/peso. Já causou problema real na abertura da loja de Lauro de Freitas (produto não reconhecido no scanner). Recomenda-se registrar como risco formal de migração de dados — tratado no Blueprint como o novo pilar transversal "Cadastro & Dados Mestres".
Fonte: Agenda - Supply - Cadastros - Logística BEL REC-SSA — Consultoria Peers, 13/08/2026
Agenda 03 · Bel Recife + Salvador
Digital e SAC
SAC — plataformas de atendimento
- Zendesk: central de atendimento — e-mail, chat, Facebook, Instagram, Google Meu Negócio, Reclame Aqui; CRM (piloto cashback) descontinuado
- Suri: WhatsApp homologado Meta, número único; impedimento p/ Bel — gerenciador de negócios tem logo do Mundo
- Google Meu Negócio: Recife/Salvador em cadastro; Rio de Janeiro sem acesso ainda
- Instagram Bel: sem acesso ao gerenciador Facebook; integração Zendesk pendente
Logística e entregas (Mundo)
- Lalamove + 99 Delivery (principais) · Rappi (pedido ainda não integrado — limitação técnica, não menor uso) + 1 não identificada (secundárias)
- SLA 2h · cobertura extravio: Lalamove até R$ 4.000, 99 até R$ 600
- Correios via Easy Courier (logística reversa)
- Bel: ainda sem plataformas de delivery integradas
Próximos passos da reunião
- Consolidar mapeamento e pontos de atenção (Lauro, Fabio)
- Retornar com perguntas específicas ao time Digital/SAC (Lauro, Fabio)
- Acompanhar retorno do fornecedor Proton sobre token semanal e Store ID (Layssa)
Funciona como iFood — cliente compra e paga, loja só separa. Integrado ao Suri (atendimento) e ao Proton (pedidos). Pagamento via Braspag/Cielo (antifraude ClearSale), contrato ainda não assinado.
Central telefônica com número único (4004), homologada no gerenciador de negócios da Meta — vinculado à marca Mundo do Cabeleireiro. É essa vinculação que bloqueia o Suri/WhatsApp para as lojas Bel. Custo ~R$180-200/mês.
iFood 100% nas lojas do Mundo; piloto Bel planejado para a loja de Ipituba (BA). 99Food em rollout há ~1 mês, ainda parcial — sem integração Bel em nenhum dos dois.
ERP da PB (marketplace), integrado a Mercado Livre, Amazon, TikTok e Shopee — cadastro de produto manual, exportado para os canais. Site próprio de e-commerce da PB roda em VTEX IO. Guias fiscais são geradas no Dootax (dootax.com.br), via processo manual (XML do Bling → FTP → Dootax).
Conferência e posicionamento de estoque totalmente manuais na PB — limitação crítica para o crescimento de SKUs no marketplace.
🔗 Cruzamento com o Blueprint
Confirma o gap já mapeado na camada Canais Digitais — Bel realmente não tem e-commerce próprio, dependendo de marketplace (PB). O uso do Proton no Neomode reforça que o ERP legado da Bel segue ativo mesmo em iniciativas digitais novas. A ausência de WMS na PB reforça o gap de WMS já identificado no comparativo de sistemas (slide 17 / Blueprint).
Fonte: Agenda - Digital - SAC BEL RE-SSA — Consultoria Peers, 13/08/2026
Agenda 04 · Bel Recife
Jurídico, Compliance e Contratos
Escopo do Jurídico (Bel)
- Gestão de contratos (serviços, imobiliários, licenças)
- Contencioso (trabalhista, civil, tributário, consumerista)
- Societário e propriedade intelectual · licenças e alvarás
- Consultoria interna para DP, RH, operações e SAC
- Provisões e contingências — integradas com controladoria via planilha Excel
- Apoia o canal SAC via "Reclame Aqui" — cruzamento direto com o pilar Digital/SAC
Fluxo atual de contratos de serviço
- Gestor negocia e envia minuta por e-mail
- Jurídico revisa e valida pontos frágeis
- Prestador sobe o contrato na plataforma de assinatura digital (DocuSign)
- Jurídico valida fidelidade, assina e encaminha para diretores
- Contrato retorna ao jurídico e é cadastrado no Projuris
Próximos passos da reunião
- Avaliar ativação de módulos adicionais do Projuris — depende de decisão conjunta com TI, não é ação unilateral do Jurídico (Nathalia + Luiz Pecci)
- Mapear e formalizar contratos da Bel com prestadores de serviço
- Revisitar estrutura de LGPD/DPO na Bel
Cobre contratos, processos, societário e licenças. Módulos adicionais (ex.: atualização de índices contratuais) disponíveis no licenciamento, mas ainda não ativados. Sem integração com o ERP — integração financeira é possível, mas não foi implementada.
Sistema da própria Controladoria da Bel para contratos imobiliários e de arrendamento — hoje sem qualquer integração com o Projuris, gerando duplicidade/desalinhamento entre o controle jurídico e o controle financeiro desses contratos.
Sem área de suprimentos — cada área negocia e fecha seu próprio contrato de serviço; sem pedido de compra para serviços (só para produtos de revenda). Gestão financeira dos contratos não passa pelo jurídico — sem confronto entre valor contratado e pagamentos realizados.
Bel não tem equipe jurídica interna — explica a falta de documentação. Contratos praticamente inexistentes ou inacessíveis: relatório de processos obtido, mas incompleto e sem contingenciamento; contratos imobiliários (os mais estratégicos) de difícil acesso.
DPO formalmente atribuído a Nathalia, mas de forma apenas ilustrativa/nominal — sem autoridade ou processo real de governança. Cerca de 5 solicitações de exclusão até agora; políticas publicadas no site, atualizações na base feitas pelo próprio Luiz Pecci. Empresa se autoavalia como não tratando dados sensíveis.
🔗 Cruzamento com o Blueprint
Abre uma dimensão de risco ainda não coberta pelos três frameworks técnicos do Blueprint (COBIT/ITIL/NIST CSF): governança jurídica e contratual. ⚠ Ponto de atenção de nomenclatura: esta agenda tem a tag "BEL REC" — ou seja, Nathalia e o Projuris são a função jurídica central do grupo, herdada do lado Mundo (sediada em Recife), não um sistema próprio da Bel. O que a transcrição chama de "a Bel não tem equipe jurídica" refere-se especificamente ao histórico da Bel legado (Salvador), que essa função central está absorvendo. Blueprint atualizado: Mundo = Projuris (estruturante), Bel = gap de contratos herdado.
Fonte: Agenda - Jurídico - Compliance - Contratos (BEL REC) — Consultoria Peers, 13/08/2026
Agenda 05 · Bel Salvador (SSA) — legado Bel
Operações de Loja — Bel (SSA)
Operação de caixa (PDV)
- Abertura/fechamento autônomos, sem senha gerencial; sangria em livro físico + Proton PDV
- Desconto manual em item derruba as promoções dos demais itens do cupom (achado crítico)
- Sem visibilidade de vendas do dia no caixa — workaround "troca 88" com senha própria
- Cartão físico de desconto de colaborador (15%) aplica desconto no caixa sem exigir senha gerencial — controle fora do fluxo
Problemas técnicos recorrentes
- Travamento no pagamento via TEF: 3–4 ocorrências/semana; casos de mercadoria entregue sem pagamento confirmado
- Cancelamento de Pix com troca de forma de pagamento demora até 30 min
- Integração PDV → Proton RP instável em lojas com internet fraca
- Senha do painel Sitef muda com frequência, gerando transtorno operacional; estorno em falha de TEF leva até 72h
Próximos passos da reunião
- Desenhar fluxo consolidado dos processos mapeados (Lauro, Fabio)
- Realizar entrevista com equipe administrativa (central)
Recebimento via "Conferência Cega" (bipagem sem ver quantidades da nota; central concilia divergências no Proton). Cadastro de produto novo demora até 7 dias ponta a ponta.
Loja não cadastra cliente PJ nem emite Danfe diretamente — mesmo com CNPJ já cadastrado. Perda de vendas corporativas (hotéis, Rede Globo, lojas de aeroporto).
"Relatório 88" para trocas sem origem; produto retorna via motoboy próprio contratado (só em Salvador) ou, no Rio de Janeiro e em Fortaleza, com a própria gerente fazendo o transporte manualmente. Solicitação: cadastro unificado por CPF para trocar em qualquer loja.
🔗 Cruzamento com o Blueprint
Detalha pela primeira vez o dia a dia operacional da Bel (já mapeada como isolada/on-premise) — confirma o gap de WMS/bipagem e adiciona um risco novo e concreto: a dependência total da central para NF-e corporativa, que já custa vendas reais. Entra no Blueprint como novo pilar "Operações de Loja". Gap estratégico levantado pelo próprio time: ausência total de canal digital de venda (100% loja física) — as próprias gerentes sugeriram um modelo "omnichannel" (venda usando estoque de outra loja/central).
Fonte: Agenda - Operações de Loja (BEL SSA) — Consultoria Peers, 14/08/2026
Agenda 06 · Bel Recife (REC) — herdado do Mundo
Operações de Loja — Mundo (REC)
Sistemas em uso nas lojas
- PDV Zanthus (citado como "Santos"/"Zantos") em todas as unidades BEL/MDC
- Retaguarda: Amplys ("sistema legado") · TOTVS já piloto em algumas lojas (ex.: Loja 14)
- GLPI (chamados) · Suri (pedidos WhatsApp) · Cielo (maquininha/link) · SAM (bipagem no recebimento)
- ⚠ Nomenclatura já resolvida por cruzamento entre agendas: "Wintor"/"Entor"/"Entorno" = Winthor mal transcrito (sotaque fora do eixo RJ/SP); "Amplys"/totem físico seguem a validar com Luiz Pecci
Dores em delivery, WhatsApp e comissionamento
- iFood/Rappi/99: finalização manual no PDV — risco de erro entre formas de pagamento
- Frete lançado como "acréscimo de venda", entrando indevidamente no comissionamento das vendedoras
- Fila de atendimento WhatsApp sem automação — demanda de troca de loja após 5 min sem resposta
- Marcar indisponibilidade de estoque com frequência no iFood pode gerar penalização da plataforma — não é só atraso operacional
- Bug de cadastro: campo de celular só aceita 10 dígitos, mas números de SP (e outros estados) têm 11 — trava o cadastro de cliente
Contingência e logística entre filiais
- Existe POS avulsa (maquininha separada) para quedas de energia/internet no Shopping Anália Franco
- Não há transportadora formal para transferência entre filiais — depende de rota informal de um único gerente de logística (risco de escalabilidade)
Próximos passos da reunião
- Compilar todos os mapeamentos em documento consolidado (Fabio)
- Definir responsável pela curadoria de playlists por loja/região
Cancelamento de venda não integra do PDV ao Amplys (chamado + voucher manual); troca de produto bloqueia crédito do cliente. Atrasos de 5 a 12 dias na integração de vendas já geraram multa em portal de shopping (Loja 14).
Usado como retaguarda adicional em algumas lojas (ex.: Loja 14), ao lado do Zanthus — sinal de que a consolidação para o padrão único já começou organicamente. TOTVS ainda recebe cargas de promoção mais devagar que o PDV.
Só Lojas 5, 8 e 11 (Recife) e 55 (SP) têm recebimento por bipagem — muito mais ágil que a conferência manual. Troca entre filiais ainda sem sistema integrado.
🔗 Cruzamento com o Blueprint
Confirma e detalha a arquitetura Mundo já mapeada (Zanthus, GLPI, Suri) — revela o sistema "Amplys", não documentado antes (relação com o Winthor a validar), e mostra que mesmo do lado Mundo a integração PDV↔retaguarda tem falhas recorrentes. Vira risco formal e novo pilar "Operações de Loja" no Blueprint.
Fonte: Agenda - Operações de Loja (BEL REC) — Consultoria Peers, 14/08/2026
Agenda 07 · Bel Recife (REC) — herdado do Mundo
Comercial — Mundo (REC)
Estrutura da equipe comercial
- Soraya (diretora) · Adalberto (coordenador, rotina 111) · Suan (pricing/margem)
- Andreza (gestão de categoria) · Rafaela (trade, controle via Excel)
- Roger: promoções no Zanthus + conta corrente de fornecedores · Jennifer: cadastro/Spenetrack
Negociação com fornecedores e JBP
- JBP atrelado a metas de sell-in/sell-out; verba proporcional ao volume realizado
- Política: não superestocar para bater meta — se venda não suporta, renegocia
- Black Friday: análise histórica no Winthor (BI) + rotina 200 para simular margem
- Exemplo concreto: Bel não bateu a meta de sell-in do JBP da L'Oréal Professional no ano anterior — recebeu verba só via trade/sellout
Ponto cego e proposta para queima de estoque
- Loja piloto BEL já opera com preço calculado pelo Mundo, mas o time comercial da Bel não consegue auditar/analisar a margem dessa loja
- Lógica proposta para controle de queima de estoque: "corrida" entre dois gatilhos — o que ocorrer primeiro entre "vendeu a quantidade limite" ou "atingiu a data de vencimento" encerra a promoção
- Risco de estoque compartilhado loja física/e-commerce: caso concreto na Black Friday, venda dupla do mesmo item
Próximos passos da reunião
- Agendar entrevista com Cristiane (time de cadastro)
- Agendar entrevista com equipe comercial de Salvador (Bel)
- Aprofundar questão de DRE por filial com o time financeiro
111: venda diária/margem por fornecedor · 200: simulação de promoções/precificação · 290: coerência verba × bonificação · 820: gestão de categoria (entrada/saída, estoque, giro).
Cadastro e execução de promoções, envio direto ao PDV. Promoções com validade até 2030 usadas como tabela de preço fixa.
Único dado extraído do ERP é a nota bonificada (rotina 290) — apuração de débitos/créditos de verba é toda manual.
🔗 Achado crítico — verba não rateada por loja
Aplicação de verba no ERP concentra-se em 2-3 lojas em vez de ser rateada proporcionalmente — distorce a margem por filial e inviabiliza a análise pós-verba (equipe sempre analisa margem pré-verba). Some-se: estoque compartilhado loja física/e-commerce gera venda duplicada do mesmo item, e o cadastro de produtos Bel × Mundo é duplicado (vínculo manual pela Cristiane). Ambos entram no Blueprint como novo pilar "Comercial" e riscos formais. A divergência de cardinalidade EAN (1:1 Bel vs. 1:N Mundo) também veio à tona nesta entrevista, mas é tratada pelo time de cadastro (Cristiane) — fora do escopo comercial; entra no Blueprint como o novo pilar transversal "Cadastro & Dados Mestres".
Fonte: Agenda - Comercial (BEL REC) — Consultoria Peers, 14/08/2026
Agenda 08 · Bel Salvador (SSA) — legado Bel
Comercial — Bel (SSA)
Estrutura e contexto
- Equipe de Salvador (Patrício) apoia compras e canais digitais (PB Marketing)
- Comunicação com a central (Ivana) por WhatsApp, telefone e e-mail
- Central faz cadastro, entrada de nota e lançamento de preços no sistema
- Gerentes de loja: autonomia de até 15% de desconto adicional
- Qualquer desconto além dos 15% precisa passar pelo comercial de Salvador — diferente de Recife, onde a ponta tem mais autonomia
Recebimento, devoluções e sazonalidade
- Divergências no recebimento detectadas só após abertura — ocorrência aberta à central por e-mail
- Devolução: tudo ou nada no ato da entrega; central emite nota em 3–4 dias
- Feira regional em Salvador 2x/ano (abril, set/out) — 99% bonificado pelo fornecedor
- Evento sazonal Bee Week também compõe o calendário promocional, ao lado de Dia das Mães, Black Friday etc.
- Boletos vencidos ou sem boleto: tratados pelo comercial de Salvador contatando o fornecedor diretamente — processo manual não mapeado antes
Próximos passos da reunião
- Mapear depara dos processos manuais identificados
- Incluir feira regional e canais digitais (PB Marketing) no mapeamento
Extração de relatório por loja em Excel para cálculo de pedido. Cada usuário tem conta própria; sem alteração direta no sistema.
Portal do Sefaz usado para conferência manual de nota fiscal do fornecedor.
Pedidos enviados por e-mail; controle em planilha Excel sem somatório agregado — sem visibilidade do valor total de compras do mês nem do que ficou sem atendimento.
Precificação calculada em planilha (margem + imposto), enviada à central para lançamento. Produtos de baixo giro recebem promoção com vigência longa (até 2 anos) em vez de rebaixa de tabela — a promoção impede o desconto extra de 15% da gerente. As 72 lojas BEL comunicam a necessidade de rebaixa de preço por e-mail à central.
🔗 Cruzamento com o Blueprint
Confirma que o Proton segue como sistema de registro da Bel mesmo no comercial — acesso hoje é só leitura via servidor. A ausência de vínculo sistêmico entre pedido e entrada de nota, já detectada aqui, é o mesmo padrão de processo manual visto em Operações de Loja (BEL SSA). Entra no Blueprint como o lado Bel do novo pilar "Comercial". Diferenças REC vs. SSA a destacar: em Salvador a gerência tem menos autonomia (desconto além de 15% precisa passar pelo comercial central); verba de grandes fornecedores é recebida pontualmente, sem o modelo mensal recorrente de Recife; e o vínculo sistêmico pedido↔nota existe em Recife, mas em Salvador o processo é 100% manual.
Fonte: Agenda - Comercial (BEL SSA) — Consultoria Peers, 14/08/2026
Agenda 09 · Bel Recife + Salvador — comparativo RM × Domínio
Gente e Gestão
Processos manuais e dores identificadas
- Rateio de benefícios por loja: cruzamento manual em Excel, lançado loja a loja — com expansão para 350 lojas pode consumir 1 semana/mês
- Controle de ponto Bel: gerentes enviam planilha de escala, DP importa manualmente no RM
- Transferências de pessoal (~40-50/mês): lançadas manualmente pelo DP no RM
- Entrevista de desligamento: manual via WhatsApp, pessoa a pessoa — inviável na escala atual
Pontos de atenção para a migração
- Ausência de e-mail corporativo nomeado para gerentes bloqueia automação de transferências/desligamentos no Meu RH
- Ponto Bel não integrado à infraestrutura de rede das lojas — migração depende de TI e tem implicações de segurança
- Causa-raiz de erros de ponto: ausência de geolocalização é decisão de custo, exigindo aprovação manual do gestor — fonte recorrente de erro ("gestor desatento")
- Proposta concreta: criar campo complementar de e-mail corporativo no RM, exclusivo para o fluxo de aprovação, sem substituir o e-mail pessoal — jurídico não permite usar e-mail pessoal nesse fluxo
Próximos passos da reunião
- Compilar mapeamento de processos e sistemas (Lauro, Fabio, Bianca)
- Verificar viabilidade de e-mail corporativo nomeado para gerentes/supervisoras
- Casar agenda de migração das lojas Bel Salvador com atualização de funções no RM
Folha da Bel roda no Domínio, operado pela Silveira Contabilidade — já em migração para o RM, rodando em paralelo este mês, com prazo máximo de dois meses para conclusão.
Ploxi cobre VT/VA/VR/combustível para lojas Bel, com nota por CNPJ por loja — modelo exige aditivo contratual a cada abertura, inviável para o ritmo de ~3 lojas/mês. Decisão em aberto: migrar 100% para o Alelo (já usado no Mundo) ou renegociar o contrato com a Ploxi.
Retaguarda do RM: 12 licenças simultâneas para uma equipe de Gente e Gestão de tamanho impreciso ao vivo — faixa entre 16 (estritamente na folha) e ~20 (contando acessos ao RM), com ~18 como estimativa mais citada — gera conflito de acesso no dia a dia. Portal do colaborador Meu RH tem limite próprio de ~120 usuários simultâneos, distinto das licenças de retaguarda — risco de dimensionamento à medida que a rede de lojas expande.
Não há sistema para controle de fardamento/uniforme nem de EPI — gaps hoje sem nenhuma solução, tanto no lado Bel quanto no Mundo.
Movimentações de pessoal frequentemente feitas fisicamente sem atualização de função no RM — gera problemas de acesso no RP e no PDV. Ponto crítico na migração das lojas Bel Salvador.
🔗 Cruzamento com o Blueprint
Preenche o maior gap do Blueprint até aqui: o lado Bel do pilar RH/Gente, antes registrado como "não identificado". Agora sabemos que a Bel usa o Domínio (via Silveira Contabilidade) e já está em migração real para o RM — um dos poucos processos de integração já em curso, junto com o piloto TOTVS em loja Mundo.
Fonte: Agenda - Gente e Gestão (BEL REC) — Consultoria Peers, 14/08/2026
Agenda 10 · Bel Recife + Salvador
Marketing, Mídias Sociais e CRM
CRM e contato com o cliente
- Bel: nenhuma estrutura de CRM — sem disparo, sem coleta de dado de cliente
- Site da Bel desativado há ~2 anos; iniciativa de cashback de perfume descontinuada antes de ativar
- Mundo: CRM e marketing digital ficam 100% com a equipe de digital (fora do escopo desta entrevista) — solução mencionada: Dinamiza
Mídias sociais — hoje separadas
- Bel (Salvador): Instagram em nome de terceiros; gestão por uma única pessoa (Erika)
- Mundo (Recife): Instagram + TikTok ativos; Spotify/YouTube/Pinterest existem mas inativos
- Unificação das contas aguarda o rebrand da marca (~2-3 meses) — processo será gradativo
- Decisão em formação (não formalizada): manter a conta de anúncios Meta do Mundo (não a da Bel) na unificação, pelo histórico de impulsionamento acumulado
- Agência de rebranding contratada: "Story" — processo de ~3 meses até a marca nova; troca de bandeira nas lojas será gradual depois disso
Modelo organizacional: Trade e Rádio (Bel × Mundo)
- Trade (vitrines/PDV) fica dentro do Marketing na Bel, mas é área separada, ligada ao Comercial no Mundo
- Rádio nas lojas é responsabilidade do Marketing na Bel, mas de Operações no Mundo
- Diferença relevante para desenhar a estrutura organizacional-alvo pós-fusão — hoje não há um único dono funcional para esses dois processos
Gaps operacionais adicionais
- Sem ferramenta de agendamento de mídia social para fins de semana — domingo é pico de audiência, hoje depende de postagem manual pessoal da gerente de Salvador
- SAC do Instagram fragmentado entre equipes, sem dono único; uso de IA no atendimento vem reduzindo o engajamento
Comunicação com gerentes de loja
- Bel: 100% via WhatsApp pessoal (74 gerentes/subgerentes/supervisoras), sem número corporativo — histórico se perde na troca de gerente
- Mundo: centralizada no Teams corporativo, com grupos setorizados e GLPI para chamados
- Controle de quem está em cada loja hoje é manual (planilha), não inclui subgerentes e desatualiza rápido
Próximos passos da reunião
- Compilar mapeamento de processos Bel e Mundo
- Agendar call com Tanny sobre unificação de contas de mídias sociais
Conta em nome de terceiros, não da marca diretamente. Dívida pendente com a Meta impede anúncios; sem cartão corporativo para resolver a pendência. SAC do Instagram acompanhado por equipe separada, sem integração com marketing.
Acesso às máquinas via AnyDesk para instalação/atualização. Dois perfis ativos (padrão e premium — lojas como JK Iguatemi, Barra Shopping, Morumbi). Insatisfação com playlist em algumas lojas.
Sexta-feira recente: ligação para ~5 lojas (RJ e Salvador) usando nome da gerente e do provedor de rádio, pedindo acesso remoto (AnyDesk) para "atualizar programa de música" — em horário de troca de turno (~18h40). Nenhum acesso concedido desta vez.
🔗 Cruzamento com o Blueprint
Abre uma dimensão inteiramente nova, ainda não mapeada no Blueprint: Marketing / CRM. Confirma que nenhum dos dois lados tem CRM maduro — Bel é gap total, Mundo delega a uma equipe de digital fora do escopo mapeado até aqui. O incidente de engenharia social via AnyDesk (ListenerX/Cléber) é um risco de segurança formal e concreto, com precedente real de fraude — deve entrar como risco de alta prioridade, adjacente aos gaps de MFA/SIEM já registrados nos Riscos Críticos. Novo ponto para o Blueprint: diferença de modelo organizacional Bel × Mundo em Trade (Marketing na Bel vs. Comercial no Mundo) e Rádio (Marketing na Bel vs. Operações no Mundo) — relevante para o desenho da estrutura-alvo pós-fusão.
Fonte: Agenda 20260817 - Marketing - Mídias Sociais - CRM (BEL REC e SSA) — Consultoria Peers, 17/08/2026
Agenda 11 · Bel Salvador (SSA) — legado Bel · aprofundamento CD Pirajá
Supply, Cadastros e Logística — Bel (SSA)
⚠ Achado crítico — modelo pedido↔nota diverge REC × SSA
- Vínculo entre pedido de compra e nota de entrada é 1:1 em Recife, mas N:N em Salvador — divergência de modelo de dados entre as duas operações
- Já causou atrito real na abertura da loja piloto de Lauro de Freitas — pedidos e notas não conciliam automaticamente entre os dois modelos
- Candidato a risco formal de arquitetura no pilar Cadastro & Dados Mestres do Blueprint
Cadastro e entrada de mercadoria
- Cadastro de produto feito na central, válido para todas as lojas — só ativa para venda quando a NF de entrada é lançada
- Produto novo com frequência só é identificado na chegada da mercadoria; loja envia planilha-modelo + foto para a central cadastrar
- Abastecimento interno CD→lojas tem parametrização automática (pedido gerado pelo sistema) — diferente da compra a fornecedor, que é gerada manualmente via SQL e enviada às lojas por e-mail
- Conferência cega pelo estoquista; central confronta XML (CIEG) com o arquivo de conferência
CD Pirajá — estrutura e logística
- Recebe de fornecedores e distribui para lojas na Bahia e outros estados
- Divergência interna não resolvida sobre o % de volume que passa pelo CD: Adria estima ~80%, Ivana contesta e calcula ~20% de compra centralizada via CD — marcar como "a validar", não como fato fechado
- Transportadora Trajeta (CTE emitido na coleta); rastreamento logístico inexistente em sistema — feito via WhatsApp/ligação
- A própria equipe descreve o CD como "depósito": sem endereçamento, sem corredores definidos, sem equipamentos adequados
Processos financeiros e fiscais (manuais)
- Contas a pagar lançadas manualmente no Próton (exceto NF de revenda, automática); conciliação bancária diária com dupla conferência. Correção: o Próton tem módulo próprio de contas a pagar/conciliação bancária — a gestão optou por não usá-lo (decisão de negócio, não limitação técnica)
- Comissão de vendedores: relatório do Próton repassado manualmente ao RH; "Gêutas" (incentivo de fornecedor) apuradas em planilha
- Substituição tributária (MG): notas verificadas diariamente no CIEG antes da mercadoria transitar no estado
- Avarias: distinção entre avaria/falta (gera devolução) e sobra (não gera devolução, pode virar compra adicional se o produto tiver giro) — NF de devolução só é emitida se o fornecedor autorizar; processo 100% manual em planilha, tentativa de usar o Próton para isso não funcionou
Próximos passos da reunião
- Consolidar mapeamento SSA e confrontar com o mapeamento de Recife
- Levantar percentual exato de linhas via CD Pirajá vs. direto às lojas (Adria)
- Liberar acesso ao Winthor para a equipe de SSA (Luiz / Leonardo)
Próton (automação comercial) considerado limitado — exige muito Excel e intervenção manual. CIEG importa XML de NF-e e é confrontado manualmente com a conferência cega.
Sem endereçamento, corredores ou equipamentos — mercadoria alocada conforme espaço disponível. Volume alto de avarias por transporte e validade vencida, sem solução robusta.
Aberta sob razão social MDC — opera no Winthor (Winthor), não no Próton. Equipe SSA já treinada no sistema-alvo há ~15 dias, mas ainda sem liberação de acesso (IPs a liberar) — abastecimento da loja piloto segue sendo feito pelo time de Recife nesse meio-tempo. Mix de produto diferente, cadastros incompletos, sem pedidos prévios na abertura.
🔗 Cruzamento com o Blueprint
Aprofunda a vertical Comercial/Suprimentos do lado Bel, hoje registrada de forma genérica como "Proton — pedidos/fornecedores": revela o CD Pirajá como ponto crítico de estrutura logística e a loja piloto como evidência concreta de que o cadastro de produtos e os parâmetros de abastecimento precisam ser unificados antes da escala. A divergência de política de comissão entre BEL Recife e BEL Salvador é um novo ponto a alinhar com o pilar Comercial. Reforço: a divergência de modelo pedido-nota (1:1 em Recife vs. N:N em Salvador) é o achado mais crítico desta entrevista e deve entrar como risco formal de arquitetura de dados no pilar Cadastro & Dados Mestres.
Fonte: Agenda 20260817 - Supply - Cadastros - Logística (BEL SSA) — Consultoria Peers, 17/08/2026
Agenda 12 · Bel Recife (REC) — herdado do Mundo
Financeiro, Tesouraria, Controladoria e Fiscal — Mundo (REC)
Estrutura societária
- Grupo opera com duas razões sociais: MDC e BC Piedade
- BC Piedade tem fiscal/contábil terceirizado para a Silveira Contabilidade — mesmo escritório usado pela BEL SSA
- Financeiro já parcialmente internalizado (aprovações centralizadas em Recife); plano de internalizar tudo da Silveira sem cronograma definido (expectativa até fim do ano)
- Consolidação de balanços MDC × BC Piedade feita via Excel — o Winthor nunca foi testado para isso
Fluxo de caixa e contas a pagar
- Fluxo de caixa em planilha Excel (diário/semanal/3 meses); conciliação de cartões/Pix manual — sistema "IFUS" contratado mas inoperante
- Único fluxo automático é o recebimento em dinheiro, via robô
- Contas a pagar parcialmente automatizado via CNAB Banco Itaú, com exceções manuais para títulos vendidos a empresas de factoring
- Impostos pagos via DocPay (integrado ao Santander)
⚠ Reforma tributária e aluguéis
- Produtos já cadastrados para IBS/CBS via atendimento diferenciado contratado com a TOTVS (meados de 2025) — sem apuração paralela (simulação regime atual vs. reforma)
- Split payment (2027) percebido com apreensão forte — impacto no fluxo de caixa, na política de retenção e na forma de contratação
- 100% dos contratos de locação da MDC são de imóveis de loja (todas as lojas MDC são alugadas), sem nenhuma classificação IFRS 16 hoje — gap contábil relevante frente à reforma
- Maquininhas de cartão não são objeto de contrato de aluguel na MDC (só na BC Piedade, valor não detalhado)
Próximos passos da reunião
- Validar automação de GNRE de entrada via Dotex
- Mapear dificuldades de centro de custo no Proton (BC Piedade)
- Avaliar capacidade do Winthor para consolidação contábil entre CNPJs
- Levantar classificação IFRS 16 dos contratos de aluguel
Rotina 139 (fluxo de caixa) insuficiente; rotina 124 (rateio gerencial) usada como referência. Cadastro de "coligadas e controladas" existe mas nunca foi testado para consolidação. Centro de custo não implementado — usa "tabela de projetos" como paliativo.
Pagamento de impostos e contas a pagar parcialmente automatizados; exceções manuais recorrentes (boletos com desdobramento, títulos cedidos a factoring).
GNRE de saída automatizada via Winthor na maioria dos estados; GNRE de entrada 100% manual (operador acessa portal de cada estado), cobrindo hoje São Paulo, Minas Gerais e Bahia. Dotex avaliada para automatizar a entrada (funcionalidade ainda não confirmada).
🔗 Cruzamento com o Blueprint — novo pilar Financeiro, Tesouraria & Fiscal
Abre o novo pilar Financeiro, Tesouraria & Fiscal, hoje ausente do Blueprint AS-IS (só citado genericamente na Matriz por Vertical). Achado crítico: ausência de classificação IFRS 16 para 100% dos contratos de locação de loja da MDC — relevante diante da reforma tributária e do split payment (2027).
Fonte: Agenda 20260818 — Financeiro, Tesouraria, Controladoria e Fiscal (BEL REC), 18/08/2026 + transcrição completa
Agenda 13 · Bel Salvador (SSA) — legado Bel
Financeiro, Tesouraria, Controladoria e Fiscal — Bel (SSA)
Contas a pagar e fluxo financeiro
- Notas de produto lançadas automaticamente via XML no Próton; notas de serviço/DP/guias (DARE, DAE, GNRE, FGTS, GPS) lançadas manualmente
- Fluxo: Sirlane inclui títulos → gera relatório PDF+Excel → financeiro MDC aprova → títulos incluídos no banco → comprovantes impressos e arquivados
- Conciliação bancária cruza extrato com Próton; extratos enviados à Silveira para contabilizar no Domínio
Processo fiscal via Silveira
- Recebe SPED Fiscal + EFD Contribuições exportados do Próton
- Conferência extra-sistema com ferramentas próprias Tax Sell (converte TXT→Excel) e CIEG (confronta XML com SPED), com macros/robôs de cruzamento
- Após conferência, importa para o Domínio (módulo fiscal/contábil), que contabiliza compras/vendas automaticamente — mas a contabilização das apurações fiscais (ICMS/PIS/Cofins) é manual, via memória de cálculo
- GNRE de antecipação de ICMS (MG, SC, RS) gerada por automação a partir do XML
⚠ Fechamento contábil — gargalo de prazo
- Fechamento hoje em média no dia 20 do mês seguinte (meta interna: dia 15/16)
- Causa principal: falta de integração entre Próton, Domínio e financeiro — cada etapa (fiscal → contabilidade → contas a pagar) só começa depois que a anterior termina, replicando informação manualmente
- ~55 filiais vencem ICMS até dia 10, demais entre dia 15-20
- Com sistema integrado (tipo TOTVS/SAP), fechamento poderia cair para o 3º-7º dia
Próximos passos da reunião
- Processar transcrições e mapeamento dos processos BEL SSA
- Retornar com análise de impacto da migração Próton → Winthor
Lançamento automático de notas de produto via XML; lançamento manual de notas de serviço/guias.
Importação automática gera contabilização de compras/vendas; apuração fiscal (ICMS/PIS/Cofins) manual via planilha de memória de cálculo; ajustes automatizados para o SPED via integração.
Ferramentas próprias da Silveira Contabilidade para conferência: conversão TXT→Excel (Tax Sell) e confronto XML×SPED (CIEG).
🔗 Cruzamento com o Blueprint — mesmo pilar novo Financeiro, Tesouraria & Fiscal
Achado crítico de arquitetura: o gargalo de fechamento contábil (dia 20) é causado pela ausência de integração sistêmica entre Próton, Domínio e financeiro — item central para o desenho do sistema-alvo. DRE por loja "contaminado" por despesas de lojas em abertura lançadas na matriz sem CNPJ ainda aberto — mesmo padrão de gap já visto no lado REC/MDC.
Fonte: Agenda 20260818 — Financeiro, Tesouraria, Controladoria e Fiscal (BEL SSA), 18/08/2026
Agenda 14 · Bel Recife (REC) — encerramento da 1ª rodada de mapeamento
FP&A — Bel (REC)
Apuração do realizado
- Trabalho de FP&A inteiramente em Excel, sem sistema de projeção/consolidação
- Fonte de dados: balancetes da Silveira (Bel) e da contabilidade da Mundo, em dois formatos (consolidado por empresa e comparativo de movimento por loja)
- Júlia não depende de acesso direto ao sistema — consulta o razão contábil só pontualmente
Rateios manuais pós-balancete
- Verbas comerciais e bonificações: historicamente em 2–3 filiais, redistribuídas manualmente por faturamento
- Impostos: PIS de todas as naturezas caía numa única conta; realocação manual junto ao fiscal da Silveira, linha a linha
- Frete, marketing e despesas comerciais: rateados por faturamento — critério que a própria Júlia reconhece que pode melhorar
- Separação folha lojas × administrativa: recente na Bel; retroativo era manual
Processo orçamentário
- Orçamento 2026 foi projeção histórica + dados da fusão, sem processo estruturado
- Decisão explícita: não há necessidade imediata de sistema para projeção orçamentária — Excel é suficiente por ora
- Nice-to-have futuro (Lauro/Pablo): orçamento no sistema por centro de custo/conta contábil — prioridade hoje é o transacional bem feito
Próximos passos da reunião
- Consolidar material das entrevistas e avançar para as próximas etapas do mapeamento (Lauro, Fabio)
- Realizar as duas entrevistas restantes da primeira rodada
- Acompanhar o desenvolvimento da melhoria de rateio entre CNPJs junto à Totvs
Ferramenta central de todo o trabalho de FP&A — consolidação, rateios, apuração de resultado e orçamento.
Gera dados "crus" e incompletos, exigindo robôs e processamentos manuais desenvolvidos pela própria Silveira antes do fechamento — a Silveira enviou o balancete de julho só no dia 28 do mês seguinte.
Rateio por centro de custo só funciona dentro do mesmo CNPJ — não rateia entre MDC e BC Piedade. Usado também para desdobramento manual de títulos (assistência médica, VT), com perda de rastreabilidade do título original.
Estoque por loja da Bel extraído manualmente do Domínio — não integrado ao balanço, diferente da Mundo (que já abre ativo circulante por loja).
Melhoria de rateio entre CNPJs em desenvolvimento pela Totvs há mais de um ano, com prazos já ultrapassados e sem previsão concreta.
🔗 Cruzamento com o Blueprint
Aprofunda o pilar Financeiro, Tesouraria & Fiscal aberto nas Agendas 12/13: confirma a mesma limitação do Entó (sem rateio entre CNPJs) já flagrada no lado Mundo, e mostra que o gargalo de fechamento (já visto do lado Bel SSA, dia 20) também trava a análise de FP&A do lado Recife — a dor raiz não é falta de análise, é falta de previsibilidade no fechamento contábil que a alimenta.
Fonte: PMI Tecnologia: FP&A (BEL REC) — Consultoria Peers, 19/08/2026
Agenda 15 · Bel Recife + Salvador — Programa de Migração Winthor
Mapeamentos ERP Winthor — Programa de Migração
Estrutura do programa e frentes de trabalho
- Programa ainda sendo construído pela TI da Bel — sem coordenador único formalmente designado para todas as frentes (cadastros, parametrizações, treinamentos, definições comerciais/fiscais)
- Migração de dados: scripts de extração do Proton para o Winthor, validados por Bruna junto à TOTVS
- Migração de lojas: cadastro de filiais, PDV (Ambus), integrações — conduzida por Valte
- Capacitações: treinamentos de ERP e PDV feitos pelas próprias áreas de negócio, não pela TOTVS
Cadastros e parametrizações pendentes
- Fornecedor nota (fornecedor principal de cada produto, base nas últimas compras)
- Prazo de pagamento por fornecedor — campo inexistente no sistema atual
- Múltiplos de compra: não usado hoje em Bel Salvador, precisa ser ajustado e carregado
- Índice ativo por loja: lógica construída com Cristina, baseada em transferências desde 2025
- Abrangência do CD Ibirajá: decisão ainda pendente da diretoria — trava a parametrização do abastecimento
⚠ Plano de testes e cronograma de rollout
- Testes distribuídos por tópico, sem fluxo ponta a ponta desenhado (pedido → recebimento → estoque → venda → contas a receber → contabilização → balancete)
- Responsáveis de negócio ainda não descritos na planilha de testes — atividades hoje só sob responsabilidade de TI
- Meta: 75 filiais migradas até dezembro/2026 (set.: 24 · out.: 30 · nov.: 20) — cores na planilha distinguem 1ª filial de UF, filiais adicionais e lojas novas
Próximos passos da reunião
- Agendar demo do ERP/PDV em homologação, fluxo ponta a ponta — sugestão 20/08, 10h-12h (Luiz)
- Alinhar material/escopo da apresentação à diretoria, 20/08 à tarde (Lauro)
- Incluir responsáveis de negócio e linha de treinamentos na planilha de mapeamento (Luiz)
- Definir com a diretoria o prazo da decisão sobre a abrangência do CD Ibirajá
Já em uso na loja piloto da Bahia. Recebe os dados extraídos do Proton via scripts validados com a TOTVS.
Já integrado ao Winthor em ambiente de homologação, com venda realizada com sucesso nos testes.
Valida scripts de extração e participa de workshops (não de treinamentos operacionais). Agosto: 56h alocadas; setembro: ~60h previstas.
Mesmo fornecedor desenvolveu a rotina customizada de comissão (linguagem Proced) e sustenta outras integrações da Bel — sem autonomia interna para essa customização.
🔗 Cruzamento com o Blueprint
Detalha pela primeira vez o programa de migração decidido desde o Kickoff (Agenda 01: Winthor como stack-alvo). A meta de 75 lojas até dezembro é ambiciosa frente ao estado atual — sem cronograma fechado, sem plano de testes ponta a ponta e com cadastros ainda pendentes.
Fonte: PMI Tecnonologia: Mapeamentos ERP Winthor — Consultoria Peers, 19/08/2026
Agenda 16 · Bel Recife + Salvador — demonstração do ambiente de homologação
Alinhamento e Entendimento dos Testes Realizados
Ambiente de homologação e PDVs
- Loja de teste 998 (filial YY no ERP), dois PDVs físicos em Linux, imagem padrão do Zanthus (v22) já com aplicação de PDV e periféricos
- Parametrização após subir imagem: loja, CNPJ, número do PDV e sequencial de nota fiscal
- PDVs não dependem de concentrador de loja — comunicam direto com a retaguarda
Fluxo de vendas e testes realizados
- PDV → retaguarda de loja → ERP via API, cada rotina (produto/preço/venda) com tempo de execução próprio
- Vendas NFC-e e NF-e testadas na loja 998/YY; nota de entrada importada do SEFAZ (exemplo de 2019)
- Rotinas demonstradas ao vivo: 111 (faturamento), 115 (cupons/notas), 1318/29½ (entrada), 1118 (estoque), 1103 (custos), 1207 (contas a receber)
⚠ Esgotamento de numeração e tributação de produtos novos
- Fusão levou o total de lojas a ~140-150, ultrapassando o limite numérico de 99 do campo de filial — exigiu criação de tabela "depara" (alfanumérico ↔ numérico); parte das integrações ainda em ajuste
- Produtos da bandeira Bel ainda não existentes no ERP Mundo precisam de tributação cadastrada (NCM do fornecedor + origem/procedência) — conduzido pela coordenadora tributária
Próximos passos da reunião
- Subir as gravações das últimas reuniões na plataforma (Lauro)
- Reagendar reunião sobre material para as 15h
- Continuar ajuste das integrações que ainda usam o depara de lojas (TI Bel)
- Tratar tributação dos produtos novos ainda não cadastrados no ERP Mundo (coordenadora tributária)
Linux, imagem customizada pelo Zanthus, comunica direto com a retaguarda via API — sem concentrador de loja.
Recebe as vendas do PDV e as envia ao ERP central multiempresas.
Usada para transmitir e autorizar NF-e/NFC-e nos testes — autorizações mais lentas que em produção.
Kits exibidos no Bling, mas a venda é registrada item a item no ERP — mesmo ERP/Bling já mapeado na Agenda 03 (Digital/SAC).
Tabela criada para converter o código alfanumérico do ERP (ex.: YY) para o código numérico do PDV (ex.: 998) — algumas integrações ainda em ajuste.
🔗 Cruzamento com o Blueprint
Confirma e detalha o ERP/Bling já mapeado na Agenda 03 (Digital/SAC) e adiciona um risco de arquitetura ainda não documentado: o esgotamento da numeração de filiais pela fusão, que já exige uma camada extra de tradução (depara) em parte das integrações.
Fonte: PMI Tecnologia: Alinhamento e Entendimento dos Testes Realizados — Consultoria Peers, 20/08/2026
Agenda 17 · Bel Salvador + Recife — última área do ciclo de mapeamento
Expansão, Obras e Manutenção
Cadeia de valor: expansão e abertura de lojas
- Ponta a ponta sob responsabilidade de Luciano: avaliação de ponto → viabilidade financeira → comitê → contrato/projetos/cotação → obra → recebimento/inauguração → operações → (se preciso) encerramento
- Meta de expansão: 300 a 350 lojas nos próximos anos; seleção via ranking das 20 melhores lojas por margem/venda/fluxo (BI do Luiz), depois nova régua para ~30 lojas adicionais
- Negociação de TT (Taxa de Transferência de Controle) com shoppings, vinculando abertura de novas lojas como contrapartida — multa de 8 a 20 aluguéis por contrato
⚠ Gestão de obras: dores e necessidades
- Controle financeiro em planilha: boletos consolidados de um mesmo prestador cobrindo várias obras precisam ser redistribuídos manualmente por loja
- Medição de obra não automatizada — risco de pagar sem avanço real (ex.: R$200k de uma obra de R$1M com só mobilização de equipe feita)
- Acionamento de áreas 100% informal (ligação/mensagem/e-mail conforme urgência); pendências de inauguração (prateleira, iluminação) caem no esquecimento sem sistema de rastreio
- Sem sistema formal de manutenção — Solange já usa GLPI como usuária vinda da Mundo Recife
⚠ Migração de lojas: lições de Lauro de Freitas
- 6 linhas com preço errado no PDV pós-migração (ex.: secador de R$499 vendido a R$299) — corrigido replicando preços de loja Proton próxima + ajuste manual no Winthor
- Proton (Bel) não segrega estoque avariado do disponível — risco de contaminar o novo sistema no tombamento "como está"; ERP/PDV Mundo já segrega
- Recomendação de Luciano para as próximas migrações: migrar aos domingos, com a manhã reservada para testes de preço/venda/pagamento antes da abertura ao meio-dia
Próximos passos da reunião
- Agendar follow-up com Luciano para validar plano de migração consolidado (Peers)
- Pilotar catálogo de serviços de manutenção no GLPI (Luiz Pecci)
- Organizar e documentar o mapeamento da entrevista (Peers)
Todo produto aparece como disponível para venda, mesmo o avariado — risco direto de contaminação na migração de estoque.
Diferente do Proton, já separa estoque disponível do movimentado para avaria.
Sistema de retaguarda onde o comercial corrige manualmente os preços que ficaram errados após a migração de uma loja.
Já em uso via Mundo Recife (Solange já é usuária) — cogitado como catálogo de serviços para manutenção, com requisito de histórico por ativo.
Controle financeiro de obras multimilionárias, distribuição de pagamento por loja e medição de avanço físico — tudo hoje em planilha.
🔗 Cruzamento com o Blueprint
Adiciona uma terceira falha distinta da loja piloto Lauro de Freitas — depois do EAN N:1 (Agenda 02) e do vínculo pedido↔nota 1:1 vs. N:N (Agenda 11), agora preços errados no PDV pós-migração. Reforça que a "escola" da primeira migração ainda está gerando aprendizados corretivos, não preventivos. O GLPI, já em uso pela Mundo (ver Agenda 06), volta a aparecer como ferramenta pronta para reaproveitar em vez de comprar algo novo.
Fonte: PMI Tecnologia: Expansão, Obras & Manutenção (BEL SSA + REC) — Consultoria Peers, 27/08/2026
Agenda 18 · Bel Salvador + Recife — execução da decisão de EAN N:1
Alinhamento — Múltiplos EANs
Rastreabilidade fiscal: nota fiscal, não ajuste gerencial
- Toda movimentação de migração de estoque precisa ser via nota fiscal (saída do produto antigo + entrada do novo) — ajuste gerencial perderia o histórico de entrada
- SPED fiscaliza pelo código interno, não pelo EAN — dá alguma flexibilidade operacional (confirmado por Taciane e Alyssandra)
⚠ Produto similar/principal — risco importado × nacional
- Vínculo "produto similar → produto principal" exige mesmo NCM e mesma volumetria; após migração, os similares são inativados e a entrada de nota passa a ser por EAN
- Decisão: produto principal sempre nacional (nunca importado) — produto principal importado trava nota na SEFAZ em venda interestadual por e-commerce (alíquota 4% importado vs. 12% nacional)
- Impacto estimado do risco: ~2-3% do mix — considerado pequeno e aceito para a migração
Migração em ondas e escala por fornecedor
- Fluxo: gerar Excel/TXT dos itens → Luiz importa e executa movimentação em massa (como inventário) → baixa nos similares + entrada no principal → conferir → avançar
- Ordem: Shampoo Vela (piloto, em conclusão) → linha completa Vela → L'Oréal e demais fornecedores pesados → Maquilã e Bigose (controle) → escala geral só após ~90% dos códigos resolvidos
- Volume: ~1.800 produtos vinculados só na loja 14 — inviável manualmente, exige importação em massa pela TI
Próximos passos da reunião
- Concluir migração do Shampoo Vela na loja piloto (Luiz)
- Levantar o tamanho do problema por fornecedor, mapeando casos nacional × importado
- Teste de geração de SPED/declaração fiscal na base de teste, alinhado com Taciane e Alyssandra (Luiz)
- Definir ordem de migração das lojas — Bahia, São Paulo ou matriz (CNPJ 0001) primeiro: em aberto
Onde o estoque está cadastrado e onde Luiz importa os arquivos para executar as movimentações de similar → principal em massa.
Vincula produto similar ao produto principal; após a migração, os similares são inativados e a entrada de nota passa a ser por EAN, não mais por código de fábrica.
Não fiscaliza pelo EAN — dá folga operacional para a migração. Teste de geração agendado para a semana da reunião.
Venda interestadual para pessoa física com produto principal importado trava por alíquota incorreta — mitigado pela regra "principal sempre nacional".
🔗 Cruzamento com o Blueprint — fecha o ciclo aberto na Agenda 02
Esta reunião é a execução direta da decisão registrada como achado crítico na Agenda 02: reverter o MDC para o modelo de EAN N:1 da Bel. O estoque "bagunçado" da loja Lauro de Freitas por recebimentos no modelo antigo é o terceiro problema distinto identificado nessa mesma loja piloto, ao lado do vínculo pedido↔nota (Agenda 11) e dos preços errados no PDV (Agenda 17) — reforça que a loja segue sendo o ponto de maior concentração de aprendizados (e riscos) da fusão.
Fonte: ENC: Alinhamento múltiplos EANs — Consultoria Peers, 31/08/2026
Agenda 19 · Bel Recife + Salvador — segunda rodada com TI Bel
Infraestrutura de Loja e PDV — Programa de Migração
Infraestrutura de loja (parque de equipamentos)
- Máquinas Bel são montadas (fornecedor CNE), diferente do Mundo, que usa equipamentos prontos de fábrica — processador mínimo Intel Core i3 2ª geração, memória 4 GB (mínimo) a 8 GB (padrão atual), 100% SSD (upgrade há ~4 anos, coincidindo com a virada para o PDV Zantos)
- Suporte de peças via CNE (Salvador); técnico próprio Bel cobre o Rio de Janeiro
- Lojas Bel operam com link único, sem redundância, por decisão de gestão anterior (custo) — PDV roda offline em caso de queda de link; loja Pituba tem no-break 3000 VA com 2 baterias estacionárias por instabilidade elétrica local
- Periféricos (impressoras, leitores, gavetas) em bom estado e compatíveis com o novo sistema — maioria das impressoras (marca 9 e Bematech) compatível com Zantos; Tanca a confirmar com Valte (volume pequeno de unidades)
- SAT (SP) e MFE (CE) descontinuados com a reforma tributária — hoje 100% NFC-e
- Inventário de máquinas desatualizado: sistema MUSE substituído pelo LogMeIn (recadastro individual em andamento); último inventário completo foi no início do ano passado, período da diligência de aquisição
- Concentrador em loja: um computador por loja faz a ponte entre PDVs e o ERP central — não há servidor dedicado em loja; data center Bel Salvador é 100% on-premise, Oracle, sem cloud atualmente
Suporte Linux e prontidão da equipe
- Equipe de TI Bel não tem experiência 100% em Linux, mas a abertura da loja de Lauro de Freitas correu sem grandes problemas — avaliação: não é impeditivo, curva de aprendizado rápida com a prática
- Imagem fechada pela Zantos facilita o suporte: problema no Linux → baixa imagem, reconfigura, pronto
- Máquinas com 4 GB de RAM rodam Linux (confirmado), mas com desempenho inferior às de 8 GB — não é impeditivo, mas é ponto de atenção
⚠ Estratégias de migração de loja
- Duas abordagens já usadas em migrações anteriores (PDV Totos → PDV Zantos): (1) loja aberta — troca PDV a PDV enquanto a loja opera; (2) migração noturna — fecha caixa, valida integração, aplica imagem após o fechamento (~22h–23h), libera só quando tudo migrado
- Terceira opção em avaliação: PDV móvel como contingência (Valte negociando com a Zantos)
- Estratégia de pulmão de máquinas: leva equipamentos já preparados (ex.: em hotel) e substitui na loja à noite, reduzindo o tempo de permanência da equipe — já usado em lojas de SP; Ennald confirma que facilita, pois a equipe foca só na troca, não na configuração in loco
- Pré-requisito crítico antes de aplicar nova imagem: garantir 100% das vendas integradas ao Proton (ERP) — após a formatação não há recuperação; validação via Redução Z impressa + Proton Monitor + Sefaz (feita pelo administrativo central)
- Migração de PDV e migração de ERP são casadas: estoque do Proton vira saldo inicial no WinThor
⚠ Pontos de atenção operacionais
- Vale-presente / cupom de troca é o maior risco pós-migração: compras feitas no PDV Proton não terão histórico no WinThor — solução em discussão: nota de devolução avulsa gerando vale-crédito, restrita a supervisores; política de troca (30/60/90 dias) precisa ser definida e oficializada antes da migração
- Identificação de cliente: Bel Salvador não tem clube de fidelidade (diferente do Mundo) — ponto a alinhar
- Cadastro TEF precisa migrar junto com o PDV; POS (maquininhas Cielo) não precisam ser trocadas (CNPJ permanece o mesmo), mas taxas por bandeira podem diferir (parametrizável no WinThor)
- Permissões de acesso vinculadas ao RM (folha de pagamento) — colaboradores da loja devem estar cadastrados com funções corretas antes da virada; a definir se Bel Salvador seguirá 100% as diretrizes de perfil do Mundo
- Processo de recebimento de mercadoria vai mudar: Bel confere produto a produto, Mundo usa SAM sem conferência individual
- Ambiente legado (Proton + satélites) deve ficar ativo até a última loja migrada — obrigação legal de manter dados de origem por no mínimo 5 anos
Próximos passos da reunião
- Compartilhar inventário de servidores e máquinas de loja, com IP e função de cada servidor (Leonardo)
- Confirmar compatibilidade das impressoras Tanca com o PDV Zantos e levantar quantas unidades existem no parque (Valte)
- Definir e oficializar política de trocas e permissões de perfil para Bel Salvador
- Construir plano de migração detalhado com checklist por loja, incluindo retaguarda, instalação de PDV, validação fiscal e contingência com PDV móvel (Ricardo)
Imagem padrão fechada pela Zantos — problema no Linux se resolve baixando e reaplicando a imagem, sem depender de expertise Linux aprofundada da equipe Bel.
Licença ativa, cobre todos os equipamentos de loja (Windows). Recadastro individual em andamento — último inventário completo foi feito no início do ano passado, na diligência de aquisição.
Funções dos colaboradores no RM definem quem abre/fecha caixa e aplica desconto — premissa é que todos estejam com cadastro e função corretos antes da virada.
Compras feitas no PDV Proton não têm histórico no WinThor. Alternativa técnica discutida: aplicação web para consultar a base do Proton e relacionar à nota de devolução no WinThor — ainda sem decisão fechada.
🔗 Cruzamento com o Blueprint
Detalha, pela primeira vez, o parque físico de equipamentos e a estratégia operacional de virada de loja — complementa o pilar "Operações de Loja" (Agenda 05, Agenda 06) e o Programa de Migração Winthor (Agenda 15, Agenda 16, Agenda 17) com o lado de infraestrutura de loja/PDV que ainda não tinha sido mapeado. O risco de vale-presente/cupom sem histórico é o achado mais crítico desta agenda — soma-se aos demais problemas já registrados na loja piloto Lauro de Freitas.
Fonte: Agenda de Trabalho Peers - Reunião TI Infraestrutura Lojas PDV — Consultoria Peers, 01/09/2026
Agenda 20 · Bel Salvador — execução técnica com TI Bel
Operação — Múltiplos EANs
Estrutura de múltiplos EANs (pai/filho)
- Modelo da Bel adotado como referência para a migração ao Mundo (Intó): um código pai, N códigos filhos
- Todo estoque é alimentado pelo código pai, independente do EAN físico recebido — "uma vez pai, sempre pai" (o vínculo não muda depois de definido)
- Regra definida pela diretoria MDC: código principal deve sempre começar com 789 (tributação nacional 4%) — exceção só quando o produto não tem nenhum outro EAN disponível; códigos começando com 800x ou 4xxx não podem ser principais
⚠ Diagnóstico: divergências entre Bel e Mundo
- Estruturas de agrupamento (árvore pai/filho) podem divergir entre Bel e Mundo — no Mundo, o critério atual é "produto mais recente vira ativo, demais ficam suspensos (similar)"; no modelo de múltiplo EAN, o pai é fixo e os novos EANs entram como filhos
- Exemplo concreto identificado por Bruna: shampoo Vela tem código principal começando com 8000 na Bel — não atende à regra do 789, exigindo correção antes da migração
- Produtos sem EAN (ampolas, pinças, lixas, palitos) não são impactados pelo processo de múltiplo EAN — seguem por código interno
Processo de migração e depara
- Passos para espelhar a Bel no Mundo: (1) identificar todos os EANs vinculados a cada produto na Bel, pai + filhos; (2) verificar quais existem no Mundo, criar os que faltam; (3) validar se o código pai da Bel começa com 789, corrigindo os que não atendem; (4) fazer o depara código interno Bel → código equivalente no Mundo (Intó); (5) migrar estoque via script de ajuste, sem exigir inventário físico
- Custo médio dos similares agrupados: usar a média dos custos para não distorcer a margem
- Após a carga de múltiplos EANs, a base de similares é apagada (os dois modelos não podem coexistir) — pré-requisito: Antônio precisa ter o modelo de leitura da nova base pronto antes disso
Parâmetro de código de fábrica vs. EAN
- Decisão: substituir o uso do código de fábrica pelo EAN direto no recebimento — o EAN reflete melhor o fator de embalagem, enquanto o código de fábrica pode mudar de fator sem aviso (ex.: caixa de 6 vira caixa de 12), gerando erro de entrada
- XML de nota fiscal tem campo EAN obrigatório, mas o sistema não bloqueia emissão sem ele — ~90% dos fornecedores preenchem; exceções tratadas caso a caso
- CD próprio (coligado): transferências entre CD e loja são internas, com divergências de EAN já corrigidas na entrada do CD
Próximos passos da reunião
- Montar loja em ambiente homológico com produto de exemplo (shampoo Vela) para validação com Cris e Luiz (Bruna)
- Mapear produtos da Bel fora da regra do 789 e definir correções antes da migração
- Alinhar com Antônio o cronograma de adaptação da ferramenta de abastecimento antes de apagar a base de similares
- Solicitar a Ivana entradas e saídas por EAN dos produtos importados (Vela), para subsidiar a análise de cadastro tributário com Alessandra
Código principal sempre começa com 789 (tributação nacional 4%) — exceção só quando não há outro EAN disponível; 800x/4xxx nunca podem ser principais.
Precisa ser apagada após a carga de múltiplos EANs — dependência crítica: Antônio precisa ter o modelo de leitura da nova base pronto antes do apagamento.
Destino do script de migração de estoque por ajuste — sem exigência de inventário físico obrigatório na virada.
🔗 Cruzamento com o Blueprint — aprofunda a execução da Agenda 18
Detalha, em nível técnico, a regra de negócio e o script de migração que executam a decisão registrada como achado crítico na Agenda 02 e colocada em prática na Agenda 18. Introduz uma regra nova e formal (código principal sempre 789) e um risco de dependência ainda não coberto: a base de similares só pode ser desligada depois que a ferramenta de abastecimento (Antônio) estiver adaptada à nova base — sem isso, o tombamento de novas lojas fica bloqueado.
Fonte: Agenda de trabalho - Operação Múltiplos EANs — Consultoria Peers, 02/09/2026
Agenda 21 · Bel Salvador — Diretoria Comercial
Diretoria Comercial — Migração ERP Proton → Winthor/Zanthus (BEL SSA)
⚠ Cadastro e sortimento por loja
- Proton não tem controle de mix ativo por loja: Bel tem ~16 mil produtos cadastrados, mas cada loja opera com ~8 mil (perfis A, B, C) — Winthor/Zanthus (Mundo) também não tem essa discriminação por loja
- Risco: carregar toda a base Bel no novo ERP deixaria todos os produtos ativos em todas as lojas, levando o abastecimento automático a comprar 16 mil SKUs para todas as lojas no dia seguinte
- Solução proposta: limpeza de base por critério de movimentação — produto ativo é o que teve compra ou transferência recente; consenso: excluir produtos sem entrada e sem venda por mais de 12 meses, com inventário pós-virada para ajustar estoques residuais
- Lojas novas: sortimento já criado dentro do Winthor com base em loja espelho da mesma praça
⚠ Requisitos mínimos para abastecimento
- Histórico de vendas é pré-requisito para ligar o sistema de abastecimento (Onoz/SAM): ideal 12 meses (sazonalidade), mínimo operacional 6 meses, mínimo absoluto 120 dias
- Dado de venda não migra automaticamente para o Winthor — fica no Proton e no BI; solução: extrair dados do Proton e alimentar tabela separada no banco do Winthor, acessível via BI. Proton não pode ser desligado para abastecimento enquanto o SAM/Onoz não estiver plugado
- Relatório de histórico de vendas vira pré-requisito formal no checklist de liberação de loja — sem ele, a migração da loja é pausada
Cadastros necessários para operação
- Cadastro fiscal/tributário: UFs onde Bel tem lojas e Mundo não operava (ex.: RS, PA, MA) precisam de tributação cadastrada antes do tombamento
- Fornecedores Bel: nem todos comuns ao Mundo; faturamento mínimo, embalagem mínima e lead time não existem no Proton, serão alimentados gradualmente; forma de pagamento também não migra, comercial deve fornecer por fornecedor/praça
- Tabela de preço (custo de reposição): sem ela o Onoz não compra o produto — exceção adotada em Lauro de Freitas (usar custo da última entrada como tabela provisória) prevista também para as lojas Bel na virada
- Cadastros adicionais necessários: grupo de filial, grupo de loja, árvore mercadológica, região de preço
Precificação, promoções e processos operacionais na virada
- Estratégia definida: manter os preços vigentes do Proton na data de migração, sem reprecificação massiva — ajustes de rentabilidade graduais após a virada. Regiões de preço criadas por UF (ex.: PE com regiões A/C, SP com A/C/E)
- Promoções: Bel usa sistema externo (Casanos) para ativação no PDV, não o ERP — necessário migrar promoções ativas para o novo sistema antes da virada
- Devoluções/vale-troca: Bel não tem prazo para troca (só cupom fiscal, sem limite de dias); no período de migração a venda origem não estará vinculada automaticamente, gerando risco de crédito indevido — sugestão de liberar rotina de devolução avulsa por prazo limitado (~30 dias pós-virada)
- Comissionamento: calculado sobre venda líquida, já vinculado ao cupom/vendedor — no período de migração o link venda-devolução pode se perder, com risco de pagar comissão cheia; campanhas de comissão Bel SSA diferem do modelo Mundo, precisa comunicar a mudança às equipes
Próximos passos da reunião
- Consolidar plano geral de atividades e pré-requisitos de migração, para validação com a Bel na semana de 07/09 (Ricardo)
- Incluir relatório de histórico de vendas (12 meses) no checklist de liberação de loja
- Mapear promoções ativas no Proton por loja, para alimentar o Casanos antes da virada (Bruna)
- Definir abrangência do CD Pirajá junto à diretoria — sem isso não dá para cadastrar o CD como fornecedor no Winthor nem parametrizar o abastecimento (Soraya)
- Validar cadastro de funcionários Bel no RGM como pré-requisito de virada
Carga integral sem filtro ativaria todos os produtos em todas as lojas — abastecimento comprava 16 mil SKUs por loja no dia seguinte. Limpeza por critério de movimentação (sem entrada/venda há mais de 12 meses) definida como solução.
Mínimo absoluto de 120 dias de histórico para ligar (estoque + venda + custo + data de cadastro + última entrada); ideal 12 meses para cobrir sazonalidade. Vira pré-requisito formal de liberação de loja.
Sistema externo usado pela Bel para ativação de promoções direto no PDV — mapeamento em andamento com a equipe Proton antes da migração.
Sem a definição de negócio, não é possível desenhar o cadastro de fornecedor CD nem parametrizar o abastecimento — impacto de tributação entre CNPJs diferentes e custo logístico adicional (~15% de custo operacional + frete mínimo).
🔗 Cruzamento com o Blueprint
Aprofunda, do lado comercial/negócio, o mesmo programa de migração já mapeado tecnicamente nas Agendas 15-16 e no lado de EAN nas Agendas 18 e 20 — confirma que a base de produtos sem discriminação por loja é um risco tão crítico quanto o de EAN, e adiciona o CD Pirajá (já citado na Agenda 11) como bloqueio ainda sem dono na diretoria.
Fonte: Diretoria Comercial: Migração ERP PRÓTON → WINTHOR/ZANTHUS (BEL SSA) — Consultoria Peers, 02/09/2026
Agenda 22 · Ambiente de Homologação (MDCHML)
Ambiente Teste TI — Migração de Dados, Tributação e Cobertura de Testes
Status da migração de dados (scripts)
- Bruna conduz dois cenários em paralelo: piloto manual (lojas PDB Santos, 2 lojas, ajuste progressivo de parâmetros) e carga 100% via script (lojas integradas sem interação manual, exceto a camada PDV)
- Valte + Tércio testam tributação e operações de PDV
- Já em produção: produto, fornecedor, filial, vendedor, funcionário, cobrança
- Em homologação (construídos e validados, aguardando produção): PC filial, tributação por UF espelho, promoções (parcial)
- Pendentes: contas a pagar (em afunilamento de valores), promoções "compre e ganhe" (script em construção)
Tributação por UF espelho
- Lógica: copiar a tributação de uma UF semelhante como base (ex.: Minas Gerais → Rio de Janeiro, ~90% igual)
- Alessandra (fiscal) valida e ajusta manualmente as exceções específicas por NCM — Rio de Janeiro já validado
- Cenário de teste: entrada de XML da loja BEL no ambiente de homologação + simulação de venda
Testes realizados: entradas, vendas e devoluções
- Entradas: 5 notas da BEL Matriz e filial (J3) inseridas; estoque conferido antes/depois com diferença de R$ 1.700 no estoque financeiro, considerada aceitável (operação em horário comercial)
- Vendas: NFe e NFC-e emitidas em homologação, caixa fechado no perfil gerente de loja; contas a receber gerado corretamente por data de vencimento e taxa
- Devolução parcial: crédito gerado via voucher para o cliente
- Transferência e contas a pagar: gerados e evidenciados; baixa de caixa não executada (processo normal, não é falha)
- Validação TOTVS: todos os cenários acima homologados com consultora da TOTVS, exceto contas a pagar
Gestão de usuários e permissões de acesso
- Permissões herdadas automaticamente via função cadastrada no RM (integração DP → ambiente de homologação) — não depende de TI configurar manualmente
- Funções já existentes (ex.: gerente de loja) já têm permissões espelhadas corretamente
- Garantia necessária antes da virada: todos os colaboradores BEL devidamente cadastrados no RM
Próximos passos da reunião
- Adicionar colunas de recorrência, criticidade e dependência na planilha de migração (Bruna)
- Construir análise de cobertura por UF com loja piloto (Bruna)
- Revisar permissões das funções novas cadastradas no RM (Arthur)
- Finalizar migração de contas a pagar (Bruna)
- Definir prazo de crédito avulso para devoluções BEL pós-virada (Luiz/Valte)
28 das 38 tabelas de migração Bel → Winthor (MDC) já estão sob acompanhamento formal — 39% em Produção, 89% já validadas tanto pela consultora TOTVS quanto pela TI. Cada linha registra módulo/rotina, ordem de virada, situação, link da query/procedure e status final.
Mesma planilha, aba "Migração Lojas": 68 processos mapeados em 4 blocos — 1 · ERP (parametrização, fiscal, usuários, campanhas, vendas, compras, transferência), 2 · Integrações (Mobioh, Neomode, BI, Unous, SkyOne, Corp, iFood, Rappi, 99Food, VTEX, SAAM), 3 · Zanthus (parametrização, promoções, vendas) e 4 · Virada (carga de estoque, WTA, preço).
Soraya (diretora comercial) sugere iniciar pelas lojas de São Paulo (4-5 lojas BEL, já 30 sob bandeira Mundo). Critérios propostos: % do mix BEL já cadastrado no ambiente Mundo, % de fornecedores BEL já cadastrados no MDC, % de tributação de saída já parametrizada — considerando histórico de compras, vendas recentes e estoque (incluindo negativos). Bruna vai montar a lógica inicial com uma loja piloto e validar com as áreas de negócio.
🔗 Cruzamento com o Blueprint
Fecha o ciclo de execução do mesmo programa de migração mapeado tecnicamente nas Agendas 15-16, no lado de EAN nas Agendas 18 e 20, e do lado comercial/negócio na Agenda 21 — aqui aparece a régua concreta de execução (34% das 68 atividades de teste já realizadas) que vai orientar a ordem real de virada por UF.
Fonte: Agenda de trabalho - Ambiente Teste TI Migração — Consultoria Peers, 03/09/2026 · Planilha "Acompanhamento de Virada.xlsx"
Agenda 23 · Bel Salvador — Área Tributária
Área Tributária — Migração ERP Proton → Winthor/Zanthus (BEL SSA)
Parametrização tributária por UF (modelo espelho)
- Loja espelho consolida todo o mix de produtos das filiais da UF; novas filiais copiam a tributação dela, e ajustes pontuais na espelho replicam automaticamente para toda a UF
- Minas Gerais como espelho para Rio de Janeiro (UF mais próxima em tributação) — cópia já validada com sucesso por Alyssandra
- Bahia e Minas já parametrizadas e prontas para rollout; próximas UFs: Rio de Janeiro (em andamento) e Distrito Federal
Mix de produtos BEL × Mundo
- Produtos exclusivos da bandeira BEL Salvador já cadastrados no ERP, mas a tributação de saída pode estar incompleta
- Tributação de entrada depende do regime tributário do fornecedor (feita por recebimento de nota)
- Tributação de saída é obrigatória antes do tombamento — sem regra definida, o sistema tributa "cheio" (risco de ST antecipado incorreto)
- Necessidade de lista dos itens exclusivos BEL para preparar a tributação de saída (Alyssandra pode buscar nos e-mails da carga massiva anterior)
⚠ Plano de contas e estrutura contábil
- Dois momentos distintos: (1) tombamento do sistema — BEL permanece como BC Piedade, CNPJ separado dentro do Winthor/Zanthus; (2) incorporação das filiais BC Piedade ao corpo da MDC (CNPJ único)
- Problema atual: o plano de contas do MDC cria 3-4 contas novas por filial aberta (receita, custo, imposto a recolher/recuperar) — insustentável para o crescimento acelerado, impacta também FP&A e projeções
- Regras contábeis: cada filial nova precisa ser inserida manualmente em cada regra contábil existente
- Decisão pendente: revisar a estrutura agora (definitivo) ou replicar o modelo atual e ajustar na incorporação — Rose (Roseli) indicada para conduzir o tema
Obrigações acessórias e SPED
- Período de sistema duplo é inevitável (parte do mês no Proton, parte no Winthor/Zanthus) — a Silveira Contabilidade consolida os arquivos e transmite as obrigações nesse período
- SPEDs por tipo: ICMS gerado por filial individualmente; ECD, ECF e PIS/COFINS consolidados pela matriz
- Matriz BC Piedade precisa estar cadastrada no Winthor/Zanthus mesmo sem movimentação (estrutura obrigatória)
- Teste de junção dos arquivos SPED (Proton + Winthor/Zanthus no PVA) ainda não realizado — TOTVS já ajustou a geração; arquivo enviado ao Eduardo para validação interna antes de ir para a Silveira
Próximos passos da reunião
- Extrair parâmetros fiscais do Proton e lista de itens exclusivos BEL (Alyssandra)
- Validar o arquivo SPED internamente antes de compartilhar com a Silveira (Taciane)
- Agendar reunião de trabalho com a Silveira — mapear relatórios, ferramentas e compatibilidade com Winthor/Zanthus (Luiz Pecci)
- Inserir plano de contas no cronograma do projeto (Thales)
- Decidir o modelo de NF (1 para 1 vs. 1 para múltiplos) até 08/09 (Renê + Thales)
- Avaliar cadastrar todas as filiais BEL em produção em "modo oculto", preparando tributação/plano de contas/estoque em paralelo (Luiz Pecci)
Robô de entrada (rotina 212) e robô de saída (tributação via NCM, valida por UF e tipo de produto nacional/importado) — ainda não em produção.
IBS e CBS já contemplados na entrada e saída, mas fornecedores que não incluem IBS/CBS no XML impedem o aproveitamento de crédito.
Silveira usa Domínio, Sieg e macros/robôs para converter dados do Proton. Se for limitação do Proton, o Winthor/Zanthus pode resolver nativamente; se for fluxo padrão, as ferramentas precisam ser adaptadas. Enquanto as filiais permanecerem no CNPJ BC Piedade, a Silveira segue responsável pelas obrigações — ao virar filial MDC, a responsabilidade passa para o escritório Recife.
BEL opera com 1 NF para várias filiais; Mundo opera 1 para 1. Já causou problema real na loja Lauro de Freitas: itens de NF 1-para-múltiplos chegam como "inexistentes" no PDV Mundo.
🔗 Cruzamento com o Blueprint
Aprofunda, do lado tributário/contábil, o mesmo programa de migração mapeado tecnicamente nas Agendas 15-16 e executado na Agenda 22 — e acrescenta mais um problema real à loja piloto Lauro de Freitas (NF 1-para-múltiplos gerando itens "inexistentes" no PDV), que já acumula falhas de EAN (Agenda 02), vínculo pedido↔nota (Agenda 11) e preços/estoque (Agenda 17). O plano de contas por filial se soma ao CD Pirajá (Agenda 21) como novo risco estrutural para o ritmo de abertura de lojas.
Fonte: Área Tributária: Migração ERP PRÓTON → WINTHOR/ZANTHUS (BEL SSA) — Consultoria Peers, 04/09/2026
Agenda 24 · Síntese consolidada de todas as agendas
Consolidado — achados e pontos de atenção
O que as vinte e três agendas anteriores acrescentam ao Blueprint AS-IS do projeto, agrupado por pilar.
| Achado / Risco | Origem | Status |
|---|---|---|
| Migração de Dados & EAN | ||
| Loja piloto Lauro de Freitas concentra quatro falhas distintas de migração já identificadas: modelo EAN (N:1 × 1:N), vínculo pedido↔nota (1:1 REC × N:N SSA), preços errados no PDV pós-migração e estoque avariado não segregado no Proton — a "escola" da primeira migração segue gerando aprendizados corretivos, não preventivos. | 02, 11, 17, 18 | Risco alto |
| Reconstrução do modelo EAN×Produto do MDC — decisão tomada de reverter para o modelo N:1 da Bel, implicando reconstruir estoque, vendas, histórico e carteira de pedidos. | 02 | Risco alto |
| Execução da migração EAN N:1 já em curso, em ondas por fornecedor (Shampoo Vela → L'Oréal → demais) — ~1.800 produtos vinculados só na loja 14, exigindo importação em massa pela TI. | 18 | Em andamento |
| Regra fiscal definida para a migração: produto principal sempre nacional, nunca importado — produto principal importado trava nota na SEFAZ por alíquota (interestadual 4% importado × 12% nacional). Impacto estimado em ~2-3% do mix, aceito para seguir. | 18 | Risco alto |
| SPED fiscaliza a migração pelo código interno, não pelo EAN — dá folga operacional; teste de geração de SPED/declaração fiscal em base de teste ainda em aberto. | 18 | Confirmado |
| Sistemas & Integrações | ||
| Satélites de abastecimento e fiscal da Bel mapeados: UNOUS (sugestão de compra) e SAM (captura fiscal). | 02 | Novo sistema mapeado |
| Bling (ERP da PB) e ausência de WMS na PB — reforça o gap de WMS já apontado no comparativo de sistemas do Blueprint. | 03 | Novo sistema mapeado |
| PDV Mundo (Zanthus) não integra automaticamente com o Amplys — atrasos de 5–12 dias já geraram multa em shopping. Risco a resolver antes de escalar de 65 para 200+ lojas. | 06 | Risco alto |
| TOTVS/Winthor já roda como piloto em loja Mundo (Loja 14) — consolidação para o padrão único já começou organicamente, antes do roadmap formal. | 06 | Sinergia |
| Sistema "Amplys" citado como retaguarda legado Mundo/Recife, não documentado no Blueprint — confirmar se é módulo/apelido do Winthor ou sistema distinto. | 06 | A validar |
| Programa de migração Winthor ainda sem coordenador único formalmente designado para todas as frentes (cadastros, parametrizações, treinamentos, definições comerciais/fiscais). | 15 | Risco alto |
| Meta de 75 lojas migradas até dezembro/2026, mas ainda sem cronograma fechado nem plano de testes ponta a ponta desenhado (pedido → recebimento → estoque → venda → contas a receber → contabilização → balancete). | 15 | Risco alto |
| Dependência única do fornecedor externo Proced para a customização de comissão (linguagem Proced) e outras integrações da Bel, sem autonomia interna. | 15 | Risco alto |
| Esgotamento da numeração de filiais (limite 99) com a fusão levando o total a ~140-150 lojas — exigiu tabela "depara" alfanumérico↔numérico, com parte das integrações ainda em ajuste. | 16 | Risco alto |
| Ambiente de homologação (MDCHML) validado com sucesso: PDV Zanthus, integração ao Winthor via API e emissão fiscal NFC-e/NF-e testadas ao vivo. | 16 | Confirmado |
| Execução no ambiente de teste em 34% (23 de 68 processos mapeados) — itens pendentes concentrados em Fiscal (tributação por UF, declarações) e Abastecimento (CD Pirajá, mix ativo por filial). | 22 | Risco médio |
| Migração de dados Bel → Winthor: 28 das 38 tabelas já sob acompanhamento formal, 39% em Produção, 89% validadas por TOTVS e TI. Planilha ganhará colunas de recorrência, criticidade e dependência de definição. | 22 | Em andamento |
| Financeiro, Fiscal & Fechamento Contábil | ||
| Verba comercial não rateada proporcionalmente entre lojas — concentra-se em 2-3 filiais, distorcendo a DRE por loja e impedindo análise pós-verba. | 07 | Risco alto |
| Promoções eternas no Zanthus (validade até 2030, mais de 1 milhão de linhas) replicadas ao PDV, prejudicando o tempo de carga em todas as lojas Mundo. | 07 | Risco alto |
| FP&A da Bel Recife é 100% manual em Excel, sem sistema de projeção/consolidação — decisão explícita de manter assim por ora (Excel suficiente para o volume atual). | 14 | Risco médio |
| Entó/Winthor confirmado sem rateio de centro de custo entre CNPJs (MDC × BC Piedade) também do lado FP&A — mesma limitação já vista no financeiro central; melhoria em desenvolvimento pela TOTVS há mais de um ano, sem previsão. | 14 | Risco alto |
| Atraso da Silveira Contabilidade é causa raiz do atraso de FP&A — balancete de julho entregue só no dia 28 do mês seguinte, exigindo robôs/processamentos manuais para dados "crus" do Proton. | 14 | Risco alto |
| Fornecedores que não incluem IBS/CBS no XML impedem o aproveitamento de crédito — travar a entrada dessas notas está em avaliação, mas cria risco operacional (fornecedor precisaria reemitir a NF). | 23 | Risco alto |
| Plano de contas do MDC cria 3-4 contas novas por filial aberta — insustentável para o ritmo de crescimento acelerado; decisão pendente entre revisar a estrutura agora ou só na incorporação das filiais BC Piedade. | 23 | Risco alto |
| Modelo de nota fiscal divergente (BEL: 1 NF para múltiplas filiais · Mundo: 1 para 1) já causou itens "inexistentes" no PDV na loja piloto Lauro de Freitas — decisão de qual modelo adotar pendente até 08/09. | 23 | Risco alto |
| Jurídico, Governança & Compliance | ||
| Contratos da Bel praticamente inexistentes ou inacessíveis — sem equipe jurídica interna; contratos de serviço terão que ser formalizados do zero, imobiliários (os mais estratégicos) de difícil acesso. | 04 | Risco alto |
| LGPD/DPO incipiente na função central (Recife, herdada do Mundo) — papel formalmente atribuído, mas sem autoridade ou processo real de governança. | 04 | Governança & compliance |
| Operações de Loja & PDV | ||
| Bel SSA depende 100% da central para NF-e corporativa — loja não emite Danfe nem cadastra PJ, gerando perda de vendas para hotéis, Rede Globo e lojas de aeroporto. Candidato a quick win. | 05 | Risco médio |
| Gente e Gestão (RH) | ||
| RH da Bel identificado: usa o Domínio (via Silveira Contabilidade), já em migração real para o RM, um dos poucos processos de integração já em curso. | 09 | Gap preenchido |
| Contrato de benefícios Ploxi (Bel) inviável para expansão rápida — aditivo por CNPJ a cada abertura trava o ritmo de ~3 lojas/mês. | 09 | Risco médio |
| Perfis de acesso ERP/PDV desatualizados — movimentações de pessoal sem atualização de função no RM geram problemas de acesso, ponto crítico para a migração da Bel Salvador. | 09 | Risco alto |
| Permissões são herdadas automaticamente do RM via função do colaborador (sem trabalho manual de TI) — mas funções novas sem equivalente no MDC exigem revisão manual antes da virada, sob risco de acesso a mais ou a menos do que o necessário. | 22 | Risco médio |
| Marketing, CRM & Segurança | ||
| Marketing/CRM é gap em ambos os lados — Bel sem nenhuma estrutura de CRM, Mundo delega a equipe de digital fora do escopo mapeado. Nova dimensão para o Blueprint. | 10 | Nova dimensão mapeada |
| Engenharia social via AnyDesk mirando lojas (ListenerX/Cléber) — tentativa recente sem sucesso, mas incidente anterior já gerou fraude real e 15 dias de sistema bloqueado. Risco de segurança formal, adjacente aos gaps de MFA/SIEM. | 10 | Risco alto |
| Logística, Expansão & Obras | ||
| CD Pirajá é, na prática, um "depósito" — sem endereçamento, corredores ou equipamentos, rastreamento logístico só via WhatsApp/ligação. Ponto crítico para a Bel Salvador escalar. | 11 | Risco médio |
| Loja piloto Lauro de Freitas expõe complexidade tributária subestimada — BEL opera em 14 estados contra 4 do MDC; transferência entre razões sociais tratada como "venda" (custo+15%) é workaround, não solução. | 11 | Risco alto |
| Controle financeiro de obras multimilionárias 100% em planilha — medição de avanço físico não automatizada, com risco de pagar sem avanço real. | 17 | Risco médio |
| GLPI (já em uso via Mundo Recife) cogitado como piloto de catálogo de serviços de manutenção — ferramenta pronta para reaproveitar em vez de comprar algo novo. | 17 | Oportunidade |
| Infraestrutura de Loja & PDV | ||
| Vale-presente/cupom de troca: compras feitas no PDV Proton não terão histórico no WinThor pós-migração — maior risco identificado nesta agenda; política de troca (30/60/90 dias) ainda não definida nem oficializada. | 19 | Risco alto |
| Lojas Bel operam com link único, sem redundância (decisão de custo) — PDV roda offline em caso de queda de link; inventário de máquinas desatualizado desde a diligência de aquisição (migração MUSE → LogMeIn em andamento). | 19 | Risco médio |
| Pré-requisito crítico de migração de loja: garantir 100% das vendas integradas ao Proton antes de aplicar nova imagem no PDV — sem recuperação possível após a formatação. | 19 | Risco alto |
| PDV móvel como contingência de migração (em negociação com a Zantos) e estratégia de "pulmão de máquinas" já validada em lojas de SP — reduz o tempo de permanência da equipe em loja. | 19 | Em avaliação |
| Regra formal definida para múltiplos EANs: código principal sempre começa com 789 (tributação nacional) — exceção só sem outro EAN disponível; 800x/4xxx nunca podem ser principais. Ex.: shampoo Vela (BEL) já identificado fora da regra, precisa correção. | 20 | Regra definida |
| Base de Similares do Mundo precisa ser apagada após a carga de múltiplos EANs (os dois modelos não coexistem) — bloqueada até a ferramenta de abastecimento (Antônio) estar adaptada à nova base; risco de travar o tombamento de novas lojas. | 20 | Risco alto |
| Decisão de usar o EAN direto no recebimento em vez do código de fábrica — o código de fábrica pode mudar de fator de embalagem sem aviso, gerando erro de entrada. | 20 | Confirmado |
| Base de ~16 mil produtos do Proton não tem mix ativo por loja (cada loja opera com só ~8 mil) — carga integral sem filtro ativaria todos os SKUs em todas as lojas, distorcendo o abastecimento automático. Limpeza por movimentação (sem entrada/venda há +12 meses) definida como solução. | 21 | Risco alto |
| Histórico de vendas vira pré-requisito formal no checklist de liberação de loja (mínimo absoluto 120 dias, ideal 12 meses) — sem ele, o sistema de abastecimento (Onoz/SAM) não pode ser ligado e a migração da loja é pausada. | 21 | Risco alto |
| CD Pirajá segue sem definição de abrangência pela diretoria — bloqueia o cadastro do CD como fornecedor no Winthor e a parametrização do abastecimento; mesmo ponto já sinalizado na Agenda 11. | 21, 11 | Risco alto |
| Estratégia de precificação na virada definida: manter preços vigentes do Proton, sem reprecificação massiva — ajustes de rentabilidade graduais após o tombamento de cada loja. | 21 | Decisão tomada |
Follow-ups em aberto (agendas 01–13)
Sessão individual com Ivana (Bel Salvador) · consolidar mapeamento e retornar com perguntas ao time Digital/SAC · acompanhar retorno do fornecedor Proton (token/Store ID) · ativar módulos do Projuris e formalizar contratos da Bel · revisitar LGPD/DPO · casar migração de lojas Salvador com atualização de funções no RM · agendar call sobre unificação de contas de mídias sociais · liberar acesso ao Winthor para a equipe SSA · levantar percentual exato de linhas via CD Pirajá.
Fonte: Agendas 01–23 (03/08 a 04/09/2026) + Blueprint AS-IS PMI Bel & Mundo