لسنوات كانت عمليات العمرة تجري عبر بوابات منفصلة: الفنادق في مكان، والنقل في آخر، والتأشيرات في ثالث. وكانت البرامج تقود تلك البوابات بأتمتة المتصفح — تُفتح نافذة وتُملأ الحقول، وإذا ظهرت كابتشا عُرضت على موظف. أنهت السعودية هذا الترتيب.
ما الذي تغيّر
جمعت نسك مسار كل خطوات تشغيل العمرة في منصة واحدة: تسجيل الوكالة، وتعريف الباقة، وحجز الفندق، والنقل، وطلب التأشيرة. ومنذ ١٠ يونيو ٢٠٢٥ لا يمكن الحصول على تأشيرة لطلب بلا حجز فندقي مؤكَّد على نسك.
وهذا ليس تغيير بوابة واحدة. الترتيب نفسه تغيّر: كانت التأشيرة تأتي أولًا ويُرتَّب الفندق بعدها؛ أما الآن فالفندق أولًا والتأشيرة تابعة له.
ماذا يعني ذلك للبرامج القديمة
توقفت كل وحدة تأشيرات كُتبت بأتمتة المتصفح. وكانت تلك الوحدات هشّة أصلًا — فحين تنقل البوابة حقلًا يتوقف التكامل ويعود الموظفون إلى الإدخال اليدوي حتى يُحدَّث الكود.
والنقطة الحاسمة: الكود المكتوب لبوابات مغلقة لا قيمة لنقله. وعند الانتقال إلى برنامج جديد لم يعد سؤال «هل ستُنقل وحدة التأشيرات» ذا معنى؛ فلا شيء يُنقل، بل شيء يُعاد كتابته.
ما الذي حلّ محلّها
لنسك بوابة مطوّرين رسمية تقدّم واجهة REST حديثة. فبدل قيادة الشاشات تتبادل الأنظمة البيانات مباشرة: يُرسَل الطلب، ويُستعلَم عن حالته، وتعود النتيجة.
والوصول يتطلب حساب وكالة مرخّصة. وهذا ليس ما يرتّبه مزوّد البرمجيات وحده؛ بل يُفتح بتفويض الوكالة نفسها. والسؤال الصحيح عند تقييم برنامج ليس «هل عندكم تكامل نسك» بل «أي جانب منه تبنونه حين يتاح الاتصال».
ما تستطيع الوكالة فعله اليوم
حتى يكتمل اتصال نسك، أكثر ما يستهلك الوقت في التأشيرات هو فحص النواقص قبل الإرسال. وتكلفة الطلب المرفوض وقت لا رسوم: يعود الملف، ويُكتشف نقص، ويُتّصل بالمسافر، ثم يُعاد الإرسال.
وهذا الفحص لا يعتمد على نسك. فالمسافرون بلا جواز، أو من ينتهي جوازهم قبل تاريخ العودة، أو بلا صورة، أو بلا محرم مختار، يمكن سردهم جميعًا قبل الإرسال.
- صلاحية الجواز تُحسب من تاريخ العودة لا من اليوم
- قاعدة المحرم يجب أن تكون قابلة للضبط لا مدفونة في الكود — فالنظام يتغيّر
- دقة الصورة تُقاس قبل الإرسال؛ فالدقة المنخفضة سبب رفض