How ERP Systems Work: Modules, Data Flow, and the Ledger Underneath
One transaction followed through every module of an ERP, with the actual journal entries, and why the general ledger is the record everything else reads.
يعمل نظام تخطيط موارد المؤسسات (ERP) عن طريق تخزين كل حدث تجاري مرة واحدة في قاعدة بيانات مشتركة واحدة، مما يتيح لكل وحدة قراءة هذا السجل المشترك والكتابة عليه. فالطلب المشحون هو نفس السجل بغض النظر عما إذا كان مستودع التخزين، أو فريق المبيعات، أو المحاسب هو من يطلع عليه. أما الوحدة التي تحافظ على سلامة النظام بأكمله فهي دفتر الأستاذ العام (General Ledger): حيث ينتهي مطاف كل حدث ذي قيمة مالية كقيد يومية متوازن فيه، ويتم استخراج كل تقرير من تلك القيود.
تتتبع هذه المقالة عملية بيع واحدة عبر الوحدات المختلفة، وتوضح قيود اليومية الناتجة عنها، وتشرح سبب كون التكامل مع نظام الـ ERP متعلقاً بالأحداث ودفتر الأستاذ بدلاً من شاشات العرض.
قاعدة البيانات المشتركة
قبل ظهور أنظمة الـ ERP، كان كل قسم يدير برنامجه الخاص. فقد كان المخزون يقبع في نظام المستودعات، والفواتير في نظام الفوترة، والدفتر المحاسبي في برنامج محاسبة منفصل. وكان وقت إقفال الشهر يُستهلك بالكامل في إجراء مطابقة بين هذه الأنظمة الثلاثة. يشرح مقال ما هي برمجيات تخطيط موارد المؤسسات هذه الفئة من البرمجيات، بينما تتمثل الآلية التي تجعلها تعمل في نموذج بيانات موحد يتم فيه ما يلي:
- استخدام سجل شريك (Partner) مشترك بين المبيعات والمشتريات ودفتر الأستاذ على حد سواء،
- احتواء سجل الصنف (Item) على كمية المخزون، وطبقات تكلفة الوارد أولاً يصرف أولاً (FIFO)، وسعر البيع، وحساب الإيرادات،
- ارتبط المستند (الطلب، الفاتورة، إشعار الدائن، الشراء، أمر الإنتاج) بالشركاء والأصناف لإنتاج مجموعة واحدة بالضبط من قيود اليومية،
- ارتبط قيد اليومية (Journal Entry) بالمستند الذي أنشأه، بحيث يمكن تتبع كل رقم في أي تقرير وصولاً إلى مصدره.
وعندما تتشارك الأقسام هذه السجلات، فلا توجد حاجة لإجراء مطابقة بين الوحدات المختلفة. وما يتبقى للمطابقة هو العالم الخارجي فحسب، أي كشوفات الحسابات البنكية والإقرارات الضريبية.
خريطة الوحدات
| الوحدة | عمليات الكتابة | عمليات القراءة |
|---|---|---|
| المبيعات | الطلبات، الفواتير، إشعارات الدائن | الشركاء، الأصناف، الأسعار، قواعد ضريبة القيمة المضافة |
| المشتريات | أوامر الشراء، فواتير الموردين | الشركاء، الأصناف، حسابات المصروفات |
| المخزون | حركات المخزون، طبقات تكلفة الوارد أولاً يصرف أولاً (FIFO)، جرد المخزون | الأصناف، المستودعات |
| الإنتاج | أوامر الإنتاج، استهلاك المكونات، المنتجات التامة | قوائم المواد (BOM)، المخزون |
| البنك | المعاملات المستوردة، مطابقات المدفوعات | الفواتير المفتوحة، الحسابات البنكية |
| الرواتب | مسيرات الرواتب، الاشتراكات، الإقرارات | الموظفون، العقود، جداول الضرائب |
| الأصول | سجل الأصول، عمليات الإهلاك | مجموعات الأصول، الأعمار الإنتاجية |
| الضرائب | إقرارات ضريبة القيمة المضافة، قوائم المبيعات الأوروبية، نظام إنتراستات (Intrastat)، الفواتير الإلكترونية | المستندات الصادرة والمُسجلة |
| دفتر الأستاذ العام | قيود اليومية، إقفال الفترات المحاسبية | كل ما سبق |
| التقارير | لا شيء | دفتر الأستاذ العام ودفاتر الأستاذ الفرعية |
تنتهي كل صف عدا الصفين الأخيرين بعملية كتابة في دفتر الأستاذ العام. وتلك هي القاعدة التصميمية التي تميز نظام الـ ERP عن مجموعة من الأدوات المتصلة ببعضها.
تدفق عمل تجريبي للبيانات
يستخدم المثال أدناه نقاط النهاية (Endpoints) الخاصة بـ Nordlet والحسابات الافتراضية لشجرة الحسابات الليتوانية المرفقة معه. يقوم أي نظام ERP بنفس الخطوات، مع اختلاف رموز الحسابات وأسماء نقاط النهاية.
1. الطلب
يُنشئ المتجر الإلكتروني طلباً عبر POST /v1/ecommerce/orders/create: شريك، بنود تتضمن أصنافاً وكميات، وبلد الشحن. لا يتم ترحيل أي شيء إلى دفتر الأستاذ بعد. فالطلب يمثل التزاماً وليس معاملة مالية.
2. حجز المخزون
تؤدي نقطة النهاية orders/reserve إلى حجز الكميات جانباً حتى لا يتمكن طلب ثانٍ من بيع نفس الوحدات. ولا يزال قيد اليومية غائباً هنا أيضاً، فالمخزون المحجوز يظل مملوكاً للشركة.
3. إتمام الطلب (Fulfilment)
تسجل نقطة النهاية orders/fulfill خروج البضائع من المستودع. وهنا يحدث أمران في معاملة قاعدة بيانات واحدة:
- يُستهلك المخزون بناءً على تكلفة الوارد أولاً يصرف أولاً (FIFO): حيث يتم استخدام أقدم طبقات التكلفة لكل صنف أولاً، وهي الطريقة المشروحة في مدخل مسرد المصطلحات الخاص بـ تقييم مخزون الوارد أولاً يصرف أولاً.
- تُرحَّل تكلفة تلك الوحدات كقيد يومية: مدين حساب تكلفة البضاعة المباعة، ودائن حساب المخزون.
| الحساب | مدين | دائن |
|---|---|---|
| 6000 تكلفة البضاعة المباعة | 600.00 | |
| 2040 المخزون | 600.00 |
ينشئ إتمام الطلب أيضاً مسودة فاتورة (Draft Invoice) للطلب، ويحدد المعاملة الضريبية لضريبة القيمة المضافة بناءً على بلد الشحن باستخدام محرك ضريبة القيمة المضافة الأوروبي.
4. إصدار الفاتورة
إصدار الفاتورة هو اللحظة التي يتم فيها الاعتراف بالإيراد لعملية بيع تتم في نقطة زمنية محددة. يحصل المستند على رقمه المتسلسل الخالي من الفراغات، ويتم ترحيل قيد متوازن واحد: الإجمالي إلى المدينين، وضريبة القيمة المضافة إلى حساب ضريبة المخرجات، والصفو إلى حساب الإيرادات.
بالنسبة لعملية بيع صافية بقيمة 1,000 يورو تخضع لضريبة القيمة المضافة في ليتوانيا بنسبة 21%:
| الحساب | مدين | دائن |
|---|---|---|
| 2410 الذمم المدينة (العملاء) | 1,210.00 | |
| 5000 إيرادات المبيعات السلع | 1,000.00 | |
| 4492 ضريبة القيمة المضافة المستحقة (المخرجات) | 210.00 |
إذا كان البند يحمل طريقة اعتراف بالإيراد تختلف عن نقطة الزمن المحددة، فإن الصافي يذهب إلى الإيرادات المؤجلة بدلاً من ذلك، ويقوم محرك الاعتراف بالإيرادات بتحريره وفقاً للجدول الزمني المحدد. أما ترحيل الذمم المدينة وضريبة القيمة المضافة فلا يتغير.
يمكن إرسال الفاتورة الآن على شكل ملف PDF، أو فاتورة إلكترونية بصيغة Peppol BIS 3.0، أو بالصيغة الوطنية للفاتورة الإلكترونية التي تفرضها دولة الشركة.
5. مطابقة البنك
بعد أسبوعين، يصل مبلغ 1,210 يورو. وتصل هذه الحركة عبر تغذية بنكية بنظام الخدمات المالية المفتوحة (PSD2) أو استيراد كشف حساب بصيغة camt.053. تقوم وحدة البنك بتقييم الفواتير المرشحة بناءً على المبلغ، ومرجع الدفع، واسم الطرف المقابل، ورقم الحساب المصرفي الدولي (IBAN)، وتقوم نقطة النهاية bank/transactions/match بتسجيل التسوية:
| الحساب | مدين | دائن |
|---|---|---|
| 2710 البنك | 1,210.00 | |
| 2410 الذمم المدينة (العملاء) | 1,210.00 |
تتغير حالة الفاتورة إلى مدفوعة، ويتم إطلاق خط Webhook من نوع sale_invoice.paid. يشرح مدخل مسرد المصطلحات الخاص بـ مطابقة المدفوعات منطق المطابقة بمزيد من التفصيل. أما الدفع بعملة أخرى فيسجل فروق أسعار العملات المحققة في حساب الأرباح أو الخسائر في نفس الخطوة.
6. إقرار ضريبة القيمة المضافة
عند نهاية الشهر، لا يتم إدخال أي بيانات يدوياً. يتم احتساب إقرار ضريبة القيمة المضافة من المستندات الصادرة والمُسجلة: عبر declarations/eu/vat-return/compute للإقرار المحلي (FR0600 في ليتوانيا)، أو عبر declarations/eu/oss/compute لمبيعات المستهلكين العابرة للحدود بموجب آلية نافذة خدمة واحد (OSS) للاتحاد الأوروبي. وتستقر عملية البيع المذكورة أعلاه في خانة الأسعار القياسية للإقرار المحلي نظراً لأن نظام ضريبة القيمة المضافة الخاص بها هو domestic.
7. إقفال الفترة المحاسبية
بمجرد تقديم الإقرار، تقوم نقطة النهاية ledger/periods/lock بإغلاق الشهر. ومنذ تلك اللحظة فصاعداً، يتم رفض أي قيد يُؤرَّخ في تلك الفترة، بما في ذلك المطابقات البنكية المتأخرة أو طلبات واجهة برمجة التطبيقات (API) التي يتم إعادة إرسالها، برمز خطأ HTTP 409. يؤدي الإقفال أيضاً إلى تحفيز الاعتراف بأي إيرادات مؤجلة مستحقة حتى نهاية الفترة، بحيث لا يمكن إقفال الشهر وبقاء إيرادات مكتسبة عالقة في حساب الالتزامات.
لماذا يُعد دفتر الأستاذ نظام السجلات المعتمد
تحتفظ كل وحدة من الوحدات المذكورة أعلاه بدفتر أستاذ فرعي (Subledger) خاص بها: الذمم المدينة حسب العميل، الذمم الدائنة حسب المورد، المخزون حسب الصنف، والأصول حسب الأصل. ويحتفظ دفتر الأستاذ العام بالإجماليات التي يجب أن تتطابق معها دفاتر الأستاذ الفرعية تلك. يغطي مقال دفتر الأستاذ الفرعي مقابل دفتر الأستاذ العام هذه العلاقة؛ أما الناحية العملية فتتمثل في أن التقرير المُعد من دفتر الأستاذ والتقرير المُعد من دفتر الأستاذ الفرعي يجب أن يعطيا نفس الرقم تماماً، ويضمن نظام الـ ERP ذلك عن طريق إنتاجهما معاً من نفس قيود اليومية.
تمنح ثلاثة خصائص دفتر الأستاذ موثوقية عالية كسجل أساسي:
- فرض التوازن المحاسبي: في نظام Nordlet، ترفض قاعدة البيانات أي قيد لا يتساوى فيه الجانب المدين مع الجانب الدائن. وبالتالي، لا يمكن لأي خطأ برمجي (Bug) في أي وحدة إنشاء قيد غير متوازن.
- السجلات تاريخية وغير قابلة للتعديل (Append-only): لا يتم تعديل القيد المُرحَّل أبداً. بل يتم تصحيح أي خطأ عن طريق إنشاء قيد عكسي وقيد جديد، على أن يكون كلاهما مرتبطاً بالقيد الأصلي. يوضح مدخل مسرد المصطلحات الخاص بـ دفتر الأستاذ غير القابل للتعديل سبب إصرار المراجعين الخارجيين على هذه القاعدة.
- إقفال الفترات: لا يمكن تغيير الشهر المقفل، مما يعني أن الأرقام التي أقررتها هي نفسها الأرقام الباقية في النظام.
التكامل: الأحداث ومعالجة التكرار الآمن بدلاً من الدفعات الليلية
اعتمدت عمليات التكامل القديمة لأنظمة الـ ERP على ملفات يتم تبادلها ليلياً: تصدير الطلبات، استيرادها، ثم التحقق من سجل الأخطاء في الصباح. أما أنظمة الـ ERP الحديثة فتتيح واجهة برمجة تطبيقات (API)، ليصبح التكامل مسألة تتمحور حول مبدأين أساسيين.
الأحداث الصادرة (Events out): عندما يتغير أي شيء، يبلغك نظام الـ ERP بذلك. يكتب نظام Nordlet كل حدث Webhook في صندوق الصادر (Outbox) ضمن نفس معاملة قاعدة البيانات التي تم فيها التغيير، وبذلك فإن أي مستند تم التراجع عنه لا يصدر أي حدث أبداً، ولن يتم ضياع أي حدث. يتم توقيع عمليات التسليم باستخدام خوارزمية HMAC-SHA256 وإعادة محاولة إرسالها باستخدام التراجع الأسي (Exponential Backoff). وبدلاً من أن يسأل نظامك كل خمس دقائق عما إذا تم دفع الفاتورة أم لا، فإنه يتفاعل مباشرة مع الحدث sale_invoice.paid.
إعادة المحاولة الآمنة الواردة (Safe retries in): تتعرض الشبكات للأعطال، ويجب ألا يؤدي الطلب الذي يتم إعادة إرسالها إلى إنشاء فاتورة ثانية. يقبل نظام Nordlet ترويسة Idempotency-Key في كل طلب تعديل: فالمفتاح نفسه الذي يحمل نفس الحمولة (Payload) يعيد الاستجابة المخزنة، بينما يُرفض المفتاح نفسه إذا حمل حمولة مختلفة، وتنتهي صلاحية المفاتيح بعد 24 ساعة. يصف مدخل مسرد المصطلحات الخاص بـ منع تكرار العمليات (Idempotency) واتفاقيات واجهة برمجة التطبيقات (API conventions) السلوك الدقيق لذلك.
ونظراً لأن كل عملية تشكل استدعاء لنقطة النهاية POST /v1/{module}/{resource}/{action} وأن التطبيق يستخدم نفس نقاط النهاية، يمكن لعملية التكامل تشغيل تدفق العمل بأكمله المذكور أعلاه دون أن يفتح أي شخص أي شاشة عرض. يشرح مقال كيفية دمج واجهة برمجة التطبيقات المحاسبية السحابية في منصة برمجيات كخدمة (SaaS) خطوات بناء مثل هذا النظام.
ما تقرأه التقارير
لا تقوم التقارير بتخزين الأرقام، بل هي عبارة عن استعلامات تُجرى على دفتر الأستاذ ودفاتر الأستاذ الفرعية في نقطة زمنية محددة:
- ميزان المراجعة، الميزانية العمومية، قائمة الدخل، وقائمة التدفقات النقدية: تقرأ قيود اليومية حسب الحساب والفترة المحاسبية.
- تقادم الديون (Debt aging): يقرأ الذمم المدينة والدائنة المفتوحة حسب تاريخ الاستحقاق.
- رصيد المخزون وحركته: يقرأ دفتر الأستاذ الفرعي للمخزون وطبقات تكلفة الوارد أولاً يصرف أولاً (FIFO) الخاصة به.
- ملخص ضريبة القيمة المضافة: يقرأ بنود ضريبة القيمة المضافة للمستندات الصادرة والمُسجلة.
- تقارير مراكز الكسب (Cost-center reports): تقرأ بُعد مركز التكلفة على كل سطر من سطور القيود اليومية.
في نظام Nordlet، يتم إنشاء التقرير في الخلفية بصيغة XLSX أو PDF أو JSON، ويتم إطلاق خط Webhook عندما يصبح الملف جاهزاً. أما أرقام المجموعات فتأتي من عملية توحيد القوائم المالية (Consolidation)، والتي تدمج دفاتر أستاذ لعدة شركات مع ترجيح الملكية وتحويل العملات.
أين يفشل هذا النظام في الواقع العملي
معظم مشكلات أنظمة الـ ERP تعود إلى إخفاقات في مبدأ السجل المشترك وليس في البرمجيات بحد ذاتها. ومن أبرز الحالات الشائعة:
- وجود جدول بيانات موازٍ (Spreadsheet) لأمر ما يعجز نظام الـ ERP عن فعله بحسب زعمهم، مما يؤدي في النهاية إلى تعارضه مع الدفاتر المحاسبية.
- استخدام قيود يومية يدوية لتصحيح مخرجات الوحدات بدلاً من تصحيح المستند الأساسي، مما يقطع سلسلة التتبع من التقرير إلى المصدر.
- عمليات التكامل التي تكتب الأرصدة بدلاً من المستندات، بحيث يصبح دفتر الأستاذ محوَلاً لإجماليات لا يمكن لأحد تفسير مصدرها.
- ترك الفترات المحاسبية مفتوحة دون إقفال لأشهر عديدة، مما يؤدي إلى انحراف الأرقام المُقررة للربع الماضي.
يغطي مقال لماذا تفشل مشاريع تطبيق أنظمة الـ ERP كيفية نشوء هذه الممارسات العادات أثناء عملية طرح النظام، بينما يوضح مقال الجداول الزمنية الواقعية لتطبيق أنظمة الـ ERP المرحلة التي تظهر فيها عادة خلال المشروع.
FAQ
ما هو جوهر نظام تخطيط موارد المؤسسات (ERP)؟
دفتر الأستاذ العام ونموذج البيانات المشترك المحيط به. حيث تكتب كل وحدة مستندات تنتج قيود يومية متوازنة، ويتم اشتقاق كل تقرير من تلك القيود.
كيف تتسلسل البيانات عبر نظام الـ ERP؟
يتم تسجيل الحدث مرة واحدة كمستند (طلب، فاتورة، حركة مخزون، مسير رواتب). وينتج عن المستند قيود يومية في دفتر الأستاذ وحركات في دفتر الأستاذ الفرعي ذي الصلة. ويتم احتساب التقارير والإقرارات الضريبية من تلك السجلات، دون الحاجة لنسخ أي بيانات بين الوحدات.
ما الفرق بين الوحدة (Module) وعملية التكامل (Integration)؟
تكتب الوحدة بياناتها في نفس قاعدة البيانات ونفس دفتر الأستاذ الذي يستخدمه باقي النظام. أما عملية التكامل فهي برنامج خارجي يستدعي واجهة برمجة التطبيقات (API) الخاصة بنظام الـ ERP. ومع أنظمة الـ ERP المصممة بواقع برمجة تطبيقات أولاً (API-first)، يصبح هذا الفرق ضئيلاً للغاية، لأن التكامل يستخدم نفس نقاط النهاية التي تستخدمها وحدات النظام نفسها.
هل يقوم نظام الـ ERP ترحيل القيود المحاسبية تلقائياً؟
نعم. إصدار فاتورة، إتمام طلب، مطابقة دفعة مالية، تشغيل مسير الرواتب، أو إهلاك أصل؛ ينتج عن كل إجراء من هذه الإجراءات قيد يومية خاص به دون أن يحتاج أي شخص لبناء الجانبين المدين والدائن يدوياً. وتُستمد الحسابات المستخدمة من قواعد الترحيل التي يمكن تعديلها لكل شركة على حدة.
لماذا تقفل أنظمة الـ ERP الفترات المحاسبية؟
لكل تتوقف الأرقام المُبلغ عنها أو المُقرة لفترة معينة عن التغير لاحقاً. ترفض الفترة المقفلة أي قيود جديدة، مما يحمي مسار التدقيق (Audit trail) ويجبر المستخدمين على إجراء التصحيحات في الفترة الحالية حيث تكون مرئية للجميع.