Trip Schedules

Uma TripSchedule é um template recorrente que materializa viagens (Trip) futuras vendáveis. Ela combina cooperativa, permissionário, rota, veículo, motorista, frequência e paradas-template, e o sistema gera as ocorrências em um horizonte móvel de 90 dias.

​

Campos

​

Templates de parada e itinerário

As paradas-template vivem em TripScheduleStop, e os itinerários-template vivem em TripScheduleItinerary. Na materialização, esses templates produzem os TripStop e TripItinerary de cada viagem gerada.

​

Ciclo de vida

A atualização altera apenas o name. Pausar, retomar e arquivar são operações dedicadas.

​

Materialização

​

Horizonte e ocorrências

As ocorrências são calculadas a partir do momento atual até 90 dias à frente. Se endAt for anterior ao fim do horizonte, ele é o limite. Apenas ocorrências futuras dentro do limite entram. Há um teto de segurança de 10.000 iterações. A partir de departureAt, cada ocorrência index avança por frequência: Para cada ocorrência, estimatedArrivalAt = departureAt + max(route.estimatedDuration, maiorOffsetDeParada), e os horários das paradas são derivados dos offsets do template.

​

Preview e criação

• Preview calcula todo o horizonte de 90 dias e devolve, por ocorrência, departureAt, estimatedArrivalAt, status e uma descrição.
• Criação materializa somente as occurrences escolhidas pelo cliente e salva a programação. Candidatas conflitantes/duplicadas são ignoradas.

​

Avaliação das candidatas

Cada viagem candidata recebe um status antes de ser criada: A chave de agendamento é cooperativeId | transportOperatorId | departureAt | routeId | vehicleId | driverId. Conflitos são detectados contra viagens SCHEDULED/IN_PROGRESS cujo intervalo [departureAt, estimatedArrivalAt) se sobrepõe.

​

Guard operacional na materialização

A materialização é o primeiro checkpoint pesado de validação operacional. Cada candidata deve validar rota ativa, permissionário regular, autorização do permissionário na rota, veículo autorizado, motorista vinculado e cota disponível. Quando uma candidata fica BLOCKED por incoerência operacional, o sistema deve:

• não criar a Trip;
• registrar o motivo de bloqueio de forma auditável;
• criar uma Notification com audience = BKO, type = OPERATIONAL_GUARD_ALERT e priority = URGENT;
• entregar a notificação aos usuários internos administradores da MOB/BKO.

Boarding não deve repetir essa validação estrutural completa. O segundo checkpoint pesado acontece no start da Trip, documentado em Trips.

​

Idempotência

A idempotência é baseada na chave cooperativeId | transportOperatorId | departureAt | routeId | vehicleId | driverId. Uma mesma viagem não é materializada duas vezes.

​

Criação das viagens

As viagens MATERIALIZABLE são criadas junto com suas paradas e itinerários.

​

Rotina diária de materialização

Uma rotina diária percorre as programações ACTIVE e rematerializa cada uma sobre o horizonte móvel de 90 dias, estendendo a cobertura conforme o tempo avança. Programações PAUSED/ARCHIVED são ignoradas. Falhas em uma programação não abortam as demais, e a idempotência impede a recriação de viagens já existentes.

​

Capacidades OPS