التعامل مع الإيرادات المؤجلة والتكاليف المؤجلة في ERPNext v15

أولاً. المفاهيم الأساسية والمصطلحات

الإيرادات المؤجلة مقابل التكاليف المؤجلة: تشير الإيرادات المؤجلة إلى الأموال المستلمة مقابل منتجات أو خدمات لم تقدمها الشركة بعد؛ فهي في الأساس إيرادات غير مكتسبة تُسجل كالتزام[1]. تشير التكاليف المؤجلة إلى مدفوعات نفقات تم دفعها مقدماً لكنها لم تتحمل بعد؛ وهي مصروفات مدفوعة مسبقاً تُسجل كأصل في الميزانية[2]. في كلتا الحالتين، لا يتم الاعتراف بالاستلام أو الدفع الأولي مباشرة في بيان الدخل. بدلاً من ذلك، يتم الاحتفاظ بالمبلغ في حساب مؤقت في الميزانية العمومية (التزام للإيرادات المؤجلة، وأصل للتكاليف المؤجلة) حتى تكتمل عملية الكسب أو يتم استهلاك الفائدة. عند هذه النقطة، يُنقل المبلغ إلى حساب الإيرادات أو المصروفات الفعلية في بيان الأرباح والخسائر[1][2].

الحسابات المؤقتة مقابل الحسابات الفعلية: المصطلحات “الإيرادات المؤجلة” و “المصروفات المؤجلة” هي التسميات المحاسبية الصحيحة لهذه الحسابات المؤقتة. الإيرادات المؤجلة (وتسمى أيضاً Unearned Revenue أو Advance from Customers) هي حساب التزام لأنها تمثل التزاماً بتسليم السلع/الخدمات في المستقبل[1]. المصروفات المؤجلة (وغالباً ما تسمى Prepaid Expense أو Prepayments) هي حساب أصل لأنها تمثل مورداً (حق في فوائد أو خدمات مستقبلية) ستستخدمه الشركة مستقبلاً[2]. هذه الحسابات مؤقتة بمعنى أنها سيتم تصفيتها في النهاية: فعندما تُكتسب الإيرادات أو تُتحقق المصروفات، تُنقل الأرصدة من الميزانية العمومية إلى حسابات الدخل أو المصروفات الحقيقية. على سبيل المثال، شركة برمجيات تبيع اشتراكاً لمدة 12 شهراً مقابل 12,000 دولار ستسجل في البداية التزام إيرادات مؤجلة بقيمة 12,000 دولار ثم تعترف بـ 1,000 دولار كإيرادات فعلية كل شهر، مما يقلل من رصيد الحساب المؤجل وفقاً لذلك. وبالمثل، إذا دفعت شركة 12,000 دولار مقدماً لبوليصة تأمين لمدة عام، فستسجل مصروفات مدفوعة مسبقاً (أصل) بقيمة 12,000 دولار ثم تعترف بمصروفات تأمين بقيمة 1,000 دولار شهرياً، مما يقلل من الأصل المدفوع مسبقاً.

المحاسبة على أساس الاستحقاق مقابل أساس النقد: بموجب المحاسبة على أساس الاستحقاق، يتم الاعتراف بالإيرادات عند كسبها (عند تسليم السلع أو الخدمات)، ويتم الاعتراف بالمصروفات عند تحملها – وليس عند تغير النقد. لهذا السبب توجد حسابات الإيرادات المؤجلة والمصروفات المدفوعة مسبقاً: لسد الفجوة الزمنية بين استلام/دفع النقد وعملية الكسب/الاستهلاك[3]. على العكس من ذلك، في المحاسبة على أساس النقد لا توجد فعلياً مفاهيم الإيرادات المؤجلة أو المصروفات المدفوعة مسبقاً. حيث يتم الاعتراف بالإيرادات والمصروفات في وقت استلام أو دفع النقد فقط. على سبيل المثال، في نظام نقدي بحت، أي نقد يتم استلامه مسبقاً يتم تسجيله فوراً كدخل، والمصروفات المدفوعة مسبقاً تُعتبر مصروفات عند الدفع[3]. لا يوجد إيرادات غير مكتسبة في المحاسبة النقدية – بمجرد أن تتلقى الأموال، تُعتبر إيرادات فقط[3]. لذا، يوفر استخدام طريقة الاستحقاق للحسابات المؤجلة صورة أكثر دقة من خلال مطابقة الإيرادات والمصروفات مع الفترات التي تنتمي إليها، في حين أن أساس النقد قد يشوه التوقيت (مثل الاعتراف بإيرادات أو مصروفات إيجار لسنة كاملة مقدماً لمجرد استلام النقد). معظم الأطر التنظيمية المعتمدة (IFRS، US GAAP) والشركات الكبيرة تطلب المحاسبة على أساس الاستحقاق، لذلك فإن حسابات الإيرادات المؤجلة (التزام) والمصروفات المؤجلة (أصل) أساسية للامتثال لـ مبدأ المطابقة. (ملاحظة: غالباً ما يُستخدم مصطلحا “المصروفات المؤجلة” و “المصروفات المدفوعة مسبقاً” بالتبادل. فنظرياً، المصروفات المدفوعة مسبقاً تشير عادةً إلى التأجيلات قصيرة الأجل (لاستخدامها خلال السنة)، في حين يمكن أن تشير التكاليف المؤجلة أو المصروفات المؤجلة إلى تأجيلات طويلة الأجل تُحمل كأصول طويلة الأجل[4][4]. ومع ذلك، في الاستخدام اليومي، يغطي مصطلح “المصروفات المدفوعة مسبقاً” كلا الحالتين.)

ثانياً. المعايير وأُطر المحاسبة

المعيار الدولي للتقارير المالية 15 مقابل المعيار الدولي للمحاسبة 18 (الاعتراف بالإيرادات): شهدت معايير التقارير المالية الدولية (IFRS) تغيراً كبيراً في الاعتراف بالإيرادات عند دخول المعيار IFRS 15 “Revenue from Contracts with Customers” حيز التنفيذ (2018)، حيث حل محل المعايير الأقدم IAS 18 و IAS 11[5]. بموجب IAS 18، كان النهج أكثر عمومية – حيث يتم الاعتراف بإيرادات بيع السلع عند انتقال المخاطر والمنافع (غالباً عند التسليم)، ويتم الاعتراف بإيرادات الخدمات بناءً على مرحلة الإنجاز (غالباً بناءً على الوقت). أتاح هذا أحياناً للشركات هامشاً لتطوير سياساتها الخاصة[5]. قدم IFRS 15 نموذجاً مفصلاً مكوناً من خمس خطوات يركز على التزامات الأداء وانتقال السيطرة[5][5]. المبدأ الأساسي في IFRS 15 هو أن الإيراد يتم الاعتراف به عندما (أو أثناء) تفي الجهة بالتزام أداء من خلال نقل السيطرة على سلعة أو خدمة إلى العميل، بمبلغ يعكس المقابل الذي تتوقع الشركة استحقاقه[5]. عملياً، هذا يعني أنه إذا دفع العميل مقدماً، يظل الدفع في Contract Liability (الإيرادات المؤجلة) حتى يتم تسليم أو أداء السلع/الخدمات الموعودة. وعلى العكس، إذا قامت الشركة بتسليم منتج أو خدمة ولم تستلم الدفع بعد، يجوز لها الاعتراف بالإيراد (وإنشاء حساب ذمم) طالما كان التحصيل محتملًا. يسمح IFRS 15 بالاعتراف بالإيرادات إما على مدى فترة زمنية أو عند نقطة زمنية معينة حسب كيفية الوفاء بالتزامات الأداء. على سبيل المثال، الاشتراك في برنامج أو عقد خدمة يُنفذ بشكل مستمر خلال فترة معينة سيُعترف بإيراد متناسب خلال تلك الفترة، في حين أن بيع منتج أو إتمام مرحلة مشروع في تاريخ محدد سيؤدي إلى الاعتراف بالإيراد في تلك النقطة الزمنية. كما أدخل المعيار الجديد مصطلح “contract liability” للإشارة إلى الإيرادات المؤجلة/غير المكتسبة في الميزانية العمومية، مشدداً على أنها جزء من محاسبة أداء العقد. يجيز IFRS 15 صراحة أنماط الاعتراف القائمة على الإنجازات أو غير الخطية إذا كانت تعكس نقل السيطرة بصدق. في الواقع، بموجب IFRS 15 (والمعيار المماثل في الولايات المتحدة ASC 606)، يمكن للشركات استخدام طرق الإخراج (مثل الإنجازات المحققة أو الوحدات المسلمة) أو طرق الإدخال (مثل التكاليف المتكبدة أو الوقت المنقضي) للاعتراف بالإيرادات على مدى الزمن[6][7]. هذا يعني أن الاعتراف غير الدوري (مثلاً عند إتمام مرحلة أو تسليم) مسموح به طالما يعكس وقت تسليم القيمة للعميل. ما لا يسمح به IFRS 15 هو الاعتراف بالإيراد فقط بناءً على استلام النقد إذا لم تُسلم السلع/الخدمات – فالدفع وحده ليس سبباً للاعتراف بالإيرادات بموجب معايير الاستحقاق (الدفع مهم لمخاطر الائتمان، لكن كسب الإيراد يعتمد على الأداء). حتى يتم الوفاء بالتزامات الأداء، تظل المدفوعات المقدمة مسجلة كالتزامات (الإيرادات المؤجلة)[3].

المبادئ المحاسبية المقبولة عموماً في الولايات المتحدة (US GAAP) (ASC 606 و ASC 340): تقاربت المبادئ المحاسبية المقبولة عموماً في الولايات المتحدة مع IFRS من خلال ASC 606 (المعيار الجديد للاعتراف بالإيرادات تحت US GAAP) والذي يشبه تقريباً IFRS 15[5]. يستخدم ASC 606 نفس إطار العمل المكون من 5 خطوات للاعتراف بالإيرادات[3]، لذلك للأغراض العملية، تتعامل US GAAP الآن مع الإيرادات المؤجلة وتوقيت الاعتراف بها بنفس الطريقة التي يتبعها IFRS: حيث يتم الاعتراف بالإيرادات عند الوفاء بالتزامات الأداء (سواء على مدى فترة أو عند نقطة زمنية معينة)، وتؤدي المدفوعات المقدمة إلى تسجيل التزام (deferred revenue) حتى يتم كسب الإيراد. قبل ASC 606 (الذي دخل حيز التنفيذ عام 2018 لمعظم الشركات)، كانت US GAAP تحتوي على إرشادات صناعية خاصة – على سبيل المثال، غالباً ما تتبع شركات البرمجيات والاشتراكات قواعد متخصصة، وكان هناك مفهوم “طريقة الإنجاز المرحلية” للاعتراف بالإيرادات عند تحقيق مراحل معينة في صناعات مثل التكنولوجيا الحيوية[8][8]. وقد تم استبدالها إلى حد كبير بـ ASC 606 الموحد، والذي لا يزال يسمح بالاعتراف القائم على الإنجازات/الأحداث طالما يتماشى مع اكتمال الأداء. باختصار، كلا من IFRS 15 و ASC 606 يشترطان أن يكون التسليم أو الأداء هو العامل الأساسي لتحويل المبالغ من الإيرادات المؤجلة إلى الإيرادات الفعلية. ولا يسمحان بالاعتراف بالإيرادات لمجرد استلام النقد إذا لم تكتمل عملية الكسب – ففي المحاسبة على أساس الاستحقاق، الدفع المسبق يولد فقط التزاماً (وعد بالتسليم أو الاسترداد)[3].

في جانب المصروفات، تقدم US GAAP إرشادات محددة لتأجيل بعض التكاليف تحت ASC 340 (وخاصة ASC 340-40 “Other Assets and Deferred Costs – Contracts with Customers”). يوجه هذا المعيار إلى أنه يجب رسملة التكاليف الإضافية للحصول على عقد (مثل عمولات البيع) أو بعض تكاليف التنفيذ كأصل ويتم استهلاكها خلال فترة الاستفادة، بدلاً من تحميلها كمصروفات فوراً[9][9]. الفكرة هي مطابقة التكاليف مع نمط الاعتراف بالإيرادات: مثلاً، إذا دفعت عمولة للحصول على عقد لمدة 3 سنوات مع العميل، يجب عليك تأجيل تكلفة تلك العمولة والاعتراف بها على مدى نفس فترة الثلاث سنوات التي يُكسب فيها الإيراد[9][9]. هذا يجنب تشويه الأرباح الناتج عن تحميل جميع التكاليف دفعة واحدة بينما تتدفق الإيرادات لاحقاً[9]. لدى IFRS متطلب مماثل جداً (لكن مضمن ضمن IFRS 15 بدلاً من معيار منفصل): تنص فقرات IFRS 15 رقم 91 وما بعدها على أنه إذا كانت التكاليف للحصول على العقد إضافية ومتوقع استردادها، يجب الاعتراف بها كأصل واستهلالها خلال مدة العقد. وكذلك، يجب تأجيل تكاليف تنفيذ العقد التي لا تندرج تحت نطاق معايير أخرى (مثل المخزون أو الأصول الثابتة) إذا كانت تخلق منفعة اقتصادية مستقبلية وقابلة للاسترداد. جوهرياً، كلا من US GAAP و IFRS يسمحان بتأجيل المصروفات في شكل تكاليف مدفوعة مسبقاً أو أصول تكلفة عقد عند الاقتضاء، مما يضمن التناسق مع توقيت الإيرادات. بموجب هذه الأُطر، يعمل تسليم الخدمة/السلعة أو مرور فترة الاستفادة كعامل لتوقيت الاعتراف بالتكلفة، بدلاً من تاريخ دفع النقد.

ملخص المحاسبة على أساس الاستحقاق مقابل أساس النقد: تحت المعايير القائمة على الاستحقاق (IFRS/GAAP)، يتم الاعتراف بالإيرادات عند كسبها (التسليم/الأداء) والمصروفات عند تحملها/استخدامها، بغض النظر عن توقيت النقد، مما يستدعي وجود حسابات الإيرادات المؤجلة والتكاليف المؤجلة للمدفوعات المسبقة. بينما تحت أساس النقد البحت، يتم الاعتراف بالإيرادات عند استلام النقد والمصروفات عند دفع النقد – وبالتالي لا يتم تسجيل أي تأجيلات لأن مفهوم “الإيرادات المكتسبة وغير المستلمة” أو “المدفوعات المدفوعة وغير المستخدمة” غير موجود في السجلات[3]. معظم الأُطر التنظيمية (خصوصاً للشركات التي تقدم تقارير مالية عامة) لا تسمح بأساس النقد البحت للتقارير المالية لأنه قد يشوه الوضع المالي؛ ومع ذلك، قد تستخدم الشركات الصغيرة أو المحاسبة الضريبية في بعض النظم أساس النقد. قد تفرض بعض القوانين المحلية أو الضريبية تعديلات – مثلاً، قد تضع قوانين الضرائب حدوداً على تأجيل الإيرادات أو تتطلب فرض الضرائب فوراً على المدفوعات المقدمة. لكن بشكل عام، تحدد IFRS 15/ASC 606 مبدأً عاماً بأن الإيرادات تتبع التسليم، والقبوضات المقدمة تُسجل كالتزامات، بينما التكاليف المدفوعة مسبقاً تُسجل كأصول – مع استثناءات محتملة لفترات غير جوهرية أو إرشادات لمدة سنة واحدة (مثل بعض أنظمة الضرائب التي تسمح بخصم المصروفات المدفوعة مسبقاً وفقاً لـ “قاعدة 12 شهراً” للبساطة). كلا الإطارين يسمحان باستراتيجيات الاعتراف غير الدوري إذا كانت تعكس الأداء الفعلي. على سبيل المثال، إذا لم تُسلم الخدمة بشكل متساوٍ، ليس من الضروري الاعتراف بالإيرادات بشكل متساوٍ – يمكن الاعتراف بها على دفعات تتوافق مع مراحل التسليم. وبالمثل، إذا تم استهلاك مصروف (مثل حملة إعلانية مدفوعة مسبقاً) بشكل غير متساوٍ، يمكن استهلاكه وفقاً لنسبة المنفعة في كل فترة. المفتاح هو أن نمط الاعتراف يجب أن يعكس الواقع الاقتصادي للتسليم أو الاستهلاك للعناصر الأساسية.

ثالثاً. تحليل حالات الاستخدام – سيناريوهات الاعتراف المؤجل في الممارسة العملية

تحتاج تطبيقات ERP الحقيقية غالباً إلى استيعاب سيناريوهات مختلفة للإيرادات/المصروفات المؤجلة تتجاوز النهج القياسي للتوزيع الخطي. فيما يلي تحليل لحالات استخدام شائعة:

1. التأجيل القياسي حسب الفاصل الزمني (الاعتراف المبني على الوقت): هذه هي الحالة الكلاسيكية للاعتراف بالإيرادات أو التكاليف بشكل متساوٍ على فترة زمنية. مثال نموذجي هو اشتراك SaaS أو وثيقة تأمين: يدفع العميل مقدماً مقابل 12 شهراً من الخدمة، ويجب الاعتراف بالإيرادات شهرياً (1/12 من المبلغ كل شهر). وبالمثل، يتم الاعتراف بمصروف مدفوع مسبقاً مثل الإيجار السنوي كمصروف شهرياً. تنفذ العديد من الأنظمة هذا من خلال تقسيم المبلغ حسب الشهور أو الأيام. على سبيل المثال، إذا دُفع 12,000 دولار مقابل سنة من الخدمة، سيعترف النظام بـ 1,000 دولار شهرياً (أو مبالغ معدلة قليلاً إذا تم حساب النسبة حسب الأيام)[1]. هذا التأجيل الخطي مناسب عندما يتم تقديم الفائدة بشكل متساوٍ على مدى الوقت. فهو ينعم تأثير بيان الأرباح والخسائر ويطابق الإيرادات/المصروفات مع استخدام كل شهر. يدعم ERPNext هذا طبيعياً من خلال السماح لك بالتأجيل على عدد محدد من الأشهر وسيخصص المبالغ تلقائياً إما بالتساوي شهرياً أو تناسبياً حسب أيام كل شهر، وفقاً للإعدادات[1]. حالة الاستخدام: SaaS، اشتراكات الاتصالات، أقساط التأمين، رسوم الاحتفاظ – أي شيء حيث يكون الكسب مرتبطاً بالوقت. الافتراض الأساسي هو أن الخدمة لها قيمة تقريبية متساوية في كل فترة. إذا كان هذا صحيحاً، فإن جدول الفاصل الزمني (مثل قيود اليومية الشهرية) هو الأفضل.
2. الاعتراف المبني على التسليم/الاستلام (الاعتراف المبني على القابلية للتسليم): في بعض السيناريوهات، يجب الاعتراف بالإيرادات فقط عندما يتم تسليم البضائع أو تقديم الخدمات، حتى لو تم استلام الدفع أو إصدار الفاتورة مسبقاً. يحدث هذا كثيراً عندما يدفع العميل مقدماً مقابل بضائع سيتم شحنها على دفعات، أو يتم فوترته مقدماً مقابل منتج مشروع. تبقى المبالغ مؤجلة حتى يحدث التسليم. يتم الاعتراف بها دفعة واحدة أو بعدة دفعات تتوافق مع أحداث التسليم الفعلية. يجب دعم الاعتراف الجزئي – مثلاً، إذا تم دفع مقدماً مقابل 100 وحدة وتم تسليم 20 وحدة الآن، يتم الاعتراف بإيرادات هذه الـ 20 وحدة (ينتقل المبلغ من المؤجل إلى المبيعات الحقيقية)، بينما تبقى الباقي مؤجل حتى يتم شحن الوحدات المتبقية. ينطبق الأمر نفسه على جانب المصروفات: إذا دفعت للمورد مقدماً مقابل عدة تسليمات، تعامل مع المبلغ كأصل مدفوع مسبقاً واحتسب المصروف فقط للجزء المتعلق بكل تسليم عند استلام البضائع (أو تقديم الخدمات). هذا النموذج المرتبط بالتسليم يطابق الاعتراف بالإيراد/التكلفة مع انتقال الملكية أو إتمام الخدمة. وهو مستند بقوة إلى مبادئ الاستحقاق (الكسب عند التسليم) ومطلوب في سياقات مثل التصنيع أو مبيعات المعدات الثقيلة ذات التسليم المتدرج. حالة الاستخدام: لنفترض أن مصنع معدات بناء يبيع لعميل حزمة من 5 آلات بقيمة 500 ألف دولار، مدفوعة مقدماً لضمان الإنتاج. سيتم تسليم الآلات على مدى 5 أشهر (آلة واحدة شهرياً). لن يعتبر البائع مبلغ 500 ألف دولار إيراداً فورياً؛ بل يتم الاعتراف بـ 100 ألف دولار شهرياً عند تسليم كل آلة (تأكيد ذلك عبر مذكرة تسليم أو مستند مماثل)، مما يقلل الإيرادات المؤجلة تباعاً. هذا يضمن الاعتراف بالإيرادات عند الوفاء بكل التزام أداء (تسليم كل وحدة). المحاسبة المؤجلة القياسية في ERPNext تعتمد على الوقت بشكل افتراضي، لذا فإن تطبيق الاعتراف المبني على التسليم يتطلب عادة تخصيصاً (مناقش في القسم الرابع). مثال واقعي من صناعة الطيران: تذاكر الطيران المباعة مقدماً تعتبر إيرادات غير مكتسبة حتى يتم تقديم الخدمة (الرحلة). عند موعد إقلاع الرحلة، تعترف شركة الطيران بإيراد التذكرة. في حل ERPNext لشركات الطيران، تعامل المنفذون مع هذا من خلال ترحيل مبيعات التذاكر إلى حساب التزام “Unearned Revenue” ثم نقلها إلى الإيرادات عبر سكريبت عند إقلاع الرحلة[10]. هذا هو اعتراف مرتبط بالتسليم فعلياً، حيث أن “التسليم” هو إقلاع الرحلة. التسليمات الجزئية شائعة في صناعات أخرى أيضاً (مثل طلبية كبيرة تُشحن على دفعات)، لذلك يجب أن يسمح أي حل تأجيل بالتحويل الجزئي من المؤجل إلى الفعلي بناءً على كل سند استلام تسليم.
3. الاعتراف المبني على الدفع (الاعتراف المحفز بالدفع): في بعض الحالات، تختار الشركات الاعتراف بالإيرادات فقط عندما يدفع العميل فعلياً، بغض النظر عن حالة التسليم أو توقيت الفاتورة. هذا هو بشكل أساسي تعديل على أساس النقد داخل نظام الاستحقاق. بينما هذا ليس معيارياً بموجب IFRS/GAAP (الذي يركز على التسليم)، قد تبرره بعض سياقات الأعمال أو السياسات الداخلية. مثلاً، قد لا ترغب شركة ذات مخاطر ائتمانية عالية في تسجيل الإيرادات عند تسليم البضائع بالائتمان؛ قد تؤجلها ولا تعترف بالإيراد إلا بعد استلام النقد من العميل. هذا يتجنب تضخيم الإيرادات والأرباح إذا كان التحصيل غير مؤكد. وبالمثل في جانب المصروفات، قد تستلم الشركة بضائع أو فاتورة لكنها تختار (لأغراض التقارير الإدارية أو بعض المعايير المحلية) الاعتراف بالمصروف فقط بعد دفع المورد فعلياً. حالة الاستخدام: قد تصدر شركة تنفيذ برمجيات فاتورة عند إتمام المشروع (تم التسليم)، لكن إذا كان للعميل شروط دفع لمدة 90 يوماً، تؤجل الشركة الاعتراف بالإيراد حتى استلام الدفع، لتكون أكثر حذراً. أو فكر في شركة صغيرة تريد، للبساطة أو لأسباب ضريبية، مواءمة الاعتراف بالإيرادات مع التدفقات النقدية – أي تعمل على أساس النقد للإيرادات. في ERPNext، هذا ليس وضعاً مدمجاً (لأن الاستحقاق مفترض)، لكنه يمكن تحقيقه عن طريق تسجيل مبلغ الفاتورة أولاً كإيرادات مؤجلة ثم تفعيل الاعتراف عند تسجيل الدفعات. تؤدي الدفعات الجزئية إلى اعتراف جزئي متناسب بالإيرادات. مثلاً، إذا كانت الفاتورة 10,000 دولار (مؤجلة عند الفوترة) وسُددت على دفعتين بقيمة 5,000 دولار لكل منهما، يجب أن يعترف النظام بـ 5,000 دولار إيراد عند الدفعة الأولى و5,000 دولار الباقية عند الدفعة الثانية. هذا النموذج أقل شيوعاً في المحاسبة على أساس الاستحقاق الصارم، لكنه يُستخدم في بعض الحالات الواقعية (بما في ذلك بعض مستخدمي ERPNext الذين طلبوا ذلك لبيئات تنظيمية محددة). ملاحظة: يجب على الشركات التي تستخدم هذا الأسلوب التأكد من عدم تعارضه مع المعايير المحاسبية في نطاق اختصاصها – غالباً ما يُستخدم للتقارير الإدارية أو إذا سمح بذلك GAAP المحلي. قامت ClefinCode (مزود حلول ERPNext) بتخصيصات لتلبية طلبات التأجيلات القائمة على الدفع لعملاء يحتاجون إلى تطابق الإيرادات مع النقد؛ وهذا يوضح أن المنصة يمكن تمديدها للتعامل مع سيناريوهات محفزة بالدفع عندما يكون ذلك ضرورياً (المزيد عن التنفيذ في القسم الرابع).
4. النماذج المختلطة (الشروط المركبة): تستخدم بعض الشركات مزيجاً من المحفزات – حيث يجب استيفاء عدة شروط قبل الاعتراف بالإيراد أو المصروف. من النماذج المختلطة الشائعة:
5. الفاتورة + التسليم: تصدر الشركة فاتورة (غالباً لتحفيز الفوترة القانونية أو الدفع المقدم) لكنها لا ترغب في الاعتراف بالإيراد حتى يتم تسليم المنتج. في هذه الحالة، مجرد إصدار الفاتورة لا يكفي للاعتراف بالإيراد؛ يجب أن يحدث التسليم أيضاً. قد يكون القيد المحاسبي: عند إصدار الفاتورة، مدين لحساب الذمم المدينة، ودائن لحساب الإيرادات المؤجلة (بدلاً من المبيعات). عند إصدار مذكرة التسليم (تأكيد شحن البضائع أو تقديم الخدمة)، يتم مدين حساب الإيرادات المؤجلة ودائن حساب إيرادات المبيعات الفعلية. بعبارة أخرى، يجب وجود كل من الفاتورة وحدث التسليم. هذا النموذج مفيد للمبيعات التي تم فوترتها مسبقاً: مثلاً، إذا تم إصدار فاتورة للعميل بنسبة 100% قبل الشحن، يُسجل الذمم المدينة والتزام الإيرادات المؤجلة؛ ثم مع حدوث الشحنات، يُعترف بالإيراد. من منظور الرقابة الداخلية، يضمن هذا عدم الاعتراف بالإيرادات حتى يكون لدى العميل البضائع، رغم وجود فاتورة رسمية. إنه إجراء وقائي ضد الاعتراف المبكر بالإيرادات. تعاني العديد من أنظمة ERP من صعوبة التعامل مع هذا تلقائياً لأنها تفترض أن الفاتورة = الإيراد في المحاسبة على أساس الاستحقاق، لذا غالباً ما تحتاج إلى تخصيص (الإجراء الافتراضي في ERPNext هو تأجيل مبني على الوقت وليس مرتبط بأحداث التسليم). إحدى الحلول هي التعامل مع الفاتورة المبكرة كفاتورة proforma أو فاتورة مقدمة (دون تسجيل الدخل)، ولا يتم إصدار الفاتورة النهائية إلا عند التسليم؛ لكن إذا كانت اللوائح تطلب فوترة المقدمات، فإن نهج الإيرادات المؤجلة هو الصحيح. (في مثال هولندا على منتدى ERPNext، أشار المستخدمون إلى أن السلطات الضريبية تطلب فاتورة خلال 14 يوماً من أي دفعة، حتى المقدمة، لكن من الناحية المحاسبية يجب أن تُدين الفاتورة المقدمة حساب الإيرادات المؤجلة[11].)
6. الفاتورة + الدفع: في هذه الحالة، قد تصدر الشركة فاتورة (لأغراض التسجيل/المتابعة)، لكنها تعترف بالإيراد فقط بعد استلام الدفع. هذا يعني فعلياً وجود معيارين: أن يُصدر المبلغ فاتورة و أن يتم تحصيله. إذا تم إصدار فاتورة ولم تُدفع، يبقى الإيراد مؤجلاً. يمكن تكوين هذا بطريقة مماثلة عن طريق تسجيل ائتمان الإيرادات المؤجلة عند الفوترة، ثم تفعيل عملية تلقائية عند إدخال الدفع لتحويله إلى الإيراد. قد يكون هذا المزيج نتيجة سياسة داخلية أو للامتثال لمعيار معين (مثلاً، بعض عقود الحكومة أو المنظمات غير الربحية قد تعمل على نظام إيرادات أقرب إلى أساس النقد). كما يمكن أن يكون طريقة لإدارة الاعتراف بالإيرادات لفئات عملاء مختلفة – مثلاً “الاعتراف عند الدفع للعملاء ذوي المخاطر العالية، والاحتساب العادي للاستحقاق للآخرين” ضمن نظام واحد.
7. يمكن أن توجد تراكيب أخرى مثل الفاتورة + التسليم + الدفع، لكن عادة إذا كنت تطلب التسليم والدفع معاً، فهذا يعني أنك تؤجل حتى الحدث الأحدث من الاثنين (وغالباً ما يكون الدفع إذا جاء أخيراً). أو قد تعتمد شركة نموذج التسليم + الدفع بدون تحفيز الفاتورة (في سياق خدمات حيث يتم تقديم العمل والدفع على دفعات غير منتظمة).
8. هذه النماذج المختلطة قابلة للتكوين حسب الشركة أو العميل أو فئة المنتج. مثلاً، قد تدير مجموعة أعمال شركتين في ERPNext: شركة تعتمد التأجيل الزمني القياسي، وأخرى (ربما في بلد أو صناعة مختلفة) تعتمد سياسة تأجيل مبنية على التسليم. أو ضمن شركة واحدة قد تصنف العملاء: مثلاً العملاء الحكوميون – يستخدمون الاعتراف المبني على الدفع بسبب متطلبات المحاسبة الصارمة؛ العملاء الأفراد – يستخدمون نظام الاستحقاق العادي. وبالمثل حسب المنتج: مثلاً اشتراكات البرمجيات (تأجيل زمني)، مقابل المعدات المخصصة (تأجيل حتى التسليم)، مقابل خدمات الدعم (قد يتم الفوترة مجدولة والاعتراف حسب الساعات المقدمة). يجب أن يكون النظام مرناً لدعم هذه الاختلافات. واجه فريق ClefinCode مثل هذه الاحتياجات عملياً – مثل تطبيق الاعتراف بالإيرادات المبني على الإيصال/التسليم لعميل موزع، والاعتراف المبني على الدفع لعميل في الخدمات المالية – مما يظهر أن متطلبات التأجيل الواقعية متنوعة وتحتاج حلول مخصصة.

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

رابعاً. معالجة ERPNext الخاصة بالإيرادات والتكاليف المؤجلة

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

إعدادات المحاسبة المؤجلة في ERPNext. يوفر ERPNext إعدادات المحاسبة المؤجلة العامة ضمن وحدة الحسابات للتحكم في كيفية معالجة الإيرادات والتكاليف المؤجلة[1][1]. كما هو موضح في لقطة الشاشة، يمكنك تفعيل أو تعطيل الترحيل التلقائي للقيود المؤجلة، اختيار ما إذا كان يجب توزيع التأجيل حسب الأيام أو الشهور، وتحديد ما إذا كان يجب على النظام ترحيل قيود التأجيل عبر قيود اليومية (وكذلك ما إذا كان يجب تقديم تلك القيود تلقائياً)[1][1]. بشكل افتراضي، يعالج ERPNext تلقائياً قيود التأجيل في الخلفية عند نهاية الفترة، مقسماً المبالغ شهرياً (أو يومياً) حسب التكوين. هذا يعني إذا أجريت تأجيلاً لمبلغ 12,000 دولار على 12 شهراً بدءاً من يناير، يمكن أن يرحل 1,000 دولار كل شهر أو مبالغ معدلة قليلاً مثل 986.30 دولار لشهر 30 يوماً مقابل 1,019.17 دولار لشهر 31 يوماً إذا تم اختيار أساس “الأيام”[1]. تمنح هذه الإعدادات مرونة في مدى انتظام توزيع الجدول. بالإضافة لذلك، إذا تم تفعيل “ترحيل القيود المؤجلة عبر قيد اليومية”، سيقوم النظام بإنشاء مسودات قيود يومية لكل شهر اعتراف (بنمط سند خاص “Deferred Revenue” أو “Deferred Expense”) ليتمكن المحاسب من مراجعتها وتقديمها[1]. وإلا، فإن الوضع الافتراضي يرحل قيود دفتر الأستاذ مباشرة دون مستندات قيود منفصلة (مبسّط لكن مع وضوح أقل لتتبع التدقيق – مع ذلك، تبقى قيود GL موجودة في كل الأحوال).

تمكين التأجيل على الأصناف/الفواتير: عادةً ما يتم تكوين الإيرادات أو المصروفات المؤجلة في ERPNext على مستوى الصنف في عمليات البيع أو الشراء. في بطاقة الصنف، يمكنك تفعيل خيار الإيرادات المؤجلة أو المصروفات المؤجلة وتحديد الحساب المؤجل الافتراضي وعدد الأشهر للتأجيل لذلك الصنف[1]. على سبيل المثال، قد يكون لديك صنف “اشتراك سنوي” حيث تفعل الإيرادات المؤجلة، وتعين حساب “Deferred Revenue – Liability” وتحدد 12 شهراً. عند استخدام هذا الصنف في فاتورة المبيعات، سيعترف ERPNext تلقائياً بأن الإيراد يجب تأجيله. بدلاً من قيد الدائن في حساب الدخل العادي عند الفوترة، يقوم النظام بقيد الدائن في حساب الالتزام المؤجل المختار للمبلغ كاملًا[1]. كما تلتقط الفاتورة “تاريخ بدء الخدمة” و”تاريخ نهاية الخدمة” (يمكن إدخالهما يدوياً أو جلبهما بناءً على إعدادات الصنف) لتعريف فترة الاعتراف بالإيراد. بالنسبة للعميل، إذا كان يستخدم ERPNext أيضاً، ستظهر نفس المعاملة كمصروف مؤجل في جهته (مدين لأصل مصروف مدفوع مسبق). على جانب الشراء، التكوين مشابه: يمكن تعليم صنف كمصروف مؤجل مع حساب أصل وفترة. وعند استخدام ذلك الصنف في فاتورة الشراء، يُقيد الحساب مديناً في حساب المصروف المؤجل (الأصل) بدلاً من حساب المصروف[2]. مثلاً، يمكن لصنف “وثيقة تأمين لمدة 12 شهراً” أن يقيد التأمين المدفوع مسبقاً (أصل) عند حجز فاتورة المورد.

إعدادات بطاقة الصنف للإيرادات المؤجلة في ERPNext. مع وجود التكوين على مستوى الصنف، يقوم ERPNext بأتمتة قيود الاعتراف اللاحقة. في نهاية كل شهر (أو كل يوم، إذا كان التردد يومياً، رغم أن نهاية الشهر هي الأكثر شيوعاً)، ستنشئ عملية في الخلفية قيود اليومية اللازمة لنقل الجزء المناسب من الحساب المؤجل إلى حساب الدخل أو المصروف الفعلي[1]. مثلاً، لفاتورة مبيعات بقيمة 12,000 دولار مؤجلة على الفترة من يناير إلى ديسمبر، سيقوم ERPNext، في 31 يناير، بإنشاء قيد (أو قيد دفتر أستاذ) مديناً حساب الإيرادات المؤجلة بـ 1,000 دولار ودائنًا لحساب دخل المبيعات الفعلي 1,000 دولار؛ ثم في 28 فبراير يعترف بمبلغ 1,000 دولار آخر، وهكذا شهرياً حتى يتم الاعتراف بالكامل[1]. إذا كانت إعدادات “الإرسال التلقائي لقيد اليومية” معطلة، تبقى هذه القيود في وضع المسودة للمراجعة (يقوم النظام بتصنيفها كنوع “Deferred Revenue” أو “Deferred Expense” لزيادة الوضوح[12]). هناك أيضاً أداة Process Deferred Accounting في ERPNext تسمح بالتشغيل اليدوي أو مراجعة جدول التأجيل[13][13]. هي في الأساس سجل لمعالجة الإيرادات/المصروفات المؤجلة حيث يمكنك تحديد نطاق زمني ويقوم النظام بترحيل جميع قيود الاعتراف المعلقة حتى تاريخ معين[13]. هذه الأداة مفيدة للحاق بالركب (مثلاً، إذا كان الترحيل التلقائي معطلاً وتريد الترحيل ربع سنوي بدلاً من شهري، أو لمحاكاة ما سيتم الاعتراف به خلال فترة مستقبلية). باختصار، تغطي وظيفة ERPNext القياسية حالة الاستخدام “التأجيل القياسي حسب الفاصل الزمني” بشكل ممتاز: يمكنك تكوين عدد الأشهر التي يجب التأجيل عليها لكل صنف، وسيتولى النظام الباقي، محافظاً على توازن دفتر الأستاذ العام (ترحيل الفاتورة الأولي إلى الحساب المؤجل، ثم نقل تدريجي إلى الحساب الحقيقي مع مرور الوقت).

التخصيص للاعتراف المبني على التسليم: بشكل افتراضي، آلية التأجيل في ERPNext مدفوعة بالفواصل الزمنية، وليس بالأحداث الخارجية مثل مذكرات التسليم أو إتمام المشروع. ومع ذلك، ERPNext مبني على إطار عمل Frappe، الذي يسمح بتخصيص كبير عبر السكريبتات. لتنفيذ الاعتراف عند التسليم أو الاستلام، يمكن استخدام سكريبتات الخادم أو سكريبتات بايثون مخصصة التي تُشغل عند تقديم مذكرات التسليم (للمبيعات) أو استلام المشتريات (للمشتريات). الفكرة العامة: عند تقديم مذكرة تسليم، يتحقق السكريبت مما إذا كانت مرتبطة بأي فاتورة مبيعات تم تأجيل إيرادها. إذا كانت الإجابة بنعم، يحسب المبلغ الذي يجب الاعتراف به بناءً على الكمية أو القيمة التي تم تسليمها، وينشئ قيد يومية (أو قيد GL مباشر) يدين حساب الالتزام بالإيرادات المؤجلة ويقيد حساب الدخل الفعلي لذلك الجزء. قد يتطلب ذلك ربط صفوف أصناف مذكرة التسليم بأصناف الفاتورة الأصلية (ربما عبر أمر البيع أو رمز الصنف). ERPNext لا يدعم تلقائياً “التناسب” في الإيرادات المؤجلة حسب كمية التسليم، لذا يجب أن يتولى السكريبت هذا المنطق. على سبيل المثال، إذا كانت الفاتورة لـ 100 وحدة بسعر 100 دولار لكل منها (مجموع 10,000 دولار مؤجلة) وتم تسليم 20 وحدة الآن، سيولد السكريبت قيداً بقيمة 2,000 دولار للاعتراف بالإيراد، وربما يعلّم تلك 20 وحدة كمُعترف بها لتجنب العد المزدوج لاحقاً. تم تنفيذ هذا النوع من التخصيص في مثال شركة الطيران السابقة: حيث استمع سكريبت خادم مخصص لتغيير حالة وثيقة الرحلة إلى “Departed” ثم نقل إيرادات التذاكر المرتبطة من غير مكتسبة إلى مكتسبة[10]. في سيناريو المخزون الأبسط، يمكن أن يكون تقديم مذكرة التسليم هو المحفز. وبالمثل، بالنسبة لـ المصروفات المؤجلة على الاستلامات: عند تقديم مذكرة استلام مشتريات (أي استلام البضائع أو الخدمات)، يمكن للسكريبت نقل التكلفة النسبية من الأصل المدفوع مسبقاً إلى حساب المصروف الفعلي. يربط نموذج بيانات ERPNext فواتير الشراء والاستلامات عبر مراجع الأوامر، وهو ما يمكن للسكريبت استخدامه لتحديد الارتباط. نهج آخر (للتسليمات الجزئية) هو تقسيم الفوترة نفسها إلى أجزاء، لكن إذا أصر العمل على الفوترة الكاملة مقدماً، فإن قيود الاعتراف المخصصة هي الحل.

يتطلب تنفيذ الاعتراف المبني على التسليم إدارة الاعتراف الجزئي بعناية. أحد التصاميم المقترحة هو تتبع “الرصيد المؤجل المتبقي” لكل سطر في الفاتورة. يمكن أن يكون هذا حتى حقل مخصص يبدأ مساويًا لمبلغ الفاتورة ويتم تقليله مع كل تسليم. بعد ذلك، يقوم السكريبت بترحيل وخصم المبلغ وفقًا لذلك حتى يتم الاعتراف الكامل. من الحكمة أيضاً إدخال فحوصات – مثلاً، التأكد من عدم الاعتراف بإيرادات أكثر من المبلغ المؤجل أصلاً (في حالة التسليم الزائد أو الإرجاع). رغم أن ERPNext لا يحتوي على وحدة مدمجة لهذا السيناريو، فإنه يوفر كل نقاط الربط اللازمة: واجهة برمجة أحداث (Event API) (عند تقديم المستندات)، وظائف ترحيل قيود GL، وهيكل قاعدة بيانات متسق لربط المستندات. لذلك، مع بعض التخصيص البرمجي المتوسط، يمكن لنشر ERPNext التعامل مع تأجيلات معقدة مبنية على التسليم أو الإنجازات المرحلية. يمكن أن يقيم هذا التخصيص في تطبيق مخصص أو يتم عبر Server Script (ميزة في Frappe/ERPNext تسمح بكتابة شيفرات بايثون أو جافاسكريبت مباشرة في الموقع، تُنفذ عند أحداث المستندات، دون الحاجة لنشر تطبيق كامل).

التخصيص للاعتراف المبني على الدفع: الاعتراف المحفز بالدفع هو سيناريو آخر يتطلب تخصيصاً. يمكن استخدام مستند Payment Entry في ERPNext كمحفز. النهج سيكون: عند تقديم Payment Entry وتطبيقه على فاتورة تحتوي على إيرادات مؤجلة، يتم نقل المبلغ المقابل من الإيرادات المؤجلة إلى الإيرادات الفعلية. إذا كان الدفع يغطي الفاتورة بالكامل، يمكن الاعتراف بكامل المبلغ المتبقي المؤجل. إذا كان الدفع جزئياً، يتم الاعتراف بشكل نسبي. يعرف النظام تخصيص الدفع لفواتير محددة وحتى لأصناف فاتورة معينة (عبر جدول المراجع في Payment Entry). يمكن لسكريبت مخصص استغلال ذلك لتحديد مقدار الدائن من أي حساب إيرادات مؤجلة. مثلاً، إذا كانت فاتورة بقيمة 10,000 دولار مؤجلة وتم استلام دفعة بقيمة 4,000 دولار، يمكن الاعتراف بـ 4,000 دولار (على افتراض أن هذا الجزء يُعتبر مكتسباً لأن النقد دخل). مع ذلك، يجب النظر فيما إذا كان الدفع الجزئي يعني فعلاً الكسب الجزئي – ففي بعض الحالات قد يعني ذلك (مثلاً، إذا دفع العميل مقدماً مقابل 4 أشهر من أصل 10 أشهر خدمة). إذا لم يرتبط الدفع مباشرة بالجزء المسلّم، يجب أن تكون سياسة المحاسبة واضحة حول المعنى: هل الشركة تتوخى الحذر وتعترف فقط بما تم تحصيله نقداً (مع بقاء الباقي مؤجلاً حتى يتم تحصيله)؟ إذاً، ينفذ السكريبت هذا بالضبط. على جانب المصروفات، يمكن تطبيق منطق مماثل: عند دفع فاتورة مورد مؤجلة، يتم نقلها إلى المصروف. (هذا أقل شيوعاً إلا إذا كانت الشركة تحتفظ بسجلاتها على أساس الاستحقاق لكنها تريد رؤية نقدية للمصروفات – قد يحدث ذلك في بعض سيناريوهات محاسبة الصناديق أو تقارير إدارة التدفقات النقدية).

يمكن أن يكون منطق التأجيل المبني على الدفع مشروطاً أيضاً. يمكن توسيع ERPNext بحيث يحتوي كل Sales Invoice على حقل مثل “طريقة الاعتراف” بخيارات (الوقت، عند التسليم، عند الدفع). ثم يتصرف سكريبت مخصص وفقاً لذلك: إذا كان “عند الدفع”، سيتجاهل الجدول الشهري المعتاد وينتظر الدفعات فقط. هذا يقودنا إلى منطق لكل فاتورة أو لكل عميل.

منطق لكل فاتورة / لكل عميل / لكل صنف: بشكل افتراضي، يتم تكوين التأجيل في ERPNext على مستوى الصنف ويُطبَّق كلما تم بيع هذا الصنف. لتجاوز هذا على أساس حالة بحالة، يمكنك استخدام حقول مخصصة أو منطق سكريبت. على سبيل المثال، يمكن إضافة حقل إلى نموذج Sales Invoice، مثلاً “Deferral Trigger”، بخيارات: الوقت (شهري)، التسليم، الدفع. يختار المحاسب الوضع المناسب عند إنشاء الفاتورة (أو يمكن تعيينه تلقائياً بناءً على العميل أو الصنف). ثم تقوم بتوسيع المنطق بحيث:

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

نهج آخر هو استخدام مجموعات العملاء أو مجموعات الأصناف للتحكم بالمنطق بشكل شامل. مثلاً، وضع علامة على بعض العملاء كمجموعة “الاعتراف بالإيرادات على أساس النقد” ثم يقوم السكريبت بفحص: إذا كانت invoice.customer_group == “Cash Basis”، يؤجل حتى الدفع؛ وإلا يتم المعتاد. هذا يجنب الحاجة إلى تبديل يدوي لكل فاتورة، ويضمن تطبيق السياسة على مستوى بيانات رئيسية. ويمكن تطبيق نفس المنطق عبر مجموعات الأصناف (خطوط المنتجات).

تُعد مرونة ERPNext مع سكريبتات مخصصة (على جانب العميل أو الخادم) وأحداث المستندات من العوامل الأساسية هنا. لا حاجة لتعديل النواة – يمكنك استخدام الهياكل البيانية الحالية (الفواتير، قيود الدفع، مذكرات التسليم، قيود دفتر الأستاذ العام) وإضافة المنطق اللازم لتحريك المبالغ بين الحسابات عند استيفاء الشروط. قامت ClefinCode وشركاء ERPNext الآخرون بتنفيذ مثل هذه التخصيصات عملياً. على سبيل المثال، نفذت ClefinCode حلاً لمزود خدمة تعليمية قام بفوترة الطلاب مقدماً لدورة دراسية لكن أجل الاعتراف بالإيراد حتى حضور الطلاب الفصول (يشبه النموذج المبني على التسليم)؛ وفي حالة أخرى، فعّلوا الاعتراف بالإيراد على أساس الدفع لعميل يدير اشتراكات بمعدلات تخلف عالية (فكان الاعتراف شهريًا فقط إذا تم استلام القسط فعلاً). تم تحقيق ذلك بتوسيع إطار عمل التأجيل في ERPNext بإضافة محفزات وفحوصات، مما يوضح أن ERPNext v15 يمكن تشكيله لتلبية متطلبات معقدة مع بعض الجهد التطويري.

الحفاظ على دفتر أستاذ واضح (فصل الحسابات): سواء باستخدام الميزات القياسية أو المخصصة، من الضروري الحفاظ على المبالغ المؤجلة في حساباتها الصحيحة حتى الاعتراف بها. وهذا يعني إنشاء حسابات مخصصة في مخطط الحسابات لـ “Deferred Revenue” و “Deferred Expense” (عادة حسابات ضمن المطلوبات المتداولة للدخل المؤجل، وضمن الأصول المتداولة للتكاليف المدفوعة مسبقاً). غالبًا ما يشمل مخطط ERPNext الافتراضي مثل هذه الحسابات (غالباً باسم “Unearned Revenue” أو “Prepaid Expenses”). يجب أن تدخل كل التأجيلات هذه الحسابات، وكل الاعترافات تنقل الرصيد بوضوح إلى حسابات الدخل أو المصروف النهائية. يضمن هذا الفصل أن يظهر دفتر الأستاذ العام دائماً مقدار المبالغ غير المحررة (الموجودة في الميزانية العمومية) مقابل المحررة في بيان الأرباح والخسائر. عند التخصيص، يجب الحذر في استخدام مراجع الحسابات الصحيحة. مثلاً، إذا كان من المعتاد أن تقيد صنف في الفاتورة “Sales – Consulting” لكن تم تأجيله، يجب أن تقيد الفاتورة “Deferred Revenue – Consulting” بدلاً من ذلك. ثم قيد الاعتراف يدين حساب Deferred Revenue – Consulting ويقيد Sales – Consulting. التأثير الصافي بعد الاعتراف الكامل هو نفسه كما لو ذهبت للمبيعات أصلاً، لكن التوقيت مُتحكم فيه. إدارة التأجيل المدمجة في ERPNext تتعامل مع هذه القيود الحسابية تلقائياً إذا تم تكوينها على الصنف. في السكريبتات المخصصة، يجب على المطور التأكد من الإشارة إلى الحسابات الصحيحة (والتي قد تُخزن في الفاتورة أو بطاقة الصنف). من الممارسات الجيدة تخزين الحساب المؤجل والحساب الفعلي في سطر الفاتورة أو سجل مرتبط حتى يعرف السكريبت من أين وإلى أين يحرك المال.

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

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

خامساً. التقارير ومسار التدقيق

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

تقرير الأرصدة المؤجلة: أحد الطرق الأساسية للإبلاغ عن المبالغ المؤجلة هو مباشرة على الميزانية العمومية – حيث تظهر الإيرادات المؤجلة كالتزام (غالباً ضمن المطلوبات المتداولة إذا كان سيتم تحقيقها خلال سنة) والمصروفات المؤجلة كأصول. ومع ذلك، غالباً ما يرغب المديرون والمدققون في تقارير أكثر تفصيلاً. يتضمن ERPNext تقريراً مدمجاً بعنوان “Deferred Revenue and Expense” (في الإصدارات الأحدث) يعرض جدول المبالغ المؤجلة وما تم الاعتراف به. يمكن لهذا التقرير أن يسرد، مثلاً، كل بند إيراد مؤجل حسب الفاتورة أو حسب الحساب، مقدار المؤجل أصلاً، مقدار المعترف به حتى الآن، والرصيد المتبقي للاعتراف به. تم تحسين هذا التقرير في ERPNext v15.54 لضمان فصل البيانات حسب الشركة بشكل صحيح[14]. باستخدام مثل هذا التقرير، يمكن رؤية بسرعة في نهاية الفترة: “لدينا 50,000 دولار إيرادات مؤجلة في الدفاتر، منها 15,000 دولار ستُعترف في الربع القادم و35,000 دولار لاحقاً خلال السنة”، وهكذا. وبالمثل بالنسبة للتكاليف المؤجلة.

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

قابلية تتبع التدقيق: يرغب المدققون في تتبع عينة من المعاملات من البداية للنهاية: من الفاتورة الأولية إلى الاعتراف النهائي. مع ERPNext، إذا استخدمت طريقة قيد اليومية للاحتسابات المؤجلة، يحتوي كل قيد يومية على رابط للفاتورة الأصلية (تفاصيل قيد اليومية في ERPNext لديها حقول مثل “Against Invoice” عند الاقتضاء). حتى لو استُخدمت قيود دفتر الأستاذ المباشرة، يملأ النظام مراجع في جدول قيود دفتر الأستاذ تربط مرة أخرى بمعرف فاتورة المبيعات أو الشراء. في السكريبتات المخصصة، من الضروري أيضاً ربط المراجع بطريقة مماثلة. على سبيل المثال، إذا أنشأ سكريبت خادم مخصص قيد يومية عند التسليم، يجب أن يملأ حقل مرجعي أو على الأقل يضع وصفاً واضحاً (مثل “Recognized revenue for INV-0001, Delivery Note DN-0005”) في تعليق القيد. بهذه الطريقة، يمكن للمدقق اختيار فاتورة ورؤية: في البداية تم تسجيلها في حساب الإيرادات المؤجلة، ثم في تواريخ معينة تم ترحيل هذه القيود إلى الدخل – وتلك تقابل مستندات التسليم أو الدفع. يُحافظ على مسار التدقيق بالتأكد من توثيق كل حركة ومدعومة بحدث عمل.

يدعم ERPNext أيضاً إرفاق الملفات أو إضافة تعليقات للمعاملات، والتي يمكن استخدامها لتخزين الأدلة الداعمة (مثل إرفاق إثبات التسليم لقيد اليومية عند الحاجة).

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

المبالغ غير المحررة مقابل المعترف بها: من المفيد غالباً تقديم تقرير عن الإيرادات غير المكتسبة مقابل المكتسبة (أو التكاليف المدفوعة مسبقاً غير المصروفة مقابل المصروفة). بالنسبة للإيرادات، قد يكون هذا تقريراً حسب العقد أو العميل يظهر قيمة العقد الإجمالية، المبلغ المعترف به حتى الآن (كمُعترف به كإيراد)، والمبلغ المؤجل المتبقي. تقوم شركات المشاريع بذلك في تقارير Work-in-Progress. تتيح بيانات ERPNext إمكانية إنشاء تقرير مخصص أو لوحة تحكم لهذا الغرض. مثلاً، يمكن عمل تقرير يسرد كل قيود الإيرادات المؤجلة حسب الفاتورة مع أعمدة لتاريخ بدء الخدمة، تاريخ نهاية الخدمة، المبلغ الكلي، الإيرادات المعترف بها حتى الآن (مجموع قيود اليومية المنشورة)، والإيرادات المعلقة. ربما يوفر تقرير Deferred Revenue and Expense الكثير من هذا. بالإضافة لذلك، يمكن استخدام التحليلات: بما أن الإيرادات المؤجلة غالباً ما تشير إلى إيرادات مستقبلية، تتعامل بعض الشركات مع رصيد الإيرادات المؤجلة كمؤشر قيادي للأداء المستقبلي (مثلاً، في SaaS، الإيرادات المؤجلة وARR مرتبطان ارتباطاً وثيقاً). قد يكون من المفيد عرض اتجاه أرصدة الإيرادات المؤجلة مع مرور الوقت، ويمكن تحقيق ذلك عبر تقرير اتجاه Account Balance في ERPNext أو بتصدير البيانات.

من منظور الرقابة الداخلية، يجب مراجعة الحسابات المؤجلة دورياً لضمان عدم وجود مبالغ “عالقة” فيها بعد انتهاء الفترة المناسبة. على سبيل المثال، إذا كان من المفترض الاعتراف بصنف على مدى 12 شهراً بدءاً من العام الماضي وبعد 12 شهراً يجب أن يكون الرصيد صفر، لكن حساب الإيرادات المؤجلة لا يزال به رصيد، فهذا يشير إلى مشكلة (ربما لم يتم معالجة الجدول أو لم يُسجل تسليم). يمكن مراقبة قدم الإيرادات المؤجلة – مثلاً، تجميع الإيرادات المؤجلة حسب متى من المتوقع كسبها. إذا لاحظت مبالغ مؤجلة قديمة جداً دون حركة، فتحقق مما إذا كان يجب الاعتراف بها أو ردها.

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

باختصار، يشمل التقرير عن الإيرادات/المصروفات المؤجلة ما يلي:

1. تتبع الرصيد (كمية المؤجل في أي وقت معين)،
2. رؤية الجدول الزمني (متى وكيف ستؤثر في بيان الأرباح والخسائر)،
3. قابلية التتبع (ربط كل جزء من الإيراد/المصروف بمصدره وأحداث الاعتراف).

تقارير ERPNext المدمجة إلى جانب الاستعلامات المخصصة تغطي هذه الاحتياجات. من الممارسات الجيدة دمج المبالغ المؤجلة في تقارير الإدارة – على سبيل المثال، عرض “الإيرادات (على أساس الاستحقاق)” مقابل “الفواتير (على أساس النقد)” إذا دعت الحاجة، أو إبراز في البيانات المالية أن “الدخل يشمل $X للفترة الحالية و$Y تم تأجيله لفترات مستقبلية”.

سادساً. مرونة النظام واعتبارات التصميم

يتطلب تصميم نظام ERP قادر على التعامل مع طرق تأجيل متعددة توازناً بين المرونة والتحكم. نقترح هنا آليات تسمح للمالية أو مديري النظام بتكوين طرق الاعتراف ونتحدث عن المخاطر والضوابط المرتبطة.

طرق الاعتراف القابلة للتكوين: من المثالي أن يتم توسيع آلية التأجيل في ERPNext لتصبح مدفوعة بالسياسة. أحد النهج هو إدخال إعداد أو كائن بيانات رئيسي يحدد طريقة الاعتراف المستخدمة في السيناريوهات المختلفة. على سبيل المثال، قد يكون تكوين “سياسة التأجيل” عبارة عن جدول قواعد:

1. الشركة = ABC Ltd، مجموعة العملاء = “Government” → الطريقة = عند الدفع.
2. الشركة = ABC Ltd، مجموعة الأصناف = “Equipment” → الطريقة = عند التسليم.
3. الشركة = XYZ Inc (شركة فرعية) → الطريقة = شهرياً على مدى فترة الخدمة (الافتراضية).
4. إذا تطابقت عدة شروط، يمكن استخدام أولوية أو تجاوز محدد للمعاملة. في حالة عدم وجود قاعدة محددة، يُطبق الافتراضي العام (مثل التأجيل الشهري القياسي). يمكن تنفيذ محرك قواعد كهذا عبر السكريبتات أو DocType يمكن للمسؤول إدارتها. ولتسهيل الاستخدام، قد يحصل المسؤول على قائمة منسدلة بسيطة في إعدادات الحسابات: “الاعتراف بالإيرادات المؤجلة الافتراضي: [حسب الأيام/الأشهر | عند مذكرة التسليم | عند الدفع | يدوي]”. على سبيل المثال، اختيار “عند مذكرة التسليم” عالمياً سيخبر النظام بتأجيل كل فواتير المبيعات إلى حساب الالتزام ثم الاعتراف فقط عبر أحداث التسليم.

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

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

مخاطر المرونة: السماح بعدة طرق للاعتراف في نظام واحد يرفع حتماً من خطر الخطأ أو التلاعب:

1. تطبيق غير متسق: هناك خطر أن يختار المستخدمون الطريقة الخاطئة لعملية بيع معينة (سواء عن طريق الخطأ أو عمداً لتغيير النتائج المالية). مثلاً، تعليم فاتورة كـ “فوري” (بدون تأجيل) بينما يجب أن تؤجل سيؤدي إلى تضخيم الإيرادات مبكراً. وبالعكس، تأجيل شيء يجب أن يكون فورياً قد يقلل من الإيرادات. إذا كانت هناك خيارات كثيرة للمستخدمين، قد يؤدي ذلك إلى التباين. الضبط: لتقليل هذا، يجب أن يتضمن تصميم النظام منطق افتراضي وقيود. مثلاً، ربما فقط أدوار معينة يمكنها تجاوز طريقة الاعتراف الافتراضية. أو إذا تم تكوين صنف كـ مؤجل زمنياً، قد يحذر النظام أو يمنع تجاوز إلى “عند الدفع” بدون موافقة إضافية.
2. التدقيق والامتثال: تغيير الطرق يمكن أن يعقد مسارات التدقيق. يتوقع المدققون من الشركة اتباع سياسة اعتراف إيرادات متسقة. إذا سمح النظام بالتبديل بسهولة، يجب التأكد من أن يتم ذلك لأسباب مشروعة ومدون. الضبط: يجب تسجيل تغييرات إعدادات المستوى الإداري (من غير غيّر، متى) ومن الأفضل أن تتطلب سبباً. كما يجب أن تعرف السياسات الداخلية متى تكون كل طريقة مناسبة (مثلاً، “الاعتراف المعتمد على الإنجازات يستخدم فقط لمشاريع تنفيذ بسعر ثابت كما وافق المدير المالي”).
3. إدارة الانتهاء والفترات: إذا تغيرت الطريقة في منتصف العملية، هناك خطر العد المزدوج أو الحذف. مثلاً، إذا تم تعيين عملية بيع بدايةً كمعترف بها زمنياً واعتُرف بشهر من الإيرادات، ثم غيرها شخص إلى طريقة التسليم واعتُرف بالتسليم الكامل – دون عكس، قد يتم العد مرتين لشهر واحد. الضبط: من المحتمل أن يقفل النظام طريقة الاعتراف لمعاملة معينة بعد بدء الترحيل، أو يعالج التحولات بحذر (بتعديلات يدوية). التحكم القوي في النسخ أو حظر التغييرات بعد ترحيل الفاتورة هو قاعدة معقولة.
4. تعقيد للمستخدمين: خطر آخر هو ببساطة إرباك المستخدمين. إذا كان على مندوبي المبيعات أو المحاسبين اختيار من بين عدة خيارات تأجيل لكل معاملة، قد يرتكبون أخطاء. قد يبطئ ذلك أيضاً معالجة الفواتير. التخفيف: استخدم الأتمتة لتعيين الطريقة كلما أمكن (حسب الصنف أو العميل كما سبق). اجعل واجهة المستخدم بسيطة – ربما تظهر الخيار فقط عندما لا يكون واضحاً من السياق.

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

1. مراجعة جميع قيود الإيرادات المؤجلة الكبيرة أو غير العادية من قبل محاسب أول أو مراقب.
2. التسوية الدورية للحسابات المؤجلة مع الجداول الأساسية، كما ذُكر في قسم التقارير.
3. إذا سُمح بعدة طرق، توفير ضابط لضمان استخدام الطريقة الصحيحة لكل نوع عقد (مثلاً، قائمة تحقق عند إدخال عقد مبيعات جديد: “هل يتضمن مراحل تسليم؟ إذا نعم، تأكد من تعليم العقد للاعتراف المعتمد على التسليم”).
4. يمكن تطبيق فصل الواجبات: ربما الشخص الذي يصدر الفواتير لا يمكنه تغيير إعدادات التأجيل بدون موافقة؛ أو تحتاج قيود الاعتراف (خصوصاً اليدوية) إلى موافقة.

عند تمكين منطق تأجيل مرن في ERPNext، يجب النظر في إضافة طبقة من الموافقة أو التحقق للحالات الخاصة تلك. مثلاً، يمكن إنشاء سير عمل بحيث إذا وُسمت فاتورة بـ “الاعتراف اليدوي” أو طريقة غير قياسية، يتم تحويلها إلى مدير للموافقة قبل الترحيل.

تصميم النظام للطرق الهجينة: قد يسمح تصميم قوي بمحفزات مركبة بطريقة قابلة للتكوين. أحد التصاميم المفاهيمية:

1. يمكن أن يحمل كل سطر في الفاتورة عدة أعلام مثل defer_till_delivery = Yes/No، defer_till_payment = Yes/No، وdefer_over_time = Yes/No مع فترة زمنية. ثم يكون المنطق أن كل الشروط المعلمة بـ "نعم" يجب أن تُستوفى للاعتراف. مثلاً، سطر فاتورة به delivery=yes, payment=yes يعترف فقط بعد التسليم وأيضاً الدفع. سطر به delivery=yes, payment=no, time=yes (6 months) قد يعني “الاعتراف على مدى 6 أشهر بدءاً من بعد التسليم” – سيناريو معقد قليلاً لكنه قد يكون عقداً حيث يتم الفوترة مقدماً، والتسليم حدث واحد، لكن الخدمة/الدعم يستمر 6 أشهر بعد التسليم لذا الإيرادات مكتسبة على مدى 6 أشهر بعد ذلك الحدث. يمكن للنظام الانتظار حتى حدث التسليم ثم يبدأ مؤقت 6 أشهر للاعتراف بالإيرادات. بينما ERPNext لا يدعم هذا تلقائياً، يمكن بناء مثل هذا المنطق مخصصاً.
2. جانب تصميم آخر هو جعله مودولارياً: استخدام كائنات منفصلة لمحفزات مختلفة. مثلاً، يمكن أن يحتوي ERPNext على DocType بعنوان “Deferred Revenue Schedule” الذي يكون افتراضياً قائماً على الوقت، لكن يمكنك أيضاً إدخال أحداث فيه. يمكن لمذكرة تسليم تحديث إدخال جدول أو تعليم جزء على أنه محقق.

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

مخاطر تعطيل منطق التأجيل: إذا قام شخص ما بإيقاف التأجيلات بالكامل (مثلاً تعطيل الميزة في إعدادات الحسابات بحيث يذهب كل الدخل مباشرة إلى بيان الأرباح والخسائر)، فإن الخطر يكمن في عدم الامتثال لمعايير الاستحقاق إذا كانت الأعمال فعلاً تستلم دفعات مقدمة. قد يؤدي ذلك إلى تحريف مادي في النتائج المالية. لذلك، يجب اتخاذ أي قرار لتعطيل أو تجاوز التأجيل بحذر. إحدى الضوابط الداخلية يمكن أن تكون تشغيل فحوص دورية لأي أرصدة كبيرة في حساب سلف العملاء غير معوضة بقيود الإيرادات المؤجلة – قد يشير ذلك إلى أن الإيرادات تم الاعتراف بها خطأً. وبالمثل، إذا كان خيار “المعالجة التلقائية للمحاسبة المؤجلة” معطلًا في ERPNext (مما يعني أن القيود لن تُرحل إلا يدويًا)، فهناك خطر نسيان ترحيلها. أحد الضوابط التعويضية هو وجود قائمة مراجعة إغلاق شهرية تتضمن “معالجة قيود الإيرادات المؤجلة” ومراجعة سجل Process Deferred Accounting.

باختصار، يجب أن يصاحب بناء المرونة في ERPNext للتأجيلات ما يلي:

1. واجهات تكوين واضحة (لكل شركة، لكل صنف/عميل أو لكل فاتورة)،
2. سلوكيات افتراضية تقلل التدخل اليدوي،
3. تسجيل وموافقة على التغييرات،
4. توثيق السياسات المتوافقة مع إعدادات النظام،
5. المراقبة الدورية للنتائج لضمان عمل منطق التأجيل كما هو مقصود (مثلاً، عدم وجود أرصدة غريبة، توقيت الإيرادات الصحيح).

السابع. اعتبارات إضافية

عند التعامل مع الإيرادات والمصروفات المؤجلة، يجب الانتباه إلى بعض العوامل الإضافية عبر الجوانب القانونية والضريبية وسياقات الأعمال:

الاعتبارات القانونية/التعاقدية: في بعض الصناعات أو الولايات القضائية، قد يكون الاعتراف بالإيرادات قبل أن تُعتبر “مكتسبة” قانونياً مشكلة. على سبيل المثال، إذا كان للعميل الحق القانوني في استرداد المال حتى تُكتمل الخدمة بالكامل، فلا يجب على الشركة الاعتراف بتلك الإيرادات (وغالباً لا تفعل ذلك بموجب IFRS/GAAP). من الضروري ضمان توافق إعدادات التأجيل في ERP مع شروط العقود. إذا نص العقد على “الدفع مقدمًا ولكن يمكن استرداده إذا لم يكتمل التسليم”، فهذا مؤشر قوي على وجوب وضع كل هذه المبيعات ضمن الإيرادات المؤجلة حتى النقطة التي لا يمكن فيها الاسترداد (عادة التسليم). أحياناً تفرض قواعد تنظيمية (خارج معايير المحاسبة) تعريفاتها الخاصة بموعد اعتبار الخدمة مُسلَّمة. من المهم معرفة هذه القواعد وضبط ERP وفقها.

الاعتبارات الضريبية: المحاسبة الضريبية قد تختلف عن المحاسبة المالية. تعترف العديد من الجهات الضريبية بالدخل على أساس النقد أو لديها قواعد محددة للتأجيلات. على سبيل المثال، في الولايات المتحدة، عادةً ما تتطلب القوانين الضريبية (IRC) الأساس على الاستحقاق للشركات الكبيرة، لكنها توفر استثناءات مثل “تأجيل الدفعات المقدمة للسلع” حتى سنة في بعض الحالات، أو قاعدة الـ 12 شهراً للمصروفات المدفوعة مسبقاً (حيث يمكن خصم بعض المصروفات المدفوعة مسبقاً عند الدفع إذا كانت فترة الاستفادة أقل من 12 شهراً)[15][16]. عملياً، قد تحتفظ الشركات بسجلات ضريبية منفصلة للدخل. يمكن لـ ERPNext أن يُستخدم لتتبع الاثنين (عبر دفاتر منفصلة أو وسم)، لكن غالباً ما تُدار التعديلات الضريبية خارجياً أو في قيود نهاية السنة. سيناريو شائع: تؤجل الإيرادات لأغراض الدفاتر، لكن قد تطلب منك هيئة الضرائب دفع ضريبة على تلك الدفعة المقدمة (خصوصاً ضريبة القيمة المضافة أو ضريبة المبيعات كما سنناقش أدناه). من الضروري التمييز بين التأجيل الدفتري والتأجيل الضريبي. عادةً يتبع دفتر الأستاذ الرئيسي في ERPNext قواعد الدفاتر (IFRS/GAAP). إذا كانت هناك حاجة لمعالجة ضريبية مختلفة، قد تُستخدم البيانات المالية المخصصة في ERP أو مجموعة موازية من الحسابات لتعديل الضريبة. على سبيل المثال، تستخدم بعض الشركات نموذج قيد اليومية في ERPNext في نهاية السنة لعكس بعض التأجيلات لأغراض حساب الضريبة إذا دعت الحاجة. لكن بما أن سؤال المستخدم يتعلق بمعالجة النظام، فنحن نفترض التركيز على جانب الدفاتر/المحاسبة.

الضرائب غير المباشرة (VAT/GST وغيرها): لا يغير المحاسبة عن الإيرادات المؤجلة عادةً توقيت استحقاق VAT/GST على البيع. في معظم الولايات القضائية، تُحفز ضريبة القيمة المضافة عند إصدار الفاتورة أو استلام الدفعة، وليس عند الاعتراف بالإيراد في دفتر الأستاذ. هذا يعني أن الشركة قد تسجل إيرادات مؤجلة (التزام) في دفاترها لكنها ما تزال مطالبة بدفع ضريبة القيمة المضافة على تلك الدفعة المقدمة في الفترة التي صدرت فيها الفاتورة أو استلمت فيها النقود. يدعم ERPNext هذا بشكل طبيعي: عند إصدار فاتورة مبيعات، يحسب VAT على المبلغ الكامل ويسجل تلك الضريبة في حساب الضرائب المستحقة، حتى لو كان صافي المبيعات يُرحل إلى الإيرادات المؤجلة. الإيرادات المؤجلة فقط على المبلغ الصافي (بدون VAT)، لأن VAT ليست إيراداً للشركة – إنها التزام تجاه الحكومة. مثلاً، إذا أصدرت فاتورة بـ 10,000 دولار + 10% VAT = 11,000 دولار لخدمة سيتم تقديمها في السنة القادمة. ستكون قيود الفاتورة غالباً: مدين حساب العملاء بـ 11,000 دولار؛ دائن الإيرادات المؤجلة بـ 10,000 دولار؛ دائن ضريبة القيمة المضافة المستحقة بـ 1,000 دولار. الـ 1,000 دولار تذهب لسلطات الضرائب في الفترة الحالية، بينما الـ 10,000 دولار تبقى في الإيرادات المؤجلة حتى تُكتسب. هذا له أثر مهم على التدفق النقدي: تأجيل الإيرادات لا يؤجل دفع الضريبة (إلا إذا كانت القوانين المحلية تسمح بنظام VAT على أساس النقد، كما في بعض الدول للشركات الصغيرة – حيث تدفع الضريبة أيضاً عند استلام النقود، ولكن حتى في هذه الحالة تُستحق الضريبة عند الاستلام بغض النظر عن التسليم). من ناحية المصروفات، إذا دفعت مصروفاً مقدماً وشُحنت عليه VAT، يمكنك غالباً المطالبة بضريبة المدخلات فوراً (حسب الاختصاص) بمجرد حصولك على فاتورة صالحة، حتى لو كان المصروف مؤجلاً في الدفاتر. في ERPNext، تسجل فاتورة الشراء ضريبة المدخلات في الحساب المناسب (غالباً في فترة الفاتورة). إذن المحاسبة الضريبية والتأجيلية تسيران على مسارات منفصلة. الخلاصة: يجب أن يضمن التعامل مع الإيرادات المؤجلة في ERPNext معالجة التزامات الضرائب في الوقت المناسب. حسابات الضريبة والتقارير (إقرارات VAT، إلخ) تعتمد على الفواتير والمدفوعات، لا على ما إذا كان الدخل في بيان الأرباح والخسائر أو مؤجلاً. لذا من منظور تصميم النظام، لا حاجة لشيء خاص سوى الوعي بأن بيان الأرباح والخسائر قد لا يتطابق مع المبيعات الخاضعة للضريبة في فترة معينة إذا استُخدم الكثير من التأجيلات. غالباً ما تحافظ فرق المالية على تسوية بين إيرادات المحاسبة وإيرادات الضريبة لهذا السبب. قد يطلب المدققون ومفتشو الضرائب رؤية جداول الإيرادات المؤجلة لضمان عدم وجود إيرادات “تفلت” دون ضرائب – لكن بما أن فواتير ERPNext هي المحرك للضريبة، فهذه المخاطرة منخفضة.

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

1. الإيرادات والربحية: إذا باعت شركة عقداً كبيراً لمدة سنتين بقيمة 120,000 دولار وأخذته بالكامل كإيراد فوراً، سيرتفع إيراد الربع الواحد بمقدار 120,000 دولار وقد تبدو الأرباع التالية خالية، وهذا لا يعكس أن الشركة مشغولة فعلاً بخدمة ذلك العقد على مدى عامين. بالتأجيل، قد تظهر 15,000 دولار إيراد كل ربع لمدة 8 أرباع، مما يعطي اتجاه أداء أكثر اتساقاً ويطابق الإيراد بفترات تقديم الخدمة. هذا يؤدي إلى تحليل أكثر موثوقية لهامش الربح الإجمالي و<م>الربح التشغيلي من فترة إلى أخرى. يتم تقليل القفزات أو الانخفاضات المفاجئة إلا إذا تباطأت الأعمال أو تسارعت فعلاً.
2. MRR/ARR (الإيرادات المتكررة الشهرية / السنوية): في SaaS، تُراقب الإيرادات المؤجلة عن كثب. تساعدك تأجيلات ERPNext في حساب مقاييس مثل ARR – فالإيرادات المؤجلة (بالإضافة للإيرادات) تساعد في استنتاج إجمالي قيمة العقد. غالباً ما ينظر المستثمرون إلى نمو الإيرادات المؤجلة كدليل على نمو المبيعات في أعمال الاشتراك. ضمان تكوين ERPNext بشكل صحيح لتأجيل إيرادات الاشتراك يعني أنه يمكنك بثقة الإبلاغ عن مقاييس مثل “الفواتير” مقابل “الإيرادات المعترف بها”. العديد من مقاييس SaaS، مثل معدل التراجع (churn)، القيمة العمرية للعميل (LTV)، تعتمد على توقيت الاعتراف الذي يتماشى مع تقديم الخدمة.
3. التدفق النقدي مقابل الإيرادات: تساعد الإيرادات المؤجلة أيضاً في فصل التدفق النقدي عن الإيرادات في التحليل. يحتوي ERPNext على تقارير مثل بيانات التدفق النقدي حيث تُدرج سلف العملاء (زيادة الإيرادات المؤجلة) كدخل نقدي تشغيلي منفصل عن الدخل. زيادة صحية في الإيرادات المؤجلة تعني دخول نقدي لخدمات مستقبلية – وهو مؤشر إيجابي على السيولة – لكن بيان الدخل يظل معتدلاً حتى يتم تقديم تلك الخدمات.
4. النسب المالية: تتأثر بعض النسب بالتأجيلات. مثلاً، النسبة الحالية (الأصول المتداولة / المطلوبات المتداولة) ستشمل الإيرادات المؤجلة ضمن المطلوبات المتداولة، مما قد يجعل الشركة تبدو أكثر مديونية – لكن هذا ليس سيئاً إذا كانت تلك إيرادات غير مكتسبة (غالباً ما يدل على مبيعات قوية للاشتراكات). قد يضيف المحللون في الواقع الإيرادات المؤجلة لبعض التحليلات، معتبرين إياها أكثر “تشغيلية”. يجب أن يسمح ERP بشرح هذه الأمور عند الحاجة.
5. الإفصاح عن التزامات الأداء: يتطلب IFRS 15 الإفصاح عن التزامات الأداء المتبقية (الإيرادات المؤجلة غير المكتسبة). لذلك تكشف الشركات غالباً عن مقدار الإيرادات المؤجلة التي سيتم الاعتراف بها في المستقبل (مثلاً “سيتم الاعتراف بـ $X العام القادم، و$Y في العام الذي يليه”). مع ERPNext، يمكن استخراج هذه المعلومات بسهولة إذا كانت التأجيلات متتبعة بالتواريخ – يمكنك جمع كل الإيرادات المؤجلة التي لها تاريخ نهاية خدمة يتجاوز السنة الحالية للحصول على رقم الإفصاح هذا.

الاعتبارات الصناعية: يشير السؤال بشكل خاص إلى أن هذا يجب أن ينطبق عبر صناعات مثل SaaS، التصنيع، الخدمات، وغيرها. لقد تناولنا ذلك: تعتمد SaaS والخدمات بشكل كبير على التأجيلات القائمة على الوقت (أو المعالم لمشاريع الخدمات)، بينما تعتمد الصناعات التحويلية ومبيعات المنتجات على الاعتراف القائم على التسليم (خصوصًا مع الدفعات المقدمة)، وحالات أخرى مثل عقود البناء/العقود طويلة الأجل قد تستخدم نسبة الإنجاز (وهو فعلياً شكل من أشكال الاعتراف على مدى الوقت، وربما يتطلب جدولة أكثر تعقيدًا – وهو شيء يمكن لـ ERPNext القيام به عبر وحدة المشاريع أو قيود اليومية اليدوية). غالبًا ما تمتلك شركات الخدمات المهنية (الاستشارات، الوكالات) اتفاقيات احتفاظ أو فواتير معالم، والتي تتماشى مع التأجيلات الزمنية أو محفزات التسليم (المعلم = إتمام القابل للتسليم يحفز الإيراد). قد تحتوي شركات الاتصالات والإعلام على حزم اشتراك معقدة؛ يتطلب IFRS 15 تقسيمها إلى التزامات أداء – يمكن لـ ERPNext التعامل مع كل مكون (مثلاً تأجيل جزء الخدمة، والاعتراف الفوري بمبيعات الأجهزة، إذا تم الإعداد لكل صنف). يسمح تصميم النظام الذي ناقشناه بالتكوين لكل صنف، وهذا بالضبط ما تستخدمه في سيناريو الحزمة: مثلاً، عقد جوال قد يحتوي على هاتف (الصنف: إيرادات الأجهزة الفورية) وخطة خدمة لمدة 12 شهرًا (الصنف: مؤجل على 12 شهرًا). يمكن لـ ERPNext فعل ذلك مباشرة عبر تمييز صنف خطة الخدمة كإيراد مؤجل لـ 12 شهرًا بينما الهاتف هو صنف عادي.

مساهمات المجتمع والمدخلات الواقعية: ساهم مجتمع ERPNext في تحسين ميزات المحاسبة المؤجلة (على سبيل المثال، يقترح رقم القضية على GitHub #41238 إضافة معالجة الإيرادات/المصروفات المؤجلة في نماذج قيود اليومية لمزيد من المرونة[17]). ساعدت النقاشات على المنتدى في تشكيل ميزات مثل تقرير الإيرادات المؤجلة وإصلاح أخطاء الحالات الخاصة[14]. تُظهر تجارب ClefinCode المذكورة في كافة أجزاء النص كيف يُطبق معرفة المجتمع: تنفيذ أحد أعضاء المجتمع لحلول شركات الطيران بإيرادات التذاكر غير المكتسبة، وأخرى لشروط فواتير مخصصة لمعالم – وقد شاركوا هذه الخبرات مما أدى غالبًا إلى تحسينات عامة في المنتج الأساسي. كون ERPNext مفتوح المصدر يعني أنه إذا أصبح نمط التأجيل معين شائعًا، فقد يساهم به أحدهم في الكود الأساسي في المستقبل (مثلاً، ميزة لربط الاعتراف بالإيراد المؤجل بحالة مذكرة التسليم ستكون إضافة مرحب بها).

الخلاصة: تجمع معالجة الإيرادات والتكاليف المؤجلة في ERPNext v15 بين الوظائف القياسية التي تتماشى مع مبادئ IFRS/GAAP والقدرة على التخصيص لتلبية الاحتياجات الأكثر تعقيدًا. المفاهيم الأساسية هي إبقاء المبالغ غير المكتسبة في الميزانية العمومية والاعتراف بها في بيان الأرباح والخسائر فقط عندما يتم الوفاء بالتزام الشركة أو تحقيق الفائدة – سواء حدث ذلك بشكل متساوٍ على مدى الوقت، أو عند حدث معين، أو عند الدفع. من خلال استغلال إعدادات ERPNext للتأجيلات الزمنية وتوسيعه بمنطق مخصص لمحفزات الحدث أو الدفع، يمكن للمؤسسة البقاء متوافقة مع معايير المحاسبة (IFRS 15 / ASC 606 للإيرادات، IAS 38 / ASC 340 للتكاليف) مع تلبية متطلبات التقارير الداخلية. تضمن التقارير القوية والضوابط حول هذه العمليات الشفافية والدقة. يمكن لكل صناعة تطبيق هذه المبادئ: تضمن شركات SaaS تنعيم إيرادات الاشتراكات، وترتبط الصناعات التحويلية بالإيرادات وفقًا للشحنات، وتطابق شركات الخدمات الإيرادات مع الأعمال المنجزة أو المدفوعات المستلمة حسب الحاجة. مع قدرات ERPNext وتنفيذ مدروس، تصبح معالجة الإيرادات والمصروفات المؤجلة عملية قابلة للإدارة والتدقيق، محولة تحدي المحاسبة المعقد إلى سير عمل مؤتمت بشكل جيد في النظام.