(FRD)
VietGara — Multi-Tenant SaaS Platform for Auto Garage Management & Maintenance
Version 1.9 — October 12, 2026
1. Introduction
1.1. Purpose
This document specifies the detailed functional requirements of the VietGara platform, serving as the basis for the development team’s API, database, and UI design, and for the QA team’s test case design. It elaborates on the features described at a high level in the Vision & Scope Document and maps each requirement to the corresponding service in the Software Architecture Document (SAD).
1.2. Scope
This document covers all 24 functional groups of the system, from user administration to reporting and analytics, across all three access channels: the garage web console, the customer app, and the technician app. Non-functional requirements (performance, security, scalability) are not repeated here in detail — see the Non-Functional Requirements Document (NFRD), the Software Architecture Document (SAD) and ADR-001 through ADR-011.
1.3. Reference Documents
- Vision & Scope Document — VietGara, Version 1.4
- Software Architecture Document (SAD) — VietGara, Version 1.3
1.4. Document Conventions
| Notation | Meaning |
|---|
| FR ID | Format: FR-[Module Code]-[Sequence], e.g. FR-QUO-01 is functional requirement #01 in the Quote (QUO) module |
| Priority — Must have | Required for the system to operate (MoSCoW framework) |
| Priority — Should have | Important but can be deferred if a schedule trade-off is needed |
| Priority — Could have | Adds incremental value; its absence does not affect core operations |
| Phase | Phase 1 (MVP) through Phase 17, corresponding to the delivery roadmap in Section 3 of the Vision & Scope Document |
1.5. Terminology
| Term | Meaning |
|---|
| User | A person who signs in to any VietGara app: owner, staff, customer with an app, platform admin or admin staff (formerly called an “account”) |
| Owner | A user who owns garages; the subscription belongs to the owner user |
| Staff | A user’s membership of one garage, through staff groups and roles |
| Customer | A garage-owned profile of a vehicle owner. It needs no user; it can be linked to a user with the user’s consent (FR-CUS-06) |
| Supplier | A garage-owned record of a business that sells parts to the garage (FR-SUP-01). It is not a customer; a user link and portal come in Phase 17 (FR-SUP-02/03) |
| Insurer | A garage-owned record of an insurance company, in the Insurance module (FR-INS-07). It is neither a customer nor a supplier |
| Platform Admin, Admin Staff | Users holding platform permissions (FR-IAM-10) |
| Owner Web, Admin Web | The two web consoles. Owner Web (vietgara-owner-web) is for garage owners and staff; Admin Web (vietgara-admin-web) is only for platform admins and admin staff. A garage user never uses the Admin Web |
| Owner App, Admin App, Customer App, Technician App | The four mobile apps; the Owner App and Admin App are the mobile companions of the Owner Web and the Admin Web |
“Account” is used only in ordinary English phrases: My account (a user’s own settings page), bank account, Google account.
2. Users & Roles (Actors)
| Actor | Description |
|---|
| Garage Owner / Manager | The owner owns the user, its garages and the subscription, holds every permission in the garages they own and defines the roles their staff receive. A Manager is a staff member with the default Manager role (FR-IAM-03): every catalogue permission, but not the owner-only actions (garage status, staff groups) |
| Garage Accountant | Manages settlements, receivables, and e-invoicing; limited rights on system configuration |
| Technician | Receives and updates assigned repair orders; no access to financial data |
| Service Advisor | Creates quotes, greets customers, tracks repair progress |
| Inventory Staff | Manages parts stock in/out/on-hand |
| End Customer | The vehicle owner. Needs no user to be a garage’s customer; with a VietGara user (Customer App) they approve quotes, track progress, book appointments and pay |
| Platform Admin | Operates the VietGara platform with every platform permission, including viewing any garage’s data (logged); not tied to any single garage. Uses the dedicated vietgara-admin-web web app and vietgara-admin-app, not the owner web |
| Admin Staff | A user with limited platform permissions through platform staff groups and roles (FR-IAM-10); may read one garage’s data only through an approved, time-boxed, read-only support grant (FR-IAM-11) |
| Supplier | A business that sells parts to the garage. Today it is a record the garage keeps (FR-SUP-01) and the garage sends it purchase orders by print or e-mail. From Phase 17 a supplier that has a VietGara user (the supplier user) works in the Supplier Portal (FR-SUP-02/03): it sees the purchase orders addressed to it, confirms lines and attaches delivery notes. Not an End Customer and not a garage user |
| Visitor | A person who has no VietGara user and reads the public sites: a garage owner who is considering VietGara, a customer, a partner. Reads viettechno.com and vietgara-help.viettechno.com and may send a contact request (FR-WEB-02). Not an End Customer and not a garage user |
| External System | E-invoice provider, payment gateway, insurance company — a system actor communicating via API/webhook |
The staff actors above are the default roles created for every owner (FR-IAM-03). What a staff member may do is decided by the permissions of the roles assigned to their staff groups, not by the actor name, so an owner can adapt or add roles.
3. Detailed Functional Requirements
3.1. Identity & Access Management
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-IAM-01 | Garage user registration | A garage owner self-registers with e-mail, password and full name (phone optional), or signs up instantly with a Google (Gmail) user (OAuth 2.0). E-mail users start unverified: a 6-digit OTP is e-mailed, valid for 2 minutes (resend after 30 seconds, 5 attempts). Until the e-mail is verified the user may only edit its profile and verify; garage, staff and business pages are blocked. Verification creates the user’s trial subscription (FR-LIC-01) and its default roles (FR-IAM-03). Google accounts are verified on sign-up | Garage Owner | Must have | Phase 1 |
| FR-IAM-02 | Login / logout | Login with e-mail/password or Google; short-lived access token plus a rotating refresh token; logout revokes the refresh token | All | Must have | Phase 1 |
| FR-IAM-03 | Role-based access control (RBAC) | The owner defines roles (a name and a set of permissions from a fixed catalogue, e.g. customer.write, staff.write) shared by all their garages. The catalogue is grouped by module (garage, staff, customer, …), each offering a read and/or write permission (<module>.read / <module>.write); a write permission includes its module’s read permission. The owner edits a role on one page: a module × read/write checkbox grid, saved as the role’s whole permission set in one update; a default role can be reset to its default permissions. In each garage, a staff group assigns one role to its members; a staff member holds the union of their groups’ permissions in that garage. Default roles (Manager, Service Advisor, Technician, Accountant, Inventory Staff) and matching groups are generated when the owner verifies their e-mail and for every new garage. Access is checked from the database on every request, so changes apply immediately | Garage Owner | Must have | Phase 1 |
| FR-IAM-04 | Forgot / reset password | The user enters their e-mail and receives a 6-digit OTP by e-mail, valid for 2 minutes; after entering the OTP they set a new password (a short-lived reset token links the two steps). The answer does not reveal whether the e-mail has a user. All sessions are revoked on reset. Not applicable to Google-only users | All | Must have | Phase 1 |
| FR-IAM-05 | Integration API key management | Garage Owner/Platform Admin creates and revokes API keys for third-party integrations (if a garage connects its own external systems) | Garage Owner, Platform Admin | Could have | Phase 16 |
| FR-IAM-06 | Link / unlink Google account | Allow a user to link a Google account to an existing e-mail user, or unlink it | All | Should have | Phase 13 |
| FR-IAM-07 | Interface language | The web console is available in Vietnamese (default) and English; the choice is saved on the user and also selects the language of e-mails | All | Must have | Phase 1 |
| FR-IAM-08 | Platform administrators | Platform Admin rights are granted to the users listed in the deployment configuration (PLATFORM_ADMIN_EMAILS); they hold every platform permission, including viewing any garage’s data without an owner’s approval (every access is logged), and manage plans and subscriptions (FR-LIC-05) | Platform Admin | Must have | Phase 1 (extended in Phase 8) |
| FR-IAM-09 | Multi-factor authentication | Users that sign in with e-mail and password can turn on MFA with a TOTP authenticator app and recovery codes. MFA is optional for every user (platform admins, owners, staff and customers alike) and is never enforced; the sign-in asks for a code only from a user who turned it on. Google sign-in relies on the Google account’s own 2-step verification and never asks for a code. Applies to the web consoles and to the owner, admin and technician apps; the customer app signs in with Google only, so it does not offer it | All | Should have | Phase 6 |
| FR-IAM-10 | Platform roles, groups and admin staff | The Platform Admin creates platform roles (sets of platform permissions: plan, subscription, stats, garage directory, user lookup, platform staff, support, audit), platform staff groups, and invites users into a group; the group’s roles apply per request. Admin staff see only what their roles allow in the admin web and admin app. Platform users can protect their sign-in with the optional MFA (FR-IAM-09) | Platform Admin | Must have | Phase 8 |
| FR-IAM-11 | Read-only support access to a garage | Admin staff request a time-boxed, read-only support grant for one garage with a reason; the garage owner approves it. A Platform Admin needs no approval but gives a reason, and the owner is notified. A support session cannot change data or act as a user, shows a banner, and every read is audited. The owner sees a Support access log and can revoke a grant at once. Masking of sensitive fields and write access are not offered yet | Admin staff, Platform Admin, Garage Owner | Must have | Phase 8 |
| FR-IAM-12 | User profile name | A user can edit their full name. The name is a display name, taken from Google at first sign-in; Google sign-in never overwrites a name the user has edited (full_name_source). Names printed on invoices, vouchers and payments come from business records (the garage’s legal name, the customer’s tax profile, the payer on a voucher), never from the user’s display name | All | Must have | Phase 1 (source tracking in Phase 5) |
3.2. Tenant / Garage Management
Terminology note: in this document, “branch” and “garage” are used interchangeably. The user model is one owner – many garages: an owner (chain owner) registers a single user, then creates and manages multiple independent garages under that same user — each garage acts as one branch within the chain, with its own operational data, staff, and configuration, but sharing a single login and a single license subscription (see Section 3.3).
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-TEN-01 | Create garage profile | Enter information for one garage: name, address, phone, e-mail and a logo (PNG/JPEG/WebP up to 1 MB). The legal identity used on documents and invoices is FR-TEN-06 | Garage Owner | Must have | Phase 1 |
| FR-TEN-02 | Create multiple garages under one user | Owner creates additional garages under the same registered user (one owner – many garages model); each garage created is an independent operating unit, equivalent to one branch in a chain model. The owner can edit each garage and set its status to Active or Inactive (staff cannot use an inactive garage). The number of active garages is limited by the owner’s plan (FR-LIC-02) | Garage Owner | Must have | Phase 1 |
| FR-TEN-03 | Switch active garage | Allow a user to switch between the garages it owns or works in within the same session, without signing in again | Garage Owner, Staff | Should have | Phase 1 |
| FR-TEN-04 | Staff management | Only existing VietGara users can become staff. A user with staff.write looks a user up by e-mail or phone and sends an invitation for the garage with the staff groups to join; the invitee receives an e-mail and accepts or declines in the web console (invitations expire after 7 days and can be revoked). Staff members are then assigned to groups, set Active/Inactive, or removed. The number of staff across the owner’s garages (members plus pending invitations) is limited by the plan | Garage Owner, Manager | Must have | Phase 1 |
| FR-TEN-05 | Garage configuration | Configure time zone (default Asia/Ho_Chi_Minh), displayed currency (default VND), weekly operating hours, quote/repair order/settlement numbering templates (e.g. BG-{YYYY}{MM}-{SEQ:4}), and the garage’s default quote approval mode (public link or manual, FR-QUO-02) per garage. Stored in Release 1.1; the numbering templates and default approval mode are applied when quotes, repair orders and settlements arrive in Releases 1.2–1.4. From Release 7.0 also the goods receipt and stock issue numbering templates and the stock issue mode (post when the order closes, or when work starts, FR-INV-20) | Garage Owner | Should have | Phase 1 |
| FR-TEN-06 | Garage legal profile | Store the garage’s legal company name, tax ID (mã số thuế), legal address, representative, bank account and logo. They print in the header of every document (quotes, repair orders, settlements, payment vouchers) and are the seller data of e-invoices (FR-EIN-02). Changing them never rewrites documents already issued: each document keeps a snapshot | Garage Owner | Must have | Phase 5 |
3.3. License Management
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-LIC-01 | Trial plan sign-up | Automatically create a 14-day trial subscription for the owner when its e-mail is verified | System | Must have | Phase 1 |
| FR-LIC-02 | Plan upgrade / downgrade | The subscription belongs to the owner and covers all its garages. Each plan sets limits on garages, staff and business transactions per day (quotes, repair orders and settlements created), e.g. Pro = 2 garages, 20 staff, 100 transactions/day, plus included features. The owner chooses another plan in the web console or the owner app and pays for it by bank transfer (FR-LIC-07); the new plan takes effect at once when the platform admin approves the payment (FR-LIC-08), so an upgrade, a downgrade and a billing-cycle change follow the same rule. Usage is validated against the new plan’s limits (garages, staff) when the request is submitted and again at approval; a plan the usage exceeds is refused with PLAN_LIMIT_REACHED, and the limits are listed so the owner knows what to reduce. The trial plan is given once, by the system, at sign-up (FR-LIC-01) and is never offered again. The unused part of the current period is credited against the new price (FR-LIC-09). Until the payment is approved the current plan stays in force | Garage Owner | Must have | Phase 1 / Phase 5 (manual payment) / Phase 16 (online payment) |
| FR-LIC-03 | Automatic subscription renewal | Automatically renew on the subscribed cycle, charging the saved payment method at the price of the plan then in effect; it replaces the manual renewal request of FR-LIC-07 | System | Must have | Phase 16 |
| FR-LIC-04 | Expiry alerts & read-only mode | Notify the owner 7 days before the period ends, with the platform’s payment instructions and the amount to renew (FR-LIC-07); switch to read-only mode during the grace period if not renewed, then suspend. The owner is e-mailed when the subscription becomes past due (read-only until the end of the grace period) and again when it is suspended, each time with the amount and the platform’s payment instructions. A payment approved at any time reactivates the subscription | System | Must have | Phase 1 / Phase 5 (payment instructions) |
| FR-LIC-05 | Plan management (platform side) | Platform Admin creates and edits plans with price, billing cycle, limits, included features, visibility and availability; looks up subscriptions and extends them manually (a correction or goodwill, FR-LIC-08 is the normal way to renew). Provided in the vietgara-admin-web app | Platform Admin | Must have | Phase 1 |
| FR-LIC-06 | Add garages beyond plan limit | Charge an additional fee when an owner adds garages beyond the plan’s limit (BranchLicense) | Garage Owner | Should have | Phase 16 |
| FR-LIC-07 | Plan payment request | To change plan or renew, the owner starts a request and is shown the amount due (new price minus the credit of FR-LIC-09), the platform’s bank details with a QR code (FR-LIC-10) and a unique transfer reference such as VG-7K2M9Q to write in the transfer note; the request waits for the payment. After transferring, the owner submits the payer’s name, bank and account, the amount transferred, the bank’s transaction reference, the date and a screenshot of the evidence. The request is validated against the plan’s limits (FR-LIC-02). An owner has one open request at a time (one that is still waiting for payment is replaced by a new one), can cancel it before it is reviewed, and a submitted request never expires, because the money has already moved. When the credit covers the whole price the amount due is 0: no transfer and no evidence are needed, and the platform admin still approves. The amount quoted at submission is the amount honoured at approval. The owner sees the request’s status and, when rejected, the reason, and may submit again | Garage Owner | Must have | Phase 5 |
| FR-LIC-08 | Payment review and approval | Platform Admin works a review queue of submitted requests with the owner, plan, quoted and declared amounts and the evidence. Approve applies the plan at once in one transaction: the plan and its limits take effect, a new period of the plan’s billing cycle starts at approval (the unused days of a trial are lost; a renewal of the current plan before its end extends from the old end date, one after expiry restarts from approval and reactivates the subscription), the amount paid is recorded on the period, a surplus is added to the account credit (FR-LIC-09) and the entitlements are refreshed. The limits are validated again; an approval that would exceed them is refused with the reason. When the amount transferred differs from the quote the admin sees a warning, resolves it with the owner and may still approve with a note. Reject needs a reason, which the owner sees. The admin is e-mailed when a request arrives and reminded every day while requests wait; the owner is e-mailed on approval and rejection. Every decision is audited | Platform Admin | Must have | Phase 5 |
| FR-LIC-09 | Proration and account credit | Changing plan before the period ends credits the owner for the unused part of the current period: credit = whole unused days ÷ days of the period × the price of that period (what was paid, credit included), rounded down to whole dong; a trial period was paid 0. The amount due is the new plan’s full price minus the available credit, never below 0. When the credit exceeds the new price (a downgrade) the surplus becomes account credit, applied automatically to the next payment; refunds are paid manually by the platform outside the system. Every credit movement is kept in a ledger the owner can see | Garage Owner | Must have | Phase 5 |
| FR-LIC-10 | Platform payment details | Platform Admin edits the bank, account number, account holder, branch, transfer instructions and an uploaded QR code image that owners are shown with every request, in the vietgara-admin-web and vietgara-admin-app apps. Every change is audited with who and when, and a request keeps the instructions that were shown when it started | Platform Admin | Must have | Phase 5 |
stateDiagram-v2
[*] --> Trial: e-mail verified
Trial --> Active: payment approved
Trial --> PastDue: trial ends
Active --> Active: plan change or renewal approved
Active --> PastDue: period ends
PastDue --> Active: payment approved / extended
PastDue --> Suspended: grace period ends
Suspended --> Active: payment approved / extended
note right of PastDue: read-only
note right of Suspended: locked
3.4. Customer & Vehicle Management
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-CUS-01 | Create/edit customer profile | Store customer information: name, phone, email, address. A customer is a garage-owned profile and needs no VietGara user: staff create a customer (a “walk-in customer”) when the person does not want a user. When the person has a user, the profile is linked to it (FR-CUS-06) | Service Advisor | Must have | Phase 1 (profile) / Phase 5 (user optional, FR-CUS-06) |
| FR-CUS-02 | Register vehicle profile | Store license plate, make/model, chassis number, engine number, year, linked to one customer. Identity fields (plate, chassis, engine number, make, model, year) can be edited only while no live document refers to the vehicle (quote, repair order, settlement, booking or claim; a deleted quote does not count; all six fields lock together). Other fields (colour, notes, odometer) are always editable. A locked field is changed by a correction (FR-CUS-09) | Service Advisor | Must have | Phase 1 (edit lock in Phase 5) |
| FR-CUS-03 | Look up repair history by vehicle | View the complete history of quotes/repair orders/settlements for a specific vehicle | Service Advisor, Garage Owner | Must have | Phase 1 |
| FR-CUS-04 | (moved) | Moved to FR-SUP-01 (Section 3.23): a supplier is not a customer. The directory of suppliers is no longer part of the Customer & Vehicle group | — | — | Phase 5 |
| FR-CUS-05 | Personal data subject requests | Allow customers to request to view/edit/delete their personal data in accordance with Decree 13/2023/ND-CP | End Customer | Must have | Phase 13 |
| FR-CUS-06 | Find and link a customer with a user | While preparing a quote, staff search the garage’s customers (name, phone, e-mail or plate). When the profile has an e-mail that is the verified e-mail of a VietGara user, staff can send a link request; the garage learns only that a request was sent, never who the user is, and a request for an e-mail nobody owns is refused. The user confirms with the one-time code sent to their e-mail (which staff enter), or accepts or declines in the Customer App; either side can end the link and the profile stays. A customer has at most one current link; declined and ended links stay as history. A user’s verified e-mail still links matching profiles automatically at sign-in, but only when the profile has never had a link with that user (a refusal or an unlink is respected, and a request still waiting is answered in the app) and no other user is linked to it. If the person has no user or declines, staff keep or create a walk-in customer without one. Phone matching needs a verified, normalized (E.164) phone and waits for phone sign-in (Release 2.4); until then a link is matched by e-mail only. Link changes are audited without naming the user | Service Advisor, End Customer | Must have | Phase 5 |
| FR-CUS-07 | Customer tax profiles | A customer has tax profiles of two kinds in one list: at most one personal and any number of company profiles (legal name, tax ID, address, e-mail for invoices; one marked default, which a deactivated profile loses). The tax ID is optional but format-checked (10 digits, or 13 with the branch suffix; spaces, dots and dashes typed are dropped). A quote picks the billing party, and the choice is kept as a snapshot on the quote, carried to its repair order and starting the settlement, which can change it later; PDFs and payment vouchers print it, and the voucher’s payer defaults to it. When no party is chosen the customer’s default profile is used (retail if there is none); choosing retail on purpose bills the customer under their own name. A settlement can be marked invoice requested only when its billing party is complete (legal name, tax ID and address, for a personal or a company profile); otherwise the request is refused (INVOICE_DATA_INCOMPLETE) and the document stays a retail receipt. A profile a quote or settlement was billed to is deactivated instead of deleted (FR-CAT-07). Used by documents (FR-DOC-01) and e-invoices (FR-EIN-02). Which identity an individual buyer must show is to be confirmed with the garage’s accountant | Service Advisor, Garage Accountant | Must have | Phase 5 |
| FR-CUS-09 | Correct a locked vehicle field | A garage staff member who holds the permission customer.correct (the Manager role and the owner have it; it includes customer.read) can correct one identity field of a vehicle that live documents use, with a mandatory reason. The correction is audited with the values before and after; documents keep the value they snapshotted. If the vehicle really changed, the garage deactivates it and creates a new one; if it was sold, an owner-change action (reason optional, audited) moves it to another customer of the garage and keeps its history. An ordinary edit never changes the owner. The API tells the screens which fields are locked (editable, lockedFields) and refuses a locked edit with VEHICLE_FIELD_LOCKED | Garage staff with customer.correct | Must have | Phase 5 |
3.5. Quote & Pricing
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-QUO-01 | Create a quote | Select customer (found by phone or e-mail, FR-CUS-06), vehicle and vehicle owner, add labor/part line items, system automatically calculates each line total and the quote total. From Phase 7 a line can come from the job catalogue (FR-CAT-06). Numbered from the garage’s quote numbering template (FR-TEN-05); counts against the plan’s daily transaction limit (FR-LIC-02) | Service Advisor | Must have | Phase 1 |
| FR-QUO-02 | Send quote for customer approval | The gara owner chooses, per quote (default from the garage’s own setting, FR-TEN-05), how the customer approves: Link — a public, no-login viewing/approval link is generated and e-mailed to the customer automatically when they have an e-mail on file (at minimum notifying them of the proposed work), or shared by the advisor by any other channel; or Manual — no link or e-mail is produced, for garages that only ask the customer face to face | System | Must have | Phase 1 (web link) / Phase 11 (in the Customer App, FR-CAPP-03) |
| FR-QUO-03 | Approve/reject quote | The customer’s acceptance or rejection of each individual line item is recorded either by the customer themself through the public link (Link mode) or by a staff member on the customer’s behalf (Manual mode, or as an override of Link mode, e.g. the customer decided by phone). The quote as a whole is Approved once at least one line is approved, otherwise Rejected | End Customer, Service Advisor | Must have | Phase 1 |
| FR-QUO-04 | Convert quote to repair order | After the quote is approved, create a draft repair order preserving only the approved line items; counts separately against the plan’s daily transaction limit. Full repair-order management (technician assignment, Kanban board, progress) arrives with the Repair Order module in Release 1.3 | Service Advisor | Must have | Phase 1 |
| FR-QUO-05 | Print / export quote as PDF | Export the quote as a PDF using the garage’s template | Service Advisor | Must have | Phase 1 |
3.6. Repair Order
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-REP-01 | Create repair order | Generate a repair order from an approved quote, or create one directly for ad-hoc work | Service Advisor | Must have | Phase 1 |
| FR-REP-02 | Assign technicians | Assign one or more technicians to each line item within the repair order | Service Advisor | Must have | Phase 1 |
| FR-REP-03 | Update progress | Technician updates the status of each line item: not started / in progress / completed. The repair order’s own status is derived from its lines: open, in progress, completed or closed, plus waiting_on_parts for an order blocked on a part that is not in stock (the Kanban board’s fifth column) | Technician | Must have | Phase 1 (web) / Phase 11 (app) |
| FR-REP-04 | Before/after repair photos | Attach photos documenting vehicle condition before and after repair to the repair order | Technician | Should have | Phase 11 |
| FR-REP-05 | Real-time progress tracking | Customer views their vehicle’s repair progress in real time via the Customer App | End Customer | Should have | Phase 11 |
| FR-REP-06 | Close repair order | Mark all line items as complete, lock further edits, move to the settlement step | Service Advisor | Must have | Phase 1 |
| FR-REP-07 | Change the lines of an open repair order | Add, edit (description, part, quantity, unit, price) and remove lines of a repair order that is not closed or cancelled; the total and status follow, and the draft stock issue follows the part lines. After the stock issue is posted the parts are fixed, but labor lines and prices stay editable | Service Advisor | Should have | Phase 7 (Release 7.3) |
| FR-REP-08 | Cancel a repair order | Cancel an order that is open or waiting on parts and has no started work: its draft stock issue is cancelled and the reservation released. The quote it came from stays converted. Refused once work has started or the stock issue is posted | Service Advisor | Should have | Phase 7 (Release 7.3) |
3.7. Inventory Management
Quantities are always kept in the part’s base unit (FR-CAT-02); how stock is received, issued, counted and corrected is described step by step in Business Procedures P11 to P13.
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-INV-01 | Stock receipt | Record a goods receipt from a supplier, updating on-hand quantity and average cost. From Release 7.0 a receipt is a goods receipt document (FR-INV-06); the single-part receipt of Release 1.3 is replaced | Inventory Staff | Must have | Phase 1 (document in Phase 7) |
| FR-INV-02 | Stock issue | Parts consumed by a repair order are issued through the stock issue document of FR-INV-20 and automatically decrement stock | System (triggered from Repair Order) | Must have | Phase 1 (document in Phase 7) |
| FR-INV-03 | Stock lookup | View current on-hand quantity per part code, per branch | Inventory Staff, Garage Owner | Must have | Phase 1 |
| FR-INV-04 | Low-stock alerts | Send a notification when a part’s stock falls below a configured threshold | System | Should have | Phase 10 |
| FR-INV-05 | Periodic in/out/on-hand report | Export a stock movement report by month/quarter/year | Garage Owner, Inventory Staff | Must have | Phase 1 |
| FR-INV-06 | Goods receipt document | A multi-line goods receipt with number from the garage’s template, date, delivery note number and notes; status draft, completed, cancelled. Every line records its supplier (a garage supplier, FR-SUP-01); the header supplier is only a default that lines inherit and may override, and a receipt cannot be completed while a line has no supplier. Lines are added by search; barcode scanning and Excel import come with Release 7.2. Completing updates stock and cost; cancelling a completed receipt reverses it, and is refused when part of that stock has already been used | Inventory Staff | Must have | Phase 7 (done in Release 7.0) |
| FR-INV-07 | Weighted-average cost and valuation | Each completed receipt updates the part’s weighted-average cost; every stock issue keeps a cost snapshot. A valuation report shows quantity and value per part and category at a date, as Excel too | Inventory Staff, Garage Accountant | Must have | Phase 7 (done in Release 7.0) |
| FR-INV-08 | Cost visibility permission | Cost, average cost and valuation are visible only with inventory.cost.read. By default managers and accountants have it; advisors and technicians see quantities only | Garage Owner | Must have | Phase 7 (done in Release 7.0) |
| FR-INV-09 | Stock write-off | Reduce stock with a reason (damaged, lost, expired, internal use, warranty replacement) at average cost, as a numbered document. The document is posted when created and is refused beyond the quantity on hand; cancelling it puts the parts back at their cost | Inventory Staff | Must have | Phase 7 (done in Release 7.1) |
| FR-INV-10 | Return to supplier | A numbered document that reduces stock and records the supplier credit, linked to the supplier and, where known, to a completed goods receipt of that supplier. A line without a typed cost takes the cost of that receipt, else the average cost; the credit is the sum of the lines’ amounts. Cancelling it puts the parts back | Inventory Staff | Should have | Phase 7 (done in Release 7.1) |
| FR-INV-11 | Return of unused parts from a repair order | Return a part line of a repair order to stock, reversing its cost, with a reason (required). Possible only once the order’s stock issue is posted, up to the quantity issued on that line. The record is immutable and does not change the order’s lines or the billing | Service Advisor, Inventory Staff | Should have | Phase 7 (done in Release 7.1) |
| FR-INV-12 | Stock count | A stock-count document: counted quantity per line against the system quantity, shown as matched, over, short or uncounted; draft save and merge of drafts; completing posts adjustments so stock equals the count and records the value of the difference at average cost, and the count is then read-only; cancelling a completed count posts its reversal; Excel export | Inventory Staff | Must have | Phase 7 (done in Release 7.1) |
| FR-INV-13 | Barcodes | Up to 20 barcodes per part, unique in the garage without regard to case; each is for the base unit or a packaging unit (a case barcode stands for a case). Scanning with the phone camera (or a USB scanner, which types into the field) adds a line to a receipt or a count, or opens the part; a code no part has is told on the spot. Label printing arrives with thermal printing | Inventory Staff | Should have | Phase 7 (scan, done in Release 7.2) / Phase 14 (labels) |
| FR-INV-14 | Excel import | Import parts (with units, categories, brand, barcodes, opening quantity, cost and a supplier per row), goods receipts and stock counts from a downloadable template: upload, a preview that lists every problem with its row and column, then confirm. A file is imported as a whole or not at all; the same file cannot be imported twice. Opening stock is posted as one completed goods receipt; receipt and count files make a draft. Up to 5,000 rows and 5 MB | Inventory Staff, Garage Owner | Should have | Phase 7 (done in Release 7.2, web console) |
| FR-INV-15 | Stock reservation | The draft stock issue of a repair order (FR-INV-20) is the reservation: a part shows on hand, reserved (in draft issues) and available. The reservation is consumed when the issue is posted and released when the repair order is cancelled (FR-REP-08). Reservations are served first come, first served per part; a repair order whose draft issue the stock on hand cannot cover is waiting on parts, and comes back by itself when stock arrives or another order frees it. It never blocks the work | System | Should have | Phase 7 (reserve in 7.0; waiting on parts and release in 7.3) |
| FR-INV-16 | Purchase orders | Create purchase orders per supplier from the low-stock list; printable and e-mailed; shown to the supplier in the supplier portal from Phase 17; receiving pre-fills a goods receipt | Inventory Staff | Should have | Phase 13 |
| FR-INV-17 | Supplier payables | Each completed goods receipt creates payables per supplier of its lines; payment-out vouchers allocate against it; payables list by supplier and age, and Excel export | Garage Accountant | Should have | Phase 13 |
| FR-INV-18 | Transfer between garages | An owner moves parts between their garages with a two-step document (ship, receive), each step scoped to one garage | Garage Owner, Inventory Staff | Could have | Phase 15 |
| FR-INV-19 | Part suppliers | A part lists its usual suppliers with the supplier’s own code and the last cost paid, and one default supplier. The default pre-fills the supplier of a receipt line; purchases by supplier and period are reported from completed receipts. Purchase orders (FR-INV-16) will group by supplier too | Inventory Staff | Should have | Phase 7 (done in Release 7.0) |
| FR-INV-20 | Stock issue document (phiếu xuất kho) | Creating a repair order automatically creates a numbered draft stock issue listing every part line of the order, printable; lines added, removed or changed on the order update the draft until it is posted. Posting writes the stock movements. By default it posts when the order is closed; inventory staff can post earlier (“issue now”) when parts leave the shelf, and a garage setting can post when the order starts. After posting, corrections are returns or adjustments (FR-INV-09..11). Stock is not deducted at creation, because orders are cancelled and parts are not yet taken | System, Inventory Staff | Must have | Phase 7 (done in Release 7.0) |
3.8. Billing & Settlement
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-BIL-01 | Create settlement | Aggregate costs from a closed repair order and calculate the final total | Garage Accountant | Must have | Phase 1 |
| FR-BIL-02 | Allocate customer-paid / insurance-paid amounts | Withdrawn in Release 5.0. A settlement has a single payer, the customer. Splitting a settlement with an insurer returns, designed around insurance claims, as FR-INS-05 | Garage Accountant | Must have | Phase 1 (withdrawn in Phase 5, returns in Phase 17) |
| FR-BIL-03 | Record payment | Record the amount actually collected and the payment method (cash/bank transfer/online payment). Each recorded payment produces a payment voucher (FR-BIL-05) | Garage Accountant | Must have | Phase 1 |
| FR-BIL-04 | Issue e-invoice from settlement | Automatically trigger an e-invoice issuance request as soon as a settlement is confirmed | System | Must have | Phase 16 |
| FR-BIL-05 | Payment voucher (phiếu thu) | Every recorded payment gets its own voucher numbered from the garage’s voucher numbering template, with the payer’s name and address (or the billing company of FR-CUS-07), the reason for payment, amount in figures and words, method, the collector and signature blocks. It can be printed as a PDF (FR-DOC-01) in the 01-TT layout | Garage Accountant | Must have | Phase 5 |
| FR-BIL-06 | Void a payment voucher | A wrong payment can be voided with a reason. The voucher stays on file marked void and the settlement totals are recalculated; the audit log records who voided it | Garage Accountant | Must have | Phase 5 |
| FR-BIL-07 | Payment-out voucher (phiếu chi) | Record money paid out, for example to a supplier after a stock receipt, with its own numbered voucher | Garage Accountant | Should have | Phase 13 |
3.9. Receivables
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-REC-01 | Track customer receivables | List of settlements not yet fully collected, per customer: the settlement list filtered to pending and partially paid (outstandingOnly), each row carrying its customer; a receivables model with reminder state arrives in Phase 13 | Garage Accountant | Must have | Phase 1 |
| FR-REC-02 | Track insurance receivables | List of amounts pending payment from insurers, per claim | Garage Accountant | Must have | Phase 17 |
| FR-REC-03 | Automated payment reminders | Send payment reminder notifications to customers on a configured schedule (e.g. 3 days, 7 days overdue) | System | Should have | Phase 13 |
| FR-REC-04 | Receivables reconciliation | Export a periodic receivables reconciliation report for accounting purposes | Garage Accountant | Must have | Phase 13 |
3.10. Insurance Integration
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-INS-01 | Create an insurance claim | From a repair order of a vehicle with a claim, staff create a claim record: insurer (from the garage’s insurers, FR-INS-07), policy number, incident date, place and a short description. The claim is a tracking workflow around the repair; the vehicle owner files the claim with the insurer | Service Advisor | Must have | Phase 17 |
| FR-INS-02 | Notification and assessment deadlines | The claim shows its deadlines and reminds staff and the owner: the insurer must be told in writing or through its app or e-mail within 5 working days of the incident (Decree 67/2023/ND-CP), and the insurer’s assessor inspects the vehicle within 24 hours. Staff attach the assessment report (biên bản giám định) | Service Advisor, End Customer | Must have | Phase 17 |
| FR-INS-03 | Insurer-agreed quote and document checklist | The garage’s quote is versioned as the insurer-agreed quote once cost and repair method are agreed. A checklist tracks the claim file: vehicle registration, driver’s licence, ID card of the owner or driver, insurance certificate or e-policy, accident report (police, if any), damage and assessment reports, repair invoice and vouchers. The vehicle owner can upload documents in the Customer App | Service Advisor, End Customer | Must have | Phase 17 |
| FR-INS-04 | Track claim status | Claim status: reported / assessed / quote agreed / file submitted / under review / approved / rejected / paid, with the expected review time (3-5 days for small losses, 7-15 days for complex ones) | Garage Accountant, Service Advisor | Must have | Phase 17 |
| FR-INS-05 | Split settlement with the insurer | When a claim is approved, the settlement splits into the owner’s deductible or out-of-cover part and the insurer’s payable part. Payments from the insurer are recorded against the claim, and receivables (FR-REC-02) follow | Garage Accountant | Must have | Phase 17 |
| FR-INS-06 | Submit the claim file | Package the file according to the insurer’s template for manual e-mail or portal submission, or submit by API where the insurer supports it (PVI, PTI, Bao Viet first) | Service Advisor, System | Should have | Phase 17 |
| FR-INS-07 | Manage insurers | The garage keeps its own directory of insurers (name, hotline, claim e-mail or portal, claim file template). An insurer is a record of the Insurance module: it is never a customer (the policy holder is the vehicle’s customer) and never a supplier | Garage Owner, Service Advisor | Must have | Phase 17 |
3.11. Payment Gateway Adapter
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-PAY-01 | Online payment for customers | Customer pays a settlement via VNPay/Momo/ZaloPay directly in the Customer App or via a payment link | End Customer | Must have | Phase 16 |
| FR-PAY-02 | Payment confirmation via webhook | Receive a webhook confirming a successful transaction from the payment gateway and automatically update receivables status | System | Must have | Phase 16 |
| FR-PAY-03 | Platform subscription payment | Garage owner pays the recurring License fee via a saved payment method; it replaces the manual transfer and review of FR-LIC-07 and FR-LIC-08 | Garage Owner | Must have | Phase 16 |
3.12. E-Invoice Service
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-EIN-01 | Connect e-invoice provider account | Garage owner enters their VNPT or Viettel user/contract details to activate the integration | Garage Owner | Must have | Phase 16 |
| FR-EIN-02 | Issue e-invoice | Send an invoice issuance request to the connected provider and receive the invoice number and digital signature status | System | Must have | Phase 16 |
| FR-EIN-03 | Look up invoice status | View invoice status: issued / submitted to tax authority / cancelled | Garage Accountant | Must have | Phase 16 |
| FR-EIN-04 | Cancel/adjust invoice | Submit a cancellation or issue an adjustment invoice in accordance with current regulations | Garage Accountant | Should have | Phase 16 |
3.13. Document/Print Service
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-DOC-01 | Export quote/repair order/receipt as PDF | Generate a PDF using the garage’s standard template for each document type. From Release 7.0 also the goods receipt (FR-INV-06) and the stock issue (FR-INV-20) | All (per permission) | Must have | Phase 1 (goods receipt and stock issue: Release 7.0) |
| FR-DOC-02 | Export reports as Excel | Export reports to Excel: inventory movement (Phase 1; from Phase 6 in the part’s units, FR-CAT-02), purchases by supplier and stock valuation (Release 7.0, FR-INV-07 and FR-INV-19), stock count (Release 7.1, FR-INV-12), revenue (Phase 6) and receivables (Phase 13) | Garage Owner, Garage Accountant | Must have | Phase 1 / 6 / 13 |
| FR-DOC-03 | Customize document templates | Allow a garage to design its own templates for printed documents. Provided as the constrained template designer of FR-DOC-09 | Garage Owner | Could have | Phase 14 |
| FR-DOC-04 | Print templates and paper sizes | Each printable document (quote, repair order, settlement, payment voucher, stock receipt and issue voucher) has built-in templates per paper size. A4 (210 x 297 mm) is the default, used for detailed quotes, part lists and warranty terms; A5 (148 x 210 mm) serves payment slips and short quotes. A garage picks its default template and paper size per document type. Every template renders one stable print model per document type | Garage Owner, All (per permission) | Must have | Phase 10 |
| FR-DOC-05 | Print from web and mobile | Print through the system print dialog on the web, and through the OS print and share sheet (AirPrint, Android print) in the mobile apps. Any printer the device already knows, including network printers, works | All (per permission) | Must have | Phase 10 |
| FR-DOC-06 | Thermal receipt printing | Roll-paper templates (K80 and K57) for payment vouchers and quick quotes, rendered as ESC/POS for thermal printers | All (per permission) | Should have | Phase 14 |
| FR-DOC-07 | LAN printer discovery and direct printing (mobile) | The mobile apps find network printers by mDNS (and manual IP entry), store the garage’s printers and print directly (ESC/POS over TCP 9100 for thermal, IPP for A4). Web browsers cannot discover printers, so the web uses FR-DOC-05 or FR-DOC-08 | Garage Owner, Service Advisor | Should have | Phase 14 |
| FR-DOC-08 | Print agent | An optional local agent on a garage PC lists the PC’s printers and prints jobs from the web silently, over an outbound secure connection to VietGara | Garage Owner | Could have | Phase 14 |
| FR-DOC-09 | Template designer | A garage designs its own templates with blocks (header with logo, parties, items table with chosen columns, totals, footer, notes) over a whitelist of print-model fields, with a live preview. Templates are versioned and a printed document keeps the version it used. No free-form HTML | Garage Owner | Could have | Phase 14 |
| FR-DOC-10 | E-invoice printout | An e-invoice is printed from the PDF the invoice provider returns, not from a VietGara template. Until e-invoicing ships (Phase 16) VietGara prints a payment slip or voucher, never a tax invoice | All (per permission) | Must have | Phase 16 |
3.14. Notification Service
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-NOT-01 | SMS notifications | Send SMS to customers on important updates (new quote, vehicle ready) | System | Must have | Phase 16 |
| FR-NOT-02 | Zalo ZNS notifications | Send official notifications via the Zalo channel to customers with a verified phone number | System | Should have | Phase 16 |
| FR-NOT-03 | In-app push notifications | Send push notifications to the Owner, Admin, Customer and Technician Apps | System | Must have | Phase 11 |
| FR-NOT-04 | Email notifications | Send e-mails for key events in the recipient’s language: verification and password-reset OTPs, staff invitations, registration confirmation, license renewal reminders and past-due and suspension notices with the payment instructions, plan payment decisions and the admin’s review reminders (FR-LIC-07, FR-LIC-08) (Mailjet in staging/production). Invoices are sent with FR-EIN-02 | System | Must have | Phase 1 / Phase 5 |
| FR-NOT-05 | Expanded e-mail notifications | E-mail customers and garage staff at each hand-off, in the recipient’s language: quote ready, quote approved/rejected, vehicle ready, settlement receipt (PDF attached), payment received. Each garage chooses which are sent; customers can opt out of non-essential e-mails; every send is logged and retried | System | Should have | Phase 10 |
3.15. Reporting & Analytics
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-RPT-01 | Periodic revenue report | Revenue statistics by day/month/quarter/year for a single garage | Garage Owner | Must have | Phase 1 |
| FR-RPT-02 | Technician performance report | Statistics on completed repair orders and average turnaround time per technician | Garage Owner | Should have | Phase 13 |
| FR-RPT-03 | Multi-branch consolidated dashboard | Consolidated revenue, inventory, and receivables figures across all branches of a garage chain | Garage Owner | Should have | Phase 15 |
| FR-RPT-04 | Custom report export | Filter and export reports by custom date range, branch, and service type | Garage Owner, Garage Accountant | Could have | Phase 15 |
| FR-RPT-05 | Profit per repair order and job | Revenue less the cost snapshots of consumed parts, per repair order and in a report by period, job and technician; visible only with inventory.cost.read | Garage Owner, Garage Accountant | Should have | Phase 13 |
3.16. Customer App
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-CAPP-01 | Login/register | Authenticate the customer with Google or by OTP sent to the phone number (open within Release 2.4). A user is optional for being a garage’s customer (FR-CUS-01) | End Customer | Must have | Phase 2 |
| FR-CAPP-02 | View vehicle list & history | View registered vehicles and each vehicle’s repair history | End Customer | Must have | Phase 2 |
| FR-CAPP-03 | Approve quotes & track progress | View and approve/reject quotes; track repair progress in real time | End Customer | Must have | Phase 11 |
| FR-CAPP-04 | Pay & receive e-invoice | Make an online payment and receive the e-invoice directly in the app | End Customer | Must have | Phase 16 |
| FR-CAPP-05 | Accept a garage link request | See the garages that hold a customer profile for the user: link requests waiting for an answer and the garages already linked. Accept or decline a request, or end a link. Records linked by the verified e-mail appear without a request (FR-CUS-06). Suppliers never appear here | End Customer | Must have | Phase 5 |
| FR-CAPP-06 | Book an appointment | Pick a garage, a vehicle, jobs and a slot, and see, change or cancel bookings (FR-BKG-03) | End Customer | Must have | Phase 12 |
3.17. Technician App
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-TAPP-01 | Receive assigned repair order list | View the list of work assigned for the day, sorted by priority | Technician | Must have | Phase 2 |
| FR-TAPP-02 | Offline-first progress updates | Update work status even while offline, automatically syncing once connectivity is restored | Technician | Must have | Phase 11 |
| FR-TAPP-03 | Capture & upload before/after photos | Take photos directly within the app and attach them to the corresponding repair order | Technician | Must have | Phase 11 |
3.18. Owner App
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-OAPP-01 | Sign in & garage switcher | Sign in with e-mail and password, verify the e-mail, reset the password, accept invitations and switch between the owner’s garages | Garage Owner | Must have | Phase 2 |
| FR-OAPP-02 | Follow up quotes & repair orders | Send quotes, record the customer’s decision, convert to a repair order; update line progress and technicians, close orders | Garage Owner | Must have | Phase 2 |
| FR-OAPP-03 | Receivables & documents | See outstanding settlements, record payments with their vouchers, share quote/repair order/receipt PDFs | Garage Owner | Must have | Phase 2 |
| FR-OAPP-04 | Dashboard & subscription | Revenue, orders in progress, low stock and receivables at a glance; plan, usage, plan change and renewal with the payment request of FR-LIC-07 and its status | Garage Owner | Must have | Phase 2 / Phase 5 |
3.19. Admin App
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-AAPP-01 | Platform admin sign-in | Sign in for users listed as platform admins only (MFA per NFR-SE-04); other users are refused | Platform Admin | Must have | Phase 2 |
| FR-AAPP-02 | Plans & subscriptions on mobile | List and edit plans (FR-LIC-05); search subscriptions and extend one manually; work the payment review queue (FR-LIC-08) and edit the platform payment details with the QR code (FR-LIC-10) | Platform Admin | Must have | Phase 2 / Phase 5 |
| FR-AAPP-03 | Platform dashboards on mobile | The Platform Analytics figures of Section 3.20 | Platform Admin | Should have | Phase 12 |
Aggregate figures for VietGara’s own operators, in the admin web and the Admin App. Counts only, never a garage’s business data. Each figure can be bucketed by day, month or year over a chosen date range, and exported as CSV.
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-ADM-01 | New joiners | New users, verified users and new garages per day / month / year | Platform Admin | Must have | Phase 12 |
| FR-ADM-02 | Licenses | New trials, trial-to-paid conversions, plan upgrades/downgrades, subscriptions that became past due, suspended or cancelled, and active subscriptions by plan, per day / month / year | Platform Admin | Must have | Phase 12 |
| FR-ADM-03 | Platform activity | Active garages (a quote, repair order or settlement in the last 30 days) and platform-wide transactions per day | Platform Admin | Should have | Phase 12 |
3.21. Catalogue & Reference Data
Implemented by the Catalogue module (HLD #18): the part itself (including its selling price, brand and category), units, conversion, images and, from Phase 7, jobs. The quantities of a part belong to the Inventory module (HLD Section 3.1). Catalogue is guarded by its own permissions, catalogue.read and catalogue.write (Release 6.0, FR-IAM-03).
Shared reference data a garage manages itself: units of measure, parts, part categories and jobs. FR-CAT-07 applies to every object in this document that a user can delete.
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-CAT-01 | Units of measure | Add, edit and delete the garage’s units of measure (piece, litre, can, case, hour, …). Every part has one base unit | Garage Owner, Inventory Staff | Must have | Phase 6 |
| FR-CAT-02 | Unit conversion | Per part, define packaging units with a factor to the base unit (for example 1 case = 24 cans, a different factor per part). Stock is kept in the base unit. Stock receipts, stock issues and quote lines accept any unit of the part and are converted when saved; reports show both | Inventory Staff | Must have | Phase 6 |
| FR-CAT-03 | Part categories and brands | Parts belong to a category tree of up to three levels (for example Engine oil > Synthetic) and have a brand. Lists and pickers search and filter by SKU, name, category and brand | Inventory Staff, Service Advisor | Must have | Phase 6 |
| FR-CAT-04 | Part images | Upload one to three images per part (PNG/JPEG/WebP) for easier recognition in lists and pickers | Inventory Staff | Should have | Phase 6 |
| FR-CAT-05 | Job catalogue | Add, edit and delete jobs (types of work): name (unique in the garage), a category label, standard labor price and duration, and up to 30 suggested parts with a default quantity and unit. Follows the delete-or-deactivate rule (FR-CAT-07); a job is quoting data, so it needs the quote permissions | Garage Owner, Service Advisor | Must have | Phase 7 (Release 7.3) |
| FR-CAT-06 | Pick jobs when quoting | While creating a quote, staff pick a job; the system adds the labor line at the job’s labor price and one line per suggested part at the part’s current price, in the suggested unit, which stay editable. A deactivated job is not offered; a quote that already used it keeps its lines | Service Advisor | Must have | Phase 7 (Release 7.3) |
| FR-CAT-07 | Delete or deactivate | Deleting an object checks whether anything references it. An object used nowhere is soft-deleted. An object in use is only deactivated: it disappears from pickers but stays on the documents that use it, and staff can reactivate it. The confirmation dialog tells which will happen. Soft deletion is not erasure of personal data (see FR-CUS-05) | All (per permission) | Must have | Phase 5 (rule and first entities), then every new entity |
| FR-CAT-08 | Hidden consumables on a job | A suggested part of a job can be marked non-billable (grease, screws). Its line has no price, is left out of the quote total, the public approval page, the PDFs and the customer’s decisions; it goes to the repair order with its job, its stock is deducted, and its cost stays on the stock issue for the profit reports | Garage Owner | Should have | Phase 7 (Release 7.3) |
| FR-CAT-09 | Part selling price | A part has a selling price per base unit (VND), which is what the customer pays, separate from its cost (what the garage pays, FR-INV-07). A packaging unit uses the base price times its factor unless it has its own price. Part lines on quotes and the job picker prefill from it; changing a price never changes existing quotes. Cost is hidden without inventory.cost.read, the price is visible to anyone who can quote. A warning shows when a price is below the average cost | Garage Owner, Inventory Staff | Must have | Phase 6 |
3.22. Scheduling
Customers book appointments with a garage. Requirements follow the design recommendations of Release Plan Phase 12.
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-BKG-01 | Booking settings | Per garage: working hours, holidays and blocked periods, slot length, capacity per slot (vehicles taken at once), minimum lead time, cancellation window, and auto-confirm or manual confirm. Times follow the garage’s time zone (FR-TEN-05) | Garage Owner | Must have | Phase 12 |
| FR-BKG-02 | Slot availability | Free slots are computed from the settings and existing bookings when read, never stored in advance. A booking is created with a database-level capacity check so two customers cannot take the last slot | System | Must have | Phase 12 |
| FR-BKG-03 | Customer booking in the app | A customer with a user books a garage, a vehicle, one or more jobs from the job catalogue and a slot, and can see, reschedule or cancel their bookings | End Customer | Must have | Phase 12 |
| FR-BKG-04 | Public booking page | Each garage has a public page and QR code (/b/:garageSlug). A person without a user verifies their e-mail by OTP and a walk-in customer is created (FR-CUS-01). An unverified booking holds its slot for 15 minutes only | End Customer | Must have | Phase 12 |
| FR-BKG-05 | Confirm, reject and manage | Staff see bookings on a calendar (web and owner app), confirm or reject requests, create bookings by hand and mark a customer as arrived or no-show | Service Advisor | Must have | Phase 12 |
| FR-BKG-06 | Reminders | Push notification to the customer 24 hours before the slot when the customer has a linked user (the Customer App is the main channel), e-mail otherwise, and notices to staff on new requests and cancellations. SMS and Zalo are added with Phase 16 | System | Should have | Phase 12 |
| FR-BKG-07 | Convert to quote or repair order | Create a quote or repair order from a booking with the customer, vehicle and jobs prefilled. The new document counts toward the plan’s daily limit, the booking does not | Service Advisor | Must have | Phase 12 |
| FR-BKG-08 | Abuse protection | At most 2 open bookings per verified e-mail or phone per garage and 5 across the platform; per-IP rate limits on the public endpoints; a captcha after the limit trips; availability is shown without other customers’ data; a garage may require manual confirmation after repeated no-shows. Booking is a plan capability (booking_enabled) and is not metered | System | Must have | Phase 12 |
| FR-BKG-09 | Bays and technician assignment | Optional resources: the garage defines bays (lift, wash bay, paint booth) and marks which jobs need which bay type. A booking may carry a bay and a technician, with conflict detection over the estimated duration (the jobs’ durations). A grid calendar by bay or technician supports drag and drop. Customers never choose the technician. Without bays the simple capacity per slot applies | Garage Owner, Service Advisor | Could have | Phase 12 (Release 12.3) |
| FR-BKG-10 | Problem description and photos | The customer describes what is wrong and attaches up to three photos; they prefill the quote created from the booking | End Customer | Should have | Phase 12 |
| FR-BKG-11 | Visit status and owner page | After conversion the booking card shows the linked repair order’s progress (waiting, in service, done), and the quote or repair order links back to the booking. An owner-level page lists the owner’s garages for booking | Service Advisor, End Customer | Should have | Phase 12 |
3.23. Suppliers
A supplier sells parts to the garage. It is a garage-owned record in the Supplier module, separate from customers (vehicle owners) and from insurers. Money goes out to suppliers (payables, payment-out vouchers); it comes in from customers (receivables).
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-SUP-01 | Manage suppliers | Maintain the garage’s directory of parts suppliers: name (unique per garage), tax code, bank details, contact person, phone, e-mail, address and a note. In Phase 1 a supplier is the supplier type of “partners”; from Release 5.0 the record is its own suppliers table with supplier.read / supplier.write permissions. Follows the delete-or-deactivate rule (FR-CAT-07) | Garage Owner, Inventory Staff | Must have | Phase 1 / Phase 5 (rename) |
| FR-SUP-02 | Link a supplier with a user | When a supplier has a VietGara user, the garage sends a link request that the user confirms. The link has its own consent text and table (supplier_user_links) and does not use the customer flow of FR-CUS-06 | Garage Owner, Supplier | Could have | Phase 17 |
| FR-SUP-03 | Supplier portal | A linked supplier user sees the purchase orders addressed to them, confirms or declines lines, and attaches delivery notes and invoices. It is a supplier-facing surface, not the Customer App | Supplier | Could have | Phase 17 |
3.24. Public Web Presence
The public sites are static and hold no tenant data. They live in their own repositories (viettechno-website, vietgara-help) and are published separately from the product’s web consoles (ADR-013).
| ID | Requirement Name | Description | Actor | Priority | Phase |
|---|
| FR-WEB-01 | Company homepage and product pages | A public homepage for VietTechno with one landing page per product (VietGara first): what it does, features by role, screenshots, plans and prices, stories, a blog, the privacy policy and the terms of use. Vietnamese first, with English | Visitor | Should have | Phase 10 |
| FR-WEB-02 | Contact and demo request | A form with name, garage name, phone, e-mail, message and consent, protected by an anti-spam check. The request is stored and e-mailed to support. The page also shows the phone, Zalo and e-mail contacts | Visitor | Should have | Phase 10 |
| FR-WEB-03 | User guide | A public, searchable how-to guide for garage owners and staff, organized by task, with screenshots refreshed each release. Each web console page and mobile app screen links to its guide page | Visitor, Garage Owner, Staff | Should have | Phase 10 |
| FR-WEB-04 | Contact request endpoint | POST /api/v1/public/contact-requests, called by the website’s server-side function and not by browsers. Validates, rate-limits per source, stores the request and notifies support by e-mail. No other module reads it | External System | Should have | Phase 10 |
4. Traceability Matrix
The table below maps each functional group to its corresponding feature in the Vision & Scope Document and the responsible service in the Software Architecture Document, to help verify consistency across documents.
| Functional Group (FRD) | Corresponding Feature (Vision & Scope) | Responsible Service (SAD) |
|---|
| Identity & Access Management | — | Identity & Access |
| Tenant / Garage Management | — | Tenant/Garage Management |
| License Management | — | License Management |
| Customer & Vehicle Management | — | Customer & Vehicle |
| Quote & Pricing | Quotes & Repair Orders | Quote & Pricing |
| Repair Order | Quotes & Repair Orders | Repair Order |
| Inventory Management | Parts Inventory Management | Inventory |
| Billing & Settlement | Settlement & Receivables | Billing & Settlement |
| Receivables | Settlement & Receivables | Receivables |
| Insurance Integration | Insurance Reconciliation | Insurance Integration |
| Payment Gateway Adapter | Online Payments | Payment Gateway Adapter |
| E-Invoice Service | E-Invoicing | E-Invoice Service |
| Document/Print Service | — | Document/Print Service |
| Notification Service | — | Notification Service |
| Reporting & Analytics | Reporting & Analytics | Reporting & Analytics |
| Customer App | Customer App | Customer BFF + related services |
| Technician App | Technician App | Technician BFF + Repair Order |
| Owner App | Mobile apps | Existing REST API (same as the Owner Web) |
| Admin App | Mobile apps | Existing /admin REST API |
| Platform Analytics | Reporting & Analytics | Platform Analytics (platform-admin read path) |
| Catalogue & Reference Data | Parts Inventory Management | Catalogue (units, parts, jobs) with Inventory |
| Scheduling | Appointment Booking | Booking |
| Suppliers | Parts Inventory Management | Supplier (directory; portal in Phase 17) |
| Public Web Presence | Public website and user guide | viettechno-website, vietgara-help (static sites); Notification (contact request e-mail) |