كل صاحب نشاط في السعودية يبدأ بدفتر اليومية التقليدي، يقيد مبيعاته ومصروفاته في عمودَي مدين ودائن، ثم يكتشف بعد سنة أو سنتين أن هذه الطريقة لم تعد كافية. أنت تعرف كم بعت، لكن لا تعرف لأي عميل ولا في أي فرع ولا أي مورد كان السبب. تعرف كم دفعت رواتب، لكن لا تعرف كم ساعة عمل قابلت كل ريال. الأرقام موجودة، لكن العلاقات بينها مفقودة.
نموذج البيانات REA (Resources, Events, Agents) هو إجابة محاسبية حديثة على هذا الفراغ. وضعه البروفيسور William McCarthy عام 1982 كبديل لدفتر اليومية المزدوج في الأنظمة الإلكترونية، ويقوم على فكرة بسيطة جدًا: كل عملية اقتصادية في شركتك تتكون من 3 عناصر فقط، مورد يدخل أو يخرج، حدث يحرّك هذا المورد، وطرف بشري أو مؤسسي يقف خلف الحدث. هذه الثلاثية تكفي لتوليد كل تقرير محاسبي تحتاجه، مع ميزة إضافية أن البيانات تظل متصلة بالعميل والموظف والمنتج والفرع.
في هذا الدليل نشرح نموذج REA بلغة عملية لصاحب نشاط ومحاسب سعودي، من الجذور النظرية إلى تطبيقه داخل دورة المبيعات ودورة المصروفات، مرورًا بربطه بالفوترة الإلكترونية المرحلة الثانية، وصولًا إلى كيف يُجسّده قيود داخل النظام دون أن يطلب منك أن تتعلم نظرية محاسبية جديدة. القالب المرفق يساعدك على رسم نموذج REA لشركتك في ورقة عمل واحدة قبل أن تنقله إلى أي نظام (ERP).
قالب نموذج REA جاهز بصيغة Excel و Google Sheets
ورقة عمل تحصر موارد شركتك وأحداثها وأطرافها، مع خرائط جاهزة لدورة المبيعات والشراء والإنتاج والرواتب، وأمثلة سعودية وحقول ضريبة القيمة المضافة 15% ومتطلبات الفوترة الإلكترونية المرحلة الثانية.
ما هو نموذج البيانات REA ومن وضعه
REA اختصار لثلاث كلمات: Resources (موارد)، Events (أحداث)، Agents (أطراف). وهو نموذج بيانات محاسبي قدّمه البروفيسور William McCarthy في جامعة ميتشيغان عام 1982 في ورقة بحثية بعنوان “The REA Accounting Model” نُشرت في مجلة The Accounting Review. الفكرة الأساسية كانت أن دفتر اليومية المزدوج صُمم في القرن الخامس عشر لخدمة الدفاتر الورقية، وأن قواعد البيانات الحديثة تستطيع تخزين المعلومة المحاسبية بشكل أغنى دون الحاجة إلى تجريدها في عمودَي مدين ودائن.
في النموذج التقليدي، عندما تبيع منتجًا بقيمة 1000 ريال، يقيّد النظام في دفتر اليومية: مدين عملاء 1000، دائن مبيعات 1000. هذا القيد دقيق محاسبيًا، لكنه يُسقط معلومات مهمة: من هو العميل؟ من هو الموظف الذي أتم البيع؟ أي منتج بالضبط؟ من أي مخزن؟ في أي وقت؟ تُخزَّن هذه التفاصيل في جداول مساعدة، لكن العلاقة بينها وبين القيد المحاسبي تبقى ضعيفة.
REA يقلب المعادلة. بدلًا من القيد ثم التفاصيل، يبدأ من الحدث الاقتصادي نفسه (بيع بقيمة 1000 ريال)، ويربطه مباشرة بالمورد (المنتج المُسلّم والنقد المستلم) وبالأطراف (العميل والبائع). القيد المحاسبي يُولَّد لاحقًا تلقائيًا من هذه البيانات. النتيجة: قاعدة بيانات واحدة تخدم المحاسبة والمبيعات والمخزون والموارد البشرية دون ازدواج.
الجذر النظري
McCarthy استند إلى نموذج Entity-Relationship الذي طوّره Peter Chen عام 1976 لقواعد البيانات. فكرة Chen أن العالم يتكون من كيانات وعلاقات بينها، وأن أي نظام معلومات يجب أن يعكس هذه البنية بدل اختراع بنية موازية. McCarthy طبّق هذا على المحاسبة: الكيانات الاقتصادية ثلاثة (موارد، أحداث، أطراف)، والعلاقات بينها كافية لتوليد كل ما يحتاجه المحاسب.
الانتشار
منذ التسعينيات، تبنّت أنظمة (ERP) الكبرى مفاهيم REA دون أن تُسمّيها بالاسم. كل نظام محاسبي حديث تستخدمه اليوم، بما فيها قيود، يخزّن البيانات بنمط قريب من REA ويُولّد دفتر اليومية كطبقة تقارير فوقها. أنت تقيّد بيعًا لعميل في النظام، فيظهر القيد المزدوج في دفتر اليومية تلقائيًا، دون أن تكتبه يدويًا.
لماذا يستبدل ERP الحديث دفتر اليومية بنموذج REA
دفتر اليومية المزدوج اختراع رائع للقرن الخامس عشر، لكنه يحمل قيودًا تظهر بوضوح حين تنتقل من الورق إلى البرمجيات. أولها أن القيد المحاسبي تجريد، يُسقط البعد العملي للحدث ويُبقي على الأثر المالي فقط. ثانيها أن الربط بين القيد وبيانات العميل والمنتج يحدث عبر جداول جانبية، فتنشأ ازدواجية مستمرة بين سجلات المحاسبة وسجلات المبيعات والمخزون.
REA يحل هذه القيود بطريقتين عمليتين. الأولى: حذف الجداول الجانبية الزائدة. بدلًا من جدول للعملاء في وحدة المبيعات وجدول مكرر للعملاء في وحدة المحاسبة، يوجد جدول واحد للأطراف (Agents) يُستخدمه الجميع. الثانية: حفظ الحدث الاقتصادي كما حدث فعلًا، بكل تفاصيله، ثم استخراج القيد المحاسبي منه عند الحاجة. لو احتجت تقريرًا غير مالي (مثلًا: كم عميلًا اشترى منتجًا معينًا في الربع الماضي)، تستخرجه من نفس البيانات دون أن تذهب لجداول أخرى.
- وحدة بيانات واحدة: العميل والمنتج والموظف موجودون مرة واحدة في النظام، ويستخدمهم المحاسب والبائع وأمين المخزن بنفس السجل.
- تقارير مرنة: لأن البيانات مخزّنة بتفاصيلها الكاملة، تستطيع توليد تقارير مالية وغير مالية من نفس المصدر.
- دقة في التتبع: كل حدث اقتصادي يحمل توقيتًا دقيقًا وطرفًا مسؤولًا، مما يسهّل التدقيق الداخلي والخارجي.
- توافق مع الفوترة الإلكترونية: متطلبات هيئة الزكاة والضريبة والجمارك في المرحلة الثانية تتطلب بيانات تفصيلية لكل فاتورة، وهي بيانات يخزّنها REA أصلًا.
- قابلية التوسع: عند إضافة وحدة جديدة (CRM، إدارة مشاريع، شؤون موظفين)، تتصل بنفس قاعدة الأطراف والأحداث دون تكرار.
المكونات الثلاثة بالتفصيل: الموارد والأحداث والأطراف
قبل أن تبني نموذج REA لشركتك، يجب أن تفهم بدقة ما تعنيه كل كلمة من الثلاث، لأن الأخطاء في تطبيق REA كلها تقريبًا تنشأ من خلط بين هذه الفئات.
الموارد (Resources)
كل شيء له قيمة اقتصادية في شركتك ويمكن أن يُكتسَب أو يُستهلَك أو يُحوَّل: المنتجات والخدمات التي تبيعها، المواد الخام التي تشتريها، النقد في الصناديق والبنوك، الذمم المدينة عند العملاء، الذمم الدائنة عند الموردين، الأصول الثابتة (المعدات، السيارات، الأثاث)، حتى ساعات عمل الموظفين تُعتبر موردًا. الشرط أن يكون قابلًا للقياس ماليًا.
الأحداث (Events)
أي عملية اقتصادية تحرّك موردًا. البيع حدث، الشراء حدث، استلام النقد حدث، صرف الراتب حدث، استلام بضاعة في المخزن حدث، تحويل مواد خام إلى منتج تام الصنع حدث. الحدث في REA دائمًا له طرفان متبادلان (Duality): حدث يأخذ موردًا وحدث آخر يعطي موردًا في المقابل. مثلًا، بيع منتج (حدث يخرج المورد “بضاعة”) يقابله استلام نقد (حدث يدخل المورد “نقد”).
الأطراف (Agents)
كل شخص أو جهة لها دور في الحدث. تنقسم إلى نوعين: داخلي (موظف شركتك الذي نفّذ الحدث، مثلًا البائع أو أمين المخزن) وخارجي (الطرف الآخر، مثلًا العميل أو المورد). كل حدث في REA يجب أن يحمل طرفًا داخليًا وطرفًا خارجيًا على الأقل، حتى تعرف من نفّذ ومن تعامل.
| المكوّن | التعريف | أمثلة في شركة سعودية | مرتبط بـ |
|---|---|---|---|
| الموارد (Resources) | الأصول الاقتصادية القابلة للقياس | منتجات، نقد، ذمم، مخزون مواد خام، أصول ثابتة | جدول الأصول، المخزون |
| الأحداث الاقتصادية (Events) | أي عملية تحرّك موردًا داخلًا أو خارجًا | بيع، شراء، تحصيل، سداد، صرف راتب، إنتاج | دفتر اليومية يُولَّد منها |
| الأطراف الداخليون (Internal Agents) | موظفون يقومون بالأحداث | البائع، أمين المخزن، المحاسب، مدير الفرع | سجل الموظفين، الموارد البشرية |
| الأطراف الخارجيون (External Agents) | أطراف خارج الشركة تشارك في الأحداث | العملاء، الموردون، البنوك، هيئة الزكاة والضريبة والجمارك | سجل العملاء، سجل الموردين |
| العلاقة الثنائية (Duality) | قاعدة أن كل حدث يقابله حدث معاكس | بيع يقابله تحصيل، شراء يقابله سداد | منطق المعادلة المحاسبية |
كيف تبني نموذج REA لشركتك خطوة بخطوة
بناء نموذج REA لشركتك لا يتطلب برمجة ولا قاعدة بيانات في المرحلة الأولى. يكفي أن تأخذ ورقة عمل (القالب المرفق) وتمر على دورات شركتك الرئيسية واحدة واحدة. كل دورة تخرج منها بثلاث قوائم: قائمة الموارد، قائمة الأحداث، قائمة الأطراف.
الخطوة 1: حدّد دوراتك الاقتصادية
أي شركة، صغيرة كانت أو كبيرة، تتكون اقتصاديًا من 4 إلى 6 دورات: دورة الإيراد (المبيعات وتحصيلها)، دورة المصروفات (الشراء وسداده)، دورة الإنتاج (إن وُجد تصنيع)، دورة الرواتب والموارد البشرية، دورة التمويل (قروض ورأس مال)، دورة الأصول الثابتة. ابدأ بأهم دورتين عندك، عادة الإيراد والمصروفات.
الخطوة 2: لكل دورة، اكتب الأحداث
في دورة المبيعات مثلًا: استقبال طلب من عميل، تأكيد الطلب، تجهيز البضاعة من المخزن، شحنها أو تسليمها، إصدار الفاتورة، استلام الدفعة. لا يلزم أن تكون كل هذه الأحداث محاسبية بالمعنى الكلاسيكي، لكنها كلها أحداث اقتصادية يهتم بها النظام.
الخطوة 3: لكل حدث، حدّد المورد المتحرّك
تجهيز البضاعة يحرّك مورد “المخزون” (يخرج). إصدار الفاتورة يُنشئ موردًا جديدًا اسمه “ذمم مدينة” (يدخل). استلام الدفعة يحرّك مورد “نقد” (يدخل) ويُسقط مورد “ذمم مدينة” (يخرج).
الخطوة 4: لكل حدث، حدّد الأطراف
الطرف الداخلي يكون من فريقك (البائع، المحاسب، أمين المخزن). الطرف الخارجي يكون العميل أو المورد أو البنك. اسأل دائمًا: من نفّذ هذا الحدث من جهتنا؟ ومع من؟
| الدورة | الأحداث الرئيسية | الموارد المتحركة | الأطراف |
|---|---|---|---|
| دورة الإيراد (مبيعات) | طلب، تجهيز، شحن، فاتورة، تحصيل | مخزون، ذمم مدينة، نقد | عميل، بائع، أمين مخزن، محاسب |
| دورة المصروفات (شراء) | طلب شراء، استلام، فاتورة مورد، سداد | مخزون، ذمم دائنة، نقد | مورد، مشتريات، أمين مخزن، محاسب |
| دورة الإنتاج (مصانع) | سحب مواد خام، تشغيل، إنتاج تام، تخزين | مواد خام، عمالة، منتج تام | عامل، مشرف إنتاج، أمين مخزن |
| دورة الرواتب | تسجيل ساعات، احتساب، صرف، تحويل التأمينات | عمالة، نقد، التزامات حكومية | موظف، محاسب رواتب، البنك، GOSI |
| دورة التمويل | قرض، سداد دفعات، فوائد، رأس مال | نقد، التزامات، حقوق ملكية | بنك، مالك، محاسب |
علاقة REA بدورة الإيراد ودورة المصروفات
دورتا الإيراد والمصروفات هما العمود الفقري لأي شركة، وهما الأوضح في تطبيق نموذج REA لأنهما تظهران بشكل مرآة لبعضهما. كل ما يحدث في دورة إيرادك يحدث عند المورد بشكل معكوس في دورة مصروفاته. هذه الرؤية تساعدك على تصميم نظامك بطريقة متماثلة، فتختصر نصف العمل.
دورة الإيراد
تبدأ من لحظة استقبال الطلب وتنتهي بإقفال الذمة المدينة عند استلام كامل الدفعة. الأحداث الرئيسية: استلام الطلب، التجهيز، الشحن، إصدار الفاتورة الضريبية (مع رمز QR والـ XML وفق متطلبات هيئة الزكاة والضريبة والجمارك)، استلام الدفعة، الإقفال. كل حدث منها يحرّك موردًا أو يُنشئه أو يُسقطه.
دورة المصروفات
صورة معكوسة لدورة الإيراد. تبدأ من تحديد الحاجة وتنتهي بإقفال الذمة الدائنة بعد سداد المورد. الأحداث: طلب شراء داخلي، اعتماد، إرسال أمر شراء للمورد، استلام البضاعة، استلام فاتورة المورد، تسجيل الذمة الدائنة، السداد. تلاحظ التماثل: ما تستلمه في الإيراد، تدفعه في المصروفات، والعكس.
قاعدة الثنائية (Duality)
كل حدث “اقتصادي” في REA يحمل ثنائيته: حدث يدخل موردًا يقابله حدث يخرج موردًا. هذه القاعدة هي البديل الحديث لقاعدة “لكل مدين دائن” في القيد المزدوج. مثال: بيع بضاعة بقيمة 5,000 ريال شامل ضريبة القيمة المضافة 15% يولّد حدثين: حدث يخرج “بضاعة بتكلفة 3,500 ريال” وحدث يدخل “ذمة مدينة بقيمة 5,000 ريال”. هذه الثنائية تضمن أن النظام محاسبيًا متوازن، تمامًا كما تضمن قاعدة المدين والدائن في الدفتر التقليدي.
الفرق بين REA وقيد اليومية المزدوج
سؤال يطرحه كل محاسب يسمع عن REA لأول مرة: هل هذا يلغي القيد المزدوج؟ الإجابة المختصرة: لا، يستوعبه. القيد المزدوج يصبح طبقة تقارير فوق نموذج REA، وليس البنية الأساسية لتخزين البيانات.
على مستوى التخزين
في النظام التقليدي، البيانات تُخزن مباشرة كقيود يومية: تاريخ، حساب مدين، حساب دائن، مبلغ، بيان. التفاصيل الأخرى (العميل، المنتج، الموظف) تُحفظ في جداول جانبية وتُربط بالقيد عبر مفاتيح. في REA، البيانات تُخزَّن كأحداث اقتصادية، ولكل حدث: تاريخ، نوع، طرف داخلي، طرف خارجي، مورد متحرّك، كمية، قيمة. القيد المحاسبي يُستخرج آليًا.
على مستوى التقارير
كلا النموذجين يولّدان دفتر يومية ودفتر أستاذ وميزانية وقائمة دخل. الفرق أن REA يستطيع توليد تقارير غير مالية بنفس السهولة: عدد طلبات كل عميل، متوسط زمن التجهيز، إنتاجية كل موظف. النظام التقليدي يحتاج جداول إضافية لهذه التقارير.
على مستوى المرونة
عند إضافة بُعد جديد (فرع جديد، خط منتجات، عملة مختلفة)، النظام التقليدي يحتاج تعديلات في شجرة الحسابات والتقارير. REA يستوعب البُعد الجديد كحقل إضافي في جداول الأحداث والأطراف دون تعديل في البنية.
- القيد المزدوج: تجريد مالي للحدث، يحتفظ بالأثر المالي ويُسقط التفاصيل العملية.
- REA: يحفظ الحدث بتفاصيله الكاملة، ويولّد القيد المالي عند الحاجة.
- القيد المزدوج: ممتاز للتقارير المالية الكلاسيكية.
- REA: يدعم تقارير مالية وغير مالية من نفس المصدر.
- القيد المزدوج: يحتاج جداول مساعدة لربط الحدث بالعميل والمنتج.
- REA: العلاقات مدمجة في بنية البيانات نفسها.
تطبيق REA على شركة سعودية: مثال متجر تجزئة كامل
لنأخذ متجر تجزئة افتراضي في الرياض اسمه “مؤسسة الندى للأجهزة المنزلية”، يبيع أجهزة كهربائية ومنزلية بثلاثة فروع (الرياض، جدة، الدمام) و12 موظفًا. سنرسم نموذج REA لكامل دوراته في جلسة واحدة.
الموارد
المنتجات (أجهزة من 50 صنفًا)، النقد في صناديق الفروع، النقد في الحسابات البنكية (3 حسابات)، الذمم المدينة (مبيعات بالأقساط)، الذمم الدائنة (مع 8 موردين)، المخزون في المستودع المركزي ومخزون كل فرع، الأصول الثابتة (واجهات المتجر، شاحنات التوصيل). كل مورد له هوية فريدة في النظام، حتى لو كان نفس المنتج موجودًا في 3 فروع، يُعامل كأرصدة منفصلة لكل فرع.
الأحداث
في دورة الإيراد: مبيعات نقدية مباشرة في الفروع، مبيعات بالأقساط، توصيل لعنوان، إصدار فاتورة ضريبية وفق المرحلة الثانية، تحصيل دفعات. في دورة المصروفات: شراء من موردين سعوديين وخليجيين، استلام بضاعة في المستودع المركزي، توزيع على الفروع، سداد للموردين. في دورة الموارد البشرية: تسجيل دوام، احتساب راتب، تحويل عبر مدد، صرف بدلات.
الأطراف
الأطراف الداخليون: مدير عام، 3 مديري فروع، 6 بائعين، أمين مستودع مركزي، محاسب، اختصاصي موارد بشرية. الأطراف الخارجيون: 1,200 عميل مسجل، 8 موردون، 3 بنوك، هيئة الزكاة والضريبة والجمارك، التأمينات الاجتماعية (GOSI)، مدد، قوى.
سيناريو حدث واحد بالتفصيل
عميل اسمه “خالد العتيبي” يشتري ثلاجة من فرع الرياض بقيمة 4,600 ريال شامل ضريبة القيمة المضافة 15% (4,000 ريال قبل الضريبة + 600 ريال ضريبة)، يدفع بمدى. الحدث في REA يُسجَّل كالتالي: نوع الحدث “بيع نقدي”، التاريخ، الطرف الخارجي “خالد العتيبي”، الطرف الداخلي “أحمد البائع”، المورد الخارج “ثلاجة سامسونج طراز RT38” بكمية 1 بتكلفة 3,000 ريال، المورد الداخل “نقد بنك الراجحي” بمبلغ 4,600 ريال، الضريبة 600 ريال، الفرع “الرياض”. القيد المحاسبي المتوازن يُولَّد آليًا من هذه البيانات: مدين بنك الراجحي 4,600، دائن مبيعات 4,000، دائن ضريبة القيمة المضافة 600، مدين تكلفة المبيعات 3,000، دائن المخزون 3,000.
الميزانية واستخراج القوائم المالية من نموذج REA
السؤال العملي الذي يطرحه كل محاسب: إذا كانت البيانات مخزّنة كأحداث وموارد وأطراف، كيف أستخرج الميزانية وقائمة الدخل وقائمة التدفقات النقدية؟ الإجابة أن النظام يقرأ نفس البيانات بطرق مختلفة لكل تقرير.
الميزانية العمومية
تُبنى من الموارد. النظام يجمع كل الموارد الموجودة عند تاريخ معيّن: النقد، الذمم المدينة، المخزون، الأصول الثابتة (الجانب المدين)، الذمم الدائنة، القروض، حقوق الملكية (الجانب الدائن). كل مورد محسوب من أحداثه المتراكمة، مثلًا رصيد المخزون لمنتج معيّن هو مجموع أحداث “استلام” ناقص مجموع أحداث “صرف”.
قائمة الدخل
تُبنى من الأحداث خلال فترة. أحداث المبيعات تُجمع لتعطي الإيرادات، أحداث الشراء وصرف المخزون تعطي تكلفة المبيعات، أحداث الرواتب والإيجار تعطي المصروفات التشغيلية. كل حدث يحمل تاريخه، فالنظام يفلتر بالفترة المطلوبة.
قائمة التدفقات النقدية
تُبنى من أحداث النقد فقط. النظام يستخرج كل حدث حرّك مورد “نقد”، يفصلها بحسب نوع النشاط (تشغيلي، استثماري، تمويلي)، ويعرض الصافي.
REA والفوترة الإلكترونية المرحلة الثانية
هيئة الزكاة والضريبة والجمارك أطلقت المرحلة الثانية من الفوترة الإلكترونية في ديسمبر 2022، وامتد التطبيق بموجات إلى جميع المنشآت الخاضعة. متطلبات المرحلة الثانية معقّدة من ناحية البيانات: كل فاتورة يجب أن تحمل XML يحتوي على بيانات تفصيلية للبائع والمشتري والمنتجات وحقول الضريبة، مع توقيع رقمي ورمز QR، ويجب إرسال الفاتورة إلى منصة فاتورة (Fatoora) قبل تسليمها للعميل (في حالة B2B) أو بعد إصدارها مباشرة (في حالة B2C).
نموذج REA يتعامل مع هذه المتطلبات بسلاسة لأن البيانات التي تطلبها الهيئة موجودة أصلًا في بنيته. حقل البائع هو “الطرف الداخلي”، حقل المشتري هو “الطرف الخارجي”، حقول المنتجات هي “الموارد المتحركة” في حدث البيع، حقل الضريبة محسوب من قيمة المورد. النظام الذي يطبّق REA يستطيع توليد الـ XML المطلوب من نفس بيانات الحدث دون أن يطلب من المحاسب إدخالها مرتين.
| حقل المرحلة الثانية (XML) | المكوّن المقابل في REA | المصدر |
|---|---|---|
| بيانات البائع (الاسم، الرقم الضريبي، العنوان) | الطرف الداخلي (Internal Agent) | بيانات الشركة المسجّلة مرة واحدة |
| بيانات المشتري (الاسم، الرقم الضريبي إن وُجد) | الطرف الخارجي (External Agent) | سجل العملاء |
| تفاصيل البنود (الوصف، الكمية، السعر) | الموارد المتحركة (Resources) | سجل المنتجات |
| قيمة الفاتورة قبل الضريبة | قيمة الحدث (Event Value) | الكمية × السعر |
| قيمة الضريبة 15% | محسوبة من الحدث | قاعدة ضريبية على المورد |
| تاريخ ووقت الإصدار | طابع الحدث الزمني (Event Timestamp) | تلقائي من النظام |
| رمز QR والتوقيع الرقمي | إضافة فوق الحدث | وحدة التشفير في النظام |
كيف يطبّق قيود نموذج REA داخل النظام
قيود نظام محاسبي سعودي معتمد من هيئة الزكاة والضريبة والجمارك، مصمَّم منذ نشأته على بنية بيانات تتوافق مع منطق REA دون أن يطلب من المستخدم تعلّم النموذج. أنت تُسجّل فاتورة بيع لعميل، فيخزّن النظام: الحدث (بيع)، الطرف الخارجي (العميل)، الطرف الداخلي (المستخدم)، الموارد المتحركة (المنتجات)، القيم، التاريخ، الفرع، وكل تفصيلة تحتاجها لاحقًا.
هذا التصميم يظهر في 3 ميزات تستخدمها يوميًا داخل قيود. الأولى أن سجل العملاء مرتبط مباشرة بكل حدث، فعند فتح ملف العميل ترى تاريخه الكامل (طلبات، فواتير، تحصيلات، رسائل) دون الحاجة لتقارير منفصلة. الثانية أن المخزون مرتبط بأحداث الشراء والبيع لحظيًا، فأي بيع يُسقط الكمية من المخزن آليًا. الثالثة أن دفتر اليومية يُولَّد كطبقة تقارير، فأنت ترى القيد المزدوج جاهزًا حسب المعيار السعودي دون أن تكتبه يدويًا.
تستطيع تجربة هذا فعليًا بفتح حساب على منصة قيود وتسجيل أول 5 فواتير من نشاطك. ستلاحظ أن كل فاتورة تنتج تلقائيًا: تحديث للمخزون، قيد في دفتر اليومية، تحديث لرصيد العميل، إدخال في تقارير المبيعات، وإن كنت في المرحلة الثانية من الفوترة الإلكترونية، إرسال للـ XML إلى منصة فاتورة. كل هذا من حدث واحد سجّلته.
للمحاسب الذي يريد أن يتعمّق، تتوفر في قيود تقارير محاسبية تكشف عن طبقات REA المختلفة: تقارير المبيعات حسب العميل (الأطراف)، حسب المنتج (الموارد)، حسب الفرع (الأبعاد الإضافية)، حسب الموظف. كل هذه التقارير تعمل من نفس بيانات الحدث المسجّل.
الأخطاء الشائعة في تطبيق REA
عند تطبيق REA على شركة قائمة، تظهر أخطاء متكررة. معرفتها مسبقًا يوفّر عليك أشهرًا من إعادة العمل.
خلط الموارد بالأحداث
أكثر الأخطاء شيوعًا. شخص يكتب “البيع” في قائمة الموارد، رغم أن البيع حدث وليس موردًا. القاعدة: المورد شيء “موجود” يمكن قياسه في لحظة معيّنة (رصيد المخزون اليوم، رصيد النقد اليوم). الحدث شيء “يحدث” خلال زمن (بيع تم اليوم الساعة 11).
إغفال الطرف الداخلي
بعض الشركات تسجّل اسم العميل فقط في كل حدث وتنسى تسجيل اسم البائع. هذا يفرّغ نصف قيمة REA. الطرف الداخلي ضروري لتقارير الإنتاجية والمحاسبة عن الأداء.
اعتبار كل عملية حدثًا اقتصاديًا
ليس كل ما يحدث في الشركة حدث اقتصادي بمعنى REA. إرسال عرض سعر ليس حدثًا اقتصاديًا (لم يتحرّك مورد بعد)، طباعة فاتورة ليست حدثًا اقتصاديًا. الحدث الاقتصادي يجب أن يحرّك موردًا فعلًا.
كثرة المستويات في الأطراف
محاولة تصنيف العملاء إلى 7 أو 8 فئات داخل سجل الأطراف. الأفضل أن تبقي السجل بسيطًا (عميل، مورد، موظف، بنك، جهة حكومية) وتستخدم خصائص إضافية (Attributes) للتفصيل.
تجاهل قاعدة الثنائية
تسجيل حدث “بيع” دون تسجيل الحدث المقابل (تحصيل أو إنشاء ذمة مدينة). كل حدث يدخل موردًا يقابله حدث يخرج موردًا. تجاهل هذه القاعدة يكسر التوازن المحاسبي.
متى يكون REA مناسبًا ومتى تحتاج نظامًا أبسط
REA ليس حلًا لكل شركة. هو ملائم جدًا لشركات حجمها يستوجب تتبع علاقات معقّدة بين العملاء والمنتجات والموظفين. أما إذا كنت مالك محل واحد بحركة بسيطة، نظام نقاط بيع (POS) موصول بدفتر يومية تقليدي قد يكفيك.
REA مناسب جدًا في الحالات التالية
شركة عندها أكثر من فرع أو خط منتجات وتحتاج تقارير متقاطعة، شركة تعمل تحت متطلبات الفوترة الإلكترونية المرحلة الثانية وتحتاج بيانات تفصيلية لكل فاتورة، شركة عندها فريق مبيعات وتريد قياس إنتاجية كل بائع، شركة تخطط للنمو وتريد بنية بيانات لا تحتاج إعادة بناء مع التوسع، شركة عندها CRM ونظام مخزون ومحاسبة وتريد توحيد البيانات.
نظام تقليدي قد يكفي في الحالات التالية
محل صغير بفرع واحد ومنتجات محدودة وعدد عملاء قليل، شركة خدمية بسيطة بأرقام مبيعات ثابتة، عمل موسمي قصير الأمد. الفرق بين النموذجين على هذا الحجم لا يُحدث فارقًا عمليًا، ومرونة REA لا تُستثمر.
للمقارنة بين الخيارات وتكلفة كل خطة وكم بيانًا تستطيع تخزينه، راجع صفحة باقات قيود. خطط قيود تغطي من الشركات الناشئة إلى الشركات متعددة الفروع، وكلها مبنية على نفس بنية البيانات الحديثة.
أسئلة شائعة
هل REA يلغي الحاجة إلى محاسب؟
لا. REA يلغي إدخال القيود يدويًا، لكنه يزيد من قيمة دور المحاسب. المحاسب في بيئة REA ينتقل من كتابة القيود إلى تحليل البيانات وفهم الأنماط واتخاذ القرارات. تحتاج محاسبًا يفهم نشاطك ويتأكد أن الأحداث تُسجَّل بطريقة صحيحة وأن التقارير تعكس الواقع.
هل يمكنني تطبيق REA يدويًا قبل اقتناء نظام؟
نعم. القالب المرفق يساعدك على رسم نموذج REA لشركتك في ورقة عمل. ستحدد مواردك وأحداثك وأطرافك، ثم تستطيع نقل هذا التصميم إلى أي نظام (ERP) تختاره لاحقًا. هذه الخطوة التحضيرية تختصر شهور التطبيق.
هل REA متوافق مع المعايير المحاسبية السعودية والدولية؟
نعم. REA طبقة بيانات، لا تتعارض مع المعايير. القوائم المالية التي يولّدها أي نظام يطبّق REA تلتزم بمعايير IFRS المعتمدة في المملكة العربية السعودية ومتطلبات هيئة الزكاة والضريبة والجمارك. الفرق فقط في طريقة التخزين الداخلية للبيانات.
كم يستغرق بناء نموذج REA لشركة متوسطة؟
الرسم الأولي على ورقة عمل يستغرق من جلستين إلى 4 جلسات بساعة لكل جلسة، حسب تعقّد دوراتك. التطبيق داخل نظام (مثل قيود) لا يحتاج وقتًا إضافيًا لأن النظام مبني على بنية REA من الأصل، أنت فقط تُدخل بيانات شركتك. تطبيق نظام مخصّص من الصفر قد يستغرق أشهرًا.
ما الفرق بين REA وERP؟
REA نموذج بيانات، ERP صنف من البرمجيات. ERP يعني نظام تخطيط موارد المؤسسة، وهو برنامج يدير المحاسبة والمخزون والمبيعات والموارد البشرية. أغلب أنظمة ERP الحديثة، بما فيها قيود، تستخدم بنية بيانات قريبة من REA دون أن تُعلن عن ذلك. REA هو “كيف تُخزَّن البيانات” وERP هو “بأي برنامج تتفاعل مع هذه البيانات”.
هل أحتاج معرفة برمجية لتطبيق REA؟
لا. كصاحب نشاط أو محاسب، تحتاج فقط فهم المفاهيم الثلاثة (موارد، أحداث، أطراف) وكيفية رسمها على دوراتك. التطبيق التقني داخل النظام يقوم به النظام نفسه. القالب المرفق لا يحتاج أي معرفة برمجية، يكفي ملء الخلايا.
كيف يخدمني REA في التحضير لتدقيق هيئة الزكاة والضريبة والجمارك؟
تدقيق الهيئة يبحث عن تطابق بين الفواتير المُصدَرة وأرصدة المخزون وأرصدة النقد وتقارير الضريبة. في بيئة REA، كل فاتورة هي حدث له مورد متحرّك وطرف خارجي. عند التدقيق، النظام يستطيع تتبع أي فاتورة من رمز QR في الـ XML إلى الحدث المخزّن، إلى المنتج المتحرّك في المخزون، إلى الدفعة المستلمة في البنك. سلسلة كاملة دون فجوات.
هل REA يدعم تعدد العملات والفروع؟
نعم. الموارد في REA تحمل خصائصها (العملة، الفرع، الموقع، الكمية). شركة لها فرع في الرياض وفرع في دبي تستطيع تسجيل الأحداث بعملاتها، والنظام يحسب التحويلات حسب أسعار الصرف عند تاريخ الحدث. تقاريرك الموحّدة تعرض الأرقام بالعملة الأم.