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.
Not yet a rule
Section titled “Not yet a rule”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.