تخصيص ERPNext للامتثال في الإمارات العربية المتحدة والمملكة العربية السعودية

1. الأطر القانونية والتنظيمية

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

1.1 معايير المحاسبة وإعداد التقارير المالية

1. الإمارات العربية المتحدة: جميع الشركات في دولة الإمارات مطالبة قانونًا باتباع معايير المحاسبة الدولية لإعداد التقارير المالية (IFRS) في بياناتها المالية[1]. يفرض قانون الشركات التجارية الإماراتي (القانون الاتحادي رقم 2 لعام 2015) الالتزام بـ IFRS للتقارير المالية للأغراض العامة[1]. يمكن للكيانات الصغيرة والمتوسطة استخدام معيار IFRS المبسط للشركات الصغيرة والمتوسطة إذا كانت مؤهلة (الإيرادات ≤ 50 مليون درهم إماراتي)[2]. وقد تم تعزيز هذه المتطلبات من خلال قانون الضريبة على الشركات الجديد لعام 2023، الذي نص صراحة على أن IFRS هو الإطار المحاسبي المقبول لأغراض الضرائب[2]. عمليًا، يعني ذلك أن تطبيق ERPNext في دولة الإمارات يجب أن يدعم مخططات الحسابات والتقارير المالية المتوافقة مع IFRS. ينبغي أن تتماشى جميع السياسات المحاسبية الهامة (مثل الاستحقاق، والاستهلاك، والاعتراف بالإيرادات، وما إلى ذلك) مع معايير IFRS لضمان الامتثال.
2. المملكة العربية السعودية: اعتمدت المملكة العربية السعودية IFRS مع بعض التعديلات المحلية. يجب على جميع الكيانات ذات المسؤولية العامة في المملكة استخدام "معايير IFRS كما أقرها SOCPA"، الهيئة السعودية للمحاسبين القانونيين[3]. تتضمن المعايير التي أقرها SOCPA جميع معايير IFRS الصادرة عن مجلس معايير المحاسبة الدولية IASB، مع متطلبات إفصاح إضافية للزكاة وغيرها من القضايا المحلية[3]. يسمح (وفي بعض الحالات يُطلب) من الشركات الصغيرة استخدام معيار IFRS للشركات الصغيرة والمتوسطة[3]. بناءً عليه، يجب أيضًا تكوين ERPNext في المملكة العربية السعودية ليتوافق مع المعايير المحاسبية IFRS. علاوة على ذلك، أضافت SOCPA بعض الإفصاحات (مثل حساب الزكاة) التي لا تغطيها معايير IFRS. [3]، يجب على نظام ERP تسجيل هذه العناصر والإبلاغ عنها. قد تتبع الكيانات الحكومية أو العامة في المملكة العربية السعودية IPSAS (معايير المحاسبة الدولية للقطاع العام) للمحاسبة على أساس الاستحقاق، ولكن إذا تم استخدام ERPNext، فسيكون من الضروري مواءمته مع IFRS كأساس (مع التعديلات اللازمة للمحاسبة بالصناديق).
3. متطلبات التدقيق: كلا البلدين يفرضان بموجب القانون إجراء تدقيق مالي سنوي لمعظم الشركات. في دولة الإمارات، يفرض قانون الشركات التجارية وقانون مهنة التدقيق أن تكون القوائم المالية للشركات مدققة من قبل مدقق مسجل[1][1]. في المملكة العربية السعودية، يتطلب قانون الشركات أيضًا من الشركات الاحتفاظ بحسابات سليمة والخضوع لتدقيق سنوي من قبل مدققين مرخصين (خصوصًا في شركات المسؤولية المحدودة وشركات المساهمة). يجب أن يسهل ERPNext هذا من خلال الاحتفاظ بسجلات معاملات مفصلة، ودعم سجلات التدقيق، وإنتاج تقارير قياسية (دفاتر الأستاذ العامة، ميزان المراجعة، القوائم المالية) التي يمكن للمراجعين الاطلاع عليها. كما ينبغي أن يدعم النظام المحاسبة متعددة العملات (مثل المعاملات بالدولار الأمريكي مع دفاتر بالعملة المحلية مثل الدرهم الإماراتي أو الريال السعودي) وفقًا لما تسمح به معايير IFRS.

1.2 الضرائب: ضريبة القيمة المضافة، ضريبة الشركات، والزكاة

1. ضريبة القيمة المضافة في الإمارات: تفرض دولة الإمارات ضريبة القيمة المضافة بنسبة 5% على معظم السلع والخدمات بموجب المرسوم بقانون اتحادي رقم 8 لعام 2017[4]. تنطبق ضريبة القيمة المضافة على توريد السلع/الخدمات في كل مرحلة من سلسلة التوريد، مع بعض الإعفاءات والتوريدات ذات السعر الصفري (مثل الصادرات وبعض خدمات الرعاية الصحية). وبموجب القانون، يجب إصدار "فاتورة ضريبية" للتوريدات الخاضعة للضريبة، تحتوي على رقم تسجيل الضريبة للمورد، تاريخ الفاتورة، رقم الفاتورة الفريد، مبلغ الضريبة ونسبتها، وغيرها من التفاصيل المطلوبة بموجب قانون ضريبة القيمة المضافة ولوائحه التنفيذية[4]. كما تسمح لوائح ضريبة القيمة المضافة في الإمارات بإصدار فواتير مبسطة للمبيعات الصغيرة (مثل المبيعات التي تقل عن 10,000 درهم إماراتي)، وتطلب إصدار إشعارات دائن للتعديلات. يجب تكوين ERPNext لإصدار فواتير متوافقة مع ضريبة القيمة المضافة تعرض جميع الحقول المطلوبة. كما ينبغي للنظام الاحتفاظ بحسابات منفصلة لضريبة القيمة المضافة المستحقة (المخرجات) وضريبة القيمة المضافة المدفوعة (المدخلات) لتسهيل تقديم الإقرار الضريبي ربع السنوي (النموذج VAT 201). كما ينبغي أن يدعم النظام محاسبة الضريبة الانتقائية إذا كانت ذات صلة (بالنسبة للشركات التي تتعامل في الكحول أو التبغ أو المشروبات المحلاة، إلخ، التي تخضع لضريبة السلع الانتقائية في الإمارات).
2. ضريبة الشركات في الإمارات: بدءًا من السنوات المالية التي تبدأ في 1 يونيو 2023 أو بعده، أدخلت دولة الإمارات نظام ضريبة الدخل على الشركات (القانون الاتحادي رقم 47 لعام 2022) بنسبة 9% على أرباح الأعمال [5][6]. تطبق نسبة 0% على الدخل الخاضع للضريبة حتى 375,000 درهم إماراتي (لدعم الشركات الصغيرة)[5]. يمكن لشركات المناطق الحرة المؤهلة الاستمرار في الاستفادة من نسبة الضريبة 0% على دخلها المؤهل، لكنها لا تزال مطالبة بالتسجيل وتقديم الإقرارات. يتطلب قانون ضريبة الشركات من الأشخاص الخاضعين للضريبة الاحتفاظ بسجلات محاسبية وبيانات مالية لمدة 7 سنوات بعد الفترة الضريبية ذات الصلة[7][8]. يجب على ERPNext تسهيل حساب الأرباح الخاضعة للضريبة (استنادًا إلى الربح المحاسبي وفقًا لـ IFRS مع بعض التعديلات الضريبية) وربما إنشاء جداول مساعدة لتقديم الإقرار الضريبي. قد يشمل التكوين إعداد حساب ضريبة الشركات المستحقة، وطريقة لتتبع أصول/التزامات الضرائب المؤجلة إذا تطلبت معايير IFRS ذلك. بالنسبة لكيانات المناطق الحرة، يجب أن يتيح النظام فصل مصادر الدخل للتمييز بين الدخل المؤهل وغير المؤهل لأغراض الضريبة، ودعم أي تقارير مطلوبة للجهات التنظيمية في المنطقة الحرة. (تتطلب العديد من المناطق الحرة أيضًا تقديم القوائم المالية المدققة وفقًا لمعايير IFRS سنويًا كجزء من تجديد الترخيص.)
3. ضريبة القيمة المضافة في المملكة العربية السعودية: أدخلت المملكة العربية السعودية ضريبة القيمة المضافة في عام 2018 بنسبة 5%، ولكن في عام 2020 تمت زيادة نسبة ضريبة القيمة المضافة إلى 15%[9]. يتشابه قانون ضريبة القيمة المضافة في المملكة ولوائحه التنفيذية (الصادرة عن هيئة الزكاة والضريبة والجمارك حاليًا) مع العديد من أحكام إطار ضريبة القيمة المضافة الخليجي. يجب على الشركات إصدار فواتير ضريبية باللغة العربية (على الأقل باللغتين) وتضمين رقم التسجيل الضريبي، وتاريخ الفاتورة (التاريخ الميلادي إلزامي)، ورقم الفاتورة التسلسلي، ومبلغ الضريبة ونسبتها، وبالنسبة للفواتير التي تتجاوز مبلغًا معينًا، تفاصيل المشتري[10][11]. يجب على ERPNext في المملكة العربية السعودية التعامل مع حسابات ضريبة القيمة المضافة بنسبة 15%، والتمييز بين التوريدات الخاضعة لنسبة 0% والمعفاة، وإنتاج الإقرار الضريبي (يتضمن النموذج حقولًا لإجمالي المبيعات، والمبيعات الخاضعة للضريبة، والواردات، وغيرها). ينبغي للنظام أيضًا دعم تسجيل ضريبة الاستقطاع، إذ تفرض المملكة ضريبة استقطاع على بعض المدفوعات للمقيمين خارج المملكة (بنسب تتراوح من 5% إلى 20% اعتمادًا على طبيعة الدفع). [9]). بالإضافة إلى ذلك، اعتبارًا من عام 2023، قد يتطلب الامتثال لضريبة القيمة المضافة على الخدمات الرقمية والتجارة الإلكترونية اهتمامًا خاصًا (مثل قواعد الفوترة الإلكترونية في المملكة العربية السعودية، المذكورة أدناه).
4. الزكاة (السعودية): الزكاة هي ضريبة دينية على الثروة تطبق في المملكة العربية السعودية على الشركات المملوكة للسعوديين ومواطني دول مجلس التعاون الخليجي. يتم تحصيلها بنسبة 2.5% من وعاء الزكاة السنوي[12]. يمثل وعاء الزكاة تقريبًا صافي قيمة أصول الشركة، وفقًا لقواعد هيئة الزكاة والضريبة والجمارك (تضاف الأرباح المحتجزة وبعض الاحتياطيات والأصول طويلة الأجل أو تعدل). إذا كان للشركة ملكية أجنبية، يخضع الجزء الأجنبي لضريبة الدخل على الشركات (بنسبة 20% من الأرباح الصافية) بينما يخضع الجزء السعودي للزكاة – ويجب على نظام ERP استيعاب كلا الحسابين في مثل هذه الحالات. يجب على جميع الشركات تقديم إقرار سنوي إلى هيئة الزكاة والضريبة والجمارك – إما إقرار زكاة للكيانات المملوكة بالكامل لسعوديين/خليجيين أو إقراري زكاة وضريبة للشركات ذات الملكية المختلطة[12]. ينبغي تهيئة ERPNext لحساب وعاء الزكاة (الذي قد يتطلب سحب أرصدة الأصول والخصوم في نهاية السنة وإجراء تعديلات محددة). على سبيل المثال، قد تُضاف الحسابات المستحقة للمساهمين والقروض طويلة الأجل إلى حقوق الملكية لأغراض الزكاة، وقد تُخصم الأصول الثابتة المحتفظ بها لأكثر من سنة – يمكن بناء هذه القواعد في بيان مالي مخصص أو عبر كود مخصص. علاوة على ذلك، نظرًا لأن SOCPA يطلب الإفصاح عن الزكاة في البيانات المالية[3]، يمكن أن يتضمن مخطط الحسابات حسابات مخصصة لمصروفات الزكاة ومخصص الزكاة.
5. الفواتير الضريبية والفوترة الإلكترونية (السعودية): اعتبارًا من ديسمبر 2021، تفرض المملكة العربية السعودية الفوترة الإلكترونية (“فاتورة”) على جميع المكلفين. تتطلب المرحلة الأولى من الشركات إصدار فواتير ضريبية عبر نظام إلكتروني يمكنه إنشاء فاتورة متوافقة مع رمز الاستجابة السريعة (QR) (للفواتير المبسطة) وتخزين الفواتير إلكترونيًا. تتطلب المرحلة الثانية، التي يتم تنفيذها تدريجيًا، التكامل مع أنظمة هيئة الزكاة والضريبة والجمارك للتحقق الفوري أو تقديم تقارير الفواتير[13][13]. تشمل النقاط الأساسية للامتثال: يجب أن تكون الفواتير باللغة العربية (مع إمكانية الازدواجية اللغوية) وأن تحتوي على رمز الاستجابة السريعة الذي يشفّر اسم البائع، ورقم التسجيل الضريبي، والتاريخ والوقت، وإجمالي الفاتورة مع الضريبة (للفواتير المبسطة)، بالإضافة إلى ختم تشفيري ورمز UUID فريد لكل فاتورة في المرحلة الثانية[14]. أيضًا، لا يمكن تحرير الفواتير أو حذفها – يجب إجراء أي تعديلات عبر إشعارات دائن/مدين، ويجب على النظام الاحتفاظ بسجلات غير قابلة للتلاعب. تعني هذه المتطلبات القانونية أن ERPNext يحتاج إلى تخصيص كبير للمملكة العربية السعودية:
6. بالنسبة للمرحلة الأولى، تأكد من أن تنسيق طباعة فاتورة المبيعات يتضمن جميع الحقول المطلوبة باللغتين العربية والإنجليزية وإنشاء رمز الاستجابة السريعة وفقًا لمواصفات هيئة الزكاة والضريبة والجمارك. (توفر الهيئة مواصفات رمز الاستجابة السريعة بصيغة base64 TLV وتشمل خمسة حقول – اسم البائع، رقم الضريبة، الوقت، إجمالي الفاتورة، وإجمالي الضريبة).
7. بالنسبة للمرحلة الثانية، قم بتنفيذ التوقيع الرقمي للفواتير والتكامل مع واجهات برمجة التطبيقات (API) الخاصة بهيئة الزكاة والضريبة والجمارك. يفرض القانون السعودي إنشاء فاتورة XML بصيغة UBL 2.1 مع توقيعات رقمية XML (XAdES)، ثم الحصول على ختم تشفيري من الهيئة للتحقق. [15][15]. يجب أن يكون نظام ERP قادرًا على إنتاج ملف XML، وتوقيعه باستخدام المفتاح الخاص بالشركة (باستخدام شهادة رقمية صادرة عن ZATCA)، وإرساله عبر واجهة برمجة التطبيقات (API) للمصادقة. يجب تخزين الرد من ZATCA (الفاتورة المصدق عليها مع رقم المصادقة الفريد والتوقيع المُثبت) في النظام. يجب أن تتم كل هذه العمليات بسرعة (من الناحية المثالية، في الوقت الفعلي عند تقديم الفاتورة). هذه متطلبات قانونية صارمة لممارسة الأعمال في المملكة العربية السعودية، لذا يجب على أي شركة تستخدم ERPNext هناك الالتزام بها لتجنب العقوبات.
8. المناطق الحرة والأقاليم الخاصة: في الإمارات العربية المتحدة، تخضع شركات المناطق الحرة عادةً لضريبة القيمة المضافة (إلا إذا كانت المنطقة الحرة مصنفة كمنطقة محددة لأغراض ضريبة القيمة المضافة حيث يمكن اعتبار بعض التوريدات خارج نطاق ضريبة القيمة المضافة في الدولة). يجب أن يسمح ERPNext بتكوين قواعد الضرائب الخاصة بحالات المناطق الحرة – مثلًا، قد تكون المبيعات داخل نفس المنطقة المحددة غير خاضعة للضريبة، لكن المبيعات إلى الإمارات الأم (البر الرئيسي) خاضعة للضريبة. بالإضافة إلى ذلك، غالبًا ما تطلب السلطات في المناطق الحرة من الشركات تقديم حسابات مدققة؛ لذا يجب أن يكون ERPNext قادرًا على إنتاج البيانات المالية وفقًا لمعايير IFRS لذلك. في السعودية، لا توجد مناطق خالية من ضريبة القيمة المضافة (باستثناء بعض الحوافز الخاصة بالمدن الاقتصادية)، ولكن بدأت تظهر مناطق اقتصادية خاصة (قد تحتوي على قواعد ضريبية مختلفة). يجب أن يكون تكوين الضرائب في النظام مرنًا لاستيعاب مثل هذه المناطق أو التغييرات المستقبلية (مثلًا، الإمارات تُدخل أيضًا ضريبة شركات بنسبة 9%، ولكن 0% للعديد من مداخيل المناطق الحرة – لذا يجب أن يدعم ERPNext تتبع الدخل حسب المصدر لتطبيق المعالجة الضريبية الصحيحة).

1.3 الرواتب، قانون العمل، والامتثال للموارد البشرية

1. قانون العمل الإماراتي (القطاع الخاص): يحكم قانون العمل الإماراتي (المرسوم بقانون اتحادي رقم 33 لعام 2021، ساري المفعول من فبراير 2022) شروط التوظيف، وساعات العمل، والإجازات المستحقة، وإنهاء الخدمة، ومكافأة نهاية الخدمة[16][16]. تشمل الأحكام الرئيسية التي يجب تنفيذها في وحدة الموارد البشرية في ERPNext:
2. ساعات العمل والعمل الإضافي: ساعات العمل العادية عادةً 8 ساعات يوميًا (48 ساعة في الأسبوع) ما لم يُنص على خلاف ذلك. يُسمح بالعمل الإضافي في حدود معينة (بحد أقصى ساعتين إضافيتين يوميًا في العديد من الحالات) ويجب تعويضه بأجر إضافي (125% من الأجر العادي للعمل الإضافي نهارًا، و150% لساعات الليل المتأخرة أو أيام الراحة) وفقًا للقانون. يمكن استخدام ميزتي الحضور وسجل الدوام في ERPNext لتتبع ساعات العمل، ويمكن للبرمجة المخصصة حساب أجر العمل الإضافي على قسائم الراتب وفقًا لهذه القواعد.
3. الإجازة السنوية: يحق للموظفين 30 يومًا تقويميًا من الإجازة السنوية مدفوعة الأجر لكل سنة (بعد إتمام سنة خدمة). بالنسبة للأعوام الجزئية، تُكتسب الإجازة بمعدل يومين على الأقل شهريًا[17][18]. يجب أن تُخصص وحدة تخصيص الإجازات في النظام 30 يومًا سنويًا، ويجب أن تضمن تطبيق الإجازة عدم تجاوز الرصيد. يمكن ضبط أي تفاصيل خاصة بالإمارات (مثل حدود الترحيل أو صرف الإجازة) من خلال سياسات الإجازات.
4. الإجازات الأخرى: أدخل القانون الإماراتي الجديد عدة أنواع من الإجازات: مثلًا إجازة الأمومة (60 يومًا إجمالًا، وفقًا للتعديلات، مع 45 يومًا بأجر كامل و15 يومًا بنصف أجر)، إجازة الوالدين (5 أيام)، إجازة الوفاة (الحداد)، إجازة الدراسة (10 أيام للموظفين ذوي الخدمة الطويلة)[18]. يمكن أن يحتوي ERPNext على أنواع إجازات منفصلة لكل نوع وتتبع الاستخدام، ويجب ضبطها وفقًا للحد الأدنى في القانون.
5. مكافأة نهاية الخدمة (EOSB): بدلًا من نظام التقاعد للوافدين، يفرض القانون الإماراتي دفع مكافأة نهاية الخدمة عند إنهاء العقد (باستثناء حالات الفصل لأسباب تأديبية). الصيغة القياسية: 21 يومًا من الأجر الأساسي عن كل سنة خدمة خلال أول 5 سنوات، و30 يومًا عن كل سنة بعد ذلك[19]. (يُحدد الحد الأقصى للمكافأة بسنتين من الراتب). لا يحسب ERPNext ذلك افتراضيًا، لذا يلزم استخدام برمجية مخصصة أو تقرير مخصص لحساب المكافأة وفقًا لراتب الموظف ومدة خدمته. يجب أن يأخذ الحساب في الاعتبار حالات الاستقالة: وفقًا للقانون الجديد، يحصل الموظف على المكافأة كاملة حتى لو استقال (كان القانون السابق يقلل الاستحقاق قبل 5 سنوات، لكن تم إلغاء هذا التمييز[18] – تُدفع المكافأة كاملة طالما أكمل الموظف سنة خدمة واحدة على الأقل). يجب أن يعكس تنفيذ ERPNext آخر تحديثات القانون (المكافأة كاملة بعد سنة خدمة، لا تُستحق لمن خدم أقل من سنة).
6. أنواع العقود وإنهاء الخدمة: جميع العقود الآن عقود محددة المدة (قابلة للتجديد) تصل إلى 3 سنوات[18]. يجب أن تسجل مستندات الموظفين في ERPNext تواريخ بدء ونهاية العقد، ويمكن إعداد تنبيه (عبر سير العمل أو الإشعارات) لانتهاء العقد. يجب تنفيذ سير العمل لإنهاء الخدمة والاستقالة: مثلًا، إذا استقال موظف، يجب على الموارد البشرية تسجيل آخر يوم عمل وبدء عملية التسوية النهائية (المكافأة، صرف الإجازات غير المستخدمة، وغيرها) – يمكن لـ ERPNext أتمتة أجزاء من ذلك عبر سير العمل للفصل.
7. نظام حماية الأجور (WPS): نظام حماية الأجور في الإمارات هو نظام تحويل الرواتب إلكترونيًا لضمان دفعها في الوقت المحدد. يجب على أصحاب العمل دفع جميع الرواتب عبر التحويلات المصرفية أو مكاتب الصرافة، وإنتاج ملف WPS (SIF – ملف معلومات الراتب) في كل دورة رواتب. حددت الوزارة (MOHRE) والمصرف المركزي تنسيق ملف .SIF (ملف نصي بطول ثابت أو مفصول بالتقسيمات يحتوي على بيانات الشركة والموظفين وأرقام IBAN والرواتب وغيرها). يفرض القانون الإماراتي استخدام WPS لجميع شركات البر الرئيسي والعديد من شركات المناطق الحرة؛ وعدم الامتثال يمكن أن يؤدي إلى غرامات أو حظر تصاريح العمل الجديدة. [20][20]. يجب توسيع وحدة الرواتب في ERPNext لإخراج هذا الملف: يجب التقاط جميع الحقول الضرورية (رقم تعريف الموظف الفريد – مثل بطاقة العمل أو رقم الهوية الإماراتية، رقم IBAN للموظف، رموز البنوك، مبلغ الراتب، إلخ). يمكن لبرمجية مخصصة أو تنسيق طباعة مخصص (لأنه إخراج نصي) توليد ملف SIF. لحسن الحظ، معظم البيانات موجودة في قسيمة الراتب ومستندات الموظف؛ وكما أشار أحد مقترحات المجتمع: “مع جميع الحقول في مستند الموظف وقسيمة الراتب، البيانات موجودة بالفعل… يمكننا توليد [ملف WPS .sif]”[21][21]. في الواقع، تمت إضافة مساهمة لبناء امتداد مفتوح المصدر لإنتاج ملف WPS الإماراتي من ERPNext[21]. يمكننا استخدام هذا الحل أو تكييفه. باختصار، يجب أن يتيح ERPNext للموارد البشرية توليد ملف WPS البنكي كل شهر لرفعه إلى البنك/وزارة الموارد البشرية، مع الحد الأدنى من التدخل اليدوي.
8. سجلات الموظفين والمستندات: يفرض القانون الإماراتي الاحتفاظ بالعديد من مستندات الموظفين. على سبيل المثال، يجب تخزين نسخ من جوازات السفر، التأشيرات، بطاقات الهوية الإماراتية، عقود العمل، وغيرها. يمكن استخدام قسم مرفقات الموظف أو مستندات الملفات في ERPNext للاحتفاظ بالمسوحات الضوئية لهذه المستندات. من الحكمة إضافة حقول مخصصة لتفاصيل مثل رقم التأشيرة، تاريخ انتهاء التأشيرة، الهوية الإماراتية، رقم بطاقة العمل، تاريخ انتهاء التأمين الصحي وغيرها[21] بحيث يمكن تتبعها وضبط التذكيرات. يمكن للنظام إرسال تنبيهات بريد إلكتروني تلقائية للموارد البشرية أو الموظف قبل X يومًا من انتهاء صلاحية التأشيرة أو الهوية (باستخدام الإشعارات التي تعتمد على حقل تاريخ المستند).
9. حفظ السجلات: بموجب قانون العمل الجديد، يجب الاحتفاظ بسجلات التوظيف لمدة لا تقل عن سنتين بعد إنهاء الموظف[18]. هذا يعني أنه يجب على ERPNext عدم حذف سجلات الموظفين السابقين أو بيانات الرواتب لمدة لا تقل عن هذه الفترة. بدلاً من ذلك، يجب تنفيذ حالة “أرشيف” للموظفين الذين غادروا، ولكن تبقى بياناتهم قابلة للبحث لمدة سنتين. علاوة على ذلك، يجب تخزين سجلات الرواتب وملفات WPS ونسخها احتياطيًا. (من منظور النظام، يكفي ضمان أن تغطي قاعدة البيانات أو النسخ الاحتياطية هذه الفترة؛ من منظور السياسة، يُنصح بعدم حذف أي بيانات للموارد البشرية قبل مرور سنتين.)
10. قانون العمل السعودي: ينص نظام العمل السعودي (المرسوم الملكي رقم م/51، بصيغته المعدلة) على مبادئ مشابهة مع بعض الاختلافات:
11. ساعات العمل: عمومًا 8 ساعات يوميًا أو 48 ساعة أسبوعيًا كحد أقصى في الأيام العادية. خلال شهر رمضان للموظفين المسلمين، تُخفض الساعات إلى 6 ساعات يوميًا. يتم دفع العمل الإضافي بنسبة 150% من الأجر العادي (أو أكثر إذا وافق صاحب العمل) للساعات الإضافية أو العمل في أيام الراحة/العطلات الرسمية. يجب أن تعكس قواعد تتبع الوقت والرواتب في ERPNext هذه المعدلات.
12. الإجازة السنوية: يحق للموظفين السعوديين 21 يومًا من الإجازة السنوية مدفوعة الأجر في السنة، وتزيد إلى 30 يومًا بعد 5 سنوات من الخدمة[22]. ينص القانون بوضوح على “ألا تقل عن 21 يومًا… ولا تقل عن 30 يومًا لمن تجاوزت خدمته 5 سنوات”. [22]. في ERPNext، يمكن تكوين تخصيص مبدئي للإجازة لمدة 21 يومًا، ثم إضافة قاعدة (عبر برمجية مخصصة صغيرة) لزيادة الاستحقاق إلى 30 يومًا بمجرد أن تتجاوز مدة خدمة الموظف خمس سنوات. يجب توثيق جميع الإجازات – حيث ينبغي للنظام تتبع الإجازات المأخوذة والرصيد المتبقي. في حالة إنهاء الخدمة، يجب دفع ثمن الإجازات غير المستخدمة عادةً، ويمكن للنظام حساب ذلك بضرب الأيام غير المستخدمة في الأجر اليومي.
13. الإجازة المرضية والإجازات الأخرى: يمنح القانون السعودي 120 يومًا من الإجازة المرضية (الأيام الـ30 الأولى بأجر كامل، والـ60 التالية بأجر 75%، والباقي بدون أجر)، وإجازة الأمومة (10 أسابيع؛ 50 يومًا بأجر كامل للطفل الأول، إلخ)، وإجازات أخرى مثل الزواج أو الوفاة وفقًا لسياسة الشركة. يمكن إدارة هذه الإجازات من خلال تكوين أنواع إجازات مختلفة، وربما مكونات راتب مخصصة للتمييز بين الأجزاء المدفوعة وغير المدفوعة.
14. مكافأة نهاية الخدمة: تفرض السعودية مكافأة نهاية خدمة مماثلة لما هو موجود في الإمارات، ولكن قواعد الاستقالة تختلف. الصيغة القياسية (لإنهاء الخدمة أو انتهاء العقد بشكل طبيعي) هي نصف شهر أجر عن كل سنة من السنوات الخمس الأولى، وشهر أجر عن كل سنة إضافية[19]، ويعتمد ذلك على آخر أجر للموظف. هذا هو الاستحقاق الكامل إذا أنهى صاحب العمل خدمة الموظف أو انتهى العقد بشكل طبيعي. إذا استقال الموظف، يقيّد القانون السعودي الاستحقاق: لا تُدفع مكافأة نهاية خدمة إذا كانت مدة الخدمة أقل من سنتين؛ تُدفع ثلث المكافأة إذا كانت من سنتين إلى 5 سنوات؛ تُدفع ثلثا المكافأة إذا كانت من 5 إلى 10 سنوات؛ وتُدفع كاملة إذا تجاوزت 10 سنوات[19]. يجب تخصيص وحدة الإجازات والرواتب في ERPNext لحساب المكافأة وفقًا لهذه السيناريوهات. أحد الأساليب هو إنشاء سكريبت خادم يعمل عند فصل الموظف، ليحسب المبلغ المستحق بناءً على مدة الخدمة وسبب المغادرة، ثم يولّد إدخال الرواتب للتسوية النهائية متضمنًا هذا المبلغ. يمكن ترميز الصيغة مباشرةً من نص القانون[19][19]. هذا يضمن الامتثال لقانون العمل السعودي ويسهّل معالجة خروج الموظفين.
15. نظام حماية الأجور (WPS): تطبّق السعودية أيضًا نظام حماية الأجور لتحويل الرواتب. يجب على الشركات رفع ملف الرواتب الإلكتروني إلى بوابة وزارة الموارد البشرية (MHRSD) شهريًا، عبر البنك الخاص بصاحب العمل. تنسيق ملف WPS في السعودية (وفقًا لمواصفات الوزارة الفنية) هو ملف نصي ثابت (TXT) مشابه لنظام الإمارات، ويحتوي على الهوية الوطنية لكل موظف، رقم IBAN البنكي، الراتب، البدلات، الخصومات، إلخ[23][24]. يجب استخدام بيانات الرواتب في ERPNext لتوليد هذا الملف. يمكن تنفيذ ذلك على غرار طريقة SIF الإماراتية، مع تعديلات تتوافق مع أي اختلافات في التنسيق (مثلًا، قد يتطلب الملف السعودي إدخال رقم الإقامة كرقم تعريف الموظف، إلخ). عبر تخصيص تقرير أو بناء أداة صغيرة في ERPNext، يمكن للمستخدم اختيار فترة الرواتب وتصدير ملف WPS. الامتثال مهم جدًا: اعتبارًا من 2025، شددت السلطات السعودية على تطبيق WPS (مع ضرورة رفع الملف خلال 30 يومًا من تاريخ استحقاق الراتب)[25]. يجب أن يساعد ERPNext عبر إرسال تنبيه إذا تأخر رفع ملف WPS.
16. بيانات الموظفين واللغة: تنص لوائح العمل السعودية على أن اللغة العربية هي اللغة الرسمية لجميع سجلات التوظيف والعقود والمستندات[26][27]. بينما تُستخدم الوثائق الثنائية اللغة عادةً في الممارسة العملية، في حال نشوء أي نزاع، يُعتد بالنص العربي. لذا، يجب أن تكون جميع خطابات الموارد البشرية، العقود، قسائم الرواتب، إلخ، مكتوبة بالعربية أو مزدوجة اللغة. بالنسبة لـ ERPNext، هذا يعني تكوين تنسيقات طباعة لهذه المستندات بالعربية. يمكن استخدام الترجمة المدمجة في النظام لتوفير التسميات العربية، لكن قد يتعين تخزين القيم مثل اسم الموظف وبنود العقد بالعربية. من الناحية القانونية، يجب أيضًا على الشركات الاحتفاظ بسجل للموظفين السعوديين وغير السعوديين لتتبع السعودة (التوطين) – يمكن لـ ERPNext المساعدة في ذلك من خلال التقاط الجنسية لكل موظف وربما إنتاج تقرير نسبة السعودة.
17. حفظ السجلات: يُطلب من أصحاب العمل في السعودية الاحتفاظ بسجلات التوظيف (مثل سجلات الرواتب، سجلات الموظفين، إلخ) لعدة سنوات – وأفضل ممارسة هي 5–6 سنوات. في الواقع، يفرض قانون الضرائب/ضريبة القيمة المضافة في السعودية الاحتفاظ بالسجلات المحاسبية لمدة 6 سنوات (انظر حفظ السجلات أدناه)، وقد تطلع تفتيشات العمل على سجلات الرواتب حتى 5 سنوات ماضية. لذا، وبشكل مماثل للإمارات، لا تُحذف بيانات الموارد البشرية. كما يجب على صاحب العمل الاحتفاظ ببعض السجلات في مكان العمل (مثل سجل استبدال العمالة الوافدة بسعوديين، وفقًا للمادة 17). [11] وعرض جداول العمل علنًا[11]. هذه أمور تشغيلية: لا يمكن لـ ERPNext فرض عرض جدول مادي، ولكن يمكنه توليد الجدول كملف PDF باللغة العربية للطباعة.
18. الاعتبارات الحكومية وقطاع القطاع العام: إذا تم تطبيق النظام للجهات الحكومية أو شبه الحكومية، فقد يتطلب الأمر الامتثال لإجراءات المشتريات العامة (قواعد المناقصات)، المحاسبة على أساس الموازنة، واتباع القواعد الخاصة بالموارد البشرية في الدولة (مثل درجات الخدمة المدنية). على سبيل المثال، تتبع الجهات الاتحادية في الإمارات قانون الموارد البشرية الاتحادي، وغالبًا ما يكون لديها جداول درجات ومزايا تختلف عن قانون العمل في القطاع الخاص (رغم تشابه العديد من المبادئ). في السعودية، قد تتبع الجهات الحكومية نظام الخدمة المدنية بدلاً من قانون العمل. هذه التفاصيل تتجاوز نطاق ERPNext القياسي، ولكن قد يلزم تخصيص مستندات مثل سير عمل الموافقات على الميزانية، محاسبة الالتزامات أو سلالم الرواتب حسب الدرجات لتوفير حل شامل حقيقي للقطاع العام. بالإضافة إلى ذلك، غالبًا ما تتطلب الجهات الحكومية تقارير ثنائية اللغة (عربي/إنجليزي) وقد تحتاج إلى توحيد الحسابات وفقًا لمعايير IPSAS (إذا كانت تعتمد المحاسبة على أساس الاستحقاق). سيكون من المفيد التأكد من أن ERPNext يدعم المحاسبة على أساس الصناديق أو التقارير حسب الأقسام/المشاريع في هذه الحالات.

1.4 حفظ السجلات والأرشفة والالتزامات بالتدقيق

لدى الإمارات والسعودية قوانين تحدد مدة احتفاظ الشركات بسجلات الحسابات والسجلات الأخرى، مما يؤثر مباشرةً على سياسات الاحتفاظ بالبيانات في ERPNext:

1. مدة الاحتفاظ بالسجلات المحاسبية: ينص قانون الإجراءات الضريبية الإماراتي ولوائح ضريبة القيمة المضافة على وجوب الاحتفاظ بجميع السجلات الضريبية (الفواتير، دفاتر الأستاذ، إلخ) لمدة 5 سنوات بعد نهاية الفترة الضريبية ذات الصلة[28]. لبعض السجلات مثل العقارات، تصل المدة إلى 15 سنة. وفي الوقت نفسه، ينص قانون ضريبة الشركات الإماراتي الجديد صراحةً على 7 سنوات للاحتفاظ بالسجلات المحاسبية والمستندات من نهاية الفترة المالية ذات الصلة[7]. للامتثال، يجب على ERPNext الاحتفاظ بالبيانات المتعلقة بالمعاملات (فواتير المبيعات، فواتير الشراء، قيود اليومية، سجلات الرواتب) لمدة لا تقل عن 7 سنوات. هذا يعني ضرورة تعطيل أي برمجيات أرشفة أو حذف للبيانات الأحدث من هذه المدة. كما يجب تكوين سياسات النسخ الاحتياطي في النظام للاحتفاظ بنسخ أرشيفية طويلة الأجل (مثل نسخ احتياطية سنوية محفوظة خارج الموقع) تحسبًا لعمليات التدقيق.
2. في السعودية، تطلب هيئة الزكاة والضريبة والجمارك (ZATCA) من دافعي الضرائب الاحتفاظ بسجلات ضريبة القيمة المضافة والزكاة لمدة لا تقل عن 6 سنوات بعد السنة الضريبية[29][30]. يجب أن تكون جميع الدفاتر والفواتير (بما في ذلك الفواتير الإلكترونية) والمستندات ذات الصلة متاحة للتدقيق خلال تلك الفترة. بالإضافة إلى ذلك، يجب تخزين السجلات الإلكترونية باللغة العربية وداخل المملكة العربية السعودية أو الوصول إليها من داخل المملكة[10]. وهذا له آثار على نشر النظام: ينبغي على الشركات السعودية استضافة نظام ERPNext على خادم داخل المملكة (أو على الأقل ضمان وجود نسخة بيانات في الوقت الفعلي داخل السعودية) للامتثال لقواعد إقامة البيانات الخاصة بالفوترة الإلكترونية. عمليًا، يوصى باستخدام موفري السحابة أو الاستضافة المحلية في السعودية (مثل مراكز البيانات في الرياض أو جدة)[31]. حتى إن شركاء ERPNext في المنطقة (مثل ERPGulf) يقدمون الاستضافة المحلية لأن “القانون يفرض أن تكون خوادم ERP داخل المنطقة الجغرافية” في السعودية وبعض دول الخليج الأخرى. [31]. يجب علينا التخطيط لذلك: التأكد من أن المستخدم إذا اختار نشر النظام على السحابة، فيجب أن يكون على خادم داخل السعودية، أو إذا كان مُستضافًا ذاتيًا، فيجب أن يكون الخادم فعليًا داخل المملكة.
3. سجلات التدقيق: تتوقع كلا الدولتين من الشركات الحفاظ على سجلات تدقيق مناسبة. يفرض القانون الإماراتي (وكذلك ممارسات الحوكمة الرشيدة) أن تكون أي تعديلات أو إدخالات قابلة للتتبع. تطلب اللوائح السعودية الخاصة بالفوترة الإلكترونية سجلات غير قابلة للتلاعب لجميع الفواتير (لكل فاتورة تجزئة فريدة وأي محاولة تعديل يجب تسجيلها). لدى ERPNext بالفعل سجلات نسخ تاريخية لتعديلات المستندات؛ يجب التأكد من تفعيل هذه السجلات لجميع المستندات المالية وعدم حذفها. كما يُعد تفعيل المصادقة الثنائية وإعدادات التحكم في الوصول الصحيحة في ERPNext من أفضل ممارسات الامتثال لمنع التغييرات غير المصرح بها.
4. تنسيقات المستندات واللغة: كما ذُكر، غالبًا ما يُشترط أن تكون المستندات القانونية باللغة العربية (خاصة في السعودية). ينص شرط اللغة الرسمية في نظام العمل السعودي (المادة 9) على أن تكون عقود العمل والسجلات والمراسلات باللغة العربية؛ وأي نص بلغة أجنبية هو للسهولة فقط، وتسود العربية في حال النزاع[26][27]. بالمثل، تشترط القوانين التجارية السعودية والمحاكم عادةً أن تكون المستندات باللغة العربية عند التقديم الرسمي. في الإمارات، العربية هي اللغة الرسمية للقوانين الاتحادية والمحاكم، ولكن الإنجليزية شائعة في الأعمال؛ ومع ذلك، يجب أن تكون المستندات الموجهة للجهات الحكومية (مثل تقارير التدقيق المقدمة للوزارات، عقود العمل المرسلة عبر وزارة الموارد البشرية، إلخ) مكتوبة بالعربية أو ثنائية اللغة. في ERPNext، هذا يعني ضرورة تعديل جميع تنسيقات الطباعة القياسية للفواتير، أوامر الشراء، قسائم الرواتب، إلخ، لتكون قوالب ثنائية اللغة. يجب تضمين تسميات الحقول باللغة العربية، وربما القيم المترجمة (مثل أسماء المنتجات أو العملاء) حيثما أمكن. على سبيل المثال، يجب أن تحتوي فاتورة ضريبية في السعودية على “فاتورة ضريبية” و “Tax Invoice” كعنوان، وتظهر الحقول مثل اسم العميل، العنوان، إلخ، باللغة العربية. قد يتطلب ذلك تخزين نسخة عربية من البيانات الرئيسية (مثل أسماء العملاء والعناصر) في حقول مخصصة، ما لم يدخلها المستخدم مباشرةً بالصيغة الثنائية.
5. المحتوى الإلزامي للمستندات: بعض المستندات لها محتوى إلزامي قانونيًا:
6. يجب أن تتضمن الفواتير في الإمارات والسعودية رقم تسجيل الضريبة (TRN في الإمارات، رقم ضريبة القيمة المضافة في السعودية) للبائع (وفي السعودية، للمشتري في الفواتير بين الشركات). لدى ERPNext حقل رقم الضريبة للشركات بالفعل؛ تأكد من تعبئته وطباعته[32].
7. يجب أن تُشير الملاحظات الدائنة (لإرجاع البضائع أو الخصومات) إلى رقم الفاتورة الأصلية وتاريخها. يجب على ERPNext فرض ربط الملاحظة الدائنة بالفاتورة (ربما باستخدام خانة Return والربط بالأصل).
8. للجهات الحكومية أو المناطق الحرة، قد تُطلب تنسيقات معينة: مثلًا، في الإمارات، قد تطلب وزارة الموارد البشرية من الشركات الكبيرة تقرير التوطين (قائمة المواطنين الإماراتيين العاملين وتفاصيلهم) – يجب أن يكون لدى وحدة الموارد البشرية في النظام القدرة على إنتاج هذا التقرير (مع عامل تصفية الجنسية).
9. غالبًا ما يتعين على الشركات الخاضعة لـالتدقيق الإلزامي إنتاج تنسيقات محددة لـميزان المراجعة، دفتر الأستاذ، وشهادات الأرصدة. يجب التحقق من أن تقارير ERPNext القياسية تفي بإرشادات وزارة الاقتصاد أو هيئة الزكاة (مثلًا، تطلب ZATCA ترقيمًا متسلسلًا للفواتير بدون فجوات، لذا يجب تكوين سلسلة التسمية في ERPNext لتكون غير قابلة للتعديل ومتسلسلة بشكل مستمر).
10. التدقيق والوصول التنظيمي: جانب آخر من جوانب الامتثال هو الاستعداد للتدقيق أو التفتيش. في الإمارات، يمكن للهيئة الاتحادية للضرائب أو وزارة المالية إجراء عمليات تدقيق وتوقع من دافع الضرائب توفير السجلات بصيغة مفهومة. في السعودية، يمكن للهيئة (ZATCA) طلب البيانات أو حتى إجراء تدقيق إلكتروني (قد تطلب أرشيفات XML للفوترة الإلكترونية). يجب أن يتيح النظام تصدير البيانات بسهولة – مثل تصدير جميع الإدخالات لسنة معينة إلى Excel أو CSV للمراجع. ضمان ملفات PDF قابلة للقراءة باستخدام OCR أو تنسيق موحد للفواتير (PDF/A-3 مع ملف XML مضمن كما هو مطلوب في السعودية[14]) هو جزء من الامتثال أيضًا. تنص لوائح الفوترة الإلكترونية في ZATCA على تنسيق الأرشيف: يجب حفظ الفواتير بتنسيق PDF/A-3 مع ملف XML مضمن، ولفترة 6 سنوات. يجب تكوين ERPNext لإنتاج ملفات PDF/A-3 (قد يتطلب الأمر خطوة توليد PDF مخصصة باستخدام مكتبة تدعم معايير PDF/A) وإرفاق XML به. هذا مطلب تقني مهم منصوص عليه في القانون، ولكنه حاسم للشركات الكبرى في المرحلة الثانية من الفوترة الإلكترونية.

باختصار، يفرض الإطار القانوني في الإمارات والسعودية العديد من احتياجات تكوين ERPNext: هيكل محاسبي قائم على IFRS، معالجة ضريبة القيمة المضافة/الزكاة، نظام رواتب قوي مع WPS وحسابات نهاية الخدمة، إخراج مستندات ثنائية اللغة، وميزات قوية للاحتفاظ بالسجلات وسجلات التدقيق. بعد ذلك، نناقش الحلول مفتوحة المصدر الحالية التي تلبي هذه المتطلبات، والتي يمكننا الاستفادة منها أو استلهام الأفكار منها.

2. مراجع مفتوحة المصدر للامتثال في الخليج

لتجنب إعادة اختراع العجلة، من الحكمة دراسة التخصيصات أو الوحدات المحلية مفتوحة المصدر التي تعالج بالفعل متطلبات الامتثال في الإمارات/السعودية. فيما يلي نسلط الضوء على المشاريع والميزات ذات الصلة من المجتمع:

1. التخصيصات المدمجة لـ ERPNext في دول مجلس التعاون: قدم ERPNext نفسه دعمًا أساسيًا للإمارات والسعودية عندما بدأت هذه الدول في تطبيق ضريبة القيمة المضافة. على سبيل المثال، كان ERPNext الإصدار 10 (صدر حوالي 2017) “جاهزًا لضريبة القيمة المضافة في السعودية/الإمارات” مباشرة من الصندوق، ما أتاح إصدار فواتير متوافقة مع الضريبة بتنسيقات مبسطة ومفصلة كما يقتضيه القانون. [32]. شمل ذلك طباعة الفواتير مع التفاصيل الضريبية المطلوبة ويفترض أنه يمكن تكوين معدلات الضريبة 5٪ (التي أصبحت 15٪ الآن في السعودية). كما أضاف ERPNext إعدادات إقليمية لهذه الدول: النظام يحتوي على دليل حسابات الإمارات الجاهز (يتوافق مع معايير IFRS وفئات الهيئة الاتحادية للضرائب) ودليل حسابات السعودية. عند إنشاء شركة جديدة في تلك الدول، يمكن لـ ERPNext تثبيت هذه الأدلة. من المفيد استخدامها كنقطة انطلاق، لأنها غالبًا ما تتضمن حسابات أساسية مثل ضريبة المخرجات، ضريبة المدخلات، الزكاة، وغيرها.
2. الوحدة الإقليمية للإمارات في ERPNext: أضاف القائمون على الصيانة حقولًا خاصة في DocType لتلبية متطلبات الإمارات. توثق مستندات ERPNext حقول "الإمارات الإقليمية"، التي تتضمن:
3. في سجل الأصناف: خانة اختيار "الصنف خاضع لضريبة الصفر" (لتحديد الأصناف الخاضعة لمعدل الصفر)[33].
4. في فواتير المبيعات والمشتريات: حقول لرقم التسجيل الضريبي TRN الخاص بالعميل/المورد، وربما حقول لتمييز توريدات المناطق المحددة. تساعد هذه الحقول على إعداد إقرارات الضريبة بشكل صحيح (مثل نموذج الإقرار الضريبي 201 الإماراتي الذي يحتوي على خانات منفصلة للمعاملات القياسية والخاضعة للصفر والمعفاة والواردات).
5. تؤكد مستندات ERPNext الرسمية أن هناك تقرير ضريبة القيمة المضافة الإماراتية 201 مدمج[34][34]. يجمع هذا التقرير البيانات اللازمة لتقديم الإقرار (VAT201) – على الأرجح يعرض ضريبة المخرجات والمدخلات والمبيعات الخاضعة للصفر وغيرها خلال فترة معينة. يتيح استخدام التوطين الإماراتي في ERPNext إنتاج هذا التقرير بدون تطوير مخصص. يجب التأكد من توافقه مع أحدث نموذج للهيئة الاتحادية للضرائب، لكنه يعتبر أساسًا متينًا لأنه جزء من النظام.
6. ضريبة القيمة المضافة والزكاة في السعودية عبر ERPNext: بشكل مشابه، أضاف ERPNext وحدة "إدارة وإعداد تقارير ضريبة القيمة المضافة السعودية"[34]. من المحتمل أن يوفر هذا التقرير ما يعادل نموذج إقرار ضريبة السعودية، وقد يتضمن ميزات للتعامل مع الزكاة. (الزكاة ليست ضريبة معاملات، لذا قد لا تظهر في العمليات اليومية؛ ومع ذلك، يمكن لتوسيع القوائم المالية في ERPNext حساب وعاء الزكاة أو توفير الأرصدة اللازمة لحسابها.) كما شارك المجتمع نصوصًا لحساب الزكاة وفق الصيغة القياسية (أساسًا 2.5٪ من صافي الأصول بعد خصومات معينة). قد نجد هذه النصوص في المنتديات أو GitHub. على الأقل، يتضمن دليل الحسابات للسعودية (متوفر عبر وحدة l10n_sa في Odoo وبشكل مشابه في ERPNext) حسابات مثل "مخصص زكاة" و"مصروف زكاة" التي توضح كيفية معالجة الزكاة – عادةً كاقتطاع من الأرباح المحتجزة أو مصروف قابل للخصم وفقًا لسياسة الشركة.
7. حلول الفوترة الإلكترونية مفتوحة المصدر (تكامل مع ZATCA): هذا مجال تطوير كبير نظرًا لأنظمة السعودية. أنشأ العديد من شركاء ERPNext تطبيقات للامتثال مع ZATCA:
8. تطبيق ZATCA من ERPGulf: أصدرت شركة ERPGulf تطبيقًا مفتوح المصدر لـالمرحلة الثانية من الفوترة الإلكترونية على GitHub. يوصف بأنه "تطبيق للفوترة الإلكترونية في السعودية" بموجب ترخيص MIT[15]. يعالج هذا التطبيق:
9. إصدار الفاتورة بصيغة XML بالصيغة المطلوبة (UBL 2.1) مع جميع بيانات الفاتورة[15].
10. حساب تجزئة التشفير (digest) للفاتورة والتوقيع الرقمي باستخدام معايير XAdES[15].
11. تضمين الشهادة الرقمية الخاصة بالشركة والتوقيع داخل ملف XML (وفقًا لإرشادات ZATCA)[15].
12. الاتصال بواجهة برمجة تطبيقات ZATCA لإرسال الفاتورة واستلام الاستجابة بالموافقة أو التقرير (بما في ذلك UUID/CSID الفريد الذي يجب تضمينه في الفاتورة النهائية)[15].
13. تخزين الفاتورة المعتمدة وتوفير رمز QR مع الختم التشفيري.
14. يذكر ملف README الخاص بالمستودع خطوات مثل إنشاء XML بصيغة UBL، توقيع XAdES، والاتصال بواجهة ZATCA[15][15] – وهي أساسًا مخطط لما يجب تنفيذه. يمكننا إعادة استخدام هذا التطبيق أو منطقه لتوفير الوقت. كما لوحظ وجود إصدار محدث (لتوجيهات 2024)[15]، مما يشير إلى أن الحل يتطور مع متطلبات ZATCA.
15. التطبيق المحسن من ERPGulf (zatca_erpgulf): مستودع آخر من ERPGulf (قد يكون نفس التطبيق محدثًا) يسرد ميزات مثل "التكامل مع واجهة ZATCA للمعالجة والتقارير"، "إنشاء طلبات CSR (توقيع الشهادات) تلقائيًا والتحقق من الامتثال"، "إدارة الرموز الآمنة"، "تقديم الفواتير واسترجاع رموز QR"، وسجلات التدقيق[35]. يدعم إصدارات ERPNext من v13 حتى v15[35]. تغطي قائمة الميزات كل ما يحتاجه النشاط التجاري للامتثال:
16. الامتثال الكامل للمرحلة الثانية (توقيع رقمي وتأكيد الموافقة).
17. معالجة ملاحظات الدائن/المدين أيضًا (نظرًا لأن هذه يجب الإبلاغ عنها أيضًا).
18. لوحة تحكم أو تقارير لمطابقة الفواتير في ERPNext مع ما تم الإبلاغ عنه إلى ZATCA (مهم جدًا للتدقيق)[35].
19. من المحتمل أن يتم تثبيت هذا التطبيق مباشرةً (عبر bench) نظرًا لأنه مفتوح المصدر. إنه يوفر بداية قوية جدًا للامتثال في السعودية. بدلًا من بناء تكامل مخصص من الصفر، يمكننا تفرع هذا التطبيق وتكييفه مع بيئتنا. كما يعتبر مرجعًا جيدًا لفهم كيفية هيكلة التكامل.
20. حل شركة Beveren: شريك آخر لـ ERPNext، Beveren، لديه حل ZATCA (رغم أنه قد يكون مغلق المصدر). نشروا مقالًا على Medium (2024) يصف تكاملهم ERPNext ZATCA Phase 2. [14]. يبرزون ميزات مثل أكثر من 150 فحص تحقق، الموافقة الفورية مع ZATCA، وتخزين البيانات على خوادم السعودية[14]. بشكل ملحوظ، يذكرون فواتير PDF/A-3 تتضمن XML مدمج، يحتوي على UUID وتجزئة الفاتورة ورمز QR والتوقيع الرقمي[14] – مما يؤكد أن ERPNext الخاص بهم يمكنه إنتاج فواتير إلكترونية متوافقة تمامًا. رغم أن الشفرة غير عامة، فإن وصفهم يؤكد النهج الذي نحتاجه. كما يبرزون أرشفة الفواتير لمدة 6 سنوات على السحابة وأمان ضد التلاعب[14][14]، مما يتوافق مع المتطلبات القانونية. الخلاصة من مقال Beveren هي أهمية:
21. فحوصات التحقق الصارمة للبيانات (مثلًا، يجب أن تكون أرقام ضريبة القيمة المضافة للعملاء 15 رقمًا، ويجب أن تتضمن العناوين رقم المبنى والحي كما تطلب ZATCA، وإلا سيتم رفض الفاتورة).
22. سير عمل سهل الاستخدام: يجب ألا يضطر المستخدم للتوقيع أو رفع الفواتير يدويًا – النظام يجب أن يتعامل معها ويبلغ فقط ما إذا تمت الموافقة على الفاتورة أو حدث خطأ.
23. دعم الشركات المتعددة: إذا كان هناك أكثر من شركة تستخدم نفس نظام ERPNext، يجب أن يدعم التكامل بيانات اعتماد واجهة API وشهادات متعددة[14].
24. يمكننا دمج هذه النقاط عند بناء حلنا – ربما عن طريق إنشاء DocType باسم "إعدادات ZATCA" في ERPNext لتخزين تفاصيل ضريبة القيمة المضافة لكل شركة وشهاداتها وبيانات واجهة API الخاصة بها، كما هو مفترض في هذه التطبيقات.
25. التوطين في Odoo (للرجوع إليه): نظام Odoo، وهو ERP مفتوح المصدر آخر، لديه وحدات رسمية مخصصة للسعودية يمكننا الاستفادة منها كمرجع. توضح وثائق Odoo 18.0 أنهم يوفرون وحدات l10n_sa (المحاسبة)، l10n_sa_edi (الفوترة الإلكترونية)، وl10n_sa_pos[13][13]. تطبق وحدة الفوترة الإلكترونية في Odoo متطلبات ZATCA وتوجه المستخدمين لاستخدام بوابة محاكاة فاتورة للاختبار[13][13]. من المقتطفات المهمة في وثائق Odoo:
26. يتطلبون تعبئة حقول العنوان التفصيلية مثل رقم المبنى ورقم القطعة للشركات[13]، وهو متطلب ZATCA للفواتير. لذا يجب علينا إضافة هذه الحقول في قالب العنوان في ERPNext للسعودية (وتظهر في الفاتورة المطبوعة).
27. يسمحون باختيار نظام التعريف (مثل السجل التجاري، إلخ.) للشركة وإدخال رقمه[13] – قد يُستخدم ذلك لملء <BuyerIdentifier> في XML للفواتير الإلكترونية.
28. لديهم وضع "محاكاة" لاختبار الفواتير على بيئة ZATCA التجريبية[13]، وهو ذكي. يمكننا تنفيذ وضع محاكاة في ERPNext أيضًا (تُوفر ZATCA واجهة API خاصة بذلك).
29. من المحتمل أن تشمل توطينات Odoo أيضًا وحدات الرواتب السعودية (للتعامل مع GOSI ونظام حماية الأجور WPS). تذكر مدونات المجتمع (مثل Technaureus) أن Odoo يغطي حساب GOSI وملف WPS أساسي. حتى لو لم نستخدم Odoo، تؤكد تجربتهم أهمية ذلك: مثلًا، تحديد مساهمة GOSI كعنصر في كشف الرواتب: في السعودية، يدفع صاحب العمل 12٪ والموظف 10٪ من الراتب لـ GOSI للمواطنين (وللوافدين نسبة أصغر للتأمين ضد المخاطر المهنية). يمكن إعداد ذلك بسهولة في قواعد الرواتب في ERPNext (هيكل الرواتب)، لكنه شيء يجب تذكره.
30. أدوات نظام حماية الأجور (WPS): بالنسبة للإمارات، ذُكر مساهمة مفتوحة المصدر على المنتدى (بواسطة المستخدم Zubaer) نفذت إنشاء ملف WPS[21]. قيل إنهم أنشأوا "وحدة رواتب منفصلة تولد ملف WPS". يجب علينا البحث في متجر تطبيقات Frappe أو GitHub عن "wps" – ربما يوجد مستودع (مثل "erpnext_wps" أو ما شابه). حتى لو لم يكن متاحًا علنًا، فإن تطوير مُصدّر WPS أمر بسيط نظرًا لأن الصيغة موثقة من قبل المصرف المركزي ووزارة الموارد البشرية. بعض الشركات أيضًا أصدرت حلول WPS مفتوحة المصدر؛ على سبيل المثال، ذُكرت نصوص Oracle PeopleSoft أو SAP التي تمت مشاركتها في المنتديات. [36]. لأغراضنا، يمكننا استخدام المواصفات (مثل ملف PDF من hrsd.gov.sa لنظام حماية الأجور السعودي[23]، أو إرشادات وزارة الموارد البشرية والتوطين في الإمارات) لرسم حقول ERPNext مع المخرجات المطلوبة.
31. إذا كان هناك مكتبة مفتوحة بلغة Python لـ SIF، يمكننا دمجها، ولكن من المحتمل أنها مخصصة. بدلًا من ذلك، سنقوم ببناء برنامج Python داخل ERPNext لتوليد الملف عند اكتمال الرواتب في قسم الموارد البشرية.
32. مشاريع التوطين للموارد البشرية: بعض المشاريع التي يقودها المجتمع تستهدف احتياجات الموارد البشرية في الخليج. على سبيل المثال، قد نجد إضافة “الموارد البشرية بالعربية” أو تفرعًا من ERPNext يحتوي على ميزات لقوانين العمل في الخليج. حتى الآن، معظمها في المنتديات وليس في مستودع مركزي. ومع ذلك، هناك مشروع يسمى Frappe HR (تطبيق مستقل رسميًا) قد يضم ميزات موارد بشرية إضافية. يجب علينا التحقق مما إذا كان لدى Frappe HR (بواسطة الفريق الأساسي) أي دعم خاص بالمنطقة مثل قواعد مكافأة نهاية الخدمة القابلة للتخصيص أو صيغ الرواتب الأكثر مرونة. إذا كانت الإجابة نعم، فإن تبني Frappe HR في تطبيقنا يمكن أن يوفر ميزات موارد بشرية متقدمة تتجاوز ERPNext الافتراضي.
33. مكتبات / واجهات برمجة التطبيقات للامتثال الخارجي: فئة أخرى من الموارد مفتوحة المصدر: مكتبات لخدمات محلية. على سبيل المثال:
34. توليد رمز QR الخاص بـ ZATCA – في وقت سابق، شارك المطورون شفرة لتوليد رمز QR بتنسيق base64 TLV للمرحلة الأولى. هذه مقتطفات صغيرة لكنها منتشرة بشكل واسع على Stack Overflow وGitHub Gists. يمكننا إعادة استخدام مثل هذا المقتطف في تنسيق الطباعة المخصص لدينا لضمان طباعة الرمز على الفاتورة بشكل صحيح.
35. التعامل مع النصوص العربية – لدى Python مكتبات مثل python-bidi وreportlab يمكنها المساعدة في تنسيق النص من اليمين لليسار في ملفات PDF. إذا احتجنا لتوليد ملفات PDF ثنائية اللغة مع محاذاة صحيحة، فقد يكون من الضروري الاستفادة من مثل هذه المكتبات عبر سكريبتات الخادم (على الرغم من أن محرك PDF في Frappe المسمى wkhtmltopdf يمكنه التعامل مع العربية إذا تم إعداد html/css باستخدام dir="rtl" وخط عربي).
36. التحقق من صحة IBAN – كلا البلدين يستخدمان IBAN لحسابات البنوك. من الممكن دمج أداة تحقق من صحة IBAN (توجد مكتبات Python مفتوحة المصدر لذلك). يمكن أن يساعد ذلك في التأكد من صحة IBAN المدخل لموظفي الرواتب (لنظام WPS) أو لحسابات البنوك الخاصة بالشركة (للمدفوعات) والتقاط الأخطاء مبكرًا.
37. قاعدة معارف المجتمع: منتديات ERPNext ومجموعات Telegram لمنطقة الشرق الأوسط تعتبر مصادر غنية بحلول محددة. على سبيل المثال، المواضيع المتعلقة بـإدارة الشيكات المؤجلة في الإمارات أو حساب مكافأة نهاية الخدمة في الكويت غالبًا ما تنطبق أيضًا على الإمارات / السعودية مع بعض التعديلات. من الحكمة البحث عن هذه المراجع والاحتفاظ بها. يشير الويبينار الخاص بـ “تحقيق التوطين الإماراتي” على YouTube[37] بواسطة عضو في المجتمع إلى أن الكثير من هذه الميزات قد نوقشت وربما تمت برمجتها.
38. استفد من ميزات قوالب الضرائب في ERPNext:
39. في شركة الإمارات، أنشئ قالب ضريبة المبيعات (ضريبة القيمة المضافة): بنسبة 5%، الحساب = ضريبة المخرجات. حدده كمتضمن/غير متضمن حسب متطلبات التسعير (عادة غير متضمن). وافعل الأمر نفسه لقالب ضريبة المشتريات (ضريبة القيمة المضافة) بنسبة 5% على المصاريف.
40. في شركة السعودية، القوالب الضريبية بنسبة 15%. أضف أيضًا أي رموز خاصة: مثلًا، قالب ضريبة صفرية (0%) للأصناف الخاضعة لمعدل الصفر (التصدير، إلخ)، وقالب معفى للمبيعات المعفاة (مثل الرعاية الصحية إذا كانت تنطبق).
41. يجب أن تختار الفواتير القالب الصحيح تلقائيًا بناءً على إعدادات الصنف أو العميل. يمكن استخدام قواعد الضرائب: على سبيل المثال، تحديد قاعدة تنص على أنه إذا كان العميل أجنبيًا (خارج مجلس التعاون الخليجي)، تطبق ضريبة 0% (تصدير). أو إذا كان الصنف محددًا بأنه "صنف خاضع لمعدل الصفر"، تطبق 0%. يمكن لنظام قواعد الضرائب المعتمد على الشروط في ERPNext التعامل مع هذا.
42. تأكد من أن رقم التعريف الضريبي (TRN) للشركة محفوظ في سجل الشركة (يحتوي ERPNext على حقل “Tax ID” يمكن إعادة تسميته كما تشاء). أدخل رقم ضريبة القيمة المضافة المكون من 15 رقمًا للسعودية، ورقم TRN للإمارات (عادةً أيضًا 15 رقمًا). عند طباعة الفواتير، ضمن تسمية ورقم التعريف باللغتين.
43. 3.1.4 الفوترة والفوترة الإلكترونية:
44. هذا جزء بالغ الأهمية:
45. تنسيق الفاتورة القياسي: صمم تنسيق طباعة مخصص لفاتورة المبيعات يكون ثنائي اللغة (عربي/إنجليزي). تأكد من تضمين جميع الحقول المطلوبة:
46. عنوان الفاتورة: “فاتورة ضريبية (Tax Invoice)”.
47. اسم البائع، عنوانه، ورقم التعريف الضريبي باللغة العربية والإنجليزية.
48. اسم المشتري وعنوانه. في السعودية، إذا كان المشتري مسجلاً بضريبة القيمة المضافة، يجب أن يظهر رقم التعريف الضريبي الخاص به؛ أضف حقلًا لرقم التعريف الضريبي للعميل في سجل العميل واجلبه إلى الفاتورة.
49. تاريخ الفاتورة بالتقويم الميلادي (ويمكن إضافة التاريخ الهجري إذا رغبت – غير إلزامي لكن بعض الشركات تفضله).
50. رقم فاتورة فريد. (استخدم سلسلة تسمية في ERPNext مثل KSA-{year}-{#####} لضمان الاستمرارية. قم بقفلها بحيث لا يمكن للمستخدمين تعديلها بعد الإرسال للحفاظ على تسلسل الأرقام.)
51. وصف الأصناف – إذا كان جميع العملاء يتحدثون العربية، قد تحتفظ بأسماء الأصناف بالعربية؛ وإلا اعرض اللغتين. يمكنك الاحتفاظ بحقل مخصص "اسم الصنف بالعربية" في DocType الخاص بالصنف للطباعة.
52. الكمية، سعر الوحدة، الإجمالي لكل سطر، وقيمة الضريبة لكل سطر (إذا كان ذلك مطلوبًا في الفاتورة التفصيلية).
53. إجمالي المبلغ بدون ضريبة، الضريبة، والمبلغ الإجمالي شامل الضريبة بالأرقام وبالكلمات (بالإنجليزية والعربية). لا يلزم القانون كتابة المبالغ بالكلمات، لكن من الشائع في المنطقة عرضها.
54. رمز الاستجابة السريعة (QR Code): في السعودية، يجب طباعة رمز QR على الفواتير المبسطة (مثل مبيعات التجزئة النقدية B2C). حتى في B2B، تتطلب المرحلة الثانية رمز QR يحتوي على الختم التشفيري. سنقوم بـ:
55. كتابة سكريبت مخصص لتوليد بيانات QR المشفرة بتنسيق base64 بعد إرسال الفاتورة. في المرحلة الأولى (إذا افترضنا الالتزام الأولي)، يحتوي رمز QR على: اسم البائع، رقم ضريبة البائع، الطابع الزمني، الإجمالي، إجمالي الضريبة (كلها في TLV منظم). في المرحلة الثانية، يحتوي على نسخة مختصرة من الختم التشفيري (عادةً تجزئة الفاتورة وتوقيع ECDSA). يمكننا تنفيذ رمز المرحلة الأولى أولًا (وهو أسهل)، ثم رمز المرحلة الثانية بعد تكامل كامل.
56. إضافة حقل HTML في تنسيق الطباعة مع <img src="data:image/png;base64, {{ qr_image_data }}"> لعرض رمز QR. يمكننا توليد qr_image_data باستخدام طريقة على الخادم (مثل مكتبة qrcode في Python أو عبر API) وتخزينها في حقل مخصص في فاتورة المبيعات عند الإرسال.
57. الشروط والأحكام: إذا كانت هناك ملاحظات إلزامية قانونًا (مثلًا، في الإمارات غالبًا ما تقول الفواتير “شكرًا لتعاملكم معنا” إلخ، لكنها ليست إلزامية؛ في السعودية، مثلًا في الفاتورة المبسطة، يمكن إضافة عبارة “فاتورة مبسطة – غير صالحة للمطالبة بالضريبة من قبل المشتري” كاحتراز).
58. تكامل الفوترة الإلكترونية (المرحلة الثانية السعودية): نوصي بشدة بتثبيت أو تطوير تطبيق Frappe مخصص للتكامل مع ZATCA:
59. فكر في استخدام تطبيق ERPGulf ZATCA مفتوح المصدر[35] . يمكن تثبيته باستخدام bench get-app وفقًا لتعليماتهم[35]. بمجرد تثبيته وترحيله، ستحصل على وحدة جديدة في ERPNext خاصة بـ ZATCA. على الأرجح توفر Doctype باسم ZATCA Settings لتكوين مفاتيح API، وتتكامل مع حدث إرسال فاتورة المبيعات.
60. قم بتكوين إعدادات ZATCA باستخدام شهادة الشركة (تصدر ZATCA شهادة رقمية بعد التسجيل)، وبيانات اعتماد API (client ID/secret لـ API)، ووضع التكامل المختار (الموافقة الفورية مقابل الإبلاغ). بالنسبة للشركات الكبرى، الموافقة الفورية (تأكيد الفاتورة في الوقت الحقيقي) مطلوبة؛ أما الأصغر، فيُسمح لها بالإبلاغ (إرسال دفعة خلال 24 ساعة) – ZATCA تحدد من ينتمي لكل مرحلة.
61. اختبر التكامل في وضع Sandbox: يجب أن يسمح التطبيق أو تكاملنا المخصص بتبديل واجهات API إلى وضع Sandbox. استخدم مفاتيح ZATCA المخصصة للاختبار وجرّب إرسال بعض الفواتير. تحقق من تلقي ERPNext استجابة مع UUID وأن رمز QR الخاص بالفاتورة تم تحديثه ليتوافق مع المتطلبات.
62. عدل سير عمل ERPNext: على الأرجح، بمجرد إرسال فاتورة، سيمنع التطبيق الطباعة حتى تتم الموافقة (لضمان إصدار الفواتير المختومة فقط). إذا استخدمنا تكاملنا الخاص، طبق هذا المنطق: مثلًا، أنشئ حقلًا مخصصًا “حالة الموافقة” (قيد الانتظار، تمت الموافقة، فشل). عند إرسال فاتورة مبيعات، استدعِ دالة Python للقيام بما يلي:
63. توليد UBL XML من الفاتورة (رسم خرائط حقول ERPNext مع هيكل XML).
64. توقيع XML (قد نحتاج لاستخدام مكتبة مثل signxml أو حزمة SDK الخاصة بـ ZATCA المكتوبة بـ Java، أو استخدام subprocess أو API إذا كان متوفرًا).
65. إرساله إلى ZATCA عبر API (باستخدام مكتبة requests).
66. استلام الاستجابة: إذا كانت ناجحة، خزّن UUID ونسخة من XML الموقع كمرفق أو في Doctype. ثم حدد الحالة “تمت الموافقة”.
67. إذا حدث فشل، سجّل الخطأ، حدد الحالة “فشل”، وأبلغ موظفي المالية. يمكن للمستخدم عندها معالجة المشكلة (ربما عنوان مفقود أو ساعة النظام غير متزامنة) ثم إعادة الإرسال عبر زر.
68. تأكد من أن فاتورة PDF النهائية تتضمن الحقول المطلوبة من الاستجابة:
69. يجب عادةً طباعة UUID (تجزئة الفاتورة) (يطبعها البعض كسلسلة hex طويلة على الفاتورة).
70. رمز QR الذي يمثل الآن الفاتورة الموقعة (توضح مواصفات ZATCA أن الرمز يجب أن يشفر على الأقل: اسم البائع، رقم ضريبة القيمة المضافة، الطابع الزمني، الإجمالي، الضريبة، بالإضافة إلى الختم التشفيري أو رابط – في المرحلة الثانية، يشمل الرمز الختم).
71. اختياريًا، يمكن تضمين عبارة مثل “تمت الموافقة بواسطة ZATCA” أو رقم الموافقة على الفاتورة للشفافية.
72. نظرًا لتعقيد هذا الأمر، فإن الاعتماد على التطبيق مفتوح المصدر مفيد. توضح وثائق README الخاصة بالتطبيق أنه يتعامل مع إدارة الشهادات وبيانات اعتماد API[35]، وهو أمر معقد (تتطلب واجهة API الخاصة بـ ZATCA تبادل رموز OAuth2). استخدام حل معتمد من المجتمع يقلل من مخاطر عدم الامتثال.
73. السجلات الإلكترونية والأرشفة: قم بتكوين إرفاق تلقائي لملف PDF عند إرسال الفاتورة. يحتوي ERPNext على ميزة لإرفاق نسخة PDF تلقائيًا عند الإرسال (عبر إعدادات الطباعة). فعل ذلك لأغراض التدقيق. في السعودية، تأكد أن الملف بصيغة PDF/A-3 – إذا كان إخراج wkhtmltopdf ليس PDF/A، قد نحتاج لمحول خارجي أو استخدام مولد PDF مخصص. ربما، بعد استلام XML الموافق عليه، يمكننا تضمينه في بيانات التعريف داخل PDF (هذا متقدم؛ ربما ليس في الإصدار الأول، لكن خطط له). على الأقل، خزّن ملف XML كمرفق للفاتورة لمدة 6 سنوات.
74. الفواتير المتكررة والمسودات: في المناطق الحرة أو العقود الحكومية، يُستخدم أحيانًا إصدار فواتير متكررة. يمكن لـ ERPNext توليد مسودات تلقائيًا. يجب الحرص على تشغيل واجهة ZATCA فقط عند اعتماد الفاتورة (الإرسال). لاحظ أيضًا أن قواعد الفوترة الإلكترونية في السعودية تحظر الحذف – لذا بمجرد إنشاء الفاتورة في ERPNext (حتى كمسودة)، إذا احتجت لإلغائها، استخدم طريقة الإلغاء عبر إشعار دائن بدلًا من الحذف النهائي. قد نطبق قيودًا عبر الصلاحيات بحيث لا يمكن حذف فواتير المبيعات بمجرد حفظها، بل إلغاؤها فقط (لضمان تسلسل الأرقام).
75. 3.1.5 الضرائب والرسوم الأخرى:
76. إذا كانت الشركة تتعامل مع ضريبة الاستقطاع (سيناريو السعودية للخدمات من الخارج)، قد يحتاجون لتسجيل ذلك. يمكننا إضافة ميزة: مثلًا، حقل مخصص في فاتورة الشراء لتحديد ما إذا كانت ضريبة الاستقطاع تنطبق، وبأي نسبة. عند الإرسال، يتم إنشاء قيد يومية تلقائي لخصم حساب مستحقات ضريبة الاستقطاع ومقابلة مصروف أو حساب المورد. لكن قد يكون هذا زائدًا عن الحاجة؛ يمكنهم دائمًا تسجيل قيود يدوية. فقط تأكد أن دليل الحسابات يحتوي على حساب لضريبة الاستقطاع عند الحاجة.
77. بالنسبة لـالضريبة الانتقائية (إذا كان نشاط المستخدم يتطلبها، مثل مستورد التبغ في الإمارات أو السعودية)، سيحتاج ERPNext لوحدة خاصة بالضريبة الانتقائية – وهي معقدة لأنها تشمل حركة المخزون في المستودع. قد تكون خارج نطاقنا إلا إذا طُلبت تحديدًا. نذكرها كتكامل محتمل مع طرف ثالث (بعض الشركات تستخدم حلولًا خارجية للضريبة الانتقائية وتتكامل مع ERPNext عبر القيود).

3.2 التكيف مع الموارد البشرية والرواتب

1. 3.2.1 إعدادات الموارد البشرية الأساسية:
2. قم بإعداد ساعات العمل بشكل صحيح: في ERPNext، حدد وقت العمل الافتراضي (النوبة) كـ 8 ساعات/اليوم، من الأحد إلى الخميس للإمارات (لأن العديد من الشركات في الإمارات الآن تتبع عطلة نهاية أسبوع من الاثنين إلى الجمعة، لكن الحكومة غيرت عطلة نهاية الأسبوع إلى السبت-الأحد في 2022 للقطاع العام؛ القطاع الخاص يمكنه الاختيار). يجب التأكد من ممارسات العميل. في السعودية، أسبوع العمل عادةً من الأحد إلى الخميس. قم بتكوين العطلة الأسبوعية وفقًا لذلك في إعدادات الموارد البشرية.
3. أنشئ قائمة العطلات لكل دولة (العطلات الرسمية). لدى الإمارات حوالي 14 عطلة رسمية (مولد النبي، اليوم الوطني، إلخ – تتغير تواريخها كل عام لأنها تتبع أحيانًا التقويم الهجري). في السعودية حوالي 10 (عيد الفطر، عيد الأضحى، اليوم الوطني). أدخل هذه البيانات لمدة عام أو عامين مقدمًا.
4. 3.2.2 تخصيص Doctype للموظف:
5. أضف حقولًا مخصصة إلى سجل الموظف لالتقاط التفاصيل المحلية:
6. الجنسية (إذا لم يكن موجودًا بالفعل – قد يكون موجودًا، لكن تأكد من توافره للتمييز بين المواطنين والوافدين).
7. رقم جواز السفر، تاريخ انتهاء جواز السفر.
8. رقم تأشيرة الإقامة، تاريخ انتهاء التأشيرة (أو تفاصيل تصريح العمل). بالنسبة للسعودية، رقم الإقامة وتاريخ انتهائها.
9. رقم بطاقة العمل/تصريح العمل (للإمارات – وزارة الموارد البشرية).
10. أرقام التأمينات الاجتماعية: مثلًا، في السعودية رقم GOSI؛ في الإمارات للموظفين الإماراتيين، رقم GPSSA (المعاشات).
11. رقم WPS الفريد: في الإمارات، تعين وزارة الموارد البشرية لكل موظف رقم شخصي لنظام WPS (عادةً مذكور في بطاقة العمل أو العقد). أدرجه لأن ملف WPS يحتاجه[21].
12. تاريخ انتهاء التأمين الصحي (نظرًا لأن القانون يتطلب توفير تأمين صحي للموظفين في الإمارات وبعض مناطق السعودية). تتبع تواريخ الانتهاء يضمن التجديد في الوقت المناسب.
13. حساب البنك (IBAN): على الرغم من أن ERPNext يحتوي على جدول فرعي لحسابات الموظف البنكية، قد لا يخزن IBAN صراحةً. يمكن إضافة حقل “IBAN” و“اسم البنك”. ملف WPS سيحتاج أيضًا إلى رمز توجيه البنك (في الإمارات، رمز بنك من 3 أرقام، في السعودية قد يكون اختصار البنك). يمكننا الاحتفاظ بـ Doctype للبنوك مع رموزها، أو ترك موظف الموارد البشرية يدخله يدويًا.
14. يمكن تجميع العديد من هذه الحقول في قسم “البيانات الحكومية” في نموذج الموظف. حدد أذونات الوصول بحيث يمكن لقسم الموارد البشرية فقط رؤية/تعديل الحقول الحساسة مثل الراتب، وربما يمكن للموظفين رؤية تاريخ انتهاء تأشيرتهم عبر الخدمة الذاتية للموظف (إذا كانت مفعلة).
15. استخدم ميزات التنبيهات لتواريخ الانتهاء: مثلًا، بريد إلكتروني أسبوعي لقسم الموارد البشرية يعرض أي تأشيرات/جوازات على وشك الانتهاء خلال 60 يومًا. هذا يضمن الالتزام بقوانين الهجرة (ليس التزام ERP مباشرًا، لكنه مهم تشغيليًا).
16. 3.2.3 تكوين الرواتب:
17. مكونات الراتب: عرّف مكونات تعكس فئات الدخل/الخصم الشائعة:
18. الراتب الأساسي
19. بدل السكن، بدل المواصلات، إلخ. (في الخليج، من الشائع تقسيم الراتب إلى أساسي + بدلات متنوعة للسكن والسيارة، خاصة للوافدين).
20. أجر العمل الإضافي – يمكنك إنشاء مكون تُحسب قيمته عن طريق صيغة من الجداول الزمنية أو الحضور. بدلاً من ذلك، يمكن التعامل مع العمل الإضافي كمدخلات “راتب إضافي” منفصلة لكل شهر يحتسبها قسم الموارد البشرية.
21. GOSI (السعودية): أنشئ مكونين للخصم: “GOSI الموظف” (10% من الإجمالي أو جزء محدد من الراتب) و“GOSI الشركة” (12%). يتيح ERPNext تحديد ما إذا كان المكون يُدفع من الشركة (مساهمة صاحب العمل) أو يُخصم من الموظف. حدد 12% كمساهمة الشركة بحيث لا تقلل من صافي الراتب، لكنها تُسجل كتكلفة. تطبق فقط على المواطنين السعوديين (الوافدون يدفعون فقط تأمين ضد إصابات العمل ~2%). لتطبيق ذلك، استخدم شروط تعيين هيكل الراتب أو سكريبت مخصص: إذا employee.nationality == ‘سعودي’، أدرج مكونات GOSI؛ وإلا، استبعدها أو حددها بـ 0.
22. المعاشات (للمواطنين الإماراتيين): إذا كان لدى الشركة موظفون إماراتيون أو من دول مجلس التعاون، يجب تسجيلهم لدى هيئة المعاشات (GPSSA في الإمارات) ودفع المساهمات (عادةً ~5% من الموظف، 12.5% من الشركة). يمكن عكس ذلك في الرواتب، مشابه لـ GOSI. تختلف هذه النسب حسب الإمارة (مثل أبوظبي لديها صندوق ADGP بنسبة 5%/15%). يمكننا إدراجها عند الحاجة.
23. تراكم مكافأة نهاية الخدمة: تختار بعض الشركات احتساب مكافأة نهاية الخدمة شهريًا (باحتساب 1/12 من التكلفة السنوية كمصروف). يمكن إدخال مكون “تراكم نهاية الخدمة” بصيغة مثل: basic_salary * (إذا كانت مدة الخدمة <5 سنوات، 0.583%، وإلا 0.833%) شهريًا – تستند هذه النسب إلى (21 يوم/365) و(30 يوم/365). لكن هذا قد يكون تفصيليًا جدًا؛ كثيرون يفضلون الحساب عند نهاية الخدمة. لذا هذا اختياري.
24. بدلات WPS: إذا كان ملف WPS يحتاج لتقسيم (الأساسي مقابل البدلات عادةً مطلوب في SIF الإماراتي)، تأكد من تصنيفها وفقًا لذلك. مثلًا، تريد وزارة الموارد البشرية الإماراتية رؤية الراتب الأساسي والسكني منفصلين في الملف. صمم هيكل الراتب بمكونات واضحة لذلك. ثم يمكن لتقرير WPS المخصص رسمها في حقول الملف.
25. عملية الرواتب:
26. استخدم هيكل الرواتب لكل فئة من الموظفين إذا لزم الأمر (مثلًا، هياكل مختلفة للوافدين مقابل المواطنين بسبب فروقات GOSI مقابل المعاشات).
27. كل شهر، شغّل إدخال الرواتب -> أنشئ قسائم الرواتب -> قدمها. سنضيف عند هذه النقطة توليد ملف WPS:
28. بعد تقديم الرواتب، شغّل سكريبت خادم مخصص أو تقرير “توليد ملف WPS”. سيقوم السكريبت باستعلام جميع قسائم الرواتب للفترة، وربطها مع بيانات الموظف (للحصول على رقم WPS، IBAN، إلخ)، وإخراج الملف النصي بالتنسيق المطلوب. يمكننا إضافة زر في Doctype إدخال الرواتب (عبر تخصيص النموذج) بعنوان “تنزيل ملف WPS”. هذا الزر يستدعي طريقتنا في Python لتوليد الملف وتقديمه كمحتوى قابل للتنزيل.
29. يتضمن تنسيق .SIF (الإمارات) أقسامًا: سطر رأس (برمز بنك الشركة وتاريخ الرواتب، إلخ)، عدة أسطر تفاصيل (لكل موظف)، وسطر تذييل (إجماليات). اكتب المنطق بعناية واختبره مقابل ملفات عينة. استخدم الإرشادات الرسمية مثل المواصفات الفنية لوزارة الموارد البشرية لضمان مواضع الحقول[21].
30. في السعودية، قم بالأمر نفسه بناءً على مواصفات HRSD (الملف PDF أو مساعدة Oracle يمكن أن توجهك للأعمدة مثل رقم التسلسل، رقم إقامة الموظف، إلخ). بعض البنوك تنشئ ملف WPS بنفسها عند رفع بيانات الرواتب؛ لكن بما أن الرفع المباشر شائع، نفترض أننا نحتاج لتوليده.
31. في كلا البلدين، بعد رفع ملف WPS، إذا فشلت أي رواتب (مثلًا يرفض البنك حسابًا)، قد تكون هناك حاجة لتعديلات. ننصح باستخدام تصحيحات إدخال الرواتب (أو تحويل بنكي يدوي ثم إعادة الرفع). هذا خارج أتمتة ERPNext، لكن على الأقل وجود السجلات يساعد.
32. إدارة الإجازات:
33. قم بتكوين أنواع الإجازات: الإجازة السنوية (30 يومًا/سنة في الإمارات، 21 أو 30 يومًا في السعودية حسب مدة الخدمة – ربما نضبطها على 30 للتبسيط؛ في السعودية لن يصل الموظف لـ 30 يومًا حتى 5 سنوات على أي حال)، الإجازة المرضية، الأمومة، إلخ. استخدم خيارات “الحد الأقصى للأيام” و“الترحيل” وفقًا للقانون أو سياسة الشركة.
34. بالنسبة للإمارات، يجب دفع أي رصيد إجازة غير مستخدم عند ترك الخدمة (بسعر الراتب الأساسي). في السعودية، نفس الشيء (القانون ينص على تعويض الإجازة غير المستخدمة). يمكننا التعامل مع هذا عند إنهاء الخدمة: عند وضع حالة الموظف كـ Left، يجب على الموارد البشرية حساب الإجازة غير المستخدمة وإضافتها في التسوية النهائية. يمكننا أتمتة ذلك: إنشاء أداة التسوية النهائية التي تقرأ الأيام المتبقية من سجل الإجازات، وتدرجها كبند في الراتب النهائي (أو قيد يومية). ربما خارج النطاق الحالي، لكن شيء يجب ملاحظته.
35. الخدمة الذاتية للموظف:
36. إذا رغب المستخدم، يمكن لبوابة الموظف في ERPNext السماح للموظفين برؤية قسائم الرواتب، تقديم طلبات الإجازة، إلخ. نظرًا للحاجة للواجهة ثنائية اللغة، يجب تمكين اللغة العربية في البوابة أيضًا. ربما يفضل الموظف واجهة عربية. سنناقش دعم اللغة لاحقًا (في القسم 5)، لكن من منظور الموارد البشرية، جعل النظام قابلًا للاستخدام لموظفين ناطقين بالعربية يعني ترجمة تسميات Doctype مثل “طلب إجازة” بدلاً من “Leave Application” إلخ. يجب أن تغطي ترجمة ERPNext النماذج القياسية، لكن الحقول المخصصة (التي أضفناها) سنوفر ترجمات لها.
37. الأداء والعقود:
38. رغم أنه ليس إلزاميًا قانونيًا، تتبع فترات التجربة (في الإمارات الحد الأقصى 6 أشهر، في السعودية 90 يومًا يمكن تمديدها إلى 180) عملي جدًا. يمكننا استخدام حقل تاريخ نهاية التجربة في سجل الموظف (إذا لم يكن موجودًا، أضفه) ووضع تنبيه لتذكير الموارد البشرية بالموافقة أو إنهاء التوظيف بحلول ذلك التاريخ.
39. الاحتفاظ بـ وثائق العقود: يمكننا استخدام عقود الموظف أو إرفاق ملف PDF للعقد الموقع. في السعودية، تأكد من أنه باللغة العربية ومرفوع على بوابة الوزارة (مُدد). لا يمكننا التكامل مباشرةً مع تلك البوابات الحكومية (لا توجد واجهات برمجة معروفة)، لذا فقط تأكد من سهولة الوصول للبيانات لإدخالها يدويًا عند الحاجة.
40. تكاملات خارجية للموارد البشرية:
41. إذا قرر المستخدم أن HR الخاص بـ ERPNext غير كافٍ تمامًا (بعض المؤسسات تفضل برامج الرواتب المحلية المتخصصة)، يمكننا التكامل على مستوى أساسي. مثلًا، هناك حلول رواتب محلية مثل MenaITech أو SAP SF التي تتعامل مع تفاصيل الرواتب في الخليج. في هذه الحالة، سنعطل وحدة الرواتب في ERPNext ونقوم بـ تكامل دفتر اليومية: استيراد قيد شهري من نظام الرواتب الخارجي (مدين مصاريف الرواتب، إلخ، دائن البنك/WPS، إلخ). سيستخدم المستخدم النظام الخارجي لتوليد ملف WPS وقسائم الرواتب. لكن، نظرًا لأن هدفنا هو حل موحد عبر ERPNext، نهدف لتجنب ذلك من خلال تعزيز ERPNext كما ذكر أعلاه.
42. أحد المجالات التي قد نحتاج فيها طرفًا ثالثًا هو الحضور والانصراف (أنظمة البصمة أو القياسات الحيوية) وعمليات الموارد البشرية (مثل التوظيف أو إدارة الأداء). إذا لزم الأمر، يوفر ERPNext نقاط تكامل (APIs) لجلب سجلات الحضور أو إرسال طلبات الإجازة. يمكننا استخدامها عند الحاجة.
43. 3.2.4 معالجة نهاية الخدمة:
44. تنفيذ إجراء تشغيلي قياسي في ERPNext عند مغادرة الموظف:
45. تقوم الموارد البشرية بتحديد حالة الموظف كـ “Left” وإدخال تاريخ الإعفاء.
46. تفعيل سكريبت خادم “عند التغيير” للحالة إلى Left والذي:
47.  1- يحسب مكافأة نهاية الخدمة (EOSB) باستخدام الصيغة:

      if years_of_service < 1:
        gratuity = 0
      else:
          if resignation:
            if years<2: gratuity_pct=0
            elif years<5: gratuity_pct=1/3
            elif years<10: gratuity_pct=2/3
            else: gratuity_pct=1
          else:
        gratuity_pct = 1
    # base daily wage = basic salary / 30 (assuming 30 days month as per law)
    daily_wage = basic_salary / 30
    # first 5 years:
    amount_first5 = min(years_of_service,5) * 21 * daily_wage
    # subsequent:
    amount_after5 = max(0, years_of_service-5) * 30 * daily_wage
    raw_gratuity = amount_first5 + amount_after5
    gratuity = raw_gratuity * gratuity_pct

1.    
2.    (يجب التعامل أيضًا مع كسور السنة – تشمل الأشهر بحسب النسبة).
3.  2-استخرج أيام الإجازة غير المستخدمة من سجل الإجازات وقم بتقييمها (عادةً على أساس الراتب اليومي الكامل أو الأساسي وفقًا لسياسة الشركة – عادةً تُدفع الإجازة غير المستخدمة بكامل الراتب).
4.  3-أنشئ مستند التسوية النهائية (يمكننا إنشاء Doctype جديد لذلك أو فقط استخدام قيد يومية/قسيمة راتب). مثلًا، أنشئ قيد يومية يقيد “مصروف نهاية الخدمة” و“مصروف راتب الإجازة” كمدين، ودائن “مستحقات نهاية الخدمة” (إن وجدت) و“الصندوق/البنك” أو “مستحق للموظف” للمبلغ الصافي. أو إصدار قسيمة راتب منفصلة لذلك الشهر تتضمن فقط مكونات نهاية الخدمة وتعويض الإجازة.
5. تضمن هذه الأتمتة الاتساق وتقلل من أخطاء الحساب اليدوية في المدفوعات القانونية.
6. 3.2.5 السعودة ومتطلبات الامتثال الأخرى:
7. بالنسبة للسعودية، تتبع نسبة الموظفين السعوديين. يمكننا إنشاء لوحة تحكم للموارد البشرية أو تقرير مخصص: عدد السعوديين مقابل إجمالي الموظفين، وتحديد إذا كان أقل من النسبة المطلوبة (نطاقات). رغم أن ERPNext لا يمكنه التكامل مع وزارة الموارد البشرية للتحقق من الامتثال، إعطاء هذا الوضوح للموارد البشرية يساعد على تجنب العقوبات.
8. متطلب آخر خاص بالسعودية: الشركات بحجم معين يجب أن توظف أشخاصًا من ذوي الإعاقة بنسبة معينة (يُحسبون كنسبة أكبر في نطاقات). يمكننا إضافة حقل “إعاقة (نعم/لا)” في سجل الموظف لتحديدهم ومراعاة ذلك في تقرير السعودة.
9. تقديم عقود العمل: في السعودية، بعد توقيع عقد العمل، يجب على صاحب العمل تسجيله على البوابة الإلكترونية. يمكننا توليد طباعة عقد عمل موحد (عربي/إنجليزي) من ERPNext بجميع التفاصيل (يوجد نموذج موحد من الوزارة). ثم تستخدمه الموارد البشرية لإدخاله يدويًا. في الإمارات، تتطلب وزارة الموارد البشرية استخدام نظامها لعقود العمل (والذي يولد عقدًا موحدًا). لا يمكننا أتمتة ذلك، لكن على الأقل تخزين رقم العقد وتاريخ الانتهاء في ERPNext.
10. 3.2.6 اختلافات الموارد البشرية في القطاع الحكومي:
11. إذا شمل التطبيق جهات حكومية أو شبه حكومية:
12. مفهوم الدرجات/الخطوات: الموظفون الحكوميون غالبًا لديهم سلم درجات. يمكننا استخدام Doctype القسم أو المسمى الوظيفي لتخزين الدرجة، أو إنشاء Doctype جديد “الدرجة” وربطه. يمكن أن تكون هياكل الرواتب لكل درجة. هذا يساعد على ربط مكونات الراتب تلقائيًا إذا تغيرت الدرجة.
13. استحقاقات الإجازة قد تكون أعلى (مثل 30 يوم عمل، إلخ)، وقد تكون هناك بدلات تذاكر سفر سنوية أو كل سنتين للوافدين (شائع في القطاع العام وبعض الخاص – تذاكر سفر للوطن). يمكن إضافة مكون “بدل تذاكر” متراكم.
14. تتبع التدريب والتطوير: ليس إلزاميًا مباشرًا، لكن بعض الجهات الحكومية تحتاج لتتبع نسب التوطين وبرامج التدريب. ربما خارج النطاق، لكن نذكر أن ERPNext به Doctype للتدريب يمكن استخدامه.

3.3 المبيعات والمشتريات والوحدات الأخرى

1. 3.3.1 معلومات العملاء والموردين:
2. أثرِ Doctype العميل والمورد بإضافة حقول:
3. رقم TRN/VAT (ستمتلكه الشركات الإماراتية والسعودية المسجلة). سمّه بحسب الدولة.
4. بالنسبة لعملاء السعودية، ربما حقل “نوع العميل” (تاجر أو مستهلك) مفيد لمعرفة ما إذا كان يمكن إصدار فاتورة مبسطة. لكن القانون يفرض الفوترة الإلكترونية حتى للإيصالات B2C، لذا ربما نعامل الجميع بنفس الطريقة. بدلًا من ذلك، ربما تحديد ما إذا كان العميل خارج السعودية/الإمارات (لتطبيق قواعد تصدير).
5. تأكد من أن العناوين تحتوي على المعلومات المطلوبة: بالنسبة للسعودية، كما توصي توطينة Odoo، تضمين رقم المبنى، الشارع، الحي، المدينة، الرمز البريدي، الرقم الإضافي – هذه جزء من التنسيق الرسمي للعناوين السعودية (حسب العنوان الوطني). يمكننا تخصيص قالب العنوان للسعودية وفقًا لذلك. في الإمارات، العناوين أقل رسمية (لا رموز بريدية منتشرة إلا صناديق البريد)، لكن تضمين “الإمارة” (دبي، أبوظبي، إلخ) ضروري. يجب أن نضيف حقل الإمارة (ربما نستخدم حقل “الولاية” كإمارات، مع خيارات منسدلة).
6. العملة الافتراضية للعملاء/الموردين: لدى العديد من الشركات الإماراتية موردون أجانب بالدولار أو اليورو. اضبط العملة الافتراضية في سجلهم بحيث تختار المعاملات العملة وسعر الصرف تلقائيًا.
7. 3.3.2 سير عمل المبيعات والمشتريات:
8. يمكن أيضًا جعل تنسيقات عرض الأسعار وأوامر المبيعات وأوامر الشراء ثنائية اللغة للاتساق، رغم أنها ليست إلزامية قانونيًا، لكنها احترافية. غالبًا ما تتطلب المناقصات الحكومية أوامر شراء باللغة العربية.
9. إذا كنت تبيع لجهات حكومية، قد تحتاج لتضمين بيانات تسجيلهم في الفواتير. مثلًا، في السعودية تتطلب بعض الجهات الحكومية تضمين رقم السجل التجاري للمورد على الفاتورة. يمكننا بسهولة إضافة هذه البيانات لعناوين الطباعة إذا لزم الأمر (فقط بتخصيص رأس الصفحة أو التنسيق).
10. تتطلب بعض المناطق الحرة إخلاء مسؤولية معين في الفواتير إذا كان الكيان في منطقة حرة ويتم اعتبار الإمداد خارج نطاق ضريبة القيمة المضافة. مثلًا، مؤسسة في JAFZA تبيع ضمن JAFZA قد تطبع “ضريبة القيمة المضافة غير قابلة للتطبيق لأن الإمداد ضمن منطقة محددة”. يمكن التعامل مع هذا باستخدام قسم الشروط والأحكام في الفاتورة أو حقل مخصص لتفعيل هذه العبارة.
11. الفوترة الإلكترونية خارج فواتير المبيعات: لاحظ أن قواعد الفوترة الإلكترونية في السعودية تنطبق أيضًا على إشعارات الخصم والائتمان (يجب أن تكون إلكترونية أيضًا). يعالج ERPNext إشعار الائتمان كفاتورة مبيعات سالبة (عبر خانة اختيار إشعار الائتمان). يجب التأكد من أن تكامل الفوترة الإلكترونية يغطي ذلك أيضًا. من المرجح أن التطبيقات مفتوحة المصدر تغطي ذلك (تذكر قائمة الميزات دعم إشعارات الائتمان/الخصم[35]). لذا لا يجب تجاهل الفواتير المرتجعة أثناء الاختبار.
12. 3.3.3 أدوات حفظ السجلات والتدقيق في ERPNext:
13. تفعيل سجل تدقيق دفتر الأستاذ العام (GL Audit Trail): يسمح ERPNext افتراضيًا بتحرير قيود GL المرسلة عبر Repost، إلخ، فقط للمسؤول. قد نعطل هذه الصلاحيات للمستخدمين العاديين ونشجع على استخدام الإلغاء والتعديل الذي يحتفظ بسجل تدقيق.
14. استخدم الإصدارات (Versioning) على Doctypes الحساسة (فاتورة المبيعات، فاتورة الشراء، قيد اليومية) بحيث يتم تسجيل أي تغيير في المسودة. يساعد ذلك في التدقيق الداخلي.
15. تصدير البيانات للمدققين: أنشئ تقارير مخصصة أو استخدم الحالية:
16. ميزان المراجعة بالعربية – ربما بترجمة أسماء الحسابات للعربية (يمكن الاحتفاظ بالاسم العربي في دليل الحسابات عبر الترجمة أو حقل مخصص).
17. تقرير دفتر الأستاذ العام – تأكد من إمكانية التصفية حسب التاريخ وتصديره إلى Excel للمدققين.
18. تقارير المخزون – إذا كانت هناك تعاملات بالمخزون، قد تحتاج وزارة التجارة أو ZATCA لرؤية سجلاته. دفتر أستاذ المخزون في ERPNext مفيد هنا.
19. إرفاق المستندات: شجع على مسح وإرفاق المستندات الأصلية في ERPNext (مثل إرفاق PDF لفاتورة المورد في سجل فاتورة الشراء). القوانين غالبًا تتطلب الاحتفاظ بالمستندات الأصلية؛ وجودها في ERPNext (مع نسخ احتياطية) يساعد في تلبية ذلك بشكل خالٍ من الورق. قانون الضرائب الإماراتي وأنظمة السعودية تقبل النسخ الإلكترونية طالما أنها غير قابلة للتلاعب. مرفقات ERPNext مختومة زمنيًا ويمكن جعلها غير قابلة للتعديل بعد الإرسال (يمكن إزالة إذن الحذف للمرفقات).
20. تقارير الامتثال للتدقيق: ربما أنشئ Doctype “قائمة مرجعية للامتثال” أو حتى صفحة Wiki في ERPNext للشركة، تسرد مهام مثل “تقديم البيانات المالية السنوية للوزارة بحلول التاريخ X – نعم/لا”، “تقديم الزكاة – إرفاق الإيصال”، “تقديم ملف WPS للشهر – التاريخ”. رغم أنه ليس من وظائف ERPNext المعتادة، إلا أن Doctype مخصصًا بسيطًا للمهام مع تاريخ ووصف ومسؤول وحالة يمكن أن يساعد المستخدم على تتبع الالتزامات.

3.4 فصل التخصيصات بين الإمارات والسعودية والميزات المشتركة

1. نهدف إلى تنفيذ حل أساسي مع امتدادات خاصة بكل دولة:
2. الميزات الأساسية المشتركة:
3. إطار محاسبي متوافق مع IFRS (دليل الحسابات، تعدد العملات، التقارير المالية).
4. ميزات الموارد البشرية الأساسية (بيانات الموظفين، إدارة الإجازات، عملية الرواتب).
5. وظائف ضريبة القيمة المضافة في ERPNext (محرك الضرائب موحد لأي نسبة أو قواعد).
6. مفهوم WPS (توليد ملف بنكي للرواتب).
7. إمكانية المستندات ثنائية اللغة (طريقة الترجمة مشتركة).
8. سياسة الاحتفاظ بالبيانات والنسخ الاحتياطي – السياسة نفسها تقريبًا (5–7 سنوات).
9. تعزيز النظام بشكل عام للتدقيق (السجلات، الإصدارات، إلخ).
10. ننفذ هذه مرة واحدة ونستخدم التكوين أو تعديلات طفيفة لكل بلد:
11. مثلًا، يمكن لمولد ملف WPS أن يكون أداة واحدة تنتج تنسيق الإمارات إذا كانت الشركة.country = الإمارات، أو تنسيق السعودية إذا كانت country = السعودية. الاختلاف الأساسي في الأعمدة وبعض القيم (الإمارات تتطلب رقم MOHRE للشركة، السعودية قد تتطلب رقم MOL، إلخ – يمكن جعل هذه الحقول شرطية).
12. تنفيذات خاصة بالإمارات:
13. ضريبة القيمة المضافة بنسبة 5% وصيغة الإقرار الخاصة (VAT201): تقرير ضريبة القيمة المضافة المدمج في الإمارات كافٍ[34]. نتحقق من صحته وربما نعدله إذا تطلب الأمر تكامله مع ضريبة الشركات (ليست مباشرة، لأن ضريبة الشركات مستقلة).
14. حسابات ضريبة الشركات: فقط الإمارات لديها هذه الضريبة الجديدة (في السعودية، ضريبة الشركات فقط على الجزء الأجنبي والزكاة تغطي الجزء المحلي). قد نصمم تقرير تقدير ضريبة الشركات للإمارات – يأخذ أرباح المحاسبة من قائمة الدخل، ويعدل على البنود غير القابلة للخصم (مثل الترفيه المرفوض بنسبة 50% إلخ، حسب القانون)، لكن هذا قد يكون تفصيليًا جدًا ومن الأفضل أن تنفذه المالية يدويًا. على الأقل، تأكد من أن سجلات مثل الإهلاك واضحة لأي تعديلات ضريبية.
15. صيغة مكافأة نهاية الخدمة: صيغة أبسط في الإمارات (لا توجد عقوبة للاستقالة) مقابل صيغة مشروطة في السعودية. يجب أن يكتشف سكريبت نهاية الخدمة البلد ويطبق القواعد المناسبة. يمكننا تخزين حقل في Doctype الشركة أو استخدام حقل الدولة للشركة لتفرع المنطق في الكود.
16. تقارير وزارة الموارد البشرية: ربما تطلب الشركات الإماراتية تقديم تقارير توطين ربع سنوية أو تقارير سكن العمالة. ليست ضمن نطاق ERP عادةً، لكن يمكننا إنشاء تقرير بسيط بالموظفين حسب الجنسية (فقط للمساعدة).
17. معالجة المناطق الحرة: ربما نحتفظ بعلم في الشركة (مثل “شركة منطقة حرة”) لتفعيل بعض السلوكيات: مثلًا، إذا كانت في منطقة حرة، اعتبر المبيعات المحلية صادرات للضريبة (0% للإمارات الداخلية؟)، أو حدد أن ضريبة الشركات قد تكون 0%. يمكن استخدام هذا العلم في سكريبتات قواعد الضرائب أو في تقرير VAT201 لاستبعاد بعض المبيعات (رغم أن المناطق الحرة ما زالت تقدم تقارير الضريبة إذا كانت مشمولة، لكنها قد تحتوي على الكثير من المعاملات صفرية).
18. تنفيذات خاصة بالسعودية:
19. ضريبة القيمة المضافة بنسبة 15% والإقرار السعودي: إذا لم يكن لدى ERPNext تقرير ضريبة مضافة رسمي للسعودية، قد ننشئه (أو نتأكد من تثبيت تقرير المجتمع). سيجمع إجمالي المبيعات، التصدير، المعفى، إلخ، مثل الإمارات ولكن بنسبة 15% وأي حقول سعودية خاصة (قد تطلب استمارة ZATCA الزكاة إذا كانت مجمعة؟ فعليًا الزكاة ترفع بشكل منفصل).
20. الفوترة الإلكترونية (ZATCA): فقط للسعودية. هذه وحدة منفصلة تمامًا كما ناقشنا. سنقسمها بحيث إذا كانت الشركة.country == "Saudi Arabia" يتم تفعيل تطبيق الفوترة الإلكترونية؛ إذا لم يكن، يبقى غير مفعل. بهذه الطريقة، لن تتأثر شركات الإمارات بهذا العبء.
21. الزكاة: السعودية فقط تتطلب ذلك. ربما ننشئ أداة حاسبة زكاة في ERPNext. يمكن أن تكون نموذجًا بسيطًا يدخل فيه المستخدم بعض الأرصدة (أو يختار سنة مالية وتستخرج الأداة أرصدة حقوق الملكية والأصول الثابتة إلخ) وتحسب الزكاة المستحقة. ليست ضرورية تمامًا إذا كان المستخدم مرتاحًا بحسابها خارجيًا، لكن إضافتها تزيد من قيمة النظام. بما أن المراجع مفتوحة المصدر (مثل ملف IFRS[3]) تذكر أن الزكاة تتطلب إفصاحات إضافية، نضمن أن بياناتنا المالية أو الملاحظات يمكن تعديلها لتتضمن “وعاء الزكاة: ريال كذا، زكاة مستحقة: ريال كذا”.
22. GOSI والسعودة: فقط السعودية. لذا هيكل الرواتب مع مساهمات GOSI سيستخدم لشركات السعودية (ويطبق فقط على الموظفين السعوديين). تقرير السعودة كذلك مهم فقط في السعودية.
23. اللغة: رغم أن البلدين يحتاجان للغة العربية، السعودية أكثر تشددًا قانونيًا. ربما يجب أن نضبط لغة الطباعة الافتراضية للوثائق لتكون العربية في السعودية، بينما في الإمارات العديد من الشركات تستخدم الإنجليزية كلغة أساسية. للإمارات، ما زلنا نوفر ثنائية اللغة، لكن ربما الإنجليزية أولًا. في السعودية، تأكد من عرض العربية أولًا أو في الأعلى حسب العرف.
24. سنحتفظ بـ تطبيقات مخصصة أو سكريبتات منفصلة لأي منطق خاص بكل دولة:
25. ربما ننشئ تطبيقين: erpnext_uae وerpnext_ksa للاحتفاظ بالتخصيصات الخاصة (مثل تنسيقات الطباعة، التقارير، وتكاملات API).
26. التخصيصات المشتركة (مثل دعم ثنائية اللغة، تحسينات أساسية) يمكن أن تبقى في تطبيق مشترك أو مجرد تهيئة في النظام الأساسي.

3.5 التكاملات والأدوات الخارجية

1. 3.5.1 التكامل البنكي:
2. بدلًا من مجرد إخراج ملفات WPS، قد ندمج مع البنوك عبر واجهات API لعمليات تحويل الرواتب أو مدفوعات الموردين. بعض البنوك الإماراتية (مثل Emirates NBD) لديها اتصال ERP لمدفوعات مجمعة. إذا رغب المستخدم، يمكننا بناء تكامل API بحيث يدفع ERPNext الرواتب مباشرة للبنك (سيظل ينتج ملف WPS في الخلفية). لكن، نظرًا للأمان والتعقيد، النهج الأكثر أمانًا هو توليد الملف وجعل فريق المالية يرفعه على بوابة البنك.
3. بالنسبة لمدفوعات العملاء، كلا البلدين يستخدمان بشكل أساسي التحويلات البنكية والشيكات. يمكن إدارة الشيكات عبر طباعة الشيكات في ERPNext أو Doctype مخصص. (في الإمارات، الشيكات المؤجلة شائعة؛ يمكن إضافة تحسين لإظهار شيكات PDC وتواريخ استحقاقها، لكن هذا ميزة أكثر من كونه امتثالًا.)
4. 3.5.2 بوابات الحكومة:
5. تقديم إقرارات ضريبة القيمة المضافة: لدى FTA (الإمارات) وZATCA (السعودية) بوابات إلكترونية حيث يدخل فريق المالية الأرقام يدويًا من تقارير ERP. طموح التكامل قد يكون باستخدام أي واجهة API متاحة لتقديم الإقرارات مباشرة. حاليًا، الإمارات لا توفر API مفتوحة لذلك (حسب المعلومات المتاحة). السعودية توفرها للفوترة الإلكترونية فقط وليس للزكاة/تقديم VAT (يتم على بوابتهم). لذا نكتفي بتوفير تقارير دقيقة للتقديم اليدوي.
6. تصاريح الاستيراد/التصدير: قد يرغب بعض المستخدمين في التكامل مع الجمارك (مثل SABER أو Fasah السعودية للإفراج الجمركي، أو Dubai Trade في الإمارات). هذه متخصصة وخارج ERPNext. نكتفي بضمان أن ERP يمكنه تسجيل الرسوم الجمركية والضرائب المرفقة، وربما إرفاق مستندات الجمارك.
7. 3.5.3 الرواتب أو أنظمة الموارد البشرية الخارجية:
8. كما أشرنا، إذا كانت هناك ميزات متقدمة مطلوبة (مثل الخدمة الذاتية للموظف، تقييم الأداء، تقارير تنظيمية محلية) يمكن دمج نظام HRMS خارجي. مثلًا، خدمة سحابية تتعامل مع تحديثات قوانين العمل المحلية قد تكون خيارًا. استراتيجية التكامل: استخدم واجهات API لمزامنة بيانات الموظفين ونتائج الرواتب الأساسية. واحتفظ بـ ERPNext كنظام مالي رئيسي.
9. نظرًا لأن توجهنا هو تمكين ERPNext للقيام بذلك محليًا، نوصي بالطرف الثالث فقط إذا لزم الأمر حقًا. سيناريو واحد قد يكون إذا كان لدى الشركة مئات الموظفين ويفضلون الاستعانة بمزود خارجي للرواتب (مثل RemotePass أو Mercans المذكورة في المصادر).
10. [24]). في هذه الحالة، يمكننا التخطيط لتصدير البيانات اللازمة من ERPNext (الحضور، الإجازات) إلى ذلك النظام، واستيراد قيد الرواتب مرة أخرى. أو استخدام واجهة API لذلك النظام لجلب النتائج شهريًا.
11. 3.5.4 أدوات ترجمة المستندات:
12. إذا كان إدخال البيانات ثنائي اللغة في الوقت الحقيقي يمثل تحديًا، يمكننا التكامل مع واجهة ترجمة API للوصف. لكن بما أن معظم العناصر والمصطلحات ستكون ثابتة، من الأفضل تخزين الترجمات يدويًا. ربما نستخدم Doctype الترجمة في ERPNext: أدخل الترجمات العربية لكل أسماء العناصر ووحدات القياس، إلخ، بحيث عندما يغير المستخدم اللغة للعربية، تظهر تلك الترجمات. هذا آلية مدمجة يمكننا استخدامها بدلًا من طرف ثالث.
13. 3.5.5 ذكاء الأعمال ومراقبة الامتثال:
14. يمكننا التفكير في ربط ERPNext بأداة BI (مثل Metabase أو لوحة معلومات داخلية) لمراقبة مؤشرات الامتثال باستمرار: مثلًا، “لم يتم رفع WPS هذا الشهر – تنبيه”، “تاريخ استحقاق إقرار الضريبة الأسبوع المقبل – تنبيه إذا لم يقدم”، إلخ. لكن، قد يكون هذا معقدًا أكثر من اللازم؛ الأبسط هو استخدام إطار عمل التنبيهات والإشعارات في ERPNext (الذي يمكنه إرسال رسائل بريد إلكتروني بناءً على الشروط، كما خططنا لتاريخ انتهاء التأشيرة، إلخ) للتذكيرات المتعلقة بالامتثال أيضًا. مثلًا، تعيين تنبيه للمدير المالي في اليوم 15 من الشهر التالي لنهاية الربع: “هل قدمت إقرار ضريبة القيمة المضافة للربع X؟”.
15. ختامًا، يتطلب تنفيذ هذه التوصيات مزيجًا من ميزات ERPNext الأصلية (الاستفادة من عناصر التوطين في الإمارات/السعودية)، تهيئة مخصصة (أدلة الحسابات، الضرائب، تنسيقات الطباعة)، سكريبتات خادم وتطبيقات مخصصة (لـ WPS، الفوترة الإلكترونية، معالجة نهاية الخدمة المتقدمة)، وضمان توافق بيئة النظام مع المتطلبات القانونية (مثل موقع الاستضافة، النسخ الاحتياطية).
16. يجب توثيق جميع التطويرات المخصصة واختبارها ضد سيناريوهات فعلية: مثلًا، توليد إقرار ضريبة القيمة المضافة ومقارنته مع حساب يدوي معروف؛ محاكاة موظف يترك العمل بعد 7 سنوات مع استقالة للتحقق من مطابقة مكافأة نهاية الخدمة مع القانون؛ التحقق من أن فاتورة إلكترونية سعودية تم توليدها اجتازت فحوصات بوابة ZATCA، إلخ. ونظرًا لأن القوانين تتطور، سننشئ أيضًا عملية لمتابعة التغييرات (مثلًا، إذا طبقت الإمارات الفوترة الإلكترونية مستقبلاً أو غيرت نسبة ضريبة القيمة المضافة، أو إذا عدلت السعودية قانون العمل). يجب بناء النظام بحيث يستوعب هذه التحديثات – مثل وجود معدلات الضرائب في Doctype (وهو موجود بالفعل)، أو الاحتفاظ بصيغ EOS في سكريبت يمكن تعديله بسرعة.

4. متطلبات الإمارات مقابل السعودية والميزات المشتركة

1. أثناء تصميم الحل، من المهم فصل وظائف كل دولة عن الميزات المشتركة، للحفاظ على وضوح الصيانة وسهولتها:
2. المحاسبة والضرائب: أساس IFRS مشترك، لكن نسب ضريبة القيمة المضافة والزكاة تختلف. سنحتفظ بـ قوالب وتقارير ضرائب منفصلة لكل دولة (5% للإمارات مقابل 15% للسعودية؛ VAT201 للإمارات مقابل الإقرار السعودي). سيتم تفعيل وحدة الزكاة فقط لشركات السعودية. في ERPNext، قد ننجز ذلك بفحص دولة الشركة في السكريبتات أو فقط بتثبيت تطبيق الزكاة لشركات السعودية. الجوانب المشتركة مثل تعدد العملات وهيكل الحسابات ومنطق البيانات المالية تبقى مشتركة.
3. الموارد البشرية والرواتب: وحدة WPS ستتضمن منطقًا شرطيًا لكل دولة (تنسيقات ملفات مختلفة). ستتفرع صيغة مكافأة نهاية الخدمة أيضًا لقواعد الإمارات أو السعودية. معظم مكونات الموارد البشرية الأخرى (الإجازات، الحضور) مشتركة، لكن سندمج الشروط حسب الحاجة (مثلًا، تطبق GOSI فقط على السعوديين، GPSSA فقط على الإماراتيين). يجب أن توضح الوثائق لمستخدمي الموارد البشرية: “إذا كنت تستخدم نسخة السعودية، لاحظ اختلافات X، Y، Z” وكذلك للإمارات.
4. الفوترة الإلكترونية: امتداد خاص تمامًا بالسعودية حاليًا. سنجعله في وحدة منفصلة بحيث لا يتداخل مع عمليات الإمارات. مثلًا، مستخدمو الإمارات لن يروا عناصر قائمة ZATCA أو يواجهوا التواقيع الرقمية عند حفظ الفواتير. نضمن أن هذه المشغلات تتعلق فقط بمعاملات شركات السعودية. ربما يكتشف التطبيق بلد الشركة عند التثبيت ويعطل نفسه إذا لم تكن السعودية. إذا طبقت الإمارات الفوترة الإلكترونية مستقبلًا، يمكننا توسيع الإطار نفسه بمتطلبات FTA (غالبًا ستكون مشابهة، لكن لم تُعلن بعد).
5. 
   
6. اللغة والتعريب: كلا البلدين يتطلبان دعم اللغة العربية، لكن ربما يختلف المستوى (في السعودية يُلزم القانون وجود العربية في جميع المستندات الخارجية، في حين تشجع الإمارات ذلك ولكن ليس إلزاميًا تمامًا في المعاملات الخاصة). لذلك، سنطبق القدرة الكاملة على ثنائية اللغة لكلا البلدين، لكن نفرض اللغة العربية كمخرج افتراضي للسعودية. يمكننا أن نحتفظ بمجموعتين من تنسيقات الطباعة إذا لزم الأمر، أو تنسيق طباعة ديناميكي واحد يضبط لغة العناوين بناءً على الشركة/البلد.
7. تقارير الامتثال: لدى الإمارات متطلبات مثل لوائح "المادة الجوهرية الاقتصادية" (ESR) و"الإفصاح عن المالك المستفيد النهائي" (UBO) لبعض الشركات، بينما لدى السعودية تقارير السعودة. هذه الأمور خارج نطاق ERP ولكن إذا لزم الأمر يمكننا توفير بيانات للمساعدة (مثل قائمة الكيانات القانونية وما إلى ذلك). على الأرجح، هذا خارج نطاق ERP.
8. ممارسة جيدة هي الاحتفاظ بـ ملف تكوين أو Doctype يسمى “إعدادات إقليمية” لكل شركة، حيث يمكننا تحديد خيارات مثل “تطبيق قانون العمل السعودي” أو “تطبيق قانون ضريبة القيمة المضافة الإماراتي” إلخ. لكن بما أن البلد هو بالفعل حقل في النظام، قد يكون كافيًا لتقسيم المنطق في الكود.
9. يجب أن تحتوي مواد التوثيق والتدريب المقدمة للمستخدم على أقسام منفصلة للإمارات والسعودية لتجنب أي التباس. على سبيل المثال، دليل المستخدم النهائي: “كيفية معالجة الرواتب – الإمارات” مقابل “معالجة الرواتب – السعودية” مع إبراز الفروق (مثل خطوة GOSI الإضافية في السعودية، إلخ).

5. إرشادات تنفيذ ثنائية اللغة (إنجليزي/عربي)

1. دعم كل من الإنجليزية والعربية في واجهة ERP والإخراجات ضروري لاعتماد المستخدم والامتثال القانوني. إليك كيفية تحقيق دعم ثنائي اللغة قوي في ERPNext:
2. واجهة ERPNext بالعربية: يأتي ERPNext بترجمة عربية لمعظم المصطلحات القياسية. في إعدادات النظام، قم بتعيين اللغات المتاحة لتشمل العربية (ar) والإنجليزية (en). يمكن للمستخدمين بعد ذلك اختيار لغتهم المفضلة في ملفهم الشخصي. بالنسبة للعربية:
3. ستتحول الواجهة تلقائيًا إلى اتجاه من اليمين إلى اليسار (RTL) للغة العربية. تحقق من ذلك في حساب مستخدم اختباري. قد تحتاج بعض الصفحات المخصصة أو التطبيقات إلى CSS إضافي لمحاذاة RTL بالكامل (يجب اختبار النماذج والتقارير بعد تمكين العربية لتصحيح أي مشاكل محاذاة).
4. تأكد من ترجمة تسميات الحقول المخصصة وأسماء Doctype المخصصة. نظرًا لأننا سنضيف حقولًا مثل “انتهاء صلاحية التأشيرة”، يجب تقديم المكافئ العربي (“انتهاء صلاحية التأشيرة”). يمكننا فعل ذلك عن طريق إضافة إدخالات في Doctype الترجمة (أو ملف CSV) باللغة = العربية، النص المصدر = “Visa Expiry”، النص الهدف = المقابل بالعربية. بدلاً من ذلك، يمكن تسمية الحقل المخصص بتسمية عربية مباشرة إذا كانت قاعدة المستخدمين في الغالب عربية. لكن من الأفضل الاحتفاظ بالإنجليزية داخليًا واستخدام الترجمات للمرونة.
5. يمكن أن تبقى تنسيقات التاريخ والأرقام كما هي (معظم الشركات الخليجية تستخدم الأرقام الغربية حتى في المستندات العربية). لكن إذا لزم الأمر، يمكننا تطبيق تعريب للتواريخ (لإظهار أسماء الشهور العربية). هذا ليس إلزاميًا قانونيًا؛ اللغة العربية مع التواريخ الميلادية مقبولة.
6. المستندات بالعربية والإنجليزية: بالنسبة للمستندات الرسمية مثل الفواتير، أوامر الشراء، قسائم الرواتب، إلخ، نوصي بـ تنسيقات ثنائية اللغة:
7. أحد الأساليب هو وجود عمودين في جدول تنسيق الطباعة لكل حقل (واحد للإنجليزية، وآخر للعربية). مثلًا، وصف بند الفاتورة يمكن أن يعرض “Description (الوصف)” كعنوان، ويظهر كل عنصر اسمه بالإنجليزية/العربية.
8. أو عرض النص الإنجليزي والعربي في سطر واحد مفصول بشرطة مائلة أو سطر جديد.
9. استخدم خطوطًا واضحة تدعم العربية. عادةً ما يستخدم مولد PDF المدمج خطًا يدعم الأحرف العربية، لكن إذا لم يكن كذلك، قد نحتاج لتحديد خط ويب (مثل Google Noto Kufi أو Arial Unicode). يمكننا تضمين CSS في تنسيق الطباعة لاستخدام خط مناسب للأجزاء العربية.
10. يجب ألا نضع هنا صيغة 【...†embed_image】 الخاصة بالصور لأنها غير ذات صلة؛ بل تأكد من أن شعار الشركة (إذا وُجد) في رأس الصفحة ثنائي اللغة أو شعار مزدوج.
11. بالنسبة للشروط والأحكام أو النصوص الطويلة التي تحتاج ثنائية اللغة، ضع في اعتبارك الاحتفاظ بنسختين. مثلًا، أنشئ سجل شروط وأحكام باسم “Invoice Arabic” يحتوي على النص القانوني القياسي بالعربية (مثل “هذه فاتورة ضريبية…” مترجمة). ثم في تنسيق الطباعة، اعرض النصين معًا.
12. إدخال البيانات بالعربية: قد تكون هناك حقول يجب تخزين البيانات فيها بالعربية، مثل أسماء الموظفين للنماذج الحكومية، أو أسماء العناصر إذا كانت الأعمال بالعربية بالأساس. لدينا خيارات:
13. استخدام حقل واحد يحتوي على الإنجليزية والعربية معًا (ليس الأفضل للبحث).
14. استخدام حقلين: مثل “Name (English)” و“Name (Arabic)” كحقول مخصصة في العملاء، العناصر، إلخ. ثم في النماذج، عرض كليهما. يمكن للمستخدم تعبئة الاثنين. هذا واضح ولكنه يتطلب تكرار في الإدخال.
15. استخدام آلية الترجمة في ERPNext: إذا تم تبديل واجهة المستخدم للعربية، يمكن لـ ERPNext عرض بعض القيم مترجمة إذا تم توفير الترجمة. لكن هذا ينطبق أساسًا على تسميات النظام، وليس بيانات المستخدم. هناك ميزة لترجمة أسماء العناصر: في Doctype العنصر، يمكنك الاحتفاظ بترجمات الاسم/الوصف للغات مختلفة (عبر Doctype الترجمة أو رفع ملف CSV). ثم، إذا طبعت فاتورة ولغة المستخدم هي العربية، ستظهر النسخة العربية من اسم العنصر. هذه ميزة جيدة للاستفادة منها:
16. يمكننا الاحتفاظ بملف ترجمة مخصص لكل أسماء العناصر وربما وحدات القياس. لكن بالنسبة للأسماء مثل أسماء العملاء، فهي أسماء علمية – من الأفضل تخزينها ثنائيًا مباشرةً إذا لزم الأمر.
17. نظرًا للتعقيد، نهج عملي: تخزين البيانات الرئيسية المهمة باللغتين. مثلًا، إضافة حقل مخصص “الاسم بالعربي” للعملاء والموردين. بالنسبة للعناصر، ربما نترجمها عبر الآلية المدمجة لأن العنصر عادةً له اسم واحد ونظير واضح بالعربية. بالنسبة للعناوين، نضيف سطرًا بالعربية إذا لزم الأمر.
18. الطباعة باتجاه RTL بشكل صحيح: تأكد من أنه في HTML لتنسيق الطباعة، عندما يكون هناك نص عربي، نحدد dir="rtl" على ذلك الحاوي (مثل <div style="text-align: right" dir="rtl">). هذا سيرتب الكلمات بشكل صحيح. بدون ذلك، قد يظهر النص العربي ولكن في اتجاه خاطئ أو علامات الترقيم في مكان غريب.
19. يجب علينا اختبار طباعة فاتورة تحتوي على محتوى عربي كثيف لمعرفة ما إذا كان توليد PDF يتعامل مع التفاف الأسطر بشكل صحيح. أحيانًا، يمكن لمولدات PDF أن تضع علامات التشكيل في غير موضعها أو تربط الحروف بشكل خاطئ. إذا حدث ذلك، قد نضطر لاستخدام صورة للنص العربي (وهو أقل تفضيلًا)، أو ضمان أن الخط المستخدم متين.
20. تدريب المستخدم: قد يفضل بعض الموظفين استخدام النظام بالإنجليزية لكن يحتاجون المخرجات بالعربية. سنوفر خيارات بسيطة: مثل إضافة معامل لتنسيق الطباعة يتيح للمستخدم اختيار لغة الطباعة. أو إنشاء تنسيقين للطباعة (Invoice-ENG وInvoice-AR). لكن صيانة اثنين عمل إضافي. تنسيق ديناميكي واحد يعرض اللغتين هو الأسهل للامتثال (لا خطر لإعطاء فاتورة باللغة الإنجليزية فقط لعميل سعودي).
21. الأرقام العربية: عادةً، حتى المستندات العربية في الخليج تستخدم “الأرقام العربية” الغربية (0,1,2…). لا تُستخدم عادةً الأرقام العربية الشرقية (٠١٢...). سنستخدم الأرقام الغربية لتجنب الالتباس، كما هو شائع في الفواتير والمالية في الإمارات/السعودية. إذا طلبت جهة حكومية أرقامًا شرقية، يمكن استخدام خط يعرض الأرقام بهذا الشكل، لكن غالبًا لا حاجة.
22. اللغة في مستندات الموارد البشرية: قدم عقود العمل والخطابات بصيغة ثنائية اللغة. يمكننا إنشاء قوالب رسائل في ERPNext (باستخدام Jinja لسحب بيانات الموظف) مثل شهادات الراتب، خطابات عدم الممانعة، إلخ، باللغتين. هذا يعزز قيمة النظام للمستخدم.
23. رسائل النظام والأخطاء: إذا كان هناك مستخدمون عرب فقط، ضع في اعتبارك ترجمة رسائل التحقق أو الأخطاء المخصصة. مثلًا، إذا حاول المستخدم إرسال فاتورة بدون رقم ضريبي للعميل، يمكننا عرض: “Customer VAT ID is required – يجب إدخال الرقم الضريبي للعميل”. يمكننا عرض اللغتين في رسالة واحدة أو اكتشاف لغة المستخدم وعرض واحدة. الجمع بين اللغتين هو الأبسط للوضوح.
24. دعم RTL في بوابة الويب: يجب التحقق من بوابات الويب للموظف والعميل في وضع العربية لضمان محاذاة القوائم يمينًا، إلخ. Frappe عادةً يقوم بعمل جيد، لكن الصفحات المخصصة (إن وجدت) يجب ضبطها.
25. من خلال تنفيذ ما سبق، سيكون ERPNext v15 ثنائي اللغة بالكامل: يمكن للمستخدمين العمل باللغة المفضلة، وجميع المخرجات التي تذهب للطرف الخارجي (فواتير، قسائم رواتب، إلخ) ستكون باللغتين عند الحاجة. هذا لا يفي فقط بالمتطلبات القانونية (خصوصًا في السعودية حيث العربية إلزامية) بل يجعل النظام سهلًا للمحاسبين وموظفي الموارد البشرية والموظفين الناطقين بالعربية.
26. الخلاصة: باستخدام هذه الإعدادات المخصصة والتخصيصات المتعمقة، سيتم تحويل ERPNext 15 إلى نظام ERP جاهز لدولة الإمارات العربية المتحدة / المملكة العربية السعودية. سيتولى النظام المحاسبة وفقًا لمعايير IFRS مع الامتثال المحلي للضرائب (ضريبة القيمة المضافة، ضريبة الشركات، الزكاة)، وتطبيق قواعد قانون العمل في الموارد البشرية (ساعات العمل، الإجازات، نظام حماية الأجور، نهاية الخدمة)، وإنتاج المستندات والتقارير التي تتوافق مع المعايير الحكومية (تنسيقات الفواتير، المحتوى الثنائي اللغة، سجلات التدقيق)، والتكامل مع الأنظمة الحكومية اللازمة (مثل الفوترة الإلكترونية السعودية عبر واجهة برمجة تطبيقات ZATCA). لقد استفدنا من الوحدات مفتوحة المصدر ومعرفة المجتمع لتسريع التطوير - بدءًا من أدوات تقارير ضريبة القيمة المضافة[32] إلى تطبيقات تكامل ZATCA المتكاملة[35] - لضمان أننا لا نبدأ من الصفر، بل نبني على حلول مجربة. والنتيجة ستمكّن المستخدم من نشر ERPNext بثقة للأعمال في الإمارات العربية المتحدة والمملكة العربية السعودية، مع العلم أن الامتثال القانوني والتوطين قد تمت معالجتهما بشكل كامل.
27. يجب تنفيذ جميع التوصيات المذكورة أعلاه بعناية واختبار دقيق وتدريب للمستخدمين. بعد التفعيل، يجب على المستخدم أيضًا متابعة التغييرات القانونية (مثل أي قرارات جديدة في الإمارات بشأن الفوترة الإلكترونية، أو التغييرات في معدلات التأمينات الاجتماعية السعودية، وما إلى ذلك) وتحديث تكوينات ERPNext وفقًا لذلك – لكن الأساس الذي تم وضعه في هذا البحث يوفر قاعدة قوية وقابلة للتوسيع للامتثال المستمر في كلا النظامين.