Pular para o conteúdo principal

Regras de Negocio: Execucao de Servicos

Regras que governam a execucao de servicos dentro de uma Ordem de Servico (OS).


Fluxo Geral

OS criada -> Servicos adicionados com localizacao -> Funcionarios atribuidos ->
Transicoes de status -> Conclusao automatica quando todos terminam

Entidades Envolvidas

EntidadeDescricao
WorkOrderOrdem de servico principal
ServiceAssignmentServico atribuido a OS com localizacao no ativo
ServiceCatalogo de servicos (tipo, categoria, tempo estimado)
EmployeeServiceAssignmentFuncionario alocado ao servico
PartRequestSolicitacao de peca vinculada ao servico

Maquina de Status (Servico)

PENDENTE ──> EM_ANDAMENTO ──> CONCLUIDO
│ │
│ └──> PAUSADO ──> EM_ANDAMENTO

└──> CANCELADO
StatusDescricaoTerminal?
PENDENTEServico criado, aguardando inicioNao
EM_ANDAMENTOEm execucao por ao menos um funcionarioNao
PAUSADOTemporariamente parado (aguardando peca, etc.)Nao
CONCLUIDOFinalizadoSim
CANCELADOCanceladoSim

Regras de Transicao

DeParaCondicao
PENDENTEEM_ANDAMENTOAo menos 1 funcionario atribuido
PENDENTECANCELADOPode cancelar a qualquer momento
EM_ANDAMENTOPAUSADOMotivo de pausa obrigatorio
EM_ANDAMENTOCONCLUIDOTodos os funcionarios concluiram
PAUSADOEM_ANDAMENTORetomar apos resolucao
PAUSADOCANCELADOPode cancelar estando pausado

Tipos de Localizacao

Cada servico tem um ServiceLocationType que define quais campos de localizacao sao obrigatorios:

TipoCampos obrigatoriosExemplo
NONENenhumLavagem geral
ASSET_ONLYAsset (veiculo/carreta)Inspecao geral do ativo
SIDEAsset + lado (E/D)Reparo lateral
DIRECTIONALAsset + direcao (frente/traseira)Reparo frontal
AXLEAsset + eixo + ladoTroca de mola
WHEELAsset + eixo + rodaTroca de pneu
STRUCTURALAsset + posicao estruturalSolda em barrote especifico

Regra de Unicidade

Nao podem existir dois servicos com a mesma combinacao de localizacao na mesma OS. Exemplo: nao e possivel ter dois "Troca de pneu" no mesmo eixo/roda.


Atribuicao de Funcionarios

  • Um servico pode ter multiplos funcionarios atribuidos
  • Cada funcionario tem seu proprio status (independente do servico)
  • Status do funcionario: PENDENTE, EM_ANDAMENTO, CONCLUIDO, CANCELADO

Coordenacao Automatica (Regra Critica)

Quando todos os funcionarios de um servico concluem, o servico transiciona automaticamente para CONCLUIDO.

ServiceAssignment
├── Employee A: CONCLUIDO
├── Employee B: CONCLUIDO -> ServiceAssignment: CONCLUIDO (automatico)
└── Employee C: CONCLUIDO

Se um funcionario e cancelado, ele e ignorado na contagem.


Pre-condicoes para Criar Servico

  1. OS deve existir e pertencer a mesma empresa
  2. Servico do catalogo deve estar ativo
  3. Se locationType != NONE, o asset deve estar vinculado a OS
  4. Combinacao de localizacao deve ser unica na OS
  5. Se locationType == WHEEL, o eixo tambem deve ser informado

Solicitacao de Pecas (PartRequest)

  • Pecas sao vinculadas ao ServiceAssignment (nao ao servico generico)
  • A localizacao da peca e herdada do servico (SSOT)
  • Nao se duplica a localizacao na PartRequest

Status de solicitacao

StatusDescricao
PENDINGAguardando aprovacao
APPROVEDAprovada
REJECTEDRejeitada (motivo obrigatorio)
DELIVEREDPeca entregue

Servico Especial: Consumiveis

O servico "Consumiveis Diversos" e um servico de sistema que:

  • Nao pode ser deletado
  • Nao pode ser editado
  • Aceita solicitacoes de pecas sem localizacao no ativo
  • Existe por padrao em todas as empresas

Motivos de Pausa

MotivoDescricao
WAITING_PARTAguardando peca chegar
WAITING_APPROVALAguardando aprovacao do gestor
WAITING_EQUIPMENTAguardando ferramenta/equipamento
SHIFT_ENDFim do turno
LUNCH_BREAKIntervalo de almoco
PRIORITY_CHANGEServico mais urgente entrou
OTHEROutro motivo (descricao obrigatoria)

Auditoria e Rastreabilidade

Cada transicao de status registra:

  • Quem fez a transicao (userId)
  • Quando (timestamp)
  • De qual status para qual status
  • Motivo (quando aplicavel)

Metricas de Tempo

MetricaCalculo
Tempo em filamaintenanceStartTime - queueEntryTime
Tempo de manutencaomaintenanceEndTime - maintenanceStartTime
Tempo aguardando pecaspartsWaitEndTime - partsWaitStartTime
Tempo totalmaintenanceEndTime - queueEntryTime

Constraints de Integridade

  • Multi-tenant: Tudo filtrado por companyId
  • Relacoes obrigatorias: ServiceAssignment sempre vinculado a WorkOrder e Service
  • RBAC: Permissoes por role (gestor pode aprovar pecas, borracheiro pode executar servico)

Gaps Identificados (Perguntas para Produto)

  1. Deve existir limite maximo de funcionarios por servico?
  2. Servico pausado pode receber novos funcionarios?
  3. Como tratar conflito quando dois funcionarios pausam/concluem simultaneamente?
  4. Cancelar servico deve cancelar PartRequests pendentes automaticamente?
  5. Deve ser possivel reabrir um servico concluido?
  6. Servico sem funcionario pode ser iniciado?
  7. Qual o comportamento quando a OS e cancelada com servicos em andamento?
  8. PartRequest rejeitada pode ser reenviada?

Referencias