کنترل داخلی مالی و پیشگیری از خطا
تفکیک دسترسی، برگشت سند، جلوگیری از پرداخت تکراری و تست‌های مالی
کنترل داخلی حسابداری: امنیت، تأیید، ثبت تکراری و اصلاح اسناد
خطاهای مالی صرفاً خطای تایپ نیستند. یک پرداخت تکراری، دسترسی اشتباه به اطلاعات شخص دیگر یا پاک‌کردن سند قطعی می‌تواند اثر جدی داشته باشد. هدف کنترل داخلی این است که هر عدد به مدرک قابل اعتماد و هر تغییر به شخص مسئول برسد.
پنج اصل کاربردی
۱. جداسازی نقش‌ها: تهیه‌کننده سند، تأییدکننده آن و اجراکننده پرداخت در عملیات حساس ترجیحاً افراد یا مجوزهای جدا باشند.
۲. کمترین دسترسی: کاربر ثبت هزینه خرد لازم نیست بتواند پروفایل حسابداری یا دوره بسته را تغییر دهد.
۳. تفکیک شخصیت و Tenant: حساب بانکی، طرف حساب، سند و گزارش نباید از کسب‌وکار/واحد دیگری قابل استفاده یا مشاهده باشند.
۴. یکتایی عملیاتی: خطای شبکه نباید باعث ثبت دوباره خرید، فاکتور، دریافت یا پرداخت شود. شناسه درخواست و مرجع اصلی را حفظ کنید.
۵. اصلاح سابقه‌دار: سند قطعی را با برگشت/اصلاح مجاز جبران کنید، نه ویرایش پنهانی یا حذف.
مواردی که باید در هر فرم مالی مشخص باشند
| سؤال | کنترل مناسب |
|---|---|
| چه کسی ثبت کرد؟ | کاربر ثبت‌کننده و زمان ایجاد |
| چه کسی مجاز به تأیید بود؟ | نقش و سطح مجوز عملیاتی |
| برای کدام واحد ثبت شد؟ | شخصیت حسابداری معتبر |
| مبلغ به چه ارزی است؟ | ارز آشکار با تبدیل معتبر |
| آیا موجودی تغییر کرد؟ | وضعیت ثبت قطعی، نه فقط موفقیت ذخیره UI |
| مدرک اصلی کجاست؟ | فاکتور، رسید، سفارش، تراکنش بانک یا مرجع عملیات |
| آیا قبلاً ثبت شده؟ | شناسه مرجع/idempotency/کلید ورود بانک |
| اگر اشتباه بود چه می‌شود؟ | سند اصلاحی قابل ردیابی و کنترل دوره |
ثبت پیش‌نویس در برابر اثر دفتری
یک فرم ممکن است پیام «با موفقیت ذخیره شد» بدهد اما سند دفترکل هنوز پیش‌نویس باشد. این رخداد نباید به عنوان کاهش قطعی بانک یا افزایش قطعی هزینه در گزارش نمایش داده شود. در مسیر خرید ساده، هزینه روزانه یا آورده مالک، وضعیت ثبت و تأیید را بررسی کنید.
جلوگیری از دوباره‌شماری
به‌طور خاص این سه ارتباط حساس‌اند: رسید بانک ↔ سند دفترکل، فاکتور ↔ تخصیص وجه و رسید کالا ↔ موجودی/بهای تمام‌شده. اگر یکی از این‌ها با تراکنش مستقل جدید «ترمیم» شود، ممکن است ارقام دو برابر شوند.
سطح دسترسی و حریم خصوصی
در نسخه فعلی دسترسی منابع و عملیات با مجوزهای Backend کنترل می‌شوند. پنهان‌کردن دکمه در Frontend جای مجوز سروری نیست. هنگام ارائه گزارش به مشتری، اطلاعات حساب بانکی، شبا، شناسه ملی و مشخصات شخص ثالث را فقط به کاربران مجاز نشان دهید.
چک‌لیست پیش از انتشار تغییرات مالی
- ثبت خرید/فروش، پرداخت و دریافت را در محیط آزمایشی با سند قطعی بررسی کنید.
- تست دوبار ارسال یک درخواست و چند عملیات هم‌زمان را اجرا کنید.
- تست جداسازی Tenantها و شخصیت‌های حسابداری را انجام دهید.
- با حساب‌های مختلف، وضعیت دکمه و مجوز سروری را کنترل کنید.
- بستن/بازگشایی دوره و برگشت سند را بررسی کنید.
- صورت‌حساب بانک و تراز آزمایشی را پیش و پس از عملیات مقایسه کنید.
- سناریوی ریال/تومان و ارقام بزرگ و اعشاری را تست کنید.
- مستند کنید چه چیزی واقعاً تست شده و کدام مسیر هنوز بتا است.
اگر مشکلی کشف شد
ابتدا رکورد مبنا و شناسه‌ها را ثبت کنید، جلوی تکرار عملیات را بگیرید، سند/رویداد/بانک را تطبیق دهید و بعد برای اصلاح با مجوز اقدام کنید. اضافه‌کردن یک سند دستی برای مساوی‌کردن کارت داشبورد راه‌حل قابل دفاع نیست.
ادامه
ثبت سند · دوره مالی · نقش‌ها و مجوزها
سناریوی پرداخت تکراری بعد از قطع اینترنت
حسابدار درخواست پرداخت ۱۰ میلیون به تأمین‌کننده را ثبت می‌کند. شبکه قطع می‌شود و دکمه در مرورگر نتیجه‌ای نشان نمی‌دهد. اینجا دو احتمال وجود دارد: درخواست اصلاً به سرور نرسیده یا به سرور رسیده و ذخیره شده اما پاسخ به مرورگر برنگشته. اگر بلافاصله روی ثبت دوباره کلیک کند، ممکن است دو درخواست معتبر تولید شود. راه درست این است که با شناسه عملیات، طرف حساب، مبلغ و زمان، وجود درخواست اول بررسی شود؛ سپس در صورت روشن‌بودن وضعیت اقدام شود. برای پرداخت بانکی باید وضعیت بانک نیز بررسی شود، چون ممکن است درخواست از مرحله داخلی عبور کرده باشد.
جداسازی اختیار ثبت از اختیار ویرایش قواعد
کارمند می‌تواند هزینه خرید ملزومات را ثبت کند، ولی نباید بتواند حساب هزینه، حساب بانکی و دوره‌های قطعی را بی‌ضابطه تغییر دهد. مدیر مالی باید مجوز نگاشت حساب و اصلاح سند را داشته باشد و اجرای پرداخت پرمبلغ نیازمند تأیید مجزا باشد. در سیستم‌های چندشخصیتی باید تست شود که کاربر یک شخصیت، رکورد شخص یا بانک شخصیت دیگر را از طریق تغییر پارامتر API دریافت یا ویرایش نمی‌کند. مخفی‌کردن یک گزینه در رابط، به‌تنهایی امنیت سرور نیست.
ممیزی وضعیت‌ها
برای هر عملیات حساس زمان ایجاد، کاربر درخواست‌دهنده، تأییدکننده، ثبت‌کننده قطعی و نتیجه بانک را جدا نگه دارید. رسید/سند مرجع باید به عملیات متصل باشد. وقتی اصلاحی انجام می‌شود، علت و رابطه با عملیات اولیه باید در تاریخچه باقی بماند. اگر فقط آخرین مقدار نمایش داده شود و امکان تشخیص اینکه چه کسی چه چیزی را تغییر داده نباشد، رسیدگی حسابرسی دشوار می‌شود.
کنترل دوره بسته
تغییر تاریخ سند برای جا دادن آن در دوره باز، پاسخ مناسبی به سند جاافتاده دوره بسته نیست. اگر واقعاً رویداد به دوره قبل تعلق دارد، سیاست اصلاح دوره و الزامات قانونی/حسابرسی تعیین می‌کند آیا باید سند اصلاحی دوره جاری ثبت شود یا دوره قبل با مجوز بازگشایی شود. با بازگشایی، باید گزارش‌های وابسته دوباره محاسبه و نسخه قبلی برای مقایسه حفظ شود.
کنترل مانده پس از تغییر نرم‌افزار
اگر پچ جدیدی فرایند خرید یا محاسبه بدهی را تغییر می‌دهد، صرف پاس‌شدن TypeScript کافی نیست. سناریوی کامل خرید، رسید، پرداخت، بازپرداخت، پیش‌دریافت و برگشت باید با دیتابیس آزمایشی تست شود. توازن بدهکار و بستانکار شرط لازم است، اما حساب اشتباه نیز می‌تواند توازن داشته باشد. به همین دلیل باید نام حساب‌ها، مانده‌های شخص و ارزش موجودی انبار با انتظار حسابداری مقایسه شوند.
چهارچشمی برای پرداخت حساس و ثبت قطعی
در پرداخت‌های بالاتر از سقف مصوب، پیشنهاد می‌شود درخواست‌کننده، تأییدکننده و اجراکننده پرداخت نقش‌های متمایز داشته باشند؛ مجری تطبیق صورت‌حساب نیز مستقل یا قابل بازبینی باشد. تغییر حساب بانکی ذی‌نفع، به‌ویژه پس از تأیید درخواست، باید دوباره بررسی شود.
اگر شبکه قطع شد و پاسخ ثبت نامعلوم ماند، قبل از فشردن دوباره دکمه، شناسه عملیاتی و رکوردهای موجود را جست‌وجو کنید. بازپخش idempotency در برخی جریان‌ها کمک می‌کند ولی نباید به‌صورت فرضی برای همه فرم‌ها اعلام شود.