مرحباً أصدقاء المحاسبة 👋
اليوم سأشارككم تجربة واقعية تواجهها كل شركة عقارية: **العميل يُحوّل دفعة الوحدة إلى حساب الشركة بدلاً من حساب أمانة المشروع**. يبدو خطأً بسيطاً، لكن تأثيره المحاسبي ليس بسيطاً أبداً. تعالوا نرى كيف عالجت منصة سديد هذا التحدي بطريقة ذكية ومتوافقة مع المعايير الدولية.
---
## أولاً: لماذا تُفصل أموال المشاريع عن أموال الشركة؟
عندما تبيع شركة عقارية وحدة سكنية للعميل، فالمبالغ التي يدفعها العميل **ليست إيراداً للشركة**. هي **أمانة (Trust)** تُدار لصالح المشروع حتى يتم تسليم الوحدة. هذا مبدأ محاسبي أساسي:
> **المبلغ المُستلم من العميل = التزام على المشروع تجاه العميل (Customer Advance)**
> وليس إيراداً — حتى يتم التسليم وإصدار الفاتورة النهائية.
لذلك في سديد، كل مشروع عقاري له **حسابات بنكية مستقلة** تُسمى **حسابات أمانة المشروع (Project Trust Accounts)**. ولكل مشروع **بلنس شيت خاص** منفصل تماماً عن بلنس شيت الشركة.
---
## ثانياً: ماذا يحدث عندما يُودع المبلغ في الحساب الخاطئ؟
الواقع يقول: أحياناً العميل يكون مُخزّناً لرقم حساب الشركة الرئيسي في تطبيق البنك، ويُحوّل عليه بالخطأ بدلاً من حساب أمانة المشروع. أو أن المحاسب يستلم المبلغ في فرع الشركة ويُودعه في حساب الشركة.
### الإشكالية المحاسبية
المال موجود فعلياً في بنك الشركة، لكنه **يخص المشروع قانونياً ومحاسبياً**. إذا تجاهلنا هذا:
- بلنس شيت الشركة سيُظهر أصولاً أكبر من الواقع
- بلنس شيت المشروع لن يعكس الدفعة
- كشف حساب العميل لن يُظهر أنه دفع
---
## ثالثاً: الحل — نظام المقاصة بين الكيانات (Intercompany Clearing)
سديد تعامل مع هذا بإنشاء **حسابات وسيطة تلقائية** لكل مشروع عقاري:
| الحساب | النوع | أين يظهر | المعنى |
|--------|-------|----------|--------|
| **أمانة لدى الشركة** | أصل متداول | بلنس شيت المشروع | "المشروع له مبلغ محتجز لدى الشركة" |
| **أمانات المشاريع** | التزام متداول | بلنس شيت الشركة | "الشركة تحتفظ بمبلغ يخص المشروع" |
### القيد عند الإيداع الخاطئ (4 أطراف):
**في دفاتر الشركة:**
```
مدين: حساب البنك (الشركة) ← النقد دخل فعلاً
دائن: أمانات المشاريع - المشروع X ← الشركة تعترف بدين للمشروع
```
**في دفاتر المشروع:**
```
مدين: أمانة لدى الشركة ← المشروع يسجل ذمة على الشركة
دائن: سلف العملاء (Customer Advance) ← التزام تجاه العميل تم تسجيله
```
### النتيجة:
- ✅ بلنس شيت **الشركة** متوازن — البنك زاد بنفس مبلغ الالتزام
- ✅ بلنس شيت **المشروع** متوازن — الذمة على الشركة تُقابل التزام العميل
- ✅ **العميل** يرى دفعته في كشف حسابه كالمعتاد
- ✅ **المدير المالي** يرى فوراً "الشركة عليها X لصالح مشروع Y"
---
## رابعاً: التصحيح — إرجاع المبلغ لحساب المشروع
عندما يتم اكتشاف الإيداع الخاطئ، يتم تحويل بنكي فعلي من حساب الشركة إلى حساب أمانة المشروع. سديد يُسجل هذا تلقائياً:
**في دفاتر الشركة:**
```
مدين: أمانات المشاريع - المشروع X ← الدين انتفى
دائن: حساب البنك (الشركة) ← النقد خرج
```
**في دفاتر المشروع:**
```
مدين: حساب البنك (المشروع) ← النقد وصل
دائن: أمانة لدى الشركة ← الذمة انتفت
```
### المحصلة النهائية:
بعد الإيداع + الإرجاع = **كأن الدفعة دخلت حساب المشروع من البداية**. الحسابات الوسيطة عادت لصفر.
---
## خامساً: التجربة العملية في سديد
### 1. لحظة استلام الدفعة
عندما يختار المحاسب "حساب الشركة" بدلاً من "حساب المشروع"، يظهر له **تنبيه فوري**:
> ⚠️ **تنبيه — إيداع في حساب الشركة**
> هذه دفعة لمشروع عقاري، لكنك اخترت إيداعها في حساب الشركة بدلاً من حساب أمانة المشروع.
> سيتم تسجيل القيد كـ "أمانة لدى الشركة" ويجب لاحقاً تحويل المبلغ عبر صفحة المعالجة.
النظام يطلب **سبب الإيداع** (إلزامي) ويتطلب **صلاحية خاصة** للمتابعة.
### 2. صفحة المعالجة (Reconciliation)
صفحة مخصصة تعرض كل المبالغ المحتجزة لدى الشركة:
- المبلغ، التاريخ، اسم العميل، الحساب الذي استلمها
- حالة كل إيداع: محتجز → بانتظار الموافقة → تمت المعالجة
- زر "طلب إرجاع" → يُرسل مهمة للمسؤول المالي بأولوية (عادي/مستعجل/طارئ)
### 3. الموافقة والتنفيذ
المسؤول المالي يراجع الطلب في قائمة مهامه، يُوافق أو يرفض. عند الموافقة:
- القيود المحاسبية تُسجل تلقائياً (4 أطراف)
- الحسابات الوسيطة تعود لصفر
- المبلغ ينعكس في رصيد حساب أمانة المشروع
### 4. التقارير المالية
- **بلنس شيت المشروع**: إذا كانت هناك مبالغ محتجزة، تظهر تحت "أصول → أمانة لدى الشركة"
- **بلنس شيت الشركة**: تظهر تحت "التزامات → أمانات المشاريع" مع تفصيل لكل مشروع
- **تنبيه تلقائي**: شريط برتقالي يُنبه في صفحة Financial Summary: "يوجد X ر.ع محتجزة في حساب الشركة"
---
## سادساً: الدفعات التاريخية (Record Only)
ماذا عن الدفعات التي تمت **قبل تاريخ الرصيد الافتتاحي** لحساب المشروع؟
هذه دفعات تاريخية كانت موجودة قبل أن يبدأ المشروع باستخدام سديد. النظام يتعامل معها بذكاء:
- أي دفعة تاريخها **قبل** تاريخ الـ Opening Balance للحساب تُعتبر تلقائياً **"إدخال تاريخي"**
- تظهر في **كشف حساب العميل** كمرجع (يرى العميل تاريخ مدفوعاته الكامل)
- **لا تؤثر** على رصيد الحساب ولا تُولّد قيود محاسبية
- تُعرض بـ badge أزرق "تاريخي" مع tooltip يشرح السبب
هذا يُحل معضلة شائعة: **كيف أُدخل سجلات الماضي بدون أن أُفسد الأرقام الحالية؟**
---
## سابعاً: أرقام من الواقع
عند تطبيق هذا النظام على شركة عقارية فعلية:
| المؤشر | القيمة |
|--------|--------|
| عدد المشاريع | 15+ مشروعاً نشطاً |
| حسابات الأمانة | 21 حساباً بنكياً |
| إجمالي الدفعات | 336 دفعة بقيمة 26+ مليون ر.ع |
| منها تاريخية | 223 دفعة (أرصدة مُرحّلة) |
| دفعات فعلية خاطئة التوجيه | 6 فقط بقيمة 12,900 ر.ع |
**6 دفعات فقط من أصل 336** وصلت للحساب الخاطئ — وكلها تم اكتشافها وتصحيحها عبر صفحة المعالجة.
---
## الخلاصة
منصة سديد لا تكتفي بتسجيل الأرقام — بل تُطبّق **فلسفة محاسبية صحيحة** تضمن:
1. **الفصل الحقيقي** بين أموال الشركة وأموال المشاريع
2. **القيد المزدوج** يعمل تلقائياً في كل عملية
3. **الرقابة** عبر الصلاحيات والتنبيهات وسير عمل الموافقات
4. **الشفافية** — كل تقرير يعكس الحقيقة بدقة
5. **المرونة** — يتعامل مع الأخطاء البشرية بدل تجاهلها
إذا كنت تُدير مشاريع عقارية وتريد أن تطمئن أن أموال عملائك في المكان الصحيح — هذا هو النظام الذي تحتاجه.
---
*سلطان — متخصص في المحاسبة والمالية*
*قناة المحاسبة والمالية — مجتمع سديد*
How Sadeed Manages Real Estate Project Trust Funds — A Tale of Two Accounts
Login from your company dashboard to comment