Banco de Dados Guia de Consulta Visão Geral O Dommus é composto por múltiplos módulos, e cada módulo possui o seu próprio banco de dados. Além dos bancos individuais, existe um banco central chamado GU (General User), responsável por armazenar informações globais da plataforma, como usuários cadastrados e permissões de acesso. Estrutura dos Bancos de Dados por Módulo Cada módulo segue uma convenção de nomenclatura própria para o banco e para as tabelas. Abaixo estão os principais: Módulo Vendas  O banco de dados do módulo Vendas segue o padrão  DOMMUS_NOMEDOCLIENTE . As tabelas deste banco utilizam o prefixo  tb_ , por exemplo:  tb_equipe ,  tb_processo ,  tb_unidade . A separação entre palavras é feita sempre com underscore ( _ ), sem espaços ou pontuações especiais. Módulo CRM  O banco de dados do CRM segue o padrão  CRM_INQUILINO_00IDDOINQUILINODOCLIENTE . As tabelas deste banco  não utilizam  o prefixo  tb_ , por exemplo:  oferta_ativa . A separação entre palavras também segue o padrão underscore, sem espaços ou pontuações. Módulo Conecta  O banco de dados do Conecta segue o padrão  DOMMUS_CA_INQUILINO_00ID_INQUILINO_CLIENTE . As tabelas deste banco  utilizam  o prefixo  tb_ , por exemplo:  tb_perfil . Módulo Desk  O banco de dados do Desk segue o padrão  DESK_INQUILINO_00ID_INQUILINO_CLIENTE . As tabelas deste banco  não utilizam  o prefixo  tb_ , por exemplo:  ticket_status . Banco GU (Geral)  O banco GU é o repositório central de informações da plataforma. Nele estão armazenados todos os usuários cadastrados no Dommus, acessíveis pela tabela  dommus_homolog_gu.tb_usuario . Este banco serve de referência para validações de acesso e permissões em qualquer módulo. Regra Geral de Nomenclatura de Tabelas Independentemente do módulo, todas as tabelas seguem a seguinte convenção: a separação de palavras é sempre feita por underscore ( _ ), nunca por espaços, pontos, hífens ou qualquer outro caractere especial. Chaves Primárias e Secundárias Todos os bancos de dados da Dommus são compostos por chaves primárias e chaves secundárias (estrangeiras). Isso significa que uma tabela pode conter o ID de outra tabela como referência, permitindo filtrar registros sem precisar conhecer o ID principal da tabela. Por exemplo, na  tb_processo  existe o campo referente ao ID da unidade. Isso permite buscar todos os processos de uma unidade antes mesmo de saber o ID do processo. Exemplo de consulta: sql Copiar SELECT * FROM tb_processo WHERE unidade = 12323; Para obter o ID da unidade, é necessário consultá-la previamente na  tb_unidade , buscando pela informação desejada. Fluxo de Validação por Módulo Quando um cliente reporta um problema relacionado a um módulo específico, a validação deve ser feita no banco correspondente. O módulo reportado pelo cliente indica onde a consulta deve ser realizada. Exemplo prático — Cliente com problema de login no CRM: Validação 1 — Verificar se o cliente está habilitado para o módulo CRM. Validação 2 — Consultar a tabela  tb_cliente_modulo_usuario  no banco  dommus_homolog_gu . Validação 3 — Verificar o  perfil_usuario  diretamente no banco do CRM do cliente. Tabelas Importantes no Módulo Vendas tb_referencia_integracao  — Esta tabela é responsável por referenciar a relação entre o Dommus e uma integração externa, como um ERP Financeiro ou uma plataforma de Assinatura Digital. Quando há uma integração ativa, é nesta tabela que está registrado o vínculo entre os dois sistemas. tb_atividade_parceiro  — Esta tabela registra os retornos de erros de integrações. Quando ocorre uma falha em uma operação integrada (por exemplo, ao tentar enviar um contrato para assinatura digital), o log de erro correspondente estará registrado nesta tabela. É o primeiro lugar a ser consultado para diagnosticar problemas de integração. Se quiser, posso complementar com mais tabelas, adicionar exemplos de queries ou formatar de forma diferente para se adequar melhor ao padrão do duvidas.dommus.com.br.