هدف، محدوده و سناریوها

وضعیت سند

این سند در حال تدوین است. هدف و محدوده اولیه ثبت شده‌اند و سناریوها به‌ترتیب تکمیل می‌شوند.

خلاصه تصمیم

ثبت ساختمان بر اساس نوع «کوچک، متوسط یا برج» انجام نمی‌شود. متقاضی تعداد واحدهای مسکونی، تجاری و اداری را وارد می‌کند و قیمت پایه اشتراک بر اساس مجموع واحدها محاسبه می‌شود.

ورود به محصول همیشه با تأیید شماره موبایل و OTP آغاز می‌شود. سیستم پس از احراز شماره، عضویت‌ها و دعوت‌نامه‌های در انتظار را بررسی و مقصد مناسب کاربر را تعیین می‌کند.

تصمیم طراحی فرم تکمیلی

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

مشخصات سند

فیلد	مقدار
ماژول	راه‌اندازی ساختمان و عضویت
وضعیت	Draft
مالک محتوا	تیم محصول تریپیلون
مرحله فعلی	هدف، محدوده و سناریوها
آخرین بازبینی	2026-07-26

۱. هدف ماژول

هدف این ماژول آن است که یک متقاضی بتواند بدون نیاز به راه‌اندازی دستی توسط تیم تریپیلون:

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

این ماژول باید زمان و پیچیدگی شروع کار را کاهش دهد، اما نباید از روی پاسخ‌های فرم، دسترسی نقش‌های دیگر را به متقاضی واگذار کند.

۲. نتیجه موفق ماژول

نتیجه موفق راه‌اندازی

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

نتیجه موفق عضویت

• شخص می‌تواند پیش از ورود به اپ، به‌عنوان مالک، مستأجر، ساکن یا عضو خانواده در رکوردهای ساختمان ثبت شده باشد.
• Charge، Bill و اعلان پیامکی می‌توانند بر اساس رکورد و رابطه معتبر شخص با واحد ایجاد یا ارسال شوند.
• Account فقط پس از تأیید شماره موبایل با OTP به رکورد شخص متصل می‌شود.
• Roleهای دسترسی‌دار و حساس فقط پس از پذیرش دعوت فعال می‌شوند.
• رویداد ثبت شخص، اتصال حساب، دعوت، پذیرش و تخصیص Role قابل پیگیری است.

۳. داخل محدوده

راه‌اندازی تجاری

• ثبت درخواست ایجاد ساختمان
• دریافت و تأیید شماره موبایل با OTP پیش از شروع فرم
• بررسی عضویت فعال و دعوت‌نامه در انتظار
• دریافت تعداد واحدهای مسکونی، تجاری و اداری
• محاسبه قیمت پایه بر اساس تعداد واحدها
• پیشنهاد دوره پرداخت سه‌ماهه یا دوازده‌ماهه
• دریافت مبلغ ثابت شارژ اولیه پنل پیامکی
• نمایش مبلغ اشتراک پیش از مالیات و عوارض
• دریافت Self-Declaration اختیار متقاضی پیش از پرداخت
• پرداخت آنلاین اشتراک اولیه

راه‌اندازی سیستمی

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

عضویت

• دعوت فرد با شماره تماس یا روش شناسایی مورد تأیید
• ایجاد رکورد شخص و رابطه او با واحد بدون وابستگی به ورود به اپ
• تعیین یک یا چند Role و Scope در یک دعوت
• مشاهده، پذیرش یا رد دعوت
• اتصال حساب موجود یا ایجاد حساب برای فرد دعوت‌شده
• فعال‌سازی Roleهای نیازمند پذیرش
• ارسال مجدد یا لغو دعوت استفاده‌نشده
• غیرفعال‌سازی دسترسی فرد به ساختمان یا محدوده مرتبط، بدون غیرفعال‌کردن حساب سراسری او

۴. خارج از محدوده

موارد زیر در این ماژول انجام نمی‌شوند:

• تعریف تفصیلی بلوک‌ها، طبقات، واحدها، پارکینگ‌ها و انباری‌ها
• ثبت مالکیت، اجاره، سکونت و قرارداد مستأجر
• پرونده ورود یا خروج ساکن
• طراحی یا ویرایش تفصیلی Permissionها و Role Templateها
• عملیات مالی ساختمان مانند شارژ، هزینه و تسویه
• تمدید، ارتقا، تنزل، تعلیق یا لغو اشتراک پس از راه‌اندازی اولیه
• مدیریت شیفت و وظایف کارکنان
• احراز حقوقی مالکیت یا اختیار متقاضی پیش از ایجاد ساختمان؛ نسخه فعلی بر Self-Declaration متقاضی متکی است
• نمایش گزارش نهایی پرداخت‌ها، هشدارها و فعالیت‌ها؛ این قابلیت متعلق به ماژول گزارش‌ها است
• درخواست دمو، محتوای آموزشی و جلسه معرفی پیش از ثبت‌نام؛ این موارد متعلق به وب‌سایت عمومی و جریان بازاریابی تریپیلون هستند

فرم راه‌اندازی فقط اطلاعات تجمیعی مانند تعداد بلوک، طبقه و واحد را دریافت می‌کند. ایجاد موجودیت‌های تفصیلی به ماژول «ساختمان، بلوک، طبقه و واحد» تعلق دارد.

۵. قواعد مرزبندی

• ساختمان در زمان ثبت‌نام به «کوچک، متوسط یا برج» طبقه‌بندی نمی‌شود.
• قیمت پایه اشتراک فعلاً بر اساس مجموع واحدهای مسکونی، تجاری و اداری محاسبه می‌شود.
• تعرفه هر واحد مسکونی، تجاری و اداری در نسخه فعلی برابر است.
• حداقل تعداد واحد برای خرید آنلاین ۲ واحد است و سقف تعداد واحد وجود ندارد.
• ماژول‌های افزوده می‌توانند در آینده قیمت جداگانه داشته باشند؛ برای نمونه سیستم حسابداری هوشمند.
• دوره‌های قابل خرید در راه‌اندازی اولیه سه‌ماهه و دوازده‌ماهه هستند.
• مبلغ دوره سه‌ماهه بر اساس هزینه سه ماه خدمت محاسبه می‌شود.
• پلن سالانه شامل ۱۲ ماه خدمت با هزینه ۱۱ ماه است.
• مبلغ ثابت شارژ اولیه پنل پیامکی به‌صورت ردیف مستقل به هزینه راه‌اندازی اضافه می‌شود.
• مبلغ شارژ اولیه پنل پیامکی باید قابل تنظیم باشد و مقدار نهایی آن هنوز تعیین نشده است.
• مبلغ نمایش‌داده‌شده در مرحله انتخاب دوره، جمع اشتراک پیش از مالیات و عوارض است.
• مالیات و عوارض در جمع این مرحله محاسبه نمی‌شوند و اضافه‌شدن آن‌ها با یادداشت صریح به متقاضی اعلام می‌شود.
• متقاضی پیش از شروع فرم، شماره موبایل خود را با OTP تأیید می‌کند.
• اگر شماره موبایل عضویت فعال داشته باشد، فرایند ثبت اولیه نمایش داده نمی‌شود و کاربر وارد صفحه اصلی می‌شود.
• اگر دعوت‌نامه در انتظار وجود داشته باشد، دعوت‌نامه پیش از گزینه ثبت ساختمان نمایش داده می‌شود.
• اگر شماره موبایل نه عضویت فعال و نه دعوت‌نامه در انتظار داشته باشد، کاربر بین «ثبت ساختمان جدید» و «منتظر دعوت هستم» انتخاب می‌کند.
• کاربر عضو می‌تواند از صفحه اصلی درخواست ایجاد ساختمان دیگری را آغاز کند.
• اعلام وجود نقش‌هایی مانند نگهبان، لابی‌من یا حسابدار فقط Role Template و تنظیمات مرتبط را فعال می‌کند.
• تا زمانی که فردی به یک نقش منتسب نشده باشد، Permissionهای آن نقش به هیچ کاربری داده نمی‌شود.
• پرداخت موفق، محرک ایجاد ساختمان است؛ ثبت فرم به‌تنهایی ساختمان فعال ایجاد نمی‌کند.
• ایجاد ساختمان به تأیید ادمین پلتفرم نیاز ندارد.
• متقاضی باید پیش از پرداخت، اختیار و مسئولیت خود برای ثبت ساختمان را از طریق Self-Declaration تأیید کند.
• شباهت نام یا مشخصات کلی ساختمان، مانع ایجاد ساختمان جدید نیست.
• یک پرداخت موفق باید حداکثر یک ساختمان ایجاد کند؛ تکرار Callback پرداخت نباید ساختمان تکراری بسازد.
• حساب کاربری، عضویت در ساختمان و نقش‌های فرد سه مفهوم مستقل هستند.
• تغییر مدیر راه‌اندازی در اختلاف‌های رسمی با درخواست، صورت‌جلسه یا تعهدنامه امضاشده هیئت‌مدیره و اقدام ادمین پلتفرم انجام می‌شود.
• درخواست تغییر مدیر باید حمایت هیئت‌مدیره یا حمایت بیش از ۵۰٪ مالکان ثبت‌شده ساختمان را داشته باشد.
• در شمارش حمایت، هر مالک یکتا یک مالک محسوب می‌شود؛ تعداد واحدها، تعداد ساکنان و سهم مالکیت مبنای شمارش نیست.
• اگر درخواست هیئت‌مدیره با درخواست مورد حمایت بیش از ۵۰٪ مالکان تعارض داشته باشد، درخواست مالکان اولویت دارد.

۶. Business Rules

شناسه	شرط	اقدام سیستم	نتیجه
BR-SET-01	متقاضی تعداد واحدها را وارد می‌کند	مجموع واحدهای مسکونی، تجاری و اداری محاسبه می‌شود	مبنای قیمت پایه مشخص می‌شود
BR-SET-01A	نوع واحد مسکونی، تجاری یا اداری است	تعرفه یکسان برای هر واحد اعمال می‌شود	نوع واحد در قیمت پایه ضریب جداگانه ندارد
BR-SET-01B	مجموع واحدها کمتر از ۲ است	خرید آنلاین مجاز نیست	متقاضی نمی‌تواند فرایند پرداخت را ادامه دهد
BR-SET-02A	متقاضی دوره سه‌ماهه را انتخاب می‌کند	هزینه سه ماه بر اساس تعداد واحدها محاسبه می‌شود	سه ماه خدمت در پیشنهاد قیمت ثبت می‌شود
BR-SET-02B	متقاضی دوره دوازده‌ماهه را انتخاب می‌کند	هزینه ۱۱ ماه دریافت می‌شود	۱۲ ماه خدمت فعال می‌شود
BR-SET-02C	قیمت دوره به متقاضی نمایش داده می‌شود	مالیات و عوارض در جمع اشتراک محاسبه نمی‌شوند و یادداشت اضافه‌شدن آن‌ها نمایش داده می‌شود	مبلغ نمایش‌داده‌شده به‌عنوان «جمع پیش از مالیات و عوارض» شناخته می‌شود
BR-SET-02D	قیمت راه‌اندازی محاسبه می‌شود	مبلغ ثابت شارژ اولیه پنل پیامکی به‌صورت ردیف مستقل اضافه می‌شود	جمع پیش از مالیات شامل اشتراک و شارژ اولیه پنل پیامکی است
BR-SET-03	پرداخت معتبر با موفقیت ثبت می‌شود	ساختمان بدون تأیید دستی ادمین ایجاد می‌شود	عضویت و نقش مدیر راه‌اندازی فعال می‌شوند
BR-SET-04	Callback موفق پرداخت تکرار می‌شود	سیستم نتیجه قبلی را برمی‌گرداند	ساختمان دوم ایجاد نمی‌شود
BR-SET-05	ساختمان فعال می‌شود	چک‌لیست تکمیل اطلاعات نمایش داده می‌شود	متقاضی اطلاعات تکمیلی را مرحله‌ای وارد می‌کند
BR-SET-06	وجود نقش یا نیرویی در فرم تکمیلی اعلام می‌شود	Role Template مرتبط فعال می‌شود	Permission به فردی داده نمی‌شود تا نقش به او Assign شود
BR-SET-06A	مدیر وارد Setup Dashboard می‌شود	پنج بخش مستقل با وضعیت و پیشرفت نمایش داده می‌شوند	تکمیل اطلاعات به‌صورت مرحله‌ای و غیرخطی انجام می‌شود
BR-SET-06B	تعداد واحدهای واقعی با ظرفیت خریداری‌شده متفاوت است	ثبت واحدها مسدود نمی‌شود و در حالت افزایش، هشدار و اختلاف ظرفیت ثبت می‌شود	اصلاح ظرفیت در Flow جداگانه پیگیری می‌شود
BR-SET-06C	فایل Excel دارای خطای مسدودکننده است	کل Import متوقف می‌شود	مدیر فایل را اصلاح و دوباره بارگذاری می‌کند
BR-SET-06D	فایل Excel معتبر است و مدیر Import را تأیید می‌کند	رکورد اشخاص، روابط واحد و Membership عملیاتی ثبت می‌شوند	Invitation، Account Link یا Permission فعال ایجاد نمی‌شود
BR-SET-06E	شماره موبایل شخص در Excel خالی است	Warning نمایش داده می‌شود	شخص ثبت می‌شود اما تا تکمیل شماره قابل دعوت نیست
BR-SET-06F	مدل مدیریت انتخاب می‌شود	Roleهای حاکمیتی مرتبط پیشنهاد می‌شوند	ساختار اولیه مدیریت شکل می‌گیرد
BR-SET-06G	مدیر راه‌اندازی خودش را برای یک Role مدیریتی انتخاب می‌کند	پس از تأیید صریح، Role به Membership فعال او تخصیص می‌یابد	Invitation لازم نیست و اقدام Audit می‌شود
BR-SET-06H	شخص مسئول Membership فعال ندارد	Role پیشنهادی در انتظار باقی می‌ماند	Permission تا پذیرش Invitation اعمال نمی‌شود
BR-SET-06I	Role مدیریتی انتخاب می‌شود	بسته دسترسی پیش‌فرض به‌صورت خلاصه پیشنهاد می‌شود	فهرست کامل Permissionها فقط در مسیر پیشرفته نمایش داده می‌شود
BR-SET-06J	نوع کار برای ساختمان انتخاب می‌شود	Role Template پیش‌فرض همان نوع کار فعال می‌شود	تنظیمات پایه بدون درگیرکردن مدیر با Permissionهای جزئی آماده می‌شوند
BR-SET-06K	مدیر Role Template را شخصی‌سازی می‌کند	تغییر برای همه افراد دارای همان Role در ساختمان اعمال می‌شود	Per-person Override در راه‌اندازی اولیه ایجاد نمی‌شود
BR-SET-06L	Permission حساس تغییر می‌کند	هشدار و تأیید صریح دریافت می‌شود	تغییر حساس بدون تأیید اعمال نمی‌شود
BR-SET-06M	برای Role هنوز شخصی تعیین نشده است	موقعیت با وضعیت «بدون متصدی» ذخیره می‌شود	تکمیل بخش بدون Invitation ممکن است
BR-SET-06N	ساختمان کارکنان ندارد	نبود کارکنان صریحاً ثبت می‌شود	بخش حل‌شده محسوب و Role Template عملیاتی فعال نمی‌شود
BR-SET-06O	مدیر تنظیمات مالی را باز می‌کند	«پرداخت آنلاین» به‌عنوان روش دریافت پیش‌فرض نمایش داده می‌شود، اما تا ثبت مقصد تسویه فعال نمی‌شود	مدیر می‌تواند روش پیش‌فرض را تأیید یا روش واریز بانکی را نیز فعال کند
BR-SET-06P	مدیر «بعداً انجام می‌دهم» را انتخاب می‌کند	تصمیم در Setup Dashboard ثبت می‌شود	راه‌اندازی کلی ساختمان مسدود نمی‌شود
BR-SET-06Q	دریافت آنلاین انتخاب می‌شود	مقصد تسویه معتبر درخواست می‌شود	بدون مقصد معتبر، دریافت آنلاین فعال نمی‌شود
BR-SET-06Q1	واریز بانکی فعال می‌شود	حداقل یک مقصد کارت یا حساب معتبر و دستورالعمل پرداخت ثبت می‌شود	ساکن می‌تواند کارت‌به‌کارت یا حساب‌به‌حساب را انتخاب کند
BR-SET-06Q2	ساکن واریز بانکی انجام می‌دهد	مبلغ، تاریخ، شماره پیگیری و تصویر قبض را ثبت می‌کند	پرداخت در وضعیت «در انتظار تأیید مدیر» باقی می‌ماند
BR-SET-06Q3	مدیر قبض را تأیید می‌کند	Payment دستی ثبت و به Bill یا بدهی انتخاب‌شده تخصیص داده می‌شود	مانده Unit Ledger فقط پس از تأیید کاهش می‌یابد
BR-SET-06Q4	مدیر قبض را رد می‌کند	دلیل رد ثبت و به پرداخت‌کننده نمایش داده می‌شود	مانده بدهی تغییر نمی‌کند و ارسال مجدد قبض ممکن است
BR-SET-06Q5	پرداخت آنلاین و واریز بانکی هر دو فعال‌اند	هر دو گزینه در صفحه پرداخت واحد نمایش داده می‌شوند	پرداخت‌کننده روش هر پرداخت را انتخاب می‌کند
BR-SET-06R	Charge تکرارشونده تعریف می‌شود	Schedule فقط Draft دوره بعد را ایجاد می‌کند	Publish فقط پس از بررسی و تأیید مدیر انجام می‌شود
BR-SET-06S	امکان جدید تعریف می‌شود	امکان ابتدا در وضعیت Draft ایجاد می‌شود	بدون تنظیمات معتبر فعال نمی‌شود
BR-SET-06T	حداقل قواعد یک امکان تکمیل و تأیید می‌شوند	امکان فعال می‌شود	استفاده یا رزرو بر اساس قواعد همان امکان انجام می‌شود
BR-SET-06U	ساختمان امکانات ندارد	نبود امکانات ثبت می‌شود	بخش تکمیل و ماژول رزرو غیرفعال می‌ماند
BR-SET-06V	مدیر یا تأییدکننده برای Facility انتخاب می‌شود	Role و Permission معتبر بررسی می‌شوند	تعریف Facility به‌تنهایی دسترسی ایجاد نمی‌کند
BR-ID-01	کاربر شماره موبایل را وارد می‌کند	OTP ارسال و شماره تأیید می‌شود	عضویت‌ها و دعوت‌نامه‌های مرتبط قابل بررسی می‌شوند
BR-ID-02	شماره موبایل عضویت فعال دارد	ثبت اولیه نمایش داده نمی‌شود	کاربر وارد صفحه اصلی و Current Context می‌شود
BR-ID-03	شماره موبایل دعوت‌نامه در انتظار دارد	دعوت‌نامه به کاربر نمایش داده می‌شود	کاربر می‌تواند دعوت را بررسی کند
BR-ID-04	شماره موبایل عضویت یا دعوت‌نامه ندارد	دو مسیر شروع نمایش داده می‌شود	کاربر ثبت ساختمان یا انتظار برای دعوت را انتخاب می‌کند
BR-AUTH-01	متقاضی قصد پرداخت دارد	Self-Declaration اختیار و مسئولیت نمایش داده می‌شود	ادامه پرداخت به پذیرش آن وابسته است
BR-PAY-01	متقاضی وارد مرحله پرداخت می‌شود	مالیات و عوارض قابل اعمال به جمع اشتراک اضافه می‌شوند	مبلغ نهایی قابل پرداخت مشخص می‌شود
BR-PAY-02	پرداخت در درگاه موفق اعلام می‌شود	سامانه نتیجه را از سمت سرویس پرداخت اعتبارسنجی می‌کند	فقط پرداخت معتبر، ایجاد ساختمان را آغاز می‌کند
BR-PAY-03	پرداخت لغو یا ناموفق می‌شود	درخواست راه‌اندازی و دوره انتخاب‌شده حفظ می‌شوند	متقاضی می‌تواند دوباره پرداخت کند
BR-PAY-04	نتیجه پرداخت قطعی نیست	وضعیت «در حال بررسی پرداخت» نمایش داده می‌شود	تا تعیین نتیجه قطعی، ساختمان ایجاد نمی‌شود
BR-PAY-05	نتیجه موفق یک پرداخت بیش از یک‌بار دریافت می‌شود	نتیجه ثبت‌شده قبلی بازیابی می‌شود	پرداخت و ساختمان تکراری ایجاد نمی‌شوند
BR-SUB-01	پرداخت موفق است و راه‌اندازی بدون خطای داخلی انجام می‌شود	دوره اشتراک از زمان پرداخت موفق محاسبه می‌شود	تاریخ شروع اشتراک برابر زمان پرداخت است
BR-SUB-02	فعال‌سازی ساختمان به‌دلیل خطای داخلی تریپیلون به تأخیر می‌افتد	تاریخ شروع اشتراک به زمان فعال‌شدن واقعی ساختمان منتقل می‌شود	مدت اختلال داخلی از اشتراک مشتری کسر نمی‌شود
BR-SUB-03	کاربر تکمیل چک‌لیست را به تأخیر می‌اندازد	تاریخ شروع اشتراک تغییر نمی‌کند	تأخیر کاربر باعث تمدید دوره نمی‌شود
BR-ADMIN-01	تغییر مدیر راه‌اندازی درخواست می‌شود	درخواست فقط از طریق Support Ticket و بررسی دستی ادمین پلتفرم انجام می‌شود	تغییر Self-service مجاز نیست
BR-ADMIN-02	درخواست تغییر مدیر با درخواست دیگری تعارض دارد	تعداد مالکان یکتای حامی هر درخواست بررسی می‌شود	درخواست دارای حمایت بیش از ۵۰٪ مالکان بر درخواست هیئت‌مدیره اولویت دارد
BR-ADMIN-03	Ticket تغییر مدیر تأیید می‌شود	Role جدید تا پذیرش شخص پیشنهادی Pending می‌ماند	دسترسی حساس بدون پذیرش فعال نمی‌شود
BR-ADMIN-04	مدیر جدید Invitation را می‌پذیرد	Role قبلی سلب و Role جدید به‌صورت اتمیک فعال می‌شود	ساختمان بدون مدیر راه‌اندازی باقی نمی‌ماند
BR-ADMIN-05	خطر امنیتی یا سوءاستفاده فوری گزارش می‌شود	ادمین پلتفرم می‌تواند Role قبلی را موقتاً Suspend کند	تصمیم و دلیل در Audit ثبت می‌شوند
BR-MEM-01	دسترسی فرد به ساختمان پایان می‌یابد	Membership یا Scope مرتبط غیرفعال می‌شود	حساب سراسری فرد فعال می‌ماند
BR-MEM-02	مالک، مستأجر، ساکن یا عضو خانواده توسط مدیر ثبت می‌شود	Building Membership و Unit Relationship عملیاتی ایجاد می‌شوند	ثبت فرد به پذیرش Invitation وابسته نیست
BR-MEM-03	فرد هنوز وارد اپ نشده است	Charge، Bill و SMS بر اساس رکورد و شماره تماس او ادامه می‌یابند	نبود Account Link مانع عملیات ساختمان نیست
BR-MEM-04	فرد با OTP وارد تریپیلون می‌شود	Account به Person Record و Membership موجود متصل می‌شود	حساب تکراری ایجاد نمی‌شود
BR-MEM-05	Invitation شامل Role حساس است	Role تا پذیرش در وضعیت Pending Acceptance باقی می‌ماند	Permission پیش از پذیرش اعمال نمی‌شود
BR-MEM-06	Invitation چند Role دارد	یک Invitation Envelope همه Roleها را نگه می‌دارد	یک پیام دعوت برای همان شخص و ساختمان کافی است
BR-MEM-07	Invitation ایجاد شده است	Business Expiry ندارد و تا پذیرش، رد یا لغو مدیر معتبر می‌ماند	دسترسی به Invitation هر بار با OTP کنترل می‌شود
BR-MEM-08	ارسال گروهی بخشی موفق و بخشی ناموفق است	ارسال‌های موفق حفظ می‌شوند	فقط موارد ناموفق Retry می‌شوند
BR-MEM-09	مدیر Invitation را Resend می‌کند	Delivery Attempt جدید روی همان Envelope ثبت می‌شود	Invitation یا Role Assignment تکراری ایجاد نمی‌شود
BR-MEM-10	از آخرین ارسال کمتر از ۲۴ ساعت گذشته است	Resend مجاز نیست	مدیر پس از پایان محدودیت دوباره تلاش می‌کند
BR-MEM-11	Invitation Pending لغو می‌شود	پذیرش Roleهای Pending از همان Envelope متوقف می‌شود	Membership و روابط عملیاتی حفظ می‌شوند
BR-MEM-12	لغو مربوط به Role مدیریتی، مالی یا کارکنان است	ثبت دلیل لغو الزامی می‌شود	اقدام همراه با دلیل Audit می‌شود
BR-MEM-13	رابطه مستأجر پایان می‌یابد	مستأجر و اعضای وابسته Household با Effective Date آرشیو می‌شوند	تاریخچه حفظ و دسترسی‌های Scope واحد غیرفعال می‌شوند
BR-MEM-14	بدهی واحد هنگام خروج مستأجر تسویه نشده است	مسئولیت پرداخت مانده به مالک جاری منتقل می‌شود	بدهی روی Unit Ledger باقی می‌ماند
BR-MEM-15	مالکیت واحد تغییر می‌کند	رابطه مالک قبلی پایان و مالک جدید ایجاد می‌شود	مانده بدهی واحد بر عهده مالک جاری قرار می‌گیرد
BR-MEM-16	تغییر مالک پیش از معامله ثبت می‌شود	صورت بدهی یا تسویه واحد ارائه می‌شود	خریدار و فروشنده از مانده واحد آگاه می‌شوند
BR-MEM-17	نیروی انسانی جایگزین می‌شود	Task و Shiftهای باز بررسی می‌شوند	تا تعیین تکلیف موارد باز، جایگزینی نهایی نمی‌شود

۷. فهرست سناریوها

راه‌اندازی ساختمان

• SET-01 شروع درخواست و شناسایی متقاضی
• SET-02 ثبت تعداد واحدهای مسکونی، تجاری و اداری
• SET-03 مشاهده قیمت و انتخاب دوره اشتراک
• SET-04 پرداخت آنلاین اشتراک
• SET-05 ایجاد ساختمان و تخصیص نقش مدیر راه‌اندازی
• SET-06 تکمیل هدایت‌شده اطلاعات ساختمان پس از ورود

عضویت

• MEM-01 ایجاد و ارسال دعوت‌نامه
• MEM-02 پذیرش یا رد دعوت‌نامه
• MEM-03 ارسال مجدد یا لغو دعوت‌نامه
• MEM-04 غیرفعال‌سازی دسترسی عضو
• MEM-05 تغییر مدیر راه‌اندازی با درخواست رسمی و صورت‌جلسه

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

• بازیگران
• نقطه شروع
• پیش‌شرط‌ها
• مسیر اصلی
• مسیرهای جایگزین
• خطاها و استثناها
• نتیجه نهایی

۸. سناریوی SET-01 — شروع درخواست و شناسایی متقاضی

بازیگران

• بازدیدکننده یا متقاضی
• کاربر عضو ساختمان
• سامانه تریپیلون

نقطه شروع

کاربر در وب‌سایت یا اپ تریپیلون، ورود یا شروع ثبت ساختمان را انتخاب می‌کند.

پیش‌شرط‌ها

• کاربر به یک شماره موبایل معتبر دسترسی دارد.
• سرویس ارسال و تأیید OTP در دسترس است.
• شماره موبایل می‌تواند به صفر، یک یا چند Building Membership مرتبط باشد.

مسیر اصلی — متقاضی بدون عضویت یا دعوت

1. کاربر شماره موبایل خود را وارد می‌کند.
2. سامانه OTP را ارسال می‌کند.
3. کاربر OTP معتبر را وارد می‌کند.
4. سامانه عضویت‌های فعال و دعوت‌نامه‌های در انتظار را بررسی می‌کند.
5. سامانه تشخیص می‌دهد کاربر عضویت فعال یا دعوت‌نامه در انتظار ندارد.
6. صفحه انتخاب مسیر نمایش داده می‌شود:
7. ثبت ساختمان جدید
8. منتظر دعوت هستم
9. کاربر «ثبت ساختمان جدید» را انتخاب می‌کند.
10. سامانه کاربر را به سناریوی SET-02 هدایت می‌کند.

مسیرهای جایگزین

ALT-SET-01A — کاربر عضویت فعال دارد

سامانه فرایند ثبت اولیه را نمایش نمی‌دهد و کاربر را وارد صفحه اصلی آخرین Building Context معتبر می‌کند. کاربر می‌تواند از Building Switcher بین ساختمان‌ها جابه‌جا شود یا از صفحه اصلی «ثبت ساختمان جدید» را انتخاب کند.

ALT-SET-01B — کاربر دعوت‌نامه در انتظار دارد

سامانه دعوت‌نامه را با نام ساختمان، نقش پیشنهادی و اقدام‌های «پذیرش» و «رد» نمایش می‌دهد. ثبت ساختمان جدید به‌عنوان اقدام ثانویه در دسترس باقی می‌ماند.

ALT-SET-01C — کاربر منتظر دعوت است

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

خطاها و استثناها

شناسه	خطا	رفتار سیستم	بازیابی
ERR-SET-01	شماره موبایل نامعتبر	ارسال OTP انجام نمی‌شود	اصلاح شماره
ERR-SET-02	OTP اشتباه یا منقضی	ورود رد و تعداد تلاش ثبت می‌شود	ورود مجدد یا ارسال دوباره
ERR-SET-03	درخواست بیش از حد OTP	ارسال موقتاً محدود می‌شود	انتظار تا پایان محدودیت
ERR-SET-04	بررسی عضویت ناموفق	مقصد کاربر حدس زده نمی‌شود	تلاش مجدد بدون ساخت حساب یا ساختمان تکراری

نتیجه نهایی

یکی از نتایج زیر حاصل می‌شود:

• کاربر عضو وارد صفحه اصلی می‌شود؛
• کاربر دعوت‌نامه در انتظار را مشاهده می‌کند؛
• متقاضی جدید وارد سناریوی SET-02 می‌شود؛
• کاربر در حالت «منتظر دعوت» باقی می‌ماند.

۹. سناریوی SET-02 — ثبت اطلاعات پایه و تعداد واحدها

بازیگران

• متقاضی راه‌اندازی ساختمان
• سامانه تریپیلون

نقطه شروع

متقاضی در پایان سناریوی SET-01 گزینه «ثبت ساختمان جدید» را انتخاب می‌کند. کاربر دارای عضویت فعال نیز می‌تواند همین سناریو را از صفحه اصلی آغاز کند.

پیش‌شرط‌ها

• شماره موبایل متقاضی با OTP تأیید شده است.
• متقاضی وارد مسیر ثبت ساختمان جدید شده است.
• هنوز ساختمان فعالی برای این درخواست ایجاد نشده است.

اطلاعات دریافتی

در ثبت اولیه فقط اطلاعات ضروری زیر دریافت می‌شوند:

• نام ساختمان
• تعداد واحدهای مسکونی
• تعداد واحدهای تجاری
• تعداد واحدهای اداری

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

مسیر اصلی

1. سامانه فرم اطلاعات پایه ساختمان را نمایش می‌دهد.
2. متقاضی نام ساختمان را وارد می‌کند.
3. متقاضی تعداد واحدهای مسکونی، تجاری و اداری را وارد می‌کند.
4. سامانه معتبر بودن نام و مقادیر واردشده را بررسی می‌کند.
5. سامانه مجموع سه نوع واحد را محاسبه می‌کند.
6. سامانه تشخیص می‌دهد مجموع واحدها حداقل ۲ است.
7. سامانه اطلاعات را در درخواست راه‌اندازی ذخیره می‌کند.
8. متقاضی برای مشاهده قیمت و انتخاب دوره اشتراک به سناریوی SET-03 هدایت می‌شود.

قواعد و محدودیت‌ها

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

مسیرهای جایگزین

ALT-SET-02A — شروع توسط کاربر دارای عضویت فعال

کاربر از صفحه اصلی «ثبت ساختمان جدید» را انتخاب می‌کند. سامانه Current Context فعلی او را تغییر نمی‌دهد و کاربر را وارد فرم همین سناریو می‌کند.

ALT-SET-02B — بازگشت و اصلاح اطلاعات

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

خطاها و استثناها

شناسه	خطا	رفتار سیستم	بازیابی
ERR-SET-05	نام ساختمان وارد نشده است	ادامه مسیر انجام نمی‌شود و خطای همان فیلد نمایش داده می‌شود	واردکردن نام ساختمان
ERR-SET-06	مقدار یکی از انواع واحد نامعتبر یا منفی است	ادامه مسیر انجام نمی‌شود و فیلد نامعتبر مشخص می‌شود	اصلاح مقدار
ERR-SET-07	مجموع واحدها کمتر از ۲ است	پیام «برای راه‌اندازی تریپیلون حداقل ۲ واحد لازم است» در همان صفحه نمایش داده می‌شود	افزایش تعداد واحدها تا حداقل ۲
ERR-SET-08	ذخیره اطلاعات درخواست ناموفق است	کاربر وارد مرحله قیمت‌گذاری نمی‌شود	تلاش مجدد بدون ایجاد درخواست یا ساختمان تکراری

نتیجه نهایی

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

۱۰. سناریوی SET-03 — مشاهده قیمت و انتخاب دوره اشتراک

بازیگران

• متقاضی راه‌اندازی ساختمان
• سامانه تریپیلون

نقطه شروع

متقاضی سناریوی SET-02 را با اطلاعات معتبر تکمیل کرده و وارد مرحله مشاهده قیمت می‌شود.

پیش‌شرط‌ها

• نام ساختمان در درخواست راه‌اندازی ثبت شده است.
• مجموع واحدهای مسکونی، تجاری و اداری حداقل ۲ است.
• تعرفه فعال هر واحد در دسترس سامانه است.
• هنوز پرداختی برای این درخواست ثبت نشده است.

مسیر اصلی

1. سامانه مجموع واحدهای ثبت‌شده را از درخواست راه‌اندازی دریافت می‌کند.
2. سامانه قیمت پایه یک ماه خدمت را بر اساس تعداد واحدها و تعرفه هر واحد محاسبه می‌کند.
3. سامانه قیمت دوره سه‌ماهه را بر اساس هزینه سه ماه خدمت محاسبه می‌کند.
4. سامانه قیمت دوره دوازده‌ماهه را برای ۱۲ ماه خدمت با کسر هزینه یک ماه محاسبه می‌کند.
5. سامانه مبلغ ثابت شارژ اولیه پنل پیامکی را به‌صورت ردیف مستقل به محاسبات اضافه می‌کند.
6. سامانه برای هر دوره، تعداد واحدها، تعرفه هر واحد، مبلغ پیش از تخفیف، تخفیف، شارژ اولیه پنل پیامکی و جمع کل را نمایش می‌دهد.
7. سامانه زیر محاسبات اعلام می‌کند که مالیات و عوارض به مبلغ نمایش‌داده‌شده اضافه خواهد شد.
8. متقاضی دوره سه‌ماهه یا دوازده‌ماهه را انتخاب می‌کند.
9. سامانه دوره انتخاب‌شده و محاسبات مرتبط را در درخواست راه‌اندازی ثبت می‌کند.
10. متقاضی برای پرداخت آنلاین به سناریوی SET-04 هدایت می‌شود.

قواعد محاسبه و نمایش

• فقط دوره‌های سه‌ماهه و دوازده‌ماهه قابل انتخاب هستند.
• مبلغ دوره سه‌ماهه برابر هزینه سه ماه خدمت برای مجموع واحدها است.
• دوره دوازده‌ماهه شامل ۱۲ ماه خدمت با هزینه ۱۱ ماه است.
• تخفیف دوره دوازده‌ماهه باید جدا از مبلغ پیش از تخفیف نمایش داده شود.
• مبلغ هر واحد، تعداد کل واحدها، مبلغ اشتراک و شارژ اولیه پنل پیامکی باید قابل مشاهده باشند.
• شارژ اولیه پنل پیامکی مبلغی ثابت، مستقل از تعداد واحدها و دوره اشتراک است.
• مالیات و عوارض در جمع این مرحله محاسبه نمی‌شوند.
• مبلغ این مرحله «جمع کل پیش از مالیات و عوارض» است و نباید «مبلغ نهایی قابل پرداخت» نامیده شود.
• Add-onها و ماژول‌های دارای قیمت مستقل در محاسبه راه‌اندازی اولیه وارد نمی‌شوند.

مسیرهای جایگزین

ALT-SET-03A — تغییر دوره اشتراک

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

ALT-SET-03B — اصلاح تعداد واحدها

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

خطاها و استثناها

شناسه	خطا	رفتار سیستم	بازیابی
ERR-SET-09	تعرفه فعال در دسترس نیست	قیمت حدس زده نمی‌شود و ادامه به پرداخت ممکن نیست	تلاش مجدد پس از دریافت تعرفه معتبر
ERR-SET-10	محاسبه قیمت ناموفق است	مبلغ ناقص یا قدیمی نمایش داده نمی‌شود	محاسبه مجدد
ERR-SET-11	اطلاعات واحدها پس از محاسبه تغییر کرده است	محاسبات قبلی نامعتبر می‌شوند	محاسبه مجدد بر اساس آخرین تعداد واحدها

نتیجه نهایی

• متقاضی یکی از دوره‌های سه‌ماهه یا دوازده‌ماهه را انتخاب کرده است.
• مبلغ هر واحد، مبلغ پیش از تخفیف، تخفیف، شارژ اولیه پنل پیامکی و جمع کل پیش از مالیات و عوارض مشخص شده‌اند.
• اضافه‌شدن مالیات و عوارض به متقاضی اعلام شده است.
• دوره و محاسبات انتخاب‌شده در درخواست راه‌اندازی ثبت شده‌اند.
• هنوز پرداختی انجام و ساختمان فعالی ایجاد نشده است.
• متقاضی آماده ورود به سناریوی SET-04 است.

۱۱. سناریوی SET-04 — پرداخت آنلاین اشتراک

بازیگران

• متقاضی راه‌اندازی ساختمان
• سامانه تریپیلون
• درگاه پرداخت

نقطه شروع

متقاضی در سناریوی SET-03 دوره سه‌ماهه یا دوازده‌ماهه را انتخاب و ورود به پرداخت را تأیید می‌کند.

پیش‌شرط‌ها

• درخواست راه‌اندازی دارای نام ساختمان و تعداد معتبر واحدها است.
• دوره اشتراک، مبلغ شارژ اولیه پنل پیامکی و جمع کل پیش از مالیات و عوارض مشخص شده‌اند.
• متقاضی Self-Declaration اختیار و مسئولیت ثبت ساختمان را پذیرفته است.
• هنوز پرداخت موفقی برای این درخواست ثبت نشده است.

مسیر اصلی

1. سامانه تعداد واحدها، تعرفه فعال، دوره انتخاب‌شده، تخفیف، شارژ اولیه پنل پیامکی و جمع کل را دوباره اعتبارسنجی می‌کند.
2. سامانه مالیات و عوارض قابل اعمال را محاسبه و به جمع اشتراک و شارژ اولیه پنل پیامکی اضافه می‌کند.
3. سامانه مبلغ نهایی قابل پرداخت را به متقاضی نمایش می‌دهد.
4. متقاضی پرداخت را تأیید می‌کند.
5. سامانه یک درخواست پرداخت یکتا برای مبلغ نهایی ایجاد می‌کند.
6. سامانه متقاضی را به درگاه پرداخت منتقل می‌کند.
7. متقاضی عملیات پرداخت را در درگاه تکمیل می‌کند.
8. درگاه نتیجه پرداخت را به تریپیلون اعلام و متقاضی را به تریپیلون بازمی‌گرداند.
9. سامانه نتیجه پرداخت را مستقیماً از سرویس پرداخت اعتبارسنجی می‌کند.
10. سامانه پرداخت را موفق و معتبر تشخیص می‌دهد.
11. سامانه پیام موفقیت پرداخت را نمایش می‌دهد.
12. سامانه فرایند ایجاد ساختمان را در سناریوی SET-05 آغاز می‌کند.

قواعد پرداخت

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

مسیرهای جایگزین

ALT-SET-04A — لغو پرداخت توسط متقاضی

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

ALT-SET-04B — پرداخت ناموفق

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

ALT-SET-04C — نتیجه پرداخت در حال بررسی

اگر نتیجه پرداخت قطعی نباشد، Callback دریافت نشده باشد یا اعتبارسنجی نهایی در دسترس نباشد، سامانه صفحه «در حال بررسی پرداخت» را نمایش می‌دهد. سامانه تا دریافت نتیجه قطعی، پرداخت را موفق اعلام و ساختمان را ایجاد نمی‌کند.

پس از تعیین نتیجه:

• اگر پرداخت معتبر و موفق باشد، پیام موفقیت نمایش داده و SET-05 آغاز می‌شود.
• اگر پرداخت ناموفق باشد، امکان تلاش مجدد نمایش داده می‌شود.

ALT-SET-04D — دریافت Callback تکراری

سامانه نتیجه قبلی همان درخواست پرداخت را بازیابی می‌کند و عملیات پرداخت یا ایجاد ساختمان را دوباره اجرا نمی‌کند.

خطاها و استثناها

شناسه	خطا	رفتار سیستم	بازیابی
ERR-SET-12	اطلاعات قیمت پیش از پرداخت تغییر کرده یا نامعتبر شده است	انتقال به درگاه انجام نمی‌شود	محاسبه مجدد و تأیید مبلغ جدید توسط متقاضی
ERR-SET-13	ایجاد درخواست پرداخت ناموفق است	متقاضی به درگاه منتقل نمی‌شود	تلاش مجدد بدون ایجاد درخواست پرداخت تکراری
ERR-SET-14	درگاه پرداخت در دسترس نیست	درخواست راه‌اندازی حفظ و خطای موقت نمایش داده می‌شود	تلاش مجدد
ERR-SET-15	اعتبارسنجی نتیجه پرداخت موقتاً ممکن نیست	وضعیت پرداخت موفق یا ناموفق حدس زده نمی‌شود	نمایش صفحه «در حال بررسی پرداخت» و بررسی مجدد
ERR-SET-16	مبلغ تأییدشده در درگاه با مبلغ درخواست متفاوت است	پرداخت معتبر شناخته نمی‌شود و ساختمان ایجاد نمی‌شود	بررسی سیستمی و پشتیبانی

نتیجه نهایی

یکی از نتایج زیر حاصل می‌شود:

• پرداخت معتبر ثبت و سناریوی SET-05 آغاز می‌شود؛
• پرداخت لغو یا ناموفق می‌شود و درخواست برای تلاش مجدد حفظ می‌شود؛
• نتیجه پرداخت در وضعیت «در حال بررسی» باقی می‌ماند و تا تعیین نتیجه، ساختمان ایجاد نمی‌شود.

۱۲. سناریوی SET-05 — ایجاد ساختمان و تخصیص مدیر راه‌اندازی

بازیگران

• متقاضی راه‌اندازی ساختمان
• سامانه تریپیلون

نقطه شروع

پرداخت معتبر در سناریوی SET-04 ثبت شده و سامانه آماده ایجاد ساختمان است.

پیش‌شرط‌ها

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

مسیر اصلی

1. سامانه صفحه «در حال راه‌اندازی ساختمان» را نمایش می‌دهد.
2. سامانه بررسی می‌کند برای پرداخت معتبر، ساختمان دیگری ایجاد نشده باشد.
3. سامانه ساختمان را با نام ثبت‌شده ایجاد می‌کند.
4. سامانه تعداد واحدهای مسکونی، تجاری و اداری را به‌عنوان داده تجمیعی قیمت‌گذاری ثبت می‌کند.
5. سامانه اشتراک سه‌ماهه یا دوازده‌ماهه را بر اساس خرید معتبر فعال می‌کند.
6. سامانه در حالت عادی، زمان پرداخت موفق را به‌عنوان تاریخ شروع اشتراک ثبت می‌کند.
7. سامانه تنظیمات پایه لازم برای ادامه راه‌اندازی را اعمال می‌کند.
8. سامانه برای متقاضی یک Building Membership فعال ایجاد می‌کند.
9. سامانه فقط نقش «مدیر راه‌اندازی ساختمان» را در محدوده ساختمان به Membership متقاضی تخصیص می‌دهد.
10. سامانه دسترسی لازم برای ورود به ساختمان و ادامه چک‌لیست راه‌اندازی را از طریق همین نقش فراهم می‌کند.
11. سامانه ساختمان جدید را Current Context متقاضی قرار می‌دهد.
12. سامانه چک‌لیست تکمیل اطلاعات ساختمان را در صفحه اصلی فعال می‌کند.
13. سامانه راه‌اندازی را موفق اعلام و متقاضی را وارد صفحه اصلی ساختمان می‌کند.

قواعد ایجاد و دسترسی اولیه

• تعدادهای ثبت‌شده در خرید، داده تجمیعی قیمت‌گذاری هستند و به ایجاد خودکار واحد، طبقه یا بلوک منجر نمی‌شوند.
• در این سناریو فقط نقش «مدیر راه‌اندازی ساختمان» به متقاضی تخصیص می‌یابد.
• نقش «مدیر ساختمان» یا هیچ نقش عملیاتی و حاکمیتی دیگری به‌صورت خودکار تخصیص نمی‌یابد.
• وجود نقش‌هایی مانند لابی‌من، نگهبان، سرایدار، حسابدار یا عضو هیئت‌مدیره در این سناریو پرسیده نمی‌شود.
• Role Templateها و تنظیمات نقش‌های ساختمان پس از پاسخ‌های چک‌لیست SET-06 فعال می‌شوند.
• فعال‌شدن Role Template به معنی تخصیص Role یا Permission به فرد نیست.
• جزئیات Permissionهای مدیر راه‌اندازی در مرحله «دسترسی‌ها» تعریف می‌شود؛ در این مرحله فقط ضرورت دسترسی او به ساختمان و چک‌لیست ثبت می‌شود.
• هر پرداخت موفق حداکثر یک ساختمان، یک اشتراک اولیه و یک Membership مدیر راه‌اندازی ایجاد می‌کند.

قواعد شروع اشتراک

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

مسیرهای جایگزین

ALT-SET-05A — راه‌اندازی در حال پردازش

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

ALT-SET-05B — اختلال داخلی تریپیلون

اگر ساخت ساختمان، فعال‌سازی اشتراک، ایجاد Membership یا تخصیص نقش به‌دلیل خطای داخلی کامل نشود:

1. پرداخت معتبر حفظ می‌شود.
2. سامانه عملیات ناقص را بدون ایجاد ساختمان یا عضویت تکراری دوباره اجرا می‌کند.
3. ساختمان تا تکمیل اجزای ضروری، آماده استفاده اعلام نمی‌شود.
4. تاریخ شروع اشتراک به زمان فعال‌شدن واقعی ساختمان منتقل می‌شود.
5. متقاضی در صفحه «در حال راه‌اندازی ساختمان» باقی می‌ماند و دوباره پرداخت نمی‌کند.

ALT-SET-05C — دریافت درخواست تکراری ایجاد ساختمان

سامانه ساختمان و نتیجه راه‌اندازی مرتبط با همان پرداخت را بازیابی می‌کند و ساختمان، اشتراک، Membership یا Role Assignment جدیدی ایجاد نمی‌کند.

خطاها و استثناها

شناسه	خطا	رفتار سیستم	بازیابی
ERR-SET-17	ایجاد ساختمان پس از پرداخت معتبر ناموفق است	پرداخت حفظ و ساختمان آماده استفاده اعلام نمی‌شود	اجرای مجدد خودکار عملیات ایجاد
ERR-SET-18	ساختمان ایجاد شده اما فعال‌سازی اشتراک کامل نشده است	ورود نهایی به ساختمان انجام نمی‌شود	تکمیل خودکار فعال‌سازی بدون دریافت وجه مجدد
ERR-SET-19	ایجاد Membership یا تخصیص مدیر راه‌اندازی کامل نشده است	ساختمان برای متقاضی قابل استفاده اعلام نمی‌شود	اجرای مجدد بخش ناقص بدون ایجاد رکورد تکراری
ERR-SET-20	تعیین Current Context ناموفق است	ساختمان ایجادشده حفظ می‌شود و صفحه راه‌اندازی خطا نمایش می‌دهد	تلاش مجدد برای انتخاب Context

نتیجه نهایی

• ساختمان فعال با نام ثبت‌شده ایجاد شده است.
• تعداد واحدها فقط به‌عنوان داده تجمیعی قیمت‌گذاری نگهداری شده‌اند.
• اشتراک اولیه با تاریخ شروع معتبر فعال شده است.
• متقاضی Building Membership فعال دارد.
• فقط نقش مدیر راه‌اندازی ساختمان به متقاضی تخصیص یافته است.
• هیچ نقش مربوط به کارکنان، مدیریت ساختمان یا هیئت‌مدیره خودکار تخصیص نیافته است.
• ساختمان Current Context متقاضی است.
• چک‌لیست SET-06 در صفحه اصلی در دسترس است.

۱۳. سناریوی SET-06 — تکمیل مرحله‌ای راه‌اندازی از صفحه اصلی

هدف

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

بازیگران

• مدیر راه‌اندازی ساختمان
• سامانه تریپیلون

نقطه شروع

ساختمان در سناریوی SET-05 فعال شده و مدیر راه‌اندازی وارد صفحه اصلی ساختمان می‌شود.

پیش‌شرط‌ها

• ساختمان فعال و Current Context مدیر راه‌اندازی است.
• Membership و نقش مدیر راه‌اندازی فعال هستند.
• مدیر راه‌اندازی به Setup Dashboard دسترسی دارد.

بخش‌های Setup Dashboard

ترتیب پیشنهادی	بخش	اهمیت	نتیجه مورد انتظار
۱	واحدها و ساکنان	ضروری برای داده پایه ساختمان	ثبت فهرست اولیه واحدها و ارتباط اشخاص
۲	تیم مدیریت و هیئت‌مدیره	ضروری برای مدیریت رسمی	مشخص‌شدن نقش‌های حاکمیتی و آماده‌سازی انتساب
۳	کارکنان و دسترسی‌ها	وابسته به وجود کارکنان	انتخاب Role Template و آماده‌سازی دسترسی پیشنهادی
۴	تنظیمات مالی و شارژ	ضروری برای استفاده از قابلیت‌های مالی	هدایت به تنظیمات مرجع ماژول مالی
۵	امکانات و تنظیمات تکمیلی	اختیاری یا وابسته به ساختمان	ثبت امکانات و اطلاعاتی مانند آدرس

جزئیات تخصصی هر قابلیت در ماژول مرجع خودش تعریف می‌شود. Setup Dashboard فقط وضعیت، اولویت، نقطه ورود و معیار تکمیل هر بخش را مدیریت می‌کند.

وضعیت بخش‌ها

هر بخش یکی از وضعیت‌های زیر را دارد:

• شروع نشده
• در حال تکمیل
• تکمیل‌شده
• در این ساختمان وجود ندارد
• فعلاً تکمیل‌شده

قواعد تجربه راه‌اندازی

• بخش‌ها ترتیب پیشنهادی دارند، اما به‌صورت اجباری پشت سر هم اجرا نمی‌شوند.
• مدیر می‌تواند Setup Dashboard را ببندد و بعداً ادامه دهد.
• صفحه اصلی تعداد بخش‌های باقی‌مانده و درصد پیشرفت را نمایش می‌دهد.
• تکمیل‌نشدن همه بخش‌ها مانع ورود مدیر به ساختمان یا شروع اشتراک نمی‌شود.
• هر قابلیت می‌تواند تا تکمیل داده وابسته خودش، وضعیت ناقص یا راهنمای تکمیل نمایش دهد.
• بخش اختیاری می‌تواند با انتخاب «در این ساختمان وجود ندارد» حل‌شده محسوب شود.
• تأخیر مدیر در تکمیل بخش‌ها باعث جابه‌جایی تاریخ شروع اشتراک نمی‌شود.

مسیر اصلی Setup Dashboard

1. سامانه پنج بخش راه‌اندازی را در صفحه اصلی نمایش می‌دهد.
2. سامانه وضعیت، اهمیت و میزان پیشرفت هر بخش را نمایش می‌دهد.
3. مدیر راه‌اندازی یکی از بخش‌ها را انتخاب می‌کند.
4. سامانه مدیر را به قابلیت یا تنظیمات مرجع همان بخش هدایت می‌کند.
5. پس از ذخیره اطلاعات معتبر، سامانه وضعیت بخش را به‌روزرسانی می‌کند.
6. مدیر می‌تواند به صفحه اصلی بازگردد و بخش دیگری را در زمان دلخواه تکمیل کند.
7. با حل‌شدن همه بخش‌ها، Setup Dashboard وضعیت راه‌اندازی را کامل اعلام می‌کند.

۱۳.۱. زیرسناریوی SET-06A — ثبت واحدها و ساکنان

هدف

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

قواعد تکمیل بخش

• تکمیل بخش به برابرشدن تعداد واحدهای ثبت‌شده با تعداد واحدهای خریداری‌شده وابسته نیست.
• مدیر می‌تواند فهرست اولیه را در وضعیت «فعلاً تکمیل‌شده» قرار دهد و بعداً آن را اصلاح کند.
• هر واحد می‌تواند خالی یا دارای یک یا چند شخص مرتبط باشد.
• یک شخص می‌تواند با یک شماره موبایل به چند واحد مرتبط باشد.
• ثبت فهرست، Person Record، Building Membership عملیاتی و Unit Relationship ایجاد می‌کند.
• ثبت فهرست، Account Link، Invitation یا Permission فعال ایجاد نمی‌کند.
• زمان ارسال دعوت‌نامه کاملاً در اختیار مدیر است و از Action همان شخص در «لیست واحدها ← جزئیات واحد ← افراد و نقش‌ها» آغاز می‌شود.

اختلاف با ظرفیت خریداری‌شده

• کمتر یا بیشتر بودن تعداد واحدهای واقعی نسبت به تعداد خریداری‌شده مانع ثبت فهرست یا تکمیل این بخش نمی‌شود.
• اگر تعداد واحدهای واقعی بیشتر از ظرفیت خریداری‌شده باشد، سامانه هشدار نمایش می‌دهد.
• سامانه اختلاف ظرفیت را برای پیگیری ثبت می‌کند.
• اصلاح ظرفیت و مبلغ اشتراک در Flow جداگانه تغییر اشتراک انجام می‌شود و داخل SET-06A نیست.

ورود دستی

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

ورود با Excel

فایل Excel در نسخه اولیه یک Sheet دارد و هر ردیف نماینده ارتباط یک شخص با یک واحد است. اگر چند شخص به یک واحد مرتبط باشند، اطلاعات واحد در چند ردیف تکرار می‌شود.

ستون	الزام	توضیح
block	اختیاری	نام یا شماره بلوک، در صورت وجود
floor	اختیاری	طبقه، در صورت وجود
unit_number	الزامی	شماره یا شناسه واحد
unit_type	الزامی	مسکونی، تجاری یا اداری
occupancy_status	الزامی	خالی یا دارای ساکن
first_name	برای واحد دارای ساکن الزامی	نام شخص
last_name	برای واحد دارای ساکن الزامی	نام خانوادگی شخص
mobile	اختیاری	شماره موبایل برای دعوت آتی
relation	برای شخص الزامی	مالک، مستأجر، ساکن یا عضو خانواده

مسیر اصلی Upload

1. مدیر بخش «واحدها و ساکنان» را باز می‌کند.
2. مدیر قالب Excel را دریافت و تکمیل می‌کند.
3. مدیر فایل را بارگذاری می‌کند.
4. سامانه ساختار فایل، ستون‌ها، واحدها، اشخاص و روابط را اعتبارسنجی می‌کند.
5. سامانه Preview شامل تعداد واحدها، اشخاص، خطاها و هشدارها را نمایش می‌دهد.
6. اگر خطای مسدودکننده وجود داشته باشد، کل Import متوقف می‌شود.
7. مدیر خطاها را مشاهده یا گزارش آن‌ها را دریافت و فایل را اصلاح می‌کند.
8. اگر خطای مسدودکننده وجود نداشته باشد، مدیر Import را تأیید می‌کند.
9. سامانه واحدها، رکورد اشخاص، Building Membership عملیاتی و روابط آن‌ها را بدون ارسال دعوت‌نامه ثبت می‌کند.
10. سامانه نتیجه Import و وضعیت به‌روزشده بخش را نمایش می‌دهد.

قواعد اعتبارسنجی Excel

• Import به‌صورت یکپارچه انجام می‌شود؛ وجود خطای مسدودکننده باعث توقف کل فایل می‌شود.
• Warning مانع Import نیست، اما پیش از تأیید به مدیر نمایش داده می‌شود.
• خالی‌بودن شماره موبایل Warning است و مانع ثبت شخص نمی‌شود.
• شخص بدون شماره موبایل تا تکمیل شماره، قابل دعوت نیست.
• خالی‌بودن relation برای ردیف دارای شخص، خطای مسدودکننده است.
• تکرار یک واحد برای ثبت چند شخص مجاز است.
• تکرار شماره موبایل باعث ایجاد Account جدید نمی‌شود.
• Import موفق هیچ پیامک یا دعوت‌نامه‌ای ارسال نمی‌کند.

خطاها و بازیابی

شناسه	خطا	رفتار سیستم	بازیابی
ERR-SET-21	قالب یا ستون‌های فایل معتبر نیستند	Preview نهایی و Import انجام نمی‌شوند	دریافت قالب و اصلاح فایل
ERR-SET-22	یک یا چند ردیف خطای مسدودکننده دارند	کل Import متوقف می‌شود	دریافت گزارش، اصلاح و Upload مجدد
ERR-SET-23	نوع واحد، وضعیت سکونت یا رابطه نامعتبر است	ردیف خطادار مشخص و Import متوقف می‌شود	انتخاب مقدار معتبر
ERR-SET-24	ثبت نهایی Import ناموفق است	داده ناقص ثبت نمی‌شود	تلاش مجدد بدون ایجاد داده تکراری

نتیجه نهایی SET-06A

• فهرست اولیه واحدها و اشخاص مرتبط ثبت شده است.
• واحدهای خالی قابل ثبت هستند.
• اختلاف احتمالی ظرفیت خریداری‌شده ثبت و در صورت نیاز هشدار داده شده است.
• Building Membership عملیاتی و رابطه شخص با واحد ثبت شده‌اند.
• هیچ Invitation، Account Link یا Permission فعالی ایجاد نشده است.
• مدیر می‌تواند در زمان دلخواه از ردیف شخص در جزئیات همان واحد، دعوت، Resend یا Cancel را انجام دهد.

۱۳.۲. زیرسناریوی SET-06B — تعیین تیم مدیریت و هیئت‌مدیره

هدف

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

نقش‌های اولیه

• مدیر ساختمان
• رئیس هیئت‌مدیره
• عضو هیئت‌مدیره
• خزانه‌دار
• بازرس

یک شخص می‌تواند هم‌زمان چند نقش داشته باشد.

مدل‌های مدیریت

مدیر راه‌اندازی یکی از مدل‌های زیر را انتخاب می‌کند:

• فقط مدیر ساختمان
• مدیر ساختمان همراه با هیئت‌مدیره
• فقط هیئت‌مدیره
• ساختار مدیریت هنوز مشخص نیست

انتخاب «ساختار مدیریت هنوز مشخص نیست» مجاز است، اما بخش را در وضعیت «در حال تکمیل» نگه می‌دارد.

مسیر اصلی

1. مدیر راه‌اندازی بخش «تیم مدیریت و هیئت‌مدیره» را باز می‌کند.
2. سامانه مدل‌های مدیریت را نمایش می‌دهد.
3. مدیر راه‌اندازی مدل مناسب ساختمان را انتخاب می‌کند.
4. سامانه Roleهای مرتبط با مدل انتخاب‌شده را پیشنهاد می‌دهد.
5. مدیر برای هر Role یک شخص را از فهرست SET-06A انتخاب یا شخص جدیدی را با نام و شماره موبایل ثبت می‌کند.
6. سامانه برای هر Role، بسته دسترسی پیش‌فرض را به‌صورت خلاصه نمایش می‌دهد.
7. مدیر می‌تواند بسته پیشنهادی را بدون مشاهده فهرست کامل Permissionها تأیید کند.
8. سامانه گزینه ثانویه «شخصی‌سازی دسترسی‌ها» را برای کاربر حرفه‌ای در دسترس قرار می‌دهد.
9. مدیر ساختار مدیریت و اشخاص مسئول را ذخیره می‌کند.
10. سامانه وضعیت بخش را بر اساس معیارهای تکمیل به‌روزرسانی می‌کند.

تخصیص نقش به خود مدیر راه‌اندازی

مدیر راه‌اندازی می‌تواند خودش را به‌عنوان مدیر ساختمان، رئیس هیئت‌مدیره یا هر Role مجاز دیگری انتخاب کند.

در این حالت:

• دعوت‌نامه لازم نیست.
• Account و Membership شخص از قبل فعال هستند.
• سامانه پیش از تخصیص، تأیید می‌گیرد که شخص در حال افزودن یک نقش مدیریتی جدید به خودش است.
• Role جدید پس از تأیید به Membership فعال او تخصیص می‌یابد.
• بسته دسترسی پیش‌فرض Role فعال می‌شود.
• اقدام در Audit Trail ثبت می‌شود.
• Role «مدیر راه‌اندازی ساختمان» حذف یا جایگزین نمی‌شود.
• شخص می‌تواند هم‌زمان چند Role داشته باشد.

تخصیص نقش به سایر افراد

• ثبت نام شخص در این بخش به‌تنهایی Membership یا Permission فعال ایجاد نمی‌کند.
• اگر شخص Membership فعال نداشته باشد، Role پیشنهادی تا تکمیل دعوت از Action همان شخص در فهرست تیم مدیریت در وضعیت در انتظار باقی می‌ماند.
• ارسال Invitation و SMS در اختیار مدیر و خارج از این زیرسناریو است.
• Permissionها برای شخص فاقد Membership فعال، پیش از پذیرش دعوت اعمال نمی‌شوند.

تجربه تنظیم دسترسی

• بسته دسترسی پیش‌فرض برای هر Role، مسیر اصلی و پیشنهادی است.
• فهرست کامل Permissionها در نمای اصلی نمایش داده نمی‌شود.
• گزینه «شخصی‌سازی دسترسی‌ها» ثانویه و کم‌تأکید است.
• در نمای پیشرفته، Permissionها باید گروه‌بندی شوند.
• Permissionهای حساس مانند مالی، اطلاعات خصوصی و مدیریت کاربران باید جدا و همراه با هشدار نمایش داده شوند.
• تعریف دقیق بسته‌ها و Permissionهای هر Role در مرحله «دسترسی‌ها» انجام می‌شود.

معیار تکمیل بخش

بخش زمانی تکمیل‌شده محسوب می‌شود که:

• مدل مدیریت انتخاب شده باشد؛
• حداقل یک شخص مسئول به‌عنوان مدیر ساختمان یا رئیس هیئت‌مدیره مشخص شده باشد؛
• Roleهای انتخاب‌شده دارای شخص مسئول باشند.

ارسال یا پذیرش Invitation شرط تکمیل این بخش نیست.

تاریخ شروع و پایان دوره مسئولیت در راه‌اندازی اولیه اختیاری است و می‌تواند بعداً تکمیل شود.

مسیرهای جایگزین

ALT-SET-06B-01 — انتخاب خود مدیر راه‌اندازی

مدیر راه‌اندازی خودش را به‌عنوان مسئول انتخاب می‌کند، تأیید تخصیص نقش را انجام می‌دهد و Role جدید بدون Invitation فعال می‌شود.

ALT-SET-06B-02 — ساختار مدیریت هنوز مشخص نیست

سامانه انتخاب فعلی را ذخیره می‌کند و بخش در وضعیت «در حال تکمیل» باقی می‌ماند. مدیر می‌تواند بعداً بازگردد و ساختار نهایی را تعیین کند.

ALT-SET-06B-03 — شخص مسئول هنوز عضو نیست

اطلاعات شخص و Role پیشنهادی ذخیره می‌شوند، اما Role فعال و Permission اعمال نمی‌شود. مدیر می‌تواند در زمان دلخواه از ردیف همان Role و شخص، دعوت را ارسال کند.

خطاها و بازیابی

شناسه	خطا	رفتار سیستم	بازیابی
ERR-SET-25	مدل مدیریت انتخاب شده اما شخص مسئولی مشخص نشده است	بخش تکمیل‌شده اعلام نمی‌شود	انتخاب مدیر ساختمان یا رئیس هیئت‌مدیره
ERR-SET-26	تخصیص Role به خود مدیر راه‌اندازی بدون تأیید نهایی است	Role جدید فعال نمی‌شود	تأیید صریح تخصیص
ERR-SET-27	شخص فاقد Membership فعال است	Permission فعال نمی‌شود	ذخیره Role پیشنهادی و دعوت بعدی از MEM-01
ERR-SET-28	ذخیره ساختار مدیریت ناموفق است	وضعیت قبلی حفظ می‌شود	تلاش مجدد بدون ایجاد Role Assignment تکراری

نتیجه نهایی SET-06B

• مدل مدیریت ساختمان مشخص شده است یا در وضعیت «هنوز مشخص نیست» قرار دارد.
• حداقل یک شخص مسئول برای تکمیل بخش تعیین شده است.
• مدیر راه‌اندازی می‌تواند خودش یکی از اشخاص مسئول باشد.
• تخصیص Role به خود مدیر بدون Invitation و با ثبت Audit انجام می‌شود.
• Role سایر افراد فاقد Membership تا ارسال و پذیرش Invitation فعال نمی‌شود.
• جزئیات Permissionها بدون نیاز در معرض مدیر قرار نگرفته‌اند.

۱۳.۳. زیرسناریوی SET-06C — تعیین کارکنان و بسته‌های دسترسی

هدف

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

انواع نیروی اولیه

• لابی‌من
• نگهبان
• سرایدار
• مسئول تأسیسات
• حسابدار
• ناظر مالی
• مدیر عملیات
• تعمیرکار
• پیمانکار

فهرست Roleهای قابل استفاده و Permissionهای دقیق در مرحله «دسترسی‌ها» نهایی می‌شود.

مسیر اصلی

1. مدیر راه‌اندازی بخش «کارکنان و دسترسی‌ها» را باز می‌کند.
2. سامانه انواع نیروی پیشنهادی را نمایش می‌دهد.
3. مدیر انواع نیروی موجود یا موردنیاز ساختمان را انتخاب می‌کند.
4. سامانه برای هر نوع کار، Role Template و بسته دسترسی پیش‌فرض را فعال می‌کند.
5. سامانه خلاصه‌ای قابل فهم از قابلیت‌های اصلی هر بسته نمایش می‌دهد.
6. مدیر می‌تواند بسته پیشنهادی را بدون مشاهده فهرست کامل Permissionها تأیید کند.
7. مدیر در صورت نیاز گزینه ثانویه «شخصی‌سازی دسترسی‌ها» را باز می‌کند.
8. سامانه Permissionها را به‌صورت گروه‌بندی‌شده نمایش می‌دهد.
9. مدیر تغییرات Role Template را تأیید و ذخیره می‌کند.
10. مدیر برای Role موردنظر یک شخص را انتخاب می‌کند یا موقعیت را «بدون متصدی» ثبت می‌کند.
11. سامانه تنظیمات Role و موقعیت‌های نیروی انسانی را بدون ارسال Invitation ذخیره می‌کند.
12. سامانه وضعیت بخش را بر اساس معیارهای تکمیل به‌روزرسانی می‌کند.

قواعد Role Template

• شخصی‌سازی دسترسی در سطح Role Template همان ساختمان انجام می‌شود.
• تغییر Role Template بر تمام افرادی که اکنون یا در آینده همان Role را در ساختمان دریافت می‌کنند اعمال می‌شود.
• در نسخه اولیه، Permission اختصاصی برای یک فرد تعریف نمی‌شود.
• تفاوت دسترسی افراد هم‌Role از طریق Per-person Override در محدوده این راه‌اندازی نیست.
• بسته پیش‌فرض مسیر اصلی و پیشنهادی است.
• گزینه «شخصی‌سازی دسترسی‌ها» ثانویه و کم‌تأکید است.
• مدیر می‌تواند Role Template را به تنظیمات پیش‌فرض تریپیلون بازگرداند.
• هر تغییر Role Template باید در Audit Trail ثبت شود.

نمایش Permissionها

• فهرست طولانی Permissionها در نمای اصلی نمایش داده نمی‌شود.
• نمای اصلی فقط خلاصه قابلیت‌های مهم Role را نشان می‌دهد.
• در نمای پیشرفته، Permissionها بر اساس حوزه کاری گروه‌بندی می‌شوند.
• Permissionهای مالی، اطلاعات خصوصی، مدیریت کاربران و تغییر دسترسی‌ها حساس محسوب می‌شوند.
• فعال‌کردن Permission حساس نیازمند تأیید صریح و نمایش هشدار است.
• اگر تغییر Role Template بر افراد فعال اثر بگذارد، تعداد افراد متأثر پیش از ذخیره نمایش داده می‌شود.

انتخاب شخص یا موقعیت بدون متصدی

• مدیر می‌تواند شخص را از فهرست قبلی انتخاب یا شخص جدیدی با نام و شماره موبایل ثبت کند.
• انتخاب شخص در این بخش به‌تنهایی Invitation، Membership یا Permission فعال ایجاد نمی‌کند.
• فعال‌سازی Role برای شخص از Action همان موقعیت شغلی و پس از پذیرش دعوت انجام می‌شود.
• مدیر می‌تواند Role موردنیاز را بدون انتخاب شخص، با وضعیت «بدون متصدی» ثبت کند.
• وضعیت «بدون متصدی» به معنی فعال‌بودن Role Template بدون Role Assignment فعال است.
• Shift، Schedule و Task Assignment در این زیرسناریو تعریف نمی‌شوند.

ساختمان بدون کارکنان

اگر ساختمان هیچ نیروی اجرایی یا اداری ندارد، مدیر می‌تواند گزینه «ساختمان در حال حاضر کارکنان ندارد» را انتخاب کند. در این حالت بخش حل‌شده محسوب می‌شود و هیچ Role Template عملیاتی فعال نمی‌شود.

معیار تکمیل بخش

بخش زمانی تکمیل‌شده محسوب می‌شود که:

• انواع نیروی موجود یا موردنیاز مشخص شده باشند؛
• برای هر نوع انتخاب‌شده، Role Template پیش‌فرض یا سفارشی ذخیره شده باشد؛
• هر Role دارای شخص پیشنهادی یا وضعیت «بدون متصدی» باشد؛
• یا نبود کارکنان در ساختمان صریحاً ثبت شده باشد.

ارسال و پذیرش Invitation شرط تکمیل این بخش نیست.

مسیرهای جایگزین

ALT-SET-06C-01 — پذیرش بسته دسترسی پیش‌فرض

مدیر بدون ورود به جزئیات Permissionها، بسته پیشنهادی تریپیلون را تأیید می‌کند و Role Template ذخیره می‌شود.

ALT-SET-06C-02 — شخصی‌سازی Role Template

مدیر نمای پیشرفته را باز می‌کند، Permissionهای گروه‌بندی‌شده را تغییر می‌دهد و پس از بررسی هشدارهای لازم، تنظیمات را ذخیره می‌کند. تغییر برای همه افراد همان Role در ساختمان اعمال می‌شود.

ALT-SET-06C-03 — موقعیت بدون متصدی

مدیر نوع کار و Role Template را مشخص می‌کند، اما هنوز شخصی برای آن ندارد. موقعیت با وضعیت «بدون متصدی» ذخیره می‌شود و بعداً قابل تکمیل است.

ALT-SET-06C-04 — ساختمان بدون کارکنان

مدیر نبود کارکنان را ثبت می‌کند. بخش تکمیل‌شده محسوب می‌شود و هر زمان شرایط ساختمان تغییر کند قابل بازگشایی است.

خطاها و بازیابی

شناسه	خطا	رفتار سیستم	بازیابی
ERR-SET-29	Role انتخاب شده اما Role Template معتبر ندارد	بخش تکمیل‌شده اعلام نمی‌شود	انتخاب بسته پیش‌فرض یا ذخیره تنظیمات معتبر
ERR-SET-30	Permission حساس بدون تأیید صریح فعال شده است	تغییر ذخیره نمی‌شود	مشاهده هشدار و تأیید صریح
ERR-SET-31	تغییر Role Template بر افراد فعال اثر می‌گذارد اما اثر آن تأیید نشده است	تغییر اعمال نمی‌شود	بررسی افراد متأثر و تأیید تغییر
ERR-SET-32	ذخیره Role Template یا موقعیت نیروی انسانی ناموفق است	تنظیمات قبلی حفظ می‌شوند	تلاش مجدد بدون ایجاد Role تکراری

نتیجه نهایی SET-06C

• انواع نیروی ساختمان مشخص شده‌اند یا نبود کارکنان ثبت شده است.
• Role Template هر نوع کار با بسته پیش‌فرض یا سفارشی آماده است.
• سفارشی‌سازی در سطح Role انجام شده و برای افراد جداگانه Override ایجاد نشده است.
• هر Role دارای شخص پیشنهادی یا وضعیت «بدون متصدی» است.
• هیچ Invitation، Membership یا Permission جدیدی صرفاً به‌دلیل تکمیل این بخش فعال نشده است.
• مدیر می‌تواند Invitation کارکنان را در زمان دلخواه از ردیف همان موقعیت شغلی ارسال کند.

۱۳.۴. زیرسناریوی SET-06D — ورود به تنظیمات مالی و شارژ

هدف

مدیر راه‌اندازی تصمیم می‌گیرد تنظیمات مالی را اکنون آغاز کند یا به زمان دیگری موکول کند. این بخش فقط نقطه ورود و وضعیت راه‌اندازی قابلیت مالی را مدیریت می‌کند؛ تعریف Expense، Charge، Bill، Template و گردش‌کار انتشار در سند مرجع ماژول مالی انجام می‌شود.

اصول مرزبندی

• تریپیلون روش محاسبه، دوره یا گروه پرداخت‌کننده را به‌صورت خودکار انتخاب نمی‌کند.
• روش پیشنهادی دریافت وجه «پرداخت آنلاین» است، اما مدیر باید مقصد تسویه آن را آگاهانه تأیید کند.
• مدیر می‌تواند در کنار پرداخت آنلاین، واریز بانکی را نیز فعال کند؛ این دو روش مانعةالجمع نیستند.
• بازکردن این بخش هیچ Charge، Bill یا Expenseای ایجاد نمی‌کند.
• انتشار اولین Charge شرط تکمیل Setup Dashboard نیست.
• جزئیات محاسبه و انتشار به ماژول «شارژ ساختمان و صورتحساب» تعلق دارد.

پیش‌نیاز

• مدیر راه‌اندازی به Setup Dashboard دسترسی دارد.
• برای تخصیص Charge به واحدها، حداقل فهرست اولیه واحدها در SET-06A باید موجود باشد.
• بدون واحد، مدیر می‌تواند بخش را مشاهده کند اما نمی‌تواند تنظیمات قابل اجرا را نهایی کند.

مسیر اصلی

1. مدیر راه‌اندازی بخش «تنظیمات مالی و شارژ» را باز می‌کند.
2. سامانه دو انتخاب «شروع تنظیمات مالی» و «بعداً انجام می‌دهم» را نمایش می‌دهد.
3. مدیر «شروع تنظیمات مالی» را انتخاب می‌کند.
4. سامانه وجود فهرست اولیه واحدها را بررسی می‌کند.
5. سامانه مدیر را به تنظیمات مرجع ماژول مالی هدایت می‌کند.
6. سامانه «پرداخت آنلاین» را به‌عنوان روش پیش‌فرض نمایش می‌دهد.
7. مدیر مقصد تسویه آنلاین را انتخاب یا ثبت می‌کند.
8. مدیر می‌تواند گزینه «واریز بانکی با تأیید قبض» را نیز فعال کند.
9. برای واریز بانکی، مدیر یک یا چند مقصد را ثبت می‌کند:
10. شماره کارت برای کارت‌به‌کارت؛
11. شماره حساب یا شبا برای حساب‌به‌حساب؛
12. نام صاحب حساب و بانک؛
13. توضیح یا دستورالعمل لازم برای پرداخت‌کننده.
14. مدیر مشخص می‌کند چه Roleهایی اجازه بررسی قبض دارند.
15. سامانه خلاصه هر دو مسیر دریافت وجه و اثر آن‌ها بر مانده واحد را نمایش می‌دهد.
16. مدیر تنظیمات را ذخیره می‌کند.
17. سامانه وضعیت بخش را «تکمیل‌شده» یا «در حال تکمیل» اعلام می‌کند.

قواعد حساب و دریافت وجه

• پرداخت آنلاین روش پیش‌فرض رابط است، نه انتخاب قطعی و غیرقابل‌تغییر کسب‌وکار.
• مدیر می‌تواند فقط پرداخت آنلاین، فقط واریز بانکی یا هر دو را فعال کند.
• مقصد تسویه معتبر برای فعال‌سازی پرداخت آنلاین الزامی است.
• حداقل یک کارت، حساب یا شبا برای فعال‌سازی واریز بانکی الزامی است.
• واریز بانکی شامل دو گزینه «کارت‌به‌کارت» و «حساب‌به‌حساب» است.
• پرداخت‌کننده پس از واریز، مبلغ، تاریخ، شماره پیگیری و تصویر قبض را ثبت می‌کند.
• ثبت قبض به‌تنهایی Payment قطعی ایجاد نمی‌کند و مانده واحد را کاهش نمی‌دهد.
• قبض ابتدا در وضعیت «در انتظار تأیید» قرار می‌گیرد.
• مدیر ساختمان، حسابدار یا Role مالی مجاز می‌تواند قبض را تأیید یا با دلیل رد کند.
• تأیید قبض، Payment دستی را ثبت و آن را به Bill یا بدهی انتخاب‌شده تخصیص می‌دهد؛ سپس مانده Unit Ledger کاهش می‌یابد.
• رد قبض، مانده بدهی را تغییر نمی‌دهد و پرداخت‌کننده می‌تواند قبض اصلاح‌شده ارسال کند.
• تأیید تکراری یک قبض نباید Payment یا کاهش مانده تکراری ایجاد کند.
• اطلاعات کامل کارت و حساب فقط برای کاربران مجاز نمایش داده می‌شوند.
• اطلاعات حساب و تسویه باید در ماژول مالی نگهداری شوند، نه در Setup Dashboard.

تجربه پرداخت ساکن

اگر هر دو روش فعال باشند، صفحه پرداخت Bill این گزینه‌ها را نمایش می‌دهد:

1. پرداخت آنلاین — انتقال به درگاه، تأیید خودکار و کاهش مانده پس از نتیجه معتبر Provider؛
2. کارت‌به‌کارت — نمایش کارت مقصد، ثبت مشخصات و بارگذاری قبض؛
3. حساب‌به‌حساب — نمایش حساب یا شبا، ثبت مشخصات و بارگذاری قبض.

وضعیت قبض واریز بانکی برای پرداخت‌کننده یکی از این موارد است:

• در انتظار تأیید؛
• تأیید و اعمال‌شده در مانده؛
• ردشده همراه با دلیل؛
• نیازمند اصلاح.

انتخاب «بعداً انجام می‌دهم»

• مدیر می‌تواند راه‌اندازی مالی را به تعویق بیندازد.
• بخش با وضعیت «فعلاً تکمیل‌شده» یا «بعداً» در Setup Dashboard ثبت می‌شود.
• این انتخاب مانع تکمیل کلی راه‌اندازی ساختمان نمی‌شود.
• قابلیت‌های وابسته به تنظیمات مالی تا زمان تکمیل آن‌ها فعال یا قابل اجرا نیستند.
• مدیر می‌تواند هر زمان بخش را دوباره باز کند.

ارتباط با ساخت Charge

ساخت Charge در ماژول مالی انجام می‌شود و هنگام ایجاد آن، مدیر مشخص می‌کند:

• Charge یک‌باره است یا تکرارشونده؛
• در حالت تکرارشونده، Draft در چه تناوبی ساخته شود؛
• روز انتشار پیشنهادی چه زمانی است؛
• گروه پرداخت‌کننده چه کسانی هستند؛
• مبلغ با چه روش سفارشی محاسبه شود؛
• آیا تنظیمات به‌عنوان Template ذخیره شوند.

Schedule فقط Draft ایجاد می‌کند. هر Draft باید پیش از Publish توسط مدیر بررسی و تأیید شود.

معیار تکمیل بخش

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

• مدیر تنظیمات اولیه مالی و روش دریافت وجه را ذخیره کرده است؛
• مدیر صریحاً «بعداً انجام می‌دهم» را انتخاب کرده است.

ساخت یا انتشار Charge شرط تکمیل این بخش نیست.

خطاها و بازیابی

شناسه	خطا	رفتار سیستم	بازیابی
ERR-SET-33	فهرست واحدها برای تخصیص مالی موجود نیست	نهایی‌سازی تنظیمات قابل اجرا متوقف می‌شود	تکمیل حداقل فهرست واحدها در SET-06A
ERR-SET-34	دریافت آنلاین انتخاب شده اما مقصد تسویه معتبر نیست	فعال‌سازی دریافت آنلاین انجام نمی‌شود	ثبت یا اصلاح مقصد تسویه
ERR-SET-35	ذخیره تنظیمات مالی ناموفق است	وضعیت قبلی بخش حفظ می‌شود	تلاش مجدد
ERR-SET-35A	واریز بانکی فعال است اما کارت، حساب یا شبای معتبر ثبت نشده است	روش واریز بانکی فعال نمی‌شود	ثبت حداقل یک مقصد معتبر
ERR-SET-35B	قبض بدون مبلغ، تاریخ، شماره پیگیری یا فایل معتبر ارسال شده است	قبض ثبت نهایی نمی‌شود	تکمیل اطلاعات یا بارگذاری فایل معتبر
ERR-SET-35C	قبض قبلاً تأیید یا رد شده است	تصمیم دوم اعمال نمی‌شود	بارگذاری وضعیت جاری
ERR-SET-35D	تأییدکننده Permission مالی معتبر ندارد	قبض و مانده بدون تغییر می‌مانند	ارجاع به مدیر یا Role مالی مجاز

نتیجه نهایی SET-06D

• مدیر تنظیمات اولیه مالی را آغاز کرده یا آن را آگاهانه به تعویق انداخته است.
• هیچ روش محاسبه‌ای به‌صورت خودکار به ساختمان تحمیل نشده است.
• پرداخت آنلاین به‌عنوان روش پیش‌فرض پیشنهاد شده و واریز بانکی می‌تواند در کنار آن فعال باشد.
• مسیر کارت‌به‌کارت و حساب‌به‌حساب با بارگذاری قبض و تأیید مدیر تعریف شده است.
• مانده واحد فقط پس از تأیید معتبر پرداخت آنلاین یا قبض بانکی کاهش می‌یابد.
• هیچ Charge یا Bill صرفاً با تکمیل این بخش ایجاد یا منتشر نشده است.
• مدیر برای ادامه کار به ماژول مرجع مالی هدایت می‌شود.

۱۳.۵. زیرسناریوی SET-06E — تعریف امکانات و قواعد استفاده

هدف

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

امکانات پیشنهادی

کاتالوگ اولیه در رابط به‌صورت گروه‌بندی‌شده نمایش داده می‌شود:

گروه	امکانات پیشنهادی
ورزشی و تندرستی	استخر، سونا، جکوزی، باشگاه ورزشی، زمین ورزشی
گردهمایی و کار	سالن اجتماعات، سالن چندمنظوره، اتاق جلسه، فضای کار اشتراکی
فضای باز و خانواده	روف‌گاردن، حیاط یا باغ، فضای بازی کودک، فضای باربیکیو
پارکینگ و نگهداری	پارکینگ مهمان، پارکینگ دوچرخه یا موتور، جایگاه شارژ خودروی برقی، انباری قابل تخصیص
خدمات مشترک	لاندری، نمازخانه، اتاق مهمان، آشپزخانه یا سالن پذیرایی مشترک
زیرساخت ساختمان	آسانسور، ژنراتور یا UPS، مخزن و پمپ آب، موتورخانه یا تهویه مرکزی
ایمنی و دسترسی	دوربین مداربسته، کنترل تردد، آیفون یا دربازکن، اعلام و اطفای حریق
سفارشی	هر فضای قابل رزرو، خدمت مشترک یا زیرساخت تعریف‌شده توسط مدیر

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

مسیر اصلی

1. مدیر راه‌اندازی بخش «امکانات و تنظیمات تکمیلی» را باز می‌کند.
2. سامانه گزینه «ساختمان امکانات ندارد» و فهرست امکانات پیشنهادی را نمایش می‌دهد.
3. مدیر یک یا چند امکان را انتخاب یا امکان سفارشی ایجاد می‌کند.
4. سامانه هر امکان را ابتدا در وضعیت Draft ایجاد می‌کند.
5. سامانه نوع امکان را تشخیص می‌دهد: رزروپذیر، استفاده آزاد، خدمت مشترک یا زیرساخت.
6. مدیر مدل استفاده یا رزرو را برای هر امکان مشخص می‌کند.
7. مدیر گروه‌های مجاز استفاده را تعیین می‌کند.
8. مدیر مدل قیمت‌گذاری را برای امکانات پولی انتخاب می‌کند.
9. مدیر زمان‌بندی، ظرفیت، محدودیت‌ها، تأیید و قواعد لغو را برای امکانات رزروپذیر مشخص می‌کند.
10. برای زیرساخت‌ها، مدیر وضعیت، محل، مسئول نگهداری، دوره سرویس و اطلاعات ضروری را ثبت می‌کند.
11. مدیر مسئولان مدیریت و تأیید را تعیین می‌کند.
12. سامانه کامل‌بودن حداقل تنظیمات متناسب با نوع هر امکان را بررسی می‌کند.
13. مدیر تنظیمات امکان را تأیید و فعال می‌کند.
14. سامانه وضعیت بخش را بر اساس امکانات فعال یا انتخاب «ساختمان امکانات ندارد» به‌روزرسانی می‌کند.

مدل استفاده

هر امکان یکی از مدل‌های زیر را دارد:

• قابل رزرو
• استفاده آزاد
• درخواست و تأیید
• فقط اطلاع‌رسانی
• زیرساخت یا تجهیز غیررزروی

گروه‌های مجاز

• مالکان
• مستأجران
• ساکنان
• اعضای خانواده
• کارکنان
• مهمانان
• گروه سفارشی

مدل قیمت‌گذاری

• رایگان
• مبلغ ثابت برای هر رزرو
• ساعتی
• بر اساس تعداد نفر
• ودیعه
• مدل سفارشی

قواعد رزرو و استفاده

برای هر امکان، در صورت ارتباط، این موارد تعریف می‌شوند:

• روزها و ساعت‌های قابل استفاده
• مدت رزرو
• ظرفیت
• حداقل زمان ثبت درخواست پیش از استفاده
• حداکثر افق رزرو
• حداکثر تعداد رزرو هر کاربر
• محدودیت رزرو هم‌زمان
• نیاز یا عدم نیاز به تأیید
• نقش تأییدکننده
• مهلت لغو
• قاعده بازپرداخت
• جریمه لغو دیرهنگام
• قاعده عدم مراجعه
• محدودیت سنی
• تعداد مهمان
• نیاز به Membership فعال
• محدودیت بدهی، در صورت انتخاب مدیر
• مدارک لازم
• روزها یا بازه‌های مسدود
• محل دقیق یا طبقه
• مسئول بهره‌برداری یا نگهداری
• برنامه سرویس دوره‌ای برای زیرساخت‌ها
• وضعیت فعال، خارج از سرویس یا نیازمند تعمیر

قواعد فعال‌سازی

• امکان جدید ابتدا Draft است.
• امکان تا تکمیل حداقل تنظیمات و تأیید مدیر فعال نمی‌شود.
• هر امکان تنظیمات مستقل دارد.
• انتخاب یک امکان هیچ Role یا Permissionی را خودکار به فردی تخصیص نمی‌دهد.
• تعیین مدیر یا تأییدکننده فقط Role پیشنهادی را مشخص می‌کند و فعال‌سازی شخص تابع Membership و Permission معتبر است.
• جزئیات رزرو، پرداخت، تداخل زمانی و چرخه عمر Reservation در ماژول مرجع رزرو امکانات تعریف می‌شوند.

ساختمان بدون امکانات

مدیر می‌تواند «ساختمان امکانات ندارد» را انتخاب کند. در این حالت بخش تکمیل‌شده محسوب می‌شود و ماژول رزرو فعال نمی‌شود. مدیر می‌تواند بعداً این تصمیم را تغییر دهد.

اطلاعات تکمیلی ساختمان

اطلاعاتی مانند آدرس و راه ارتباطی می‌توانند از این بخش به تنظیمات عمومی ساختمان هدایت شوند، اما تکمیل آن‌ها شرط فعال‌شدن امکانات یا تکمیل Setup Dashboard نیست.

معیار تکمیل بخش

بخش زمانی تکمیل‌شده محسوب می‌شود که:

• گزینه «ساختمان امکانات ندارد» انتخاب شده باشد؛
• یا همه امکانات انتخاب‌شده دارای حداقل تنظیمات معتبر و وضعیت فعال باشند.

وجود Facility در وضعیت Draft، بخش را «در حال تکمیل» نگه می‌دارد.

خطاها و بازیابی

شناسه	خطا	رفتار سیستم	بازیابی
ERR-SET-36	مدل استفاده امکان مشخص نشده است	امکان فعال نمی‌شود	انتخاب مدل استفاده
ERR-SET-37	گروه مجاز، قیمت یا محدودیت الزامی ناقص است	امکان در وضعیت Draft باقی می‌ماند	تکمیل تنظیمات
ERR-SET-38	تأییدکننده انتخاب‌شده دسترسی معتبر ندارد	مسیر تأیید فعال نمی‌شود	انتخاب Role یا شخص دارای دسترسی
ERR-SET-39	ذخیره یا فعال‌سازی امکان ناموفق است	تنظیمات قبلی حفظ و امکان فعال نمی‌شود	تلاش مجدد

نتیجه نهایی SET-06E

• نبود امکانات ثبت شده یا امکانات ساختمان با قواعد مستقل تعریف شده‌اند.
• هر امکان فعال دارای مدل استفاده، گروه مجاز، قیمت، زمان‌بندی و محدودیت معتبر است.
• امکانات ناقص در وضعیت Draft باقی مانده‌اند.
• هیچ Role یا Permissionی صرفاً با تعریف Facility فعال نشده است.
• Setup Dashboard وضعیت نهایی بخش امکانات را نمایش می‌دهد.

۱۴. سناریوی MEM-01 — ایجاد و ارسال دعوت‌نامه فردی و گروهی

هدف

مدیر مجاز بتواند برای اشخاص ثبت‌شده، یک Invitation Envelope شامل یک یا چند Role ایجاد و ارسال کند. ثبت عملیاتی ساکن به پذیرش دعوت وابسته نیست، اما Roleهای حساس تا پذیرش صریح فعال نمی‌شوند.

بازیگران

• مدیر راه‌اندازی ساختمان
• مدیر ساختمان یا کاربر دارای Permission دعوت
• شخص دعوت‌شده
• سامانه تریپیلون
• سرویس پیامک

نقاط شروع

ارسال دعوت می‌تواند از این نقاط آغاز شود:

• Action فردی یا گروهی داخل «لیست واحدها»
• بخش «افراد و نقش‌ها» در جزئیات یک واحد
• ردیف شخص در فهرست تیم مدیریت و هیئت‌مدیره
• ردیف موقعیت یا شخص در فهرست کارکنان
• نتیجه Import فایل Excel با بازگشت به لیست واحدها

تصمیم ناوبری

ماژول صفحه یا «مرکز دعوت‌ها»ی مستقل ندارد. وضعیت Invitation در Context همان شخص، واحد، Role مدیریتی یا موقعیت شغلی نمایش داده و مدیریت می‌شود.

پیش‌شرط‌ها

• ساختمان فعال است.
• ارسال‌کننده Permission معتبر دعوت در Scope ساختمان دارد.
• شخص دارای رکورد و شماره موبایل معتبر است.
• Role Template و Scope پیشنهادی معتبر هستند.
• برای ارسال پیامک، موجودی پنل پیامکی کافی است.

مسیر اصلی ارسال گروهی

1. مدیر لیست واحدها، جزئیات یک واحد، فهرست تیم مدیریت یا فهرست کارکنان را باز می‌کند.
2. مدیر یک یا چند شخص را انتخاب می‌کند.
3. مدیر اقدام «ارسال دعوت‌نامه گروهی» را انتخاب می‌کند.
4. سامانه برای هر شخص، روابط عملیاتی، Roleهای پیشنهادی و Scope را نمایش می‌دهد.
5. مدیر می‌تواند برای یک شخص چند Role را در یک Invitation Envelope قرار دهد.
6. سامانه مشخص می‌کند کدام Roleها نیازمند پذیرش هستند.
7. سامانه تعداد پیامک‌ها، هزینه ارسال و موجودی پنل پیامکی را نمایش می‌دهد.
8. مدیر فهرست نهایی و هزینه را تأیید می‌کند.
9. سامانه برای هر شخص و ساختمان یک Invitation Envelope یکتا ایجاد یا Envelope در انتظار موجود را به‌روزرسانی می‌کند.
10. سامانه پیامک‌ها را ارسال و نتیجه تحویل هر گیرنده را جداگانه ثبت می‌کند.
11. ارسال‌های موفق حفظ و موارد ناموفق برای Retry مشخص می‌شوند.

قواعد رکورد ساکن و دسترسی

• ثبت مالک، مستأجر، ساکن یا عضو خانواده به پذیرش Invitation وابسته نیست.
• شخص ثبت‌شده حتی بدون ورود به اپ در فهرست ساختمان باقی می‌ماند.
• Charge، Bill و اعلان پیامکی می‌توانند برای او ایجاد یا ارسال شوند.
• نبود Account Link مانع عضویت عملیاتی شخص در ساختمان نیست.
• Permission اپ تا اتصال Account و فعال‌شدن Role معتبر اعمال نمی‌شود.

Roleهای نیازمند پذیرش

Roleهای حساس و دسترسی‌دار، از جمله موارد زیر، تا پذیرش صریح فعال نمی‌شوند:

• مدیر ساختمان
• رئیس یا عضو هیئت‌مدیره
• خزانه‌دار
• بازرس
• حسابدار
• کارکنان عملیاتی
• سایر Roleهای دارای Permission

این Roleها داخل Invitation Envelope با وضعیت PENDING_ACCEPTANCE نگهداری می‌شوند.

دعوت ساکن عادی

• برای رابطه عادی مالک، مستأجر، ساکن یا عضو خانواده، پذیرش یا رد شرط ثبت عضویت عملیاتی نیست.
• پیامک نقش اطلاع‌رسانی و مسیر ورود به تریپیلون را دارد.
• شخص هر زمان با شماره موبایل و OTP وارد شود، Account او به Person Record و Membership موجود متصل می‌شود.
• رد یا نادیده‌گرفتن مسیر ورود، رکورد سکونت، Charge، Bill یا اعلان‌های پیامکی را حذف نمی‌کند.

دعوت چند Role

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

بدون انقضای کسب‌وکاری

• Invitation Envelope تاریخ انقضای کسب‌وکاری ندارد.
• Envelope تا زمان اتصال حساب، پذیرش، رد Role حساس یا لغو توسط مدیر قابل پیگیری است.
• لینک پیامک نباید Token دائمی دسترسی باشد.
• بازکردن لینک در هر زمان نیازمند تأیید شماره موبایل با OTP و بررسی معتبرماندن Envelope است.
• مدیر می‌تواند Envelope استفاده‌نشده را لغو کند.

موجودی پیامک و ارسال ناموفق

• اگر موجودی پنل پیامکی کافی نباشد، Envelopeها در Draft باقی می‌مانند و ارسال آغاز نمی‌شود.
• پس از افزایش موجودی، مدیر می‌تواند همان Batch را ارسال کند.
• در ارسال گروهی، موفقیت یا شکست هر گیرنده مستقل ثبت می‌شود.
• موفقیت بخشی از Batch Rollback نمی‌شود.
• فقط ارسال‌های ناموفق Retry می‌شوند.
• Retry نباید Invitation Envelope تکراری ایجاد کند.

جلوگیری از تکرار

• برای یک شخص، ساختمان و مجموعه Role یک Envelope در انتظار تکراری ساخته نمی‌شود.
• Resend از Envelope موجود استفاده می‌کند.
• تغییر Roleهای پیشنهادی، نسخه Envelope در انتظار را به‌روزرسانی و Audit می‌کند.
• Account جدید برای شماره موبایلی که Account موجود دارد ساخته نمی‌شود.

وضعیت‌های ارسال

• DRAFT
• READY_TO_SEND
• SENT
• PARTIALLY_FAILED
• DELIVERY_FAILED
• PENDING_ACCEPTANCE
• ACCEPTED
• REJECTED
• CANCELED

وضعیت Delivery پیامک از وضعیت پذیرش Role جدا نگهداری می‌شود.

خطاها و بازیابی

شناسه	خطا	رفتار سیستم	بازیابی
ERR-MEM-01	شماره موبایل موجود یا معتبر نیست	شخص وارد Batch ارسال نمی‌شود	تکمیل یا اصلاح شماره
ERR-MEM-02	موجودی پنل پیامکی کافی نیست	هیچ پیامکی از Batch ارسال نمی‌شود	افزایش موجودی و ارسال همان Batch
ERR-MEM-03	Role یا Scope معتبر نیست	Envelope مربوط ساخته یا ارسال نمی‌شود	اصلاح Role یا Scope
ERR-MEM-04	ارسال برخی پیامک‌ها ناموفق است	ارسال‌های موفق حفظ می‌شوند	Retry فقط برای موارد ناموفق
ERR-MEM-05	Envelope در انتظار تکراری است	Envelope جدید ساخته نمی‌شود	استفاده، ویرایش یا Resend Envelope موجود
ERR-MEM-06	مدیر Envelope را پیش از استفاده لغو کرده است	اتصال یا پذیرش از طریق آن مجاز نیست	ایجاد Envelope جدید توسط مدیر

نتیجه نهایی

• Invitation Envelopeهای یکتا با یک یا چند Role ایجاد شده‌اند.
• ارسال‌های موفق و ناموفق به‌صورت مستقل ثبت شده‌اند.
• رکورد و Membership عملیاتی ساکنان به پذیرش دعوت وابسته نیست.
• Roleهای حساس تا پذیرش در وضعیت Pending باقی مانده‌اند.
• Account Link فقط پس از OTP ایجاد می‌شود.
• Invitation انقضای کسب‌وکاری ندارد، اما دسترسی از لینک همواره با OTP کنترل می‌شود.

۱۵. سناریوی MEM-02 — اتصال حساب و تصمیم درباره Roleهای دعوت‌شده

هدف

شخصی که شماره موبایل او از قبل در تریپیلون شناخته شده است، با OTP هویت خود را تأیید می‌کند، Account موجود را به Person Record و Membership متصل می‌کند و درباره Roleهای نیازمند پذیرش تصمیم می‌گیرد. این سناریو Account جدید ایجاد نمی‌کند.

بازیگران

• شخص دعوت‌شده
• سامانه تریپیلون
• سرویس OTP

نقطه شروع

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

پیش‌شرط‌ها

• شماره موبایل با Account موجود، Person Record یا Invitation Envelope معتبر در تریپیلون شناخته شده است.
• Invitation لغو نشده است.
• برای Roleهای حساس، وضعیت PENDING_ACCEPTANCE وجود دارد.

مسیر اصلی

1. شخص شماره موبایل خود را وارد می‌کند.
2. سامانه OTP را ارسال می‌کند.
3. شخص OTP معتبر را وارد می‌کند.
4. سامانه Account یا شناسه دیجیتال از قبل موجود را پیدا می‌کند.
5. سامانه Account موجود را به Person Record و Membershipهای منطبق متصل می‌کند.
6. سامانه Invitation Envelope و Roleهای پیشنهادی را بارگذاری می‌کند.
7. سامانه نام ساختمان، Role، Scope و خلاصه دسترسی هر Role حساس را نمایش می‌دهد.
8. شخص برای هر Role حساس به‌صورت مستقل «پذیرش» یا «رد» را انتخاب می‌کند.
9. سامانه Roleهای پذیرفته‌شده را فعال و Permissionهای مرتبط را در Scope معتبر اعمال می‌کند.
10. سامانه Roleهای ردشده را بدون Permission فعال ثبت می‌کند.
11. سامانه Building Membership عملیاتی و Unit Relationship شخص را بدون تغییر حفظ می‌کند.
12. سامانه Current Context معتبر را انتخاب و شخص را وارد تریپیلون می‌کند.

ممنوعیت ایجاد Account در ورود

• این سناریو Account جدید ایجاد نمی‌کند.
• موبایل باید پیش از ورود با یک رکورد معتبر در سیستم شناخته شده باشد.
• OTP فقط هویت موجود را تأیید و Account Link را فعال می‌کند.
• اگر شماره موبایل هیچ Account، Person Record، Membership یا Invitation معتبری نداشته باشد، MEM-02 ادامه نمی‌یابد و کاربر به مسیریابی SET-01 هدایت می‌شود.

شخص دارای رابطه عادی

اگر شخص فقط مالک، مستأجر، ساکن یا عضو خانواده باشد:

• صفحه پذیرش یا رد عضویت نمایش داده نمی‌شود.
• پس از OTP، Account موجود به رکورد و Membership عملیاتی متصل می‌شود.
• ساختمان در Contextهای قابل دسترس شخص نمایش داده می‌شود.
• نادیده‌گرفتن پیامک قبلی مانع اتصال در مراجعه بعدی نیست.

تصمیم مستقل برای هر Role

• یک Invitation Envelope می‌تواند چند Role داشته باشد.
• شخص می‌تواند هر Role را جداگانه بپذیرد یا رد کند.
• برای نمونه، شخص می‌تواند Role عضو هیئت‌مدیره را بپذیرد و Role خزانه‌دار را رد کند.
• پذیرش یک Role باعث پذیرش خودکار Roleهای دیگر نمی‌شود.
• رد یک Role، Roleهای پذیرفته‌شده دیگر را غیرفعال نمی‌کند.

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

شخص می‌تواند گزینه «این ساختمان یا واحد متعلق به من نیست» را انتخاب کند.

در این حالت:

1. Account Link مورد اختلاف فعال نمی‌شود.
2. Contact Point در وضعیت DISPUTED قرار می‌گیرد.
3. ارسال پیامک‌های حساس به شماره مورد اختلاف متوقف می‌شود.
4. مدیر برای بررسی و اصلاح Person Record، Unit Relationship یا شماره موبایل مطلع می‌شود.
5. Bill یا سابقه مالی واحد حذف نمی‌شود، اما تا رفع اختلاف به شماره اشتباه ارسال نمی‌شود.
6. هیچ Role یا Permissionی برای رابطه مورد اختلاف فعال نمی‌شود.

Invitation لغوشده

اگر مدیر Invitation Envelope را لغو کرده باشد:

• Roleهای Pending از آن Envelope فعال نمی‌شوند.
• سامانه وضعیت لغو را نمایش می‌دهد.
• شخص برای دریافت Role نیازمند Invitation جدید است.
• Building Membership عملیاتی موجود فقط به‌دلیل لغو Invitation حذف نمی‌شود.

خطاها و بازیابی

شناسه	خطا	رفتار سیستم	بازیابی
ERR-MEM-07	شماره موبایل در هیچ رکوردی شناخته نشده است	Account جدید ساخته نمی‌شود و MEM-02 ادامه نمی‌یابد	هدایت به SET-01
ERR-MEM-08	OTP نامعتبر یا منقضی است	Account Link و Role Activation انجام نمی‌شوند	ورود مجدد OTP یا ارسال دوباره
ERR-MEM-09	Invitation لغو شده است	Roleهای Pending فعال نمی‌شوند	دریافت Invitation جدید
ERR-MEM-10	Role یا Scope پس از ارسال نامعتبر شده است	همان Role فعال نمی‌شود	بررسی و ارسال مجدد توسط مدیر
ERR-MEM-11	شخص تعلق ساختمان یا واحد را رد می‌کند	Contact Point مورد اختلاف و دسترسی متوقف می‌شوند	بررسی و اصلاح توسط مدیر
ERR-MEM-12	ذخیره بخشی از تصمیم‌های چند Role ناموفق است	تصمیم ناقص نهایی نمی‌شود	تلاش مجدد بدون Role Assignment تکراری

نتیجه نهایی

• Account جدیدی ایجاد نشده است.
• Account موجود پس از OTP به رکوردهای معتبر متصل شده است.
• Roleهای حساس به‌صورت مستقل پذیرفته یا رد شده‌اند.
• فقط Roleهای پذیرفته‌شده Permission فعال دریافت کرده‌اند.
• Building Membership و Unit Relationship عملیاتی با رد Role حذف نشده‌اند.
• رابطه اشتباه می‌تواند بدون حذف سابقه مالی در وضعیت Disputed قرار گیرد.

۱۶. سناریوی MEM-03 — ارسال مجدد یا لغو Invitation

هدف

مدیر مجاز بتواند Invitation استفاده‌نشده را بدون ایجاد Envelope تکراری مجدداً ارسال، پیش از ارسال ویرایش یا لغو کند.

بازیگران

• مدیر راه‌اندازی ساختمان
• مدیر ساختمان یا کاربر دارای Permission دعوت
• سامانه تریپیلون
• سرویس پیامک

پیش‌شرط‌ها

• Invitation Envelope موجود است.
• ارسال‌کننده Permission معتبر مدیریت Invitation دارد.
• Envelope در وضعیت قابل Resend، Edit یا Cancel است.

مسیر اصلی Resend

1. مدیر لیست واحدها یا فهرست Role مرتبط را باز می‌کند.
2. مدیر یک یا چند شخص با وضعیت دعوت «در انتظار» یا «ارسال ناموفق» را انتخاب می‌کند.
3. مدیر اقدام Resend را انتخاب می‌کند.
4. سامانه زمان آخرین ارسال، وضعیت Roleها و معتبرماندن Envelope را بررسی می‌کند.
5. سامانه هزینه پیامک و موجودی پنل پیامکی را نمایش می‌دهد.
6. مدیر Resend را تأیید می‌کند.
7. سامانه روی همان Envelope یک Delivery Attempt جدید ثبت می‌کند.
8. سامانه پیامک را ارسال و نتیجه هر گیرنده را مستقل ثبت می‌کند.
9. فقط موارد ناموفق برای Retry بعدی باقی می‌مانند.

قواعد Resend

• Resend Envelope یا Role Assignment جدید ایجاد نمی‌کند.
• Resend فقط Reminder و Delivery Attempt جدید است.
• Resend فردی و گروهی مجاز است.
• Resend خودکار در نسخه فعلی وجود ندارد.
• حداقل فاصله میان دو ارسال برای یک شخص و Envelope، ۲۴ ساعت است.
• Invitation به‌دلیل گذشت زمان منقضی نمی‌شود.
• موجودی و هزینه SMS پیش از هر Resend بررسی می‌شوند.

ویرایش پیش از Resend

• مدیر می‌تواند Role یا Scope در وضعیت Pending را پیش از Resend اصلاح کند.
• تغییر روی همان Envelope ثبت و نسخه‌بندی می‌شود.
• تغییر Role یا Scope باید Audit شود.
• پس از تغییر، مدیر می‌تواند پیامک جدید ارسال کند.
• Role فعال از مسیر Edit Invitation تغییر یا حذف نمی‌شود.

مسیر اصلی Cancel

1. مدیر Envelope در انتظار را انتخاب می‌کند.
2. مدیر اقدام Cancel را انتخاب می‌کند.
3. سامانه Roleهای Pending و اثر لغو را نمایش می‌دهد.
4. اگر Invitation مربوط به مدیر، هیئت‌مدیره، حسابدار یا کارکنان باشد، مدیر دلیل لغو را وارد می‌کند.
5. مدیر لغو را تأیید می‌کند.
6. سامانه Envelope را CANCELED و Roleهای Pending آن را غیرقابل پذیرش می‌کند.
7. سامانه اقدام، دلیل و Actor را در Audit Trail ثبت می‌کند.

اثر Cancel

• Cancel، Building Membership عملیاتی را حذف نمی‌کند.
• Cancel، Unit Relationship، Charge، Bill یا سابقه شخص را حذف نمی‌کند.
• Cancel فقط پذیرش Roleهای Pending همان Envelope را متوقف می‌کند.
• Roleی که پیش از Cancel فعال شده است غیرفعال نمی‌شود.
• حذف یا غیرفعال‌سازی Role فعال از مسیر MEM-04 انجام می‌شود.
• بازکردن لینک Envelope لغوشده پس از OTP فقط وضعیت لغو را نمایش می‌دهد.

دلیل لغو

• برای Roleهای مدیریتی، هیئت‌مدیره، مالی و کارکنان، دلیل لغو الزامی است.
• برای دعوت دسترسی ساده ساکن، دلیل لغو اختیاری است.
• دلیل لغو در Audit نگهداری می‌شود و برای کاربران غیرمجاز نمایش داده نمی‌شود.

خطاها و بازیابی

شناسه	خطا	رفتار سیستم	بازیابی
ERR-MEM-13	از آخرین ارسال کمتر از ۲۴ ساعت گذشته است	Resend انجام نمی‌شود	انتظار تا پایان محدودیت
ERR-MEM-14	موجودی پیامک کافی نیست	Delivery Attempt آغاز نمی‌شود	افزایش موجودی و تلاش مجدد
ERR-MEM-15	Envelope لغو یا نامعتبر شده است	Resend یا Edit انجام نمی‌شود	ایجاد Invitation جدید در صورت مجازبودن
ERR-MEM-16	لغو Role حساس بدون دلیل است	Cancel ثبت نمی‌شود	ثبت دلیل و تأیید مجدد
ERR-MEM-17	Resend گروهی بخشی ناموفق است	ارسال‌های موفق حفظ می‌شوند	Retry فقط موارد ناموفق

نتیجه نهایی

• Invitation موجود بدون ایجاد Envelope تکراری Resend شده است؛
• یا Envelope Pending با حفظ Membership و سوابق عملیاتی لغو شده است؛
• محدودیت ۲۴ ساعته و هزینه SMS رعایت شده‌اند؛
• تغییرات، ارسال‌ها و لغوها در Audit ثبت شده‌اند.

۱۷. سناریوی MEM-04 — پایان، آرشیو و جایگزینی رابطه یا Role

هدف

مدیر مجاز بتواند رابطه مستأجر، مالک، ساکن، کارکن یا سرویس‌کار را بدون حذف تاریخچه پایان دهد و در صورت نیاز شخص جدید را با Effective Date جایگزین کند.

نقطه شروع در رابط

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

اصل مدل

• Person و Account حذف نمی‌شوند.
• رکورد قبلی با End Date آرشیو می‌شود.
• رابطه یا Role جدید به‌صورت رکورد مستقل ساخته می‌شود.
• Replacement به معنی ویرایش Person قبلی و تبدیل او به Person جدید نیست.
• History، Bill، Payment، Audit و Documentها حفظ می‌شوند.

جایگزینی مستأجر

1. مدیر مستأجر فعلی واحد را انتخاب می‌کند.
2. سامانه Tenant Household، بدهی واحد، دسترسی‌ها و پرونده‌های باز را نمایش می‌دهد.
3. مدیر Effective End Date را مشخص می‌کند.
4. سامانه مستأجر و اعضای خانواده وابسته به همان Household را با هم آرشیو می‌کند.
5. Role Assignmentها و دسترسی‌های وابسته به Scope واحد در Effective Date غیرفعال می‌شوند.
6. اگر بدهی واحد تسویه نشده باشد، مانده روی Unit Ledger حفظ و مسئولیت پرداخت به مالک جاری منتقل می‌شود.
7. مدیر مستأجر جدید و Effective Start Date را ثبت می‌کند.
8. سامانه Tenant Relationship و Household جدید ایجاد می‌کند.
9. Invitation در زمان انتخابی مدیر و از مسیر MEM-01 ارسال می‌شود.

قواعد Household مستأجر

• اعضای خانواده وابسته به Tenant Household همراه با مستأجر آرشیو می‌شوند.
• این آرشیو گروهی نیازمند انتخاب جداگانه هر عضو نیست.
• اگر یکی از اعضا رابطه مستقل دیگری مانند مالکیت همان یا واحد دیگر داشته باشد، فقط رابطه وابسته به Household پایان می‌یابد.
• پایان Household، Account سراسری افراد را غیرفعال نمی‌کند.

بدهی هنگام خروج مستأجر

• Debt متعلق به Unit Ledger است، نه Person.
• مستأجر باید پیش از خروج بدهی واحد را تسویه کند.
• اگر بدهی تسویه نشود، مانده از Unit Ledger حذف نمی‌شود.
• پس از پایان رابطه مستأجر، مالک جاری مسئول پرداخت مانده واحد است.
• سابقه نشان می‌دهد بدهی در چه دوره‌ای و هنگام حضور چه مستأجری ایجاد شده است.
• انتقال مسئولیت پرداخت، تاریخچه ایجاد Charge یا پرداخت‌کنندگان قبلی را بازنویسی نمی‌کند.

جایگزینی مالک

1. مدیر مالک فعلی و واحد را انتخاب می‌کند.
2. سامانه Unit Ledger، مانده بدهی و صورت بدهی واحد را نمایش می‌دهد.
3. در Flow عادی، مالک یا خریدار پیش از معامله صورت بدهی یا تسویه را از ساختمان دریافت می‌کند.
4. مدیر مدرک یا Reference انتقال و Effective Transfer Date را ثبت می‌کند.
5. سامانه Ownership Relationship مالک قبلی را آرشیو می‌کند.
6. سامانه Ownership Relationship مالک جدید را ایجاد می‌کند.
7. مانده بدهی Unit Ledger حذف یا به Person قبلی قفل نمی‌شود.
8. مالک جاری پس از انتقال مسئول مانده بدهی واحد است.
9. دسترسی مالک قبلی در Scope مالکیت همان واحد غیرفعال و دسترسی مالک جدید پس از قواعد عضویت فعال می‌شود.

انتقال مالکیت کشف‌شده با تأخیر

اگر انتقال مالکیت بدون اطلاع مدیر انجام شده باشد:

• مدیر می‌تواند انتقال را با Effective Date واقعی و مدرک موجود ثبت کند.
• تاریخچه مالک قبلی و جدید حفظ می‌شود.
• مانده بدهی روی Unit Ledger باقی می‌ماند.
• مالک جاری ثبت‌شده مسئول پرداخت مانده است.
• ثبت دیرهنگام و Actor تغییر در Audit Trail مشخص می‌شوند.

Warning

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

جایگزینی کارکن یا سرویس‌کار

1. مدیر Role Assignment و Scope فرد فعلی را انتخاب می‌کند.
2. سامانه Shift، Task، Facility Approval و Assignmentهای باز را نمایش می‌دهد.
3. مدیر برای هر مورد باز، Reassign یا Close را انتخاب می‌کند.
4. تا تعیین تکلیف همه موارد باز، جایگزینی نهایی نمی‌شود.
5. Role Assignment فرد قبلی با Effective End Date غیرفعال می‌شود.
6. Role Assignment یا Invitation فرد جدید ایجاد می‌شود.
7. Permissionهای فرد قبلی فقط در Scope پایان‌یافته حذف می‌شوند.
8. Account و Roleهای او در ساختمان‌ها یا Scopeهای دیگر فعال می‌مانند.

قواعد جایگزینی

• Old Relationship و New Relationship نباید در بازه نامعتبر با هم تداخل داشته باشند.
• عملیات Close Old و Create New باید اتمیک یا قابل بازیابی باشد.
• Effective Date برای هر پایان یا جایگزینی الزامی است.
• Notification و Chargeهای آینده از رابطه معتبر در تاریخ مربوط استفاده می‌کنند.
• Bill و Payment قبلی حذف یا بی‌صدا بازنویسی نمی‌شوند.
• Current Context شخص قبلی پس از پایان آخرین Scope معتبر اصلاح می‌شود.

مسیرهای جایگزین

ALT-MEM-04A — پایان رابطه بدون جایگزین

مدیر رابطه فعلی را با End Date آرشیو می‌کند. واحد یا موقعیت می‌تواند تا ثبت شخص جدید در وضعیت خالی یا بدون متصدی باقی بماند.

ALT-MEM-04B — جایگزینی با شخص دارای Account

سامانه Person و Account موجود را بازیابی و رابطه یا Role جدید را بدون ساخت Account تکراری ایجاد می‌کند.

ALT-MEM-04C — جایگزینی با شخص بدون دسترسی فعال

رکورد و رابطه جدید ثبت می‌شوند، اما Role حساس تا Invitation و پذیرش در وضعیت Pending باقی می‌ماند.

خطاها و بازیابی

شناسه	خطا	رفتار سیستم	بازیابی
ERR-MEM-18	Effective Date وارد نشده یا نامعتبر است	پایان یا جایگزینی ثبت نمی‌شود	اصلاح تاریخ
ERR-MEM-19	Household مستأجر ناقص تعیین شده است	آرشیو گروهی نهایی نمی‌شود	بازبینی اعضای وابسته
ERR-MEM-20	Ownership Relationship جدید با رابطه موجود تداخل دارد	انتقال ثبت نمی‌شود	اصلاح تاریخ یا مالک جاری
ERR-MEM-21	Task یا Shift فعال کارکن تعیین تکلیف نشده است	جایگزینی نهایی نمی‌شود	Reassign یا Close موارد باز
ERR-MEM-22	Close Old انجام شده اما Create New ناموفق است	عملیات ناقص نهایی نمی‌شود	Rollback یا Retry امن

نتیجه نهایی

• رابطه یا Role قبلی با تاریخچه کامل آرشیو شده است.
• رابطه یا Role جدید بدون بازنویسی Person قبلی ایجاد شده است.
• Tenant Household وابسته به‌صورت گروهی پایان یافته است.
• Debt روی Unit Ledger حفظ و مسئولیت آن طبق رابطه جاری تعیین شده است.
• Task و Shiftهای کارکن پیش از جایگزینی تعیین تکلیف شده‌اند.
• Account و Scopeهای نامرتبط افراد حفظ شده‌اند.

۱۸. سناریوی MEM-05 — تغییر مدیر راه‌اندازی از طریق Support Ticket

تصمیم محصول

تغییر مدیر راه‌اندازی در نسخه فعلی قابلیت Self-service نیست. این تغییر یک استثنای کم‌تکرار و پرریسک است و فقط از طریق Support Ticket، بررسی دستی و اقدام ادمین پلتفرم انجام می‌شود.

بازیگران

• درخواست‌کننده تغییر
• مدیر راه‌اندازی فعلی
• مدیر راه‌اندازی پیشنهادی
• ادمین پلتفرم یا تیم پشتیبانی مجاز
• سامانه تریپیلون

نقطه شروع

شخص مجاز از داخل ساختمان یا کانال پشتیبانی، Ticket با موضوع «تغییر مدیر راه‌اندازی ساختمان» ثبت می‌کند.

اطلاعات و مدارک Ticket

• ساختمان
• مشخصات درخواست‌کننده
• مدیر راه‌اندازی فعلی
• شخص پیشنهادی جدید و شماره موبایل او
• دلیل تغییر
• صورت‌جلسه یا تعهدنامه امضاشده هیئت‌مدیره
• تأییدیه مالکان، در صورت وجود
• مدارک تکمیلی موردنیاز پشتیبانی

مسیر اصلی

1. درخواست‌کننده Support Ticket را ثبت و مدارک را بارگذاری می‌کند.
2. سامانه Ticket را با وضعیت OPEN ثبت می‌کند.
3. ادمین پلتفرم هویت درخواست‌کننده، ساختمان و کامل‌بودن مدارک را بررسی می‌کند.
4. در صورت نقص، Ticket به وضعیت NEEDS_INFO می‌رود.
5. پس از تکمیل، Ticket در وضعیت UNDER_REVIEW قرار می‌گیرد.
6. ادمین پلتفرم حمایت هیئت‌مدیره و مالکان ثبت‌شده را بررسی می‌کند.
7. در صورت تأیید، Ticket به وضعیت APPROVED می‌رود.
8. سامانه Role مدیر راه‌اندازی را برای شخص جدید در وضعیت PENDING_ACCEPTANCE ایجاد می‌کند.
9. شخص پیشنهادی با OTP وارد و Role را می‌پذیرد.
10. سامانه به‌صورت اتمیک Role مدیر فعلی را سلب و Role مدیر جدید را فعال می‌کند.
11. سامانه Ticket را COMPLETED و نتیجه را در Audit Trail ثبت می‌کند.

قواعد بررسی

• تأیید مدیر راه‌اندازی فعلی شرط لازم تغییر نیست.
• درخواست باید دارای صورت‌جلسه یا تعهدنامه معتبر هیئت‌مدیره باشد.
• حمایت بیش از ۵۰٪ مالکان ثبت‌شده می‌تواند مبنای تصمیم باشد.
• هر مالک یکتا یک مالک محسوب می‌شود؛ تعداد واحد یا سهم مالکیت تعداد رأی را افزایش نمی‌دهد.
• در تعارض میان درخواست هیئت‌مدیره و درخواست دارای حمایت بیش از ۵۰٪ مالکان، درخواست مالکان اولویت دارد.
• بررسی اسناد و شمارش حمایت در نسخه فعلی دستی است.

فعال‌سازی مدیر جدید

• شخص جدید باید شماره موبایل شناخته‌شده و هویت تأییدشده با OTP داشته باشد.
• Role مدیر راه‌اندازی تا پذیرش صریح فعال نمی‌شود.
• پیش از پذیرش شخص جدید، Role فعلی در حالت عادی فعال باقی می‌ماند.
• پس از پذیرش، Revoke مدیر قبلی و Activate مدیر جدید باید اتمیک باشند.
• Roleهای دیگر مدیر قبلی مانند مالک، ساکن یا عضو هیئت‌مدیره خودکار حذف نمی‌شوند.

مسیر اضطراری

اگر خطر امنیتی، سوءاستفاده یا دسترسی غیرمجاز فوری وجود داشته باشد:

1. ادمین پلتفرم می‌تواند Role مدیر فعلی را موقتاً SUSPENDED کند.
2. دلیل، Actor و زمان Suspension باید Audit شوند.
3. ساختمان تا تعیین مدیر جدید در وضعیت مدیریت پشتیبانی‌شده قرار می‌گیرد.
4. Suspension اضطراری جایگزین بررسی مدارک و تصمیم نهایی نیست.

رد درخواست

• اگر مدارک، اختیار یا حمایت لازم تأیید نشوند، Ticket REJECTED می‌شود.
• دلیل رد ثبت می‌شود.
• Role مدیر فعلی بدون تغییر باقی می‌ماند، مگر Suspension اضطراری مستقل وجود داشته باشد.
• درخواست جدید با مدارک تازه قابل ثبت است.

وضعیت‌های Ticket

• OPEN
• NEEDS_INFO
• UNDER_REVIEW
• APPROVED
• REJECTED
• COMPLETED
• CANCELED

خطاها و بازیابی

شناسه	خطا	رفتار سیستم	بازیابی
ERR-MEM-23	مدارک Ticket ناقص هستند	بررسی نهایی انجام نمی‌شود	تکمیل مدارک
ERR-MEM-24	شخص پیشنهادی شماره موبایل معتبر یا شناخته‌شده ندارد	Role Pending ایجاد نمی‌شود	ثبت یا اصلاح شخص و شماره
ERR-MEM-25	مدیر جدید Role را نپذیرفته است	مدیر فعلی در حالت عادی حفظ می‌شود	یادآوری یا معرفی شخص جدید
ERR-MEM-26	Revoke و Activate اتمیک ناموفق است	تغییر نهایی ثبت نمی‌شود	Rollback و Retry امن
ERR-MEM-27	درخواست‌های متعارض وجود دارند	تصمیم خودکار گرفته نمی‌شود	بررسی دستی مدارک و حمایت مالکان

نتیجه نهایی

• Ticket با تصمیم و مدارک قابل Audit بسته شده است.
• در صورت تأیید و پذیرش، مدیر راه‌اندازی جدید بدون ایجاد خلأ دسترسی فعال شده است.
• Role مدیر قبلی سلب شده، اما Roleها و Membershipهای نامرتبط او حفظ شده‌اند.
• در صورت رد، ساختار دسترسی تغییر نکرده است.

Warning

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

۱۹. Audit و گزارش‌پذیری

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

تفکیک Audit از اثبات اختیار

گزارش فعالیت‌ها نشان می‌دهد چه کسی چه اقدامی انجام داده است، اما Self-Declaration به‌تنهایی اختیار حقوقی متقاضی را اثبات نمی‌کند. در اختلاف رسمی، صورت‌جلسه یا تعهدنامه امضاشده هیئت‌مدیره و تأییدیه بیش از ۵۰٪ مالکان ثبت‌شده، مبنای بررسی ادمین پلتفرم است.

نیازمند بررسی حقوقی

قاعده «هر مالک یک رأی و اولویت بیش از ۵۰٪ مالکان» یک تصمیم محصولی است و پیش از اجرا باید با قوانین و اسناد حاکم بر ساختمان تطبیق داده شود؛ به‌ویژه برای مالکیت مشترک و مالکان حقوقی.

۲۰. سؤالات باز

شناسه	موضوع	وضعیت
OPEN-PRICE-01	مبلغ ثابت شارژ اولیه پنل پیامکی	تعیین نشده و باید پیش از پیاده‌سازی قیمت‌گذاری مشخص شود
OPEN-SUB-01	زمان و قواعد اصلاح ظرفیت اشتراک پس از ثبت واحدهای بیشتر از ظرفیت خریداری‌شده	خارج از SET-06A و نیازمند Flow مستقل تغییر اشتراک

بازگشت