========================================
3.1) ORÇAMENTOS
========================================

Tabela: tb_orcamentos
Status: AJUSTAR (moderado)

Objetivo

Registrar orçamentos/pedidos da empresa, concentrando produtos e serviços no mesmo documento, permitindo geração de PDF, controle de status e posterior integração com financeiro.

📌 Importante (conceito)
O orçamento é o documento central:
nele convivem peças (produtos) e serviços, exatamente como você viu no Ema.

Campos essenciais do MVP
- id_orcamento | INT, PK, AUTO_INCREMENT (hoje está id)
- id_empresa | INT, FK → tb_empresas.id_empresa (hoje está cliente)
- id_vendedor | INT, FK → tb_usuario.id_usuario (hoje está vendedor)
- data_criacao | DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
- status | INT FK → tb_status_orcamento.id_status
- valor_total | DECIMAL(10,2)
- desconto | DECIMAL(10,2) DEFAULT 0.00
- situacao | ENUM('aberto','aprovado','reprovado','cancelado','finalizado')

Campos opcionais (MVP+)
- comentarios | TEXT NULL
- motivo | VARCHAR(255) NULL (reprovação/cancelamento)
- motivo_opc | VARCHAR(255) NULL
- data_finalizacao | DATETIME NULL
- data_entrega | DATE NULL
- pdf_gerado | TINYINT(1) DEFAULT 0

Campos financeiros / condições (MVP+)
- condicao | INT FK → tb_orcamento_condicoes.id_condicao
- forma | INT FK → tb_forma_pagamento.id_forma_pagamento
- primeiro_vencimento | DATE NULL
- tipo | ENUM('orcamento','pedido')

Campos legados / a ajustar
- cliente → renomear para id_empresa
- vendedor → renomear para id_vendedor

🔑 Observação importante — PRODUTO + SERVIÇO NO MESMO ORÇAMENTO

O que você viu no Ema é exatamente o caminho certo:

✔️ Conceito correto

- Orçamento/Pedido é o pai
- Itens do orçamento são filhos
- Cada item pode ser:
-- Produto (peça) → com código fiscal (ex: NCM 8708xxxx)
-- Serviço → mão de obra, alinhamento, diagnóstico, etc.

📌 Para isso, NÃO separar orçamento de serviço.
A separação acontece no item, não no documento.

Exemplo mental:

Orçamento #123
 ├─ Produto: Pastilha de freio (NCM 8708xxxx)
 ├─ Serviço: Troca da pastilha
 ├─ Serviço: Revisão do sistema de freio


👉 Isso normalmente é resolvido em:

3.2 Itens do Orçamento (tb_orcamento_itens)

com campos como:
- tipo_item (produto | servico)
- id_item
- descricao
- quantidade
- valor_unitario
- ncm (quando produto)

Ou seja:
produto e serviço usam a mesma “tabela de itens”, não cadastros separados no orçamento.

Fluxo básico (MVP)

1. Criar orçamento
2. Inserir itens (produtos e serviços juntos)
3. Calcular total
4. Aprovar / reprovar
5. Gerar PDF

(Opcional) gerar financeiro a partir do orçamento

========================================
3.2) ITENS DO ORÇAMENTO
========================================

Tabela: tb_orcamento_itens
Status: AJUSTAR (moderado)

Objetivo

Armazenar os itens que compõem um orçamento/pedido, permitindo que produtos e serviços coexistam no mesmo documento, cada um com sua quantidade, valor e desconto.

📌 Aqui nasce o modelo que você viu no Ema
Produto e serviço são tratados como item, não como documento separado.

Campos essenciais do MVP
- id_orcamento_item | INT, PK, AUTO_INCREMENT (hoje está id)
- id_orcamento | INT, FK → tb_orcamentos.id_orcamento (hoje está duplicado como id_orcamento)
- id_item | INT (hoje está produto_id — pode ser produto ou serviço)
- tipo_item | ENUM('produto','servico')
- qtde | DECIMAL(10,2)
- valor_unitario | DECIMAL(10,2) (hoje está valor)
- desconto | DECIMAL(10,2) DEFAULT 0.00
- total | DECIMAL(10,2)
- especificacao | VARCHAR(255) NULL

Campos opcionais (MVP+)
- ordem | INT DEFAULT 0 (ordem visual no orçamento)
- criado_em | DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP

Campos legados / a ajustar
- produto_id → renomear para id_item
- valor → renomear para valor_unitario
- id → renomear para id_orcamento_item

Observações importantes (essa é a chave do modelo)
🔹 Produto e serviço usam a MESMA tabela
- A diferença está em tipo_item
- O cadastro base pode ser:
-- tb_produtos
-- tb_servicos
- O orçamento não precisa saber disso além do tipo

🔹 Fiscal entra aqui, não no orçamento

Quando (e se) o módulo fiscal existir, os campos entram aqui:
- ncm (produto)
- cfop
- cst/csosn

Sem mexer em:
- tb_orcamentos
- tb_financeiro

🔹 Total pode ser calculado ou armazenado
- Calculado: qtde * valor_unitario - desconto
- Armazenado: facilita relatório e histórico
- Sua estrutura permite os dois

Exemplo real (Raavcar / Ema-style)
Orçamento #458
────────────────────────
Produto | Pastilha Freio | Qtde: 1 | R$ 180,00
Serviço | Troca pastilha | Qtde: 1 | R$ 120,00
Serviço | Revisão freio  | Qtde: 1 | R$  80,00
────────────────────────
Total: R$ 380,00


Tudo isso é uma única tabela de itens.

========================================
3.3) CONDIÇÕES DE PAGAMENTO
========================================

Tabelas: tb_condicoes e tb_orcamento_condicoes
Status: AJUSTAR (simplificação recomendada)

Primeiro: o que isso faz (em português claro)

Essas tabelas existem para responder a pergunta:

“Como esse orçamento será pago?”

Exemplos:
- À vista
- 2x 30/60
- 3x 30/60/90

🧠 Papel de cada tabela (conceito correto)
🔹 tb_condicoes → MODELO (catálogo)

Define tipos de condição reutilizáveis.

Exemplo:
- À vista
- 2x
- 3x
- 4x

🔹 tb_orcamento_condicoes → APLICAÇÃO no orçamento

Guarda o detalhamento real daquela condição no orçamento específico:
- dias
- valores
- datas

📌 É aqui que mora o parcelamento de verdade.

Agora, no molde 👇
3.3.1) CONDIÇÕES (CATÁLOGO)

Tabela: tb_condicoes
Status: AJUSTAR (leve)

Objetivo

Definir modelos de parcelamento reutilizáveis nos orçamentos.

Campos essenciais do MVP
- id_condicao | INT, PK, AUTO_INCREMENT (hoje está id)
- condicao | VARCHAR(100) (ex: À vista, 2x, 3x sem juros)
- parcelas | INT (quantidade de parcelas)
- ativo | TINYINT(1) DEFAULT 1

Campos opcionais (MVP+)
- descricao | VARCHAR(255) NULL
- criado_em | DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP

Observações
- Essa tabela não define datas nem valores.
- Ela apenas diz “quantas parcelas existem”.

3.3.2) CONDIÇÕES DO ORÇAMENTO

Tabela: tb_orcamento_condicoes
Status: AJUSTAR (avaliar manter)

Objetivo

Registrar o parcelamento efetivo de um orçamento, com datas e valores por parcela.

Campos essenciais do MVP
- id_orcamento_condicao | INT, PK, AUTO_INCREMENT (hoje está id)
- id_orcamento | INT, FK → tb_orcamentos.id_orcamento
- dias | INT (dias após a data base)
- data_vencimento | DATE (hoje está data)
- valor | DECIMAL(10,2)
- obs | VARCHAR(255) NULL

Observações importantes (a parte “aha”)
🔴 Por que você não lembra dessa tabela?

Porque hoje ela concorre com o Financeiro.

Você já tem:
- tb_financeiro → parcelas reais
- com status, pagamento, atraso etc.

📌 Isso cria sobreposição.

✅ Decisão recomendada (importante)
Caminho moderno (recomendado)

- tb_condicoes → fica
- tb_orcamento_condicoes → pode ser:
-- ❌ removida no futuro
-- ou usada só como base para gerar o financeiro

Fluxo ideal:
1️⃣ escolhe condição no orçamento
2️⃣ sistema gera parcelas direto em tb_financeiro
3️⃣ financeiro vira a fonte da verdade

Nesse cenário:

tb_orcamento_condicoes vira opcional ou transitória.

========================================
3.4) STATUS DO ORÇAMENTO
========================================

Tabela: tb_status_orcamento
Status: AJUSTAR (leve)

Objetivo

Definir os status possíveis de um orçamento/pedido, controlando fluxo, visualização e regras de negócio.

Campos essenciais do MVP
- id_status | INT, PK, AUTO_INCREMENT (hoje está id)
- status | VARCHAR(50) (ex: Aberto, Aprovado, Reprovado)
- descricao | VARCHAR(255) NULL
- cor_hex | CHAR(7) (ex: #2ECC71)

Campos opcionais (MVP+)
- ordem | INT DEFAULT 0 (ordenação do fluxo)
- ativo | TINYINT(1) DEFAULT 1
- criado_em | DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP

Observações
- A cor (cor_hex) facilita:
-- badges
-- dashboards
-- leitura rápida do status
- Recomenda-se não apagar status, apenas inativar.
- Esse status pode:
-- controlar permissões (ex: só aprovar se estiver “Aberto”)
-- disparar ações (gerar financeiro, gerar PDF, etc.)

Status padrão sugeridos (MVP)
- Aberto
- Enviado
- Aprovado
- Reprovado
- Cancelado
- Finalizado