پرش به محتویات

مدیریت دریافت‌ها (Receivables Management)

۱. مقدمه و فلسفه وجودی

در سیستم ERP تابان، ماژول «مدیریت دریافت‌ها» دروازه ورود جریان نقدینگی (Cash Inflow) به سازمان است. این ماژول تنها نقطه مجاز برای ثبت هرگونه افزایش در دارایی‌های نقد (بانک، صندوق، اسناد دریافتنی) می‌باشد.

تغییر پارادایم نسبت به سیستم‌های سنتی: در سیستم‌های قدیمی، دریافت پول و تسویه حساب مشتری دو فرآیند جداگانه بودند (اول پول را می‌گرفتند، بعداً در حسابداری سند می‌زدند). اما در طراحی جدید تابان، ما از رویکرد «دریافت مبتنی بر تراکنش» (Transaction-Based Receipt) استفاده می‌کنیم. یعنی در همان لحظه‌ای که پول وارد می‌شود، باید مشخص شود که این پول بابت کدام فاکتور، کدام سفارش یا کدام سرفصل درآمدی است.

اهداف کلیدی این ماژول:

  1. شفافیت لحظه‌ای: بدانیم دقیقا چقدر پول نقد و چک دست شرکت است.
  2. تسویه آنی (Real-time Settlement): مانده حساب مشتری در لحظه دریافت به‌روز شود.
  3. ردیابی منشأ پول: جلوگیری از پولشویی و ابهامات مالی با اجباری کردن "مرجع" (Reference).
  4. کنترل داخلی: جلوگیری از دریافت‌های ثبت نشده یا سوءاستفاده از وجوه نقد.

۲. دسته‌بندی انواع دریافت (Receipt Types)

قبل از ورود به فرم عملیاتی، باید بدانیم که "جنس" دریافت‌ها متفاوت است. فیلد ReceiptType رفتار فرم را تغییر می‌دهد:

نوع دریافت نام فنی (Technical Enum) کاربرد و منطق رفتاری
۱. دریافت از مشتری (استاندارد) CustomerPayment (پرکاربردترین) دریافت وجه جهت تسویه فاکتورهای فروش یا مانده حساب مشتری.
ویژگی: انتخاب «مشتری» اجباری است. تب «تخصیص فاکتور» فعال می‌شود.
۲. پیش‌دریافت سفارش DownPayment دریافت وجه قبل از صدور فاکتور و تحویل کالا (مرتبط با Order).
ویژگی: به جای فاکتور، باید به شماره «سفارش فروش» (SO) لینک شود. شامل محاسبه مالیات بر ارزش افزوده (VAT) روی پیش‌دریافت می‌شود.
۳. درآمد متفرقه MiscReceipt دریافت‌هایی که مربوط به عملیات اصلی فروش نیستند (مانند فروش ضایعات، سود سپرده بانکی).
ویژگی: نیاز به تعریف مشتری ندارد. مستقیماً به یک «حساب معین درآمدی» (GL Account) لینک می‌شود.
۴. تسویه تنخواه (باقیمانده) PettyCashReturn زمانی که تنخواه‌گردان پول اضافه آورده و به صندوق/بانک شرکت برمی‌گرداند.

۳. فرم عملیاتی: سند دریافت جدید (Receipt Document)

مسیر دسترسی: خزانه‌داری > عملیات دریافت > سند دریافت جدید

این فرم به صورت Tabular (تب‌بندی شده) طراحی شده تا پیچیدگی را مدیریت کند. کاربر باید مراحل را به ترتیب طی کند.

بخش اول: اطلاعات سربرگ (Header Info)

این بخش "هویت" تراکنش را مشخص می‌کند.

عنوان فیلد نام فنی (Field Name) نوع داده الزامی راهنمای تکمیل و منطق سیستم
شماره سند DocNum String بله تولید خودکار توسط سیستم (مثلاً RCT-1403-00520).
بنگاه اقتصادی LegalEntityID FK بله مشخص می‌کند پول وارد حساب کدام شرکت می‌شود (هلدینگ).
نوع دریافت ReceiptType Enum بله طبق جدول بالا (مشتری، پیش‌دریافت، ...).
پرداخت‌کننده PayerID FK شرطی نام مشتری یا طرف حساب. (اگر نوع دریافت "درآمد متفرقه" باشد، غیرفعال می‌شود).
تاریخ دریافت DocDate Date بله تاریخ واقعی واریز وجه یا دریافت چک (مهم برای مغایرت‌گیری).
ارز سند CurrencyID FK بله ارزی که پول را دریافت کرده‌اید (ریال، دلار).
نرخ ارز ExchangeRate Decimal بله اگر ارز سند با ارز پایه شرکت فرق دارد، نرخ تبدیل در این فیلد وارد می‌شود.
شرح سند Description String بله توضیحات (مثلاً: واریزی آقای رضایی بابت فاکتور ۱۰۱).
وضعیت Status Enum - پیش‌نویس (Draft)، ثبت شده (Posted)، ابطال شده (Void).

بخش دوم: تب روش‌های دریافت (Receipt Lines)

سوال سیستم: این پول چگونه و به کجا وارد شده است؟ کاربر می‌تواند ترکیبی از روش‌ها را استفاده کند (مثلاً: ۱۰ میلیون نقد + ۵۰ میلیون چک).

روش ۱: واریز بانکی / حواله (Wire Transfer)

فیلد نام فنی توضیحات و منطق
حساب مقصد DestBankAccountID پولی که مشتری ریخته، به کدام حساب بانکی ما وارد شده؟ (فیلتر بر اساس ارز).
مبلغ واریزی Amount مبلغ دقیقی که به حساب نشسته است.
شماره پیگیری ReferenceNo شماره ارجاع/پیگیری فیش بانکی (Trace No). (یکتایی این فیلد چک می‌شود).
تاریخ واریز ValueDate تاریخی که در پرینت بانک درج شده است.
هزینه کارمزد BankChargeAmount (قابلیت جدید) اگر مشتری ۱۰۰ واحد بدهکار بوده اما ۹۹ واحد واریز کرده و ۱ واحد کارمزد انتقال کسر شده، عدد ۱ را اینجا می‌زنید. سیستم این ۱ واحد را به عنوان "هزینه بانکی" سند می‌زند و بدهی مشتری را همان ۱۰۰ واحد تسویه می‌کند.

روش ۲: چک (Cheque)

فیلد نام فنی توضیحات و منطق
صندوق مقصد DestBoxID فیزیک چک در کدام گاوصندوق قرار می‌گیرد؟ (پیش‌فرض: صندوق اسناد نزد صندوق).
مبلغ چک Amount مبلغ روی چک.
شناسه صیادی SayadID کد ۱۶ رقمی صیاد (الزامی). سیستم صحت الگوریتم و تکراری نبودن را چک می‌کند.
تاریخ سررسید DueDate تاریخ نقد شدن چک.
شماره سریال SerialNo شماره چاپی چک.
بانک صادرکننده IssuingBank نام بانک مشتری (مثلاً صادرات).
صاحب حساب AccountOwner نام شخصی که چک را صادر کرده (اگر متفاوت از مشتری است).

روش ۳: پول نقد (Cash)

فیلد نام فنی توضیحات و منطق
صندوق مقصد DestCashBoxID پول به کدام صندوق فیزیکی وارد شده؟ (مثلاً صندوق فروشگاه ۱).
مبلغ Amount مقدار پول نقد.

روش ۴: کارت‌خوان (POS)

فیلد نام فنی توضیحات و منطق
دستگاه کارت‌خوان POSTerminalID انتخاب دستگاه پوز. (سیستم می‌داند این پوز به کدام حساب بانکی وصل است).
شماره مرجع RRN کد مرجع تراکنش (RRN) چاپ شده روی رسید.
مبلغ Amount مبلغ تراکنش.

بخش سوم: تب تخصیص و تسویه (Allocation) - (قلب سیستم)

سوال سیستم: این پول بابت کدام بدهی پرداخت شده است؟ این تب به صورت خودکار لیست «اقلام باز» (Open Items) مشتری انتخاب شده را نمایش می‌دهد.

انتخاب نوع سند شماره سند تاریخ مبلغ کل مانده باز مبلغ تخصیص (Allocation) کسورات/تخفیف (Write-off)
☑️ فاکتور فروش INV-101 1403/01/05 100,000,000 100,000,000 100,000,000 0
☑️ فاکتور فروش INV-105 1403/02/10 50,000,000 20,000,000 10,000,000 0
☐ سند برگشتی DR-002 1403/02/12 5,000,000 5,000,000 0 0

سناریوهای تخصیص:

  1. تسویه کامل (Full Match): کاربر تیک فاکتور INV-101 را می‌زند. مبلغ ۱۰۰ میلیون از پول دریافتی به این فاکتور اختصاص می‌یابد. وضعیت فاکتور «تسویه شده» می‌شود.
  2. تسویه بخشی (Partial Match): کاربر فاکتور INV-105 را انتخاب می‌کند اما در ستون "مبلغ تخصیص"، دستی عدد ۱۰ میلیون را وارد می‌کند. مانده فاکتور ۱۰ میلیون باقی می‌ماند.
  3. تخفیف نقدی/رند کردن (Write-off): فرض کنید مشتری به جای ۱۰۰,۰۰۰,۰۰۰ ریال، مبلغ ۹۹,۹۰۰,۰۰۰ ریال واریز کرده است. کاربر ۱۰۰,۰۰۰ تومان اختلاف را در ستون "کسورات/تخفیف" وارد می‌کند و کد "تخفیف نقدی" را انتخاب می‌کند. سیستم فاکتور را کامل تسویه می‌کند و آن ۱۰۰ تومان را به هزینه تخفیفات می‌برد.
  4. علی‌الحساب (On-Account): اگر کاربر هیچ فاکتوری را انتخاب نکند (یا مبلغ دریافتی بیشتر از جمع فاکتورها باشد)، باقیمانده پول به عنوان "پیش‌دریافت/علی‌الحساب" در حساب مشتری ذخیره می‌شود تا بعداً مصرف شود.

۴. کنترل‌های سیستمی و اعتبارسنجی (Validations)

برای جلوگیری از خطا و کلاهبرداری، سیستم این قوانین را قبل از ذخیره چک می‌کند:

  1. قانون تراز سند:

    • جمع مبالغ روش‌های دریافت (تب ۲) باید برابر باشد با مبلغ کل هدر (تب ۱).
    • جمع مبالغ تخصیص داده شده (تب ۳) نباید بیشتر باشد از مبلغ کل هدر.

  2. جلوگیری از ثبت تکراری (Duplicate Check):

    • سیستم ترکیبی از شماره فیش/چک + مبلغ + تاریخ را بررسی می‌کند. اگر قبلاً سندی با این مشخصات ثبت شده باشد، هشدار جدی (Hard Stop) می‌دهد: "این فیش قبلاً در سند شماره RCT-88 ثبت شده است."

  3. کنترل تاریخ (Date Check):

    • تاریخ دریافت نمی‌تواند در "دوره مالی بسته شده" باشد.
    • تاریخ سررسید چک نمی‌تواند مربوط به گذشته (بیشتر از حد مجاز مثلاً ۱ سال قبل) باشد.

  4. اعتبارسنجی صیاد:

    • الگوریتم شناسه صیادی چک می‌شود.
    • وضعیت مشتری در "لیست سیاه" چک می‌شود (اختیاری).

۵. اسناد حسابداری اتوماتیک (GL Accounting)

به محض زدن دکمه "ثبت نهایی"، سیستم موتور حسابداری (Accounting Engine) را صدا می‌زند.

سناریو ۱: دریافت نقد و تسویه فاکتور (کامل)

مبلغ: ۱۰۰ واحد | روش: نقد به صندوق | بابت: فاکتور فروش

کد حساب نام حساب بدهکار (Dr) بستانکار (Cr)
۱۱-۰۲-۰۱ موجودی نقد - صندوق مرکزی ۱۰۰
۱۲-۰۱-۰۱ حساب‌های دریافتنی تجاری (مشتری X) ۱۰۰

سناریو ۲: دریافت حواله با کارمزد و کسورات (پیچیده)

مبلغ فاکتور: ۱۰۰ واحد | واریزی مشتری: ۹۴ واحد | کارمزد بانک: ۱ واحد | تخفیف ما به مشتری: ۵ واحد

کد حساب نام حساب بدهکار (Dr) بستانکار (Cr) شرح
۱۱-۰۱-۰۱ بانک ملت (ورودی واقعی) ۹۴ اصل پول
۶۵-۰۲-۰۵ هزینه کارمزد بانکی ۱ کارمزد بانک
۶۱-۰۵-۰۱ تخفیفات نقدی فروش ۵ تخفیف داده شده
۱۲-۰۱-۰۱ حساب‌های دریافتنی تجاری ۱۰۰ تسویه کامل فاکتور

سناریو ۳: پیش‌دریافت سفارش (بدون فاکتور)

مبلغ: ۵۰ واحد | روش: چک | بابت: سفارش SO-500

کد حساب نام حساب بدهکار (Dr) بستانکار (Cr)
۱۱-۰۴-۰۱ اسناد دریافتنی نزد صندوق ۵۰
۲۱-۰۵-۰۱ پیش‌دریافت از مشتریان (مشتری X) ۵۰

(نکته: در زمان صدور فاکتور نهایی، این پیش‌دریافت به حساب‌های دریافتنی تهاتر می‌شود).

۶. فرآیندهای جانبی و امکانات پیشرفته

الف) دریافت گروهی (Batch Receipt Upload)

برای شرکت‌هایی که روزانه صدها واریزی خرد دارند (مثل شرکت‌های پخش).

  • قابلیت: بارگذاری فایل اکسل پرینت بانک.
  • منطق: سیستم بر اساس "شناسه واریز" (Payment ID) یا تطبیق "مبلغ + نام واریزکننده"، به صورت خودکار ردیف‌ها را شناسایی کرده و برای هر کدام سند دریافت صادر می‌کند.

ب) چاپ رسید (Receipt Print)

سیستم یک فرم چاپی رسمی (A4 یا A5) تولید می‌کند شامل:

  • لوگوی شرکت.
  • شماره سریال و تاریخ.
  • جدول روش‌های پرداخت (شماره چک‌ها و فیش‌ها).
  • جدول فاکتورهای تسویه شده.
  • امضای تحویل‌دهنده و تحویل‌گیرنده.

ج) استرداد دریافت (Reversal)

اگر سندی اشتباه ثبت شد یا چک مشتری عودت داده شد:

  • امکان "حذف" سند ثبت شده وجود ندارد (اصول حسابداری).
  • کاربر باید دکمه "صدور سند معکوس" (Reverse/Void) را بزند.
  • سیستم یک سند جدید با مبالغ منفی (یا جای بدهکار/بستانکار عوض شده) صادر می‌کند و لینک فاکتورها را آزاد می‌کند (فاکتورها دوباره "باز" می‌شوند).

۷. گزارش‌های کلیدی دریافت

مدیران و حسابداران به این گزارش‌ها نیاز حیاتی دارند:

  1. گزارش روزانه وجوه (Daily Cash Report):

    • امروز دقیقاً چقدر پول نقد، چقدر چک و چقدر حواله وارد شرکت شده است؟ (به تفکیک کاربر ثبت‌کننده).

  2. گزارش پیگیری وصول (Collection Report):

    • کدام فاکتورها هنوز تسویه نشده‌اند؟
    • میانگین روزهای تاخیر مشتریان در پرداخت چقدر است (DSO)؟

  3. گزارش چک‌های دریافتی (Receivable Cheques):

    • لیست چک‌های موجود در صندوق که سررسیدشان هفته آینده است (جهت واگذاری به بانک).

  4. گزارش دریافت‌های تخصیص نیافته (Unallocated Receipts):

    • پول‌هایی که از مشتری گرفته‌ایم اما هنوز معلوم نیست بابت کدام فاکتور است (مانده‌های بلاتکلیف).

۸. سوالات متداول (FAQ)

س: اگر مشتری چک شخص دیگری را بدهد (چک خرجی)، نام چه کسی را ثبت کنیم؟ پ: در فیلد "پرداخت‌کننده" (Header) نام مشتری خودتان را بزنید تا حساب او تسویه شود. در فیلد "صاحب حساب" (Tab چک)، نام شخص صادرکننده چک را بنویسید تا در صورت برگشت خوردن چک، بتوانید او را پیدا کنید.

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

س: آیا می‌توانم سند دریافتی را ثبت کنم ولی حسابداری آن را بعداً بزنم؟ پ: خیر. فلسفه ERP یکپارچگی است. ثبت سند دریافت همیشه مساوی است با صدور سند حسابداری. اگر مطمئن نیستید، سند را در حالت "پیش‌نویس" (Draft) ذخیره کنید؛ در این حالت سند حسابداری صادر نمی‌شود و تاثیری در مانده حساب‌ها ندارد.