کدینگ حسابداری صندوق قرض‌الحسنه؛ ساختار حساب‌ها در مبین

اگر سپرده عضو، آورده سرمایه و دریافت اصل قسط همگی زیر عنوان «وجوه اعضا» ثبت شوند، پیدا کردن یک عدد شاید آسان باشد، ولی توضیح آن دشوار می‌شود. صندوق باید بداند چه مبلغی را به عضو بدهکار است و چه مبلغی را از او طلب دارد. کدینگ حسابداری، جای ثبت و مسیر جمع شدن همین اطلاعات را روشن می‌کند.

در این راهنما، به‌جای پیشنهاد یک درخت فرضیِ جدا از نرم‌افزار، ساختار حساب‌های آموزشی در خود مبین را می‌بینید. شماره‌ها برای این نمونه انتخاب شده‌اند و کد اجباری یا الگوی قانونی همه صندوق‌ها نیستند. پیش از راه‌اندازی واقعی، تعریف هر حساب باید با روش حسابداری صندوق هماهنگ شود.

هر سطح قرار است کدام سؤال را جواب دهد؟

گروه، دسته بزرگ حساب را مشخص می‌کند؛ کل موضوع اصلی و معین زیرمجموعه دقیق‌تر آن را. در حساب‌های اعضا نیز باید ارتباط با شخص، قرارداد و حساب معین روشن باشد. شماره عضو، شماره حساب و شماره قرارداد شناسه‌های متفاوتی‌اند؛ یک نام مشترک جای این ارتباط‌ها را نمی‌گیرد.

در تصویر، حساب‌های کل نمونه زیر گروه‌های مربوط قرار دارند. برای بررسی ساختار، ابتدا بپرسید خروجی موردنیاز چیست: مانده هر حساب بانک، جمع سپرده اعضا یا اصل وام وصول‌نشده؟ سپس حساب‌های لازم را تعریف کنید.

حساب‌های کل نمونه و گروه والدشان در رابط واقعی مبین؛ تفکیک ساختار برای دنبال کردن جمع حساب‌ها.

ساختن حساب کل جدا برای تک‌تک اعضا معمولاً پیگیری ساختار را دشوار می‌کند. حساب کنترل باید جمع را نشان دهد و ریز حساب عضو، اجزای آن را توضیح دهد. اگر یک نفر چند وام دارد، صرف نام شخص برای تشخیص قرارداد هر پرداخت کافی نیست.

ثبت مستقیم در معین با حساب معینِ دارای ریز یکی نیست

در صفحه معین مبین، امکان ثبت مستقیم هر حساب هم مشخص است. در نمونه، بانک و نقد قابل ثبت مستقیم‌اند؛ معین سپرده و معین وام، ریز حساب‌های مربوط دارند. این انتخاب را باید با ساختار داده و گزارش صندوق هماهنگ کرد تا یک رویداد، هم در حساب کنترل و هم در ریز دوباره شمرده نشود.

ساختار واقعی نرم‌افزار با حساب‌های آموزشی؛ شماره‌ها نمونه‌اند. ماهیت ۱ بدهکار و ۲ بستانکار است؛ ثبت مستقیم حساب‌ها جدا مشخص شده است.

این شماره‌ها نمونه آموزشی‌اند؛ مهم، تعریف حساب و ارتباط درست سطوح است. در فهرست معینِ این نسخه، ماهیت ۱ بدهکار و ۲ بستانکار است. مانده علامت‌دار نیز بستانکار منهای بدهکار نمایش داده می‌شود؛ برای تفسیر، ماهیت و ستون‌های گردش را کنار آن بخوانید.

مثال: صد میلیون سپرده باید به عضو مشخص برسد

در داده نمونه، معین سپرده ۱۰۰٬۰۰۰٬۰۰۰ ریال بستانکار است و فقط یک ریز پس‌انداز دارد: حساب ۷۲۰۰۰۰۱ متعلق به عضو ۹۰۰۱، با همان مانده. در صفحه پرونده عضو، این رابطه و قرارداد مربوط دیده می‌شود. اگر چند عضو داشتیم، جمع ریز آن‌ها باید حساب کنترل را توضیح می‌داد.

عضو ساختگی ۹۰۰۱ و حساب پس‌انداز ۷۲۰۰۰۰۱ با ۱۰۰٬۰۰۰٬۰۰۰ ریال مانده بستانکار؛ اطلاعات شخصی واقعی در تصویر نیست.

برای کنترل کامل، فقط جمع را نبینید؛ از یک رسید تا حساب عضو و از آن تا گزارش حرکت کنید. دریافت یک عضو به حساب عضو دیگر می‌تواند جمع کل را تغییر ندهد. برای وام هم ریز قرارداد و مانده اصل باید قابل پیگیری باشد.

هنگام تغییر کدینگ چه چیزی را نگه داریم؟

برای هر حساب، تعریف، ماهیت، حساب والد، امکان ثبت، وضعیت و مسئول تغییر را مشخص کنید. حساب دارای سابقه را بدون بررسی آثارش برای معنای دیگری استفاده نکنید. در مهاجرت، نگاشت کد قدیم به جدید و مواردی که چند حساب ادغام یا یک حساب تفکیک می‌شود باید قابل بازبینی باشد.

بعد از تغییر، یک دریافت سپرده، پرداخت اصل وام و انتقال داخلی را بررسی کنید: حساب‌ها درست انتخاب شوند، جمع‌ها برابر بمانند و ریز عضو از گزارش حذف نشود. برای یک دریافت با چند جزء نیز هر بخش باید طبق مدرک به حساب درست برود؛ ثبت همه مبلغ در «سایر» نباید جای دائمی تعیین ماهیت باشد.

نیاز به تفکیک شعبه یا مرکز هزینه را هم دقیق بنویسید. وجود ساختار حساب، به‌تنهایی اثبات گزارش تجمیعی یا تفکیک همه اطلاعات شعب نیست. درباره این نیازها، راهنمای صندوق چندشعبه‌ای را ببینید؛ تراز آزمایشی نیز مرحله کنترل جمع سطوح است.

در مبین، صفحات گروه، کل، معین و پرونده حساب، این ساختار را قابل مشاهده می‌کنند. برای انتخاب یا راه‌اندازی نرم افزار حسابداری صندوق قرض الحسنه، فهرست حساب‌های فعلی و گزارش‌های ضروری را مبنای بررسی نیازهای صندوق با تیم مبین قرار دهید. انتقال اطلاعات به مبین ادامه همین آماده‌سازی است.

مبنای عمومی تفکیک دارایی، بدهی و حقوق مالکانه: چارچوب مفهومی بنیاد IFRS. شماره‌گذاری و درخت این مثال از داده آموزشی نرم‌افزار است.