Vendas e contratos¶
Em produção. A venda tem uma tela só, e ela cria o contrato de verdade.
Antes existiam duas telas que não conversavam. A de fechamento não criava venda nenhuma: marcava o lead como ganho e gravava um nome de produto de uma taxonomia própria do CRM, um valor e uma string de forma de pagamento. A outra criava o contrato, mas exigia um aluno já cadastrado e não deixava tocar no que estava sendo vendido.
A regra que governa o módulo¶
O que foi vendido é dado da venda, não do catálogo
O pacote negociado é congelado em contract_items no fechamento. É dele que derivam os entregáveis do aluno e as sessões previstas. O cadastro do produto é o default da tela de venda, nunca a fonte do que o aluno recebe: alterá-lo depois não alcança venda alguma. Ver AD-017.
Corolário prático: quem pergunta "o que esta venda tem?" lê contract_items. Só cai na composição do produto para vendas anteriores ao congelamento.
O mentor vem do cadastro¶
O mentor não é uma escolha feita na venda. Ele é o tutor padrão da ocorrência e os tutores habilitados da sessão, ambos do cadastro. Ambiguidade deixa a ocorrência sem tutor e pendente de atribuição, em vez de impedir o fechamento.
A exceção é a importação, onde o especialista da planilha já atendeu e a linha é registro do que aconteceu. Ali o cadastro valida em vez de decidir, e divergência vai para o relatório. Ver AD-019.
Prazo: duas datas¶
| Campo | O que é | Quando muda |
|---|---|---|
contracts.end_date |
Prazo de referência, congelado como início mais duração | Nunca |
effective_end_date |
Prazo real | Só por prorrogação explícita, com autor e data |
O prazo não bloqueia agendamento
Decisão do cliente: o aluno pode ter dificuldade de agenda e prorrogar, e travar a agenda transformaria isso em chamado. A diferença entre as duas datas é o que torna o atraso de cronograma mensurável. Ver AD-018.
Quem pergunta "até quando esta venda vale" lê o prazo real.
Importação de venda já datada¶
Sete clientes tiveram a agenda do ano inteiro marcada à mão numa planilha, sem existir no sistema como venda. A importação resolve isso.
O fechamento normal agenda sozinho, escolhendo horários na agenda liberada do tutor. Na importação as datas já estão decididas, então o caminho registra a venda com a agenda que já existe.
A importação passa pelo mesmo serviço de fechamento e grava o mesmo contract_items, para que venda importada e venda digitada sejam o mesmo registro.
Aula em grupo vira sessões sobrepostas
O esquema não tem sessão de grupo. Uma aula para quatro alunas vira quatro sessões sobrepostas na agenda do tutor, e a checagem de conflito é dispensada por opção nomeada, testada e restrita a esse caso. A linha que se declara Individual tem veto, para que uma coincidência entre clientes não passe por aula em grupo.
Financeiro¶
Pagamentos ficam em payments, com formas de pagamento em payment_methods. O perfil Financeiro alcança o módulo inteiro; a Secretaria vê apenas as formas de pagamento, em leitura.