هر کس مدتی در واحد مالی یک بانک یا صندوق کار کرده باشد، این صحنه را دیده است. پایان روز، عدد سامانهٔ سپرده با عدد حسابداری نمیخواند و کسی باید تراکنشها را یکییکی کنار هم بگذارد تا پیدا کند اختلاف از کجا آمده است. گاهی یک سند دستی فراموش شده، گاهی تراکنشی در یک سامانه ثبت شده و در دیگری نه، و گاهی قطعی کوتاه شبکه درست وسط یک انتقال رخ داده است.
این اختلافها معمولاً از بیدقتی کارکنان نیست و ریشه در معماری دارد. وقتی سامانهٔ سپرده ماندهٔ حساب را در جدول خودش نگه میدارد، سامانهٔ کارت ماندهٔ اعتبار را در جدول خودش، و حسابداری هم ماندهٔ همان حسابها را در سرفصلهای خودش، برای یک واقعیت سه عدد وجود دارد. همگامسازی هر قدر هم دقیق باشد، دیر یا زود یکی از این عددها از بقیه جدا میافتد.
تصمیمی که در دارا گرفتیم
در دارا هیچ ماژولی ستون مانده ندارد. سپرده، کیف پول، کارت اعتباری، تسهیلات و پرتفوی سرمایهگذاری موجودی را از هستهٔ مالی میخوانند و هر اثر مالی را بهصورت سند در همان هسته ثبت میکنند. ماژول سپرده اطلاعاتی مثل شمارهٔ حساب، صاحبان حساب، دسته و سیاستها را نگه میدارد، اما مبلغ موجودی را فقط هستهٔ مالی میداند.
برای اینکه این کار شدنی باشد، چارت حساب باید جزئیات را در خود جا بدهد. چارت حساب دارا تا شش سطح تفصیل پایین میرود و تفصیلها شناورند. هر حساب سپرده، هر کیف پول و هر قرارداد تسهیلات تفصیل اختصاصی خود را زیر سرفصل مربوط دارد. به این ترتیب گردش حساب تفصیلی یک مشتری همان صورتحسابی است که او در اپ میبیند و برای ساختنش به منبع دیگری نیاز نیست.
برداشت در این مدل چطور کنترل میشود
ماژول سپرده پیش از ثبت برداشت، موجودی در دسترس را از هسته میگیرد؛ یعنی ماندهٔ تفصیلی حساب منهای مسدودیهای فعال. اگر مبلغ کافی باشد، سند برداشت در هسته ثبت میشود و بعد وضعیت عملیات در خود ماژول بهروز میشود.
ترتیب این دو گام اهمیت دارد. اگر ارتباط وسط کار قطع شود، یا سند ثبت نشده و اتفاقی نیفتاده است، یا سند ثبت شده و ماژول در تلاش بعدی آن را پیدا میکند. حالتی که پول جابهجا شده باشد و سندی پشتش نباشد پیش نمیآید.
تکرار هم مسئلهٔ دیگری است. شبکه گاهی پاسخ را گم میکند و فرستنده همان درخواست را دوباره میفرستد. در دارا هر درخواست ثبت سند یک کلید یکتا دارد. اگر درخواستی با کلید تکراری برسد، هسته همان سند قبلی را برمیگرداند و سند دوم نمیسازد.
سند سهمرحلهای و شمارهٔ عطف
سند در هستهٔ مالی سه مرحله دارد: یادداشت، موقت و دائم. گذار میان این مرحلهها در خود سامانه کنترل میشود و سند دائم دیگر ویرایش نمیشود. خرید با کارت اعتباری مثال خوبی است. در لحظهٔ خرید سند موقت ثبت میشود و اعتبار مشتری کم میشود؛ وقتی پذیرنده خرید را تأیید کرد، همان سند دائم میشود.
شمارهٔ عطف هر دورهٔ مالی از شمارندهٔ اختصاصی همان دوره گرفته میشود و به عقب برنمیگردد. حسابرس با دنبالهای پیوسته از شمارهها روبهروست و جای خالی یا شمارهٔ تکراری در آن نمیبیند.
برای واحد مالی چه تغییر میکند
- مغایرتگیری میان زیرسیستمها از کارهای پایان روز حذف میشود، چون عدد دومی وجود ندارد. مغایرتگیری با صورتحساب بانکها سر جای خود میماند و در خزانهداری انجام میشود.
- گزارشهای مالی، از تراز آزمایشی و گردش حساب کل و معین و تفصیلی تا ترازنامه، از همان دادهای ساخته میشوند که کارمند باجه با آن کار میکند.
- عددی که مشتری در اپ میبیند با عدد گزارش پایان دوره یکی است.
- افزودن محصول تازه، مثلاً یک نوع کیف پول یا کارت، به نوشتن دوبارهٔ منطق مانده نیاز ندارد. ماژول تازه به همان هسته وصل میشود.
هزینهٔ این تصمیم
این معماری هزینه هم دارد. همهٔ ماژولها برای خواندن مانده به هستهٔ مالی وابستهاند، پس هسته باید همیشه در دسترس و پاسخگو باشد. به همین دلیل خواندن مانده در هسته ساده نگه داشته شده و ثبت سند از یک مسیر واحد انجام میشود. در طراحی استقرار هر پروژه هم هستهٔ مالی حساسترین جزء است و ظرفیت آن جداگانه برنامهریزی میشود.
با این حال، به نظر ما نگه داشتن یک هستهٔ پایدار سادهتر از تطبیق هرروزهٔ چند عدد رقیب است، هم برای تیم فنی و هم برای واحد مالی. بیشتر تصمیمهای طراحی دیگر دارا، از موتور فرایند تا کیف پول، روی همین پایه گرفته شدهاند.
- #هستهٔ_مالی
- #معماری
- #مغایرتگیری
- #سند_حسابداری
