مخطط دفتر فوترة قابل للمصالحة: الفواتير والمدفوعات

لماذا تتوقف بيانات الفوترة عن المطابقة

بالنسبة للمالية، "المصالحة" وعد بسيط: أن الإجماليات في التقارير تتطابق مع السجلات المصدرية، ويمكن تتبع كل رقم. إذا أظهر الشهر جمعًا قدره $12,430، يجب أن تكون قادرًا على الإشارة إلى المدفوعات الدقيقة (وأي مستردات)، ورؤية أي فواتير طبقتها، وشرح أي اختلاف بسجل مؤرخ.

عادةً ما تتوقف بيانات الفوترة عن المطابقة عندما يخزن النظام نتائج بدلًا من الحقائق. حقول مثل paid_amount أو balance أو amount_due يتم تحديثها مع الوقت بواسطة منطق التطبيق. خطأ واحد، إعادة محاولة واحدة، أو تصحيح يدوي واحد يمكنه تغيير التاريخ بهدوء. بعد أسابيع، قد تقول جدول الفواتير إن الفاتورة "مدفوعة"، لكن صفوف المدفوعات لا تجمع، أو يوجد مرتجع بدون رصيد مطابَق.

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

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

صمم لهدف واضح:

• إجماليات واضحة لكل عميل، لكل فاتورة، ولكل فترة محاسبية
• كل تغيير مسجل كسطر جديد (لا تُكتب فوق القديم)
• سلسلة كاملة من الفاتورة إلى المدفوعات والاعتمادات والمرتجعات والتعديلات
• القدرة على إعادة حساب الإجماليات من القيود الأولية والحصول على نفس النتيجة

مثال: إذا دفع عميل $100، ثم حصل على رصيد قدره $20، يجب أن تُظهر تقاريرك $100 تم جمعها، $20 معتمدة، و$80 صافيًا، دون تعديل مبلغ الفاتورة الأصلية.

فواصل: فواتير منفصلة، مدفوعات، اعتمادات وتعديلات

إذا أردت مخطط دفتر فوترة يمكن تسويته، اعتبر كل نوع مستند كحدث مختلف. جمعها كلها في جدول "transactions" واحد قد يبدو مرتبًا، لكنه يشوش المعنى.

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

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

مذكرة الائتمان تقلل ما يدين به العميل دون بالضرورة إعادة نقد. المرتجع هو نقد يخرج. يحدثان غالبًا معًا، لكنهما ليسا نفس الشيء.

• الفاتورة: تزيد المدينون والإيراد (أو الإيراد المؤجل)
• الدفعة: تزيد النقد وتقلل المدينون
• مذكرة الائتمان: تقلل المدينون
• المرتجع: يقلل النقد

التعديل هو تصحيح تقوم به فرقكم عندما لا يتطابق الواقع مع السجلات. تحتاج التعديلات إلى سياق لتثق بها المالية. خزن من أنشأها، ومتى نُشرت، وكود السبب، وملاحظة قصيرة. أمثلة: "شطب 0.03 بسبب التقريب"، أو "ترحيل رصيد قديم".

قاعدة عملية: اسأل "هل كان هذا سيُوجد لو لم يرتكب أحد خطأ؟" الفواتير والمدفوعات ومذكرات الائتمان والمرتجعات ستستمر بالوجود. يجب أن تكون التعديلات نادرة، معنونة بوضوح، وسهلة المراجعة.

اختر نموذج دفتر يمكن للمالية تدقيقه

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

مستندات مقابل قيود (خزن كلاهما)

احتفظ بالمستندات (رأس الفاتورة وبنودها، إيصال الدفع، مذكرة الائتمان) لأن الناس بحاجة إلى قراءتها. لكن لا تعتمد على إجماليات المستند كمصدر للحقيقة للمصالحة.

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

نموذج بسيط مناسب للتدقيق يتبع قواعد قليلة:

• قيود غير قابلة للتعديل: لا تحرر المبالغ المنشورة؛ التغييرات قيود جديدة.
• حدث ترحيل واضح: ينشئ كل مستند دفعة ترحيل مع مرجع فريد.
• منطق متوازن: القيود تتوازن (غالبًا المدين يساوي الدائن على مستوى الشركة).
• تواريخ منفصلة: احتفظ بتاريخ المستند (ما يراه العميل) وبـ posted_at (متى يظهر في التقارير).
• مراجع ثابتة: خزن المرجع الخارجي (رقم الفاتورة، معرف مزوّد الدفع) إلى جانب المعرفات الداخلية.

المفاتيح الطبيعية مقابل المعرفات المفتاحية

استخدم معرفات بديلة للوصلات والأداء، لكن خزن أيضًا مفتاحًا طبيعيًا ثابتًا ينجو من الترحيلات وإعادة الاستيراد. ستطلب المالية "Invoice INV-10483" بعد وقت طويل من تغير معرفات قاعدة البيانات. عامل أرقام الفواتير ومعرفات المزود (مثل معرف الشحن من مزوّد الدفع) كحقول من الدرجة الأولى.

الإلغاءات دون حذف التاريخ

عندما يجب التراجع عن شيء، لا تحذف أو تكتب فوق القديم. أنشر عكسية: قيود جديدة تعكس المبالغ الأصلية بعلامات معاكسة، مرتبطة بالترحيل الأصلي.

مثال: دفعة $100 طُبقت على الفاتورة الخطأ تصبح خطوتين: عكس الترحيل المطبّق خطأً، ثم نشر تطبيق جديد للفاتورة الصحيحة.

مخطط خطوة بخطوة للجداول والمفاتيح

مخطط دفتر الفوترة يتصالح بشكل أكثر موثوقية عندما يكون لكل نوع مستند جدول خاص وتربطه بسجلات تخصيص صريحة (بدلًا من تخمين العلاقات لاحقًا).

ابدأ بمجموعة صغيرة من الجداول الأساسية، كل واحدة بمفتاح أساسي واضح (UUID أو bigserial) ومفاتيح خارجية مطلوبة:

• customers: customer_id (PK)، بالإضافة إلى معرفات ثابتة مثل external_ref (فريد)
• invoices: invoice_id (PK), customer_id (FK), invoice_number (unique), issue_date, due_date, currency
• invoice_lines: invoice_line_id (PK), invoice_id (FK), line_type, description, qty, unit_price, tax_code, amount
• payments: payment_id (PK), customer_id (FK), payment_date, method, currency, gross_amount
• credits: credit_id (PK), customer_id (FK), credit_number (unique), credit_date, currency, amount

ثم أضف الجداول التي تجعل الإجماليات قابلة للتدقيق: التخصيصات. دفعة أو ائتمان يمكن أن يغطي عدة فواتير، والفاتورة يمكن أن تُدفع بعدة دفعات.

استخدم جداول وصل بمفاتيح خاصة بها (ليس فقط مفاتيح مركبة):

• payment_allocations: payment_allocation_id (PK), payment_id (FK), invoice_id (FK), allocated_amount, posted_at
• credit_allocations: credit_allocation_id (PK), credit_id (FK), invoice_id (FK), allocated_amount, posted_at

أخيرًا، احتفظ بالتعديلات منفصلة حتى ترى المالية ما تغيّر ولماذا. جدول adjustments يمكن أن يشير إلى السجل المستهدف عبر invoice_id (قابل للـ null) ويخزن مبلغ الفارق، دون إعادة كتابة التاريخ.

أضف حقول تدقيق في كل مكان تُنشر فيه مبالغ:

• created_at, created_by
• reason_code (شطب، تقريبا، حسن نية، استرداد)
• source_system (يدوي، استيراد، Stripe، أداة دعم)

اعتمادات، مرتجعات، وشطب دون إجماليات مكسورة

معظم مشاكل المصالحة تبدأ عندما تُسجل الاعتمادات والمرتجعات كـ "دفعات سالبة"، أو عندما يختلط الشطب مع بنود الفاتورة. مخطط دفتر نظيف يحفظ كل نوع مستند كسجل منفصل، والمكان الوحيد الذي يتفاعلون فيه هو عبر تخصيصات صريحة.

ينبغي أن توضح مذكرة الائتمان سبب تقليل ما يدين به العميل. إذا طُبقت على فاتورة واحدة، سجّل مذكرة ائتمان واحدة وخصصها لتلك الفاتورة. إذا طُبقت عبر عدة فواتير، خصص نفس مذكرة الائتمان لعدة فواتير. يبقى الائتمان مستندًا واحدًا مع تخصيصات متعددة.

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

المدفوعات الجزئية والاعتمادات الجزئية تعمل بنفس الطريقة: احتفظ بإجمالي الدفعة أو الائتمان في صف منفصل، واستخدم صفوف التخصيص لبيان المبلغ المطبق على كل فاتورة.

قواعد النشر التي تمنع العد المزدوج

هذه القواعد تزيل معظم "الفروقات الغامضة":

• لا تخزن دفعة سالبة أبدًا. استخدم سجل مرتجع.
• لا تقلل إجمالي الفاتورة بعد النشر. استخدم مذكرة ائتمان أو تعديل.
• انشر المستندات مرة واحدة (مع طابع زمني posted_at) ولا تحرر المبالغ بعد النشر.
• الشيء الوحيد الذي يغير رصيد الفاتورة هو مجموع التخصيصات المنشورة.
• الشطب هو تعديل مع كود سبب، يُخصص للفاتورة مثل الائتمان.

الضرائب والرسوم والعملات وخيارات التقريب

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

الضرائب والرسوم: احتفظ بها على مستوى السطر

خزن مبالغ الضريبة والرسوم لكل بند، ليس فقط كملخص على مستوى الفاتورة. قد يكون لكل منتج معدل ضريبي مختلف، الرسوم قد تكون خاضعة للضريبة أو لا، والإعفاءات قد تنطبق على جزء من الفاتورة فقط. إذا خزنت tax_total واحدة فقط، ستصادف حالة لا تستطيع تفسيرها.

احتفظ بـ:

• البنود الأولية (ما بيع، الكمية، سعر الوحدة، الخصم)
• إجماليات السطر المحسوبة (line_subtotal, line_tax, line_total)
• إجماليات ملخص الفاتورة (subtotal, tax_total, total)
• معدل الضريبة ونوعها المستخدم
• الرسوم كبنود منفصلة (مثل "رسوم معالجة الدفع")

هذا يسمح للمالية بإعادة بناء الإجماليات والتأكد من أن الضريبة حسبت بنفس الطريقة في كل مرة.

تعدد العملات: خزن ما حدث وكيف تُبلغ عنه

إذا دعمت عملات متعددة، سجّل كلًا من عملة المعاملة وقيم التقرير. الحد العملي الأدنى: currency_code على كل مستند نقدي، وfx_rate المستخدم عند النشر، ومبالغ التقرير المنفصلة (مثلًا amount_reporting) إذا كان دفتر حساباتك يغلق بعملة واحدة.

مثال: عميل مفوتر 100.00 EUR زائد 20.00 EUR ضريبة. خزّن بنود وإجماليات بالـ EUR، بالإضافة إلى fx_rate المستخدم عند ترحيل الفاتورة والمجاميع المحوَّلة للتقارير.

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

الحالات، تواريخ النشر، وما الذي لا يجب تخزينه

تصبح المصالحة فوضوية عندما يُستخدم "الحالة" كاختصار للحقيقة المحاسبية. عامل الحالة كوسم سير عمل، واجعل قيود الدفتر المنشورة مصدر الحقيقة.

اجعل الحالات صارمة ومملة. كل حالة يجب أن تجيب عن: هل يمكن لهذا المستند أن يؤثر في الإجماليات الآن؟

• Draft: داخلي فقط، غير منشور، لا يجب أن يظهر في التقارير
• Issued: مُنهى ومُرسل، جاهز للترحيل (أو مُرحَّل بالفعل)
• Void: مُلغى؛ إن كان قد نُشر، يجب عكسه
• Paid: مُستوفى تمامًا بواسطة مدفوعات واعتمادات منشورة
• Refunded: النقد عاد للخارج عبر مرتجع منشور

التواريخ أهم مما يتوقع معظم الفرق. ستسأل المالية: "لأي شهر ينتمي هذا؟" ويجب أن لا يعتمد جوابك على سجلات واجهة المستخدم.

• issued_at: متى أصبحت الفاتورة نهائية
• posted_at: متى تظهر في تقارير المحاسبة
• settled_at: متى تم تأكيد أو مقاصة الأموال
• voided_at / refunded_at: متى أصبح الإلغاء أو المرتجع نافذًا

ما لا يجب تخزينه كحقيقة: أرقام مشتقة لا يمكنك إعادة بنائها من الدفتر. حقول مثل balance_due, is_overdue, وcustomer_lifetime_value مقبولة كعروض مخبأة فقط إذا كنت دائمًا قادرًا على إعادة حسابها من الفواتير والمدفوعات والاعتمادات والتخصيصات والتعديلات.

مثال بسيط: فشل محاولة الدفع ضُربت مرتين على البوابة. بدون idempotency_key، قد تخزن دفعتين، وتعلّم الفاتورة "مدفوعة"، ثم ترى المالية مبلغًا إضافيًا قدره $100 في النقد. خزّن idempotency_key فريد لكل محاولة شحن خارجية وارفض التكرارات على مستوى قاعدة البيانات.

التقارير التي تتوقعها المالية من اليوم الأول

يثبت مخطط دفتر الفوترة نفسه عندما تستطيع المالية الإجابة عن الأسئلة الأساسية بسرعة والحصول على نفس الإجماليات دائمًا.

تبدأ معظم الفرق بـ:

• تقادم الحسابات المستحقة: المبالغ المفتوحة حسب العميل وفئات العمر (0-30، 31-60، إلخ)
• النقد المستلم: الأموال المجمعة يوميًا، أسبوعيًا، شهريًا، بناءً على تواريخ نشر المدفوعات
• الإيراد مقابل النقد: الفواتير المُرحَّلة مقابل المدفوعات المنشورة
• مسار تدقيق للصادرات: مسار تتبعي من سطر تصدير GL إلى المستندات وتخصيصات المصدر التي أنشأته

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

يجب أن يستند النقد المستلم إلى جدول المدفوعات، لا حالة الفاتورة. يمكن للعملاء أن يدفعوا مبكرًا، متأخرًا، أو جزئيًا.

الإيراد مقابل النقد هو سبب بقاء الفواتير والمدفوعات منفصلة. مثال: تصدر فاتورة $1,000 في 30 مارس، تتلقى $600 في 5 أبريل، وتصدر مذكرة ائتمان $100 في 20 أبريل. الإيراد يعود إلى مارس (ترحيل الفاتورة)، النقد ينتمي إلى أبريل (ترحيل الدفعة)، والائتمان يقلل المدينين عند ترحيله. التخصيصات هي التي تربط كل شيء.

سيناريو نموذجي: عميل واحد، أربعة أنواع مستندات

عميل واحد، شهر واحد، أربعة أنواع مستندات. يُخزن كل مستند مرة، والمال يتحرك عبر جدول التخصيص (المسمى أحيانًا "applications"). هذا يجعل الرصيد النهائي سهل إعادة الحساب وسهل التدقيق.

افترض العميل C-1001 (Acme Co.).

السجلات التي تنشئها

invoices

payments

credits (مذكرة ائتمان، رصيد حسن نية، إلخ)

adjustments (تصحيح بعد الحدث، ليس بيعًا جديدًا)

allocations (هذا ما يُصالِح الرصيد فعليًا)

كيفية حساب رصيد الفاتورة

بالنسبة INV-10، يمكن للمراجع إعادة حساب الرصيد المفتوح من الصفوف المصدرية:

open_balance = invoice.total + sum(adjustments) - sum(allocations)

إذاً: 120.00 + 5.00 - (70.00 + 20.00) = 35.00 مستحقة.

لتتبع الـ "35.00" رجعاً:

• ابدأ من إجمالي الفاتورة (INV-10)
• أضف التعديلات المنشورة المرتبطة بنفس الفاتورة (ADJ-3)
• اطرح كل تخصيص منشور مطبق على الفاتورة (AL-900, AL-901)
• تأكد أن كل تخصيص يشير إلى مستند مصدر حقيقي (PAY-77, CR-5)
• تحقق من التواريخ وposted_at لشرح التسلسل الزمني

أخطاء شائعة تكسر المصالحة

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

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

سبب متكرر آخر هو تغيير التاريخ. إذا صدرت فاتورة، لا تحررها لاحقًا لتتوافق مع سعر جديد أو عنوان مصحح. احتفظ بالمستند الأصلي وانشر تعديلًا أو مذكرة ائتمان تشرح التغيير.

أنماط تكسر الإجماليات عادة:

• استخدام صفوف سالبة بدون قاعدة عكسية صارمة ومرجع إلى الصف الأصلي
• تحرير فواتير قديمة بعد الإصدار بدلًا من نشر تعديلات أو مذكّرات ائتمان
• خلط معرفات معاملات البوابة مع المعرفات الداخلية بدون جدول مطابقة ومصدر حقيقة واضح
• السماح لكود التطبيق بحساب الإجماليات بينما تفتقد صفوف الدعم (الضريبة، الرسوم، التقريب، التخصيصات)
• عدم فصل "تحرك المال" (نقل نقد) عن "تخصيص المال" (أي فاتورة دفعها النقد)

النقطة الأخيرة تُسبب الارتباك الأكبر. مثال: يدفع العميل $100، ثم تطبق $60 على الفاتورة A و$40 على الفاتورة B. الدفعة حركة نقد واحدة، لكنها تخلق تخصيصين. إن خزنت فقط "الدفعة = الفاتورة"، فلن تدعم المدفوعات الجزئية أو الزيادات أو إعادة التخصيص.

قائمة تحقق وخطوات تالية

قبل إضافة ميزات أكثر، تأكد من أن الأساس متين. يتصالح مخطط دفتر الفوترة عندما يمكن تتبع كل إجمالي إلى صفوف محددة، ولكل تغيير أثر أثر تدقيق.

فحوصات سريعة للمصالحة

شغّل هذه الفحوصات على عينة صغيرة (عميل واحد، شهر واحد) ثم على مجموعة البيانات الكاملة:

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

خطوات تالية للشحن بشيء قابل للاستخدام

بمجرد أن يصبح المخطط ثابتًا، ابنِ سير العمل التشغيلي حوله:

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

إذا أردت طريقًا أسرع لبناء بوابة داخلية للمالية، AppMaster (appmaster.io) يمكن أن يساعدك على نمذجة مخطط PostgreSQL، وتوليد واجهات برمجة تطبيقات، وبناء شاشات الإدارة من نفس المصدر، بحيث تظل قواعد النشر والتخصيص متسقة مع تطور التطبيق.