من أحد المترجمين : خلال عملي في شركة fintech النيجيرية ، اضطررت إلى إنشاء نظام دفع واحد من البداية. في ذلك الوقت ، لم أفهم شيئًا فعليًا حول المحاسبة ، في كيفية تخزين المدفوعات والأرصدة. ولكن كان هناك شك في أن الخيار البدائي برقم رصيد واحد في حساب المستخدم سهل للغاية.
ساعدني هذا المقال في فهم وتجنب حفنة من المشاكسات في هذا الشأن. في الوقت نفسه ، فإن المعلومات حول موضوع "كيفية جعل نظام الدفع الخاص بك" صغيرة جدًا ، وليس من السهل على المبرمج فهم الكتب المتعلقة بالمحاسبة (ومملة للغاية). آمل أن تكون هذه المواد مفيدة لأولئك الذين سيفعلون شيئًا كهذا.
أعتذر فورًا عن عدم الدقة المحتملة في المصطلحات المالية الناطقة باللغة الروسية - ما زلت مبرمجًا ، لا محاسب ، ولست على دراية بالمصطلحات الروسية في هذا المجال.
مقدمة
تخزن العديد من أنظمة الكمبيوتر التي تستخدم قواعد البيانات العلائقية نوعًا من المعلومات المالية حول الأرصدة والمعاملات. علاوة على ذلك ، غالبًا ما يثير تصميم قاعدة البيانات هذه وتطويرها مسألة كيفية تخزين هذه المعلومات. عادة ما يكون الاختيار بين "تسجيل بسيط" رخيص و "تسجيل مزدوج" أكثر تعقيدًا.
لوكا باشيولي ، مؤلف كتاب أقدم (القرن الخامس عشر) على قيد الحياة يصف مبادئ الدخول المزدوج
في نظام "السجل البسيط" ، يتم تسجيل القيم العددية مرة واحدة فقط. في نظام القيد المزدوج ، يتم تسجيل كل قيمة مرتين كرصيد (قيمة موجبة) وكخصم (قيمة سالبة). هناك مجموعة من القواعد التي تحدد العلاقة بين هذه القيم. سيتم وصف هذه القواعد بسهولة لك من قبل أي محاسب متمرس ، على الرغم من أنه قد لا يتخيل كيف يمكن تمثيلها في قاعدة بيانات علائقية.
القواعد الأساسية هي كما يلي:
- يجب أن يكون كل إدخال في النظام متوازناً ، أي مجموع القيم في عملية واحدة يجب أن يعطي صفر.
- يجب أن يعطي مجموع جميع القيم في النظام بأكمله في أي وقت معين صفرًا (قاعدة ما يسمى "ميزان المراجعة").
- لا يمكن تحرير أو حذف القيم التي تم إدخالها بالفعل في قاعدة البيانات. إذا كانت التصحيحات ضرورية ، يجب أولاً إلغاء العملية عن طريق عملية أخرى مع الإشارة المعاكسة ، ثم تكرارها بالقيمة الصحيحة. يتيح لك ذلك تنفيذ مسار تدقيق موثوق (سجل كامل لجميع المعاملات ، غالبًا ما يكون مطلوبًا أثناء عمليات التفتيش).
مضاعفة مسك الدفاتر
في بداية المشروع ، يكون السعر المنخفض للتسجيل البسيط مغريًا دائمًا ، ويبدو أن تكلفة التنفيذ وتعقيد التسجيل المزدوج الكامل غير ضروري. ومع ذلك ، في الواقع ، في كثير من الأحيان باستخدام تسجيل بسيط هو وفورات خاطئة.
إذا كانت المعلومات المحاسبية في نظام تكنولوجيا المعلومات تنسخ فقط السجلات الورقية الموجودة المخزنة خارج قاعدة البيانات التي يجري تطويرها ، فإن السجل البسيط لا يزال له الحق في الحياة. ومع ذلك ، إذا كانت واحدة على الأقل من حقائق النظام المدرجة أدناه صحيحة ، فيجب استخدام الإدخال المزدوج من البداية:
- إذا كان أي وقت مضى مطلوب مراجعة الحسابات من المعلومات
- إذا كانت المعلومات الموجودة في النظام هي المصدر الوحيد للمعلومات حول العقار
- إذا كانت المعلومات تتعلق بأشياء ذات قيمة عالية
- إذا كان من المخطط تطوير النظام بجدية في المستقبل
مثال على الدخول المزدوج
إن الفكرة الأساسية للدخول المزدوج هي وجود حساب "دفتر نقدي" خاص ( ترجمة تقريبية: لم أجد كيف أسميها باللغة الروسية بشكل كاف ، هل يمكن لأحد أن يقول لي؟ ). يحتوي هذا الحساب على سجلات يتم تسجيلها عند إيداع الأشياء الثمينة (مثل المال) أو سحبها من نظامنا المحاسبي. وبالتالي ، يعكس الرصيد الحالي لهذا الحساب إجمالي عدد القيم في النظام.
التالي مثال بسيط مع حسابين ، "دفتر النقدية" و "سميث".
(أ) يتم إدخال 300 جنيه استرليني في النظام وتودع في حساب سميث. يتم إنشاء قرض بقيمة 300 جنيه إسترليني في حساب سميث (ائتمان على اليمين ، خصم على اليسار). لتسوية هذا المبلغ ، يتم إنشاء خصم بقيمة 300 جنيه إسترليني في حساب دفتر النقدية.
(ب) سميث ثم يستنتج 50 £ من النظام. نقوم بإنشاء خصم لهذا المبلغ في حساب سميث وائتمان في دفتر النقدية.
(ج) أضف حساب Pattel آخر وقم بتحويل 100 جنيه إسترليني له من Smith. للقيام بذلك ، نحتاج إلى إنشاء خصم لهذا المبلغ مع Smith وقرض مع Pattel.
(د) لمسة نهائية ، اسمح لـ Pattel الآن بسحب 60 جنيهًا إسترلينيًا من النظام. نقوم بإنشاء خصم في حسابه وائتمان في دفتر النقدية.
نتيجة لكل هذه العمليات ، يمكننا حساب أن الرصيد الكلي لـ Smith هو 150 جنيهًا إسترلينيًا ، و Pattela 40 جنيهًا إسترلينيًا ، وفي Cash Cash -190 جنيهًا إسترلينيًا ، وهو المبلغ السلبي لأرصدة جميع الحسابات الأخرى. استنادًا إلى هذه القواعد والعمليات البسيطة في المستقبل ، يمكنك إنشاء نظام شامل للتحكم في القيمة.
نموذج البيانات
هيكل نموذج بيانات بسيط يمكن استخدامه لتمثيل كل هذه المعلومات:
يحتوي جدول POSTING على الإدخالات المزدوجة نفسها. تخزين جميع الأرقام في جدول واحد يسهل إلى حد كبير جميع العمليات الحسابية. يجب استخدام عداد زيادة رتابة كمفتاح أساسي. يجب أن تسير القيم على التوالي ، في هذه الحالة ، من خلال الرقم الذي يمكنك دائمًا التأكد من أنه لم يتم حذف أي سجل فيه. يتم استخدام الجداول BATCH و JOURNAL للتحكم وإدخال البيانات في جدول POSTING هذا.
يمثل كل إدخال في جدول JOURNAL معاملة (من منظور أعمال) تنشئ إدخالات مزدوجة. مثل هذه المعاملة هي وحدة عمل مكتملة أو عملية تجارية. يجب إكمال جميع سجلات POSTING المرتبطة بسجل JOURNAL بنجاح ، أو عدم إكمال أي منها. يجب أن يكون مجموع جميع سجلات POSTING في معاملة واحدة صفراً. يتم تمثيل كل عملية نقل من المثال أعلاه بإدخالها في جدول JOURNAL
يتم الإدخال في الجدول BATCH من أجل راحة إدخال البيانات. يتم استخدامه لتجميع سجلات JOURNAL في حزم ملائمة ، على سبيل المثال ، مجموعة من عمليات التحقق للدخول إلى النظام ، أو نوع من عمليات الأعمال العالمية ، مثل فرض الفائدة على جميع المستخدمين في وقت واحد ، إلخ.
يخزن جدول الحساب بيانات على مالكي القيم في النظام.
يحتوي جدول ASSET TYPE على معلومات حول أنواع القيم المستخدمة في النظام. بإضافة نوع قيمة إلى المفتاح الأساسي لجدول POSTING ، يمكنك إنشاء نظام يعمل على عدة أنواع من القيم في وقت واحد (على سبيل المثال ، معالجة عدة عملات).
إليك كيف يمكن أن تبحث قاعدة البيانات هذه عن المثال أعلاه في الشكل الأكثر بساطة:
ميزان عمود المبلغ في جدول POSTING يكون دائمًا صفراً بعد إتمام أي معاملة من JOURNAL (يجب أن يضمن البرنامج عدم وجود سجلات للمعاملات غير المكتملة في قاعدة البيانات).
يعطي مجموع العمليات لحساب Cash Book -190 ، وهو ما يساوي مجموع أرصدة Smith و Pattel مع الإشارة المعاكسة.
لإظهار العملية متعددة العملات ، تمت إضافة نوع جديد من القيمة. إذا أراد سميث استبدال 20 جنيهًا مقابل الدولار بمعدل 1 مقابل 1.5 ، فسيتم إجراء المعاملة من خلال Cash Cash بهذه الطريقة:
فترات الفوترة
يبدو النموذج رائعًا ، لكن في الواقع سوف ينكسر بسرعة كبيرة تحت عبء كبير نظرًا لحقيقة أننا لا نستطيع حذف أي شيء ونضطر إلى إعادة حساب عدد السجلات المتزايد باستمرار في POSTING.
معظم النظم المحاسبية لديها مفهوم فترة الفوترة - عادة ما تكون شهر أو ثلاثة أشهر أو سنة. تشير هذه الفترة إلى نقاط ملائمة لتقسيم دفق البيانات. عادة ما تكون النقطة المناسبة هي نهاية السنة أو التقويم أو المالي.
يمكننا إضافة عمود مع مؤشر فترة إلى جدول POSTING وإلى مفتاحه الأساسي ، بتقسيم البيانات إلى مجموعات يمكن معالجتها بشكل مستقل. في حالة وجود بعض السجلات في المثال أعلاه في فترة إعداد فواتير جديدة ، فسيتم ترحيل أرصدة الحسابات كما يلي.
أولاً ، سيتم مسح أرصدة الفترة السابقة.
وبعد ذلك سيتم نقلهم إلى فترة جديدة
بعد وقت معين ، يمكن إرسال جميع سجلات فترة YEAR 1 إلى الأرشيف وحذفها من النظام دون أن تفقد سلامتها.
تجميع المعاملات
يمكن أن تؤثر بعض العمليات في نظام المحاسبة على العديد من المستخدمين ، أو حتى جميعهم ، مرة واحدة. على سبيل المثال ، مدفوعات الفائدة لجميع المستخدمين في شكل حصة من رصيدهم الحالي.
يمكن معالجة هذه العمليات كجزء من معاملة واحدة في جدول JOURNAL ويمكنك تجميع جميع العمليات باستخدام Cash Book في سجل واحد مشترك في جدول POSTING (بدلاً من إنشاء عملية منفصلة لكل حساب). سيتيح لك ذلك الامتثال لجميع القواعد المحاسبية المذكورة أعلاه وفي نفس الوقت خفض عدد السجلات في قاعدة البيانات إلى النصف. باستخدام هذا النهج ، ستبدو نهاية العام في قاعدة البيانات كما يلي:
تجهيز الدفعات
غالبًا ما تستخدم معالجة الدُفعات لتبسيط إدخال البيانات في نظام المحاسبة.
تاريخيا ، عملت معالجة الاختيار مثل هذا. أعطيت للمحاسب حزمة من عشرة شيكات ، وعدد العبوة والمبلغ الإجمالي لجميع الشيكات. في المرحلة الأولى ، يتم إدخال الشيكات في النظام في شكل إدخالات "غير مصرح بها". في هذه الحالة ، من خلال جدول BATCH ، يتم فحص الكمية والكمية الإجمالية ، وفقط في حالة تطابق القيمة الصحيحة ، يُسمح للمستخدم بالالتزام بالحزمة. بعد الانتهاء من ذلك ، يتم إرسال الحزمة إلى موظف آخر يقوم بفحصها للتأكد من صحتها ثم "يأذن" إذا تم إدخال كل شيء بشكل صحيح.
وتسمى هذه العملية "صانع / المدقق" ويمكن استخدامها لإدخال أي بيانات ذات صلة في النظام.
في هذه الحالة ، ستكون السجلات "غير المصرح بها" في جدول منفصل عن المجموعة الرئيسية للسجلات المزدوجة في جدول POSTING صحيحة. يمكنك أيضًا الحصول على عدد من هذه الجداول لعمليات تجارية مختلفة. على سبيل المثال ، في حالة الشيكات التي يتم من خلالها إدخال الأموال أو سحبها من النظام ، سيحتاج المحاسب فقط إلى التحقق من حساب واحد. منذ الثانية ، وكتاب النقدية ، في مثل هذه العمليات هو دائما ضمني. في هذه الحالة ، سيكون من الممكن في جدول CHECK إدارة عمود واحد فقط مع الحساب ، بينما في الجدول الافتراضي ستكون هناك حاجة إلى عمودين: "المرسل" و "المستلم".
هذا هو المكان الذي ينشأ فيه سوء الفهم الأساسي لمبادئ التسجيل المزدوج. معظم الناس في الحياة العادية يصادفون فقط دفاتر المحاسبة الورقية البسيطة. في مثل هذا الكتاب الورقي ، على سبيل المثال ، لحساب الموارد المالية لنادي مصلحة معين ، تحتاج فقط إلى إدخال واحد لكل عملية. ومع ذلك ، لا يزال يحتوي على إدخال مزدوج ضمني ، نظرًا لوجود حساب دفتر شيكات ضمني دائمًا (في هذه الحالة ، هذا هو النادي) ، نظرًا لأن جميع التدفقات النقدية تكون إما مدخلات (دفع الرسوم من قبل المشاركين) أو سحب أموال من النظام (الإنفاق) النادي).
السبب الثاني للمفاهيم الخاطئة هو أن الأموال المودعة في الحساب ستعتبر في "بيانات الحساب الشخصي" "قرض" ، لأن الشخص يقرض أساسًا إلى بنك يتلقى أمواله. على الرغم من أن هذا الشخص حافظ على دفتر الأستاذ الخاص به ، فقد تم تسجيل هذا الإدخال فيه كـ "مدين" - حيث أن البنك مدين لهذا العميل بعملته. يتم سحب هذه الأموال من "نظام الدفع" للمستخدم وإدخالها في النظام المصرفي.
هندسة البرمجيات
يتم تطوير البرمجيات التي تنفذ مثل هذا النظام المحاسبي مزدوج القيد باستخدام OOP ونهج متدرج. المستويات هي كما يلي:
- الواجهة الخارجية
- منطق العمل
- العمل مع DB
بالطبع ، ستعتمد بنية النظام على ما يجب أن يفعله هذا النظام بالضبط ، ومع ذلك ، يمكننا افتراض وجود الوحدات التالية فيه:
PostEntry: وحدة نمطية تتحكم في إنشاء إدخالات مزدوجة في جدول POSTING. إنه مسؤول عن إدراج السجلات وتعيين المعرفات والطوابع الزمنية. لا يمكن للوحدة حذف السجلات أو تعديلها ، ولا ينبغي لأي وحدة أخرى حذف هذه السجلات أو تعديلها ، باستثناء الحذف المحتمل للسجلات المؤرشفة القديمة لفترات إعداد الفواتير غير الملائمة بالفعل. يجب أن يكون جدول POSTING للقراءة فقط لجميع الوحدات النمطية الأخرى.
MakeDeposit ، MakeWithdrawal ، MakeTransfer: تقوم هذه الوحدات بتطبيق منطق الأعمال الأساسي لعمليات تحويل الأموال. سوف يستخدمون وحدة PostEntry لإدخال نتائجهم في قاعدة البيانات.
ChequeEntry و ChequeAuthorisation ، ReceiveBACS ( ملاحظة: BACS هو نظام دفع بين البنوك ): هذه الوحدات سوف تربط النظام مع العالم الخارجي وتوفر واجهة عالية المستوى. سوف يستخدمون وحدات طبقة الأعمال لأداء وظائفهم. في هذه الحالة ، يمكنك ضمان المعالجة الصحيحة بغض النظر عن طريقة إدخال البيانات ، حيث أن ChequeEntry و ReceiveBACS سيعملان على نفس MakeDeposit
يمكن تطبيق هذه الطريقة لفصل الطبقات إلى حد أكبر أو أقل ، اعتمادًا على تعقيد النظام والنقاء المرغوب فيه لاستخدام مبادئ تصميم الكائن. في الوقت نفسه ، قد يكون من المنطقي ، على سبيل المثال ، السماح لوحدة إنشاء التقارير (على سبيل المثال TestTrialBalance) بالوصول مباشرة إلى قاعدة البيانات من مستوى الواجهة - بدلاً من إنشاء وحدات نمطية وسيطة على طبقات العمل وقاعدة البيانات.
ميزان المراجعة
"ميزان المراجعة" - الطريقة الرئيسية للتحقق من سلامة النظام المحاسبي. إذا تم إدخال جميع الإدخالات في النظام وفقًا لقواعد الإدخال المزدوج ولم تكن هناك أخطاء ، فيجب أن يكون مجموع كل الإدخالات صفرًا. إن احتمال حدوث أخطاء منفصلة عديدة وإعطاء ما مجموعه صفر على قاعدة غير صالحة عادة ما يكون صغيراً للغاية بحيث يتم إهماله.
أفضل طريقة للتحقق هي حركة ثابتة من المستوى العلوي إلى الأسفل. الشيكات منطقية بهذا الترتيب:
- مجموع كل القيم في عمود POSTING.Amount
إذا تم العثور على خطأ (القيمة ليست صفرية) ، فقم بما يلي: - مجموع كل قيم POSTING.Amount ، لكن يتم حسابه بشكل منفصل لأنواع مختلفة من القيم وفترات التسوية
في هذه المرحلة ، يجب أن يصبح الأمر أكثر وضوحًا في أي جزء من النظام حدث خطأ. - التحقق من العمليات الفردية في جدول JOURNAL. نظرًا لأن مجموع جميع POSTING.Account في كل معاملة من جدول JOURNAL يجب أن يعطي أيضًا صفرًا ، فيمكنك تتبع المعاملة المعضلة المحددة.
أنواع منشورات JOURNAL
يحتوي جدول JOURNAL على تمثيل بسيط للكيانات ، والذي غالباً ما يثبت أنه أكثر تعقيدًا ويشارك في علاقات مختلفة.
في بعض الأحيان يكون من المنطقي تقسيم جدول واحد إلى عدة. على سبيل المثال ، في MATERIALIZED و DEMATERIALIZED ، والتي قد تحتوي على مجموعة مختلفة من الأعمدة ، على سبيل المثال ، قد تتطلب كيانات المواد بيانات عن موقعها الحالي.
أو في جدول واحد ، يمكن تخزين أنواع فرعية مختلفة من القيم ، مثل العملة أو الأوراق المالية ، ويمكن أن يكون لكل نوع فرعي مجموعة الخصائص والسمات الخاصة به.
يمكن تنظيم الكيانات التي تحتوي على كل من الأنواع الفرعية والنوعية في قاعدة البيانات بإحدى الطرق الأربع (هذا وضع قياسي إلى حد ما لأي قاعدة بيانات):
- جدول واحد كبير مشترك مع العديد من الأعمدة الاختيارية لسمات النوع الفرعي
- جدول منفصل لكل نوع فرعي ، مع تكرار جميع الأعمدة الشائعة
- افصل الكيانات بحيث يتم تخزين النوع الفائق في جدول منفصل وينضم إلى الجداول الأخرى التي تحتوي على أعمدة محددة فقط من النوع الفرعي
- كما هو الحال في 3 ، ولكن مع ازدواجية أعمدة الكتابة الفائقة في جداول الأنواع الفرعية
كل خيار من الخيارات الأربعة له إيجابيات وسلبيات. من وجهة نظر الإدخال المزدوج ، من المفيد أن يكون لديك جدول مشترك لإدخالات POSTING. الخيار 1 هو الأنسب لنظام محاسبة بسيط (كما في الأمثلة في هذه المقالة ، حيث يتم تحديد الفرق الوحيد في أنواع القيم بواسطة العمود JOURNAL.Type). ربما يكون الخيار 3 أكثر ملاءمة للأنظمة المعقدة التي تعمل مع مجموعة واسعة من القيم المختلفة جدًا.