Skip to content

RNT · Rentals and contracts

A rental links a driver to a car over time, with the rates frozen on it. A pending rental is waiting for a car. Contracts hang off the rental: a new car or a renewal is a new contract, and a rate change starts a new rental. Code RNT.

These questions are open in #82. Each gets a rule with a new ID once it is answered.

  • RNT open 1 · Who reads rentals
  • RNT open 2 · Pending means paid?
  • RNT open 3 · Where a new rental's rates come from
  • RNT open 4 · Contract term

R-RNT-01 · A car has at most one live rental (booked, active or paused)

Section titled “R-RNT-01 · A car has at most one live rental (booked, active or paused)”
  • Status: planned
  • Example: given a car booked for driver A, when it is booked for driver B, then it is refused.
  • Refusal: none: unique_violation (23505), from rentals_one_live_per_vehicle.
  • Who: every writer.
  • Source: D9 (P1); the M0 acceptance checks.

R-RNT-02 · A driver has at most one live rental (pending, booked, active or paused)

Section titled “R-RNT-02 · A driver has at most one live rental (pending, booked, active or paused)”
  • Status: planned
  • Example: given driver A with a pending rental, when a second rental is created for him, then it is refused.
  • Refusal: none: unique_violation (23505), from rentals_one_live_per_driver.
  • Who: every writer.
  • Source: D9 (P1); the M0 acceptance checks.

R-RNT-03 · A rental's pool is its car's home pool at booking

Section titled “R-RNT-03 · A rental's pool is its car's home pool at booking”
  • Status: planned
  • Example: given a car whose home pool is PML, when it is booked, then the rental's pool_id is PML, whatever pool the request gave.
  • Refusal: none: the pool is set, not refused.
  • Who: every writer.
  • Source: D9 (P5); the M0 acceptance checks.

R-RNT-04 · Booking refuses a car whose home pool differs from the driver's pool

Section titled “R-RNT-04 · Booking refuses a car whose home pool differs from the driver's pool”
  • Status: planned
  • Example: given a driver at PML and a car at SBY, when the car is booked for him, then it is refused with the detail {"driver_pool_id": "…", "vehicle_pool_id": "…"}; the driver is transferred first.
  • Refusal: rental.cross_pool
  • Who: every writer.
  • Source: D9 (Q5, P5); the M0 acceptance checks.

R-RNT-05 · A pending rental with no car takes the driver's pool

Section titled “R-RNT-05 · A pending rental with no car takes the driver's pool”
  • Status: planned
  • Example: given a driver at SBY who passes his virtual check, when his pending rental is created with no car, then its pool is SBY.
  • Refusal: none.
  • Who: every writer.
  • Source: [Ref] Database rules and conventions, Bookings.

R-RNT-06 · A rental without a car can only be pending or cancelled

Section titled “R-RNT-06 · A rental without a car can only be pending or cancelled”
  • Status: planned
  • Example: given a pending rental with no car, when its status is set to booked, then it is refused.
  • Refusal: none: check_violation (23514).
  • Who: every writer.
  • Source: [Ref] Database rules and conventions, Bookings; [Ref] Data model V13: rentals.

R-RNT-07 · An ended rental has an end reason

Section titled “R-RNT-07 · An ended rental has an end reason”
  • Status: planned
  • Example: given an active rental, when it is ended with no end_reason, then it is refused; ended with contract_ended, it is accepted.
  • Refusal: none: check_violation (23514).
  • Who: every writer.
  • Source: [Ref] Database rules and conventions, Bookings; [Ref] Data model V13: rentals.

R-RNT-08 · App users can't change a rental's status directly; only database functions can

Section titled “R-RNT-08 · App users can't change a rental's status directly; only database functions can”
  • Status: planned
  • Example: given an admin_fleet, when he updates rentals.status from booked to active, then it is refused and the status stays booked.
  • Refusal: rental.status_locked
  • Who: every app user (authenticated). Database functions, jobs and the migration may.
  • Source: D9 (P9); [Ref] Database rules and conventions, Status and stage only through functions.

R-RNT-09 · A rental keeps the daily rate and daily cost it was booked at

Section titled “R-RNT-09 · A rental keeps the daily rate and daily cost it was booked at”
  • Status: planned
  • Example: given a rental booked at Rp 150.000 a day, when the pricing group's rate rises to Rp 160.000, then the rental and its rent charges stay at Rp 150.000.
  • Refusal: none.
  • Who: the booking function and the rent job.
  • Source: [Ref] Database rules and conventions, Bookings (rates are frozen on the rental).

R-RNT-10 · A daily-rate change on renewal replaces the rental with a new rental and a new contract

Section titled “R-RNT-10 · A daily-rate change on renewal replaces the rental with a new rental and a new contract”
  • Status: planned
  • Example: given a rental at Rp 150.000, when it is renewed at Rp 140.000, then the old rental ends and a new rental at Rp 140.000 starts with its own contract.
  • Refusal: none.
  • Who: the renewal function (M4).
  • Source: D9 (Q3).

R-RNT-11 · A contract keeps the admin fee, daily rate and billing frequency it was signed with

Section titled “R-RNT-11 · A contract keeps the admin fee, daily rate and billing frequency it was signed with”
  • Status: planned
  • Example: given a contract signed with an admin fee of Rp 200.000, when the pricing group's admin fee changes, then the contract still reads Rp 200.000.
  • Refusal: none.
  • Who: the booking and renewal functions.
  • Source: D9 (Q1: contracts.admin_fee stays as the signed snapshot); [Ref] Database rules and conventions, Bookings.

R-RNT-12 · A contract number is unique within the organization

Section titled “R-RNT-12 · A contract number is unique within the organization”
  • Status: planned
  • Example: given a contract numbered by TOP, when a second contract with the same number is saved in the organization, then it is refused.
  • Refusal: none: unique_violation (23505).
  • Who: every writer.
  • Source: [Ref] Data model V13: contracts.

R-RNT-13 · A contract's term is a positive number of months

Section titled “R-RNT-13 · A contract's term is a positive number of months”
  • Status: planned
  • Example: given a new contract, when term_months is saved as 0, then it is refused.
  • Refusal: none: check_violation (23514).
  • Who: every writer.
  • Source: [Ref] Data model V13: contracts.

R-RNT-14 · A rental is never deleted; it ends or is cancelled

Section titled “R-RNT-14 · A rental is never deleted; it ends or is cancelled”
  • Status: planned
  • Example: given a super_admin, when she deletes a cancelled rental, then nothing is deleted.
  • Refusal: none: no effect, as there is no delete policy.
  • Who: every app user.
  • Source: D9 (P13); [Ref] Roles, policy matrix.

R-RNT-15 · onboarding:read or booking:read at a rental's pool lets a user read the rental and its contracts

Section titled “R-RNT-15 · onboarding:read or booking:read at a rental's pool lets a user read the rental and its contracts”
  • Status: planned
  • Example: given a viewer at PML, when she reads rentals, then PML's rentals and their contracts come back.
  • Refusal: none: hidden without them.
  • Who: super_admin, admin, admin_driver, admin_fleet and viewer hold one of these.
  • Source: [Ref] Roles, policy matrix.

R-RNT-16 · Adding or changing a rental or a contract needs booking:write, onboarding:write or inspection:handover at its pool

Section titled “R-RNT-16 · Adding or changing a rental or a contract needs booking:write, onboarding:write or inspection:handover at its pool”
  • Status: planned
  • Example: given a finance user at PML, when she edits a PML contract, then nothing changes; a checker at PML, who holds inspection:handover, may.
  • Refusal: none: insufficient_privilege (42501) on insert; no effect on update.
  • Who: super_admin, admin, admin_driver, admin_fleet and checker hold one of these.
  • Source: [Ref] Roles, policy matrix.