الإجابة باختصار: في بنية الإصدار V17 من Mikro، بات عليك أن تبني تكاملك على واجهة Mikro Desktop API الرسمية، لا على SQL المباشر. أما العبارة المتداولة بين مزوّدي التكامل في السوق، وهي «أُغلق الوصول المباشر إلى قاعدة البيانات في V17 وأصبح النظام قائمًا على API بالكامل»، فهي تلخيص قوي لكنها ليست دقيقة تمامًا: إذ تنص وثائق Mikro الرسمية بوضوح على أن حقول الجداول غير الظاهرة في JSON الخاص بواجهة API لا يزال بالإمكان الإشارة إليها مباشرةً بأسمائها في قاعدة البيانات (DB). فالقراءة الصحيحة إذن هي: مع V17 أصبحت واجهة API الرسمية قناة التكامل الأساسية والمدعومة؛ ويبقى استثناء موثّق هو «الوصول بالاسم في قاعدة البيانات» للحقول التي لا تعرضها الواجهة. فماذا عليك أن تفعل الآن؟ ثلاث خطوات: (1) اجرد كل نقاط القراءة والكتابة الحالية في SQL عمودًا عمودًا، (2) وحدّد لكل حقل: «هل توجد نقطة نهاية (Endpoint) في API، أم أحتاج إلى البديل بالاسم في قاعدة البيانات؟»، (3) ثم اطلب مفتاح API (API Key) عبر بوابة المطورين الرسمية، وشغّل التدفق الجديد بالتوازي لاختباره، وبعدها نفّذ الانتقال النهائي (Cutover). ونشرح في هذا الدليل هذا الترحيل خطوة بخطوة، دون ادّعاء يقين لا سند له، واستنادًا إلى وثائق Mikro الرسمية.

بصفتنا شركة هندسة برمجيات مقرها صقاريا (Sakarya) وتعمل بنموذج B2B (بين الشركات) وWhite-Label (تحت علامتك التجارية)، ندير هذا الترحيل للتكاملات المعتمدة على Mikro في مجالات التجارة الإلكترونية والبرمجيات المخصصة والمحاسبة. ونعرض فيما يلي المنطق الذي يقف وراء القرار ودليل التنفيذ العملي (Playbook) الذي نطبّقه ميدانيًا. وقد أبقينا كل عبارة تبدو «قاطعة» بشأن التواريخ والمنافذ في المواضع التي استطعنا إسنادها فيها إلى مصدر رسمي، وأشرنا بوضوح إلى المواضع التي تمثل تفسيرًا من مزوّدي التكامل.

ما الذي تغيّر بالضبط؟

نشرت Mikro على العنوان apidocs.mikro.com.tr بوابة مطورين رسمية لمنتجات سطح المكتب لديها. وشعار البوابة هو «طوّر، واختبر، وانشر — دليل تكامل Mikro API»، وهي تحدد جمهورها صراحةً على النحو التالي: عملاء برمجيات Mikro، وشركاء برمجيات Mikro، ومطوّرو الحلول من الجهات الخارجية. وبعبارة أخرى، لا تقتصر هذه الواجهة على الموزعين، بل هي القناة الرسمية أيضًا لفرق العملاء الداخلية ولشركات البرمجيات المستقلة.

والطبيعة التقنية لهذه الواجهة واضحة كذلك، فهي تعتمد REST/JSON عبر HTTP أساسًا لها. وتوفر البوابة الرسمية أدلة بعناوين «أساسيات JSON وREST API» و«بروتوكول HTTP ورموز الحالة» و«استخدام نقاط النهاية»، إلى جانب مجموعات Postman رسمية قابلة للتنزيل للإصدارين V17 وV16 («مجموعة Postman الحالية (V17)» و«(V16)»). وتمثل هذه المجموعات نقطة الانطلاق الرسمية لمرحلة الاختبار لديك.

فارق دقيق بالغ الأهمية: من الخطأ القول إن «V17 ألغى كل وصول مباشر إلى قاعدة البيانات». فوفقًا للأسئلة الشائعة الرسمية، «يمكن أيضًا استخدام حقول الجداول غير الموجودة في JSON الخاص بواجهة API مباشرةً بأسمائها في قاعدة البيانات». والصياغة الصحيحة هي أن واجهة API الرسمية أصبحت الآن القناة الأساسية الإلزامية والمدعومة، في حين يبقى مسار الاسم في قاعدة البيانات استثناءً موثقًا للحقول التي لا تعرضها الواجهة.

لماذا أصبح الوصول المباشر إلى قاعدة البيانات خيارًا ثانويًا؟ (منطق القرار)

تلخّص مدونات مزوّدي التكامل في السوق (مثل ozgurguler.net وmikrodestek.net) هذا التغيير بعبارة: «اعتبارًا من Mikro V17 أُغلق الوصول المباشر إلى قاعدة البيانات وانتقل النظام إلى نموذج قائم على API بالكامل». وينبغي نقل هذه العبارة لا بوصفها جملة رسمية من Mikro، بل بوصفها تفسيرًا من مزوّدي التكامل، لأننا لم نجد هذه الصياغة نفسها في مصادر Mikro، ولأن استثناء الاسم في قاعدة البيانات المذكور أعلاه يخفف من هذا الادعاء المطلق. ومع ذلك، فإن المنطق التقني واضح حين يفرض مورّد نظام ERP طبقة API مضبوطة بدلًا من SQL المباشر:

  • الاستقرار والاستقلال عن المخطط: يرتبط SQL المباشر ارتباطًا وثيقًا ببنية الجداول والأعمدة. فعندما يغيّر المورّد المخطط (Schema) في أحد الإصدارات، تتعطل استعلاماتك بصمت. أما طبقة API فتضع عقدًا بين المخطط الداخلي والمستهلك الخارجي، وحتى إن تغيّرت البنية الداخلية، يمكن الحفاظ على عقد نقطة النهاية.
  • الأمان ونطاق الصلاحيات: إن تسليم تطبيقك بيانات اعتماد مباشرة لقاعدة البيانات (سلسلة الاتصال أو Connection String) هو أوسع نطاق ممكن للصلاحيات. أما الوصول عبر API فيفوّض المصادقة إلى آلية الجلسات والتفويض لدى Mikro نفسها، ويمكن تقييد الوصول على مستوى نقطة النهاية.
  • الدعم وقابلية التنبؤ: مع SQL المباشر لا يمكن للمورّد أن يعرف ما تقرؤه أو تكتبه، ولأن قواعد العمل قد تُتجاوز، ينشأ خطر على سلامة البيانات. أما العمليات المنفذة عبر API فهي محددة، وخاضعة لإدارة الإصدارات، وقابلة للدعم. وبالفعل، تنشر Mikro سجل تغييرات (Changelog) لواجهة V17 API بتواريخ محددة: فالسجل [17.03a] – 14.04.2025 هو أقدم ما تمكنّا من رؤيته، والسجل [17.07b] – 05.08.2026 هو الأحدث. وهذا دليل على أن الواجهة تخضع لإدارة إصدارات نشطة وتتطور باستمرار.

من يتأثر بهذا التغيير؟

يتأثر بهذا الترحيل كل تكامل يتصل بقاعدة بيانات Mikro مباشرة. وهذه هي المجموعات الثلاث التي نصادفها أكثر من غيرها ميدانيًا:

  • تكاملات التجارة الإلكترونية: المتاجر التي تستخدم SQL لمزامنة بيانات المخزون والأسعار والحسابات الجارية والطلبات بين Mikro وموقعها الإلكتروني أو السوق الإلكتروني (Marketplace). وتمثل عمليات الكتابة، مثل خصم المخزون وإنشاء الفواتير وأذون التسليم ونقل الطلبات، أخطر المخاطر في هذا الجانب.
  • البرمجيات المخصصة والمشاريع الداخلية: التطويرات الداخلية التي تتخذ من Mikro المرجع الوحيد للبيانات (Source of Truth)، مثل متابعة الإنتاج، وتطبيقات الفرق الميدانية، وبوابات الموزعين (B2B). وبالنسبة إلى هذه المجموعة، تجري عملية ترخيص مفتاح API يدويًا (انظر أدناه).
  • تكاملات المحاسبة والتقارير: مطابقة الحسابات، وجسور الفاتورة الإلكترونية (e-Fatura) وفاتورة الأرشيف الإلكتروني (e-Arşiv)، ولوحات ذكاء الأعمال (BI) والتقارير، وعمليات التصدير الدورية. ورغم أن معظمها «للقراءة فقط»، فإن هذه المجموعة هي الأكثر اعتمادًا على الاستعلامات المباشرة في الجداول.

أما حلّ تدفقات التجارة الإلكترونية والفاتورة الإلكترونية على جانب Mikro بوحدة جاهزة أو بتكامل API مخصص، فهو قرار قائم بذاته تناولناه في مقال منفصل: تكامل التجارة الإلكترونية وERP والفاتورة الإلكترونية: حل جاهز أم API مخصصة؟

دليل الترحيل العملي: من قراءات SQL إلى نقاط نهاية API

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

1) جرد الحقول: تحديد مقابل لكل عمود في SQL

الخطوة الأولى وأكثرها تعرضًا للإغفال: استخرج كل جدول وكل عمود يتعامل معه تكاملك الحالي. ثم اختر لكل حقل أحد مسارين:

  • إذا كان الحقل ظاهرًا في JSON الخاص بواجهة API، فاقرأه من استجابة نقطة نهاية REST المعنية.
  • إذا لم يكن الحقل موجودًا في JSON الخاص بواجهة API، فيمكن الإشارة إليه مباشرةً باسمه في قاعدة البيانات كما تنص الأسئلة الشائعة الرسمية. وهذا مخرج مهم يخفف ضغط عبارة «عليك تحويل كل شيء إلى API دفعة واحدة».
  • إذا لم يكن متاحًا لا عبر نقطة نهاية ولا بوصفه حقلًا يمكن الوصول إليه، فقدّم طلب جدول أو نقطة نهاية جديدة عبر نموذج طلب Program API (إذ تقول Mikro: «لطلبات الجداول الجديدة: نموذج طلب API»).

وعمليات الترحيل التي تُنفَّذ دون هذا الجرد تنهار في بيئة الإنتاج بأخطاء «حقل مفقود». فالمطابقة عمودًا عمودًا هي أكثر خطوات الترحيل إرهاقًا، لكنها أكثرها تأثيرًا في النتيجة.

2) المصادقة وتقديم الطلب

الوصول أولًا: نموذج طلب Program API هو ما يملؤه مزوّدو التكامل. ووفقًا للدليل الرسمي، تُخصَّص مفاتيح API تلقائيًا لمن يستخدمون حلًا قطاعيًا (Vertical Solution)، أما البرمجيات الداخلية فيصدر لها ترخيص يدوي. (خطوات «تقييم الأسئلة والأجوبة التفصيلي عبر البريد الإلكتروني ثم الإحالة إلى قسم كلمات المرور» الموصوفة في بعض مدونات مزوّدي التكامل ليست موثقة بهذه الصورة في المواد الرسمية، إذ لا يتضمن المصدر الرسمي سوى النموذج، والتمييز في الترخيص، وعناوين التواصل.)

نموذج المصادقة ليس OAuth، ولنكن واضحين في هذا. فالنموذج يقوم على مفتاح API + الجلسة/تسجيل الدخول. ووفقًا للدليل الرسمي، تُستخدم المعلومات التالية في كل طلب:

الحقل وظيفته
ApiKey المفتاح الذي تحصل عليه عبر الطلب، ويُرسل بصيغة JSON في جسم الطلب. وإذا كان خاطئًا، تظهر رسالة الخطأ «Geçersiz api key» (مفتاح API غير صالح).
FirmaKodu رمز الشركة.
CalismaYili سنة العمل.
KullaniciKodu رمز المستخدم.
Sifre كلمة المرور، وتُحسب وفقًا للدليل الرسمي بالصيغة MD5 Hash (التاريخ + كلمة المرور).

تختلف إدارة الجلسات باختلاف الإصدار. فطرق (Methods) الإصدار V1 تفتح جلسة أولًا عبر APILogin (العنوان في صفحة التثبيت الرسمية هو POST http://localhost:8094/Api/APIMethods/APILogin، مع إرسال FirmaKodu وCalismaYili وApiKey وKullaniciKodu وSifre في جسم الطلب). أما طرق V2/V3 فترسل بيانات المستخدم مباشرة في JSON الخاص بكل نقطة نهاية، وتسجّل الخروج تلقائيًا فور اكتمال العملية. فاحسم هذا الفرق منذ البداية عند بناء بنيتك (جلسة دائمة أم جلسة عند الطلب).

3) التثبيت وإعدادات المنفذ

تُثبَّت واجهة API عبر خيار «Server» في صفحة تحديثات الإصدار، وتسجّل خدمة Windows باسم Mikro Desktop API في النظام. وتعمل الخدمة ضمن الحساب NT SERVICE\MikroDesktopAPIContainer، ويضم المسار HKLM\SYSTEM\CurrentControlSet\Services\MikroDesktopAPIContainer\Parameters معاملات المنفذ. وإذا أردت تغيير المنفذ، فأوقف الخدمة وعدّله عبر regedit (Decimal Base)، ثم افتح المنفذ في جدار الحماية الخاص بنظام Windows (Windows Firewall).

تختلف منافذ الخدمة الافتراضية باختلاف الإصدار: 8094 (V17) و8084 (V16). وهذه قيم افتراضية يمكن تغييرها عبر سجل Windows (Registry)؛ لذا فبدلًا من القول إن «Mikro غيّرت المنفذ من 8084 إلى 8094»، فالأصح أن يقال: «8084 هو منفذ V16 الافتراضي، و8094 هو منفذ V17 الافتراضي». وإذا كنت قد خصّصت هذا المنفذ في بيئتك، فاضبط عناوين الاستدعاء تبعًا لذلك.

4) الاختبار: مجموعة Postman الرسمية

قبل كتابة الكود، تحقق من الاستدعاءات يدويًا. نزّل حزمة Postman Collection (V17) الرسمية من Mikro، وشغّل نقاط النهاية التي حددتها في الجرد باستخدام بيانات اعتمادك. ثم قارن الاستجابات المتوقعة بمخرجات SQL الحالية، ولا تنتقل إلى بيئة الإنتاج حتى يتحقق التطابق حقلًا حقلًا. وفي هذه المرحلة، قناة الدعم الفني الرسمية هي العنوان [email protected]، ويُخصَّص العنوان [email protected] للأسئلة المتعلقة بمفتاح API أو بجانب الشركاء.

5) التشغيل المتوازي وخطة التراجع

هذه هي الخطوة التي تقلل المخاطر إلى أدنى حد: شغّل التدفق الجديد القائم على API إلى جانب تدفق SQL القديم. ودَع المسارين ينتجان البيانات نفسها (قراءةً وكتابةً) لفترة محددة، وقارن النتائج تلقائيًا، وهي عملية المطابقة (Reconciliation). فإذا لم يظهر أي اختلاف، ازدادت الثقة. وخلال هذه الفترة، أبقِ خطة التراجع (Rollback) جاهزة: ينبغي أن تتمكن بمفتاح تفعيل الميزات (Feature Flag) من العودة إلى التدفق القديم بنقرة واحدة. وهذا النهج القائم على التشغيل المتوازي والتراجع ليس تعليمات من Mikro، بل هو شبكة الأمان المعيارية للتكامل التي نوصي بها.

6) الانتقال النهائي (Cutover) وقرار الإصدار

عندما تأتي نتائج المقارنة نظيفة، نفّذ الانتقال النهائي: انقل حركة الكتابة إلى API، وحوّل مسار SQL إلى وضع المراقبة للقراءة فقط، ثم أوقفه تمامًا. ثبّت واجهة API على إصدار معروف، وأعد تشغيل مجموعة اختبارات الانحدار (Regression) في Postman مع كل تحديث لواجهة Mikro Desktop API، فنشاط سجل التغييرات يدل على أن التغييرات الصامتة واردة.

تنبيه واحد: العبارة القائلة إن نظام Mikro ERP يتطلب «V17 أو أعلى» لاستخدام API هي عبارة لم نجدها حرفيًا في الصفحة الرئيسية أو الأدلة الرسمية على apidocs، بل وردت في صفحة لدى مزوّد تكامل من جهة خارجية (Ovo Yazılım). ولا نقدّم هذا المتطلب بوصفه صادرًا عن مصدر رسمي، ونوصي بالتحقق منه عبر المتصفح في بيئتك الخاصة.

التوقيت: ما التواريخ المتداولة بشأن V16؟

بالنسبة إلى الفرق التي تريد ربط الترحيل بجدول زمني، يتردد تاريخان كثيرًا. لكننا لم نتمكن من تأكيدهما من مصدر أولي لدى Mikro، إذ كانت صفحات الإعلانات الرسمية مغلقة أمام الوصول الآلي. وتستند التواريخ التالية إلى مدونة أحد مزوّدي التكامل التي تقتبس إعلان Mikro (ozgurguler.net)، وإلى سجلات شكاوى المستهلكين؛ أي إنها يجب التحقق منها عبر المتصفح من صفحة الإعلانات الرسمية لدى Mikro قبل النشر:

  • 15 أكتوبر 2025 — الموعد النهائي للتجديد (عمليات التجديد): وفقًا للعبارة المنقولة، ستتم جميع عمليات التجديد بعد هذا التاريخ عبر V17 فقط. وهذا ليس النهاية الكاملة للدعم، بل هو الموعد النهائي للتجديد لا غير.
  • 15 أكتوبر 2026 — النهاية الكاملة للدعم: وفقًا لإعلان ذُكر أنه مؤرخ في 29 سبتمبر 2025، ستنتهي تمامًا بالنسبة إلى V16 في هذا التاريخ تحديثات الإصدار والتحديثات التنظيمية، والتطوير الجديد، ودعم العملاء، وترخيص المستخدمين الإضافيين والوحدات والحلول القطاعية. وهذه محطة منفصلة تأتي بعد عام واحد من الموعد النهائي للتجديد، فلا تخلط بين التاريخين.

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

أخطاء شائعة

  • تخطي الجرد: افتراض أن «واجهة API ستوفر كل شيء على أي حال». فبعض الحقول لا تتوفر إلا باسمها في قاعدة البيانات، وبعضها يتطلب تقديم طلب جدول جديد. والجرد الناقص يعني مفاجآت في بيئة الإنتاج.
  • الظن بأن OAuth هو نموذج المصادقة: النموذج هو مفتاح API + تسجيل الدخول/الجلسة، وكلمة المرور تُحسب بالصيغة MD5 Hash (التاريخ + كلمة المرور). وتطبيقات العميل (Clients) المبنية بمنطق رموز Bearer تصطدم بخطأ «Geçersiz api key» وبأخطاء الجلسات.
  • افتراض رقم المنفذ: يتوقع القادمون من V16 المنفذ 8084، بينما المنفذ الافتراضي في V17 هو 8094، وقد يكون قد غُيّر عبر السجل. فبدلًا من كتابة منفذ ثابت في الكود، اجعله قابلًا للضبط.
  • عدم تثبيت الإصدار: تتطور واجهة API باستمرار. ومن دون تثبيت الإصدار، يحمل كل تحديث خطر انحدار صامت.
  • الظن بأن أدوات الجهات الخارجية رسمية: بعض أدوات الاختبار والتثبيت المساعدة المتداولة في المجتمع التقني (مثل أداة يسميها أحد المدوّنين «تطبيق الاختبار المجاني الذي طوّرته») ليست من منتجات Mikro الرسمية. والأداة الرسمية للاختبار هي مجموعة Postman المنشورة من Mikro نفسها.
  • الانتقال النهائي دون فترة تشغيل متوازٍ: التبديل المباشر دون مطابقة وخطة تراجع لا يكشف تناقضات البيانات إلا عبر شكاوى العملاء.

كيف تساعدك Partnerfy

بصفتنا شركة هندسة برمجيات مقرها صقاريا، ندير عمليات ترحيل ERP هذه لا بوصفها «وعدًا» بل بوصفها عملية قابلة للتكرار: نبدأ بجرد تبعيات SQL الحالية لديك على مستوى الحقول، ثم نبني طبقة تكامل API (الطلب، والمصادقة، وربط نقاط النهاية)، ثم نختبر بمجموعة Postman الرسمية، ونشغّل بالتوازي مع المطابقة، وننفذ انتقالًا نهائيًا مُحكمًا. وإذا كانت تدفقات CRM/ERP المتصلة بنظام Mikro لديك في جانب التجارة الإلكترونية أو برمجيات الويب المخصصة، فإننا نصمم هذه الطبقة ونتولى صيانتها من فريق واحد يتحمل مسؤوليتها كاملة.

ملاحظة صريحة: لا يستطيع أي مزوّد تكامل أن يضمن أن نظامًا يستخدم واجهة API الخاصة بالمورّد سيبقى بمنأى عن كل تغيير مستقبلي في الإصدارات، ولهذا نبني تصميمًا يتحمل التغيير، ويعتمد إصدارًا مثبتًا، ويتمتع بقابلية المراقبة (Observability). ويمكنك كذلك النظر من زاوية مختلفة في مدى ملاءمة الاستثمار في نظام ERP/CRM مصمَّم لشركتك: هل تناسبك برمجيات ERP/CRM المصممة خصيصًا لشركتك؟

الخلاصة

مع V17، أصبحت واجهة Mikro Desktop API الرسمية القناة الأساسية والمدعومة للتكاملات، وصارت البنى المتجذرة في SQL المباشر هشّة وخارج نطاق الدعم. لكن القول إن «كل وصول إلى قاعدة البيانات قد أُغلق» خاطئ، إذ يبقى استثناء موثّق بالاسم في قاعدة البيانات للحقول التي لا تعرضها الواجهة. والخطوة الصحيحة هي إعداد جرد على مستوى الحقول، وتقديم طلب الوصول إلى واجهة API الرسمية، والاختبار عبر Postman، والتشغيل بالتوازي قبل انتقال نهائي مُحكم تحميه شبكة أمان للتراجع. وتحقق من تاريخي 15 أكتوبر 2025 و15 أكتوبر 2026 المتداولين من إعلان Mikro الرسمي، ولا تترك الترحيل إلى الموعد النهائي. وإذا أردت تخطيط هذا الترحيل أو إسناده إلينا، تواصل معنا؛ وسنستخرج تبعيات SQL لديك ونقترح خطة لنقلها إلى API مخصصة لك.

المصادر

الأسئلة الشائعة

هل أُغلق كل وصول مباشر إلى قاعدة البيانات فعلًا في Mikro V17؟

لا، فالقول إن «كل شيء قد أُغلق» غير دقيق. أصبحت واجهة API الرسمية الآن القناة الأساسية والمدعومة، لكن الأسئلة الشائعة لدى Mikro نفسها تذكر أن حقول الجداول غير الظاهرة في JSON الخاص بواجهة API يمكن استخدامها مباشرةً بأسمائها في قاعدة البيانات. أما عبارة «أُغلق الوصول إلى قاعدة البيانات بالكامل» فليست جملة رسمية من Mikro، بل تفسير من مزوّدي التكامل.

كيف أتقدم بطلب الوصول إلى Mikro API، وكيف أحصل على مفتاح API؟

تتقدم بالطلب عبر نموذج طلب Program API على موقع الشركة (mikro.com.tr). ووفقًا للدليل الرسمي، تُخصَّص مفاتيح API تلقائيًا لمن يستخدمون حلًا قطاعيًا (Vertical Solution)، أما البرمجيات الداخلية فيصدر لها ترخيص يدوي. وتُقدَّم طلبات الجداول أو نقاط النهاية الجديدة عبر النموذج نفسه. ويُخصَّص العنوان الرسمي [email protected] للأسئلة التقنية، والعنوان الرسمي [email protected] لكل ما يتعلق بالمفتاح (API Key).

هل تستخدم واجهة Mikro Desktop API بروتوكول OAuth؟ وكيف تعمل المصادقة؟

لا، فهي لا تعتمد على بروتوكول OAuth في المصادقة. يقوم النموذج على مفتاح API + الجلسة/تسجيل الدخول: يرسل كل طلب ApiKey (في جسم JSON) وFirmaKodu وCalismaYili وKullaniciKodu وSifre، وتُحسب كلمة المرور بالصيغة «MD5 Hash (التاريخ + كلمة المرور)». وتستخدم طرق V1 جلسة APILogin، أما طرق V2/V3 فترسل المعلومات مباشرة في كل نقطة نهاية، وتسجّل الخروج تلقائيًا فور اكتمال العملية.

ما المنفذ الذي تستخدمه واجهة Mikro API؟

يختلف المنفذ الافتراضي للخدمة باختلاف الإصدار: 8094 (V17) و8084 (V16). وهذه قيم افتراضية يمكن تغييرها عبر regedit (بإيقاف الخدمة واستخدام Decimal Base)، ويجب عند تغيير المنفذ فتحه في جدار الحماية الخاص بنظام Windows (Windows Firewall). لذلك، اجعل المنفذ قابلًا للضبط في تطبيق العميل لديك بدلًا من كتابته بصورة ثابتة في الكود.

متى ينتهي دعم V16؟ وبحلول متى ينبغي أن أنفذ الترحيل؟

يتردد تاريخان في مصادر مزوّدي التكامل: 15 أكتوبر 2025 (اقتصار عمليات التجديد على V17) و15 أكتوبر 2026 (الانتهاء الكامل لتحديثات الإصدار والتحديثات التنظيمية والدعم والترخيص بالنسبة إلى V16). ولم نتمكن من تأكيد هذين التاريخين من مصدر أولي لدى Mikro؛ لذا تحقق منهما عبر mikro.com.tr/duyurular قبل النشر. وفي كل الأحوال، فإن إتمام الترحيل قبل الموعد النهائي بوقت طويل هو الخيار الأكثر أمانًا.

لماذا تُفضَّل أفضل شركة برمجيات في صقاريا (Sakarya) في تكامل Mikro V17 API؟

تُعد Partnerfy شركة هندسة برمجيات تعمل بنموذج B2B (بين الشركات) وWhite-Label، ويقع مقرها الرئيسي في أدابازاري (Adapazarı) بولاية صقاريا (Sakarya)، ولها مكاتب في تركيا وألمانيا وروسيا وأيرلندا. وهي تدير ترحيل Mikro V17 بوصفه عملية قابلة للتكرار: جرد SQL على مستوى الحقول، وتقديم طلب الوصول إلى واجهة API الرسمية وإعداد المصادقة، والاختبار عبر Postman، والتشغيل المتوازي مع المطابقة (Reconciliation)، ثم الانتقال النهائي المُحكم (Cutover). وهي لا تبيع إحصاءات مختلقة أو ضمانات، بل تبني تكاملًا بإصدار مثبّت وقابل للمراقبة، ولذلك تُعد من الشركات المفضلة في تكاملات التجارة الإلكترونية والبرمجيات المخصصة والمحاسبة.