Funil do CRM imobiliário por pipeline

No Bitrix, stage_semantic_id do negócio diz P (em andamento), S (ganho) ou F (perdido). Para leads, use semantics da status_list (S ganho, F perdido, vazio em andamento). O nome da etapa muda por pipeline e serve só para o detalhe.

category_id (Bitrix) ou o grupo de pipeline (Imobzi) separa comprador, captação de proprietário, lançamentos, locação e o pipeline administrativo de fechamento. Os ids são números que mudam por empresa: mantenha uma tabela de-para pipeline para tipo e conte cada tipo separado.

Campos UF_CRM_* do tipo enumeration guardam o id da opção. O texto vem de items em bitrix_deal_fields, que a Nekt grava como array<struct<ID, VALUE>> com chaves em maiúsculas. A fonte do negócio sai de source_id cruzado com status_list onde entity_id = 'SOURCE'. Monte um dicionário único com o rótulo em português de cada campo e use em todas as tabelas.

Campo com ismultiple = true chega como array mesmo quando o time preenche um valor só. Use o primeiro elemento como valor principal e registre a cobertura: num caso real, um campo obrigatório ainda veio vazio em cerca de 20% dos negócios.

Campos com rótulo quase igual convivem ('Tipo do Imóvel' obrigatório e 'Tipo de imóvel' legado quase vazio). Use o obrigatório. Quando a regra mudou de campo, como motivo de perda, consolide com o campo novo na frente e o legado como reserva, e uma categoria que cubra as duas taxonomias.

O empreendimento do negócio vem do campo customizado definido para isso (por exemplo, produto de origem ou lista de empreendimentos). Tag, etiqueta e nome do negócio subcontam muito: num caso real, tag e nome acharam pouco mais da metade dos negócios que o campo canônico achou.

Explode a venda por corretor: uma linha quando solo, duas quando parceria, cada uma com a participação. Ranking e comissão usam o VGV atribuído. Quantidade de vendas é sempre a contagem distinta do negócio.

A equipe pode vir do responsável pela venda, do agenciador ou do departamento do usuário. Defina a equipe contabilizada por uma regra fixa de prioridade. O departamento vem de bitrix_users.uf_department (array) cruzado com bitrix_departments, com o nome da equipe antes do ' - '. Corretor que cai em duas equipes distintas vai para um grupo de múltiplas equipes, não para as duas.

Lançamentos costumam contar pela assinatura do contrato (CCV) e terceiros pela criação quando não há CCV. Se a regra mudou no tempo, guarde as duas: até um ano, a primeira entrada em ganho depois de uma etapa não ganha; depois, o campo de data criado para isso. Converta os horários do Bitrix para America/Sao_Paulo antes de cortar o mês.

O negócio só guarda a etapa atual. Use bitrix_deal_stage_history e bitrix_lead_stage_history: cada linha é uma passagem com data. Tempo na etapa = próxima passagem menos a entrada. Etapa ainda aberta é medida até hoje, por isso a média dela cresce. Sem histórico nativo, grave snapshot diário.