---
title: "كيف ترسل ملايين رسائل SMS يومياً: دليل الإرسال بكميات ضخمة"
description: "إرسال ملايين رسائل SMS يومياً: حساب TPS، وارتباطات SMPP ونافذتها، والطوابير وتحديد المعدل، وتقارير التسليم، وأسماء المرسل وساعات الهدوء ومؤشرات المراقبة."
canonical: "https://omnichannels.ai/ar/blog/high-volume-sms-sending-guide/"
language: "ar"
updated: "2026-11-02"
publisher: "BroadNet Technologies"
brand: "OmniChannels.ai"
category: "sms"
primaryQuery: "send millions of sms per day"
keywords: ["إرسال ملايين الرسائل النصية", "سرعة إرسال SMS TPS", "نافذة SMPP", "الإرسال الجماعي بكميات كبيرة", "ارتباطات SMPP", "طوابير الرسائل وتحديد معدل الإرسال", "معالجة تقارير التسليم DLR"]
published: "2026-11-02"
author: "OmniChannels.ai Editorial Team"
reviewer: "BroadNet Messaging Solutions Team"
readingMinutes: 11
answer: "لإرسال ملايين رسائل SMS يومياً، قدّر الطاقة الاستيعابية للذروة لا للمتوسط اليومي: اقسم عدد الأجزاء المطلوب إرسالها على ثواني نافذة الإرسال، وأضف هامشاً لحركة رموز التحقق، واضبط نافذة SMPP على قيمة لا تقل عن TPS مضروباً في زمن الذهاب والإياب. استخدم عدة ارتباطات وطوابير لكل مشغّل ومحدِّد معدل يتراجع عند أخطاء الخنق، وعالج تقارير التسليم بشكل منفصل، وافصل رموز التحقق عن الرسائل الترويجية."
takeaways: ["عشرة ملايين رسالة يومياً تعني متوسطاً نحو 116 رسالة في الثانية فقط، لكن حملة ترويجية مضغوطة في أربع ساعات تحتاج نحو 694 في الثانية، وكل جزء إضافي يضاعف الرقم.", "تتيح مواصفة SMPP للمرسل إصدار طلبات كثيرة دون انتظار الردود، وتترك عدد الطلبات المعلّقة للتنفيذ، لذا يجب الاتفاق على النافذة وضبطها. وقاعدة البداية الجيدة: نافذة لا تقل عن TPS مضروباً في زمن الذهاب والإياب بالثواني.", "الخنق (ESME_RTHROTTLED، 0x58) وامتلاء الطابور (ESME_RMSGQFUL، 0x14) إشارتان إلى التباطؤ وإعادة المحاولة مع تراجع تدريجي، لا إلى إعادة الإرسال فوراً.", "تقارير التسليم تدفق ثانٍ بحجم كبير: خطّط لمستهلكيها وتخزينها ومطابقتها بالعناية نفسها التي تخطط بها لعمليات الإرسال.", "تُتفق الطاقة الاستيعابية لكل حساب ولكل مسار مع مزوّدك، فاطلب أرقام الذروة كتابةً واختبرها قبل الإطلاق."]
faq: 
  - q: "كم رسالة في الثانية أحتاج لإرسال مليون رسالة؟"
    a: "اقسم عدد الأجزاء على ثواني نافذة الإرسال. مليون رسالة من جزء واحد في ساعة تحتاج نحو 278 في الثانية، وفي أربع ساعات نحو 69، وموزعة على يوم كامل نحو 12. تُحتسب الرسائل متعددة الأجزاء لكل جزء في معظم المنصات، فرسالة من جزأين تضاعف المعدل المطلوب."
  - q: "ما هي نافذة SMPP وكيف أضبطها؟"
    a: "النافذة هي عدد طلبات submit_sm المسموح أن تكون معلّقة، أي أُرسلت ولم يصل ردها بعد. تسمح مواصفة SMPP بالطلبات غير المتزامنة وتترك الحد للتنفيذ. القاعدة العملية: نافذة لا تقل عن معدل TPS المستهدف مضروباً في زمن الذهاب والإياب بالثواني، ثم ارفعها فقط حتى الحد الذي يتفق عليه مزوّدك، لأن تجاوزه يسبب الخنق."
  - q: "كم ارتباط SMPP أحتاج للإرسال بكميات كبيرة؟"
    a: "يعتمد ذلك على معدل الذروة والحد المتفق عليه لكل ارتباط ومتطلبات الاحتياط. اقسم TPS الذروة على المعدل المتفق عليه لكل ارتباط، وقرّب الناتج إلى الأعلى، وأضف ارتباطاً احتياطياً واحداً على الأقل كي لا يوقف انقطاع اتصال عملية الإرسال. أبقِ رموز التحقق على ارتباطاتها أو حسابها الخاص. تُجهَّز الارتباطات لكل حساب."
  - q: "ماذا أفعل عند استلام ESME_RTHROTTLED؟"
    a: "خفّف السرعة. تعرّف المواصفة ESME_RTHROTTLED (0x58) بأنه تجاوز المرسل حدود الرسائل المسموحة. أوقف الإرسال أو خفّضه، وأعد محاولة الرسائل المرفوضة بتراجع أسّي مع تشويش عشوائي (jitter)، ولا تعد المحاولة في حلقة سريعة فتطيل الخنق. وإذا تكرر ذلك فمعدلك أو نافذتك أعلى من الحد المتفق عليه."
  - q: "كيف أتعامل مع ملايين تقارير التسليم؟"
    a: "أقرّ كل deliver_sm برد deliver_sm_resp فوراً، وضع التقرير في طابور، وعالجه بشكل غير متزامن إلى تخزين مفهرس بمعرّف الرسالة. اجعل المعالجة آمنة عند التكرار (idempotent) لأن التقارير قد تتكرر. شغّل مستهلكي التقارير بمعزل عن مسار الإرسال وراقب مدى تأخرهم."
  - q: "هل يمكنني إرسال رسائل ترويجية ليلاً؟"
    a: "ليس في عدة أسواق. تمنع الإمارات الرسائل التسويقية من 21:00 إلى 07:00 والسعودية من 22:00 إلى 09:00، ومن 01:00 إلى 12:00 في رمضان. جدول الترويج بحسب التوقيت المحلي لكل مستلم، وأرسل رموز التحقق والتنبيهات على حدة لأنها ليست ترويجية."
sources: 
  - title: "SMPP Protocol Specification v3.4, SMPP Developers Forum"
    url: "https://smpp.org/SMPP_v3_4_Issue1_2.pdf"
  - title: "3GPP TS 23.040: Technical realization of the Short Message Service (SMS)"
    url: "https://www.3gpp.org/dynareport?code=23040"
  - title: "TDRA spam policy, UAE"
    url: "https://tdra.gov.ae/-/media/About/regulations-and-ruling/EN/cellular-phone-spam-regulatory-policy-English.ashx"
  - title: "CST Regulations for Curbing SPAM Messages and Calls, Saudi Arabia"
    url: "https://www.cst.gov.sa/en/regulations-and-licenses/regulations/Document-522"
---

# كيف ترسل ملايين رسائل SMS يومياً: دليل الإرسال بكميات ضخمة

Canonical: https://omnichannels.ai/ar/blog/high-volume-sms-sending-guide/
Language: ar
Publisher: OmniChannels.ai by BroadNet Technologies

هذا الدليل موجَّه إلى المهندسين ومسؤولي عمليات الرسائل وفرق المشتريات الذين يرسلون، أو يوشكون أن يرسلوا، بين مليون وعشرة ملايين رسالة SMS يومياً. يوضح كيف تحوّل الحجم اليومي إلى هدف للإنتاجية، وكيف تضبط ارتباطات SMPP ونافذتها، وكيف تدير الطوابير وتحدّد المعدل، وكيف تعالج تقارير التسليم على نطاق واسع، وما يجب تجهيزه لكل دولة. الأرقام في الأمثلة أرقام تخطيطية توضيحية، وليست تصريحات عن طاقة أي مزوّد.

## كم رسالة في الثانية تحتاج لإرسال ملايين الرسائل يومياً؟

تحتاج إلى عدد الأجزاء مقسوماً على ثواني النافذة التي تستطيع الإرسال خلالها فعلاً. الإنتاجية، وتُقاس بـ TPS (عدد الرسائل أو الأجزاء المرسلة في الثانية)، رقم ذروة لا متوسط يومي. راجع [الإنتاجية (TPS)](/ar/glossary/throughput-tps/).

احسب المتوسط أولاً، ثم الذروة لنافذة الإرسال الفعلية:

| الرسائل اليومية | المتوسط في الثانية على 24 ساعة | إذا أُرسلت في 4 ساعات | إذا أُرسلت في ساعتين |
|---|---|---|---|
| 1,000,000 | 11.6 | 69.4 | 138.9 |
| 5,000,000 | 57.9 | 347.2 | 694.4 |
| 10,000,000 | 115.7 | 694.4 | 1,388.9 |

يغيّر الجدول عاملان مضاعِفان:

- **الأجزاء.** الرسالة الأطول من جزء واحد تُرسل في عدة أجزاء، وتحتسب معظم المنصات كل جزء. عشرة ملايين رسالة بمتوسط 1.5 جزء تعني 15 مليون عملية إرسال. تحكّم في ذلك عبر [حدود أحرف SMS](/ar/blog/sms-character-limits-unicode-arabic/) و[أداة عدّ الأحرف](/ar/tools/sms-character-counter/).
- **الهامش الاحتياطي.** أضف الحركة غير التابعة للحملة، مثل رموز التحقق، وهامشاً لإعادة المحاولة والمشغّلين البطيئين. ثلاثون بالمئة بدل تخطيطي شائع، وليست قاعدة.

## كيف تخطط للإنتاجية من أكثر الساعات ازدحاماً لا من المتوسط؟

خطّط انطلاقاً من الساعة أو النافذة الأعلى حركة، لأنها الوقت الذي تتراكم فيه الطوابير ويظهر فيه الخنق. استخدم هذه المعادلة:

**TPS المطلوب = (أجزاء الحملة ÷ ثواني النافذة + TPS ذروة رموز التحقق والتنبيهات) × (1 + الهامش).**

### مثال تطبيقي: متجر تجزئة إقليمي

يرسل متجر تجزئة افتراضي 6 ملايين رسالة ترويجية في اليوم إلى عملاء في الخليج، بمتوسط 1.4 جزء للرسالة. ويريد إنهاء الإرسال خلال أربع ساعات داخل نافذة النهار المسموحة.

- الأجزاء: 6,000,000 × 1.4 = 8,400,000.
- النافذة: 4 ساعات = 14,400 ثانية، فيكون 8,400,000 ÷ 14,400 = 583 في الثانية.
- ذروة حركة رموز التحقق والتنبيهات أثناء الحملة: 40 في الثانية (من قياس المتجر نفسه).
- الهامش: 30 بالمئة.
- المطلوب: (583 + 40) × 1.3 ≈ 810 في الثانية.

هذا الرقم هو ما يطلب المتجر من مزوّده تأكيده لكل مسار كتابةً قبل الإطلاق. هو مدخل تخطيط، ولا يقول شيئاً عمّا تستطيع أي منصة حمله.

## ما هو ارتباط SMPP وكم ارتباطاً تحتاج؟

ارتباط SMPP (bind) جلسة TCP طويلة العمر بين نظامك ومركز الرسائل (SMSC) لدى المزوّد، تُوثَّق ببيانات اعتماد وعنوان IP مسموح. و SMPP (Short Message Peer-to-Peer) بروتوكول الاتصالات لتبادل الرسائل النصية، وهو مبني للحجم المتواصل. راجع [ارتباط SMPP](/ar/glossary/smpp-bind/) و[SMPP مقابل REST API](/ar/blog/sms-api-vs-smpp/).

للارتباط ثلاثة أنواع: مرسِل (transmitter) للإرسال فقط، ومستقبِل (receiver) للتقارير والرسائل الواردة فقط، ومرسِل مستقبِل (transceiver) لكليهما في جلسة واحدة. ويستخدم معظم المرسلين النوع الأخير.

كيف تحدد عدد الارتباطات:

1. خذ TPS الذروة المطلوب.
2. اقسمه على المعدل لكل ارتباط الذي يتفق عليه مزوّدك لحسابك.
3. قرّب إلى الأعلى وأضف ارتباطاً احتياطياً واحداً على الأقل كي لا يوقف انقطاع اتصال عملية الإرسال.
4. ضع حركة رموز التحقق على ارتباطاتها أو حسابها الخاص.

تُجهَّز الارتباطات لكل حساب، فاسأل عن العدد والمعدل لكل ارتباط وعناوين IP المصدر المسموحة. تصف صفحة [بوابة SMPP](/ar/channels/sms/smpp-gateway/) و[وثائق SMPP للمطورين](/developers/smpp/) آلية الاتصال.

## كيف تعمل نافذة SMPP؟

النافذة هي عدد طلبات submit_sm التي يمكن أن تكون معلّقة في وقت واحد. بروتوكول SMPP غير متزامن: تنص المواصفة على أن للمرسل أن يرسل عدة طلبات دون انتظار الردود، وتُستخدم قيمة sequence_number في كل PDU لمطابقة الرد بطلبه. أما الحد الأقصى للعمليات المعلّقة فلا تحدده المواصفة، بل يخضع لتنفيذ كل طرف.

القاعدة الناتجة عن حساب الطوابير هي:

**النافذة ≥ TPS المستهدف × زمن الذهاب والإياب (بالثواني).**

| TPS المستهدف | ذهاب وإياب 50 ms | ذهاب وإياب 150 ms | ذهاب وإياب 300 ms |
|---|---|---|---|
| 100 | 5 | 15 | 30 |
| 400 | 20 | 60 | 120 |
| 810 | 41 | 122 | 243 |

نافذة بقيمة 1 تعني أن المرسل ينتظر كل رد، فيتحدد سقف الإنتاجية بواحد مقسوماً على زمن الذهاب والإياب. ورفع النافذة يفيد حتى تبلغ المعدل الذي يسمح به مزوّدك، وما بعده لا ينتج إلا الخنق. تعامل مع الرقم على أنه أمر يُتفق عليه مع المزوّد ويُختبر، لا يُرفع إلى أقصاه. وزّع TPS على الارتباطات عند استخدام عدة ارتباطات: أربعة ارتباطات بإجمالي 810 TPS يحمل كل منها نحو 203.

## كيف تدير الطوابير وتحدّد المعدل على نطاق واسع؟

ضع طابوراً دائماً بين تطبيقك واتصال SMPP، وصرّفه بمحدِّد معدل يمكنك تغييره أثناء التشغيل. يمتص الطابور الدفعات المفاجئة، ويُبقيك المحدِّد عند المعدل المتفق عليه.

- **دلو رموز (token bucket) لكل ارتباط ولكل مسار.** يُعاد ملؤه بمعدل TPS المتفق عليه، وتؤخذ منه وحدة لكل submit_sm، مع احتساب كل جزء.
- **طابور لكل أولوية.** حركة رموز التحقق والتنبيهات أولاً، ثم رسائل المعاملات، ثم الترويجية.
- **تراجع عند الأخطاء.** عند ESME_RTHROTTLED (0x58) أو ESME_RMSGQFUL (0x14) توقف ثم أعد المحاولة بتراجع أسّي مع تشويش عشوائي. لا تعد الإرسال في حلقة سريعة.
- **أعد الاتصال بتراجع** بعد انقطاعه، وتتبّع أرقام التسلسل المعلّقة لتطابق ما قُبل فعلاً.
- **أبقِ الجلسات حية.** تعرّف المواصفة مؤقت enquire_link للتحقق من أن الطرف الآخر ما زال لديه جلسة نشطة، ومؤقت خمول قد تُقطع الجلسة بعده. أرسل enquire_link أثناء الخمول.
- **إرسال آمن عند التكرار (idempotent).** احفظ معرّف الرسالة الخاص بك قبل الإرسال حتى لا تؤدي إعادة المحاولة إلى إرسالها مرتين.

## كيف توجّه الرسائل لكل مشغّل على نطاق واسع؟

ضع الطوابير ومحدِّدات المعدل لكل مشغّل وجهة، لا لكل ارتباط فقط، كي لا يعرقل مشغّل بطيء بقية المشغّلين. قد يضع المشغّلون سقفاً لحركة A2P لكل مرسل أو مسار، فيكون الحد الفعلي لدولة ما أقل من معدل الحساب.

1. حدّد المشغّل لكل رقم. يفيد فحص الأرقام؛ راجع [فحص HLR](/ar/blog/hlr-lookup-number-validation/).
2. احتفظ بطابور ومحدِّد لكل مشغّل أو مجموعة مسارات.
3. راقب معدل التسليم وتأخر التقارير لكل مشغّل، وأبطئ من يتراجع أداؤه.
4. اسأل مزوّدك هل تُستخدم مسارات مباشرة؛ راجع [المسارات المباشرة مقابل الرمادية](/ar/blog/grey-route-vs-direct-route-sms/).

## كيف تعالج تقارير التسليم على نطاق واسع؟

تعامل مع تقارير التسليم على أنها تدفق ثانٍ بحجم الأول. يصل التقرير على شكل deliver_sm في ارتباطك، ويجب أن تردّ على كل واحد منها بـ deliver_sm_resp. وتعرّف المواصفة الحالات النهائية والمرحلية في التقرير: DELIVRD وEXPIRED وDELETED وUNDELIV وACCEPTD وUNKNOWN وREJECTD. راجع [تقارير التسليم](/ar/glossary/delivery-receipt/) و[شرح حالات تسليم الرسائل](/ar/blog/message-delivery-status-explained/).

تصميم موثوق:

1. **أقرّ بسرعة.** أرسل deliver_sm_resp بمجرد وضع التقرير في طابور.
2. **عالج بشكل غير متزامن** بعاملين يطابقون التقرير مع الرسالة الأصلية عبر معرّف الرسالة.
3. **اجعل المعالجة آمنة عند التكرار.** قد تتكرر التقارير وقد يصل بعضها بترتيب مختلف.
4. **تعامل مع الأجزاء.** بحسب المسار قد تصلك تقارير لكل جزء أو لكل رسالة؛ اختبر ذلك.
5. **حدّد مهلة** للرسائل التي لا تصل لها حالة نهائية وصنّفها مجهولة.
6. **أبعد مستهلكي التقارير عن مسار الإرسال** كي لا يبطئ تراكمها الإرسال.

## ما الذي يجب تسجيله في كل دولة قبل الإرسال؟

تختلف قواعد اسم المرسل من دولة إلى أخرى، وفي بعض الأسواق تُحجب أسماء المرسل غير المسجَّلة أو تُستبدل. من الأمثلة: تشترط الإمارات والسعودية التسجيل لدى المشغّلين، وتشترط الهند تسجيل الترويسة وكل قالب على منصة DLT، وتستخدم الولايات المتحدة 10DLC أو الأرقام المجانية بدل أسماء المرسل الأبجدية الرقمية. تتراوح مدد التجهيز من بضعة أيام عمل إلى نحو شهر في الأسواق التي نتابعها.

ابدأ التسجيلات أولاً لأنها على المسار الحرج للإطلاق. راجع [قواعد التسويق عبر SMS حسب الدولة](/ar/blog/sms-marketing-rules-by-country/) و[أداة فحص اسم المرسل](/ar/tools/sender-id-checker/) و[دليل اسم المرسل في الإمارات والسعودية](/ar/blog/sms-sender-id-registration-uae-saudi/). نُعدّ ونقدّم طلبات التسجيل معك عبر [خدمة التسجيل](/ar/services/registrations/)، وتبقى الموافقات بيد الجهات المنظِّمة والمشغّلين.

## كيف تلتزم بساعات الهدوء عند الإرسال بكميات كبيرة؟

جدول الرسائل الترويجية بحسب التوقيت المحلي لكل مستلم وقاعدة كل دولة، وأبعد الحركة غير الترويجية عن هذا التقييد. تنشر بعض الأسواق نوافذ محددة: تمنع الإمارات الرسائل التسويقية من 21:00 إلى 07:00، والسعودية من 22:00 إلى 09:00 ومن 01:00 إلى 12:00 في رمضان. راجع [ساعات الهدوء](/ar/glossary/quiet-hours/).

- جمّع القائمة بحسب الدولة والمنطقة الزمنية قبل وضعها في الطابور.
- أطلق كل مجموعة في طابورها حين تفتح نافذتها.
- أوقف طوابير الترويج عند نهاية النافذة وأجّل المتبقي إلى اليوم التالي.
- خطّط التسلسل باستخدام [مخطط وقت الإرسال](/ar/tools/send-time-planner/).

النافذة الضيقة ترفع TPS الذي تحتاجه، فاحسبها في معادلة التخطيط.

## لماذا تفصل رموز التحقق عن الحركة الترويجية؟

رسائل رموز التحقق والتنبيهات حساسة للوقت، أما الحملات الترويجية فجماعية؛ وإذا تشاركت طابوراً أو ارتباطاً فقد تؤخر حملة رمز تسجيل دخول. استخدم ارتباطات أو حسابات منفصلة، وأسماء مرسل منفصلة حيث تشترط القواعد ذلك، وطوابير منفصلة بأولوية صارمة، ومراقبة منفصلة. رموز التحقق ليست ترويجية فلا تسري عليها ساعات الهدوء. وحمِّ مسارات رموز التحقق من الإساءة أيضاً: راجع [منع احتيال SMS pumping](/ar/blog/sms-pumping-fraud-prevention/) و[دليل رسائل رموز التحقق](/ar/blog/otp-authentication-messages-guide/).

## ما مؤشرات الأداء التي يجب مراقبتها؟

راقب سلامة الإرسال وعمر الطابور ونتائج التقارير وتأخرها، موزعة بحسب الدولة والمشغّل. وأنذر عند التغيرات مقارنةً بخط أساسك الخاص.

| المؤشر | المعادلة | ماذا يخبرك |
|---|---|---|
| نسبة نجاح الإرسال | submit_sm_resp المقبولة ÷ submit_sm المرسلة | سلامة الارتباط والحساب |
| نسبة الخنق | ردود ESME_RTHROTTLED ÷ submit_sm المرسلة | معدل أو نافذة أعلى من اللازم |
| عمر الطابور (p95) | الزمن من دخول الطابور إلى الإرسال | نقص في الطاقة الاستيعابية |
| نسبة التسليم | DELIVRD ÷ الرسائل ذات الحالة النهائية | جودة المسار والمحتوى |
| حصة الفاشلة والمنتهية | (UNDELIV + EXPIRED + REJECTD) ÷ الحالات النهائية | صلاحية الأرقام واسم المرسل والتصفية |
| تأخر التقارير (الوسيط وp95) | وقت التقرير − وقت الإرسال | بطء المشغّل |
| تغطية التقارير | الحالات النهائية ÷ الرسائل المرسلة | تقارير مفقودة |
| نسبة الإلغاء | ردود STOP ÷ الرسائل الترويجية المسلَّمة | ملاءمة الجمهور والمحتوى |

راجع [تحسين معدل تسليم SMS](/ar/blog/sms-not-delivered-improve-delivery-rate/) للتشخيص.

## ما قائمة الإطلاق لحملة بملايين الرسائل؟

1. حساب TPS الذروة المطلوب من الأجزاء والنافذة وحمل رموز التحقق.
2. تأكيد المزوّد كتابةً للمعدل لكل ارتباط وعدد الارتباطات والنافذة وعناوين IP المصدر.
3. تسجيل أسماء المرسل في كل دولة، مع القوالب حيث تُشترط.
4. اختبار حمل بجزء من الحجم، ثم التدرج على خطوات؛ لا تبدأ بالحد الأقصى.
5. اختبار الطوابير ومحدِّد المعدل والتراجع والإرسال الآمن عند التكرار، بما فيه قطع اتصال متعمد.
6. اختبار مسار التقارير بحجم التقارير الكامل.
7. التحقق من جدولة ساعات الهدوء لكل دولة.
8. فصل حركة رموز التحقق ومراقبتها.
9. لوحات المتابعة والتنبيهات تعمل، ومعها مسؤول مناوب.
10. زر إيقاف يوقف طوابير الترويج فوراً.

## كيف تساعدك OmniChannels.ai

تسلّم BroadNet الرسائل النصية عبر اتصال مباشر بالمشغّلين، وتدعم SMPP 3.4 عبر TLS بارتباطات تُجهَّز لكل حساب، إضافةً إلى REST API والإرسال الجماعي والرسائل ثنائية الاتجاه ودعم Unicode والعربية وفحص HLR وتقارير التسليم. تُحدَّد الطاقة الاستيعابية لكل حساب ولكل مسار: أخبرنا بوجهاتك وحجم الذروة ونوافذ الإرسال وأسماء المرسل، ونتفق معك على الإنتاجية والارتباطات والتسجيلات. يُعدّ فريقنا تسجيلات اسم المرسل. [تواصل مع فريق المبيعات](/ar/contact/) مع خطة حجمك، أو اطّلع على [برنامج الجملة](/ar/partners/wholesale/).