3.1 - التسجيل في المنصة

3.1.1 المعلومات العامة

العنوان التفاصيل
أهداف العمل
  • التأكد من أن كل مستخدم للمنصة قادر على تقديم الخدمة أو طلب الخدمة بطريقة آمنة وفعالة
  • ضمان أن المعلومات المقدمة من المستخدمين صحيحة وحديثة
الجهات المعنية
  • المستخدمون (العملاء، مقدمو الخدمات)
  • إداريي النظام
الخطوات الرئيسية
  • المستخدم الجديد يقوم بالتسجيل في النظام عن طريق ادخال بياناته
  • يقوم المستخدم بالقراءة والموافقة على شروط الخدمة وسياسة الخصوصية
  • المستخدم يقوم بتوثيق رقم هاتفه عن طريق رسالة OTP (اختياري لاداري النظام أن تكون من خلال منصات موثوقة مثل نفاذ)
  • المستخدم يقوم بتقديم وثائق تعريفية بناء على طبيعة استخدامه للمنصة
  • المستخدم يتلقى إشعارات النظام (أو البريد في حالة استخدامه) تحتوي على تحديث حالة التسجيل (مقبول، مرفوض وسبب الرفض)
الخطوات البديلة
  • إذا تم رفض حساب المستخدم، المستخدم يمكنه المراجعة والتعديل وإعادة تقديم الطلب
قصص المستخدمين
  • كمستخدم عميل، أريد أن أقوم بالتسجيل في التطبيق بسرعة وسهولة حتى أتمكن من البدء في استخدام المنصة ، من أجل استخدام الخدمات المتوفرة
  • كمقدم خدمة أريد أن أقوم بالتسجيل في التطبيق، من أجل عرض خدماتي و الحصول على فرص عمل جديدة وبناء شراكات
  • كمستخدم، أنا بحاجة لتوثيق رقم الهاتف الخاص بي لضمان أمان حسابي
  • كمستخدم، أنا بحاجة لتقديم وثائق تحقيق الشخصية الخاصة بي للتأكد من اعتمادي من النظام
  • موظف إداري في المنصة، أرغب في تلقي إشعارات عند تسجيل مستخدم جديد أو مقدم خدمة جديد حتى أتمكن من فحص وثائقهم والتحقق منها للتأكد من التزام المنصة بمعايير الجودة والسلامة
  • موظف إداري في المنصة، يحتاج إلى مراجعة طلبات الالتحاق, مراجعتها إما القبول أو وضع سبب الرفض
  • كمستخدم، أريد تلقي تحديثات حول حالة طلب التسجيل الخاص بي، من أجل معرفة ما إذا كان مقبولًا أم مرفوضًا أم في انتظار المراجعة
مؤشرات الأداء
  • عدد المسجلين مع تصنيف الفئات (تاجر، ناقل، وسيط....../ تسجيل مقبول، تسجيل مرفوض، إعادة تسجيل....)
  • الفترة الزمنية للتسجيل

3.1.2 حالات الاستخدام

3.1.2.1- المستخدم الجديد يقوم بالتسجيل في النظام عن طريق إدخال بياناته الشخصية وإنشاء حساب جديد

graph LR A[User opens registration page] --> B[User enters personal details] B --> C[User checks the I agree checkbox] C --> D[User clicks Register] D --> E[System validates data] E --> F[System creates new account]
العنوانالتفاصيل
المستخدمالمستخدم (العميل أو مقدم الخدمة)
الشروط المسبقة
  • المستخدم غير مسجل سابقًا في النظام
الشروط اللاحقة
  • المستخدم يكون لديه حساب جديد في النظام
تسلسل الأحداث
  • المستخدم يفتح صفحة التسجيل
  • المستخدم يدخل البيانات الشخصية المطلوبة
  • المستخدم يقرأ سياسة الخصوصية ويوافق عليها
  • المستخدم ينقر على زر 'تسجيل'
  • النظام يتحقق من صحة البيانات
  • النظام ينشئ حسابًا جديدًا للمستخدم
الخطوات البديلةإذا كانت البيانات المدخلة غير صحيحة
  • النظام يعرض رسالة خطأ توضح البيانات غير الصحيحة
  • المستخدم يعدل البيانات المدخلة
  • النقر على زر 'تسجيل' مرة أخرى
الخطوات الاستثنائيةإذا كان المستخدم مسجل مسبقًا
  • النظام يعرض رسالة تفيد بأن البريد الإلكتروني أو رقم الهاتف مستخدم مسبقًا
  • المستخدم يمكنه استخدام خيار 'نسيت كلمة المرور' لاستعادة الوصول إلى الحساب
القواعد التجارية
  • يجب أن تكون كلمة المرور قوية (تحتوي على حروف وأرقام ورموز)
الافتراضات
  • المستخدم (الناقل ) يمتلك رقم هاتف صالح
  • باقي المستخدمين يمتلكون رقم هاتف وبريد الكتروني صالحين
المدخلاتالاسم | البريد الإلكتروني | رقم الهاتف | كلمة المرور | الموافقة على سياسة الخصوصية |
سيناريوهات الاستخدام
  • كمستخدم جديد، أرغب في إنشاء حساب على النظام حتى أتمكن من استخدام الخدمات المتاحة
متطلبات الأمان
  • يجب التحقق من صحة البريد الإلكتروني ورقم الهاتف لتجنب التسجيلات الزائفة
متطلبات الاختبار
  • اختبارات وظيفية للتحقق من إنشاء الحساب بنجاح
  • اختبارات الأمان للتحقق من قوة كلمة المرور وصحة البيانات المدخلة
تفاصيل ال API
Method: POST || Endpoint: /api/user/register
Request Headers
Content-Type: application/json

Request Body

name: نص email: نص phone: نص password: نص acceptedTerms: boolean

Response

الحالةالمحتوى
200userId: نص message: تم تسجيل المستخدم بنجاح
الوصف: Success
400
الوصف: Bad Request
5343werwerwer
الوصف: werewr

تفاصيل الواجهات
شاشة التسجيل

  • form
    • text
      • العنوان : الاسم
      • التحقق : required
    • email
      • العنوان : البريد الإلكتروني
      • التحقق : required|^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$
    • text
      • العنوان : الهاتف
      • التحقق : required|/^(009665|9665|\+9665|05|5)5|0|3|6|4|9|1|8|7)([0-9]{7})$/
    • password
      • العنوان : كلمة المرور
      • التحقق : required|min:8|contains:letters,numbers
    • checkbox
      • العنوان : أوافق على الشروط والأحكام
  • رسالة زر الإرسال: Register
  • رسالة النجاح: تم التسجيل بنجاح
  • إعادة توجيه النجاح: شاشة تسجيل الدخول
الاشعارات

العنوان : تم التسجيل بنجاح
الرسالة : لقد تم إنشاء حسابك بنجاح. مرحبا بكم في منصتنا!
عن طريق : الهاتف ,الايميل  المستقبل : المستخدم

العنوان : تم التسجيل بنجاح
الرسالة : لقد تم إنشاء حسابك بنجاح. مرحبا بكم في منصتنا!
عن طريق : الهاتف  المستقبل : الناقل

3.1.2.2- المستخدم يقوم بتوثيق رقم هاتفه عن طريق رسالة OTP (اختياري لإداري النظام أن تكون من خلال منصات موثوقة مثل نفاذ)

graph LR A[User opens phone verification page] --> B[User enters phone number] B --> C[User clicks 'Send OTP'] C --> D[User receives OTP] D --> E[User enters OTP] E --> F[User clicks 'Verify'] F --> G[Phone verified successfully]
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • إكمال خطوات التسجيل السابقة
  • فتح صفحة توثيق رقم الهاتف
الشروط اللاحقة
  • تم توثيق رقم الهاتف بنجاح
تسلسل الأحداث
  • المستخدم يفتح صفحة توثيق رقم الهاتف
  • إدخال رقم الهاتف
  • النقر على زر 'إرسال رمز التحقق'
  • استلام رسالة OTP على الهاتف المدخل
  • إدخال رمز OTP في الحقل المخصص
  • النقر على زر 'تحقق'
الخطوات البديلةإذا لم يستلم المستخدم رسالة OTP
  • النقر على زر 'إعادة إرسال الرمز'
  • استلام رمز OTP جديد
  • إدخال الرمز الجديد في الحقل المخصص
  • النقر على زر 'تحقق'
الخطوات الاستثنائيةإذا أدخل المستخدم رمز OTP غير صحيح
  • النظام يعرض رسالة خطأ تطلب إدخال الرمز الصحيح
  • إعادة إدخال رمز OTP صحيح
  • النقر على زر 'تحقق' مرة أخرى
الافتراضات
  • المستخدم يمتلك رقم هاتف صالح ويستطيع استلام رسائل OTP
المدخلاترقم الهاتف | رمز OTP |
سيناريوهات الاستخدام
  • كمستخدم جديد، أرغب في توثيق رقم هاتفي لضمان أمان حسابي
متطلبات الأمان
  • يجب التحقق من صحة رمز OTP لضمان توثيق رقم الهاتف بشكل صحيح
التكامل مع الأنظمة الأخرى
  • منصة نفاذ لتوثيق رقم الهاتف
متطلبات الاختبار
  • اختبارات وظيفية للتحقق من عملية إرسال واستلام رمز OTP
  • اختبارات الأمان للتحقق من صحة رمز OTP المدخل
تفاصيل ال API
Method: POST || Endpoint: /api/user/verify-phone
Request Headers
Content-Type: application/json

Request Body

phoneNumber: نص

Response

الحالةالمحتوى
200status: نص message: تم إرسال رمز التحقق بنجاح
الوصف: Success
400
الوصف: Bad Request

Method: POST || Endpoint: /api/user/confirm-otp
Request Headers
Content-Type: application/json

Request Body

phoneNumber: نص otp: نص

Response

الحالةالمحتوى
200status: نص message: تم التحقق من الهاتف بنجاح
الوصف: Success
400
الوصف: Invalid OTP

تفاصيل الواجهات
شاشة التحقق من الهاتف

  • form
    • text
      • العنوان : رقم الهاتف
      • التحقق : required|phone
    • text
      • العنوان : رمز التحقق
      • التحقق : required
  • رسالة زر الإرسال: Verify
  • رسالة النجاح: تم التحقق من الهاتف بنجاح
  • إعادة توجيه النجاح: NextRegistrationStep
الاشعارات

العنوان : رمز التحقق الخاص بك هو: {code}
الرسالة : رمز التحقق الخاص بك هو: {code}
عن طريق : SMS  المستقبل : المستخدم

3.1.2.3- المستخدم يقوم بتقديم وثائق تعريفية بناء على طبيعة استخدامه للمنصة

graph LR A[Upload Documents] --> B[Verify Documents] B --> C[Verification Successful] B --> D[Verification Failed] C --> E[Notify User of Success] D --> F[Notify User of Failure]
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • إكمال خطوات التسجيل السابقة
  • توافر الوثائق المطلوبة
الشروط اللاحقة
  • تم تحميل الوثائق المطلوبة
تسلسل الأحداث
  • النظام يطلب تحميل وثائق تعريفية
  • المستخدم يقوم بتحميل الوثائق التعريفية
  • النظام يتحقق من صحة المستندات
الخطوات البديلةإذا كان هناك خطأ في مستند
  • النظام يرسل رسالة بالخطأ للمستخدم
  • المستخدم يقوم بإعادة تحميل الوثائق المطلوبة
  • النظام يتحقق من الوثائق مرة أخرى
الافتراضات
  • المستخدم يمتلك الوثائق اللازمة
المدخلاتالوثائق التعريفية |
المخرجات
  • حالة التحقق
تفاعلات المستخدم
  • رفع المستندات عبر النظام
  • تلقي اشعارا بحالة التحقق
الشروط الخاصة
  • يجب أن تكون المستندات واضحة للقراءة
سيناريوهات الاستخدام
  • كمستخدم جديد، أرغب في تحميل الوثائق الخاصة بشكل صحيح
متطلبات الأمان
  • يجب تأمين جميع المستندات المرفوعة وحمايتها من الوصول غير المصرح به
التكامل مع الأنظمة الأخرى
  • النظام يجب أن يكون متكاملاً مع قواعد البيانات الحكومية للتحقق من صحة المستندات
القيود والافتراضات
  • النظام يجب أن يدعم رفع المستندات بصيغ وأحجام مختلفة
متطلبات الاختبار
  • اختبارات وظيفية للتحقق من عملية إرسال واستلام المستندات
  • اختبارات الأمان للتحقق من صحة المستندات المحملة
تفاصيل ال API
Method: POST || Endpoint: /api/user/upload-documents
Request Headers
Content-Type": multipart/form-data

Request Body

userId: نص documents: array

Response

الحالةالمحتوى
200Documents uploaded successfully
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة التحقق من المستندات

  • textblock
    • Please upload your verification documents

  • form
    • file
      • العنوان : document
      • التحقق : required: true error_message: Please upload the required documents
  • رسالة زر الإرسال: Upload Documents
  • textblock
    • Your documents are being verified. Please wait...

  • textblock
    • Document verification status will be displayed here.

الاشعارات

العنوان : التحقق من الوثائق التعريفية
الرسالة : Your document verification status: {status}
عن طريق : ايميل  المستقبل : المستخدم

3.1.2.4- المستخدم يتلقى إشعارات النظام تحتوي على تحديث حالة التسجيل سواء كان مقبولًا أو مرفوضًا مع سبب الرفض إذا كان متاحًا

graph LR A[Complete registration steps] --> B[System reviews registration documents] B --> C[System sends registration status notification] C --> D[User receives notification and follows instructions]
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • إكمال جميع خطوات التسجيل السابقة
الشروط اللاحقة
  • تم إشعار المستخدم بحالة التسجيل
تسلسل الأحداث
  • النظام يراجع وثائق التسجيل
  • النظام يرسل إشعارًا للمستخدم بحالة التسجيل
  • المستخدم يتلقى الإشعار ويتابع التعليمات المناسبة
الافتراضات
  • النظام يقوم بمراجعة الوثائق في وقت مناسب
سيناريوهات الاستخدام
  • كمستخدم، أرغب في تلقي إشعار بحالة تسجيل حسابي لمعرفة ما إذا كان قد تم قبوله أو رفضه وما هي الخطوات التالية
متطلبات الاختبار
  • اختبارات وظيفية للتحقق من إرسال واستلام الإشعارات بحالة التسجيل
  • اختبارات للتحقق من ظهور سبب الرفض في الإشعارات في حال وجوده
تفاصيل ال API
Method: POST || Endpoint: /api/user/registration-status
Request Headers
Content-Type: application/json

Request Body

userId: نص status: نص rejectionReason: نص

Response

الحالةالمحتوى
200status: نص message: تم إرسال الإشعار بنجاح
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة حالة التسجيل

  • textblock
    • Your registration status will be updated here

الاشعارات

العنوان : تحديث حالة التسجيل
الرسالة : تم تسجيلك {status}. {rejectionReason}
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : المستخدم

3.1.2.5- إذا تم رفض حساب المستخدم، يمكنه المراجعة والتعديل وإعادة تقديم الطلب

graph LR A[Receive rejection notification] --> B[Read rejection reason] B --> C[Update required data] C --> D[Resubmit registration]
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • استلام إشعار برفض الحساب
  • توافر سبب الرفض
الشروط اللاحقة
  • إعادة تقديم طلب التسجيل بعد التعديل
تسلسل الأحداث
  • استلام إشعار برفض الحساب
  • قراءة سبب الرفض
  • تعديل البيانات أو الوثائق المطلوبة
  • إعادة تقديم طلب التسجيل
الافتراضات
  • المستخدم يمكنه تعديل البيانات أو الوثائق المطلوبة
سيناريوهات الاستخدام
  • كمستخدم، أرغب في إعادة تقديم طلب التسجيل بعد تعديله لضمان قبولي في النظام
متطلبات الاختبار
  • اختبارات وظيفية للتحقق من عملية إعادة التقديم بعد التعديل
تفاصيل ال API
Method: POST || Endpoint: /api/user/resubmit-registration
Request Headers
Authorization: Bearer token Content-Type: application/json

Request Body

userId: نص updatedData: object

Response

الحالةالمحتوى
200status: نص message: تم إعادة تقديم التسجيل بنجاح
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة إعادة تقديم التسجيل

  • form
    • text
      • العنوان : تم تحديث البيانات
      • التحقق : required
  • رسالة زر الإرسال: Resubmit
  • رسالة النجاح: تم إعادة تقديم التسجيل بنجاح
  • إعادة توجيه النجاح: شاشة حالة التسجيل

3.2 - الإشعارات

3.2.1 المعلومات العامة

العنوان التفاصيل
أهداف العمل
  • للتأكيد على أن كافة المستخدمين، بغض النظر عن الدور، يتلقون الإشعارات ذات الصلة بنشاطهم في النظام ولتحسين سهولة الاستخدام وتجربة المستخدم
الجهات المعنية
  • إداريي النظام
  • المستخدمون (مقدمو الخدمات والعملاء)
الخطوات الرئيسية
  • تلقي الإشعارات الداخلية في لوحة التحكم للإداريين
  • تلقي الإشعارات الخارجية عبر البريد الإلكتروني أو الإشعارات push notification
  • تلقي الإشعارات الداخلية في مركز الإشعارات بالتطبيق للمستخدمين
  • إعدادات الإشعارات التي تسمح للمستخدمين بتفعيل/تعطيل أنواع محددة من الإشعارات
  • إعدادات الإشعارات التي تسمح للمستخدمين بتحديد طريقة استلام الإشعارات
الخطوات البديلة
  • تعطيل الإشعارات
  • تغيير طرق تلقي الإشعارات
قصص المستخدمين
  • مدير النظام: يجب أن يحصل على إشعار داخلي عند حدوث حدث معين يتطلب انتباهه
  • مقدم الخدمة: يجب أن يتلقى إشعارًا عند استلام طلب جديد للخدمة، أو رسالة جديدة، تحديث في حالة خدمة
  • العميل: يجب أن يحصل على إشعار عندما يقوم مقدم الخدمة بتغييرات مهمة في الطلب مثل قبول الطلب، أو تغيير الحالة، أو إرسال رسالة جديدة
  • العميل و مقدم الخدمة: يجب أن يحصلوا على إشعار دعائي عند تقديم عروض جديدة أو خدمات أو تحديثات في النظام
مؤشرات الأداء
  • عدد الاشعارات المرسلة مع التصنيف حسب نوع المستخدم

3.2.2 حالات الاستخدام

3.2.2.1- تلقي الإشعارات الداخلية في لوحة التحكم للإداريين، مما يسمح لهم بالبقاء على اطلاع دائم بالأحداث والأنشطة المهمة داخل النظام

graph LR; A[بدء] -->|حدوث نشاط أو حدث| B[إرسال إشعار إلى لوحة التحكم]; B --> C[عرض الإشعار في لوحة التحكم]; C --> D[الإداري يتخذ الإجراءات اللازمة]; D --> E[نهاية];
العنوانالتفاصيل
المستخدمإداري النظام
الشروط المسبقة
  • وجود أحداث أو أنشطة تحتاج إلى إشعار الإداري
الشروط اللاحقة
  • إشعار الإداري بالأحداث المهمة
تسلسل الأحداث
  • حدوث نشاط أو حدث في النظام
  • إرسال إشعار إلى لوحة التحكم
  • عرض الإشعار في لوحة التحكم
الخطوات البديلةالإداري يرغب في تعطيل الإشعارات لفترة معينة
  • الإداري يدخل إلى إعدادات الإشعارات
  • الإداري يعطل الإشعارات للفترة المطلوبة
  • النظام يحفظ التغييرات ويوقف الإشعارات خلال الفترة المحددة
الخطوات الاستثنائيةفشل في إرسال الإشعار
  • النظام يعيد محاولة إرسال الإشعار
  • إذا استمر الفشل، يعرض رسالة خطأ للإداري ويقوم بتسجيل المشكلة
القواعد التجارية
  • يجب أن يكون جميع الإشعارات ذات الصلة دقيقة وفي الوقت المناسب
  • يجب على النظام تسجيل جميع الإشعارات المرسلة وأي فشل في الإرسال
الافتراضات
  • النظام قادر على اكتشاف الأنشطة المهمة وتوليد الإشعارات بشكل تلقائي
  • الإداري يستخدم لوحة التحكم بشكل منتظم
المتطلبات الخاصة
  • يجب أن تكون واجهة المستخدم في لوحة التحكم سهلة الاستخدام وفعالة في عرض الإشعارات
  • يجب أن يدعم النظام تسجيل ومراجعة تاريخ الإشعارات
الملاحظات والمشاكل
  • يجب اختبار جميع أنواع الإشعارات لضمان عملها بشكل صحيح
  • يجب معالجة أي مشكلات تقنية تتعلق بفشل إرسال الإشعارات بسرعة
المدخلاتبيانات النشاط أو الحدث الذي يتطلب الإشعار |
المخرجات
  • إشعار معروض في لوحة التحكم للإداري
تفاعلات المستخدم
  • الإداري يتفاعل مع الإشعار في لوحة التحكم لاتخاذ الإجراءات اللازمة
الشروط الخاصة
  • في حالة تعطل النظام، يجب على الإداري تلقي إشعار عبر البريد الإلكتروني أو وسائل أخرى بديلة
سيناريوهات الاستخدام
  • الإداري يتلقى إشعار عند حدوث نشاط مريب يتطلب التدخل الفوري
  • الإداري يتلقى إشعار بخصوص تحديثات النظام أو الصيانة المجدولة
متطلبات الأمان
  • يجب تشفير جميع بيانات الإشعارات لضمان الأمان
  • يجب أن تكون الإشعارات مرئية فقط للإداريين المخولين
التكامل مع الأنظمة الأخرى
  • يجب أن يتم تنسيق الإشعارات مع أنظمة المراقبة الأمنية الداخلية إن وجدت
القيود والافتراضات
  • النظام يجب أن يدعم كافة أنواع الإشعارات المطلوبة
  • يجب أن تكون عملية إرسال الإشعارات فورية ودقيقة
متطلبات الاختبار
  • يجب اختبار قدرة النظام على اكتشاف الأنشطة المهمة وإرسال الإشعارات بشكل صحيح
  • يجب التحقق من أن جميع الإشعارات تصل إلى لوحة التحكم وتعرض بشكل صحيح
تفاصيل ال API
Method: POST || Endpoint: /api/v1/admin/notifications
Request Headers
Authorization: Bearer token

Request Body

event_type: نص event_details: نص

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

Method: GET || Endpoint: /api/v1/admin/notifications
Request Headers
Authorization: Bearer token

Request Body

Response

الحالةالمحتوى
200notifications: array
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
لوحة التحكم الإدارية

  • textblock
    • لوحة التحكم

  • list
    • النوع : إشعار 1: حدث مهم في النظام

    • النوع : إشعار 2: تحديث النظام المجدول

الاشعارات

العنوان : إشعار جديد في النظام
الرسالة : حدث جديد يتطلب انتباهك. يرجى مراجعة لوحة التحكم
عن طريق : الاشعارات داخل التطبيق, ايميل  المستقبل : إداري النظام

3.2.2.2- تلقي الإشعارات الخارجية عبر البريد الإلكتروني أو الإشعارات push notification لضمان بقاء المستخدمين مطلعين على الأنشطة والأحداث المهمة في النظام بشكل فوري

graph LR;A[حدوث نشاط أو حدث في النظام] --> B[تحديد نوع الإشعار المناسب];B --> C[إرسال الإشعار];C --> D[تلقي المستخدم للإشعار];D --> E[مراجعة المستخدم للإشعار];
العنوانالتفاصيل
المستخدمالمستخدم (العميل أو مقدم الخدمة)
الشروط المسبقة
  • إعداد البريد الإلكتروني بشكل صحيح
  • تمكين الإشعارات push notification من إعدادات التطبيق
الشروط اللاحقة
  • تلقى المستخدم إشعارًا بالبريد الإلكتروني أو push notification
  • المستخدم مطلع على الأحداث أو الأنشطة التي تتطلب انتباهه
تسلسل الأحداث
  • حدوث نشاط أو حدث في النظام
  • تحديد نوع الإشعار المناسب
  • إرسال الإشعار
  • تلقي المستخدم للإشعار
  • مراجعة المستخدم للإشعار
الخطوات البديلةالمستخدم لم يتلق الإشعار
  • المستخدم يتأكد من إعدادات البريد الإلكتروني وإعدادات الإشعاراتpush notification
  • النظام يعيد إرسال الإشعار
الخطوات الاستثنائيةفشل في إرسال الإشعار
  • النظام يسجل خطأ في الإرسال
  • النظام يحاول إعادة الإرسال بعد فترة زمنية محددة
  • إذا استمر الفشل، يتم إبلاغ فريق الدعم الفني
القواعد التجارية
  • يجب إرسال الإشعارات بشكل فوري لضمان اطلاع المستخدم على الأحداث المهمة
الافتراضات
  • المستخدم قد قام بتمكين إعدادات البريد الإلكتروني وإشعارات push notification في التطبيق
  • النظام يمكنه الاتصال بخوادم الإشعارات الخارجية
المتطلبات الخاصة
  • الإشعارات يجب أن تكون مختصرة وواضحة
  • تقديم روابط مباشرة للمستخدمين للوصول إلى التفاصيل في التطبيق
الملاحظات والمشاكل
  • قد يواجه بعض المستخدمين تأخر في استلام الإشعارات بسبب مشاكل في الاتصال
  • يجب اختبار جميع الإشعارات بشكل دوري لضمان عملها بشكل صحيح
المدخلاتنوع النشاط أو الحدث | معلومات المستخدم (البريد الإلكتروني، إعدادات الإشعارات) |
المخرجات
  • إشعار بالبريد الإلكتروني أو push notification
تفاعلات المستخدم
  • تلقي الإشعار
  • مراجعة تفاصيل النشاط أو الحدث
الشروط الخاصة
  • عدم وصول الإشعار للمستخدم بسبب مشاكل تقنية
  • تأخر في استلام الإشعار
سيناريوهات الاستخدام
  • تلقي المستخدم إشعار بوجود رسالة جديدة في التطبيق
  • تلقي إشعار بتحديث حالة طلب
  • تلقي إشعار بوجود عرض جديد
متطلبات الأمان
  • تأمين بيانات المستخدمين المرسلة عبر البريد الإلكتروني
  • ضمان عدم إرسال إشعارات إلى الأطراف غير المصرح بها
التكامل مع الأنظمة الأخرى
  • نظام البريد الإلكتروني الخارجي
  • نظام push notification الخارجي
القيود والافتراضات
  • يجب أن يكون لدى المستخدم اتصال إنترنت فعال لتلقي الإشعارات
  • يجب أن تكون خوادم الإشعارات الخارجية متاحة
متطلبات الاختبار
  • اختبار إرسال واستلام الإشعارات بشكل دوري
  • اختبار إعدادات الإشعارات المختلفة في التطبيق
تفاصيل ال API
Method: POST || Endpoint: /sendNotification
Request Headers
Authorization: Bearer token Content-Type: application/json

Request Body

user_id: نص notification_type: نص message: نص

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
إعدادات الإشعارات

  • textblock
    • إعدادات الإشعارات

  • form
    • Checkbox
      • العنوان : تمكين إشعارات البريد الإلكتروني
    • Checkbox
      • العنوان : تمكين إشعارات Push
    • Button
      • العنوان : حفظ الإعدادات
      • الخيارات : saveNotificationSettings
الاشعارات

العنوان : تنبيه جديد
الرسالة : لديك تنبيه جديد في نظامنا
عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : المستخدم

3.2.2.3- تلقي الإشعارات الداخلية في مركز الإشعارات بالتطبيق للمستخدمين لضمان وصولهم الفوري للمعلومات الهامة المتعلقة بأنشطتهم داخل التطبيق

graph LR;A[حدوث نشاط أو حدث في النظام] --> B[تحديد أن الإشعار داخلي];B --> C[إرسال الإشعار إلى مركز الإشعارات];C --> D[ظهور الإشعار في مركز الإشعارات];D --> E[مراجعة المستخدم للإشعار];
العنوانالتفاصيل
المستخدمالمستخدم (العميل أو مقدم الخدمة)
الشروط المسبقة
  • تسجيل الدخول في التطبيق
الشروط اللاحقة
  • ظهور الإشعار في مركز الإشعارات بالتطبيق
  • تمكن المستخدم من الاطلاع على المعلومات الهامة المتعلقة بالحدث أو النشاط
تسلسل الأحداث
  • حدوث نشاط أو حدث في النظام
  • تحديد أن الإشعار داخلي
  • إرسال الإشعار إلى مركز الإشعارات
  • ظهور الإشعار في مركز الإشعارات
  • مراجعة المستخدم للإشعار
الخطوات البديلةالمستخدم لم يتلق الإشعار في مركز الإشعارات
  • المستخدم يتأكد من تسجيل الدخول الصحيح في التطبيق
  • النظام يتحقق من إعدادات الإشعارات الداخلية
  • إعادة إرسال الإشعار إلى مركز الإشعارات
الخطوات الاستثنائيةفشل في إرسال الإشعار إلى مركز الإشعارات
  • النظام يسجل خطأ في إرسال الإشعار
  • النظام يحاول إعادة الإرسال بعد فترة زمنية محددة
  • إذا استمر الفشل، يتم إبلاغ فريق الدعم الفني لاتخاذ الإجراء اللازم
القواعد التجارية
  • يجب إرسال الإشعارات بشكل فوري إلى مركز الإشعارات لضمان اطلاع المستخدم على الأحداث الهامة
الافتراضات
  • المستخدم قد قام بتسجيل الدخول إلى التطبيق
  • النظام يمكنه الاتصال بخوادم الإشعارات الداخلية
المتطلبات الخاصة
  • الإشعارات يجب أن تكون مختصرة وواضحة
  • تقديم روابط مباشرة للمستخدمين للوصول إلى التفاصيل في التطبيق
الملاحظات والمشاكل
  • قد يواجه بعض المستخدمين تأخر في استلام الإشعارات بسبب مشاكل في الاتصال
  • يجب اختبار جميع الإشعارات بشكل دوري لضمان عملها بشكل صحيح
المدخلاتنوع النشاط أو الحدث | معلومات المستخدم (تسجيل الدخول، إعدادات الإشعارات) |
المخرجات
  • إشعار في مركز الإشعارات
تفاعلات المستخدم
  • تلقي الإشعار
  • مراجعة تفاصيل النشاط أو الحدث
الشروط الخاصة
  • عدم وصول الإشعار للمستخدم بسبب مشاكل تقنية
  • تأخر في استلام الإشعار
سيناريوهات الاستخدام
  • تلقي المستخدم إشعار بوجود رسالة جديدة في التطبيق
  • تلقي إشعار بتحديث حالة طلب
  • تلقي إشعار بوجود عرض جديد
متطلبات الأمان
  • تأمين بيانات المستخدمين المرسلة عبر مركز الإشعارات
  • ضمان عدم إرسال إشعارات إلى الأطراف غير المصرح بها
التكامل مع الأنظمة الأخرى
  • نظام إدارة الإشعارات الداخلية
  • نظام التوثيق وتسجيل الدخول
القيود والافتراضات
  • يجب أن يكون لدى المستخدم اتصال إنترنت فعال لتلقي الإشعارات
  • يجب أن تكون خوادم الإشعارات الداخلية متاحة
متطلبات الاختبار
  • اختبار إرسال واستلام الإشعارات بشكل دوري
  • اختبار إعدادات الإشعارات المختلفة في التطبيق
تفاصيل ال API
Method: POST || Endpoint: /sendInternalNotification
Request Headers
Authorization: Bearer token Content-Type: application/json

Request Body

user_id: نص notification_type: نص message: نص

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
مركز الإشعارات

  • textblock
    • مركز الإشعارات

  • list
    • النوع : id: notification-list Items :

  • form
    • Button
      • العنوان : تحديث
      • الخيارات : refreshNotifications
الاشعارات

العنوان : تنبيه جديد
الرسالة : لديك تنبيه جديد في مركز الإشعارات
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : المستخدم

3.2.2.4- إعدادات الإشعارات التي تسمح للمستخدمين بتفعيل/تعطيل أنواع محددة من الإشعارات لضمان وصول المعلومات المناسبة فقط للمستخدمين حسب تفضيلاتهم

graph LR;A[فتح إعدادات الإشعارات] --> B[اختيار التفضيلات];B --> C[حفظ التفضيلات];C --> D[تحديث النظام بناءً على التفضيلات الجديدة];
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • الوصول إلى إعدادات الإشعارات في التطبيق
الشروط اللاحقة
  • تحديث تفضيلات الإشعارات الخاصة بالمستخدم
  • تفعيل أو تعطيل أنواع محددة من الإشعارات بناءً على تفضيلات المستخدم
تسلسل الأحداث
  • فتح إعدادات الإشعارات
  • اختيار التفضيلات
  • حفظ التفضيلات
  • تحديث النظام بناءً على التفضيلات الجديدة
الخطوات البديلةفشل حفظ التفضيلات
  • النظام يعرض رسالة خطأ للمستخدم
  • المستخدم يحاول حفظ التفضيلات مرة أخرى
الخطوات الاستثنائيةانقطاع الاتصال بالإنترنت
  • النظام يعرض رسالة تنبيه بانقطاع الاتصال
  • المستخدم ينتظر استعادة الاتصال ويحاول مرة أخرى
القواعد التجارية
  • يجب أن تكون واجهة إعدادات الإشعارات سهلة الاستخدام
الافتراضات
  • المستخدم يعرف كيفية الوصول إلى إعدادات الإشعارات في التطبيق
  • النظام قادر على حفظ التفضيلات بشكل صحيح
المتطلبات الخاصة
  • يجب توفير واجهة سهلة الاستخدام لإعدادات الإشعارات
  • يجب أن يتم حفظ التفضيلات بشكل فوري
الملاحظات والمشاكل
  • قد يواجه بعض المستخدمين صعوبة في فهم واجهة إعدادات الإشعارات
  • يجب تقديم إرشادات واضحة للمستخدمين
المدخلاتتفضيلات الإشعارات الجديدة |
المخرجات
  • تحديث إعدادات الإشعارات في النظام
تفاعلات المستخدم
  • اختيار التفضيلات
  • حفظ التفضيلات
الشروط الخاصة
  • فشل حفظ التفضيلات
  • انقطاع الاتصال بالإنترنت
سيناريوهات الاستخدام
  • تفعيل إشعارات البريد الإلكتروني فقط
  • تعطيل جميع الإشعارات ما عدا إشعارات الطوارئ
متطلبات الأمان
  • ضمان عدم وصول إعدادات الإشعارات لجهات غير مصرح لها
التكامل مع الأنظمة الأخرى
  • نظام إدارة الإشعارات
  • نظام تفضيلات المستخدم
القيود والافتراضات
  • يجب أن يكون لدى المستخدم اتصال إنترنت فعال لتحديث التفضيلات
متطلبات الاختبار
  • اختبار واجهة إعدادات الإشعارات للتأكد من سهولة الاستخدام
  • اختبار حفظ التفضيلات بشكل صحيح
تفاصيل ال API
Method: POST || Endpoint: /updateNotificationPreferences
Request Headers
Authorization: Bearer token Content-Type: application/json

Request Body

user_id: نص Preferences : boolean, boolean, boolean

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
تفضيلات الإشعارات

  • textblock
    • إعدادات الإشعارات

  • form
    • Checkbox
      • العنوان : تمكين إشعارات البريد الإلكتروني
    • Checkbox
      • العنوان : تمكين إشعارات Push
    • Checkbox
      • العنوان : تمكين إشعارات SMS
    • Button
      • العنوان : حفظ التفضيلات
      • الخيارات : saveNotificationPreferences
الاشعارات

العنوان : تم تحديث إعدادات الإشعارات
الرسالة : تم تحديث إعدادات الإشعارات الخاصة بك بنجاح
عن طريق : ايميل, الاشعارات علي الهاتف, SMS  المستقبل : المستخدم

3.2.2.5- إعدادات الإشعارات التي تسمح للمستخدمين بتحديد طريقة استلام الإشعارات (بريد إلكتروني، push notification، SMS) لضمان تلقي المعلومات بالطريقة الأنسب لهم

graph LR;A[فتح إعدادات الإشعارات] --> B[اختيار طريقة استلام الإشعارات];B --> C[حفظ التفضيلات];C --> D[تحديث النظام بناءً على التفضيلات الجديدة];
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • الوصول إلى إعدادات الإشعارات في التطبيق
الشروط اللاحقة
  • تحديث طريقة استلام الإشعارات الخاصة بالمستخدم
  • استلام الإشعارات بالطريقة المحددة من قبل المستخدم
تسلسل الأحداث
  • فتح إعدادات الإشعارات
  • اختيار طريقة استلام الإشعارات
  • حفظ التفضيلات
  • تحديث النظام بناءً على التفضيلات الجديدة
الخطوات البديلةفشل حفظ التفضيلات
  • النظام يعرض رسالة خطأ للمستخدم
  • المستخدم يحاول حفظ التفضيلات مرة أخرى
الخطوات الاستثنائيةانقطاع الاتصال بالإنترنت
  • النظام يعرض رسالة تنبيه بانقطاع الاتصال
  • المستخدم ينتظر استعادة الاتصال ويحاول مرة أخرى
القواعد التجارية
  • يجب أن تكون واجهة إعدادات الإشعارات سهلة الاستخدام
  • توفير خيارات متعددة لاستلام الإشعارات
الافتراضات
  • المستخدم يعرف كيفية الوصول إلى إعدادات الإشعارات في التطبيق
  • النظام قادر على حفظ التفضيلات بشكل صحيح
المتطلبات الخاصة
  • يجب توفير واجهة سهلة الاستخدام لإعدادات الإشعارات
  • يجب أن يتم حفظ التفضيلات بشكل فوري
الملاحظات والمشاكل
  • قد يواجه بعض المستخدمين صعوبة في فهم واجهة إعدادات الإشعارات
  • يجب تقديم إرشادات واضحة للمستخدمين
المدخلاتتفضيلات استلام الإشعارات الجديدة |
المخرجات
  • تحديث إعدادات استلام الإشعارات في النظام
تفاعلات المستخدم
  • اختيار طريقة استلام الإشعارات
  • حفظ التفضيلات
الشروط الخاصة
  • فشل حفظ التفضيلات
  • انقطاع الاتصال بالإنترنت
سيناريوهات الاستخدام
  • تحديد استلام الإشعارات عبر البريد الإلكتروني فقط
  • تحديد استلام الإشعارات عبر push notification و SMS فقط
متطلبات الأمان
  • ضمان عدم وصول إعدادات استلام الإشعارات لجهات غير مصرح لها
التكامل مع الأنظمة الأخرى
  • نظام إدارة الإشعارات
  • نظام تفضيلات المستخدم
القيود والافتراضات
  • يجب أن يكون لدى المستخدم اتصال إنترنت فعال لتحديث التفضيلات
متطلبات الاختبار
  • اختبار واجهة إعدادات استلام الإشعارات للتأكد من سهولة الاستخدام
  • اختبار حفظ التفضيلات بشكل صحيح
تفاصيل ال API
Method: POST || Endpoint: /updateNotificationPreferences
Request Headers
Authorization: Bearer token Content-Type: application/json

Request Body

user_id: نص Preferences : boolean, boolean, boolean

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
تفضيلات الإشعارات

  • textblock
    • إعدادات استلام الإشعارات

  • form
    • Checkbox
      • العنوان : تمكين إشعارات البريد الإلكتروني
    • Checkbox
      • العنوان : تمكين إشعارات Push
    • Checkbox
      • العنوان : تمكين إشعارات SMS
    • Button
      • العنوان : حفظ التفضيلات
      • الخيارات : saveNotificationPreferences
الاشعارات

العنوان : تم تحديث إعدادات استلام الإشعارات
الرسالة : تم تحديث إعدادات استلام الإشعارات الخاصة بك بنجاح
عن طريق : ايميل, الاشعارات علي الهاتف, SMS  المستقبل : المستخدم

3.3 - تعديل الحساب وتغيير كلمة المرور

3.3.1 المعلومات العامة

العنوان التفاصيل
أهداف العمل
  • السماح للمستخدمين بتحديث معلوماتهم الشخصية بما في ذلك كلمة المرور
  • تعزيز الأمان من خلال تحديد متطلبات لكلمات المرور
الجهات المعنية
  • جميع المستخدمين
الخطوات الرئيسية
  • المستخدم ينقر على 'تعديل الحساب' أو 'تغيير كلمة المرور' في حسابه
  • المستخدم يمكنه تحديث المعلومات الشخصية و/أو كلمة المرور
  • لتغيير كلمة المرور، يتوجب على المستخدم إدخال كلمة المرور القديمة ثم إدخال الجديدة
  • كلمة المرور الجديدة يجب أن تكون أكثر من 8 رموز وأن تحتوي على حروف وأرقام
  • المستخدم ينقر على 'حفظ' لتأكيد التغييرات
الخطوات البديلة
  • ليس هناك أي حاجة لتأكيد المستخدم عبر البريد الإلكتروني أو الرسالة النصية
قصص المستخدمين
  • كمستخدم، أريد تحديث معلومات حسابي الشخصية (بما في ذلك كلمة المرور) بحيث يمكنني الحفاظ على الدقة والأمان
  • كمستخدم، أريد تغيير كلمة السر الخاصة بي بإدخال القديمة أولاً، للتأكد من أنني الشخص الوحيد الذي يمكنه تغييرها
  • كمستخدم، أريد أن تكون كلمة السر التي اختارها آمنة ومعقدة، وذلك لحماية حسابي من الاختراق
مؤشرات الأداء
  • عدد المستخدمين الذي قاموا بتعديل او تحديث حساباتهم

3.3.2 حالات الاستخدام

3.3.2.1- المستخدم ينقر على 'تعديل الحساب' أو 'تغيير كلمة المرور' في حسابه لتحديث معلوماته الشخصية و/أو كلمة المرور

graph LR; A[Start] --> B[Login to account]; B --> C[Click on 'Edit Account' or 'Change Password']; C --> D[Open Edit Account Page];
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • المستخدم مسجل في النظام
  • المستخدم مسجل الدخول إلى حسابه
الشروط اللاحقة
  • فتح صفحة تعديل الحساب أو تغيير كلمة المرور
الافتراضات
  • يجب أن يكون المستخدم على دراية بإجراءات النظام لتحديث معلومات الحساب
  • يجب أن يكون لدى المستخدم كلمة مرور صالحة للدخول إلى النظام
متطلبات الأمان
  • يجب تأمين عملية تسجيل الدخول لضمان أن الشخص الذي يقوم بالتعديلات هو صاحب الحساب
القيود والافتراضات
  • يجب أن تكون صفحة تعديل الحساب محمية بكلمة مرور
متطلبات الاختبار
  • يجب التحقق من صحة خطوات تحديث الحساب أو تغيير كلمة المرور لضمان أنها تعمل بشكل صحيح
  • يجب اختبار حالات الاستخدام الخاطئة مثل إدخال كلمة مرور غير صحيحة
تفاصيل ال API
Method: GET || Endpoint: /account/edit
Request Headers
Authorization: Bearer token

Request Body

Response

الحالةالمحتوى
200status: نص account_details: object
الوصف: Success
400
الوصف: Bad Request

Method: POST || Endpoint: /account/update
Request Headers
Authorization: Bearer token

Request Body

user_id: نص name: نص email: نص password: نص

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة تعديل الحساب

  • textblock
    • Edit your account information

  • form
    • text
      • العنوان : الاسم
      • التحقق : Please enter a valid name
    • email
      • العنوان : البريد الإلكتروني
      • التحقق : Please enter a valid email
    • password
      • العنوان : كلمة المرور الحالية
      • التحقق : Please enter your current password
    • password
      • العنوان : كلمة المرور الجديدة
      • التحقق : Please enter a new password
  • رسالة زر الإرسال: Save Changes
  • رسالة النجاح: تم تحديث حسابك بنجاح
  • إعادة توجيه النجاح: AccountOverviewScreen
الاشعارات

العنوان : تحديث الحساب
الرسالة : تم تحديث معلومات حسابك بنجاح
عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : user

3.3.2.2- المستخدم يمكنه تحديث المعلومات الشخصية و/أو تغيير كلمة المرور

graph LR; A[Start] --> B[Open Edit Account Page]; B --> C[Update Personal Information or Password]; C --> D[Click 'Save']; D --> E[Update Successful];
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • فتح صفحة تعديل الحساب أو تغيير كلمة المرور
الشروط اللاحقة
  • تم تحديث المعلومات الشخصية و/أو كلمة المرور
الافتراضات
  • يجب أن يكون المستخدم على دراية بكيفية تحديث معلومات الحساب
  • يجب أن يكون لدى المستخدم كلمة مرور صالحة للدخول إلى النظام
متطلبات الأمان
  • يجب تأمين عملية تحديث المعلومات لضمان أن الشخص الذي يقوم بالتعديلات هو صاحب الحساب
القيود والافتراضات
  • يجب أن تكون صفحة تعديل الحساب محمية بكلمة مرور
متطلبات الاختبار
  • يجب التحقق من صحة خطوات تحديث المعلومات الشخصية وكلمة المرور لضمان أنها تعمل بشكل صحيح
  • يجب اختبار حالات الاستخدام الخاطئة مثل إدخال بيانات غير صحيحة
تفاصيل ال API
Method: POST || Endpoint: /account/update
Request Headers
Authorization: Bearer token

Request Body

user_id: نص name: نص email: نص password: نص

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة تعديل الحساب

  • textblock
    • Edit your account information

  • form
    • text
      • العنوان : الاسم
      • التحقق : Please enter a valid name
    • email
      • العنوان : البريد الإلكتروني
      • التحقق : Please enter a valid email
    • password
      • العنوان : كلمة المرور الجديدة
      • التحقق : Please enter a new password
  • رسالة زر الإرسال: Save Changes
  • رسالة النجاح: تم تحديث حسابك بنجاح
  • إعادة توجيه النجاح: AccountOverviewScreen
الاشعارات

العنوان : تحديث الحساب
الرسالة : تم تحديث معلومات حسابك بنجاح
عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : user

3.3.2.3- لتغيير كلمة المرور، يتوجب على المستخدم إدخال كلمة المرور القديمة ثم إدخال الجديدة لضمان أمان الحساب

graph LR A[User chooses to change password] --> B[Opens change password page] B --> C[User enters current password] C --> D[User enters new password] D --> E[User clicks 'Save'] E --> F[Password changed successfully]
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • فتح صفحة تغيير كلمة المرور
  • تذكر كلمة المرور القديمة
الشروط اللاحقة
  • تم تغيير كلمة المرور بنجاح
تسلسل الأحداث
  • المستخدم يفتح صفحة تغيير كلمة المرور
  • المستخدم يدخل كلمة المرور القديمة
  • المستخدم يدخل كلمة المرور الجديدة
  • المستخدم ينقر على زر 'حفظ' لتأكيد التغيير
القواعد التجارية
  • يجب أن تكون كلمة المرور الجديدة أكثر من 8 رموز وأن تحتوي على حروف وأرقام
الافتراضات
  • المستخدم يتذكر كلمة المرور القديمة
سيناريوهات الاستخدام
  • كمستخدم، أرغب في تغيير كلمة المرور الخاصة بي لضمان أمان الحساب
متطلبات الأمان
  • يجب التحقق من كلمة المرور القديمة قبل السماح بتغييرها
متطلبات الاختبار
  • اختبارات الأمان لتغيير كلمة المرور
  • اختبارات وظيفية لضمان عملية التغيير تتم بنجاح
تفاصيل ال API
Method: POST || Endpoint: /api/user/change-password
Request Headers
Authorization: Bearer token

Request Body

userId: نص currentPassword: نص newPassword: نص

Response

الحالةالمحتوى
200status: نص message: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة تغيير كلمة المرور

  • form
    • password
      • العنوان : كلمة المرور الحالية
      • التحقق : required
    • password
      • العنوان : كلمة المرور الجديدة
      • التحقق : required|min:8|contains:letters,numbers
    • password
      • العنوان : تأكيد كلمة المرور الجديدة
      • التحقق : required|same:newPassword
  • رسالة زر الإرسال: Save Changes
  • رسالة النجاح: تم تغيير كلمة المرور بنجاح
  • إعادة توجيه النجاح: ProfileScreen
الاشعارات

العنوان : تغيير كلمة المرور
الرسالة : تم تغيير كلمة المرور الخاصة بك بنجاح
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : المستخدم

3.3.2.4- كلمة المرور الجديدة يجب أن تكون أكثر من 8 رموز وأن تحتوي على حروف وأرقام. يجب أن يتم التحقق من صحة كلمة المرور الجديدة قبل حفظها في النظام

graph LR; A[فتح صفحة تغيير كلمة المرور] --> B[إدخال كلمة المرور القديمة]; B --> C[إدخال كلمة المرور الجديدة]; C --> D{هل كلمة المرور الجديدة تستوفي الشروط؟}; D -->|نعم| E[النقر على زر 'حفظ']; D -->|لا| F[عرض رسالة خطأ]; E --> G[حفظ كلمة المرور الجديدة في قاعدة البيانات]; G --> H[عرض رسالة تأكيد]; F --> C
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • فتح صفحة تغيير كلمة المرور
  • إدخال كلمة المرور القديمة بشكل صحيح
الشروط اللاحقة
  • تم التحقق من صحة كلمة المرور الجديدة
  • تم حفظ كلمة المرور الجديدة بنجاح
تسلسل الأحداث
  • المستخدم يفتح صفحة تغيير كلمة المرور
  • المستخدم يدخل كلمة المرور القديمة
  • المستخدم يدخل كلمة المرور الجديدة
  • النظام يتحقق من صحة كلمة المرور الجديدة
  • النظام يحفظ كلمة المرور الجديدة في قاعدة البيانات
الخطوات البديلةكلمة المرور الجديدة لا تستوفي شروط الأمان
  • النظام يعرض رسالة خطأ توضح المتطلبات المطلوبة لكلمة المرور الجديدة
  • المستخدم يعيد إدخال كلمة مرور جديدة تستوفي الشروط
الخطوات الاستثنائيةالنظام يواجه خطأ أثناء حفظ كلمة المرور الجديدة
  • النظام يعرض رسالة خطأ للمستخدم تشير إلى فشل عملية الحفظ
  • المستخدم يعيد المحاولة بعد فترة
القواعد التجارية
  • كلمة المرور الجديدة يجب أن تكون فريدة ولا يمكن أن تكون مشابهة للقديمة
  • كلمة المرور يجب أن تحتوي على حروف كبيرة وصغيرة وأرقام
الافتراضات
  • المستخدم يتذكر كلمة المرور القديمة
  • المستخدم قادر على إدخال كلمة مرور جديدة تستوفي الشروط
المتطلبات الخاصة
  • تحقق من كلمة المرور الجديدة من خلال واجهة المستخدم قبل حفظها
الملاحظات والمشاكل
  • يجب توفير مساعدة للمستخدم في حال واجه صعوبة في اختيار كلمة مرور جديدة تستوفي الشروط
المدخلاتكلمة المرور القديمة | كلمة المرور الجديدة |
المخرجات
  • رسالة تأكيد بتغيير كلمة المرور
  • رسالة خطأ في حال عدم استيفاء كلمة المرور الجديدة للشروط
تفاعلات المستخدم
  • نموذج إدخال كلمة المرور القديمة والجديدة
  • زر 'حفظ' لتأكيد التغييرات
الشروط الخاصة
  • إدخال كلمة المرور الجديدة بشكل غير صحيح لعدة مرات متتالية
سيناريوهات الاستخدام
  • كمستخدم، أرغب في تغيير كلمة المرور الخاصة بي لضمان أمان حسابي
  • كمستخدم، أرغب في التأكد من أن كلمة المرور الجديدة تستوفي جميع شروط الأمان المطلوبة قبل حفظها
متطلبات الأمان
  • التحقق من كلمة المرور القديمة بشكل آمن
  • تخزين كلمة المرور الجديدة بشكل مشفر
التكامل مع الأنظمة الأخرى
  • نظام إدارة الحسابات
  • قاعدة بيانات المستخدمين
القيود والافتراضات
  • يجب أن يكون المستخدم مسجل الدخول إلى النظام لتغيير كلمة المرور
  • يجب أن تكون كلمة المرور الجديدة مستوفية لشروط الأمان المحددة
متطلبات الاختبار
  • اختبار إدخال كلمة مرور جديدة تستوفي شروط الأمان
  • اختبار سيناريوهات الخطأ عند إدخال كلمة مرور غير صحيحة أو عدم استيفاء الشروط
تفاصيل ال API
Method: POST || Endpoint: /user/change-password
Request Headers
Authorization: Bearer token

Request Body

old_password: نص new_password: نص

Response

الحالةالمحتوى
200status: success
الوصف: تم تغيير كلمة المرور بنجاح
400
الوصف: كلمة المرور الجديدة لا تستوفي شروط الأمان
401
الوصف: كلمة المرور القديمة غير صحيحة
500
الوصف: خطأ في الخادم أثناء تغيير كلمة المرور

تفاصيل الواجهات
شاشة تغيير كلمة المرور

  • form
    • password
      • العنوان : كلمة المرور القديمة
      • التحقق : كلمة المرور القديمة مطلوبة
    • password
      • العنوان : كلمة المرور الجديدة
      • التحقق : كلمة المرور الجديدة يجب أن تكون أكثر من 8 رموز وتشمل حروف وأرقام
  • رسالة زر الإرسال: حفظ
  • رسالة النجاح: تم تغيير كلمة المرور بنجاح
  • إعادة توجيه النجاح: ProfileScreen
الاشعارات

العنوان : تأكيد تغيير كلمة المرور
الرسالة : تم تغيير كلمة المرور بنجاح. إذا لم تقم بإجراء هذا التغيير، يرجى الاتصال بالدعم فوراً
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : المستخدم

3.3.2.5- المستخدم ينقر على زر 'حفظ' لتأكيد التغييرات التي أجراها على معلومات حسابه أو كلمة المرور. يجب أن يتم التحقق من صحة جميع التغييرات المدخلة وحفظها في النظام

graph LR; A[فتح صفحة تعديل الحساب أو تغيير كلمة المرور] --> B[إدخال التغييرات المطلوبة]; B --> C[النقر على زر 'حفظ']; C --> D{هل البيانات المدخلة صحيحة؟}; D -->|نعم| E[حفظ التغييرات في قاعدة البيانات]; D -->|لا| F[عرض رسالة خطأ]; E --> G[عرض رسالة تأكيد]; F --> B
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • فتح صفحة تعديل الحساب أو تغيير كلمة المرور
  • إدخال التغييرات المطلوبة
الشروط اللاحقة
  • تم حفظ التغييرات بنجاح في النظام
تسلسل الأحداث
  • المستخدم يفتح صفحة تعديل الحساب أو تغيير كلمة المرور
  • المستخدم يدخل التغييرات المطلوبة
  • المستخدم ينقر على زر 'حفظ'
  • النظام يتحقق من صحة البيانات المدخلة
  • النظام يحفظ التغييرات
  • النظام يعرض رسالة تأكيد
الخطوات البديلةالبيانات المدخلة غير صحيحة أو غير مكتملة
  • النظام يعرض رسالة خطأ توضح البيانات التي تحتاج إلى تعديل
  • المستخدم يقوم بتعديل البيانات الخاطئة أو غير المكتملة
  • المستخدم ينقر على زر 'حفظ' مرة أخرى
الخطوات الاستثنائيةالنظام يواجه خطأ أثناء حفظ التغييرات
  • النظام يعرض رسالة خطأ تشير إلى فشل عملية الحفظ
  • المستخدم يعيد المحاولة بعد فترة
القواعد التجارية
  • يجب التحقق من صحة البيانات المدخلة قبل حفظها
  • يجب إعلام المستخدم بأي أخطاء في البيانات المدخلة
الافتراضات
  • المستخدم يرغب في تحديث بيانات حسابه بشكل صحيح
  • المستخدم قادر على تصحيح أي أخطاء في البيانات المدخلة
المتطلبات الخاصة
  • النظام يجب أن يوفر استجابة سريعة لحفظ التغييرات
الملاحظات والمشاكل
  • يجب توفير مساعدة للمستخدم في حال واجه صعوبة في إدخال البيانات بشكل صحيح
المدخلاتالبيانات الشخصية المحدثة | كلمة المرور الجديدة (إذا تم تغييرها) |
المخرجات
  • رسالة تأكيد بحفظ التغييرات
  • رسالة خطأ في حال عدم صحة البيانات المدخلة
تفاعلات المستخدم
  • نموذج إدخال البيانات الشخصية المحدثة وكلمة المرور الجديدة
  • زر 'حفظ' لتأكيد التغييرات
الشروط الخاصة
  • إدخال بيانات غير صحيحة أو غير مكتملة
سيناريوهات الاستخدام
  • كمستخدم، أرغب في تحديث بيانات حسابي الشخصية أو تغيير كلمة المرور، وأريد أن يتم حفظ هذه التغييرات بشكل صحيح وسريع
متطلبات الأمان
  • التحقق من صحة البيانات المدخلة بشكل آمن
  • تخزين البيانات المحدثة بشكل مشفر
التكامل مع الأنظمة الأخرى
  • نظام إدارة الحسابات
  • قاعدة بيانات المستخدمين
القيود والافتراضات
  • يجب أن يكون المستخدم مسجل الدخول إلى النظام لتعديل بيانات الحساب
  • يجب أن تكون البيانات المحدثة مستوفية للشروط المطلوبة
متطلبات الاختبار
  • اختبار إدخال بيانات محدثة وحفظها بشكل صحيح
  • اختبار سيناريوهات الخطأ عند إدخال بيانات غير صحيحة أو غير مكتملة
تفاصيل ال API
Method: POST || Endpoint: /user/update-profile
Request Headers
Authorization: Bearer token

Request Body

user_data: object

Response

الحالةالمحتوى
200status: success
الوصف: تم تحديث البيانات بنجاح
400
الوصف: البيانات المدخلة غير صحيحة
401
الوصف: المستخدم غير مصرح له
500
الوصف: خطأ في الخادم أثناء تحديث البيانات

تفاصيل الواجهات
شاشة تعديل الملف الشخصي

  • form
    • text
      • العنوان : الاسم الكامل
      • التحقق : الاسم الكامل مطلوب
    • email
      • العنوان : البريد الإلكتروني
      • التحقق : البريد الإلكتروني مطلوب
    • password
      • العنوان : كلمة المرور القديمة
      • التحقق : كلمة المرور القديمة مطلوبة
    • password
      • العنوان : كلمة المرور الجديدة
      • التحقق : كلمة المرور الجديدة يجب أن تكون أكثر من 8 رموز وتشمل حروف وأرقام
  • رسالة زر الإرسال: حفظ
  • رسالة النجاح: تم تحديث البيانات بنجاح
  • إعادة توجيه النجاح: ProfileScreen
الاشعارات

العنوان : تأكيد تحديث البيانات
الرسالة : تم تحديث بيانات حسابك بنجاح. إذا لم تقم بإجراء هذا التغيير، يرجى الاتصال بالدعم فوراً
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : المستخدم

3.4 - تسجيل الدخول

3.4.1 المعلومات العامة

العنوان التفاصيل
أهداف العمل
  • تزويد المستخدمين بوسيلة آمنة وسهلة للدخول إلى حساباتهم
  • تقليل فرص الاختراق والوصول غير الشرعي من خلال استخدام OTP
الجهات المعنية
  • جميع المستخدمين
الخطوات الرئيسية
  • المستخدم يدخل رقم الهاتف وكلمة المرور ثم ينقر على زر 'تسجيل الدخول'
  • في حالة الرغبة في استخدام OTP، المستخدم يضغط على الزر 'إرسال OTP'. المنصة ترسل رسالة نصية مع الOTP إلى رقم الهاتف
  • المستخدم يدخل ال OTP المرسلة عبر الرسالة النصية ويضغط على 'تسجيل الدخول'
  • جعل التطبيق في حالة تسجيل (دخول للحساب) مستمرة للعمل في الخلفية (نشط – غير نشط)
الخطوات البديلة
  • إذا كان المستخدم قد نسي كلمة المرور، يمكنه الضغط على 'نسيت كلمة المرور' واتباع الإرشادات لاستعادة الحساب
  • إذا كان الOTP غير صالح (مرت أكثر من 3 دقائق منذ إرسالها)، يمكن للمستخدم طلب OTP جديدة
قصص المستخدمين
  • كمستخدم، أريد تسجيل الدخول إلى حسابي بسهولة وأمان باستخدام رقم الهاتف وكلمة السر
  • كمستخدم، أريد القدرة على استخدام OTP كطريقة بديلة لتسجيل الدخول، للحفاظ على أمان حسابي وتقديم خيار تسجيل دخول مرن
  • كمستخدم، أريد القدرة على طلب OTP جديدة إذا كانت القديمة غير صالحة
مؤشرات الأداء
  • عدد المستخدمين الذين قاموا بتسجيل الدخول (حالياً او خلال فترات سابقة)
  • عدد المستخدمين النشطين حاليآ او خلال فترات سابقة
  • عدد المستخدمين الذين لا يمكنهم ممارسة الأعمال بسبب احد الوثائق المقدمة مثل انتهاء صلاحيتها أو عدم تقديمها

3.4.2 حالات الاستخدام

3.4.2.1- المستخدم يدخل رقم الهاتف وكلمة المرور ثم ينقر على زر 'تسجيل الدخول'. يتم التحقق من صحة البيانات المدخلة، وفي حال صحتها، يتم تسجيل دخول المستخدم إلى حسابه

graph LR;A[فتح صفحة تسجيل الدخول] --> B[إدخال رقم الهاتف وكلمة المرور];B --> C[النقر على زر 'تسجيل الدخول'];C --> D{هل البيانات المدخلة صحيحة؟};D -->|نعم| E[تسجيل الدخول إلى الحساب];D -->|لا| F[عرض رسالة خطأ];E --> G[عرض رسالة تأكيد];F --> B
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • المستخدم مسجل في النظام
  • المستخدم يمتلك رقم هاتف مسجل وكلمة مرور صحيحة
الشروط اللاحقة
  • تم تسجيل دخول المستخدم إلى حسابه
تسلسل الأحداث
  • فتح صفحة تسجيل الدخول
  • إدخال رقم الهاتف وكلمة المرور
  • النقر على زر 'تسجيل الدخول'
  • النظام يتحقق من صحة البيانات المدخلة
  • النظام يسجل دخول المستخدم إذا كانت البيانات صحيحة
الخطوات البديلةكلمة المرور غير صحيحة
  • النظام يعرض رسالة خطأ توضح أن كلمة المرور غير صحيحة
  • المستخدم يعيد إدخال كلمة المرور الصحيحة
الخطوات الاستثنائيةالنظام يواجه مشكلة في الاتصال بقاعدة البيانات
  • النظام يعرض رسالة خطأ تشير إلى وجود مشكلة في النظام
  • المستخدم يحاول تسجيل الدخول مرة أخرى بعد فترة
القواعد التجارية
  • يجب التحقق من صحة البيانات المدخلة قبل السماح بتسجيل الدخول
  • يجب إعلام المستخدم بأي أخطاء في البيانات المدخلة
الافتراضات
  • المستخدم يتذكر رقم الهاتف وكلمة المرور الصحيحة
المتطلبات الخاصة
  • النظام يجب أن يوفر استجابة سريعة لتسجيل الدخول
الملاحظات والمشاكل
  • يجب توفير مساعدة للمستخدم في حال نسيان كلمة المرور
المدخلاترقم الهاتف | كلمة المرور |
المخرجات
  • رسالة تأكيد بتسجيل الدخول
  • رسالة خطأ في حال عدم صحة البيانات المدخلة
تفاعلات المستخدم
  • نموذج إدخال رقم الهاتف وكلمة المرور
  • زر 'تسجيل الدخول' لتأكيد الدخول
الشروط الخاصة
  • إدخال كلمة مرور غير صحيحة لعدة مرات متتالية
سيناريوهات الاستخدام
  • كمستخدم، أرغب في تسجيل الدخول إلى حسابي على النظام باستخدام رقم الهاتف وكلمة المرور الخاصة بي
متطلبات الأمان
  • التحقق من صحة البيانات المدخلة بشكل آمن
  • حماية البيانات الشخصية للمستخدم
التكامل مع الأنظمة الأخرى
  • نظام إدارة الحسابات
  • قاعدة بيانات المستخدمين
القيود والافتراضات
  • يجب أن يكون المستخدم مسجل في النظام
  • يجب أن تكون البيانات المدخلة صحيحة
متطلبات الاختبار
  • اختبار إدخال بيانات صحيحة وتسجيل الدخول بشكل صحيح
  • اختبار سيناريوهات الخطأ عند إدخال بيانات غير صحيحة
تفاصيل ال API
Method: POST || Endpoint: /user/login
Request Headers
Content-Type: application/json

Request Body

phone_number: نص password: نص

Response

الحالةالمحتوى
200status: success token: نص
الوصف: تم تسجيل الدخول بنجاح
400
الوصف: بيانات الدخول غير صحيحة
500
الوصف: خطأ في الخادم أثناء تسجيل الدخول

تفاصيل الواجهات
شاشة تسجيل الدخول

  • form
    • text
      • العنوان : رقم الهاتف
      • التحقق : رقم الهاتف مطلوب
    • password
      • العنوان : كلمة المرور
      • التحقق : كلمة المرور مطلوبة
  • رسالة زر الإرسال: تسجيل الدخول
  • رسالة النجاح: تم تسجيل الدخول بنجاح
  • إعادة توجيه النجاح: HomeScreen
الاشعارات

العنوان : تأكيد تسجيل الدخول
الرسالة : تم تسجيل دخولك بنجاح. إذا لم تقم بإجراء هذا الدخول، يرجى الاتصال بالدعم فوراً
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : المستخدم

3.4.2.2- في حالة الرغبة في استخدام OTP، المستخدم يضغط على الزر 'إرسال OTP'. المنصة ترسل رسالة نصية مع OTP إلى رقم الهاتف. يقوم المستخدم بإدخال OTP في الحقل المخصص ثم ينقر على زر 'تسجيل الدخول' لتأكيد الدخول إلى الحساب

graph LR;A[فتح صفحة تسجيل الدخول] --> B[إدخال رقم الهاتف];B --> C[النقر على زر 'إرسال OTP'];C --> D[استلام رسالة نصية تحتوي على OTP];D --> E[إدخال OTP في الحقل المخصص];E --> F[النقر على زر 'تسجيل الدخول'];F --> G{هل OTP المدخل صحيح؟};G -->|نعم| H[تسجيل الدخول إلى الحساب];G -->|لا| I[عرض رسالة خطأ];I --> E
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • المستخدم مسجل في النظام
  • المستخدم يمتلك رقم هاتف مسجل
الشروط اللاحقة
  • تم إرسال OTP إلى هاتف المستخدم
تسلسل الأحداث
  • فتح صفحة تسجيل الدخول
  • إدخال رقم الهاتف
  • النقر على زر 'إرسال OTP'
  • استلام رسالة نصية تحتوي على OTP
  • إدخال OTP في الحقل المخصص
  • النقر على زر 'تسجيل الدخول'
الخطوات البديلةعدم استلام المستخدم لرسالة OTP
  • النظام يعرض رسالة خطأ تشير إلى فشل إرسال OTP
  • المستخدم يعيد المحاولة بعد التأكد من صحة رقم الهاتف
الخطوات الاستثنائيةإدخال OTP بشكل غير صحيح
  • النظام يعرض رسالة خطأ تشير إلى أن OTP المدخل غير صحيح
  • المستخدم يعيد إدخال OTP بشكل صحيح
القواعد التجارية
  • يجب التحقق من صحة OTP المدخل قبل السماح بتسجيل الدخول
  • يجب إعلام المستخدم بأي أخطاء في إدخال OTP
الافتراضات
  • المستخدم يتذكر رقم الهاتف المسجل
  • المستخدم قادر على استلام الرسائل النصية على رقم الهاتف المسجل
المتطلبات الخاصة
  • النظام يجب أن يوفر استجابة سريعة لإرسال واستلام OTP
الملاحظات والمشاكل
  • يجب توفير مساعدة للمستخدم في حال عدم استلام OTP
المدخلاترقم الهاتف | رمز التحقق |
المخرجات
  • رسالة تأكيد بتسجيل الدخول
  • رسالة خطأ في حال عدم صحة OTP المدخل
تفاعلات المستخدم
  • نموذج إدخال رقم الهاتف وOTP
  • زر 'إرسال OTP'
  • زر 'تسجيل الدخول' لتأكيد الدخول
الشروط الخاصة
  • عدم استلام OTP على الهاتف المسجل
سيناريوهات الاستخدام
  • كمستخدم، أرغب في تسجيل الدخول إلى حسابي على النظام باستخدام OTP المرسل إلى رقم الهاتف الخاص بي
متطلبات الأمان
  • التحقق من صحة OTP المدخل بشكل آمن
  • حماية البيانات الشخصية للمستخدم
التكامل مع الأنظمة الأخرى
  • نظام إدارة الحسابات
  • قاعدة بيانات المستخدمين
  • خدمة الرسائل النصية
القيود والافتراضات
  • يجب أن يكون المستخدم مسجل في النظام
  • يجب أن يكون رقم الهاتف المدخل صحيحاً وقادراً على استلام الرسائل النصية
متطلبات الاختبار
  • اختبار إدخال رقم الهاتف وإرسال OTP بشكل صحيح
  • اختبار سيناريوهات الخطأ عند إدخال OTP بشكل غير صحيح أو عدم استلامه
تفاصيل ال API
Method: POST || Endpoint: /user/request-otp
Request Headers
Content-Type: application/json

Request Body

phone_number: نص

Response

الحالةالمحتوى
200status: success
الوصف: تم إرسال OTP بنجاح
400
الوصف: رقم الهاتف غير صحيح
500
الوصف: خطأ في الخادم أثناء إرسال OTP

Method: POST || Endpoint: /user/login
Request Headers
Content-Type: application/json

Request Body

phone_number: نص otp: نص

Response

الحالةالمحتوى
200status: success token: نص
الوصف: تم تسجيل الدخول بنجاح
400
الوصف: OTP غير صحيح
500
الوصف: خطأ في الخادم أثناء تسجيل الدخول

تفاصيل الواجهات
شاشة تسجيل الدخول

  • form
    • text
      • العنوان : رقم الهاتف
      • التحقق : رقم الهاتف مطلوب
    • text
      • العنوان : رمز التحقق
      • التحقق : OTP مطلوب
  • رسالة زر الإرسال: تسجيل الدخول
  • رسالة النجاح: تم تسجيل الدخول بنجاح
  • إعادة توجيه النجاح: HomeScreen
    • Button
      • العنوان : إرسال OTP
      • الخيارات : requestOtp
الاشعارات

العنوان : OTP المرسل لتسجيل الدخول
الرسالة : تم إرسال OTP إلى رقم الهاتف المسجل. يرجى إدخاله لتأكيد الدخول إلى الحساب
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : المستخدم

3.4.2.3- جعل التطبيق في حالة تسجيل (دخول للحساب) مستمرة للعمل في الخلفية (نشط – غير نشط). يتضمن ذلك تسجيل الدخول بنجاح والحفاظ على الجلسة نشطة حتى عند التبديل بين التطبيقات أو العودة إلى الشاشة الرئيسية

graph LR; A[User Login] --> B[Session Token Generated]; B --> C[Keep Session Active]; C --> D[User Navigates Between Apps]; D --> E[Session Remains Active];
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • تم تسجيل دخول المستخدم بنجاح
الشروط اللاحقة
  • التطبيق يعمل في الخلفية بحالة تسجيل دخول مستمرة
تفاصيل ال API
Method: POST || Endpoint: /user/login
Request Headers
Content-Type: application/json

Request Body

phone_number: نص password: نص

Response

الحالةالمحتوى
200status: نص session_token: نص
الوصف: Success
400
الوصف: Bad Request

Method: GET || Endpoint: /user/session
Request Headers
Authorization: Bearer session_token

Request Body

Response

الحالةالمحتوى
200status: نص
الوصف: Session Active
401
الوصف: Unauthorized

تفاصيل الواجهات
الصفحة الرئيسية

  • textblock
    • Welcome to the Home Screen

  • form
    • Button
      • العنوان : الانتقال إلى لوحة التحكم
      • الخيارات : navigateToDashboard

لوحة التحكم

  • textblock
    • لوحة التحكم

  • textblock
    • You are logged in

3.4.2.4- إذا كان المستخدم قد نسي كلمة المرور، يمكنه الضغط على 'نسيت كلمة المرور' واتباع الإرشادات لاستعادة الحساب. يتضمن ذلك إعادة تعيين كلمة المرور من خلال خطوات التحقق

graph LR; A[Forgot Password] --> B[Send Reset Token]; B --> C[User Receives Token]; C --> D[Enter Reset Token and New Password]; D --> E[Reset Password]; E --> F[Login with New Password];
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • المستخدم غير قادر على تذكر كلمة المرور
  • وجود خيار 'نسيت كلمة المرور' في واجهة التطبيق
الشروط اللاحقة
  • استعادة المستخدم لحسابه عن طريق إعادة تعيين كلمة المرور
تفاصيل ال API
Method: POST || Endpoint: /user/forgot-password
Request Headers
Content-Type: application/json

Request Body

phone_number: نص

Response

الحالةالمحتوى
200status: نص reset_token: نص
الوصف: Password reset initiated successfully
400
الوصف: Bad Request

Method: POST || Endpoint: /user/reset-password
Request Headers
Content-Type: application/json

Request Body

reset_token: نص new_password: نص

Response

الحالةالمحتوى
200status: نص
الوصف: Password reset successfully
400
الوصف: Bad Request

تفاصيل الواجهات
نسيت كلمة المرور

  • textblock
    • نسيت كلمة المرور

  • form
    • text
      • العنوان : رقم الهاتف
      • التحقق : {"required":true,"error_message":"يرجى إدخال رقم الهاتف"}
  • رسالة زر الإرسال: إرسال رمز إعادة التعيين
  • رسالة النجاح: تم إرسال رمز إعادة التعيين إلى رقم هاتفك
  • إعادة توجيه النجاح: إعادة تعيين كلمة المرور

إعادة تعيين كلمة المرور

  • textblock
    • إعادة تعيين كلمة المرور

  • form
    • text
      • العنوان : رمز إعادة التعيين
      • التحقق : {"required":true,"error_message":"يرجى إدخال رمز إعادة التعيين"}
    • password
      • العنوان : كلمة المرور الجديدة
      • التحقق : {"required":true,"min_length":8,"pattern":"^(?=.*[a-zA-Z])(?=.*d).+$","error_message":"يجب أن تحتوي كلمة المرور على 8 أحرف على الأقل وتحتوي على حروف وأرقام"}
  • رسالة زر الإرسال: إعادة تعيين كلمة المرور
  • رسالة النجاح: تمت إعادة تعيين كلمة المرور بنجاح
  • إعادة توجيه النجاح: Login

3.4.2.5- إذا كان الOTP غير صالح (مرت أكثر من 3 دقائق منذ إرسالها)، يمكن للمستخدم طلب OTP جديدة. يتضمن ذلك طلب رمز OTP جديد عند انتهاء صلاحية الرمز الحالي وإدخاله في الحقل المخصص

graph LR; A[OTP Expired] --> B[Resend OTP]; B --> C[Receive New OTP]; C --> D[Enter New OTP]; D --> E[Verify OTP];
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • انتهاء صلاحية الOTP
  • وجود خيار لإعادة إرسال OTP
الشروط اللاحقة
  • استلام المستخدم OTP جديدة صالحة
تفاصيل ال API
Method: POST || Endpoint: /user/resend-otp
Request Headers
Content-Type: application/json

Request Body

phone_number: نص

Response

الحالةالمحتوى
200status: نص otp: نص
الوصف: تم إرسال رمز التحقق بنجاح
400
الوصف: Bad Request

تفاصيل الواجهات
إعادة إرسال رمز التحقق

  • textblock
    • إعادة إرسال OTP

  • form
    • text
      • العنوان : رقم الهاتف
      • التحقق : {"required":true,"error_message":"يرجى إدخال رقم الهاتف"}
  • رسالة زر الإرسال: إعادة إرسال OTP
  • رسالة النجاح: تم إرسال OTP جديدة إلى رقم هاتفك
  • إعادة توجيه النجاح: إدخال رمز التحقق

إدخال رمز التحقق

  • textblock
    • إدخال OTP

  • form
    • text
      • العنوان : رمز التحقق
      • التحقق : {"required":true,"error_message":"يرجى إدخال OTP الجديدة"}
  • رسالة زر الإرسال: تحقق
  • رسالة النجاح: تم التحقق من OTP بنجاح
  • إعادة توجيه النجاح: لوحة التحكم

3.5 - إعادة تعيين كلمة السر

3.5.1 المعلومات العامة

العنوان التفاصيل
أهداف العمل
  • تزويد المستخدمين بالقدرة على استعادة الوصول إلى حساباتهم بسهولة في حالة نسيان كلمة المرور
  • تقليل فرص تعطل الخدمة أو التأخير بسبب نسيان كلمة السر وتحقيق أقصى قدر من الكفاءة والراحة للمستخدم
الجهات المعنية
  • المستخدمون الذين نسوا كلمة المرور
الخطوات الرئيسية
  • المستخدم ينقر على 'نسيت كلمة المرور'
  • المستخدم يدخل رقم الهاتف وينقر على 'إرسال'
  • يتم إرسال رسالة نصية إلى الهاتف المحمول للمستخدم تحتوي على OTP وكلمة سر مؤقتة
  • المستخدم يدخل OTP ويقوم بالدخول
  • بمجرد تسجيل الدخول، يتم توجيه المستخدم إلى صفحة تعديل الحساب لوضع كلمة سر جديدة
الخطوات البديلة
  • إذا تم إدخال OTP أو كلمة السر المؤقتة بشكل خاطئ، يتم تقديم الرسائل الخطأ المناسبة
  • إذا شعر المستخدم بالحاجة لإعادة المحاولة، يمكن طلب OTP وكلمة السر المؤقتة مرة أخرى
قصص المستخدمين
  • كمستخدم، أريد أن أتمكن من استعادة الوصول إلى حسابي إذا نسيت كلمة المرور
  • كمستخدم، أرغب في الحصول على OTP وكلمة سر مؤقتة بسرعة وسهولة عبر الرسائل النصية
  • كمستخدم، أرغب في تغيير كلمة السر إلى واحدة جديدة بمجرد تسجيل الدخول باستخدام كلمة المرور المؤقتة
مؤشرات الأداء
  • عدد المستخدمين الذين قاموا بإعادة او تغيير كلمات المرور

3.5.2 حالات الاستخدام

3.5.2.1- يبدأ المستخدم عملية إعادة تعيين كلمة المرور من خلال النقر على 'نسيت كلمة المرور'

graph LR; A[Forgot Password] --> B[Enter Phone Number]; B --> C[Send OTP and Temporary Password]; C --> D[Receive OTP and Temporary Password];
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • المستخدم لديه حساب مسجل في النظام
الشروط اللاحقة
  • تم إرسال OTP وكلمة سر مؤقتة إلى رقم الهاتف المسجل
تسلسل الأحداث
  • المستخدم ينقر على نسيت كلمة المرور
  • المستخدم يدخل رقم الهاتف ويضغط على إرسال
  • النظام يرسل رقم OTP وكلمة سر مؤقتة
  • استلام المستخدم لOTP وكلمة السر المؤقتة
الافتراضات
  • النظام قادر على إرسال OTP وكلمة السر المؤقتة بشكل صحيح وسريع
  • المستخدم يتذكر رقم الهاتف المسجل في النظام
المتطلبات الخاصة
  • يجب أن يكون OTP سهل القراءة ومكون من 6-8 أرقام
الملاحظات والمشاكل
  • قد يواجه المستخدمون مشاكل في استلام OTP في مناطق ذات تغطية شبكة ضعيفة
المدخلاترقم الهاتف |
المخرجات
  • OTP وكلمة سر مؤقتة مرسلة إلى رقم الهاتف المسجل
تفاعلات المستخدم
  • ادخال رقم الهاتف
  • النقر على ارسال
الشروط الخاصة
  • يجب أن يكون رقم الهاتف المدخل مطابق للرقم المسجل في المنصة
سيناريوهات الاستخدام
  • المستخدم ينسى كلمة المرور، يقوم بإعادة تعيينها عبر إدخال OTP وكلمة سر مؤقتة مرسلة إلى هاتفه
متطلبات الأمان
  • يجب تأمين عملية إرسال OTP وكلمة السر المؤقتة لضمان عدم اعتراضها
التكامل مع الأنظمة الأخرى
  • النظام يجب أن يكون متكاملاً مع مزودي خدمة الرسائل النصية لإرسال OTP وكلمة السر المؤقتة
القيود والافتراضات
  • النظام يجب أن يدعم إرسال رسائل نصية بشكل موثوق وسريع
متطلبات الاختبار
  • اختبار عملية إرسال واستلام OTP وكلمة السر المؤقتة بشكل صحيح وسريع
تفاصيل ال API
Method: GET || Endpoint: /user/request-password-reset
Request Headers
Content-Type: application/json

Request Body

phone_number:string

Response

الحالةالمحتوى
200OTP and temporary password sent successfully
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
Password Reset

  • textblock
    • Please enter your phone number to receive an OTP and temporary password

  • form
    • text
      • العنوان : Phone number
      • التحقق : placeholder:Enter your phone number required: true error_message:Please enter a valid phone number.
  • رسالة زر الإرسال: Send OTP
الاشعارات

العنوان : Password reset
الرسالة : An OTP and temporary password have been sent to your registered phone number
عن طريق : push notification   المستقبل : user

3.5.2.2- يستخدم المستخدم OTP وكلمة السر المؤقتة لتسجيل الدخول وتعيين كلمة سر جديدة بسهولة وأمان، مما يمكنه من استعادة حسابه واستمرارية استخدام المنصة

graph LR; A[User initiates password reset] --> B[Receives OTP and temporary password via SMS]; B --> C[Enters OTP and temporary password]; C --> D[Logs in with temporary password]; D --> E[Directed to change password]; E --> F[Enters new password and confirms]; F --> G[Password reset successful]; G --> H[User notified of successful password reset];
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • المستخدم تلقى OTP وكلمة السر المؤقتة عبر الرسالة النصية
الشروط اللاحقة
  • تم تعيين كلمة سر جديدة بنجاح
  • المستخدم يمكنه الآن تسجيل الدخول باستخدام كلمة السر الجديدة
تسلسل الأحداث
  • المستخدم ينقر على 'نسيت كلمة المرور'
  • النظام يرسل OTP وكلمة السر المؤقتة
  • المستخدم يدخل OTP وكلمة السر المؤقتة لتسجيل الدخول
  • النظام يوجه المستخدم إلى صفحة تعديل الحساب
  • المستخدم يعين كلمة سر جديدة
الخطوات البديلةالمستخدم لم يتلقى OTP
  • المستخدم ينقر على خيار 'إعادة إرسال OTP'
  • النظام يرسل OTP جديدة إلى الهاتف المسجل
الخطوات الاستثنائيةإدخال OTP أو كلمة السر المؤقتة بشكل خاطئ
  • النظام يعرض رسالة خطأ
  • المستخدم يعيد المحاولة بإدخال البيانات الصحيحة
القواعد التجارية
  • OTP صالح لمدة 3 دقائق فقط
  • كلمة السر الجديدة يجب أن تكون مكونة من 8 أحرف على الأقل وتحتوي على حروف وأرقام
الافتراضات
  • المستخدم يتذكر رقم الهاتف المسجل في النظام
  • المستخدم لديه وصول إلى الهاتف المسجل لاستلام OTP
المتطلبات الخاصة
  • التحقق من أن النظام يمكنه إرسال OTP في الوقت المناسب
  • توفير واجهة سهلة الاستخدام لإدخال OTP وكلمة السر الجديدة
الملاحظات والمشاكل
  • قد يواجه المستخدمون مشكلات في استلام OTP بسبب مشاكل في الشبكة أو رقم الهاتف غير صحيح
المدخلاترمز التحقق | كلمة السر المؤقتة | كلمة السر الجديدة |
المخرجات
  • تأكيد تغيير كلمة السر بنجاح
تفاعلات المستخدم
  • النظام يرسل رسالة نصية تحتوي على OTP وكلمة السر المؤقتة
  • النظام يعرض واجهة إدخال OTP وكلمة السر الجديدة
الشروط الخاصة
  • فشل المستخدم في استلام OTP
  • إدخال المستخدم للبيانات بشكل خاطئ
سيناريوهات الاستخدام
  • كمستخدم، إذا نسيت كلمة المرور، أريد استلام OTP وكلمة سر مؤقتة عبر الرسائل النصية لتسجيل الدخول وتعيين كلمة سر جديدة
متطلبات الأمان
  • OTP يتم إرسالها عبر قناة آمنة
  • تشفير البيانات الحساسة مثل كلمة السر الجديدة
التكامل مع الأنظمة الأخرى
  • تكامل مع نظام الرسائل النصية لإرسال OTP وكلمة السر المؤقتة
القيود والافتراضات
  • يجب أن يكون للمستخدم رقم هاتف صالح مسجل في النظام
  • يجب أن يكون هناك تكامل موثوق مع خدمة الرسائل النصية
متطلبات الاختبار
  • اختبارات وظيفية للتحقق من إرسال OTP واستلامها
  • اختبارات أمان للتأكد من حماية البيانات الحساسة
تفاصيل ال API
Method: POST || Endpoint: /reset-password
Request Headers
Content-Type: application/json

Request Body

phone_number: نص otp: نص temporary_password: نص new_password: نص

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة إعادة تعيين كلمة المرور

  • textblock
    • Enter the OTP and temporary password sent to your phone

  • form
    • text
      • العنوان : رمز التحقق
      • التحقق : required
    • password
      • العنوان : كلمة مرور مؤقتة
      • التحقق : required
    • password
      • العنوان : كلمة المرور الجديدة
      • التحقق : required|min:8
    • password
      • العنوان : تأكيد كلمة المرور الجديدة
      • التحقق : required|same:new_password
  • رسالة زر الإرسال: Reset Password
الاشعارات

العنوان : تم إعادة تعيين كلمة المرور بنجاح
الرسالة : تم إعادة تعيين كلمة المرور الخاصة بك بنجاح. يمكنك الآن تسجيل الدخول باستخدام كلمة المرور الجديدة
عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : المستخدم

3.5.2.3- في حال إدخال OTP أو كلمة السر المؤقتة بشكل خاطئ، يتم تقديم الرسائل الخطأ المناسبة لإبلاغ المستخدم بالمشكلة وتمكينه من إعادة المحاولة باستخدام البيانات الصحيحة

graph LR; A[User enters OTP and temporary password] --> B[System verifies OTP and password]; B --> C{Are the credentials correct?}; C -->|Yes| D[OTP verified successfully]; C -->|No| E[System displays error message]; E --> F[User retries with correct credentials];
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • المستخدم يحاول تسجيل الدخول باستخدام OTP أو كلمة السر المؤقتة
الشروط اللاحقة
  • المستخدم يعلم أن البيانات المدخلة خاطئة ويمكنه إعادة المحاولة
تسلسل الأحداث
  • المستخدم يدخل OTP أو كلمة السر المؤقتة
  • النظام يتحقق من صحة البيانات المدخلة
  • النظام يعرض رسالة خطأ في حال كانت البيانات خاطئة
الخطوات الاستثنائيةإدخال OTP أو كلمة السر المؤقتة بشكل خاطئ
  • النظام يعرض رسالة خطأ
  • المستخدم يعيد المحاولة بإدخال البيانات الصحيحة
القواعد التجارية
  • OTP صالح لمدة 3 دقائق فقط
  • يجب أن تكون كلمة السر المؤقتة قوية ومعقدة بما يكفي
الافتراضات
  • المستخدم يتذكر رقم الهاتف المسجل في النظام
  • المستخدم لديه وصول إلى الهاتف المسجل لاستلام OTP
المتطلبات الخاصة
  • النظام يجب أن يكون قادرًا على التحقق من صحة OTP وكلمة السر المؤقتة بسرعة
  • توفير واجهة سهلة الاستخدام لإدخال OTP وكلمة السر الجديدة
الملاحظات والمشاكل
  • قد يواجه المستخدمون مشكلات في استلام OTP بسبب مشاكل في الشبكة أو رقم الهاتف غير صحيح
المدخلاترمز التحقق | كلمة السر المؤقتة |
المخرجات
  • رسالة خطأ في حال كانت البيانات خاطئة
تفاعلات المستخدم
  • النظام يعرض واجهة إدخال OTP وكلمة السر الجديدة
  • النظام يعرض رسالة خطأ في حال كانت البيانات خاطئة
الشروط الخاصة
  • فشل المستخدم في إدخال OTP أو كلمة السر المؤقتة بشكل صحيح
سيناريوهات الاستخدام
  • كمستخدم، إذا أدخلت OTP أو كلمة السر المؤقتة بشكل خاطئ، أريد أن أستلم رسالة خطأ تشرح المشكلة وتتيح لي إعادة المحاولة
متطلبات الأمان
  • OTP يتم إرسالها عبر قناة آمنة
  • تشفير البيانات الحساسة مثل OTP وكلمة السر المؤقتة
التكامل مع الأنظمة الأخرى
  • تكامل مع نظام الرسائل النصية لإرسال OTP
  • تكامل مع النظام الأساسي للتحقق من صحة البيانات
القيود والافتراضات
  • يجب أن يكون للمستخدم رقم هاتف صالح مسجل في النظام
  • يجب أن يكون هناك تكامل موثوق مع خدمة الرسائل النصية
متطلبات الاختبار
  • اختبارات وظيفية للتحقق من التحقق من صحة OTP وكلمة السر المؤقتة
  • اختبارات أمان للتأكد من حماية البيانات الحساسة
تفاصيل ال API
Method: POST || Endpoint: /verify-otp
Request Headers
Content-Type: application/json

Request Body

phone_number: نص otp: نص temporary_password: نص

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة التحقق من رمز التحقق

  • textblock
    • Enter the OTP and temporary password sent to your phone

  • form
    • text
      • العنوان : رمز التحقق
      • التحقق : required
    • password
      • العنوان : كلمة مرور مؤقتة
      • التحقق : required
  • رسالة زر الإرسال: Verify OTP
الاشعارات

العنوان : رمز التحقق أو كلمة المرور المؤقتة غير صحيحة. يرجى المحاولة مرة أخرى
الرسالة : رمز التحقق أو كلمة المرور المؤقتة التي أدخلتها غير صحيحة. يرجى المحاولة مرة أخرى
عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : المستخدم

3.5.2.4- في حالة فشل إرسال OTP بسبب مشكلات في الشبكة أو خطأ في رقم الهاتف، يجب أن يتلقى المستخدم رسالة خطأ ويوجه لإعادة المحاولة

graph LR; A[User requests OTP] --> B[System tries to send OTP]; B --> C{Is OTP sent successfully?}; C -->|Yes| D[OTP sent successfully]; C -->|No| E[System displays error message]; E --> F[User retries with correct phone number];
العنوانالتفاصيل
المستخدمالمستخدم
الشروط المسبقة
  • المستخدم قام بإدخال رقم هاتف صالح
  • النظام يحاول إرسال OTP إلى المستخدم
الشروط اللاحقة
  • المستخدم يعلم أن هناك مشكلة في إرسال OTP ويمكنه إعادة المحاولة
تسلسل الأحداث
  • المستخدم يطلب إرسال OTP
  • النظام يحاول إرسال OTP إلى رقم الهاتف المدخل
  • في حالة فشل الإرسال، يعرض النظام رسالة خطأ
الخطوات الاستثنائيةفشل إرسال OTP بسبب مشكلات في الشبكة أو خطأ في رقم الهاتف
  • النظام يعرض رسالة خطأ
  • النظام يقترح إعادة المحاولة أو التحقق من رقم الهاتف
القواعد التجارية
  • OTP صالح لمدة 3 دقائق فقط
  • النظام يجب أن يتأكد من صحة رقم الهاتف المدخل
الافتراضات
  • المستخدم يتذكر رقم الهاتف المسجل في النظام
  • المستخدم لديه وصول إلى الهاتف المسجل لاستلام OTP
المتطلبات الخاصة
  • النظام يجب أن يكون قادرًا على اكتشاف مشكلات الشبكة أو أخطاء رقم الهاتف
  • توفير واجهة سهلة الاستخدام لإعادة المحاولة
الملاحظات والمشاكل
  • قد يواجه المستخدمون مشكلات في استلام OTP بسبب مشاكل في الشبكة أو رقم الهاتف غير صحيح
المدخلاترقم الهاتف |
المخرجات
  • رسالة خطأ في حال فشل الإرسال
تفاعلات المستخدم
  • النظام يعرض واجهة إدخال رقم الهاتف
  • النظام يعرض رسالة خطأ في حال فشل الإرسال
الشروط الخاصة
  • فشل النظام في إرسال OTP
سيناريوهات الاستخدام
  • كمستخدم، إذا فشل إرسال OTP بسبب مشكلة في الشبكة أو خطأ في رقم الهاتف، أريد أن أستلم رسالة خطأ تشرح المشكلة وتتيح لي إعادة المحاولة
متطلبات الأمان
  • OTP يتم إرسالها عبر قناة آمنة
  • تشفير البيانات الحساسة مثل OTP
التكامل مع الأنظمة الأخرى
  • تكامل مع نظام الرسائل النصية لإرسال OTP
  • تكامل مع النظام الأساسي للتحقق من صحة البيانات
القيود والافتراضات
  • يجب أن يكون للمستخدم رقم هاتف صالح مسجل في النظام
  • يجب أن يكون هناك تكامل موثوق مع خدمة الرسائل النصية
متطلبات الاختبار
  • اختبارات وظيفية للتحقق من إرسال OTP واستلامها
  • اختبارات أمان للتأكد من حماية البيانات الحساسة
تفاصيل ال API
Method: POST || Endpoint: /send-otp
Request Headers
Content-Type: application/json

Request Body

phone_number: نص

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة إرسال رمز التحقق

  • textblock
    • Enter your phone number to receive OTP

  • form
    • text
      • العنوان : رقم الهاتف
      • التحقق : required|phone
  • رسالة زر الإرسال: Send OTP
الاشعارات

العنوان : فشل إرسال رمز التحقق
الرسالة : واجهنا مشكلة أثناء إرسال رمز التحقق. يرجى المحاولة مرة أخرى
عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : المستخدم

3.6 - تسجيل المركبات

3.6.1 المعلومات العامة

العنوان التفاصيل
أهداف العمل
  • ضمان أن مقدمي خدمة النقل مستعدون بشكل كافي ولديهم المركبات اللازمة للقيام بعمليات النقل
  • أن المركبات لديها التراخيص القانونية وتلبي معايير الجودة والسلامة المطلوبة
الجهات المعنية
  • مقدم خدمة النقل (المستخدم)
الخطوات الرئيسية
  • التحقق من أن المستخدم مقدم خدمة نقل
  • تقديم خيارات لإدخال معلومات السيارة / السيارات المستخدمة في النقل
  • التحقق من صحة المعلومات المقدمة والوثائق المرفقة
الخطوات البديلة
  • في حالة كانت وثائق السيارة غير صحيحة، يتم تقديم رسالة خطأ مع توضيح الخطأ وطلب تصحيحه
قصص المستخدمين
  • كمقدم خدمة نقل فردي، أريد إمكانية إضافة معلومات سيارتي ورفع الوثائق المطلوبة، لكي أثبت صلاحية سيارتي لأداء عمليات النقل
  • كمقدم خدمة نقل تابع إلى (مؤسسة - شركة)، أريد إمكانية إضافة معلومات السيارة التي أعمل عليها وإرفاقها إلى أسطول الشركة التي أعمل لديها
  • كمقدم خدمة نقل أعمل كسائق، في حالة وجود أي أخطاء في البيانات أو الوثائق المرفقة، أرغب في تلقي رسالة خطأ توضح المشكلة، حتى أتمكن من تصحيحها واستكمال التسجيل
  • كشركة نقل، أرغب في القدرة على إضافة عدد غير محدود من السيارات، لكي أتمكن من تسجيل كل السيارات التي تعتبر جزءًا من أسطول الشركة
مؤشرات الأداء
  • عدد المركبات المسجلة حسب تصنيف فئات محدد (نوع المركبة، حجم المركبة، موديل المركبة...)
  • عدد المركبات المسجلة والتي لا يمكنها ممارسة الأعمال بسبب أحد الوثائق المسجلة (انتهاء الصلاحية، عدم تقديم المستند...)

3.6.2 حالات الاستخدام

3.6.2.1- يتمكن مقدم خدمة النقل من إضافة مركبة جديدة إلى نظام التسجيل من خلال إدخال المعلومات اللازمة ورفع الوثائق المطلوبة للتحقق من صحة المركبة

graph LR; A[Service Provider logs into vehicle management page] --> B[Selects 'Add New Vehicle']; B --> C[Enters vehicle details and uploads documents]; C --> D[System verifies information and documents]; D --> E{Are the details correct?}; E -->|Yes| F[Vehicle added to the system]; E -->|No| G[System displays error message]; G --> H[Service Provider corrects information and retries];
العنوانالتفاصيل
المستخدممقدم خدمة النقل
الشروط المسبقة
  • وجود حساب لمقدم خدمة النقل على النظام
  • توفر الوثائق المطلوبة للمركبة
الشروط اللاحقة
  • تم إضافة السيارة الجديدة إلى نظام التسجيل بنجاح
تسلسل الأحداث
  • مقدم خدمة النقل يدخل إلى صفحة إدارة المركبات
  • يختار خيار 'إضافة مركبة جديدة'
  • يدخل معلومات السيارة
  • يرفع الوثائق المطلوبة
  • النظام يتحقق من صحة المعلومات والوثائق
  • يتم إضافة السيارة الجديدة إلى النظام
الخطوات البديلةمقدم خدمة النقل لم يتمكن من رفع الوثائق
  • النظام يعرض رسالة توضح المشكلة
  • مقدم خدمة النقل يعيد المحاولة أو يتواصل مع الدعم الفني
الخطوات الاستثنائيةالمعلومات المدخلة غير صحيحة
  • النظام يعرض رسالة خطأ توضح المشكلة
  • مقدم خدمة النقل يصحح المعلومات المدخلة ويحاول مرة أخرى
القواعد التجارية
  • يجب أن تكون المركبة مسجلة بشكل قانوني وصالحة للاستخدام في النقل
  • جميع الوثائق المرفقة يجب أن تكون سارية المفعول
الافتراضات
  • مقدم خدمة النقل لديه جميع الوثائق المطلوبة جاهزة للرفع
  • النظام قادر على التحقق من صحة المعلومات والوثائق بسرعة
المتطلبات الخاصة
  • واجهة سهلة الاستخدام لإدخال معلومات السيارة ورفع الوثائق
  • نظام سريع ودقيق للتحقق من صحة الوثائق
الملاحظات والمشاكل
  • قد يواجه مقدم خدمة النقل مشكلات في رفع الوثائق بسبب حجم الملف أو صيغة الوثيقة
المدخلاتنوع السيارة | رقم اللوحة | السنة | موديل السيارة | رخصة المركبة | تأمين المركبة |
المخرجات
  • رسالة تأكيد إضافة السيارة الجديدة إلى النظام
تفاعلات المستخدم
  • النظام يعرض واجهة إدخال معلومات السيارة ورفع الوثائق
  • النظام يعرض رسالة تأكيد بعد التحقق من صحة المعلومات والوثائق
الشروط الخاصة
  • فشل النظام في التحقق من صحة الوثائق
  • عدم قدرة مقدم خدمة النقل على رفع الوثائق بسبب مشاكل تقنية
سيناريوهات الاستخدام
  • كمقدم خدمة نقل، أريد إضافة مركبة جديدة إلى النظام بإدخال المعلومات المطلوبة ورفع الوثائق اللازمة للتحقق من صحتها
متطلبات الأمان
  • تشفير البيانات الحساسة مثل معلومات السيارة والوثائق المرفقة
  • التحقق من صلاحية الوثائق والتأكد من عدم تزويرها
التكامل مع الأنظمة الأخرى
  • تكامل مع نظام إدارة الوثائق للتحقق من صحة الوثائق المرفقة
  • تكامل مع نظام إدارة المركبات لتسجيل السيارة الجديدة
القيود والافتراضات
  • يجب أن يكون للمستخدم حساب صالح كمقدم خدمة نقل
  • يجب أن تكون جميع الوثائق سارية المفعول وصالحة للاستخدام
متطلبات الاختبار
  • اختبارات وظيفية للتحقق من إمكانية إضافة مركبة جديدة بنجاح
  • اختبارات أمان للتأكد من حماية البيانات الحساسة والوثائق المرفقة
تفاصيل ال API
Method: POST || Endpoint: /add-vehicle
Request Headers
Content-Type: application/json

Request Body

vehicle_type: نص new_vehicle_type: نص license_plate: نص year: نص model: نص license_document: file insurance_document: file

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة إضافة مركبة

  • textblock
    • Enter the vehicle details and upload the required documents

  • form
    • select
      • العنوان : نوع المركبة
      • التحقق : required
      • الخيارات : [ { "label": "نوع المركبة", "value": " قيمة نوع المركبة" }, { "label": " أخرى", "value": "other" } ]
    • text
      • العنوان : نوع مركبة جديد
    • text
      • العنوان : لوحة الترخيص
      • التحقق : {"required":true,"pattern":"^[\u0600-\u06FF\u0750-\u077FA-Za-z]{1,8}\s?\d{1,9}\s?[A-Za-z\u0600-\u06FF\u0750-\u077F]{0,8}$"}
    • text
      • العنوان : السنة
      • التحقق : {"required"}
    • text
      • العنوان : الطراز
      • التحقق : required
    • file
      • العنوان : وثيقة الترخيص
      • التحقق : required
    • file
      • العنوان : وثيقة التأمين
      • التحقق : required
  • رسالة زر الإرسال: Add Vehicle
الاشعارات

العنوان : تمت إضافة المركبة بنجاح
الرسالة : تمت إضافة مركبتك إلى النظام بنجاح
عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : مقدم خدمة النقل

العنوان : إقتراح نوع مركبة جديد
الرسالة : تم اقتراح نوع جديد لمركبة يرجى الإطلاع عليه وتأكيد صحته لإضافته على النظام
عن طريق : الاشعارات داخل التطبيق, ايميل  المستقبل : المسؤول

3.6.2.2- تعديل معلومات سيارة مسجلة مسبقًا

graph LR A[مقدم خدمة النقل يسجل الدخول إلى النظام] --> B[مقدم خدمة النقل يذهب إلى صفحة إدارة المركبات] B --> C[مقدم خدمة النقل يختار السيارة المراد تعديلها] C --> D[مقدم خدمة النقل يقوم بتعديل المعلومات المطلوبة] D --> E[مقدم خدمة النقل يرفع الوثائق الجديدة إن وجدت] E --> F[مقدم خدمة النقل يحفظ التعديلات] F --> G[النظام يتحقق من صحة الوثائق الجديدة] G --> H[في حالة صحة الوثائق يتم تحديث معلومات السيارة] H --> I[إشعار الإداريين بالتعديلات الجديدة] G --> J[في حال فشل التحقق من صحة الوثائق الجديدة عرض رسالة خطأ] J --> K[طلب إعادة تحميل وثائق صالحة] C --> L[في حالة عدم وجود سيارة مسجلة مسبقًا عرض رسالة خطأ] L --> M[إعطاء المستخدم خيارًا لتسجيل سيارة جديدة]
العنوانالتفاصيل
المستخدممقدم خدمة النقل
الشروط المسبقة
  • وجود حساب لمقدم خدمة النقل على النظام
  • وجود سيارة مسجلة مسبقًا في النظام
الشروط اللاحقة
  • تحديث معلومات السيارة في النظام
  • إمكانية رؤية التحديثات في تفاصيل السيارة
تسلسل الأحداث
  • مقدم خدمة النقل يسجل الدخول إلى النظام
  • مقدم خدمة النقل يذهب إلى صفحة إدارة المركبات
  • مقدم خدمة النقل يختار السيارة المراد تعديلها
  • مقدم خدمة النقل يقوم بتعديل المعلومات المطلوبة
  • مقدم خدمة النقل يرفع الوثائق الجديدة (إن وجدت)
  • مقدم خدمة النقل يحفظ التعديلات
  • النظام يتحقق من صحة الوثائق الجديدة
  • في حالة صحة الوثائق، يتم تحديث معلومات السيارة
  • إشعار الإداريين بالتعديلات الجديدة
الخطوات البديلةفي حالة عدم وجود سيارة مسجلة مسبقًا
  • عرض رسالة خطأ توضح عدم وجود سيارة مسجلة مسبقًا
  • إعطاء المستخدم خيارًا لتسجيل سيارة جديدة
الخطوات الاستثنائيةفي حال فشل التحقق من صحة الوثائق الجديدة
  • عرض رسالة خطأ توضح أن الوثائق الجديدة غير صالحة
  • طلب إعادة تحميل وثائق صالحة
القواعد التجارية
  • يجب أن تكون جميع الوثائق المرفوعة صالحة وحديثة
الافتراضات
  • مقدم خدمة النقل لديه حساب نشط ومسجل
  • السيارة المطلوب تعديل معلوماتها مسجلة مسبقًا في النظام
المتطلبات الخاصة
  • يجب أن يكون التعديل متاحًا فقط للمستخدمين المصرح لهم
الملاحظات والمشاكل
  • قد يحتاج النظام إلى إرسال إشعار إلى الإداريين لمراجعة التعديلات على السيارة
المدخلاتمعلومات السيارة الجديدة (مثل رقم اللوحة، السنة، موديل السيارة) | وثائق السيارة الجديدة (إن وجدت) |
المخرجات
  • معلومات السيارة المحدثة
  • إشعار الإداريين بالتعديلات
تفاعلات المستخدم
  • شاشة إدارة المركبات
  • نموذج تعديل معلومات السيارة
الشروط الخاصة
  • في حالة تغيير كامل للمعلومات (مثل تبديل السيارة)، يجب إجراء عملية تسجيل جديدة للسيارة
سيناريوهات الاستخدام
  • مقدم خدمة النقل يريد تحديث رقم اللوحة لسيارة مسجلة مسبقًا
  • مقدم خدمة النقل يريد تحديث وثائق السيارة مثل رخصة المركبة
متطلبات الأمان
  • يجب التحقق من هوية مقدم خدمة النقل قبل السماح بتعديل معلومات السيارة
التكامل مع الأنظمة الأخرى
  • التحقق من الوثائق الجديدة من خلال قواعد بيانات الجهات المعنية
القيود والافتراضات
  • يجب أن تكون المعلومات المحدثة مطابقة للمعايير القانونية والتنظيمية
متطلبات الاختبار
  • اختبارات وظيفية للتأكد من إمكانية تعديل المعلومات وحفظها بشكل صحيح
  • اختبارات أمنية لضمان حماية البيانات ومنع التلاعب
تفاصيل ال API
Method: PUT || Endpoint: /vehicles/{vehicle_id}
Request Headers
Authorization: Bearer token

Request Body

license_plate: نص year: integer model: نص documents: array

Response

الحالةالمحتوى
200status: نص vehicle: object
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
إدارة المركبات

  • form
    • text
      • العنوان : رقم اللوحة
      • التحقق : {required | ^[\u0600-\u06FF\u0750-\u077F]{1,3}\s?\d{1,4}\s?[A-Za-z\u0600-\u06FF\u0750-\u077F]{0,3}$ }
    • number
      • العنوان : السنة
      • التحقق : {"required":true,"min":1900,"max":2100}
    • text
      • العنوان : موديل السيارة
      • التحقق : {"required":true}
    • file
      • العنوان : وثائق السيارة
      • التحقق : {"required":false,"accept":"image\/*,application\/pdf"}
  • رسالة زر الإرسال: حفظ التعديلات
  • رسالة النجاح: تم تحديث معلومات السيارة بنجاح
  • إعادة توجيه النجاح: VehicleDetails
الاشعارات

العنوان : تحديث معلومات السيارة
الرسالة : تم تحديث معلومات السيارة. يرجى مراجعة التعديلات
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : إداري النظام

3.6.2.3- التحقق من صحة وثائق سيارة مسجلة

graph LR; A[إداري النظام يسجل الدخول إلى النظام] --> B[إداري النظام يذهب إلى صفحة إدارة المركبات]; B --> C[إداري النظام يختار السيارة المراد التحقق من وثائقها]; C --> D[إداري النظام يتحقق من صحة الوثائق المرفقة]; D --> E[إداري النظام يعرض رسالة الخطأ ويطلب الوثائق الصحيحة في حالة وجود مشكلات]; E --> F[إداري النظام يؤكد صحة الوثائق في حالة عدم وجود مشكلات];
العنوانالتفاصيل
المستخدمإداري النظام
الشروط المسبقة
  • وجود حساب إداري على النظام
  • وجود سيارة مسجلة ضمن النظام
الشروط اللاحقة
  • التأكد من صحة وثائق السيارة
  • إبلاغ مقدم خدمة النقل في حال وجود أي مشكلات في الوثائق
تسلسل الأحداث
  • إداري النظام يسجل الدخول إلى النظام
  • إداري النظام يذهب إلى صفحة إدارة المركبات
  • إداري النظام يختار السيارة المطلوب التحقق من وثائقها
  • إداري النظام يتحقق من صحة الوثائق المرفقة
  • إداري النظام يعرض رسالة الخطأ ويطلب الوثائق الصحيحة في حالة وجود مشكلات
  • إداري النظام يؤكد صحة الوثائق في حالة عدم وجود مشكلات
الخطوات البديلةفي حال عدم وجود وثائق السيارة أو فقدانها
  • إداري النظام يعرض رسالة خطأ توضح عدم وجود وثائق السيارة
  • إداري النظام يطلب من مقدم خدمة النقل تحميل الوثائق المفقودة أو المحدثة
الخطوات الاستثنائيةفي حال فشل التحقق من صحة الوثائق
  • إداري النظام يعرض رسالة خطأ توضح أن الوثائق غير صالحة
  • إداري النظام يطلب من مقدم خدمة النقل إعادة تحميل الوثائق الصحيحة
القواعد التجارية
  • يجب أن تكون جميع الوثائق المرفوعة صالحة وحديثة
الافتراضات
  • إداري النظام لديه الصلاحيات اللازمة للتحقق من الوثائق
  • الوثائق المرفوعة من قبل مقدم خدمة النقل دقيقة وكاملة
المتطلبات الخاصة
  • يجب أن يكون التحقق من الوثائق سريعًا ودقيقًا لتجنب تأخير عمليات النقل
الملاحظات والمشاكل
  • قد يتطلب النظام توفير آلية للتحقق من صحة الوثائق بشكل أوتوماتيكي من قواعد بيانات الجهات المعنية
المدخلاتوثائق السيارة (رخصة المركبة، تأمين المركبة) |
المخرجات
  • تأكيد صحة الوثائق
  • رسالة خطأ توضح المشكلات (إن وجدت)
تفاعلات المستخدم
  • شاشة إدارة المركبات
  • نموذج التحقق من الوثائق
الشروط الخاصة
  • في حال رفض الوثائق بشكل متكرر، قد يتم تعليق حساب مقدم خدمة النقل حتى يتم تقديم الوثائق الصحيحة
سيناريوهات الاستخدام
  • إداري النظام يريد التحقق من صحة رخصة المركبة لمقدم خدمة النقل
  • إداري النظام يريد التحقق من صحة وثيقة تأمين المركبة
متطلبات الأمان
  • يجب التأكد من أن الوثائق المرفوعة محفوظة بأمان ولا يمكن التلاعب بها
التكامل مع الأنظمة الأخرى
  • التحقق من الوثائق عبر قواعد بيانات الجهات المعنية
القيود والافتراضات
  • يجب أن تكون الوثائق المقدمة قانونية وصحيحة
متطلبات الاختبار
  • اختبارات وظيفية للتأكد من إمكانية التحقق من الوثائق وحفظها بشكل صحيح
  • اختبارات أمنية لضمان حماية الوثائق ومنع التلاعب
تفاصيل ال API
Method: GET || Endpoint: /vehicles/{vehicle_id}/documents
Request Headers
Authorization: Bearer token

Request Body

Response

الحالةالمحتوى
200status: نص documents: array
الوصف: Success
400
الوصف: Bad Request

Method: PUT || Endpoint: /vehicles/{vehicle_id}/documents
Request Headers
Authorization: Bearer token

Request Body

documents: array

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
إدارة المركبات

  • list
    • النوع : title: رخصة المركبة content-render-format: link

    • النوع : title: تأمين المركبة content-render-format: link

  • form
    • file
      • العنوان : تحميل وثائق جديدة
      • التحقق : {"required":true,"accept":"image\/*,application\/pdf"}
  • رسالة زر الإرسال: حفظ الوثائق
  • رسالة النجاح: تم تحديث وثائق السيارة بنجاح
  • إعادة توجيه النجاح: VehicleDetails
الاشعارات

العنوان : تحقق من صحة الوثائق
الرسالة : تم التحقق من صحة وثائق سيارتك. يرجى مراجعة النظام للمزيد من التفاصيل
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : مقدم خدمة النقل

العنوان : تحقق من صحة الوثائق
الرسالة : تم التحقق من صحة وثائق السيارة بنجاح
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : إداري النظام

3.7 - إضافة معلومات السائقين وربطهم بالسيارات

3.7.1 المعلومات العامة

العنوان التفاصيل
أهداف العمل
  • تحقيق القدرة على تقديم معلومات دقيقة للعملاء حول السائقين والسيارات المتوفرة لخدمات النقل
الجهات المعنية
  • مقدمي الخدمات (شركات النقل)
الخطوات الرئيسية
  • مقدم الخدمة يدخل إلى صفحة إدارة السائقين
  • يختار إضافة سائق جديد
  • يدخل معلومات السائق (اسم السائق، رقم الهاتف، العنوان، رقم الرخصة، صورة الرخصة)
  • يتم ربط السائق مع سيارة محددة من قائمة السيارات المتاحة له
الخطوات البديلة
  • مقدم الخدمة يستطيع تعديل معلومات السائق أو فصله عن السيارة في أي وقت
قصص المستخدمين
  • مقدم الخدمة: يرغب في إضافة سائق جديد، لذا يقوم بدخول صفحة إدارة السائقين، يضغط على إضافة سائق جديد، يملأ معلومات السائق ويربطه بالسيارة المناسبة
  • مقدم الخدمة: يرغب في تعديل معلومات سائق، يقوم بالدخول إلى صفحة إدارة السائقين، يبحث عن السائق المطلوب، يقوم بتعديل المعلومات المطلوبة
  • مقدم الخدمة: يرغب في فصل سائق عن سيارة، يقوم بالدخول إلى صفحة إدارة السائقين، يبحث عن السائق المطلوب، يقوم بفصل السائق عن السيارة
مؤشرات الأداء
  • عدد المركبات المضافة من شركات النقل
  • عدد المركبات المضافة والغير مرتبطة بسائقين

3.7.2 حالات الاستخدام

3.7.2.1- إضافة سائق جديد إلى نظام إدارة السائقين وربطه بسيارة متاحة

graph LR; A[مقدم الخدمة يدخل إلى صفحة إدارة السائقين] --> B[اختيار خيار إضافة سائق جديد]; B --> C[إدخال معلومات السائق]; C --> D[ربط السائق بسيارة محددة من قائمة السيارات المتاحة]; D --> E[النظام يؤكد عملية الربط]
العنوانالتفاصيل
المستخدممقدم الخدمة
الشروط المسبقة
  • وجود حساب لمقدم الخدمة على النظام
  • وجود سيارات متاحة ضمن حساب مقدم الخدمة
الشروط اللاحقة
  • إضافة السائق الجديد وربطه بسيارة محددة
  • إمكانية تعديل معلومات السائق أو فصله عن السيارة في المستقبل
تسلسل الأحداث
  • مقدم الخدمة يفتح صفحة إدارة السائقين
  • النظام يعرض خيار 'إضافة سائق جديد'
  • مقدم الخدمة يدخل معلومات السائق
  • النظام يتحقق من صحة المعلومات
  • النظام يعرض قائمة السيارات المتاحة
  • مقدم الخدمة يختار سيارة لربطها بالسائق
  • النظام يؤكد عملية الربط
الخطوات البديلةإذا كانت معلومات السائق غير مكتملة أو غير صحيحة
  • النظام يعرض رسالة خطأ توضح المشكلة
  • مقدم الخدمة يقوم بتصحيح المعلومات
  • مقدم الخدمة يحاول إعادة إدخال السائق
الخطوات الاستثنائيةإذا لم تكن هناك سيارات متاحة ضمن حساب مقدم الخدمة
  • النظام يعرض رسالة توضح عدم توفر سيارات
  • مقدم الخدمة يتأكد من إضافة سيارات إلى حسابه
  • مقدم الخدمة يحاول إعادة ربط السائق بعد إضافة السيارات
القواعد التجارية
  • يجب أن يكون السائق مسجلاً بشكل صحيح برخصة قيادة سارية المفعول
  • يجب أن تكون السيارة المربوطة بالسائق مؤهلة وموجودة في النظام
الافتراضات
  • مقدم الخدمة لديه صلاحية إضافة سائقين وربطهم بسيارات ضمن النظام
  • السائق يمتلك كافة الوثائق والمعلومات اللازمة
المتطلبات الخاصة
  • يجب أن يكون النظام قادرًا على معالجة الصور المرفوعة لمستندات السائق
الملاحظات والمشاكل
  • تحتاج إلى التأكد من صحة المعلومات المدخلة لتجنب الأخطاء في الربط بين السائقين والسيارات
المدخلاتاسم السائق | رقم الهاتف | العنوان | رقم الرخصة | صورة الرخصة |
المخرجات
  • تأكيد إضافة السائق وربطه بسيارة
  • رسائل خطأ في حالة وجود معلومات غير صحيحة أو غير مكتملة
تفاعلات المستخدم
  • واجهة إدخال معلومات السائق
  • قائمة السيارات المتاحة
  • رسائل التأكيد والخطأ
الشروط الخاصة
  • إذا كانت السيارة المربوطة بالسائق تحتاج إلى صيانة أو غير صالحة للاستخدام، يجب تحديث حالتها في النظام
سيناريوهات الاستخدام
  • إضافة سائق جديد وربطه بسيارة لنقل البضائع في يوم محدد
  • تعديل معلومات سائق موجود وربطه بسيارة مختلفة بناءً على متطلبات العمل
متطلبات الأمان
  • يجب التحقق من صحة المستندات المرفوعة وضمان عدم التلاعب بها
  • يجب حماية البيانات الشخصية للسائقين ومقدمي الخدمة
التكامل مع الأنظمة الأخرى
  • النظام يجب أن يتكامل مع قواعد بيانات إدارة السائقين والسيارات
  • التكامل مع نظام التحقق من صحة رخص القيادة
القيود والافتراضات
  • النظام يعمل ضمن حدود عدد معين من السائقين والسيارات لكل مقدم خدمة
  • النظام يفترض صحة البيانات المدخلة من قبل مقدمي الخدمة
متطلبات الاختبار
  • اختبارات وظيفة الإدخال والتحقق من المعلومات
  • اختبارات ربط السائقين بالسيارات بشكل صحيح
  • اختبارات الأداء لضمان سرعة استجابة النظام
تفاصيل ال API
Method: POST || Endpoint: /drivers/add
Request Headers
Authorization: Bearer token

Request Body

name: نص phone: نص address: نص license_number: نص license_image: file

Response

الحالةالمحتوى
200status: نص driver_id: نص
الوصف: Success
400
الوصف: Bad Request

Method: POST || Endpoint: /drivers/link
Request Headers
Authorization: Bearer token

Request Body

driver_id: نص vehicle_id: نص

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
إدارة السائقين

  • list
    • النوع : title: قائمة السائقين Items :

  • form
    • text
      • العنوان : اسم السائق
      • التحقق : {"required":true,"minLength":2}
    • text
      • العنوان : رقم الهاتف
      • التحقق : {"required":true,"pattern":"^d{10}$"}
    • text
      • العنوان : العنوان
      • التحقق : {"required":true}
    • text
      • العنوان : رقم الرخصة
      • التحقق : {"required":true}
    • file
      • العنوان : صورة الرخصة
      • التحقق : {"required":true}
  • رسالة زر الإرسال: إضافة سائق
  • رسالة النجاح: تم إضافة السائق بنجاح
  • إعادة توجيه النجاح: DriverList
الاشعارات

العنوان : تم إضافة سائق جديد
الرسالة : تم إضافة السائق بنجاح وربطه بسيارة محددة
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : مقدم الخدمة

3.7.2.2- تعديل معلومات سائق موجود في نظام إدارة السائقين

graph LR; A[مقدم الخدمة يدخل إلى صفحة إدارة السائقين] --> B[البحث عن السائق المطلوب]; B --> C[تعديل المعلومات المطلوبة]; C --> D[حفظ التعديلات]
العنوانالتفاصيل
المستخدممقدم الخدمة
الشروط المسبقة
  • وجود حساب لمقدم الخدمة على النظام
  • وجود سائق مسجل مسبقًا في النظام
الشروط اللاحقة
  • تحديث معلومات السائق في النظام
  • إمكانية رؤية التحديثات في تفاصيل السائق
تسلسل الأحداث
  • مقدم الخدمة يفتح صفحة إدارة السائقين
  • النظام يعرض قائمة السائقين المسجلين
  • مقدم الخدمة يبحث عن السائق المطلوب
  • مقدم الخدمة يقوم بتعديل المعلومات
  • النظام يتحقق من صحة المعلومات
  • النظام يحفظ التعديلات
الخطوات البديلةإذا كانت المعلومات المدخلة غير صحيحة أو غير كاملة
  • النظام يعرض رسالة خطأ توضح المشكلة
  • مقدم الخدمة يقوم بتصحيح المعلومات
  • مقدم الخدمة يحاول حفظ التعديلات مجددًا
الخطوات الاستثنائيةإذا لم يتم العثور على السائق المطلوب
  • النظام يعرض رسالة تفيد بعدم وجود السائق في النظام
  • مقدم الخدمة يتحقق من المعلومات المدخلة
  • مقدم الخدمة يحاول البحث مجددًا باستخدام معلومات صحيحة
القواعد التجارية
  • يجب أن تكون المعلومات المدخلة للسائق صحيحة ومحدثة
  • يجب أن يتوافق السائق مع متطلبات النظام الحالية
الافتراضات
  • مقدم الخدمة لديه صلاحية تعديل معلومات السائقين
  • معلومات السائق المدخلة تتوافق مع المتطلبات القانونية
المتطلبات الخاصة
  • يجب أن يكون النظام قادرًا على معالجة الصور والوثائق المرفوعة بشكل صحيح
الملاحظات والمشاكل
  • تأكد من صحة المعلومات المدخلة لتجنب الأخطاء في النظام
المدخلاتاسم السائق | رقم الهاتف | العنوان | رقم الرخصة | صورة الرخصة |
المخرجات
  • تأكيد تعديل معلومات السائق
  • رسائل خطأ في حالة وجود معلومات غير صحيحة أو غير مكتملة
تفاعلات المستخدم
  • واجهة تعديل معلومات السائق
  • قائمة السائقين المسجلين
  • رسائل التأكيد والخطأ
الشروط الخاصة
  • إذا كان السائق يحتاج إلى تحديث مستنداته، يجب تحديثها في النظام
سيناريوهات الاستخدام
  • تعديل معلومات سائق موجود لتحديث رقم الهاتف أو العنوان
  • إضافة أو تحديث صورة رخصة السائق في النظام
متطلبات الأمان
  • يجب التحقق من صحة المستندات المرفوعة وضمان عدم التلاعب بها
  • يجب حماية البيانات الشخصية للسائقين ومقدمي الخدمة
التكامل مع الأنظمة الأخرى
  • النظام يجب أن يتكامل مع قواعد بيانات إدارة السائقين والسيارات
  • التكامل مع نظام التحقق من صحة رخص القيادة
القيود والافتراضات
  • النظام يعمل ضمن حدود عدد معين من السائقين لكل مقدم خدمة
  • النظام يفترض صحة البيانات المدخلة من قبل مقدمي الخدمة
متطلبات الاختبار
  • اختبارات وظيفة الإدخال والتحقق من المعلومات
  • اختبارات تعديل السائقين وربطهم بسيارات بشكل صحيح
  • اختبارات الأداء لضمان سرعة استجابة النظام
تفاصيل ال API
Method: PUT || Endpoint: /drivers/update
Request Headers
Authorization: Bearer token

Request Body

driver_id: نص name: نص phone: نص address: نص license_number: نص license_image: file

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
إدارة السائقين

  • list
    • النوع : title: قائمة السائقين Items :

  • form
    • text
      • العنوان : اسم السائق
      • التحقق : {"required":true,"minLength":2}
    • text
      • العنوان : رقم الهاتف
      • التحقق : {"required":true,"pattern":"^d{10}$"}
    • text
      • العنوان : العنوان
      • التحقق : {"required":true}
    • text
      • العنوان : رقم الرخصة
      • التحقق : {"required":true}
    • file
      • العنوان : صورة الرخصة
      • التحقق : {"required":true}
  • رسالة زر الإرسال: تعديل معلومات السائق
  • رسالة النجاح: تم تعديل معلومات السائق بنجاح
  • إعادة توجيه النجاح: DriverList
الاشعارات

العنوان : تم تعديل معلومات السائق
الرسالة : تم تعديل معلومات السائق بنجاح
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : مقدم الخدمة

3.7.2.3- فصل سائق عن سيارة في نظام إدارة السائقين

graph LR; A[مقدم الخدمة يدخل إلى صفحة إدارة السائقين] --> B[البحث عن السائق المطلوب]; B --> C[فصل السائق عن السيارة]; C --> D[النظام يحدّث حالة السيارة لإظهار أنها غير مرتبطة بسائق]
العنوانالتفاصيل
المستخدممقدم الخدمة
الشروط المسبقة
  • وجود حساب لمقدم الخدمة على النظام
  • وجود سائق مسجل ومربوط بسيارة ضمن النظام
الشروط اللاحقة
  • فصل السائق عن السيارة المحددة
  • تحديث الحالة في النظام لإظهار أن السيارة غير مرتبطة بسائق
تسلسل الأحداث
  • مقدم الخدمة يفتح صفحة إدارة السائقين
  • النظام يعرض قائمة السائقين المسجلين
  • مقدم الخدمة يبحث عن السائق المطلوب
  • مقدم الخدمة يقوم بفصل السائق عن السيارة
  • النظام يحدّث حالة السيارة لإظهار أنها غير مرتبطة بسائق
الخطوات البديلةإذا لم تكن السيارة المربوطة بالسائق موجودة أو غير صالحة للاستخدام
  • النظام يعرض رسالة خطأ توضح المشكلة
  • مقدم الخدمة يتحقق من حالة السيارة
  • مقدم الخدمة يحاول إعادة فصل السائق بعد حل المشكلة
الخطوات الاستثنائيةإذا لم يتم العثور على السائق المطلوب
  • النظام يعرض رسالة تفيد بعدم وجود السائق في النظام
  • مقدم الخدمة يتحقق من المعلومات المدخلة
  • مقدم الخدمة يحاول البحث مجددًا باستخدام معلومات صحيحة
القواعد التجارية
  • يجب أن تكون السيارة بحالة جيدة وصالحة للاستخدام بعد فصل السائق
  • يجب أن يكون لدى السائق إمكانية التسجيل مع سيارة أخرى إذا لزم الأمر
الافتراضات
  • مقدم الخدمة لديه صلاحية فصل السائقين عن السيارات
  • السيارة ستكون متاحة للاستخدام بعد فصل السائق
المتطلبات الخاصة
  • يجب أن يكون النظام قادرًا على تحديث حالة السيارة بشكل فوري
الملاحظات والمشاكل
  • تأكد من صحة المعلومات المدخلة لتجنب الأخطاء في النظام
المدخلاتاسم السائق | رقم السيارة أو معرف السيارة |
المخرجات
  • تأكيد فصل السائق عن السيارة
  • رسائل خطأ في حالة وجود معلومات غير صحيحة أو غير كاملة
تفاعلات المستخدم
  • واجهة فصل السائق عن السيارة
  • قائمة السائقين المسجلين
  • رسائل التأكيد والخطأ
الشروط الخاصة
  • إذا كانت السيارة تحتاج إلى صيانة بعد فصل السائق، يجب تحديث حالتها في النظام
سيناريوهات الاستخدام
  • فصل سائق عن سيارة بناءً على طلب السائق أو متطلبات العمل
  • تحديث معلومات السائق وربطه بسيارة أخرى إذا لزم الأمر
متطلبات الأمان
  • يجب التحقق من صحة البيانات المدخلة وضمان عدم التلاعب بها
  • يجب حماية البيانات الشخصية للسائقين ومقدمي الخدمة
التكامل مع الأنظمة الأخرى
  • النظام يجب أن يتكامل مع قواعد بيانات إدارة السائقين والسيارات
  • التكامل مع نظام تتبع حالة السيارات
القيود والافتراضات
  • النظام يعمل ضمن حدود عدد معين من السائقين لكل مقدم خدمة
  • النظام يفترض صحة البيانات المدخلة من قبل مقدمي الخدمة
متطلبات الاختبار
  • اختبارات وظيفة فصل السائق عن السيارة
  • اختبارات تحديث حالة السيارة في النظام
  • اختبارات الأداء لضمان سرعة استجابة النظام
تفاصيل ال API
Method: POST || Endpoint: /drivers/unlink
Request Headers
Authorization: Bearer token

Request Body

driver_id: نص vehicle_id: نص

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
إدارة السائقين

  • list
    • النوع : name: اسم السائق label: فصل عن السيارة onClick: unlinkDriver

الاشعارات

العنوان : تم فصل السائق عن السيارة
الرسالة : تم فصل السائق عن السيارة بنجاح
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : مقدم الخدمة

3.8 - إضافة معلومات محطات الوقود

3.8.1 المعلومات العامة

العنوان التفاصيل
أهداف العمل
  • تزويد المستخدمين بأماكن محطات الوقود المحلية وتقديم معلومات مفصلة عنها لتعزيز التجربة الكلية للمستخدم وتوفير خدمات الدعم التقني
الجهات المعنية
  • مقدمي الخدمات المتخصصة (أصحاب محطات الوقود)
الخطوات الرئيسية
  • يدخل مالك المحطة إلى صفحة إدارة المحطات
  • يختار إضافة محطة جديدة
  • يدخل معلومات المحطة (اسم الفرع، العنوان)
  • يحدد الإحداثيات على الخريطة
الخطوات البديلة
  • يستطيع مالك المحطة تعديل معلومات المحطة أو تحديث موقعها على الخريطة في أي وقت
قصص المستخدمين
  • مالك المحطة: يرغب في إضافة فرع جديد، فيقوم بالدخول إلى صفحة إدارة المحطات، يضغط على 'إضافة محطة جديدة'، يقوم بتقديم معلومات الفرع وموقعه على الخريطة
  • مالك المحطة: يرغب في تعديل معلومات فرع، فيقوم بالدخول إلى صفحة إدارة المحطات، يبحث عن الفرع المطلوب، يقوم بتعديل المعلومات المطلوبة
  • مالك المحطة: في حالة تغير موقع الفرع، يقوم بدخول صفحة إدارة المحطات، يبحث عن الفرع، تعديل موقعه على الخريطة
مؤشرات الأداء
  • عدد المحطات المسجلة حسب المواقع (مدن أو مناطق أو مسارات طريق)

3.8.2 حالات الاستخدام

3.8.2.1- إضافة فرع جديد لمحطة الوقود في النظام لتوفير معلومات مفصلة عن المحطة وتعزيز تجربة المستخدم

graph LR; A[يدخل مالك المحطة إلى صفحة إدارة المحطات] --> B[يختار إضافة محطة جديدة]; B --> C[يدخل معلومات المحطة]; C --> D[يحدد الإحداثيات على الخريطة]; D --> E[يؤكد إضافة المحطة];
العنوانالتفاصيل
المستخدممالك محطة الوقود
الشروط المسبقة
  • وجود حساب مسجل لمالك المحطة في المنصة
الشروط اللاحقة
  • إضافة محطة جديدة إلى قاعدة بيانات المحطات
المدخلاتاسم الفرع | العنوان | خط العرض | خط الطول |
المخرجات
  • اضافة محطة جديدة
تفاصيل ال API
Method: POST || Endpoint: /api/stations
Request Headers
Authorization: Bearer token

Request Body

name: نص address: نص Coordinates : float, float

Response

الحالةالمحتوى
200status: نص station_id: integer
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة إضافة محطة

  • form
    • text
      • العنوان : اسم الفرع
      • التحقق : {"required":true,"maxLength":100,"errorMessage":"الاسم مطلوب ويجب ألا يتجاوز 100 حرف"}
    • text
      • العنوان : العنوان
      • التحقق : {"required":true,"maxLength":200,"errorMessage":"العنوان مطلوب ويجب ألا يتجاوز 200 حرف"}
    • number
      • العنوان : خط العرض
      • التحقق : {"required":true,"errorMessage":"خط العرض مطلوب"}
    • number
      • العنوان : خط الطول
      • التحقق : {"required":true,"errorMessage":"خط الطول مطلوب"}
  • رسالة زر الإرسال: إضافة المحطة
الاشعارات

العنوان : تم إضافة المحطة بنجاح
الرسالة : لقد تمت إضافة محطة الوقود الجديدة بنجاح إلى النظام
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : مالك المحطة

3.8.2.2- تعديل معلومات فرع موجود لمحطة الوقود في النظام لتحديث البيانات وضمان دقتها

graph LR; A[يدخل مالك المحطة إلى صفحة إدارة المحطات] --> B[يبحث عن الفرع المطلوب]; B --> C[يقوم بتعديل المعلومات المطلوبة]; C --> D[يؤكد التعديلات];
العنوانالتفاصيل
المستخدممالك محطة الوقود
الشروط المسبقة
  • وجود حساب مسجل لمالك المحطة في المنصة
  • وجود فرع مسجل في النظام
الشروط اللاحقة
  • تحديث معلومات الفرع في قاعدة بيانات المحطات
الخطوات البديلةاذا كان الفرع المطلوب غير مسجل
  • يرسل النظام إشعارا بعدم وجود الفرع
  • المستخدم يتأكد من البيانات المدخلة
  • مقدم الخدمة يحاول البحث مجددًا باستخدام معلومات صحيحة
تفاصيل ال API
Method: PUT || Endpoint: /api/stations/{station_id}
Request Headers
Authorization: Bearer token

Request Body

name: نص address: نص Coordinates : float, float

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة تعديل المحطة

  • form
    • text
      • العنوان : اسم الفرع
      • التحقق : {"required":true,"maxLength":100,"errorMessage":"الاسم مطلوب ويجب ألا يتجاوز 100 حرف"}
    • text
      • العنوان : العنوان
      • التحقق : {"required":true,"maxLength":200,"errorMessage":"العنوان مطلوب ويجب ألا يتجاوز 200 حرف"}
    • number
      • العنوان : خط العرض
      • التحقق : {"required":true,"errorMessage":"خط العرض مطلوب"}
    • number
      • العنوان : خط الطول
      • التحقق : {"required":true,"errorMessage":"خط الطول مطلوب"}
  • رسالة زر الإرسال: تعديل المحطة
الاشعارات

العنوان : تم تعديل معلومات المحطة بنجاح
الرسالة : لقد تم تعديل معلومات محطة الوقود بنجاح في النظام
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : مالك المحطة

3.8.2.3- تعديل موقع فرع لمحطة الوقود على الخريطة لتحديث بيانات الموقع الجغرافي وضمان دقتها

graph LR; A[يدخل مالك المحطة إلى صفحة إدارة المحطات] --> B[يبحث عن الفرع المطلوب]; B --> C[يقوم بتعديل موقع الفرع على الخريطة]; C --> D[يؤكد التعديلات];
العنوانالتفاصيل
المستخدممالك محطة الوقود
الشروط المسبقة
  • وجود حساب مسجل لمالك المحطة في المنصة
  • وجود فرع مسجل في النظام
الشروط اللاحقة
  • تحديث موقع الفرع في قاعدة بيانات المحطات
تفاصيل ال API
Method: PUT || Endpoint: /api/stations/{station_id}/location
Request Headers
Authorization: Bearer token

Request Body

Coordinates : float, float

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة تعديل موقع المحطة

  • form
    • number
      • العنوان : خط العرض
      • التحقق : {"required":true,"errorMessage":"خط العرض مطلوب"}
    • number
      • العنوان : خط الطول
      • التحقق : {"required":true,"errorMessage":"خط الطول مطلوب"}
  • رسالة زر الإرسال: تعديل الموقع
الاشعارات

العنوان : تم تعديل موقع المحطة بنجاح
الرسالة : لقد تم تعديل موقع محطة الوقود بنجاح في النظام
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : مالك المحطة

3.9 - طلب خدمة النقل

3.9.1 المعلومات العامة

العنوان التفاصيل
أهداف العمل
  • تمكين العملاء من تقديم طلبات خدمة النقل مع تحديد تفاصيلها
الجهات المعنية
  • طالب خدمة النقل (التاجر، وسيط النقل، الفرد)
الخطوات الرئيسية
  • تحديد نوع العميل: مرسل/مرسل إليه
  • اختيار فئة المركبة المطلوبة (نقل خفيف، نقل ثقيل)
  • اختيار نوع المركبة المطلوبة حسب الفئة المحددة (قائمة منسدلة لكل فئة) - اختيار متعدد
  • وصف الحمل والوزن الإجمالي
  • تحديد قيمة الحمولة
  • تحديد موقع التحميل والتنزيل (موقع واحد أو مواقع متعددة)
  • تحديد موعد التحميل (الآن/مجدول بحد أقصى ٢٠ ساعة)
  • تحديد نطاق البحث (١٠كم، ٥٠كم، ١٠٠كم، ٢٠٠كم)
  • اختيار آلية التسعير (طلب تسعيرة {مزايدة عامة، مزايدة خاصة}/ سعر ثابت)
الخطوات البديلة
  • الخدمة غير متاحة في حال لم يكن هناك مقدمي الخدمة المتاحين وفقا للمعايير المحددة
قصص المستخدمين
  • كطالب خدمة، أريد أن أحدد دوري في العملية (مرسل/مستلم)، لكي يتم تحديد اتجاه الحمولة ومسئوليتي فيها
  • كطالب خدمة، أريد اختيار فئة المركبة المطلوبة، لكي يتم البحث عن مقدمي الخدمة المتوافقين مع احتياجاتي
  • كطالب خدمة، أريد اختيار نوع المركبة المطلوبة بناءً على الفئة التي اخترتها، لكي يتم البحث عن مقدمي الخدمة المناسبين
  • كطالب خدمة، أريد تحديد الوزن الكلي للحمولة، لكي يتم تقدير التكلفة الكلية للخدمة
  • كطالب خدمة، أريد تحديد مواقع تحميل وتنزيل الحمولة، لكي يتم توجيه مقدم الخدمة بشكل صحيح
  • كطالب خدمة، أريد تحديد موعد التحميل (الآن / مجدول)، لضمان توفر مقدم الخدمة في الوقت المطلوب
  • كطالب خدمة، أريد أن أحدد نطاق البحث، للحصول على قائمة من مقدمي الخدمات المتاحين في المنطقة المطلوبة
  • كطالب خدمة، أريد اختيار آلية التسعير (طلب تسعير / سعر ثابت)، لكي أتمكن من التحكم في تكلفة الخدمة
  • كمقدم خدمة، أريد أن أرى تفاصيل طلبات النقل المطابقة لمعايير خاصة بي، لكي أتمكن من تقديم عروض أسعار مناسبة
مؤشرات الأداء
  • عدد الطلبات مع تصنيفها (نوع وفئة المركبة المستخدمة، مدينة الارسال والاستلام،....)

3.9.2 حالات الاستخدام

3.9.2.1- يقوم طالب خدمة النقل (التاجر، وسيط النقل، الفرد) بتحديد نوع العميل (مرسل/مرسل إليه) عند طلب خدمة النقل

graph LR A[User enters Transport Request page] --> B[Selects customer type: Sender/Receiver] B --> C[Clicks 'Next'] C --> D[System confirms selection and redirects to next step]
العنوانالتفاصيل
المستخدمطالب خدمة النقل (التاجر، وسيط النقل، الفرد)
الشروط المسبقة
  • وجود حساب مستخدم مسجل في المنصة
  • المستخدم قد قرأ ووافق على شروط الخدمة
الشروط اللاحقة
  • تحديد دور المستخدم في العملية وتوجيه الطلب بناءً على ذلك
تسلسل الأحداث
  • المستخدم يدخل إلى المنصة
  • المستخدم يختار خيار طلب خدمة نقل
  • النظام يعرض صفحة تحديد نوع العميل
  • المستخدم يحدد نوع العميل وينقر على زر 'التالي'
القواعد التجارية
  • يجب على المستخدم تحديد دوره بدقة لضمان توجيه الطلب بشكل صحيح
الافتراضات
  • المستخدم لديه معرفة كافية بعملية النقل وأنواع العملاء
  • المنصة تدعم عملية تحديد نوع العميل بشكل سهل وسلس
المتطلبات الخاصة
  • واجهة المستخدم يجب أن تكون بديهية وسهلة الاستخدام
الملاحظات والمشاكل
  • يجب التأكد من أن جميع الحقول المطلوبة في النموذج مملوءة بشكل صحيح قبل الانتقال للخطوة التالية
المدخلاتنوع العميل (مرسل/مرسل إليه) |
المخرجات
  • تأكيد نوع العميل وتوجيه الطلب
تفاعلات المستخدم
  • نموذج إدخال لتحديد نوع العميل
  • زر 'التالي' للانتقال للخطوة التالية
سيناريوهات الاستخدام
  • تاجر يرغب في إرسال بضاعة إلى عميل
  • فرد يرغب في استلام شحنة من مقدم خدمة
متطلبات الأمان
  • يجب تأمين عملية الإدخال والتحقق من صحة البيانات المدخلة
التكامل مع الأنظمة الأخرى
  • تكامل مع نظام الحسابات للتحقق من أن المستخدم مسجل
القيود والافتراضات
  • يجب أن يكون المستخدم مسجل في المنصة
  • يجب أن تكون شروط الخدمة محدثة ومقبولة من قبل المستخدم
متطلبات الاختبار
  • اختبارات وظيفية للتحقق من دقة وسهولة تحديد نوع العميل
  • اختبارات الأمان للتحقق من صحة البيانات المدخلة وحمايتها
تفاصيل ال API
Method: POST || Endpoint: /api/transport-request/customer-type
Request Headers
Content-Type: application/json Authorization: Bearer token

Request Body

customer_type: نص

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة طلب النقل

  • textblock
    • Please select your role in the transport process:

  • form
    • select
      • العنوان : نوع العميل
      • التحقق : Please select a customer type
      • الخيارات : ["Sender","Receiver"]
  • رسالة زر الإرسال: Next
  • رسالة النجاح: تم اختيار نوع العميل بنجاح
  • إعادة توجيه النجاح: NextStepScreen
الاشعارات

العنوان : تم بدء طلب النقل
الرسالة : لقد بدأت طلب النقل. يرجى متابعة الخطوات المطلوبة
عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : user

3.9.2.2- يقوم طالب خدمة النقل باختيار فئة المركبة المطلوبة (نقل خفيف، نقل ثقيل) ونوع المركبة المطلوبة بناءً على نوع الخدمة المطلوبة

graph LR A[User enters Transport Request page] --> B[Selects vehicle category: Light/Heavy] B --> C[Selects vehicle type] C --> D[Clicks 'Next'] D --> E[System confirms selection and redirects to next step]
العنوانالتفاصيل
المستخدمطالب خدمة النقل (التاجر، وسيط النقل، الفرد)
الشروط المسبقة
  • تحديد نوع العميل (مرسل/مرسل إليه)
الشروط اللاحقة
  • تحديد نوع وفئة المركبة المناسبة للخدمة المطلوبة
تسلسل الأحداث
  • المستخدم يدخل إلى صفحة طلب خدمة النقل
  • المستخدم يحدد نوع العميل ( مرسل أو مرسل إليه )
  • المستخدم يختار فئة المركبة المطلوبة
  • المستخدم يختار نوع المركبة المطلوب
  • المستخدم يحدد فئة المركبة وينقر على زر 'التالي'
القواعد التجارية
  • يجب على المستخدم اختيار فئة ونوع المركبة بدقة لضمان توفير المركبة المناسبة للخدمة المطلوبة
الافتراضات
  • المستخدم لديه معرفة بأنواع المركبات المتاحة ومواصفاتها
  • المنصة تعرض قائمة بفئات المركبات المتاحة بشكل واضح
المتطلبات الخاصة
  • واجهة المستخدم يجب أن تكون بديهية وسهلة الاستخدام
الملاحظات والمشاكل
  • يجب التأكد من أن جميع الحقول المطلوبة في النموذج مملوءة بشكل صحيح قبل الانتقال للخطوة التالية
المدخلاتفئة المركبة (نقل خفيف، نقل ثقيل) | نوع المركبة |
المخرجات
  • تأكيد فئة ونوع المركبة المطلوبة
تفاعلات المستخدم
  • نموذج إدخال لتحديد فئة ونوع المركبة
  • زر 'التالي' للانتقال للخطوة التالية
سيناريوهات الاستخدام
  • تاجر يرغب في تحديد مركبة خفيفة لنقل بضاعة صغيرة
  • وسيط نقل يرغب في تحديد مركبة ثقيلة لنقل شحنة كبيرة
متطلبات الأمان
  • يجب تأمين عملية الإدخال والتحقق من صحة البيانات المدخلة
التكامل مع الأنظمة الأخرى
  • تكامل مع نظام المركبات للتحقق من توفر الفئات المطلوبة
القيود والافتراضات
  • يجب أن تكون فئات وأنواع المركبات محدثة ومتاحة في النظام
  • يجب أن تكون واجهة المستخدم سهلة الاستخدام لتسهيل اختيار فئة ونوع المركبة
متطلبات الاختبار
  • اختبارات وظيفية للتحقق من دقة وسهولة اختيار فئة المركبة
  • اختبارات الأمان للتحقق من صحة البيانات المدخلة وحمايتها
تفاصيل ال API
Method: POST || Endpoint: /api/transport-request/vehicle-category
Request Headers
Content-Type: application/json Authorization: Bearer token

Request Body

vehicle_category: نص vehicle_type: نص

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة فئة ونوع المركبة لطلب النقل

  • textblock
    • Please select the category of the vehicle required for transport:

  • form
    • select
      • العنوان : فئة المركبة
      • التحقق : {"required: true"}
      • الخيارات : ["Light Transport","Heavy Transport"]
    • select
      • العنوان : نوع المركبة
      • التحقق : {"required: true"}
  • رسالة زر الإرسال: Next
  • رسالة النجاح: تم اختيار نوع المركبة بنجاح
  • إعادة توجيه النجاح: NextStepScreen
الاشعارات

العنوان : تم اختيار فئة المركبة
الرسالة : لقد اخترت فئة ونوع المركبة لطلب النقل بنجاح. يرجى متابعة الخطوات التالية
عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : user

3.9.2.3- يقوم طالب خدمة النقل باختيار نوع المركبة المطلوبة بناءً على الفئة المحددة

graph LR A[User enters Transport Request page] --> B[Selects vehicle category] B --> C[System displays available vehicle types] C --> D[User selects vehicle type] D --> E[Clicks 'Next'] E --> F[System confirms selection and redirects to next step]
العنوانالتفاصيل
المستخدمطالب خدمة النقل (التاجر، وسيط النقل، الفرد)
الشروط المسبقة
  • اختيار فئة المركبة
الشروط اللاحقة
  • تحديد النوع المناسب للمركبة المطلوبة
تسلسل الأحداث
  • المستخدم يدخل إلى صفحة طلب خدمة النقل
  • المستخدم يحدد نوع العميل ( مرسل أو مرسل إليه )
  • المستخدم يختار فئة المركبة المطلوبة
  • النظام يعرض قائمة بأنواع المركبات المتاحة حسب الفئة المختارة
  • المستخدم يحدد نوع المركبة وينقر على زر 'التالي'
القواعد التجارية
  • يجب على المستخدم اختيار نوع المركبة بدقة لضمان توفير المركبة المناسبة للخدمة المطلوبة
الافتراضات
  • المستخدم لديه معرفة بأنواع المركبات المتاحة ومواصفاتها
  • المنصة تعرض قائمة بأنواع المركبات المتاحة بشكل واضح بناءً على الفئة المختارة
المتطلبات الخاصة
  • واجهة المستخدم يجب أن تكون بديهية وسهلة الاستخدام
الملاحظات والمشاكل
  • يجب التأكد من أن جميع الحقول المطلوبة في النموذج مملوءة بشكل صحيح قبل الانتقال للخطوة التالية
المدخلاتنوع المركبة |
المخرجات
  • تأكيد نوع المركبة المطلوبة
تفاعلات المستخدم
  • نموذج إدخال لتحديد نوع المركبة
  • زر 'التالي' للانتقال للخطوة التالية
سيناريوهات الاستخدام
  • تاجر يرغب في تحديد نوع مركبة معينة لنقل بضاعة حساسة
  • وسيط نقل يرغب في تحديد نوع مركبة محددة لنقل شحنة كبيرة
متطلبات الأمان
  • يجب تأمين عملية الإدخال والتحقق من صحة البيانات المدخلة
التكامل مع الأنظمة الأخرى
  • تكامل مع نظام المركبات للتحقق من توفر الأنواع المطلوبة
القيود والافتراضات
  • يجب أن تكون أنواع المركبات محدثة ومتاحة في النظام
  • يجب أن تكون واجهة المستخدم سهلة الاستخدام لتسهيل اختيار نوع المركبة
متطلبات الاختبار
  • اختبارات وظيفية للتحقق من دقة وسهولة اختيار نوع المركبة
  • اختبارات الأمان للتحقق من صحة البيانات المدخلة وحمايتها
تفاصيل ال API
Method: POST || Endpoint: /api/transport-request/vehicle-type
Request Headers
Content-Type: application/json Authorization: Bearer token

Request Body

vehicle_type: نص

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة نوع المركبة لطلب النقل

  • textblock
    • Please select the type of vehicle required for transport based on the selected category:

  • form
    • select
      • العنوان : نوع المركبة
      • التحقق : Please select a vehicle type
      • الخيارات : ["Type 1","Type 2","Type 3"]
  • رسالة زر الإرسال: Next
  • رسالة النجاح: تم اختيار نوع المركبة بنجاح
  • إعادة توجيه النجاح: NextStepScreen
الاشعارات

العنوان : تم اختيار نوع المركبة
الرسالة : لقد اخترت نوع المركبة لطلب النقل بنجاح. يرجى متابعة الخطوات التالية
عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : user

3.9.2.4- يقوم طالب خدمة النقل بوصف الحمل والوزن الإجمالي للحمولة

graph LR A[User enters Transport Request page] --> B[Selects vehicle type] B --> C[System displays cargo details fields] C --> D[User enters cargo description and weight] D --> E[Clicks 'Next'] E --> F[System confirms details and redirects to next step]
العنوانالتفاصيل
المستخدمطالب خدمة النقل (التاجر، وسيط النقل، الفرد)
الشروط المسبقة
  • اختيار نوع وفئة المركبة المطلوبة
الشروط اللاحقة
  • تحديد تفاصيل الحمولة لتقديم الطلب بدقة
تسلسل الأحداث
  • المستخدم يدخل إلى صفحة طلب خدمة النقل
  • المستخدم يحدد نوع العميل ( مرسل أو مرسل إليه )
  • تحديد فئة المركية
  • المستخدم يختار نوع المركبة المطلوبة
  • النظام يعرض حقول إدخال وصف الحمولة والوزن الإجمالي
  • المستخدم يدخل وصفًا للحمولة والوزن الإجمالي
  • المستخدم ينقر على زر 'التالي' لاستكمال الطلب
القواعد التجارية
  • يجب على المستخدم تقديم وصف دقيق للحمولة وتحديد الوزن الإجمالي لضمان توفير الخدمة المناسبة
الافتراضات
  • المستخدم لديه معرفة دقيقة بتفاصيل الحمولة والوزن الإجمالي
  • المنصة توفر واجهة سهلة لإدخال تفاصيل الحمولة
المتطلبات الخاصة
  • واجهة المستخدم يجب أن تكون بديهية وسهلة الاستخدام
الملاحظات والمشاكل
  • يجب التأكد من أن جميع الحقول المطلوبة في النموذج مملوءة بشكل صحيح قبل الانتقال للخطوة التالية
المدخلاتوصف الحمولة | الوزن الإجمالي |
المخرجات
  • تأكيد تفاصيل الحمولة
تفاعلات المستخدم
  • نموذج إدخال لوصف الحمولة
  • نموذج إدخال لتحديد الوزن الإجمالي
  • زر 'التالي' للانتقال للخطوة التالية
سيناريوهات الاستخدام
  • تاجر يرغب في وصف شحنة من البضائع وتحديد الوزن الإجمالي لتقديم طلب نقل
  • وسيط نقل يرغب في تقديم تفاصيل دقيقة عن الحمولة والوزن الإجمالي لضمان دقة الخدمة
متطلبات الأمان
  • يجب تأمين عملية الإدخال والتحقق من صحة البيانات المدخلة
التكامل مع الأنظمة الأخرى
  • تكامل مع نظام التحقق من وزن الحمولة للتحقق من صحة البيانات المدخلة
القيود والافتراضات
  • يجب أن تكون تفاصيل الحمولة والوزن الإجمالي محدثة ومتاحة في النظام
  • يجب أن تكون واجهة المستخدم سهلة الاستخدام لتسهيل إدخال تفاصيل الحمولة
متطلبات الاختبار
  • اختبارات وظيفية للتحقق من دقة وسهولة إدخال تفاصيل الحمولة
  • اختبارات الأمان للتحقق من صحة البيانات المدخلة وحمايتها
تفاصيل ال API
Method: POST || Endpoint: /api/transport-request/cargo-details
Request Headers
Content-Type: application/json Authorization: Bearer token

Request Body

cargo_description: نص cargo_weight: number

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة تفاصيل الحمولة لطلب النقل

  • textblock
    • Please provide details of the cargo for transport:

  • form
    • text
      • العنوان : وصف الحمولة
      • التحقق : Please provide a description of the cargo
    • number
      • العنوان : وزن الحمولة
      • التحقق : Please provide the total weight of the cargo
  • رسالة زر الإرسال: Next
  • رسالة النجاح: تم إدخال تفاصيل الحمولة بنجاح
  • إعادة توجيه النجاح: NextStepScreen
الاشعارات

العنوان : تم إدخال تفاصيل الحمولة
الرسالة : لقد أدخلت تفاصيل الحمولة لطلب النقل بنجاح. يرجى متابعة الخطوات التالية
عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : user

3.9.2.5- يقوم طالب خدمة النقل بتحديد وصف الحمولة بشكل دقيق للمساعدة في حساب التكلفة

graph LR A[User enters Transport Request page] --> B[System displays cargo value field]; B --> C[User enters cargo value]; C --> D[Clicks 'Next']; D --> E[System confirms value and redirects to next step];
العنوانالتفاصيل
المستخدمطالب خدمة النقل (التاجر، وسيط النقل، الفرد)
الشروط المسبقة
  • وصف الحمل والوزن الإجمالي
الشروط اللاحقة
  • تحديد قيمة الحمولة للمساعدة في حساب التكلفة
تسلسل الأحداث
  • المستخدم يدخل إلى صفحة طلب خدمة النقل
  • المستخدم يحدد قيمة الحمولة
  • المستخدم ينقر على زر 'التالي' لاستكمال الطلب
القواعد التجارية
  • يجب على المستخدم تحديد قيمة الحمولة بدقة لضمان حساب التكلفة بشكل صحيح
الافتراضات
  • المستخدم لديه معرفة دقيقة بقيمة الحمولة
  • المنصة توفر واجهة سهلة لإدخال قيمة الحمولة
المتطلبات الخاصة
  • واجهة المستخدم يجب أن تكون بديهية وسهلة الاستخدام
الملاحظات والمشاكل
  • يجب التأكد من أن جميع الحقول المطلوبة في النموذج مملوءة بشكل صحيح قبل الانتقال للخطوة التالية
المدخلاتقيمة الحمولة |
المخرجات
  • تأكيد قيمة الحمولة
تفاعلات المستخدم
  • نموذج إدخال لتحديد قيمة الحمولة
  • زر 'التالي' للانتقال للخطوة التالية
سيناريوهات الاستخدام
  • تاجر يرغب في تحديد قيمة البضائع التي سيتم نقلها لتقديم طلب نقل
  • وسيط نقل يرغب في تقديم تفاصيل دقيقة عن قيمة الحمولة لضمان دقة الخدمة
متطلبات الأمان
  • يجب تأمين عملية الإدخال والتحقق من صحة البيانات المدخلة
التكامل مع الأنظمة الأخرى
  • تكامل مع نظام التحقق من قيمة الحمولة للتحقق من صحة البيانات المدخلة
القيود والافتراضات
  • يجب أن تكون قيمة الحمولة محدثة ومتاحة في النظام
  • يجب أن تكون واجهة المستخدم سهلة الاستخدام لتسهيل إدخال قيمة الحمولة
متطلبات الاختبار
  • اختبارات وظيفية للتحقق من دقة وسهولة إدخال قيمة الحمولة
  • اختبارات الأمان للتحقق من صحة البيانات المدخلة وحمايتها
تفاصيل ال API
Method: POST || Endpoint: /api/transport-request/cargo-value
Request Headers
Content-Type: application/json Authorization: Bearer token

Request Body

cargo_value: number

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة قيمة الحمولة لطلب النقل

  • textblock
    • Please provide the value of the cargo for transport:

  • form
    • number
      • العنوان : قيمة الحمولة
      • التحقق : Please provide the value of the cargo
  • رسالة زر الإرسال: Next
  • رسالة النجاح: تم إدخال قيمة الحمولة بنجاح
  • إعادة توجيه النجاح: NextStepScreen
الاشعارات

العنوان : تم إدخال قيمة الحمولة
الرسالة : لقد أدخلت قيمة الحمولة لطلب النقل بنجاح. يرجى متابعة الخطوات التالية
عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : user

3.9.2.6- يقوم طالب خدمة النقل بتحديد موقع التحميل والتنزيل (موقع واحد أو مواقع متعددة)

graph LR A[User enters Transport Request page] --> B[System displays locations fields] B --> C[User enters loading location] C --> D[User enters unloading location] D --> E[Clicks 'Next'] E --> F[System confirms locations and redirects to next step]
العنوانالتفاصيل
المستخدمطالب خدمة النقل (التاجر، وسيط النقل، الفرد)
الشروط المسبقة
  • تحديد الوصف الكامل للحمولة
  • تحديد نوع وفئة المركبة
الشروط اللاحقة
  • تحديد موقع التحميل والتنزيل بدقة لتوجيه مقدم الخدمة
تسلسل الأحداث
  • المستخدم يدخل إلى صفحة طلب خدمة النقل
  • المستخدم يحدد موقع التحميل
  • المستخدم يحدد موقع التنزيل
  • المستخدم ينقر على زر 'التالي' لاستكمال الطلب
القواعد التجارية
  • يجب على المستخدم تحديد مواقع التحميل والتنزيل بدقة لضمان توجيه مقدم الخدمة بشكل صحيح
الافتراضات
  • المستخدم لديه معرفة دقيقة بمواقع التحميل والتنزيل
  • المنصة توفر واجهة سهلة لإدخال مواقع التحميل والتنزيل
المتطلبات الخاصة
  • واجهة المستخدم يجب أن تكون بديهية وسهلة الاستخدام
الملاحظات والمشاكل
  • يجب التأكد من أن جميع الحقول المطلوبة في النموذج مملوءة بشكل صحيح قبل الانتقال للخطوة التالية
المدخلاتموقع التحميل | موقع التنزيل |
المخرجات
  • تأكيد مواقع التحميل والتنزيل
تفاعلات المستخدم
  • نموذج إدخال لتحديد موقع التحميل
  • نموذج إدخال لتحديد موقع التنزيل
  • زر 'التالي' للانتقال للخطوة التالية
سيناريوهات الاستخدام
  • تاجر يرغب في تحديد موقع تحميل البضائع وموقع التنزيل لتقديم طلب نقل
  • وسيط نقل يرغب في تقديم تفاصيل دقيقة عن مواقع التحميل والتنزيل لضمان دقة الخدمة
متطلبات الأمان
  • يجب تأمين عملية الإدخال والتحقق من صحة البيانات المدخلة
التكامل مع الأنظمة الأخرى
  • تكامل مع نظام الخرائط للتحقق من صحة مواقع التحميل والتنزيل
القيود والافتراضات
  • يجب أن تكون مواقع التحميل والتنزيل محدثة ومتاحة في النظام
  • يجب أن تكون واجهة المستخدم سهلة الاستخدام لتسهيل إدخال مواقع التحميل والتنزيل
متطلبات الاختبار
  • اختبارات وظيفية للتحقق من دقة وسهولة إدخال مواقع التحميل والتنزيل
  • اختبارات الأمان للتحقق من صحة البيانات المدخلة وحمايتها
تفاصيل ال API
Method: POST || Endpoint: /api/transport-request/loading-unloading-locations
Request Headers
Content-Type: application/json Authorization: Bearer token

Request Body

loading_location: نص unloading_location: نص

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة مواقع التحميل والتفريغ لطلب النقل

  • textblock
    • Please provide the loading and unloading locations for transport:

  • form
    • text
      • العنوان : موقع التحميل
      • التحقق : Please provide the loading location
    • text
      • العنوان : موقع التفريغ
      • التحقق : Please provide the unloading location
  • رسالة زر الإرسال: Next
  • رسالة النجاح: تم إدخال المواقع بنجاح
  • إعادة توجيه النجاح: NextStepScreen
الاشعارات

العنوان : تم إدخال المواقع
الرسالة : لقد أدخلت مواقع التحميل والتفريغ لطلب النقل بنجاح. يرجى متابعة الخطوات التالية
عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : user

3.9.2.7- يقوم طالب خدمة النقل بتحديد موعد التحميل (الآن/مجدول بحد أقصى ٢٠ ساعة)

graph LR A[User enters Transport Request page] --> B[System displays loading time field]; B --> C[User selects loading time]; C --> D[Clicks 'Next']; D --> E[System confirms loading time and redirects to next step];
العنوانالتفاصيل
المستخدمطالب خدمة النقل (التاجر، وسيط النقل، الفرد)
الشروط المسبقة
  • تحديد موقع التحميل والتنزيل
الشروط اللاحقة
  • تحديد موعد التحميل لتنسيق الخدمة
تسلسل الأحداث
  • المستخدم يدخل إلى صفحة طلب خدمة النقل
  • المستخدم يحدد موعد التحميل (الآن أو مجدول)
  • المستخدم ينقر على زر 'التالي' لاستكمال الطلب
القواعد التجارية
  • يجب على المستخدم تحديد موعد التحميل بدقة لضمان تنسيق الخدمة بشكل صحيح
الافتراضات
  • المستخدم لديه معرفة دقيقة بموعد التحميل المطلوب
  • المنصة توفر واجهة سهلة لتحديد موعد التحميل
المتطلبات الخاصة
  • واجهة المستخدم يجب أن تكون بديهية وسهلة الاستخدام
الملاحظات والمشاكل
  • يجب التأكد من أن جميع الحقول المطلوبة في النموذج مملوءة بشكل صحيح قبل الانتقال للخطوة التالية
المدخلاتموعد التحميل |
المخرجات
  • تأكيد موعد التحميل
تفاعلات المستخدم
  • نموذج إدخال لتحديد موعد التحميل
  • زر 'التالي' للانتقال للخطوة التالية
سيناريوهات الاستخدام
  • تاجر يرغب في تحديد موعد تحميل البضائع لتقديم طلب نقل
  • وسيط نقل يرغب في تقديم تفاصيل دقيقة عن موعد التحميل لضمان دقة الخدمة
متطلبات الأمان
  • يجب تأمين عملية الإدخال والتحقق من صحة البيانات المدخلة
التكامل مع الأنظمة الأخرى
  • تكامل مع نظام الجدولة للتحقق من توفر المواعيد المدخلة
القيود والافتراضات
  • يجب أن تكون مواعيد التحميل محدثة ومتاحة في النظام
  • يجب أن تكون واجهة المستخدم سهلة الاستخدام لتسهيل تحديد موعد التحميل
متطلبات الاختبار
  • اختبارات وظيفية للتحقق من دقة وسهولة تحديد موعد التحميل
  • اختبارات الأمان للتحقق من صحة البيانات المدخلة وحمايتها
تفاصيل ال API
Method: POST || Endpoint: /api/transport-request/loading-time
Request Headers
Content-Type: application/json Authorization: Bearer token

Request Body

loading_time: نص

Response

الحالةالمحتوى
200status: نص
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة وقت التحميل لطلب النقل

  • textblock
    • Please provide the loading time for transport:

  • form
    • datetime
      • العنوان : وقت التحميل
      • التحقق : Please provide the loading time
  • رسالة زر الإرسال: Next
  • رسالة النجاح: تم إدخال وقت التحميل بنجاح
  • إعادة توجيه النجاح: NextStepScreen
الاشعارات

العنوان : تم إدخال وقت التحميل
الرسالة : لقد أدخلت وقت التحميل لطلب النقل بنجاح. يرجى متابعة الخطوات التالية
عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : user

3.9.2.8- تحديد نطاق البحث (١٠كم، ٥٠كم، ١٠٠كم، ٢٠٠كم) للعثور على مقدمي الخدمة المتاحين

graph LR; A[User specifies search range] --> B{Search providers within range}; B -->|Providers available| C[Display list of providers]; B -->|No providers available| D[Display 'no providers' message]; C --> E[User selects provider]; D --> F[User redefines search range]; F --> B
العنوانالتفاصيل
المستخدمطالب خدمة النقل
الشروط المسبقة
  • تحديد موعد التحميل
  • أن يكون هناك حساب مسجل لطالب الخدمة في المنصة
  • أن يكون مقدم الخدمة قد قبل بشروط وأحكام الخدمة
الشروط اللاحقة
  • تحديد نطاق البحث
  • ظهور قائمة بمقدمي الخدمة المتاحين ضمن النطاق المحدد
تسلسل الأحداث
  • يدخل المستخدم إلى صفحة طلب خدمة النقل
  • يحدد المستخدم نطاق البحث المناسب
  • ينقر المستخدم على زر 'التالي'
  • النظام يعرض قائمة مقدمي الخدمة المتاحين
الخطوات البديلةإذا لم يكن هناك مقدمي الخدمة المتاحين في النطاق المحدد
  • النظام يعرض رسالة تفيد بعدم توفر مقدمي الخدمة في النطاق المحدد
  • المستخدم يختار نطاق بحث أوسع أو يعيد المحاولة لاحقًا
الخطوات الاستثنائيةفي حالة حدوث خطأ في تحديد نطاق البحث
  • النظام يعرض رسالة خطأ
  • المستخدم يعيد تحديد نطاق البحث
  • المستخدم ينقر على زر 'التالي' لاستكمال الطلب
القواعد التجارية
  • يجب أن تكون الخيارات المتاحة لنطاق البحث محددة مسبقًا (١٠كم، ٥٠كم، ١٠٠كم، ٢٠٠كم)
الافتراضات
  • المستخدم يعرف كيفية تحديد نطاق البحث المناسب لطلبه
  • النظام يحتوي على بيانات كافية لمقدمي الخدمة لتوفير قائمة دقيقة
المتطلبات الخاصة
  • النظام يجب أن يكون قادرًا على معالجة وإظهار البيانات بشكل سريع وفعال
الملاحظات والمشاكل
  • قد يحتاج المستخدم إلى توسيع نطاق البحث إذا لم يتم العثور على مقدمي الخدمة في النطاق المحدد
المدخلاتنطاق البحث المختار |
تفاعلات المستخدم
  • تحديد نطاق البحث
  • النقر على زر 'التالي
الشروط الخاصة
  • عدم وجود مقدمي الخدمة في النطاق المحدد
سيناريوهات الاستخدام
  • كمستخدم، أريد أن أكون قادرًا على تحديد نطاق البحث لتقديم طلب خدمة النقل، بحيث يمكنني العثور على مقدمي الخدمة المتاحين بسهولة
متطلبات الأمان
  • تأكد من أن جميع بيانات المستخدمين ومقدمي الخدمة محمية بشكل مناسب
التكامل مع الأنظمة الأخرى
  • يجب أن يتكامل النظام مع قاعدة بيانات مقدمي الخدمة لضمان عرض قائمة محدثة ودقيقة
القيود والافتراضات
  • النظام يجب أن يحتوي على بيانات كافية لمقدمي الخدمة
  • المستخدم يعرف كيفية استخدام النظام وتحديد نطاق البحث المناسب
متطلبات الاختبار
  • اختبار عرض قائمة مقدمي الخدمة بناءً على نطاق البحث المحدد
  • اختبار الأداء لضمان سرعة استجابة النظام
تفاصيل ال API
Method: POST || Endpoint: /api/transport-request/searchProviders
Request Headers
Content-Type: application/json

Request Body

range: integer

Response

الحالةالمحتوى
200providers: array of provider objects
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة تحديد نطاق البحث

  • textblock
    • اختر نطاق البحث

  • list
    • النوع : 10 كم

    • النوع : 50 كم

    • النوع : 100 كم

    • النوع : 200 كم

  • form
    • button
      • العنوان : التالي
      • الخيارات : onClick: goToNextStep

نتائج نطاق البحث

  • table
    • الاسم : اسم المزود
    • نوع المحتوي : text

    • الاسم : المسافة
    • نوع المحتوي : text

    • الاسم : التقييم
    • نوع المحتوي : text

الاشعارات

العنوان : نتائج البحث عن مقدمي الخدمة
الرسالة : تم العثور على مقدمي خدمة ضمن النطاق المحدد.2
عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : user

3.9.2.9- 9.9

العنوانالتفاصيل
description_simple_copy1
تفاصيل الواجهات
1

  • textblock
    • 1

3.9.2.10- 9.10

العنوانالتفاصيل
description_simple_copy1
تفاصيل الواجهات
1

  • form
    • 1
      • العنوان : 1
      • التحقق : 1
      • الخيارات : 1
  • رسالة زر الإرسال: 1
  • رسالة النجاح: 1

3.9.2.11- 9.11

العنوانالتفاصيل
المستخدم2
الشروط المسبقة
  • 2
الشروط اللاحقة
  • 2
تسلسل الأحداث
  • 2
الخطوات البديلةث
  • ث
الخطوات الاستثنائيةث
  • ث
القواعد التجارية
  • 1
الافتراضات
  • 1
  • 2
المتطلبات الخاصة
  • 2
الملاحظات والمشاكل
  • 2

3.10 - تسعير الحمولة

3.10.1 المعلومات العامة

العنوان التفاصيل
أهداف العمل
  • تقنين وتنظيم عملية تسعير الحمولة وتوفير الشفافية
الجهات المعنية
  • العميل
  • مقدمي الخدمات
  • إداريي المنصة
الخطوات الرئيسية
  • العميل يختار بين نوع التسعير الثابت أو تلقي عروض الأسعار
  • في حالة التسعير الثابت، يتم إبلاغ العميل بالقيمة الأساسية لأجرة النقل، ومن ثم إضافة الرسوم الإضافية لتأكيد المبلغ الإجمالي
  • في حالة طلب عروض الأسعار، يتم عرض طلب النقل للمقدمين لتقديم عروضهم، سواء بشكل عام أو خاص
الخطوات البديلة
  • النظام يسمح برؤية العروض في حالة المزايدة العامة من قبل جميع مقدمي الخدمات
  • العميل يمكنه ترتيب وفلترة العروض حسب السعر، التقييم، ومعايير أخرى
  • يجب تحديد آلية واضحة لعرض ومشاركة أسعار المزايدات؛ في العروض العامة، يمكن لجميع مقدمي الخدمة رؤية العروض، بينما في العروض الخاصة، تظهر التفاصيل فقط لطالب الخدمة
قصص المستخدمين
  • العميل، يريد تحديد سعر ثابت للنقل، للتحكم الكامل في تكلفة الخدمة
  • العميل، يريد استقبال عروض الأسعار للحصول على أفضل صفقة ممكنة
  • مقدم الخدمة، يريد مشاهدة طلبات النقل لتقديم عرض تنافسي
  • الأدمن، يريد تحديد حدود للتسعير للحفاظ على استقرار وعدالة السوق
مؤشرات الأداء
  • عدد الطلبات حسب تصنيف آلية التسعير (ثابت، عرض سعر)، مزايدة عامة أو خاصة وربطها بالفترات الزمنية
  • نسبة المستجيبين للطلبات إلى المستلمين

3.10.2 حالات الاستخدام

3.10.2.1- العميل يقوم بتحديد نوع التسعير المطلوب سواء كان ثابتًا أو عبر تلقي عروض الأسعار من مقدمي الخدمات

graph LR;A[Start] --> B[Client Enters Pricing Page];B --> C[Client Selects Pricing Type];C --> D[Pricing Type Confirmed];D --> E[End];
العنوانالتفاصيل
المستخدمالعميل
الشروط المسبقة
  • وجود خدمة النقل المطلوبة
  • توافر معلومات الحمولة
الشروط اللاحقة
  • تحديد نوع التسعير المطلوب
تسلسل الأحداث
  • العميل يدخل إلى النظام
  • العميل يحدد نوع التسعير
الافتراضات
  • العميل يمتلك معلومات دقيقة حول الحمولة المطلوبة للنقل
المدخلاتمعلومات الحمولة |
المخرجات
  • نوع التسعير المطلوب
تفاعلات المستخدم
  • واجهة تحديد نوع التسعير
سيناريوهات الاستخدام
  • اختيار تسعير ثابت للحصول على تكلفة ثابتة ومحددة مسبقًا
  • اختيار تلقي عروض الأسعار للحصول على أفضل عرض من مقدمي الخدمات
متطلبات الاختبار
  • التأكد من أن العميل يمكنه تحديد نوع التسعير المطلوب بسهولة
تفاصيل ال API
Method: POST || Endpoint: /pricing/select
Request Headers
Authorization: Bearer token

Request Body

pricing_type: نص

Response

الحالةالمحتوى
200status: نص message: تم اختيار نوع التسعير بنجاح
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة اختيار نوع التسعير

  • textblock
    • Select Pricing Type

  • list
    • النوع : type: RadioButton Props : تسعير ثابت, fixed

    • النوع : type: RadioButton Props : تلقي العروض, quotes

  • form
    • Button
      • العنوان : تأكيد
      • الخيارات : submitPricingType
الاشعارات

العنوان : تم اختيار نوع التسعير
الرسالة : لقد اخترت نوع التسعير لشحنتك بنجاح
عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : client

3.10.2.2- النظام يقوم بإبلاغ العميل بالقيمة الأساسية لأجرة النقل في حالة اختيار العميل للتسعير الثابت

graph LR;A[Start] --> B[System Calculates Base Fare];B --> C[System Displays Base Fare];C --> D[End];
العنوانالتفاصيل
المستخدمالنظام
الشروط المسبقة
  • اختيار العميل للتسعير الثابت
الشروط اللاحقة
  • إبلاغ العميل بالقيمة الأساسية لأجرة النقل
تسلسل الأحداث
  • النظام يحسب القيمة الأساسية
  • النظام يعرض القيمة الأساسية للعميل
الافتراضات
  • النظام يحتوي على بيانات دقيقة لحساب أجرة النقل
المدخلاتبيانات الحمولة |
المخرجات
  • القيمة الأساسية لأجرة النقل
تفاعلات المستخدم
  • واجهة عرض القيمة الأساسية
سيناريوهات الاستخدام
  • حساب القيمة الأساسية بناءً على بيانات الحمولة المحددة
متطلبات الاختبار
  • التأكد من أن النظام يحسب ويعرض القيمة الأساسية لأجرة النقل بشكل صحيح
تفاصيل ال API
Method: GET || Endpoint: /pricing/calculate
Request Headers
Authorization: Bearer token

Request Body

Response

الحالةالمحتوى
200status: نص base_fare: number
الوصف: Success
400
الوصف: Bad Request

تفاصيل الواجهات
شاشة إظهار الأجرة الأساسية

  • textblock
    • Base Fare Calculation

  • form
    • text
      • Button
        • العنوان : تأكيد
        • الخيارات : confirmBaseFare
    الاشعارات

    العنوان : تم حساب الأجرة الأساسية
    الرسالة : تم حساب الأجرة الأساسية لشحنتك
    عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : client

    3.10.2.3- النظام يقوم بإضافة الرسوم الإضافية وتأكيد المبلغ الإجمالي لأجرة النقل في حالة اختيار العميل للتسعير الثابت

    graph LR;A[Start] --> B[System Calculates Additional Fees];B --> C[System Displays Total Fare];C --> D[End];
    العنوانالتفاصيل
    المستخدمالنظام
    الشروط المسبقة
    • إبلاغ العميل بالقيمة الأساسية لأجرة النقل
    الشروط اللاحقة
    • إظهار المبلغ الإجمالي للعميل
    تسلسل الأحداث
    • النظام يحسب الرسوم الإضافية
    • النظام يعرض المبلغ الإجمالي
    الافتراضات
    • النظام يحتوي على بيانات دقيقة لحساب الرسوم الإضافية
    المدخلاتبيانات الحمولة |
    المخرجات
    • المبلغ الإجمالي لأجرة النقل
    تفاعلات المستخدم
    • واجهة عرض المبلغ الإجمالي
    سيناريوهات الاستخدام
    • حساب الرسوم الإضافية بناءً على بيانات الحمولة المحددة
    متطلبات الاختبار
    • التأكد من أن النظام يحسب ويعرض المبلغ الإجمالي لأجرة النقل بشكل صحيح
    تفاصيل ال API
    Method: GET || Endpoint: /pricing/total
    Request Headers
    Authorization: Bearer token

    Request Body

    Response

    الحالةالمحتوى
    200status: نص total_fare: number
    الوصف: Success
    400
    الوصف: Bad Request

    تفاصيل الواجهات
    شاشة إظهار الأجرة الإجمالية

    • textblock
      • Total Fare Calculation

    • form
      • text
        • Button
          • العنوان : تأكيد
          • الخيارات : confirmTotalFare
      الاشعارات

      العنوان : تم حساب الأجرة الإجمالية
      الرسالة : تم حساب الأجرة الإجمالية لشحنتك
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : client

      3.10.2.4- النظام يقوم بعرض طلب النقل لمقدمي الخدمات ليقدموا عروضهم في حالة طلب العميل لعروض الأسعار

      graph LR;A[Start] --> B[System Displays Request to Providers];B --> C[Service Providers Submit Quotes];C --> D[End];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • اختيار العميل لطلب عروض الأسعار
      الشروط اللاحقة
      • عرض الطلب على مقدمي الخدمات
      تسلسل الأحداث
      • النظام يعرض طلب النقل
      • مقدمي الخدمات يقدمون عروضهم
      الافتراضات
      • مقدمي الخدمات يمكنهم تقديم عروض الأسعار بناءً على المعلومات المقدمة في الطلب
      المدخلاتمعلومات الحمولة |
      المخرجات
      • عروض الأسعار من مقدمي الخدمات
      تفاعلات المستخدم
      • واجهة عرض الطلب لمقدمي الخدمات
      سيناريوهات الاستخدام
      • عرض طلب النقل لتلقي عروض الأسعار من مقدمي الخدمات
      متطلبات الاختبار
      • التأكد من أن النظام يعرض الطلب بشكل صحيح لمقدمي الخدمات
      تفاصيل ال API
      Method: POST || Endpoint: /requests/submit
      Request Headers
      Authorization: Bearer token

      Request Body

      request_id: نص cargo_details: object

      Response

      الحالةالمحتوى
      200status: نص message: تم تقديم الطلب بنجاح
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تقديم الطلب

      • textblock
        • Submit Cargo Request

      • form
        • text
          • العنوان : تفاصيل الحمولة
        • Button
          • العنوان : إرسال
      الاشعارات

      العنوان : طلب حمولة جديد
      الرسالة : تم تقديم طلب حمولة جديد. يرجى تقديم عروضكم
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : service_providers

      3.10.2.5- مقدمي الخدمات يمكنهم رؤية جميع العروض المقدمة في حالة المزايدة العامة

      graph LR;A[Start] --> B[System Displays All Bids];B --> C[Service Providers View Bids];C --> D[End];
      العنوانالتفاصيل
      المستخدممقدمي الخدمات
      الشروط المسبقة
      • عرض الطلب للمزايدة العامة
      الشروط اللاحقة
      • رؤية العروض من قبل جميع مقدمي الخدمات
      تسلسل الأحداث
      • النظام يعرض جميع العروض المقدمة
      • مقدمي الخدمات يمكنهم رؤية العروض
      الافتراضات
      • مقدمي الخدمات يمكنهم تقديم عروضهم بناءً على المعلومات المقدمة
      المدخلاتمعلومات الحمولة |
      المخرجات
      • جميع العروض المقدمة من مقدمي الخدمات
      تفاعلات المستخدم
      • واجهة عرض العروض لمقدمي الخدمات
      سيناريوهات الاستخدام
      • عرض جميع العروض المقدمة لتقييمها من قبل مقدمي الخدمات
      متطلبات الاختبار
      • التأكد من أن النظام يعرض جميع العروض المقدمة بشكل صحيح
      تفاصيل ال API
      Method: GET || Endpoint: /bids/view
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص bids: array
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة عرض العروض

      • textblock
        • View All Bids

      • table
        • الاسم : المزود
        • نوع المحتوي : text

        • الاسم : مبلغ العرض
        • نوع المحتوي : currency

        • الاسم : التقييم
        • نوع المحتوي : stars

      الاشعارات

      العنوان : عرض جديد متاح
      الرسالة : تم تقديم عرض جديد للمزاد العلني. تفقده الآن
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : service_providers

      3.10.2.6- العميل يقوم بترتيب وفلترة العروض المقدمة حسب السعر، التقييم، ومعايير أخرى لتسهيل اختيار العرض الأنسب

      graph LR;A[Start] --> B[Client Selects Sort and Filter Criteria];B --> C[System Sorts and Filters Offers];C --> D[System Displays Sorted and Filtered Offers];D --> E[End];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • تلقي العروض من مقدمي الخدمات
      الشروط اللاحقة
      • العروض مرتبة ومفلترة حسب معايير العميل
      تسلسل الأحداث
      • العميل يختار معايير الترتيب والفلترة
      • النظام يرتب ويفلتر العروض حسب المعايير المحددة
      • النظام يعرض العروض مرتبة ومفلترة للعميل
      الافتراضات
      • النظام يحتوي على خاصية ترتيب وفلترة العروض
      المدخلاتمعايير الترتيب والفلترة |
      المخرجات
      • العروض مرتبة ومفلترة
      تفاعلات المستخدم
      • واجهة ترتيب وفلترة العروض
      سيناريوهات الاستخدام
      • ترتيب العروض حسب السعر من الأدنى إلى الأعلى
      • ترتيب العروض حسب تقييم مقدمي الخدمات
      • فلترة العروض لإظهار العروض التي تتوافق مع معايير معينة
      متطلبات الاختبار
      • التأكد من أن النظام يرتب ويفلتر العروض بشكل صحيح حسب معايير العميل
      تفاصيل ال API
      Method: POST || Endpoint: /offers/sort-filter
      Request Headers
      Authorization: Bearer token

      Request Body

      sort_by: نص filter_criteria: object

      Response

      الحالةالمحتوى
      200status: نص sorted_filtered_offers: array
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة ترتيب وتصفية العروض

      • textblock
        • Sort and Filter Offers

      • form
        • select
          • العنوان : ترتيب حسب
          • الخيارات : [{"label":"السعر (من الأقل إلى الأعلى)","value":"price_low_high"},{"label":"السعر (من الأعلى إلى الأقل)","value":"price_high_low"},{"label":"التقييم (من الأعلى إلى الأقل)","value":"rating_high_low"}]
        • CheckboxGroup
          • العنوان : معايير التصفية
          • الخيارات : [{"label":"نطاق السعر","value":"price_range"},{"label":"التقييم","value":"rating"},{"label":"وقت التسليم","value":"delivery_time"}]
        • Button
          • العنوان : تطبيق
      الاشعارات

      العنوان : تم ترتيب وتصفية العروض بناءً على معاييرك
      الرسالة : تم ترتيب وتصفية العروض بناءً على معاييرك
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : client

      3.10.2.7- النظام يقوم بتحديد آلية عرض ومشاركة أسعار المزايدات بين مقدمي الخدمات بناءً على نوع المزايدة (عامة أو خاصة)

      graph LR;A[Start] --> B[System Determines Auction Type];B --> C[System Displays Bids Based on Auction Type];C --> D[End];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • عرض العروض من مقدمي الخدمات
      الشروط اللاحقة
      • العروض منظمة حسب نوع المزايدة (عامة أو خاصة)
      تسلسل الأحداث
      • النظام يحدد نوع المزايدة
      • النظام يعرض العروض حسب نوع المزايدة
      الافتراضات
      • النظام يمكنه تنظيم العروض بناءً على نوع المزايدة
      المدخلاتمعلومات العروض المقدمة |
      المخرجات
      • العروض منظمة حسب نوع المزايدة
      تفاعلات المستخدم
      • واجهة عرض العروض
      سيناريوهات الاستخدام
      • تنظيم العروض المقدمة في مزايدة عامة
      • تنظيم العروض المقدمة في مزايدة خاصة
      متطلبات الاختبار
      • التأكد من أن النظام يعرض العروض بشكل صحيح حسب نوع المزايدة
      تفاصيل ال API
      Method: GET || Endpoint: /bids/display
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص bids: array
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة عرض العروض

      • textblock
        • Display Bids

      • table
        • الاسم : المزود
        • نوع المحتوي : text

        • الاسم : مبلغ العرض
        • نوع المحتوي : currency

        • الاسم : النوع
        • نوع المحتوي : text

      الاشعارات

      العنوان : تم عرض العروض
      الرسالة : تم تنظيم وعرض العروض بناءً على نوع المزاد
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : service_providers

      3.11 - إتمام الصفقة

      3.11.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • ضمان أن يتم دفع أتعاب الناقل مقابل خدمات النقل
      • توفير آلية لحجز واحتجاز الأموال حتى يتم إتمام الخدمة بالكامل
      • تعزيز الثقة بين الأطراف عن طريق ضمان الدفع
      • تمكين العميل من الغاء طلب الحمولة بأقل خسائر للناقل
      الجهات المعنية
      • طالب الخدمة
      • الناقل
      • المنصة
      • خدمة الدفع
      الخطوات الرئيسية
      • يتم التحقق من أن لدى طالب الخدمة مبلغ كافٍ في محفظته على المنصة
      • إرسال رسالة برمز تأكيد لإتمام عملية الحجز
      • يتم حجز مبلغ المعاملة وتجميده في حساب طالب الخدمة
      • في حالة عدم توافر الرصيد الكافي، يجب إرسال رسالة تحتوي على رمز تأكيد لإكمال عملية إضافة الأموال
      • يتم توجيه طالب الخدمة لإضافة الأموال إلى محفظته من خلال واحدة من وسائل الدفع
      • يبقى المبلغ محجوزًا حتى يتم إتمام عملية النقل
      الخطوات البديلة
      • في حال إلغاء طالب الخدمة لعملية النقل، يتم تحديد قيمة الاسترداد بناءً على مدى قرب الناقل من الموقع وما إذا كان قد بدأ في الرحلة وعدة عوامل أخرى تحددها الادارة
      قصص المستخدمين
      • طالب الخدمة: يريد تأكيد الصفقة، ليتيح للناقل بدأ عمله
      • الناقل: يريد التأكد من اتمام العميل للصفقة حتى يبدأ عمله بدون تأخير
      • طالب الخدمة: يريد إمكانية إلغاء طلب النقل، حتى يظهر في امان اذا تغيرت الظروف
      مؤشرات الأداء
      • عدد الطلبات التي تم إتمام الصفقة لها و نسبتها لإجمالي الطلبات خلال فترات محددة
      • عدد الطلبات التي لم يكن لها رصيد في المحفظة وتم إضافة الأموال لحظة الإتمام
      • عدد الطلبات التي لم يتم إتمامها بسبب عدم توفر مبلغ كافي في المحفظة
      • قيمة المبالغ المحجوزة

      3.11.2 حالات الاستخدام

      3.11.2.1- التحقق من أن لدى طالب الخدمة مبلغ كافٍ في محفظته على المنصة

      graph LR A[User Requests Balance Check] --> B[System Checks Balance] B --> C{Balance Sufficient?} C -->|Yes| D[Confirm Transaction] C -->|No| E[Notify User to Add Funds]
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • طالب الخدمة قد أضاف مبلغًا في محفظته من قبل
      الشروط اللاحقة
      • تأكيد وجود المبلغ الكافي في المحفظة
      تسلسل الأحداث
      • التحقق من رصيد المحفظة
      • عرض رسالة تأكيد
      القواعد التجارية
      • يجب أن يكون لدى طالب الخدمة رصيد كافٍ في محفظته لتأكيد الصفقة قبل بدء الخدمة
      الافتراضات
      • طالب الخدمة لديه حساب مفعل على المنصة
      • طالب الخدمة يملك الوسائل لإضافة الأموال إلى محفظته
      المتطلبات الخاصة
      • يجب أن يتم التحقق من الرصيد بشكل فوري ودقيق
      الملاحظات والمشاكل
      • في حالة وجود خلل في التحقق من الرصيد، يجب على النظام إبلاغ المستخدم بشكل واضح
      المدخلاترصيد المحفظة الحالي |
      المخرجات
      • رسالة تأكيد بوجود المبلغ الكافي
      تفاعلات المستخدم
      • طالب الخدمة يتلقى إشعارًا بحالة الرصيد
      سيناريوهات الاستخدام
      • في حال كان الرصيد كافيًا، يتم تأكيد الصفقة
      • في حال لم يكن الرصيد كافيًا، يتم إبلاغ طالب الخدمة بضرورة إضافة أموال
      متطلبات الأمان
      • تشفير بيانات المحفظة وحماية المعاملات المالية
      التكامل مع الأنظمة الأخرى
      • نظام إدارة المحفظة الإلكترونية
      • نظام الدفع
      القيود والافتراضات
      • التحقق من الرصيد يجب أن يكون سريعًا ودقيقًا
      متطلبات الاختبار
      • اختبارات الوظائف المالية للتأكد من دقة التحقق من الرصيد
      تفاصيل ال API
      Method: GET || Endpoint: /wallet/check-balance
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص balance: number
      الوصف: Success
      400
      الوصف: Bad Request
      401
      الوصف: Unauthorized

      تفاصيل الواجهات
      تحقق من الرصيد

      • textblock
        • Checking your balance..

      • form
        • Button
          • العنوان : تحقق من الرصيد
          • الخيارات : checkBalance
      • textblock
        • balanceResult

      الاشعارات

      العنوان : Balance Check
      الرسالة : Your wallet balance has been checked successfully
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : طالب الخدمة

      3.11.2.2- إرسال رسالة برمز تأكيد لإتمام عملية الحجز

      graph LR A[Check Wallet Balance] --> B[Send Confirmation Code] B --> C{Code Received?} C -->|Yes| D[Confirm Booking] C -->|No| E[Resend Code]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • طالب الخدمة لديه مبلغ كافٍ في محفظته
      الشروط اللاحقة
      • استلام طالب الخدمة لرسالة تحتوي على رمز التأكيد
      تسلسل الأحداث
      • التحقق من رصيد المحفظة
      • إرسال رمز التأكيد
      القواعد التجارية
      • يجب إرسال رمز التأكيد إلى طالب الخدمة فورًا بعد التحقق من الرصيد
      الافتراضات
      • النظام قادر على إرسال الرسائل النصية بشكل فوري
      المتطلبات الخاصة
      • يجب أن يتم إرسال رمز التأكيد بشكل آمن وسريع
      الملاحظات والمشاكل
      • في حالة عدم استلام طالب الخدمة لرمز التأكيد، يجب على النظام توفير طريقة لإعادة الإرسال
      المدخلاترصيد المحفظة الحالي |
      المخرجات
      • رسالة نصية تحتوي على رمز التأكيد
      تفاعلات المستخدم
      • طالب الخدمة يتلقى إشعارًا برمز التأكيد
      سيناريوهات الاستخدام
      • في حال استلام رمز التأكيد بنجاح، يتم تأكيد الحجز
      • في حال عدم استلام رمز التأكيد، يتم إعادة الإرسال
      متطلبات الأمان
      • تشفير الرسائل النصية لضمان سرية المعلومات
      التكامل مع الأنظمة الأخرى
      • نظام إدارة الرسائل النصية
      • نظام التحقق من الرصيد
      القيود والافتراضات
      • إمكانية إرسال الرسائل النصية في جميع الأوقات
      متطلبات الاختبار
      • اختبارات الأداء لضمان سرعة إرسال الرسائل
      • اختبارات الأمان لضمان تشفير الرسائل
      تفاصيل ال API
      Method: POST || Endpoint: /notifications/send
      Request Headers
      Authorization: Bearer token

      Request Body

      user_id: نص message: نص

      Response

      الحالةالمحتوى
      200status: نص message_id: نص
      الوصف: Success
      400
      الوصف: Bad Request
      401
      الوصف: Unauthorized

      تفاصيل الواجهات
      إرسال رمز التأكيد

      • textblock
        • Sending confirmation code..

      • form
        • Button
          • العنوان : إرسال الرمز
          • الخيارات : sendConfirmationCode
      • textblock
        • confirmationResult

      الاشعارات

      العنوان : Confirmation Code Sent
      الرسالة : Your confirmation code has been sent successfully
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : طالب الخدمة

      3.11.2.3- حجز مبلغ المعاملة وتجميده في حساب طالب الخدمة عند إدخال رمز التأكيد بشكل صحيح لضمان توفر المبلغ المطلوب لإتمام الخدمة

      graph LR; A[Start] --> B[Enter Confirmation Code]; B --> C[Verify Code]; C -- Valid --> D[Freeze Amount]; D --> E[Booking Confirmed]; C -- Invalid --> F[Show Error]; F --> B;
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • طالب الخدمة قد أدخل رمز التأكيد بشكل صحيح
      الشروط اللاحقة
      • المبلغ محجوز ومجمد في حساب طالب الخدمة
      تفاصيل ال API
      Method: POST || Endpoint: /api/confirm-booking
      Request Headers
      Authorization: Bearer token

      Request Body

      confirmation_code: نص

      Response

      الحالةالمحتوى
      200status: نص message: تم تجميد المبلغ بنجاح
      الوصف: Success
      400error: Invalid confirmation code
      الوصف: Bad Request
      500error: An error occurred while processing your request
      الوصف: Internal Server Error

      تفاصيل الواجهات
      تأكيد الحجز

      • textblock
        • Please enter the confirmation code sent to your registered phone number

      • form
        • text
          • العنوان : رمز التأكيد
          • التحقق : "required": true "pattern": "^[0-9]{6}$", "error_message": "Please enter a valid 6-digit confirmation code"
      • رسالة زر الإرسال: Confirm Booking
      • رسالة النجاح: تم تأكيد حجزك بنجاح
      • إعادة توجيه النجاح: BookingDetails
      الاشعارات

      العنوان : تأكيد الحجز
      الرسالة : تم تجميد مبلغ الحجز بنجاح. تم تأكيد الحجز الآن
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل, SMS  المستقبل : طالب الخدمة

      3.11.2.4- إرسال رسالة تحتوي على رمز تأكيد لإكمال عملية إضافة الأموال في حالة عدم توافر الرصيد الكافي لضمان استكمال الحجز

      graph LR; A[Start] --> B[Check Balance]; B -- Insufficient --> C[Send Confirmation Code]; C --> D[User Enters Code]; D --> E[Verify Code]; E -- Valid --> F[Add Funds]; F --> G[Booking Confirmed]; E -- Invalid --> H[Show Error]; H --> D;
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • رصيد طالب الخدمة في المحفظة غير كافٍ لإتمام الحجز
      الشروط اللاحقة
      • استلام طالب الخدمة لرسالة تحتوي على رمز تأكيد لإضافة الأموال
      تفاصيل ال API
      Method: POST || Endpoint: /api/send-confirmation-code
      Request Headers
      Authorization: Bearer token

      Request Body

      user_id: نص

      Response

      الحالةالمحتوى
      200status: نص message: تم إرسال رمز التأكيد بنجاح
      الوصف: Success
      400error: Invalid user ID
      الوصف: Bad Request
      500error: An error occurred while processing your request
      الوصف: Internal Server Error

      تفاصيل الواجهات
      تأكيد إضافة الأموال

      • textblock
        • Your balance is insufficient. Please enter the confirmation code sent to your registered phone number to add funds

      • form
        • text
          • العنوان : رمز التأكيد
          • التحقق : "required": true, "pattern": "^[0-9]{6}$", "error_message": "Please enter a valid 6-digit confirmation code"
      • رسالة زر الإرسال: إضافة الأموال
      • رسالة النجاح: تمت إضافة الأموال بنجاح
      • إعادة توجيه النجاح: BookingDetails
      الاشعارات

      العنوان : تأكيد إضافة الأموال
      الرسالة : يرجى إدخال رمز التأكيد المرسل إلى هاتفك المسجل لإضافة الأموال وإكمال حجزك
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل, SMS  المستقبل : طالب الخدمة

      3.11.2.5- إضافة الأموال إلى محفظة طالب الخدمة من خلال واحدة من وسائل الدفع بعد استلام رسالة التأكيد لضمان توفر المبلغ المطلوب لإتمام عملية الحجز

      graph LR; A[Start] --> B[Receive Confirmation Code]; B --> C[Enter Payment Details]; C --> D[Enter Confirmation Code]; D --> E[Verify Code]; E -- Valid --> F[Add Funds]; F --> G[Booking Confirmed]; E -- Invalid --> H[Show Error]; H --> D;
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • استلام طالب الخدمة لرسالة تحتوي على رمز تأكيد لإضافة الأموال
      الشروط اللاحقة
      • إضافة المبلغ المطلوب إلى محفظة طالب الخدمة
      تفاصيل ال API
      Method: POST || Endpoint: /api/add-funds
      Request Headers
      Authorization: Bearer token

      Request Body

      payment_method: نص payment_details: object confirmation_code: نص

      Response

      الحالةالمحتوى
      200status: نص message: تمت إضافة الأموال بنجاح
      الوصف: Success
      400error: Invalid confirmation code or payment details
      الوصف: Bad Request
      500error: An error occurred while processing your request
      الوصف: Internal Server Error

      تفاصيل الواجهات
      إضافة الأموال

      • textblock
        • Please enter the confirmation code sent to your registered phone number to add funds to your wallet

      • form
        • text
          • العنوان : رمز التأكيد
          • التحقق : "required": true, "pattern": "^[0-9]{6}$", "error_message": "Please enter a valid 6-digit confirmation code"
        • text
          • العنوان : طريقة الدفع
          • التحقق : "required": true, "error_message": "يرجى إدخال طريقة دفع صالحة"
        • text
          • العنوان : تفاصيل الدفع
          • التحقق : "required": true, "error_message": "يرجى إدخال تفاصيل دفع صالحة"
      • رسالة زر الإرسال: إضافة الأموال
      • رسالة النجاح: تمت إضافة الأموال بنجاح
      • إعادة توجيه النجاح: BookingDetails
      الاشعارات

      العنوان : تأكيد إضافة الأموال
      الرسالة : يرجى إدخال رمز التأكيد المرسل إلى هاتفك المسجل لإضافة الأموال وإكمال حجزك
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل, SMS  المستقبل : طالب الخدمة

      3.11.2.6- بقاء المبلغ محجوزًا في حساب طالب الخدمة حتى يتم إتمام عملية النقل لضمان أن المبلغ المطلوب متاح ولا يمكن استخدامه لأغراض أخرى

      graph LR; A[Start] --> B[Freeze Amount]; B --> C[Amount Frozen]; C --> D[Complete Transport Service]; D --> E[Unfreeze Amount]; E --> F[End];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • نجاح عملية اضافة المبلغ ال المحفظة
      الشروط اللاحقة
      • المبلغ يبقى محجوزًا في المحفظة حتى يتم إتمام عملية النقل
      تفاصيل ال API
      Method: POST || Endpoint: /api/freeze-amount
      Request Headers
      Authorization: Bearer token

      Request Body

      user_id: نص transaction_id: نص

      Response

      الحالةالمحتوى
      200status: نص message: تم تجميد المبلغ بنجاح حتى يتم الانتهاء من خدمة النقل
      الوصف: Success
      400error: Invalid transaction ID or user ID
      الوصف: Bad Request
      500error: An error occurred while processing your request
      الوصف: Internal Server Error

      تفاصيل الواجهات
      تأكيد تجميد المبلغ

      • textblock
        • The transaction amount has been successfully frozen until the transport service is completed

      الاشعارات

      العنوان : تأكيد تجميد المبلغ
      الرسالة : تم تجميد مبلغ المعاملة بنجاح وسيظل مجمداً حتى يتم الانتهاء من خدمة النقل
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل, SMS  المستقبل : طالب الخدمة

      3.11.2.7- تحديد قيمة الاسترداد في حالة إلغاء طالب الخدمة لعملية النقل بناءً على مدى قرب الناقل من الموقع وما إذا كان قد بدأ في الرحلة

      graph LR; A[Start] --> B[Cancel Transport Request]; B --> C[Verify Cancellation]; C --> D[Calculate Refund]; D --> E[Send Refund Details]; E --> F[End];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • إلغاء طالب الخدمة لعملية النقل
      الشروط اللاحقة
      • حساب قيمة الاسترداد بناءً على معايير محددة
      تفاصيل ال API
      Method: POST || Endpoint: /api/cancel-transport
      Request Headers
      Authorization: Bearer token

      Request Body

      user_id: نص transaction_id: نص

      Response

      الحالةالمحتوى
      200status: نص message: تم حساب الاسترداد بنجاح
      الوصف: Success
      400error: Invalid transaction ID or user ID
      الوصف: Bad Request
      500error: An error occurred while processing your request
      الوصف: Internal Server Error

      تفاصيل الواجهات
      إلغاء النقل

      • textblock
        • Your transport request has been cancelled. The refund amount will be calculated based on how close the transporter was to your location and whether they had started the journey

      الاشعارات

      العنوان : إلغاء طلب النقل
      الرسالة : تم إلغاء طلب النقل الخاص بك. سيتم حساب مبلغ الاسترداد وسيتم إعلامك قريبًا
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل, SMS  المستقبل : طالب الخدمة

      3.12 - إدخال بيانات الحمولة من العميل

      3.12.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • تحقيق تجربة يسيرة ومرنة للعميل أثناء تقديم فائدة متعددة الجوانب بتحديد دقيق لتفاصيل الحمولة بما في ذلك الأصناف، الوزن، القيمة، وظروف النقل
      • تعزيز الشفافية في عملية النقل من خلال السماح للمستلم بتأكيد معرفته باستلام الحمولة
      • تعزيز حماية البضائع من خلال التدقيق الشامل والحصر الدقيق لها
      الجهات المعنية
      • العميل
      • المرسل إليه (المستلم)
      الخطوات الرئيسية
      • العميل يدخل عدد الأصناف للحمولة
      • العميل يدخل البيانات التالية لكل صنف: الوصف، العدد، الوزن/لكل حبة أو وزن الصنف الإجمالي، القيمة لكل حبة أو القيمة الإجمالية للصنف
      • العميل يدخل اشتراطات النقل (ظروف التخزين والعناية المطلوبة من الناقل)
      • إذا كان التحميل أو التنزيل لأكثر من موقع، العميل يوضح ذلك لكل صنف على حدة مع توضيح المُرسل إليه (المستلم) لكل صنف
      • يتم إرسال رسالة نصية للمستلم / للمستلمين تحتوي على رابط لتأكيد معرفته بالحمولة المتجهة إليه والتأكيد عليها من خلال التطبيق اذا كان مسجلا في التطبيق
      الخطوات البديلة
      • في حال عدم تسجيل المستلم في المنصة، يُمكن إجراء التأكيد عن طريق إرسال رمز مؤقت إلى هاتفه المحمول لضمان تعريفه. أما إذا كان المستلم مُسجلاً بالفعل في التطبيق، فيتم تنفيذ عملية التسليم باستخدام رمز QR الموفر من المنصة نفسها
      قصص المستخدمين
      • العميل، بعد إتمام الدفع، أريد أن أتمكن من توصيف الحمولة، حتي اضمن حقوقي المالية
      • العميل، أريد أن أتمكن من إضافة مستلمين الحمولة ومعلوماتهم، حتي يسهل علي الناقل توصيل الحمولة بدون مشاكل
      • المستلم، أود استلام رسالة تضم التفاصيل الشاملة للشحنة الموجهة إلى عنواني، تشمل الوزن، القيمة، وموقع التحميل، لتمكيني من تأكيد معرفتي بهذه المعلومات والاستعداد المناسب
      • العميل، في حالة النقل إلى مواقع متعددة، أريد أن أتمكن من منظمة الحمولة بشكل معكوس لتأكيد استلام كل أصناف الحمولة في الموقع المناسب
      مؤشرات الأداء
      • عدد الطلبات المرسلة للمستلمين غير مسجلين في التطبيق

      3.12.2 حالات الاستخدام

      3.12.2.1- يقوم العميل بإدخال عدد الأصناف للحمولة المراد نقلها عبر المنصة، مما يساعد على ضمان دقة وسلامة المعلومات المقدمة وتحسين تجربة النقل

      graph LR; A[Enter Cargo Details] --> B[Enter Number of Items]; B --> C[Submit Item Count]; C --> D[Item Count Recorded];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • تواجد الحمولة المراد نقلها
      • إمكانية دخول العميل على المنصة
      الشروط اللاحقة
      • النظام يسجل عدد الأصناف المدخلة
      الافتراضات
      • العميل لديه اتصال إنترنت مستقر
      • العميل على دراية باستخدام المنصة
      المدخلاتعدد الأصناف |
      المخرجات
      • تسجيل عدد الأصناف في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /cargo/enter-items-count
      Request Headers
      Authorization: Bearer token

      Request Body

      item_count: integer

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة إدخال عدد العناصر

      • textblock
        • Enter the number of items

      • textblock
        • Please enter the number of items in your cargo

      • form
        • number
          • العنوان : عدد العناصر
          • التحقق : required: 1 error_message: عدد العناصر مطلوب
      • رسالة زر الإرسال: إرسال
      • رسالة النجاح: تم إدخال عدد العناصر بنجاح
      • إعادة توجيه النجاح: NextStepScreen
      الاشعارات

      العنوان : تم إدخال عدد العناصر
      الرسالة : تم تسجيل عدد العناصر في حمولتك بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : client

      3.12.2.2- العميل يقوم بإدخال تفاصيل كل صنف في الحمولة المراد نقلها عبر المنصة، بما في ذلك الوصف، العدد، الوزن والقيمة، مما يضمن دقة وسلامة المعلومات المقدمة وتحسين تجربة النقل

      graph LR; A[Enter Cargo Details] --> B[Enter Item Details]; B --> C[Submit Item Details]; C --> D[Item Details Recorded];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • إدخال العميل لعدد الأصناف
      الشروط اللاحقة
      • النظام يسجل تفاصيل الأصناف
      الافتراضات
      • العميل لديه اتصال إنترنت مستقر
      • العميل على دراية باستخدام المنصة
      المدخلاتتفاصيل الأصناف (الوصف، العدد، الوزن، القيمة) |
      المخرجات
      • تسجيل تفاصيل الأصناف في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /cargo/enter-item-details
      Request Headers
      Authorization: Bearer token

      Request Body

      item_description: نص item_count: integer item_weight: float item_value: float

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة إدخال تفاصيل العناصر

      • textblock
        • Enter the details of each item

      • textblock
        • Please enter the details of each item in your cargo

      • form
        • text
          • العنوان : وصف العنصر
          • التحقق : required: 1 error_message: وصف العنصر مطلوب
        • number
          • العنوان : عدد العناصر
          • التحقق : required: 1 error_message: عدد العناصر مطلوب
        • number
          • العنوان : وزن العنصر
          • التحقق : required: 1 error_message: وزن العنصر مطلوب
        • number
          • العنوان : قيمة العنصر
          • التحقق : required: 1 error_message: قيمة العنصر مطلوبة
      • رسالة زر الإرسال: إرسال
      • رسالة النجاح: تم إدخال تفاصيل العنصر بنجاح
      • إعادة توجيه النجاح: NextStepScreen
      الاشعارات

      العنوان : تم إدخال تفاصيل العنصر
      الرسالة : تم تسجيل تفاصيل كل عنصر في حمولتك بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : client

      3.12.2.3- يقوم العميل بإدخال اشتراطات النقل مثل ظروف التخزين والعناية المطلوبة من الناقل لكل صنف في الحمولة، لضمان نقل الأصناف بطريقة صحيحة وآمنة

      graph LR; A[Enter Cargo Details] --> B[Enter Item Details]; B --> C[Enter Transport Requirements]; C --> D[Submit Transport Requirements]; D --> E[Transport Requirements Recorded];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • إدخال تفاصيل الأصناف
      الشروط اللاحقة
      • النظام يسجل اشتراطات النقل
      الافتراضات
      • العميل لديه اتصال إنترنت مستقر
      • العميل على دراية باستخدام المنصة
      المدخلاتاشتراطات النقل لكل صنف |
      المخرجات
      • تسجيل اشتراطات النقل في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /cargo/enter-transport-requirements
      Request Headers
      Authorization: Bearer token

      Request Body

      item_id: integer storage_conditions: نص care_requirements: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة إدخال متطلبات النقل

      • textblock
        • Enter Transport Requirements

      • textblock
        • Please enter the storage and care requirements for each item in your cargo

      • form
        • text
          • العنوان : شروط التخزين
          • التحقق : required: 1 error_message: شروط التخزين مطلوبة
        • text
          • العنوان : متطلبات الرعاية
          • التحقق : required: 1 error_message: متطلبات الرعاية مطلوبة
      • رسالة زر الإرسال: إرسال
      • رسالة النجاح: تم إدخال متطلبات النقل بنجاح
      • إعادة توجيه النجاح: NextStepScreen
      الاشعارات

      العنوان : تم إدخال متطلبات النقل
      الرسالة : تم تسجيل متطلبات النقل لحمولتك بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : client

      3.12.2.4- إذا كان التحميل أو التنزيل لأكثر من موقع، العميل يوضح ذلك لكل صنف على حدة مع توضيح المُرسل إليه (المستلم) لكل صنف، لضمان وصول الحمولة إلى المواقع الصحيحة

      graph LR; A[Enter Cargo Details] --> B[Enter Item Details]; B --> C[Enter Transport Requirements]; C --> D[Enter Loading and Unloading Locations]; D --> E[Submit Loading and Unloading Locations]; E --> F[Loading and Unloading Locations Recorded];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • إدخال العميل لتفاصيل الأصناف واشتراطات النقل
      الشروط اللاحقة
      • النظام يسجل مواقع التحميل والتنزيل
      • النظام يسجل معلومات المستلم لكل صنف
      الافتراضات
      • العميل لديه اتصال إنترنت مستقر
      • العميل على دراية باستخدام المنصة
      المدخلاتمواقع التحميل والتنزيل | معلومات المستلم لكل صنف |
      المخرجات
      • تسجيل مواقع التحميل والتنزيل في النظام
      • تسجيل معلومات المستلم لكل صنف في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /cargo/enter-loading-unloading-locations
      Request Headers
      Authorization: Bearer token

      Request Body

      item_id: integer loading_location: نص unloading_location: نص recipient_info: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة إدخال مواقع التحميل والتفريغ

      • textblock
        • Enter Loading and Unloading Locations

      • textblock
        • Please enter the loading and unloading locations for each item in your cargo

      • form
        • text
          • العنوان : موقع التحميل
          • التحقق : required: 1 error_message: موقع التحميل مطلوب
        • text
          • العنوان : موقع التفريغ
          • التحقق : required: 1 error_message: موقع التفريغ مطلوب
        • text
          • العنوان : معلومات المستلم
          • التحقق : required: 1 error_message: معلومات المستلم مطلوبة
      • رسالة زر الإرسال: إرسال
      • رسالة النجاح: تم إدخال مواقع التحميل والتفريغ بنجاح
      • إعادة توجيه النجاح: NextStepScreen
      الاشعارات

      العنوان : تم إدخال مواقع التحميل والتفريغ
      الرسالة : تم تسجيل مواقع التحميل والتفريغ لحمولتك بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : client

      3.12.2.5- النظام يقوم بإرسال رسالة نصية للمستلم أو المستلمين تحتوي على رابط لتأكيد معرفتهم بالحمولة المتجهة إليهم، ويتيح لهم التأكيد عبر التطبيق إذا كانوا مسجلين فيه

      graph LR; A[Enter Cargo Details] --> B[Enter Item Details]; B --> C[Enter Transport Requirements]; C --> D[Enter Loading and Unloading Locations]; D --> E[Send Confirmation Link]; E --> F[Confirmation Link Sent];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • النظام يسجل جميع تفاصيل الحمولة ومعلومات المستلمين
      الشروط اللاحقة
      • المستلم يتلقى رسالة نصية تحتوي على رابط لتأكيد الحمولة
      الافتراضات
      • العميل أدخل معلومات دقيقة وصحيحة عن المستلم
      • المستلم لديه وسيلة للوصول إلى الإنترنت لتأكيد الحمولة
      المدخلاتمعلومات المستلم | تفاصيل الحمولة |
      المخرجات
      • رسالة نصية تحتوي على رابط تأكيد الحمولة
      تفاصيل ال API
      Method: POST || Endpoint: /cargo/send-confirmation-link
      Request Headers
      Authorization: Bearer token

      Request Body

      recipient_phone: نص cargo_details: object

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة إرسال رابط التأكيد

      • textblock
        • Send Confirmation Link

      • textblock
        • Please enter the recipient's phone number to send the confirmation link

      • form
        • text
          • العنوان : رقم هاتف المستلم
          • التحقق : required: 1 error_message: رقم هاتف المستلم مطلوب
        • text
          • العنوان : تفاصيل الحمولة
          • التحقق : required: 1 error_message: تفاصيل الحمولة مطلوبة
      • رسالة زر الإرسال: Send Link
      • رسالة النجاح: تم إرسال رابط التأكيد بنجاح
      • إعادة توجيه النجاح: NextStepScreen
      الاشعارات

      العنوان : تم إرسال رابط التأكيد
      الرسالة : تم إرسال رابط التأكيد لحمولتك بنجاح إلى المستلم
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : client

      3.13 - قبول الناقل للحمولة

      3.13.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • إتاحة الفرصة للناقلين لقبول أو رفض النقلات المقترحة، وتأكيد الربط بين العميل والناقل في حالة القبول
      الجهات المعنية
      • العميل
      • الناقل
      الخطوات الرئيسية
      • العميل يؤكد معلومات الحمولة
      • النظام يرسل QR للعميل
      • الناقل يمسح QR لكي يوافق على نقل الحمولة
      • النظام يقوم بربط العميل والناقل سوياً
      الخطوات البديلة
      قصص المستخدمين
      • الناقل، بمجرد تلقي إشعار من النظام، أرغب في القدرة على الموافقة على الحمولة التي تم اسنادها لي
      • العميل، بعد تأكيد معلومات الحمولة، أرغب في العلم بأن المهمة قد تم توجيهها إلى الناقل وأن الناقل قد وافق عليها
      مؤشرات الأداء

      3.13.2 حالات الاستخدام

      3.13.2.1- العميل يؤكد معلومات الحمولة التي سيتم نقلها عبر النظام لضمان دقة البيانات المقدمة قبل إرسال رمز الاستجابة السريعة (QR) للناقل

      graph LR; A[Client reviews and confirms cargo details] --> B[System sends QR code to client]; B --> C[Client receives QR code]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • وجود الحمولة المراد نقلها
      • اكتمال بيانات الحمولة
      الشروط اللاحقة
      • النظام يرسل رمز QR للعميل
      تسلسل الأحداث
      • العميل يدخل على منصة النظام
      • العميل يقوم بمراجعة وتأكيد معلومات الحمولة
      • النظام يرسل رمز QR للعميل
      الافتراضات
      • العميل يمتلك حسابًا نشطًا في النظام
      المدخلاتمعلومات الحمولة (الوصف، الوزن، الحجم، إلخ) |
      المخرجات
      • تأكيد معلومات الحمولة
      • إرسال رمز QR للعميل
      تفاعلات المستخدم
      • العميل يتفاعل مع واجهة النظام لمراجعة وتأكيد معلومات الحمولة
      سيناريوهات الاستخدام
      • عميل يريد نقل حمولة ويتأكد من تفاصيلها قبل إرسالها للناقل
      متطلبات الأمان
      • تأكيد هوية العميل قبل السماح له بتأكيد معلومات الحمولة
      القيود والافتراضات
      • يجب أن يكون النظام متاحًا عند مراجعة وتأكيد معلومات الحمولة
      متطلبات الاختبار
      • اختبارات التحقق من صحة بيانات الحمولة المدخلة
      • اختبارات إرسال رمز QR بعد تأكيد الحمولة
      تفاصيل ال API
      Method: POST || Endpoint: /confirm-cargo
      Request Headers
      Authorization: Bearer token

      Request Body

      cargo_description: نص cargo_weight: number cargo_volume: number

      Response

      الحالةالمحتوى
      200status: نص qr_code: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تأكيد الحمولة

      • form
        • text
          • العنوان : وصف الحمولة
          • التحقق : {"required":true,"error_message":"وصف الحمولة مطلوب"}
        • number
          • العنوان : وزن الحمولة
          • التحقق : {"required":true,"error_message":"وزن الحمولة مطلوب"}
        • number
          • العنوان : حجم الحمولة
          • التحقق : {"required":true,"error_message":"حجم الحمولة مطلوب"}
      • رسالة زر الإرسال: Confirm Cargo
      • رسالة النجاح: تم تأكيد الحمولة بنجاح!
      • إعادة توجيه النجاح: CargoDetailsScreen
      الاشعارات

      العنوان : تأكيد الحمولة
      الرسالة : تم تأكيد تفاصيل الحمولة الخاصة بك. يرجى استخدام رمز QR المقدم للخطوات التالية
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : client

      3.13.2.2- النظام يرسل رمز QR للعميل بعد تأكيد العميل لمعلومات الحمولة. هذا الرمز يستخدمه الناقل للموافقة على نقل الحمولة

      graph LR; A[Client confirms cargo details] --> B[System generates QR code]; B --> C[System sends QR code to client]; C --> D[Client receives QR code]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • تأكيد العميل لمعلومات الحمولة
      الشروط اللاحقة
      • العميل يستلم رمز QR
      • الناقل يستلم إشعار النقل
      تسلسل الأحداث
      • تأكيد العميل لمعلومات الحمولة
      • توليد رمز QR
      • إرسال رمز QR للعميل
      الافتراضات
      • النظام قادر على توليد وإرسال رموز QR بشكل صحيح
      المدخلاتمعلومات الحمولة المؤكدة من قبل العميل |
      المخرجات
      • رمز QR فريد
      تفاعلات المستخدم
      • تأكيد معلومات الحمولة من قبل العميل
      • استلام رمز QR
      سيناريوهات الاستخدام
      • عميل يؤكد معلومات الحمولة ويريد استلام رمز QR لاستخدامه من قبل الناقل
      متطلبات الأمان
      • تأكيد هوية العميل قبل إرسال رمز QR
      القيود والافتراضات
      • يجب أن يكون النظام متاحًا لإنشاء وإرسال رمز QR
      متطلبات الاختبار
      • اختبارات التحقق من صحة توليد رموز QR
      • اختبارات إرسال رمز QR بعد تأكيد الحمولة
      تفاصيل ال API
      Method: POST || Endpoint: /generate-qr
      Request Headers
      Authorization: Bearer token

      Request Body

      cargo_details: object

      Response

      الحالةالمحتوى
      200qr_code: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة توليد رمز QR

      • textblock
        • Cargo details have been confirmed. Your QR code is being generated

      الاشعارات

      العنوان : تم توليد رمز QR
      الرسالة : تم توليد رمز QR لحمولتك المؤكدة. يرجى استخدامه لمتابعة الشحنة
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : client

      3.13.2.3- الناقل يمسح رمز QR الذي استلمه من العميل للموافقة على نقل الحمولة. عند مسح الرمز، يتم تحديث حالة الحمولة في النظام ويبدأ عملية النقل

      graph LR; A[Carrier receives notification with QR code] --> B[Carrier scans QR code]; B --> C[System updates cargo status]; C --> D[Client and carrier are linked]
      العنوانالتفاصيل
      المستخدمالناقل
      الشروط المسبقة
      • استلام الناقل لإشعار النقل
      • توافر رمز QR لدى العميل
      الشروط اللاحقة
      • النظام يقوم بربط العميل والناقل سوياً
      تسلسل الأحداث
      • استلام الناقل لإشعار النقل مع رمز QR
      • مسح الناقل لرمز QR
      الافتراضات
      • النظام قادر على معالجة رموز QR بشكل صحيح
      المدخلاترمز QR |
      المخرجات
      • تحديث حالة الحمولة في النظام
      • ربط العميل والناقل
      تفاعلات المستخدم
      • الناقل يمسح رمز QR باستخدام التطبيق
      سيناريوهات الاستخدام
      • ناقل يستلم رمز QR من العميل ويقوم بمسحه للموافقة على نقل الحمولة
      متطلبات الأمان
      • تأكيد هوية الناقل قبل السماح بمسح رمز QR
      القيود والافتراضات
      • يجب أن يكون النظام متاحًا لمعالجة مسح رمز QR
      متطلبات الاختبار
      • اختبارات التحقق من صحة مسح رموز QR
      • اختبارات تحديث حالة الحمولة بعد مسح رمز QR
      تفاصيل ال API
      Method: POST || Endpoint: /scan-qr
      Request Headers
      Authorization: Bearer token

      Request Body

      qr_code: نص

      Response

      الحالةالمحتوى
      200status: نص cargo_details: object
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة مسح رمز QR

      • form
        • text
          • العنوان : رمز QR
          • التحقق : {"required":true,"error_message":"رمز QR مطلوب"}
      • رسالة زر الإرسال: Scan QR
      • رسالة النجاح: تم مسح رمز QR بنجاح!
      • إعادة توجيه النجاح: CargoDetailsScreen
      الاشعارات

      العنوان : تعيين الحمولة
      الرسالة : لقد قمت بمسح رمز QR بنجاح وقبلت الحمولة. يرجى متابعة الشحنة
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : carrier

      3.13.2.4- النظام يقوم بربط العميل والناقل سوياً بعد أن يقوم الناقل بمسح رمز QR لتأكيد موافقته على نقل الحمولة. يتم إرسال تأكيد الربط لكل من العميل والناقل

      graph LR; A[Carrier scans QR code] --> B[System receives confirmation]; B --> C[System links cargo details]; C --> D[System sends confirmation to client and carrier]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • موافقة الناقل على نقل الحمولة عبر مسح رمز QR
      الشروط اللاحقة
      • تأكيد الربط بين العميل والناقل
      تسلسل الأحداث
      • النظام يتلقى تأكيد الموافقة من الناقل عبر مسح رمز QR
      • النظام يربط معلومات الحمولة بالعميل والناقل سوياً
      • النظام يرسل تأكيد الربط لكل من العميل والناقل
      الافتراضات
      • النظام قادر على معالجة مسح رموز QR بشكل صحيح
      المدخلاتتأكيد الموافقة عبر رمز QR |
      المخرجات
      • تأكيد الربط بين العميل والناقل
      تفاعلات المستخدم
      • مسح الناقل لرمز QR باستخدام التطبيق
      سيناريوهات الاستخدام
      • ناقل يقوم بمسح رمز QR لتأكيد موافقته على نقل الحمولة، والنظام يربط معلومات الحمولة بالعميل والناقل
      متطلبات الأمان
      • تأكيد هوية الناقل قبل معالجة موافقته عبر رمز QR
      القيود والافتراضات
      • يجب أن يكون النظام متاحًا لمعالجة مسح رمز QR
      متطلبات الاختبار
      • اختبارات التحقق من صحة مسح رموز QR
      • اختبارات تحديث حالة الحمولة وربطها بين العميل والناقل
      تفاصيل ال API
      Method: POST || Endpoint: /link-cargo
      Request Headers
      Authorization: Bearer token

      Request Body

      qr_code: نص

      Response

      الحالةالمحتوى
      200status: نص linked_details: object
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة ربط الحمولة

      • textblock
        • Cargo has been successfully linked to the client and carrier

      الاشعارات

      العنوان : تم ربط الحمولة
      الرسالة : تم ربط الحمولة الخاصة بك بنجاح بالناقل. يرجى متابعة الخطوات التالية
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : client

      العنوان : تم ربط الحمولة
      الرسالة : لقد أكدت الحمولة بنجاح. يرجى متابعة الشحنة
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : carrier

      3.14 - جرد الناقل للحمولة

      3.14.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • تأكيد استلام الناقل للحمولة المطلوب نقلها وإثبات هذا من خلال التقاط صور والايصالات الالكترونية
      الجهات المعنية
      • الناقل
      • المستلم
      • إداري النظام
      الخطوات الرئيسية
      • يقوم الناقل بمعاينة بيان الحمولة واختيار الأصناف التي يستلمها في شاحنته، إما كل صنف على حدة أو جميعها معًا
      • عند انتهاء استلام كافة الأصناف في بيان الحمولة، يقر الناقل باستلام الأصناف حسب وصفاتها وأعدادها في بيان الحمولة وأنها سليمة
      • يلتقط الناقل ثلاث صور للحمل (ثلث الحمولة، ثلثي الحمولة، كامل الحمولة) من خلال التطبيق
      • يرفق الناقل نسخة إلكترونية من المستندات الخاصة بالحمولة ويؤكد تسليم الأصول للمستلم
      الخطوات البديلة
      • في حالة وجود أية ملاحظات على الأصناف، يمكن للناقل اختيار خيار استلام الأصناف (تم الاستلام بدون ملاحظات/تم الاستلام مع ملاحظات)، حيث يجب كتابة الملاحظات المرصودة
      قصص المستخدمين
      • الناقل: أرغب في مراجعة بيان الحمولة واختيار الأصناف التي يمكنني استلامها، لضمان أنني قمت بتحميل جميع الأصناف المطلوبة
      • الناقل: أرغب في التقاط صور للشحنة ورفعها عبر التطبيق، للتحقق من استلامي للأصناف بالتطابق مع المواصفات المذكورة في بيان الحمولة
      • الناقل: أريد رفع نسخة إلكترونية من المستندات الخاصة بالحمولة، للتأكيد على استلامي للأصناف
      • الإداري: أود أن أمتلك القدرة على تفعيل وتعطيل عملية الجرد بأكملها أو جزء منها حسب رغبتي، بهدف مراقبة وتنظيم العملية بطريقة أكثر فاعلية
      مؤشرات الأداء
      • المدة الزمنية المحددة لتحميل وقبول استلام الشحنة

      3.14.2 حالات الاستخدام

      3.14.2.1- معاينة الناقل لبيان الحمولة واختيار الأصناف التي يستلمها

      graph LR A[استلام إشعار بالحمولة] --> B[معاينة بيان الحمولة] B --> C{اختيار الأصناف} C --> D[تأكيد استلام الأصناف] C --> E[تسجيل الملاحظات] E --> D
      العنوانالتفاصيل
      المستخدمالناقل
      الشروط المسبقة
      • وجود بيان الحمولة
      الشروط اللاحقة
      • تحديد الأصناف المستلمة في الشاحنة
      تسلسل الأحداث
      • استلام إشعار بالحمولة
      • معاينة بيان الحمولة
      • اختيار الأصناف المستلمة
      • تأكيد استلام الأصناف
      الخطوات البديلةوجود ملاحظات على الأصناف
      • الناقل يختار خيار 'تم الاستلام مع ملاحظات'
      • الناقل يكتب الملاحظات المرصودة
      • النظام يسجل الملاحظات
      الافتراضات
      • الناقل لديه القدرة على الوصول إلى بيان الحمولة إلكترونيًا
      الملاحظات والمشاكل
      • يجب التحقق من مطابقة الأصناف للبيان قبل التأكيد
      • يجب أن يكون النظام قادرًا على التعامل مع ملاحظات الناقل وتسجيلها بدقة
      المدخلاتبيان الحمولة | ملاحظات الناقل (في حالة وجودها) |
      المخرجات
      • تأكيد استلام الأصناف
      • سجل بالملاحظات (إن وجدت)
      تفاعلات المستخدم
      • شاشة معاينة بيان الحمولة
      • خيارات تحديد الأصناف
      • نموذج تسجيل الملاحظات
      الشروط الخاصة
      • في حالة وجود اختلاف بين الأصناف المسلمة وبيان الحمولة
      سيناريوهات الاستخدام
      • حالة: استلام حمولة بدون ملاحظات
      • حالة: استلام حمولة مع ملاحظات
      متطلبات الأمان
      • يجب أن تكون بيانات الحمولة محمية ومشفرة
      • يجب التحقق من هوية الناقل قبل السماح له بمعاينة البيان
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة المخزون لتحديث حالة الأصناف المستلمة
      القيود والافتراضات
      • يجب أن يكون النظام متاحًا عبر الإنترنت
      • يجب أن يكون الناقل مدربًا على استخدام النظام
      متطلبات الاختبار
      • اختبار قدرة النظام على عرض بيان الحمولة
      • اختبار عملية تسجيل الملاحظات وتأكيد الاستلام
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/shipments/{shipmentId}/receive
      Request Headers
      Authorization: Bearer token

      Request Body

      items: array notes: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request
      401
      الوصف: Unauthorized

      تفاصيل الواجهات
      تفتيش الشحنة

      • textblock
        • تفاصيل الحمولة

      • list
        • النوع : items: shipmentItems

      • form
        • Checkbox
          • العنوان : استلام بدون ملاحظات
        • textarea
          • العنوان : ملاحظات
      • رسالة زر الإرسال: تأكيد الاستلام
      • رسالة النجاح: تم تأكيد الاستلام بنجاح
      • إعادة توجيه النجاح: الصفحة الرئيسية
      الاشعارات

      العنوان : تأكيد استلام الحمولة
      الرسالة : تم استلام الحمولة بنجاح من قبل الناقل
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : المستلم

      3.14.2.2- التقاط صور الحمولة بواسطة الناقل

      graph LR A[استلام الأصناف في الشاحنة] --> B[التقاط الصور -ثلث، ثلثين، كامل الحمولة-] B --> C[رفع الصور عبر التطبيق]
      العنوانالتفاصيل
      المستخدمالناقل
      الشروط المسبقة
      • استلام الأصناف في الشاحنة
      الشروط اللاحقة
      • وجود صور الحمولة المرفوعة على النظام
      تسلسل الأحداث
      • استلام الأصناف في الشاحنة
      • التقاط الصور (ثلث، ثلثين، كامل الحمولة)
      • رفع الصور عبر التطبيق
      الافتراضات
      • الناقل لديه إمكانية الوصول إلى الكاميرا عبر التطبيق
      الملاحظات والمشاكل
      • يجب أن تكون الصور واضحة وتظهر الحمولة بشكل كامل
      • يجب أن يكون النظام قادرًا على تحميل الصور بسرعة وبدون أخطاء
      المدخلاتصور الحمولة |
      المخرجات
      • صور الحمولة مرفوعة على النظام
      تفاعلات المستخدم
      • شاشة التقاط الصور
      • خيارات رفع الصور
      سيناريوهات الاستخدام
      • حالة: التقاط صور الحمولة بدون مشاكل
      • حالة: حدوث خطأ أثناء رفع الصور
      متطلبات الأمان
      • يجب أن تكون الصور محمية ومشفرة
      • يجب التحقق من هوية الناقل قبل السماح له برفع الصور
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة المستندات لتخزين الصور
      القيود والافتراضات
      • يجب أن يكون النظام متاحًا عبر الإنترنت
      • يجب أن يكون الناقل مدربًا على استخدام النظام
      متطلبات الاختبار
      • اختبار قدرة النظام على التقاط الصور
      • اختبار عملية رفع الصور
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/shipments/{shipmentId}/photos
      Request Headers
      Authorization: Bearer token

      Request Body

      photos: array

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request
      401
      الوصف: Unauthorized

      تفاصيل الواجهات
      صور الشحنة

      • textblock
        • التقط صور الحمولة

      • form
        • Button
          • العنوان : رفع الصور
          • الخيارات : uploadPhotos
      الاشعارات

      العنوان : صور الحمولة مرفوعة
      الرسالة : تم رفع صور الحمولة بواسطة الناقل
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : المستلم

      3.14.2.3- إرفاق المستندات الإلكترونية للحمولة بواسطة الناقل

      graph LR A[تجهيز المستندات] --> B[إرفاق المستندات عبر التطبيق] B --> C[تأكيد تسليم الأصول]
      العنوانالتفاصيل
      المستخدمالناقل
      الشروط المسبقة
      • وجود المستندات الخاصة بالحمولة
      الشروط اللاحقة
      • المستندات مرفوعة على النظام
      تسلسل الأحداث
      • تجهيز المستندات
      • إرفاق المستندات عبر التطبيق
      • تأكيد تسليم الأصول
      الافتراضات
      • الناقل لديه القدرة على الوصول إلى المستندات إلكترونيًا
      الملاحظات والمشاكل
      • يجب أن تكون المستندات بصيغة مقبولة وذات دقة عالية
      • يجب أن يكون النظام قادرًا على تحميل المستندات بسرعة وبدون أخطاء
      المدخلاتالمستندات الإلكترونية للحمولة |
      المخرجات
      • المستندات مرفوعة على النظام
      تفاعلات المستخدم
      • شاشة إرفاق المستندات
      • خيارات رفع المستندات
      سيناريوهات الاستخدام
      • حالة: إرفاق المستندات بدون مشاكل
      • حالة: حدوث خطأ أثناء رفع المستندات
      متطلبات الأمان
      • يجب أن تكون المستندات محمية ومشفرة
      • يجب التحقق من هوية الناقل قبل السماح له بإرفاق المستندات
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة المستندات لتخزين المستندات
      القيود والافتراضات
      • يجب أن يكون النظام متاحًا عبر الإنترنت
      • يجب أن يكون الناقل مدربًا على استخدام النظام
      متطلبات الاختبار
      • اختبار قدرة النظام على إرفاق المستندات
      • اختبار عملية رفع المستندات
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/shipments/{shipmentId}/documents
      Request Headers
      Authorization: Bearer token

      Request Body

      documents: array

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request
      401
      الوصف: Unauthorized

      تفاصيل الواجهات
      وثائق الشحنة

      • textblock
        • إرفاق المستندات

      • form
        • file
          • العنوان : اختر المستندات لرفعها
        • Button
          • العنوان : رفع المستندات
          • الخيارات : uploadDocuments
      الاشعارات

      العنوان : مستندات الحمولة مرفوعة
      الرسالة : تم رفع مستندات الحمولة بواسطة الناقل
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : المستلم

      3.14.2.4- استلام الأصناف بوجود ملاحظات على الحالة أو الكمية

      graph LR A[وجود ملاحظات على الأصناف] --> B[اختيار خيار 'تم الاستلام مع ملاحظات'] B --> C[كتابة الملاحظات وتسجيلها في النظام]
      العنوانالتفاصيل
      المستخدمالناقل
      الشروط المسبقة
      • وجود ملاحظات على الأصناف
      الشروط اللاحقة
      • الملاحظات مسجلة في النظام
      تسلسل الأحداث
      • وجود ملاحظات على الأصناف
      • اختيار خيار 'تم الاستلام مع ملاحظات'
      • كتابة الملاحظات وتسجيلها في النظام
      الافتراضات
      • الناقل يستطيع تسجيل الملاحظات إلكترونيًا
      الملاحظات والمشاكل
      • يجب أن تكون الملاحظات مفصلة ودقيقة
      • يجب أن يكون النظام قادرًا على تسجيل الملاحظات بدون أخطاء
      المدخلاتملاحظات الناقل |
      المخرجات
      • سجل بالملاحظات المسجلة
      تفاعلات المستخدم
      • شاشة تسجيل الملاحظات
      سيناريوهات الاستخدام
      • حالة: استلام أصناف بحالة جيدة مع ملاحظات طفيفة
      • حالة: استلام أصناف بحالة سيئة مع ملاحظات جوهرية
      متطلبات الأمان
      • يجب حماية الملاحظات وتشفيرها
      • يجب التحقق من هوية الناقل قبل تسجيل الملاحظات
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة المخزون لتحديث حالة الأصناف
      القيود والافتراضات
      • يجب أن يكون النظام متاحًا عبر الإنترنت
      • يجب أن يكون الناقل مدربًا على استخدام النظام
      متطلبات الاختبار
      • اختبار قدرة النظام على تسجيل الملاحظات
      • اختبار دقة الملاحظات المسجلة
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/shipments/{shipmentId}/notes
      Request Headers
      Authorization: Bearer token

      Request Body

      notes: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request
      401
      الوصف: Unauthorized

      تفاصيل الواجهات
      ملاحظات الشحنة

      • textblock
        • تسجيل ملاحظات الأصناف

      • form
        • textarea
          • العنوان : اكتب ملاحظاتك هنا
        • Button
          • العنوان : تسجيل الملاحظات
          • الخيارات : submitNotes
      الاشعارات

      العنوان : ملاحظات على الأصناف المستلمة
      الرسالة : تم تسجيل ملاحظات على الأصناف المستلمة بواسطة الناقل
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : المستلم

      3.15 - متابعة الرحلة

      3.15.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • اتاحة الامكانية للأطراف المعنية بمتابعة الحمولة في الوقت الحقيقي
      الجهات المعنية
      • العميل (مرسل، مستلم)
      • شركة النقل
      الخطوات الرئيسية
      • بدء الرحلة عند تأكيد استلام الحمولة
      • يحسب النظام الوقت المتوقع للوصول إلى الوجهة/الوجهات المقصودة بناءً على العوامل التالية: السرعة المتوسطة (65كم/ساعة)، العدد المتوقع لساعات التوقف خلال الرحلة، عدد ساعات الراحة المتوقعة للشاحن خلال الرحلة
      • يتيح النظام تتبع الموقع الحالي للشاحن على الخريطة
      • مراقبة البيانات الواردة من أجهزة الاستشعار إذا كانت متوفرة
      • مراقبة حالة العقبات المتوقعة في مسار الرحلة
      الخطوات البديلة
      قصص المستخدمين
      • كمشرف، أريد أن أعرف الموقع الحالي للحمولة، حتى أتمكن من توفير تحديثات سريعة للعميل
      • كمشرف، أريد أن أتابع بيانات الاستشعار، بما في ذلك الحرارة والصور، حتى أتأكد من سلامة الحمولة
      • كمشرف، أريد أن أعرف حالة الطرق المقبلة، حتى أتمكن من إبلاغ الشاحن بالتحديثات المطلوبة
      • كعميل، أريد أن أتابع الحمولة في الوقت الحقيقي، حتى أتمكن من التخطيط بشكل أفضل لوصول الحمولة
      مؤشرات الأداء
      • الزمن المستغرق للرحلة
      • المسافة المقطوعة
      • عدد فترات التوقف لفترات طويلة
      • قيمة أجرة النقل بالنسبة للمسافة والزمن للرحلة (ريال/كم، ريال/ساعة أو يوم)

      3.15.2 حالات الاستخدام

      3.15.2.1- بدء الرحلة عند تأكيد استلام الحمولة. هذا يشمل جميع الإجراءات الضرورية من استلام الحمولة حتى بدء الرحلة، مع التأكد من جميع التفاصيل المتعلقة بالشحنة وتحديث حالة النظام

      graph LR A[استلام الحمولة] --> B[تأكيد استلام الحمولة] B --> C[بدء متابعة الرحلة]
      العنوانالتفاصيل
      المستخدمالناقل
      الشروط المسبقة
      • الناقل قد استلم الحمولة
      • النظام قد تحقق من استلام الحمولة بنجاح
      الشروط اللاحقة
      • الرحلة تبدأ والنظام يبدأ في متابعة الرحلة في الوقت الحقيقي
      تسلسل الأحداث
      • استلام الحمولة
      • تأكيد الاستلام
      • بدء الرحلة
      القواعد التجارية
      • يجب أن يكون تأكيد استلام الحمولة متسقًا مع السياسات الأمنية لضمان صحة البيانات
      الافتراضات
      • الناقل قادر على الوصول إلى النظام لتأكيد الاستلام
      • النظام قادر على التحقق من بيانات الحمولة بشكل دقيق
      المتطلبات الخاصة
      • النظام يجب أن يكون قادرًا على التعامل مع كميات كبيرة من البيانات في الوقت الحقيقي
      الملاحظات والمشاكل
      • قد تواجه بعض الحالات التي لا يتم فيها تأكيد الاستلام بسبب مشاكل في الاتصال، ويجب التعامل مع هذه الحالات بشكل يدوي
      المدخلاتبيانات الحمولة | تأكيد استلام الحمولة |
      المخرجات
      • تحديث حالة الرحلة
      • بدء متابعة الرحلة في النظام
      تفاعلات المستخدم
      • الناقل يستخدم النظام لتأكيد استلام الحمولة
      سيناريوهات الاستخدام
      • عملية النقل القياسية بعد استلام الحمولة
      متطلبات الأمان
      • يجب تأكيد استلام الحمولة باستخدام مصادقة ثنائية
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة النقل الداخلي لتحديث حالة الرحلة
      القيود والافتراضات
      • يفترض أن جميع المستخدمين لديهم وصول إلى الإنترنت لإتمام العملية
      متطلبات الاختبار
      • اختبار تأكيد الاستلام في بيئات متعددة لضمان الأداء
      • اختبار تحميل البيانات في النظام في الوقت الحقيقي
      تفاصيل ال API
      Method: POST || Endpoint: /confirm-receipt
      Request Headers
      Authorization: Bearer token

      Request Body

      shipment_id: نص confirmation_status: boolean

      Response

      الحالةالمحتوى
      200status: نص message: تم تأكيد استلام الشحنة
      الوصف: Success
      400
      الوصف: Bad Request

      Method: GET || Endpoint: /track-shipment
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص Location : float, float estimated_arrival: datetime
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تأكيد الاستلام

      • textblock
        • Please confirm the receipt of the shipment

      • form
        • Button
          • العنوان : تأكيد
          • الخيارات : confirmReceipt

      تتبع الشحنة

      • textblock
        • Estimated Arrival Time: {{estimated_arrival}}

      الاشعارات

      العنوان : تم تأكيد استلام الشحنة
      الرسالة : تم تأكيد استلام الشحنة الخاصة بك بنجاح وبدأت الرحلة
      عن طريق : الاشعارات علي الهاتف, ايميل, SMS  المستقبل : العميل

      3.15.2.2- حساب الوقت المتوقع للوصول بناءً على السرعة المتوسطة والعوامل الأخرى. يشمل ذلك جميع الخطوات الضرورية لجمع البيانات المطلوبة، حساب الوقت المتوقع للوصول، وعرضه للمستخدمين

      graph LR A[بدء الرحلة] --> B[جمع بيانات السرعة المتوسطة] B --> C[جمع بيانات التوقف] C --> D[حساب الوقت المتوقع للوصول] D --> E[عرض الوقت المتوقع للوصول]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • الرحلة قد بدأت
      • النظام يحتوي على بيانات السرعة المتوسطة والمدة المتوقعة للتوقف
      الشروط اللاحقة
      • النظام يعرض الوقت المتوقع للوصول
      تسلسل الأحداث
      • جمع البيانات
      • حساب الوقت المتوقع
      • عرض الوقت المتوقع
      القواعد التجارية
      • يجب أن يكون حساب الوقت المتوقع للوصول دقيقًا بناءً على البيانات الفعلية المتاحة
      الافتراضات
      • النظام قادر على جمع البيانات في الوقت الحقيقي
      • البيانات المتاحة للنظام دقيقة ومحدثة
      المتطلبات الخاصة
      • النظام يجب أن يكون قادرًا على معالجة البيانات بسرعة لتوفير تحديثات في الوقت الحقيقي
      الملاحظات والمشاكل
      • قد تواجه بعض الحالات التي تكون فيها البيانات غير متاحة أو غير دقيقة، مما يتطلب تدخلًا يدويًا
      المدخلاتبيانات السرعة المتوسطة | بيانات التوقف |
      المخرجات
      • الوقت المتوقع للوصول
      تفاعلات المستخدم
      • النظام يعرض الوقت المتوقع للوصول للمستخدمين
      سيناريوهات الاستخدام
      • حساب الوقت المتوقع للوصول أثناء الرحلة
      متطلبات الأمان
      • يجب تأمين البيانات المستخدمة في حساب الوقت المتوقع للوصول
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة النقل الداخلي لجمع البيانات
      القيود والافتراضات
      • يفترض أن جميع البيانات المستخدمة متاحة ودقيقة
      متطلبات الاختبار
      • اختبار دقة حساب الوقت المتوقع في بيئات متعددة
      • اختبار أداء النظام في معالجة البيانات في الوقت الحقيقي
      تفاصيل ال API
      Method: GET || Endpoint: /calculate-eta
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص estimated_arrival: datetime
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تتبع الشحنة

      • textblock
        • Estimated Arrival Time: {{estimated_arrival}}

      الاشعارات

      العنوان : الوقت المقدر للوصول
      الرسالة : من المتوقع وصول الشحنة الخاصة بك في {{estimated_arrival}}
      عن طريق : الاشعارات علي الهاتف, ايميل, SMS  المستقبل : العميل

      3.15.2.3- عرض الموقع الحالي للشاحنة على الخريطة في الوقت الحقيقي. يشمل ذلك تحديثات مستمرة للموقع بناءً على البيانات الواردة من نظام GPS وتحليلها لتوفير الموقع الدقيق

      graph LR A[بدء الرحلة] --> B[تحديث بيانات GPS] B --> C[تحليل بيانات GPS] C --> D[عرض الموقع الحالي على الخريطة]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • الرحلة قد بدأت
      • النظام يحتوي على بيانات GPS محدثة
      الشروط اللاحقة
      • الموقع الحالي للشاحنة يعرض بشكل دقيق على الخريطة
      تسلسل الأحداث
      • تحديث بيانات GPS
      • تحليل البيانات
      • عرض الموقع
      القواعد التجارية
      • يجب أن تكون بيانات GPS محدثة ودقيقة لضمان عرض الموقع بشكل صحيح
      الافتراضات
      • النظام قادر على استلام وتحليل بيانات GPS في الوقت الحقيقي
      • بيانات GPS المتاحة دقيقة ومحدثة
      المتطلبات الخاصة
      • النظام يجب أن يكون قادرًا على معالجة وتحديث بيانات GPS بسرعة وفعالية
      الملاحظات والمشاكل
      • قد تواجه بعض الحالات التي تكون فيها بيانات GPS غير متاحة أو غير دقيقة، مما يتطلب تدخلًا يدويًا
      المدخلاتبيانات GPS |
      المخرجات
      • الموقع الحالي للشاحنة على الخريطة
      تفاعلات المستخدم
      • النظام يعرض الموقع الحالي للشاحنة للمستخدمين على الخريطة
      سيناريوهات الاستخدام
      • عرض الموقع الحالي للشاحنة أثناء الرحلة
      متطلبات الأمان
      • يجب تأمين بيانات GPS ضد الوصول غير المصرح به
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة النقل الداخلي لاستلام بيانات GPS
      القيود والافتراضات
      • يفترض أن جميع بيانات GPS المستخدمة متاحة ودقيقة
      متطلبات الاختبار
      • اختبار دقة عرض الموقع الحالي في بيئات متعددة
      • اختبار أداء النظام في معالجة بيانات GPS في الوقت الحقيقي
      تفاصيل ال API
      Method: GET || Endpoint: /current-location
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص Location : float, float
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تتبع الشاحنة

      • form
        • Map
          • العنوان : الخريطة
          • التحقق : "location": { "latitude": "float", "longitude": "float" }
          • الخيارات : "apiKey": "نص"
      الاشعارات

      العنوان : تحديث الموقع الحالي
      الرسالة : تم تحديث الموقع الحالي لشحنتك
      عن طريق : الاشعارات علي الهاتف, ايميل, SMS  المستقبل : العميل

      3.15.2.4- مراقبة البيانات الواردة من أجهزة الاستشعار أثناء الرحلة. يشمل ذلك جمع وتحليل البيانات المتعلقة بحالة الشاحنة والحمولة مثل درجة الحرارة، الاهتزازات، والرطوبة، وعرضها للمستخدمين بشكل مستمر

      graph LR A[بدء الرحلة] --> B[جمع بيانات أجهزة الاستشعار] B --> C[تحليل البيانات] C --> D[عرض البيانات]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • الرحلة قد بدأت
      • النظام يحتوي على أجهزة استشعار متصلة بالشاحنة
      الشروط اللاحقة
      • النظام يعرض بيانات الاستشعار بشكل مستمر ودقيق
      تسلسل الأحداث
      • جمع البيانات
      • تحليل البيانات
      • عرض البيانات
      القواعد التجارية
      • يجب أن تكون البيانات المجمعة دقيقة ويتم تحديثها بشكل مستمر
      الافتراضات
      • النظام قادر على جمع وتحليل البيانات في الوقت الحقيقي
      • جميع أجهزة الاستشعار تعمل بشكل صحيح ومتصلة بالنظام
      المتطلبات الخاصة
      • النظام يجب أن يكون قادرًا على معالجة كميات كبيرة من البيانات بسرعة وفعالية
      الملاحظات والمشاكل
      • قد تواجه بعض الحالات التي تكون فيها أجهزة الاستشعار غير متاحة أو لا تعمل بشكل صحيح، مما يتطلب تدخلًا يدويًا
      المدخلاتبيانات أجهزة الاستشعار |
      المخرجات
      • عرض بيانات الاستشعار
      تفاعلات المستخدم
      • النظام يعرض البيانات الواردة من أجهزة الاستشعار للمستخدمين
      سيناريوهات الاستخدام
      • مراقبة بيانات الشاحنة والحمولة أثناء الرحلة
      متطلبات الأمان
      • يجب تأمين البيانات المجمعة ضد الوصول غير المصرح به
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة النقل الداخلي لاستلام وتحليل بيانات أجهزة الاستشعار
      القيود والافتراضات
      • يفترض أن جميع أجهزة الاستشعار تعمل بشكل صحيح ومتصلة بالنظام
      متطلبات الاختبار
      • اختبار دقة عرض البيانات في بيئات متعددة
      • اختبار أداء النظام في معالجة بيانات أجهزة الاستشعار في الوقت الحقيقي
      تفاصيل ال API
      Method: GET || Endpoint: /sensor-data
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص Data : float, float, float
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      بيانات المستشعر

      • table
        • الاسم : معامل
        • نوع المحتوي : text

        • الاسم : القيمة
        • نوع المحتوي : text

      الاشعارات

      العنوان : تحديث بيانات المستشعر
      الرسالة : بيانات مستشعر جديدة متاحة للشحنة الحالية
      عن طريق : الاشعارات علي الهاتف, ايميل, SMS  المستقبل : المشرف

      3.15.2.5- مراقبة حالة العقبات المتوقعة في مسار الرحلة. يشمل ذلك جمع وتحليل البيانات المتعلقة بالحالة المرورية والعقبات المتوقعة في المسار وعرضها للمستخدمين بشكل مستمر

      graph LR A[بدء الرحلة] --> B[جمع بيانات الحالة المرورية] B --> C[تحليل البيانات] C --> D[عرض حالة العقبات المتوقعة]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • الرحلة قد بدأت
      • النظام يحتوي على بيانات الحالة المرورية والعقبات المتوقعة
      الشروط اللاحقة
      • النظام يعرض حالة العقبات المتوقعة
      تسلسل الأحداث
      • جمع البيانات
      • تحليل البيانات
      • عرض حالة العقبات
      القواعد التجارية
      • يجب أن تكون البيانات المتعلقة بالحالة المرورية محدثة ودقيقة لضمان عرض حالة العقبات بشكل صحيح
      الافتراضات
      • النظام قادر على جمع وتحليل بيانات الحالة المرورية في الوقت الحقيقي
      • البيانات المتاحة للنظام دقيقة ومحدثة
      المتطلبات الخاصة
      • النظام يجب أن يكون قادرًا على معالجة البيانات بسرعة لتوفير تحديثات في الوقت الحقيقي
      الملاحظات والمشاكل
      • قد تواجه بعض الحالات التي تكون فيها البيانات غير متاحة أو غير دقيقة، مما يتطلب تدخلًا يدويًا
      المدخلاتبيانات الحالة المرورية |
      المخرجات
      • حالة العقبات المتوقعة
      تفاعلات المستخدم
      • النظام يعرض حالة العقبات المتوقعة للمستخدمين
      سيناريوهات الاستخدام
      • مراقبة حالة العقبات المتوقعة أثناء الرحلة
      متطلبات الأمان
      • يجب تأمين البيانات المستخدمة في مراقبة حالة العقبات ضد الوصول غير المصرح به
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة النقل الداخلي لجمع البيانات
      القيود والافتراضات
      • يفترض أن جميع البيانات المستخدمة متاحة ودقيقة
      متطلبات الاختبار
      • اختبار دقة عرض حالة العقبات المتوقعة في بيئات متعددة
      • اختبار أداء النظام في معالجة بيانات الحالة المرورية في الوقت الحقيقي
      تفاصيل ال API
      Method: GET || Endpoint: /traffic-conditions
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص traffic_conditions: array
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      حالة المرور

      • table
        • الاسم : الموقع
        • نوع المحتوي : text

        • الاسم : الحالة
        • نوع المحتوي : text

        • الاسم : الشدة
        • نوع المحتوي : text

      الاشعارات

      العنوان : تحديث حالة المرور
      الرسالة : حالة مرور جديدة متاحة لمسارك
      عن طريق : الاشعارات علي الهاتف, ايميل, SMS  المستقبل : السائق

      3.16 - تسليم النقل

      3.16.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • إتمام عملية نقل بسهوله مع ضمان حقوق الطرفين
      الجهات المعنية
      • المستلم
      • المرسل
      • مقدم الخدمة (الناقل)
      الخطوات الرئيسية
      • يتم تسليم الحمولة للمستلم
      • إذا كان المستلم مسجل في التطبيق، يتم التسليم خلال التطبيق بواسطة QR
      • إذا لم يكن المستلم مسجلاً في التطبيق، سيتم إرسال رسالة نصية إلى هاتفه المحمول تتضمن رابطًا لتأكيد استلام الشحنة وبدء عملية الاستلام
      • تتم عملية استلام الشحنة باستخدام آلية جرد تشابه تلك المستخدمة في عملية التسليم بين المرسل والناقل. بمجرد استلام كافة الأصناف وتنزيل الشحنة بالكامل، يُطلب من المستلم التأكيد على استلام الشحنة بالكامل دون أية ملاحظات، أو تسجيل أي ملاحظات متعلقة بالتسليم. هذا الإقرار مشروط بدفع قيمة النقل أو عدمه. في حالة عدم الدفع، يتوجب على المستلم رفع الملاحظات وتوثيقها بالصور مباشرةً عبر التطبيق
      • يُصدر إشعار إلى طالب الخدمة الأساسي، وكذلك إلى الأطراف ذات العلاقة مثل المرسل، يُفيد بأن الشحنة قد تم تسليمها بنجاح
      • في حالة عدم وجود أي ملاحظات تشترط عدم دفع تكلفة النقل، يتم تحويل التكاليف من حساب طالب الخدمة إلى حساب الناقل بعد مرور ساعة من وقت إتمام الإرسال
      • إضافة ارسال إشعار للنظام (المشرف) في حال وجود ملاحظات تعيق عملية تحويل التكاليف
      الخطوات البديلة
      قصص المستخدمين
      • كمستلم، عند استلام الشحنة، أود التأكد من استلام جميع الأصناف وتفريغ الحمولة بالكامل. سأقر بأن التسليم تم بدون أي ملاحظات تعوق الإجراءات، لضمان إتمام المعاملة بسلاسة وحفظ حقوقي
      • كمستلم غير مسجل في التطبيق، أريد أن أستقبل رسالة نصية تحتوي على رابط لتأكيد استلام الحمولة ووضع ملاحظات على التسليم لضمان سلامة القطع والأصناف
      • كطالب خدمة، أريد استلام إشعار بأن الحمولة قد تم تسليمها لكي أكون مطمئن على سير العملية بالشكل المطلوب
      • كمقدم خدمة (ناقل)، أريد تحويل الأجرة من حساب العميل إلى محفظتي أو حسابي البنكي بعد ساعة من تسليم الحمولة، لكي أضمن حصولي على مستحقاتي
      مؤشرات الأداء
      • إحصاء عدد الطلبات التي تم إتمامها بنجاح، بما في ذلك تسليم الشحنة وتصنيفها إلى: مقبولة بدون ملاحظات، مقبولة مع ملاحظات مشروطة بالدفع، أو مقبولة مع ملاحظات بدون شروط الدفع
      • الفترة الزمنية للتنزيل

      3.16.2 حالات الاستخدام

      3.16.2.1- تسليم الحمولة للمستلم المسجل في التطبيق باستخدام QR. يتم هذا عبر قيام الناقل بتسليم الحمولة للمستلم الذي يقوم بمسح رمز QR لتأكيد الاستلام، مما يؤدي إلى تحديث حالة الطلب في النظام

      graph LR; A[Delivery Completed] -->|Scan QR Code| B[Update Order Status]; B --> C[Notify Stakeholders];
      العنوانالتفاصيل
      المستخدمالمستلم
      الشروط المسبقة
      • إتمام عملية النقل
      • المستلم مسجل في التطبيق
      الشروط اللاحقة
      • تأكيد استلام الشحنة
      • تحديث حالة الطلب في النظام
      تسلسل الأحداث
      • الناقل يستلم الحمولة من المرسل
      • الناقل يقوم بنقل الحمولة إلى المستلم
      • المستلم يمسح رمز QR لتأكيد الاستلام
      • النظام يحدث حالة الطلب
      المدخلاترمز QR |
      المخرجات
      • تأكيد استلام الحمولة
      • تحديث حالة الطلب في النظام
      تفاعلات المستخدم
      • تفاعل المستلم مع الناقل لتسلم الحمولة ومسح رمز QR
      سيناريوهات الاستخدام
      • إذا كانت الحمولة تتضمن عدة صناديق، يقوم المستلم بمسح رمز QR لكل صندوق لتأكيد استلامه
      متطلبات الأمان
      • تأكيد صحة رمز QR
      • تشفير البيانات المنقولة بين التطبيق والنظام
      التكامل مع الأنظمة الأخرى
      • نظام إدارة الطلبات لتحديث حالة الطلب
      القيود والافتراضات
      • يفترض أن المستلم لديه التطبيق ومسجل فيه
      • يفترض أن الإنترنت متاح للمستلم عند مسح رمز QR
      متطلبات الاختبار
      • اختبارات وحدة لتأكيد مسح رمز QR وتحديث حالة الطلب
      • اختبارات تكامل للتأكد من تفاعل التطبيق مع نظام إدارة الطلبات بشكل صحيح
      تفاصيل ال API
      Method: POST || Endpoint: /confirm-delivery
      Request Headers
      Authorization: Bearer token

      Request Body

      qr_code: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تأكيد التسليم

      • textblock
        • Please scan the QR code to confirm delivery

      • form
        • Button
          • العنوان : تأكيد
          • الخيارات : submitConfirmation
      الاشعارات

      العنوان : Delivery Confirmed
      الرسالة : The shipment has been successfully delivered and confirmed by the recipient
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : المرسل,الناقل

      3.16.2.2- تسليم الحمولة للمستلم غير المسجل في التطبيق باستخدام رسالة نصية. يتم هذا عبر إرسال النظام رسالة نصية إلى هاتف المستلم تتضمن رابطًا لتأكيد استلام الشحنة. يفتح المستلم الرابط ويؤكد استلام الشحنة، مما يؤدي إلى تحديث حالة الطلب في النظام

      graph LR; A[Delivery Completed] -->|Send SMS| B[Recipient Confirms Delivery]; B --> C[Update Order Status]; C --> D[Notify Stakeholders];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • إتمام عملية النقل
      • المستلم غير مسجل في التطبيق
      الشروط اللاحقة
      • تأكيد استلام الشحنة
      • تحديث حالة الطلب في النظام
      تسلسل الأحداث
      • الناقل يستلم الحمولة من المرسل
      • الناقل يقوم بنقل الحمولة إلى المستلم
      • النظام يرسل رسالة نصية تتضمن رابط تأكيد الاستلام
      • المستلم يفتح الرابط ويؤكد استلام الشحنة
      • النظام يحدث حالة الطلب
      المدخلاترابط تأكيد الاستلام |
      المخرجات
      • تأكيد استلام الحمولة
      • تحديث حالة الطلب في النظام
      تفاعلات المستخدم
      • تفاعل المستلم مع الرابط لتأكيد استلام الحمولة
      سيناريوهات الاستخدام
      • إذا كانت الحمولة تتضمن عدة صناديق، يقوم المستلم بفتح الرابط وتأكيد استلام كل صندوق على حدة
      متطلبات الأمان
      • تأكيد صحة الرابط
      • تشفير البيانات المنقولة بين النظام والمستلم
      التكامل مع الأنظمة الأخرى
      • نظام إدارة الطلبات لتحديث حالة الطلب
      القيود والافتراضات
      • يفترض أن المستلم لديه اتصال بالإنترنت لفتح الرابط وتأكيد الاستلام
      متطلبات الاختبار
      • اختبارات وحدة لتأكيد فتح الرابط وتحديث حالة الطلب
      • اختبارات تكامل للتأكد من تفاعل النظام مع نظام إدارة الطلبات بشكل صحيح
      تفاصيل ال API
      Method: POST || Endpoint: /confirm-delivery
      Request Headers
      Authorization: Bearer token

      Request Body

      confirmation_link: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تأكيد التسليم

      • textblock
        • Please click the link in the SMS to confirm delivery

      • form
        • Button
          • العنوان : تأكيد
          • الخيارات : openConfirmationLink
      الاشعارات

      العنوان : Delivery Confirmed
      الرسالة : The shipment has been successfully delivered and confirmed by the recipient
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : المرسل - الناقل

      3.16.2.3- استخدام آلية جرد لاستلام الشحنة. يتم هذا عبر قيام الناقل بتقديم الأصناف المدرجة في بيان الحمولة إلى المستلم، الذي يقوم بجردها وتأكيد استلامها، مما يؤدي إلى تحديث حالة الطلب في النظام

      graph LR; A[Delivery Completed] -->|Present Items| B[Review and Confirm]; B --> C[Update Order Status]; C --> D[Notify Stakeholders];
      العنوانالتفاصيل
      المستخدمالمستلم
      الشروط المسبقة
      • إتمام عملية النقل
      • استعداد المستلم لاستلام الشحنة
      الشروط اللاحقة
      • تأكيد استلام كافة الأصناف
      • تحديث حالة الطلب في النظام
      تسلسل الأحداث
      • الناقل يستلم الحمولة من المرسل
      • الناقل يقوم بنقل الحمولة إلى المستلم
      • الناقل يقدم الأصناف المدرجة في بيان الحمولة
      • المستلم يراجع الأصناف ويقوم بجردها
      • المستلم يؤكد استلام كافة الأصناف بدون ملاحظات أو مع ملاحظات
      • النظام يحدث حالة الطلب بناءً على تأكيد المستلم
      المدخلاتبيان الحمولة |
      المخرجات
      • تأكيد استلام الأصناف
      • تحديث حالة الطلب في النظام
      تفاعلات المستخدم
      • تفاعل المستلم مع الناقل لاستلام الأصناف وجردها
      سيناريوهات الاستخدام
      • إذا كانت الحمولة تتضمن عدة أصناف، يقوم المستلم بجرد كل صنف على حدة وتأكيد استلامه
      متطلبات الأمان
      • تأكيد صحة بيان الحمولة
      • تشفير البيانات المنقولة بين النظام والمستلم
      التكامل مع الأنظمة الأخرى
      • نظام إدارة الطلبات لتحديث حالة الطلب
      القيود والافتراضات
      • يفترض أن المستلم يمكنه الوصول إلى بيان الحمولة وجرد الأصناف
      • يفترض أن الإنترنت متاح للمستلم عند جرد الأصناف وتأكيد الاستلام
      متطلبات الاختبار
      • اختبارات وحدة لتأكيد جرد الأصناف وتحديث حالة الطلب
      • اختبارات تكامل للتأكد من تفاعل النظام مع نظام إدارة الطلبات بشكل صحيح
      تفاصيل ال API
      Method: POST || Endpoint: /confirm-delivery
      Request Headers
      Authorization: Bearer token

      Request Body

      delivery_id: نص items_confirmed: array

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تأكيد التسليم

      • textblock
        • Please review and confirm the items received

      • form
        • Button
          • العنوان : تأكيد
          • الخيارات : submitConfirmation
      الاشعارات

      العنوان : Delivery Confirmed
      الرسالة : The shipment has been successfully delivered and confirmed by the recipient
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : المرسل,الناقل

      3.16.2.4- تحويل التكاليف بعد استلام الشحنة. يتم هذا عبر النظام الذي يتحقق من استلام الشحنة بنجاح ومن ثم يقوم بتحويل التكاليف من حساب طالب الخدمة إلى حساب الناقل بعد مرور ساعة من وقت إتمام الإرسال، ويقوم بتحديث سجل المعاملات في النظام

      graph LR; A[Shipment Received] -->|Verify Receipt| B[Transfer Costs]; B --> C[Update Transaction Records]; C --> D[Notify Stakeholders];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • استلام الشحنة من قبل المستلم
      • عدم وجود ملاحظات تعوق عملية الدفع
      الشروط اللاحقة
      • تحويل التكاليف من حساب طالب الخدمة إلى حساب الناقل
      • تحديث سجل المعاملات في النظام
      تسلسل الأحداث
      • استلام الشحنة من قبل المستلم
      • تحقق النظام من استلام الشحنة
      • تحويل التكاليف بعد مرور ساعة
      • تحديث سجل المعاملات في النظام
      المخرجات
      • تأكيد تحويل التكاليف
      • تحديث سجل المعاملات
      متطلبات الأمان
      • تأكيد صحة استلام الشحنة
      • تشفير البيانات المالية المنقولة بين النظام والبنك
      التكامل مع الأنظمة الأخرى
      • نظام إدارة الحسابات لتحديث سجل المعاملات
      القيود والافتراضات
      • يفترض أن النظام يمكنه التواصل مع البنك لتحويل التكاليف
      • يفترض أن النظام يتلقى تأكيدًا من البنك بخصوص تحويل التكاليف
      متطلبات الاختبار
      • اختبارات وحدة لتأكيد تحويل التكاليف وتحديث سجل المعاملات
      • اختبارات تكامل للتأكد من تفاعل النظام مع نظام إدارة الحسابات والبنك بشكل صحيح
      تفاصيل ال API
      Method: POST || Endpoint: /transfer-costs
      Request Headers
      Authorization: Bearer token

      Request Body

      order_id: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تأكيد تحويل التكلفة

      • textblock
        • The costs will be transferred to the carrier after one hour

      الاشعارات

      العنوان : Cost Transfer Completed
      الرسالة : The costs have been successfully transferred to the carrier
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : المرسل,الناقل

      3.17 - تحويل أرباح عملية النقل

      3.17.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • ضمان دقة وشفافية في توزيع الأرباح بين الجهات المعنية والتطبيق
      الجهات المعنية
      • الناقل
      • التطبيق
      • هيئة الزكاة والضريبة والجمارك في المملكة العربية السعودية
      الخطوات الرئيسية
      • يتم تحويل أجرة النقل مباشرة إلى محفظة الناقل الإلكترونية
      • يتم تحويل رسوم الخدمة إلى حساب التطبيق تحت تصنيف 'رسوم خدمات النقل'، مع تفريق بين نقل ثقيل وخفيف، وإضافة تفاصيل إضافية تتعلق بنوع المركبة المستخدمة
      • تحويل ضريبة القيمة المضافة إلى حساب الضريبة في التطبيق
      الخطوات البديلة
      قصص المستخدمين
      • الناقل: بعد تنفيذ الخدمة، يتم تحويل أجرة النقل التي دفعها العميل إلى محفظة الناقل الإلكترونية
      مؤشرات الأداء
      • عدد الطلبات التي تم اكتمال تحويل تكاليفها وقيمتها خلال فترات محددة مع تصنيف (أجرة النقل، رسوم الخدمة، نسبة الضريبة)
      • عدد الطلبات المعلقة وقيمتها خلال فترات محددة مع تصنيف (أجرة النقل، رسوم الخدمة، نسبة الضريبة)

      3.17.2 حالات الاستخدام

      3.17.2.1- تحويل أجرة النقل إلى محفظة الناقل الإلكترونية بعد إتمام الخدمة

      graph LR; A[تحقق من إتمام عملية النقل] --> B[تحويل أجرة النقل إلى محفظة الناقل]; B --> C[تحديث سجل المعاملات];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • إتمام عملية النقل بنجاح
      • توفر معلومات المحفظة الإلكترونية للناقل
      الشروط اللاحقة
      • تحويل أجرة النقل إلى محفظة الناقل
      • تحديث سجل المعاملات في النظام
      تسلسل الأحداث
      • تحقق النظام من إتمام عملية النقل
      • تحويل أجرة النقل إلى محفظة الناقل
      • تحديث سجل المعاملات
      الافتراضات
      • توافر معلومات دقيقة ومحدثة عن محفظة الناقل
      • وجود تكامل سلس بين النظام والمحفظة الإلكترونية
      المتطلبات الخاصة
      • متطلبات أمان عالية لضمان سلامة المعاملات المالية
      • التوافق مع الأنظمة المصرفية والمحافظ الإلكترونية المعتمدة
      المدخلاتمعلومات المحفظة الإلكترونية للناقل | بيانات إتمام عملية النقل |
      المخرجات
      • تأكيد تحويل أجرة النقل إلى محفظة الناقل
      • تحديث سجل المعاملات
      تفاعلات المستخدم
      • النظام يتفاعل مع محفظة الناقل الإلكترونية لإتمام التحويل
      سيناريوهات الاستخدام
      • بعد إتمام النقل، يتم تحويل أجرة النقل تلقائيًا إلى محفظة الناقل
      متطلبات الأمان
      • تشفير جميع البيانات المالية لضمان حمايتها من الاختراق
      التكامل مع الأنظمة الأخرى
      • التكامل مع أنظمة المحافظ الإلكترونية والبنوك
      القيود والافتراضات
      • توفر تكامل تقني مستمر مع أنظمة الدفع
      • تحديث مستمر لمعلومات المحفظة الإلكترونية
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من صحة عملية التحويل
      • اختبارات أمان لضمان حماية البيانات المالية
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/transfer/payment
      Request Headers
      Authorization: Bearer token

      Request Body

      transport_id: نص wallet_id: نص amount: number

      Response

      الحالةالمحتوى
      200status: نص transaction_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تأكيد الدفع

      • textblock
        • تم تحويل أجرة النقل إلى محفظة الناقل بنجاح

      • form
        • Button
          • العنوان : عودة
          • الخيارات : goBack
      الاشعارات

      العنوان : تم تحويل أجرة النقل
      الرسالة : تم تحويل أجرة النقل إلى محفظتك الإلكترونية بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : الناقل

      3.17.2.2- تحويل رسوم الخدمة إلى حساب التطبيق بعد إتمام النقل

      graph LR; A[تحقق من إتمام عملية النقل] --> B[تحويل رسوم الخدمة إلى حساب التطبيق]; B --> C[تحديث سجل المعاملات];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • إتمام عملية النقل بنجاح
      • تحديد رسوم الخدمة المطلوبة
      الشروط اللاحقة
      • تحويل رسوم الخدمة إلى حساب التطبيق
      • تحديث سجل المعاملات في النظام
      تسلسل الأحداث
      • تحقق النظام من إتمام عملية النقل
      • تحويل رسوم الخدمة إلى حساب التطبيق
      • تحديث سجل المعاملات
      الافتراضات
      • توافر تكامل بين النظام وحساب التطبيق
      • تحديث مستمر لمعلومات الرسوم
      المتطلبات الخاصة
      • متطلبات أمان لضمان سلامة المعاملات المالية
      • التوافق مع الأنظمة المصرفية والتطبيق
      المدخلاتمعلومات رسوم الخدمة | بيانات إتمام عملية النقل |
      المخرجات
      • تأكيد تحويل رسوم الخدمة إلى حساب التطبيق
      • تحديث سجل المعاملات
      تفاعلات المستخدم
      • النظام يتفاعل مع حساب التطبيق لإتمام التحويل
      سيناريوهات الاستخدام
      • بعد إتمام النقل، يتم تحويل رسوم الخدمة تلقائيًا إلى حساب التطبيق
      متطلبات الأمان
      • تشفير جميع البيانات المالية لضمان حمايتها من الاختراق
      التكامل مع الأنظمة الأخرى
      • التكامل مع الأنظمة المصرفية والتطبيق
      القيود والافتراضات
      • توفر تكامل تقني مستمر مع أنظمة الدفع
      • تحديث مستمر لمعلومات الرسوم
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من صحة عملية التحويل
      • اختبارات أمان لضمان حماية البيانات المالية
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/transfer/service-fee
      Request Headers
      Authorization: Bearer token

      Request Body

      transport_id: نص service_fee: number

      Response

      الحالةالمحتوى
      200status: نص transaction_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تأكيد رسوم الخدمة

      • textblock
        • تم تحويل رسوم الخدمة إلى حساب التطبيق بنجاح

      • form
        • Button
          • العنوان : عودة
          • الخيارات : goBack
      الاشعارات

      العنوان : تم تحويل رسوم الخدمة
      الرسالة : تم تحويل رسوم الخدمة إلى حساب التطبيق بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : إداري النظام

      3.17.2.3- تحويل ضريبة القيمة المضافة إلى حساب الضريبة في التطبيق بعد إتمام النقل

      graph LR; A[تحقق من إتمام عملية النقل] --> B[تحويل ضريبة القيمة المضافة إلى حساب الضريبة]; B --> C[تحديث سجل المعاملات];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • إتمام عملية النقل بنجاح
      • تحديد قيمة ضريبة القيمة المضافة المستحقة
      الشروط اللاحقة
      • تحويل ضريبة القيمة المضافة إلى حساب الضريبة في التطبيق
      • تحديث سجل المعاملات في النظام
      تسلسل الأحداث
      • تحقق النظام من إتمام عملية النقل
      • تحويل ضريبة القيمة المضافة إلى حساب الضريبة
      • تحديث سجل المعاملات
      الافتراضات
      • توافر تكامل بين النظام وحساب الضريبة
      • تحديث مستمر لمعلومات ضريبة القيمة المضافة
      المتطلبات الخاصة
      • متطلبات أمان لضمان سلامة المعاملات المالية
      • التوافق مع الأنظمة المصرفية وحسابات الضريبة
      المدخلاتمعلومات ضريبة القيمة المضافة | بيانات إتمام عملية النقل |
      المخرجات
      • تأكيد تحويل ضريبة القيمة المضافة إلى حساب الضريبة
      • تحديث سجل المعاملات
      تفاعلات المستخدم
      • النظام يتفاعل مع حساب الضريبة لإتمام التحويل
      سيناريوهات الاستخدام
      • بعد إتمام النقل، يتم تحويل ضريبة القيمة المضافة تلقائيًا إلى حساب الضريبة
      متطلبات الأمان
      • تشفير جميع البيانات المالية لضمان حمايتها من الاختراق
      التكامل مع الأنظمة الأخرى
      • التكامل مع الأنظمة المصرفية وحسابات الضريبة
      القيود والافتراضات
      • توفر تكامل تقني مستمر مع أنظمة الدفع
      • تحديث مستمر لمعلومات ضريبة القيمة المضافة
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من صحة عملية التحويل
      • اختبارات أمان لضمان حماية البيانات المالية
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/transfer/vat
      Request Headers
      Authorization: Bearer token

      Request Body

      transport_id: نص vat_amount: number

      Response

      الحالةالمحتوى
      200status: نص transaction_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تأكيد ضريبة القيمة المضافة

      • textblock
        • تم تحويل ضريبة القيمة المضافة إلى حساب الضريبة بنجاح

      • form
        • Button
          • العنوان : عودة
          • الخيارات : goBack
      الاشعارات

      العنوان : تم تحويل ضريبة القيمة المضافة
      الرسالة : تم تحويل ضريبة القيمة المضافة إلى حساب الضريبة بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : إداري النظام

      3.18 - تقييم خدمة النقل

      3.18.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • نظام التقييم مطلوب لضمان الشفافية وبناء الثقة بين العملاء ومقدمي الخدمات. هذا سيخدم كوسيلة للتحسين المستمر للخدمات التي تقدم من قبل مقدمي الخدمات
      الجهات المعنية
      • العملاء
      • إداري المنصة
      الخطوات الرئيسية
      • عند اكتمال عملية النقل، يتقدم النظام برسالة إلى العميل لتقييم تجربة النقل
      • يتم أرشفة التقييمات وجعلها مرئية للجمهور في صفحة مقدم الخدمة
      الخطوات البديلة
      • في حالة إغفال العميل للتقييم، يجب تقديم تذكيرات بالتقييم
      قصص المستخدمين
      • كعميل، بعد استلام نقلتي، أريد تقييم جودة الخدمة التي تلقيتها، حتى يتمكن الآخرون من الاطلاع على تجربتي
      • كإداري للمنصة، أريد رؤية جميع التقييمات للمعاملات التي تمت على المنصة، حتى أتمكن من مراقبة الجودة والتحسين المستمر للمنصة
      • كعميل آخر، أرغب في رؤية تقييمات العملاء والخدمات الأخرى لمقدم الخدمة، حتى أتمكن من اتخاذ قرار مستنير بشأن التعامل معهم
      مؤشرات الأداء
      • تحديد نسبة التقييم الإجمالية وربط تصنيفها بفئة المركبة المستخدمة
      • عدد الطلبات التي تم تقييمها من إجمالي الطلبات

      3.18.2 حالات الاستخدام

      3.18.2.1- عند اكتمال عملية النقل، يتقدم النظام برسالة إلى العميل لتقييم تجربة النقل. العميل يستلم رسالة التقييم، يفتحها، ويقوم بتقييم الخدمة التي تلقاها. هذا التقييم يساعد في تحسين جودة الخدمات المقدمة من قبل مقدمي الخدمة وضمان الشفافية بين الأطراف

      graph LR; A[Complete Transportation] --> B[Send Evaluation Message]; B --> C[Customer Receives Message]; C --> D[Customer Opens Message]; D --> E[Customer Submits Evaluation]; D --> F{Customer Ignores Message}; F --> G[Send Reminder]; G --> H[Customer Receives Reminder]; H --> D[Customer Opens Message];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • اكتمال عملية النقل
      • العميل مسجل في النظام
      الشروط اللاحقة
      • استلام العميل لرسالة التقييم
      تسلسل الأحداث
      • اكتمال النقل
      • إرسال رسالة التقييم
      • فتح الرسالة
      • إكمال التقييم
      الخطوات البديلةفي حالة إغفال العميل للتقييم
      • مرور فترة محددة دون تقييم
      • النظام يرسل تذكير للعميل
      • العميل يتلقى التذكير
      الافتراضات
      • العميل سيقوم بفتح رسالة التقييم بعد استلامها
      سيناريوهات الاستخدام
      • اكتمال النقل -> النظام يرسل رسالة تقييم -> العميل يفتح الرسالة ويقيم الخدمة
      متطلبات الأمان
      • يجب تأمين عملية إرسال واستقبال رسائل التقييم
      متطلبات الاختبار
      • اختبار إرسال رسالة التقييم بشكل صحيح
      • اختبار استلام العميل للرسالة وفتحها
      • اختبار عملية التقييم
      تفاصيل ال API
      Method: POST || Endpoint: /sendEvaluationMessage
      Request Headers
      Content-Type: application/json

      Request Body

      user_id: نص transaction_id: نص message: نص

      Response

      الحالةالمحتوى
      200status: success
      الوصف: Success
      400
      الوصف: Bad Request

      Method: GET || Endpoint: /getEvaluationReminder
      Request Headers
      Content-Type: application/json

      Request Body

      Response

      الحالةالمحتوى
      200status: reminder sent
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة التقييم

      • textblock
        • Please rate your recent transportation experience

      • form
        • text
          • العنوان : تعليقات
        • radio
          • العنوان : التقييم
          • الخيارات : ["1","2","3","4","5"]
      • رسالة زر الإرسال: إرسال
      الاشعارات

      العنوان : Request for Service Evaluation
      الرسالة : Please rate your recent transportation experience
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : العميل

      العنوان : Reminder: Service Evaluation
      الرسالة : You haven't rated your recent transportation experience. Please take a moment to provide your feedback
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : العميل

      3.18.2.2- يتم أرشفة التقييمات وجعلها مرئية للجمهور في صفحة مقدم الخدمة. هذا يساعد العملاء في الاطلاع على تقييمات الخدمات المقدمة من قبل مقدمي الخدمة، مما يعزز الشفافية والثقة

      graph LR; A[Receive Evaluation] --> B[Archive Evaluation]; B --> C[Display Evaluation on Service Provider Page];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • العميل قام بتقييم الخدمة
      • النظام يستلم التقييم
      الشروط اللاحقة
      • التقييم مرئي للجمهور في صفحة مقدم الخدمة
      تسلسل الأحداث
      • استلام التقييم من العميل
      • أرشفة التقييم
      • عرض التقييم على صفحة مقدم الخدمة
      الافتراضات
      • التقييم سيكون موضوعيًا ودقيقًا
      سيناريوهات الاستخدام
      • العميل يقيم الخدمة -> النظام يستلم التقييم -> التقييم يتم أرشفته -> التقييم يعرض على صفحة مقدم الخدمة
      متطلبات الأمان
      • يجب حماية التقييمات من التلاعب
      متطلبات الاختبار
      • اختبار عملية استلام التقييم بشكل صحيح
      • اختبار أرشفة التقييم
      • اختبار عرض التقييم على صفحة مقدم الخدمة
      تفاصيل ال API
      Method: POST || Endpoint: /archiveEvaluation
      Request Headers
      Content-Type: application/json

      Request Body

      evaluation_id: نص service_provider_id: نص evaluation: نص

      Response

      الحالةالمحتوى
      200status: archived
      الوصف: Success
      400
      الوصف: Bad Request

      Method: GET || Endpoint: /getServiceProviderEvaluations
      Request Headers
      Content-Type: application/json

      Request Body

      Response

      الحالةالمحتوى
      200evaluations: array
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      ملف مقدم الخدمة

      • textblock
        • Customer Reviews

      • list
        • النوع : Review 1

        • النوع : Review 2

      3.18.2.3- في حالة إغفال العميل للتقييم بعد فترة محددة، يجب على النظام إرسال تذكير للعميل لتقييم الخدمة. هذا يضمن أن يتم جمع التغذية الراجعة بشكل كامل ويساعد في تحسين جودة الخدمات المقدمة

      graph LR; A[No Evaluation After Specific Period] --> B[Send Evaluation Reminder]; B --> C[Customer Receives Reminder]; C --> D[Customer Opens Reminder]; D --> E[Customer Submits Evaluation]; B --> F{No Response}; F --> G[Send Second Reminder]; G --> C
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • العميل لم يقم بتقييم الخدمة بعد فترة محددة
      • النظام لديه وسيلة اتصال بالعميل
      الشروط اللاحقة
      • استلام العميل لتذكير بتقييم الخدمة
      • إرسال التذكير عبر الوسائل المتاحة (البريد الإلكتروني، الإشعارات)
      تسلسل الأحداث
      • مرور فترة محددة دون تقييم
      • إرسال تذكير للعميل
      • استلام التذكير من قبل العميل
      • فتح التذكير وتقييم الخدمة
      الخطوات البديلةفي حالة عدم استجابة العميل للتذكير الأول
      • مرور فترة إضافية دون تقييم
      • النظام يرسل تذكير ثاني للعميل
      • العميل يتلقى التذكير الثاني
      الخطوات الاستثنائيةفي حالة وجود مشكلة في إرسال التذكير
      • النظام يحاول إعادة إرسال التذكير بعد فترة محددة
      • إبلاغ فريق الدعم الفني في حالة استمرار المشكلة
      الافتراضات
      • العميل سيقوم بفتح التذكير بعد استلامه
      سيناريوهات الاستخدام
      • مرور فترة محددة دون تقييم -> النظام يرسل تذكير -> العميل يستلم التذكير ويقيم الخدمة
      متطلبات الأمان
      • يجب تأمين عملية إرسال واستقبال التذكيرات
      متطلبات الاختبار
      • اختبار إرسال التذكير بشكل صحيح
      • اختبار استلام العميل للتذكير وفتحه
      • اختبار عملية التقييم بعد التذكير
      تفاصيل ال API
      Method: POST || Endpoint: /sendEvaluationReminder
      Request Headers
      Content-Type: application/json

      Request Body

      user_id: نص transaction_id: نص reminder_message: نص

      Response

      الحالةالمحتوى
      200status: reminder sent
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة التذكير

      • textblock
        • You haven't rated your recent transportation experience. Please take a moment to provide your feedback

      • form
        • Button
          • العنوان : قيم الآن
          • الخيارات : openEvaluationform
      الاشعارات

      العنوان : Reminder: Service Evaluation
      الرسالة : You haven't rated your recent transportation experience. Please take a moment to provide your feedback
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : العميل

      3.18.2.4- كعميل، بعد استلام نقلتي، أريد تقييم جودة الخدمة التي تلقيتها، حتى يتمكن الآخرون من الاطلاع على تجربتي. سيتم إرسال رسالة تقييم للعميل بعد إتمام عملية النقل، وسيقوم العميل بفتح الرسالة وتقييم الخدمة التي تلقاها. التقييم سيساعد في تحسين جودة الخدمات المقدمة وضمان الشفافية

      graph LR; A[Complete Transportation] --> B[Send Evaluation Request]; B --> C[Customer Receives Request]; C --> D[Customer Opens Request]; D --> E[Customer Submits Evaluation]; E --> F[Display Evaluation on Service Provider Page];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • اكتمال عملية النقل
      • استلام العميل لرسالة التقييم
      الشروط اللاحقة
      • تقديم التقييم من قبل العميل
      • التقييم مرئي للجمهور
      تسلسل الأحداث
      • اكتمال عملية النقل
      • إرسال رسالة تقييم
      • فتح رسالة التقييم
      • تقديم التقييم
      • حفظ التقييم
      • عرض التقييم في صفحة مقدم الخدمة
      الخطوات البديلةفي حالة عدم تقديم العميل للتقييم بعد فترة معينة
      • النظام يرسل تذكير للعميل
      • العميل يتلقى التذكير ويقوم بتقييم الخدمة
      الخطوات الاستثنائيةفي حالة عدم استلام العميل لرسالة التقييم
      • العميل يتواصل مع دعم العملاء
      • دعم العملاء يتحقق من المشكلة ويرسل رسالة تقييم جديدة
      الافتراضات
      • العميل سيقوم بفتح رسالة التقييم وتقديم التقييم
      سيناريوهات الاستخدام
      • اكتمال النقل -> إرسال رسالة تقييم -> فتح الرسالة -> تقييم الخدمة -> عرض التقييم
      متطلبات الأمان
      • حماية عملية إرسال واستقبال التقييمات
      متطلبات الاختبار
      • اختبار إرسال واستلام رسالة التقييم
      • اختبار تقديم التقييم عبر النظام
      • اختبار عرض التقييم على صفحة مقدم الخدمة
      تفاصيل ال API
      Method: POST || Endpoint: /sendEvaluationRequest
      Request Headers
      Content-Type: application/json

      Request Body

      user_id: نص transaction_id: نص message: نص

      Response

      الحالةالمحتوى
      200status: evaluation request sent
      الوصف: Success
      400
      الوصف: Bad Request

      Method: POST || Endpoint: /submitEvaluation
      Request Headers
      Content-Type: application/json

      Request Body

      user_id: نص transaction_id: نص rating: integer comments: نص

      Response

      الحالةالمحتوى
      200status: evaluation submitted
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة التقييم

      • textblock
        • Please rate your recent transportation experience

      • form
        • text
          • العنوان : تعليقات
        • radio
          • العنوان : التقييم
          • الخيارات : ["1","2","3","4","5"]
      • رسالة زر الإرسال: إرسال
      الاشعارات

      العنوان : Request for Service Evaluation
      الرسالة : Please rate your recent transportation experience
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : العميل

      3.18.2.5- كإداري للمنصة، أريد رؤية جميع التقييمات للمعاملات التي تمت على المنصة، حتى أتمكن من مراقبة الجودة والتحسين المستمر للمنصة. سيتمكن الإداري من الوصول إلى واجهة الإدارة حيث يمكنه عرض جميع التقييمات المقدمة من العملاء لمراقبة وتحليل جودة الخدمة المقدمة من قبل مقدمي الخدمات

      graph LR; A[Admin Logs In] --> B[Open Evaluations Page]; B --> C[View Evaluations]; C --> D[Review and Analyze Evaluations];
      العنوانالتفاصيل
      المستخدمإداري المنصة
      الشروط المسبقة
      • وجود تقييمات محفوظة في النظام
      • الإداري لديه صلاحية الوصول إلى واجهة الإدارة
      الشروط اللاحقة
      • الإداري يستطيع عرض ومراجعة التقييمات
      • تحليل التقييمات لتحسين الجودة
      تسلسل الأحداث
      • تسجيل الدخول إلى واجهة الإدارة
      • فتح صفحة التقييمات
      • عرض التقييمات
      • مراجعة وتحليل التقييمات
      الافتراضات
      • التقييمات المقدمة من العملاء دقيقة وموضوعية
      سيناريوهات الاستخدام
      • الإداري يسجل الدخول -> يفتح صفحة التقييمات -> يعرض التقييمات -> يراجع التقييمات لتحسين الجودة
      متطلبات الأمان
      • يجب تأمين واجهة الإدارة لمنع الوصول غير المصرح به
      متطلبات الاختبار
      • اختبار صلاحيات الإداري للوصول إلى واجهة الإدارة
      • اختبار عرض التقييمات بشكل صحيح
      • اختبار أدوات تحليل التقييمات
      تفاصيل ال API
      Method: GET || Endpoint: /getEvaluations
      Request Headers
      Authorization: Bearer token Content-Type: application/json

      Request Body

      Response

      الحالةالمحتوى
      200evaluations: array
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة التقييمات الإدارية

      • table
        • الاسم : معرف المستخدم
        • نوع المحتوي : نص

        • الاسم : معرف المعاملة
        • نوع المحتوي : نص

        • الاسم : التقييم
        • نوع المحتوي : number

        • الاسم : تعليقات
        • نوع المحتوي : نص

      3.19 - طلب خدمة دعم فني للناقل

      3.19.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • توفير خدمات الرحلة بطريقة سهلة وفعالة، تمكن العملاء من طلب الخدمات المطلوبة وتحديد الموقع بطريقة سريعة ودقيقة
      الجهات المعنية
      • العميل: الذي سيطلب الخدمة ويحدد حالتها
      • مقدم الخدمة: سيكون له القدرة على تقديم الخدمات بناء على حالة ووصف الطلب
      الخطوات الرئيسية
      • الناقل يحدد حالة الخدمة (طارئة أو عادية)
      • الناقل يحدد نوع الخدمة (مثل الصيانة)
      • الناقل يدخل وصف الخدمة (عبر النص أو التسجيل الصوتي أو الصور أو الكل)
      • يتم تحديد الموقع الجغرافي عبر النظام GPS
      الخطوات البديلة
      • في حالة فقدان الاتصال بالإنترنت، يمكن للمالك توفير معلومات الموقع يدوياً
      قصص المستخدمين
      • كعميل، أسعى لتوضيح حالة الخدمة (طارئة أو عادية) المطلوبة، وذلك لمنح مقدمي الخدمة فرصة كاملة لفهم السياق الخاص بطلبي، مما يمكنهم من تقديم الخدمة بأعلى مستوى من الكفاءة والجودة
      • كعميل، أريد تحديد نوع الخدمة، لأضمن أن المزود المناسب للخدمة هو من سيتعامل مع طلبي
      • كعميل، أسعى إلى تقديم وصف دقيق للخدمة المطلوبة، بهدف تمكين مزود الخدمة من فهم احتياجاتي بشكل واضح ومحدد
      • كعميل، أريد أن أكون قادرًا على تحديد موقعي تلقائيًا، لضمان أن مزود الخدمة يعرف بالضبط أين أنا
      • كمقدم خدمة، أريد أن أرى تفاصيل الطلب، بما في ذلك حالة الخدمة والنوع والوصف والموقع، حتى أتمكن من تقديم الخدمة بشكل أكثر فعالية وسرعة
      مؤشرات الأداء
      • عدد الطلبات خلال فترات محددة مع تحديد التصنيفات (صيانة عادية، طارئة،...)
      • عدد الورش الفنية التي استلمت الطلب ونسبة الاستجابة

      3.19.2 حالات الاستخدام

      3.19.2.1- يقوم الناقل بتحديد حالة الخدمة المطلوبة، سواء كانت طارئة أو عادية، لضمان تقديم الخدمة بشكل ملائم وفقًا لحالة الطلب

      graph LR; A[فتح تطبيق النظام] --> B[تحديد حالة الخدمة كطارئة أو عادية] --> C[حفظ الإعدادات]
      العنوانالتفاصيل
      المستخدمالناقل
      الشروط المسبقة
      • الناقل مسجل في النظام
      • الناقل لديه مركبة مسجلة
      الشروط اللاحقة
      • النظام يحتفظ بحالة الخدمة المحددة
      تفاصيل ال API
      Method: POST || Endpoint: /service-status
      Request Headers
      Authorization: Bearer token

      Request Body

      service_status: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      حالة الخدمة

      • textblock
        • تحديد حالة الخدمة

      • form
        • RadioGroup
          • العنوان : حالة الخدمة
          • الخيارات : {"label": "طارئة", "value": "emergency" },{ "label": "عادية", "value": "regular" }
        • Button
          • العنوان : حفظ
          • الخيارات : submitServiceStatus
      الاشعارات

      العنوان : تم تحديد حالة الخدمة
      الرسالة : تم حفظ حالة الخدمة المحددة بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : الناقل

      3.19.2.2- يقوم الناقل بتحديد نوع الخدمة المطلوبة، مثل الصيانة، لضمان تقديم الخدمة بشكل ملائم وفقًا لنوع الطلب

      graph LR; A[فتح تطبيق النظام] --> B[تحديد نوع الخدمة المطلوبة] --> C[حفظ الإعدادات]
      العنوانالتفاصيل
      المستخدمالناقل
      الشروط المسبقة
      • الناقل مسجل في النظام
      • الناقل لديه مركبة مسجلة
      الشروط اللاحقة
      • النظام يحتفظ بنوع الخدمة المحدد
      تفاصيل ال API
      Method: POST || Endpoint: /service-type
      Request Headers
      Authorization: Bearer token

      Request Body

      service_type: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      نوع الخدمة

      • textblock
        • تحديد نوع الخدمة

      • form
        • select
          • الخيارات : [{"label":"صيانة","value":"maintenance"},{"label":"إصلاح","value":"repair"}]
        • Button
          • العنوان : حفظ
          • الخيارات : submitServiceType
      الاشعارات

      العنوان : تم تحديد نوع الخدمة
      الرسالة : تم حفظ نوع الخدمة المحددة بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : الناقل

      3.19.2.3- يقوم الناقل بإدخال وصف الخدمة المطلوبة عن طريق النص أو التسجيل الصوتي أو الصور، لضمان تقديم الخدمة بشكل دقيق وفقًا للوصف المدخل

      graph LR; A[فتح تطبيق النظام] --> B[إدخال وصف الخدمة بالنص أو التسجيل الصوتي أو الصور] --> C[حفظ الوصف]
      العنوانالتفاصيل
      المستخدمالناقل
      الشروط المسبقة
      • الناقل مسجل في النظام
      • الناقل لديه مركبة مسجلة
      • الناقل حدد حالة ونوع الخدمة
      الشروط اللاحقة
      • النظام يحتفظ بوصف الخدمة المدخل
      تفاصيل ال API
      Method: POST || Endpoint: /service-description
      Request Headers
      Authorization: Bearer token

      Request Body

      service_description: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      وصف الخدمة

      • textblock
        • إدخال وصف الخدمة

      • form
        • textarea
          • العنوان : وصف الخدمة
          • الخيارات : "placeholder": "أدخل وصف الخدمة هنا.."
        • Button
          • العنوان : حفظ
          • الخيارات : submitServiceDescription
      • رسالة زر الإرسال: حفظ
      • رسالة النجاح: تم الحفظ
      الاشعارات

      العنوان : تم حفظ وصف الخدمة
      الرسالة : تم حفظ وصف الخدمة المدخل بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : الناقل

      3.19.2.4- يتم تحديد الموقع الجغرافي عبر النظام GPS لضمان دقة تقديم الخدمة

      graph LR; A[فتح تطبيق النظام] --> B[النظام يتصل بنظام GPS] --> C[تحديد الموقع الجغرافي] --> D[حفظ الموقع في النظام]
      العنوانالتفاصيل
      المستخدمالناقل
      الشروط المسبقة
      • الناقل مسجل في النظام
      • الجهاز المستخدم يحتوي على نظام GPS مفعل
      الشروط اللاحقة
      • الموقع الجغرافي للناقل محدد في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /location
      Request Headers
      Authorization: Bearer token

      Request Body

      latitude: number longitude: number

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      الموقع

      • textblock
        • تحديد الموقع الجغرافي

      • form
        • text
          • العنوان : النظام يتصل بنظام GPS لتحديد موقعك"
        • Button
          • العنوان : حفظ الموقع
          • الخيارات : submitLocation
      الاشعارات

      العنوان : تم تحديد الموقع الجغرافي
      الرسالة : تم حفظ الموقع الجغرافي المحدد بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : الناقل

      3.19.2.5- في حالة فقدان الاتصال بالإنترنت، يمكن للناقل توفير معلومات الموقع يدويًا لضمان دقة تقديم الخدمة

      graph LR; A[فتح تطبيق النظام] --> B[إدخال معلومات الموقع الجغرافي يدويًا] --> C[حفظ الموقع في النظام]
      العنوانالتفاصيل
      المستخدمالناقل
      الشروط المسبقة
      • الناقل مسجل في النظام
      • الجهاز المستخدم يحتوي على نظام GPS مفعل
      • فقدان الاتصال بالإنترنت
      الشروط اللاحقة
      • الموقع الجغرافي للناقل مدخل في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /manual-location
      Request Headers
      Authorization: Bearer token

      Request Body

      latitude: number longitude: number

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      الموقع اليدوي

      • textblock
        • إدخال الموقع الجغرافي يدويًا

      • textblock
        • يرجى إدخال معلومات الموقع الجغرافي يدويًا

      • form
        • number
          • العنوان : خط العرض
          • التحقق : {"required":true,"min":-90,"max":90,"errorMessage":"خط العرض يجب أن يكون بين -90 و 90"}
        • number
          • العنوان : خط الطول
          • التحقق : {"required":true,"min":-180,"max":180,"errorMessage":"خط الطول يجب أن يكون بين -180 و 180"}
      • رسالة زر الإرسال: حفظ الموقع
      • رسالة النجاح: تم حفظ الموقع الجغرافي بنجاح
      • إعادة توجيه النجاح: LocationConfirmation
      الاشعارات

      العنوان : تم حفظ الموقع الجغرافي
      الرسالة : تم حفظ الموقع الجغرافي المدخل بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : الناقل

      3.19.2.6- كعميل، أسعى لتوضيح حالة الخدمة (طارئة أو عادية) المطلوبة، وذلك لمنح مقدمي الخدمة فرصة كاملة لفهم السياق الخاص بطلبي، مما يمكنهم من تقديم الخدمة بأعلى مستوى من الكفاءة والجودة

      graph LR; A[فتح تطبيق النظام] --> B[تحديد حالة الخدمة المطلوبة] --> C[حفظ الإعدادات]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • العميل مسجل في النظام
      • العميل يطلب خدمة دعم فني
      الشروط اللاحقة
      • حالة الخدمة محددة في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /client-service-status
      Request Headers
      Authorization: Bearer token

      Request Body

      service_status: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      حالة خدمة العميل

      • textblock
        • تحديد حالة الخدمة

      • form
        • RadioGroup
          • العنوان : حالة الخدمة
          • الخيارات : { "label": "طارئة", "value": "emergency" },{"label": "عادية", "value": "regular" }
        • Button
          • العنوان : حفظ
          • الخيارات : submitServiceStatus
      الاشعارات

      العنوان : تم تحديد حالة الخدمة
      الرسالة : تم حفظ حالة الخدمة المحددة بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : العميل

      3.19.2.7- كعميل، أريد تحديد نوع الخدمة المطلوبة، لأضمن أن المزود المناسب للخدمة هو من سيتعامل مع طلبي، مما يضمن تقديم الخدمة بأعلى جودة وكفاءة

      graph LR; A[فتح تطبيق النظام] --> B[تحديد نوع الخدمة المطلوبة] --> C[حفظ الإعدادات]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • العميل مسجل في النظام
      • العميل يطلب خدمة دعم فني
      الشروط اللاحقة
      • نوع الخدمة محدد في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /client-service-type
      Request Headers
      Authorization: Bearer token

      Request Body

      service_type: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      نوع خدمة العميل

      • textblock
        • تحديد نوع الخدمة

      • form
        • select
          • الخيارات : [{"label":"صيانة","value":"maintenance"},{"label":"إصلاح","value":"repair"}]
        • Button
          • العنوان : حفظ
      الاشعارات

      العنوان : تم تحديد نوع الخدمة
      الرسالة : تم حفظ نوع الخدمة المحددة بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : العميل

      3.19.2.8- كعميل، أسعى إلى تقديم وصف دقيق للخدمة المطلوبة، بهدف تمكين مزود الخدمة من فهم احتياجاتي بشكل واضح ومحدد، مما يساعد على تقديم الخدمة بأعلى مستوى من الكفاءة والجودة

      graph LR; A[فتح تطبيق النظام] --> B[إدخال وصف الخدمة بالنص أو التسجيل الصوتي أو الصور] --> C[حفظ الوصف]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • العميل مسجل في النظام
      • العميل يطلب خدمة دعم فني
      الشروط اللاحقة
      • وصف الخدمة محفوظ في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /client-service-description
      Request Headers
      Authorization: Bearer token

      Request Body

      service_description: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      وصف خدمة العميل

      • textblock
        • إدخال وصف الخدمة

      • form
        • textarea
          • العنوان : وصف الخدمة
          • الخيارات : "placeholder": "أدخل وصف الخدمة هنا.."
        • Button
          • العنوان : حفظ
          • الخيارات : submitServiceDescription
      الاشعارات

      العنوان : تم حفظ وصف الخدمة
      الرسالة : تم حفظ وصف الخدمة المدخل بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : العميل

      3.19.2.9- كعميل، أريد أن أكون قادرًا على تحديد موقعي تلقائيًا، لضمان أن مزود الخدمة يعرف بالضبط أين أنا

      graph LR; A[فتح تطبيق النظام] --> B[النظام يتصل بنظام GPS] --> C[تحديد الموقع الجغرافي] --> D[حفظ الموقع في النظام]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • العميل مسجل في النظام
      • الجهاز المستخدم يحتوي على نظام GPS مفعل
      الشروط اللاحقة
      • الموقع الجغرافي للعميل محدد في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /client-location
      Request Headers
      Authorization: Bearer token

      Request Body

      latitude: number longitude: number

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      موقع العميل

      • textblock
        • تحديد الموقع الجغرافي

      • form
        • text
          • العنوان : النظام يتصل بنظام GPS لتحديد موقعك
        • Button
          • العنوان : حفظ الموقع
          • الخيارات : submitLocation
      الاشعارات

      العنوان : تم تحديد الموقع الجغرافي
      الرسالة : تم حفظ الموقع الجغرافي المحدد بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : العميل

      3.19.2.10- كمقدم خدمة، أريد أن أرى تفاصيل الطلب، بما في ذلك حالة الخدمة والنوع والوصف والموقع، حتى أتمكن من تقديم الخدمة بشكل أكثر فعالية وسرعة

      graph LR; A[فتح تطبيق النظام] --> B[عرض تفاصيل الطلب] --> C[مراجعة حالة الخدمة والنوع والوصف والموقع]
      العنوانالتفاصيل
      المستخدممقدم الخدمة
      الشروط المسبقة
      • مقدم الخدمة مسجل في النظام
      • مقدم الخدمة يتلقى إشعار طلب خدمة
      الشروط اللاحقة
      • مقدم الخدمة يطلع على تفاصيل الطلب
      تفاصيل ال API
      Method: GET || Endpoint: /service-details
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200service_status: نص service_type: نص service_description: نص Location : number, number
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تفاصيل الخدمة

      • textblock
        • تفاصيل الطلب

      • form
        • text
          • العنوان : حالة الخدمة: {{service_status}}
        • text
          • العنوان : نوع الخدمة: {{service_type}}
        • text
          • العنوان : وصف الخدمة: {{service_description}}
        • Map
          • العنوان : الخريطة
          • الخيارات : "latitude": "{{latitude}}", "longitude": "{{longitude}}"
      الاشعارات

      العنوان : تم استلام طلب جديد
      الرسالة : لديك طلب خدمة جديد. الرجاء مراجعة التفاصيل في التطبيق
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : مقدم الخدمة

      3.20 - خدمة فنية لرحلة النقل

      3.20.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • توفير خدمة تتيح للعملاء الحصول على خدمات فنية للمركبات بشكل مريح وفعال، وفي الوقت نفسه تتيح لورش العمل الفنية استقبال الطلبات التي تتفق مع مجال خبراتهم وإمكانياتهم
      الجهات المعنية
      • العميل (الذي يرسل طلب الخدمة)
      • ورش العمل الفنية (التي تستقبل الطلبات وتجيب عليها)
      الخطوات الرئيسية
      • يتم تصنيف كل طلب خدمة فنية بناءً على نوع الخدمة المحددة وبيانات الخدمة، مثل نوع المركبة والمسافة التقريبية من موقع الخدمة
      • يتم إرسال الطلب إلى ورش العمل الفنية المسجلة التي تفي بالمعايير
      • يقوم المتلقي بمراجعة الطلب ويحدد رده (قبول تقديم الخدمة مع الرد وتحديد التكلفة، طلب مزيد من المعلومات، أو رفض الطلب مع ذكر الأسباب)
      الخطوات البديلة
      قصص المستخدمين
      • العميل، كمستخدم: أريد تقديم طلب لخدمة فنية، حتى أستطيع الحصول على الخدمات المناسبة لحالة مركبتي
      • الورشة الفنية، كمستخدم: أريد استعراض الطلبات المتاحة، حتى أتمكن من الاختيار والاستجابة للطلبات التي هي في نطاق خبرتي وإمكانياتي
      • الورشة الفنية، كمستخدم: أريد أن أكون قادرًا على رفض الطلبات التي لا أستطيع التعامل معها، حتى لا أضيع وقتي وجهدي بلا داع
      مؤشرات الأداء
      • عدد الطلبات خلال فترات محددة مع تحديد التصنيفات (صيانة عادية، طارئة ...)

      3.20.2 حالات الاستخدام

      3.20.2.1- يتم تصنيف كل طلب خدمة فنية بناءً على نوع الخدمة المحددة وبيانات الخدمة، مثل نوع المركبة والمسافة التقريبية من موقع الخدمة

      graph LR A[إنشاء طلب الخدمة] --> B[تصنيف الطلب] B --> C[إرسال الطلب إلى الورش الفنية] C --> D[استلام الورش للطلب]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • وجود طلب خدمة فنية
      • توفر بيانات المركبة والموقع
      الشروط اللاحقة
      • تصنيف الطلب وإرساله إلى الورش الفنية المناسبة
      تسلسل الأحداث
      • إنشاء طلب الخدمة الفنية من قبل العميل
      • تصنيف الطلب بناءً على نوع الخدمة والمركبة والموقع
      • إرسال الطلب إلى الورش الفنية المناسبة
      القواعد التجارية
      • يجب أن يتم تصنيف الطلبات بناءً على معايير محددة تتعلق بنوع الخدمة ونوع المركبة والموقع
      الافتراضات
      • البيانات المدخلة من قبل العميل صحيحة ودقيقة
      • الورش الفنية المسجلة متاحة لتقديم الخدمة المطلوبة
      المتطلبات الخاصة
      • يجب أن يتم تصنيف الطلب في أقل من دقيقة
      • يجب أن يكون النظام قادرًا على معالجة بيانات كبيرة بفعالية
      الملاحظات والمشاكل
      • تأكد من أن الورش الفنية المحددة قادرة على تقديم الخدمة المطلوبة في الوقت المناسب
      المدخلاتبيانات الطلب | بيانات المركبة | بيانات الموقع |
      المخرجات
      • طلب مصنف
      • إشعار للورش الفنية
      تفاعلات المستخدم
      • النظام يتفاعل مع العميل والورش الفنية لتقديم الخدمة
      سيناريوهات الاستخدام
      • إنشاء طلب صيانة طارئ وإرساله إلى أقرب ورشة فنية
      متطلبات الأمان
      • يجب حماية بيانات العميل والمركبة
      • يجب تأكيد هوية الورش الفنية قبل إرسال الطلبات
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام GPS لتحديد الموقع بدقة
      • تكامل مع قاعدة بيانات الورش الفنية المسجلة
      القيود والافتراضات
      • يجب أن يكون لدى الورش الفنية القدرة على استلام الطلبات إلكترونيًا
      متطلبات الاختبار
      • اختبار أداء النظام في تصنيف الطلبات تحت ضغط كبير
      • اختبار دقة تصنيف الطلبات وإرسالها إلى الورش المناسبة
      تفاصيل ال API
      Method: POST || Endpoint: /classifyServiceRequest
      Request Headers
      Authorization: Bearer token Content-Type: application/json

      Request Body

      service_type: نص vehicle_data: object location_data: object

      Response

      الحالةالمحتوى
      200status: نص workshops: array
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تصنيف طلب الخدمة

      • form
        • text
          • العنوان : نوع الخدمة
          • التحقق : نص
        • text
          • العنوان : بيانات المركبة
          • التحقق : object
        • text
          • العنوان : بيانات الموقع
          • التحقق : object
      • رسالة زر الإرسال: إرسال الطلب
      الاشعارات

      العنوان : طلب خدمة فنية جديد
      الرسالة : لديك طلب خدمة فنية جديد. يرجى مراجعة التفاصيل والرد في أقرب وقت ممكن
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : الورش الفنية

      3.20.2.2- يتم إرسال الطلب إلى ورش العمل الفنية المسجلة التي تفي بالمعايير المحددة

      graph LR A[تصنيف الطلب] --> B[إرسال الطلب إلى الورش الفنية] B --> C[تحديث حالة الطلب]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • تصنيف الطلب
      • توفر الورش الفنية المسجلة
      الشروط اللاحقة
      • الورش الفنية تتلقى الطلب
      تسلسل الأحداث
      • تصنيف الطلب
      • إرسال الطلب إلى الورش الفنية المسجلة
      • تحديث حالة الطلب
      القواعد التجارية
      • يجب أن يتم إرسال الطلبات إلى الورش الفنية المسجلة بناءً على معايير محددة تتعلق بنوع الخدمة والموقع
      الافتراضات
      • الورش الفنية المسجلة متاحة ومستعدة لتقديم الخدمة المطلوبة
      • البيانات المصنفة دقيقة وكاملة
      المتطلبات الخاصة
      • يجب أن يتم إرسال الطلبات في أقل من دقيقة بعد التصنيف
      • يجب أن يكون النظام قادرًا على معالجة وإرسال بيانات كبيرة بفعالية
      الملاحظات والمشاكل
      • تأكد من أن الورش الفنية المحددة قادرة على تقديم الخدمة المطلوبة في الوقت المناسب
      المدخلاتبيانات الطلب المصنفة | قائمة الورش الفنية المسجلة |
      المخرجات
      • طلب مرسل إلى الورش الفنية
      • تحديث حالة الطلب في النظام
      تفاعلات المستخدم
      • النظام يتفاعل مع الورش الفنية لتقديم الخدمة
      سيناريوهات الاستخدام
      • إنشاء طلب صيانة طارئ وإرساله إلى أقرب ورشة فنية مسجلة
      متطلبات الأمان
      • يجب حماية بيانات الطلب والمركبة
      • يجب تأكيد هوية الورش الفنية قبل إرسال الطلبات
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الورش الفنية لتحديد الورش المناسبة
      • تكامل مع قاعدة بيانات الورش الفنية المسجلة
      القيود والافتراضات
      • يجب أن يكون لدى الورش الفنية القدرة على استلام الطلبات إلكترونيًا
      متطلبات الاختبار
      • اختبار أداء النظام في إرسال الطلبات تحت ضغط كبير
      • اختبار دقة إرسال الطلبات إلى الورش المناسبة
      تفاصيل ال API
      Method: POST || Endpoint: /sendServiceRequest
      Request Headers
      Authorization: Bearer token Content-Type: application/json

      Request Body

      request_id: نص workshop_id: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      إرسال طلب الخدمة

      • form
        • text
          • العنوان : معرف الطلب
          • التحقق : نص
        • text
          • العنوان : معرف الورشة
          • التحقق : نص
      • رسالة زر الإرسال: إرسال الطلب
      الاشعارات

      العنوان : طلب خدمة فنية جديد
      الرسالة : لديك طلب خدمة فنية جديد. يرجى مراجعة التفاصيل والرد في أقرب وقت ممكن
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : الورش الفنية

      3.20.2.3- يقوم المتلقي بمراجعة الطلب ويحدد رده، حيث يمكنه إما قبول تقديم الخدمة مع الرد وتحديد التكلفة، طلب مزيد من المعلومات، أو رفض الطلب مع ذكر الأسباب

      graph LR A[تلقي الطلب] --> B[مراجعة الطلب] B --> C[تحديد الرد] C --> D[إرسال الرد إلى النظام] D --> E[إبلاغ العميل برد الورشة الفنية]
      العنوانالتفاصيل
      المستخدمالورشة الفنية
      الشروط المسبقة
      • تلقي الطلب
      • توفر معلومات كافية لتحديد الرد
      الشروط اللاحقة
      • النظام يتلقى رد الورشة الفنية
      • إبلاغ العميل برد الورشة الفنية
      تسلسل الأحداث
      • تلقي الطلب من النظام
      • مراجعة الطلب من قبل الورشة الفنية
      • تحديد الرد المناسب (قبول/رفض/طلب معلومات إضافية)
      • إرسال الرد إلى النظام
      • إبلاغ العميل برد الورشة الفنية
      القواعد التجارية
      • يجب أن يتم الرد على الطلبات في غضون فترة زمنية محددة لتلبية متطلبات الخدمة الفعالة
      الافتراضات
      • الورشة الفنية لديها القدرة على تقييم الطلبات والرد عليها بشكل صحيح
      • النظام قادر على تلقي الردود ومعالجتها
      المتطلبات الخاصة
      • يجب أن يكون النظام قادرًا على معالجة ردود متعددة من الورش الفنية في وقت واحد
      • يجب أن يتم تحديث حالة الطلب فور تلقي الرد من الورشة الفنية
      الملاحظات والمشاكل
      • تأكد من أن جميع الردود المقدمة من الورش الفنية يتم تسجيلها بشكل صحيح في النظام
      المدخلاتبيانات الطلب | تفاصيل الخدمة المطلوبة | معلومات إضافية من العميل إن وجدت |
      المخرجات
      • رد الورشة الفنية (قبول/رفض/طلب معلومات إضافية)
      • تحديث حالة الطلب في النظام
      • إشعار العميل برد الورشة الفنية
      تفاعلات المستخدم
      • النظام يتفاعل مع الورشة الفنية لتلقي الردود
      • النظام يتفاعل مع العميل لإبلاغه برد الورشة الفنية
      سيناريوهات الاستخدام
      • تلقي الورشة الفنية طلب صيانة، ومراجعة تفاصيله، وإرسال رد بقبول الطلب وتحديد التكلفة
      متطلبات الأمان
      • يجب حماية بيانات الطلب وردود الورشة الفنية
      • يجب التحقق من هوية الورشة الفنية قبل السماح لها بالرد على الطلبات
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الطلبات لتتبع حالة الطلبات
      • تكامل مع قاعدة بيانات الورش الفنية المسجلة
      القيود والافتراضات
      • يجب أن يكون لدى الورش الفنية القدرة على استلام ومعالجة الطلبات إلكترونيًا
      متطلبات الاختبار
      • اختبار قدرة النظام على تلقي ومعالجة ردود متعددة من الورش الفنية
      • اختبار دقة تحديث حالة الطلب بعد تلقي الرد
      تفاصيل ال API
      Method: POST || Endpoint: /respondToServiceRequest
      Request Headers
      Authorization: Bearer token Content-Type: application/json

      Request Body

      request_id: نص response: نص cost_estimate: number additional_info: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      الرد على طلب الخدمة

      • form
        • text
          • العنوان : رد الورشة
          • التحقق : نص
        • number
          • العنوان : التكلفة التقديرية
          • التحقق : number
        • text
          • العنوان : معلومات إضافية
          • التحقق : نص
      • رسالة زر الإرسال: إرسال الرد
      الاشعارات

      العنوان : رد على طلب الخدمة الفنية
      الرسالة : تم الرد على طلبك من قبل الورشة الفنية. يرجى مراجعة الرد في التطبيق
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : العميل

      3.21 - الرد على طلب خدمة النقل

      3.21.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • توفير واجهة سهلة الاستخدام تُمكن الورشة الفنية من الرد على الطلبات بما يحقق تقديرها الخاص للتكلفة والوقت، مما يزيد فرص تلقي العميل الخدمة التي يحتاجها بشكل ملائم ومريح
      الجهات المعنية
      • الورشة الفنية (التي تقدم الرد على الطلب وتحدد الرسوم)
      الخطوات الرئيسية
      • الورشة الفنية تدخل الزمن المتوقع للرد (مثل: خلال كم ساعة خدمة)
      • الورشة الفنية تدخل الأجرة المتوقعة للإصلاح المطلوب
      • يتم حساب الرسوم المقررة على الخدمة
      • يتم حساب الضريبة على الخدمة المقررة
      • يتم عرض صافي المبلغ المستحق للورشة بعد خصم الرسوم من أجرة الإصلاح
      • الموافقة وإرسال العرض لطالب الخدمة
      الخطوات البديلة
      • في حالة عدم الموافقة على الطلب، يمكن للورشة الفنية رفض الطلب مع ذكر السبب
      قصص المستخدمين
      • الورشة الفنية، كمستخدم: أريد إدخال الزمن المتوقع للرد وتحديد الأجرة للإصلاح، حتى أستطيع تقديم عرض ملائم ومنافس
      • الورشة الفنية، كمستخدم: أريد أن أرى صافي المبلغ المستحق بعد خصم الرسوم والضرائب من أجرة الإصلاح، حتى يكون لدي فكرة واضحة عن ما سأحصل عليه
      • الورشة الفنية، كمستخدم: أريد أن أتمكن من الموافقة على العرض وإرساله إلى العميل، لكي أحصل على الفرصة لتقديم الخدمة
      مؤشرات الأداء
      • عدد الورش الفنية التي استلمت الطلب ونسبة الاستجابة

      3.21.2 حالات الاستخدام

      3.21.2.1- الورشة الفنية تدخل الزمن المتوقع للرد (مثل: خلال كم ساعة خدمة)

      graph LR A[استلام الطلب] --> B[إدخال الزمن المتوقع] B --> C[تحديث الزمن في النظام] C --> D[إشعار طالب الخدمة]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • طلب خدمة النقل موجود
      • الورشة الفنية لها صلاحيات كاملة
      الشروط اللاحقة
      • يتم عرض الزمن المتوقع للرد لطالب الخدمة
      تسلسل الأحداث
      • جمع بيانات الخدمة الفنية المطلوبة
      • تحلل بياناتها الورشة الفنية
      • تحدد الوقت المتوقع من الورشة الفنية
      • تحديث الوقت في النظام
      الخطوات البديلةفي حالة عدم وجود بيانات كافية لإدخال الزمن المتوقع
      • النظام يطلب من الورشة الفنية مراجعة تفاصيل الطلب
      • الورشة الفنية تجمع المعلومات المطلوبة وتدخل الزمن المتوقع
      الخطوات الاستثنائيةإذا لم تتمكن الورشة الفنية من إدخال الزمن المتوقع بسبب خطأ تقني
      • النظام يعرض رسالة خطأ
      • الورشة الفنية تحاول مرة أخرى أو تتواصل مع دعم النظام
      القواعد التجارية
      • يجب إدخال الزمن المتوقع بدقة لضمان تلبية توقعات العميل
      • يجب تحديث الزمن المتوقع في النظام في الوقت الحقيقي
      الافتراضات
      • الورشة الفنية لديها اتصال مستقر بالانترنت
      • الورشة الفنية تعرف كيفية استخدام النظام لإدخال البيانات
      المتطلبات الخاصة
      • يجب أن يكون النظام قادرًا على التعامل مع عدد كبير من الطلبات في وقت واحد
      • يجب أن يكون النظام متاحًا على مدار الساعة
      الملاحظات والمشاكل
      • في حالة وجود تأخير في إدخال الزمن المتوقع، يجب التحقيق في السبب ومعالجته لضمان الكفاءة
      المدخلاتتفاصيل الطلب | الزمن المتوقع |
      المخرجات
      • تحديث الزمن في النظام
      • ارسال اشعار لطالب الخدمة بالزمن المتوقع
      تفاعلات المستخدم
      • ادخال الزمن المتوقع
      • تأكيد الادخال
      الشروط الخاصة
      • يجب أن يكون النظام متاحًا ومتجاوبًا
      • يجب أن تكون البيانات المدخلة دقيقة ومحدثة
      سيناريوهات الاستخدام
      • استخدام الورشة الفنية الخاصية لإدخال الزمن المتوقع عند استلام الطلب
      • استخدام النظام لتحديث الزمن المتوقع في قاعدة البيانات
      متطلبات الأمان
      • يجب أن تكون البيانات المدخلة محمية ومشفرة
      • يجب أن يكون الوصول إلى النظام محدودًا للمستخدمين المصرح لهم فقط
      التكامل مع الأنظمة الأخرى
      • قاعدة بيانات النظام لتحديث الزمن المتوقع
      • نظام الإشعارات لإبلاغ العميل بالزمن المتوقع
      القيود والافتراضات
      • يفترض أن الورشة الفنية لديها جميع الصلاحيات اللازمة للوصول إلى النظام
      • يفترض أن النظام يعمل بشكل صحيح ودون أعطال
      متطلبات الاختبار
      • اختبار إدخال الزمن المتوقع في بيئات مختلفة لضمان الكفاءة
      • اختبار واجهة المستخدم لضمان سهولة الاستخدام
      • اختبار عملية تحديث الزمن في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/service/expected_time
      Request Headers
      Authorization: Bearer token

      Request Body

      service_id: string expected_time: integer

      Response

      الحالةالمحتوى
      200status: string
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      ExpectedTimeEntryScreen

      • textblock
        • إدخال الزمن المتوقع للرد

      • form
        • NumberInput
          • العنوان : الزمن المتوقع (بالساعات)
          • التحقق : required|min:1 error_message: يرجى إدخال الزمن المتوقع بشكل صحيح
          • الخيارات : id:expected_time
      • رسالة زر الإرسال: ادخال
      • رسالة النجاح: تم إدخال الزمن المتوقع بنجاح
      • إعادة توجيه النجاح: ServiceDetailsScreen
      الاشعارات

      العنوان : تحديث الزمن المتوقع
      الرسالة : تم تحديث الزمن المتوقع للرد على طلبك
      عن طريق : push notification, notification bar  المستقبل : طالب الخدمة

      3.21.2.2- الورشة الفنية تدخل الأجرة المتوقعة للإصلاح المطلوب

      graph LR; A[إدخال الأجرة المتوقعة] --> B[تحديث النظام بالأجرة المتوقعة]; B --> C[عرض الأجرة لطالب الخدمة];
      العنوانالتفاصيل
      المستخدمالورشة الفنية
      الشروط المسبقة
      • طلب خدمة النقل موجود
      • الورشة الفنية لديها الصلاحيات اللازمة
      الشروط اللاحقة
      • يتم عرض الأجرة المتوقعة لطالب الخدمة
      تسلسل الأحداث
      • إدخال الأجرة المتوقعة
      • تحديث النظام بالأجرة المتوقعة
      • عرض الأجرة لطالب الخدمة
      الخطوات البديلةفي حال وجود خطأ في إدخال الأجرة المتوقعة
      • النظام يعرض رسالة خطأ للورشة الفنية
      • الورشة الفنية تصحح الأجرة المتوقعة وتعيد الإدخال
      الخطوات الاستثنائيةإذا تعذر على النظام تحديث الأجرة المتوقعة
      • النظام يعرض رسالة خطأ
      • الورشة الفنية تتواصل مع الدعم الفني لحل المشكلة
      القواعد التجارية
      • يجب أن تكون الأجرة المتوقعة معقولة ومتوافقة مع معايير السوق
      • يجب أن تشمل الأجرة المتوقعة جميع التكاليف المحتملة
      الافتراضات
      • الورشة الفنية لديها المعلومات الكافية لتحديد الأجرة المتوقعة
      • النظام قادر على تحديث الأجرة المتوقعة بشكل صحيح
      المتطلبات الخاصة
      • النظام يجب أن يكون قادرًا على التعامل مع حجم البيانات الكبير
      • يجب أن يتم تحديث الأجرة المتوقعة في الوقت الفعلي
      الملاحظات والمشاكل
      • قد تحتاج الورشة الفنية إلى تدريب على كيفية استخدام النظام بشكل صحيح لتحديد الأجرة المتوقعة
      • يجب توفير دعم فني لحل أي مشكلات قد تواجه الورش الفنية
      المدخلاتتفاصيل الخدمة المطلوبة | التكاليف المتوقعة للإصلاح |
      المخرجات
      • الأجرة المتوقعة للإصلاح
      تفاعلات المستخدم
      • إدخال الأجرة المتوقعة عبر واجهة المستخدم
      • عرض الأجرة المتوقعة لطالب الخدمة
      الشروط الخاصة
      • خطأ في إدخال الأجرة المتوقعة
      • تعذر تحديث الأجرة المتوقعة في النظام
      سيناريوهات الاستخدام
      • الورشة الفنية تحدد الأجرة المتوقعة بعد تلقي طلب خدمة النقل
      • النظام يعرض الأجرة المتوقعة لطالب الخدمة
      متطلبات الأمان
      • تحديد صلاحيات الوصول لإدخال الأجرة المتوقعة
      • حماية البيانات المدخلة وضمان عدم التلاعب بها
      التكامل مع الأنظمة الأخرى
      • نظام إدارة الطلبات لتلقي تفاصيل الخدمة المطلوبة
      • نظام إدارة التكاليف لتحديد الأجرة المتوقعة
      القيود والافتراضات
      • يجب أن تكون البيانات المدخلة دقيقة وحديثة
      • يجب أن يكون النظام قادرًا على التعامل مع حجم البيانات الكبير
      متطلبات الاختبار
      • اختبار دقة الأجرة المتوقعة
      • اختبار عملية تحديث الأجرة المتوقعة في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /repair-estimate
      Request Headers
      Authorization: Bearer token

      Request Body

      service_request_id: integer estimated_cost: decimal

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: تم تقديم التكلفة المقدرة بنجاح
      400
      الوصف: Bad Request

      Method: GET || Endpoint: /repair-estimate/:id
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200estimated_cost: decimal
      الوصف: Estimated cost retrieved successfully
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تقدير الإصلاح

      • form
        • text
          • العنوان : التكلفة المقدرة
          • التحقق : required: 1 pattern: ^[0-9]*.?[0-9]+$ errorMessage: Please enter a valid cost
      • رسالة زر الإرسال: Submit Estimate
      • رسالة النجاح: تم تقديم التكلفة المقدرة بنجاح
      • إعادة توجيه النجاح: ServiceRequestDetails
      الاشعارات

      العنوان : تكلفة الإصلاح المقدرة
      الرسالة : تم تقديم تكلفة الإصلاح المقدرة لطلب الخدمة الخاص بك. يرجى مراجعة التفاصيل
      عن طريق : ايميل  المستقبل : طالب الخدمة

      3.21.2.3- حساب الرسوم المقررة على الخدمة بناءً على معايير محددة

      graph LR; A[جمع بيانات الخدمة المطلوبة] --> B[حساب الرسوم المقررة]; B --> C[عرض الرسوم للورشة الفنية];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • وجود طلب خدمة النقل
      • توفر بيانات الشحنات المطلوبة
      • الأجرة المتوقعة للإصلاح مدخلة
      الشروط اللاحقة
      • حساب الرسوم المقررة على الخدمة وعرضها للورشة الفنية
      تسلسل الأحداث
      • جمع بيانات الخدمة المطلوبة
      • ادخال الاجرة المتوقعة للاصلاح
      • حساب الرسوم المقررة
      • عرض الرسوم للورشة الفنية
      الخطوات البديلةفي حال عدم توفر البيانات الكافية لحساب الرسوم
      • النظام يعرض رسالة تنبيه بعدم توفر البيانات الكافية
      • النظام يطلب من الورشة الفنية إدخال البيانات الناقصة
      الخطوات الاستثنائيةفي حال حدوث خطأ أثناء حساب الرسوم
      • النظام يعرض رسالة خطأ
      • النظام يسجل الخطأ في السجلات
      • الورشة الفنية تتواصل مع الدعم الفني لحل المشكلة
      القواعد التجارية
      • الرسوم يجب أن تحسب بناءً على معايير محددة تتضمن تكلفة المواد والعمل
      • يجب أن يتم تحديث الرسوم في النظام تلقائيًا بعد كل تعديل
      الافتراضات
      • النظام يحتوي على جميع البيانات اللازمة لحساب الرسوم
      • الورشة الفنية يمكنها تقديم بيانات إضافية إذا لزم الأمر
      المتطلبات الخاصة
      • النظام يجب أن يكون قادرًا على التعامل مع مختلف أنواع البيانات وتحديثها بشكل فوري
      • الرسوم يجب أن تكون دقيقة ومعتمدة على بيانات صحيحة
      الملاحظات والمشاكل
      • يجب تحسين النظام لضمان دقة الحسابات وتقليل الأخطاء
      • قد تحتاج الورش الفنية إلى تدريب على كيفية إدخال البيانات بشكل صحيح
      المدخلاتبيانات الخدمة المطلوبة | تكاليف المواد والعمل |
      المخرجات
      • الرسوم المقررة على الخدمة
      تفاعلات المستخدم
      • عرض الرسوم المقررة للورشة الفنية
      • إدخال البيانات الناقصة من قبل الورشة الفنية إذا لزم الأمر
      الشروط الخاصة
      • عدم توفر البيانات الكافية لحساب الرسوم
      • حدوث خطأ أثناء حساب الرسوم
      سيناريوهات الاستخدام
      • ورشة فنية تطلب حساب الرسوم بعد إدخال تفاصيل الخدمة المطلوبة
      • النظام يعرض الرسوم للورشة الفنية لتقديمها للعميل
      متطلبات الأمان
      • حماية البيانات المدخلة وضمان عدم التلاعب بها
      • تحديد صلاحيات الوصول إلى البيانات والرسوم
      التكامل مع الأنظمة الأخرى
      • نظام إدارة الطلبات لتلقي تفاصيل الخدمة المطلوبة
      • نظام إدارة التكاليف لحساب الرسوم المقررة
      القيود والافتراضات
      • يجب أن تكون البيانات المدخلة دقيقة وحديثة
      • يجب أن يكون النظام قادرًا على التعامل مع حجم البيانات الكبير
      متطلبات الاختبار
      • اختبار دقة الرسوم المحسوبة
      • اختبار عملية حساب الرسوم في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /service-fee
      Request Headers
      Authorization: Bearer token

      Request Body

      service_details: object material_cost: decimal labor_cost: decimal

      Response

      الحالةالمحتوى
      200service_fee: decimal
      الوصف: تم حساب رسوم الخدمة بنجاح
      400
      الوصف: Bad Request

      Method: GET || Endpoint: /service-fee/:id
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200service_fee: decimal
      الوصف: Service fee retrieved successfully
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      رسوم الخدمة

      • form
        • text
          • العنوان : تكلفة المواد
          • التحقق : required: 1 pattern: ^[0-9]*.?[0-9]+$ errorMessage: Please enter a valid cost
        • text
          • العنوان : تكلفة العمل
          • التحقق : required: 1 pattern: ^[0-9]*.?[0-9]+$ errorMessage: Please enter a valid cost
      • رسالة زر الإرسال: Calculate Fee
      • رسالة النجاح: تم حساب رسوم الخدمة بنجاح
      • إعادة توجيه النجاح: ServiceFeeDetails
      الاشعارات

      العنوان : حساب رسوم الخدمة
      الرسالة : تم حساب رسوم الخدمة لطلبك. يرجى مراجعة التفاصيل
      عن طريق : ايميل  المستقبل : ورشة فنية

      3.21.2.4- يقوم النظام بحساب الضريبة على الخدمة المقررة

      graph LR; A[جمع بيانات الخدمة المطلوبة] --> B[حساب تكاليف الأجرة]; B --> C[حساب الرسوم للورشة الفنية] --> D[ حساب الضريبة]; D --> E[عرض الضريبة لطالب الخدمة];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • الأجرة المتوقعة للإصلاح مدخلة
      • حساب الرسوم المقررة على الخدمة
      الشروط اللاحقة
      • عرض الضريبة المقررة لطالب الخدمة
      تسلسل الأحداث
      • ادخال الأجرة المتوقعة للاصلاح
      • حساب الرسوم المقررة على الخدمة
      • حساب الضريبة على الخدمة
      • عرض الضريبة على طالب الخدمة
      الخطوات البديلةفي حالة حدوث خطأ أثناءحساب الضريبة
      • النظام يعرض رسالة الخطأ
      • النظام يسجل الخطأ في السجلات
      • النظام يتواصل مع الدعم الفني لحل المشكلة
      القواعد التجارية
      • الضريبة يجب أن تحسب بناءا على معايير معينة
      • يجب أن يتم تحديث الضريبة في النظام تلقائيا
      الافتراضات
      • النظام يحتوي على جميع البيانات اللازمة لحساب الضريبة
      المتطلبات الخاصة
      • إشعار فوري عبر البريد الإلكتروني و/أو الرسائل النصية القصيرة
      الملاحظات والمشاكل
      • الضريبة يجب أن تكون دقيقة ومعتمدة على بينانات صحيحة
      • النظام يجب أن يكون قادر على التعامل مع محتلف البيانات وتحديثها بشكل فوري
      المدخلاتبيانات الأجرة المتوقعة | الرسوم المقررة |
      المخرجات
      • الضريبة المقررة على الخدمة
      تفاعلات المستخدم
      • عرض الضربة المقررة على طالب الخدمة
      الشروط الخاصة
      • عدم توفير البيانات الكافية لحساب الضريبة
      • حدوث خطأ أثناء حساب الضريبة
      سيناريوهات الاستخدام
      • طالب الخدمة يستعلم عن تفاصيل الضريبة المفروضة على الخدمة
      متطلبات الأمان
      • تأكيد هوية المستلم قبل تأكيد الاستلام
      التكامل مع الأنظمة الأخرى
      • نظام ادارة الضرائب لحساب الضريبة المقررة على الخدمة
      القيود والافتراضات
      • يجب أن تكون البيانات المدخلة دقيقة وحديثة
      • يجب أن يكون النظام قادر على التعامل مع حجم البيانات الكبيرة
      متطلبات الاختبار
      • اختبار دقة الضرائب المحسوبة
      • اختبار عملية حساب الضرائب في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /taxes-fee
      Request Headers
      Authorization: Bearer token

      Request Body

      service-details:object material-cost:decimal labor-cost:decimal service-fee:decimal

      Response

      الحالةالمحتوى
      200taxes-fee:decimal
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      ضرائب الخدمة

      • form
        • text
          • العنوان : أجرة الخدمة
          • التحقق : required: 1 pattern: ^[0-9]*.?[0-9]+$ errorMessage: Please enter a valid cost
        • text
          • العنوان : الرسوم المقررة
          • التحقق : required: 1 pattern: ^[0-9]*.?[0-9]+$ errorMessage: Please enter a valid number
      • رسالة زر الإرسال: Calculate taxes
      • رسالة النجاح: تم حساب الضريبة بنجاح
      • إعادة توجيه النجاح: TaxesFeeDetails
      الاشعارات

      العنوان : ضريبة الخدمة
      الرسالة : تم حساب رسوم الخدمة لطلبك. يرجى مراجعة التفاصيل
      عن طريق : ايميل  المستقبل : العميل( طالب الخدمة )

      3.21.2.5- عرض صافي المبلغ المستحق للورشة بعد خصم الرسوم من أجرة الإصلاح

      graph LR A[إدخال الأجرة المتوقعة] -->|حساب الرسوم والضرائب| B[حساب صافي المبلغ المستحق] B --> C[تحديث صافي المبلغ المستحق في النظام] C --> D[عرض صافي المبلغ للورشة]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • الأجرة المتوقعة للإصلاح مدخلة
      • الرسوم والضرائب محسوبة
      الشروط اللاحقة
      • عرض صافي المبلغ المستحق للورشة
      تسلسل الأحداث
      • النظام يحسب صافي المبلغ المستحق
      • تحديث صافي المبلغ المستحق في النظام
      • عرض صافي المبلغ المستحق للورشة
      الخطوات الاستثنائيةإذا فشل النظام في حساب صافي المبلغ المستحق
      • النظام يرسل إشعارًا إلى المشرف لإصلاح المشكلة
      • المشرف يقوم بإصلاح المشكلة ويعيد المحاولة
      القواعد التجارية
      • يجب حساب الرسوم والضرائب بدقة قبل عرض صافي المبلغ المستحق
      الافتراضات
      • الرسوم والضرائب محسوبة بدقة
      • النظام قادر على حساب صافي المبلغ المستحق بدون أخطاء
      المتطلبات الخاصة
      • تحديث مستمر لصافي المبلغ المستحق في النظام
      الملاحظات والمشاكل
      • التأكد من دقة الحسابات وتجنب الأخطاء في النظام
      المدخلاتالأجرة المتوقعة للإصلاح | الرسوم والضرائب |
      المخرجات
      • صافي المبلغ المستحق
      تفاعلات المستخدم
      • النظام يعرض صافي المبلغ المستحق للورشة
      الشروط الخاصة
      • إذا كان هناك خطأ في حساب الرسوم أو الضرائب
      سيناريوهات الاستخدام
      • الورشة ترى صافي المبلغ المستحق بعد خصم الرسوم والضرائب
      متطلبات الأمان
      • حماية البيانات المالية والحسابات من الوصول غير المصرح به
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام المحاسبة لحساب الرسوم والضرائب
      القيود والافتراضات
      • النظام يعمل بكفاءة ويقوم بالحسابات بدقة
      متطلبات الاختبار
      • اختبار حساب الرسوم والضرائب وصافي المبلغ المستحق بدقة
      تفاصيل ال API
      Method: POST || Endpoint: /workshop/net-amount
      Request Headers
      Authorization: Bearer token

      Request Body

      repair_cost: number fees: number taxes: number

      Response

      الحالةالمحتوى
      200net_amount: number
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة المبلغ الصافي

      • textblock
        • صافي المبلغ المستحق

      • form
        • text
          • العنوان : المبلغ
      الاشعارات

      العنوان : خطأ في حساب صافي المبلغ المستحق
      الرسالة : حدث خطأ في حساب صافي المبلغ المستحق. يرجى التحقق وإصلاح المشكلة
      عن طريق : ايميل, SMS  المستقبل : المشرف

      3.21.2.6- الموافقة وإرسال العرض لطالب الخدمة

      graph LR A[إدخال الأجرة المتوقعة] -->|حساب الرسوم والضرائب| B[الموافقة على العرض] B --> C[النظام يرسل العرض لطالب الخدمة] C --> D[عرض الورشة الفنية مرسل لطالب الخدمة]
      العنوانالتفاصيل
      المستخدمالورشة الفنية
      الشروط المسبقة
      • الأجرة المتوقعة للإصلاح مدخلة
      • الرسوم والضرائب محسوبة
      الشروط اللاحقة
      • عرض الورشة الفنية مرسل لطالب الخدمة
      تسلسل الأحداث
      • الورشة الفنية توافق على العرض
      • النظام يرسل العرض لطالب الخدمة
      الخطوات الاستثنائيةإذا فشل النظام في إرسال العرض
      • النظام يرسل إشعارًا إلى المشرف لإصلاح المشكلة
      • المشرف يقوم بإصلاح المشكلة ويعيد المحاولة
      القواعد التجارية
      • يجب حساب الرسوم والضرائب بدقة قبل إرسال العرض لطالب الخدمة
      الافتراضات
      • الرسوم والضرائب محسوبة بدقة
      • النظام قادر على إرسال العرض بدون أخطاء
      المتطلبات الخاصة
      • تحديث مستمر لحالة العرض في النظام
      الملاحظات والمشاكل
      • التأكد من دقة الحسابات وتجنب الأخطاء في النظام
      المدخلاتالأجرة المتوقعة للإصلاح | الرسوم والضرائب |
      المخرجات
      • عرض الورشة الفنية لطالب الخدمة
      تفاعلات المستخدم
      • النظام يعرض العرض لطالب الخدمة
      الشروط الخاصة
      • إذا كان هناك خطأ في إرسال العرض
      سيناريوهات الاستخدام
      • الورشة الفنية توافق على العرض ويتم إرساله لطالب الخدمة بنجاح
      متطلبات الأمان
      • حماية بيانات العرض من الوصول غير المصرح به
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام المحاسبة لحساب الرسوم والضرائب
      القيود والافتراضات
      • النظام يعمل بكفاءة ويقوم بالحسابات بدقة
      متطلبات الاختبار
      • اختبار إرسال العرض بدقة والتحقق من وصوله لطالب الخدمة
      تفاصيل ال API
      Method: POST || Endpoint: /workshop/send-offer
      Request Headers
      Authorization: Bearer token

      Request Body

      offer_id: نص repair_cost: number fees: number taxes: number

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تأكيد العرض

      • textblock
        • تم إرسال عرضك بنجاح

      • form
        • Button
          • العنوان : حسناً
          • الخيارات : closeNotification
      الاشعارات

      العنوان : خطأ في إرسال العرض
      الرسالة : حدث خطأ في إرسال العرض. يرجى التحقق وإصلاح المشكلة
      عن طريق : ايميل, SMS  المستقبل : المشرف

      3.21.2.7- رفض الطلب مع ذكر السبب

      graph LR A[وجود طلب خدمة النقل] -->|رفض الطلب| B[إدخال سبب الرفض] B --> C[إرسال سبب الرفض لطالب الخدمة] C --> D[إشعار طالب الخدمة برفض الطلب]
      العنوانالتفاصيل
      المستخدمالورشة الفنية
      الشروط المسبقة
      • طلب خدمة النقل موجود
      الشروط اللاحقة
      • يتم إبلاغ طالب الخدمة برفض الطلب وسببه
      تسلسل الأحداث
      • الورشة الفنية ترفض الطلب
      • إدخال سبب الرفض
      • النظام يرسل سبب الرفض لطالب الخدمة
      الخطوات الاستثنائيةإذا فشل النظام في إرسال سبب الرفض
      • النظام يرسل إشعارًا إلى المشرف لإصلاح المشكلة
      • المشرف يقوم بإصلاح المشكلة ويعيد المحاولة
      القواعد التجارية
      • يجب على الورشة الفنية توضيح سبب الرفض بشكل دقيق
      الافتراضات
      • النظام قادر على إرسال سبب الرفض بدون أخطاء
      المتطلبات الخاصة
      • تحديث مستمر لحالة الطلب في النظام
      الملاحظات والمشاكل
      • التأكد من دقة سبب الرفض المقدم وتجنب الأخطاء في النظام
      المدخلاتطلب خدمة النقل | سبب الرفض |
      المخرجات
      • إشعار برفض الطلب مع ذكر السبب
      تفاعلات المستخدم
      • النظام يرسل سبب الرفض لطالب الخدمة
      الشروط الخاصة
      • إذا كان هناك خطأ في إرسال سبب الرفض
      سيناريوهات الاستخدام
      • الورشة الفنية ترفض الطلب مع ذكر السبب، ويتم إبلاغ طالب الخدمة بذلك
      متطلبات الأمان
      • حماية بيانات الرفض من الوصول غير المصرح به
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام الإشعارات لإبلاغ طالب الخدمة
      القيود والافتراضات
      • النظام يعمل بكفاءة ويقوم بإرسال الإشعارات بدقة
      متطلبات الاختبار
      • اختبار إرسال سبب الرفض والتحقق من وصوله لطالب الخدمة
      تفاصيل ال API
      Method: POST || Endpoint: /workshop/reject-request
      Request Headers
      Authorization: Bearer token

      Request Body

      request_id: نص rejection_reason: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة إشعار الرفض

      • textblock
        • تم رفض طلبك

      • textblock
        • {rejection_reason}

      • form
        • Button
          • العنوان : حسناً
          • الخيارات : closeNotification
      الاشعارات

      العنوان : تم رفض طلبك
      الرسالة : طلبك رقم {request_id} قد تم رفضه. السبب: {rejection_reason}
      عن طريق : ايميل, SMS  المستقبل : طالب الخدمة

      3.22 - الموافقة على خدمة فنية للرحلة

      3.22.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • توفير واجهة سهلة الاستخدام تُمكن العميل من الاختيار بين العروض المتاحة وقبول الأنسب بناءً على احتياجاته وتوقعاته
      الجهات المعنية
      • العميل (طالب الخدمة)
      الخطوات الرئيسية
      • العميل يستعرض كافة العروض المستلمة
      • العميل يقارن بين العروض بناءً على أجرة الإصلاح، المسافة بين الورشة والزمن المتوقع للإصلاح
      • العميل يقرر قبول أحد العروض
      • يتم حساب التكلفة بإجمالي: رسوم أجرة الإصلاح + رسوم الخدمة المقررة + رسوم الضريبة على الخدمة
      الخطوات البديلة
      • في حالة عدم الموافقة على أي من العروض، يمكن للعميل إعادة إصدار طلب جديد أو التواصل مع الورش الفنية مباشرة
      قصص المستخدمين
      • العميل، كمستخدم: أريد مطالعة كافة العروض المستلمة والاختيار من بينها بناءً على تقديري للسعر والمدة والبعد عن الورشة، حتى أحصل على الخدمة بالوقت والمال المناسب لي
      • العميل، كمستخدم: أريد أن أعرف التكلفة الإجمالية للخدمة بما في ذلك الرسوم والضرائب، حتى يكون لدي فكرة واضحة عما سأدفعه
      • العميل، كمستخدم: أريد أن أتمكن من الموافقة على العرض، حتى نتمكن من بدء الإصلاح بأسرع وقت ممكن
      مؤشرات الأداء

      3.22.2 حالات الاستخدام

      3.22.2.1- العميل يقوم بالاستعراض الكامل لجميع العروض المستلمة من الورش الفنية، بما في ذلك التفاصيل المتعلقة بأجرة الإصلاح، المسافة إلى الورشة، والزمن المتوقع للإصلاح.

      graph LR; A[Start] --> B[Login]; B --> C[Navigate to Received Offers Page]; C --> D[View Offer Details]; D --> E[Compare Offers]; E --> F[End];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • توافر العروض بعد استلامها من الورش الفنية.
      • تسجيل دخول العميل إلى النظام.
      الشروط اللاحقة
      • العروض تكون متاحة للمقارنة من قبل العميل.
      • تحديث حالة العروض التي تم مراجعتها في النظام.
      الافتراضات
      • العميل لديه اتصال بالإنترنت.
      • العميل لديه حساب مسجل في النظام.
      تفاصيل ال API
      Method: GET || Endpoint: /offers/received
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200Offers : Array
      الوصف: Success
      400
      الوصف: Bad Request
      401
      الوصف: Unauthorized

      تفاصيل الواجهات
      شاشة العروض المستلمة

      • textblock
        • عروض الإصلاح المستلمة

      • list
        • النوع : repair_cost: number distance_to_workshop: number expected_repair_time: نص

      3.22.2.2- العميل يقوم بمقارنة العروض المستلمة من الورش الفنية بناءً على عدة معايير، مثل أجرة الإصلاح، المسافة بين الورشة وموقع العميل، والزمن المتوقع لإتمام الإصلاح، بهدف اختيار العرض الأنسب.

      graph LR; A[Start] --> B[View Offers]; B --> C[Click Compare Offers]; C --> D[Compare Based on Criteria]; D --> E[Select Best Offer]; E --> F[End];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • توافر عدة عروض مستلمة من الورش الفنية.
      • العميل قد استعرض تفاصيل العروض.
      الشروط اللاحقة
      • يتم اختيار العرض الأنسب من قبل العميل.
      • يتم تحديث حالة العروض التي تمت مقارنتها في النظام.
      الافتراضات
      • العميل لديه اتصال بالإنترنت.
      • العميل لديه حساب مسجل في النظام.
      تفاصيل ال API
      Method: POST || Endpoint: /offers/compare
      Request Headers
      Authorization: Bearer token

      Request Body

      Offer_ids : array of strings

      Response

      الحالةالمحتوى
      200Comparison_result : Array
      الوصف: Success
      400
      الوصف: Bad Request
      401
      الوصف: Unauthorized

      تفاصيل الواجهات
      شاشة مقارنة العروض

      • textblock
        • مقارنة العروض

      • table
        • الاسم : أجرة الإصلاح
        • نوع المحتوي : number

        • الاسم : المسافة إلى الورشة
        • نوع المحتوي : number

        • الاسم : الزمن المتوقع للإصلاح
        • نوع المحتوي : نص

      • form
        • Button
          • العنوان : اختيار العرض الأنسب
          • الخيارات : selectBestOffer

      3.22.2.3- العميل يقرر قبول أحد العروض المتاحة بعد المقارنة، ويقوم بتثبيت العرض المقبول في النظام ليتم تحديث حالة الطلب والانتقال إلى مرحلة حساب التكلفة الإجمالية.

      graph LR; A[Start] --> B[Compare Offers]; B --> C[Select Best Offer]; C --> D[Click Accept Offer]; D --> E[Confirm Offer in System]; E --> F[Update Request Status]; F --> G[Notify Workshop]; G --> H[Move to Cost Estimation]; H --> I[End];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • تمت مقارنة العروض المتاحة.
      • العميل قد حدد العرض الأنسب بناءً على المعايير.
      الشروط اللاحقة
      • يتم تثبيت العرض المقبول وتحديث حالة الطلب في النظام.
      • يتم الانتقال إلى مرحلة حساب التكلفة الإجمالية.
      الافتراضات
      • العميل لديه اتصال بالإنترنت.
      • العميل لديه حساب مسجل في النظام.
      تفاصيل ال API
      Method: POST || Endpoint: /offers/accept
      Request Headers
      Authorization: Bearer token

      Request Body

      offer_id: نص

      Response

      الحالةالمحتوى
      200status: accepted next_step: cost_estimation
      الوصف: Success
      400
      الوصف: Bad Request
      401
      الوصف: Unauthorized

      تفاصيل الواجهات
      شاشة قبول العرض

      • form
        • Button
          • العنوان : قبول العرض
          • الخيارات : acceptOffer
      الاشعارات

      العنوان : قبول العرض
      الرسالة : تم قبول العرض المقدم من قبل العميل. الرجاء البدء في الإجراءات اللازمة.
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : الورشة الفنية

      العنوان : تأكيد قبول العرض
      الرسالة : تم قبول العرض بنجاح والانتقال إلى مرحلة حساب التكلفة الإجمالية.
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : العميل

      3.22.2.4- يتم حساب التكلفة بإجمالي: رسوم أجرة الإصلاح + رسوم الخدمة المقررة + رسوم الضريبة على الخدمة

      graph LR; A[قبول العرض من قبل العميل] --> B[حساب التكلفة الإجمالية]; B --> C[عرض التكلفة الإجمالية للعميل]; C --> D[تحديث حالة الطلب في النظام لتشمل التكلفة الإجمالية];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • تم قبول عرض من قبل العميل
      • تفاصيل الرسوم والخدمات متاحة في النظام
      الشروط اللاحقة
      • يتم عرض التكلفة الإجمالية للعميل
      • يتم تحديث حالة الطلب في النظام لتشمل التكلفة الإجمالية
      سيناريوهات الاستخدام
      • العميل: بعد قبول العرض، أحتاج إلى معرفة التكلفة الإجمالية المتوقعة للخدمة بما في ذلك كافة الرسوم والضرائب
      تفاصيل ال API
      Method: POST || Endpoint: /calculate-total-cost
      Request Headers
      Content-Type: application/json

      Request Body

      service_id: نص repair_cost: number service_fee: number tax_rate: number

      Response

      الحالةالمحتوى
      200total_cost: number
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      عرض التكلفة الإجمالية

      • textblock
        • التكلفة الإجمالية للخدمة

      • list
        • النوع : تكلفة الإصلاح

        • النوع : رسوم الخدمة

        • النوع : قيمة الضريبة

        • النوع : التكلفة الإجمالية

      الاشعارات

      العنوان : تفاصيل التكلفة الإجمالية
      الرسالة : تم حساب التكلفة الإجمالية بما في ذلك كافة الرسوم والضرائب
      عن طريق : الاشعارات داخل التطبيق  المستقبل : العميل

      3.23 - إتمام التعاقد

      3.23.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • تأكيد حجز الخدمة وتجميد الرسوم المطلوبة للخدمة في حساب طالب الخدمة لضمان تنفيذ الخدمة وسداد الرسوم
      الجهات المعنية
      • العميل (طالب الخدمة)
      • مزود الخدمة (الورشة الفنية)
      الخطوات الرئيسية
      • عبور العميل لمرحلة القبول النهائي للصفقة عبر التطبيق
      • التحقق من متطلبات الصفقة من حيث الرسوم والخدمات المطلوبة
      • التحقق من متطلبات الدفع، بما في ذلك توافر المبلغ في المحفظة
      • في حالة عدم توافر المبلغ، يتم اتمام خطوات الدفع الالكتروني لتعبئة المحفظة والاستمرار في العملية
      • إرسال كود تأكيد للحجز على المبلغ وتجميده ضمن حساب طالب الخدمة
      الخطوات البديلة
      • في حالة عدم توافر المبلغ لدى طالب الخدمة يتم إيقاف العملية حتى يتم تزويد الحساب بالمبلغ المطلوب
      • قبل انتهاء الزمن المحدد للاستجابة، يمكن لطالب الخدمة أو للورشة الفنية طلب الإلغاء وبعدها يتم الرجوع للخطوات السابقة
      قصص المستخدمين
      • كعميل: أود إعطاء تأكيد نهائي للصفقة، لضمان حجز الخدمة وتأمين الرسوم المتفق عليها بأمان
      • كعميل: إذا كان المبلغ الكافي غير متوفر في محفظتي، أريد إضافة المبلغ المطلوب عبر وسائل الدفع الإلكترونية المتاحة لي
      • كعميل: أريد ضمان إمكانية الإلغاء في حالة عدم استجابة الورشة الفنية في الوقت المحدد أو في حالة تغيير رأيي في الخدمة المطلوبة
      مؤشرات الأداء
      • عدد الطلبات التي تم إتمام التعاقد عليها ونسبتها للاجمالي الطلبات التي تم الاستجابة لها

      3.23.2 حالات الاستخدام

      3.23.2.1- عبور العميل لمرحلة القبول النهائي للصفقة عبر التطبيق

      graph LR; A[اختيار العرض] --> B[عرض ملخص الصفقة] --> C[تأكيد القبول] --> D[تحديث حالة الصفقة]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • يجب أن يكون العميل قد اختار عرضًا محددًا من الورشة الفنية
      • يجب أن تكون معلومات الصفقة متاحة
      الشروط اللاحقة
      • يتم الانتقال إلى مرحلة التحقق من متطلبات الصفقة
      • يتم تحديث حالة الصفقة في النظام
      تسلسل الأحداث
      • اختيار العرض
      • عرض ملخص الصفقة
      • تأكيد القبول
      المدخلاتمعلومات الصفقة | اختيار العميل للعرض |
      المخرجات
      • تأكيد القبول
      • تحديث حالة الصفقة
      تفاعلات المستخدم
      • العميل
      سيناريوهات الاستخدام
      • اختيار العميل للعرض وقبوله عبر التطبيق
      متطلبات الأمان
      • تأكيد القبول من خلال إجراءات الأمان مثل كلمة المرور أو OTP
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام المحفظة الإلكترونية
      القيود والافتراضات
      • يجب أن يكون العميل مسجلًا في النظام ولديه محفظة إلكترونية مفعّلة
      متطلبات الاختبار
      • اختبار قبول الصفقة
      • اختبار إجراءات الأمان
      تفاصيل ال API
      Method: POST || Endpoint: /api/accept-deal
      Request Headers
      Authorization: Bearer token

      Request Body

      deal_id: نص client_id: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة قبول الصفقة

      • textblock
        • ملخص الصفقة

      • form
        • Button
          • العنوان : قبول الصفقة
          • الخيارات : handleAcceptDeal
      الاشعارات

      العنوان : تأكيد قبول الصفقة
      الرسالة : تم قبول الصفقة بنجاح
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.23.2.2- التحقق من متطلبات الصفقة من حيث الرسوم والخدمات المطلوبة

      graph LR; A[قبول الصفقة] --> B[استعراض تفاصيل الرسوم] --> C[استعراض تفاصيل الخدمات] --> D[عرض ملخص التكاليف النهائية]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • تم قبول الصفقة من قبل العميل
      • البيانات المطلوبة للرسوم والخدمات متوفرة في النظام
      الشروط اللاحقة
      • يتم عرض تفاصيل الرسوم والخدمات للعميل
      • يتم الانتقال إلى مرحلة التحقق من متطلبات الدفع
      تسلسل الأحداث
      • استعراض تفاصيل الرسوم
      • استعراض تفاصيل الخدمات
      • عرض ملخص التكاليف النهائية
      المدخلاتالبيانات المطلوبة للرسوم والخدمات |
      المخرجات
      • عرض تفاصيل الرسوم والخدمات
      • عرض ملخص التكاليف
      تفاعلات المستخدم
      • العميل
      سيناريوهات الاستخدام
      • تحقق النظام من الرسوم والخدمات المطلوبة بعد قبول الصفقة من العميل
      متطلبات الأمان
      • التحقق من صحة البيانات قبل عرضها للعميل
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام المحفظة الإلكترونية
      القيود والافتراضات
      • يجب أن تكون البيانات متاحة في النظام عند قبول الصفقة
      متطلبات الاختبار
      • اختبار التحقق من الرسوم
      • اختبار التحقق من الخدمات
      تفاصيل ال API
      Method: GET || Endpoint: /api/deal-details
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200fees: array services: array
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تفاصيل الصفقة

      • textblock
        • تفاصيل الرسوم والخدمات

      • form
        • Button
          • العنوان : عرض التكاليف النهائية
          • الخيارات : showFinalCosts
      الاشعارات

      العنوان : تفاصيل الصفقة
      الرسالة : تم استعراض تفاصيل الصفقة بنجاح
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.23.2.3- التحقق من متطلبات الدفع، بما في ذلك توافر المبلغ في المحفظة لضمان إمكانية إتمام الصفقة

      graph LR A[تحقق من رصيد المحفظة] --> B{هل الرصيد كافي؟} B -->|نعم| C[إرسال كود التأكيد] B -->|لا| D[عرض خيارات الدفع لتعبئة المحفظة]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • تم التحقق من تفاصيل الصفقة بنجاح
      • يجب أن تكون المحفظة الإلكترونية للعميل مفعّلة
      الشروط اللاحقة
      • تم التأكد من توفر المبلغ المطلوب في المحفظة
      • الانتقال إلى مرحلة إرسال كود التأكيد
      تفاصيل ال API
      Method: POST || Endpoint: /api/verify-wallet-balance
      Request Headers
      Authorization: Bearer token

      Request Body

      client_id: نص transaction_amount: float

      Response

      الحالةالمحتوى
      200status: نص is_balance_sufficient: boolean
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة التحقق من الدفع

      • textblock
        • تحقق من رصيد المحفظة

      • form
        • text
          • العنوان : مبلغ الصفقة
          • التحقق : required: 1 minValue: 1
      • رسالة زر الإرسال: تحقق
      • رسالة النجاح: تم التحقق من الرصيد بنجاح
      • إعادة توجيه النجاح: شاشة رمز التأكيد
      الاشعارات

      العنوان : التحقق من رصيد المحفظة
      الرسالة : تم التحقق من رصيد المحفظة، يمكنك الآن إتمام الصفقة
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : client

      3.23.2.4- في حالة عدم توافر المبلغ، يتم اتمام خطوات الدفع الالكتروني لتعبئة المحفظة والاستمرار في العملية

      graph LR A[تحقق من رصيد المحفظة] --> B{هل الرصيد كافي؟} B -->|لا| C[اختيار وسيلة الدفع الإلكتروني] C --> D[إدخال تفاصيل الدفع] D --> E[تحقق النظام من نجاح العملية] E -->|نجاح| F[إرسال كود التأكيد] E -->|فشل| G[عرض رسالة خطأ]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • التحقق من رصيد المحفظة أظهر عدم كفاية المبلغ
      • العميل يرغب في الاستمرار في الصفقة
      الشروط اللاحقة
      • يتم تعبئة المحفظة بالمبلغ المطلوب
      • الانتقال إلى مرحلة إرسال كود التأكيد
      تفاصيل ال API
      Method: POST || Endpoint: /api/add-funds
      Request Headers
      Authorization: Bearer token

      Request Body

      client_id: نص amount: float payment_method: نص

      Response

      الحالةالمحتوى
      200status: نص transaction_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة إضافة الأموال

      • textblock
        • تعبئة المحفظة

      • form
        • text
          • العنوان : المبلغ المطلوب
          • التحقق : required: 1 minValue: 1
        • select
          • العنوان : طريقة الدفع
          • التحقق : required: 1
          • الخيارات : ["بطاقة ائتمان","تحويل بنكي"]
      • رسالة زر الإرسال: تأكيد
      • رسالة النجاح: تمت تعبئة المحفظة بنجاح
      • إعادة توجيه النجاح: شاشة رمز التأكيد
      الاشعارات

      العنوان : تعبئة المحفظة
      الرسالة : تمت تعبئة محفظتك بنجاح، يمكنك الآن إتمام الصفقة
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : client

      3.23.2.5- إرسال كود تأكيد للحجز على المبلغ وتجميده ضمن حساب طالب الخدمة

      graph LR A[تحقق من رصيد المحفظة] --> B[توليد كود التأكيد] B --> C[إرسال كود التأكيد] C --> D[إدخال كود التأكيد] D --> E[التحقق من صحة الكود] E -->|صحيح| F[تأكيد الحجز وتجميد المبلغ] E -->|غير صحيح| G[عرض رسالة خطأ]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • تم التأكد من توفر المبلغ المطلوب في المحفظة
      • العميل أكد رغبته في إتمام الصفقة
      الشروط اللاحقة
      • يتم تجميد المبلغ في حساب المحفظة
      • يتم إرسال كود التأكيد للعميل
      تفاصيل ال API
      Method: POST || Endpoint: /api/send-confirmation-code
      Request Headers
      Authorization: Bearer token

      Request Body

      client_id: نص transaction_id: نص

      Response

      الحالةالمحتوى
      200status: نص confirmation_code: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة رمز التأكيد

      • textblock
        • أدخل كود التأكيد لإتمام الحجز

      • form
        • text
          • العنوان : كود التأكيد
          • التحقق : required: 1 pattern: ^[0-9]{6}$
      • رسالة زر الإرسال: تأكيد
      • رسالة النجاح: تم تأكيد الحجز بنجاح
      • إعادة توجيه النجاح: Booking Confirmation Screen
      الاشعارات

      العنوان : كود تأكيد الحجز
      الرسالة : تم إرسال كود التأكيد لحجز المبلغ. يرجى إدخال الكود لإتمام العملية
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : client

      3.24 - مباشرة الحالة

      3.24.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • تأكيد بدء الخدمة بين العميل ومزود الخدمة وضمان انتقال سلس وآمن للعملية إلى المرحلة التالية
      الجهات المعنية
      • العميل (طالب الخدمة)
      • مزود الخدمة (الورشة الفنية)
      الخطوات الرئيسية
      • إعطاء (العميل) رمز تأكيد فريد يتولد بشكل تلقائي من قبل النظام
      • يقوم مزود الخدمة بطلب رمز التحقق من طالب الخدمة للتحقق من بداية الخدمة
      • التحقق من نجاح التفعيل ومباشرة الخدمة من خلال التطبيق برمز QR
      الخطوات البديلة
      • في حالة عدم التمكن من استخدام العميل للرمز، يمكنه الاتصال بخدمة العملاء للمساعدة
      • في حالة فقدان الرمز، يتم إنشاء رمز جديد
      قصص المستخدمين
      • كعميل: بمجرد تأكيد الصفقة، أريد تلقي رمز تأكيد فريد يمكنني من التحقق من بداية الخدمة
      • كعميل: إذا واجهت مشكلة في استخدام الرمز، أريد الاتصال بخدمة العملاء للمساعدة
      • كمقدم الخدمة: عند بداية الخدمة، أريد استخدام رمز التحقق المقدم من العميل لتأكيد بدء الخدمة
      مؤشرات الأداء
      • نسبة عدد الطلبات التي تم مباشرتها من إجمالي الطلبات التي تم التعاقد عليها

      3.24.2 حالات الاستخدام

      3.24.2.1- يقوم المستخدم بإرسال طلب تحديث إلى قاعدة البيانات لتعديل تفاصيل الحمولة

      graph LR A[Open Edit Page] --> B[Enter New Details] B --> C[Save Changes] C --> D[Success Message] C --> E[Error Handling]
      العنوانالتفاصيل
      المستخدمالمستخدم
      الشروط المسبقة
      • المستخدم مسجل الدخول إلى النظام
      • توافر تفاصيل الحمولة في النظام
      الشروط اللاحقة
      • تم تعديل تفاصيل الحمولة بنجاح في قاعدة البيانات
      تسلسل الأحداث
      • يقوم المستخدم بفتح صفحة تعديل تفاصيل الحمولة
      • يدخل المستخدم البيانات الجديدة
      • يضغط المستخدم على زر 'حفظ التعديلات'
      الخطوات البديلةإذا لم تكن البيانات المدخلة صحيحة أو مكتملة
      • عرض رسالة خطأ توضح البيانات الناقصة أو غير الصحيحة
      • إعادة المستخدم لتصحيح البيانات
      • النقر على زر 'حفظ التعديلات' مجددًا
      الخطوات الاستثنائيةفي حالة فشل الاتصال بقاعدة البيانات
      • عرض رسالة خطأ توضح مشكلة الاتصال
      • توجيه المستخدم للمحاولة مرة أخرى لاحقًا
      القواعد التجارية
      • يجب أن تكون جميع البيانات المدخلة صحيحة وموثقة
      الافتراضات
      • المستخدم يمتلك الصلاحيات اللازمة لتعديل تفاصيل الحمولة
      المتطلبات الخاصة
      • يجب أن يتم التحقق من صحة البيانات المدخلة قبل حفظها في النظام
      • توافر اتصال مستقر بقاعدة البيانات
      الملاحظات والمشاكل
      • إذا تكررت مشاكل الاتصال بقاعدة البيانات، يجب مراجعة إعدادات الخادم
      المدخلاتتفاصيل الحمولة الجديدة التي يرغب المستخدم في تعديلها |
      المخرجات
      • تأكيد أن التعديلات تم حفظها بنجاح في النظام
      تفاعلات المستخدم
      • فتح صفحة تعديل تفاصيل الحمولة
      • إدخال البيانات الجديدة
      • النقر على زر 'حفظ التعديلات'
      الشروط الخاصة
      • إذا كانت تفاصيل الحمولة تتطلب موافقة إدارية قبل تعديلها، يجب إشعار المستخدم بذلك
      سيناريوهات الاستخدام
      • كمستخدم، أريد تعديل تفاصيل الحمولة لضمان دقة المعلومات المسجلة في النظام
      • كمسؤول، أحتاج إلى مراجعة التعديلات وإعطاء الموافقة النهائية على التغييرات
      متطلبات الأمان
      • يجب أن يكون التعديل مسموحًا فقط للمستخدمين الذين يمتلكون الصلاحيات اللازمة
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام التحقق من البيانات لضمان صحة المعلومات المدخلة
      القيود والافتراضات
      • يجب أن يكون الاتصال بقاعدة البيانات مستقرًا
      • يجب أن تكون البيانات المدخلة مكتملة وصحيحة
      متطلبات الاختبار
      • اختبار دقة التعديلات المدخلة وحفظها في النظام
      • اختبار حالات الخطأ المحتملة مثل مشاكل الاتصال
      تفاصيل ال API
      Method: PUT || Endpoint: /api/haulage/details/update
      Request Headers
      Authorization: Bearer token

      Request Body

      haulage_id: نص new_details: object

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تعديل تفاصيل النقل

      • form
        • text
          • العنوان : معرف النقل
          • التحقق : {"required":true,"error_message":"معرف النقل مطلوب"}
        • textarea
          • العنوان : تفاصيل جديدة
          • التحقق : {"required":true,"error_message":"التفاصيل الجديدة مطلوبة"}
      • رسالة زر الإرسال: Save Changes
      • رسالة النجاح: تم تحديث التفاصيل بنجاح
      • إعادة توجيه النجاح: HaulageDetails
      الاشعارات

      العنوان : تم تحديث تفاصيل النقل
      الرسالة : تم تحديث تفاصيل النقل الخاصة بك بنجاح
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : user

      3.24.2.2- يقوم مزود الخدمة بطلب رمز التحقق من طالب الخدمة للتحقق من بداية الخدمة

      graph LR A[Request Confirmation Code] --> B[Enter Code] B --> C[Validate Code] C --> D[Success Message] C --> E[Error Handling]
      العنوانالتفاصيل
      المستخدممزود الخدمة
      الشروط المسبقة
      • تسلم مزود الخدمة رمز التأكيد من العميل
      الشروط اللاحقة
      • التأكد من صلاحية رمز التأكيد
      تسلسل الأحداث
      • يقوم مزود الخدمة بطلب رمز التأكيد من العميل
      • يدخل مزود الخدمة الرمز في النظام للتحقق من صلاحيته
      الخطوات البديلةإذا لم يكن الرمز صحيحًا
      • عرض رسالة خطأ توضح عدم صحة الرمز
      • طلب إعادة إرسال الرمز من العميل
      الخطوات الاستثنائيةفي حالة فشل الاتصال بالنظام
      • عرض رسالة خطأ توضح مشكلة الاتصال
      • توجيه مزود الخدمة للمحاولة مرة أخرى لاحقًا
      القواعد التجارية
      • يجب أن يكون رمز التأكيد فريدًا وصالحًا
      الافتراضات
      • مزود الخدمة يمتلك الصلاحيات اللازمة للوصول إلى النظام
      المتطلبات الخاصة
      • يجب أن يتم التحقق من صحة رمز التأكيد قبل بدء الخدمة
      • توافر اتصال مستقر بالنظام
      الملاحظات والمشاكل
      • إذا تكررت مشاكل الاتصال بالنظام، يجب مراجعة إعدادات الخادم
      المدخلاترمز التأكيد الذي يقدمه العميل |
      المخرجات
      • تأكيد صحة رمز التأكيد من النظام
      تفاعلات المستخدم
      • طلب رمز التأكيد من العميل
      • إدخال الرمز في النظام
      الشروط الخاصة
      • إذا كان رمز التأكيد غير صحيح، يجب طلب إعادة إرسال الرمز من العميل
      سيناريوهات الاستخدام
      • كمزود خدمة، أريد التحقق من صحة رمز التأكيد المقدم من العميل لضمان بدء الخدمة بشكل صحيح
      • كمزود خدمة، أحتاج إلى طريقة للتحقق من صلاحية رمز التأكيد قبل بدء العمل
      متطلبات الأمان
      • يجب أن يكون رمز التأكيد محميًا بشكل جيد لمنع التزوير
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة الرموز لضمان صحة رمز التأكيد
      القيود والافتراضات
      • يجب أن يكون الاتصال بالنظام مستقرًا
      • يجب أن يكون رمز التأكيد صالحًا
      متطلبات الاختبار
      • اختبار صحة التحقق من الرموز المدخلة
      • اختبار حالات الخطأ المحتملة مثل مشاكل الاتصال
      تفاصيل ال API
      Method: POST || Endpoint: /api/verification/confirm
      Request Headers
      Authorization: Bearer token

      Request Body

      confirmation_code: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تأكيد الخدمة

      • form
        • text
          • العنوان : رمز التأكيد
          • التحقق : {"required":true,"error_message":"رمز التأكيد مطلوب"}
      • رسالة زر الإرسال: تأكيد
      • رسالة النجاح: تم تأكيد الخدمة بنجاح
      • إعادة توجيه النجاح: تفاصيل الخدمة
      الاشعارات

      العنوان : تأكيد الخدمة
      الرسالة : يرجى تأكيد الخدمة بإدخال رمز التأكيد المقدم
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : service_provider

      3.24.2.3- التحقق من نجاح التفعيل ومباشرة الخدمة من خلال التطبيق برمز QR

      graph LR A[Enter Confirmation Code] --> B[Validate Code] B --> C[Activate Service] C --> D[Update Service Status] C --> E[Error Handling]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • إدخال مزود الخدمة رمز التأكيد الصحيح
      الشروط اللاحقة
      • بدء الخدمة بنجاح وتحديث حالة الطلب
      تسلسل الأحداث
      • يقوم مزود الخدمة بإدخال رمز التأكيد في النظام
      • النظام يتحقق من صحة الرمز
      • في حالة صحة الرمز، يتم تفعيل الخدمة وتحديث حالة الطلب
      الخطوات البديلةإذا لم يكن رمز التأكيد صحيحًا
      • عرض رسالة خطأ توضح عدم صحة الرمز
      • طلب إعادة إدخال الرمز
      الخطوات الاستثنائيةفي حالة فشل التحقق من الرمز بسبب مشكلة في النظام
      • عرض رسالة خطأ توضح وجود مشكلة فنية
      • توجيه مزود الخدمة للمحاولة مرة أخرى لاحقًا
      القواعد التجارية
      • يجب أن يكون رمز التأكيد فريدًا وصالحًا
      الافتراضات
      • النظام قادر على التحقق من الرموز بشكل صحيح
      المتطلبات الخاصة
      • يجب أن يتم التحقق من صحة رمز التأكيد قبل بدء الخدمة
      • توافر اتصال مستقر بالنظام
      الملاحظات والمشاكل
      • إذا تكررت مشاكل التحقق من الرموز، يجب مراجعة إعدادات النظام
      المدخلاترمز التأكيد الذي يقدمه مزود الخدمة |
      المخرجات
      • تأكيد بدء الخدمة وتحديث حالة الطلب
      تفاعلات المستخدم
      • إدخال رمز التأكيد في النظام
      • تلقي تأكيد بدء الخدمة من النظام
      الشروط الخاصة
      • إذا كان رمز التأكيد غير صحيح، يجب طلب إعادة إدخال الرمز
      سيناريوهات الاستخدام
      • كمزود خدمة، أريد التحقق من صحة رمز التأكيد لضمان بدء الخدمة بشكل صحيح
      • كمزود خدمة، أحتاج إلى طريقة للتحقق من صلاحية رمز التأكيد قبل بدء العمل
      متطلبات الأمان
      • يجب أن يكون رمز التأكيد محميًا بشكل جيد لمنع التزوير
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة الرموز لضمان صحة رمز التأكيد
      القيود والافتراضات
      • يجب أن يكون الاتصال بالنظام مستقرًا
      • يجب أن يكون رمز التأكيد صالحًا
      متطلبات الاختبار
      • اختبار صحة التحقق من الرموز المدخلة
      • اختبار حالات الخطأ المحتملة مثل مشاكل الاتصال
      تفاصيل ال API
      Method: POST || Endpoint: /api/verification/validate
      Request Headers
      Authorization: Bearer token

      Request Body

      confirmation_code: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تفعيل الخدمة

      • form
        • text
          • العنوان : رمز التأكيد
          • التحقق : {"required":true,"error_message":"رمز التأكيد مطلوب"}
      • رسالة زر الإرسال: Activate Service
      • رسالة النجاح: تم تفعيل الخدمة بنجاح
      • إعادة توجيه النجاح: تفاصيل الخدمة
      الاشعارات

      العنوان : تفعيل الخدمة
      الرسالة : تم تفعيل الخدمة بنجاح
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : service_provider

      3.24.2.4- في حالة عدم التمكن من استخدام العميل للرمز، يمكنه الاتصال بخدمة العملاء للمساعدة

      graph LR A[Failed to Use Code] --> B[Contact Customer Support] B --> C[Verify Issue] C --> D[Generate New Code] C --> E[Provide Solution]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • تأكيد الصفقة وفشل استخدام رمز التأكيد
      الشروط اللاحقة
      • الحصول على مساعدة من خدمة العملاء أو رمز تأكيد جديد
      تسلسل الأحداث
      • يتصل العميل بخدمة العملاء
      • يشرح العميل مشكلة فشل استخدام الرمز
      • تتحقق خدمة العملاء من المشكلة
      • تقدم خدمة العملاء حلاً مناسبًا مثل توليد رمز جديد
      الخطوات الاستثنائيةفي حالة عدم تمكن خدمة العملاء من توليد رمز جديد فورًا
      • إبلاغ العميل بضرورة المحاولة لاحقًا
      • تحديد موعد لمعاودة الاتصال بخدمة العملاء
      القواعد التجارية
      • يجب أن يتلقى العميل الدعم الفني بسرعة وفعالية
      الافتراضات
      • خدمة العملاء متاحة على مدار الساعة
      المتطلبات الخاصة
      • يجب أن يكون الاتصال بخدمة العملاء مجانيًا وسهل الوصول إليه
      • يجب أن يكون هناك بروتوكول محدد للتعامل مع حالات فشل الرموز
      الملاحظات والمشاكل
      • تكرار مشاكل استخدام الرموز قد يشير إلى حاجة النظام لتحديث أو تحسين
      المدخلاتتفاصيل الصفقة | الرمز الفاشل |
      المخرجات
      • حل المشكلة وتقديم رمز جديد إذا لزم الأمر
      تفاعلات المستخدم
      • الاتصال بخدمة العملاء
      • تقديم تفاصيل المشكلة
      • تلقي الحل من خدمة العملاء
      الشروط الخاصة
      • إذا كان النظام غير متاح، يجب على خدمة العملاء تحديد موعد لاحق لحل المشكلة
      سيناريوهات الاستخدام
      • كعميل، أريد أن أحصل على دعم سريع عند فشل استخدام رمز التأكيد لضمان استمرار الخدمة
      • كخدمة عملاء، أريد أن أتمكن من توليد رموز جديدة بسرعة عند الحاجة لضمان رضا العملاء
      متطلبات الأمان
      • يجب حماية بيانات العميل أثناء التفاعل مع خدمة العملاء
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام توليد الرموز لضمان إمكانية توليد رمز جديد بسرعة
      القيود والافتراضات
      • يجب أن تكون خدمة العملاء مدربة على التعامل مع مثل هذه الحالات
      • يجب أن يكون النظام قادرًا على توليد رموز جديدة بسرعة
      متطلبات الاختبار
      • اختبار فعالية وسرعة توليد الرموز الجديدة
      • اختبار استجابة خدمة العملاء
      تفاصيل ال API
      Method: POST || Endpoint: /api/customer-support/generate-new-code
      Request Headers
      Authorization: Bearer token

      Request Body

      transaction_details: object failed_code: نص

      Response

      الحالةالمحتوى
      200new_code: نص status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      دعم العملاء

      • form
        • text
          • العنوان : تفاصيل المعاملة
          • التحقق : {"required":true,"error_message":"تفاصيل المعاملة مطلوبة"}
        • text
          • العنوان : رمز الفشل
          • التحقق : {"required":true,"error_message":"رمز الفشل مطلوب"}
      • رسالة زر الإرسال: إرسال
      • رسالة النجاح: تم تقديم طلب الدعم بنجاح
      • إعادة توجيه النجاح: SupportConfirmation
      الاشعارات

      العنوان : طلب الدعم
      الرسالة : تم تقديم طلب الدعم الخاص بك بنجاح. سنقوم بالرد عليك قريبًا
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : customer

      3.24.2.5- في حالة فقدان الرمز، يتم إنشاء رمز جديد

      graph LR A[Report Code Loss] --> B[Generate New Code] B --> C[Send New Code] C --> D[Customer Receives New Code] B --> E[Error Handling]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • إبلاغ العميل عن فقدان الرمز
      الشروط اللاحقة
      • توليد رمز تأكيد جديد وإرساله إلى العميل
      تسلسل الأحداث
      • يقوم العميل بالإبلاغ عن فقدان الرمز
      • يتلقى النظام الطلب ويولد رمزًا جديدًا
      • يتم إرسال الرمز الجديد إلى العميل
      الخطوات الاستثنائيةفي حالة فشل النظام في توليد الرمز
      • عرض رسالة خطأ توضح المشكلة
      • توجيه العميل للمحاولة مرة أخرى لاحقًا
      القواعد التجارية
      • يجب أن يتم توليد رمز جديد فريد لكل طلب
      الافتراضات
      • النظام قادر على توليد الرموز بشكل صحيح
      المتطلبات الخاصة
      • يجب أن يكون توليد الرمز سريعًا وفعالاً
      • يجب أن يصل الرمز الجديد إلى العميل عبر وسيلة موثوقة
      الملاحظات والمشاكل
      • إذا تكررت مشاكل فقدان الرموز، يجب مراجعة عملية توليد وإدارة الرموز
      المدخلاتتفاصيل طلب العميل لإنشاء رمز جديد |
      المخرجات
      • رمز التأكيد الجديد الذي يتم إرساله إلى العميل
      تفاعلات المستخدم
      • الإبلاغ عن فقدان الرمز عبر التطبيق
      • تلقي الرمز الجديد
      الشروط الخاصة
      • إذا كان النظام غير قادر على توليد الرمز فورًا، يجب إبلاغ العميل بالمحاولة لاحقًا
      سيناريوهات الاستخدام
      • كعميل، أريد الحصول على رمز تأكيد جديد بسرعة إذا فقدت الرمز السابق لضمان استمرار الخدمة
      • كنظام، أريد توليد رمز تأكيد جديد فور طلب العميل لضمان تقديم خدمة فعالة
      متطلبات الأمان
      • يجب حماية عملية توليد وإرسال الرموز لمنع التزوير
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام الرسائل النصية أو إشعارات التطبيق لضمان وصول الرمز الجديد إلى العميل
      القيود والافتراضات
      • يجب أن يكون النظام قادرًا على توليد الرموز بشكل مستمر
      • يجب أن يكون الاتصال بالنظام مستقرًا
      متطلبات الاختبار
      • اختبار فعالية وسرعة توليد الرموز الجديدة
      • اختبار استجابة النظام لطلبات العملاء
      تفاصيل ال API
      Method: POST || Endpoint: /api/confirmation-code/generate
      Request Headers
      Authorization: Bearer token

      Request Body

      request_details: object

      Response

      الحالةالمحتوى
      200new_code: نص status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      طلب رمز جديد

      • form
        • text
          • العنوان : تفاصيل الطلب
          • التحقق : {"required":true,"error_message":"تفاصيل الطلب مطلوبة"}
      • رسالة زر الإرسال: إرسال
      • رسالة النجاح: تم توليد رمز جديد بنجاح
      • إعادة توجيه النجاح: ConfirmationCode
      الاشعارات

      العنوان : رمز تأكيد جديد
      الرسالة : تم توليد رمز تأكيد جديد وإرساله إليك
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : customer

      3.25 - إنهاء الخدمة الفنية

      3.25.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • تأكيد انتهاء تقديم الخدمة من قبل الورشة الفنية وضمان تحصيل المبلغ المستحق بشكل صحيح
      الجهات المعنية
      • العميل (طالب الخدمة)
      • مزود الخدمة (الورشة الفنية)
      الخطوات الرئيسية
      • إعطاء مزود الخدمة (الورشة الفنية) القدرة على إدخال ملخص الإصلاح (اختياري)
      • السماح لمزود الخدمة بعرض المبلغ المستحق أو التعديل عليه (بالتقليل فقط في حالة عدم الاتفاق)
      • تأكيد العملية من طالب الخدمة من خلال استخدام كود أو رسالة استجابة
      الخطوات البديلة
      • في حالة عدم الاتفاق على المبلغ المطلوب، يمكن للعميل الاتصال بخدمة العملاء للمساعدة
      قصص المستخدمين
      • كمقدم الخدمة: بعد الانتهاء من تقديم الخدمة، أريد إدخال ملخص الإصلاح والمبلغ المطلوب بشكل سهل ومباشر
      • كعميل: بعد استلام ملخص الإصلاح والمبلغ المطلوب، أريد قابلية التأكيد على المبلغ المطلوب أو طلب مراجعته
      مؤشرات الأداء
      • نسبة عدد الطلبات المنتهية من إجمالي الطلبات التي تمت مباشرتها

      3.25.2 حالات الاستخدام

      3.25.2.1- إعطاء مزود الخدمة (الورشة الفنية) القدرة على إدخال ملخص الإصلاح (اختياري)

      graph LR; A[Service Completed] --> B[Submit Service Summary]; B --> C[Review and Confirm]; C --> D[Summary Submitted];
      العنوانالتفاصيل
      المستخدممزود الخدمة
      الشروط المسبقة
      • انتهاء تقديم الخدمة الفنية
      الشروط اللاحقة
      • إدخال ملخص الإصلاح في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /api/service-summary
      Request Headers
      Authorization: Bearer token

      Request Body

      service_id: integer summary: نص cost: decimal

      Response

      الحالةالمحتوى
      200status: نص message: تم تقديم ملخص الخدمة بنجاح
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة ملخص الخدمة

      • form
        • text
          • العنوان : معرف الخدمة
        • textarea
          • العنوان : الملخص
        • text
          • العنوان : التكلفة
      • رسالة زر الإرسال: Submit Summary
      الاشعارات

      العنوان : تم تقديم ملخص الخدمة
      الرسالة : تم تقديم ملخص الخدمة الخاص بك بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : service provider

      3.25.2.2- السماح لمزود الخدمة بعرض المبلغ المستحق أو التعديل عليه (بالتقليل فقط في حالة عدم الاتفاق)

      graph LR; A[Service Summary Submitted] --> B[Submit Service Charge]; B --> C[Modify Charge if Needed]; C --> D[Charge Submitted];
      العنوانالتفاصيل
      المستخدممزود الخدمة
      الشروط المسبقة
      • إدخال ملخص الإصلاح
      الشروط اللاحقة
      • عرض المبلغ المستحق على العميل
      تفاصيل ال API
      Method: POST || Endpoint: /api/service-charge
      Request Headers
      Authorization: Bearer token

      Request Body

      service_id: integer charge_amount: decimal

      Response

      الحالةالمحتوى
      200status: نص message: تم تقديم رسوم الخدمة بنجاح
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة رسوم الخدمة

      • form
        • text
          • العنوان : معرف الخدمة
        • text
          • العنوان : مبلغ الرسوم
      • رسالة زر الإرسال: Submit Charge
      الاشعارات

      العنوان : تم تقديم رسوم الخدمة
      الرسالة : تم تقديم رسوم الخدمة الخاصة بك بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : service provider

      3.25.2.3- تأكيد العملية من طالب الخدمة من خلال استخدام كود أو رسالة استجابة

      graph LR; A[Service Charge Displayed] --> B[User Confirms or Requests Review]; B --> C[Confirmation Processed]; C --> D[Charge Confirmed];
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • عرض المبلغ المستحق من قبل مزود الخدمة
      الشروط اللاحقة
      • تأكيد أو طلب مراجعة المبلغ من قبل طالب الخدمة
      تفاصيل ال API
      Method: POST || Endpoint: /api/service-confirmation
      Request Headers
      Authorization: Bearer token

      Request Body

      service_id: integer confirmation_code: نص

      Response

      الحالةالمحتوى
      200status: نص message: تم تأكيد رسوم الخدمة بنجاح
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تأكيد الخدمة

      • form
        • text
          • العنوان : معرف الخدمة
        • text
          • العنوان : رمز التأكيد
      • رسالة زر الإرسال: Confirm Charge
      الاشعارات

      العنوان : تم تأكيد رسوم الخدمة
      الرسالة : تم تأكيد رسوم الخدمة الخاصة بك بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : service user

      3.25.2.4- في حالة عدم الاتفاق على المبلغ المطلوب، يمكن للعميل الاتصال بخدمة العملاء للمساعدة

      graph LR; A[Disagreement on Amount] --> B[Contact Customer Support]; B --> C[Customer Support Intervention]; C --> D[Dispute Resolved];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • عدم الاتفاق على المبلغ المطلوب
      الشروط اللاحقة
      • الحصول على مساعدة من خدمة العملاء
      تفاصيل ال API
      Method: POST || Endpoint: /api/customer-support
      Request Headers
      Authorization: Bearer token

      Request Body

      service_id: integer dispute_details: نص

      Response

      الحالةالمحتوى
      200status: نص message: تم تقديم طلب دعم العملاء بنجاح
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة دعم العملاء

      • form
        • text
          • العنوان : معرف الخدمة
        • textarea
          • العنوان : تفاصيل النزاع
      • رسالة زر الإرسال: Submit Dispute
      الاشعارات

      العنوان : تم تقديم طلب دعم العملاء
      الرسالة : تم تقديم طلب دعم العملاء الخاص بك بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : customer

      3.26 - إغلاق الخدمة الفنية

      3.26.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • ضمان توزيع الأموال المستحقة بشكل صحيح بين الأطراف المعنية (الورشة الفنية، المنصة، الضرائب) عند إغلاق الخدمة الفنية
      الجهات المعنية
      • العميل (طالب الخدمة)
      • مزود الخدمة (الورشة الفنية)
      • المنصة (التطبيق)
      الخطوات الرئيسية
      • خصم المبلغ الإجمالي من حساب المحفظة لطالب الخدمة
      • تحويل أجرة الإصلاح إلى حساب المحفظة الإلكترونية للورشة الفنية
      • تحويل رسوم الخدمة إلى حساب التطبيق تحت مسمى رسوم خدمات مساندة
      • تحويل ضريبة القيمة المضافة إلى حساب الضريبة في التطبيق
      الخطوات البديلة
      قصص المستخدمين
      • كعميل: بعد الموافقة على المبلغ المطلوب، أريد أن يتم خصم المبلغ من محفظتي وتحويله بشكل صحيح دون أي تدخل مني
      • كمزود الخدمة: بعد تقديم الخدمة وتأكيد العميل، أريد تلقي أجرة الإصلاح بشكل مباشر وسهل في محفظتي على التطبيق
      • كإداري للمنصة: أريد تلقي رسوم الخدمة المستحقة وتوزيع الأموال المستحقة بشكل آلي وصحيح على الأطراف المعنية
      مؤشرات الأداء
      • عدد الطلبات المغلقة ونسبتها للطلبات التي تم الانتهاء منها
      • إجمالي تكاليف الخدمة وتفصيلها (رسوم الخدمة والضريبة)

      3.26.2 حالات الاستخدام

      3.26.2.1- خصم المبلغ الإجمالي من حساب المحفظة لطالب الخدمة بعد اكتمال الخدمات الفنية المقدمة. يخصم النظام أجرة الإصلاح، رسوم الخدمة، وضريبة القيمة المضافة دفعة واحدة

      graph LR A[طلب الخدمة الفنية] --> B[مزود الخدمة ينفذ العمل] B --> C[النظام يتحقق من اكتمال العمل] C --> D[النظام يخصم المبلغ الإجمالي] D --> E[تحويل الأموال إلى الحسابات المعنية] E --> F[إشعار طالب الخدمة]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • استخدام طالب الخدمة لخدمات فنية وإتمام العمل المطلوب
      • تواجد مبلغ كافي في محفظة طالب الخدمة لتغطية التكلفة
      الشروط اللاحقة
      • خصم المبلغ الإجمالي من محفظة طالب الخدمة
      • تحويل أجرة الإصلاح إلى حساب الورشة الفنية
      • تحويل رسوم الخدمة إلى حساب التطبيق
      • تحويل ضريبة القيمة المضافة إلى حساب الضريبة في التطبيق
      تسلسل الأحداث
      • طالب الخدمة يطلب الخدمة الفنية
      • مزود الخدمة ينفذ العمل المطلوب
      • النظام يتحقق من اكتمال العمل ورضا طالب الخدمة
      • النظام يخصم المبلغ الإجمالي من محفظة طالب الخدمة
      • النظام يحول المبالغ المستحقة إلى الجهات المعنية
      القواعد التجارية
      • يجب أن يتم خصم المبلغ الإجمالي فقط بعد إتمام الخدمات الفنية والتأكد من رضا طالب الخدمة
      الافتراضات
      • طالب الخدمة لديه مبلغ كافي في محفظته
      • النظام قادر على التعامل مع العمليات المالية بشكل صحيح وموثوق
      المتطلبات الخاصة
      • التأكد من حماية البيانات المالية لطالب الخدمة
      • توثيق جميع المعاملات المالية في سجلات التطبيق
      الملاحظات والمشاكل
      • إذا لم يكن هناك رصيد كافٍ في محفظة طالب الخدمة، يجب إشعاره بذلك وإعطاؤه فرصة لإضافة رصيد
      المدخلاتطلب الخدمة الفنية | تأكيد اكتمال العمل | تفاصيل الفواتير المالية |
      المخرجات
      • خصم المبلغ الإجمالي من محفظة طالب الخدمة
      • تحويل الأموال إلى الحسابات المعنية
      تفاعلات المستخدم
      • طالب الخدمة يتلقى إشعاراً بخصم المبلغ من محفظته
      سيناريوهات الاستخدام
      • استخدام الحالة عند إتمام أي خدمة فنية وخصم المبلغ الإجمالي بشكل تلقائي
      متطلبات الأمان
      • حماية البيانات المالية للمستخدمين باستخدام تقنيات التشفير
      • ضمان عدم وجود عمليات خصم غير مصرح بها
      التكامل مع الأنظمة الأخرى
      • النظام المالي الداخلي للتطبيق
      • خدمات الدفع الإلكترونية المرتبطة
      القيود والافتراضات
      • يجب أن يكون النظام متكاملًا مع مزودي الدفع المعتمدين
      • الافتراض بأن جميع المستخدمين لديهم وصول إلى محفظاتهم الإلكترونية بشكل دائم
      متطلبات الاختبار
      • اختبار عملية الخصم والتأكد من تحويل الأموال بشكل صحيح
      • اختبار الحالات الاستثنائية عند عدم توفر رصيد كافٍ
      تفاصيل ال API
      Method: POST || Endpoint: /api/financial/close-service
      Request Headers
      Authorization: Bearer token

      Request Body

      service_id: نص amount: number

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة إغلاق الخدمة

      • textblock
        • يرجى التأكد من أن كافة المعلومات صحيحة قبل إغلاق الخدمة

      • form
        • Button
          • العنوان : إغلاق الخدمة
          • الخيارات : closeService
      الاشعارات

      العنوان : تم خصم المبلغ الإجمالي من محفظتك
      الرسالة : تم خصم المبلغ الإجمالي بنجاح وتحويل الأموال إلى الجهات المعنية
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : طالب الخدمة

      3.26.2.2- تحويل أجرة الإصلاح إلى حساب المحفظة الإلكترونية للورشة الفنية

      graph LR A[خصم المبلغ من محفظة طالب الخدمة] --> B[تحويل أجرة الإصلاح إلى محفظة الورشة الفنية] B --> C[إشعار ورشة الإصلاح بتحويل المبلغ]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • خصم المبلغ الإجمالي من حساب محفظة طالب الخدمة
      الشروط اللاحقة
      • تحويل أجرة الإصلاح إلى محفظة الورشة الفنية
      تسلسل الأحداث
      • خصم المبلغ الإجمالي من حساب محفظة طالب الخدمة
      • تحويل أجرة الإصلاح إلى حساب المحفظة الإلكترونية للورشة الفنية
      القواعد التجارية
      • يجب أن يتم تحويل أجرة الإصلاح بشكل صحيح إلى المحفظة الإلكترونية للورشة الفنية
      الافتراضات
      • النظام قادر على تحويل الأموال بشكل موثوق وآمن
      المتطلبات الخاصة
      • التأكد من حماية البيانات المالية أثناء عملية التحويل
      • توثيق جميع التحويلات المالية في سجلات التطبيق
      الملاحظات والمشاكل
      • إذا فشلت عملية التحويل، يجب على النظام إعادة المحاولة تلقائيًا وإشعار الإداري بالفشل
      المدخلاتتأكيد خصم المبلغ من محفظة طالب الخدمة |
      المخرجات
      • تحويل أجرة الإصلاح إلى محفظة الورشة الفنية
      تفاعلات المستخدم
      • ورشة الإصلاح تتلقى إشعاراً بتحويل أجرة الإصلاح إلى محفظتها
      سيناريوهات الاستخدام
      • استخدام الحالة عند إتمام أي خدمة فنية وتحويل أجرة الإصلاح بشكل تلقائي
      متطلبات الأمان
      • حماية بيانات التحويل المالي باستخدام تقنيات التشفير
      • ضمان عدم وجود عمليات تحويل غير مصرح بها
      التكامل مع الأنظمة الأخرى
      • النظام المالي الداخلي للتطبيق
      • خدمات الدفع الإلكترونية المرتبطة
      القيود والافتراضات
      • يجب أن يكون النظام متكاملًا مع مزودي الدفع المعتمدين
      • الافتراض بأن جميع المستخدمين لديهم وصول إلى محفظاتهم الإلكترونية بشكل دائم
      متطلبات الاختبار
      • اختبار عملية التحويل والتأكد من إتمامها بشكل صحيح
      • اختبار الحالات الاستثنائية عند فشل عملية التحويل
      تفاصيل ال API
      Method: POST || Endpoint: /api/financial/transfer-repair-fee
      Request Headers
      Authorization: Bearer token

      Request Body

      service_id: نص amount: number

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تحويل رسوم الإصلاح

      • textblock
        • يتم الآن تحويل أجرة الإصلاح إلى محفظة الورشة الفنية

      الاشعارات

      العنوان : تحويل أجرة الإصلاح
      الرسالة : تم تحويل أجرة الإصلاح إلى محفظتكم بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : ورشة الإصلاح

      3.26.2.3- تحويل رسوم الخدمة إلى حساب التطبيق تحت مسمى رسوم خدمات مساندة. يتم خصم رسوم الخدمة من محفظة طالب الخدمة وتحويلها إلى حساب التطبيق الخاص بخدمات المساندة

      graph LR A[خصم المبلغ من محفظة طالب الخدمة] --> B[تحويل رسوم الخدمة إلى حساب التطبيق] B --> C[إشعار الإداري بتحويل المبلغ]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • خصم المبلغ الإجمالي من حساب محفظة طالب الخدمة
      الشروط اللاحقة
      • تحويل رسوم الخدمة إلى حساب التطبيق
      تسلسل الأحداث
      • خصم المبلغ الإجمالي من حساب محفظة طالب الخدمة
      • تحويل رسوم الخدمة إلى حساب التطبيق تحت مسمى رسوم خدمات مساندة
      القواعد التجارية
      • يجب أن يتم تحويل رسوم الخدمة بشكل صحيح إلى حساب التطبيق الخاص بخدمات المساندة
      الافتراضات
      • النظام قادر على تحويل الأموال بشكل موثوق وآمن
      المتطلبات الخاصة
      • التأكد من حماية البيانات المالية أثناء عملية التحويل
      • توثيق جميع التحويلات المالية في سجلات التطبيق
      الملاحظات والمشاكل
      • إذا فشلت عملية التحويل، يجب على النظام إعادة المحاولة تلقائيًا وإشعار الإداري بالفشل
      المدخلاتتأكيد خصم المبلغ من محفظة طالب الخدمة |
      المخرجات
      • تحويل رسوم الخدمة إلى حساب التطبيق
      تفاعلات المستخدم
      • إشعار الإداري بتحويل رسوم الخدمة إلى حساب التطبيق
      سيناريوهات الاستخدام
      • استخدام الحالة عند إتمام أي خدمة فنية وتحويل رسوم الخدمة بشكل تلقائي
      متطلبات الأمان
      • حماية بيانات التحويل المالي باستخدام تقنيات التشفير
      • ضمان عدم وجود عمليات تحويل غير مصرح بها
      التكامل مع الأنظمة الأخرى
      • النظام المالي الداخلي للتطبيق
      • خدمات الدفع الإلكترونية المرتبطة
      القيود والافتراضات
      • يجب أن يكون النظام متكاملًا مع مزودي الدفع المعتمدين
      • الافتراض بأن جميع المستخدمين لديهم وصول إلى محفظاتهم الإلكترونية بشكل دائم
      متطلبات الاختبار
      • اختبار عملية التحويل والتأكد من إتمامها بشكل صحيح
      • اختبار الحالات الاستثنائية عند فشل عملية التحويل
      تفاصيل ال API
      Method: POST || Endpoint: /api/financial/transfer-service-fee
      Request Headers
      Authorization: Bearer token

      Request Body

      service_id: نص amount: number

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تحويل رسوم الخدمة

      • textblock
        • يتم الآن تحويل رسوم الخدمة إلى حساب التطبيق

      الاشعارات

      العنوان : تحويل رسوم الخدمة
      الرسالة : تم تحويل رسوم الخدمة إلى حساب التطبيق بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : إداري النظام

      3.26.2.4- تحويل ضريبة القيمة المضافة إلى حساب الضريبة في التطبيق. بعد خصم المبلغ الإجمالي من محفظة طالب الخدمة، يقوم النظام بتحويل الضريبة إلى الحساب المخصص لذلك

      graph LR A[خصم المبلغ من محفظة طالب الخدمة] --> B[تحويل ضريبة القيمة المضافة إلى حساب الضريبة] B --> C[إشعار الإداري بتحويل المبلغ]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • خصم المبلغ الإجمالي من حساب محفظة طالب الخدمة
      الشروط اللاحقة
      • تحويل ضريبة القيمة المضافة إلى حساب الضريبة في التطبيق
      تسلسل الأحداث
      • خصم المبلغ الإجمالي من حساب محفظة طالب الخدمة
      • تحويل ضريبة القيمة المضافة إلى حساب الضريبة في التطبيق
      القواعد التجارية
      • يجب أن يتم تحويل ضريبة القيمة المضافة بشكل صحيح إلى حساب الضريبة في التطبيق
      الافتراضات
      • النظام قادر على تحويل الأموال بشكل موثوق وآمن
      المتطلبات الخاصة
      • التأكد من حماية البيانات المالية أثناء عملية التحويل
      • توثيق جميع التحويلات المالية في سجلات التطبيق
      الملاحظات والمشاكل
      • إذا فشلت عملية التحويل، يجب على النظام إعادة المحاولة تلقائيًا وإشعار الإداري بالفشل
      المدخلاتتأكيد خصم المبلغ من محفظة طالب الخدمة |
      المخرجات
      • تحويل ضريبة القيمة المضافة إلى حساب الضريبة في التطبيق
      تفاعلات المستخدم
      • إشعار الإداري بتحويل ضريبة القيمة المضافة إلى حساب الضريبة في التطبيق
      سيناريوهات الاستخدام
      • استخدام الحالة عند إتمام أي خدمة فنية وتحويل ضريبة القيمة المضافة بشكل تلقائي
      متطلبات الأمان
      • حماية بيانات التحويل المالي باستخدام تقنيات التشفير
      • ضمان عدم وجود عمليات تحويل غير مصرح بها
      التكامل مع الأنظمة الأخرى
      • النظام المالي الداخلي للتطبيق
      • خدمات الدفع الإلكترونية المرتبطة
      القيود والافتراضات
      • يجب أن يكون النظام متكاملًا مع مزودي الدفع المعتمدين
      • الافتراض بأن جميع المستخدمين لديهم وصول إلى محفظاتهم الإلكترونية بشكل دائم
      متطلبات الاختبار
      • اختبار عملية التحويل والتأكد من إتمامها بشكل صحيح
      • اختبار الحالات الاستثنائية عند فشل عملية التحويل
      تفاصيل ال API
      Method: POST || Endpoint: /api/financial/transfer-vat
      Request Headers
      Authorization: Bearer token

      Request Body

      service_id: نص amount: number

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تحويل ضريبة القيمة المضافة

      • textblock
        • يتم الآن تحويل ضريبة القيمة المضافة إلى حساب الضريبة

      الاشعارات

      العنوان : تحويل ضريبة القيمة المضافة
      الرسالة : تم تحويل ضريبة القيمة المضافة إلى حساب الضريبة بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : إداري النظام

      3.27 - تقييم خدمة فنية

      3.27.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • ضمان تقييم شفاف للخدمات المقدمة والحفاظ على سجل دقيق وموثق للبيانات، بهدف تعزيز الجودة وتحسين الخدمات مستقبلاً
      الجهات المعنية
      • العميل (طالب الخدمة)
      • مزود الخدمة (الورشة الفنية)
      • المنصة (التطبيق)
      الخطوات الرئيسية
      • تقييم الخدمة من قبل كل الأطراف
      • أرشفة البيانات الأساسية (وصف الحالة، موقع الإصلاح، تاريخ الطلب) للخدمة في سجلات الطلبات لكل الأطراف
      • أرشفة كافة بيانات الخدمة في سجلات المنصة
      الخطوات البديلة
      قصص المستخدمين
      • كعميل: بعد استكمال الخدمة، أريد تقييم الخدمة حتى يعرف الآخرون عن جودة العمل والكفاءة
      • كمزود الخدمة: أريد تلقي تغذية راجعة من العملاء حتى أستطيع تحسين أدائي وخدمتي في المستقبل
      • كإداري للمنصة: أريد التأكد من تقييم الجودة الشامل لاستكمال بناء منصة موثوقة وفعالة
      مؤشرات الأداء
      • إحصاء عدد الطلبات التي خضعت للتقييم وحساب نسبتها من إجمالي الطلبات المقدمة

      3.27.2 حالات الاستخدام

      3.27.2.1- تقييم الخدمة من قبل كل الأطراف

      graph LR A[End of Service] --> B[Client and Provider Evaluate] B --> C[System Records Evaluation]
      العنوانالتفاصيل
      المستخدممقدم الخدمة
      الشروط المسبقة
      • انتهاء تقديم الخدمة الفنية
      الشروط اللاحقة
      • تسجيل التقييم في النظام
      تسلسل الأحداث
      • انتهاء تقديم الخدمة الفنية
      • تقييم الخدمة من قبل كل الأطراف
      • تسجيل التقييم في النظام
      • عرض التقييم في صفحة مزود الخدمة
      تفاعلات المستخدم
      • العميل يدخل تقييمه في النظام
      • مزود الخدمة يدخل تقييمه في النظام
      سيناريوهات الاستخدام
      • بعد انتهاء خدمة فنية، يدخل كل من العميل ومزود الخدمة تقييماتهم في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /service/evaluation
      Request Headers
      Authorization: Bearer token Content-Type: application/json

      Request Body

      service_id-: integer client_rating: integer provider_rating: integer comments: string

      Response

      الحالةالمحتوى
      200status: string message: string
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      Service Evaluation

      • textblock
        • Please evaluate the service you received

      • form
        • number
          • العنوان : Client Rating
          • التحقق : "id": "client-rating", "min": 1, "max": 5, "validationErrorMessage": "Please provide a rating between 1 and 5."
        • number
          • العنوان : Provider Rating
          • التحقق : "id": "provider-rating", "min": 1, "max": 5, "validationErrorMessage": "Please provide a rating between 1 and 5."
      • رسالة زر الإرسال: Submit Evaluation
      • رسالة النجاح: Thank you for your feedback
      • إعادة توجيه النجاح: Home
      الاشعارات

      العنوان : Service Evaluation Request
      الرسالة : Please evaluate the service you received.
      عن طريق : push notification, email  المستقبل : client , provider

      3.27.2.2- أرشفة البيانات الأساسية (وصف الحالة، موقع الإصلاح، تاريخ الطلب) للخدمة في سجلات الطلبات لكل الأطراف

      graph LR A[إدخال التقييم من قبل جميع الأطراف] --> B[النظام يقوم بأرشفة البيانات الأساسية في سجلات الطلبات]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • إدخال التقييم من قبل جميع الأطراف
      الشروط اللاحقة
      • أرشفة البيانات الأساسية في سجلات الطلبات
      المدخلاتوصف الحالة | موقع الإصلاح | تاريخ الطلب |
      المخرجات
      • تأكيد أرشفة البيانات الأساسية في سجلات الطلبات
      سيناريوهات الاستخدام
      • النظام يقوم بأرشفة البيانات الأساسية بعد إدخال التقييم من جميع الأطراف
      تفاصيل ال API
      Method: POST || Endpoint: /archive-service-data
      Request Headers
      Authorization: Bearer token

      Request Body

      case_description: نص repair_location: نص request_date: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات

      3.27.2.3- أرشفة كافة بيانات الخدمة في سجلات المنصة

      graph LR A[إدخال التقييم من قبل جميع الأطراف] --> B[النظام يقوم بأرشفة كافة بيانات الخدمة في سجلات المنصة]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • إدخال التقييم من قبل جميع الأطراف
      الشروط اللاحقة
      • أرشفة كافة بيانات الخدمة في سجلات المنصة
      المدخلاتبيانات الخدمة الكاملة |
      المخرجات
      • تأكيد أرشفة كافة بيانات الخدمة في سجلات المنصة
      سيناريوهات الاستخدام
      • النظام يقوم بأرشفة كافة بيانات الخدمة بعد إدخال التقييم من جميع الأطراف
      تفاصيل ال API
      Method: POST || Endpoint: /archive-all-service-data
      Request Headers
      Authorization: Bearer token

      Request Body

      service_data: object

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات

      3.28 - إدخال بيانات قطع الغيار

      3.28.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • تسهيل الوصول إلى خدمات قطع الغيار من محلات مختارة وموثوقة، وتوفير تجربة سلسة ومريحة للعملاء في اختيار وطلب قطع الغيار
      الجهات المعنية
      • العميل (طالب الخدمة)
      • محلات القطع الغيار (مقدم الخدمة)
      • المنصة (التطبيق)
      الخطوات الرئيسية
      • العميل يختار نوع القطع (جديد/مستعمل)
      • النظام يستدعي بيانات المركبة للعميل
      • العميل يدخل بيانات القطع الوصفية والكمية (يمكن استخدام النص، التسجيل الصوتي، الصورة، أو الكل)
      • تحديد الموقع بشكل آلي من خلال النظام GPS
      الخطوات البديلة
      • العميل لا يمكنه تسجيل أرقام الهاتف للتواصل بين الأطراف
      قصص المستخدمين
      • كعميل: أريد اختيار نوع المحل، البحث عن قطع الغيار وطلبها بناءً على بيانات مركبتي
      • محلات قطع الغيار: أريد استلام الطلبات من العملاء ومعرفة تفاصيلها لإمكانية تقديم الخدمة المطلوبة
      • كإداري للمنصة كمستخدم: أريد توفير منصة موثوقة وسهلة الاستخدام للعملاء لطلب قطع الغيار، وأريد تحقيق تواصل فعال بين العميل ومحلات قطع الغيار
      مؤشرات الأداء

      3.28.2 حالات الاستخدام

      3.28.2.1- اختيار العميل لنوع القطعة (جديدة أو مستعملة) في نظام إدارة قطع الغيار

      flowchart LR A[العميل يفتح صفحة طلب قطع الغيار] --> B[العميل يختار نوع القطعة] B --> C[النظام يعرض رسالة تأكيد]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • تسجيل دخول العميل إلى النظام
      • توفر بيانات المركبة في النظام
      الشروط اللاحقة
      • تم تحديد نوع القطعة في النظام
      تسلسل الأحداث
      • العميل يفتح التطبيق
      • العميل يسجل دخوله
      • العميل يذهب إلى صفحة طلب قطع الغيار
      • العميل يحدد نوع القطعة
      الخطوات البديلةإذا لم يتمكن العميل من تحديد نوع القطعة
      • النظام يعرض رسالة خطأ توضح المشكلة
      • العميل يحاول تحديد النوع مرة أخرى
      الخطوات الاستثنائيةإذا تعذر الوصول إلى بيانات المركبة
      • النظام يعرض رسالة خطأ تشير إلى عدم توفر بيانات المركبة
      • العميل يتأكد من إدخال بيانات المركبة بشكل صحيح أو يحاول مرة أخرى لاحقًا
      القواعد التجارية
      • يجب أن تكون بيانات المركبة محدثة وصحيحة
      • يجب أن يتاح للعميل اختيار نوع القطعة (جديدة أو مستعملة)
      الافتراضات
      • العميل لديه معرفة بنوع القطعة التي يحتاجها
      • النظام يحتوي على قاعدة بيانات محدثة لقطع الغيار
      المتطلبات الخاصة
      • النظام يجب أن يكون قادرًا على معالجة طلبات القطع بشكل دقيق وسريع
      • يجب دعم واجهة المستخدم بعدة لغات لتلبية احتياجات جميع العملاء
      الملاحظات والمشاكل
      • تأكد من أن جميع بيانات المركبة متوفرة في النظام قبل محاولة تحديد نوع القطعة
      المدخلاتبيانات تسجيل الدخول | بيانات المركبة | نوع القطعة المطلوبة |
      المخرجات
      • تأكيد تحديد نوع القطعة
      • رسائل خطأ في حالة وجود مشاكل
      تفاعلات المستخدم
      • اختيار نوع القطعة من واجهة المستخدم
      • التفاعل مع رسائل التأكيد أو الخطأ
      الشروط الخاصة
      • في حالة عدم توفر بيانات المركبة، يتم إبلاغ العميل لتحديث البيانات
      سيناريوهات الاستخدام
      • كعميل، أرغب في اختيار نوع القطعة (جديدة أو مستعملة) عندما أطلب قطع غيار لمركبتي، لضمان الحصول على القطعة المناسبة
      متطلبات الأمان
      • تأمين بيانات المركبة والمستخدم لضمان الخصوصية
      • التحقق من هوية المستخدم قبل السماح بطلب قطع الغيار
      التكامل مع الأنظمة الأخرى
      • التكامل مع قاعدة بيانات قطع الغيار لتوفير معلومات دقيقة
      • التكامل مع نظام إدارة المستخدمين للتحقق من تسجيل الدخول
      القيود والافتراضات
      • يجب أن يكون لدى العميل اتصال إنترنت مستقر لاستخدام النظام
      • يفترض أن جميع بيانات المركبة المدخلة صحيحة ومحدثة
      متطلبات الاختبار
      • اختبارات وظيفية للتأكد من صحة عملية اختيار نوع القطعة
      • اختبارات أمان للتحقق من حماية بيانات المستخدم والمركبة
      تفاصيل ال API
      Method: GET || Endpoint: /api/spare-parts/types
      Request Headers
      Authorization: Bearer token Content-Type: application/json

      Request Body

      Response

      الحالةالمحتوى
      200Types : new, used
      الوصف: Success
      400
      الوصف: Bad Request
      401
      الوصف: Unauthorized

      تفاصيل الواجهات
      طلب قطع الغيار

      • form
        • dropdown
          • العنوان : نوع القطعة
          • التحقق : type: نص Enum : جديدة, مستعملة errorMessage: يرجى اختيار نوع القطعة (جديدة أو مستعملة)
          • الخيارات : ["جديدة","مستعملة"]
      • رسالة زر الإرسال: تأكيد
      • رسالة النجاح: تم تحديد نوع القطعة بنجاح
      • إعادة توجيه النجاح: SparePartsDetails
      الاشعارات

      العنوان : تحديد نوع القطعة
      الرسالة : تم تحديد نوع القطعة بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : العميل

      3.28.2.2- النظام يستدعي بيانات المركبة للعميل لتمكينه من طلب قطع الغيار المناسبة بسهولة وسرعة

      graph LR; A[العميل يحدد نوع القطع المطلوبة] --> B[النظام يستدعي بيانات المركبة]; B --> C[النظام يعرض بيانات المركبة للعميل];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • تحديد نوع القطع من قبل العميل
      الشروط اللاحقة
      • عرض بيانات المركبة للعميل في صفحة طلب قطع الغيار
      تسلسل الأحداث
      • العميل يحدد نوع القطع المطلوبة
      • النظام يستدعي بيانات المركبة
      • النظام يعرض بيانات المركبة في صفحة طلب قطع الغيار
      الخطوات البديلةإذا كانت بيانات المركبة غير متوفرة
      • النظام يعرض رسالة تنبيه بضرورة إدخال البيانات يدوياً
      • العميل يقوم بإدخال بيانات المركبة يدوياً
      الخطوات الاستثنائيةإذا كان هناك خطأ في الاتصال بقاعدة البيانات
      • النظام يعرض رسالة تنبيه بفشل الاتصال
      • يتم إعادة المحاولة تلقائياً بعد فترة محددة
      القواعد التجارية
      • يجب أن تكون بيانات المركبة محدثة وصحيحة في قاعدة البيانات
      • يجب أن يتم التحقق من صلاحية البيانات المستدعاة قبل عرضها للعميل
      الافتراضات
      • وجود اتصال دائم بقاعدة البيانات
      • أن العميل يعرف نوع القطع المطلوبة
      المتطلبات الخاصة
      • يجب أن تكون واجهة المستخدم سهلة الاستخدام لتمكين العميل من تحديد نوع القطع بسرعة
      • يجب أن يتم استدعاء بيانات المركبة بشكل سريع وفعال
      الملاحظات والمشاكل
      • تأكد من التعامل مع جميع الأخطاء المحتملة بشكل صحيح لضمان تجربة مستخدم سلسة
      • قد تحتاج العملية إلى تحسين الأداء لتقليل زمن الاستجابة
      المدخلاتنوع القطع المطلوبة |
      المخرجات
      • بيانات المركبة المعروضة للعميل
      تفاعلات المستخدم
      • تحديد نوع القطع المطلوبة من قبل العميل
      • عرض بيانات المركبة من قبل النظام
      الشروط الخاصة
      • إذا كانت بيانات المركبة غير متوفرة في قاعدة البيانات
      سيناريوهات الاستخدام
      • طلب قطع غيار جديدة باستخدام بيانات المركبة
      • طلب قطع غيار مستعملة باستخدام بيانات المركبة
      متطلبات الأمان
      • يجب حماية بيانات المركبة باستخدام تقنيات التشفير المناسبة
      • يجب التأكد من أن بيانات المركبة يمكن الوصول إليها فقط من قبل المستخدمين المصرح لهم
      التكامل مع الأنظمة الأخرى
      • تكامل مع قاعدة بيانات المركبات لاستدعاء البيانات
      • تكامل مع واجهة المستخدم لعرض البيانات
      القيود والافتراضات
      • افتراض وجود اتصال مستقر بقاعدة البيانات
      • قيود على نوع البيانات التي يمكن استدعاؤها من قاعدة البيانات
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من صحة استدعاء البيانات
      • اختبارات الأداء لضمان سرعة الاستجابة
      تفاصيل ال API
      Method: GET || Endpoint: /api/vehicles/{vehicleId}
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200vehicle_id: نص make: نص model: نص year: integer
      الوصف: Success
      404
      الوصف: Vehicle not found

      تفاصيل الواجهات
      شاشة تفاصيل المركبة

      • textblock
        • تفاصيل المركبة

      • table
        • الاسم : النوع
        • نوع المحتوي : text

        • الاسم : الطراز
        • نوع المحتوي : text

        • الاسم : السنة
        • نوع المحتوي : text

      • form
        • Button
          • العنوان : تأكيد
          • الخيارات : confirmVehicleDetails
      الاشعارات

      العنوان : تم استدعاء بيانات المركبة
      الرسالة : تم استدعاء بيانات المركبة بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : العميل

      3.28.2.3- العميل يدخل بيانات القطع الوصفية والكمية (يمكن استخدام النص، التسجيل الصوتي، الصورة، أو الكل) لطلب قطع الغيار

      graph LR; A[العميل يعرض بيانات المركبة] --> B[العميل يدخل بيانات القطع باستخدام النص]; B --> C[العميل يستخدم التسجيل الصوتي لإدخال بيانات القطع]; C --> D[العميل يلتقط صورة للقطع المراد طلبها]; D --> E[النظام يعرض رسالة تأكيد نجاح إدخال البيانات];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • عرض بيانات المركبة للعميل
      الشروط اللاحقة
      • إدخال بيانات القطع في النظام
      تسلسل الأحداث
      • العميل يعرض بيانات المركبة
      • العميل يدخل بيانات القطع الوصفية والكمية باستخدام النص، الصوت، أو الصورة
      • النظام يعرض رسالة تأكيد نجاح إدخال البيانات
      الخطوات البديلةإذا كان العميل غير قادر على استخدام التسجيل الصوتي
      • النظام يوفر خيار إدخال البيانات يدوياً
      الخطوات الاستثنائيةإذا كان هناك خطأ في إدخال البيانات
      • النظام يعرض رسالة خطأ توضح المشكلة
      • العميل يعيد إدخال البيانات الصحيحة
      القواعد التجارية
      • يجب أن تكون البيانات المدخلة دقيقة ومحدثة
      • يجب أن تكون الصور واضحة ومعبرة عن القطع المطلوبة
      الافتراضات
      • العميل لديه القدرة على استخدام أدوات إدخال البيانات (نص، صوت، صورة)
      • العميل يعرف تفاصيل القطع التي يحتاجها
      المتطلبات الخاصة
      • يجب أن تكون واجهة المستخدم سهلة الاستخدام لدعم إدخال البيانات بطرق متعددة
      • يجب أن يدعم النظام إدخال البيانات النصية، الصوتية، والصورية
      الملاحظات والمشاكل
      • تأكد من أن النظام يمكنه معالجة جميع أنواع البيانات المدخلة بشكل صحيح
      • تأكد من أن النظام يمكنه تقديم ملاحظات فورية للعميل بشأن جودة البيانات المدخلة
      المدخلاتبيانات القطع الوصفية | بيانات القطع الكمية | تسجيل صوتي لبيانات القطع | صورة للقطع المطلوبة |
      المخرجات
      • رسالة تأكيد نجاح إدخال البيانات
      • تحديث قاعدة بيانات الطلبات
      تفاعلات المستخدم
      • تعبئة نموذج إدخال بيانات القطع
      • استخدام ميكروفون لتسجيل الصوت
      • استخدام كاميرا لالتقاط الصور
      الشروط الخاصة
      • إذا كانت الصور غير واضحة أو البيانات الصوتية غير مفهومة
      سيناريوهات الاستخدام
      • طلب قطع غيار جديدة باستخدام النص والصوت
      • طلب قطع غيار جديدة باستخدام الصور والنص
      متطلبات الأمان
      • يجب حماية البيانات المدخلة باستخدام تقنيات التشفير المناسبة
      • يجب التأكد من أن البيانات المدخلة يمكن الوصول إليها فقط من قبل المستخدمين المصرح لهم
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام معالجة الصور لتحليل الصور المدخلة
      • تكامل مع نظام التعرف على الصوت لتحليل البيانات الصوتية
      القيود والافتراضات
      • افتراض وجود اتصال مستقر بالإنترنت أثناء العملية
      • قيود على نوع وحجم البيانات التي يمكن إدخالها
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من صحة إدخال البيانات
      • اختبارات الأمان لضمان حماية البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /api/parts
      Request Headers
      Authorization: Bearer token

      Request Body

      part_description: نص part_quantity: integer part_audio: file part_image: file

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة إدخال تفاصيل القطع

      • form
        • text
          • العنوان : وصف القطع
          • التحقق : يرجى إدخال وصف صحيح
        • number
          • العنوان : الكمية
          • التحقق : يرجى إدخال كمية صحيحة
        • file
          • العنوان : تسجيل صوتي
          • التحقق : يرجى تحميل تسجيل صوتي صحيح
        • file
          • العنوان : صورة
          • التحقق : يرجى تحميل صورة صحيحة
      • رسالة زر الإرسال: إدخال
      • رسالة النجاح: تم إدخال بيانات القطع بنجاح
      • إعادة توجيه النجاح: PartDetailsConfirmationScreen
      الاشعارات

      العنوان : تم إدخال بيانات القطع
      الرسالة : تم إدخال بيانات القطع بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : العميل

      3.28.2.4- تحديد الموقع بشكل آلي من خلال النظام GPS لضمان دقة الطلب وتوفير الوقت

      graph LR; A[النظام يطلب إذن الوصول إلى GPS] --> B[العميل يمنح الإذن]; B --> C[النظام يستخدم GPS لتحديد الموقع]; C --> D[النظام يعرض الموقع المحدد على الخريطة للعميل];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • العميل يقوم بتفعيل خدمة GPS على جهازه
      • توفير بيانات المركبة في النظام
      الشروط اللاحقة
      • تم تحديد موقع العميل بدقة
      • استخدام الموقع المحدد لطلب قطع الغيار
      تسلسل الأحداث
      • النظام يطلب إذن الوصول إلى GPS
      • العميل يمنح الإذن
      • النظام يحدد الموقع
      • النظام يعرض الموقع للعميل
      الخطوات البديلةإذا لم يتمكن النظام من تحديد الموقع بسبب عدم تفعيل خدمة GPS
      • النظام يعرض رسالة تنبيه بضرورة تفعيل خدمة GPS
      • العميل يقوم بتفعيل خدمة GPS ويعيد المحاولة
      الخطوات الاستثنائيةإذا كان هناك خطأ في تحديد الموقع بسبب مشاكل في الاتصال بالشبكة
      • النظام يعرض رسالة تنبيه بفشل تحديد الموقع
      • يتم استخدام آخر موقع معروف للعميل إذا كان متاحًا
      القواعد التجارية
      • يجب أن يتم تفعيل خدمة GPS على جهاز العميل
      • يجب أن يكون الاتصال بالشبكة متاحًا لتحديد الموقع بدقة
      الافتراضات
      • العميل لديه القدرة على تفعيل خدمة GPS
      • العميل موجود في منطقة تغطيها خدمة GPS
      المتطلبات الخاصة
      • يجب أن يكون النظام قادرًا على التعامل مع جميع أنواع الأجهزة وتحديد المواقع بدقة
      • يجب أن يتم توفير رسائل إرشادية للعميل لتفعيل خدمة GPS في حالة عدم تفعيلها
      الملاحظات والمشاكل
      • تأكد من توفير تعليمات واضحة للعميل حول كيفية تفعيل خدمة GPS
      • تأكد من التعامل مع حالات فشل تحديد الموقع بشكل مناسب لتجنب تأثيرها على تجربة المستخدم
      المدخلاتإذن الوصول إلى GPS من العميل |
      المخرجات
      • موقع العميل المحدد بدقة
      • عرض الموقع على الخريطة
      تفاعلات المستخدم
      • تفعيل خدمة GPS
      • تأكيد موقع العميل على الخريطة
      الشروط الخاصة
      • إذا لم يتمكن النظام من تحديد الموقع بسبب عدم تفعيل GPS
      سيناريوهات الاستخدام
      • تحديد موقع العميل تلقائيًا لطلب قطع غيار
      متطلبات الأمان
      • يجب حماية بيانات الموقع باستخدام تقنيات التشفير المناسبة
      • يجب التأكد من أن بيانات الموقع يمكن الوصول إليها فقط من قبل المستخدمين المصرح لهم
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام GPS لتحديد الموقع
      • تكامل مع واجهة المستخدم لعرض الموقع
      القيود والافتراضات
      • افتراض وجود اتصال مستقر بالشبكة
      • قيود على دقة تحديد الموقع في بعض المناطق
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من دقة تحديد الموقع
      • اختبارات الأداء لضمان سرعة استجابة النظام
      تفاصيل ال API
      Method: GET || Endpoint: /api/location
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200latitude: number longitude: number
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة موقع GPS

      • textblock
        • تحديد الموقع

      • form
        • Button
          • العنوان : تفعيل GPS
          • الخيارات : enableGPS
      الاشعارات

      العنوان : تم تحديد الموقع
      الرسالة : تم تحديد موقعك بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : العميل

      3.28.2.5- العميل لا يمكنه تسجيل أرقام الهاتف للتواصل بين الأطراف لضمان حماية البيانات الشخصية

      graph LR; A[النظام يمنع تسجيل أرقام الهاتف أو أي بيانات اتصال شخصية] --> B[النظام يراجع جميع المدخلات للتأكد من عدم وجود بيانات اتصال شخصية]; B --> C[النظام يعرض رسالة تحذير بضرورة عدم إدخال بيانات الاتصال الشخصية إذا كانت هناك مدخلات مخالفة];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • إدخال بيانات القطع من قبل العميل
      • تحديد الموقع بشكل آلي من خلال النظام GPS
      الشروط اللاحقة
      • منع تسجيل أرقام الهاتف أو أي بيانات اتصال شخصية في النظام
      تسلسل الأحداث
      • النظام يمنع تسجيل أرقام الهاتف أو أي بيانات اتصال شخصية
      • النظام يراجع المدخلات ويعرض رسالة تحذير إذا كانت هناك بيانات اتصال شخصية
      الخطوات البديلةإذا حاول العميل إدخال رقم هاتف أو بيانات اتصال شخصية
      • النظام يعرض رسالة تحذير بضرورة عدم إدخال بيانات الاتصال الشخصية
      • العميل يعدل المدخلات ويحذف بيانات الاتصال الشخصية
      الخطوات الاستثنائيةإذا كان هناك خطأ في التعرف على بيانات الاتصال الشخصية
      • النظام يعرض رسالة خطأ توضح المشكلة
      • العميل يعيد إدخال البيانات بدون بيانات الاتصال الشخصية
      القواعد التجارية
      • يجب حماية بيانات الاتصال الشخصية للعملاء
      • يجب أن تكون جميع المدخلات خالية من بيانات الاتصال الشخصية
      الافتراضات
      • العميل على دراية بعدم إدخال بيانات الاتصال الشخصية
      • النظام قادر على التعرف على بيانات الاتصال الشخصية ومنعها
      المتطلبات الخاصة
      • يجب أن يكون النظام قادرًا على التعامل مع جميع أنواع المدخلات والتعرف على بيانات الاتصال الشخصية
      • يجب أن يوفر النظام رسائل إرشادية واضحة للعملاء حول عدم إدخال بيانات الاتصال الشخصية
      الملاحظات والمشاكل
      • تأكد من التعامل مع جميع الأخطاء المحتملة بشكل صحيح لضمان تجربة مستخدم سلسة
      • قد تحتاج العملية إلى تحسين الأداء لتقليل زمن الاستجابة
      المدخلاتبيانات القطع | إحداثيات الموقع |
      المخرجات
      • رسالة تحذير بعدم إدخال بيانات الاتصال الشخصية
      • تحديث قاعدة بيانات الطلبات بدون بيانات الاتصال الشخصية
      تفاعلات المستخدم
      • إدخال بيانات القطع من قبل العميل
      • استلام رسالة تحذير من النظام حول بيانات الاتصال الشخصية
      الشروط الخاصة
      • إذا لم يستطع النظام التعرف على بيانات الاتصال الشخصية بشكل صحيح
      سيناريوهات الاستخدام
      • طلب قطع غيار بدون إدخال بيانات الاتصال الشخصية
      متطلبات الأمان
      • يجب حماية بيانات الاتصال الشخصية باستخدام تقنيات التعرف المناسبة
      • يجب التأكد من أن البيانات المدخلة يمكن الوصول إليها فقط من قبل المستخدمين المصرح لهم
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام التعرف على البيانات لمنع إدخال بيانات الاتصال الشخصية
      • تكامل مع واجهة المستخدم لعرض الرسائل التحذيرية
      القيود والافتراضات
      • افتراض وجود اتصال مستقر بالإنترنت أثناء العملية
      • قيود على نوع البيانات التي يمكن إدخالها
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من صحة التعرف على بيانات الاتصال الشخصية
      • اختبارات الأمان لضمان حماية البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /api/parts/validate
      Request Headers
      Authorization: Bearer token

      Request Body

      part_description: نص part_quantity: integer part_audio: file part_image: file

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة إدخال تفاصيل القطع

      • form
        • text
          • العنوان : وصف القطع
          • التحقق : يرجى إدخال وصف صحيح
        • number
          • العنوان : الكمية
          • التحقق : يرجى إدخال كمية صحيحة
        • file
          • العنوان : تسجيل صوتي
          • التحقق : يرجى تحميل تسجيل صوتي صحيح
        • file
          • العنوان : صورة
          • التحقق : يرجى تحميل صورة صحيحة
      • رسالة زر الإرسال: إدخال
      • رسالة النجاح: تم إدخال بيانات القطع بنجاح
      • إعادة توجيه النجاح: PartDetailsConfirmationScreen
      الاشعارات

      العنوان : تم إدخال بيانات القطع
      الرسالة : تم إدخال بيانات القطع بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : العميل

      3.29 - نشر خدمة قطع الغيار

      3.29.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • إذا لم يتم العثور على عدد كافٍ من المحلات ضمن النطاق المحدد، يمكن للنظام توسيع نطاق البحث تدريجيًا
      • المحلات التي لا تستطيع تقديم عرض قد تقترح توفير القطعة المطلوبة في وقت لاحق أو توفير بديل
      الجهات المعنية
      • العميل (طالب الخدمة)
      • محلات قطع الغيار (مقدم الخدمة)
      • المنصة (التطبيق)
      الخطوات الرئيسية
      • العميل ينشر طلبًا محددًا بالقطع التي يحتاجها، مثل فانوس لعربية نقل شيفروليه
      • النظام يبحث تلقائيًا عن المحلات الأقرب إلى موقع العميل، مستهدفًا تحديد أقرب 5 محلات ضمن نطاق 10 كيلومترات. إذا لم يجد 5 محلات ضمن هذا النطاق، يتوسع قطر البحث تلقائيًا حتى يجد على الأقل 5 محلات
      • محلات قطع الغيار تستعرض الطلب وتقدم عروضها مع تفاصيل القطع والأسعار
      الخطوات البديلة
      • إذا لم يجد العميل العرض المناسب، يمكنه طلب مزيد من التفاصيل أو عروض جديدة
      • إعطاء خيار إعادة البحث وتوسيع نطاق البحث (من خلال النظام يبحث عن المحلات)
      • المحلات قد تقدم عروضًا ترويجية أو بدائل إضافية بناءً على المخزون المتاح
      قصص المستخدمين
      • كعميل: أريد أن يحدد النظام تلقائيًا المحلات الأقرب إلي ويعرض عليّ الخيارات لضمان سرعة الحصول على القطعة
      • كمحل قطع غيار: أريد أن يعرض عليّ النظام الطلبات القريبة من موقعي لتقديم عروض تنافسية وسريعة
      • كمدير للمنصة: أريد توفير نظام يكفل توزيع الطلبات بشكل عادل وفعال بين المحلات القريبة والبعيدة، معززًا الكفاءة والرضا لدى العملاء ومقدمي الخدمة
      مؤشرات الأداء
      • عدد الطلبات المنشورة خلال فترات محددة
      • عدد المستلمين لطلبات المنشورة (لكل طلب لمعرفة قاعدة المستجيبين)

      3.29.2 حالات الاستخدام

      3.29.2.1- ينشر العميل طلبًا محددًا بالقطع التي يحتاجها، مثل فانوس لعربية نقل شيفروليه، عبر النظام ليتمكن من تلقي العروض من محلات قطع الغيار

      graph LR A[Login to System] --> B[Open Parts Request Page] B --> C[Specify Parts Details] C --> D[Submit Request]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • تسجيل دخول العميل إلى النظام
      • توفر بيانات المركبة في النظام
      الشروط اللاحقة
      • نشر الطلب في النظام
      تسلسل الأحداث
      • تسجيل دخول العميل إلى النظام
      • فتح صفحة طلب قطع الغيار
      • تحديد القطع المطلوبة
      • نشر الطلب
      الافتراضات
      • المستخدم يعرف أنواع قطع الغيار التي يريدها بالتحديد
      سيناريوهات الاستخدام
      • عند حدوث عطل في السيارة ويرغب العميل في طلب قطع غيار محددة
      تفاصيل ال API
      Method: POST || Endpoint: /parts/request
      Request Headers
      Authorization: Bearer token Content-Type: application/json

      Request Body

      vehicle_id: integer part_type: string details: string

      Response

      الحالةالمحتوى
      200status : string message: string
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      Parts Request

      • textblock
        • Please enter the details of the parts you need.

      • form
        • text
          • العنوان : Part Type
          • التحقق : id: part-type validationErrorMessage: Please specify the type of part.
        • textarea
          • العنوان : Details
          • التحقق : id: details validationErrorMessage: Please provide details about the part you need.
      • رسالة زر الإرسال: Submit Request
      • رسالة النجاح: Your request has been posted!
      • إعادة توجيه النجاح: Home
      الاشعارات

      العنوان : Parts Request Submitted
      الرسالة : Your request for parts has been submitted successfully
      عن طريق : push notification , email  المستقبل : client

      3.29.2.2- النظام يبحث تلقائيًا عن المحلات الأقرب إلى موقع العميل، مستهدفًا تحديد أقرب 5 محلات ضمن نطاق 10 كيلومترات. إذا لم يجد 5 محلات ضمن هذا النطاق، يتوسع قطر البحث تلقائيًا حتى يجد على الأقل 5 محلات

      graph LR; A[Start] --> B[Enter Spare Parts Request Page]; B --> C[Enter Part ID and Location]; C --> D[Click Search]; D --> E[System Searches for Nearest Stores]; E --> F[Expand Search If Necessary]; F --> G[Display Search Results];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • نشر طلب قطع الغيار من قبل العميل
      الشروط اللاحقة
      • عرض نتائج البحث عن المحلات على العميل
      الافتراضات
      • المحلات مسجلة ومحدثة في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /api/spare-parts/request
      Request Headers
      Authorization: Bearer token

      Request Body

      user_id: integer part_id: integer location: نص

      Response

      الحالةالمحتوى
      200status: نص stores: array
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      طلب قطع الغيار

      • form
        • text
          • العنوان : معرف القطعة
          • التحقق : Please enter a valid part ID
        • text
          • العنوان : الموقع
          • التحقق : Please enter your location
      • رسالة زر الإرسال: Search
      الاشعارات

      العنوان : طلب قطع الغيار
      الرسالة : يتم معالجة طلب قطع الغيار الخاص بك
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : user

      3.29.2.3- محلات قطع الغيار تستعرض الطلب وتقدم عروضها مع تفاصيل القطع والأسعار

      graph LR; A[Start] --> B[Receive Spare Parts Request]; B --> C[Review Request Details]; C --> D[Submit Offer with Details and Prices]; D --> E[Offer Submitted];
      العنوانالتفاصيل
      المستخدممحلات قطع الغيار
      الشروط المسبقة
      • عرض طلب قطع الغيار من قبل النظام
      الشروط اللاحقة
      • تقديم عروض الأسعار للعميل
      الافتراضات
      • المحلات لديها القطع المطلوبة في المخزون
      تفاصيل ال API
      Method: POST || Endpoint: /api/spare-parts/offers
      Request Headers
      Authorization: Bearer token

      Request Body

      store_id: integer request_id: integer offers: array

      Response

      الحالةالمحتوى
      200status: نص offers: array
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تقديم عرض قطع الغيار

      • form
        • text
          • العنوان : تفاصيل العرض
          • التحقق : Please enter offer details
        • number
          • العنوان : السعر
          • التحقق : Please enter a valid price
      • رسالة زر الإرسال: Submit Offer
      الاشعارات

      العنوان : عرض قطع الغيار
      الرسالة : تم تقديم عرض جديد لطلب قطع الغيار الخاص بك
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : user

      3.29.2.4- العميل يستعرض العروض المقدمة من المحلات، ويطلب مزيدًا من التفاصيل أو عروض جديدة إذا لم يكن أي عرض مناسبًا

      graph LR; A[Start] --> B[Receive Offers]; B --> C[Review Offers]; C --> D[Request More Details or New Offers]; D --> E[Submit Request];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • استلام العروض من المحلات
      الشروط اللاحقة
      • طلب مزيد من التفاصيل أو عروض جديدة
      الافتراضات
      • المحلات تقدم عروضها بشكل كامل وشفاف
      تفاصيل ال API
      Method: GET || Endpoint: /api/spare-parts/offers
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص offers: array
      الوصف: Success
      400
      الوصف: Bad Request

      Method: POST || Endpoint: /api/spare-parts/request-details
      Request Headers
      Authorization: Bearer token

      Request Body

      offer_id: integer request_type: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      عرض العروض

      • list
        • النوع : title: العرض content-render-format: text

      • form
        • dropdown
          • العنوان : نوع الطلب
          • التحقق : Please select a request type
          • الخيارات : ["More Details","New Offers"]
      • رسالة زر الإرسال: إرسال
      الاشعارات

      العنوان : عرض قطع الغيار
      الرسالة : تم تقديم طلبك للحصول على مزيد من التفاصيل أو العروض الجديدة
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : user

      3.29.2.5- إعطاء خيار إعادة البحث وتوسيع نطاق البحث، من خلال النظام الذي يبحث عن المحلات

      graph LR; A[Start] --> B[Receive Unsuitable Offers]; B --> C[Present Re-search Option]; C --> D[Initiate Re-search]; D --> E[Expand Search Radius];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • استلام العميل للعروض غير المناسبة
      الشروط اللاحقة
      • إعادة البحث عن المحلات وتوسيع النطاق
      الافتراضات
      • النظام قادر على توسيع نطاق البحث تلقائيًا
      تفاصيل ال API
      Method: POST || Endpoint: /api/spare-parts/research
      Request Headers
      Authorization: Bearer token

      Request Body

      user_id: integer request_id: integer

      Response

      الحالةالمحتوى
      200status: نص stores: array
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      إعادة بحث قطع الغيار

      • form
        • text
          • العنوان : معرف الطلب
          • التحقق : Please enter a valid request ID
      • رسالة زر الإرسال: Re-search
      الاشعارات

      العنوان : إعادة بحث قطع الغيار
      الرسالة : يتم معالجة إعادة البحث عن قطع الغيار الخاصة بك
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : user

      3.29.2.6- المحلات قد تقدم عروضًا ترويجية أو بدائل إضافية بناءً على المخزون المتاح

      graph LR; A[Start] --> B[Review Request Details]; B --> C[Submit Promotional Offers or Alternatives]; C --> D[Offers Submitted];
      العنوانالتفاصيل
      المستخدممحلات قطع الغيار
      الشروط المسبقة
      • عرض تفاصيل الطلب على المحلات
      الشروط اللاحقة
      • تقديم عروض ترويجية أو بدائل إضافية
      الافتراضات
      • المحلات لديها مرونة في تقديم عروض ترويجية أو بدائل
      تفاصيل ال API
      Method: POST || Endpoint: /api/spare-parts/promotions
      Request Headers
      Authorization: Bearer token

      Request Body

      store_id: integer request_id: integer promotions: array

      Response

      الحالةالمحتوى
      200status: نص promotions: array
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تقديم العروض الترويجية

      • form
        • text
          • العنوان : تفاصيل العروض الترويجية
          • التحقق : Please enter promotion details
      • رسالة زر الإرسال: Submit Promotions
      الاشعارات

      العنوان : عروض قطع الغيار الترويجية
      الرسالة : تم تقديم عروض ترويجية جديدة أو بدائل لطلبك
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : user

      3.30 - قطع غيار بيانات إضافية

      3.30.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • توفير تعامل مرن ومريح بين العملاء ومحلات قطع الغيار، مع ضمان الخصوصية والأمان للمعلومات الشخصية
      الجهات المعنية
      • العميل (طالب الخدمة)
      • محلات قطع الغيار (مقدم الخدمة)
      • المنصة (التطبيق)
      الخطوات الرئيسية
      • مقدم الخدمة يطلب بيانات إضافية من خلال فتح محادثة مؤقتة والتي تسمح بالكتابة والتسجيل الصوتي وإرفاق الصور
      • على العميل الرد على طلب بيانات الخدمة الإضافية وتوفيرها
      • قواعد النظام تمنع تسجيل أرقام الهاتف أو بيانات الاتصال الشخصية بين الأطراف في المحادثات وتمنع ظهورها في استعراض الملفات
      الخطوات البديلة
      • في حالة عدم استجابة العميل، يمكن لمقدم الخدمة الرجوع إلى الطلب الأصلي ومتابعة القرار الأمثل بناءً على المعلومات المتوفرة فقط
      قصص المستخدمين
      • العميل، كمستخدم: أريد استلام طلب لتقديم معلومات إضافية، وأيضًا أن أكون قادرًا على الرد على طلبات الخدمة بسهولة
      • محلات قطع الغيار، كمستخدم: أريد أن أتمكن من طلب بيانات إضافية من العميل في حالة الحاجة، وأن يكون الاتصال تابع للمنصة ولا يتعلق ببيانات الاتصال الشخصية
      • كإداري للمنصة: أريد تزويد المستخدمين بأدوات لتوفير تحسين التواصل والتعاون، مع الحفاظ على الأمان والخصوصية لمعلومات المستخدم
      مؤشرات الأداء
      • عدد الطلبات التي تم طلب بيانات إضافية لها بالنسبة لإجمالي الطلبات

      3.30.2 حالات الاستخدام

      3.30.2.1- مقدم الخدمة يطلب بيانات إضافية من خلال فتح محادثة مؤقتة لتمكينه من تقديم الخدمة بشكل أفضل. يتم إنشاء المحادثة المؤقتة بين مقدم الخدمة والعميل لتبادل المعلومات الضرورية

      graph LR; A[مقدم الخدمة يفتح محادثة مؤقتة] --> B[مقدم الخدمة يطلب البيانات الإضافية] B --> C[النظام يقوم بإشعار العميل] C --> D[العميل يقوم بتقديم البيانات] D --> E[النظام يقوم بتحديث حالة الطلب] E --> F[النظام يغلق المحادثة المؤقتة]
      العنوانالتفاصيل
      المستخدممقدم الخدمة
      الشروط المسبقة
      • وجود طلب سابق من العميل
      • مقدم الخدمة لديه صلاحيات فتح محادثة مؤقتة
      • العميل متاح للرد على المحادثة المؤقتة
      الشروط اللاحقة
      • تمكن مقدم الخدمة من الحصول على البيانات الإضافية المطلوبة
      • إغلاق المحادثة المؤقتة بعد الحصول على البيانات
      • تحديث حالة الطلب بناءً على البيانات الجديدة
      تسلسل الأحداث
      • طلب البيانات الإضافية من قبل مقدم الخدمة
      • إشعار العميل
      • تبادل البيانات
      • تحديث الطلب
      • إغلاق المحادثة
      الخطوات البديلةالعميل غير متاح للرد على المحادثة المؤقتة
      • النظام يقوم بإشعار العميل بوجود طلب بيانات إضافية عبر البريد الإلكتروني
      • العميل يقوم بتقديم البيانات المطلوبة عبر البريد الإلكتروني أو عند تسجيل الدخول لاحقاً
      • النظام يقوم بتحديث حالة الطلب بناءً على البيانات المقدمة
      • النظام يغلق المحادثة المؤقتة بعد اكتمال تبادل المعلومات
      الخطوات الاستثنائيةمقدم الخدمة ليس لديه صلاحيات لفتح محادثة مؤقتة
      • النظام يعرض رسالة خطأ لمقدم الخدمة تشير إلى نقص الصلاحيات
      • مقدم الخدمة يقوم بطلب الصلاحيات من المسؤول
      النظام يتعطل أثناء فتح المحادثة
      • النظام يعرض رسالة خطأ لمقدم الخدمة تشير إلى وجود مشكلة تقنية
      • مقدم الخدمة يقوم بإعادة المحاولة لاحقاً
      القواعد التجارية
      • يجب أن يكون لمقدم الخدمة صلاحيات فتح المحادثة المؤقتة
      • يجب إغلاق المحادثة المؤقتة بعد اكتمال تبادل المعلومات
      الافتراضات
      • العميل سيكون متاحاً للرد على المحادثة المؤقتة
      • مقدم الخدمة لديه جميع المعلومات اللازمة لفتح المحادثة
      المتطلبات الخاصة
      • توفير وسيلة آمنة لتبادل المعلومات بين مقدم الخدمة والعميل
      • تسجيل جميع المحادثات المؤقتة للرجوع إليها لاحقاً
      الملاحظات والمشاكل
      • يجب تحسين تجربة المستخدم لضمان استجابة العميل بسرعة
      • النظر في توفير طرق بديلة لتقديم البيانات في حال عدم توفر العميل
      المدخلاتطلب مقدم الخدمة | بيانات العميل الإضافية |
      المخرجات
      • بيانات إضافية محدثة
      • تحديث حالة الطلب
      تفاعلات المستخدم
      • فتح المحادثة من قبل مقدم الخدمة
      • تقديم البيانات من قبل العميل
      الشروط الخاصة
      • عدم توفر العميل
      • مشاكل تقنية
      سيناريوهات الاستخدام
      • مقدم الخدمة يطلب معلومات ضرورية لاستكمال الطلب
      • العميل يقدم المعلومات عبر المحادثة
      متطلبات الأمان
      • يجب تأمين المحادثة لحماية البيانات الحساسة
      • يجب التحقق من هوية مقدم الخدمة والعميل
      التكامل مع الأنظمة الأخرى
      • نظام إدارة الطلبات
      • نظام الإشعارات
      القيود والافتراضات
      • افتراض أن العميل سيقوم بالرد على المحادثة في الوقت المناسب
      • تقديم النظام لوسيلة سلسة لفتح المحادثة
      متطلبات الاختبار
      • اختبار فتح المحادثة بنجاح
      • اختبار تبادل البيانات بين مقدم الخدمة والعميل
      • اختبار إغلاق المحادثة وتحديث حالة الطلب
      تفاصيل ال API
      Method: POST || Endpoint: /temporary-conversation
      Request Headers
      Authorization: Bearer token

      Request Body

      service_provider_id: integer client_id: integer request_id: integer message: نص

      Response

      الحالةالمحتوى
      200status: نص conversation_id: integer
      الوصف: Success
      400
      الوصف: Bad Request

      Method: POST || Endpoint: /temporary-conversation/{conversation_id}/message
      Request Headers
      Authorization: Bearer token

      Request Body

      message: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      Method: POST || Endpoint: /temporary-conversation/{conversation_id}/close
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      محادثة مؤقتة

      • textblock
        • بدء محادثة مؤقتة مع مقدم الخدمة لطلب بيانات إضافية

      • form
        • textarea
          • العنوان : رسالة
          • التحقق : الرسالة مطلوبة
      • رسالة زر الإرسال: إرسال
      • رسالة النجاح: تم إرسال الرسالة بنجاح
      • إعادة توجيه النجاح: RequestDetails

      استجابة المحادثة المؤقتة

      • textblock
        • تم إرسال رسالتك بنجاح، وسيقوم مقدم الخدمة بالرد قريباً

      الاشعارات

      العنوان : طلب بيانات إضافية
      الرسالة : لديك طلب جديد للحصول على بيانات إضافية من مقدم الخدمة. يرجى الرد في أقرب وقت ممكن
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : العميل

      العنوان : رد العميل على طلب البيانات
      الرسالة : قام العميل بالرد على طلبك للحصول على بيانات إضافية. يرجى مراجعة البيانات المقدمة
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : مقدم الخدمة

      3.30.2.2- على العميل الرد على طلب بيانات الخدمة الإضافية المقدم من قبل مقدم الخدمة، وتوفير البيانات المطلوبة لضمان تقديم الخدمة بشكل صحيح

      graph LR; A[النظام يقوم بإشعار العميل] --> B[العميل يقرأ طلب البيانات] B --> C[العميل يجهز البيانات] C --> D[العميل يرسل البيانات إلى مقدم الخدمة] D --> E[النظام يقوم بتحديث حالة الطلب]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • استلام طلب البيانات الإضافية من مقدم الخدمة
      • توافر البيانات المطلوبة لدى العميل
      • العميل قادر على الوصول إلى النظام للرد على الطلب
      الشروط اللاحقة
      • تقديم البيانات المطلوبة لمقدم الخدمة
      • تحديث حالة الطلب بناءً على البيانات المقدمة
      تسلسل الأحداث
      • إشعار العميل بطلب البيانات الإضافية
      • قراءة الطلب
      • تجهيز البيانات
      • إرسال البيانات
      • تحديث حالة الطلب
      الخطوات البديلةالعميل غير متاح للرد على الطلب فوراً
      • النظام يقوم بتذكير العميل بوجود طلب بيانات إضافية بعد فترة زمنية محددة
      • العميل يقرأ التذكير ويقوم بالرد على الطلب
      الخطوات الاستثنائيةالعميل يواجه مشكلة تقنية أثناء إرسال البيانات
      • النظام يعرض رسالة خطأ تشير إلى وجود مشكلة تقنية
      • العميل يعيد المحاولة لإرسال البيانات بعد فترة زمنية قصيرة
      • في حالة استمرار المشكلة، العميل يتواصل مع الدعم الفني
      القواعد التجارية
      • يجب على العميل الرد على طلب البيانات في فترة زمنية محددة
      • يجب توفير وسيلة لتذكير العميل في حالة عدم الرد
      الافتراضات
      • العميل سيكون قادراً على توفير البيانات المطلوبة
      • النظام سيكون متاحاً للعميل في أي وقت للرد على الطلب
      المتطلبات الخاصة
      • توفير واجهة مستخدم سهلة الاستخدام للعميل للرد على طلب البيانات
      • توفير أمان عالي لتبادل البيانات الحساسة
      الملاحظات والمشاكل
      • يجب مراعاة تقديم تجربة مستخدم ممتازة لضمان سرعة استجابة العميل
      • النظر في تحسين آلية التذكير للعميل في حالة عدم الرد
      المدخلاتطلب البيانات الإضافية | البيانات المطلوبة من العميل |
      المخرجات
      • البيانات المقدمة من العميل
      • تحديث حالة الطلب
      تفاعلات المستخدم
      • قراءة طلب البيانات
      • تقديم البيانات عبر المحادثة
      الشروط الخاصة
      • عدم توفر العميل
      • مشاكل تقنية أثناء التقديم
      سيناريوهات الاستخدام
      • استلام طلب بيانات إضافية من مقدم الخدمة
      • تقديم البيانات عبر المحادثة المؤقتة
      متطلبات الأمان
      • حماية البيانات المرسلة من العميل
      • التحقق من هوية العميل قبل السماح بإرسال البيانات
      التكامل مع الأنظمة الأخرى
      • نظام إدارة الطلبات
      • نظام الإشعارات
      القيود والافتراضات
      • افتراض أن العميل سيكون متاحاً للرد في الوقت المناسب
      • تقديم النظام لوسيلة سهلة لتبادل البيانات
      متطلبات الاختبار
      • اختبار عملية استلام إشعار طلب البيانات
      • اختبار عملية إرسال البيانات من قبل العميل
      • اختبار تحديث حالة الطلب بعد استلام البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /temporary-conversation/{conversation_id}/message
      Request Headers
      Authorization: Bearer token

      Request Body

      message: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تقديم بيانات إضافية

      • textblock
        • طلب مقدم الخدمة للحصول على بيانات إضافية

      • form
        • textarea
          • العنوان : البيانات المطلوبة
          • التحقق : البيانات مطلوبة
      • رسالة زر الإرسال: إرسال
      • رسالة النجاح: تم إرسال البيانات بنجاح
      • إعادة توجيه النجاح: RequestDetails

      تم تقديم البيانات الإضافية بنجاح

      • textblock
        • تم إرسال بياناتك بنجاح، وسيقوم مقدم الخدمة بمراجعتها قريباً

      الاشعارات

      العنوان : طلب بيانات إضافية
      الرسالة : لديك طلب جديد للحصول على بيانات إضافية من مقدم الخدمة. يرجى الرد في أقرب وقت ممكن
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : العميل

      العنوان : رد العميل على طلب البيانات
      الرسالة : قام العميل بالرد على طلبك للحصول على بيانات إضافية. يرجى مراجعة البيانات المقدمة
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : مقدم الخدمة

      3.30.2.3- قواعد النظام تمنع تسجيل أرقام الهاتف أو بيانات الاتصال الشخصية بين الأطراف في المحادثات وتمنع ظهورها في استعراض الملفات لحماية خصوصية المستخدمين وضمان أمان البيانات

      graph LR; A[بدء المحادثة المؤقتة] --> B[النظام يراقب المحادثة] B --> C[منع تسجيل بيانات الاتصال الشخصية] C --> D[منع عرض بيانات الاتصال في استعراض الملفات]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • بدء محادثة مؤقتة بين العميل ومقدم الخدمة
      • وجود قواعد أمان مفعّلة لمنع مشاركة بيانات الاتصال الشخصية
      الشروط اللاحقة
      • حماية بيانات الاتصال الشخصية للأطراف المشاركة في المحادثة
      • منع ظهور بيانات الاتصال الشخصية في أي استعراض للملفات
      تسلسل الأحداث
      • بدء المحادثة
      • مراقبة الرسائل
      • منع الرسائل التي تحتوي على بيانات الاتصال
      • منع عرض بيانات الاتصال في الملفات
      الخطوات البديلةمحاولة مشاركة بيانات الاتصال في رسالة نصية
      • النظام يكتشف بيانات الاتصال في الرسالة
      • النظام يمنع إرسال الرسالة ويعرض تنبيهًا للمستخدم يوضح منع مشاركة بيانات الاتصال الشخصية
      الخطوات الاستثنائيةالنظام يفشل في اكتشاف بيانات الاتصال
      • النظام يسجل الحالة في سجل الأخطاء لمراجعتها لاحقاً
      • النظام يواصل مراقبة المحادثة ويحاول منع مشاركة البيانات في المستقبل
      القواعد التجارية
      • يجب منع تسجيل أو تبادل بيانات الاتصال الشخصية بين الأطراف
      • يجب عدم ظهور بيانات الاتصال الشخصية في أي مكان في النظام
      الافتراضات
      • النظام قادر على مراقبة وفحص جميع الرسائل في الوقت الفعلي
      • المستخدمين سيتفهمون القيود الموضوعة على مشاركة البيانات الشخصية
      المتطلبات الخاصة
      • تحديثات دورية للنظام لضمان فعالية قواعد الأمان
      • توفير واجهة واضحة للمستخدمين لفهم القواعد المتعلقة بمشاركة البيانات الشخصية
      الملاحظات والمشاكل
      • يجب تحسين خوارزميات الكشف لضمان عدم تسريب أي بيانات شخصية
      • النظر في تقارير المستخدمين حول أي مشكلات متعلقة بمنع مشاركة البيانات
      المدخلاترسائل المحادثة المؤقتة | ملفات مرفقة |
      المخرجات
      • رسائل محظورة تحتوي على بيانات الاتصال الشخصية
      • تنبيهات للمستخدمين
      تفاعلات المستخدم
      • إرسال رسالة تحتوي على بيانات الاتصال
      • استقبال تنبيه من النظام
      الشروط الخاصة
      • فشل النظام في اكتشاف البيانات
      • تكرار محاولة مشاركة البيانات
      سيناريوهات الاستخدام
      • محادثة مؤقتة بين العميل ومقدم الخدمة
      • محاولة مشاركة بيانات الاتصال الشخصية
      متطلبات الأمان
      • مراقبة الرسائل في الوقت الفعلي
      • تشفير البيانات المتبادلة لضمان الأمان
      التكامل مع الأنظمة الأخرى
      • نظام إدارة المحادثات
      • نظام إدارة الملفات
      القيود والافتراضات
      • افتراض أن النظام سيكون قادرًا على مراقبة جميع الرسائل بفعالية
      • تقييد تبادل البيانات فقط داخل المحادثة المؤقتة
      متطلبات الاختبار
      • اختبار قدرة النظام على منع تسجيل أرقام الهاتف
      • اختبار منع ظهور بيانات الاتصال في استعراض الملفات
      • اختبار التنبيهات المرسلة للمستخدمين
      تفاصيل ال API
      Method: POST || Endpoint: /monitor-temporary-conversation
      Request Headers
      Authorization: Bearer token

      Request Body

      conversation_id: integer message: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      Method: GET || Endpoint: /conversation/{conversation_id}/files
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200Files : Array
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      محادثة مؤقتة

      • textblock
        • محادثة مؤقتة مع مقدم الخدمة. يرجى عدم مشاركة بيانات الاتصال الشخصية

      • form
        • textarea
          • العنوان : رسالتك
          • التحقق : يرجى عدم مشاركة بيانات الاتصال الشخصية
      • رسالة زر الإرسال: إرسال
      • رسالة النجاح: تم إرسال الرسالة بنجاح
      • إعادة توجيه النجاح: ConversationDetails
      الاشعارات

      العنوان : تنبيه: محاولة مشاركة بيانات الاتصال
      الرسالة : تم منع محاولة مشاركة بيانات الاتصال الشخصية في المحادثة المؤقتة
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : مقدم الخدمة

      العنوان : تنبيه: منع مشاركة بيانات الاتصال
      الرسالة : يرجى عدم محاولة مشاركة بيانات الاتصال الشخصية في المحادثة
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : العميل

      3.30.2.4- في حالة عدم استجابة العميل لطلب البيانات الإضافية، يتعين على مقدم الخدمة الرجوع إلى الطلب الأصلي ومتابعة اتخاذ القرار الأمثل بناءً على المعلومات المتوفرة فقط لضمان استمرارية الخدمة

      graph LR; A[انتظار استجابة العميل] --> B[انقضاء الفترة الزمنية المحددة] B --> C[الرجوع إلى الطلب الأصلي] C --> D[اتخاذ قرار بناءً على المعلومات المتوفرة] D --> E[إخطار العميل بالقرار المتخذ]
      العنوانالتفاصيل
      المستخدممقدم الخدمة
      الشروط المسبقة
      • عدم استجابة العميل لطلب البيانات الإضافية خلال الفترة الزمنية المحددة
      • توفر المعلومات الأساسية في الطلب الأصلي
      الشروط اللاحقة
      • متابعة القرار الأمثل بناءً على المعلومات المتاحة
      • إخطار العميل بالقرار المتخذ بناءً على المعلومات المتوفرة
      تسلسل الأحداث
      • طلب البيانات الإضافية
      • انتظار استجابة العميل
      • عدم استجابة العميل
      • اتخاذ قرار بناءً على المعلومات المتاحة
      • إخطار العميل بالقرار
      الخطوات البديلةاستجابة العميل بعد الفترة الزمنية المحددة
      • النظام يقبل استجابة العميل إذا كانت متوافقة مع الوقت المسموح به للإجابة المتأخرة
      • مقدم الخدمة يراجع البيانات المرسلة من العميل
      • مقدم الخدمة يتخذ قرارًا بناءً على المعلومات الجديدة المقدمة من العميل
      الخطوات الاستثنائيةالقرار المتخذ يحتاج إلى موافقة إضافية
      • مقدم الخدمة يطلب موافقة من الإدارة العليا أو الجهات المختصة
      • الجهات المختصة تراجع وتوافق على القرار
      القواعد التجارية
      • يجب أن تكون الفترة الزمنية لانتظار استجابة العميل محددة ومعروفة مسبقًا
      • يجب على مقدم الخدمة اتخاذ القرار بناءً على أفضل المعلومات المتوفرة في حالة عدم استجابة العميل
      الافتراضات
      • العميل قد لا يكون قادرًا على الرد في الفترة الزمنية المحددة لأسباب مشروعة
      • مقدم الخدمة قادر على اتخاذ قرار منطقي بناءً على المعلومات المتاحة
      المتطلبات الخاصة
      • النظام يجب أن يحتوي على آلية لتنبيه العميل قبل انتهاء الفترة الزمنية
      • توفير وثائق واضحة لمقدم الخدمة حول كيفية اتخاذ القرارات في حالة عدم استجابة العميل
      الملاحظات والمشاكل
      • قد يكون هناك حاجة لمراجعة الأسباب وراء عدم استجابة العميل لتحسين النظام في المستقبل
      • النظر في توفير وسائل إضافية لتواصل العميل في حالة عدم القدرة على الرد في الوقت المحدد
      المدخلاتطلب البيانات الإضافية | المعلومات المتوفرة في الطلب الأصلي |
      المخرجات
      • القرار المتخذ بناءً على المعلومات المتاحة
      • إخطار العميل بالقرار المتخذ
      تفاعلات المستخدم
      • انتظار استجابة العميل
      • اتخاذ القرار بناءً على المعلومات المتوفرة
      الشروط الخاصة
      • استجابة متأخرة من العميل
      • الحاجة إلى موافقة إضافية على القرار
      سيناريوهات الاستخدام
      • مقدم الخدمة ينتظر استجابة العميل دون تلقيها
      • مقدم الخدمة يتخذ قرارًا بناءً على المعلومات المتاحة في الطلب الأصلي
      متطلبات الأمان
      • تأمين بيانات الطلب الأصلي والمعلومات المتوفرة
      • ضمان أن عملية اتخاذ القرار تتبع السياسات والإجراءات المعتمدة
      التكامل مع الأنظمة الأخرى
      • نظام إدارة الطلبات
      • نظام الإشعارات
      القيود والافتراضات
      • افتراض أن العميل قد يواجه صعوبات في الرد في الوقت المحدد
      • النظام يجب أن يدعم اتخاذ القرار بناءً على المعلومات المتوفرة
      متطلبات الاختبار
      • اختبار إشعارات النظام لتنبيه العميل قبل انتهاء الفترة الزمنية
      • اختبار عملية اتخاذ القرار بناءً على المعلومات المتاحة
      • اختبار إخطار العميل بالقرار المتخذ
      تفاصيل ال API
      Method: POST || Endpoint: /request/{request_id}/follow-up-decision
      Request Headers
      Authorization: Bearer token

      Request Body

      request_id: integer decision: نص

      Response

      الحالةالمحتوى
      200status: نص decision_id: integer
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      قرار المتابعة

      • textblock
        • لم يتم استلام رد من العميل في الوقت المحدد. يرجى اتخاذ قرار بناءً على المعلومات المتاحة

      • form
        • textarea
          • العنوان : القرار
          • التحقق : القرار مطلوب
      • رسالة زر الإرسال: إرسال
      • رسالة النجاح: تم اتخاذ القرار بنجاح
      • إعادة توجيه النجاح: RequestDetails
      الاشعارات

      العنوان : تنبيه: لم يتم استلام رد
      الرسالة : لم نستلم ردك على طلب البيانات الإضافية. سيتم اتخاذ قرار بناءً على المعلومات المتاحة
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : العميل

      العنوان : تنبيه: اتخاذ قرار متابعة
      الرسالة : لم يتم استلام رد من العميل. يرجى اتخاذ قرار بناءً على المعلومات المتاحة
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : مقدم الخدمة

      3.31 - استجابة لطلب قطع غيار

      3.31.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • كفاءة وشفافية في تقديم العروض من محلات قطع الغيار إلى العملاء من خلال المنصة
      الجهات المعنية
      • محلات قطع الغيار
      • العميل
      • المنصة
      الخطوات الرئيسية
      • محل قطع الغيار يقوم بإدخال مواصفات القطعة المطلوبة، بما في ذلك الحجم، الوزن التقريبي، والعدد
      • محل قطع الغيار يقوم بإدخال تكلفة القطع
      • تقوم المنصة بحساب رسوم الخدمة
      • يتم إحتساب الضريبة على رسوم الخدمة المقررة
      • يتم عرض صافي المبلغ المستحق للمحل بعد خصم الرسوم والضريبة من تكلفة القطعة
      • محل قطع الغيار يقدم الموافقة ويرسل العرض إلى طالب الخدمة
      الخطوات البديلة
      • في حالة عدم القدرة على تقديم القطعة المطلوبة، يمكن لمحل قطع الغيار إرسال رسالة نصية للعميل تشرح السبب
      قصص المستخدمين
      • محلات قطع الغيار، كمستخدم: أريد التمكن من تحديد بيانات قطعة الغيار بدقة (بما في ذلك الحجم، الوزن، والعدد) وتحديد التكلفة المرتبطة، وبالتالي تقديم عرض شاف وواضح للعميل
      • العميل، كمستخدم: أريد أن أتلقى عروضًا شفافة ومفصلة من محلات قطع الغيار، تشمل الكلفة الكاملة والرسوم المرتبطة
      • كاداري للمنصة: أريد تقديم نظام يمكن من خلاله محلات قطع الغيار من تقديم عروض شافية وشفافة للعملاء، كل ذلك مع تجنب الاحتيال أو أي سلوك غير مرغوب فيه
      مؤشرات الأداء
      • نسبة عدد الطلبات التي تم الاستجابة لها بالنسبة لعدد الطلبات الإجمالي

      3.31.2 حالات الاستخدام

      3.31.2.1- محل قطع الغيار يقوم بإدخال مواصفات القطعة المطلوبة، بما في ذلك الحجم، الوزن التقريبي، والعدد بشكل دقيق في النظام لتلبية طلب العميل

      graph LR A[استلام طلب قطع الغيار] --> B[استعراض الطلب] B --> C[إدخال المواصفات] C --> D[التحقق من دقة البيانات] D --> E[حفظ البيانات]
      العنوانالتفاصيل
      المستخدممحل قطع الغيار
      الشروط المسبقة
      • استلام طلب من العميل لقطع الغيار
      • الوصول إلى النظام الإلكتروني المخصص لإدخال مواصفات القطع
      الشروط اللاحقة
      • إدخال مواصفات القطعة المطلوبة في النظام
      • تحديث قاعدة بيانات النظام بمواصفات القطعة المدخلة
      تسلسل الأحداث
      • استلام الطلب من العميل
      • استعراض الطلب
      • إدخال المواصفات
      • التحقق من دقة البيانات
      • حفظ البيانات
      الخطوات البديلةإذا كانت البيانات المدخلة غير كاملة أو غير صحيحة
      • النظام يعرض رسالة خطأ توضح البيانات الناقصة أو غير الصحيحة
      • محل قطع الغيار يقوم بتصحيح البيانات المدخلة
      • محل قطع الغيار يحفظ البيانات المصححة في النظام
      الخطوات الاستثنائيةإذا تعذر على محل قطع الغيار الوصول إلى النظام
      • النظام يعرض رسالة خطأ تشير إلى عدم القدرة على الوصول
      • محل قطع الغيار يحاول الوصول مرة أخرى بعد فترة قصيرة
      • إذا استمرت المشكلة، يتم الإبلاغ لفريق الدعم الفني
      القواعد التجارية
      • يجب إدخال المواصفات بشكل دقيق لتفادي أي أخطاء في الطلبات
      • يجب على النظام التحقق من تكرار البيانات لمنع الإدخال المزدوج
      الافتراضات
      • محل قطع الغيار لديه وصول مستمر إلى النظام الإلكتروني
      • محل قطع الغيار لديه التدريب اللازم لإدخال البيانات
      المتطلبات الخاصة
      • النظام يجب أن يكون متاحاً 24/7
      • النظام يجب أن يدعم إدخال البيانات بسرعة وكفاءة
      الملاحظات والمشاكل
      • تحتاج العملية إلى دقة عالية لتفادي أي أخطاء
      • يجب تحسين واجهة المستخدم لتسهيل عملية الإدخال
      المدخلاتبيانات الطلب من العميل | مواصفات القطعة المطلوبة (الحجم، الوزن، العدد) |
      المخرجات
      • تحديث قاعدة بيانات النظام بالمواصفات المدخلة
      • إشعار للعميل بتحديث الطلب
      تفاعلات المستخدم
      • استعراض الطلب على واجهة النظام
      • إدخال البيانات في الحقول المخصصة
      • حفظ البيانات والتأكد من التحديث
      الشروط الخاصة
      • إذا كانت البيانات المدخلة غير مكتملة أو غير صحيحة
      سيناريوهات الاستخدام
      • محل قطع الغيار يستلم طلب من العميل ويدخل المواصفات المطلوبة
      • النظام يتحقق من دقة البيانات ويحفظها
      متطلبات الأمان
      • يجب أن يكون الوصول إلى النظام محمي بكلمة مرور
      • البيانات المدخلة يجب أن تكون مشفرة أثناء النقل
      التكامل مع الأنظمة الأخرى
      • النظام يجب أن يتكامل مع قاعدة بيانات القطع
      • النظام يجب أن يتكامل مع نظام إدارة الطلبات
      القيود والافتراضات
      • محل قطع الغيار يمكنه الوصول إلى النظام في أي وقت
      • النظام يجب أن يكون متاحاً بشكل دائم
      متطلبات الاختبار
      • اختبار إدخال البيانات للتحقق من الدقة
      • اختبار التكامل مع الأنظمة الأخرى
      تفاصيل ال API
      Method: POST || Endpoint: /api/parts
      Request Headers
      Authorization: Bearer token

      Request Body

      size: نص weight: number quantity: integer

      Response

      الحالةالمحتوى
      200status: success Data : نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة إدخال القطع

      • textblock
        • Please enter the part specifications below:

      • form
        • text
          • العنوان : الحجم
          • التحقق : {"required":true,"error_message":"الحجم مطلوب"}
        • number
          • العنوان : الوزن
          • التحقق : {"required":true,"error_message":"الوزن مطلوب"}
        • number
          • العنوان : الكمية
          • التحقق : {"required":true,"error_message":"الكمية مطلوبة"}
      • رسالة زر الإرسال: Save
      • رسالة النجاح: تم حفظ مواصفات القطعة بنجاح
      • إعادة توجيه النجاح: PartsOverviewScreen
      الاشعارات

      العنوان : تم تحديث طلب قطع الغيار
      الرسالة : تم إدخال مواصفات القطعة المطلوبة بنجاح
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.31.2.2- محل قطع الغيار يقوم بإدخال تكلفة القطع إلى النظام، حيث يتضمن هذا الحساب المبدئي للتكلفة وإدخالها بشكل صحيح لتكون متاحة في النظام

      graph LR; A[طلب إدخال تكلفة القطعة] --> B[حساب التكلفة] --> C[إدخال التكلفة] --> D[حفظ التكلفة]
      العنوانالتفاصيل
      المستخدممحل قطع الغيار
      الشروط المسبقة
      • إدخال مواصفات القطعة المطلوبة
      • التحقق من توفر القطعة المطلوبة
      الشروط اللاحقة
      • تكلفة القطعة مدخلة ومخزنة في النظام
      • تحديث حالة الطلب لتشمل تكلفة القطعة
      تسلسل الأحداث
      • حساب التكلفة
      • إدخال التكلفة
      • حفظ التكلفة
      الخطوات البديلةإذا كانت تكلفة القطعة غير متوفرة مباشرة
      • محل قطع الغيار يتواصل مع المورد للحصول على تكلفة القطعة
      • محل قطع الغيار يدخل التكلفة المستلمة من المورد في النظام
      الخطوات الاستثنائيةإذا تم إدخال تكلفة غير صالحة
      • النظام يعرض رسالة خطأ للمحل تطلب إدخال تكلفة صحيحة
      • محل قطع الغيار يعيد إدخال تكلفة صحيحة
      القواعد التجارية
      • يجب أن تكون التكلفة المدخلة دقيقة وتعكس التكلفة الحقيقية
      • لا يمكن إدخال تكلفة سالبة أو صفرية
      الافتراضات
      • محل قطع الغيار لديه الصلاحية لإدخال تكاليف القطع
      • البيانات المطلوبة متاحة وقت الإدخال
      المتطلبات الخاصة
      • واجهة سهلة الاستخدام للإدخال
      • التحقق الفوري من صحة البيانات المدخلة
      الملاحظات والمشاكل
      • قد تحتاج الواجهة إلى تحسينات لضمان سرعة ودقة الإدخال
      • التأكد من تدريب المستخدمين على عملية الإدخال
      المدخلاتمواصفات القطعة | تكلفة القطعة |
      المخرجات
      • تكلفة القطعة المدخلة
      تفاعلات المستخدم
      • واجهة إدخال التكاليف
      • رسائل الخطأ
      الشروط الخاصة
      • قطع غير متوفرة أو تكاليف متغيرة
      سيناريوهات الاستخدام
      • محل قطع الغيار يقوم بإدخال تكلفة قطع جديدة
      • محل قطع الغيار يعدل تكلفة قطع مدخلة سابقًا
      متطلبات الأمان
      • يجب تسجيل الدخول للتحقق من الهوية
      • إدخال البيانات يجب أن يتم عبر اتصال آمن
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام المخزون للحصول على توفر القطع
      • التكامل مع نظام الطلبات لتحديث حالة الطلب
      القيود والافتراضات
      • العملية تعتمد على دقة حساب التكلفة من قبل المحل
      • قد تتطلب قطع معينة موافقات إضافية
      متطلبات الاختبار
      • اختبارات وظيفية لإدخال التكلفة
      • اختبارات أمان للتأكد من حماية البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /api/parts/cost
      Request Headers
      Authorization: Bearer token

      Request Body

      part_id: integer cost: decimal

      Response

      الحالةالمحتوى
      200status: نص message: تكلفة القطعة تم إدخالها بنجاح
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      إدخال تكلفة القطعة

      • form
        • number
          • العنوان : تكلفة القطعة
          • التحقق : required|numeric|min:0.01
      • رسالة زر الإرسال: إدخال التكلفة
      • رسالة النجاح: تم إدخال تكلفة القطعة بنجاح
      • إعادة توجيه النجاح: تكلفة القطعة
      الاشعارات

      العنوان : تكلفة جديدة للقطعة
      الرسالة : تم إدخال تكلفة جديدة للقطعة بنجاح
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : مدير المخزون

      3.31.2.3- تقوم المنصة بحساب رسوم الخدمة وإضافتها للتكلفة الإجمالية بعد استلام مواصفات وتكلفة القطعة من محل قطع الغيار

      graph LR; A[إدخال مواصفات وتكلفة القطعة] --> B[استلام البيانات] --> C[حساب رسوم الخدمة] --> D[إضافة الرسوم للتكلفة الإجمالية] --> E[عرض التكلفة الإجمالية]
      العنوانالتفاصيل
      المستخدمالمنصة
      الشروط المسبقة
      • إدخال مواصفات القطعة من قبل محل قطع الغيار
      • إدخال تكلفة القطعة من قبل محل قطع الغيار
      • التحقق من صحة البيانات المدخلة
      الشروط اللاحقة
      • حساب رسوم الخدمة بدقة
      • إضافة رسوم الخدمة إلى التكلفة الإجمالية للقطعة
      • عرض التكلفة الإجمالية متضمنة رسوم الخدمة على محل قطع الغيار
      تسلسل الأحداث
      • استلام مواصفات وتكلفة القطعة
      • التحقق من صحة البيانات
      • حساب رسوم الخدمة
      • عرض التكلفة الإجمالية
      الخطوات البديلةإذا كانت البيانات المدخلة غير صحيحة
      • النظام يعرض رسالة خطأ توضح البيانات المطلوبة
      • محل قطع الغيار يقوم بتصحيح البيانات وإعادة إدخالها
      الخطوات الاستثنائيةإذا فشل النظام في حساب رسوم الخدمة
      • النظام يعرض رسالة خطأ توضح المشكلة
      • النظام يسجل الخطأ للمعالجة اللاحقة
      • محل قطع الغيار يعيد المحاولة أو يتواصل مع الدعم الفني
      القواعد التجارية
      • رسوم الخدمة تُحسب كنسبة مئوية من تكلفة القطعة
      • النظام يجب أن يستخدم معدلات رسوم الخدمة المحدثة باستمرار
      الافتراضات
      • البيانات المدخلة من قبل محل قطع الغيار دقيقة وصحيحة
      • النظام متصل بقاعدة البيانات بشكل صحيح
      المتطلبات الخاصة
      • واجهة سهلة الاستخدام لعرض رسوم الخدمة
      • التحقق الفوري من صحة البيانات المدخلة
      الملاحظات والمشاكل
      • يجب التأكد من تحديث معدلات رسوم الخدمة بشكل دوري
      • قد تحتاج الواجهة إلى تحسينات لضمان سرعة ودقة العرض
      المدخلاتمواصفات القطعة | تكلفة القطعة |
      المخرجات
      • رسوم الخدمة
      • التكلفة الإجمالية
      تفاعلات المستخدم
      • واجهة عرض رسوم الخدمة
      • رسائل الخطأ
      الشروط الخاصة
      • تكلفة القطعة تتغير بعد إدخالها لأول مرة
      سيناريوهات الاستخدام
      • المنصة تحسب رسوم الخدمة لقطعة جديدة
      • المنصة تحسب رسوم الخدمة لقطعة معدلة
      متطلبات الأمان
      • يجب تسجيل الدخول للتحقق من الهوية
      • حماية البيانات المدخلة وضمان سرية الحسابات
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام المخزون للحصول على مواصفات القطعة
      • التكامل مع نظام الفواتير لتحديث التكلفة الإجمالية
      القيود والافتراضات
      • العملية تعتمد على دقة البيانات المدخلة من قبل المحل
      • قد تتطلب بعض الحالات موافقات إضافية
      متطلبات الاختبار
      • اختبارات وظيفية لحساب رسوم الخدمة
      • اختبارات أمان للتأكد من حماية البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /api/service/fees
      Request Headers
      Authorization: Bearer token

      Request Body

      part_id: integer part_cost: decimal

      Response

      الحالةالمحتوى
      200status: نص service_fee: decimal total_cost: decimal
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      عرض رسوم الخدمة

      • table
        • الاسم : مواصفات القطعة
        • نوع المحتوي : text

        • الاسم : تكلفة القطعة
        • نوع المحتوي : currency

        • الاسم : رسوم الخدمة
        • نوع المحتوي : currency

        • الاسم : التكلفة الإجمالية
        • نوع المحتوي : currency

      الاشعارات

      العنوان : رسوم الخدمة الجديدة
      الرسالة : تم حساب رسوم الخدمة وإضافتها للتكلفة الإجمالية
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : محل قطع الغيار

      3.31.2.4- يتم احتساب الضريبة على رسوم الخدمة المقررة وإضافتها للتكلفة الإجمالية بعد حساب رسوم الخدمة

      graph LR; A[حساب رسوم الخدمة] --> B[التحقق من صحة رسوم الخدمة] --> C[حساب الضريبة] --> D[إضافة الضريبة للتكلفة الإجمالية] --> E[عرض التكلفة الإجمالية]
      العنوانالتفاصيل
      المستخدمالمنصة
      الشروط المسبقة
      • حساب رسوم الخدمة
      • التأكد من صحة رسوم الخدمة
      الشروط اللاحقة
      • حساب الضريبة بدقة
      • إضافة الضريبة إلى التكلفة الإجمالية
      • عرض التكلفة الإجمالية متضمنة الضريبة على محل قطع الغيار
      تسلسل الأحداث
      • التحقق من رسوم الخدمة
      • حساب الضريبة
      • إضافة الضريبة للتكلفة الإجمالية
      • عرض التكلفة الإجمالية
      الخطوات البديلةإذا كانت رسوم الخدمة غير صحيحة
      • النظام يعرض رسالة خطأ توضح المشكلة
      • محل قطع الغيار يقوم بتصحيح رسوم الخدمة
      • النظام يعيد حساب الضريبة بعد تصحيح رسوم الخدمة
      الخطوات الاستثنائيةإذا فشل النظام في حساب الضريبة
      • النظام يعرض رسالة خطأ توضح المشكلة
      • النظام يسجل الخطأ للمعالجة اللاحقة
      • محل قطع الغيار يعيد المحاولة أو يتواصل مع الدعم الفني
      القواعد التجارية
      • الضريبة تُحسب كنسبة مئوية من رسوم الخدمة
      • النظام يجب أن يستخدم النسبة الضريبية المحدثة باستمرار
      الافتراضات
      • رسوم الخدمة المدخلة صحيحة ودقيقة
      • النظام متصل بقاعدة البيانات بشكل صحيح
      المتطلبات الخاصة
      • واجهة سهلة الاستخدام لعرض الضريبة المقررة
      • التحقق الفوري من صحة رسوم الخدمة قبل حساب الضريبة
      الملاحظات والمشاكل
      • يجب التأكد من تحديث النسبة الضريبية بشكل دوري
      • قد تحتاج الواجهة إلى تحسينات لضمان سرعة ودقة العرض
      المدخلاترسوم الخدمة |
      المخرجات
      • الضريبة المقررة
      • التكلفة الإجمالية
      تفاعلات المستخدم
      • واجهة عرض الضريبة المقررة
      • رسائل الخطأ
      الشروط الخاصة
      • تغيير نسبة الضريبة بعد حساب رسوم الخدمة
      سيناريوهات الاستخدام
      • المنصة تحسب الضريبة على رسوم خدمة جديدة
      • المنصة تحسب الضريبة على رسوم خدمة معدلة
      متطلبات الأمان
      • يجب تسجيل الدخول للتحقق من الهوية
      • حماية البيانات المدخلة وضمان سرية الحسابات
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام الفواتير لتحديث التكلفة الإجمالية
      • التكامل مع نظام الضرائب لتحديث النسب الضريبية
      القيود والافتراضات
      • العملية تعتمد على دقة رسوم الخدمة المدخلة
      • قد تتطلب بعض الحالات موافقات إضافية
      متطلبات الاختبار
      • اختبارات وظيفية لحساب الضريبة
      • اختبارات أمان للتأكد من حماية البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /api/tax/calculate
      Request Headers
      Authorization: Bearer token

      Request Body

      service_fee: decimal

      Response

      الحالةالمحتوى
      200status: نص tax: decimal total_cost: decimal
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      عرض الضريبة المقررة

      • table
        • الاسم : رسوم الخدمة
        • نوع المحتوي : currency

        • الاسم : الضريبة المقررة
        • نوع المحتوي : currency

        • الاسم : التكلفة الإجمالية
        • نوع المحتوي : currency

      الاشعارات

      العنوان : الضريبة الجديدة على رسوم الخدمة
      الرسالة : تم حساب الضريبة وإضافتها للتكلفة الإجمالية
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : محل قطع الغيار

      3.31.2.5- يتم عرض صافي المبلغ المستحق للمحل بعد خصم الرسوم والضريبة من تكلفة القطعة

      graph LR; A[حساب رسوم الخدمة] --> B[حساب الضريبة] --> C[جمع البيانات] --> D[حساب صافي المبلغ] --> E[عرض صافي المبلغ]
      العنوانالتفاصيل
      المستخدمالمنصة
      الشروط المسبقة
      • حساب رسوم الخدمة
      • حساب الضريبة
      • التأكد من صحة حساب رسوم الخدمة والضريبة
      الشروط اللاحقة
      • حساب صافي المبلغ المستحق بدقة
      • عرض صافي المبلغ المستحق لمحل قطع الغيار
      تسلسل الأحداث
      • جمع بيانات التكلفة، الرسوم، والضريبة
      • حساب صافي المبلغ المستحق
      • عرض صافي المبلغ المستحق
      الخطوات البديلةإذا كانت البيانات المدخلة غير صحيحة
      • النظام يعرض رسالة خطأ توضح البيانات المطلوبة
      • محل قطع الغيار يقوم بتصحيح البيانات وإعادة إدخالها
      الخطوات الاستثنائيةإذا فشل النظام في حساب صافي المبلغ المستحق
      • النظام يعرض رسالة خطأ توضح المشكلة
      • النظام يسجل الخطأ للمعالجة اللاحقة
      • محل قطع الغيار يعيد المحاولة أو يتواصل مع الدعم الفني
      القواعد التجارية
      • صافي المبلغ المستحق يُحسب بطرح مجموع الرسوم والضريبة من تكلفة القطعة
      • النظام يجب أن يستخدم بيانات رسوم الخدمة والضريبة المحدثة باستمرار
      الافتراضات
      • البيانات المدخلة من قبل محل قطع الغيار دقيقة وصحيحة
      • النظام متصل بقاعدة البيانات بشكل صحيح
      المتطلبات الخاصة
      • واجهة سهلة الاستخدام لعرض صافي المبلغ المستحق
      • التحقق الفوري من صحة البيانات المدخلة
      الملاحظات والمشاكل
      • يجب التأكد من تحديث بيانات الرسوم والضريبة بشكل دوري
      • قد تحتاج الواجهة إلى تحسينات لضمان سرعة ودقة العرض
      المدخلاتتكلفة القطعة | رسوم الخدمة | الضريبة |
      المخرجات
      • صافي المبلغ المستحق
      تفاعلات المستخدم
      • واجهة عرض صافي المبلغ المستحق
      • رسائل الخطأ
      الشروط الخاصة
      • تغيير تكلفة القطعة بعد حساب الرسوم والضريبة
      سيناريوهات الاستخدام
      • المنصة تعرض صافي المبلغ المستحق لقطعة جديدة
      • المنصة تعرض صافي المبلغ المستحق لقطعة معدلة
      متطلبات الأمان
      • يجب تسجيل الدخول للتحقق من الهوية
      • حماية البيانات المدخلة وضمان سرية الحسابات
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام الفواتير لتحديث صافي المبلغ المستحق
      • التكامل مع نظام الضرائب لتحديث النسب الضريبية
      القيود والافتراضات
      • العملية تعتمد على دقة البيانات المدخلة من قبل المحل
      • قد تتطلب بعض الحالات موافقات إضافية
      متطلبات الاختبار
      • اختبارات وظيفية لحساب صافي المبلغ المستحق
      • اختبارات أمان للتأكد من حماية البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /api/net-amount/calculate
      Request Headers
      Authorization: Bearer token

      Request Body

      part_cost: decimal service_fee: decimal tax: decimal

      Response

      الحالةالمحتوى
      200status: نص net_amount: decimal
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      عرض صافي المبلغ المستحق

      • table
        • الاسم : تكلفة القطعة
        • نوع المحتوي : currency

        • الاسم : رسوم الخدمة
        • نوع المحتوي : currency

        • الاسم : الضريبة
        • نوع المحتوي : currency

        • الاسم : صافي المبلغ المستحق
        • نوع المحتوي : currency

      الاشعارات

      العنوان : صافي المبلغ المستحق
      الرسالة : تم حساب وعرض صافي المبلغ المستحق بعد خصم الرسوم والضريبة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : محل قطع الغيار

      3.31.2.6- يقوم محل قطع الغيار بمراجعة صافي المبلغ المستحق، ثم يوافق على العرض ويرسله إلى طالب الخدمة

      graph LR; A[استلام صافي المبلغ المستحق] --> B[مراجعة صافي المبلغ] --> C[الموافقة على العرض] --> D[إرسال العرض] --> E[تحديث حالة الطلب]
      العنوانالتفاصيل
      المستخدممحل قطع الغيار
      الشروط المسبقة
      • استلام صافي المبلغ المستحق من النظام
      • التحقق من صحة صافي المبلغ المستحق
      الشروط اللاحقة
      • إرسال العرض إلى طالب الخدمة
      • تحديث حالة الطلب في النظام
      تسلسل الأحداث
      • عرض صافي المبلغ المستحق
      • مراجعة صافي المبلغ المستحق
      • الموافقة على العرض
      • إرسال العرض
      • تحديث حالة الطلب
      الخطوات البديلةإذا كان محل قطع الغيار غير راضٍ عن صافي المبلغ المستحق
      • محل قطع الغيار يعيد النظر في البيانات المدخلة
      • محل قطع الغيار يقوم بإجراء تعديلات ضرورية
      • النظام يعيد حساب صافي المبلغ المستحق
      • محل قطع الغيار يراجع المبلغ المستحق المعدل ويوافق عليه
      الخطوات الاستثنائيةإذا فشل النظام في إرسال العرض
      • النظام يعرض رسالة خطأ توضح المشكلة
      • النظام يسجل الخطأ للمعالجة اللاحقة
      • محل قطع الغيار يعيد المحاولة أو يتواصل مع الدعم الفني
      القواعد التجارية
      • يجب أن يكون العرض المرسل دقيقاً ويعكس صافي المبلغ المستحق
      • يجب أن يتم تأكيد الإرسال وتحديث حالة الطلب
      الافتراضات
      • البيانات المدخلة من قبل محل قطع الغيار دقيقة وصحيحة
      • النظام متصل بقاعدة البيانات بشكل صحيح
      المتطلبات الخاصة
      • واجهة سهلة الاستخدام لإرسال العرض
      • التحقق الفوري من صحة البيانات المدخلة
      الملاحظات والمشاكل
      • يجب التأكد من تحديث حالة الطلب بعد إرسال العرض
      • قد تحتاج الواجهة إلى تحسينات لضمان سرعة ودقة الإرسال
      المدخلاتصافي المبلغ المستحق |
      المخرجات
      • عرض مرسل إلى طالب الخدمة
      • تحديث حالة الطلب
      تفاعلات المستخدم
      • واجهة مراجعة وإرسال العرض
      • رسائل التأكيد والخطأ
      الشروط الخاصة
      • تغيير صافي المبلغ المستحق قبل إرسال العرض
      سيناريوهات الاستخدام
      • محل قطع الغيار يرسل عرض لطلب جديد
      • محل قطع الغيار يرسل عرض لطلب معدل
      متطلبات الأمان
      • يجب تسجيل الدخول للتحقق من الهوية
      • حماية البيانات المدخلة وضمان سرية الحسابات
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام الطلبات لتحديث حالة الطلب
      • التكامل مع نظام الفواتير لتسجيل العرض المرسل
      القيود والافتراضات
      • العملية تعتمد على دقة البيانات المدخلة من قبل المحل
      • قد تتطلب بعض الحالات موافقات إضافية
      متطلبات الاختبار
      • اختبارات وظيفية لإرسال العرض
      • اختبارات أمان للتأكد من حماية البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /api/offer/send
      Request Headers
      Authorization: Bearer token

      Request Body

      net_amount: decimal service_request_id: integer

      Response

      الحالةالمحتوى
      200status: نص message: تم إرسال العرض بنجاح
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      إرسال العرض

      • form
        • number
          • العنوان : صافي المبلغ المستحق
          • التحقق : required|numeric|min:0.01
      • رسالة زر الإرسال: إرسال العرض
      • رسالة النجاح: تم إرسال العرض بنجاح
      • إعادة توجيه النجاح: حالة الطلب
      الاشعارات

      العنوان : عرض جديد
      الرسالة : تم إرسال عرض جديد من محل قطع الغيار
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : طالب الخدمة

      3.31.2.7- في حالة عدم القدرة على تقديم القطعة المطلوبة، يمكن لمحل قطع الغيار إرسال رسالة نصية للعميل تشرح السبب وتوضح الخيارات المتاحة

      graph LR; A[اكتشاف عدم توفر القطعة] --> B[تحديد سبب عدم التوفر] --> C[كتابة رسالة نصية] --> D[إرسال الرسالة]
      العنوانالتفاصيل
      المستخدممحل قطع الغيار
      الشروط المسبقة
      • عدم توفر القطعة المطلوبة
      • تحديد سبب عدم توفر القطعة
      الشروط اللاحقة
      • إبلاغ العميل بعدم توفر القطعة المطلوبة
      • توضيح الخيارات البديلة إن وجدت
      تسلسل الأحداث
      • اكتشاف عدم توفر القطعة
      • تحديد سبب عدم توفر القطعة
      • كتابة رسالة نصية توضح السبب
      • إرسال الرسالة النصية
      الخطوات البديلةإذا كان هناك قطعة بديلة متاحة
      • محل قطع الغيار يقترح القطعة البديلة في الرسالة النصية
      • محل قطع الغيار يرسل الرسالة النصية للعميل مع الاقتراح البديل
      الخطوات الاستثنائيةإذا فشل النظام في إرسال الرسالة النصية
      • النظام يعرض رسالة خطأ توضح المشكلة
      • النظام يسجل الخطأ للمعالجة اللاحقة
      • محل قطع الغيار يعيد المحاولة أو يتواصل مع الدعم الفني
      القواعد التجارية
      • الرسالة النصية يجب أن تكون واضحة وتحتوي على السبب والخطوات التالية
      • يجب إرسال الرسالة فور اكتشاف عدم توفر القطعة
      الافتراضات
      • البيانات المدخلة من قبل محل قطع الغيار دقيقة وصحيحة
      • النظام متصل بشبكة الاتصالات بشكل صحيح
      المتطلبات الخاصة
      • واجهة سهلة الاستخدام لكتابة وإرسال الرسالة النصية
      • التأكد الفوري من إرسال الرسالة
      الملاحظات والمشاكل
      • يجب التأكد من تحديث قاعدة البيانات بخصوص توفر القطع
      • قد تحتاج الواجهة إلى تحسينات لضمان سرعة ودقة إرسال الرسائل
      المدخلاتسبب عدم توفر القطعة |
      المخرجات
      • رسالة نصية توضح السبب والخطوات التالية
      تفاعلات المستخدم
      • واجهة كتابة وإرسال الرسائل النصية
      • رسائل التأكيد والخطأ
      الشروط الخاصة
      • اقتراح قطعة بديلة في حالة عدم توفر القطعة المطلوبة
      سيناريوهات الاستخدام
      • محل قطع الغيار يكتشف عدم توفر قطعة محددة ويبلغ العميل
      • محل قطع الغيار يقترح قطعة بديلة عند عدم توفر القطعة المطلوبة
      متطلبات الأمان
      • يجب تسجيل الدخول للتحقق من الهوية
      • حماية بيانات العميل وضمان سرية الرسائل
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام المخزون للتحقق من توفر القطع
      • التكامل مع نظام الاتصالات لإرسال الرسائل النصية
      القيود والافتراضات
      • العملية تعتمد على دقة بيانات المخزون
      • قد تتطلب بعض الحالات موافقات إضافية
      متطلبات الاختبار
      • اختبارات وظيفية لإرسال الرسائل النصية
      • اختبارات أمان للتأكد من حماية البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /api/notification/send-sms
      Request Headers
      Authorization: Bearer token

      Request Body

      phone_number: نص message: نص

      Response

      الحالةالمحتوى
      200status: نص message_id: نص
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      إرسال رسالة نصية

      • form
        • text
          • العنوان : رقم الهاتف
          • التحقق : required|numeric
        • textarea
          • العنوان : الرسالة
          • التحقق : required|max:160
      • رسالة زر الإرسال: إرسال الرسالة
      • رسالة النجاح: تم إرسال الرسالة بنجاح
      • إعادة توجيه النجاح: حالة الطلب
      الاشعارات

      العنوان : عدم توفر القطعة المطلوبة
      الرسالة : نعتذر، القطعة المطلوبة غير متوفرة حالياً. السبب: {{سبب عدم التوفر}}
      عن طريق : SMS  المستقبل : العميل

      3.32 - الموافقة على طلب قطع غيار

      3.32.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • تمكين العميل من الاختيار بين العروض المتعددة والقدرة على الموافقة على العرض الأمثل بناءً على الأجر، المتوقع، والوقت اللازم للإصلاح.
      الجهات المعنية
      • العميل
      • المنصة
      الخطوات الرئيسية
      • العميل يستعرض كافة العروض المستلمة من محلات قطع الغيار
      • العميل ينظر إلى تفاصيل العروض بما في ذلك أجرة قطع الغيار (تكون رقم واحد شاملة أجرة قطع الغيار والرسوم والضريبة)، المسافة إلى محل قطع الغيار، والوقت المتوقع للاستجابة
      • العميل يختار العرض الأكثر ملاءمة ويرسل موافقته على التطبيق
      • المنصة تحسب التكلفة الإجمالية للخدمة بما في ذلك أجرة قطع الغيار، رسوم خدمة المنصة، ورسوم الضريبة على الخدمة
      • يتم إبلاغ العميل بالتكلفة الإجمالية ويتم طلب موافقته النهائية
      الخطوات البديلة
      • في حالة عدم موافقة العميل على التكلفة الإجمالية، يمكنه العودة لمرحلة اختيار العرض واختيار عرض آخر
      قصص المستخدمين
      • كعميل: أريد القدرة على رؤية كافة العروض المتاحة، مع تفاصيل كل عرض، واختصار الخيارات بناءً على الأحكام والمصلحة الشخصية، والقدرة على الموافقة أو الرفض
      • كاداري للمنصة: أريد توفير نظام بسيط وواضح يمكن من خلاله المستخدم من اختيار العرض الأمثل والتأكد من وضوح وشفافية الرسوم المستخدمة
      مؤشرات الأداء
      • إجمالي عدد الطلبات المقبولة و نسبتها لإجمالي عدد الطلبات التي تم إنشاؤها
      • تكاليف اجرة قطع الغيار وتفاصيلها من حيث الرسوم وغيره

      3.32.2 حالات الاستخدام

      3.32.2.1- العميل يستعرض كافة العروض المستلمة من محلات قطع الغيار عبر التطبيق، حيث يمكنه رؤية جميع التفاصيل المتعلقة بكل عرض

      graph LR; A[فتح التطبيق] --> B[الانتقال إلى صفحة العروض المستلمة] --> C[عرض قائمة العروض] --> D[استعراض تفاصيل العروض]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • استلام عروض من محلات قطع الغيار
      • تسجيل الدخول إلى التطبيق
      الشروط اللاحقة
      • العميل لديه قائمة بالعروض المفصلة
      • العميل يمكنه مقارنة العروض واتخاذ قرار
      تسلسل الأحداث
      • فتح التطبيق
      • الانتقال إلى صفحة العروض المستلمة
      • عرض قائمة العروض
      • استعراض تفاصيل العروض
      الخطوات البديلةإذا لم يستلم العميل أي عروض
      • النظام يعرض رسالة توضح عدم وجود عروض حالياً
      • العميل يمكنه العودة إلى الصفحة الرئيسية
      الخطوات الاستثنائيةإذا فشل النظام في تحميل العروض
      • النظام يعرض رسالة خطأ توضح المشكلة
      • النظام يحاول إعادة تحميل العروض
      • إذا استمرت المشكلة، يمكن للعميل التواصل مع الدعم الفني
      القواعد التجارية
      • العروض يجب أن تكون محدثة ودقيقة
      • يجب عرض جميع التفاصيل المتعلقة بكل عرض
      الافتراضات
      • العميل لديه حساب مسجل في التطبيق
      • العروض المقدمة من المحلات محدثة وصحيحة
      المتطلبات الخاصة
      • واجهة سهلة الاستخدام لعرض العروض
      • التحديث الفوري للعروض عند فتح الصفحة
      الملاحظات والمشاكل
      • يجب التأكد من دقة وتحديث المعلومات المعروضة
      • قد تحتاج الواجهة إلى تحسينات لضمان سرعة ودقة العرض
      المدخلاتقائمة العروض المستلمة |
      المخرجات
      • عرض تفاصيل العروض
      تفاعلات المستخدم
      • واجهة عرض العروض
      • رسائل الخطأ في حالة فشل التحميل
      الشروط الخاصة
      • عدم وجود عروض مستلمة
      سيناريوهات الاستخدام
      • العميل يستعرض العروض الجديدة المستلمة
      • العميل يقارن بين عروض مختلفة لاتخاذ قرار
      متطلبات الأمان
      • يجب تسجيل الدخول للتحقق من الهوية
      • حماية بيانات العروض وضمان سرية الحسابات
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة العروض لتحديث العروض بشكل دوري
      • التكامل مع نظام الطلبات لتتبع حالة العروض
      القيود والافتراضات
      • العملية تعتمد على دقة البيانات المدخلة من قبل المحلات
      • قد تتطلب بعض الحالات موافقات إضافية
      متطلبات الاختبار
      • اختبارات وظيفية لعرض العروض
      • اختبارات أمان للتأكد من حماية البيانات
      تفاصيل ال API
      Method: GET || Endpoint: /api/offers/received
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص Offers : Array
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      صفحة العروض المستلمة

      • list
        • النوع : type: OfferCard Props : integer, نص, currency, currency, link

      الاشعارات

      العنوان : عروض جديدة مستلمة
      الرسالة : لديك عروض جديدة من محلات قطع الغيار. قم بتصفحها الآن!
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.32.2.2- العميل ينظر إلى تفاصيل العروض بما في ذلك أجرة قطع الغيار (تشمل أجرة قطع الغيار، الرسوم، والضريبة)، المسافة إلى محل قطع الغيار، والوقت المتوقع للاستجابة

      graph LR; A[فتح التطبيق] --> B[الانتقال إلى صفحة العروض المستلمة] --> C[اختيار عرض محدد] --> D[عرض تفاصيل العرض] --> E[قراءة تفاصيل العرض]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • العميل يستعرض العروض المقدمة
      • تسجيل الدخول إلى التطبيق
      الشروط اللاحقة
      • العميل لديه تفاصيل كاملة عن كل عرض
      • العميل يمكنه اتخاذ قرار مستنير بناءً على التفاصيل المقدمة
      تسلسل الأحداث
      • فتح التطبيق
      • الانتقال إلى صفحة العروض المستلمة
      • اختيار عرض محدد
      • عرض تفاصيل العرض
      • قراءة تفاصيل العرض
      الخطوات البديلةإذا لم يتمكن العميل من رؤية التفاصيل
      • النظام يعرض رسالة خطأ توضح المشكلة
      • النظام يحاول إعادة تحميل التفاصيل
      • إذا استمرت المشكلة، يمكن للعميل التواصل مع الدعم الفني
      الخطوات الاستثنائيةإذا فشل النظام في تحميل التفاصيل
      • النظام يعرض رسالة خطأ توضح المشكلة
      • النظام يسجل الخطأ للمعالجة اللاحقة
      • العميل يعيد المحاولة أو يتواصل مع الدعم الفني
      القواعد التجارية
      • التفاصيل المعروضة يجب أن تكون دقيقة ومحدثة
      • يجب عرض جميع التفاصيل المتعلقة بكل عرض
      الافتراضات
      • العميل لديه حساب مسجل في التطبيق
      • التفاصيل المقدمة من المحلات محدثة وصحيحة
      المتطلبات الخاصة
      • واجهة سهلة الاستخدام لعرض تفاصيل العروض
      • التحديث الفوري للتفاصيل عند فتح الصفحة
      الملاحظات والمشاكل
      • يجب التأكد من دقة وتحديث المعلومات المعروضة
      • قد تحتاج الواجهة إلى تحسينات لضمان سرعة ودقة العرض
      المدخلاتتفاصيل العرض المحدد |
      المخرجات
      • عرض تفاصيل العرض
      تفاعلات المستخدم
      • واجهة عرض تفاصيل العروض
      • رسائل الخطأ في حالة فشل التحميل
      الشروط الخاصة
      • عدم تمكن النظام من تحميل التفاصيل في الوقت المناسب
      سيناريوهات الاستخدام
      • العميل يستعرض تفاصيل عرض محدد لاتخاذ قرار
      • العميل يقارن بين تفاصيل العروض المختلفة
      متطلبات الأمان
      • يجب تسجيل الدخول للتحقق من الهوية
      • حماية بيانات العروض وضمان سرية الحسابات
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة العروض لتحديث تفاصيل العروض بشكل دوري
      • التكامل مع نظام الموقع الجغرافي لحساب المسافة إلى محل قطع الغيار
      القيود والافتراضات
      • العملية تعتمد على دقة البيانات المدخلة من قبل المحلات
      • قد تتطلب بعض الحالات موافقات إضافية
      متطلبات الاختبار
      • اختبارات وظيفية لعرض تفاصيل العروض
      • اختبارات أمان للتأكد من حماية البيانات
      تفاصيل ال API
      Method: GET || Endpoint: /api/offer/details
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص Offer_details : integer, نص, decimal, decimal, decimal, decimal, نص, نص, نص
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      صفحة تفاصيل العرض

      • list
        • النوع : "type": "DetailCard", "props": { "part_name": "نص", "total_cost": "currency", "service_fee": "currency", "tax": "currency", "net_amount": "currency", "distance_to_shop": "نص", "estimated_response_time": "نص", "details": "نص" }

      الاشعارات

      العنوان : تفاصيل العرض المستلم
      الرسالة : يمكنك الآن الاطلاع على تفاصيل العرض المستلم من محل قطع الغيار
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.32.2.3- العميل يختار العرض الأكثر ملاءمة من بين العروض المستلمة ويرسل موافقته عبر التطبيق إلى مقدم الخدمة

      graph LR; A[فتح التطبيق] --> B[الانتقال إلى صفحة العروض المستلمة] --> C[استعراض العروض] --> D[اختيار العرض المناسب] --> E[إرسال الموافقة] --> F[تحديث حالة الطلب]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • تسجيل الدخول إلى التطبيق
      • العميل يستعرض ويقارن بين العروض المختلفة
      الشروط اللاحقة
      • العرض المختار يتم إرساله إلى مقدم الخدمة
      • تحديث حالة الطلب في النظام
      تسلسل الأحداث
      • فتح التطبيق
      • الانتقال إلى صفحة العروض المستلمة
      • استعراض العروض
      • اختيار العرض المناسب
      • إرسال الموافقة
      • تحديث حالة الطلب
      الخطوات البديلةإذا لم يكن العميل راضياً عن أي من العروض
      • العميل يغلق صفحة العروض المستلمة
      • العميل يمكنه طلب عروض جديدة أو التعديل في طلبه
      الخطوات الاستثنائيةإذا فشل النظام في إرسال الموافقة
      • النظام يعرض رسالة خطأ توضح المشكلة
      • النظام يحاول إعادة إرسال الموافقة
      • إذا استمرت المشكلة، يمكن للعميل التواصل مع الدعم الفني
      القواعد التجارية
      • العروض يجب أن تكون محدثة ودقيقة
      • يجب تأكيد استلام الموافقة من قبل مقدم الخدمة
      الافتراضات
      • العميل لديه حساب مسجل في التطبيق
      • العروض المقدمة من المحلات محدثة وصحيحة
      المتطلبات الخاصة
      • واجهة سهلة الاستخدام لاختيار وإرسال الموافقة على العروض
      • التحديث الفوري للعروض عند فتح الصفحة
      الملاحظات والمشاكل
      • يجب التأكد من دقة وتحديث المعلومات المعروضة
      • قد تحتاج الواجهة إلى تحسينات لضمان سرعة ودقة الإرسال
      المدخلاتالعرض المختار |
      المخرجات
      • موافقة مرسلة إلى مقدم الخدمة
      • تحديث حالة الطلب
      تفاعلات المستخدم
      • واجهة اختيار وإرسال الموافقة على العروض
      • رسائل التأكيد والخطأ في حالة فشل الإرسال
      الشروط الخاصة
      • عدم تمكن النظام من إرسال الموافقة في الوقت المناسب
      سيناريوهات الاستخدام
      • العميل يختار عرضاً جديداً ويوافق عليه
      • العميل يختار عرضاً معدلاً ويوافق عليه
      متطلبات الأمان
      • يجب تسجيل الدخول للتحقق من الهوية
      • حماية بيانات العروض وضمان سرية الحسابات
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة العروض لتحديث حالة العرض المختار
      • التكامل مع نظام الطلبات لتتبع حالة الطلب
      القيود والافتراضات
      • العملية تعتمد على دقة البيانات المدخلة من قبل المحلات
      • قد تتطلب بعض الحالات موافقات إضافية
      متطلبات الاختبار
      • اختبارات وظيفية لاختيار وإرسال الموافقة على العروض
      • اختبارات أمان للتأكد من حماية البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /api/offer/accept
      Request Headers
      Authorization: Bearer token

      Request Body

      offer_id: integer

      Response

      الحالةالمحتوى
      200status: نص message: تم إرسال الموافقة بنجاح
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      صفحة العروض المستلمة

      • list
        • النوع : type: OfferCard Props : integer, نص, currency, currency, link, Array

      الاشعارات

      العنوان : موافقة على العرض
      الرسالة : لقد تم إرسال موافقة العميل على العرض. قم بمتابعة الطلب الآن
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : مقدم الخدمة

      3.32.2.4- المنصة تحسب التكلفة الإجمالية للخدمة بما في ذلك أجرة قطع الغيار، رسوم خدمة المنصة، ورسوم الضريبة على الخدمة، وتعرضها للعميل للموافقة النهائية

      graph LR; A[استلام موافقة العميل على العرض] --> B[جمع بيانات العرض] --> C[حساب التكلفة الإجمالية] --> D[عرض التكلفة الإجمالية للعميل] --> E[استلام موافقة العميل النهائية] --> F[تحديث حالة الطلب]
      العنوانالتفاصيل
      المستخدمالمنصة
      الشروط المسبقة
      • العميل يرسل موافقته على العرض
      • استلام جميع التفاصيل اللازمة من العرض
      الشروط اللاحقة
      • عرض التكلفة الإجمالية للعميل للموافقة النهائية
      • تحديث حالة الطلب في النظام
      تسلسل الأحداث
      • استلام موافقة العميل على العرض
      • جمع بيانات العرض
      • حساب التكلفة الإجمالية
      • عرض التكلفة الإجمالية للعميل
      • استلام موافقة العميل النهائية
      • تحديث حالة الطلب
      الخطوات البديلةإذا لم يوافق العميل على التكلفة الإجمالية
      • العميل يرفض العرض
      • النظام يعرض خيارات أخرى للعميل
      الخطوات الاستثنائيةإذا فشل النظام في حساب التكلفة الإجمالية
      • النظام يعرض رسالة خطأ توضح المشكلة
      • النظام يحاول إعادة حساب التكلفة
      • إذا استمرت المشكلة، يمكن للعميل التواصل مع الدعم الفني
      القواعد التجارية
      • التكلفة الإجمالية يجب أن تكون دقيقة وتشمل جميع الرسوم والضرائب
      • يجب تأكيد استلام الموافقة النهائية من قبل العميل
      الافتراضات
      • البيانات المدخلة من قبل المحلات دقيقة وصحيحة
      • النظام متصل بجميع الخدمات اللازمة لحساب التكلفة الإجمالية
      المتطلبات الخاصة
      • واجهة سهلة الاستخدام لحساب وعرض التكلفة الإجمالية
      • التحديث الفوري للتكاليف عند موافقة العميل على العرض
      الملاحظات والمشاكل
      • يجب التأكد من دقة وتحديث المعلومات المعروضة
      • قد تحتاج الواجهة إلى تحسينات لضمان سرعة ودقة العرض
      المدخلاتتفاصيل العرض | أجرة قطع الغيار | رسوم الخدمة | رسوم الضريبة |
      المخرجات
      • التكلفة الإجمالية للعرض
      تفاعلات المستخدم
      • واجهة عرض التكلفة الإجمالية
      • رسائل التأكيد والخطأ في حالة فشل الحساب
      الشروط الخاصة
      • رفض العميل للتكلفة الإجمالية
      سيناريوهات الاستخدام
      • النظام يحسب التكلفة الإجمالية لعرض جديد
      • النظام يعرض التكلفة الإجمالية لعرض معدل
      متطلبات الأمان
      • يجب تسجيل الدخول للتحقق من الهوية
      • حماية بيانات الحساب وضمان سرية المعلومات
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة العروض لتحديث تفاصيل العرض
      • التكامل مع نظام الفواتير لحساب الرسوم والضريبة
      القيود والافتراضات
      • العملية تعتمد على دقة البيانات المدخلة من قبل المحلات
      • قد تتطلب بعض الحالات موافقات إضافية
      متطلبات الاختبار
      • اختبارات وظيفية لحساب التكلفة الإجمالية
      • اختبارات أمان للتأكد من حماية البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /api/total-cost/calculate
      Request Headers
      Authorization: Bearer token

      Request Body

      offer_id: integer part_cost: decimal service_fee: decimal tax: decimal

      Response

      الحالةالمحتوى
      200status: نص total_cost: decimal
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      صفحة التكلفة الإجمالية

      • form
        • Button
          • العنوان : موافقة
          • الخيارات : submitFinalApproval
      الاشعارات

      العنوان : التكلفة الإجمالية للعرض
      الرسالة : تم حساب التكلفة الإجمالية للعرض. برجاء الموافقة النهائية لإتمام الطلب
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.32.2.5- يتم إبلاغ العميل بالتكلفة الإجمالية للعرض عبر إشعار ويتم طلب موافقته النهائية لإتمام الطلب

      graph LR; A[حساب التكلفة الإجمالية للعرض] --> B[إرسال إشعار للعميل] --> C[استلام الإشعار من قبل العميل] --> D[عرض التكلفة الإجمالية للعميل] --> E[مراجعة التكلفة من قبل العميل] --> F[استلام موافقة العميل النهائية] --> G[تحديث حالة الطلب]
      العنوانالتفاصيل
      المستخدمالمنصة
      الشروط المسبقة
      • حساب التكلفة الإجمالية للعرض
      • التأكد من دقة جميع الرسوم والضرائب
      الشروط اللاحقة
      • استلام موافقة العميل النهائية
      • تحديث حالة الطلب في النظام
      تسلسل الأحداث
      • حساب التكلفة الإجمالية للعرض
      • إرسال إشعار للعميل
      • استلام الإشعار من قبل العميل
      • عرض التكلفة الإجمالية للعميل
      • مراجعة التكلفة من قبل العميل
      • استلام موافقة العميل النهائية
      • تحديث حالة الطلب
      الخطوات البديلةإذا لم يوافق العميل على التكلفة الإجمالية
      • العميل يرفض العرض
      • النظام يعرض خيارات أخرى للعميل
      الخطوات الاستثنائيةإذا فشل النظام في إرسال الإشعار
      • النظام يعرض رسالة خطأ توضح المشكلة
      • النظام يحاول إعادة إرسال الإشعار
      • إذا استمرت المشكلة، يمكن للعميل التواصل مع الدعم الفني
      القواعد التجارية
      • التكلفة الإجمالية يجب أن تكون دقيقة وتشمل جميع الرسوم والضرائب
      • يجب تأكيد استلام الموافقة النهائية من قبل العميل
      الافتراضات
      • البيانات المدخلة من قبل المحلات دقيقة وصحيحة
      • النظام متصل بجميع الخدمات اللازمة لحساب التكلفة الإجمالية
      المتطلبات الخاصة
      • واجهة سهلة الاستخدام لمراجعة وإرسال الموافقة على التكلفة الإجمالية
      • التحديث الفوري للتكاليف عند موافقة العميل على العرض
      الملاحظات والمشاكل
      • يجب التأكد من دقة وتحديث المعلومات المعروضة
      • قد تحتاج الواجهة إلى تحسينات لضمان سرعة ودقة العرض
      المدخلاتالتكلفة الإجمالية للعرض |
      المخرجات
      • موافقة العميل النهائية
      • تحديث حالة الطلب
      تفاعلات المستخدم
      • واجهة عرض التكلفة الإجمالية
      • رسائل التأكيد والخطأ في حالة فشل الإرسال
      الشروط الخاصة
      • رفض العميل للتكلفة الإجمالية
      سيناريوهات الاستخدام
      • النظام يرسل إشعار للعميل بالتكلفة الإجمالية لعرض جديد
      • النظام يرسل إشعار للعميل بالتكلفة الإجمالية لعرض معدل
      متطلبات الأمان
      • يجب تسجيل الدخول للتحقق من الهوية
      • حماية بيانات الحساب وضمان سرية المعلومات
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة العروض لتحديث تفاصيل العرض
      • التكامل مع نظام الفواتير لحساب الرسوم والضريبة
      القيود والافتراضات
      • العملية تعتمد على دقة البيانات المدخلة من قبل المحلات
      • قد تتطلب بعض الحالات موافقات إضافية
      متطلبات الاختبار
      • اختبارات وظيفية لإرسال الإشعارات
      • اختبارات أمان للتأكد من حماية البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /api/notification/send
      Request Headers
      Authorization: Bearer token

      Request Body

      user_id: integer message: نص

      Response

      الحالةالمحتوى
      200status: نص notification_id: نص
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      صفحة التكلفة الإجمالية

      • form
        • Button
          • العنوان : موافقة
          • الخيارات : submitFinalApproval
      الاشعارات

      العنوان : التكلفة الإجمالية للعرض
      الرسالة : تم حساب التكلفة الإجمالية للعرض. برجاء الموافقة النهائية لإتمام الطلب
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.32.2.6- في حالة عدم موافقة العميل على التكلفة الإجمالية، يمكنه العودة لمرحلة اختيار العرض واختيار عرض آخر من العروض المتاحة

      graph LR; A[رفض العرض الحالي] --> B[العودة لصفحة العروض] --> C[استعراض العروض المتاحة] --> D[اختيار عرض جديد] --> E[تحديث حالة الطلب]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • عدم موافقة العميل على التكلفة الإجمالية
      • تواجد عروض متعددة متاحة للعميل
      الشروط اللاحقة
      • اختيار عرض جديد من العروض المتاحة
      • تحديث حالة الطلب بناءً على العرض الجديد المختار
      تسلسل الأحداث
      • رفض العرض الحالي
      • العودة لصفحة العروض
      • استعراض العروض المتاحة
      • اختيار عرض جديد
      • تحديث حالة الطلب
      الخطوات البديلةإذا لم يجد العميل عرضاً آخر مناسب
      • العميل يمكنه طلب عروض جديدة
      • النظام يعرض رسالة توضح عدم توفر عروض جديدة حالياً
      الخطوات الاستثنائيةإذا فشل النظام في تحميل العروض المتاحة
      • النظام يعرض رسالة خطأ توضح المشكلة
      • النظام يحاول إعادة تحميل العروض
      • إذا استمرت المشكلة، يمكن للعميل التواصل مع الدعم الفني
      القواعد التجارية
      • العروض يجب أن تكون محدثة ودقيقة
      • يجب توفير واجهة سهلة للاختيار بين العروض
      الافتراضات
      • العميل لديه عروض متعددة متاحة
      • النظام متصل بجميع الخدمات اللازمة لتحديث العروض
      المتطلبات الخاصة
      • واجهة سهلة الاستخدام لرفض العرض الحالي واختيار عرض جديد
      • التحديث الفوري للعروض عند العودة إلى الصفحة
      الملاحظات والمشاكل
      • يجب التأكد من دقة وتحديث المعلومات المعروضة
      • قد تحتاج الواجهة إلى تحسينات لضمان سرعة ودقة العرض
      المدخلاتالعروض المتاحة |
      المخرجات
      • عرض جديد مختار
      • تحديث حالة الطلب
      تفاعلات المستخدم
      • واجهة رفض العرض الحالي واختيار عرض جديد
      • رسائل التأكيد والخطأ في حالة فشل التحميل
      الشروط الخاصة
      • عدم توفر عروض أخرى مناسبة
      سيناريوهات الاستخدام
      • العميل يرفض التكلفة الإجمالية ويختار عرضاً آخر
      • العميل يرفض التكلفة الإجمالية ويطلب عروض جديدة
      متطلبات الأمان
      • يجب تسجيل الدخول للتحقق من الهوية
      • حماية بيانات العروض وضمان سرية الحسابات
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة العروض لتحديث العروض المتاحة
      • التكامل مع نظام الطلبات لتتبع حالة الطلب
      القيود والافتراضات
      • العملية تعتمد على دقة البيانات المدخلة من قبل المحلات
      • قد تتطلب بعض الحالات موافقات إضافية
      متطلبات الاختبار
      • اختبارات وظيفية لرفض العرض واختيار عرض جديد
      • اختبارات أمان للتأكد من حماية البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /api/offer/reject
      Request Headers
      Authorization: Bearer token

      Request Body

      offer_id: integer

      Response

      الحالةالمحتوى
      200status: نص message: تم رفض العرض بنجاح
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      Method: GET || Endpoint: /api/offers/available
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص Offers : Array
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      صفحة العروض المتاحة

      • list
        • النوع : type: OfferCard Props : integer, نص, currency, currency, link, Array

      الاشعارات

      العنوان : عرض جديد متاح
      الرسالة : يمكنك الآن اختيار عرض جديد من العروض المتاحة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.33 - إتمام صفقة قطع الغيار

      3.33.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • تأكيد التعاملات المالية وضمان الإتمام الناجح للعمليات، حيث يحتاج العميل للتأكد من أن لديه الأموال الكافية في المحفظة ويجب على المنصة حجز هذا المبلغ بعد إرسال كود التحقق حتى يتم الاتفاق النهائي على الصفقة.
      الجهات المعنية
      • العميل
      • المنصة
      الخطوات الرئيسية
      • العميل يتأكد من وجود المبلغ الكافي في المحفظة الخاصة به
      • إذا لم يكن المبلغ المتوافر كافياً، فإن العميل يقوم بإضافة الأموال من خلال واحدة من طرق الدفع الإلكترونية المتاحة
      • في حالة التحقق من كود التحقق يتم حجز المبلغ وتجميده في انتظار التأكيد النهائي على الصفقة
      • العميل يؤكد الصفقة، وعلى إثر ذلك يتم تنفيذ أوامر النقل
      • إذا تم طلب الإلغاء قبل بداية عملية التوصيل، يتم إعادة المبلغ المحجوز إلى المحفظة
      الخطوات البديلة
      • في حالة عدم توافر العميل على المبلغ المطلوب في المحفظة، يمكنه العودة لمرحلة اختيار العرض واختيار عرض آخر أو إلغاء العملية تماماً
      قصص المستخدمين
      • العميل، كمستخدم: أريد التحقق من أن القيمة المطلوبة متوفرة في المحفظة وإضافة المزيد إذا كان ذلك ضرورياً، وتأكيد الصفقة أو إلغائها حسب الحاجة
      • كاداري للمنصة: أريد ضمان توافر الأموال الكافية من قبل العميل قبل التأكيد النهائي على الصفقة وتوفير آلية لإلغاء الصفقة في حالة الحاجة
      مؤشرات الأداء
      • عدد الطلبات التي تمت الصفقة لها ونسبتها من إجمالي الطلبات التي تم الاستجابة لها
      • قيمة المبالغ المحجوزة

      3.33.2 حالات الاستخدام

      3.33.2.1- التحقق من وجود المبلغ الكافي في المحفظة الخاصة بالعميل لإتمام الصفقة

      graph LR; A[الدخول إلى الحساب] --> B[الانتقال إلى صفحة المحفظة] --> C[عرض رصيد المحفظة] --> D[التحقق من الرصيد] --> E{هل الرصيد كافٍ؟} --> |نعم| F[تأكيد كفاية الرصيد] --> G[إتمام الصفقة] E --> |لا| H[عرض رسالة عدم كفاية الرصيد] --> I[اقتراح إعادة شحن المحفظة]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • العميل لديه حساب على المنصة
      • العميل لديه محفظة مفعلة على المنصة
      الشروط اللاحقة
      • تأكيد وجود المبلغ الكافي في المحفظة
      تسلسل الأحداث
      • الدخول إلى الحساب
      • الانتقال إلى صفحة المحفظة
      • عرض رصيد المحفظة
      • التحقق من الرصيد
      • تأكيد كفاية الرصيد
      الخطوات البديلةإذا لم يكن الرصيد كافياً
      • النظام يعرض رسالة توضح أن الرصيد غير كافٍ
      • النظام يقترح خيارات لإعادة شحن المحفظة
      الخطوات الاستثنائيةإذا فشل النظام في عرض رصيد المحفظة
      • النظام يعرض رسالة خطأ توضح المشكلة
      • النظام يحاول إعادة تحميل رصيد المحفظة
      • إذا استمرت المشكلة، يمكن للعميل التواصل مع الدعم الفني
      القواعد التجارية
      • رصيد المحفظة يجب أن يكون محدثاً ودقيقاً
      • يجب توفير واجهة سهلة للاطلاع على رصيد المحفظة
      الافتراضات
      • العميل لديه محفظة مفعلة وحساب على المنصة
      • النظام متصل بجميع الخدمات اللازمة لتحديث رصيد المحفظة
      المتطلبات الخاصة
      • واجهة سهلة الاستخدام لعرض رصيد المحفظة
      • التحديث الفوري لرصيد المحفظة عند الاطلاع عليه
      الملاحظات والمشاكل
      • يجب التأكد من دقة وتحديث المعلومات المعروضة
      • قد تحتاج الواجهة إلى تحسينات لضمان سرعة ودقة العرض
      المدخلاتبيانات الحساب | رصيد المحفظة |
      المخرجات
      • رصيد المحفظة الحالي
      • رسالة تأكيد أو عدم كفاية الرصيد
      تفاعلات المستخدم
      • واجهة عرض رصيد المحفظة
      • رسائل التأكيد والخطأ في حالة فشل العرض
      الشروط الخاصة
      • عدم كفاية الرصيد في المحفظة
      سيناريوهات الاستخدام
      • العميل يرغب في التحقق من رصيد المحفظة قبل إتمام صفقة
      • العميل يرغب في معرفة الرصيد المتبقي في محفظته
      متطلبات الأمان
      • يجب تسجيل الدخول للتحقق من الهوية
      • حماية بيانات الحساب وضمان سرية المعلومات
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة المحفظة لتحديث الرصيد
      • التكامل مع نظام الدفع لإعادة شحن المحفظة
      القيود والافتراضات
      • العملية تعتمد على دقة البيانات المدخلة من قبل العميل
      • قد تتطلب بعض الحالات موافقات إضافية
      متطلبات الاختبار
      • اختبارات وظيفية لعرض رصيد المحفظة
      • اختبارات أمان للتأكد من حماية البيانات
      تفاصيل ال API
      Method: GET || Endpoint: /api/wallet/balance
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص balance: decimal
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      Method: POST || Endpoint: /api/wallet/recharge
      Request Headers
      Authorization: Bearer token

      Request Body

      amount: decimal payment_method: نص

      Response

      الحالةالمحتوى
      200status: نص new_balance: decimal
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      صفحة المحفظة

      • textblock
        • رصيد المحفظة الحالي

      • form
        • Number
          • العنوان : wallet-balance
          • التحقق : "value": "decimal"
        • Button
          • العنوان : إعادة شحن المحفظة
          • الخيارات : rechargeWallet
      الاشعارات

      العنوان : رصيد المحفظة غير كافٍ
      الرسالة : رصيد محفظتك غير كافٍ لإتمام الصفقة. يرجى إعادة شحن المحفظة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.33.2.2- إضافة الأموال إلى المحفظة في حالة عدم كفاية الرصيد لإتمام الصفقة، ثم تجميد المبلغ المطلوب في المحفظة

      graph LR; A[تحقق من عدم كفاية الرصيد] --> B[اختيار خيار إضافة الأموال] --> C[تحديد طريقة الدفع] --> D[إدخال تفاصيل الدفع] --> E[إتمام عملية الدفع] --> F[إضافة الأموال إلى المحفظة] --> G[تجميد المبلغ المطلوب]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • العميل لديه محفظة مفعلة على المنصة
      • العميل تحقق من أن رصيد المحفظة غير كافٍ لإتمام الصفقة
      الشروط اللاحقة
      • تمت إضافة الأموال إلى المحفظة
      • تم تجميد المبلغ المطلوب في المحفظة
      تسلسل الأحداث
      • اختيار خيار إضافة الأموال
      • تحديد طريقة الدفع
      • إدخال تفاصيل الدفع
      • إتمام عملية الدفع
      • إضافة الأموال إلى المحفظة
      • تجميد المبلغ المطلوب
      الخطوات البديلةإذا فشلت عملية الدفع
      • النظام يعرض رسالة خطأ توضح فشل عملية الدفع
      • النظام يقترح إعادة المحاولة أو اختيار طريقة دفع أخرى
      الخطوات الاستثنائيةإذا فشل النظام في إضافة الأموال إلى المحفظة
      • النظام يعرض رسالة خطأ توضح المشكلة
      • النظام يعيد المحاولة تلقائياً
      • إذا استمرت المشكلة، يمكن للعميل التواصل مع الدعم الفني
      القواعد التجارية
      • الأموال المضافة يجب أن تظهر فوراً في رصيد المحفظة
      • المبلغ المجمد يجب أن يكون مساوياً للمبلغ المطلوب لإتمام الصفقة
      الافتراضات
      • العميل لديه طرق دفع إلكترونية متاحة ومفعلة
      • النظام متصل بجميع خدمات الدفع اللازمة
      المتطلبات الخاصة
      • واجهة سهلة الاستخدام لإضافة الأموال إلى المحفظة
      • التحديث الفوري لرصيد المحفظة بعد إتمام عملية الدفع
      الملاحظات والمشاكل
      • يجب التأكد من دقة وسرعة عملية إضافة الأموال
      • قد تحتاج الواجهة إلى تحسينات لضمان سرعة ودقة الإضافة والتجميد
      المدخلاتتفاصيل الدفع | المبلغ المطلوب |
      المخرجات
      • رصيد المحفظة المحدث
      • المبلغ المجمد في المحفظة
      تفاعلات المستخدم
      • واجهة اختيار طريقة الدفع
      • رسائل التأكيد والخطأ في حالة فشل الدفع
      الشروط الخاصة
      • فشل عملية الدفع
      • عدم قدرة النظام على إضافة الأموال إلى المحفظة
      سيناريوهات الاستخدام
      • العميل يضيف أموالاً إلى المحفظة لإتمام صفقة جديدة
      • العميل يضيف أموالاً إلى المحفظة لزيادة رصيد المحفظة بشكل عام
      متطلبات الأمان
      • يجب تسجيل الدخول للتحقق من الهوية
      • حماية بيانات الدفع وضمان سرية المعلومات
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام الدفع الإلكتروني لإتمام عملية الدفع
      • التكامل مع نظام المحفظة لتحديث الرصيد وتجميد المبلغ المطلوب
      القيود والافتراضات
      • العملية تعتمد على دقة تفاصيل الدفع المدخلة من قبل العميل
      • قد تتطلب بعض الحالات موافقات إضافية
      متطلبات الاختبار
      • اختبارات وظيفية لإضافة الأموال وتجميد المبلغ
      • اختبارات أمان للتأكد من حماية بيانات الدفع
      تفاصيل ال API
      Method: POST || Endpoint: /api/wallet/recharge
      Request Headers
      Authorization: Bearer token

      Request Body

      amount: decimal payment_method: نص payment_details: object

      Response

      الحالةالمحتوى
      200status: نص new_balance: decimal
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      Method: POST || Endpoint: /api/wallet/freeze
      Request Headers
      Authorization: Bearer token

      Request Body

      amount: decimal

      Response

      الحالةالمحتوى
      200status: نص frozen_amount: decimal
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      صفحة إضافة الأموال

      • form
        • number
          • العنوان : المبلغ
          • التحقق : required|numeric|min:1
        • select
          • العنوان : طريقة الدفع
          • التحقق : required
          • الخيارات : ["بطاقة ائتمان","باي بال","حوالة بنكية"]
      • رسالة زر الإرسال: إضافة الأموال
      • رسالة النجاح: تم إضافة الأموال بنجاح
      • إعادة توجيه النجاح: صفحة المحفظة
      الاشعارات

      العنوان : إضافة الأموال إلى المحفظة
      الرسالة : تمت إضافة الأموال إلى محفظتك بنجاح. يمكنك الآن إتمام الصفقة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.33.2.3- تأكيد الصفقة من قبل العميل بعد التحقق من أن المبلغ المطلوب متوفر ومحجوز في المحفظة

      graph LR; A[استعراض تفاصيل الصفقة] --> B[الضغط على زر تأكيد الصفقة] --> C[التحقق من الرصيد المحجوز] --> D{هل الرصيد كافٍ؟} --> |نعم| E[بدء أوامر النقل] --> F[تأكيد الصفقة] D --> |لا| G[عرض رسالة عدم كفاية الرصيد] --> H[اقتراح إضافة أموال]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • المبلغ المطلوب متوفر في المحفظة
      • المبلغ محجوز في المحفظة
      الشروط اللاحقة
      • تم تأكيد الصفقة
      • بدأت أوامر النقل
      تسلسل الأحداث
      • استعراض تفاصيل الصفقة
      • الضغط على زر تأكيد الصفقة
      • التحقق من الرصيد المحجوز
      • بدء أوامر النقل
      الخطوات البديلةإذا كان الرصيد المحجوز غير كافٍ
      • النظام يعرض رسالة توضح عدم كفاية الرصيد المحجوز
      • النظام يقترح إضافة أموال إلى المحفظة
      الخطوات الاستثنائيةإذا فشل النظام في بدء أوامر النقل
      • النظام يعرض رسالة خطأ توضح المشكلة
      • النظام يحاول إعادة بدء أوامر النقل
      • إذا استمرت المشكلة، يمكن للعميل التواصل مع الدعم الفني
      القواعد التجارية
      • يجب أن يكون الرصيد المحجوز كافٍ لإتمام الصفقة
      • يجب بدء أوامر النقل فور تأكيد الصفقة
      الافتراضات
      • العميل لديه محفظة مفعلة وحساب على المنصة
      • النظام متصل بجميع الخدمات اللازمة للتحقق من الرصيد وبدء أوامر النقل
      المتطلبات الخاصة
      • واجهة سهلة الاستخدام لتأكيد الصفقة
      • التحديث الفوري لحالة الصفقة عند التأكيد
      الملاحظات والمشاكل
      • يجب التأكد من دقة وسرعة عملية التحقق من الرصيد وبدء أوامر النقل
      • قد تحتاج الواجهة إلى تحسينات لضمان سرعة ودقة التأكيد
      المدخلاتتفاصيل الصفقة | الرصيد المحجوز |
      المخرجات
      • تأكيد الصفقة
      • أوامر النقل
      تفاعلات المستخدم
      • واجهة استعراض تفاصيل الصفقة
      • رسائل التأكيد والخطأ في حالة فشل بدء أوامر النقل
      الشروط الخاصة
      • عدم كفاية الرصيد المحجوز
      سيناريوهات الاستخدام
      • العميل يؤكد الصفقة بعد التحقق من تفاصيلها
      • العميل يتابع حالة أوامر النقل بعد تأكيد الصفقة
      متطلبات الأمان
      • يجب تسجيل الدخول للتحقق من الهوية
      • حماية بيانات الصفقة وضمان سرية المعلومات
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام المحفظة للتحقق من الرصيد المحجوز
      • التكامل مع نظام النقل لبدء أوامر النقل
      القيود والافتراضات
      • العملية تعتمد على دقة تفاصيل الصفقة والرصيد المحجوز
      • قد تتطلب بعض الحالات موافقات إضافية
      متطلبات الاختبار
      • اختبارات وظيفية لتأكيد الصفقة وبدء أوامر النقل
      • اختبارات أمان للتأكد من حماية البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /api/transaction/confirm
      Request Headers
      Authorization: Bearer token

      Request Body

      transaction_id: integer wallet_id: integer

      Response

      الحالةالمحتوى
      200status: نص message: تم تأكيد الصفقة بنجاح
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      Method: POST || Endpoint: /api/transfer/start
      Request Headers
      Authorization: Bearer token

      Request Body

      transaction_id: integer

      Response

      الحالةالمحتوى
      200status: نص transfer_id: integer
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      صفحة تأكيد الصفقة

      • form
        • Button
          • العنوان : تأكيد الصفقة
          • الخيارات : confirmTransaction
      الاشعارات

      العنوان : تأكيد الصفقة
      الرسالة : تم تأكيد الصفقة بنجاح وبدأت أوامر النقل
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.33.2.4- إلغاء الصفقة من قبل العميل قبل بدء عملية التوصيل، وإعادة المبلغ المحجوز إلى المحفظة

      graph LR; A[اختيار خيار إلغاء الصفقة] --> B[التحقق من عدم بدء عملية التوصيل] --> C{هل التوصيل بدأ؟} --> |نعم| D[عرض رسالة عدم إمكانية الإلغاء] --> E[متابعة حالة التوصيل] C --> |لا| F[إلغاء الصفقة] --> G[إعادة المبلغ المحجوز إلى المحفظة]
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • الصفقة تم تأكيدها ولكن لم تبدأ عملية التوصيل
      • المبلغ محجوز في المحفظة
      الشروط اللاحقة
      • تم إلغاء الصفقة
      • تم إعادة المبلغ المحجوز إلى المحفظة
      تسلسل الأحداث
      • اختيار خيار إلغاء الصفقة
      • التحقق من عدم بدء عملية التوصيل
      • إلغاء الصفقة
      • إعادة المبلغ المحجوز إلى المحفظة
      الخطوات البديلةإذا كانت عملية التوصيل قد بدأت بالفعل
      • النظام يعرض رسالة توضح عدم إمكانية إلغاء الصفقة بعد بدء التوصيل
      • العميل يمكنه متابعة حالة التوصيل
      الخطوات الاستثنائيةإذا فشل النظام في إلغاء الصفقة
      • النظام يعرض رسالة خطأ توضح المشكلة
      • النظام يحاول إعادة إلغاء الصفقة
      • إذا استمرت المشكلة، يمكن للعميل التواصل مع الدعم الفني
      القواعد التجارية
      • يجب أن يكون إلغاء الصفقة متاحاً قبل بدء عملية التوصيل
      • يجب إعادة المبلغ المحجوز فوراً إلى المحفظة بعد الإلغاء
      الافتراضات
      • العميل لديه محفظة مفعلة وحساب على المنصة
      • النظام متصل بجميع الخدمات اللازمة لإلغاء الصفقة وإعادة المبلغ المحجوز
      المتطلبات الخاصة
      • واجهة سهلة الاستخدام لإلغاء الصفقة
      • التحديث الفوري لحالة الصفقة ورصيد المحفظة عند الإلغاء
      الملاحظات والمشاكل
      • يجب التأكد من دقة وسرعة عملية الإلغاء وإعادة المبلغ
      • قد تحتاج الواجهة إلى تحسينات لضمان سرعة ودقة الإلغاء
      المدخلاتتفاصيل الصفقة | المبلغ المحجوز |
      المخرجات
      • تأكيد إلغاء الصفقة
      • رصيد المحفظة المحدث
      تفاعلات المستخدم
      • واجهة إلغاء الصفقة
      • رسائل التأكيد والخطأ في حالة فشل الإلغاء
      الشروط الخاصة
      • بدء عملية التوصيل قبل الإلغاء
      سيناريوهات الاستخدام
      • العميل يلغي صفقة لم تبدأ عملية توصيلها
      • العميل يتابع حالة الصفقة بعد الإلغاء
      متطلبات الأمان
      • يجب تسجيل الدخول للتحقق من الهوية
      • حماية بيانات الصفقة وضمان سرية المعلومات
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام المحفظة للتحقق من المبلغ المحجوز وإعادته
      • التكامل مع نظام التوصيل للتحقق من حالة التوصيل
      القيود والافتراضات
      • العملية تعتمد على دقة تفاصيل الصفقة وحالة التوصيل
      • قد تتطلب بعض الحالات موافقات إضافية
      متطلبات الاختبار
      • اختبارات وظيفية لإلغاء الصفقة وإعادة المبلغ
      • اختبارات أمان للتأكد من حماية البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /api/transaction/cancel
      Request Headers
      Authorization: Bearer token

      Request Body

      transaction_id: integer

      Response

      الحالةالمحتوى
      200status: نص message: تم إلغاء الصفقة بنجاح refunded_amount: decimal
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      Method: GET || Endpoint: /api/transfer/status
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص delivery_status: نص
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      صفحة إلغاء الصفقة

      • form
        • Button
          • العنوان : إلغاء الصفقة
          • الخيارات : cancelTransaction
      الاشعارات

      العنوان : تم إلغاء الصفقة
      الرسالة : تم إلغاء الصفقة بنجاح وأعيد المبلغ المحجوز إلى محفظتك
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.34 - طلب توصيل قطعة غيار

      3.34.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • تسهيل عملية التوصيل لقطع الغيار من المحل إلى موقع طالب الخدمة
      الجهات المعنية
      • طالب الخدمة
      • المحل
      • النظام
      • المركبات
      الخطوات الرئيسية
      • إنشاء الطلب من قبل طالب الخدمة
      • استدعاء بيانات القطع وبيانات موقع الاستلام والتسليم ونشرها لكافة المركبات في محيط ٥٠ كم وتكون متجهة لنفس نقطة التسليم
      • استلام العروض من المركبات واستعراضها من قبل طالب الخدمة
      • إرسال العرض لطالب الخدمة
      • يتم قبول الطلب وحجز المبلغ الإجمالي بمجرد التأكيد على كود التحقق المرسل
      الخطوات البديلة
      • تحديد نطاقات مختلفة للمسافة والأسعار من قبل النظام بناءًا على المعايير المحددة
      • في حالة عدم وجود عرض مناسب، يمكن استحداث سلة لوضع الطلبات فيها وتكون هذه السلة قابلة للاستعراض من الناقلين حسب معايير محددة (وجهة الناقل، مكان تواجده وغيرها) بحيث يمكن للناقل عند الدخول لهذه السلة اختيار الطلبات التي تناسبه
      قصص المستخدمين
      • طالب الخدمة: كطالب خدمة, أريد أن أقوم بإنشاء طلب لتوصيل القطع المطلوبة من المحل إلى موقعي حتى يتم تأمين القطعة بأسرع وقت ممكن
      • كاداري للمنصة: كنظام, أريد أن أقوم باستدعاء بيانات القطع وموقع الاستلام والتسليم ونشرها لكافة المركبات في محيط ٥٠ كم (لا يوجد عروض في هذه المرحلة سيكون سعر التوصيل ثابت)
      • طالب الخدمة: كطالب خدمة, أريد أن أستلم العروض المقدمة من المركبات واستعراضها حتى أختار العرض الأنسب لي من حيث السرعة والتكلفة . في حالة توجد مركبات في نطاق 50كم من موقع الاستلام (لا يوجد عروض في هذه المرحلة سيكون سعر التوصيل ثابت)
      • طالب الخدمة: كطالب خدمة, أريد أن أقبل العرض وأتم الخدمة بالحجز على المبلغ الإجمالي حتى يتم تأمين الخدمة وبدء عملية النقل
      مؤشرات الأداء
      • عدد طلبات التوصيل و نسبتها من إجمالي الطلبات التي تمت (الموافقة عليها و تمت الصفقة عليها)
      • عدد المستجيبين للطلبات

      3.34.2 حالات الاستخدام

      3.34.2.1- إنشاء الطلب من قبل طالب الخدمة يتضمن عملية دخول طالب الخدمة إلى حسابه على المنصة واختيار خيار إنشاء طلب توصيل قطع غيار، حيث يقوم بإدخال تفاصيل القطع المطلوبة وتحديد موقع الاستلام والتسليم، ثم نشر الطلب على المنصة

      graph LR A[دخول طالب الخدمة إلى حسابه] --> B[اختيار خيار إنشاء طلب] B --> C[إدخال تفاصيل القطع المطلوبة] C --> D[تحديد موقع الاستلام والتسليم] D --> E[نشر الطلب]
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • يجب أن يكون لطالب الخدمة حساب مسجل على المنصة
      • يجب أن يكون طالب الخدمة بحاجة إلى توصيل قطع غيار
      الشروط اللاحقة
      • يتم إنشاء الطلب بنجاح
      تسلسل الأحداث
      • طالب الخدمة يدخل إلى حسابه
      • طالب الخدمة يختار خيار إنشاء طلب
      • طالب الخدمة يدخل تفاصيل الطلب
      • طالب الخدمة يحدد مواقع الاستلام والتسليم
      • طالب الخدمة ينشر الطلب
      الخطوات البديلةإذا لم يكن لدى طالب الخدمة حساب مسجل
      • طالب الخدمة يقوم بإنشاء حساب جديد على المنصة
      • بعد إنشاء الحساب، يعود طالب الخدمة إلى صفحة إنشاء الطلب
      إذا لم يكن لدى طالب الخدمة معلومات كافية حول القطع المطلوبة
      • طالب الخدمة يقوم بالبحث عن معلومات إضافية حول القطع
      • بعد الحصول على المعلومات اللازمة، يعود طالب الخدمة إلى صفحة إدخال تفاصيل القطع
      الخطوات الاستثنائيةإذا حدث خطأ أثناء نشر الطلب
      • النظام يعرض رسالة خطأ لطالب الخدمة توضح سبب الخطأ
      • طالب الخدمة يقوم بمحاولة نشر الطلب مرة أخرى بعد تصحيح الخطأ
      القواعد التجارية
      • يجب أن تتوفر كافة المعلومات المطلوبة عن القطع لضمان معالجة الطلب بشكل صحيح
      • يجب أن تكون مواقع الاستلام والتسليم دقيقة لضمان توصيل الطلب بنجاح
      الافتراضات
      • يتمتع طالب الخدمة بإمكانية الوصول إلى الإنترنت
      • طالب الخدمة لديه معرفة بكيفية استخدام المنصة
      المتطلبات الخاصة
      • يجب أن تكون واجهة المستخدم سهلة الاستخدام وتوفر إرشادات واضحة خلال عملية إنشاء الطلب
      الملاحظات والمشاكل
      • يجب مراقبة الطلبات المنشورة لضمان عدم وجود أي أخطاء أو معلومات ناقصة
      المدخلاتبيانات تسجيل الدخول لحساب طالب الخدمة | تفاصيل القطع المطلوبة | موقع الاستلام والتسليم |
      المخرجات
      • طلب جديد منشور على المنصة
      تفاعلات المستخدم
      • واجهة إنشاء الطلب
      • رسائل التأكيد والإشعارات
      الشروط الخاصة
      • إذا كان الموقع المحدد خارج نطاق التوصيل، يجب عرض رسالة تنبيه
      سيناريوهات الاستخدام
      • طالب الخدمة يحتاج إلى توصيل قطع غيار بشكل عاجل، فيقوم بإنشاء طلب عبر المنصة
      متطلبات الأمان
      • تأكد من حماية بيانات طالب الخدمة والمعلومات المتعلقة بالطلب
      التكامل مع الأنظمة الأخرى
      • نظام المخزون للتحقق من توفر القطع المطلوبة
      • نظام تحديد المواقع لتحديد مواقع الاستلام والتسليم بدقة
      القيود والافتراضات
      • يجب أن يكون النظام قادراً على التعامل مع عدد كبير من الطلبات في وقت واحد
      • يجب أن يتم التحقق من صحة البيانات المدخلة قبل نشر الطلب
      متطلبات الاختبار
      • اختبارات وظيفية لضمان أن جميع خطوات إنشاء الطلب تعمل بشكل صحيح
      • اختبارات الأمان لحماية بيانات المستخدم
      تفاصيل ال API
      Method: POST || Endpoint: /create-order
      Request Headers
      Authorization: نص

      Request Body

      account_id: نص part_details: object pickup_location: نص delivery_location: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة إنشاء الطلب

      • textblock
        • إنشاء طلب جديد لتوصيل قطع غيار

      • form
        • text
          • العنوان : تفاصيل القطع المطلوبة
          • التحقق : required: 1 message: تفاصيل القطع مطلوبة
        • text
          • العنوان : موقع الاستلام
          • التحقق : required: 1 message: موقع الاستلام مطلوب
        • text
          • العنوان : موقع التسليم
          • التحقق : required: 1 message: موقع التسليم مطلوب
      • رسالة زر الإرسال: نشر الطلب
      • رسالة النجاح: تم نشر الطلب بنجاح
      • إعادة توجيه النجاح: OrdersListScreen
      الاشعارات

      العنوان : تم إنشاء الطلب
      الرسالة : تم إنشاء طلبك بنجاح، وسيتم التواصل معك قريباً لتأكيد التفاصيل
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل, SMS  المستقبل : طالب الخدمة

      3.34.2.2- يقوم النظام باستدعاء بيانات القطع المطلوبة وبيانات موقع الاستلام والتسليم من الطلب المنشأ، ثم ينشر هذه البيانات لكافة المركبات المتاحة ضمن نطاق ٥٠ كم من موقع الاستلام

      graph LR A[إنشاء طلب] --> B[استدعاء بيانات الطلب] B --> C[نشر الطلب لكافة المركبات في محيط ٥٠ كم]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • تم إنشاء الطلب من قبل طالب الخدمة
      الشروط اللاحقة
      • تم نشر الطلب لكافة المركبات في محيط ٥٠ كم
      تسلسل الأحداث
      • إنشاء طلب من قبل طالب الخدمة
      • استدعاء بيانات الطلب
      • نشر الطلب للمركبات في محيط ٥٠ كم
      الخطوات البديلةإذا لم تتوافر مركبات في محيط ٥٠ كم
      • النظام يبحث عن مركبات في محيط ١٠٠ كم
      • النظام ينشر الطلب لكافة المركبات المتاحة في محيط ١٠٠ كم
      الخطوات الاستثنائيةإذا فشل النظام في استدعاء بيانات الطلب
      • النظام يعرض رسالة خطأ لإداري النظام
      • النظام يحاول إعادة استدعاء البيانات بعد فترة زمنية محددة
      القواعد التجارية
      • يجب أن يتم نشر الطلب في نطاق جغرافي مناسب لضمان سرعة الاستجابة
      • يجب أن تتوافر بيانات دقيقة حول مواقع الاستلام والتسليم
      الافتراضات
      • يتوفر اتصال ثابت ومستقر بالإنترنت
      • البيانات المخزنة عن المركبات محدثة ودقيقة
      المتطلبات الخاصة
      • يجب أن تكون العملية آلية بالكامل بدون تدخل بشري لضمان السرعة والدقة
      الملاحظات والمشاكل
      • قد تتسبب أي أخطاء في استدعاء البيانات أو نشر الطلب في تأخير عملية التوصيل
      المدخلاتبيانات الطلب المنشأ | موقع الاستلام والتسليم |
      المخرجات
      • طلب منشور لكافة المركبات في محيط ٥٠ كم
      تفاعلات المستخدم
      • لا توجد تفاعلات مباشرة مع المستخدم
      الشروط الخاصة
      • في حال عدم توفر مركبات في محيط ٥٠ كم، يجب توسيع نطاق البحث
      سيناريوهات الاستخدام
      • يتم إنشاء طلب توصيل قطع غيار بواسطة طالب الخدمة، فيقوم النظام بنشر الطلب تلقائيًا للمركبات المتاحة في محيط ٥٠ كم
      متطلبات الأمان
      • يجب أن تكون البيانات المستدعاة مشفرة لضمان خصوصية المعلومات
      التكامل مع الأنظمة الأخرى
      • نظام إدارة المركبات لتحديد المركبات المتاحة في النطاق المحدد
      • نظام الخرائط لتحديد النطاق الجغرافي
      القيود والافتراضات
      • يجب أن يكون النظام قادرًا على التعامل مع عدد كبير من الطلبات في وقت واحد
      • يجب أن تتوافر البيانات المطلوبة في قاعدة البيانات بشكل صحيح ودقيق
      متطلبات الاختبار
      • اختبارات الأداء لضمان سرعة استدعاء البيانات ونشر الطلب
      • اختبارات تكامل لضمان التواصل السليم بين النظام وقواعد البيانات
      تفاصيل ال API
      Method: GET || Endpoint: /fetch-order-details
      Request Headers
      Authorization: نص

      Request Body

      Response

      الحالةالمحتوى
      200order_id: نص part_details: object pickup_location: نص delivery_location: نص
      الوصف: Success
      404
      الوصف: Order Not Found

      Method: POST || Endpoint: /publish-order
      Request Headers
      Authorization: نص

      Request Body

      order_id: نص radius: integer

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Order Published Successfully
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة إدارة الطلبات

      • textblock
        • إدارة الطلبات

      • list
        • النوع : title: طلب جديد content-render-format: orderDetails

      الاشعارات

      العنوان : طلب جديد
      الرسالة : تم نشر طلب جديد لكافة المركبات في محيط ٥٠ كم
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل, SMS  المستقبل : إداري النظام

      3.34.2.3- بعد نشر الطلب من قبل النظام، تستلم المركبات المتاحة في محيط ٥٠ كم الطلب وتقوم بإرسال عروضها. يقوم النظام بجمع هذه العروض وعرضها على طالب الخدمة لمراجعتها

      graph LR A[نشر الطلب لكافة المركبات في محيط ٥٠ كم] --> B[استلام العروض من المركبات] B --> C[جمع العروض المقدمة] C --> D[عرض العروض على طالب الخدمة] D --> E[استعراض العروض المقدمة]
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • تم نشر الطلب لكافة المركبات في محيط ٥٠ كم
      • استلام عروض مقدمة من المركبات في محيط 50 كم
      الشروط اللاحقة
      • طالب الخدمة استعرض العروض المقدمة
      تسلسل الأحداث
      • نشر الطلب لكافة المركبات في محيط ٥٠ كم
      • استلام العروض من المركبات المتاحة
      • جمع العروض من قبل النظام
      • عرض العروض على طالب الخدمة
      • استعراض العروض من قبل طالب الخدمة
      الخطوات البديلةإذا لم تتوافر عروض من المركبات في محيط ٥٠ كم
      • النظام يرسل إشعار لطالب الخدمة بأن لا توجد عروض متاحة حالياً
      • النظام يقوم بتوسيع نطاق البحث ليشمل محيط ١٠٠ كم
      • المركبات المتاحة في محيط ١٠٠ كم ترسل عروضها
      الخطوات الاستثنائيةإذا فشل النظام في جمع العروض المقدمة
      • النظام يعرض رسالة خطأ لطالب الخدمة
      • النظام يحاول إعادة جمع العروض بعد فترة زمنية محددة
      القواعد التجارية
      • يجب أن تتوافر العروض المقدمة ضمن النطاق الجغرافي المحدد لضمان سرعة الاستجابة
      • يجب أن تكون البيانات المتعلقة بالعروض دقيقة ومحدثة
      الافتراضات
      • يتوفر اتصال ثابت ومستقر بالإنترنت
      • البيانات المخزنة عن المركبات محدثة ودقيقة
      المتطلبات الخاصة
      • يجب أن تكون العملية آلية بالكامل لضمان السرعة والدقة في جمع وعرض العروض
      الملاحظات والمشاكل
      • قد تتسبب أي أخطاء في جمع العروض أو عرضها في تأخير عملية اتخاذ القرار من قبل طالب الخدمة
      المدخلاتبيانات العروض المقدمة من المركبات | معلومات الطلب المنشور |
      المخرجات
      • عروض المركبات المعروضة على طالب الخدمة
      تفاعلات المستخدم
      • واجهة استعراض العروض
      • إشعارات حول توفر العروض
      الشروط الخاصة
      • في حال عدم توفر عروض من المركبات في النطاق المحدد، يجب توسيع نطاق البحث
      سيناريوهات الاستخدام
      • طالب الخدمة ينشر طلب توصيل قطع غيار، ويقوم النظام بجمع العروض المقدمة من المركبات المتاحة في النطاق المحدد وعرضها لطالب الخدمة لمراجعتها
      متطلبات الأمان
      • يجب أن تكون البيانات المتعلقة بالعروض مشفرة لضمان خصوصية المعلومات
      التكامل مع الأنظمة الأخرى
      • نظام إدارة المركبات لجمع العروض المقدمة
      • نظام الخرائط لتحديد النطاق الجغرافي
      القيود والافتراضات
      • يجب أن يكون النظام قادرًا على التعامل مع عدد كبير من العروض في وقت واحد
      • يجب أن تتوافر البيانات المطلوبة في قاعدة البيانات بشكل صحيح ودقيق
      متطلبات الاختبار
      • اختبارات الأداء لضمان سرعة جمع وعرض العروض
      • اختبارات تكامل لضمان التواصل السليم بين النظام وقواعد البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /receive-offers
      Request Headers
      Authorization: نص

      Request Body

      order_id: نص vehicle_id: نص offer_details: object

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      Method: GET || Endpoint: /fetch-offers
      Request Headers
      Authorization: نص

      Request Body

      Response

      الحالةالمحتوى
      200offers: array
      الوصف: Success
      404
      الوصف: Offers Not Found

      تفاصيل الواجهات
      شاشة قائمة العروض

      • textblock
        • العروض المقدمة

      • list
        • النوع : title: عرض من مركبة content-render-format: offerDetails

      الاشعارات

      العنوان : عروض جديدة متاحة
      الرسالة : تم استلام عروض جديدة من المركبات المتاحة. يرجى استعراضها في واجهة المستخدم
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل, SMS  المستقبل : طالب الخدمة

      3.34.2.4- يقوم النظام بإرسال العرض الأفضل لطالب الخدمة بناءً على معايير محددة. يستلم طالب الخدمة العرض ويقوم بمراجعته ثم يتخذ القرار بقبوله أو رفضه

      graph LR; A[استعراض العروض] --> B[النظام يرسل العرض الأفضل]; B --> C[طالب الخدمة يستلم العرض]; C --> D[طالب الخدمة يراجع العرض]; D --> E{هل يقبل طالب الخدمة العرض؟}; E --> |نعم| F[قبول العرض]; E --> |لا| G[رفض العرض];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • تم تقديم عروض من المركبات
      • طالب الخدمة استعرض العروض المقدمة
      الشروط اللاحقة
      • تم إرسال العرض لطالب الخدمة
      الافتراضات
      • العروض المقدمة تحتوي على جميع التفاصيل اللازمة لاتخاذ القرار
      تفاصيل ال API
      Method: POST || Endpoint: /api/offers/send
      Request Headers
      Authorization: Bearer token

      Request Body

      request_id: نص best_offer: object

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تفاصيل العرض

      • textblock
        • تم إرسال العرض الأفضل لطالب الخدمة بناءً على معايير محددة

      • form
        • Button
          • العنوان : استعراض العرض
          • الخيارات : viewOfferDetails
        • Button
          • العنوان : قبول العرض
          • الخيارات : acceptOffer
        • Button
          • العنوان : رفض العرض
          • الخيارات : rejectOffer
      الاشعارات

      العنوان : عرض جديد متاح
      الرسالة : تم إرسال العرض الأفضل بناءً على المعايير المحددة. يرجى استعراض العرض لاتخاذ القرار المناسب
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : طالب الخدمة

      3.34.2.5- يقوم طالب الخدمة بقبول الطلب وحجز المبلغ الإجمالي بمجرد التأكيد على كود التحقق المرسل. بعد إدخال كود التحقق، يقوم النظام بحجز المبلغ الإجمالي في المحفظة ويؤكد الطلب

      graph LR; A[قبول العرض] --> B[تحقق من وجود المبلغ الكافي]; B --> C[إرسال كود التحقق]; C --> D[إدخال كود التحقق]; D --> E[حجز المبلغ الإجمالي في المحفظة]; E --> F[تأكيد الطلب];
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • طالب الخدمة قبل العرض المقدم
      • طالب الخدمة لديه المبلغ الكافي في المحفظة
      الشروط اللاحقة
      • تم حجز المبلغ الإجمالي في المحفظة
      • تم تأكيد الطلب
      الافتراضات
      • طالب الخدمة لديه حساب نشط في المحفظة
      • النظام يمكنه إرسال كود التحقق بشكل موثوق
      تفاصيل ال API
      Method: POST || Endpoint: /api/offers/accept
      Request Headers
      Authorization: Bearer token

      Request Body

      offer_id: نص verification_code: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      قبول العرض

      • textblock
        • يرجى إدخال كود التحقق المرسل لإتمام عملية القبول

      • form
        • text
          • العنوان : كود التحقق
        • Button
          • العنوان : تأكيد
          • الخيارات : confirmVerificationCode
      الاشعارات

      العنوان : إدخال كود التحقق
      الرسالة : يرجى إدخال كود التحقق المرسل لإتمام عملية قبول العرض
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : طالب الخدمة

      3.35 - استلام قطع الغيار

      3.35.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • لضمان عملية نقل سلسة ودقيقة لقطع الغيار من المحل إلى مركبة التوصيل، مع توفير القدرة على التتبع والتحقق من الأمان
      الجهات المعنية
      • محل بيع قطع الغيار
      • مركبة التوصيل
      الخطوات الرئيسية
      • إعداد قطع الغيار للتسليم في المحل
      • بمجرد وصول مركبة التوصيل، يقدم محل القطع رمز QR أو رمز التسليم
      • يتم فحص رمز QR أو رمز التسليم من قبل سائق مركبة التوصيل
      • بعد التحقق، تتم عملية استلام قطع الغيار
      الخطوات البديلة
      قصص المستخدمين
      • المحل: عندما يصل سائق التوصيل, أريد أن أتمكن من تقديم قطع الغيار مع رمز QR أو رمز التسليم حتى يمكن التحقق من عملية التسليم
      • سائق مركبة التوصيل: عند وصولي للمحل، أريد أن أتمكن من فحص رمز QR أو رمز التسليم حتى يمكنني التأكد من اكتمال عملية استلام القطع الغيار
      مؤشرات الأداء
      • عدد الطلبات المستلمة و نسبتها لإجمالي الطلبات التي انشاء طلب توصيل لها

      3.35.2 حالات الاستخدام

      3.35.2.1- يقوم محل بيع قطع الغيار بإعداد قطع الغيار المطلوبة للتسليم في المحل بمجرد تلقي طلب التوصيل من طالب الخدمة. يتأكد المحل من أن القطع المطلوبة متوفرة وجاهزة للتسليم في الوقت المحدد

      graph LR; A[تلقي طلب التوصيل] --> B[إعداد قطع الغيار]; B --> C[جاهزية القطع للتسليم];
      العنوانالتفاصيل
      المستخدممحل بيع قطع الغيار
      الشروط المسبقة
      • المحل يتلقى طلب التوصيل من طالب الخدمة
      • قطع الغيار المطلوبة متوفرة في المحل
      الشروط اللاحقة
      • قطع الغيار جاهزة للتسليم
      • انتظار وصول مركبة التوصيل
      تسلسل الأحداث
      الخطوات البديلةإذا كانت بعض قطع الغيار غير متوفرة في المخزون
      • النظام يقوم بإخطار المحل بعدم توافر القطع
      • المحل يتواصل مع طالب الخدمة لتقديم بدائل أو تحديد موعد جديد
      الخطوات الاستثنائيةإذا كان هناك خطأ في طلب التوصيل
      • النظام يعرض رسالة خطأ للمحل
      • المحل يتحقق يدويًا من تفاصيل الطلب
      • إذا تم اكتشاف خطأ، المحل يتواصل مع طالب الخدمة لتصحيح الطلب
      الافتراضات
      • قطع الغيار المطلوبة متوفرة وجاهزة في المحل
      • المحل لديه الموارد والوقت الكافي لتجهيز قطع الغيار
      المدخلاتطلب التوصيل | معلومات قطع الغيار المطلوبة |
      المخرجات
      • تأكيد تجهيز قطع الغيار
      تفاعلات المستخدم
      • استلام طلب التوصيل من النظام
      • تجهيز وتعبئة قطع الغيار
      الشروط الخاصة
      • توافر قطع الغيار المطلوبة في المخزون
      سيناريوهات الاستخدام
      • تجهيز قطع غيار من المحل لتسليمها إلى سائق مركبة التوصيل
      متطلبات الأمان
      • التحقق من صحة طلب التوصيل لضمان عدم تجهيز قطع غيار بشكل غير مصرح به
      التكامل مع الأنظمة الأخرى
      • نظام إدارة المخزون في محل بيع قطع الغيار
      • نظام طلبات التوصيل
      القيود والافتراضات
      • عدم وجود انقطاع في الخدمة عند استلام طلبات التوصيل
      متطلبات الاختبار
      • اختبار وظيفة استلام الطلبات من النظام
      • اختبار عملية تجهيز القطع تحت ظروف مختلفة
      تفاصيل ال API
      Method: POST || Endpoint: /api/parts/prepare
      Request Headers
      Authorization: Bearer token

      Request Body

      order_id: نص parts_list: array

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تحضير القطع

      • textblock
        • إعداد قطع الغيار للتسليم

      • list
        • النوع : طلب التوصيل: {{order_id}}

        • النوع : قائمة قطع الغيار: {{parts_list}}

      • form
        • Button
          • العنوان : تأكيد الإعداد
          • الخيارات : confirmPreparation
      الاشعارات

      العنوان : طلب توصيل جديد
      الرسالة : تم تلقي طلب توصيل جديد. يرجى إعداد قطع الغيار للتسليم
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : محل بيع قطع الغيار

      3.35.2.2- يصل سائق مركبة التوصيل إلى محل بيع قطع الغيار لاستلام القطع المطلوبة. بعد تقديم رمز QR أو رمز التسليم والتحقق منه، يتم استلام القطع ويبدأ السائق في رحلة التسليم

      graph LR; A[وصول سائق مركبة التوصيل] --> B[تقديم رمز QR أو رمز التسليم]; B --> C[التحقق من الرمز]; C --> D[استلام قطع الغيار]; D --> E[بدء رحلة التسليم];
      العنوانالتفاصيل
      المستخدمسائق مركبة التوصيل
      الشروط المسبقة
      • سائق مركبة التوصيل يتلقى طلب الاستلام
      • قطع الغيار جاهزة للتسليم في المحل
      الشروط اللاحقة
      • قطع الغيار تم استلامها بنجاح
      • سائق مركبة التوصيل يبدأ في رحلة التسليم
      تسلسل الأحداث
      • وصول سائق مركبة التوصيل
      • تقديم رمز QR أو رمز التسليم
      • التحقق من الرمز
      • استلام قطع الغيار
      الخطوات البديلةإذا لم يتمكن النظام من التحقق من صحة رمز QR أو رمز التسليم
      • النظام يعرض رسالة خطأ للسائق
      • المحل يتحقق يدويًا من صحة رمز QR أو رمز التسليم
      • إذا تم التحقق بنجاح، يستلم السائق قطع الغيار
      الخطوات الاستثنائيةإذا كانت قطع الغيار غير جاهزة عند وصول السائق
      • المحل يقوم بإخطار السائق بالانتظار
      • المحل يكمل تجهيز قطع الغيار
      • السائق يستلم القطع بعد تجهيزها
      القواعد التجارية
      الافتراضات
      • قطع الغيار جاهزة ومنظمة في المحل للتسليم السريع
      • سائق مركبة التوصيل لديه القدرة على مسح رمز QR أو رمز التسليم
      الملاحظات والمشاكل
      • يجب التأكد من أن رمز QR أو رمز التسليم يعمل بشكل صحيح لتجنب التأخيرات
      المدخلاترمز QR أو رمز التسليم |
      المخرجات
      • تأكيد استلام قطع الغيار
      تفاعلات المستخدم
      • تقديم رمز QR أو رمز التسليم
      • مسح الرمز للتحقق
      الشروط الخاصة
      • توافر شبكة إنترنت للتحقق من صحة الرمز
      سيناريوهات الاستخدام
      • وصول سائق مركبة التوصيل إلى المحل واستلام قطع الغيار المجهزة
      متطلبات الأمان
      • التحقق من صحة رمز QR أو رمز التسليم لضمان عدم استلام قطع الغيار من قبل شخص غير مصرح له
      التكامل مع الأنظمة الأخرى
      • نظام إدارة المخزون في محل بيع قطع الغيار
      • نظام تتبع مركبة التوصيل
      القيود والافتراضات
      • عدم وجود انقطاع في الخدمة عند استخدام رمز QR أو رمز التسليم
      متطلبات الاختبار
      • اختبار عملية الاستلام تحت ظروف مختلفة
      • اختبار وظيفة التحقق من رمز QR أو رمز التسليم
      تفاصيل ال API
      Method: POST || Endpoint: /api/delivery/pickup
      Request Headers
      Authorization: Bearer token

      Request Body

      pickup_id: نص qr_code: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      استلام القطع

      • textblock
        • يرجى تقديم رمز QR أو رمز التسليم لاستلام القطع

      • form
        • text
          • العنوان : رمز QR أو رمز التسليم
        • Button
          • العنوان : تأكيد
          • الخيارات : confirmPickup
      الاشعارات

      العنوان : استلام قطع الغيار
      الرسالة : يرجى تقديم رمز QR أو رمز التسليم لاستلام قطع الغيار من المحل
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : سائق مركبة التوصيل

      3.35.2.3- يقوم محل بيع قطع الغيار بالتحقق من رمز QR أو رمز التسليم المقدم من سائق مركبة التوصيل. بعد التحقق من صحة الرمز، يتم تسليم قطع الغيار إلى السائق

      graph LR; A[وصول سائق مركبة التوصيل] --> B[تقديم رمز QR أو رمز التسليم]; B --> C[التحقق من الرمز]; C --> D[تسليم قطع الغيار];
      العنوانالتفاصيل
      المستخدممحل بيع قطع الغيار
      الشروط المسبقة
      • سائق مركبة التوصيل يصل إلى المحل
      • سائق مركبة التوصيل يقدم رمز QR أو رمز التسليم
      الشروط اللاحقة
      • تم التحقق من رمز QR أو رمز التسليم
      • قطع الغيار تسلمت إلى سائق مركبة التوصيل
      تسلسل الأحداث
      • وصول سائق مركبة التوصيل
      • تقديم رمز QR أو رمز التسليم
      • التحقق من الرمز
      • تأكيد صحة الرمز
      • استلام قطع الغيار
      الخطوات البديلةإذا لم يتمكن النظام من التحقق من صحة رمز QR أو رمز التسليم
      • النظام يعرض رسالة خطأ للمحل
      • المحل يتحقق يدويًا من صحة رمز QR أو رمز التسليم
      • إذا تم التحقق بنجاح، يسلم المحل قطع الغيار
      الخطوات الاستثنائيةإذا كان رمز QR أو رمز التسليم غير صالح
      • النظام يعرض رسالة خطأ للمحل
      • المحل يرفض تسليم قطع الغيار
      • المحل يتواصل مع سائق مركبة التوصيل لحل المشكلة
      الافتراضات
      • سائق مركبة التوصيل لديه رمز QR أو رمز التسليم الصحيح
      • النظام قادر على التحقق من صحة الرمز بشكل صحيح
      الملاحظات والمشاكل
      • يجب التأكد من أن النظام يعمل بشكل صحيح للتحقق من الرموز لتجنب التأخيرات
      المدخلاترمز QR أو رمز التسليم |
      المخرجات
      • تأكيد صحة الرمز
      • تأكيد إستلام قطع الغيار
      تفاعلات المستخدم
      • تقديم رمز QR أو رمز التسليم
      • مسح الرمز للتحقق
      الشروط الخاصة
      • توافر شبكة إنترنت للتحقق من صحة الرمز" ],
      سيناريوهات الاستخدام
      • التحقق من رمز QR أو رمز التسليم المقدم من سائق مركبة التوصيل قبل استلام قطع الغيار
      متطلبات الأمان
      • التحقق من صحة رمز QR أو رمز التسليم لضمان عدم استلام قطع الغيار من قبل شخص غير مصرح له
      التكامل مع الأنظمة الأخرى
      • نظام إدارة المخزون في محل بيع قطع الغيار
      • نظام تتبع مركبة التوصيل
      القيود والافتراضات
      • عدم وجود انقطاع في الخدمة عند استخدام رمز QR أو رمز التسليم
      متطلبات الاختبار
      • اختبار وظيفة التحقق من رمز QR أو رمز التسليم
      • اختبار عملية الاستلام تحت ظروف مختلفة
      تفاصيل ال API
      Method: POST || Endpoint: /api/qr/verify
      Request Headers
      Authorization: Bearer token

      Request Body

      qr_code: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      التحقق من التسليم

      • textblock
        • يرجى تقديم رمز QR أو رمز التسليم للتحقق

      • form
        • text
          • العنوان : رمز QR أو رمز التسليم
        • Button
          • العنوان : تحقق
          • الخيارات : verifyQRCode
      الاشعارات

      العنوان : تقديم رمز QR أو رمز التسليم
      الرسالة : يرجى التحقق من رمز QR أو رمز التسليم المقدم من سائق مركبة التوصيل
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : محل بيع قطع الغيار

      3.36 - تسليم القطع وإغلاق طلب التوصيل

      3.36.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • ضمان تأكيد استلام القطع بشكل فوري ودقيق، مما يعزز الثقة والشفافية بين جميع الأطراف
      • تحسين كفاءة عملية التسليم والدفع باستخدام تقنية QR لتقليل أخطاء التحويلات المالية.
      الجهات المعنية
      • طالب الخدمة
      • مركبة التوصيل
      • التطبيق
      الخطوات الرئيسية
      • مركبة التوصيل تصل إلى وجهتها وتقدم رمز (QR) لطالب الخدمة لتأكيد الاستلام
      • طالب الخدمة يمسح رمز QR لتأكيد الاستلام وإتمام عملية التسليم
      • يتم خصم المبلغ الإجمالي من حساب محفظة طالب الخدمة بمجرد مسح رمز QR
      • أجرة التوصيل تحول مباشرة إلى حساب محفظة مركبة التوصيل فور التأكيد عبر رمز QR
      • يتم تحويل رسوم الخدمة وضريبة القيمة المضافة إلى حساب التطبيق فور تأكيد الاستلام
      الخطوات البديلة
      • في حال فشل مسح رمز QR، يجب توفير وسيلة يدوية لتأكيد استلام القطع وإتمام عملية التسليم
      قصص المستخدمين
      • طالب الخدمة: عند استلامي للقطع، أريد مسح رمز QR المقدم من سائق التوصيل لتأكيد الاستلام وضمان خصم المبلغ من حسابي بشكل صحيح
      • سائق مركبة التوصيل: عند تسليم القطعة، أريد تقديم رمز QR لطالب الخدمة لضمان تحويل أجرة التوصيل إلى حسابي فور تأكيده
      • التطبيق: أريد تسهيل عملية تحويل الأموال وتأكيد الخدمات من خلال استخدام رمز QR للحفاظ على دقة وفعالية المعاملات
      مؤشرات الأداء
      • نسبة الطلبات التي تم تأكيدها بنجاح عبر رمز QR مقارنة بإجمالي طلبات التوصيل
      • متوسط الوقت المستغرق لإتمام عملية التسليم والدفع باستخدام رمز QR

      3.36.2 حالات الاستخدام

      3.36.2.1- تصل مركبة التوصيل إلى وجهتها وتقدم رمز QR لطالب الخدمة لتأكيد الاستلام. بعد مسح رمز QR من قبل طالب الخدمة، يتم تأكيد استلام القطع وإتمام عملية التسليم

      graph LR; A[وصول مركبة التوصيل] --> B[تقديم رمز QR]; B --> C[مسح رمز QR]; C --> D[تأكيد الاستلام];
      العنوانالتفاصيل
      المستخدممركبة التوصيل
      الشروط المسبقة
      • مركبة التوصيل تحمل قطع الغيار
      • وجهة التسليم معروفة لمركبة التوصيل
      الشروط اللاحقة
      • تأكيد استلام القطع
      • إتمام عملية التسليم
      تسلسل الأحداث
      • وصول مركبة التوصيل إلى وجهتها
      • تقديم رمز QR لطالب الخدمة
      • مسح رمز QR لتأكيد الاستلام
      الخطوات البديلةإذا لم يتمكن طالب الخدمة من مسح رمز QR.
      • مركبة التوصيل تتواصل مع خدمة العملاء للحصول على رمز بديل
      • خدمة العملاء توفر وسيلة بديلة لتأكيد الاستلام
      • طالب الخدمة يستخدم الوسيلة البديلة لتأكيد الاستلام
      الخطوات الاستثنائيةإذا حدث خطأ أثناء مسح رمز QR
      • مركبة التوصيل تتحقق من حالة رمز QR
      • مركبة التوصيل تتواصل مع خدمة العملاء للإبلاغ عن المشكلة
      • خدمة العملاء تحاول حل المشكلة عن بعد أو توفر وسيلة بديلة
      القواعد التجارية
      • يجب استخدام رمز QR فريد لكل عملية تسليم
      الافتراضات
      • رمز QR صالح ويتم قراءته بسهولة
      • طالب الخدمة متواجد في وجهة التسليم
      المتطلبات الخاصة
      • يجب أن يكون قارئ رمز QR متاحًا وفعالًا على جهاز طالب الخدمة
      الملاحظات والمشاكل
      • تأكد من تدريب سائقي مركبة التوصيل على استخدام نظام رمز QR
      المدخلاترمز QR |
      المخرجات
      • تأكيد الاستلام
      تفاعلات المستخدم
      • طالب الخدمة يمسح رمز QR
      الشروط الخاصة
      • إذا كان رمز QR غير قابل للقراءة
      سيناريوهات الاستخدام
      • استخدام رمز QR لتأكيد استلام قطع الغيار عند التسليم
      متطلبات الأمان
      • يجب تشفير رمز QR لضمان عدم التلاعب
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة التوصيل ونظام إدارة العملاء
      القيود والافتراضات
      • يجب أن يتم توليد رمز QR قبل وصول مركبة التوصيل إلى وجهتها
      • افتراض أن جهاز طالب الخدمة يمكنه مسح رمز QR بشكل صحيح
      متطلبات الاختبار
      • اختبار عملية مسح رمز QR في بيئات مختلفة
      • اختبار استجابة النظام في حالة حدوث أخطاء أثناء المسح
      تفاصيل ال API
      Method: POST || Endpoint: /api/delivery/confirm
      Request Headers
      Authorization: Bearer token

      Request Body

      delivery_id: نص qr_code: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تأكيد التسليم

      • textblock
        • يرجى مسح رمز QR لتأكيد استلام القطع

      • form
        • text
          • العنوان : رمز QR
        • Button
          • العنوان : تأكيد
          • الخيارات : confirmQRCode
      الاشعارات

      العنوان : تأكيد استلام القطع
      الرسالة : يرجى مسح رمز QR المقدم من سائق مركبة التوصيل لتأكيد استلام القطع
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : طالب الخدمة

      3.36.2.2- يقوم طالب الخدمة بمسح رمز QR لتأكيد استلام القطع وإتمام عملية التسليم. بعد مسح الرمز، يتم خصم المبلغ الإجمالي من حساب محفظة طالب الخدمة وتأكيد الاستلام

      graph LR; A[وصول مركبة التوصيل] --> B[تقديم رمز QR]; B --> C[مسح رمز QR]; C --> D[تأكيد الاستلام]; D --> E[خصم المبلغ الإجمالي من حساب طالب الخدمة];
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • مركبة التوصيل تصل إلى وجهتها
      • رمز QR متوفر مع سائق مركبة التوصيل
      الشروط اللاحقة
      • تأكيد استلام القطع
      • خصم المبلغ الإجمالي من حساب محفظة طالب الخدمة
      تسلسل الأحداث
      • وصول مركبة التوصيل إلى وجهتها
      • تقديم رمز QR لطالب الخدمة
      • مسح رمز QR لتأكيد الاستلام
      الخطوات البديلةإذا لم يتمكن طالب الخدمة من مسح رمز QR.
      • مركبة التوصيل تتواصل مع خدمة العملاء للحصول على رمز بديل
      • خدمة العملاء توفر وسيلة بديلة لتأكيد الاستلام
      • طالب الخدمة يستخدم الوسيلة البديلة لتأكيد الاستلام
      الخطوات الاستثنائيةإذا حدث خطأ أثناء مسح رمز QR
      • طالب الخدمة يتحقق من حالة رمز QR
      • طالب الخدمة يتواصل مع خدمة العملاء للإبلاغ عن المشكلة
      • خدمة العملاء تحاول حل المشكلة عن بعد أو توفر وسيلة بديلة
      القواعد التجارية
      • يجب استخدام رمز QR فريد لكل عملية تسليم
      الافتراضات
      • رمز QR صالح ويتم قراءته بسهولة
      • طالب الخدمة متواجد في وجهة التسليم
      المتطلبات الخاصة
      • يجب أن يكون قارئ رمز QR متاحًا وفعالًا على جهاز طالب الخدمة
      الملاحظات والمشاكل
      • تأكد من تدريب سائقي مركبة التوصيل على استخدام نظام رمز QR
      المدخلاترمز QR |
      المخرجات
      • تأكيد الاستلام
      تفاعلات المستخدم
      • طالب الخدمة يمسح رمز QR
      الشروط الخاصة
      • إذا كان رمز QR غير قابل للقراءة
      سيناريوهات الاستخدام
      • استخدام رمز QR لتأكيد استلام قطع الغيار عند التسليم
      متطلبات الأمان
      • يجب تشفير رمز QR لضمان عدم التلاعب
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة التوصيل ونظام إدارة العملاء
      القيود والافتراضات
      • يجب أن يتم توليد رمز QR قبل وصول مركبة التوصيل إلى وجهتها
      • افتراض أن جهاز طالب الخدمة يمكنه مسح رمز QR بشكل صحيح
      متطلبات الاختبار
      • اختبار عملية مسح رمز QR في بيئات مختلفة
      • اختبار استجابة النظام في حالة حدوث أخطاء أثناء المسح
      تفاصيل ال API
      Method: POST || Endpoint: /api/qr/scan
      Request Headers
      Authorization: Bearer token

      Request Body

      delivery_id: نص qr_code: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تأكيد التسليم

      • textblock
        • يرجى مسح رمز QR لتأكيد استلام القطع

      • form
        • text
          • العنوان : رمز QR
        • Button
          • العنوان : تأكيد
          • الخيارات : confirmQRCode
      الاشعارات

      العنوان : تأكيد استلام القطع
      الرسالة : يرجى مسح رمز QR المقدم من سائق مركبة التوصيل لتأكيد استلام القطع
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : طالب الخدمة

      3.36.2.3- يتم خصم المبلغ الإجمالي من حساب محفظة طالب الخدمة بمجرد مسح رمز QR. بعد التأكيد، يتم تحويل أجرة التوصيل إلى حساب مركبة التوصيل وتحويل رسوم الخدمة وضريبة القيمة المضافة إلى حساب التطبيق

      graph LR; A[وصول مركبة التوصيل] --> B[تقديم رمز QR]; B --> C[مسح رمز QR]; C --> D[تأكيد الاستلام]; D --> E[خصم المبلغ الإجمالي من حساب طالب الخدمة]; E --> F[تحويل أجرة التوصيل]; F --> G[تحويل رسوم الخدمة وضريبة القيمة المضافة];
      العنوانالتفاصيل
      المستخدمالتطبيق
      الشروط المسبقة
      • تأكيد الاستلام عبر رمز QR
      • توفر المبلغ المطلوب في حساب محفظة طالب الخدمة
      الشروط اللاحقة
      • خصم المبلغ من حساب طالب الخدمة
      • تحويل أجرة التوصيل ورسوم الخدمة وضريبة القيمة المضافة
      تسلسل الأحداث
      • مسح رمز QR لتأكيد الاستلام
      • خصم المبلغ من حساب طالب الخدمة
      • تحويل الأموال إلى الحسابات المستحقة
      الخطوات البديلةإذا لم يتمكن النظام من خصم المبلغ من حساب طالب الخدمة
      • يتم إرسال إشعار لطالب الخدمة لإضافة أموال إلى حسابه
      • يحاول النظام مرة أخرى خصم المبلغ بعد تأكيد إضافة الأموال
      الخطوات الاستثنائيةإذا حدث خطأ أثناء خصم المبلغ
      • النظام يتواصل مع خدمة العملاء للإبلاغ عن المشكلة
      • خدمة العملاء تحاول حل المشكلة عن بعد أو توفر وسيلة بديلة لخصم المبلغ
      القواعد التجارية
      • يجب خصم المبلغ بالكامل قبل إتمام عملية التسليم
      الافتراضات
      • رمز QR صالح ويتم قراءته بسهولة
      • طالب الخدمة يملك المبلغ المطلوب في حساب المحفظة
      المتطلبات الخاصة
      • يجب أن يكون نظام المحفظة الإلكترونية متكاملًا مع التطبيق
      الملاحظات والمشاكل
      • تأكد من تدريب فريق خدمة العملاء على حل مشاكل الدفع بسرعة
      المدخلاترمز QR |
      المخرجات
      • تأكيد الدفع
      • تحويل الأموال
      تفاعلات المستخدم
      • طالب الخدمة يمسح رمز QR لتأكيد الاستلام
      الشروط الخاصة
      • إذا لم يكن هناك رصيد كافٍ في حساب طالب الخدمة
      سيناريوهات الاستخدام
      • استخدام رمز QR لتأكيد استلام قطع الغيار وخصم المبلغ تلقائيًا
      متطلبات الأمان
      • يجب تشفير جميع بيانات الدفع لضمان الأمان
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام المحفظة الإلكترونية ونظام إدارة العملاء
      القيود والافتراضات
      • يجب أن يكون توليد رمز QR صحيحًا وسهل الاستخدام
      • افتراض توفر اتصال إنترنت مستقر لتنفيذ العملية
      متطلبات الاختبار
      • اختبار خصم المبلغ في سيناريوهات مختلفة
      • اختبار استجابة النظام في حالة عدم توفر رصيد كافٍ
      تفاصيل ال API
      Method: POST || Endpoint: /api/qr/scan
      Request Headers
      Authorization: Bearer token

      Request Body

      delivery_id: نص qr_code: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تأكيد التسليم

      • textblock
        • يرجى مسح رمز QR لتأكيد استلام القطع

      • form
        • text
          • العنوان : رمز QR
        • Button
          • العنوان : تأكيد
          • الخيارات : confirmQRCode
      الاشعارات

      العنوان : تأكيد استلام القطع
      الرسالة : يرجى مسح رمز QR المقدم من سائق مركبة التوصيل لتأكيد استلام القطع
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : طالب الخدمة

      3.36.2.4- تحول أجرة التوصيل مباشرة إلى حساب محفظة مركبة التوصيل فور التأكيد عبر رمز QR. بعد خصم المبلغ من حساب طالب الخدمة، يتم تحويل الأجرة بشكل فوري إلى حساب السائق

      graph LR; A[وصول مركبة التوصيل] --> B[تقديم رمز QR]; B --> C[مسح رمز QR]; C --> D[تأكيد الاستلام]; D --> E[خصم المبلغ من حساب طالب الخدمة]; E --> F[تحويل أجرة التوصيل إلى حساب مركبة التوصيل];
      العنوانالتفاصيل
      المستخدمالتطبيق
      الشروط المسبقة
      • تأكيد الاستلام عبر رمز QR
      • خصم المبلغ الإجمالي من حساب طالب الخدمة
      الشروط اللاحقة
      • تحويل أجرة التوصيل إلى حساب مركبة التوصيل
      تسلسل الأحداث
      • تسليم القطع لطالب الخدمة
      • مسح رمز QR من قبل طالب الخدمة
      • تأكيد الاستلام عبر النظام
      • خصم المبلغ من حساب طالب الخدمة
      • تحويل أجرة التوصيل إلى حساب مركبة التوصيل
      القواعد التجارية
      • يجب أن يتم تحويل أجرة التوصيل فور تأكيد الاستلام لضمان عدم حدوث أي تأخير
      الافتراضات
      • رمز QR صالح ويتم قراءته بسهولة
      • طالب الخدمة يملك المبلغ المطلوب في حساب المحفظة
      المتطلبات الخاصة
      • يجب أن تكون هناك بنية تحتية آمنة وموثوقة للتحويلات المالية الفورية
      الملاحظات والمشاكل
      • قد يحدث تأخير في التحويل بسبب مشاكل تقنية أو بنكية خارج سيطرة النظام
      المدخلاترمز QR لتأكيد الاستلام | معلومات حساب محفظة مركبة التوصيل |
      المخرجات
      • تأكيد تحويل أجرة التوصيل إلى حساب مركبة التوصيل
      تفاعلات المستخدم
      • مسح رمز QR من قبل طالب الخدمة
      • تأكيد التحويل في واجهة التطبيق لمركبة التوصيل
      الشروط الخاصة
      • إذا فشل مسح رمز QR، يتم توفير وسيلة يدوية لتأكيد الاستلام
      سيناريوهات الاستخدام
      • يتم تسليم قطعة غيار لطالب الخدمة ويتم تأكيد الاستلام عبر رمز QR، ويتم تحويل أجرة التوصيل مباشرة إلى حساب محفظة مركبة التوصيل
      متطلبات الأمان
      • يجب تشفير جميع البيانات المالية المنقولة
      • يجب تنفيذ عمليات التحقق المزدوجة لضمان صحة التحويلات
      التكامل مع الأنظمة الأخرى
      • يجب أن يتكامل النظام مع أنظمة التحويلات المالية والبنكية لضمان التحويل الفوري
      القيود والافتراضات
      • يجب أن يكون هناك اتصال إنترنت مستقر لإتمام العملية
      • النظام البنكي يجب أن يدعم التحويلات الفورية
      متطلبات الاختبار
      • اختبار وظيفة مسح رمز QR وتأكيد الاستلام
      • اختبار عملية تحويل الأموال الفورية لحساب مركبة التوصيل
      تفاصيل ال API
      Method: POST || Endpoint: /api/qr/confirm
      Request Headers
      Authorization: Bearer token

      Request Body

      delivery_id: نص qr_code: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تأكيد التسليم

      • textblock
        • يرجى مسح رمز QR لتأكيد استلام القطع

      • form
        • text
          • العنوان : رمز QR
        • Button
          • العنوان : تأكيد
          • الخيارات : confirmQRCode
      الاشعارات

      العنوان : تأكيد استلام القطع
      الرسالة : تم تأكيد استلام القطع عبر مسح رمز QR. تم تحويل أجرة التوصيل إلى حسابك
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : سائق مركبة التوصيل

      3.36.2.5- يتم تحويل رسوم الخدمة وضريبة القيمة المضافة إلى حساب التطبيق فور تأكيد الاستلام. بعد خصم المبلغ من حساب طالب الخدمة، يتم تحويل الرسوم والضريبة مباشرة إلى حساب التطبيق

      graph LR; A[وصول مركبة التوصيل] --> B[تقديم رمز QR]; B --> C[مسح رمز QR]; C --> D[تأكيد الاستلام]; D --> E[خصم المبلغ من حساب طالب الخدمة]; E --> F[تحويل رسوم الخدمة وضريبة القيمة المضافة إلى حساب التطبيق];
      العنوانالتفاصيل
      المستخدمالتطبيق
      الشروط المسبقة
      • تأكيد الاستلام عبر رمز QR
      • خصم المبلغ الإجمالي من حساب طالب الخدمة
      الشروط اللاحقة
      • تحويل رسوم الخدمة وضريبة القيمة المضافة إلى حساب التطبيق
      تسلسل الأحداث
      • تسليم القطع لطالب الخدمة
      • مسح رمز QR من قبل طالب الخدمة
      • تأكيد الاستلام عبر النظام
      • خصم المبلغ من حساب طالب الخدمة
      • تحويل رسوم الخدمة وضريبة القيمة المضافة إلى حساب التطبيق
      القواعد التجارية
      • يجب تحويل رسوم الخدمة وضريبة القيمة المضافة فور تأكيد الاستلام لضمان عدم حدوث أي تأخير
      الافتراضات
      • رمز QR صالح ويتم قراءته بسهولة
      • طالب الخدمة يملك المبلغ المطلوب في حساب المحفظة
      المتطلبات الخاصة
      • يجب أن تكون هناك بنية تحتية آمنة وموثوقة للتحويلات المالية الفورية
      الملاحظات والمشاكل
      • قد يحدث تأخير في التحويل بسبب مشاكل تقنية أو بنكية خارج سيطرة النظام
      المدخلاترمز QR لتأكيد الاستلام | معلومات حساب التطبيق |
      المخرجات
      • تأكيد تحويل رسوم الخدمة وضريبة القيمة المضافة إلى حساب التطبيق
      تفاعلات المستخدم
      • مسح رمز QR من قبل طالب الخدمة
      • تأكيد التحويل في واجهة التطبيق
      الشروط الخاصة
      • إذا فشل مسح رمز QR، يتم توفير وسيلة يدوية لتأكيد الاستلام
      سيناريوهات الاستخدام
      • يتم تسليم قطعة غيار لطالب الخدمة ويتم تأكيد الاستلام عبر رمز QR، ويتم تحويل رسوم الخدمة وضريبة القيمة المضافة مباشرة إلى حساب التطبيق
      متطلبات الأمان
      • يجب تشفير جميع البيانات المالية المنقولة
      • يجب تنفيذ عمليات التحقق المزدوجة لضمان صحة التحويلات
      التكامل مع الأنظمة الأخرى
      • يجب أن يتكامل النظام مع أنظمة التحويلات المالية والبنكية لضمان التحويل الفوري
      القيود والافتراضات
      • يجب أن يكون هناك اتصال إنترنت مستقر لإتمام العملية
      • النظام البنكي يجب أن يدعم التحويلات الفورية
      متطلبات الاختبار
      • اختبار وظيفة مسح رمز QR وتأكيد الاستلام
      • اختبار عملية تحويل رسوم الخدمة وضريبة القيمة المضافة إلى حساب التطبيق
      تفاصيل ال API
      Method: POST || Endpoint: /api/qr/confirm
      Request Headers
      Authorization: Bearer token

      Request Body

      delivery_id: نص qr_code: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تأكيد التسليم

      • textblock
        • يرجى مسح رمز QR لتأكيد استلام القطع

      • form
        • text
          • العنوان : رمز QR
        • Button
          • العنوان : تأكيد
          • الخيارات : confirmQRCode
      الاشعارات

      العنوان : تأكيد استلام القطع
      الرسالة : تم تأكيد استلام القطع عبر مسح رمز QR. تم تحويل رسوم الخدمة وضريبة القيمة المضافة إلى حساب التطبيق
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : التطبيق

      3.36.2.6- في حال فشل مسح رمز QR، يجب توفير وسيلة يدوية لتأكيد استلام القطع وإتمام عملية التسليم. بعد التواصل مع خدمة العملاء، يمكن تأكيد الاستلام يدوياً وإتمام التسليم

      graph LR; A[فشل مسح رمز QR] --> B[تواصل مع خدمة العملاء]; B --> C[توفير وسيلة يدوية لتأكيد الاستلام]; C --> D[إتمام عملية التسليم يدوياً];
      العنوانالتفاصيل
      المستخدمالتطبيق
      الشروط المسبقة
      • مشكلة في مسح رمز QR
      • تواصل مع خدمة العملاء
      الشروط اللاحقة
      • تأكيد استلام القطع يدوياً
      • إتمام عملية التسليم
      تسلسل الأحداث
      • فشل مسح رمز QR
      • تواصل مع خدمة العملاء
      • توفير وسيلة يدوية لتأكيد الاستلام
      • إتمام عملية التسليم يدوياً
      القواعد التجارية
      • يجب توفير وسيلة يدوية لتأكيد استلام القطع في حال فشل مسح رمز QR لضمان استمرارية عملية التسليم
      الافتراضات
      • وجود خدمة عملاء فعالة لدعم العملية اليدوية
      • القدرة على تأكيد الاستلام يدوياً بشكل دقيق
      المتطلبات الخاصة
      • يجب أن تكون هناك وسيلة يدوية لتأكيد الاستلام متاحة وسهلة الاستخدام
      الملاحظات والمشاكل
      • قد يكون هناك تأخير في عملية التسليم بسبب الحاجة إلى تأكيد يدوي
      المدخلاترمز QR | بيانات الاتصال بخدمة العملاء |
      المخرجات
      • ًتأكيد الاستلام يدويا
      • إتمام عملية التسليم
      تفاعلات المستخدم
      • تواصل مع خدمة العملاء
      • تأكيد الاستلام يدوياً
      الشروط الخاصة
      • إذا لم يتمكن النظام من توفير وسيلة يدوية لتأكيد الاستلام، يتم تأجيل التسليم
      سيناريوهات الاستخدام
      • فشل مسح رمز QR، ويتواصل المستخدم مع خدمة العملاء لتأكيد الاستلام يدوياً وإتمام التسليم
      متطلبات الأمان
      • يجب تشفير جميع البيانات المتعلقة بتأكيد الاستلام اليدوي
      • يجب تسجيل كافة المحاولات اليدوية لتأكيد الاستلام لمراجعة الأمان
      التكامل مع الأنظمة الأخرى
      • يجب أن يتكامل النظام مع خدمة العملاء لضمان التفاعل السلس في حالات فشل مسح رمز QR
      القيود والافتراضات
      • يجب أن يكون فريق خدمة العملاء متاحًا على مدار الساعة لتقديم الدعم في حالات الطوارئ
      • يجب أن تكون هناك وسيلة يدوية موثوقة وسهلة الاستخدام لتأكيد الاستلام
      متطلبات الاختبار
      • اختبار فشل مسح رمز QR وكيفية التعامل معه
      • اختبار عملية التواصل مع خدمة العملاء وتأكيد الاستلام يدوياً
      تفاصيل ال API
      Method: POST || Endpoint: /api/qr/confirm/manual
      Request Headers
      Authorization: Bearer token

      Request Body

      delivery_id: نص manual_confirmation: boolean

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      التأكيد اليدوي

      • textblock
        • لم يتمكن من مسح رمز QR؟ يرجى التواصل مع خدمة العملاء لتأكيد الاستلام يدوياً

      • form
        • Button
          • العنوان : اتصل بخدمة العملاء
          • الخيارات : contactCustomerService
      الاشعارات

      العنوان : طلب تأكيد استلام يدوي
      الرسالة : تم فشل مسح رمز QR. يرجى التواصل مع طالب الخدمة لتأكيد الاستلام يدوياً
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : خدمة العملاء

      3.37 - قبول القطع / رفض القطع

      3.37.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • تسهيل عملية قبول أو رفض القطع بتحويل الأموال المستحقة بين الأطراف المعنية والتأكد من سداد رسوم الخدمة
      الجهات المعنية
      • طالب الخدمة
      • محل قطع الغيار
      الخطوات الرئيسية
      • قبول القطع وسداد المستحقات وتحويل المبالغ المحجوزة من طالب الخدمة لحساب محفظة محل قطع الغيار
      • في حال الرفض، يقوم طالب الخدمة بإنشاء طلب إعادة القطع من خلال طلب توصيل بنفس آلية توصيله مع تغير الأشخاص بين طالب الخدمة ومزود الخدمة
      • يبقى المبلغ تحت الحجز لحين إرجاع القطع ويتم تحرير المبلغ من حساب محفظة طالب الخدمة بعد تأكيد استلام المحل للقطع
      • رسوم الخدمة تبقى مستحقة ويتم خصمها عند انتهاء خدمة الطلب
      الخطوات البديلة
      قصص المستخدمين
      • كعميل طالب الخدمة، يستطيع قبول القطع وسداد المستحقات وتحويل المبالغ المحجوزة من حسابه لحساب محل قطع الغيار
      • كعميل طالب الخدمة، يستطيع في حال رفضه للقطع إنشاء طلب إعادة القطع من خلال طلب توصيل بنفس الآلية
      • كعميل طالب الخدمة، يستطيع تحرير المبلغ المحجوز من حساب محفظته بعد تأكيد استلام المحل للقطع
      مؤشرات الأداء
      • إحصاء عدد الطلبات المقبولة والمرفوضة وحساب نسبتهما إلى إجمالي الطلبات المُسلَمة
      • عدد الطلبات التي تم إعادتها ونسبتها للطلبات المرفوضة

      3.37.2 حالات الاستخدام

      3.37.2.1- يتلقى طالب الخدمة قطع الغيار ويقوم بسداد المبالغ المستحقة

      graph LR; A[استلام قطع الغيار] --> B[تأكيد القبول]; B --> C[سداد المستحقات]; C --> D[تحويل المبلغ المحجوز];
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • قطع الغيار متاحة للاستلام
      • المبلغ محجوز في محفظة طالب الخدمة
      الشروط اللاحقة
      • تحويل المبلغ إلى حساب محل قطع الغيار
      • تأكيد استلام قطع الغيار
      تسلسل الأحداث
      • طالب الخدمة يستلم القطع
      • طالب الخدمة يؤكد القبول
      • تتم عملية السداد
      • تحويل المبلغ المحجوز
      القواعد التجارية
      • يجب أن تكون قطع الغيار متاحة فعلياً في المحل
      • يجب أن يكون المبلغ محجوز مسبقاً في المحفظة
      الافتراضات
      • طالب الخدمة يمتلك محفظة تحتوي على مبلغ كافي
      • قطع الغيار مطابقة للمواصفات المطلوبة
      المتطلبات الخاصة
      • التأكد من تطابق القطع المستلمة مع الطلب الأصلي
      • ضمان أن عملية الدفع والتحويل تتم بشكل آمن وسريع
      الملاحظات والمشاكل
      • في حال عدم تطابق قطع الغيار مع الطلب، يجب على طالب الخدمة الإبلاغ فوراً وإعادة القطع للمحل
      المدخلاتتأكيد استلام القطع | قبول القطع | تفاصيل الدفع |
      المخرجات
      • تأكيد السداد
      • إشعار تحويل المبلغ
      تفاعلات المستخدم
      • واجهة تأكيد الاستلام
      • واجهة الدفع
      الشروط الخاصة
      • في حالة عدم توفر قطع الغيار، يتم إشعار طالب الخدمة بتأخير الاستلام
      سيناريوهات الاستخدام
      • استلام قطع الغيار في المحل
      • دفع المبلغ المحجوز
      متطلبات الأمان
      • ضمان سرية وأمان عمليات الدفع
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام المحفظة الإلكترونية
      • تكامل مع نظام إدارة المخزون في المحل
      القيود والافتراضات
      • قطع الغيار متوفرة في المخزن
      • المبلغ محجوز مسبقاً
      متطلبات الاختبار
      • اختبار عملية استلام القطع
      • اختبار عملية الدفع وتحويل المبلغ
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/accept-spare-parts
      Request Headers
      Authorization: Bearer token

      Request Body

      order_id: نص confirmation_status: boolean

      Response

      الحالةالمحتوى
      200status: نص transaction_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة قبول قطع الغيار

      • textblock
        • تأكيد استلام قطع الغيار

      • form
        • Button
          • العنوان : استلام
          • الخيارات : handleAcceptSpareParts
      الاشعارات

      العنوان : استلام قطع الغيار
      الرسالة : تم استلام قطع الغيار الخاصة بطلبك وتم سداد المستحقات
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : طالب الخدمة

      3.37.2.2- طالب الخدمة يقوم برفض قطع الغيار وإنشاء طلب إعادة القطع

      graph LR; A[استلام قطع الغيار] --> B[رفض القطع]; B --> C[إنشاء طلب إعادة القطع]; C --> D[تحرير المبلغ بعد تأكيد استلام القطع];
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • قطع الغيار متاحة للاستلام
      • المبلغ محجوز في محفظة طالب الخدمة
      الشروط اللاحقة
      • إنشاء طلب إعادة القطع
      • المبلغ يبقى محجوزاً حتى استلام المحل للقطع
      تسلسل الأحداث
      • طالب الخدمة يستلم القطع
      • طالب الخدمة يرفض القطع
      • إنشاء طلب إعادة القطع
      • تحرير المبلغ بعد تأكيد استلام القطع
      القواعد التجارية
      • يجب إنشاء طلب إعادة القطع فور رفض طالب الخدمة للقطع لضمان عملية الاسترجاع
      الافتراضات
      • النظام يعمل بشكل صحيح ويستطيع معالجة طلب إعادة القطع في الوقت الفعلي
      • قطع الغيار غير مطابقة للمواصفات المطلوبة
      • المحل قادر على استقبال وإعادة القطع
      المتطلبات الخاصة
      • التأكد من تسجيل سبب رفض قطع الغيار
      • ضمان عملية إعادة القطع تتم بشكل آمن وسريع
      الملاحظات والمشاكل
      • في حال عدم تطابق قطع الغيار مع الطلب، يجب على طالب الخدمة الإبلاغ فوراً وإعادة القطع للمحل
      المدخلاتتأكيد استلام القطع | رفض القطع | تفاصيل إعادة القطع |
      المخرجات
      • تأكيد رفض القطع
      • إشعار إنشاء طلب إعادة القطع
      تفاعلات المستخدم
      • واجهة استلام القطع
      • واجهة رفض القطع
      • واجهة إنشاء طلب إعادة القطع
      الشروط الخاصة
      • في حالة عدم توفر قطع الغيار البديلة، يتم إشعار طالب الخدمة بتأخير استلام البدائل
      سيناريوهات الاستخدام
      • استلام قطع الغيار في المحل
      • رفض قطع الغيار
      • إنشاء طلب إعادة القطع
      متطلبات الأمان
      • ضمان سرية وأمان عمليات رفض القطع وإعادة القطع
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام المحفظة الإلكترونية
      • تكامل مع نظام إدارة المخزون في المحل
      القيود والافتراضات
      • قطع الغيار متوفرة في المخزن
      • المبلغ محجوز مسبقاً
      متطلبات الاختبار
      • اختبار عملية استلام القطع
      • اختبار عملية رفض القطع وإنشاء طلب إعادة
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/reject-spare-parts
      Request Headers
      Authorization: Bearer token

      Request Body

      order_id: نص rejection_reason: نص

      Response

      الحالةالمحتوى
      200status: نص return_request_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة رفض قطع الغيار

      • textblock
        • رفض استلام قطع الغيار

      • form
        • Button
          • العنوان : رفض
          • الخيارات : handleRejectSpareParts
      • رسالة زر الإرسال: رفض
      الاشعارات

      العنوان : رفض قطع الغيار
      الرسالة : تم رفض قطع الغيار الخاصة بطلبك وتم إنشاء طلب إعادة القطع
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : طالب الخدمة

      3.37.2.3- تحويل رسوم الخدمة بعد قبول أو رفض القطع

      graph LR; A[قبول أو رفض القطع] --> B[تحويل رسوم الخدمة]; B --> C[تحويل ضريبة القيمة المضافة];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • قطع الغيار تم قبولها أو رفضها من قبل طالب الخدمة
      • المبلغ محجوز في محفظة طالب الخدمة
      الشروط اللاحقة
      • تحويل رسوم الخدمة إلى حساب التطبيق
      • تحويل ضريبة القيمة المضافة إلى حساب التطبيق
      تسلسل الأحداث
      • قبول أو رفض القطع من قبل طالب الخدمة
      • تحويل رسوم الخدمة إلى حساب التطبيق
      • تحويل ضريبة القيمة المضافة إلى حساب التطبيق
      القواعد التجارية
      • يجب تحويل رسوم الخدمة فور قبول أو رفض القطع
      • يجب تحويل ضريبة القيمة المضافة إلى حساب التطبيق بشكل منفصل
      الافتراضات
      • طالب الخدمة يمتلك محفظة تحتوي على مبلغ كافي
      • الرسوم والضريبة محجوزة مسبقاً في المحفظة
      المتطلبات الخاصة
      • ضمان دقة تحويل الرسوم والضريبة
      • التأكد من تسجيل كل عملية تحويل بشكل صحيح
      الملاحظات والمشاكل
      • في حال وجود خطأ في عملية التحويل، يجب إعادة المبلغ إلى محفظة طالب الخدمة والتحقق من السبب
      المدخلاتقبول أو رفض القطع | تفاصيل الرسوم | تفاصيل الضريبة |
      المخرجات
      • تأكيد تحويل الرسوم
      • تأكيد تحويل الضريبة
      تفاعلات المستخدم
      • واجهة تأكيد القبول أو الرفض
      الشروط الخاصة
      • في حال فشل التحويل، يتم إشعار طالب الخدمة وإعادة المحاولة
      سيناريوهات الاستخدام
      • تحويل رسوم الخدمة بعد القبول أو الرفض
      • تحويل ضريبة القيمة المضافة
      متطلبات الأمان
      • ضمان سرية وأمان عمليات التحويل
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام المحفظة الإلكترونية
      • تكامل مع نظام إدارة الفواتير في التطبيق
      القيود والافتراضات
      • المبلغ محجوز مسبقاً في المحفظة
      • الرسوم والضريبة معروفتان مسبقاً
      متطلبات الاختبار
      • اختبار عملية تحويل الرسوم
      • اختبار عملية تحويل الضريبة
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/transfer-service-fee
      Request Headers
      Authorization: Bearer token

      Request Body

      order_id: نص service_fee: number vat_amount: number

      Response

      الحالةالمحتوى
      200status: نص transaction_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تحويل رسوم الخدمة

      • textblock
        • تحويل رسوم الخدمة

      • form
        • Button
          • العنوان : تحويل
          • الخيارات : handleServiceFeeTransfer
      الاشعارات

      العنوان : تحويل رسوم الخدمة
      الرسالة : تم تحويل رسوم الخدمة وضريبة القيمة المضافة بعد قبول أو رفض قطع الغيار
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : طالب الخدمة

      3.38 - تقييم وارشفة خدمة قطع غيار

      3.38.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • تطوير خدمة العملاء وتقديم نظام تقييم شامل وموثوق, وتأكيد أرشفة كافة البيانات المتعلقة بالخدمة للرجوع إليها عند الحاجة
      الجهات المعنية
      • العميل
      • محل قطع الغيار
      الخطوات الرئيسية
      • كل طرف يقوم بتقييم الطرف الآخر بناء على الخدمة التي تم تقديمها
      • تعبئة نموذج التقييم المقدم من المنصة بالنجوم والتعليق
      • أرشفة البيانات الأساسية للحالة في سجلات الطلبات لكل طرف
      • يتم أرشفة كافة بيانات الحالة في سجلات المنصة بمجرد إنهاء الخدمة
      الخطوات البديلة
      قصص المستخدمين
      • العميل طالب الخدمة، يستطيع تقييم الخدمة التي تقدمها محل قطع الغيار وكتابة تعليق إذا أراد
      • العميل محل قطع الغيار، يستطيع تقييم العميل استنادًا إلى تجربة الخدمة
      • العميل طالب الخدمة و محل قطع الغيار، يستطيع الاطلاع على تفاصيل الخدمة السابقة من خلال سجل الطلبات في أي لحظة
      • المنصة تقوم بأرشفة كافة بيانات الحالة في سجلات المنصة بمجرد إنهاء الخدمة
      مؤشرات الأداء
      • عدد الطلبات التي تم تقييمها و نسبتها لإجمالي الطلبات المكتملة
      • معدل تقييم الخدمة الإجمالي

      3.38.2 حالات الاستخدام

      3.38.2.1- العميل يقوم بتقييم الخدمة التي قدمها محل قطع الغيار وكتابة تعليق إذا أراد

      graph LR; A[فتح صفحة الطلبات السابقة] --> B[اختيار الطلب]; B --> C[تعبئة نموذج التقييم]; C --> D[إرسال التقييم]; D --> E[أرشفة التقييم وربطه بالطلب];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • انتهاء الخدمة بنجاح
      • وجود حساب للعميل على المنصة
      الشروط اللاحقة
      • إضافة تقييم العميل في سجلات الطلبات
      • إتاحة التقييم للعامة
      تسلسل الأحداث
      • فتح صفحة الطلبات السابقة
      • اختيار الطلب
      • تعبئة نموذج التقييم
      • إرسال التقييم
      • أرشفة التقييم وربطه بالطلب
      القواعد التجارية
      • يجب على العميل تقييم الخدمة بعد الانتهاء منها فقط
      • يجب على المنصة أرشفة جميع التقييمات وربطها بالطلبات المعنية
      الافتراضات
      • العميل يستخدم المنصة بشكل منتظم
      • العميل يرغب في تقديم ملاحظات صادقة حول الخدمة
      المتطلبات الخاصة
      • يجب أن تكون واجهة التقييم سهلة الاستخدام
      • يجب أن تتضمن واجهة التقييم خيارات لتقييم النجوم وكتابة التعليقات
      الملاحظات والمشاكل
      • في حالة وجود مشاكل تقنية أثناء إرسال التقييم، يجب على المنصة توفير دعم فني لحل المشكلة
      المدخلاتاختيار الطلب | تقييم النجوم | التعليق (اختياري) |
      المخرجات
      • تأكيد استلام التقييم
      • عرض التقييم للعامة
      تفاعلات المستخدم
      • واجهة الطلبات السابقة
      • واجهة التقييم
      الشروط الخاصة
      • في حالة عدم توفر اتصال بالإنترنت، يتم حفظ التقييم مؤقتاً وإرساله عند استعادة الاتصال
      سيناريوهات الاستخدام
      • تقييم الخدمة بعد استلام القطع
      • كتابة تعليق حول جودة الخدمة
      متطلبات الأمان
      • ضمان سرية بيانات العميل أثناء عملية التقييم
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الطلبات
      • تكامل مع واجهة المستخدم للعرض العام
      القيود والافتراضات
      • انتهاء الخدمة بنجاح
      • وجود حساب للعميل
      متطلبات الاختبار
      • اختبار واجهة التقييم
      • اختبار عملية أرشفة التقييم
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/submit-review
      Request Headers
      Authorization: Bearer token

      Request Body

      order_id: نص rating: integer comment: نص

      Response

      الحالةالمحتوى
      200status: نص review_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تقديم المراجعة

      • textblock
        • تقييم الطلب

      • form
        • textarea
          • العنوان : تعليق (اختياري)
        • Button
          • العنوان : إرسال التقييم
          • الخيارات : handleSubmitReview
      الاشعارات

      العنوان : تأكيد التقييم
      الرسالة : تم استلام تقييمك بنجاح وشكراً لملاحظاتك
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.38.2.2- محل قطع الغيار يقوم بتقييم العميل استنادًا إلى تجربة الخدمة

      graph LR; A[فتح صفحة الطلبات السابقة] --> B[اختيار الطلب]; B --> C[تعبئة نموذج التقييم]; C --> D[إرسال التقييم]; D --> E[أرشفة التقييم وربطه بالطلب];
      العنوانالتفاصيل
      المستخدممحل قطع الغيار
      الشروط المسبقة
      • انتهاء الخدمة بنجاح
      • وجود حساب لمحل قطع الغيار على المنصة
      الشروط اللاحقة
      • إضافة تقييم محل قطع الغيار في سجلات الطلبات
      • إتاحة التقييم للعامة
      تسلسل الأحداث
      • فتح صفحة الطلبات السابقة
      • اختيار الطلب
      • تعبئة نموذج التقييم
      • إرسال التقييم
      • أرشفة التقييم وربطه بالطلب
      القواعد التجارية
      • يجب على محل قطع الغيار تقييم الخدمة بعد انتهائها فقط
      • يجب على المنصة أرشفة جميع التقييمات وربطها بالطلبات المعنية
      الافتراضات
      • محل قطع الغيار يستخدم المنصة بشكل منتظم
      • محل قطع الغيار يرغب في تقديم ملاحظات صادقة حول العميل
      المتطلبات الخاصة
      • يجب أن تكون واجهة التقييم سهلة الاستخدام
      • يجب أن تتضمن واجهة التقييم خيارات لتقييم النجوم وكتابة التعليقات
      الملاحظات والمشاكل
      • في حالة وجود مشاكل تقنية أثناء إرسال التقييم، يجب على المنصة توفير دعم فني لحل المشكلة
      المدخلاتاختيار الطلب | تقييم النجوم | التعليق (اختياري) |
      المخرجات
      • تأكيد استلام التقييم
      • عرض التقييم للعامة
      تفاعلات المستخدم
      • واجهة الطلبات السابقة
      • واجهة التقييم
      الشروط الخاصة
      • في حالة عدم توفر اتصال بالإنترنت، يتم حفظ التقييم مؤقتاً وإرساله عند استعادة الاتصال
      سيناريوهات الاستخدام
      • تقييم العميل بعد إتمام الخدمة
      • كتابة تعليق حول تجربة الخدمة
      متطلبات الأمان
      • ضمان سرية بيانات محل قطع الغيار أثناء عملية التقييم
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الطلبات
      • تكامل مع واجهة المستخدم للعرض العام
      القيود والافتراضات
      • انتهاء الخدمة بنجاح
      • وجود حساب لمحل قطع الغيار
      متطلبات الاختبار
      • اختبار واجهة التقييم
      • اختبار عملية أرشفة التقييم
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/submit-store-review
      Request Headers
      Authorization: Bearer token

      Request Body

      order_id: نص rating: integer comment: نص

      Response

      الحالةالمحتوى
      200status: نص review_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تقديم مراجعة المتجر

      • textblock
        • تقييم الطلب

      • form
        • textarea
          • العنوان : تعليق (اختياري)
        • Button
          • العنوان : إرسال التقييم
          • الخيارات : handleSubmitStoreReview
      الاشعارات

      العنوان : تأكيد التقييم
      الرسالة : تم استلام تقييمك بنجاح وشكراً لملاحظاتك
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : محل قطع الغيار

      3.38.2.3- العميل ومحل قطع الغيار يستطيعان الاطلاع على تفاصيل الخدمة السابقة من خلال سجل الطلبات

      graph LR; A[فتح صفحة الطلبات السابقة] --> B[عرض تفاصيل الطلبات السابقة]; B --> C[استعراض تفاصيل كل طلب];
      العنوانالتفاصيل
      المستخدمالمستخدم
      الشروط المسبقة
      • وجود حساب لكل من العميل ومحل قطع الغيار على المنصة
      • وجود طلبات سابقة
      الشروط اللاحقة
      • إتاحة تفاصيل الخدمة في أي وقت
      تسلسل الأحداث
      • فتح صفحة الطلبات السابقة
      • عرض تفاصيل الطلبات السابقة
      • استعراض تفاصيل كل طلب
      القواعد التجارية
      • يجب أن تكون تفاصيل الطلبات السابقة متاحة فقط لأصحاب الحسابات المعنية
      • يجب أن تكون التقييمات والتعليقات متاحة للعرض بعد إتمام الطلب
      الافتراضات
      • العميل ومحل قطع الغيار يستخدمان المنصة بشكل منتظم
      • جميع الطلبات السابقة مسجلة ومؤرشفة بشكل صحيح
      المتطلبات الخاصة
      • يجب أن تكون واجهة الطلبات السابقة سهلة الاستخدام والتنقل
      • يجب أن تحتوي واجهة الطلبات السابقة على جميع التفاصيل المتعلقة بالطلبات السابقة
      الملاحظات والمشاكل
      • في حالة وجود مشاكل في عرض تفاصيل الطلبات، يجب على المنصة توفير دعم فني لحل المشكلة
      المدخلاتاختيار الطلب لعرض تفاصيله |
      المخرجات
      • عرض تفاصيل الطلب
      • عرض التقييمات والتعليقات
      تفاعلات المستخدم
      • واجهة الطلبات السابقة
      • واجهة تفاصيل الطلب
      الشروط الخاصة
      • في حالة عدم توفر اتصال بالإنترنت، يمكن عرض تفاصيل الطلبات المؤرشفة محلياً
      سيناريوهات الاستخدام
      • الاطلاع على تفاصيل الطلبات السابقة
      • استعراض التقييمات والتعليقات على الطلبات
      متطلبات الأمان
      • ضمان سرية وأمان بيانات الطلبات السابقة
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الطلبات
      • تكامل مع واجهة المستخدم للعرض العام
      القيود والافتراضات
      • وجود حساب لكل من العميل ومحل قطع الغيار
      • وجود طلبات سابقة مسجلة
      متطلبات الاختبار
      • اختبار واجهة الطلبات السابقة
      • اختبار عرض تفاصيل الطلبات
      تفاصيل ال API
      Method: GET || Endpoint: /api/v1/order-history
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200Orders : Array
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تاريخ الطلب

      • textblock
        • سجل الطلبات السابقة

      • list
        • النوع : order_id: نص date: نص details: نص rating: integer comment: نص

      3.38.2.4- المنصة تقوم بأرشفة كافة بيانات الخدمة في سجلات المنصة بمجرد إنهاء الخدمة

      graph LR; A[استلام التقييمات والتعليقات] --> B[ربط التقييمات بالطلبات]; B --> C[حفظ البيانات في سجلات الطلبات]; C --> D[إتاحة البيانات للمراجعة];
      العنوانالتفاصيل
      المستخدمالمنصة
      الشروط المسبقة
      • انتهاء الخدمة بنجاح
      • إرسال التقييم من قبل العميل ومحل قطع الغيار
      الشروط اللاحقة
      • حفظ جميع بيانات الحالة في سجلات المنصة
      تسلسل الأحداث
      • استلام التقييمات والتعليقات
      • ربط التقييمات بالطلبات
      • حفظ البيانات في سجلات الطلبات
      • إتاحة البيانات للمراجعة
      القواعد التجارية
      • يجب أرشفة جميع التقييمات والتعليقات بعد إنهاء الخدمة
      • يجب ربط التقييمات بالطلبات المعنية بشكل صحيح
      الافتراضات
      • العميل ومحل قطع الغيار يرسلان التقييمات بعد إنهاء الخدمة
      • المنصة قادرة على حفظ البيانات بشكل آمن
      المتطلبات الخاصة
      • يجب أن تكون عملية الأرشفة سريعة وموثوقة
      • يجب أن تتيح المنصة إمكانية مراجعة البيانات عند الحاجة
      الملاحظات والمشاكل
      • في حالة حدوث خطأ أثناء عملية الأرشفة، يجب على المنصة تقديم دعم فني لحل المشكلة
      المدخلاتالتقييمات والتعليقات من العميل ومحل قطع الغيار |
      المخرجات
      • تأكيد أرشفة البيانات
      • إتاحة البيانات للمراجعة
      تفاعلات المستخدم
      • واجهة مراجعة الطلبات المؤرشفة
      الشروط الخاصة
      • في حالة عدم توفر اتصال بالإنترنت، يتم حفظ التقييمات محلياً وإرسالها عند استعادة الاتصال
      سيناريوهات الاستخدام
      • أرشفة بيانات الطلبات والتقييمات
      • مراجعة البيانات المؤرشفة
      متطلبات الأمان
      • ضمان سرية وأمان بيانات الأرشفة
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الطلبات
      • تكامل مع نظام التقييمات
      القيود والافتراضات
      • انتهاء الخدمة بنجاح
      • إرسال التقييمات من قبل العميل ومحل قطع الغيار
      متطلبات الاختبار
      • اختبار عملية الأرشفة
      • اختبار عملية مراجعة البيانات المؤرشفة
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/archive-service-data
      Request Headers
      Authorization: Bearer token

      Request Body

      order_id: نص Customer_review : integer, نص Store_review : integer, نص

      Response

      الحالةالمحتوى
      200status: نص archive_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة أرشفة بيانات الخدمة

      • textblock
        • أرشفة بيانات الخدمة

      • form
        • Button
          • العنوان : أرشفة
          • الخيارات : handleArchiveServiceData
      الاشعارات

      العنوان : تأكيد الأرشفة
      الرسالة : تمت أرشفة بيانات الخدمة بنجاح
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : النظام

      3.39 - طلب تخليص جمركي

      3.39.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • تسهيل العملية الجمركية بتوفير منصة مركزية تتيح للعملاء طلب خدمات التخليص الجمركي وارفاق الوثائق المطلوبة بكل سهولة وسرعة
      الجهات المعنية
      • العميل
      • المخلص الجمركي
      الخطوات الرئيسية
      • يقوم العميل بإرفاق وثائق التخليص الجمركي مثل شهادة المنشأ، فاتورة الحمولة، وثيقة التعبئة، شهادة الزراعة، الخ
      • العميل يحدد المنفذ الجمركي المطلوب
      • العميل يختار آلية إسناد الطلب وهي إما تخصيص مخلص جمركي أو النشر العام للطلب على المنصة
      • العميل يقوم بإرسال الطلب
      الخطوات البديلة
      • العميل يمكن أن يحتاج إلى تعديل الوثائق المرفقة أو المنفذ الجمركي بعد إرسال الطلب
      قصص المستخدمين
      • المستخدم، العميل، يستطيع رفع وثائق التخليص الجمركي وتحديد المنفذ الجمركي المطلوب
      • المستخدم، العميل، يستطيع اختيار آلية إسناد الطلب إما بتخصيص مخلص جمركي أو النشر العام للطلب على المنصة
      • المستخدم، العميل، يستطيع إرسال الطلب للتخليص الجمركي
      • المستخدم، يمكن للعميل تعديل الوثائق المرفقة أو المنفذ الجمركي المحدد بعد إرسال الطلب، إذا دعت الحاجة
      • المستخدم, المخلص الجمركي لديه القدرة على مراجعة الطلبات وقبولها أو رفضها بناءً على النشاط العام للطلبات الجمركية
      مؤشرات الأداء
      • عدد طلبات التخليص الجمركي

      3.39.2 حالات الاستخدام

      3.39.2.1- العميل يقوم بإرفاق وثائق التخليص الجمركي مثل شهادة المنشأ، فاتورة الحمولة، وثيقة التعبئة، شهادة الزراعة، الخ

      graph LR; A[فتح صفحة طلب التخليص الجمركي] --> B[إرفاق الوثائق المطلوبة]; B --> C[تحديد المنفذ الجمركي]; C --> D[اختيار آلية إسناد الطلب]; D --> E[إرسال الطلب];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • توفر الوثائق اللازمة
      • وجود حساب للعميل على المنصة
      الشروط اللاحقة
      • إرسال الطلب بنجاح
      • إتاحة الوثائق للمخلص الجمركي
      تسلسل الأحداث
      • فتح صفحة طلب التخليص الجمركي
      • إرفاق الوثائق المطلوبة
      • تحديد المنفذ الجمركي
      • اختيار آلية إسناد الطلب
      • إرسال الطلب
      القواعد التجارية
      • يجب أن تكون جميع الوثائق مرفقة بصيغة مقبولة (PDF، JPG، PNG)
      • يجب أن يتم فحص جميع الوثائق من قبل المخلص الجمركي
      الافتراضات
      • العميل يمتلك الوثائق المطلوبة
      • العميل يعلم بالمنفذ الجمركي المطلوب
      المتطلبات الخاصة
      • يجب أن تكون واجهة إرفاق الوثائق سهلة الاستخدام وتدعم صيغ متعددة للوثائق
      • يجب أن تتيح المنصة للعميل متابعة حالة الطلب بعد إرساله
      الملاحظات والمشاكل
      • في حالة عدم اكتمال الوثائق المطلوبة، يجب على المنصة إشعار العميل لتوفير الوثائق الناقصة
      المدخلاتوثائق التخليص الجمركي (شهادة المنشأ، فاتورة الحمولة، وثيقة التعبئة، شهادة الزراعة) | تحديد المنفذ الجمركي | آلية إسناد الطلب |
      المخرجات
      • تأكيد إرسال الطلب
      • إتاحة الوثائق للمخلص الجمركي
      تفاعلات المستخدم
      • واجهة طلب التخليص الجمركي
      • واجهة إرفاق الوثائق
      الشروط الخاصة
      • في حالة وجود مشاكل في رفع الوثائق، يتم حفظ الطلب مؤقتاً وإرسال إشعار للعميل
      سيناريوهات الاستخدام
      • إرفاق وثائق التخليص الجمركي
      • تقديم طلب تخليص جمركي
      متطلبات الأمان
      • ضمان سرية وأمان الوثائق المرفقة
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الطلبات
      • تكامل مع نظام المخلص الجمركي
      القيود والافتراضات
      • توفر الوثائق اللازمة
      • وجود حساب للعميل
      متطلبات الاختبار
      • اختبار واجهة إرفاق الوثائق
      • اختبار عملية إرسال الطلب
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/custom-clearance-request
      Request Headers
      Authorization: Bearer token

      Request Body

      customer_id: نص Documents : نص, نص, نص, نص customs_port: نص assignment_method: نص

      Response

      الحالةالمحتوى
      200status: نص request_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة طلب التخليص الجمركي

      • textblock
        • طلب التخليص الجمركي

      • form
        • file
          • العنوان : إرفاق الوثائق المطلوبة
        • select
          • العنوان : تحديد المنفذ الجمركي
          • الخيارات : ["منفذ 1","منفذ 2","منفذ 3"]
        • Button
          • العنوان : إرسال الطلب
          • الخيارات : handleSubmitRequest
      الاشعارات

      العنوان : تأكيد إرسال الطلب
      الرسالة : تم إرسال طلب التخليص الجمركي بنجاح وإرفاق الوثائق المطلوبة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.39.2.2- العميل يحدد المنفذ الجمركي المطلوب

      graph LR; A[فتح صفحة طلب التخليص الجمركي] --> B[إرفاق الوثائق المطلوبة]; B --> C[تحديد المنفذ الجمركي];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • توفر الوثائق اللازمة
      • وجود حساب للعميل على المنصة
      الشروط اللاحقة
      • تحديد المنفذ الجمركي في الطلب
      تسلسل الأحداث
      • فتح صفحة طلب التخليص الجمركي
      • إرفاق الوثائق المطلوبة
      • تحديد المنفذ الجمركي
      القواعد التجارية
      • يجب أن تكون جميع الوثائق مرفقة بصيغة مقبولة (PDF، JPG، PNG)
      • يجب على العميل تحديد المنفذ الجمركي بدقة
      الافتراضات
      • العميل يمتلك الوثائق المطلوبة
      • العميل يعلم بالمنفذ الجمركي المطلوب
      المتطلبات الخاصة
      • يجب أن تكون واجهة إرفاق الوثائق وتحديد المنفذ الجمركي سهلة الاستخدام
      الملاحظات والمشاكل
      • في حالة عدم اكتمال الوثائق المطلوبة، يجب على المنصة إشعار العميل لتوفير الوثائق الناقصة
      المدخلاتوثائق التخليص الجمركي |
      المخرجات
      • تحديد المنفذ الجمركي في الطلب
      تفاعلات المستخدم
      • واجهة طلب التخليص الجمركي
      • واجهة إرفاق الوثائق
      • واجهة تحديد المنفذ الجمركي
      الشروط الخاصة
      • في حالة وجود مشاكل في رفع الوثائق، يتم حفظ الطلب مؤقتاً وإرسال إشعار للعميل
      سيناريوهات الاستخدام
      • إرفاق وثائق التخليص الجمركي
      • تحديد المنفذ الجمركي
      متطلبات الأمان
      • ضمان سرية وأمان الوثائق المرفقة
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الطلبات
      • تكامل مع نظام المخلص الجمركي
      القيود والافتراضات
      • توفر الوثائق اللازمة
      • وجود حساب للعميل
      متطلبات الاختبار
      • اختبار واجهة إرفاق الوثائق
      • اختبار عملية تحديد المنفذ الجمركي
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/custom-clearance-port
      Request Headers
      Authorization: Bearer token

      Request Body

      customer_id: نص Documents : نص, نص, نص, نص customs_port: نص

      Response

      الحالةالمحتوى
      200status: نص request_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تحديد ميناء الجمارك

      • textblock
        • تحديد المنفذ الجمركي

      • form
        • file
          • العنوان : إرفاق الوثائق المطلوبة
        • select
          • العنوان : تحديد المنفذ الجمركي
          • الخيارات : ["منفذ 1","منفذ 2","منفذ 3"]
        • Button
          • العنوان : إرسال
          • الخيارات : handleSubmitRequest
      الاشعارات

      العنوان : تأكيد تحديد المنفذ الجمركي
      الرسالة : تم تحديد المنفذ الجمركي في طلب التخليص الجمركي بنجاح
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.39.2.3- العميل يختار آلية إسناد الطلب وهي إما تخصيص مخلص جمركي أو النشر العام للطلب على المنصة

      graph LR; A[فتح صفحة طلب التخليص الجمركي] --> B[إرفاق الوثائق المطلوبة]; B --> C[تحديد المنفذ الجمركي]; C --> D[اختيار آلية إسناد الطلب];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • توفر الوثائق اللازمة
      • وجود حساب للعميل على المنصة
      الشروط اللاحقة
      • تحديد آلية إسناد الطلب في النظام
      تسلسل الأحداث
      • فتح صفحة طلب التخليص الجمركي
      • إرفاق الوثائق المطلوبة
      • تحديد المنفذ الجمركي
      • اختيار آلية إسناد الطلب
      القواعد التجارية
      • يجب أن تكون جميع الوثائق مرفقة بصيغة مقبولة (PDF، JPG، PNG)
      • يجب على العميل تحديد آلية إسناد الطلب بدقة
      الافتراضات
      • العميل يمتلك الوثائق المطلوبة
      • العميل يعلم بالمنفذ الجمركي المطلوب
      المتطلبات الخاصة
      • يجب أن تكون واجهة إرفاق الوثائق وتحديد المنفذ الجمركي واختيار آلية إسناد الطلب سهلة الاستخدام
      الملاحظات والمشاكل
      • في حالة عدم اكتمال الوثائق المطلوبة، يجب على المنصة إشعار العميل لتوفير الوثائق الناقصة
      المدخلاتوثائق التخليص الجمركي | تحديد المنفذ الجمركي | آلية إسناد الطلب |
      المخرجات
      • تأكيد تحديد آلية إسناد الطلب
      تفاعلات المستخدم
      • واجهة طلب التخليص الجمركي
      • واجهة إرفاق الوثائق
      • واجهة تحديد المنفذ الجمركي
      • واجهة اختيار آلية إسناد الطلب
      الشروط الخاصة
      • في حالة وجود مشاكل في رفع الوثائق، يتم حفظ الطلب مؤقتاً وإرسال إشعار للعميل
      سيناريوهات الاستخدام
      • إرفاق وثائق التخليص الجمركي
      • تحديد المنفذ الجمركي
      • اختيار آلية إسناد الطلب
      متطلبات الأمان
      • ضمان سرية وأمان الوثائق المرفقة
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الطلبات
      • تكامل مع نظام المخلص الجمركي
      القيود والافتراضات
      • توفر الوثائق اللازمة
      • وجود حساب للعميل
      متطلبات الاختبار
      • اختبار واجهة إرفاق الوثائق
      • اختبار عملية تحديد المنفذ الجمركي
      • اختبار عملية اختيار آلية إسناد الطلب
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/custom-clearance-assignment
      Request Headers
      Authorization: Bearer token

      Request Body

      customer_id: نص Documents : نص, نص, نص, نص customs_port: نص assignment_method: نص

      Response

      الحالةالمحتوى
      200status: نص request_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تعيين التخليص الجمركي

      • textblock
        • طلب التخليص الجمركي

      • form
        • file
          • العنوان : إرفاق الوثائق المطلوبة
        • select
          • العنوان : تحديد المنفذ الجمركي
          • الخيارات : ["منفذ 1","منفذ 2","منفذ 3"]
        • Button
          • العنوان : إرسال
          • الخيارات : handleSubmitRequest
      الاشعارات

      العنوان : تأكيد آلية إسناد الطلب
      الرسالة : تم تحديد آلية إسناد الطلب في طلب التخليص الجمركي بنجاح
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.39.2.4- العميل يقوم بإرسال الطلب

      graph LR; A[فتح صفحة طلب التخليص الجمركي] --> B[إرفاق الوثائق المطلوبة]; B --> C[تحديد المنفذ الجمركي]; C --> D[اختيار آلية إسناد الطلب]; D --> E[إرسال الطلب];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • إرفاق جميع الوثائق المطلوبة
      • تحديد المنفذ الجمركي وآلية إسناد الطلب
      الشروط اللاحقة
      • إرسال الطلب إلى المخلص الجمركي
      تسلسل الأحداث
      • فتح صفحة طلب التخليص الجمركي
      • إرفاق الوثائق المطلوبة
      • تحديد المنفذ الجمركي
      • اختيار آلية إسناد الطلب
      • إرسال الطلب
      القواعد التجارية
      • يجب أن تكون جميع الوثائق مرفقة بصيغة مقبولة (PDF، JPG، PNG)
      • يجب على العميل تحديد المنفذ الجمركي وآلية إسناد الطلب بدقة
      الافتراضات
      • العميل يمتلك الوثائق المطلوبة
      • العميل يعلم بالمنفذ الجمركي المطلوب وآلية إسناد الطلب
      المتطلبات الخاصة
      • يجب أن تكون واجهة إرفاق الوثائق وتحديد المنفذ الجمركي واختيار آلية إسناد الطلب سهلة الاستخدام
      الملاحظات والمشاكل
      • في حالة عدم اكتمال الوثائق المطلوبة، يجب على المنصة إشعار العميل لتوفير الوثائق الناقصة
      المدخلاتوثائق التخليص الجمركي | تحديد المنفذ الجمركي | آلية إسناد الطلب |
      المخرجات
      • تأكيد إرسال الطلب
      • إرسال الطلب إلى المخلص الجمركي
      تفاعلات المستخدم
      • واجهة طلب التخليص الجمركي
      • واجهة إرفاق الوثائق
      • واجهة تحديد المنفذ الجمركي
      • واجهة اختيار آلية إسناد الطلب
      الشروط الخاصة
      • في حالة وجود مشاكل في رفع الوثائق، يتم حفظ الطلب مؤقتاً وإرسال إشعار للعميل
      سيناريوهات الاستخدام
      • إرفاق وثائق التخليص الجمركي
      • تحديد المنفذ الجمركي
      • اختيار آلية إسناد الطلب
      • إرسال الطلب
      متطلبات الأمان
      • ضمان سرية وأمان الوثائق المرفقة
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الطلبات
      • تكامل مع نظام المخلص الجمركي
      القيود والافتراضات
      • توفر الوثائق اللازمة
      • تحديد المنفذ الجمركي وآلية إسناد الطلب
      متطلبات الاختبار
      • اختبار واجهة إرفاق الوثائق
      • اختبار عملية تحديد المنفذ الجمركي
      • اختبار عملية اختيار آلية إسناد الطلب
      • اختبار عملية إرسال الطلب
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/submit-custom-clearance-request
      Request Headers
      Authorization: Bearer token

      Request Body

      customer_id: نص Documents : نص, نص, نص, نص customs_port: نص assignment_method: نص

      Response

      الحالةالمحتوى
      200status: نص request_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تقديم طلب التخليص الجمركي

      • textblock
        • طلب التخليص الجمركي

      • form
        • file
          • العنوان : إرفاق الوثائق المطلوبة
        • select
          • العنوان : تحديد المنفذ الجمركي
          • الخيارات : ["منفذ 1","منفذ 2","منفذ 3"]
        • Button
          • العنوان : إرسال
          • الخيارات : handleSubmitRequest
      الاشعارات

      العنوان : تأكيد إرسال الطلب
      الرسالة : تم إرسال طلب التخليص الجمركي بنجاح وإرفاق الوثائق المطلوبة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.39.2.5- العميل يمكن أن يحتاج إلى تعديل الوثائق المرفقة أو المنفذ الجمركي بعد إرسال الطلب

      graph LR; A[فتح صفحة الطلبات الحالية] --> B[اختيار الطلب المراد تعديله]; B --> C[تعديل الوثائق أو المنفذ الجمركي]; C --> D[حفظ التعديلات];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • وجود طلب قيد المراجعة
      الشروط اللاحقة
      • تحديث الوثائق أو المنفذ الجمركي في الطلب
      تسلسل الأحداث
      • فحص الطلب المرسل
      • ارسال اشعار بالتعديل
      • فتح صفحة الطلبات الحالية
      • اختيار الطلب المراد تعديله
      • تعديل الوثائق أو المنفذ الجمركي
      • حفظ التعديلات
      القواعد التجارية
      • يمكن تعديل الطلب فقط إذا كان قيد المراجعة
      • يجب على العميل التأكد من صحة الوثائق الجديدة أو المنفذ الجمركي
      الافتراضات
      • العميل يلاحظ الحاجة لتعديل الطلب بعد إرساله
      • الطلب لم يتم الموافقة عليه بعد
      المتطلبات الخاصة
      • يجب أن تكون واجهة تعديل الطلب سهلة الاستخدام وتدعم صيغ متعددة للوثائق
      الملاحظات والمشاكل
      • في حالة حدوث خطأ أثناء عملية التعديل، يجب على المنصة تقديم دعم فني لحل المشكلة
      المدخلاتتحديد الطلب المطلوب تعديله | وثائق التخليص الجمركي المعدلة | تحديد المنفذ الجمركي الجديد (إن وجد) |
      المخرجات
      • تأكيد حفظ التعديلات
      • تحديث الوثائق أو المنفذ الجمركي في النظام
      تفاعلات المستخدم
      • واجهة الطلبات الحالية
      • واجهة تعديل الطلب
      الشروط الخاصة
      • في حالة عدم توفر اتصال بالإنترنت، يتم حفظ التعديلات مؤقتاً وإرسالها عند استعادة الاتصال
      سيناريوهات الاستخدام
      • تعديل وثائق التخليص الجمركي المرفقة
      • تعديل المنفذ الجمركي
      متطلبات الأمان
      • ضمان سرية وأمان الوثائق المرفقة والتعديلات المدخلة
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الطلبات
      • تكامل مع نظام المخلص الجمركي
      القيود والافتراضات
      • وجود طلب قيد المراجعة
      • رغبة العميل في تعديل الطلب
      متطلبات الاختبار
      • اختبار واجهة تعديل الطلب
      • اختبار عملية حفظ التعديلات
      تفاصيل ال API
      Method: PUT || Endpoint: /api/v1/custom-clearance-request/{request_id}
      Request Headers
      Authorization: Bearer token

      Request Body

      Documents : نص, نص, نص, نص customs_port: نص

      Response

      الحالةالمحتوى
      200status: نص request_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تعديل طلب التخليص الجمركي

      • textblock
        • تعديل طلب التخليص الجمركي

      • list
        • النوع : order_id: نص date: نص status: نص

      • form
        • file
          • العنوان : إرفاق الوثائق الجديدة
        • select
          • العنوان : تحديد المنفذ الجمركي الجديد
          • الخيارات : ["منفذ 1","منفذ 2","منفذ 3"]
        • Button
          • العنوان : حفظ التعديلات
          • الخيارات : handleSaveChanges
      الاشعارات

      العنوان : تأكيد حفظ التعديلات
      الرسالة : تم تعديل طلب التخليص الجمركي وحفظ التعديلات بنجاح
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.40 - إرسال الطلب

      3.40.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      الجهات المعنية
      • جهات التخليص الجمركي
      • الناقل
      • العميل
      • نظام E-SHLF
      الخطوات الرئيسية
      • الناقل يقوم بإرسال الطلب إلى جهات التخليص الجمركي عن طريق المنصة
      • جهات التخليص تقوم بمراجعة الطلب والوثائق المرفقة
      • إصدار السعر للطلب من قبل جهات التخليص بما في ذلك: مبلغ الأجرة، رسوم خدمة التخليص، ضريبة رسوم التخليص، والمبلغ الصافي المستحق للمخلص بعد خصم الرسوم من الأجرة
      الخطوات البديلة
      قصص المستخدمين
      • الناقل، يرسل الطلب: الناقل يحتاج إلى إرسال الطلب والوثائق المرفقة لجهات التخليص الجمركي عبر المنصة، حتى يتمكن من تسهيل عملية النقل والتخليص الجمركي
      • جهة التخليص، تقوم بمراجعة الطلب: جهة التخليص تحتاج إلى مراجعة الطلب والوثائق المرفقة، الشيء الذي يعزز العمليات الجمركية الصحيحة والكفاءة
      • جهة التخليص، تصدر السعر للطلب: بعد مراجعة الطلب، تحتاج جهة التخليص الجمركي إلى تحديد الأجرة، رسوم خدمة التخليص، ضريبة رسوم التخليص، والمبلغ الصافي المستحق للمخلص بعد خصم الرسوم من الأجرة. ذلك يتيح للعميل فهم تكاليف الخدمة المقدمة وتسهيل عملية الدفع
      • العميل، يقوم بالدفع الإلكتروني للخدمة: بناءً على سعر الطلب الصادر من جهة التخليص، يحتاج العميل إلى سداد المبلغ عبر الدفع الإلكتروني في المنصة، حتى يتمكن من استكمال الخدمة
      مؤشرات الأداء
      • عدد طلبات التخليص التي تم الاستجابة لها و نسبتها لإجمالي الطلبات
      • عدد المستجيبين لطلبات التخليص

      3.40.2 حالات الاستخدام

      3.40.2.1- الناقل يقوم بإرسال الطلب إلى جهات التخليص الجمركي عن طريق المنصة

      graph LR; A[فتح صفحة الطلبات الجمركية] --> B[اختيار الطلب المكتمل]; B --> C[الضغط على 'إرسال الطلب']; C --> D[إرسال الطلب والوثائق المرفقة]; D --> E[تأكيد استلام الطلب];
      العنوانالتفاصيل
      المستخدمالناقل
      الشروط المسبقة
      • وجود حساب للناقل على المنصة
      • وجود طلب تخليص جمركي مكتمل
      الشروط اللاحقة
      • إرسال الطلب إلى جهات التخليص الجمركي
      • تأكيد استلام الطلب من جهة التخليص
      تسلسل الأحداث
      • فتح صفحة الطلبات الجمركية
      • اختيار الطلب المكتمل
      • الضغط على 'إرسال الطلب'
      • إرسال الطلب والوثائق المرفقة
      • تأكيد استلام الطلب
      القواعد التجارية
      • يجب على المنصة التأكد من أن جميع الوثائق مرفقة بشكل صحيح قبل إرسال الطلب
      • يجب أن يتم إرسال الطلب إلى جهة التخليص الجمركي المعنية فقط
      الافتراضات
      • الناقل يمتلك حساب على المنصة
      • الطلب يحتوي على جميع الوثائق اللازمة
      المتطلبات الخاصة
      • يجب أن تكون واجهة إرسال الطلب سهلة الاستخدام وتدعم تأكيد استلام الطلب
      • يجب أن تتضمن المنصة نظام متابعة لحالة الطلب بعد إرساله
      الملاحظات والمشاكل
      • في حالة وجود مشاكل في إرسال الطلب، يجب على المنصة توفير دعم فني لحل المشكلة
      المدخلاتتحديد الطلب المكتمل | وثائق التخليص الجمركي المرفقة |
      المخرجات
      • تأكيد إرسال الطلب
      • تأكيد استلام الطلب من جهة التخليص
      تفاعلات المستخدم
      • واجهة الطلبات الجمركية
      • واجهة إرسال الطلب
      الشروط الخاصة
      • في حالة عدم توفر اتصال بالإنترنت، يتم حفظ الطلب مؤقتاً وإرساله عند استعادة الاتصال
      سيناريوهات الاستخدام
      • إرسال طلب التخليص الجمركي
      • متابعة حالة الطلب بعد الإرسال
      متطلبات الأمان
      • ضمان سرية وأمان الوثائق المرفقة أثناء الإرسال
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الطلبات
      • تكامل مع نظام التخليص الجمركي
      القيود والافتراضات
      • وجود حساب للناقل
      • وجود طلب مكتمل
      متطلبات الاختبار
      • اختبار واجهة إرسال الطلب
      • اختبار عملية تأكيد استلام الطلب
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/send-custom-clearance-request
      Request Headers
      Authorization: Bearer token

      Request Body

      carrier_id: نص request_id: نص

      Response

      الحالةالمحتوى
      200status: نص confirmation: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة إرسال طلب التخليص الجمركي

      • textblock
        • إرسال طلب التخليص الجمركي

      • list
        • النوع : request_id: نص status: نص details: نص

      • form
        • Button
          • العنوان : إرسال الطلب
          • الخيارات : handleSendRequest
      الاشعارات

      العنوان : تأكيد إرسال الطلب
      الرسالة : تم إرسال طلب التخليص الجمركي بنجاح وتم استلامه من قبل جهة التخليص
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : الناقل

      3.40.2.2- جهات التخليص تقوم بمراجعة الطلب والوثائق المرفقة

      graph LR; A[استلام الطلب عبر المنصة] --> B[فتح الطلب والوثائق المرفقة]; B --> C[مراجعة الوثائق]; C --> D[تحديد الأجرة ورسوم التخليص]; D --> E[تحديد المبلغ الصافي المستحق];
      العنوانالتفاصيل
      المستخدمجهة التخليص الجمركي
      الشروط المسبقة
      • استلام الطلب والوثائق المرفقة من الناقل
      • وجود حساب لجهة التخليص الجمركي على المنصة
      الشروط اللاحقة
      • مراجعة الطلب وتحديد الرسوم المستحقة
      تسلسل الأحداث
      • استلام الطلب عبر المنصة
      • فتح الطلب والوثائق المرفقة
      • مراجعة الوثائق
      • تحديد الأجرة ورسوم التخليص
      • تحديد المبلغ الصافي المستحق
      القواعد التجارية
      • يجب على جهة التخليص التأكد من صحة جميع الوثائق المرفقة
      • يجب تحديد الرسوم المستحقة بشكل دقيق وشفاف
      الافتراضات
      • جهة التخليص تمتلك حساب على المنصة
      • الوثائق المرفقة كاملة وصحيحة
      المتطلبات الخاصة
      • يجب أن تكون واجهة مراجعة الطلب والوثائق المرفقة سهلة الاستخدام وتتيح الوصول السريع إلى جميع الوثائق
      الملاحظات والمشاكل
      • في حالة وجود مشاكل في الوثائق المرفقة، يجب على جهة التخليص التواصل مع الناقل لتصحيح الأخطاء
      المدخلاتالطلب والوثائق المرفقة |
      المخرجات
      • تأكيد مراجعة الطلب
      • تحديد الرسوم المستحقة
      تفاعلات المستخدم
      • واجهة مراجعة الطلبات
      • واجهة مراجعة الوثائق المرفقة
      الشروط الخاصة
      • في حالة وجود مشاكل في الوثائق، يتم إشعار الناقل لتصحيح الأخطاء
      سيناريوهات الاستخدام
      • مراجعة طلب التخليص الجمركي
      • تحديد الرسوم المستحقة
      متطلبات الأمان
      • ضمان سرية وأمان الوثائق المرفقة أثناء المراجعة
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الطلبات
      • تكامل مع نظام الرسوم والضرائب
      القيود والافتراضات
      • استلام الطلب والوثائق من الناقل
      • وجود حساب لجهة التخليص الجمركي
      متطلبات الاختبار
      • اختبار واجهة مراجعة الطلب
      • اختبار عملية تحديد الرسوم المستحقة
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/review-custom-clearance-request
      Request Headers
      Authorization: Bearer token

      Request Body

      customs_authority_id: نص request_id: نص documents_reviewed: boolean Fees : number, number, number

      Response

      الحالةالمحتوى
      200status: نص review_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة مراجعة طلب التخليص الجمركي

      • textblock
        • مراجعة طلب التخليص الجمركي

      • list
        • النوع : request_id: نص status: نص details: نص

      • form
        • Button
          • العنوان : تأكيد المراجعة
          • الخيارات : handleReviewConfirmation
      الاشعارات

      العنوان : تأكيد مراجعة الطلب
      الرسالة : تمت مراجعة طلب التخليص الجمركي بنجاح وتحديد الرسوم المستحقة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : جهة التخليص الجمركي

      3.40.2.3- إصدار السعر للطلب من قبل جهات التخليص بما في ذلك: مبلغ الأجرة، رسوم خدمة التخليص، ضريبة رسوم التخليص، والمبلغ الصافي المستحق للمخلص بعد خصم الرسوم من الأجرة

      graph LR; A[تحديد الأجرة ورسوم الخدمة والضريبة] --> B[إصدار الفاتورة النهائية]; B --> C[إشعار الناقل بالسعر النهائي]; C --> D[مراجعة الفاتورة والموافقة على الدفع]; D --> E[إصدار الفاتورة الرسمية];
      العنوانالتفاصيل
      المستخدمجهة التخليص الجمركي
      الشروط المسبقة
      • مراجعة الطلب والوثائق المرفقة
      • تحديد الرسوم المستحقة
      الشروط اللاحقة
      • إصدار الفاتورة النهائية
      • إبلاغ الناقل بالسعر النهائي
      تسلسل الأحداث
      • تحديد الأجرة ورسوم الخدمة والضريبة
      • إصدار الفاتورة النهائية
      • إشعار الناقل بالسعر النهائي
      • مراجعة الفاتورة والموافقة على الدفع
      • إصدار الفاتورة الرسمية
      القواعد التجارية
      • يجب أن تكون الفاتورة واضحة وتفصيلية
      • يجب إبلاغ الناقل بالسعر النهائي قبل إصدار الفاتورة الرسمية
      الافتراضات
      • جهة التخليص الجمركي تمتلك حساب على المنصة
      • الوثائق المرفقة كاملة وصحيحة
      المتطلبات الخاصة
      • يجب أن تكون واجهة إصدار الفاتورة سهلة الاستخدام وتتيح الوصول السريع إلى جميع المعلومات المطلوبة
      الملاحظات والمشاكل
      • في حالة وجود خلاف حول الفاتورة، يجب على جهة التخليص توفير وسيلة لتسوية النزاعات
      المدخلاتتفاصيل الأجرة ورسوم الخدمة والضريبة |
      المخرجات
      • إصدار الفاتورة النهائية
      • إشعار الناقل بالسعر النهائي
      • إصدار الفاتورة الرسمية
      تفاعلات المستخدم
      • واجهة إصدار الفاتورة
      • واجهة إشعار الناقل بالسعر النهائي
      الشروط الخاصة
      • في حالة عدم توفر اتصال بالإنترنت، يتم حفظ تفاصيل الفاتورة مؤقتاً وإصدارها عند استعادة الاتصال
      سيناريوهات الاستخدام
      • إصدار فاتورة طلب التخليص الجمركي
      • إشعار الناقل بالسعر النهائي
      متطلبات الأمان
      • ضمان سرية وأمان تفاصيل الفاتورة أثناء الإرسال
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الطلبات
      • تكامل مع نظام الرسوم والضرائب
      القيود والافتراضات
      • مراجعة الطلب والوثائق
      • تحديد الرسوم المستحقة
      متطلبات الاختبار
      • اختبار واجهة إصدار الفاتورة
      • اختبار عملية إشعار الناقل بالسعر النهائي
      • اختبار عملية إصدار الفاتورة الرسمية
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/issue-custom-clearance-invoice
      Request Headers
      Authorization: Bearer token

      Request Body

      customs_authority_id: نص request_id: نص Fees : number, number, number

      Response

      الحالةالمحتوى
      200status: نص invoice_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة إصدار فاتورة التخليص الجمركي

      • textblock
        • إصدار فاتورة طلب التخليص الجمركي

      • form
        • Button
          • العنوان : إصدار الفاتورة
          • الخيارات : handleIssueInvoice
      الاشعارات

      العنوان : إشعار بالسعر النهائي
      الرسالة : تم إصدار الفاتورة النهائية لطلب التخليص الجمركي. يرجى مراجعة السعر النهائي
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : الناقل

      3.41 - الموافقة على العرض

      3.41.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • توفير واجهة سهلة لعمليات الموافقة على العروض وتأكيد الخدمات
      الجهات المعنية
      • العميل
      • النظام
      الخطوات الرئيسية
      • استلام العرض من مقدمي الخدمات
      • احتساب رسوم الخدمة على طالب الخدمة
      • احتساب الضريبة على الرسوم
      • حساب المبلغ الإجمالي الذي يتضمن (أجرة التخليص+رسوم الخدمة+الضريبة)
      • الموافقة على العرض والمبلغ الإجمالي للخدمة
      الخطوات البديلة
      قصص المستخدمين
      • العميل, بعد استلام العروض من مقدمي الخدمات، يستعرض العروض ويختار الأفضل بناءً على معاييره الخاصة (السعر، التقييم، الجودة، السرعة). بعد الاختيار، يعرض النظام تفاصيل العرض بشكل مفصل، بما في ذلك أجرة التخليص، رسوم الخدمة، الضريبة والمبلغ الإجمالي المطلوب دفعه. بعد الرضاء عن هذه البنود، يقوم طالب الخدمة بالموافقة على العرض ويستعد للدفع
      • النظام, يقوم بالعمليات الحسابية لرسوم الخدمة (الضريبة والمبلغ الإجمالي). ويعرض هذه التفاصيل لطالب الخدمة لاستعراضها و استكمال الطلب. يحدث النظام حالة العرض لتوضيح أنه تم القبول
      مؤشرات الأداء
      • عدد الطلبات التي تم الموافقة عليها ونسبتها إجمالي الطلبات التي تمت الاستجابة لها

      3.41.2 حالات الاستخدام

      3.41.2.1- استلام العرض من مقدمي الخدمات

      graph LR; A[إرسال طلب من قبل العميل] --> B[استلام العروض المقدمة]; B --> C[عرض العروض المستلمة للعميل];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • أن يكون العميل قد أرسل طلبه إلى مقدمي الخدمات
      الشروط اللاحقة
      • يتمكن العميل من رؤية كافة العروض المستلمة من مقدمي الخدمات
      تسلسل الأحداث
      • إرسال طلب من قبل العميل
      • استلام العروض المقدمة
      • عرض العروض المستلمة للعميل
      القواعد التجارية
      • يجب أن تكون العروض المقدمة متوافقة مع متطلبات العميل
      • يجب أن يتم إبلاغ العميل فوراً عند استلام عرض جديد
      الافتراضات
      • مقدمو الخدمات يقومون بالرد على الطلبات المقدمة من العملاء
      • العميل يقوم بمتابعة الطلبات المستلمة بشكل منتظم
      المتطلبات الخاصة
      • يجب أن تكون واجهة استلام العروض سهلة الاستخدام وتتيح عرض كافة العروض بشكل واضح
      الملاحظات والمشاكل
      • في حالة عدم استلام العميل لأي عروض، يجب على المنصة تقديم إشعار بذلك
      المدخلاتالطلبات المرسلة من قبل العميل | العروض المقدمة من مقدمي الخدمات |
      المخرجات
      • عرض كافة العروض المستلمة للعميل
      تفاعلات المستخدم
      • واجهة استلام العروض
      الشروط الخاصة
      • في حالة وجود خطأ في عرض العروض، يجب على المنصة توفير دعم فني لحل المشكلة
      سيناريوهات الاستخدام
      • استلام العروض من مقدمي الخدمات
      • عرض العروض للعميل
      متطلبات الأمان
      • ضمان سرية وأمان العروض المستلمة
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الطلبات
      • تكامل مع نظام مقدمي الخدمات
      القيود والافتراضات
      • إرسال طلب من قبل العميل
      • استلام العروض من مقدمي الخدمات
      متطلبات الاختبار
      • اختبار واجهة استلام العروض
      • اختبار عملية عرض العروض المستلمة
      تفاصيل ال API
      Method: GET || Endpoint: /api/v1/get-service-offers
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200Offers : Array
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة عرض عروض الخدمة

      • textblock
        • العروض المستلمة من مقدمي الخدمات

      • list
        • النوع : provider_id: نص offer_details: نص price: number validity: date

      الاشعارات

      العنوان : عرض جديد مستلم
      الرسالة : تم استلام عرض جديد من مقدم الخدمة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.41.2.2- احتساب رسوم الخدمة على طالب الخدمة

      graph LR; A[استلام العروض من مقدمي الخدمات] --> B[حساب رسوم الخدمة]; B --> C[عرض الرسوم لطالب الخدمة];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • أن يكون العميل قد استلم العروض من مقدمي الخدمات
      الشروط اللاحقة
      • النظام يعرض رسوم الخدمة لطالب الخدمة
      تسلسل الأحداث
      • استلام العروض من مقدمي الخدمات
      • حساب رسوم الخدمة
      • عرض الرسوم لطالب الخدمة
      القواعد التجارية
      • يجب أن يتم احتساب رسوم الخدمة بدقة بناءً على العروض المستلمة
      • يجب عرض الرسوم بشكل واضح لطالب الخدمة
      الافتراضات
      • العميل استلم العروض من مقدمي الخدمات
      • النظام يحتوي على كافة التفاصيل اللازمة لحساب الرسوم
      المتطلبات الخاصة
      • يجب أن تكون واجهة عرض الرسوم سهلة الاستخدام وتتيح للعميل فهم الرسوم المستحقة
      الملاحظات والمشاكل
      • في حالة وجود خطأ في حساب الرسوم، يجب على النظام توفير وسيلة لتصحيح الأخطاء
      المدخلاتالعروض المستلمة من مقدمي الخدمات |
      المخرجات
      • عرض رسوم الخدمة لطالب الخدمة
      تفاعلات المستخدم
      • واجهة عرض الرسوم
      الشروط الخاصة
      • في حالة وجود اختلاف في الرسوم المحتسبة، يجب على النظام تقديم إشعار بذلك
      سيناريوهات الاستخدام
      • احتساب رسوم الخدمة بناءً على العروض
      • عرض الرسوم لطالب الخدمة
      متطلبات الأمان
      • ضمان سرية وأمان معلومات الرسوم
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة العروض
      • تكامل مع نظام الرسوم والضرائب
      القيود والافتراضات
      • استلام العروض من مقدمي الخدمات
      • توفر معلومات كافية لحساب الرسوم
      متطلبات الاختبار
      • اختبار واجهة عرض الرسوم
      • اختبار عملية حساب الرسوم
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/calculate-service-fees
      Request Headers
      Authorization: Bearer token

      Request Body

      customer_id: نص Offers : Array

      Response

      الحالةالمحتوى
      200service_fees: number
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة عرض رسوم الخدمة

      • textblock
        • رسوم الخدمة المستحقة

      • textblock
        • تفاصيل الرسوم {{service_fees}}

      الاشعارات

      العنوان : احتساب رسوم الخدمة
      الرسالة : تم احتساب رسوم الخدمة بناءً على العروض المستلمة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.41.2.3- احتساب الضريبة على الرسوم

      graph LR; A[حساب رسوم الخدمة] --> B[حساب الضريبة على رسوم الخدمة]; B --> C[عرض الضريبة لطالب الخدمة];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • احتساب رسوم الخدمة على طالب الخدمة
      الشروط اللاحقة
      • النظام يعرض الضريبة المحسوبة على الرسوم لطالب الخدمة
      تسلسل الأحداث
      • حساب رسوم الخدمة
      • حساب الضريبة على رسوم الخدمة
      • عرض الضريبة لطالب الخدمة
      القواعد التجارية
      • يجب احتساب الضريبة بدقة بناءً على القوانين واللوائح الضريبية المعمول بها
      • يجب عرض الضريبة بشكل واضح لطالب الخدمة
      الافتراضات
      • النظام يحتوي على كافة التفاصيل اللازمة لحساب الضريبة
      • الضريبة تعتمد على نسبة مئوية محددة من رسوم الخدمة
      المتطلبات الخاصة
      • يجب أن تكون واجهة عرض الضريبة سهلة الاستخدام وتتيح للعميل فهم الضريبة المستحقة
      الملاحظات والمشاكل
      • في حالة وجود خطأ في حساب الضريبة، يجب على النظام توفير وسيلة لتصحيح الأخطاء
      المدخلاترسوم الخدمة |
      المخرجات
      • عرض الضريبة المحسوبة لطالب الخدمة
      تفاعلات المستخدم
      • واجهة عرض الضريبة
      الشروط الخاصة
      • في حالة وجود اختلاف في الضريبة المحتسبة، يجب على النظام تقديم إشعار بذلك
      سيناريوهات الاستخدام
      • احتساب الضريبة على رسوم الخدمة
      • عرض الضريبة لطالب الخدمة
      متطلبات الأمان
      • ضمان سرية وأمان معلومات الضريبة
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الرسوم
      • تكامل مع نظام الضرائب
      القيود والافتراضات
      • احتساب رسوم الخدمة
      • توفر معلومات كافية لحساب الضريبة
      متطلبات الاختبار
      • اختبار واجهة عرض الضريبة
      • اختبار عملية حساب الضريبة
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/calculate-tax
      Request Headers
      Authorization: Bearer token

      Request Body

      service_fees: number

      Response

      الحالةالمحتوى
      200tax_amount: number
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة عرض تفاصيل الضريبة

      • textblock
        • الضريبة المستحقة على الرسوم

      • textblock
        • تفاصيل الضريبة {{tax_amount}}

      الاشعارات

      العنوان : احتساب الضريبة على الرسوم
      الرسالة : تم احتساب الضريبة على رسوم الخدمة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.41.2.4- حساب المبلغ الإجمالي الذي يتضمن (أجرة التخليص+رسوم الخدمة+الضريبة)

      graph LR; A[حساب أجرة التخليص] --> B[حساب رسوم الخدمة]; B --> C[حساب الضريبة على الرسوم]; C --> D[حساب المبلغ الإجمالي]; D --> E[عرض المبلغ الإجمالي لطالب الخدمة];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • احتساب رسوم الخدمة والضريبة على الرسوم
      الشروط اللاحقة
      • عرض المبلغ الإجمالي لطالب الخدمة
      تسلسل الأحداث
      • حساب أجرة التخليص
      • حساب رسوم الخدمة
      • حساب الضريبة على الرسوم
      • حساب المبلغ الإجمالي
      • عرض المبلغ الإجمالي لطالب الخدمة
      القواعد التجارية
      • يجب احتساب المبلغ الإجمالي بدقة بناءً على أجرة التخليص، رسوم الخدمة، والضريبة
      • يجب عرض المبلغ الإجمالي بشكل واضح لطالب الخدمة
      الافتراضات
      • النظام يحتوي على كافة التفاصيل اللازمة لحساب المبلغ الإجمالي
      • المبلغ الإجمالي يعتمد على جمع أجرة التخليص، رسوم الخدمة، والضريبة
      المتطلبات الخاصة
      • يجب أن تكون واجهة عرض المبلغ الإجمالي سهلة الاستخدام وتتيح للعميل فهم المبلغ المستحق
      الملاحظات والمشاكل
      • في حالة وجود خطأ في حساب المبلغ الإجمالي، يجب على النظام توفير وسيلة لتصحيح الأخطاء
      المدخلاتأجرة التخليص | رسوم الخدمة | الضريبة على الرسوم |
      المخرجات
      • عرض المبلغ الإجمالي لطالب الخدمة
      تفاعلات المستخدم
      • واجهة عرض المبلغ الإجمالي
      الشروط الخاصة
      • في حالة وجود اختلاف في المبلغ الإجمالي المحتسب، يجب على النظام تقديم إشعار بذلك
      سيناريوهات الاستخدام
      • حساب المبلغ الإجمالي بناءً على أجرة التخليص، رسوم الخدمة، والضريبة
      • عرض المبلغ الإجمالي لطالب الخدمة
      متطلبات الأمان
      • ضمان سرية وأمان معلومات المبلغ الإجمالي
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الرسوم
      • تكامل مع نظام الضرائب
      القيود والافتراضات
      • احتساب رسوم الخدمة والضريبة على الرسوم
      • توفر معلومات كافية لحساب المبلغ الإجمالي
      متطلبات الاختبار
      • اختبار واجهة عرض المبلغ الإجمالي
      • اختبار عملية حساب المبلغ الإجمالي
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/calculate-total-amount
      Request Headers
      Authorization: Bearer token

      Request Body

      service_fees: number tax_amount: number clearance_fees: number

      Response

      الحالةالمحتوى
      200total_amount: number
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة عرض المبلغ الإجمالي

      • textblock
        • المبلغ الإجمالي المستحق

      • textblock
        • تفاصيل المبلغ الإجمالي

      • list
        • النوع : "service_fees": "number",

        • النوع : "tax_amount": "number",

        • النوع : "clearance_fees": "number",

        • النوع : "total_amount": "number"

      الاشعارات

      العنوان : المبلغ الإجمالي المستحق
      الرسالة : تم احتساب المبلغ الإجمالي المستحق بناءً على أجرة التخليص، رسوم الخدمة، والضريبة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.41.2.5- الموافقة على العرض والمبلغ الإجمالي للخدمة

      graph LR; A[عرض المبلغ الإجمالي لطالب الخدمة] --> B[استعراض العرض والمبلغ الإجمالي]; B --> C[موافقة العميل على العرض والمبلغ الإجمالي]; C --> D[تحديث حالة العرض في النظام];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • عرض المبلغ الإجمالي لطالب الخدمة
      الشروط اللاحقة
      • النظام يحدث حالة العرض لتوضيح أنه تم القبول
      تسلسل الأحداث
      • عرض المبلغ الإجمالي لطالب الخدمة
      • استعراض العرض والمبلغ الإجمالي
      • موافقة العميل على العرض والمبلغ الإجمالي
      • تحديث حالة العرض في النظام
      القواعد التجارية
      • يجب عرض كافة تفاصيل العرض والمبلغ الإجمالي بشكل واضح
      • يجب تحديث حالة العرض في النظام بعد موافقة العميل
      الافتراضات
      • النظام يحتوي على كافة التفاصيل اللازمة لعرض المبلغ الإجمالي
      • العميل يقوم بمراجعة العرض والمبلغ الإجمالي قبل الموافقة
      المتطلبات الخاصة
      • يجب أن تكون واجهة عرض المبلغ الإجمالي والموافقة عليه سهلة الاستخدام وتتيح للعميل فهم التفاصيل بشكل كامل
      الملاحظات والمشاكل
      • في حالة وجود أي استفسارات حول العرض، يجب أن يتمكن العميل من التواصل مع النظام للحصول على توضيحات
      المدخلاتتفاصيل العرض | المبلغ الإجمالي |
      المخرجات
      • تحديث حالة العرض لتوضيح أنه تم القبول
      تفاعلات المستخدم
      • واجهة عرض العرض والمبلغ الإجمالي
      • واجهة الموافقة على العرض
      الشروط الخاصة
      • في حالة عدم موافقة العميل على العرض، يجب على النظام توفير خيار لإعادة التفاوض أو رفض العرض
      سيناريوهات الاستخدام
      • استعراض العرض والمبلغ الإجمالي
      • موافقة العميل على العرض
      متطلبات الأمان
      • ضمان سرية وأمان تفاصيل العرض والمبلغ الإجمالي
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة العروض
      • تكامل مع نظام إدارة الرسوم والضرائب
      القيود والافتراضات
      • عرض المبلغ الإجمالي لطالب الخدمة
      • موافقة العميل على العرض
      متطلبات الاختبار
      • اختبار واجهة عرض العرض والمبلغ الإجمالي
      • اختبار عملية موافقة العميل
      • اختبار عملية تحديث حالة العرض في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/approve-offer
      Request Headers
      Authorization: Bearer token

      Request Body

      customer_id: نص offer_id: نص total_amount: number

      Response

      الحالةالمحتوى
      200status: approved
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة الموافقة على العرض

      • textblock
        • عرض الخدمة والمبلغ الإجمالي

      • textblock
        • تفاصيل العرض"

      • list
        • النوع : "offer_id": "نص",

        • النوع : "provider_name": "نص",

        • النوع : "service_details": "نص",

        • النوع : "price": "number"

      • textblock
        • المبلغ الإجمالي {{total_amount}}

      • form
        • Button
          • العنوان : موافقة
          • الخيارات : handleApproveOffer
      • رسالة زر الإرسال: موافقة
      • رسالة النجاح: تمت الموافقة على العرض والمبلغ الإجمالي بنجاح
      الاشعارات

      العنوان : الموافقة على العرض
      الرسالة : تمت الموافقة على عرض الخدمة والمبلغ الإجمالي
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : العميل

      3.42 - اتمام الصفقة

      3.42.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • تأمين تكلفة الخدمة وتأكيد التزام العميل بدفعها، وتوفير قناة مركزية لإتمام المعاملات المالية بين العميل ومقدم الخدمة
      الجهات المعنية
      • طالب الخدمة
      • مقدم الخدمة
      • المخلص الجمركي
      الخطوات الرئيسية
      • قبول الصفقة النهائية من طالب الخدمة
      • التأكد من توفر المبلغ في المحفظة الخاصة بطالب الخدمة
      • الحجز على المبلغ الإجمالي المتفق عليه وتجميده ضمن حساب طالب الخدمة
      • في حالة عدم توفر المبلغ في المحفظة، يتم إضافة المبلغ للمحفظة من أحد وسائل الدفع الإلكترونية والحجز عليه مباشرة لإتمام الطلب
      الخطوات البديلة
      • يمكن إلغاء الطلب من قبل طالب الخدمة قبل تفعيل الربط مع المخلص الجمركي
      • يمكن إلغاء الطلب من طرف المخلص الجمركي قبل او بعد تفعيل الربط (ويتم إشعار طالب الخدمة)
      قصص المستخدمين
      • طالب الخدمة: بعد رفع طلب النقل، يمكنني تلقي العروض من مقدمي الخدمة واختيار العرض المناسب بناءً على السعر و الوقت المتوقع للتسليم، ثم أقوم بتأكيد الصفقة ودفع المبلغ المطلوب
      • مقدم الخدمة: بعد قبول العميل للعرض، أتلقى إشعارا بقبول الطلب وأتأكد من دفع العميل للمبلغ المتفق عليه. إذا لم يكن المبلغ متاحًا في المحفظة، يتم إضافته من وسائل الدفع الإلكترونية والحجز عليه مباشرة لإتمام الطلب
      مؤشرات الأداء
      • عدد الطلبات الملغاة من (طالب الخدمة/مقدم الخدمة)
      • عدد الطلبات التي تمت الصفقة لها و نسبتها لإجمالي الطلبات المقبولة

      3.42.2 حالات الاستخدام

      3.42.2.1- قبول الصفقة النهائية من طالب الخدمة

      graph LR; A[استلام العرض والمبلغ الإجمالي] --> B[استعراض الصفقة النهائية]; B --> C[قبول الصفقة النهائية]; C --> D[تحديث حالة الطلب في النظام];
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • استلام طالب الخدمة للعرض والمبلغ الإجمالي للخدمة
      الشروط اللاحقة
      • يتم تحديث حالة الطلب إلى 'مقبول'
      تسلسل الأحداث
      • استلام العرض والمبلغ الإجمالي
      • استعراض الصفقة النهائية
      • قبول الصفقة النهائية
      • تحديث حالة الطلب في النظام
      القواعد التجارية
      • يجب عرض كافة تفاصيل الصفقة النهائية بشكل واضح
      • يجب تحديث حالة الطلب في النظام بعد قبول الصفقة
      الافتراضات
      • النظام يحتوي على كافة التفاصيل اللازمة لعرض الصفقة النهائية
      • طالب الخدمة يقوم بمراجعة العرض النهائي قبل قبوله
      المتطلبات الخاصة
      • يجب أن تكون واجهة عرض الصفقة النهائية والموافقة عليها سهلة الاستخدام وتتيح لطالب الخدمة فهم التفاصيل بشكل كامل
      الملاحظات والمشاكل
      • في حالة وجود أي استفسارات حول الصفقة النهائية، يجب أن يتمكن طالب الخدمة من التواصل مع النظام للحصول على توضيحات
      المدخلاتتفاصيل العرض النهائي | المبلغ الإجمالي |
      المخرجات
      • تحديث حالة الطلب إلى 'مقبول'
      تفاعلات المستخدم
      • واجهة عرض الصفقة النهائية
      • واجهة قبول الصفقة
      الشروط الخاصة
      • في حالة عدم قبول طالب الخدمة للصفقة النهائية، يجب على النظام توفير خيار لإعادة التفاوض أو رفض الصفقة
      سيناريوهات الاستخدام
      • استعراض الصفقة النهائية
      • قبول طالب الخدمة للصفقة
      متطلبات الأمان
      • ضمان سرية وأمان تفاصيل الصفقة النهائية
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة الطلبات
      • تكامل مع نظام إدارة الرسوم والضرائب
      القيود والافتراضات
      • استلام العرض والمبلغ الإجمالي لطالب الخدمة
      • قبول الصفقة النهائية
      متطلبات الاختبار
      • اختبار واجهة عرض الصفقة النهائية
      • اختبار عملية قبول طالب الخدمة
      • اختبار عملية تحديث حالة الطلب في النظام
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/accept-final-deal
      Request Headers
      Authorization: Bearer token

      Request Body

      customer_id: نص deal_id: نص total_amount: number

      Response

      الحالةالمحتوى
      200status: accepted
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة قبول الصفقة النهائية

      • textblock
        • الصفقة النهائية

      • list
        • النوع : "deal_id": "نص",

        • النوع : "provider_name": "نص",

        • النوع : "service_details": "نص",

        • النوع : "total_amount": "number"

      • form
        • Button
          • العنوان : قبول
          • الخيارات : handleAcceptDeal
      • رسالة زر الإرسال: قبول
      • رسالة النجاح: تم قبول الصفقة النهائية بنجاح
      الاشعارات

      العنوان : قبول الصفقة النهائية
      الرسالة : تم قبول الصفقة النهائية والمبلغ الإجمالي
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : طالب الخدمة

      3.42.2.2- التأكد من توفر المبلغ في المحفظة الخاصة بطالب الخدمة

      graph LR; A[قبول الصفقة النهائية] --> B[التحقق من توفر المبلغ في المحفظة]; B --> C[عرض رسالة تأكيد توفر المبلغ];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • قبول طالب الخدمة للصفقة النهائية
      الشروط اللاحقة
      • النظام يعرض رسالة تأكيد توفر المبلغ في المحفظة
      تسلسل الأحداث
      • قبول الصفقة النهائية
      • التحقق من توفر المبلغ في المحفظة
      • عرض رسالة تأكيد توفر المبلغ
      القواعد التجارية
      • يجب التحقق من توفر المبلغ المطلوب بشكل دقيق
      • يجب عرض رسالة تأكيد توفر المبلغ بشكل واضح
      الافتراضات
      • النظام يحتوي على كافة التفاصيل اللازمة للتحقق من المبلغ في المحفظة
      • طالب الخدمة يمتلك محفظة على النظام
      المتطلبات الخاصة
      • يجب أن تكون واجهة عرض رسالة التأكيد سهلة الاستخدام وتتيح لطالب الخدمة فهم حالة المحفظة
      الملاحظات والمشاكل
      • في حالة عدم توفر المبلغ المطلوب، يجب على النظام توفير وسيلة لإبلاغ طالب الخدمة وإرشاده للإجراءات اللازمة
      المدخلاتتفاصيل المحفظة الخاصة بطالب الخدمة |
      المخرجات
      • عرض رسالة تأكيد توفر المبلغ
      تفاعلات المستخدم
      • واجهة عرض رسالة تأكيد توفر المبلغ
      الشروط الخاصة
      • في حالة عدم توفر المبلغ المطلوب، يجب على النظام تقديم خيار لتعبئة المحفظة أو اختيار طريقة دفع بديلة
      سيناريوهات الاستخدام
      • التحقق من توفر المبلغ في المحفظة
      • عرض رسالة تأكيد لطالب الخدمة
      متطلبات الأمان
      • ضمان سرية وأمان معلومات المحفظة
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة المحفظة
      • تكامل مع نظام إدارة الطلبات
      القيود والافتراضات
      • قبول الصفقة النهائية
      • توفر محفظة لطالب الخدمة
      متطلبات الاختبار
      • اختبار واجهة عرض رسالة التأكيد
      • اختبار عملية التحقق من توفر المبلغ
      تفاصيل ال API
      Method: GET || Endpoint: /api/v1/check-wallet-balance
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200balance_sufficient: boolean
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة التحقق من رصيد المحفظة

      • textblock
        • التحقق من رصيد المحفظة

      • textblock
        • رصيد المحفظة الحالي {{"balance": "number"}}

      • textblock
        • "message": "تم التحقق من توفر المبلغ في المحفظة"

      الاشعارات

      العنوان : تأكيد توفر المبلغ في المحفظة
      الرسالة : تم التحقق من توفر المبلغ المطلوب في المحفظة الخاصة بك
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : طالب الخدمة

      3.42.2.3- الحجز على المبلغ الإجمالي المتفق عليه وتجميده ضمن حساب طالب الخدمة

      graph LR; A[تأكيد توفر المبلغ في المحفظة] --> B[حجز المبلغ الإجمالي المتفق عليه]; B --> C[تجميد المبلغ ضمن حساب طالب الخدمة];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • تأكيد توفر المبلغ في المحفظة الخاصة بطالب الخدمة
      الشروط اللاحقة
      • النظام يحجز المبلغ ويجمده ضمن حساب طالب الخدمة
      تسلسل الأحداث
      • تأكيد توفر المبلغ في المحفظة
      • حجز المبلغ الإجمالي المتفق عليه
      • تجميد المبلغ ضمن حساب طالب الخدمة
      القواعد التجارية
      • يجب حجز المبلغ بدقة وبشكل فوري بعد التأكد من توفره
      • يجب تجميد المبلغ ضمن حساب طالب الخدمة لمنع استخدامه في عمليات أخرى
      الافتراضات
      • النظام يحتوي على كافة التفاصيل اللازمة لحجز وتجميد المبلغ
      • المبلغ المطلوب متوفر في المحفظة الخاصة بطالب الخدمة
      المتطلبات الخاصة
      • يجب أن تكون واجهة تأكيد حجز المبلغ سهلة الاستخدام وتتيح لطالب الخدمة معرفة حالة المبلغ المحجوز
      الملاحظات والمشاكل
      • في حالة وجود خطأ في حجز المبلغ، يجب على النظام توفير وسيلة لإبلاغ طالب الخدمة وإرشاده للإجراءات اللازمة
      المدخلاتتفاصيل المحفظة الخاصة بطالب الخدمة | المبلغ الإجمالي المتفق عليه |
      المخرجات
      • حجز المبلغ
      • تجميد المبلغ ضمن حساب طالب الخدمة
      تفاعلات المستخدم
      • واجهة تأكيد حجز المبلغ
      الشروط الخاصة
      • في حالة عدم قدرة النظام على حجز المبلغ، يجب على النظام تقديم إشعار بذلك لطالب الخدمة
      سيناريوهات الاستخدام
      • حجز المبلغ الإجمالي المتفق عليه
      • تجميد المبلغ ضمن حساب طالب الخدمة
      متطلبات الأمان
      • ضمان سرية وأمان عملية حجز وتجميد المبلغ
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة المحفظة
      • تكامل مع نظام إدارة الطلبات
      القيود والافتراضات
      • تأكيد توفر المبلغ في المحفظة
      • توفر محفظة لطالب الخدمة
      متطلبات الاختبار
      • اختبار واجهة تأكيد حجز المبلغ
      • اختبار عملية حجز وتجميد المبلغ
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/hold-amount
      Request Headers
      Authorization: Bearer token

      Request Body

      customer_id: نص total_amount: number

      Response

      الحالةالمحتوى
      200status: amount held and frozen
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تأكيد تجميد المبلغ

      • textblock
        • تأكيد حجز المبلغ

      • textblock
        • تفاصيل المبلغ الإجمالي {{"total_amount": "number"}}

      • textblock
        • Notification | "message": "تم حجز المبلغ وتجميده بنجاح ضمن حسابك"

      الاشعارات

      العنوان : تأكيد حجز المبلغ
      الرسالة : تم حجز المبلغ الإجمالي وتجميده ضمن حسابك
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : طالب الخدمة

      3.42.2.4- في حالة عدم توفر المبلغ في المحفظة، يتم إضافة المبلغ للمحفظة من أحد وسائل الدفع الإلكترونية والحجز عليه مباشرة لإتمام الطلب

      graph LR; A[تحقق النظام من عدم توفر المبلغ في المحفظة] --> B[عرض رسالة لعدم توفر المبلغ]; B --> C[إضافة المبلغ المطلوب إلى المحفظة]; C --> D[حجز المبلغ مباشرة بعد إضافته];
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • النظام يتحقق من عدم توفر المبلغ المطلوب في المحفظة الخاصة بطالب الخدمة
      الشروط اللاحقة
      • المبلغ يضاف إلى المحفظة ويتم الحجز عليه
      تسلسل الأحداث
      • التحقق من عدم توفر المبلغ في المحفظة
      • عرض رسالة لعدم توفر المبلغ
      • إضافة المبلغ المطلوب إلى المحفظة
      • حجز المبلغ مباشرة بعد إضافته
      القواعد التجارية
      • يجب عرض رسالة لطالب الخدمة بوضوح توضح عدم توفر المبلغ في المحفظة
      • يجب السماح لطالب الخدمة باستخدام وسائل الدفع الإلكترونية لإضافة المبلغ المطلوب
      • يجب حجز المبلغ مباشرة بعد إضافته إلى المحفظة
      الافتراضات
      • النظام يحتوي على كافة التفاصيل اللازمة للتحقق من المبلغ في المحفظة
      • طالب الخدمة يمتلك وسيلة دفع إلكترونية صالحة
      المتطلبات الخاصة
      • يجب أن تكون واجهة إضافة المبلغ للمحفظة واستخدام وسائل الدفع الإلكترونية سهلة الاستخدام وتتيح لطالب الخدمة إتمام العملية بسهولة
      الملاحظات والمشاكل
      • في حالة وجود خطأ في عملية الدفع أو الحجز، يجب على النظام توفير وسيلة لإبلاغ طالب الخدمة وإرشاده للإجراءات اللازمة
      المدخلاتتفاصيل المحفظة الخاصة بطالب الخدمة | المبلغ المطلوب | وسيلة الدفع الإلكترونية |
      المخرجات
      • إضافة المبلغ إلى المحفظة
      • حجز المبلغ
      تفاعلات المستخدم
      • واجهة عرض رسالة عدم توفر المبلغ
      • واجهة إضافة المبلغ للمحفظة
      • واجهة استخدام وسائل الدفع الإلكترونية
      الشروط الخاصة
      • في حالة فشل عملية الدفع، يجب على النظام تقديم خيار لإعادة المحاولة أو اختيار وسيلة دفع بديلة
      سيناريوهات الاستخدام
      • التحقق من عدم توفر المبلغ في المحفظة
      • إضافة المبلغ للمحفظة
      • حجز المبلغ بعد إضافته
      متطلبات الأمان
      • ضمان سرية وأمان عملية الدفع وإضافة المبلغ للمحفظة
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة المحفظة
      • تكامل مع نظام إدارة الدفع الإلكتروني
      القيود والافتراضات
      • تحقق النظام من عدم توفر المبلغ
      • توفر وسيلة دفع إلكترونية صالحة
      متطلبات الاختبار
      • اختبار واجهة عرض رسالة عدم توفر المبلغ
      • اختبار عملية إضافة المبلغ للمحفظة
      • اختبار عملية حجز المبلغ بعد إضافته
      تفاصيل ال API
      Method: POST || Endpoint: /api/v1/add-funds-and-hold
      Request Headers
      Authorization: Bearer token

      Request Body

      customer_id: نص amount: number Payment_method : نص, object

      Response

      الحالةالمحتوى
      200status: funds added and held
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة إضافة الأموال وتجميدها

      • textblock
        • إضافة المبلغ للمحفظة

      • form
        • select
          • العنوان : اختر وسيلة الدفع
          • التحقق : "onSelect": "handlePaymentMethodSelect"
          • الخيارات : "بطاقة ائتمان", "بطاقة خصم", "محفظة إلكترونية"
        • Button
          • العنوان : إضافة المبلغ
          • الخيارات : handleAddFunds
      • textblock
        • Notification | "message": "تم إضافة المبلغ للمحفظة وحجزه بنجاح"

      الاشعارات

      العنوان : إضافة المبلغ للمحفظة
      الرسالة : تم إضافة المبلغ المطلوب للمحفظة وحجزه بنجاح
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : طالب الخدمة

      3.42.2.5- إلغاء الطلب من قبل طالب الخدمة قبل تفعيل الربط مع المخلص الجمركي. يتيح هذا الإجراء لطالب الخدمة القدرة على إلغاء الطلب إذا لم يتم تفعيل الربط مع المخلص الجمركي، ويضمن إعادة المبلغ المحجوز إلى محفظة طالب الخدمة

      graph LR A[طالب الخدمة يطلب إلغاء الطلب] --> B{هل تم تفعيل الربط مع المخلص الجمركي؟} B -->|نعم| C[النظام يرفض طلب الإلغاء] B -->|لا| D[النظام يلغي الطلب ويعيد المبلغ المحجوز] C --> E[إشعار لطالب الخدمة بعدم إمكانية الإلغاء] D --> F[إشعار لطالب الخدمة بإتمام الإلغاء]
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • الصفقة لم يتم تفعيلها بعد مع المخلص الجمركي
      الشروط اللاحقة
      • الطلب يتم إلغاؤه ويعود المبلغ المحجوز إلى المحفظة
      تسلسل الأحداث
      • طالب الخدمة يطلب الإلغاء
      • النظام يتحقق من حالة تفعيل الربط
      • في حالة عدم التفعيل، النظام يلغي الطلب ويعيد المبلغ
      • في حالة التفعيل، النظام يرفض الطلب
      الخطوات البديلةإذا تم تفعيل الربط مع المخلص الجمركي قبل طلب الإلغاء
      • النظام يتحقق من حالة تفعيل الربط
      • النظام يرفض طلب الإلغاء ويبلغ طالب الخدمة بعدم إمكانية إلغاء الطلب
      الخطوات الاستثنائيةفي حالة فشل النظام في إعادة المبلغ إلى المحفظة
      • النظام يظهر رسالة خطأ لطالب الخدمة
      • طالب الخدمة يتواصل مع دعم العملاء لحل المشكلة
      القواعد التجارية
      • يجب على النظام التحقق من حالة تفعيل الربط مع المخلص الجمركي قبل تنفيذ طلب الإلغاء
      • يجب على النظام إعادة المبلغ المحجوز إلى محفظة طالب الخدمة في حالة نجاح الإلغاء
      الافتراضات
      • سيقوم طالب الخدمة بطلب الإلغاء قبل تفعيل الربط مع المخلص الجمركي
      • المبلغ المحجوز يمكن إعادته إلى محفظة طالب الخدمة دون تأخير
      المتطلبات الخاصة
      • إمكانية الوصول السريع لدعم العملاء في حالة فشل إعادة المبلغ
      الملاحظات والمشاكل
      • يجب توثيق جميع عمليات الإلغاء لأغراض المراجعة
      • توفير إشعار فوري لطالب الخدمة بحالة الطلب بعد محاولة الإلغاء
      المدخلاتطلب إلغاء من طالب الخدمة |
      المخرجات
      • إشعار بحالة الطلب بعد محاولة الإلغاء
      تفاعلات المستخدم
      • طالب الخدمة يتفاعل مع واجهة المستخدم لإرسال طلب الإلغاء
      الشروط الخاصة
      • إذا كان هناك تأخير في تحديث حالة الربط مع المخلص الجمركي، قد تتأخر عملية الإلغاء
      سيناريوهات الاستخدام
      • طالب الخدمة يطلب إلغاء الطلب لأن الشحنة لم تعد ضرورية
      • طالب الخدمة يكتشف خطأ في الطلب ويرغب في إلغائه لتقديم طلب جديد صحيح
      متطلبات الأمان
      • يجب أن يكون طالب الخدمة مسجلاً في النظام لتقديم طلب الإلغاء
      • يجب أن يتم التحقق من هوية طالب الخدمة قبل تنفيذ طلب الإلغاء
      التكامل مع الأنظمة الأخرى
      • تفاعل مع نظام المحفظة لإعادة المبلغ المحجوز
      القيود والافتراضات
      • يجب أن يتم تنفيذ عملية الإلغاء قبل تفعيل الربط مع المخلص الجمركي
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من قدرة النظام على إلغاء الطلب قبل تفعيل الربط
      • اختبارات أمان للتأكد من أن العملية محمية من الاستخدام غير المصرح به
      تفاصيل ال API
      Method: POST || Endpoint: /api/cancel-request
      Request Headers
      Authorization: Bearer token

      Request Body

      request_id: نص user_id: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request
      500
      الوصف: Internal Server Error

      تفاصيل الواجهات
      شاشة إلغاء الطلب

      • textblock
        • هل أنت متأكد من أنك تريد إلغاء الطلب؟

      • form
        • Button
          • العنوان : إلغاء الطلب
          • الخيارات : submitCancellationRequest
        • Button
          • العنوان : رجوع
          • الخيارات : navigateBack
      الاشعارات

      العنوان : حالة الطلب
      الرسالة : تم إلغاء طلبك وإعادة المبلغ المحجوز إلى محفظتك
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل, SMS  المستقبل : طالب الخدمة

      3.42.2.6- إلغاء الطلب من طرف المخلص الجمركي قبل أو بعد تفعيل الربط. يتيح هذا الإجراء للمخلص الجمركي القدرة على إلغاء الطلب في حالة عدم التنفيذ أو التنفيذ الجزئي، ويضمن إشعار طالب الخدمة بالإلغاء

      graph LR A[المخلص الجمركي يطلب إلغاء الطلب] --> B{هل تم تنفيذ الطلب جزئيًا؟} B -->|نعم| C[النظام يتحقق من حالة التنفيذ] C --> D[النظام يحسب قيمة الخدمات المنفذة جزئيًا] D --> E[النظام يخصم القيمة المنفذة جزئيًا من المبلغ المحجوز] E --> F[النظام يعيد المبلغ المتبقي إلى محفظة طالب الخدمة] B -->|لا| G[النظام يلغي الطلب مباشرة] G --> H[النظام يشعر طالب الخدمة بالإلغاء] F --> I[النظام يشعر طالب الخدمة بالإلغاء]
      العنوانالتفاصيل
      المستخدمالمخلص الجمركي
      الشروط المسبقة
      • الصفقة في حالة عدم التنفيذ أو التنفيذ الجزئي
      الشروط اللاحقة
      • الطلب يتم إلغاؤه ويتم إشعار طالب الخدمة
      تسلسل الأحداث
      • المخلص الجمركي يطلب الإلغاء
      • النظام يتحقق من حالة التنفيذ
      • النظام يلغي الطلب
      • النظام يشعر طالب الخدمة بالإلغاء
      الخطوات البديلةإذا تم إلغاء الطلب بعد التنفيذ الجزئي
      • النظام يتحقق من حالة التنفيذ
      • النظام يحسب قيمة الخدمات المنفذة جزئيًا
      • النظام يخصم القيمة المنفذة جزئيًا من المبلغ المحجوز
      • النظام يعيد المبلغ المتبقي إلى محفظة طالب الخدمة
      الخطوات الاستثنائيةفي حالة فشل النظام في إشعار طالب الخدمة
      • النظام يظهر رسالة خطأ للمخلص الجمركي
      • المخلص الجمركي يتواصل مع دعم العملاء لحل المشكلة
      القواعد التجارية
      • يجب على النظام التحقق من حالة التنفيذ قبل تنفيذ طلب الإلغاء
      • يجب على النظام إشعار طالب الخدمة بإلغاء الطلب
      الافتراضات
      • المخلص الجمركي سيقوم بطلب الإلغاء قبل أو بعد تفعيل الربط وفقًا لحالة التنفيذ
      • إشعار طالب الخدمة يتم إرساله دون تأخير
      المتطلبات الخاصة
      • إمكانية الوصول السريع لدعم العملاء في حالة فشل الإشعار
      الملاحظات والمشاكل
      • يجب توثيق جميع عمليات الإلغاء لأغراض المراجعة
      • توفير إشعار فوري لطالب الخدمة بحالة الطلب بعد محاولة الإلغاء
      المدخلاتطلب إلغاء من المخلص الجمركي |
      المخرجات
      • إشعار بحالة الطلب بعد محاولة الإلغاء
      تفاعلات المستخدم
      • المخلص الجمركي يتفاعل مع واجهة المستخدم لإرسال طلب الإلغاء
      الشروط الخاصة
      • إذا كان هناك تأخير في تحديث حالة التنفيذ، قد تتأخر عملية الإلغاء
      سيناريوهات الاستخدام
      • المخلص الجمركي يطلب إلغاء الطلب لأن العملية غير قابلة للتنفيذ
      • المخلص الجمركي يكتشف خطأ في الطلب ويرغب في إلغائه لتقديم طلب جديد صحيح
      متطلبات الأمان
      • يجب أن يكون المخلص الجمركي مسجلاً في النظام لتقديم طلب الإلغاء
      • يجب أن يتم التحقق من هوية المخلص الجمركي قبل تنفيذ طلب الإلغاء
      التكامل مع الأنظمة الأخرى
      • تفاعل مع نظام المحفظة لإعادة المبلغ المحجوز
      القيود والافتراضات
      • يجب أن يتم تنفيذ عملية الإلغاء بناءً على حالة التنفيذ الجزئي أو الكامل
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من قدرة النظام على إلغاء الطلب قبل أو بعد تفعيل الربط
      • اختبارات أمان للتأكد من أن العملية محمية من الاستخدام غير المصرح به
      تفاصيل ال API
      Method: POST || Endpoint: /api/customs-cancel-request
      Request Headers
      Authorization: Bearer token

      Request Body

      request_id: نص customs_officer_id: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request
      500
      الوصف: Internal Server Error

      تفاصيل الواجهات
      شاشة إلغاء الطلب الجمركي

      • textblock
        • هل أنت متأكد من أنك تريد إلغاء الطلب؟

      • form
        • Button
          • العنوان : إلغاء الطلب
          • الخيارات : submitCustomsCancellationRequest
        • Button
          • العنوان : رجوع
          • الخيارات : navigateBack
      الاشعارات

      العنوان : حالة الطلب
      الرسالة : تم إلغاء طلبك من قبل المخلص الجمركي
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل, SMS  المستقبل : طالب الخدمة

      3.43 - تفعيل الربط

      3.43.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • توفير قناة اتصال آمنة متكاملة بين طالب الخدمة والمخلص لتسهيل الاتصال والتنسيق المباشر بينهما
      الجهات المعنية
      • طالب الخدمة
      • المخلص
      الخطوات الرئيسية
      • توليد رمز QR أو الكود النصي من قبل النظام
      • إرسال الرمز أو الكود إلى طالب الخدمة
      • من ثم، يقوم طالب الخدمة بمشاركة الكود أو الرمز مع المخلص
      • يقوم المخلص بتحديد الرمز أو إدخال الكود لتفعيل الربط مع طالب الخدمة
      الخطوات البديلة
      • واحدة من الخطوات البديلة الشائعة هي استخدام البريد الإلكتروني أو الرسائل النصية لتبادل الرمز او الكود
      قصص المستخدمين
      • طالب الخدمة: بعد قبول الصفقة، يمكنني الحصول على رمز او كود لتفعيل الربط مع المخلص، حيث يمكنني مشاركته مع المخلص لبدء الاتصال المباشر معه
      • المخلص: بعد تلقي الرمز أو الكود من طالب الخدمة، أتمكن من تفعيل الربط معه وبدء التنسيق مباشرة معه
      مؤشرات الأداء
      • عدد الطلبات التي تفعيل الربط لها ونسبتها إجمالي الطلبات التي تم إتمام الصفقة لها

      3.43.2 حالات الاستخدام

      3.43.2.1- توليد رمز QR أو الكود النصي من قبل النظام. يتيح هذا الإجراء توليد رمز QR أو كود نصي يمكن استخدامه لتتبع الطلب أو تأكيد العمليات المرتبطة به

      graph LR A[النظام يتحقق من قبول طالب الخدمة للعرض النهائي] --> B[النظام يولد رمز QR أو الكود النصي] B --> C[النظام يخزن رمز QR أو الكود النصي في قاعدة البيانات] C --> D[النظام يشعر طالب الخدمة بتوليد الرمز أو الكود] B -->|فشل| E[النظام يحاول توليد الكود النصي كبديل] E --> F[النظام يخزن الكود النصي في قاعدة البيانات] F --> D[النظام يشعر طالب الخدمة بتوليد الكود النصي]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • قبول طالب الخدمة للعرض النهائي
      الشروط اللاحقة
      • يتم توليد رمز QR أو الكود النصي
      تسلسل الأحداث
      • النظام يتحقق من قبول طالب الخدمة للعرض النهائي
      • النظام يولد رمز QR أو الكود النصي
      • النظام يخزن الرمز أو الكود في قاعدة البيانات
      الخطوات البديلةإذا فشل توليد رمز QR
      • النظام يحاول توليد الكود النصي كبديل
      • النظام يخزن الكود النصي في قاعدة البيانات
      الخطوات الاستثنائيةفي حالة فشل تخزين رمز QR أو الكود النصي في قاعدة البيانات
      • النظام يظهر رسالة خطأ لطالب الخدمة
      • النظام يسجل الخطأ للتتبع والمراجعة
      • النظام يحاول مرة أخرى تخزين الرمز أو الكود
      القواعد التجارية
      • يجب على النظام التحقق من قبول العرض النهائي قبل توليد رمز QR أو الكود النصي
      • يجب أن يكون رمز QR أو الكود النصي فريدًا لكل عملية
      الافتراضات
      • طالب الخدمة سيقبل العرض النهائي قبل توليد رمز QR أو الكود النصي
      • النظام قادر على توليد وتخزين رموز QR أو الأكواد النصية بشكل موثوق
      المتطلبات الخاصة
      • يجب أن يتم توليد رمز QR أو الكود النصي بسرعة ودون تأخير ملحوظ
      الملاحظات والمشاكل
      • يجب توثيق جميع عمليات توليد الرموز والأكواد لأغراض المراجعة والأمان
      • توفير إشعار لطالب الخدمة بحالة العملية بعد توليد الرمز أو الكود
      المدخلاتموافقة طالب الخدمة على العرض النهائي |
      المخرجات
      • رمز QR أو كود نصي
      • إشعار بحالة العملية
      تفاعلات المستخدم
      • النظام يتفاعل مع واجهة المستخدم لتوليد وعرض رمز QR أو الكود النصي
      الشروط الخاصة
      • إذا كان هناك تأخير في توليد رمز QR، يتم توليد كود نصي كبديل
      سيناريوهات الاستخدام
      • طالب الخدمة يقبل العرض النهائي ويرغب في الحصول على رمز QR لتتبع الطلب
      • طالب الخدمة يرغب في تأكيد العملية باستخدام الكود النصي
      متطلبات الأمان
      • يجب أن يكون رمز QR أو الكود النصي مشفرًا لضمان أمان المعلومات
      • يجب التحقق من هوية طالب الخدمة قبل توليد الرمز أو الكود
      التكامل مع الأنظمة الأخرى
      • تفاعل مع نظام قاعدة البيانات لتخزين رمز QR أو الكود النصي
      القيود والافتراضات
      • يجب أن يتم توليد رمز QR أو الكود النصي بعد قبول العرض النهائي فقط
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من قدرة النظام على توليد رمز QR أو الكود النصي
      • اختبارات أمان للتأكد من أن العملية محمية من الاستخدام غير المصرح به
      تفاصيل ال API
      Method: POST || Endpoint: /api/generate-qr-code
      Request Headers
      Authorization: Bearer token

      Request Body

      request_id: نص user_id: نص

      Response

      الحالةالمحتوى
      200qr_code: نص text_code: نص status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request
      500
      الوصف: Internal Server Error

      تفاصيل الواجهات
      شاشة توليد رمز QR

      • textblock
        • الرجاء الانتظار بينما يتم توليد رمز QR أو الكود النصي

      • textblock
        • LoadingSpinner | "size": "large"

      • textblock
        • تم توليد رمز QR أو الكود النصي بنجاح | ["visibility": "hidden", "id": "successMessage"]

      الاشعارات

      العنوان : توليد رمز QR
      الرسالة : تم توليد رمز QR أو الكود النصي بنجاح لطلبك
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل, SMS  المستقبل : طالب الخدمة

      3.43.2.2- إرسال الرمز أو الكود إلى طالب الخدمة. يتيح هذا الإجراء للنظام إرسال رمز QR أو الكود النصي الذي تم توليده إلى طالب الخدمة لاستخدامه في تتبع الطلب أو تأكيد العمليات المرتبطة به

      graph LR A[النظام يتحقق من توليد رمز QR أو الكود النصي] --> B[النظام يرسل رمز QR أو الكود النصي إلى طالب الخدمة] B --> C[النظام يؤكد استلام الرمز أو الكود من قبل طالب الخدمة] B -->|فشل| D[النظام يحاول إرسال الرمز أو الكود عبر قناة بديلة] D --> E[النظام يخزن تفاصيل المحاولة البديلة في قاعدة البيانات] D --> F[النظام يؤكد استلام الرمز أو الكود من قبل طالب الخدمة] B -->|فشل| G[النظام يظهر رسالة خطأ لطالب الخدمة] G --> H[النظام يسجل الخطأ للتتبع والمراجعة] H --> I[طالب الخدمة يتواصل مع دعم العملاء لحل المشكلة]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • توليد رمز QR أو الكود النصي
      الشروط اللاحقة
      • طالب الخدمة يتلقى الرمز أو الكود
      تسلسل الأحداث
      • النظام يتحقق من توليد رمز QR أو الكود النصي
      • النظام يرسل الرمز أو الكود إلى طالب الخدمة
      • النظام يؤكد استلام الرمز أو الكود من قبل طالب الخدمة
      الخطوات البديلةإذا فشل إرسال رمز QR أو الكود النصي عبر القناة الأساسية
      • النظام يحاول إرسال الرمز أو الكود عبر قناة بديلة
      • النظام يخزن تفاصيل المحاولة البديلة في قاعدة البيانات
      الخطوات الاستثنائيةفي حالة فشل النظام في إرسال الرمز أو الكود عبر جميع القنوات
      • النظام يظهر رسالة خطأ لطالب الخدمة
      • النظام يسجل الخطأ للتتبع والمراجعة
      • طالب الخدمة يتواصل مع دعم العملاء لحل المشكلة
      القواعد التجارية
      • يجب على النظام التحقق من توليد رمز QR أو الكود النصي قبل إرساله
      • يجب أن يتم إرسال الرمز أو الكود عبر قنوات آمنة لضمان حماية المعلومات
      الافتراضات
      • النظام قادر على إرسال رمز QR أو الكود النصي عبر قنوات متعددة
      • طالب الخدمة سيتمكن من استلام الرمز أو الكود عبر القناة المحددة
      المتطلبات الخاصة
      • يجب أن يتم إرسال رمز QR أو الكود النصي بسرعة ودون تأخير ملحوظ
      • يجب توفير إشعار لطالب الخدمة بحالة العملية بعد إرسال الرمز أو الكود
      الملاحظات والمشاكل
      • يجب توثيق جميع عمليات إرسال الرموز والأكواد لأغراض المراجعة والأمان
      • يجب أن يكون هناك آلية للتأكد من استلام طالب الخدمة للرمز أو الكود
      المدخلاترمز QR أو كود نصي تم توليده |
      المخرجات
      • رمز QR أو كود نصي مستلم من قبل طالب الخدمة
      • إشعار بحالة العملية
      تفاعلات المستخدم
      • النظام يتفاعل مع واجهة المستخدم لإرسال رمز QR أو الكود النصي إلى طالب الخدمة
      الشروط الخاصة
      • إذا كان هناك تأخير في إرسال الرمز أو الكود، يتم إشعار طالب الخدمة بالتأخير ومحاولة إرسال الرمز أو الكود عبر قناة بديلة
      سيناريوهات الاستخدام
      • طالب الخدمة يتلقى رمز QR لتتبع الطلب بعد قبوله للعرض النهائي
      • طالب الخدمة يستخدم الكود النصي لتأكيد العملية بعد توليده من قبل النظام
      متطلبات الأمان
      • يجب أن يتم إرسال رمز QR أو الكود النصي عبر قنوات مشفرة لضمان أمان المعلومات
      • يجب التحقق من هوية طالب الخدمة قبل إرسال الرمز أو الكود
      التكامل مع الأنظمة الأخرى
      • تفاعل مع نظام البريد الإلكتروني أو الرسائل النصية لإرسال رمز QR أو الكود النصي
      • تفاعل مع نظام الإشعارات لإرسال رمز QR أو الكود النصي
      القيود والافتراضات
      • يجب أن يتم إرسال رمز QR أو الكود النصي بعد توليده مباشرة
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من قدرة النظام على إرسال رمز QR أو الكود النصي عبر القنوات المختلفة
      • اختبارات أمان للتأكد من أن العملية محمية من الاستخدام غير المصرح به
      تفاصيل ال API
      Method: POST || Endpoint: /api/send-qr-code
      Request Headers
      Authorization: Bearer token

      Request Body

      request_id: نص user_id: نص qr_code: نص text_code: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request
      500
      الوصف: Internal Server Error

      تفاصيل الواجهات
      شاشة إرسال رمز QR

      • textblock
        • جارٍ إرسال رمز QR أو الكود النصي إلى طالب الخدمة

      • textblock
        • LoadingSpinner | "size": "large"

      • textblock
        • تم إرسال رمز QR أو الكود النصي بنجاح

      الاشعارات

      العنوان : استلام رمز QR
      الرسالة : تم إرسال رمز QR أو الكود النصي إلى طلبك
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل, SMS  المستقبل : طالب الخدمة

      3.43.2.3- مشاركة الكود أو الرمز مع المخلص. يتيح هذا الإجراء لطالب الخدمة القدرة على مشاركة رمز QR أو الكود النصي الذي تم تلقيه مع المخلص الجمركي لتتبع الطلب أو تأكيد العمليات المرتبطة به

      graph LR A[طالب الخدمة يتلقى الرمز أو الكود] --> B[طالب الخدمة يشارك الرمز أو الكود مع المخلص] B --> C[النظام يتحقق من صحة البيانات] C --> D[النظام يرسل الرمز أو الكود إلى المخلص] D --> E[المخلص يتلقى الرمز أو الكود] C -->|فشل| F[النظام يظهر رسالة خطأ لطالب الخدمة] F --> G[طالب الخدمة يحاول طريقة مشاركة أخرى] G --> D[النظام يرسل الرمز أو الكود إلى المخلص] D --> H[النظام يؤكد استلام الرمز أو الكود من قبل المخلص] F -->|فشل| I[النظام يظهر رسالة خطأ لطالب الخدمة] I --> J[النظام يسجل الخطأ للتتبع والمراجعة] J --> K[طالب الخدمة يتواصل مع دعم العملاء لحل المشكلة]
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • تلقي طالب الخدمة للرمز أو الكود
      الشروط اللاحقة
      • المخلص يتلقى الرمز أو الكود
      تسلسل الأحداث
      • طالب الخدمة يتلقى الرمز أو الكود
      • طالب الخدمة يشارك الرمز أو الكود مع المخلص
      • المخلص يتلقى الرمز أو الكود
      الخطوات البديلةإذا فشل إرسال الرمز أو الكود عبر الطريقة المحددة
      • النظام يظهر رسالة خطأ لطالب الخدمة
      • طالب الخدمة يحاول طريقة مشاركة أخرى
      • النظام يسجل تفاصيل المحاولة البديلة في قاعدة البيانات
      الخطوات الاستثنائيةفي حالة فشل مشاركة الرمز أو الكود عبر جميع الطرق
      • النظام يظهر رسالة خطأ لطالب الخدمة
      • النظام يسجل الخطأ للتتبع والمراجعة
      • طالب الخدمة يتواصل مع دعم العملاء لحل المشكلة
      القواعد التجارية
      • يجب أن يتم مشاركة الرمز أو الكود عبر قنوات آمنة لضمان حماية المعلومات
      • يجب التحقق من هوية المخلص الجمركي قبل إرسال الرمز أو الكود
      الافتراضات
      • طالب الخدمة سيتمكن من مشاركة الرمز أو الكود بسهولة عبر الطرق المتاحة
      • المخلص الجمركي سيتمكن من استلام الرمز أو الكود عبر الطريقة المحددة
      المتطلبات الخاصة
      • يجب أن يتم مشاركة رمز QR أو الكود النصي بسرعة ودون تأخير ملحوظ
      • يجب توفير إشعار لطالب الخدمة بحالة العملية بعد مشاركة الرمز أو الكود
      الملاحظات والمشاكل
      • يجب توثيق جميع عمليات مشاركة الرموز والأكواد لأغراض المراجعة والأمان
      • يجب أن يكون هناك آلية للتأكد من استلام المخلص الجمركي للرمز أو الكود
      المدخلاترمز QR أو كود نصي تم تلقيه |
      المخرجات
      • رمز QR أو كود نصي مستلم من قبل المخلص
      • إشعار بحالة العملية
      تفاعلات المستخدم
      • طالب الخدمة يتفاعل مع واجهة المستخدم لمشاركة رمز QR أو الكود النصي مع المخلص
      الشروط الخاصة
      • إذا كان هناك تأخير في مشاركة الرمز أو الكود، يتم إشعار طالب الخدمة بالتأخير ومحاولة إرسال الرمز أو الكود عبر قناة بديلة
      سيناريوهات الاستخدام
      • طالب الخدمة يشارك رمز QR مع المخلص لتتبع الطلب بعد تلقيه
      • طالب الخدمة يستخدم الكود النصي لتأكيد العملية بعد تلقيه من قبل النظام
      متطلبات الأمان
      • يجب أن يتم مشاركة رمز QR أو الكود النصي عبر قنوات مشفرة لضمان أمان المعلومات
      • يجب التحقق من هوية المخلص الجمركي قبل مشاركة الرمز أو الكود
      التكامل مع الأنظمة الأخرى
      • تفاعل مع نظام البريد الإلكتروني أو الرسائل النصية لمشاركة رمز QR أو الكود النصي
      • تفاعل مع نظام الإشعارات لمشاركة رمز QR أو الكود النصي
      القيود والافتراضات
      • يجب أن يتم مشاركة رمز QR أو الكود النصي بعد تلقيه مباشرة
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من قدرة النظام على مشاركة رمز QR أو الكود النصي عبر القنوات المختلفة
      • اختبارات أمان للتأكد من أن العملية محمية من الاستخدام غير المصرح به
      تفاصيل ال API
      Method: POST || Endpoint: /api/share-qr-code
      Request Headers
      Authorization: Bearer token

      Request Body

      request_id: نص user_id: نص customs_officer_id: نص qr_code: نص text_code: نص share_method: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request
      500
      الوصف: Internal Server Error

      تفاصيل الواجهات
      شاشة مشاركة رمز QR

      • textblock
        • حدد طريقة المشاركة:

      • form
        • select
          • الخيارات : ["البريد الإلكتروني","الرسائل النصية","وسائل التواصل"]
        • Button
          • العنوان : مشاركة الرمز
          • الخيارات : submitShareRequest
      • textblock
        • تم إرسال رمز QR أو الكود النصي بنجاح

      الاشعارات

      العنوان : استلام رمز QR
      الرسالة : تمت مشاركة رمز QR أو الكود النصي معك
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل, SMS  المستقبل : المخلص الجمركي

      3.43.2.4- تحديد الرمز أو إدخال الكود لتفعيل الربط مع طالب الخدمة. يتيح هذا الإجراء للمخلص الجمركي القدرة على تفعيل الربط مع طالب الخدمة عن طريق إدخال رمز QR أو الكود النصي الذي تم تلقيه من طالب الخدمة

      graph LR A[المخلص يتلقى الرمز أو الكود] --> B[المخلص يدخل الرمز أو الكود في التطبيق] B --> C[النظام يتحقق من صحة الرمز أو الكود] C --> D[النظام يفعل الربط بين المخلص وطالب الخدمة] D --> E[النظام يظهر تأكيد للمخلص بنجاح تفعيل الربط] C -->|فشل| F[النظام يظهر رسالة خطأ للمخلص] F --> G[المخلص يحاول إدخال الرمز أو الكود مرة أخرى] G --> C[النظام يتحقق من صحة الرمز أو الكود] C --> H[النظام يفعل الربط بين المخلص وطالب الخدمة] F -->|فشل| I[النظام يظهر رسالة خطأ للمخلص] I --> J[النظام يسجل الخطأ للتتبع والمراجعة] J --> K[المخلص يتواصل مع دعم العملاء لحل المشكلة]
      العنوانالتفاصيل
      المستخدمالمخلص
      الشروط المسبقة
      • المخلص يتلقى الرمز أو الكود من طالب الخدمة
      الشروط اللاحقة
      • تفعيل الربط مع طالب الخدمة
      تسلسل الأحداث
      • المخلص يتلقى الرمز أو الكود
      • المخلص يدخل الرمز أو الكود في التطبيق
      • النظام يتحقق من صحة الرمز أو الكود
      • النظام يفعل الربط بين المخلص وطالب الخدمة
      الخطوات البديلةإذا فشل التحقق من صحة الرمز أو الكود
      • النظام يظهر رسالة خطأ للمخلص
      • المخلص يحاول إدخال الرمز أو الكود مرة أخرى
      • النظام يسجل تفاصيل المحاولة الفاشلة في قاعدة البيانات
      الخطوات الاستثنائيةفي حالة فشل تفعيل الربط بعد عدة محاولات
      • النظام يظهر رسالة خطأ للمخلص
      • النظام يسجل الخطأ للتتبع والمراجعة
      • المخلص يتواصل مع دعم العملاء لحل المشكلة
      القواعد التجارية
      • يجب على النظام التحقق من صحة الرمز أو الكود قبل تفعيل الربط
      • يجب أن يكون رمز QR أو الكود النصي فريدًا لكل عملية
      الافتراضات
      • المخلص الجمركي سيتمكن من إدخال الرمز أو الكود بسهولة عبر التطبيق
      • النظام قادر على التحقق من صحة الرمز أو الكود بسرعة ودون تأخير
      المتطلبات الخاصة
      • يجب أن يتم التحقق من رمز QR أو الكود النصي بسرعة ودون تأخير ملحوظ
      • يجب توفير إشعار للمخلص الجمركي بحالة العملية بعد تفعيل الربط
      الملاحظات والمشاكل
      • يجب توثيق جميع عمليات إدخال الرموز والأكواد لأغراض المراجعة والأمان
      • يجب أن يكون هناك آلية للتأكد من نجاح تفعيل الربط بين المخلص الجمركي وطالب الخدمة
      المدخلاترمز QR أو كود نصي تم تلقيه |
      المخرجات
      • تفعيل الربط مع طالب الخدمة
      • إشعار بحالة العملية
      تفاعلات المستخدم
      • المخلص يتفاعل مع واجهة المستخدم لإدخال رمز QR أو الكود النصي لتفعيل الربط مع طالب الخدمة
      الشروط الخاصة
      • إذا كان هناك تأخير في التحقق من الرمز أو الكود، يتم إشعار المخلص بالتأخير ومحاولة التحقق مرة أخرى
      سيناريوهات الاستخدام
      • المخلص يدخل رمز QR لتفعيل الربط مع طالب الخدمة بعد تلقيه
      • المخلص يستخدم الكود النصي لتأكيد عملية الربط بعد تلقيه من قبل طالب الخدمة
      متطلبات الأمان
      • يجب أن يتم التحقق من رمز QR أو الكود النصي عبر قنوات مشفرة لضمان أمان المعلومات
      • يجب التحقق من هوية المخلص الجمركي قبل تفعيل الربط
      التكامل مع الأنظمة الأخرى
      • تفاعل مع نظام قاعدة البيانات للتحقق من صحة رمز QR أو الكود النصي
      • تفاعل مع نظام الإشعارات لتأكيد تفعيل الربط
      القيود والافتراضات
      • يجب أن يتم التحقق من رمز QR أو الكود النصي بعد تلقيه مباشرة
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من قدرة النظام على التحقق من رمز QR أو الكود النصي وتفعيل الربط
      • اختبارات أمان للتأكد من أن العملية محمية من الاستخدام غير المصرح به
      تفاصيل ال API
      Method: POST || Endpoint: /api/activate-connection
      Request Headers
      Authorization: Bearer token

      Request Body

      request_id: نص customs_officer_id: نص qr_code: نص text_code: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request
      500
      الوصف: Internal Server Error

      تفاصيل الواجهات
      شاشة تفعيل الاتصال

      • textblock
        • الرجاء إدخال الرمز أو الكود لتفعيل الربط مع طالب الخدمة

      • form
        • text
          • العنوان : الكود
          • الخيارات : "placeholder": "أدخل الرمز أو الكود هنا", "onChange": "handleInputChange"
        • Button
          • العنوان : تفعيل الربط
          • الخيارات : submitCode
      • textblock
        • تم تفعيل الربط بنجاح

      الاشعارات

      العنوان : تفعيل الربط
      الرسالة : تم تفعيل الربط مع طالب الخدمة بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل, SMS  المستقبل : المخلص الجمركي

      3.43.2.5- استخدام البريد الإلكتروني أو الرسائل النصية لتبادل الرمز أو الكود. يتيح هذا الإجراء للنظام توفير طرق بديلة لتبادل رمز QR أو الكود النصي بين طالب الخدمة والمخلص الجمركي في حالة عدم تمكنهم من استخدام الطرق العادية

      graph LR A[النظام يتحقق من عدم تمكن الأطراف من استخدام الطرق العادية] --> B[النظام يوفر خيار استخدام البريد الإلكتروني أو الرسائل النصية] B --> C[النظام يرسل الرمز أو الكود عبر البريد الإلكتروني أو الرسائل النصية] C --> D[النظام يؤكد استلام الرمز أو الكود من قبل الطرف المستهدف] C -->|فشل| E[النظام يظهر رسالة خطأ لطالب الخدمة أو المخلص] E --> F[النظام يسجل تفاصيل المحاولة الفاشلة في قاعدة البيانات] F --> G[النظام يحاول إرسال الرمز أو الكود مرة أخرى] G --> H[النظام يؤكد استلام الرمز أو الكود من قبل الطرف المستهدف] E -->|فشل| I[النظام يظهر رسالة خطأ لطالب الخدمة أو المخلص] I --> J[النظام يسجل الخطأ للتتبع والمراجعة] J --> K[طالب الخدمة أو المخلص يتواصل مع دعم العملاء لحل المشكلة]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • عدم تمكن طالب الخدمة أو المخلص من استخدام الطرق العادية لتبادل الرمز أو الكود
      الشروط اللاحقة
      • النظام يمكن الأطراف من تبادل الرمز أو الكود بطرق بديلة
      تسلسل الأحداث
      • النظام يتحقق من عدم تمكن الأطراف من استخدام الطرق العادية
      • النظام يوفر خيار استخدام البريد الإلكتروني أو الرسائل النصية
      • النظام يرسل الرمز أو الكود عبر البريد الإلكتروني أو الرسائل النصية
      • النظام يؤكد استلام الرمز أو الكود
      الخطوات البديلةإذا فشل إرسال الرمز أو الكود عبر البريد الإلكتروني أو الرسائل النصية
      • النظام يظهر رسالة خطأ لطالب الخدمة أو المخلص
      • النظام يسجل تفاصيل المحاولة الفاشلة في قاعدة البيانات
      • النظام يحاول إرسال الرمز أو الكود مرة أخرى
      الخطوات الاستثنائيةفي حالة فشل إرسال الرمز أو الكود عبر جميع القنوات البديلة
      • النظام يظهر رسالة خطأ لطالب الخدمة أو المخلص
      • النظام يسجل الخطأ للتتبع والمراجعة
      • طالب الخدمة أو المخلص يتواصل مع دعم العملاء لحل المشكلة
      القواعد التجارية
      • يجب أن يتم تبادل الرمز أو الكود عبر قنوات آمنة لضمان حماية المعلومات
      • يجب التحقق من هوية الأطراف قبل إرسال الرمز أو الكود
      الافتراضات
      • النظام قادر على إرسال رمز QR أو الكود النصي عبر البريد الإلكتروني أو الرسائل النصية
      • الأطراف المستهدفة ستتمكن من استلام الرمز أو الكود عبر القنوات البديلة
      المتطلبات الخاصة
      • يجب أن يتم إرسال رمز QR أو الكود النصي بسرعة ودون تأخير ملحوظ
      • يجب توفير إشعار للأطراف المستهدفة بحالة العملية بعد إرسال الرمز أو الكود
      الملاحظات والمشاكل
      • يجب توثيق جميع عمليات إرسال الرموز والأكواد لأغراض المراجعة والأمان
      • يجب أن يكون هناك آلية للتأكد من استلام الأطراف المستهدفة للرمز أو الكود
      المدخلاترمز QR أو كود نصي تم تلقيه |
      المخرجات
      • رمز QR أو كود نصي مستلم من قبل الأطراف المستهدفة
      • إشعار بحالة العملية
      تفاعلات المستخدم
      • النظام يتفاعل مع واجهة المستخدم لتوفير خيار استخدام البريد الإلكتروني أو الرسائل النصية لتبادل رمز QR أو الكود النصي
      الشروط الخاصة
      • إذا كان هناك تأخير في إرسال الرمز أو الكود، يتم إشعار الأطراف المستهدفة بالتأخير ومحاولة إرسال الرمز أو الكود مرة أخرى
      سيناريوهات الاستخدام
      • طالب الخدمة يستخدم البريد الإلكتروني لتبادل رمز QR مع المخلص الجمركي بعد عدم تمكنه من استخدام الطرق العادية
      • المخلص الجمركي يستخدم الرسائل النصية لتأكيد عملية الربط بعد تلقيه الكود النصي من طالب الخدمة
      متطلبات الأمان
      • يجب أن يتم تبادل رمز QR أو الكود النصي عبر قنوات مشفرة لضمان أمان المعلومات
      • يجب التحقق من هوية الأطراف قبل إرسال الرمز أو الكود
      التكامل مع الأنظمة الأخرى
      • تفاعل مع نظام البريد الإلكتروني لإرسال رمز QR أو الكود النصي
      • تفاعل مع نظام الرسائل النصية لإرسال رمز QR أو الكود النصي
      القيود والافتراضات
      • يجب أن يتم تبادل رمز QR أو الكود النصي بعد التحقق من عدم تمكن الأطراف من استخدام الطرق العادية
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من قدرة النظام على إرسال رمز QR أو الكود النصي عبر البريد الإلكتروني أو الرسائل النصية
      • اختبارات أمان للتأكد من أن العملية محمية من الاستخدام غير المصرح به
      تفاصيل ال API
      Method: POST || Endpoint: /api/send-code-alternative
      Request Headers
      Authorization: Bearer token

      Request Body

      request_id: نص user_id: نص recipient_email: نص recipient_phone: نص qr_code: نص text_code: نص

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request
      500
      الوصف: Internal Server Error

      تفاصيل الواجهات
      شاشة إرسال رمز بديل

      • textblock
        • الرجاء اختيار طريقة بديلة لتبادل الرمز أو الكود

      • form
        • select
          • الخيارات : ["البريد الإلكتروني","الرسائل النصية"]
        • text
          • العنوان : البريد الإلكتروني أو رقم الهاتف هنا
          • الخيارات : "placeholder": "أدخل البريد الإلكتروني أو رقم الهاتف هنا", "onChange": "handleInputChange"
        • Button
          • العنوان : إرسال الرمز
          • الخيارات : submitAlternativeMethod
      • textblock
        • تم إرسال رمز QR أو الكود النصي بنجاح

      الاشعارات

      العنوان : استلام رمز QR
      الرسالة : تم إرسال رمز QR أو الكود النصي إليك عبر البريد الإلكتروني أو الرسائل النصية
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل, SMS  المستقبل : طالب الخدمة أو المخلص الجمركي

      3.44 - إتمام عملية التخليص

      3.44.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • توفير آلية لإكمال عملية التخليص وضمان أن مهمة المخلص قد تمت بنجاح. وكذلك، ضمان توفير فرصة لطالب الخدمة لرفض الدفع إذا لم يتم التخليص كما هو متوقع
      الجهات المعنية
      • طالب الخدمة
      • المخلص الجمركي
      الخطوات الرئيسية
      • المخلص الجمركي يرفق الوثائق التي تثبت إتمام عملية التخليص ثم يرسلها إلى طالب الخدمة
      • طالب الخدمة يقرأ التحقق ويقرر إما الموافقة على الانتهاء (وبالتالي يتم سداد المخلص)، أو الرفض (مع توضيح السبب) وإرسال الطلب مرة أخرى إلى المخلص الجمركي ما لم يتم خروج الحمولة من منفذ التخليص
      • يتم إعطاء مهلة زمنية محددة للاستجابة من طالب الخدمة، وبعد ذلك يتم اعتبار الخدمة مكتملة والدفع للمخلص تلقائيا
      • يمكن اعتبار التخليص مكتملًا تلقائياً في حالة خروج الحمولة من منفذ التخليص
      الخطوات البديلة
      • في حالة عدم الرد من طالب الخدمة، يمكن استخدام الملاحظات الآلية لمغادرة المركبة من منفذ التخليص كمؤشر لإكمال العملية
      قصص المستخدمين
      • المخلص الجمركي: عقب إتمام عملية التخليص الجمركي، أستطيع تحميل الوثائق الداعمة وإرسالها إلى طالب الخدمة لتأكيد الانتهاء من العملية
      • طالب الخدمة: عند تلقي الوثائق التي تثبت إتمام العملية، أملك القدرة على الموافقة وسداد مستحقات المخلص، أو أنا أستطيع رفض المصادقة وتوفير سبب لرفضي. إذا لم أستجب في الفترة الزمنية المحددة، يمكن للنظام الموافقة تلقائيًا والتأكد من دفع المخلص
      مؤشرات الأداء
      • عدد الطلبات المكتملة و نسبتها لإجمالي الطلبات
      • عدد الطلبات المعلقة

      3.44.2 حالات الاستخدام

      3.44.2.1- إرفاق مستندات التخليص الجمركي وإرسالها إلى طالب الخدمة

      graph LR; A[إكمال التخليص الجمركي] --> B[تحضير المستندات]; B --> C[تحميل المستندات إلى النظام]; C --> D[إرسال المستندات إلى طالب الخدمة]; D --> E[انتظار الموافقة من طالب الخدمة];
      العنوانالتفاصيل
      المستخدمالمخلص الجمركي
      الشروط المسبقة
      • إكمال عملية التخليص الجمركي
      • تحضير وتحقق من المستندات
      الشروط اللاحقة
      • إرسال المستندات إلى طالب الخدمة
      • انتظار الموافقة من طالب الخدمة
      تسلسل الأحداث
      • إكمال التخليص الجمركي
      • تحضير المستندات
      • تحميل المستندات إلى النظام
      • إرسال المستندات إلى طالب الخدمة
      الخطوات البديلةطالب الخدمة يحتاج إلى تعديلات على المستندات
      • تعديل المستندات حسب طلب طالب الخدمة
      • إعادة إرسال المستندات المعدلة إلى طالب الخدمة
      الخطوات الاستثنائيةفشل في تحميل المستندات
      • إظهار رسالة خطأ للوسيط الجمركي
      • محاولة إعادة تحميل المستندات
      القواعد التجارية
      • يجب التحقق من جميع المستندات قبل إرسالها
      الافتراضات
      • المستندات جاهزة للتحميل والإرسال
      • النظام يمكنه التعامل مع أحجام ملفات مختلفة
      المتطلبات الخاصة
      • متطلبات الأداء: يجب أن يتم تحميل المستندات وإرسالها في غضون ثوانٍ
      • متطلبات الأمان: حماية المستندات باستخدام التشفير
      الملاحظات والمشاكل
      • التأكد من أن جميع الأطراف المعنية على علم بعملية الإرسال
      المدخلاتمستندات التخليص الجمركي |
      المخرجات
      • تأكيد استلام المستندات من قبل طالب الخدمة
      تفاعلات المستخدم
      • تفاعل الوسيط الجمركي مع النظام لتحميل المستندات
      • تفاعل طالب الخدمة مع النظام لمراجعة المستندات
      الشروط الخاصة
      • طلب تعديل على المستندات من قبل طالب الخدمة
      سيناريوهات الاستخدام
      • حالة عادية: تحميل وإرسال المستندات بدون مشاكل
      • حالة طارئة: فشل تحميل المستندات
      متطلبات الأمان
      • التشفير أثناء نقل المستندات
      • مصادقة المستخدمين قبل تحميل أو استلام المستندات
      التكامل مع الأنظمة الأخرى
      • نظام التخليص الجمركي
      • نظام إدارة المستندات
      القيود والافتراضات
      • النظام يجب أن يدعم تحميل ملفات كبيرة
      • المستخدمين لديهم الوصول إلى الإنترنت
      متطلبات الاختبار
      • اختبارات الأداء لتحميل وإرسال المستندات
      • اختبارات الأمان للتحقق من التشفير
      تفاصيل ال API
      Method: POST || Endpoint: /api/clearance-documents
      Request Headers
      Authorization: Bearer token

      Request Body

      document: file

      Response

      الحالةالمحتوى
      200status: success document_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      Method: POST || Endpoint: /api/send-documents
      Request Headers
      Authorization: Bearer token

      Request Body

      document_id: نص requester_id: نص

      Response

      الحالةالمحتوى
      200status: success
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تحميل الوثيقة

      • form
        • file
          • العنوان : تحميل وثيقة التخليص
          • التحقق : {"required":true,"error_message":"الوثيقة مطلوبة"}
      • رسالة زر الإرسال: Upload Document
      • رسالة النجاح: تم تحميل الوثيقة بنجاح
      • إعادة توجيه النجاح: مراجعة الوثيقة

      مراجعة الوثيقة

      • textblock
        • Please review the uploaded clearance document

      • form
        • Button
          • العنوان : إرسال الوثيقة
          • الخيارات : sendDocument
      الاشعارات

      العنوان : مستندات التخليص الجمركي
      الرسالة : تم إرسال مستندات التخليص الجمركي للمراجعة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : طالب الخدمة

      3.44.2.2- الموافقة أو رفض استكمال التخليص الجمركي

      graph LR; A[استلام المستندات] --> B[مراجعة المستندات]; B --> C{هل المستندات مرضية؟}; C -->|نعم| D[الموافقة على المستندات]; C -->|لا| E[رفض المستندات]; E --> F[إرسال سبب الرفض]; D --> G[إعلام الوسيط الجمركي بالنتيجة]; E --> G;
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • استلام مستندات التخليص الجمركي من الوسيط الجمركي
      الشروط اللاحقة
      • دفع رسوم الوسيط الجمركي إذا تمت الموافقة
      • إعادة الطلب إلى الوسيط الجمركي إذا تم الرفض
      تسلسل الأحداث
      • استلام المستندات
      • مراجعة المستندات
      • الموافقة أو الرفض
      • إعلام الوسيط الجمركي بالنتيجة
      الخطوات البديلةطلب تعديلات بسيطة على المستندات من قبل طالب الخدمة
      • تحديد التعديلات المطلوبة على المستندات
      • إرسال المستندات المعدلة إلى الوسيط الجمركي لإجراء التعديلات
      • مراجعة المستندات المعدلة مرة أخرى بعد التعديلات
      الخطوات الاستثنائيةفشل النظام في عرض المستندات
      • إظهار رسالة خطأ لطالب الخدمة
      • محاولة إعادة تحميل المستندات وعرضها
      القواعد التجارية
      • يجب أن تكون المستندات المراجعة مطابقة للمعايير القانونية والتنظيمية
      الافتراضات
      • المستندات المرسلة قابلة للمراجعة والتدقيق
      • طالب الخدمة لديه الصلاحية للموافقة أو الرفض
      المتطلبات الخاصة
      • متطلبات الأداء: يجب إتمام عملية المراجعة والموافقة/الرفض في غضون دقائق
      • متطلبات الأمان: تأمين بيانات المستندات والمراجعات
      الملاحظات والمشاكل
      • التأكد من إعلام جميع الأطراف المعنية بنتيجة المراجعة
      المدخلاتمستندات التخليص الجمركي |
      المخرجات
      • نتيجة المراجعة (موافقة/رفض)
      • سبب الرفض إذا تم الرفض
      تفاعلات المستخدم
      • تفاعل طالب الخدمة مع النظام لمراجعة المستندات
      • إرسال النتيجة إلى الوسيط الجمركي
      الشروط الخاصة
      • طلب تعديلات بسيطة على المستندات
      سيناريوهات الاستخدام
      • حالة عادية: الموافقة على المستندات بدون مشاكل
      • حالة طارئة: رفض المستندات بسبب عدم مطابقتها للمعايير
      متطلبات الأمان
      • تشفير البيانات أثناء المراجعة والنقل
      • مصادقة المستخدمين لضمان صلاحية الوصول
      التكامل مع الأنظمة الأخرى
      • نظام إدارة التخليص الجمركي
      • نظام الدفع
      القيود والافتراضات
      • النظام يجب أن يدعم عرض مستندات كبيرة
      • طالب الخدمة لديه اتصال بالإنترنت
      متطلبات الاختبار
      • اختبارات الأداء لعملية الموافقة/الرفض
      • اختبارات الأمان لضمان حماية البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /api/review-documents
      Request Headers
      Authorization: Bearer token

      Request Body

      document_id: نص requester_id: نص

      Response

      الحالةالمحتوى
      200status: success approval_status: approved|rejected reason: string (if rejected)
      الوصف: Success
      400
      الوصف: Bad Request

      Method: POST || Endpoint: /api/send-feedback
      Request Headers
      Authorization: Bearer token

      Request Body

      document_id: نص feedback: نص

      Response

      الحالةالمحتوى
      200status: success
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      مراجعة الوثيقة

      • textblock
        • Review the customs clearance document below

      • form
        • Button
          • العنوان : الموافقة
          • الخيارات : approveDocument
        • Button
          • العنوان : رفض
          • الخيارات : rejectDocument
        • textarea
          • العنوان : سبب الرفض
          • التحقق : {"required":false,"error_message":"يرجى تقديم سبب للرفض"}
      • رسالة زر الإرسال: Submit Feedback
      • رسالة النجاح: تم تقديم الملاحظات بنجاح
      • إعادة توجيه النجاح: DocumentList
      الاشعارات

      العنوان : نتيجة مراجعة مستندات التخليص الجمركي
      الرسالة : تم مراجعة مستندات التخليص الجمركي الخاصة بك. يرجى التحقق من النتيجة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : الوسيط الجمركي

      3.44.2.3- إتمام التخليص الجمركي تلقائيًا بعد وقت محدد أو عند الخروج من نقطة التفتيش الجمركي

      graph LR; A[تقديم المستندات] --> B[بدء عداد الوقت]; B --> C[مراقبة الاستجابة]; C -->|لا استجابة| D[إتمام التخليص تلقائيًا]; D --> E[تفعيل الدفع]; C -->|استجابة قبل الوقت المحدد| F[إيقاف عداد الوقت]; F --> G[مراجعة استجابة طالب الخدمة];
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • تقديم مستندات التخليص الجمركي
      • انتظار استجابة طالب الخدمة
      الشروط اللاحقة
      • دفع رسوم الوسيط الجمركي تلقائيًا إذا انقضى الوقت المحدد دون استجابة
      • اعتبار التخليص الجمركي مكتملًا
      تسلسل الأحداث
      • تقديم المستندات
      • بدء عداد الوقت
      • مراقبة الاستجابة
      • إتمام التخليص تلقائيًا
      الخطوات البديلةاستجابة طالب الخدمة قبل انتهاء الوقت المحدد
      • إيقاف عداد الوقت
      • مراجعة استجابة طالب الخدمة وتنفيذ الخطوات المطلوبة بناءً على الموافقة أو الرفض
      الخطوات الاستثنائيةفشل النظام في بدء عداد الوقت
      • إظهار رسالة خطأ
      • محاولة إعادة تشغيل عداد الوقت
      القواعد التجارية
      • يجب تحديد مدة زمنية لاستجابة طالب الخدمة قبل اعتبار التخليص مكتملًا تلقائيًا
      الافتراضات
      • الوسيط الجمركي قد أتم جميع الإجراءات اللازمة
      • طالب الخدمة لديه الوقت الكافي للاستجابة قبل انتهاء المدة المحددة
      المتطلبات الخاصة
      • متطلبات الأداء: يجب أن يكون النظام قادرًا على تتبع الوقت بدقة وإتمام الإجراءات تلقائيًا في الوقت المحدد
      • متطلبات الأمان: تأمين البيانات والعمليات المتعلقة بالدفع التلقائي
      الملاحظات والمشاكل
      • التأكد من إعلام الأطراف المعنية بإتمام التخليص تلقائيًا
      المدخلاتمستندات التخليص الجمركي |
      المخرجات
      • إشعار بإتمام التخليص تلقائيًا
      • تأكيد دفع رسوم الوسيط الجمركي
      تفاعلات المستخدم
      • إرسال إشعار إلى طالب الخدمة عند تقديم المستندات
      • إشعار تلقائي بإتمام التخليص إذا لم يستجب طالب الخدمة في الوقت المحدد
      الشروط الخاصة
      • استجابة طالب الخدمة بعد انتهاء الوقت المحدد ولكن قبل إتمام الدفع التلقائي
      سيناريوهات الاستخدام
      • حالة عادية: انقضاء الوقت المحدد دون استجابة طالب الخدمة
      • حالة طارئة: فشل النظام في بدء عداد الوقت
      متطلبات الأمان
      • تشفير البيانات أثناء العملية
      • مصادقة المستخدمين قبل تفعيل الدفع التلقائي
      التكامل مع الأنظمة الأخرى
      • نظام التخليص الجمركي
      • نظام الدفع
      القيود والافتراضات
      • النظام يجب أن يدعم تشغيل عداد الوقت بدقة عالية
      • طالب الخدمة لديه اتصال بالإنترنت
      متطلبات الاختبار
      • اختبارات الأداء لضمان دقة عداد الوقت
      • اختبارات الأمان للتحقق من حماية البيانات
      تفاصيل ال API
      Method: POST || Endpoint: /api/start-timer
      Request Headers
      Authorization: Bearer token

      Request Body

      document_id: نص timer_duration: number

      Response

      الحالةالمحتوى
      200status: timer started end_time: timestamp
      الوصف: Success
      400
      الوصف: Bad Request

      Method: POST || Endpoint: /api/complete-clearance
      Request Headers
      Authorization: Bearer token

      Request Body

      document_id: نص

      Response

      الحالةالمحتوى
      200status: clearance completed payment_status: paid
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تقديم الوثيقة

      • form
        • file
          • العنوان : تحميل وثيقة التخليص
          • التحقق : {"required":true,"error_message":"الوثيقة مطلوبة"}
      • رسالة زر الإرسال: Submit Document
      • رسالة النجاح: تم تقديم الوثيقة بنجاح
      • إعادة توجيه النجاح: شاشة المؤقت

      شاشة المؤقت

      • textblock
        • Waiting for service requester response..

      الاشعارات

      العنوان : إشعار تقديم مستندات التخليص الجمركي
      الرسالة : تم تقديم مستندات التخليص الجمركي الخاصة بك. يرجى المراجعة والاستجابة في الوقت المحدد
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : طالب الخدمة

      العنوان : إشعار إتمام التخليص الجمركي تلقائيًا
      الرسالة : تم إتمام التخليص الجمركي تلقائيًا ودفع الرسوم الخاصة بك
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : الوسيط الجمركي

      3.45 - اغلاق الحالة

      3.45.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • تأكيد إتمام الخدمة وتسوية جميع الرسوم المالية المرتبطة بالخدمة المقدمة
      الجهات المعنية
      • طالب الخدمة
      • مقدم الخدمة (الورشة الفنية / محل قطع الغيار / المخلص الجمركي)
      • التطبيق
      الخطوات الرئيسية
      • تحصيل المبلغ الإجمالي من حساب طالب الخدمة بعد تأكيد كود الموافقة
      • تحويل أجرة الإصلاح الى حساب الورشة الفنية
      • تحويل رسوم الخدمة إلى حساب التطبيق تحت مسمى رسوم خدمات مساندة
      • تحويل ضريبة القيمة المضافة الى حساب الضريبة في التطبيق
      الخطوات البديلة
      قصص المستخدمين
      • طالب الخدمة: بمجرد اتمام الخدمة، يتم خصم المبلغ الإجمالي المتفق عليه من حسابي
      • مقدم الخدمة: أستلم اجرة الخدمة التي قدمتها بمجرد إغلاق الحالة مع خصم الرسوم الخاصة بالتطبيق
      • التطبيق: بمجرد اتمام الخدمة، يتم تحويل رسوم الخدمة وضريبة القيمة المضافة الى الحسابات المعنية في التطبيق
      مؤشرات الأداء
      • عدد الطلبات المغلقة ونسبتها للطلبات التي إتمامها
      • عدد الطلبات المغلقة ونسبتها إجمالي الطلبات التي تم إنشاؤها من الأساس
      • قيمة إجمالي الأجور وتفاصيل رسوم الخدمة والضريبة

      3.45.2 حالات الاستخدام

      3.45.2.1- جمع المبلغ الإجمالي من حساب طالب الخدمة بعد تأكيد رمز الموافقة

      graph LR A[تأكيد إكمال الخدمة] --> B[تقديم رمز الموافقة] B --> C[جمع المبلغ الإجمالي] C --> D[تحويل الرسوم] D --> E[إرسال الإشعارات]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • تأكيد إكمال الخدمة
      • تقديم رمز الموافقة من قبل طالب الخدمة
      الشروط اللاحقة
      • تم تحصيل المبلغ الإجمالي من حساب طالب الخدمة
      • تم تحويل أجرة الإصلاح إلى حساب الورشة الفنية
      • تم تحويل رسوم الخدمة إلى حساب التطبيق
      • تم تحويل ضريبة القيمة المضافة إلى حساب الضريبة
      تسلسل الأحداث
      • تأكيد إكمال الخدمة
      • تقديم رمز الموافقة
      • جمع المبلغ الإجمالي
      • تحويل الرسوم
      الخطوات البديلةإذا لم يتمكن طالب الخدمة من تقديم رمز الموافقة
      • يقوم النظام بإرسال تذكير إلى طالب الخدمة لتقديم رمز الموافقة
      • ينتظر النظام لمدة محددة لتلقي رمز الموافقة من طالب الخدمة
      الخطوات الاستثنائيةإذا حدث خطأ أثناء جمع المبلغ من حساب طالب الخدمة
      • يقوم النظام بإظهار رسالة خطأ
      • يحاول النظام إعادة جمع المبلغ بعد فترة قصيرة
      • إذا استمرت المشكلة، يتم إرسال إشعار إلى الدعم الفني
      القواعد التجارية
      • يجب أن يتم جمع المبلغ الإجمالي فقط بعد تقديم رمز الموافقة الصحيح
      • يجب تحويل الرسوم والمنصات وضريبة القيمة المضافة فورًا بعد جمع المبلغ
      الافتراضات
      • أن يكون رمز الموافقة صالحًا وغير منتهي الصلاحية
      • أن يكون حساب طالب الخدمة يحتوي على رصيد كافٍ لجمع المبلغ المطلوب
      المتطلبات الخاصة
      • يجب أن يكون النظام قادرًا على معالجة جميع المعاملات المالية بسرعة وبدقة
      • يجب أن يكون هناك نظام أمان قوي لحماية البيانات المالية لطالب الخدمة ومقدم الخدمة
      الملاحظات والمشاكل
      • يجب تقديم الدعم الفني لطالب الخدمة في حالة وجود مشاكل في تقديم رمز الموافقة
      • يجب مراجعة نظام تحويل الأموال بانتظام لضمان دقته
      المدخلاترمز الموافقة | تفاصيل حساب طالب الخدمة |
      المخرجات
      • تأكيد جمع المبلغ
      • إيصال الدفع
      تفاعلات المستخدم
      • نموذج تقديم رمز الموافقة
      الشروط الخاصة
      • إذا كان رمز الموافقة غير صالح أو منتهي الصلاحية
      سيناريوهات الاستخدام
      • طالب الخدمة يقدم رمز الموافقة الصحيح ويتم جمع المبلغ بنجاح
      • طالب الخدمة يواجه مشكلة في تقديم رمز الموافقة
      متطلبات الأمان
      • تأمين جميع البيانات المالية المدخلة والمخزنة
      • التأكد من صحة رمز الموافقة المقدم
      التكامل مع الأنظمة الأخرى
      • نظام الحسابات المالية
      • نظام الإشعارات
      القيود والافتراضات
      • قيود على عدد المحاولات المتاحة لتقديم رمز الموافقة
      • افتراض وجود اتصال إنترنت مستقر أثناء العملية
      متطلبات الاختبار
      • اختبار واجهة المستخدم لتقديم رمز الموافقة
      • اختبار جمع المبلغ من حساب طالب الخدمة
      • اختبار نظام تحويل الأموال
      تفاصيل ال API
      Method: POST || Endpoint: /api/collect-amount
      Request Headers
      Authorization: Bearer token

      Request Body

      approval_code: نص amount: number

      Response

      الحالةالمحتوى
      200status: نص transaction_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تقديم رمز الموافقة

      • textblock
        • أدخل رمز الموافقة لتأكيد إكمال الخدمة:

      • form
        • text
          • العنوان : رمز الموافقة
          • التحقق : رمز الموافقة مطلوب
      • رسالة زر الإرسال: تأكيد
      • رسالة النجاح: تم تأكيد إكمال الخدمة وجمع المبلغ بنجاح
      • إعادة توجيه النجاح: تأكيد الدفع
      الاشعارات

      العنوان : تأكيد جمع المبلغ
      الرسالة : تم جمع المبلغ من حسابك بنجاح بعد تأكيد إكمال الخدمة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : طالب الخدمة

      العنوان : تأكيد دفع رسوم الخدمة
      الرسالة : تم تحويل رسوم الخدمة إلى حسابك بعد تأكيد إكمال الخدمة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : مقدم الخدمة

      3.45.2.2- استلام رسوم الخدمة عند إغلاق حالة الخدمة

      graph LR A[تأكيد إكمال الخدمة] --> B[تحويل رسوم الخدمة] B --> C[التحقق من الاستلام] C --> D[إرسال الإشعارات]
      العنوانالتفاصيل
      المستخدممقدم الخدمة (ورشة / متجر قطع غيار / وسيط جمركي)
      الشروط المسبقة
      • تأكيد إكمال الخدمة
      • جمع النظام المبلغ الإجمالي من طالب الخدمة
      الشروط اللاحقة
      • إيداع رسوم الخدمة في حساب مقدم الخدمة
      تسلسل الأحداث
      • تأكيد إكمال الخدمة
      • تحويل رسوم الخدمة
      الخطوات البديلةإذا لم يتم تحويل رسوم الخدمة إلى حساب مقدم الخدمة
      • يقوم النظام بإظهار رسالة خطأ
      • يحاول النظام إعادة تحويل رسوم الخدمة بعد فترة قصيرة
      • إذا استمرت المشكلة، يتم إرسال إشعار إلى الدعم الفني
      الخطوات الاستثنائيةإذا كان هناك خطأ في بيانات الحساب المصرفي لمقدم الخدمة
      • يقوم النظام بإظهار رسالة خطأ
      • يتواصل مقدم الخدمة مع الدعم الفني لتحديث بيانات الحساب
      القواعد التجارية
      • يجب تحويل رسوم الخدمة إلى مقدم الخدمة فورًا بعد تأكيد إكمال الخدمة
      الافتراضات
      • أن تكون بيانات الحساب المصرفي لمقدم الخدمة صحيحة ومحدثة
      • أن يتم تأكيد إكمال الخدمة بشكل صحيح من قبل مقدم الخدمة
      المتطلبات الخاصة
      • يجب أن يكون النظام قادرًا على تحويل الأموال بشكل سريع وفعال
      • يجب أن يكون هناك نظام أمان قوي لحماية البيانات المالية لمقدم الخدمة
      الملاحظات والمشاكل
      • قد يحتاج مقدم الخدمة إلى دعم فني في حالة وجود مشاكل في استلام رسوم الخدمة
      المدخلاتتأكيد إكمال الخدمة | تفاصيل حساب مقدم الخدمة |
      المخرجات
      • تأكيد تحويل رسوم الخدمة
      تفاعلات المستخدم
      • تأكيد إكمال الخدمة من قبل مقدم الخدمة
      الشروط الخاصة
      • إذا كانت بيانات الحساب المصرفي لمقدم الخدمة غير صحيحة
      سيناريوهات الاستخدام
      • مقدم الخدمة يتلقى رسوم الخدمة بنجاح بعد تأكيد إكمال الخدمة
      • مقدم الخدمة يواجه مشكلة في استلام رسوم الخدمة
      متطلبات الأمان
      • تأمين جميع البيانات المالية المدخلة والمخزنة
      • التأكد من صحة بيانات الحساب المصرفي لمقدم الخدمة
      التكامل مع الأنظمة الأخرى
      • نظام الحسابات المالية
      • نظام الإشعارات
      القيود والافتراضات
      • قيود على عدد المحاولات المتاحة لتحويل رسوم الخدمة
      • افتراض وجود اتصال إنترنت مستقر أثناء العملية
      متطلبات الاختبار
      • اختبار واجهة المستخدم لتأكيد إكمال الخدمة
      • اختبار تحويل رسوم الخدمة إلى حساب مقدم الخدمة
      • اختبار نظام الإشعارات
      تفاصيل ال API
      Method: POST || Endpoint: /api/transfer-service-fee
      Request Headers
      Authorization: Bearer token

      Request Body

      service_completion_confirmation: boolean service_provider_account_details: object

      Response

      الحالةالمحتوى
      200status: نص transaction_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تأكيد إتمام الخدمة

      • textblock
        • تأكيد إكمال الخدمة:

      • form
        • Checkbox
          • العنوان : لقد أكملت الخدمة
          • التحقق : يجب تأكيد إكمال الخدمة
      • رسالة زر الإرسال: تأكيد
      • رسالة النجاح: تم تأكيد إكمال الخدمة بنجاح
      • إعادة توجيه النجاح: FeeTransferConfirmation
      الاشعارات

      العنوان : تأكيد تحويل رسوم الخدمة
      الرسالة : تم تحويل رسوم الخدمة إلى حسابك بعد تأكيد إكمال الخدمة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : مقدم الخدمة

      3.45.2.3- ضمان التوزيع الصحيح لرسوم الخدمة ورسوم المنصة وضريبة القيمة المضافة عند إغلاق حالة الخدمة

      graph LR A[تأكيد إكمال الخدمة] --> B[جمع المبلغ الإجمالي] B --> C[تحويل رسوم الخدمة] C --> D[تحويل رسوم المنصة] D --> E[تحويل ضريبة القيمة المضافة] E --> F[إرسال الإشعارات]
      العنوانالتفاصيل
      المستخدمالنظام
      الشروط المسبقة
      • تأكيد إكمال الخدمة
      • جمع المبلغ الإجمالي من حساب طالب الخدمة
      الشروط اللاحقة
      • تحويل رسوم الخدمة إلى مقدم الخدمة
      • تحويل رسوم المنصة إلى حساب المنصة
      • تحويل ضريبة القيمة المضافة إلى حساب الضرائب
      تسلسل الأحداث
      • تأكيد إكمال الخدمة
      • جمع المبلغ الإجمالي
      • تحويل الرسوم وضريبة القيمة المضافة
      الخطوات البديلةإذا لم يتم جمع المبلغ الإجمالي من حساب طالب الخدمة
      • يقوم النظام بإظهار رسالة خطأ
      • يحاول النظام إعادة جمع المبلغ بعد فترة قصيرة
      • إذا استمرت المشكلة، يتم إرسال إشعار إلى الدعم الفني
      الخطوات الاستثنائيةإذا حدث خطأ أثناء تحويل الرسوم أو ضريبة القيمة المضافة
      • يقوم النظام بإظهار رسالة خطأ
      • يحاول النظام إعادة التحويل بعد فترة قصيرة
      • إذا استمرت المشكلة، يتم إرسال إشعار إلى الدعم الفني
      القواعد التجارية
      • يجب تحويل الرسوم والمنصات وضريبة القيمة المضافة فورًا بعد جمع المبلغ الإجمالي
      الافتراضات
      • أن يكون المبلغ الإجمالي قد جمع بنجاح من حساب طالب الخدمة
      • أن تكون تفاصيل الحسابات المصرفية صحيحة ومحدثة
      المتطلبات الخاصة
      • يجب أن يكون النظام قادرًا على تحويل الأموال بشكل سريع وفعال
      • يجب أن يكون هناك نظام أمان قوي لحماية البيانات المالية
      الملاحظات والمشاكل
      • قد يحتاج النظام إلى دعم فني في حالة وجود مشاكل في تحويل الرسوم أو ضريبة القيمة المضافة
      المدخلاتتأكيد إكمال الخدمة | تفاصيل حسابات الرسوم والمنصة والضرائب |
      المخرجات
      • تأكيد تحويل الرسوم وضريبة القيمة المضافة
      تفاعلات المستخدم
      • تأكيد إكمال الخدمة من قبل النظام
      الشروط الخاصة
      • إذا كانت تفاصيل الحسابات المصرفية غير صحيحة
      سيناريوهات الاستخدام
      • النظام يقوم بتحويل الرسوم وضريبة القيمة المضافة بنجاح بعد جمع المبلغ الإجمالي
      • النظام يواجه مشكلة في تحويل الرسوم أو ضريبة القيمة المضافة
      متطلبات الأمان
      • تأمين جميع البيانات المالية المدخلة والمخزنة
      • التأكد من صحة تفاصيل الحسابات المصرفية
      التكامل مع الأنظمة الأخرى
      • نظام الحسابات المالية
      • نظام الإشعارات
      القيود والافتراضات
      • قيود على عدد المحاولات المتاحة لتحويل الرسوم وضريبة القيمة المضافة
      • افتراض وجود اتصال إنترنت مستقر أثناء العملية
      متطلبات الاختبار
      • اختبار عملية تحويل الرسوم وضريبة القيمة المضافة
      • اختبار نظام الإشعارات
      تفاصيل ال API
      Method: POST || Endpoint: /api/distribute-fees
      Request Headers
      Authorization: Bearer token

      Request Body

      total_amount_collected: boolean service_provider_account_details: object platform_account_details: object tax_account_details: object

      Response

      الحالةالمحتوى
      200status: نص transaction_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      تأكيد توزيع الرسوم

      • textblock
        • تأكيد توزيع الرسوم وضريبة القيمة المضافة:

      • form
        • Checkbox
          • العنوان : تم جمع المبلغ الإجمالي من حساب طالب الخدمة
          • التحقق : يجب تأكيد جمع المبلغ الإجمالي
      • رسالة زر الإرسال: تأكيد
      • رسالة النجاح: تم توزيع الرسوم وضريبة القيمة المضافة بنجاح
      • إعادة توجيه النجاح: DistributionConfirmation
      الاشعارات

      العنوان : تأكيد تحويل رسوم الخدمة
      الرسالة : تم تحويل رسوم الخدمة إلى حسابك بعد تأكيد إكمال الخدمة
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : مقدم الخدمة

      العنوان : تأكيد تحويل رسوم المنصة
      الرسالة : تم تحويل رسوم المنصة إلى حسابك بعد جمع المبلغ الإجمالي
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : المنصة

      العنوان : تأكيد تحويل ضريبة القيمة المضافة
      الرسالة : تم تحويل ضريبة القيمة المضافة إلى حسابك بعد جمع المبلغ الإجمالي
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : الهيئة الضريبية

      3.46 - طلب عرض منافسة نقل

      3.46.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • تمكين العملاء من طلب عروض تنافسية لخدمات النقل وتحديد المتطلبات بدقة
      الجهات المعنية
      • طالب الخدمة
      • الشركات الناقلة
      • وسطاء النقل
      الخطوات الرئيسية
      • اختيار طالب الخدمة لنوع المركبات المطلوبة
      • تحديد طالب الخدمة لعدد النقلات المطلوبة
      • تحديد طالب الخدمة لمدة التنفيذ المطلوبة
      • تحديد طالب الخدمة لمواقع التحميل والتنزيل
      • إرفاق طالب الخدمة لنموذج العقد المطلوب التعاقد عليه أو اختيار النموذج من طرف الآخر
      • طالب الخدمة يحدد مدة النشر المطلوبة لعرض النقل
      • التحديد غير الإجباري للمتنافسين من قبل طالب الخدمة
      • تحديد طالب الخدمة الفئات المتنافسة
      الخطوات البديلة
      قصص المستخدمين
      • طالب الخدمة: أستطيع تحديد متطلبات نقلي بدقة، وتحديد الشركات المتنافسة أو تركه عامًا، وأيضًا تحديد الفئات المتنافسة، ثم أتلقى العروض وأقارنها لاختيار الأنسب
      • الشركات الناقلة / وسطاء النقل: أتلقى الطلبات المناسبة لخدماتي وأقدم عروضي على الطلبات التي تناسبني
      مؤشرات الأداء
      • عدد طلبات عروض منافسة
      • معدل الفترة الزمنية لتعبئة طلب عرض منافسة

      3.46.2 حالات الاستخدام

      3.46.2.1- يقوم طالب الخدمة باختيار نوع المركبات المطلوبة من قائمة متاحة على المنصة

      graph LR A[فتح صفحة طلب عرض منافسة النقل] --> B[اختيار نوع المركبات المطلوبة] B --> C[حفظ نوع المركبات المطلوبة] C --> D[إرسال إشعار التأكيد]
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • وجود حساب مسجل لطالب الخدمة على المنصة
      • أن يكون طالب الخدمة مستعدًا لتحديد نوع المركبات المطلوبة
      الشروط اللاحقة
      • حفظ نوع المركبات المطلوبة في نظام المنصة
      • إرسال إشعار لتأكيد نوع المركبات المحددة
      تسلسل الأحداث
      • فتح صفحة طلب عرض منافسة النقل
      • اختيار نوع المركبات من القائمة
      • حفظ الخيار المحدد
      القواعد التجارية
      • يجب أن يكون نوع المركبات متاحاً في النظام
      • يجب أن يكون طالب الخدمة مسجلًا وموثقًا
      الافتراضات
      • أن أنواع المركبات المحددة موجودة ومحدثة في النظام
      • أن طالب الخدمة يعلم بمتطلبات نوع المركبات
      المتطلبات الخاصة
      • يجب أن تكون واجهة المستخدم سريعة الاستجابة
      • يجب أن تكون القائمة المنسدلة لتحديد المركبات سهلة الاستخدام وتعرض كافة الأنواع المتاحة
      الملاحظات والمشاكل
      • قد يحتاج بعض المستخدمين إلى مساعدة في اختيار نوع المركبات المناسبة
      • ضرورة التأكد من تحديث قائمة المركبات بانتظام
      المدخلاتنوع المركبات المطلوبة |
      المخرجات
      • تأكيد حفظ نوع المركبات المطلوبة
      تفاعلات المستخدم
      • اختيار نوع المركبات من القائمة المنسدلة
      • تأكيد حفظ الخيارات
      سيناريوهات الاستخدام
      • طالب الخدمة يريد تقديم طلب نقل يتضمن أنواع مركبات مختلفة
      متطلبات الأمان
      • تأكيد هوية طالب الخدمة قبل السماح له بالاختيار
      • تشفير بيانات نوع المركبات المطلوبة عند الحفظ
      التكامل مع الأنظمة الأخرى
      • تحديث قائمة المركبات من قاعدة البيانات المركزية
      القيود والافتراضات
      • يفترض وجود اتصال مستقر بالإنترنت عند تنفيذ هذه الخطوة
      • قيود زمنية لحفظ الخيارات المحددة
      متطلبات الاختبار
      • اختبار الأداء للتحقق من سرعة استجابة القائمة المنسدلة
      • اختبار الأمان لضمان حماية بيانات المستخدم
      تفاصيل ال API
      Method: POST || Endpoint: /api/vehicle-selection
      Request Headers
      Authorization: نص

      Request Body

      vehicle_type: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة اختيار المركبة

      • textblock
        • اختر نوع المركبات المطلوبة:

      • form
        • select
          • العنوان : نوع المركبات
          • الخيارات : ["نوع المركبة 1","نوع المركبة 2","نوع المركبة 3"]
        • Button
          • العنوان : حفظ
          • الخيارات : saveVehicleSelection
      الاشعارات

      العنوان : تأكيد نوع المركبات
      الرسالة : تم حفظ نوع المركبات المطلوبة بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : طالب الخدمة

      3.46.2.2- تحديد طالب الخدمة لعدد النقلات المطلوبة

      graph LR; A[طالب الخدمة يدخل إلى صفحة تحديد عدد النقلات] --> B[النظام يعرض خيارات عدد النقلات الممكنة]; B --> C[طالب الخدمة يحدد عدد النقلات المطلوبة]; C --> D[النظام يحفظ الاختيار]; D --> E[إرسال إشعار لتأكيد عدد النقلات المحددة];
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • أن يكون طالب الخدمة قد قام باختيار نوع المركبات المطلوبة
      • وجود حساب مسجل لطالب الخدمة على المنصة
      الشروط اللاحقة
      • حفظ عدد النقلات المطلوبة في نظام المنصة
      • إرسال إشعار لتأكيد عدد النقلات المحددة
      تسلسل الأحداث
      • طالب الخدمة يدخل إلى صفحة تحديد عدد النقلات
      • النظام يعرض خيارات عدد النقلات الممكنة
      • طالب الخدمة يحدد عدد النقلات المطلوبة
      • النظام يحفظ الاختيار
      القواعد التجارية
      • يجب أن يكون عدد النقلات المطلوبة ضمن الحد الأدنى والأقصى المحدد مسبقاً
      الافتراضات
      • طالب الخدمة لديه صلاحية الوصول إلى صفحة تحديد عدد النقلات
      المتطلبات الخاصة
      • يجب أن يكون النظام قادراً على التعامل مع عدد كبير من الطلبات بشكل متزامن
      المدخلاتعدد النقلات المطلوبة |
      المخرجات
      • تأكيد حفظ عدد النقلات المطلوبة
      تفاعلات المستخدم
      • طالب الخدمة يحدد عدد النقلات المطلوبة عبر واجهة المستخدم
      سيناريوهات الاستخدام
      • طالب الخدمة يحتاج لنقلات إضافية لزيادة الطلبات
      متطلبات الأمان
      • تأكد من صلاحية طالب الخدمة للوصول إلى هذه الخاصية
      التكامل مع الأنظمة الأخرى
      • يجب أن يتكامل النظام مع نظام إدارة الطلبات لضمان تحديث المعلومات بشكل فوري
      القيود والافتراضات
      • يفترض أن النظام قادر على معالجة الطلبات في الوقت الحقيقي
      متطلبات الاختبار
      • يجب اختبار العملية للتأكد من صحة عدد النقلات المدخل وحفظه بشكل صحيح
      • يجب اختبار الإشعارات للتأكد من وصولها لطالب الخدمة
      تفاصيل ال API
      Method: POST || Endpoint: /api/set-transport-count
      Request Headers
      Authorization: نص

      Request Body

      transport_count: integer

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تحديد عدد النقل

      • form
        • NumberInput
          • العنوان : عدد النقلات المطلوبة
          • التحقق : required: 1 min: 1 max: 100 error_message: يرجى إدخال عدد نقلات صحيح بين 1 و 100
      • رسالة زر الإرسال: حفظ
      • رسالة النجاح: تم حفظ عدد النقلات بنجاح
      • إعادة توجيه النجاح: ConfirmationScreen
      الاشعارات

      العنوان : تأكيد عدد النقلات
      الرسالة : تم تحديد عدد النقلات المطلوبة بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : طالب الخدمة

      3.46.2.3- تحديد طالب الخدمة لمدة التنفيذ المطلوبة بشكل دقيق ضمن نظام المنصة

      graph LR; A[يدخل طالب الخدمة إلى صفحة تحديد مدة التنفيذ] --> B[يحدد مدة التنفيذ المطلوبة]; B --> C[يحفظ النظام مدة التنفيذ المطلوبة];
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • أن يكون طالب الخدمة قد قام باختيار نوع المركبات وعدد النقلات المطلوبة
      • وجود حساب مسجل لطالب الخدمة على المنصة
      الشروط اللاحقة
      • حفظ مدة التنفيذ المطلوبة في نظام المنصة
      • إرسال إشعار لتأكيد مدة التنفيذ المحددة
      تسلسل الأحداث
      • طالب الخدمة يدخل إلى صفحة تحديد مدة التنفيذ
      • يحدد مدة التنفيذ المطلوبة
      • النظام يحفظ مدة التنفيذ
      الخطوات البديلةإذا كان طالب الخدمة يرغب في تعديل مدة التنفيذ بعد الحفظ
      • يدخل طالب الخدمة إلى صفحة مراجعة الطلبات
      • يختار تعديل مدة التنفيذ
      • يقوم بتعديل مدة التنفيذ المطلوبة
      • يحفظ النظام التعديلات الجديدة
      الخطوات الاستثنائيةإذا كانت مدة التنفيذ غير صالحة أو خارج النطاق المقبول
      • يعرض النظام رسالة خطأ تشير إلى أن مدة التنفيذ غير صالحة
      • يطالب النظام طالب الخدمة بإدخال مدة تنفيذ صالحة
      القواعد التجارية
      • يجب أن تكون مدة التنفيذ ضمن النطاق المحدد من قبل إدارة المنصة
      • يجب التحقق من صحة مدة التنفيذ قبل الحفظ
      الافتراضات
      • طالب الخدمة لديه فهم كامل للنطاق المقبول لمدة التنفيذ
      • النظام يحتوي على التحقق من صحة المدة المدخلة
      المتطلبات الخاصة
      • واجهة مستخدم سهلة الاستخدام لتحديد مدة التنفيذ
      • تحقق سريع من صحة المدة المدخلة
      الملاحظات والمشاكل
      • قد يواجه بعض المستخدمين صعوبة في تحديد مدة التنفيذ بدقة، لذا يجب تقديم إرشادات واضحة
      • يجب مراجعة وتحديث النطاق المقبول لمدة التنفيذ دوريًا
      المدخلاتمدة التنفيذ المطلوبة من قبل طالب الخدمة |
      المخرجات
      • مدة التنفيذ المحفوظة في النظام
      • إشعار تأكيد مدة التنفيذ
      تفاعلات المستخدم
      • واجهة إدخال مدة التنفيذ
      • رسالة تأكيد الحفظ
      الشروط الخاصة
      • طالب الخدمة يرغب في تعديل مدة التنفيذ بعد الحفظ
      • مدة التنفيذ المدخلة غير صالحة
      سيناريوهات الاستخدام
      • طالب الخدمة يقوم بتحديد مدة التنفيذ بشكل صحيح ويحفظها
      • طالب الخدمة يواجه مشكلة في إدخال مدة التنفيذ بسبب خطأ في المدخلات
      متطلبات الأمان
      • تحقق من هوية طالب الخدمة قبل السماح بتحديد مدة التنفيذ
      • تأمين البيانات المتعلقة بمدة التنفيذ المحفوظة في النظام
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام الإشعارات لإرسال تأكيد مدة التنفيذ
      • التكامل مع نظام مراجعة الطلبات لتعديل مدة التنفيذ
      القيود والافتراضات
      • لا يمكن تجاوز النطاق المحدد لمدة التنفيذ
      • النظام يعتمد على المدخلات الصحيحة من قبل طالب الخدمة
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من تحديد وحفظ مدة التنفيذ
      • اختبارات أمان لضمان حماية البيانات المدخلة
      تفاصيل ال API
      Method: POST || Endpoint: /set-execution-time
      Request Headers
      Authorization: نص

      Request Body

      execution_time: integer

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تحديد وقت التنفيذ

      • textblock
        • حدد مدة التنفيذ

      • form
        • number
          • العنوان : مدة التنفيذ بالأيام
          • التحقق : required: 1 min: 1 max: 365 error_message: يرجى إدخال مدة صالحة بين 1 و365 يومًا
      • رسالة زر الإرسال: حفظ
      • رسالة النجاح: تم حفظ مدة التنفيذ بنجاح
      • إعادة توجيه النجاح: ConfirmationScreen
      الاشعارات

      العنوان : تأكيد مدة التنفيذ
      الرسالة : تم تحديد مدة التنفيذ الخاصة بك بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : طالب الخدمة

      3.46.2.4- تمكين طالب الخدمة من تحديد مواقع التحميل والتنزيل بشكل دقيق ضمن نظام المنصة

      graph LR; A[يدخل طالب الخدمة إلى صفحة تحديد مواقع التحميل والتنزيل] --> B[يحدد مواقع التحميل والتنزيل المطلوبة]; B --> C[يحفظ النظام مواقع التحميل والتنزيل];
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • أن يكون طالب الخدمة قد قام باختيار نوع المركبات، عدد النقلات، ومدة التنفيذ المطلوبة
      • وجود حساب مسجل لطالب الخدمة على المنصة
      الشروط اللاحقة
      • حفظ مواقع التحميل والتنزيل في نظام المنصة
      • إرسال إشعار لتأكيد مواقع التحميل والتنزيل
      تسلسل الأحداث
      • طالب الخدمة يدخل إلى صفحة تحديد مواقع التحميل والتنزيل
      • يحدد مواقع التحميل والتنزيل المطلوبة
      • النظام يحفظ مواقع التحميل والتنزيل
      الخطوات البديلةإذا كان طالب الخدمة يرغب في تعديل مواقع التحميل والتنزيل بعد الحفظ
      • يدخل طالب الخدمة إلى صفحة مراجعة الطلبات
      • يختار تعديل مواقع التحميل والتنزيل
      • يقوم بتعديل مواقع التحميل والتنزيل المطلوبة
      • يحفظ النظام التعديلات الجديدة
      الخطوات الاستثنائيةإذا كانت مواقع التحميل والتنزيل غير صالحة أو غير مقبولة
      • يعرض النظام رسالة خطأ تشير إلى أن مواقع التحميل والتنزيل غير صالحة
      • يطالب النظام طالب الخدمة بإدخال مواقع تحميل وتنزيل صالحة
      القواعد التجارية
      • يجب أن تكون مواقع التحميل والتنزيل ضمن النطاق المحدد من قبل إدارة المنصة
      • يجب التحقق من صحة مواقع التحميل والتنزيل قبل الحفظ
      الافتراضات
      • طالب الخدمة لديه فهم كامل للنطاق المقبول لمواقع التحميل والتنزيل
      • النظام يحتوي على التحقق من صحة المواقع المدخلة
      المتطلبات الخاصة
      • واجهة مستخدم سهلة الاستخدام لتحديد مواقع التحميل والتنزيل
      • تحقق سريع من صحة المواقع المدخلة
      الملاحظات والمشاكل
      • قد يواجه بعض المستخدمين صعوبة في تحديد مواقع التحميل والتنزيل بدقة، لذا يجب تقديم إرشادات واضحة
      • يجب مراجعة وتحديث النطاق المقبول لمواقع التحميل والتنزيل دوريًا
      المدخلاتمواقع التحميل والتنزيل المطلوبة من قبل طالب الخدمة |
      المخرجات
      • مواقع التحميل والتنزيل المحفوظة في النظام
      • إشعار تأكيد مواقع التحميل والتنزيل
      تفاعلات المستخدم
      • واجهة إدخال مواقع التحميل والتنزيل
      • رسالة تأكيد الحفظ
      الشروط الخاصة
      • طالب الخدمة يرغب في تعديل مواقع التحميل والتنزيل بعد الحفظ
      • مواقع التحميل والتنزيل المدخلة غير صالحة
      سيناريوهات الاستخدام
      • طالب الخدمة يقوم بتحديد مواقع التحميل والتنزيل بشكل صحيح ويحفظها
      • طالب الخدمة يواجه مشكلة في إدخال مواقع التحميل والتنزيل بسبب خطأ في المدخلات
      متطلبات الأمان
      • تحقق من هوية طالب الخدمة قبل السماح بتحديد مواقع التحميل والتنزيل
      • تأمين البيانات المتعلقة بمواقع التحميل والتنزيل المحفوظة في النظام
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام الإشعارات لإرسال تأكيد مواقع التحميل والتنزيل
      • التكامل مع نظام مراجعة الطلبات لتعديل مواقع التحميل والتنزيل
      القيود والافتراضات
      • لا يمكن تجاوز النطاق المحدد لمواقع التحميل والتنزيل
      • النظام يعتمد على المدخلات الصحيحة من قبل طالب الخدمة
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من تحديد وحفظ مواقع التحميل والتنزيل
      • اختبارات أمان لضمان حماية البيانات المدخلة
      تفاصيل ال API
      Method: POST || Endpoint: /set-load-unload-locations
      Request Headers
      Authorization: نص

      Request Body

      load_location: نص unload_location: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      شاشة تحديد مواقع التحميل والتفريغ

      • textblock
        • حدد مواقع التحميل والتنزيل

      • form
        • text
          • العنوان : موقع التحميل
          • التحقق : required: 1 error_message: يرجى إدخال موقع التحميل
        • text
          • العنوان : موقع التنزيل
          • التحقق : required: 1 error_message: يرجى إدخال موقع التنزيل
      • رسالة زر الإرسال: حفظ
      • رسالة النجاح: تم حفظ مواقع التحميل والتنزيل بنجاح
      • إعادة توجيه النجاح: ConfirmationScreen
      الاشعارات

      العنوان : تأكيد مواقع التحميل والتنزيل
      الرسالة : تم تحديد مواقع التحميل والتنزيل الخاصة بك بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : طالب الخدمة

      3.46.2.5- إرفاق طالب الخدمة لنموذج العقد المطلوب التعاقد عليه أو اختيار النموذج من طرف الآخر

      graph LR A[طالب الخدمة] --> B[صفحة إرفاق نموذج العقد] B --> C[إرفاق أو اختيار نموذج] C --> D[حفظ نموذج العقد في النظام] D --> E[إرسال إشعار التأكيد]
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • أن يكون طالب الخدمة قد قام بتحديد كافة التفاصيل السابقة
      • وجود حساب مسجل لطالب الخدمة على المنصة
      الشروط اللاحقة
      • حفظ نموذج العقد في نظام المنصة
      • إرسال إشعار لتأكيد نموذج العقد
      تسلسل الأحداث
      • طالب الخدمة يدخل إلى صفحة إرفاق نموذج العقد
      • يرفق نموذج العقد أو يختار نموذجًا موجودًا
      • النظام يتحقق من صحة الملف المرفق
      • النظام يحفظ نموذج العقد
      القواعد التجارية
      • يجب أن يكون نموذج العقد مطابقًا للمعايير القانونية المحددة
      • يجب أن تكون كافة البيانات المرفقة في النموذج صحيحة ومكتملة
      الافتراضات
      • افتراض أن طالب الخدمة يمتلك جميع المعلومات اللازمة لإرفاق نموذج العقد
      الملاحظات والمشاكل
      • يجب التأكد من صحة وسلامة ملف العقد المرفق قبل الحفظ
      المدخلاتملف نموذج العقد |
      المخرجات
      • تأكيد نجاح عملية إرفاق وحفظ نموذج العقد
      تفاعلات المستخدم
      • إشعار للمستخدم بتأكيد إرفاق العقد
      سيناريوهات الاستخدام
      • طالب الخدمة يفتح صفحة إرفاق نموذج العقد
      • في حالة ملف جديد : يرفع الملف المطلوب
      • في حالة ملف جديد النظام : يتحقق من صحة الملف ويحفظه
      • يختار المستخدم نموذج عقد موجود من القائمة
      • النظام يتحقق من الاختيار ويحفظه
      متطلبات الأمان
      • يجب تشفير ملف العقد المرفق لحمايته من الوصول غير المصرح به
      • يجب تسجيل كافة العمليات المتعلقة بإرفاق وحفظ العقد
      التكامل مع الأنظمة الأخرى
      • نظام إدارة الملفات لتخزين نموذج العقد
      القيود والافتراضات
      • النظام يقبل فقط ملفات بصيغة PDF أو DOCX
      متطلبات الاختبار
      • اختبارات وظيفية للتأكد من إمكانية إرفاق وحفظ نموذج العقد بشكل صحيح
      • اختبارات أمان للتأكد من حماية ملفات العقد المرفقة
      تفاصيل ال API
      Method: POST || Endpoint: /api/contracts/upload
      Request Headers
      Authorization: Bearer token

      Request Body

      file: binary

      Response

      الحالةالمحتوى
      200status: success contractId: نص
      الوصف: Success
      400
      الوصف: Bad Request
      500
      الوصف: Internal Server Error

      تفاصيل الواجهات
      شاشة تحميل العقد

      • textblock
        • إرفاق نموذج العقد

      • textblock
        • يرجى إرفاق نموذج العقد المطلوب أو اختيار نموذج من القائمة

      • form
        • FileInput
          • العنوان : إرفاق نموذج العقد
      • رسالة زر الإرسال: إرفاق
      • رسالة النجاح: تم إرفاق نموذج العقد بنجاح
      • إعادة توجيه النجاح: ContractDetailsScreen
      الاشعارات

      العنوان : تم إرفاق نموذج العقد
      الرسالة : تم إرفاق نموذج العقد بنجاح، يرجى مراجعة التفاصيل
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : طالب الخدمة

      3.46.2.6- طالب الخدمة يحدد مدة النشر المطلوبة لعرض النقل

      graph LR A[طالب الخدمة] --> B[صفحة تحديد مدة النشر] B --> C[تحديد مدة النشر] C --> D[حفظ مدة النشر في النظام] D --> E[إرسال إشعار التأكيد]
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • أن يكون طالب الخدمة قد قام بتحديد كافة التفاصيل السابقة
      • وجود حساب مسجل لطالب الخدمة على المنصة
      الشروط اللاحقة
      • حفظ مدة النشر المطلوبة في نظام المنصة
      • إرسال إشعار لتأكيد مدة النشر
      تسلسل الأحداث
      • طالب الخدمة يدخل إلى صفحة تحديد مدة النشر
      • يحدد مدة النشر المطلوبة
      • النظام يتحقق من صحة البيانات المدخلة
      • النظام يحفظ مدة النشر المطلوبة
      القواعد التجارية
      • يجب أن تكون مدة النشر ضمن الحدود المسموح بها من قبل النظام
      • يجب أن تكون كافة البيانات المرفقة صحيحة ومكتملة
      الافتراضات
      • افتراض أن طالب الخدمة يمتلك جميع المعلومات اللازمة لتحديد مدة النشر
      الملاحظات والمشاكل
      • يجب التأكد من صحة وسلامة البيانات المدخلة قبل الحفظ
      المدخلاتمدة النشر المطلوبة |
      المخرجات
      • تأكيد نجاح عملية حفظ مدة النشر
      تفاعلات المستخدم
      • إشعار للمستخدم بتأكيد حفظ مدة النشر
      سيناريوهات الاستخدام
      • طالب الخدمة يفتح صفحة تحديد مدة النشر
      • يحدد مدة النشر المطلوبة
      • النظام يتحقق من صحة البيانات المدخلة ويحفظها
      متطلبات الأمان
      • يجب تسجيل كافة العمليات المتعلقة بتحديد وحفظ مدة النشر
      • يجب التحقق من صحة البيانات المدخلة قبل الحفظ
      التكامل مع الأنظمة الأخرى
      • نظام إدارة العروض لتخزين مدة النشر
      القيود والافتراضات
      • النظام يقبل مدة النشر بصيغة أيام فقط
      متطلبات الاختبار
      • اختبارات وظيفية للتأكد من إمكانية تحديد وحفظ مدة النشر بشكل صحيح
      • اختبارات أمان للتأكد من صحة البيانات المدخلة
      تفاصيل ال API
      Method: POST || Endpoint: /api/publication/duration
      Request Headers
      Authorization: Bearer token

      Request Body

      duration: integer

      Response

      الحالةالمحتوى
      200status: success durationId: نص
      الوصف: Success
      400
      الوصف: Bad Request
      500
      الوصف: Internal Server Error

      تفاصيل الواجهات
      شاشة مدة النشر

      • textblock
        • تحديد مدة النشر

      • textblock
        • يرجى تحديد مدة النشر المطلوبة

      • form
        • NumberInput
          • العنوان : مدة النشر (بالأيام)
      • رسالة زر الإرسال: حفظ
      • رسالة النجاح: تم حفظ مدة النشر بنجاح
      • إعادة توجيه النجاح: PublicationDetailsScreen
      الاشعارات

      العنوان : تم حفظ مدة النشر
      الرسالة : تم حفظ مدة النشر بنجاح، يرجى مراجعة التفاصيل
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : طالب الخدمة

      3.46.2.7- التحديد غير الإجباري للمتنافسين من قبل طالب الخدمة

      graph LR A[طالب الخدمة] --> B[صفحة تحديد المتنافسين] B --> C[تحديد المتنافسين] C --> D[حفظ المتنافسين في النظام] D --> E[إرسال إشعار التأكيد]
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • أن يكون طالب الخدمة قد قام بتحديد كافة التفاصيل السابقة
      • وجود حساب مسجل لطالب الخدمة على المنصة
      الشروط اللاحقة
      • حفظ المتنافسين المحددين في نظام المنصة (إن وجد)
      • إرسال إشعار لتأكيد المتنافسين المحددين
      تسلسل الأحداث
      • طالب الخدمة يدخل إلى صفحة تحديد المتنافسين
      • يحدد المتنافسين المطلوبين (إن وجد)
      • النظام يتحقق من صحة البيانات المدخلة
      • النظام يحفظ المتنافسين المحددين
      القواعد التجارية
      • يجب أن يكون المتنافسون المحددون ضمن القائمة المعتمدة على المنصة
      • يجب أن تكون كافة البيانات المرفقة صحيحة ومكتملة
      الافتراضات
      • افتراض أن طالب الخدمة يمتلك جميع المعلومات اللازمة لتحديد المتنافسين
      الملاحظات والمشاكل
      • يجب التأكد من صحة وسلامة البيانات المدخلة قبل الحفظ
      المدخلاتقائمة المتنافسين المحددين |
      المخرجات
      • تأكيد نجاح عملية حفظ المتنافسين المحددين
      تفاعلات المستخدم
      • إشعار للمستخدم بتأكيد حفظ المتنافسين المحددين
      سيناريوهات الاستخدام
      • طالب الخدمة يفتح صفحة تحديد المتنافسين
      • يحدد المتنافسين المطلوبين (إن وجد)
      • النظام يتحقق من صحة البيانات المدخلة ويحفظها
      متطلبات الأمان
      • يجب تسجيل كافة العمليات المتعلقة بتحديد وحفظ المتنافسين
      • يجب التحقق من صحة البيانات المدخلة قبل الحفظ
      التكامل مع الأنظمة الأخرى
      • نظام إدارة المتنافسين لتخزين المتنافسين المحددين
      القيود والافتراضات
      • النظام يقبل فقط المتنافسين المعتمدين على المنصة
      متطلبات الاختبار
      • اختبارات وظيفية للتأكد من إمكانية تحديد وحفظ المتنافسين بشكل صحيح
      • اختبارات أمان للتأكد من صحة البيانات المدخلة
      تفاصيل ال API
      Method: POST || Endpoint: /api/competitors/assign
      Request Headers
      Authorization: Bearer token

      Request Body

      competitors: array of strings

      Response

      الحالةالمحتوى
      200status: success competitorIds: array of strings
      الوصف: Success
      400
      الوصف: Bad Request
      500
      الوصف: Internal Server Error

      تفاصيل الواجهات
      شاشة تعيين المنافس

      • textblock
        • تحديد المتنافسين

      • textblock
        • يرجى تحديد المتنافسين المطلوبين (إن وجد)

      • form
        • MultiSelect
          • العنوان : المتنافسين
          • الخيارات : [{"value":"competitor1","label":"المنافس 1"},{"value":"competitor2","label":"المنافس 2"}]
      • رسالة زر الإرسال: حفظ
      • رسالة النجاح: تم حفظ المتنافسين بنجاح
      • إعادة توجيه النجاح: CompetitorDetailsScreen
      الاشعارات

      العنوان : تم حفظ المتنافسين
      الرسالة : تم حفظ المتنافسين المحددين بنجاح، يرجى مراجعة التفاصيل
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : طالب الخدمة

      3.46.2.8- تحديد طالب الخدمة الفئات المتنافسة

      graph LR A[تسجيل الدخول] --> B[تحديد الخدمة] B --> C[تحديد الفئات المتنافسة] C --> D[حفظ الفئات المتنافسة] D --> E[إرسال الإشعارات]
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • أن يكون طالب الخدمة قد قام بتحديد كافة التفاصيل السابقة
      • وجود حساب مسجل لطالب الخدمة على المنصة
      الشروط اللاحقة
      • حفظ الفئات المتنافسة في نظام المنصة
      • إرسال إشعار لتأكيد الفئات المتنافسة
      تسلسل الأحداث
      • تسجيل الدخول
      • تحديد الخدمة
      • تحديد الفئات المتنافسة
      • حفظ الفئات المتنافسة
      الخطوات البديلةإذا لم يتمكن طالب الخدمة من تحديد الفئات المتنافسة
      • يقوم النظام بإظهار رسالة توضيحية لمساعدة طالب الخدمة في تحديد الفئات المتنافسة
      • يقوم طالب الخدمة بإعادة المحاولة لتحديد الفئات المتنافسة
      الخطوات الاستثنائيةإذا كان هناك خطأ في النظام أثناء حفظ الفئات المتنافسة
      • يقوم النظام بإظهار رسالة خطأ لطالب الخدمة
      • يحاول النظام إعادة حفظ الفئات المتنافسة تلقائيًا
      القواعد التجارية
      • يجب أن يكون لكل خدمة على الأقل فئة متنافسة واحدة
      الافتراضات
      • وجود اتصال إنترنت مستقر
      • أن تكون جميع الفئات المتنافسة متاحة في النظام
      المتطلبات الخاصة
      • يجب أن يكون النظام قادرًا على معالجة وتخزين البيانات بشكل سريع وفعال
      • يجب أن يكون النظام قادرًا على إرسال الإشعارات الفورية لطالب الخدمة
      الملاحظات والمشاكل
      • قد يحتاج طالب الخدمة إلى دعم فني في حالة وجود مشاكل في تحديد الفئات المتنافسة
      المدخلاتتفاصيل الفئات المتنافسة |
      المخرجات
      • تأكيد الفئات المتنافسة المحفوظة
      تفاعلات المستخدم
      • نموذج تحديد الفئات المتنافسة
      الشروط الخاصة
      • إذا كانت الفئات المتنافسة غير متوفرة
      سيناريوهات الاستخدام
      • طالب الخدمة يقوم بتحديد الفئات المتنافسة بنجاح
      • طالب الخدمة يواجه مشكلة في تحديد الفئات المتنافسة
      متطلبات الأمان
      • يجب تأمين البيانات المدخلة بواسطة طالب الخدمة
      • يجب تأكيد هوية طالب الخدمة قبل السماح له بتحديد الفئات المتنافسة
      التكامل مع الأنظمة الأخرى
      • قاعدة بيانات الفئات المتنافسة
      • نظام الإشعارات
      القيود والافتراضات
      • قيود على عدد الفئات المتنافسة التي يمكن تحديدها
      • افتراض توفر جميع الفئات المتنافسة في النظام
      متطلبات الاختبار
      • اختبار واجهة المستخدم لتحديد الفئات المتنافسة
      • اختبار قدرة النظام على حفظ الفئات المتنافسة
      • اختبار نظام الإشعارات
      تفاصيل ال API
      Method: POST || Endpoint: /api/competitor-categories
      Request Headers
      Authorization: Bearer token

      Request Body

      categories: array of strings

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      اختيار فئة المنافس

      • textblock
        • اختر الفئات المتنافسة:

      • form
        • CheckboxGroup
          • العنوان : الفئات المتنافسة
          • الخيارات : [{"label":"الفئة 1","value":"category1"},{"label":"الفئة 2","value":"category2"}]
      • رسالة زر الإرسال: حفظ الفئات المتنافسة
      • رسالة النجاح: تم حفظ الفئات المتنافسة بنجاح
      • إعادة توجيه النجاح: ConfirmationPage
      الاشعارات

      العنوان : تأكيد الفئات المتنافسة
      الرسالة : تم تحديد الفئات المتنافسة بنجاح
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : طالب الخدمة

      3.47 - إعلان منافسة في مجال النقل

      3.47.1 المعلومات العامة

      العنوان التفاصيل
      الجهات المعنية
      • طالب الخدمة
      • الشركات الناقلة
      • وسطاء النقل
      • التطبيق
      • إداري النظام
      الخطوات الرئيسية
      • طالب الخدمة يقدم طلبًا لنشر منافسة نقل
      • تقديم التطبيق لمعاينة النشر والخيارات المتاحة
      • تأكيد طالب الخدمة للنشر
      • إرسال التطبيق لإشعارات للشركات المتنافسة المستهدفة
      • يمكن للشركات المتنافسة الرد على الطلبات المنشورة
      • قابلية التعطيل والتفعيل لخاصية الرسوم من قبل إداري النظام
      الخطوات البديلة
      • إمكانية تحديد طالب الخدمة لشركات معينة لتلقي الطلب بدلاً من نشره عامة
      قصص المستخدمين
      • طالب الخدمة: بعد تحديد متطلباتي الخاصة، أستطيع نشر المنافسة حيث يمكن لجميع الشركات المتنافسة المشاركة فيها أو الشركات التي اخترتها
      • الشركات الناقلة / وسطاء النقل: أتلقى إشعارات حول المنافسات التي تناسب خدماتي وأقدم عروضي
      • إداري النظام: أستطيع تعطيل أو تفعيل خاصية الرسوم حسب الحاجة
      • التطبيق: تنظم المنافسة بنجاح على الطلبات عبر المنصة، وساعد العملاء ومقدمي الخدمة في العثور على أفضل العروض والطلبات المناسبة
      مؤشرات الأداء
      • عدد المنافسات المنشورة ونسبتها للطلبات المكتملة

      3.47.2 حالات الاستخدام

      3.47.2.1- تمكين طالب الخدمة من تقديم طلب لنشر منافسة نقل عبر المنصة مع ملء كافة التفاصيل المطلوبة

      graph LR; A[يدخل طالب الخدمة إلى صفحة تقديم طلب نشر منافسة نقل] --> B[يقوم بتقديم طلب النشر بعد ملء كافة التفاصيل]; B --> C[يحفظ النظام طلب النشر وينشره على المنصة];
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • وجود حساب مسجل لطالب الخدمة على المنصة
      • أن يكون طالب الخدمة قد حدد متطلباته الخاصة بالنقل
      الشروط اللاحقة
      • نشر طلب المنافسة على المنصة
      • إرسال إشعارات للشركات المتنافسة المستهدفة
      الافتراضات
      • طالب الخدمة لديه المعلومات الكاملة لتقديم الطلب
      متطلبات الأمان
      • يجب حماية بيانات طلب النشر
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة المناقصات
      القيود والافتراضات
      • يجب أن تكون البيانات محدثة وفي الوقت الفعلي
      متطلبات الاختبار
      • اختبارات الوظائف
      • اختبارات الأمان
      تفاصيل ال API
      Method: POST || Endpoint: /api/competition/publish
      Request Headers
      Authorization: Bearer token

      Request Body

      competitionDetails: object

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      نشر المسابقة

      • textblock
        • نشر منافسة نقل

      • form
        • text
          • العنوان : تفاصيل المنافسة
      • رسالة زر الإرسال: نشر المنافسة
      • رسالة النجاح: تم نشر المنافسة بنجاح
      • إعادة توجيه النجاح: قائمة المسابقة
      الاشعارات

      العنوان : طلب منافسة جديد
      الرسالة : تم نشر طلب منافسة جديد، يرجى الاطلاع عليه
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : الشركات المتنافسة المستهدفة

      3.47.2.2- تمكين التطبيق من تقديم معاينة للنشر والخيارات المتاحة لطالب الخدمة قبل تأكيد النشر

      graph LR; A[يتحقق التطبيق من طلب النشر المقدم] --> B[يعرض التطبيق كافة الخيارات المتاحة لطالب الخدمة]; B --> C[يؤكد طالب الخدمة النشر];
      العنوانالتفاصيل
      المستخدمالتطبيق
      الشروط المسبقة
      • وجود طلب نشر منافسة مقدم من طالب الخدمة
      • إعداد كافة الخيارات الممكنة للنشر
      الشروط اللاحقة
      • عرض طلب المنافسة مع الخيارات على طالب الخدمة
      • تأكيد طالب الخدمة للنشر
      الافتراضات
      • وجود خيارات متعددة للنشر يمكن عرضها لطالب الخدمة
      متطلبات الأمان
      • يجب حماية بيانات طلب النشر والخيارات المتاحة
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة المناقصات
      القيود والافتراضات
      • يجب أن تكون البيانات محدثة وفي الوقت الفعلي
      متطلبات الاختبار
      • اختبارات الوظائف
      • اختبارات الأمان
      تفاصيل ال API
      Method: GET || Endpoint: /api/competition/{competitionId}/options
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200options: array
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      عرض خيارات المسابقة

      • textblock
        • خيارات النشر المتاحة

      • list
        • النوع : الخيار 1

        • النوع : الخيار 2

      • form
        • Button
          • العنوان : تأكيد النشر
          • الخيارات : confirmPublication
      الاشعارات

      العنوان : خيارات النشر متاحة
      الرسالة : الرجاء اختيار الخيار المناسب لنشر المنافسة
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : طالب الخدمة

      3.47.2.3- تمكين التطبيق من إرسال إشعارات للشركات المتنافسة المستهدفة بعد تأكيد نشر طلب المنافسة من قبل طالب الخدمة

      graph LR; A[يحدد التطبيق الشركات المتنافسة المستهدفة] --> B[يرسل التطبيق إشعارات لطلب المنافسة]; B --> C[يحفظ النظام سجل الإشعارات المرسلة];
      العنوانالتفاصيل
      المستخدمالتطبيق
      الشروط المسبقة
      • تأكيد طلب النشر من قبل طالب الخدمة
      • إعداد قائمة الشركات المتنافسة المستهدفة
      الشروط اللاحقة
      • إرسال الإشعارات إلى الشركات المتنافسة
      • حفظ سجل الإشعارات المرسلة
      الافتراضات
      • قائمة الشركات المتنافسة المستهدفة محدثة ودقيقة
      متطلبات الأمان
      • يجب حماية بيانات الإشعارات المرسلة
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة الإشعارات
      القيود والافتراضات
      • يجب أن تكون البيانات محدثة وفي الوقت الفعلي
      متطلبات الاختبار
      • اختبارات الوظائف
      • اختبارات الأمان
      تفاصيل ال API
      Method: POST || Endpoint: /api/competition/{competitionId}/notify
      Request Headers
      Authorization: Bearer token

      Request Body

      notificationDetails: object

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      إرسال الإشعارات

      • textblock
        • إرسال الإشعارات

      • textblock
        • جاري إرسال الإشعارات للشركات المتنافسة المستهدفة

      الاشعارات

      العنوان : إشعار منافسة جديد
      الرسالة : تم نشر طلب منافسة جديد، يرجى الاطلاع عليه
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : الشركات المتنافسة المستهدفة

      3.47.2.4- إمكانية تحديد طالب الخدمة لشركات معينة لتلقي الطلب بدلاً من نشره عامة. يتيح هذا الإجراء لطالب الخدمة القدرة على تحديد شركات معينة يرغب في التعامل معها لإرسال الطلبات مباشرة إليها، بدلاً من نشر الطلب على المنصة بشكل عام

      graph LR A[طالب الخدمة يدخل إلى صفحة تحديد الشركات المستهدفة] --> B[طالب الخدمة يحدد الشركات المستهدفة] B --> C[النظام يحفظ الشركات المحددة] C --> D[النظام يرسل الإشعارات للشركات المحددة فقط] C -->|فشل| E[النظام يظهر رسالة خطأ لطالب الخدمة] E --> F[طالب الخدمة يحاول مرة أخرى تحديد الشركات] F --> C[النظام يحفظ الشركات المحددة] C --> G[النظام يؤكد حفظ الشركات المحددة]
      العنوانالتفاصيل
      المستخدمطالب الخدمة
      الشروط المسبقة
      • وجود حساب مسجل لطالب الخدمة على المنصة
      • أن يكون طالب الخدمة قد حدد الشركات المستهدفة
      الشروط اللاحقة
      • حفظ الشركات المحددة في نظام المنصة
      • إرسال الإشعارات فقط للشركات المحددة
      تسلسل الأحداث
      • طالب الخدمة يدخل إلى صفحة تحديد الشركات المستهدفة
      • طالب الخدمة يحدد الشركات المستهدفة
      • النظام يحفظ الشركات المحددة
      • النظام يرسل الإشعارات للشركات المحددة فقط
      الخطوات البديلةإذا لم يتمكن طالب الخدمة من تحديد الشركات
      • النظام يظهر رسالة خطأ لطالب الخدمة
      • طالب الخدمة يحاول مرة أخرى تحديد الشركات
      • النظام يسجل تفاصيل المحاولة الفاشلة في قاعدة البيانات
      الخطوات الاستثنائيةفي حالة فشل حفظ الشركات المحددة في النظام
      • النظام يظهر رسالة خطأ لطالب الخدمة
      • النظام يسجل الخطأ للتتبع والمراجعة
      • طالب الخدمة يتواصل مع دعم العملاء لحل المشكلة
      القواعد التجارية
      • يجب أن يكون لدى طالب الخدمة حساب مسجل على المنصة
      • يجب أن يكون لدى النظام القدرة على حفظ وتحديث قائمة الشركات المستهدفة لطالب الخدمة
      الافتراضات
      • طالب الخدمة سيتمكن من تحديد الشركات المستهدفة بسهولة عبر واجهة المستخدم
      • النظام قادر على إرسال الإشعارات إلى الشركات المحددة دون تأخير
      المتطلبات الخاصة
      • يجب أن يكون هناك واجهة مستخدم سهلة الاستخدام لتحديد الشركات المستهدفة
      • يجب توفير إشعار لطالب الخدمة بحالة العملية بعد تحديد الشركات
      الملاحظات والمشاكل
      • يجب توثيق جميع عمليات تحديد الشركات المستهدفة لأغراض المراجعة والأمان
      • يجب أن يكون هناك آلية للتأكد من صحة وحفظ بيانات الشركات المستهدفة
      المدخلاتقائمة الشركات المستهدفة من طالب الخدمة |
      المخرجات
      • إشعار بحالة العملية
      • إشعارات للشركات المحددة
      تفاعلات المستخدم
      • طالب الخدمة يتفاعل مع واجهة المستخدم لتحديد الشركات المستهدفة
      الشروط الخاصة
      • إذا كان هناك تأخير في حفظ الشركات المحددة، يتم إشعار طالب الخدمة بالتأخير ومحاولة حفظ البيانات مرة أخرى
      سيناريوهات الاستخدام
      • طالب الخدمة يرغب في إرسال الطلبات لشركات محددة يثق بها
      • طالب الخدمة يتعاون مع شركات معينة لتقديم عروض مخصصة
      متطلبات الأمان
      • يجب أن تكون عملية تحديد الشركات المستهدفة محمية لضمان أمان المعلومات
      • يجب التحقق من هوية طالب الخدمة قبل حفظ الشركات المحددة
      التكامل مع الأنظمة الأخرى
      • تفاعل مع نظام الإشعارات لإرسال الإشعارات للشركات المحددة
      • تفاعل مع قاعدة بيانات النظام لحفظ قائمة الشركات المستهدفة
      القيود والافتراضات
      • يجب أن يتم تحديد الشركات المستهدفة بدقة لضمان إرسال الإشعارات الصحيحة
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من قدرة النظام على تحديد وحفظ الشركات المستهدفة
      • اختبارات أمان للتأكد من أن العملية محمية من الاستخدام غير المصرح به
      تفاصيل ال API
      Method: POST || Endpoint: /api/target-companies
      Request Headers
      Authorization: Bearer token

      Request Body

      user_id: نص Target_companies : Array

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request
      500
      الوصف: Internal Server Error

      تفاصيل الواجهات
      شاشة الشركات المستهدفة

      • textblock
        • حدد الشركات المستهدفة لتلقي الطلبات:

      • searchbox
      • list
        • النوع : Items : itemRenderer: renderCompanyItem

      • form
        • Button
          • العنوان : حفظ الشركات المحددة
          • الخيارات : submitTargetCompanies
      • textblock
        • تم حفظ الشركات المحددة بنجاح

      الاشعارات

      العنوان : طلب جديد
      الرسالة : لديك طلب جديد من طالب الخدمة
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : الشركات المستهدفة

      3.47.2.5- تفعيل وتعطيل خاصية الرسوم من قبل إداري النظام. يتيح هذا الإجراء لإداري النظام القدرة على تفعيل أو تعطيل خاصية الرسوم وفقًا للسياسات الحالية وإبلاغ كافة الأطراف المعنية بالتحديث

      graph LR A[إداري النظام يدخل إلى لوحة التحكم] --> B[إداري النظام يحدد تفعيل أو تعطيل خاصية الرسوم] B --> C[النظام يحفظ التحديثات] C --> D[النظام يرسل إشعارات للأطراف المعنية بالتحديث] C -->|فشل| E[النظام يظهر رسالة خطأ لإداري النظام] E --> F[إداري النظام يحاول مرة أخرى تحديد السياسة] F --> C[النظام يحفظ التحديثات] C --> G[النظام يؤكد حفظ التحديثات]
      العنوانالتفاصيل
      المستخدمإداري النظام
      الشروط المسبقة
      • وجود حساب إداري النظام
      • تحديد السياسة الحالية لتفعيل أو تعطيل الرسوم
      الشروط اللاحقة
      • تحديث حالة خاصية الرسوم في النظام
      • إبلاغ كافة الأطراف بالتحديث
      تسلسل الأحداث
      • إداري النظام يدخل إلى لوحة التحكم
      • إداري النظام يحدد تفعيل أو تعطيل خاصية الرسوم
      • النظام يحفظ التحديثات
      • النظام يرسل إشعارات للأطراف المعنية بالتحديث
      الخطوات البديلةإذا لم يتمكن إداري النظام من تحديد السياسة بشكل صحيح
      • النظام يظهر رسالة خطأ لإداري النظام
      • إداري النظام يحاول مرة أخرى تحديد السياسة
      • النظام يسجل تفاصيل المحاولة الفاشلة في قاعدة البيانات
      الخطوات الاستثنائيةفي حالة فشل حفظ التحديثات في النظام
      • النظام يظهر رسالة خطأ لإداري النظام
      • النظام يسجل الخطأ للتتبع والمراجعة
      • إداري النظام يتواصل مع دعم العملاء لحل المشكلة
      القواعد التجارية
      • يجب أن يكون لدى إداري النظام حساب مخول لإجراء التغييرات
      • يجب أن تكون التحديثات متوافقة مع السياسات الحالية للنظام
      الافتراضات
      • إداري النظام سيتمكن من الوصول إلى لوحة التحكم بسهولة
      • النظام قادر على حفظ التحديثات وإبلاغ الأطراف المعنية دون تأخير
      المتطلبات الخاصة
      • يجب أن تكون واجهة لوحة التحكم سهلة الاستخدام لتحديد وتحديث حالة الرسوم
      • يجب توفير إشعار لإداري النظام بحالة العملية بعد التحديث
      الملاحظات والمشاكل
      • يجب توثيق جميع عمليات تحديث حالة الرسوم لأغراض المراجعة والأمان
      • يجب أن يكون هناك آلية للتأكد من صحة وحفظ بيانات التحديثات
      المدخلاتحساب إداري النظام | السياسة الحالية لتفعيل أو تعطيل الرسوم |
      المخرجات
      • حالة محدثة لخاصية الرسوم في النظام
      • إشعار بحالة العملية
      • إشعارات للأطراف المعنية
      تفاعلات المستخدم
      • إداري النظام يتفاعل مع واجهة المستخدم لتحديث حالة الرسوم
      الشروط الخاصة
      • إذا كان هناك تأخير في حفظ التحديثات، يتم إشعار إداري النظام بالتأخير ومحاولة حفظ البيانات مرة أخرى
      سيناريوهات الاستخدام
      • إداري النظام يرغب في تفعيل خاصية الرسوم وفقًا للسياسات الجديدة
      • إداري النظام يرغب في تعطيل خاصية الرسوم مؤقتًا لأغراض الصيانة
      متطلبات الأمان
      • يجب أن تكون عملية تحديث حالة الرسوم محمية لضمان أمان المعلومات
      • يجب التحقق من هوية إداري النظام قبل حفظ التحديثات
      التكامل مع الأنظمة الأخرى
      • تفاعل مع نظام الإشعارات لإبلاغ الأطراف المعنية بالتحديث
      • تفاعل مع قاعدة بيانات النظام لحفظ حالة الرسوم المحدثة
      القيود والافتراضات
      • يجب أن تكون التحديثات متوافقة مع السياسات الحالية للنظام
      متطلبات الاختبار
      • اختبارات وظيفية للتحقق من قدرة النظام على تفعيل أو تعطيل خاصية الرسوم
      • اختبارات أمان للتأكد من أن العملية محمية من الاستخدام غير المصرح به
      تفاصيل ال API
      Method: POST || Endpoint: /api/toggle-fee-feature
      Request Headers
      Authorization: Bearer token

      Request Body

      admin_id: نص feature_status: boolean

      Response

      الحالةالمحتوى
      200status: نص message: نص
      الوصف: Success
      400
      الوصف: Bad Request
      500
      الوصف: Internal Server Error

      تفاصيل الواجهات
      شاشة تبديل ميزة الرسوم

      • textblock
        • حدد تفعيل أو تعطيل خاصية الرسوم:

      • form
        • Switch
          • العنوان : تفعيل الرسوم
        • Button
          • العنوان : حفظ التحديثات
          • الخيارات : submitToggleFeature
      • textblock
        • تم تحديث حالة الرسوم بنجاح

      الاشعارات

      العنوان : تحديث حالة الرسوم
      الرسالة : تم تحديث حالة خاصية الرسوم من قبل إداري النظام
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق, ايميل  المستقبل : كافة الأطراف المعنية

      3.48 - الاستجابة للمنافسة

      3.48.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • تحسين الفرص للشركات الناقلة ووسطاء النقل للمشاركة والفوز في المنافسات التي تتوافق مع خدماتها
      الجهات المعنية
      • الشركات الناقلة
      • وسطاء النقل
      • العميل
      • التطبيق
      الخطوات الرئيسية
      • تصفح الشركات الناقلة ووسطاء النقل للمنافسات المتاحة
      • تحميل بيانات المنافسة ومرفقاتها
      • تجهيز الرد على المنافسة بالاقتراح المناسب للعرض
      • إرسال الرد على المنافسة عبر البريد الإلكتروني الخاص بالعميل
      الخطوات البديلة
      • الاستجابة على المنافسة من خلال البريد الإلكتروني للشركات مباشرة
      قصص المستخدمين
      • الشركات الناقلة / وسطاء النقل: استطيع تصفح المنافسات الفعالة وتحميل بيانات المنافسة ومرفقاتها
      • الشركات الناقلة / وسطاء النقل: أجهز عروضي وأرسلها عبر البريد الإلكتروني الخاص بالعميل
      • العميل: استقبل أفضل العروض من الشركات الناقلة ووسطاء النقل من خلال البريد الإلكتروني
      • التطبيق: العمل على تيسير الاتصال بين طالب الخدمة والشركات الناقلة / وسطاء النقل، مما يؤدي إلى تبادل العروض بكفاءة
      مؤشرات الأداء
      • عدد الطلبات التي تمت الاستجابة لها ونسبتها للطلبات التي تم نشرها

      3.48.2 حالات الاستخدام

      3.48.2.1- تمكين الشركات الناقلة ووسطاء النقل من تصفح المناقصات المفتوحة على المنصة وتحديد المناقصة المناسبة للرد عليها

      graph LR; A[الدخول إلى المنصة] --> B[تسجيل الدخول بحساب المستخدم]; B --> C[تحديد قسم المنافسات من القائمة الرئيسية]; C --> D[تصفح القائمة المتاحة للمنافسات]; D --> E[اختيار المنافسة المناسبة للتفاصيل الكاملة];
      العنوانالتفاصيل
      المستخدمالشركات الناقلة / وسطاء النقل
      الشروط المسبقة
      • وجود منافسات منشورة على المنصة
      • تسجيل دخول المستخدم إلى المنصة
      الشروط اللاحقة
      • تم تصفح المنافسات وتحديد المنافسة المناسبة للرد عليها
      • تحديث حالة المناقصة في النظام لتعكس تصفح المستخدم
      تسلسل الأحداث
      • الدخول الى النظام
      • فتح صفحة المنافسات المتاحة
      • تصفح القائمة المتاحة للمنافسات
      الخطوات البديلةتصفح المنافسات عبر البريد الإلكترون
      • فتح البريد الإلكتروني
      • تصفح المنافسات المتاحة المرسلة عبر البريد الإلكتروني
      • تحديد المنافسة المناسبة للرد عليها
      الخطوات الاستثنائيةعدم وجود منافسات منشورة
      • عرض رسالة توضيحية بعدم وجود منافسات متاحة
      • الانتظار حتى نشر منافسات جديدة
      القواعد التجارية
      • المنافسات تكون متاحة فقط للشركات الناقلة ووسطاء النقل المسجلين في المنصة
      • يجب مراجعة جميع العروض المقدمة قبل إرسالها إلى العميل
      الافتراضات
      • الشركات الناقلة ووسطاء النقل لديهم حسابات مفعلة على المنصة
      • جميع البيانات والمرفقات المتعلقة بالمنافسات صحيحة ومحدثة
      المتطلبات الخاصة
      • يجب أن تكون المنافسات واضحة ومفصلة لتسهيل عملية التقديم
      • يجب أن تكون المنصة سهلة الاستخدام ومرنة في عرض المنافسات
      الملاحظات والمشاكل
      • يجب تحسين تجربة المستخدم في تصفح المنافسات لتقليل الوقت المستغرق في البحث والتقديم
      المدخلاتبيانات الدخول إلى المنصة |
      المخرجات
      • قائمة المنافسات المتاحة
      • تفاصيل المنافسة المحددة
      تفاعلات المستخدم
      • الدخول الي النظام
      • تحديد قسم المنافسات
      • تصفح القائمة المتاحة للمنافسات
      سيناريوهات الاستخدام
      • شركة نقل ترغب في تصفح المنافسات المتاحة لتقديم عرض مناسب
      • وسيط نقل يبحث عن منافسات تناسب خدماته لتقديم عرض للعميل
      متطلبات الأمان
      • يجب أن تكون المعلومات المعروضة للمستخدم محمية
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام البريد الإلكتروني لإرسال المنافسات
      • تكامل مع نظام إدارة الحسابات للتحقق من تسجيل المستخدم
      القيود والافتراضات
      • وجود منافسات منشورة على المنصة
      • الشركات الناقلة ووسطاء النقل لديهم حسابات محدثة ومسجلة
      متطلبات الاختبار
      • اختبار واجهة المستخدم لتصفح المنافسات
      • اختبار عملية تحميل وتصفح بيانات المنافسة
      تفاصيل ال API
      Method: GET || Endpoint: /api/competitions
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200Competitions : Array
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      قائمة المسابقة

      • textblock
        • المنافسات المتاحة

      • table
        • الاسم : عنوان المنافسة
        • نوع المحتوي : text

        • الاسم : الوصف
        • نوع المحتوي : text

        • الاسم : الحالة
        • نوع المحتوي : text

      الاشعارات

      العنوان : منافسة جديدة متاحة
      الرسالة : تم إضافة منافسة جديدة، يرجى الاطلاع عليها
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : الشركات الناقلة / وسطاء النقل

      3.48.2.2- تمكين الشركات الناقلة ووسطاء النقل من تحميل بيانات المنافسة ومرفقاتها من المنصة للمراجعة

      graph LR; A[فتح تفاصيل المنافسة المحددة] --> B[الضغط على زر تحميل المرفقات]; B --> C[تحميل كافة المرفقات والبيانات الخاصة بالمنافسة];
      العنوانالتفاصيل
      المستخدمالشركات الناقلة / وسطاء النقل
      الشروط المسبقة
      • تحديد المنافسة المناسبة
      • تسجيل دخول المستخدم إلى المنصة
      • توفر اتصال إنترنت مستقر
      الشروط اللاحقة
      • تم تحميل بيانات المنافسة ومرفقاتها للمراجعة
      • تحديث حالة تحميل البيانات في النظام
      القواعد التجارية
      • المنافسات تكون متاحة فقط للشركات الناقلة ووسطاء النقل المسجلين في المنصة
      • يجب مراجعة جميع العروض المقدمة قبل إرسالها إلى العميل
      الافتراضات
      • المنافسة تحتوي على مرفقات وبيانات تكون صحيحة وقابلة للتحميل
      • الشركات الناقلة ووسطاء النقل لديهم حسابات مسجلة على المنصة
      المتطلبات الخاصة
      • تكون المنافسات واضحة ومفصلة لتسهيل عملية عرض المرفقات وتحميلها
      الملاحظات والمشاكل
      • يجب تحسين تجربة المستخدم في تصفح المنافسات لتقليل الوقت المستغرق في البحث والتقديم
      المدخلاتبيانات الدخول |
      المخرجات
      • بيانات المنافسة
      • مرفقات المنافسة
      تفاعلات المستخدم
      • الدخول الى المنصة
      • فتح تفاصيل المنافسة
      • تحميل مرفقات المنافسة
      سيناريوهات الاستخدام
      • شركة نقل ترغب في مراجعة تفاصيل المنافسة لإعداد عرض مناسب
      • وسيط نقل يرغب في تحميل بيانات المنافسة ومراجعتها قبل تقديم عرض
      متطلبات الأمان
      • يجب أن تكون البيانات والمرفقات المحملة محمية وآمنة
      • يجب تأمين عملية تحميل بيانات المنافسات
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة الملفات
      القيود والافتراضات
      • وجود منافسات منشورة على المنصة
      • الشركات الناقلة ووسطاء النقل لديهم حسابات محدثة ومسجلة
      متطلبات الاختبار
      • اختبارات واجهة المستخدم لعرض المنافسات
      • اختبارات عملية تحميل وتصفح مرفقات المنافسة
      تفاصيل ال API
      Method: GET || Endpoint: /api/competition/{competitionId}/attachments
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200Attachments : Array
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      تفاصيل المسابقة

      • textblock
        • تفاصيل المنافسة

      • textblock
        • تحميل كافة المرفقات والبيانات الخاصة بالمنافسة

      • form
        • Button
          • العنوان : تحميل المرفقات
          • الخيارات : downloadAttachments
      الاشعارات

      العنوان : تم تحميل مرفقات المنافسة
      الرسالة : تم تحميل جميع المرفقات الخاصة بالمنافسة للمراجعة
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : الشركات الناقلة / وسطاء النقل

      3.48.2.3- تمكين الشركات الناقلة ووسطاء النقل من تجهيز الرد على المنافسة من خلال إعداد العرض المناسب بناءً على مراجعة البيانات والمرفقات

      graph LR; A[فتح تفاصيل المنافسة] --> B[مراجعة شروط ومتطلبات المنافسة]; B --> C[إعداد العرض المناسب مع كافة التفاصيل المطلوبة]; C --> D[حفظ العرض في النظام];
      العنوانالتفاصيل
      المستخدمالشركات الناقلة / وسطاء النقل
      الشروط المسبقة
      • مراجعة بيانات المنافسة والمرفقات
      • تسجيل دخول المستخدم إلى المنصة
      • فهم كامل لشروط ومتطلبات المنافسة
      الشروط اللاحقة
      • تم تجهيز العرض المناسب للرد على المنافسة
      • تم حفظ العرض في النظام للرد النهائي
      تسلسل الأحداث
      • مراجعة تفاصيل المنافسة
      • اعداد عرض مناسب
      • تقديم العرض
      الخطوات البديلةالحاجة لمزيد من المعلومات قبل إعداد العرض
      • التواصل مع الجهة المعلنة للمنافسة للحصول على المعلومات الإضافية
      • تحديث العرض بناءً على المعلومات الجديدة
      الخطوات الاستثنائيةعدم القدرة على إعداد عرض مناسب
      • إبلاغ الجهة المعلنة بعدم القدرة على تقديم عرض
      • توثيق الأسباب وتقديم توصيات إذا كانت متاحة
      القواعد التجارية
      • يجب أن تتوافق العروض المقدمة مع شروط ومتطلبات المنافسة
      • يجب أن تكون العروض شاملة لكافة التفاصيل المطلوبة
      الافتراضات
      • الشركات الناقلة ووسطاء النقل لديهم خبرة في إعداد العروض
      • جميع البيانات والمرفقات المتعلقة بالمنافسة متاحة ومحدثة
      المتطلبات الخاصة
      • يجب أن تكون المنصة تدعم سهولة الوصول إلى معلومات المنافسة وتفاصيلها
      • يجب أن تكون عملية إعداد وتقديم العروض مبسطة وواضحة
      الملاحظات والمشاكل
      • توفير إرشادات واضحة حول كيفية إعداد العروض بشكل صحيح لتقليل الأخطاء
      • ضمان توفر الدعم الفني في حال وجود استفسارات أو مشاكل
      المدخلاتبيانات المنافسة | مرفقات المنافسة |
      المخرجات
      • العرض المناسب للمنافسة
      تفاعلات المستخدم
      • مراجعة بيانات المنافسات
      • عداد العرض
      • تقديم العرض
      الشروط الخاصة
      • يجب أن تكون البيانات صحيحة ومحدثة
      سيناريوهات الاستخدام
      • شركة نقل ترغب في إعداد عرض مناسب لمنافسة معينة
      • وسيط نقل يرغب في تجهيز عرض للرد على منافسة متاحة
      متطلبات الأمان
      • يجب أن تكون بيانات العرض محمية ومؤمنة
      • تأمين عملية اعداد العرض وتقديمه
      التكامل مع الأنظمة الأخرى
      • تكامل مع نظام إدارة العروض لتتبع حالة العروض المقدمة
      • تكامل مع نظام الإشعارات لإبلاغ الجهة المعلنة عند تقديم العرض
      القيود والافتراضات
      • وجود منافسات منشورة على المنصة
      • الشركات الناقلة ووسطاء النقل لديهم حسابات محدثة ومسجلة
      متطلبات الاختبار
      • اختبار واجهة المستخدم لعملية إعداد وتقديم العروض
      • اختبار تكامل البيانات بين الأنظمة المختلفة
      تفاصيل ال API
      Method: POST || Endpoint: /api/competition/{competitionId}/submitOffer
      Request Headers
      Authorization: Bearer token

      Request Body

      offerDetails: object

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      تحضير العرض

      • textblock
        • إعداد العرض

      • form
        • text
          • العنوان : تفاصيل العرض
      • رسالة زر الإرسال: إرسال العرض
      • رسالة النجاح: تم إرسال العرض بنجاح
      • إعادة توجيه النجاح: قائمة المسابقة
      الاشعارات

      العنوان : تم تجهيز العرض
      الرسالة : تم تجهيز عرضك للرد على المنافسة
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : الشركات الناقلة / وسطاء النقل

      3.48.2.4- تمكين الشركات الناقلة ووسطاء النقل من إرسال العرض المناسب على المنافسة إلى العميل عبر البريد الإلكتروني

      graph LR; A[فتح تفاصيل العرض] --> B[فتح البريد الإلكتروني]; B --> C[إرفاق العرض المناسب]; C --> D[إرسال البريد الإلكتروني إلى العميل]; D --> E[تحديث حالة العرض في النظام];
      العنوانالتفاصيل
      المستخدمالشركات الناقلة / وسطاء النقل
      الشروط المسبقة
      • تجهيز العرض المناسب
      • تسجيل دخول المستخدم إلى المنصة
      • توفير البريد الإلكتروني الخاص بالعميل
      الشروط اللاحقة
      • تم إرسال العرض إلى العميل
      • تحديث حالة العرض في النظام لتعكس أنه تم إرساله
      تسلسل الأحداث
      • فتح البريد الالكتروني
      • ارفاق العرض
      • ارسال البريد الالكتروني
      الخطوات البديلةإرسال العرض من خلال المنصة
      • فتح صفحة تفاصيل المنافسة على المنصة
      • إرفاق العرض المناسب في النموذج المخصص
      • النقر على زر 'إرسال' لإرسال العرض عبر المنصة
      الخطوات الاستثنائيةعدم القدرة على إرسال البريد الإلكتروني
      • النظام يعرض رسالة خطأ
      • محاولة إرسال البريد الإلكتروني مرة أخرى بعد تصحيح المشكلة
      القواعد التجارية
      • يجب أن تتوافق العروض المقدمة مع شروط ومتطلبات المنافسة
      • يجب أن تكون العروض شاملة لكافة التفاصيل المطلوبة
      الافتراضات
      • البريد الإلكتروني الخاص بالعميل صحيح ومفعل
      • الشركات الناقلة ووسطاء النقل لديهم حسابات مسجلة على المنصة
      • جميع البيانات والمرفقات المتعلقة بالمنافسات صحيحة ومحدثة
      المتطلبات الخاصة
      • يجب أن تكون المنصة تدعم سهولة الوصول إلى معلومات المنافسة وتفاصيلها
      • يجب أن تكون عملية إعداد وتقديم العروض مبسطة وواضحة
      الملاحظات والمشاكل
      • توفير إرشادات واضحة حول كيفية إعداد العروض بشكل صحيح لتقليل الأخطاء
      • ضمان توفر الدعم الفني في حال وجود استفسارات أو مشاكل
      المدخلاتبيانات العرض | مرفقات العرض |
      المخرجات
      • البريد الالكتروني المرسل الى العميل
      تفاعلات المستخدم
      • فتح البريد الالكتروني
      • ارفاق العرض
      • ارسال البريد الالكتروني
      الشروط الخاصة
      • يجب أن يكون البريد الإلكتروني صحيح ومحدث
      سيناريوهات الاستخدام
      • شركة نقل ترغب في إرسال عرض مناسب لمنافسة معينة
      • وسيط نقل يرغب في إرسال عرض للرد على منافسة متاحة
      متطلبات الأمان
      • يجب أن يكون البريد الإلكتروني المرسل محمي وآمن
      التكامل مع الأنظمة الأخرى
      • التكامل مع نظام إدارة البريد الإلكتروني
      • تكامل مع نظام إدارة العروض لتتبع حالة العروض المقدمة
      • تكامل مع نظام الإشعارات لإبلاغ الجهة المعلنة عند تقديم العرض
      القيود والافتراضات
      • وجود منافسات منشورة على المنصة
      • الشركات الناقلة ووسطاء النقل لديهم حسابات محدثة ومسجلة
      متطلبات الاختبار
      • اختبار واجهة المستخدم لعملية إعداد وتقديم العروض
      • اختبار تكامل البيانات بين الأنظمة المختلفة
      تفاصيل ال API
      Method: POST || Endpoint: /api/competition/{competitionId}/sendOffer
      Request Headers
      Authorization: Bearer token

      Request Body

      offerDetails: object clientEmail: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: نجاح
      400
      الوصف: طلب غير صالح

      تفاصيل الواجهات
      إرسال بريد العرض

      • textblock
        • إرسال العرض عبر البريد الإلكتروني

      • form
        • text
          • العنوان : تفاصيل العرض
        • text
          • العنوان : البريد الإلكتروني للعميل
      • رسالة زر الإرسال: إرسال العرض
      • رسالة النجاح: تم إرسال العرض بنجاح
      • إعادة توجيه النجاح: قائمة المسابقة
      الاشعارات

      العنوان : تم إرسال العرض
      الرسالة : تم إرسال العرض الخاص بك إلى العميل بنجاح
      عن طريق : الاشعارات علي الهاتف, الاشعارات داخل التطبيق  المستقبل : الشركات الناقلة / وسطاء النقل

      3.49 - ارشفة منافسات النقل

      3.49.1 المعلومات العامة

      العنوان التفاصيل
      الجهات المعنية
      • العميل
      • التطبيق
      الخطوات الرئيسية
      • بعد انتهاء مدة النشر، يتم أرشفة بيانات المنافسة في حساب العميل
      • يتم أيضًا تخزين كافة البيانات المتعلقة بالمنافسة في سجلات المنصة
      قصص المستخدمين
      • العميل: بعد انتهاء مدة النشر لمنافسة النقل، أستطيع العودة والإطلاع على جميع المعلومات المتعلقة بالمنافسة في حسابي
      • التطبيق: بعد انتهاء مدة النشر، أأمن آلية لأرشفة بيانات المنافسة بطريقة منظمة ومتاحة لكل من العميل ومشرفي المنصة

      3.49.2 حالات الاستخدام

      3.49.2.1- أرشفة بيانات المنافسة بعد انتهاء مدة النشر في حساب العميل

      graph LR; A[انتهاء مدة النشر] --> B[التطبيق يتعرف على انتهاء المدة]; B --> C[نقل بيانات المنافسة إلى قسم الأرشيف في حساب العميل];
      العنوانالتفاصيل
      المستخدمالتطبيق
      الشروط المسبقة
      • انتهاء مدة النشر للمنافسة
      الشروط اللاحقة
      • تم أرشفة بيانات المنافسة في حساب العميل
      تسلسل الأحداث
      • انتهاء مدة النشر
      • التطبيق يتعرف على انتهاء المدة
      • نقل البيانات إلى الأرشيف
      سيناريوهات الاستخدام
      • تنتهي مدة النشر تلقائيًا ويتم أرشفة البيانات دون تدخل المستخدم
      متطلبات الاختبار
      • اختبار انتهاء مدة النشر
      • اختبار نقل البيانات إلى الأرشيف
      تفاصيل ال API
      Method: POST || Endpoint: /archive/competition
      Request Headers
      Authorization: Bearer token

      Request Body

      competition_id: نص

      Response

      الحالةالمحتوى
      200status: archived
      الوصف: نجاح
      400
      الوصف: طلب غير صحيح

      تفاصيل الواجهات
      شاشة تأكيد الأرشفة

      • textblock
        • تم أرشفة بيانات المنافسة بنجاح

      • form
        • Button
          • العنوان : موافق
          • الخيارات : redirectToDashboard
      الاشعارات

      العنوان : أرشفة المنافسة
      الرسالة : تم أرشفة بيانات المنافسة الخاصة بك بنجاح
      عن طريق : دفع الإشعارات, شريط الإشعارات, البريد الإلكتروني  المستقبل : العميل

      3.49.2.2- تخزين كافة البيانات المتعلقة بالمنافسة في سجلات المنصة بعد انتهاء مدة النشر

      graph LR; A[انتهاء مدة النشر] --> B[التطبيق يتعرف على انتهاء المدة]; B --> C[نقل بيانات المنافسة إلى السجلات الخاصة بالمنصة];
      العنوانالتفاصيل
      المستخدمالتطبيق
      الشروط المسبقة
      • انتهاء مدة النشر للمنافسة
      الشروط اللاحقة
      • تم تخزين كافة بيانات المنافسة في سجلات المنصة
      تسلسل الأحداث
      • انتهاء مدة النشر
      • التطبيق يتعرف على انتهاء المدة
      • نقل البيانات إلى السجلات
      سيناريوهات الاستخدام
      • تنتهي مدة النشر تلقائيًا ويتم تخزين البيانات دون تدخل المستخدم
      متطلبات الاختبار
      • اختبار انتهاء مدة النشر
      • اختبار نقل البيانات إلى السجلات
      تفاصيل ال API
      Method: POST || Endpoint: /logs/competition
      Request Headers
      Authorization: Bearer token

      Request Body

      competition_id: نص

      Response

      الحالةالمحتوى
      200status: logged
      الوصف: نجاح
      400
      الوصف: طلب غير صحيح

      تفاصيل الواجهات
      شاشة تأكيد التخزين

      • textblock
        • تم تخزين بيانات المنافسة بنجاح

      • form
        • Button
          • العنوان : موافق
          • الخيارات : redirectToDashboard
      الاشعارات

      العنوان : تخزين بيانات المنافسة
      الرسالة : تم تخزين كافة بيانات المنافسة بنجاح في سجلات المنصة
      عن طريق : دفع الإشعارات, شريط الإشعارات, البريد الإلكتروني  المستقبل : المسؤول

      3.49.2.3- استعراض العميل للمنافسات المؤرشفة في حسابه

      graph LR; A[تسجيل الدخول إلى حساب العميل] --> B[فتح قسم الأرشيف]; B --> C[تصفح المنافسات المؤرشفة];
      العنوانالتفاصيل
      المستخدمالعميل
      الشروط المسبقة
      • وجود منافسات مؤرشفة في حساب العميل
      الشروط اللاحقة
      • تم استعراض المنافسات المؤرشفة
      تسلسل الأحداث
      • العميل يسجل الدخول إلى حسابه
      • العميل يفتح قسم الأرشيف
      • العميل يتصفح المنافسات المؤرشفة
      تفاعلات المستخدم
      • تسجيل الدخول
      • التفاعل مع قسم الأرشيف
      • تصفح البيانات
      سيناريوهات الاستخدام
      • العميل يرغب في مراجعة المنافسات المؤرشفة للتحقق من البيانات
      متطلبات الأمان
      • التحقق من هوية العميل قبل السماح بالوصول إلى الأرشيف
      متطلبات الاختبار
      • اختبار قدرة العميل على الوصول إلى قسم الأرشيف
      • اختبار عرض البيانات المؤرشفة بشكل صحيح
      تفاصيل ال API
      Method: GET || Endpoint: /archive/competitions
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200Competitions : Array
      الوصف: نجاح
      400
      الوصف: طلب غير صحيح
      401
      الوصف: غير مصرح

      تفاصيل الواجهات
      شاشة الأرشيف

      • textblock
        • قائمة المنافسات المؤرشفة

      • table
        • الاسم : عنوان المنافسة
        • نوع المحتوي : نص

        • الاسم : الوصف
        • نوع المحتوي : نص

        • الاسم : تاريخ الأرشفة
        • نوع المحتوي : نص

      الاشعارات

      العنوان : استعراض المنافسات المؤرشفة
      الرسالة : يمكنك الآن استعراض المنافسات المؤرشفة في حسابك
      عن طريق : دفع الإشعارات, شريط الإشعارات, البريد الإلكتروني  المستقبل : العميل

      3.49.2.4- توفير آلية منظمة ومؤمنة لأرشفة البيانات المتعلقة بالمنافسات، بحيث يمكن نقل البيانات إلى الأرشيف بطريقة تضمن سلامتها وسهولة استرجاعها عند الحاجة

      graph LR; A[End of Publication Period] --> B[Prepare Archiving Mechanisms]; B --> C[Transfer Data to Archive]; C --> D[Confirm Data Integrity]
      العنوانالتفاصيل
      المستخدمالتطبيق
      الشروط المسبقة
      • تحديد انتهاء مدة النشر
      • تجهيز آليات الأرشفة
      الشروط اللاحقة
      • تم أرشفة البيانات بطريقة منظمة ومؤمنة
      تسلسل الأحداث
      • تحديد انتهاء مدة النشر
      • تجهيز آليات الأرشفة
      • نقل البيانات إلى الأرشيف
      • تأكيد سلامة البيانات بعد الأرشفة
      الخطوات البديلةانتهاء المدة قبل تجهيز آليات الأرشفة
      • التطبيق يقوم بإرسال إشعار إلى المسؤول لتجهيز آليات الأرشفة
      • انتظار تأكيد التجهيز ثم متابعة عملية الأرشفة
      الخطوات الاستثنائيةفشل عملية نقل البيانات إلى الأرشيف
      • التطبيق يقوم بتسجيل الخطأ
      • إرسال إشعار للمسؤول بحدوث خطأ في الأرشفة
      • محاولة إعادة الأرشفة بعد فترة محددة
      القواعد التجارية
      • يجب أن تتم الأرشفة في مدة لا تتجاوز 24 ساعة من انتهاء مدة النشر
      الافتراضات
      • وجود اتصال مستقر بالشبكة
      • صلاحيات الوصول الكافية لإجراء الأرشفة
      المتطلبات الخاصة
      • توفير آلية التحقق من سلامة البيانات بعد الأرشفة
      • ضمان سعة تخزين كافية في نظام الأرشفة
      الملاحظات والمشاكل
      • قد تتطلب بعض المنافسات عمليات أرشفة معقدة تستدعي تخصيص موارد إضافية
      المدخلاتبيانات المنافسة | تاريخ انتهاء النشر |
      المخرجات
      • تقرير بحالة الأرشفة
      • سجل الأخطاء إن وجدت
      تفاعلات المستخدم
      • إشعارات للمسؤولين عن الأرشفة
      • تنبيهات في حالة الأخطاء
      الشروط الخاصة
      • في حال وجود بيانات حساسة، يجب تطبيق إجراءات أمان إضافية
      سيناريوهات الاستخدام
      • أرشفة بيانات منافسة بعد انتهاء فترة النشر
      • فشل عملية الأرشفة والتعامل مع الأخطاء
      متطلبات الأمان
      • تشفير البيانات أثناء النقل إلى الأرشيف
      • تحديد صلاحيات الوصول لبيانات الأرشيف
      التكامل مع الأنظمة الأخرى
      • نظام إدارة المحتوى
      • قاعدة بيانات الأرشيف
      القيود والافتراضات
      • يجب أن تكون عملية الأرشفة مؤتمتة قدر الإمكان لتقليل الأخطاء البشرية
      • افتراض وجود موارد كافية لتخزين البيانات المؤرشفة
      متطلبات الاختبار
      • اختبارات الأداء للتأكد من قدرة النظام على التعامل مع حجم البيانات
      • اختبارات الأمان لضمان حماية البيانات المؤرشفة
      تفاصيل ال API
      Method: POST || Endpoint: /archive/competition-data
      Request Headers
      Authorization: Bearer token

      Request Body

      competition_id: نص archive_date: نص

      Response

      الحالةالمحتوى
      200status: نص message: تم أرشفة البيانات بنجاح
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      أرشفة بيانات المسابقة

      • form
        • text
          • العنوان : معرف المسابقة
          • التحقق : Competition ID is required
        • date
          • العنوان : تاريخ الأرشفة
          • التحقق : Archive date is required
      • رسالة زر الإرسال: Archive Data
      • رسالة النجاح: تم أرشفة البيانات بنجاح
      • إعادة توجيه النجاح: ArchiveSuccessScreen
      الاشعارات

      العنوان : اكتملت عملية أرشفة البيانات
      الرسالة : تم أرشفة بيانات المسابقة بنجاح
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : system admin,archive manager

      3.50 - إدارة العمليات المالية في المنصة

      3.50.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • توفير معلومات واضحة عن مستوى أداء المستخدم والجدوى الاقتصادية له
      • توفير بيانات واضحة للمستخدم لاتخاذ القرارات المناسبة لتأدية أعماله
      الجهات المعنية
      • جميع العملاء في التطبيق
      الخطوات الرئيسية
      • تقديم طلب تحويل المبالغ من محفظة العميل لحسابه البنكي أو تحويل نقدي لأحد نقاط التسليم النقدية
      الخطوات البديلة
      قصص المستخدمين
      • كمستخدم عميل : أريد أن أكون على علم ودراية واضحة بوضع ممارستي لأعمال النقل والجدوى الاقتصادية منها. كما ارغب بتوفر المعلومات التي تساعدني في اتخاذ القرارات بخصوص اعمالي
      مؤشرات الأداء
      • مؤشر التكاليف التشغيلية على المركبة
      • مؤشر التكاليف الإدارية على المركبة
      • مؤشر تكاليف سائق المركبة
      • مؤشر انخفاض قيمة المركبة السنوي
      • العوائد المالية من المركبة
      • الربح المتحقق من المركبة

      3.50.2 حالات الاستخدام

      3.50.2.1- تتيح ميزة إدارة العمليات المالية للمسؤولين إمكانية متابعة ومعالجة العمليات المالية على المنصة. يتضمن ذلك مراجعة وتأكيد المدفوعات، إصدار الفواتير، إدارة الاستردادات، وتحليل التقارير المالية لضمان سير العمليات المالية بشكل سلس وفعال

      graph LR A[تسجيل الدخول] --> B[إدارة العمليات المالية] B --> C[مراجعة العمليات المعلقة] C --> D{تأكيد أو رفض العملية} D -- تأكيد --> E[إصدار الفاتورة] D -- رفض --> F[معالجة الاسترداد] E --> G[تحديث التقارير] F --> G
      العنوانالتفاصيل
      المستخدممسؤول النظام
      الشروط المسبقة
      • يجب أن يكون المستخدم مسجلاً كمستخدم مسؤول
      • يجب أن يكون المستخدم قد سجل الدخول إلى النظام
      • يجب أن يكون لدى المسؤول صلاحيات لإدارة العمليات المالية
      الشروط اللاحقة
      • يتم تأكيد أو رفض العمليات المالية بشكل صحيح
      • يتم إصدار الفواتير للمستخدمين المعنيين
      • يتم معالجة طلبات الاسترداد بشكل مناسب
      • يتم تحديث التقارير المالية لتعكس الحالة الحالية للعمليات المالية
      تسلسل الأحداث
      • المسؤول يسجل الدخول
      • يختار صفحة إدارة العمليات المالية من القائمة
      • يقوم بمراجعة ومعالجة العمليات المالية
      الخطوات البديلةإذا كانت البيانات المالية المدخلة غير صحيحة أو غير كاملة
      • يتم عرض رسالة خطأ للمسؤول توضح الحقول المطلوبة أو الأخطاء الموجودة
      • يجب على المسؤول تصحيح البيانات وإعادة المحاولة
      الخطوات الاستثنائيةإذا حدث خطأ أثناء معالجة العملية المالية
      • يتم عرض رسالة خطأ للمسؤول توضح أن العملية المالية لم تتم بنجاح
      • يتم تسجيل الخطأ في سجل الأخطاء لمحاولة حله لاحقاً
      القواعد التجارية
      • يجب التأكد من صحة وتنسيق البيانات المالية المدخلة
      • يجب أن تتوافق العمليات المالية مع السياسات المالية والأمان للنظام
      الافتراضات
      • لدى المسؤولين الصلاحيات اللازمة لإدارة العمليات المالية
      • يتم تحديث وتحقق البيانات المالية في الوقت الحقيقي لضمان دقتها
      المتطلبات الخاصة
      • يجب أن تكون واجهة المستخدم سهلة الاستخدام لضمان إدارة العمليات المالية بكفاءة
      • يجب أن تكون عملية المعالجة المالية سريعة وموثوقة
      الملاحظات والمشاكل
      • يجب مراعاة أداء النظام عند معالجة كميات كبيرة من البيانات المالية
      • يجب التأكد من دقة البيانات المالية لتجنب الأخطاء في المعالجة
      المدخلاتتفاصيل تسجيل الدخول للمسؤول | البيانات المالية للعمليات |
      المخرجات
      • تأكيد أو رفض العمليات المالية
      • إصدار الفواتير
      • معالجة طلبات الاسترداد
      • تحديث التقارير المالية
      تفاعلات المستخدم
      • تفاعل المسؤول مع صفحة العمليات المالية
      • استخدام المسؤول لأزرار تأكيد/رفض العمليات، إصدار الفواتير، ومعالجة الاسترداد
      الشروط الخاصة
      • إدخال بيانات مالية غير صحيحة أو غير كاملة
      • حدوث خطأ أثناء معالجة العمليات المالية
      سيناريوهات الاستخدام
      • مراجعة المدفوعات اليومية وتأكيدها
      • إصدار الفواتير الشهرية للعملاء
      • معالجة طلبات الاسترداد التي يقدمها المستخدمون
      • تحليل التقارير المالية الشهرية لتحديد الأداء المالي
      متطلبات الأمان
      • يجب التحقق من صلاحيات المستخدم قبل السماح بالوصول إلى صفحة إدارة العمليات المالية
      • يجب تشفير البيانات المالية أثناء نقلها عبر الشبكة
      التكامل مع الأنظمة الأخرى
      • قاعدة بيانات النظام للحصول على البيانات المالية
      • خدمات الدفع الإلكترونية لتأكيد المدفوعات ومعالجتها
      القيود والافتراضات
      • يجب توفر اتصال مستقر بالإنترنت لإدارة العمليات المالية
      • يجب وجود خوادم قادرة على معالجة كميات كبيرة من البيانات المالية
      متطلبات الاختبار
      • اختبار واجهة المستخدم لضمان تفاعلها السليم
      • اختبار أداء النظام عند معالجة كميات كبيرة من البيانات المالية
      • اختبار دقة البيانات المالية المعالجة
      تفاصيل ال API
      Method: GET || Endpoint: /financial-operations
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص operations: array
      الوصف: Success
      400
      الوصف: Bad Request

      Method: POST || Endpoint: /financial-operations/confirm
      Request Headers
      Authorization: Bearer token

      Request Body

      operation_id: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      Method: POST || Endpoint: /financial-operations/reject
      Request Headers
      Authorization: Bearer token

      Request Body

      operation_id: نص reason: نص

      Response

      الحالةالمحتوى
      200status: نص
      الوصف: Success
      400
      الوصف: Bad Request

      Method: POST || Endpoint: /financial-operations/invoice
      Request Headers
      Authorization: Bearer token

      Request Body

      operation_id: نص invoice_details: object

      Response

      الحالةالمحتوى
      200status: نص invoice_id: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      العمليات المالية

      • textblock
        • إدارة العمليات المالية

      • table
        • الاسم : رقم العملية
        • نوع المحتوي : نص

        • الاسم : التاريخ
        • نوع المحتوي : date

        • الاسم : المبلغ
        • نوع المحتوي : currency

        • الاسم : الحالة
        • نوع المحتوي : نص

      • form
        • text
          • العنوان : رقم العملية
          • التحقق : يجب إدخال رقم العملية
        • textarea
          • العنوان : ملاحظات
          • التحقق : يمكن ترك الملاحظات فارغة
      • رسالة زر الإرسال: تأكيد العملية
      الاشعارات

      العنوان : تحديث العمليات المالية
      الرسالة : تم تحديث العمليات المالية بنجاح
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : المسؤول

      3.51 - لوحة البيانات الإدارية

      3.51.1 المعلومات العامة

      العنوان التفاصيل
      أهداف العمل
      • توفير معلومات واضحة لكافة الوثائق الهامة لممارسة اعمال النقل
      الجهات المعنية
      • المستخدمون (مزودو خدمات النقل)
      • إداري النظام
      الخطوات الرئيسية
      • المستخدم يقوم بإدخال بيانات الوثائق الإدارية لممارسة أعمال النقل
      • نوع الوثيقة: (هوية/إقامة، رخصة قيادة، استمارة مركبة، تأمين مركبة، تأمين صحي، بطاقة تشغيل، سجل تجاري، ترخيص حكومي، رخصة ممارسة، تفويض قيادة، تأشيرة خروج وعودة (مفرد/متعدد)، غير ذلك)
      • اسم الوثيقة
      • رقم الوثيقة
      • جهة إصدار الوثيقة: (جهة حكومية، قطاع خاص)
      • اسم الجهة المصدرة للوثيقة
      • تاريخ انتهاء الوثيقة
      • علاقة الوثيقة (بالسائق، بالمركبة، بالمنشأة)
      • هل انتهاء الوثيقة يتسبب في تعطيل ممارسة أعمال النقل
      • يقوم النظام بإصدار مؤشرات ضمن لوحة بيانات إدارية للمستخدم لتوضيح حالة الوثائق المسجلة وتاريخ انتهائها
      • يقوم النظام بإرسال إشعارات للمستخدم عند قرب انتهاء الوثائق
      الخطوات البديلة
      قصص المستخدمين
      • كمستخدم: أريد إدخال بيانات وثائقي الإدارية لممارسة أعمال النقل، بحيث أتمكن من متابعة حالتها ومعرفة تاريخ انتهائها
      • كإداري النظام: أريد توفير مؤشرات وإشعارات تساعد المستخدمين في إدارة وثائقهم وضمان عدم انتهاء صلاحيتها دون علمهم
      مؤشرات الأداء
      • عدد الوثائق المدخلة ونسبة الوثائق التي اقتربت من تاريخ الانتهاء

      3.51.2 حالات الاستخدام

      3.51.2.1- تتيح لوحة البيانات الإدارية للمستخدمين من نوع المسؤولين الوصول إلى بيانات النظام وعرض إحصائيات الأداء بشكل مرئي. يتضمن ذلك عرض رسوم بيانية، جداول وملخصات لتتبع النشاط والأداء العام للنظام

      graph LR A[تسجيل الدخول] --> B[لوحة البيانات الإدارية] B --> C[عرض البيانات] C --> D{هل البيانات كافية؟} D -- نعم --> E[عرض البيانات والإحصائيات] D -- لا --> F[عرض رسالة عدم توفر البيانات]
      العنوانالتفاصيل
      المستخدممسؤول النظام
      الشروط المسبقة
      • يجب أن يكون المستخدم مسجلاً كمستخدم مسؤول
      • يجب أن يكون المستخدم قد سجل الدخول إلى النظام
      • يجب أن يكون هناك بيانات متاحة لعرضها على اللوحة
      الشروط اللاحقة
      • يتم عرض لوحة البيانات الإدارية مع البيانات والإحصائيات المحدثة
      • يستطيع المستخدم تصدير البيانات المطلوبة في صيغة CSV أو PDF
      • يتم تسجيل كافة العمليات التي قام بها المستخدم في سجل النشاطات
      تسلسل الأحداث
      • المسؤول يسجل الدخول
      • يختار لوحة البيانات الإدارية من القائمة
      • تُعرض البيانات على اللوحة
      الخطوات البديلةإذا لم تتوفر بيانات كافية لعرضها
      • يتم عرض رسالة للمستخدم تفيد بعدم توفر بيانات كافية حالياً
      • يتم عرض الخيارات المتاحة لتحديث البيانات أو محاولة لاحقاً
      الخطوات الاستثنائيةإذا حدث خطأ في تحميل البيانات
      • يتم عرض رسالة خطأ للمستخدم تفيد بعدم القدرة على تحميل البيانات
      • يتم تسجيل الخطأ في سجل الأخطاء لمحاولة حله لاحقاً
      القواعد التجارية
      • يجب أن تتوافق البيانات المعروضة مع سياسات الخصوصية والأمان للنظام
      • يجب أن يتم عرض البيانات بشكل مرئي يسهل فهمها وتحليلها
      الافتراضات
      • يتم تحديث البيانات في النظام بشكل دوري لضمان توفر أحدث الإحصائيات
      • لدى المستخدمين المسؤولين الصلاحيات اللازمة للوصول إلى البيانات المطلوبة
      المتطلبات الخاصة
      • يجب أن تكون واجهة المستخدم متجاوبة وتعمل بكفاءة على مختلف الأجهزة
      • يجب أن تكون عملية تصدير البيانات سهلة وسريعة
      الملاحظات والمشاكل
      • يجب مراعاة أداء النظام أثناء تحميل كميات كبيرة من البيانات
      • يجب التأكد من دقة البيانات المعروضة في اللوحة
      المدخلاتتفاصيل تسجيل الدخول للمسؤول | طلب الوصول إلى لوحة البيانات الإدارية |
      المخرجات
      • البيانات والإحصائيات المعروضة
      • رسائل الخطأ في حال وجود مشاكل
      تفاعلات المستخدم
      • تفاعل المسؤول مع الرسوم البيانية والجداول
      • استخدام المسؤول لأزرار التصدير
      الشروط الخاصة
      • عدم توفر بيانات كافية
      • حدوث خطأ في تحميل البيانات
      سيناريوهات الاستخدام
      • استخدام يومي من قبل المسؤول لمتابعة أداء النظام
      • تصدير البيانات لإعداد تقارير شهرية
      متطلبات الأمان
      • يجب التحقق من صلاحيات المستخدم قبل عرض البيانات
      • يجب تشفير البيانات أثناء نقلها عبر الشبكة
      التكامل مع الأنظمة الأخرى
      • قاعدة بيانات النظام للحصول على البيانات
      • خدمات التصدير إلى CSV و PDF
      القيود والافتراضات
      • يجب توفر اتصال مستقر بالإنترنت لعرض وتحديث البيانات
      • يجب وجود خوادم قادرة على معالجة كميات كبيرة من البيانات
      متطلبات الاختبار
      • اختبار واجهة المستخدم لضمان تفاعلها السليم
      • اختبار أداء النظام عند تحميل كميات كبيرة من البيانات
      • اختبار دقة البيانات المعروضة
      تفاصيل ال API
      Method: GET || Endpoint: /admin-dashboard
      Request Headers
      Authorization: Bearer token

      Request Body

      Response

      الحالةالمحتوى
      200status: نص data: object
      الوصف: Success
      400
      الوصف: Bad Request

      Method: POST || Endpoint: /admin-dashboard/export
      Request Headers
      Authorization: Bearer token

      Request Body

      format: نص

      Response

      الحالةالمحتوى
      200status: نص file_url: نص
      الوصف: Success
      400
      الوصف: Bad Request

      تفاصيل الواجهات
      لوحة التحكم الإدارية

      • textblock
        • لوحة البيانات الإدارية

      • table
        • الاسم : العنوان
        • نوع المحتوي : نص

        • الاسم : القيمة
        • نوع المحتوي : number

      • form
        • select
          • العنوان : تنسيق التصدير
          • التحقق : يجب اختيار تنسيق التصدير
          • الخيارات : ["CSV","PDF"]
      • رسالة زر الإرسال: تصدير البيانات
      الاشعارات

      العنوان : تحديث البيانات
      الرسالة : تم تحديث البيانات على لوحة البيانات الإدارية
      عن طريق : الاشعارات علي الهاتف, ايميل  المستقبل : المسؤول