في هذا المقال سنتحدث عن الترحيل التلقائي المحاسبة.
تمهيد
ربط فواتير المبيعات والمشتريات ونقاط البيع بالمحاسبة يدوياً يستهلك وقت المحاسب ويعرّض الدفاتر لأخطاء وإغفالات. عندما يُرحّل مستند (فاتورة مبيعات، فاتورة مشتريات، مرتجع، إشعار دائن أو مدين) في يومي ERP يُنشأ تلقائياً قيد يومية مرتبط بالمستند ويُحدّث المخزون إن كان المستند يمسّ الأصناف. هذه الصفحة تشرح كيف يتم الترحيل التلقائي: التحقق من الحسابات الافتراضية أولاً، ثم إنشاء حركة مخزون إن لزم، ثم إنشاء قيد المحاسبة وربطه بالمستند، مع تركيز على آلية يومي الفعلية وليس وصفاً عاماً لأنظمة ERP.
لماذا الترحيل التلقائي وليس الإدخال اليدوي؟
الإدخال اليدوي للقيود بعد كل فاتورة يعني تكرار البيانات واحتمال الخطأ في المبلغ أو الحساب أو التاريخ. في الأنظمة التي تفصل بين المبيعات/المشتريات والمحاسبة يضطر المحاسب إلى نقل الأرقام من وحدات أخرى أو من إكسل، مما يؤخر إغلاق الشهر ويصعّب المطابقة. في يومي ERP الترحيل التلقائي يربط المستند مباشرة بقيد واحد (journal_entry_id)؛ القيد يُنشأ عند ضغط “ترحيل” أو “اعتماد” وفق نوع المستند، ويُستخدم دليل الحسابات الافتراضية (الحسابات الأساسية) لتحديد الحسابات المدينة والدائنة، فلا حاجة لإدخال القيد يدوياً. النتيجة: ميزان متسق، كشوف حسابات محدثة، وتقارير مالية مبنية على نفس بيانات الفواتير.
دليل الحسابات الافتراضية شرط قبل الترحيل
قبل ترحيل فاتورة مشتريات أو فاتورة مبيعات أو مرتجع يتحقق النظام من أن الحسابات الافتراضية المطلوبة لهذا النوع من المستندات مُعدّة في الشركة. في يومي تُعرَف هذه الحسابات في جدول company_default_ledger_accounts وواجهة “تعيين الحسابات الأساسية” (أو الحسابات الافتراضية). لفواتير المشتريات ومرتجعات المشتريات تحتاج على الأقل: حساب المخزون (inventory)، حساب ضريبة المدخلات (vat_input)، حساب الموردين (accounts_payable). إن نقص أحدها يُرجع النظام استثناء DefaultLedgerAccountsRequiredException ويُظهر للمستخدم قائمة بالحسابات الناقصة بدلاً من تنفيذ ترحيل ناقص. نفس المنطق يُطبَّق على المبيعات: إيرادات المبيعات، الذمم المدينة، ضريبة المخرجات، تكلفة المبيعات، الخصم إن وُجد، كلها تأتي من الحسابات الافتراضية. هذا يضمن أن كل قيد تلقائي يستخدم حسابات موحدة ومعتمدة من إدارة الشركة.
كيف يُنشأ القيد عند ترحيل فاتورة مشتريات
عند ترحيل فاتورة مشتريات يُستدعى PurchaseDocumentPostingService: أولاً ترحيل المخزون (postInventory) أي استلام الكميات إلى المستودع مع مرجع المستند، وثانياً ترحيل المحاسبة (postAccounting). في ترحيل المحاسبة يُحسب المجموع الفرعي وضريبة القيمة المضافة والمجموع الإجمالي من رأس وبنود الفاتورة، ويُبنى قيد يومية من ثلاثة أسطر: مدين مخزون (قيمة المشتريات)، مدين ضريبة مدخلات، دائن موردين (المجموع الإجمالي). القيد يُنشأ عبر JournalEntryService ثم يُعتمد ويُرقّم (approve وpost) ويُربط بفاتورة المشتريات بحقل journal_entry_id. تاريخ القيد يساوي تاريخ الفاتورة، والوصف يشمل نوع المستند ورقمه. بهذا تصبح الفاتورة المرحّلة مرتبطة بقيد واحد في دفتر اليومية ولا يبقى على المحاسب سوى مراجعة التقارير والمطابقة مع البنوك.
كيف يُنشأ القيد عند ترحيل مرتجع مشتريات
مرتجع المشتريات له تأثير عكسي: خروج كميات من المخزون وتقليل ذمة المورد. خدمة الترحيل تنفّذ حركة مخزون خروج (deductPurchaseReturn) ثم قيد محاسبة معكوس: مدين موردين، دائن مخزون، دائن ضريبة مدخلات. نفس الحسابات الافتراضية تُستخدم، والربط بين المرتجع والقيد يُحفظ في journal_entry_id. التصميم آمن للتراجع: لا يتم تعديل القيد الأصلي للفاتورة بل إنشاء قيد جديد معكوس يوضح في السجل أن الحركة مرتجع.
الترحيل في فواتير المبيعات والإشعارات والمرتجعات
في يومي ERP فواتير المبيعات والإشعار الدائن والإشعار المدين ومرتجعات المبيعات تتبع إطاراً موحداً للمستندات؛ عند الاعتماد أو الترحيل يُنشأ قيد محاسبة يستخدم الحسابات الافتراضية للمبيعات: الذمم المدينة، إيرادات المبيعات، ضريبة المخرجات، تكلفة المبيعات، خصم المبيعات إن وُجد. الإشعار الدائن يقلل الذمة والإيراد ويرجع المخزون (ترحيل عكسي). الإشعار المدين يزيد الذمة والإيراد ويخصم المخزون كفاتورة إضافية. كل مستند مرحّل يُربط بقيده عبر journal_entry_id لضمان تتبع كامل من الفاتورة إلى دفتر اليومية.
التحقق من اكتمال الحسابات قبل الترحيل
في واجهة المستخدم عند محاولة ترحيل فاتورة مشتريات أو مرتجع دون اكتمال الحسابات الافتراضية يُعاد للمستخدم رسالة توضح الحسابات الناقصة (مثلاً: inventory، vat_input، accounts_payable). في بعض التدفقات تُمرَّر هذه القائمة عبر الجلسة (session) لعرضها في صفحة الحسابات الافتراضية أو في نفس الصفحة. الهدف منع ترحيل ينتج قيداً بحسابات فارغة أو خاطئة. بعد إعداد كل الحسابات المطلوبة يصبح الترحيل متاحاً والقيود تُنشأ تلقائياً دون تدخل يدوي في بنود القيد.
ربط القيد بالمستند والمرجعية
كل قيد تلقائي يُخزَن فيه reference يشير إلى نوع المستند ورقمه (مثل PurchaseInvoice#123). نموذج المستند (PurchaseInvoice، PurchaseReturn، SalesInvoice، إلخ) يضم حقل journal_entry_id يشير إلى قيد اليومية. هذا يسمح بالانتقال من تقرير الفواتير إلى القيد المرتبط وبالعكس، ويُسهّل المراجعة والتدقيق. في التقارير المالية (ميزان مراجعة، قائمة دخل، كشف حساب) الأرصدة ناتجة عن هذه القيود التلقائية واليدوية معاً، فلا انفصال بين “وحدة المبيعات” و”وحدة المحاسبة”.
الخلاصة
الترحيل التلقائي في يومي ERP يعتمد على دليل الحسابات الافتراضية وخدمات الترحيل (مثل PurchaseDocumentPostingService) التي تنفّذ ترحيل المخزون ثم ترحيل المحاسبة داخل نفس السياق، مع التحقق من اكتمال الحسابات قبل التنفيذ وربط القيد بالمستند عبر journal_entry_id. المحاسبون في الخليج ومصر يجدون أن ربط فواتير المبيعات والمشتريات بالمحاسبة يصبح آلياً وموثوقاً دون إدخال قيود يدوية مكررة.
دعوة للعمل (CTA)
إذا كنت تبحث عن نظام ERP يربط المبيعات والمشتريات بالمحاسبة تلقائياً مع قيود مرتبطة بكل فاتورة، يمكنك التعرف على يومي ERP من صفحة البيلار ثم تجربة الترحيل في وحدة المحاسبة والمبيعات والمشتريات.
يومي نظام متكامل قابل للتخصيص لهذا السبب يناسب مجالك أياً كان
يومي ERP يتميز بمرونته وقابليته للتخصيص، لذلك يجعله مناسباً لإدارة الأعمال في مختلف المجالات. يمكنك تعديل التطبيقات والوظائف لتتوافق مع احتياجات شركتك، سواء كانت تشمل إدارة المخزون، إصدار الفواتير، أو تتبع العملاء. يتيح النظام كذلك دمج التطبيقات بسلاسة ويوفر تجربة استخدام متكاملة وأمناً كاملاً للبيانات. بغض النظر عن مجال عملك، يوفر يومي ERP الحلول الشاملة لتحقيق النجاح والنمو في السوق المتغيرة.