پلتفرم یکپارچه حمل‌ونقل خودرو کرمان خودرو

معرفی پروژه

این پروژه یک پلتفرم عملیاتی حمل‌ونقل خودرو است که برای ساختار واقعی شرکت‌های حمل طراحی شده؛ یعنی جایی که یک شرکت مادر روی چند شرکت عملیاتی، ناوگان، راننده‌ها، پارکینگ‌های مبدأ، نمایندگی‌های مقصد و هزاران رویداد حمل نظارت دارد. هدف فقط ثبت «فرم حمل» نیست؛ سامانه کل زنجیره‌ی تصمیم‌گیری و تحویل فیزیکی خودرو را به یک جریان دیجیتال، قابل رهگیری و قابل ممیزی تبدیل می‌کند.

نسخه‌ی پایدار 1.6.0 هسته‌ی عملیاتی بازارگاه راننده و تاریخچه سفر را تکمیل کرده و روی قابلیت‌های نسخه‌های قبلی — امنیت چندمستاجری، رهگیری، custody، QR و قفل منابع — بنا شده است. این Case Study دامنه‌ی تحویل‌شده‌ی پروژه را به‌عنوان یک محصول ۱۰۰٪ تکمیل‌شده و عملیاتی مستند می‌کند.

مسئله کسب‌وکار

در حمل خودروی بین‌شهری، چند سیستم و چند نقش باید هم‌زمان روی یک واقعیت فیزیکی توافق داشته باشند: این شاسی الان کجاست؟ چه شرکتی مسئول آن است؟ کدام راننده و کشنده مجازند آن را حمل کنند؟ چه زمانی تحویل گرفته شد؟ آیا در مقصد سالم بوده؟ اگر نمایندگی آن را مرجوع کرد، مسئول پیگیری و مقصد برگشت کجاست؟

وقتی این جریان با تماس تلفنی، اکسل و ثبت‌های پراکنده مدیریت شود، ریسک‌های اصلی عبارت‌اند از:

• تخصیص هم‌زمان یک راننده یا کشنده به چند بار
• نبود زنجیره‌ی روشن تحویل و مسئولیت (Chain of Custody)
• اختلاف بین شرکت مادر، شرکت حمل، راننده، پارکینگ و نمایندگی
• ناپدید شدن اطلاعات GPS در قطعی اینترنت
• نبود سند دقیق برای خسارت، تحویل، مرجوعی و تصمیم مدیریتی
• تأخیر در کشف بارهای آزاد و استفاده ضعیف از ظرفیت ناوگان
• گزارش‌گیری سخت و وابستگی به افراد برای فهم وضعیت واقعی عملیات

KKT این نقاط را در سطح مدل داده، API و ruleهای سمت سرور حل می‌کند؛ نه با اعتبارسنجی ظاهری در مرورگر.

معماری نقش‌ها و حاکمیت عملیاتی

شرکت حمل‌ونقل مادر

در رأس ساختار، یک شرکت مادر وجود دارد که مالک حاکمیت عملیات است. تعریف مدل داده اجازه‌ی چند «شرکت مادر» نمی‌دهد و شرکت‌های عملیاتی باید به همین شرکت بالادستی متصل باشند. تأیید نهایی بار، تصمیم روی درخواست‌های بازارگاه و تصمیم مرجوعی شاسی در این سطح انجام می‌شود.

شرکت‌های حمل عملیاتی

هر شرکت عملیاتی فقط در محدوده‌ی tenant خودش راننده، کشنده، حمل‌ها و درخواست‌های مجاز را می‌بیند. این تفکیک از backend enforce می‌شود تا تغییر URL یا دستکاری frontend باعث دسترسی بین‌شرکتی نشود.

پارکینگ‌ها و پایانه‌های مبدأ

پارکینگ محل نگهداری و تحویل اولیه شاسی است. کاربر پایانه بر اساس EndpointAccess فقط به پارکینگ/شهر/نمایندگی مجاز خودش دسترسی دارد. بارگیری، صدور challenge تحویل و شروع custody از همین نقطه انجام می‌شود.

نمایندگی‌ها و مقصد

نمایندگی مقصد فقط دریافت‌کننده‌ی ساده نیست؛ پنل مستقل برای بارهای در راه، تأیید هر شاسی، ثبت خسارت و درخواست مرجوعی دارد. مرجوعی به یک workflow جدید تبدیل می‌شود و بدون تصمیم شرکت مادر وارد چرخه‌ی برگشت نمی‌شود.

راننده

راننده از اپلیکیشن Native Android استفاده می‌کند: بارهای خودش، بازارگاه، تاریخچه سفر، اسکن QR، وضعیت سفر و رهگیری GPS را در اختیار دارد. در طول custody فعال، رفتار اپ با وضعیت واقعی سرور همگام می‌ماند.

Observer

نقش Observer دید مدیریتی گسترده دارد اما read-only است؛ مناسب مدیران ارشد، بازرسی، کنترل داخلی یا نمایش محصول بدون ریسک تغییر داده.

ماژول‌های اصلی پلتفرم

۱. گردش کار حمل و تأیید شرکت مادر

Shipping دارای وضعیت مستقل Draft، Pending Approval، Approved و Rejected است. شرکت‌های عملیاتی می‌توانند حمل را آماده کنند، اما تأیید نهایی در سطح شرکت مادر باقی می‌ماند. این تفکیک باعث می‌شود سرعت عملیات شعب حفظ شود بدون اینکه کنترل مرکزی از بین برود.

اطلاعات هر حمل شامل مبدأ، مقصد/نمایندگی، شرکت حمل، راننده، کشنده، پیش‌کرایه، بارنامه، زمان‌های گردش کار و مجموعه‌ی شاسی‌های حمل‌شده است.

۲. بازارگاه بار (Marketplace)

بارهای آماده قبل از تخصیص نهایی به MarketplaceLoad تبدیل می‌شوند. شرکت/راننده می‌تواند برای بار درخواست ثبت کند، اما درخواست به معنی تخصیص نیست. MarketplaceClaim تا تصمیم شرکت مادر Pending می‌ماند.

در زمان تأیید، backend به‌صورت transactional دوباره آزاد بودن راننده و کشنده را بررسی می‌کند، منابع را رزرو می‌کند، Shipping نهایی را می‌سازد و درخواست‌های رقیب را رد می‌کند. نتیجه این است که بازارگاه ظرفیت ناوگان را بهتر در معرض تقاضا قرار می‌دهد بدون اینکه حاکمیت شرکت مادر قربانی شود.

۳. قفل سراسری راننده و کشنده

DriverEngagement و TruckEngagement یک محدودیت مهم کسب‌وکار را در دیتابیس مدل می‌کنند: یک راننده یا کشنده تا پایان تحویل مقصد نمی‌تواند هم‌زمان روی حمل دیگری رزرو شود.

این کنترل backend-side است؛ بنابراین حتی اگر validation مرورگر دور زده شود، تخصیص دوگانه انجام نمی‌شود. پس از تحویل نهایی، lockها آزاد و منابع دوباره قابل استفاده می‌شوند.

۴. زنجیره تحویل (Custody) و QR تک‌مصرف

برای عملیات واقعی، وضعیت اداری Shipping از وضعیت custody جدا شده است. QR صرفاً یک تصویر نیست؛ challenge تصادفی کوتاه‌عمر است که:

• به Shipping، نقش، مبدأ/مقصد و action مشخص bind می‌شود
• فقط یک بار قابل مصرف است
• مقدار خام آن در دیتابیس نگهداری نمی‌شود و فقط SHA-256 ذخیره می‌شود
• می‌تواند به geofence پایانه وابسته باشد
• رویدادهای custody به‌صورت audit trail حفظ می‌شوند

پارکینگ QR تحویل مبدأ را صادر می‌کند، راننده pickup را تأیید می‌کند، و در مقصد نمایندگی تحویل نهایی را ثبت می‌کند. با تحویل مقصد، tracking فعال پایان می‌یابد و راننده/کشنده آزاد می‌شوند.

۵. اپلیکیشن Native Android راننده

اپ راننده با Kotlin + Jetpack Compose ساخته شده و یک پوسته وب نیست. جریان اصلی آن شامل سه محور است:

• بارهای من: حمل‌های تخصیص‌یافته و وضعیت جاری
• بازارگاه: مشاهده بارهای باز، کشنده‌های قابل استفاده، مبلغ، تعداد شاسی و وضعیت درخواست
• تاریخچه سفر: سفرهای تکمیل/لغوشده با مقصد، کشنده، تعداد شاسی، خسارت و metadata رهگیری

اپ از Retrofit/OkHttp برای API، DataStore برای session و Room برای صف آفلاین GPS استفاده می‌کند. سرویس Foreground Location در حین سفر فعال می‌ماند تا سیستم‌عامل رهگیری را به‌عنوان کار پس‌زمینه‌ی نامرئی متوقف نکند.

۶. رهگیری زنده و Offline-first GPS

هر نقطه مکان ابتدا با UUID روی گوشی در Room ذخیره می‌شود و سپس batch به backend ارسال می‌شود. اگر شبکه قطع شود، رکورد حذف نمی‌شود؛ بعد از برگشت اینترنت همان recordedAt اصلی ارسال می‌شود و backend با pointId دریافت تکراری را idempotent می‌کند.

این طراحی برای ناوگان بین‌شهری مهم است، چون کیفیت اینترنت در مسیر ثابت نیست. نتیجه این است که تاریخچه مسیر وابسته به «آنلاین بودن لحظه‌ای» نیست.

برای خودرو در حرکت، توقف کوتاه و توقف طولانی policyهای متفاوت وجود دارد تا هم مصرف باتری کنترل شود و هم توقف کامیون به‌اشتباه آفلاین تفسیر نشود.

۷. داشبورد مدیریت رهگیری

مدیر می‌تواند sessionهای فعال، آخرین موقعیت، تاریخچه مسیر و وضعیت راننده/کشنده را ببیند. WebSocket و Channels امکان به‌روزرسانی live را فراهم می‌کنند و scope شرکت روی کانال‌های زنده هم enforce می‌شود.

۸. پنل نمایندگی و تحویل شاسی

پس از رسیدن بار، نمایندگی هر شاسی را جداگانه بررسی می‌کند. شاسی می‌تواند Accepted شود یا وارد Return Requested شود. اطلاعاتی مثل زمان تحویل، تحویل‌گیرنده، موقعیت، وضعیت سالم/خسارت‌دیده، سطح خسارت، علت، توضیح و درجه دو شدن در مدل عملیات ثبت می‌شود.

این تفکیک per-chassis برای حمل خودرو حیاتی است؛ چون یک تریلی ممکن است چند شاسی داشته باشد و وضعیت هر کدام متفاوت باشد.

۹. مرجوعی و Reverse Logistics

مرجوعی یک تغییر flag ساده نیست. درخواست نمایندگی به Ticket متصل می‌شود، توضیح و مستندات دارد و در انتظار تصمیم شرکت مادر قرار می‌گیرد. در صورت تأیید، مقصد برگشت می‌تواند پارکینگ، نمایندگی یا شهر باشد؛ مبدأ پیش‌فرض نیز از زنجیره قبلی قابل استخراج است.

بنابراین reverse logistics بخشی از همان مدل عملیاتی است و تاریخچه رفت/برگشت از هم جدا نمی‌شود.

۱۰. خسارت و پرونده‌های بازرسی

خسارت در سطح ShippingCar ثبت می‌شود و در تاریخچه سفر راننده و گزارش‌های مدیریتی قابل مشاهده است. سطح خسارت، علت، توضیح، وضعیت درجه دو و اطلاعات پرونده/بازرسی در یک مسیر قابل پیگیری قرار می‌گیرند. این ساختار برای اتصال بعدی به فرآیند بیمه، مالی یا کنترل کیفیت آماده است.

۱۱. Inbox، Ticket و ارتباطات سازمانی

سامانه یک Inbox/Ticket داخلی برای پیگیری موارد عملیاتی دارد. Attachmentها با scope tenant کنترل می‌شوند و reply/assignee نیز باید داخل محدوده مجاز گروه/شرکت باشد. درخواست مرجوعی نیز از همین زیرساخت برای ایجاد یک پرونده قابل پیگیری استفاده می‌کند.

۱۲. گزارش‌ها و خروجی‌های مدیریتی

ماژول Reports داده‌ی عملیات را برای تصمیم‌گیری جمع می‌کند: حمل‌ها، راننده‌ها، شاسی‌ها، خسارت، تحویل و وضعیت‌ها. خروجی Excel و گزارش‌های scope‌شده به شرکت کمک می‌کنند به‌جای جمع‌آوری دستی فایل‌ها، از یک منبع داده مشترک استفاده کند.

۱۳. مدیریت داده پایه و ناوگان

راننده، کشنده، خودرو، پارکینگ، مقصد، شهر، علت خسارت و سایر داده‌های پایه در ماژول مستقل نگهداری می‌شوند. این تفکیک باعث می‌شود قوانین عملیاتی روی entityهای پایدار و قابل کنترل اجرا شوند.

۱۴. Backup و زیرساخت عملیاتی

پروژه علاوه بر ماژول‌های کسب‌وکار، Backup Manager و زیرساخت deployment دارد. سرویس‌ها containerized هستند و لایه‌های backend، frontend، realtime/Redis و storage به‌صورت مستقل قابل مدیریت‌اند.

امنیت و تمامیت داده

امنیت پروژه فقط login نیست:

• Browser auth با HttpOnly cookie، access token کوتاه‌عمر و refresh rotation
• Native Android با Bearer token و ذخیره refresh token به‌صورت encrypted
• Cloudflare Turnstile برای login مرورگر و endpoint جداگانه/throttled برای Android
• tenant-aware authorization و جلوگیری از cross-company access
• WebSocket scope بر اساس شرکت
• QR challenge تک‌مصرف و hash‌شده
• قفل راننده/کشنده در backend
• حذف secretها و کلیدهای runtime از repository
• CI gate برای migration drift، backend tests، frontend lint/build و Android build

نقاط قوت مهندسی

قوانین کسب‌وکار در backend

قواعدی مثل «راننده مشغول نباید دوباره تخصیص داده شود»، «شرکت عملیاتی بدون شرکت مادر معتبر نیست» یا «QR فقط در custody درست مصرف شود» در UI رها نشده‌اند و در backend enforce می‌شوند.

جداسازی وضعیت اداری، رهگیری و custody

Approval، GPS Tracking و Physical Custody سه state machine متفاوت‌اند. این جداسازی باعث می‌شود یک مفهوم مبهم «وضعیت حمل» تبدیل به چند وضعیت دقیق و قابل تست شود.

طراحی برای شبکه نامطمئن

اپ راننده offline-first است. نقطه GPS قبل از ارسال روی دستگاه ثبت می‌شود و retry بخشی از طراحی اصلی است، نه patch بعدی.

Auditability

Tracking code خوانا، custody eventها، زمان‌های approval، decisionهای مرجوعی و تاریخچه شاسی همگی امکان بازسازی رخداد را ایجاد می‌کنند؛ ویژگی مهم برای عملیات، بازرسی و حل اختلاف.

معماری چندنقشی واقعی

Admin، Manager، Observer، Driver و کاربران endpoint هر کدام scope متفاوت دارند. UI هم بر اساس نقش workspace مناسب را نشان می‌دهد و backend همان مرزها را enforce می‌کند.

ارزش پلتفرم برای شرکت‌های حمل‌ونقل

ارزش	اثر عملیاتی
کنترل مرکزی با اجرای توزیع‌شده	شرکت مادر سیاست و تأیید را نگه می‌دارد، شعب/شرکت‌های عملیاتی کار روزانه را انجام می‌دهند
جلوگیری از تخصیص دوگانه	کاهش خطای برنامه‌ریزی راننده و کشنده و جلوگیری از تعارض عملیاتی
Marketplace کنترل‌شده	دیده‌شدن بار آزاد برای ظرفیت موجود بدون حذف مرحله تأیید شرکت مادر
Chain of Custody دیجیتال	مشخص بودن مسئولیت از پارکینگ تا راننده و نمایندگی
رهگیری مقاوم به قطعی اینترنت	حفظ تاریخچه مسیر حتی در جاده‌های با پوشش ضعیف
تحویل per-chassis	ثبت دقیق وضعیت هر خودرو به‌جای یک تأیید کلی برای کل تریلی
Reverse Logistics ساخت‌یافته	مرجوعی، مقصد برگشت و تصمیم مدیریتی در همان سیستم نگهداری می‌شود
داده واحد برای گزارش	کاهش وابستگی به اکسل‌های پراکنده و تماس تلفنی برای فهم وضعیت
Observer read-only	امکان نظارت مدیر/بازرس بدون ریسک تغییر اطلاعات
API + Web + Android	پوشش هم‌زمان دفتر، پایانه، نمایندگی و راننده در جاده

این اثرها قابلیت‌های طراحی‌شده‌ی پلتفرم هستند؛ سنجش عددی ROI، کاهش زمان یا کاهش هزینه نیازمند داده عملیاتی واقعی هر شرکت است.

تکنولوژی و معماری

Backend: Django 5، Django REST Framework، SimpleJWT، Channels، Redis، Celery، SQL Server، Object Storage، OpenAPI

Frontend: Next.js 16، React 19، TypeScript، Redux Toolkit، Tailwind CSS، PWA

Android: Kotlin، Jetpack Compose، Retrofit/OkHttp، Room، DataStore، Fused Location Provider، Foreground Service

Infrastructure: Docker، Nginx، Redis، CI/CD، Cloudflare Turnstile، object storage

کیفیت و تست

نسخه‌های 1.3 تا 1.6 همراه با regression coverage برای tenant scope، authentication، WebSocket، workflow تأیید، engagement locks، QR single-use، جلوگیری از replay، تحویل مقصد، آزادسازی منابع، بازارگاه و trip history توسعه یافته‌اند. قبل از release 1.6، backend، frontend و Android به‌صورت مشترک از CI عبور کرده‌اند.

نتیجه نهایی

KKT یک نرم‌افزار فرم‌محور ساده نیست؛ یک سیستم عملیات حمل‌ونقل و کنترل زنجیره تحویل خودرو است که نقش‌های سازمانی، تصمیم مدیریتی، منابع فیزیکی، GPS، QR و فرآیند نمایندگی را در یک مدل واحد قرار می‌دهد.

دامنه‌ی تعریف‌شده‌ی این پروژه تکمیل شده است: وضعیت نمونه‌کار Completed — پیشرفت 100٪. نسخه پایدار مبنای این Case Study، 1.6.0 است و محصول برای استقرار سازمانی، تست میدانی و توسعه‌ی نسخه‌های بعدی روی همین هسته آماده است.