Employee representa o cadastro operacional de uma pessoa como funcionário de uma Company. Se o User identificado pelo email e telefone já existir, a Company cria o Employee já ativo e vinculado. Caso contrário, cria o Employee pendente e um convite; o convidado aceita o token e o sistema liga o User ao Employee.
A Company é a dona do vínculo. O funcionário pode ter um perfil de Customer separado para comprar passagens ou receber créditos, mas esse perfil não é pré-requisito para criar o Employee.
Campos
Relacionamentos
- Relaciona-se com Company por
companyId. - Relaciona-se com Organization por
organizationId. - Relaciona-se com User por
userId, quando a identidade é resolvida diretamente ou o convite é aceito. - Relaciona-se com Invite pelos convites emitidos para o cadastro.
Regras de negócio
Employeesó pode ser criado comorganizationIdpreenchido e pertencente a uma Company.- A criação exige
name, email e telefone para resolver a identidade do funcionário e, quando necessário, gerar o convite. organizationIddeve ser igual aoorganizationIdda Company informada emcompanyId.- Se email ou telefone resolverem o mesmo User existente, o Employee nasce
ACTIVE, comuserIdeactivatedAt, sem Invite. - Se não houver User existente, o Employee nasce
PENDING, semuserId, e recebe um InviteEMPLOYEE. - Se email e telefone resolverem Users diferentes, a criação deve ser rejeitada.
- O Invite
EMPLOYEEnão possuiroleIde não cria Membership. - Ao aceitar o convite, o sistema cria ou resolve o User, grava
userIde muda o Employee paraACTIVE. - O par
companyId+userIddeve ser único quando o usuário já estiver vinculado. - O vínculo pertence à Company. O mesmo usuário pode ser funcionário de múltiplas Companies, cada uma com seu próprio
Employee. Employeenão deve referenciarPassenger, porque Passenger é snapshot de uma passagem.- Elegibilidade, saldo e uso de subsídio ou crédito corporativo devem ser derivados de CreditGrant e CreditLedgerEntry, não persistidos em
Employee. - Quando o vínculo deixa de valer, o registro deve mudar para
SUSPENDEDouREVOKED; o histórico não deve ser apagado. - Créditos concedidos por regra de funcionário devem validar a mesma
companyIddoEmployeee resolver o Customer separadamente pelo User.