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

مالی، شارژ و پرداخت

هدف مدل

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

اصل تفکیک

Important

Expense، Charge Definition و Bill سه مفهوم مستقل هستند. ثبت هزینه به‌تنهایی برای واحد یا شخص بدهی ایجاد نمی‌کند. بدهی فقط پس از Publish شدن Charge و ایجاد Bill شکل می‌گیرد.

موجودیت‌های اصلی

موجودیت مسئولیت
Expense ثبت هزینه انجام‌شده یا تعهد مالی ساختمان همراه با دسته‌بندی و مدرک
Charge Definition تعریف عنوان، مبلغ، گروه پرداخت‌کننده و روش تخصیص
Payer Scope تعیین مالکان، مستأجران، ساکنان، واحدها یا گروه سفارشی مشمول
Allocation Rule تعریف نحوه تقسیم مبلغ میان پرداخت‌کنندگان
Charge Template نگهداری تنظیمات قابل استفاده مجدد بدون ایجاد بدهی
Recurrence Schedule تعیین تناوب ساخت Draft و روز انتشار پیشنهادی
Charge Draft نسخه قابل بررسی و ویرایش Charge برای یک دوره مشخص
Charge Approval ثبت تصمیم مدیر برای تأیید یا رد Draft
Unit Ledger دفتر مانده بدهی و بستانکاری هر واحد
Bill بدهی منتشرشده روی Unit Ledger همراه با مسئول پرداخت در زمان مربوط
Payment ثبت پرداخت و اتصال آن به یک یا چند Bill
Settlement Destination حساب یا مقصد تسویه برای دریافت آنلاین

روابط

  • Expense می‌تواند منبع یک Charge Definition باشد، اما وجود آن به‌تنهایی Bill ایجاد نمی‌کند.
  • Charge Definition دارای یک Payer Scope و یک Allocation Rule است.
  • Charge Template می‌تواند برای ساخت Charge Definition یا Draft جدید استفاده شود.
  • Recurrence Schedule در هر دوره فقط Charge Draft ایجاد می‌کند.
  • Charge Draft پیش از Publish قابل ویرایش و نیازمند تأیید مدیر است.
  • Publish شدن Charge Draft باعث ایجاد یک یا چند Bill می‌شود.
  • هر Bill به Unit Ledger مشخص متصل است.
  • Responsible Payer بر اساس رابطه معتبر مالک یا مستأجر در دوره مربوط تعیین می‌شود.
  • Payment به Billهای منتشرشده تخصیص می‌یابد.
  • Expense مربوط به مالکان از طریق Payer Scope نوع owners به Charge تبدیل می‌شود.

نقشه مفهومی

flowchart LR BUILDING["ساختمان"] --> EXPENSE["هزینه"] BUILDING --> CHARGE_DEF["تعریف شارژ"] EXPENSE -. "منبع اختیاری" .-> CHARGE_DEF TEMPLATE["الگوی شارژ"] --> CHARGE_DEF CHARGE_DEF --> PAYER_SCOPE["گروه پرداخت‌کننده"] CHARGE_DEF --> ALLOCATION["قاعده تخصیص"] CHARGE_DEF --> SCHEDULE["زمان‌بندی تکرار"] SCHEDULE --> DRAFT["پیش‌نویس شارژ"] CHARGE_DEF --> DRAFT DRAFT --> APPROVAL["تأیید مدیر"] APPROVAL --> PUBLISHED["شارژ منتشرشده"] PUBLISHED --> BILL["صورتحساب"] BILL --> UNIT_LEDGER["دفتر بدهی واحد"] UNIT_LEDGER --> RESPONSIBLE["مسئول پرداخت جاری"] BILL --> PAYMENT["پرداخت"] PAYMENT --> SETTLEMENT["مقصد تسویه"]

گروه‌های پرداخت‌کننده

Payer Scope می‌تواند یکی از حالت‌های زیر باشد:

  • مالکان
  • مستأجران
  • ساکنان
  • همه واحدها
  • واحدهای انتخاب‌شده
  • بلوک یا طبقه مشخص
  • گروه سفارشی

انتخاب گروه باید بر اساس رابطه معتبر شخص با واحد و Snapshot زمان Publish انجام شود.

قواعد Template و Schedule

  • Template فقط تنظیمات قابل استفاده مجدد را نگه می‌دارد و بدهی ایجاد نمی‌کند.
  • Schedule زمان ساخت Draft دوره بعد را تعیین می‌کند.
  • Recurring بودن به معنی Publish خودکار نیست.
  • هر Draft تکرارشونده باید پیش از Publish توسط مدیر بررسی و تأیید شود.
  • Charge متغیر می‌تواند هر دوره به‌صورت دستی از Template ساخته و اصلاح شود.

قواعد Bill

  • Bill فقط پس از Publish شدن Charge ایجاد می‌شود.
  • Bill مبلغ، واحد، مسئول پرداخت در زمان ایجاد، سررسید، ریز محاسبه و وضعیت پرداخت را نگه می‌دارد.
  • Debt روی Unit Ledger نگهداری می‌شود و به Person منتقل یا از آن جدا نمی‌شود.
  • تغییر فهرست افراد یا روابط بعد از Publish نباید Bill قبلی را بی‌صدا تغییر دهد.
  • اصلاح Bill منتشرشده باید از مسیر اصلاحیه یا ابطال انجام شود.

مسئولیت بدهی در تغییر رابطه

  • مستأجر مسئول پرداخت Chargeهای دوره سکونت خود است.
  • اگر مستأجر هنگام خروج مانده را تسویه نکند، Debt روی Unit Ledger باقی و مسئولیت پرداخت به مالک جاری منتقل می‌شود.
  • در انتقال مالکیت، مانده Unit Ledger حذف نمی‌شود و مالک جاری ثبت‌شده مسئول آن است.
  • سابقه Bill باید Responsible Payer زمان ایجاد و تغییرات بعدی مسئولیت را حفظ کند.
  • مالک یا خریدار باید بتواند پیش از معامله Unit Debt Statement دریافت کند.
  • ثبت دیرهنگام انتقال مالکیت نباید مانده یا تاریخچه Unit Ledger را حذف کند.

Warning

قواعد مسئولیت مالک جاری و انتقال مسئولیت پرداخت باید پیش از اجرا از نظر حقوقی بررسی شوند.

قواعد Expense

  • Expense مبلغ، دسته‌بندی، تاریخ، پرداخت‌کننده اولیه و مدرک را نگه می‌دارد.
  • Expense می‌تواند عمومی، مربوط به یک واحد یا مربوط به گروهی مانند مالکان باشد.
  • ثبت Expense به معنی مطالبه وجه از کاربران نیست.
  • برای مطالبه Expense از مالکان، Charge با Payer Scope نوع owners ساخته و پس از تأیید Publish می‌شود.

وضعیت‌های مفهومی

وضعیت‌های دقیق در Workflow ماژول مالی نهایی می‌شوند. حداقل وضعیت‌های موردنیاز:

  • DRAFT
  • PENDING_REVIEW
  • APPROVED
  • PUBLISHED
  • CANCELED

قواعد پرداخت و تسویه

  • دریافت آنلاین نیازمند Settlement Destination معتبر است.
  • ثبت دستی و پیگیری واریز بانکی بدون فعال‌سازی دریافت آنلاین ممکن است.
  • Payment ناموفق یا در حال بررسی نباید Bill را تسویه‌شده اعلام کند.
  • Receipt به Payment معتبر متصل است.

تصمیم‌های باز

شناسه موضوع وضعیت
OPEN-FIN-01 رفتار Draftی که تا روز انتشار تأیید نشده است Publish نمی‌شود؛ رفتار پس از عبور از تاریخ نیازمند تصمیم تفصیلی Workflow است
OPEN-FIN-02 قواعد اصلاح ظرفیت اشتراک در صورت افزایش واحدهای واقعی خارج از مدل شارژ ساختمان و نیازمند Flow اشتراک

بازگشت