m-Vehicleshop is a complete dealership ecosystem for FiveM. It is built for two worlds at once: server-run showrooms that feel like official city businesses, and player-owned dealerships that behave like real companies with staff, balances, and rules. Instead of stitching together separate scripts for sales, boss menus, financing, VIP perks, and data moves, you get one coherent product with a modern NUI and a bridge-first design so your stack (framework, keys, inventory, VIP) plugs in instead of fighting the script.
One package: showroom experience, back-office management, analytics, auctions, migrations, and extension points for payments and VIP.
1. Product overview
Think of m-Vehicleshop as the operating system for vehicle retail on your server. You can run many dealerships, each with its own location, categories, and business rules. Some lots can be public; others can be private or faction-locked, so government fleets, MC clubs, or exclusive importers get believable gates without a second resource.
Management is meant to be done in character and in UI: owners and admins work through panels and workflows, not scattered commands. Underneath, a bridge-based architecture means custom integrations (payments, VIP, insurance) stay isolated in adapters instead of forking the core.
2. Core dealership system
Every dealership is a configured place, not a hard-coded map pin. From the admin UI you create, edit, and remove locations and define how they behave.
What you configure at each site:
Main interaction zone · Showroom display · Vehicle spawn · Test drive spawn
Management desk · Used-vehicle buy zone
You choose whether a location is server-owned or player-owned, and you tie categories to each dealership so what can be sold matches the brand (economy cars vs. luxury vs. bikes, and so on). That keeps the world consistent and stops every dealer from selling every spawn code by default.
3. Access and restriction control
Not every player should see every desk. Access can be filtered by jobs and gangs, with multi-select lists and an any / all mode so you can model loose or strict membership.
You can require licenses per dealership when that fits your legal RP. Player-owned businesses get an employee model: owners vs. employees, with permissions that match how real lots split sales floor and back office. Admins can assign ownership using player id or identifier, which matters when fixing mistakes or onboarding a new owner after a story arc.
4. VIP and custom payment flows
VIP can be scoped per dealership, so perks stay premium without breaking public lots. Payments are not limited to cash and bank: the bridge supports items and custom methods registered from adapters, so coin systems, tokens, or partner VIP economies can sit next to normal money.
Dynamic registration of VIP payment paths keeps the UI honest: what the player sees matches what the server will actually accept. Packaged adapters (for example cd_vipshop and m-vipshop) illustrate the pattern so you can mirror the same idea for your own resource.
5. Sales, purchases, and stock
The purchase flow respects dealership stock: you are selling inventory, not infinite magic spawns. Plates are generated from a consistent pattern with uniqueness checks, which reduces duplicate-plate headaches in garages and databases.
Restocking is a first-class idea: a queue models incoming vehicles instead of instant refills. Management can tune stock and price per vehicle, which supports both gameplay (scarcity) and administration (events, sales).
Used vehicles get a full lifecycle: bring a player-owned vehicle into used stock, list or unlist, and control price and status so second-hand lots feel like a real market, not a trash dump for dupes.
6. Test drive and showroom experience
Browsing should feel like a dealership, not a menu. Showroom camera controls and preview spawns let players look before they commit. Test drives use timers and a clear return flow, with bucket or session handling so test drivers do not grief the main world. The goal is immersion with predictable server behavior.
7. Business management features
Player-owned lots need money movement and people management. Society balance supports deposit and withdraw so RP accounting matches the database. Hire and fire flows exist for employees, including nearby-player hiring from the management UI so roleplay stays spatial.
Coupons support fixed or percent discounts, usage caps, and expiry, which is ideal for events or owner promotions. Flash sales add timed windows, so marketing in Discord can match what the script actually enforces.
8. Orders, requests, and auctions
Sometimes the desk says no until a manager says yes. A customer request pipeline gives you approve / reject semantics instead of silent failures.
Auctions for used stock add competition: placement, start and stop, active and history views, and bid metadata so disputes and audits have a trail. That turns rare cars into server moments, not private DMs.
9. Analytics and insights
Leadership needs a dashboard, not a spreadsheet in someone’s head. Analytics support configurable time windows, sales and restock trends, conversion thinking, and vehicle heatmaps so you see what moves and what rots on the lot.
A dealership detail view for admins pulls overview, sales, employees, requests, and used stock into one place, which is what you want when balancing the economy after a wipe or a rule change.
10. Admin experience
Admins get a compact hub with dedicated pages instead of one endless scroll. Create, edit, and drill into a dealership in full-page flows so complex configs do not feel cramped.
Vehicle import and migration screens acknowledge that real servers already have data: the tool meets you where you are instead of asking for a blank slate.
11. Migration and data portability
Switching dealership scripts is historically painful. m-Vehicleshop treats migration as part of the product: bridge adapters and UI-driven flows from admin tools move data from common predecessors (for example jg-dealerships, okokvehicleshop).
Links:
This script was inspired by JG-Dealerships, which explains some of the similar functionalities; however, I in no way intend to diminish the merit of JG’s work.
| Code is accessible | bridge + utils |
| Subscription-based | Yes |
| Lines (approximately) | 15.000 + |
| Requirements | ox_lib |
| Support | Yes |