Início / Agendas & Rituais de Alinhamento

Agendas de Entrevistas — Bel Cosméticos + Mundo do Cabeleireiro

03/08–04/09/2026 · Bel Recife + Salvador (BEL REC+SSA) · 24 agendas · BEL SSA = legado Bel · BEL REC = herdado do Mundo

Agenda 01 · Kickoff · Setup do Projeto — Bel Recife + Salvador + São Paulo

Kickoff / Primeira Agenda do Projeto

03 a 10/08/2026 · Reunião de setup do projeto — discute os caminhos de incorporação societária da Bel na Mundo e define a premissa estrutural que orienta todas as demais entrevistas de mapeamento.

Tani (Operações, Comercial, E-commerce, Marketing/CRM) · Flávio (Financeiro, RH, Jurídico, TI) · lideranças Bel + Mundo · equipe Peers

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
Proton (ERP Bel) On-premise · sem cloud

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).

Winthor (ERP Mundo, TOTVS) Decisão tomada: stack alvo

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 — Silveira Contabilidade / Domínio Terceirizado

Fechamento fiscal terceirizado na Silveira Contabilidade via sistema Domínio.

Níveis de migração de dados Definido

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).

⚠ Piloto em andamento: simular loja nova (CNPJ inativo) já no Winthor + PDV Mundo, com sincronismo paralelo. Reunião com a Silveira Contabilidade em 06/08 para mapear riscos fiscais da transição (mesclar declarações de 2 ERPs via PVA).

🔗 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

13/08/2026 · Primeira entrevista de mapeamento do projeto BEL + MDC — projeto de 12 semanas, 3 frentes (TI/governança, cibersegurança, sistemas/dados).

Luiz Pecci (TI Bel) · Fabio Nascimento Correia · Soraya Lustosa · Cristiane Aquino · Ivana Guerreiro (parcial, Salvador) · Cicero Silva

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)
Winthor Confirmado · núcleo ERP

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).

UNOUS ("O Novo" / "Mais Sete") Satélite de abastecimento

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".

SAM Captura fiscal

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).

Proton (Bel) Confirma achado anterior

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

13/08/2026 · Mapeamento de sistemas, processos e pontos de atenção para a fusão/migração tecnológica entre Mundo do Cabeleireiro e Bel.

Luiz Pecci (TI Bel) · Layssa Aquino · Stefany Guedes · Fabio Nascimento Correia · Bruna Letícia (TI Bel/Mundo) · Tanny Arima · Ítalo (PB)

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)
Neomode (catálogo via WhatsApp) Em testes finais

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.

⚠ Ponto de atenção: token de acesso ao iFood precisa ser renovado manualmente toda semana; bug de Store ID gerando vendas acumuladas indevidas (em correção). Risco adicional: token de cartão (cofre) precisa ser re-migrado/re-tokenizado na troca Cielo→Braspag.
55PBX Causa raiz do bloqueio Suri

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 / 99Food 100% Mundo · piloto Bel

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.

Bling (ERP) PB · não documentado antes

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).

⚠ Novo sistema para o Blueprint: "PB Cosmetics" já era conhecido como marketplace terceiro da Bel, mas o ERP Bling não estava mapeado — atualizar comparativo de sistemas. Bug conhecido: sincronização do Mercado Livre Full com o segundo depósito do Bling falha e gera estoque negativo. BI da PB (contratado da Nação Virtual) não tem contrato de sustentação/manutenção.
WMS — PB Inexistente

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

13/08/2026 · Mapear processos, sistemas e desafios para subsidiar o plano de migração das lojas Bel para o stack do Mundo. Nathalia participou remotamente, em licença maternidade.

Luiz Pecci (TI Bel) · Nathalia Coutinho (Jurídico/Compliance/Contratos, Bel) · Fabio Nascimento Correia

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
Projuris Jurídico central do grupo · Mundo

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.

⚠ Sem fluxo automatizado de aprovação: demais controles feitos por e-mail, telefone, WhatsApp e Teams — atendimento reativo ("o que pipocar primeiro na tela a gente atende").
Gesplan (Controladoria) Sem integração com o Projuris

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.

Governança contratual Gaps identificados

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.

⚠ Este gap é maior que o jurídico sozinho: a ausência de uma área de Suprimentos/Compras formal é o risco estrutural de fundo — não há controle de pedido de compra para serviços em toda a empresa.
Contratos da Bel Risco alto de migração

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.

⚠ Contratos de serviço da Bel terão que ser formalizados do zero com cada prestador — recomenda-se registrar como risco formal de alta prioridade no plano de integração.
LGPD / DPO Papel nominal, sem autoridade real

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.

⚠ Risco de governança relevante para o momento da fusão: o papel de DPO precisa ganhar autoridade e processo formal antes da integração das bases de clientes e colaboradores.

🔗 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)

14/08/2026 · Mapeamento de processos de tecnologia e operações da Bel Salvador para subsidiar o plano de migração de sistemas.

Luiz Pecci (TI) · Evili Quezia · Renata Pacheco · Carole Seixas · Simone Matos · Fabio Nascimento Correia · Tanny Arima · Angela Moura · Bianca Oliveira Dionizio · Erica Melo · Gleice Nascimento · Djna Lima

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)
Proton PDV + Proton RP Sistemas legado Bel

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.

NF-e modelo 55 (CNPJ) Dependência total da central

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).

Troca entre lojas Processo burocrático

"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)

14/08/2026 · Mapeamento de sistemas, processos manuais e dores operacionais das lojas Recife/MDC. Contexto: 65 unidades hoje, meta de escalar para 200+.

Luiz Pecci (TI) · Angela Moura · Allyson Carlos · Tamizia Azevedo · Fabio Nascimento Correia · Tanny Arima · Lojas 34 (Shopping Anália Franco), 14 (Shopping Recife), 71 (Lauro de Freitas, piloto de fusão)

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
Zanthus ↔ Amplys Não integram

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).

⚠ Carga do ERP para o PDV demora até 24h mesmo com carga forçada pelo TI.
TOTVS (piloto) Sinergia — migração já em curso

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.

Estoque e recebimento Majoritariamente manual

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)

14/08/2026 · Mapeamento de processos, sistemas e lacunas da área comercial para subsidiar o plano de migração/integração com a bandeira Mundo.

Luiz Pecci (TI) · Soraya Lustosa (Diretora) · Adalberto Lima (Coordenador) · Suan Pyrrho (Pricing) · Andreza Leão (Categoria) · Rafaela Dubeux (Trade) · Fabio Nascimento Correia

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
Winthor — rotinas 111/200/290/820 ERP principal

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).

⚠ Números de rotina divergem entre fontes: o resumo anterior cita 200/290/820, mas a transcrição bruta cita 201/296/8121 — registrar como "a validar com TI Bel", sem substituir cegamente um pelo outro.
Zanthus Não passa pelo ERP

Cadastro e execução de promoções, envio direto ao PDV. Promoções com validade até 2030 usadas como tabela de preço fixa.

⚠ Gera mais de 1 milhão de linhas replicadas ao PDV, prejudicando o tempo de carga.
Conta corrente de fornecedores 100% em Excel

Ú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)

14/08/2026 · Mapeamento de processos de compra, precificação e promoções da equipe comercial de Salvador.

Luiz Pecci (TI) · Patricio Farias · Tania Cortes · Vinicius Silva · Fabio Nascimento Correia · Soraya Lustosa · Adalberto Lima

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
Proton (via servidor, somente leitura) Sistema legado Bel

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.

Sieg Novo sistema mapeado

Portal do Sefaz usado para conferência manual de nota fiscal do fornecedor.

Pedidos e controle de compras 100% manual

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.

ℹ Esclarecimento de segurança: o "relatório SQL" eventualmente citado pelo time é apenas um relatório parametrizável do Proton — não é execução de SQL nem acesso direto à base. Registrar assim para não gerar alarme falso em avaliação de segurança.
Precificação e promoções Bloqueia desconto da gerente

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.

⚠ Margem visível no sistema é somente margem PDV (sem verba) — diferente do modelo Mundo/Recife.

🔗 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

14/08/2026 · Mapeamento de processos, sistemas e pontos de atenção para a integração das áreas de RH/DP da Bel Recife e Bel Salvador. Compara diretamente os sistemas Mundo (RM) e Bel legado (Domínio).

Luiz Pecci (TI) · Victor Guilherme (Ger. RH/DP) · Erycka Correia (Analista sênior DP) · Ana Paula Ruiz (RH/DP Rio) · Arthur Mendes (DP Recife) · Marcelo Santos (DP Salvador) · Ney (Org. Silveira) · Fabio Nascimento Correia · Bianca Oliveira Dionizio

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
RM (Mundo) × Domínio (Bel) Migração em andamento

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.

⚠ Prazo do contrato com a Silveira Contabilidade é contraditório entre as fontes (Victor cita ~16-19/jan; a própria Silveira cita "até dezembro") — registrar como pendência a confirmar, não como fato fechado.
Benefícios: Alelo (Mundo) × Ploxi (Bel) Contrato inviável para expansã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.

Licenças RM (retaguarda) × Meu RH (portal) Dois limites distintos de licença

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.

Controle de fardamento e EPI Inexistente

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.

Perfis de acesso ERP/PDV Desatualizados

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

17/08/2026 · Mapeamento de processos de marketing, mídias sociais e CRM da Bel (Salvador/Recife) e do Mundo, para construir o cenário futuro pós-integração.

Luiz Pecci (TI) · Lorena Coelho · Erika Santos · Carolina Alves · Fabio Nascimento Correia · Lauro Cesar Alves da Silva Miguel · Bianca Oliveira Dionizio · Raissa Brito e Tanny Arima (convidadas, sem fala confirmada na gravação)

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
Instagram Bel (Salvador) Sem impulsionamento

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.

Rádio nas lojas — ListenerX Terceirizada via Cléber

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.

Tentativa de golpe via AnyDesk (engenharia social) Incidente de segurança

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.

⚠ Incidente anterior foi grave e específico: o golpista obteve acesso ao cartão/máquina de pagamento (não só ao sistema), executou as próprias transações fraudulentas e cobrou resgate para devolver o acesso — sistema ficou bloqueado por ~15 dias. Nesta tentativa mais recente, o golpista se identificou com um nome próximo a "Raissa"/"Laisa" — diferente do contato real da ListenerX (Andressa) — foi esse descompasso de nome que levantou a suspeita e evitou a repetição do golpe.

🔗 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)

17/08/2026 · Aprofundamento do mapeamento de Supply/Cadastros/Logística especificamente na operação de Salvador (CD Pirajá), incluindo a primeira leitura da loja piloto de fusão.

Luiz Pecci (TI) · Ivana Guerreiro · Adria Denise (Gerente CD Pirajá) · Fabio Nascimento Correia · Lauro Cesar Alves da Silva Miguel (Tadeu Cerqueira convidado, sem fala confirmada na gravação)

⚠ 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 + CIEG Confirma achado anterior

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.

CD Pirajá "Depósito", não CD estruturado

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.

Loja piloto Lauro de Freitas (razão social MDC) Riscos de integração

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.

⚠ Transferência entre razões sociais é impossível no sistema — tratada como "venda" a custo + 15%. BEL opera em 14 estados; correção: MDC operava em 4 estados (PE, SP, PB, MG), não 2 — complexidade tributária da fusão maior do que a base MDC sozinha sugeria. Gap de comunicação: a loja já estava vendendo (R$ 54 mil no mês) antes da data de inauguração oficialmente comunicada pelo marketing.

🔗 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)

18/08/2026 · Primeira entrevista de mapeamento da área financeira/fiscal do grupo — cobre estrutura societária, fluxo de caixa, contas a pagar e o impacto da reforma tributária. Flávio Borges convidado, presença não confirmada na gravação.

Luiz Pecci (TI-BEL) · Taciane Franca (coordenação geral) · Fernanda Carolina (financeiro/tesouraria) · Alyssandra Carvalho (fiscal/tributário) · Rosely Souza (controladoria) · Fabio Nascimento Correia · Lauro Cesar Alves da Silva Miguel

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
Winthor Limitações de consolidação

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.

⚠ Limitação: rateio de despesas só funciona dentro do mesmo CNPJ, não entre razões sociais distintas (MDC × BC Piedade).
DocPay + CNAB Itaú Parcialmente automatizado

Pagamento de impostos e contas a pagar parcialmente automatizados; exceções manuais recorrentes (boletos com desdobramento, títulos cedidos a factoring).

GNRE / Dotex A validar

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).

ℹ Uma segunda plataforma concorrente foi avaliada e descartada — nome não confirmado com certeza na gravação, registrar como "a validar".

🔗 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)

18/08/2026 · Mapeamento do fluxo financeiro, fiscal e contábil da Bel Salvador — inclui o processo via escritório terceirizado Silveira Contabilidade e o gargalo de fechamento mensal.

Luiz Pecci (TI-BEL) · Ivana Guerreiro · Sirlane (gerente financeiro/contas a pagar) · Camila (conciliação) · Silvia (contabilidade) · Carlos e Renata (fiscal) · Fabio Nascimento Correia · Escritório contábil externo: Silveira Contabilidade

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
Próton (ERP Bel SSA) Sistema legado Bel

Lançamento automático de notas de produto via XML; lançamento manual de notas de serviço/guias.

⚠ Rateio por filial manual: RH envia planilha → Sirlane lança filial a filial (77 lojas) — desdobramento de título multiplica títulos e complica o borderô financeiro.
Domínio (via Silveira) Apuração fiscal manual

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.

Tax Sell + CIEG Conferência extra-sistema

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)

19/08/2026 · Penúltima das ~15 entrevistas de mapeamento de processos por área de negócio — cobre apuração do realizado e processo orçamentário do FP&A da Bel Recife.

Lauro Cesar Alves da Silva Miguel · Fabio Nascimento Correia (Peers) · Júlia Pissinin · Pablo Melo · Flávio Borges · Taciane Franca · Luiz Pecci (TI) (Bel Cosméticos)

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
Excel 100% manual

Ferramenta central de todo o trabalho de FP&A — consolidação, rateios, apuração de resultado e orçamento.

Próton (via Silveira) Causa raiz do atraso

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.

Entó (Winthor/Totvs) Sem rateio entre CNPJs

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.

Domínio Estoque fora do balanço

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).

Totvs — melhoria de rateio Em desenvolvimento, atrasada

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

19/08/2026 · Primeira visão estruturada do programa de migração da Bel para o Winthor: frentes de trabalho, cadastros pendentes, plano de testes e cronograma de rollout.

Lauro Cesar Alves da Silva Miguel · Fabio Nascimento Correia · Bianca Oliveira Dionizio (Peers) · Luiz Pecci (TI) · Bruna Letícia · Valte Lima · Tercio Pereira · Maria Luiza Leão (Bel Cosméticos)

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á
Winthor / Intório ERP de destino

Já em uso na loja piloto da Bahia. Recebe os dados extraídos do Proton via scripts validados com a TOTVS.

Ambus (PDV) Integrado em homologação

Já integrado ao Winthor em ambiente de homologação, com venda realizada com sucesso nos testes.

TOTVS (fornecedora) ~300h implantação + 32h/mês ACC

Valida scripts de extração e participa de workshops (não de treinamentos operacionais). Agosto: 56h alocadas; setembro: ~60h previstas.

Fornecedor externo (Proced) Dependência única

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

20/08/2026 · Demonstração ao vivo do ambiente de homologação (MDCHML) pela TI da Bel — fluxo completo de venda no PDV, integração com o ERP e emissão fiscal.

Lauro Cesar Alves da Silva Miguel · Fabio Nascimento Correia · Bianca Oliveira Dionizio (Peers) · Luiz Pecci (TI) · Bruna Letícia · Valte Lima · Maria Luiza Leão (Bel Cosméticos)

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)
PDV Zanthus Testado com sucesso

Linux, imagem customizada pelo Zanthus, comunica direto com a retaguarda via API — sem concentrador de loja.

Retaguarda de loja (MDCHML) Intermediário PDV → ERP

Recebe as vendas do PDV e as envia ao ERP central multiempresas.

SEFAZ (homologação) Autorizações mais lentas

Usada para transmitir e autorizar NF-e/NFC-e nos testes — autorizações mais lentas que em produção.

Bling Marketplace — kit só exibição

Kits exibidos no Bling, mas a venda é registrada item a item no ERP — mesmo ERP/Bling já mapeado na Agenda 03 (Digital/SAC).

Depara de filiais Necessário pelo esgotamento numérico

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

27/08/2026 · Última área ouvida no ciclo de mapeamento — cadeia de valor de abertura de lojas, gestão de obras e manutenção, e lições da primeira migração (Lauro de Freitas).

Lauro Cesar Alves da Silva Miguel · Fabio Nascimento Correia · Bianca Oliveira Dionizio (Peers) · Luciano Rodrigues · Luiz Pecci (TI) · Luisa Coutinho · Vanessa Rosa · Lorena Coelho · Cristiane Cesar · Solange Cirqueira · Maria Luiza Leão (Bel Cosméticos)

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)
Proton (Bel) Não segrega estoque avariado

Todo produto aparece como disponível para venda, mesmo o avariado — risco direto de contaminação na migração de estoque.

ERP/PDV Mundo Segrega disponível × avariado

Diferente do Proton, já separa estoque disponível do movimentado para avaria.

Winthor Ajuste de preços pós-migração

Sistema de retaguarda onde o comercial corrige manualmente os preços que ficaram errados após a migração de uma loja.

GLPI Candidato a piloto de manutenção

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.

Planilhas (financeiro de obras) Único mecanismo de controle

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

31/08/2026 · Reunião de execução da decisão tomada na Agenda 02 de reverter o MDC para o modelo de EAN da Bel — regras de migração, riscos fiscais e plano em ondas por fornecedor.

Lauro Cesar Alves da Silva Miguel · Bianca Oliveira Dionizio · Ricardo Caravieri Vicente Junior (Peers) · Soraya Lustosa · Celso Moraes · Cristiane Aquino · Luiz Pecci (TI) · Cicero Silva · Taciane Franca · Alyssandra Carvalho (Bel Cosméticos)

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
Mundo (sistema de gestão) Recebe os TXT de migração

Onde o estoque está cadastrado e onde Luiz importa os arquivos para executar as movimentações de similar → principal em massa.

Cadastro de Similares Mecanismo central da migração

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.

SPED Fiscaliza por código interno

Não fiscaliza pelo EAN — dá folga operacional para a migração. Teste de geração agendado para a semana da reunião.

SEFAZ Trava nota se principal for importado

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

01/09/2026 · Segunda rodada com a equipe de TI da Bel, agora focada em mapear infraestrutura de loja e estratégias de migração — migração dupla em curso (ERP Proton → WinThor e PDV Proton → PDV Zantos/Exaltos), com frentes em paralelo de arquitetura, sinergia de times e integração de loja.

Lauro Cesar Alves da Silva Miguel · Bianca Oliveira Dionizio · Ricardo Caravieri Vicente Junior (Peers) · Luiz Pecci · Valte Lima · Ennald Silva · Leonardo Pinto · Andrey Ferreira (TI Bel)

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)
PDV Zantos (imagem fechada) Suporte simplificado

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.

LogMeIn Substitui o MUSE

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.

RM (folha de pagamento) Trava permissões de PDV

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.

Vale-presente / cupom de troca Maior risco pós-migração

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

02/09/2026 · Reunião de execução técnica da migração para o modelo de múltiplos EANs (pai/filho) — regras de agrupamento, correção de exceções e processo de depara BEL → Mundo, aprofundando a decisão e o piloto já em curso desde as Agendas 02 e 18.

Lauro Cesar Alves da Silva Miguel · Thales Macedo Miguel · Fabio Hayashi da Cruz Correa · Arthur Yudi Cardoso · Ricardo Caravieri Vicente Junior · Bianca Oliveira Dionizio (Peers) · Luiz Pecci · Bruna Letícia · Valte Lima (TI Bel) · Cristiane Aquino (Bel Cosméticos)

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
Regra "789" Definida pela diretoria MDC

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.

Base de Similares Não coexiste com múltiplo EAN

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.

Mundo (Intó) Recebe o depara BEL → Mundo

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)

02/09/2026 · Segunda rodada com a Diretoria Comercial da Bel Salvador — mapeamento de atividades macro por área e definição de pontos focais (usuários-chave) para a migração Proton → Winthor/Zanthus.

Lauro Cesar Alves da Silva Miguel · Ricardo Caravieri Vicente Junior (Peers) · Luiz Pecci · Bruna Letícia · Valte Lima (TI Bel) · Soraya Lustosa · Cristiane Aquino · Adalberto Lima · Ivana Guerreiro (Bel Cosméticos)

⚠ 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
Base de produtos Proton (~16 mil SKUs) Sem mix ativo por loja

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.

Onoz / SAM (abastecimento) Exige histórico de vendas

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.

Casanos Promoções fora do ERP

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.

CD Pirajá Sem definição de abrangência

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

03/09/2026 · Revisão do progresso dos testes no ambiente de homologação antes da virada de lojas BEL — dois focos: cobertura de testes unitários e cenários ponta a ponta integrados. Preocupação central levantada na reunião: validação formal pelos times de negócio, para resguardar o time de TI caso algo falhe depois da virada.

Luiz Pecci · Valte Lima · Bruna Letícia (TI Bel) · Ricardo Caravieri Vicente Junior · Thales Macedo Miguel · Fabio Hayashi da Cruz Correa · Arthur Yudi Cardoso · Bianca Oliveira Dionizio (Peers)

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
⚠ BEL não tem processo de crédito vigente — prazo de troca é D+0. Créditos avulsos gerados na migração serão tratados pontualmente até se definir um prazo formal.

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
⚠ Funções novas que o MDC não tinha precisam de revisão manual (Arthur) — risco de conceder acesso a mais ou a menos do que o necessário.

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)
Planilha "Acompanhamento de Virada" — Migração de Dados 28 tabelas rastreadas

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.

⚠ Melhorias propostas para a planilha: coluna de recorrência (roda uma vez, global, vs. roda a cada loja tombada), criticidade (imperativo vs. desejável vs. não impeditivo) e dependência de definição (ex.: região de preço depende do comercial, comissionamento depende de regra ainda não definida). Também em avaliação: pré-cadastrar todas as filiais como inativas e ativar conforme a virada, permitindo o comercial validar mix e parâmetros antes da loja tombar.
Execução no ambiente de teste — 68 atividades mapeadas 34% concluído (23/68)

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).

⚠ Os itens pendentes concentram-se em Fiscal (revisão de tributação por UF, geração/validação das declarações fiscais) e Abastecimento (definição de abrangência do CD Pirajá, mix ativo por filial, parâmetros de fornecedor) — os mesmos dois gaps já sinalizados nas Agenda 21 e Agenda 11.
Análise de cobertura por UF (priorização de virada) Em construçã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)

04/09/2026 · Terceira rodada de migração com a área tributária da Bel Salvador — parametrização fiscal por UF espelho, tratamento de IBS/CBS, plano de contas e obrigações acessórias durante o período de sistema duplo.

Renê Calisto · Alyssandra Carvalho · Taciane Franca (Fiscal Bel) · Valte Lima · Bruna Letícia · Tércio Pereira · Luiz Pecci (TI Bel) · Flávio Borges (Bel Cosméticos) · Thales Macedo Miguel · Ricardo Caravieri Vicente Junior · Fabio Hayashi da Cruz Correa · Arthur Yudi Cardoso · Bianca Oliveira Dionizio (Peers)

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
⚠ Declarações anuais (ECD, ECF) ficam em risco se a migração não estiver 100% concluída até o final do ano.

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ôs de automação tributária Em construção · base de teste

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/CBS e fornecedores Risco de bloqueio de crédito

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.

⚠ Travar a entrada de notas sem IBS/CBS está em avaliação — reduz o risco fiscal, mas cria risco operacional (fornecedor precisaria reemitir a NF).
Ferramentas da Silveira (Domínio, Sieg, robôs) Limitação do Próton ou fluxo padrão?

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.

Modelo de NF: 1 para 1 × 1 para múltiplos Decisão pendente até 08/09

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