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

جریان‌های کاربر

وضعیت سند

آماده بازبینی محصول — این سند از سناریوهای SET-01 تا SET-06 و MEM-01 تا MEM-05 استخراج شده است.

۱. هدف و مرزبندی

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

  • وضعیت‌های داخلی موجودیت‌ها در سند «گردش‌کارها و وضعیت‌ها» تعریف می‌شوند.
  • محل قابلیت‌ها در ناوبری، متعلق به Information Architecture است.
  • چیدمان و اجزای هر صفحه در سند «وایرفریم‌ها» تعریف می‌شوند.
  • جزئیات دسترسی هر نقش در سند «دسترسی‌ها» تعریف می‌شوند.
  • MEM-05 ذاتاً یک فرایند چندنقشی پشتیبانی است؛ در این سند تجربه قابل مشاهده درخواست‌کننده نمایش داده می‌شود و گردش‌کار داخلی Ticket باید جداگانه مدل شود.

۲. راهنمای خواندن نمودارها

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

۳. ماتریس پوشش سناریوها

شناسه Flow هدف کاربر بازیگر اصلی سناریوهای مرجع
OBM-UF-01 ایجاد و فعال‌سازی ساختمان متقاضی راه‌اندازی SET-01 تا SET-05
OBM-UF-02 مدیریت راه‌اندازی مرحله‌ای مدیر راه‌اندازی SET-06
OBM-UF-03 ثبت واحدها و ساکنان مدیر راه‌اندازی SET-06A
OBM-UF-04 تعیین تیم مدیریت مدیر راه‌اندازی SET-06B
OBM-UF-05 تعیین کارکنان و دسترسی پایه مدیر راه‌اندازی SET-06C
OBM-UF-06 آغاز تنظیمات مالی مدیر راه‌اندازی SET-06D
OBM-UF-06A ثبت و تأیید قبض واریز بانکی ساکن و مدیر مالی مجاز SET-06D
OBM-UF-07 راه‌اندازی امکانات ساکنان مدیر راه‌اندازی SET-06E
OBM-UF-07A ثبت اطلاعات تکمیلی و پایان Setup مدیر راه‌اندازی SET-06F
OBM-UF-08 ایجاد و ارسال دعوت از Context واحد یا Role مدیر مجاز MEM-01
OBM-UF-09 ورود و تصمیم درباره نقش‌ها شخص دعوت‌شده MEM-02
OBM-UF-10 مدیریت دعوت از ردیف شخص یا Role مدیر مجاز MEM-03
OBM-UF-11 پایان یا جایگزینی رابطه از جزئیات واحد مدیر مجاز MEM-04
OBM-UF-12 درخواست تغییر مدیر راه‌اندازی درخواست‌کننده تغییر MEM-05

۴. نمای کلان ماژول

این نمودار ارتباط Flowها را نشان می‌دهد و جایگزین نمودارهای تفصیلی نیست.

flowchart LR accTitle: نمای کلان جریان‌های راه‌اندازی ساختمان و عضویت accDescr: مسیر از ورود متقاضی و خرید اشتراک تا تکمیل مرحله‌ای ساختمان، دعوت افراد و نگهداری عضویت‌ها START(["ورود با شماره موبایل"]):::start ROUTE{"عضویت یا دعوت معتبر دارد؟"}:::decision EXISTING["ورود به ساختمان یا مشاهده دعوت"]:::system PURCHASE["UF-01
ایجاد و فعال‌سازی ساختمان"]:::user SETUP["UF-02
راه‌اندازی مرحله‌ای"]:::user UNITS["UF-03
واحدها و ساکنان"]:::user GOVERNANCE["UF-04
تیم مدیریت"]:::user STAFF["UF-05
کارکنان"]:::user FINANCE["UF-06
تنظیمات مالی"]:::user FACILITIES["UF-07
امکانات"]:::user PROFILE["UF-07A
اطلاعات تکمیلی"]:::user INVITE["UF-08
دعوت در Context واحد یا Role"]:::user ACCEPT["UF-09
ورود و تصمیم نقش‌ها"]:::user MANAGE["UF-10
مدیریت دعوت از ردیف شخص"]:::user REPLACE["UF-11
تغییر رابطه در جزئیات واحد"]:::user SUPPORT["UF-12
تغییر مدیر با Ticket"]:::external READY(["ساختمان عملیاتی"]):::success START --> ROUTE ROUTE -->|"بله"| EXISTING ROUTE -->|"خیر؛ ثبت ساختمان"| PURCHASE PURCHASE --> SETUP SETUP --> UNITS & GOVERNANCE & STAFF & FINANCE & FACILITIES & PROFILE PROFILE --> READY UNITS --> INVITE GOVERNANCE --> INVITE STAFF --> INVITE INVITE --> ACCEPT INVITE -.-> MANAGE EXISTING --> REPLACE EXISTING -.-> SUPPORT UNITS & GOVERNANCE & STAFF & FINANCE & FACILITIES --> READY classDef start fill:#DBEAFE,stroke:#2563EB,color:#172554,stroke-width:2px; classDef user fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E; classDef system fill:#F3F4F6,stroke:#6B7280,color:#111827; classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:2px; classDef external fill:#F3E8FF,stroke:#9333EA,color:#581C87; classDef success fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:2px;

۵. OBM-UF-01 — ایجاد و فعال‌سازی ساختمان

شناسنامه

  • بازیگر اصلی: متقاضی راه‌اندازی
  • هدف: خرید اشتراک و ورود به ساختمان فعال
  • شروع: انتخاب ورود یا ثبت ساختمان
  • پیش‌شرط: دسترسی به شماره موبایل معتبر
  • پایان موفق: ساختمان فعال، اشتراک معتبر و نقش مدیر راه‌اندازی ایجاد شده است
  • پایان ناموفق پایدار: درخواست ذخیره شده، اما ساختمان تا پرداخت معتبر ایجاد نشده است
  • خارج از محدوده: آدرس و جزئیات ساختمان، کارکنان، هیئت‌مدیره و Permissionها
flowchart TD accTitle: ایجاد و فعال‌سازی ساختمان accDescr: مسیر متقاضی از ورود با شماره موبایل تا پرداخت، فعال‌سازی ساختمان و ورود به داشبورد راه‌اندازی START(["شروع"]):::start MOBILE["واردکردن شماره موبایل"]:::user OTP["ارسال و تأیید رمز یک‌بارمصرف"]:::system OTP_OK{"رمز یک‌بارمصرف معتبر است؟"}:::decision OTP_ERROR["نمایش خطا یا محدودیت ارسال"]:::error CHECK["بررسی عضویت‌ها و دعوت‌نامه‌های موجود"]:::system USER_STATE{"وضعیت کاربر چیست؟"}:::decision ACTIVE(["ورود به ساختمان فعال"]):::success INVITATION(["نمایش دعوت‌نامه در انتظار"]):::success WAITING(["نمایش وضعیت «منتظر دعوت»"]):::success NEW_BUILDING["انتخاب «ثبت ساختمان جدید»"]:::user BASE_INFO["ثبت نام ساختمان و تعداد انواع واحد"]:::user BASE_VALID{"اطلاعات معتبر و مجموع واحدها حداقل ۲ است؟"}:::decision BASE_ERROR["نمایش خطا در همان مرحله"]:::error PRICE["نمایش قیمت دوره‌های ۳ و ۱۲ ماهه"]:::system DETAILS["نمایش مبلغ هر واحد، تخفیف و شارژ اولیه پنل پیامک"]:::system PERIOD["انتخاب دوره اشتراک"]:::user CHANGED{"تعداد واحد یا تعرفه تغییر کرده است؟"}:::decision RECALCULATE["محاسبه و تأیید دوباره قیمت"]:::system FINAL_AMOUNT["نمایش مبلغ نهایی با مالیات و عوارض"]:::system PAY["تأیید پرداخت"]:::user GATEWAY["انجام پرداخت در درگاه"]:::external VERIFY["اعتبارسنجی مستقیم نتیجه پرداخت"]:::system RESULT{"نتیجه قطعی پرداخت چیست؟"}:::decision FAILED["حفظ درخواست و نمایش امکان تلاش مجدد"]:::error PENDING["نمایش صفحه «در حال بررسی پرداخت»"]:::system RECHECK["به‌روزرسانی وضعیت پرداخت"]:::system PROVISIONING["نمایش صفحه «در حال راه‌اندازی ساختمان»"]:::system CREATE["ایجاد ساختمان، اشتراک، عضویت و نقش مدیر راه‌اندازی"]:::system CREATED{"اجزای ضروری با موفقیت ایجاد شدند؟"}:::decision RECOVER["تلاش مجدد امن بدون دریافت وجه یا رکورد تکراری"]:::system DASHBOARD(["ورود به ساختمان و نمایش داشبورد راه‌اندازی"]):::success START --> MOBILE --> OTP --> OTP_OK OTP_OK -->|"خیر"| OTP_ERROR OTP_ERROR -.->|"تلاش مجدد"| MOBILE OTP_OK -->|"بله"| CHECK --> USER_STATE USER_STATE -->|"عضویت فعال"| ACTIVE USER_STATE -->|"دعوت‌نامه در انتظار"| INVITATION USER_STATE -->|"منتظر دعوت"| WAITING USER_STATE -->|"بدون عضویت یا دعوت"| NEW_BUILDING NEW_BUILDING --> BASE_INFO --> BASE_VALID BASE_VALID -->|"خیر"| BASE_ERROR BASE_ERROR -.->|"اصلاح اطلاعات"| BASE_INFO BASE_VALID -->|"بله"| PRICE --> DETAILS --> PERIOD --> CHANGED CHANGED -->|"بله"| RECALCULATE --> PRICE CHANGED -->|"خیر"| FINAL_AMOUNT --> PAY --> GATEWAY --> VERIFY --> RESULT RESULT -->|"لغو یا ناموفق"| FAILED FAILED -.->|"پرداخت دوباره"| FINAL_AMOUNT RESULT -->|"نامشخص"| PENDING --> RECHECK --> RESULT RESULT -->|"موفق و معتبر"| PROVISIONING --> CREATE --> CREATED CREATED -->|"خیر"| RECOVER --> CREATE CREATED -->|"بله"| DASHBOARD classDef start fill:#DBEAFE,stroke:#2563EB,color:#172554,stroke-width:2px; classDef user fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E; classDef system fill:#F3F4F6,stroke:#6B7280,color:#111827; classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:2px; classDef external fill:#F3E8FF,stroke:#9333EA,color:#581C87; classDef success fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:2px; classDef error fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D;

نقاط کنترل محصول

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

۶. OBM-UF-02 — مدیریت راه‌اندازی مرحله‌ای

شناسنامه

  • بازیگر اصلی: مدیر راه‌اندازی
  • هدف: تکمیل تدریجی اطلاعات لازم بدون Wizard اجباری
  • شروع: ورود به ساختمان تازه فعال‌شده
  • پایان موفق: هر پنج بخش حل شده‌اند
  • پایان قابل قبول: بخشی از کار ذخیره شده و مدیر بعداً ادامه می‌دهد
flowchart TD accTitle: تکمیل مرحله‌ای راه‌اندازی ساختمان accDescr: مدیر راه‌اندازی پنج بخش مستقل را به انتخاب خود تکمیل می‌کند و می‌تواند هر زمان ادامه دهد START(["ورود به صفحه اصلی ساختمان"]):::start DASHBOARD["نمایش پنج بخش، وضعیت و میزان پیشرفت"]:::system SELECT{"مدیر کدام بخش را انتخاب می‌کند؟"}:::decision UNITS["واحدها و ساکنان"]:::user MANAGEMENT["تیم ساختمان"]:::user FINANCE["تنظیمات مالی و شارژ"]:::user FACILITIES["امکانات ساکنان"]:::user PROFILE["اطلاعات تکمیلی"]:::user SAVE["ذخیره نتیجه معتبر بخش"]:::system UPDATE["به‌روزرسانی وضعیت و تعداد بخش‌های باقی‌مانده"]:::system ALL_DONE{"همه بخش‌ها حل شده‌اند؟"}:::decision CONTINUE{"مدیر اکنون ادامه می‌دهد؟"}:::decision LATER(["خروج و ادامه در زمان دلخواه"]):::success DONE(["راه‌اندازی مرحله‌ای کامل شده است"]):::success START --> DASHBOARD --> SELECT SELECT --> UNITS & MANAGEMENT & FINANCE & FACILITIES & PROFILE UNITS & MANAGEMENT & FINANCE & FACILITIES & PROFILE --> SAVE SAVE --> UPDATE --> ALL_DONE ALL_DONE -->|"بله"| DONE ALL_DONE -->|"خیر"| CONTINUE CONTINUE -->|"بله"| DASHBOARD CONTINUE -->|"خیر"| LATER LATER -.->|"مراجعه بعدی"| DASHBOARD classDef start fill:#DBEAFE,stroke:#2563EB,color:#172554,stroke-width:2px; classDef user fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E; classDef system fill:#F3F4F6,stroke:#6B7280,color:#111827; classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:2px; classDef success fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:2px;

نقاط کنترل محصول

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

۷. OBM-UF-03 — ثبت واحدها و ساکنان

شناسنامه

  • بازیگر اصلی: مدیر راه‌اندازی
  • هدف: ایجاد فهرست اولیه واحدها و روابط اشخاص
  • شروع: انتخاب بخش «واحدها و ساکنان»
  • پایان موفق: فهرست اولیه دستی یا Excel ثبت شده است
  • خارج از محدوده: ارسال دعوت‌نامه و اصلاح ظرفیت اشتراک
flowchart TD accTitle: ثبت واحدها و ساکنان accDescr: مدیر اطلاعات واحدها و روابط اشخاص را دستی یا با فایل اکسل ثبت می‌کند و در این مسیر دعوت‌نامه‌ای ارسال نمی‌شود START(["بازکردن بخش واحدها و ساکنان"]):::start METHOD{"روش ورود اطلاعات چیست؟"}:::decision UNIT["مرحله ۱: ثبت مشخصات اصلی واحد"]:::user UNIT_MORE["تکمیل اختیاری سایر مشخصات، قبض‌ها و حیوانات خانگی"]:::user UNIT_VALID{"مشخصات واحد معتبر است؟"}:::decision PEOPLE["مرحله ۲: مشاهده خلاصه واحد و افراد"]:::user ADD_PERSON["افزودن فرد و انتخاب رابطه"]:::user PERSON_RULES["ثبت سهم مالکیت یا سکونت هم‌زمان در صورت نیاز"]:::user PERSON_MORE["تکمیل اختیاری اطلاعات شخص حقیقی یا حقوقی"]:::user MORE_PERSON{"فرد دیگری اضافه می‌شود؟"}:::decision MANUAL_VALID{"اطلاعات دو مرحله معتبر است؟"}:::decision UNIT_ERROR["نمایش خطای مشخصات واحد"]:::error PEOPLE_ERROR["نمایش خطای افراد و روابط"]:::error TEMPLATE["دریافت و تکمیل قالب Excel"]:::user UPLOAD["بارگذاری فایل"]:::user VALIDATE["اعتبارسنجی فایل و نمایش Preview"]:::system BLOCKING{"خطای مسدودکننده وجود دارد؟"}:::decision REPORT["نمایش یا دریافت گزارش خطاها"]:::error WARNING{"Warning غیرمسدودکننده وجود دارد؟"}:::decision REVIEW["بازبینی Warningها؛ مانند خالی‌بودن موبایل"]:::user CONFIRM["تأیید Import"]:::user SAVE["ثبت یکپارچه واحدها، اشخاص، Membership و روابط"]:::system SAVED{"ثبت نهایی موفق بود؟"}:::decision RETRY["حفظ وضعیت قبلی و تلاش مجدد امن"]:::error CAPACITY{"تعداد واقعی بیشتر از ظرفیت خریداری‌شده است؟"}:::decision FLAG["نمایش هشدار و ثبت اختلاف ظرفیت"]:::system ENOUGH{"فهرست اولیه برای اکنون کافی است؟"}:::decision PARTIAL(["ثبت وضعیت «فعلاً تکمیل‌شده»"]):::success DONE(["تکمیل بخش بدون ارسال دعوت‌نامه"]):::success START --> METHOD METHOD -->|"دستی"| UNIT --> UNIT_MORE --> UNIT_VALID UNIT_VALID -->|"خیر"| UNIT_ERROR UNIT_ERROR -.->|"اصلاح"| UNIT UNIT_VALID -->|"بله"| PEOPLE PEOPLE --> ADD_PERSON --> PERSON_RULES --> PERSON_MORE --> MORE_PERSON MORE_PERSON -->|"بله"| ADD_PERSON MORE_PERSON -->|"خیر"| MANUAL_VALID MANUAL_VALID -->|"خیر"| PEOPLE_ERROR PEOPLE_ERROR -.->|"اصلاح افراد"| PEOPLE MANUAL_VALID -->|"بله"| SAVE METHOD -->|"Excel"| TEMPLATE --> UPLOAD --> VALIDATE --> BLOCKING BLOCKING -->|"بله"| REPORT REPORT -.->|"اصلاح و بارگذاری مجدد"| UPLOAD BLOCKING -->|"خیر"| WARNING WARNING -->|"بله"| REVIEW --> CONFIRM WARNING -->|"خیر"| CONFIRM CONFIRM --> SAVE SAVE --> SAVED SAVED -->|"خیر"| RETRY RETRY -.-> SAVE SAVED -->|"بله"| CAPACITY CAPACITY -->|"بله"| FLAG --> ENOUGH CAPACITY -->|"خیر"| ENOUGH ENOUGH -->|"خیر؛ بعداً ادامه می‌دهم"| PARTIAL ENOUGH -->|"بله"| DONE classDef start fill:#DBEAFE,stroke:#2563EB,color:#172554,stroke-width:2px; classDef user fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E; classDef system fill:#F3F4F6,stroke:#6B7280,color:#111827; classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:2px; classDef success fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:2px; classDef error fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D;

نقاط کنترل محصول

  • خطای مسدودکننده کل Import را متوقف می‌کند؛ Warning مانع Import نیست.
  • موبایل خالی Warning است و شخص بدون موبایل تا تکمیل شماره قابل دعوت نیست.
  • Import موفق هیچ SMS، Invitation، Account Link یا Permission فعالی ایجاد نمی‌کند.
  • اختلاف ظرفیت ثبت را مسدود نمی‌کند و در Flow مستقل تغییر اشتراک پیگیری می‌شود.
  • در ثبت دستی، ذخیره واحد و رابطه مستقل از ارسال دعوت است؛ ارسال دعوت یک انتخاب صریح و فقط برای اشخاص دارای موبایل است.
  • وضعیت «دارای ساکن / بدون ساکن» با Segmented Control نمایش داده می‌شود، نه Switch. واحد بدون ساکن همچنان می‌تواند مالک داشته باشد.
  • ثبت دستی یک Flow تمام‌صفحه دومرحله‌ای است: ابتدا مشخصات واحد و سپس افراد واحد. Bottom Sheet فقط برای زیرفرایندهای کوتاه و اختیاری استفاده می‌شود.
  • در وضعیت «دارای ساکن»، تعداد ساکنان الزامی است. تعداد روابط سکونت ثبت‌شده نمی‌تواند از این عدد بیشتر شود؛ کمتر بودن آن مجاز است چون ثبت همه ساکنان به‌عنوان Person الزامی نیست.
  • انتخاب «ساکن» مستقیماً رابطه سکونت می‌سازد؛ مالک یا مستأجر می‌تواند با گزینه «در این واحد سکونت دارد» هم‌زمان رابطه سکونت نیز داشته باشد.
  • برای مالک، سهم مالکیت با دنگ یا درصد ثبت می‌شود و مجموع سهم‌های فعال از ۶ دنگ یا ۱۰۰٪ بیشتر نمی‌شود.
  • در این Flow کنترل جداگانه «نقش پیشنهادی در اپ» نمایش داده نمی‌شود؛ دسترسی پیش‌فرض پس از دعوت از رابطه فعال فرد مشتق می‌شود.
  • اطلاعات تکمیلی واحد، قبض‌ها، حیوانات خانگی و اطلاعات تکمیلی شخص اختیاری‌اند.
  • پیش از ساخت Person جدید، شماره موبایل نرمال‌شده با اشخاص موجود تطبیق داده می‌شود.

۸. OBM-UF-04 — ایجاد تیم ساختمان

شناسنامه

  • بازیگر اصلی: مدیر راه‌اندازی
  • هدف: انتخاب مسئولیت‌های مدیریتی، هیئت‌مدیره و کارکنان و تعیین افراد مسئول
  • شروع: انتخاب بخش «تیم ساختمان»
  • پایان موفق: مسئولیت‌های انتخاب‌شده و افراد معتبر آن‌ها ذخیره شده‌اند
flowchart TD accTitle: ایجاد تیم ساختمان accDescr: مدیر مسئولیت‌های موردنیاز را انتخاب و سپس برای هر مسئولیت شخص موجود یا جدید تعیین می‌کند START(["بازکردن بخش تیم ساختمان"]):::start MODEL["انتخاب مسئولیت‌ها در چهار گروه مدیریت ساختمان، هیئت‌مدیره، مالی و عملیات و همکاران بیرونی"]:::user UNKNOWN{"ساختار مدیریت هنوز مشخص نیست؟"}:::decision INCOMPLETE(["ذخیره با وضعیت «در حال تکمیل»"]):::success SUGGEST["نمایش خلاصه دسترسی پیش‌فرض هر مسئولیت"]:::system ASSIGN["جست‌وجوی شخص موجود یا ثبت نام و موبایل شخص جدید"]:::user SELF{"شخص انتخاب‌شده خود مدیر راه‌اندازی است؟"}:::decision SELF_CONFIRM["نمایش اثر و دریافت تأیید صریح"]:::system CONFIRMED{"تخصیص Role تأیید شد؟"}:::decision SELF_ACTIVE["فعال‌سازی Role و ثبت در Audit"]:::system MEMBER{"شخص دیگر Membership فعال دارد؟"}:::decision PENDING["ذخیره Role پیشنهادی بدون Permission فعال"]:::system READY["آماده‌سازی Role برای دعوت جداگانه"]:::system CUSTOM{"تعداد افراد با قاعده مسئولیت سازگار است؟"}:::decision DEFAULTS["اعمال خودکار بسته دسترسی پیش‌فرض"]:::system EDIT["رفع مسئولیت بدون فرد یا تعداد نامعتبر"]:::user SENSITIVE{"شخص جدید با موبایل تکراری است؟"}:::decision WARNING["پیشنهاد استفاده از Person موجود"]:::system SAVE["ذخیره ساختار مدیریت"]:::system COMPLETE{"حداقل مدیر یا رئیس هیئت‌مدیره تعیین شده است؟"}:::decision REQUIRED["درخواست تعیین شخص مسئول"]:::error DONE(["بخش تکمیل‌شده؛ دعوت شرط تکمیل نیست"]):::success START --> MODEL --> UNKNOWN UNKNOWN -->|"بله"| INCOMPLETE UNKNOWN -->|"خیر"| SUGGEST --> ASSIGN --> SENSITIVE SENSITIVE -->|"بله"| WARNING --> ASSIGN SENSITIVE -->|"خیر"| SELF SELF -->|"بله"| SELF_CONFIRM --> CONFIRMED CONFIRMED -->|"خیر"| ASSIGN CONFIRMED -->|"بله"| SELF_ACTIVE --> CUSTOM SELF -->|"خیر"| MEMBER MEMBER -->|"خیر"| PENDING --> READY --> CUSTOM MEMBER -->|"بله"| READY --> CUSTOM CUSTOM -->|"بله"| DEFAULTS --> SAVE CUSTOM -->|"خیر"| EDIT --> ASSIGN SAVE --> COMPLETE COMPLETE -->|"خیر"| REQUIRED REQUIRED -.-> ASSIGN COMPLETE -->|"بله"| DONE classDef start fill:#DBEAFE,stroke:#2563EB,color:#172554,stroke-width:2px; classDef user fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E; classDef system fill:#F3F4F6,stroke:#6B7280,color:#111827; classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:2px; classDef success fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:2px; classDef error fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D;

نقاط کنترل محصول

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

۹. OBM-UF-05 — ادغام‌شده در تیم ساختمان

تصمیم جاری محصول

این Flow دیگر صفحه مستقلی ندارد. نقش‌های کارکنان، مالی، عملیات و پیمانکاران در OBM-UF-04 و بخش «تیم ساختمان» انتخاب و به افراد منتسب می‌شوند. نمودار زیر فقط برای ردیابی تصمیم تاریخی نگه داشته شده و نباید مبنای طراحی یا توسعه باشد.

شناسنامه

  • بازیگر اصلی: مدیر راه‌اندازی
  • هدف: تعریف انواع نیروی موردنیاز و Role Template هر نوع کار
  • شروع: انتخاب بخش «کارکنان و دسترسی‌ها»
  • پایان موفق: Role Templateها و وضعیت تصدی مشخص شده‌اند یا نبود کارکنان ثبت شده است
flowchart TD accTitle: تعیین کارکنان و بسته‌های دسترسی accDescr: مدیر نوع نیروی ساختمان را مشخص می‌کند و دسترسی‌ها را در سطح نوع کار تنظیم می‌کند نه برای هر شخص START(["بازکردن بخش کارکنان و دسترسی‌ها"]):::start HAS_STAFF{"ساختمان کارکنان دارد؟"}:::decision NO_STAFF["ثبت «ساختمان کارکنان ندارد»"]:::user NO_STAFF_DONE(["تکمیل بخش بدون فعال‌سازی Role عملیاتی"]):::success TYPES["انتخاب یک یا چند نوع کار"]:::user TEMPLATE["فعال‌سازی Role Template و نمایش خلاصه بسته پیش‌فرض"]:::system CUSTOM{"بسته دسترسی شخصی‌سازی شود؟"}:::decision DEFAULT["تأیید بسته پیش‌فرض"]:::user PERMISSIONS["ویرایش Permissionها در سطح نوع کار"]:::user IMPACT{"تغییر حساس یا مؤثر بر افراد فعال است؟"}:::decision CONFIRM_IMPACT["نمایش افراد متأثر، هشدار و دریافت تأیید"]:::system OCCUPANT{"برای این موقعیت شخص مشخص است؟"}:::decision VACANT["ثبت موقعیت «بدون متصدی»"]:::user PERSON["انتخاب شخص موجود یا ثبت شخص پیشنهادی"]:::user SAVE["ذخیره Role Template و موقعیت بدون ارسال دعوت"]:::system MORE{"نوع کار دیگری باقی مانده است؟"}:::decision DONE(["بخش تکمیل‌شده؛ دعوت بعداً ارسال می‌شود"]):::success START --> HAS_STAFF HAS_STAFF -->|"خیر"| NO_STAFF --> NO_STAFF_DONE HAS_STAFF -->|"بله"| TYPES --> TEMPLATE --> CUSTOM CUSTOM -->|"خیر"| DEFAULT --> OCCUPANT CUSTOM -->|"بله"| PERMISSIONS --> IMPACT IMPACT -->|"بله"| CONFIRM_IMPACT --> OCCUPANT IMPACT -->|"خیر"| OCCUPANT OCCUPANT -->|"خیر"| VACANT --> SAVE OCCUPANT -->|"بله"| PERSON --> SAVE SAVE --> MORE MORE -->|"بله"| TEMPLATE MORE -->|"خیر"| DONE classDef start fill:#DBEAFE,stroke:#2563EB,color:#172554,stroke-width:2px; classDef user fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E; classDef system fill:#F3F4F6,stroke:#6B7280,color:#111827; classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:2px; classDef success fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:2px;

نقاط کنترل محصول

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

۱۰. OBM-UF-06 — تنظیم برنامه شارژ و حساب ساختمان

شناسنامه

  • بازیگر اصلی: مدیر راه‌اندازی
  • هدف: تعریف روش محاسبه شارژ، قبض‌های متغیر، بازبینی مبالغ و روش دریافت وجه
  • شروع: انتخاب بخش «تنظیمات مالی و شارژ»
  • پایان موفق: برنامه شارژ Draft و حداقل یک روش دریافت معتبر ذخیره شده یا تصمیم «بعداً» ثبت شده است
  • خارج از محدوده: انتشار خودکار Charge، Bill یا Expense

مسیر پنج‌مرحله‌ای قطعی

  1. روش تنظیم شارژ: انتخاب «شروع سریع» یا «محاسبه دقیق».
  2. محاسبه مبلغ: در شروع سریع یکی از سه روش «یکسان»، «گروهی» یا «واحدبه‌واحد»؛ در روش دقیق، تعریف ردیف هزینه و مبنای تخصیص هر ردیف.
  3. قبض‌ها و هزینه‌های متغیر: تعریف مواردی مانند آب بر اساس Snapshot تعداد ساکنان، مستقل از شارژ ثابت.
  4. بازبینی محاسبه: مشاهده مبلغ هر واحد، منبع قاعده و «چرا این مبلغ محاسبه شده؟» و رفع اختلاف جمع یا واحد بدون قاعده.
  5. روش دریافت و حساب: انتخاب پرداخت آنلاین، واریز بانکی یا هر دو و ثبت مقصد معتبر؛ سپس ذخیره برنامه به‌صورت Draft.

ذخیره برنامه هیچ شارژی را منتشر نمی‌کند. زمان‌بندی فقط پیش‌نویس دوره را می‌سازد و انتشار به تأیید صریح مدیر نیاز دارد.

flowchart TD accTitle: آغاز تنظیمات مالی ساختمان accDescr: مدیر تنظیمات مالی را آغاز می‌کند یا آگاهانه به زمان دیگری موکول می‌کند START(["بازکردن بخش تنظیمات مالی و شارژ"]):::start NOW{"مدیر اکنون تنظیمات مالی را انجام می‌دهد؟"}:::decision LATER["انتخاب «بعداً انجام می‌دهم»"]:::user LATER_DONE(["ثبت وضعیت «فعلاً تکمیل‌شده»"]):::success UNITS{"حداقل فهرست واحدها موجود است؟"}:::decision NEED_UNITS["راهنمای تکمیل بخش واحدها"]:::error DEFAULT["نمایش پرداخت آنلاین به‌عنوان روش پیش‌فرض"]:::system SETTLEMENT["ثبت یا انتخاب مقصد تسویه آنلاین"]:::user VALID{"مقصد تسویه معتبر است؟"}:::decision SETTLEMENT_ERROR["نمایش خطا و درخواست اصلاح"]:::error BANK{"واریز بانکی نیز فعال شود؟"}:::decision BANK_DEST["ثبت کارت، حساب یا شبا و دستورالعمل"]:::user BANK_VALID{"حداقل یک مقصد بانکی معتبر است؟"}:::decision BANK_ERROR["نمایش خطا و درخواست اصلاح مقصد"]:::error REVIEWER["تعیین Roleهای مجاز تأیید قبض"]:::user SUMMARY["نمایش هم‌زمان مسیر آنلاین و واریز بانکی"]:::system SAVE["ذخیره تنظیمات اولیه در ماژول مالی"]:::system SAVED{"ذخیره موفق بود؟"}:::decision RETRY["حفظ وضعیت قبلی و امکان تلاش مجدد"]:::error DONE(["بخش تکمیل‌شده یا در حال تکمیل"]):::success START --> NOW NOW -->|"خیر"| LATER --> LATER_DONE NOW -->|"بله"| UNITS UNITS -->|"خیر"| NEED_UNITS NEED_UNITS -.->|"پس از ثبت واحدها"| START UNITS -->|"بله"| DEFAULT --> SETTLEMENT --> VALID VALID -->|"خیر"| SETTLEMENT_ERROR SETTLEMENT_ERROR -.-> SETTLEMENT VALID -->|"بله"| BANK BANK -->|"خیر"| SUMMARY BANK -->|"بله"| BANK_DEST --> BANK_VALID BANK_VALID -->|"خیر"| BANK_ERROR BANK_ERROR -.-> BANK_DEST BANK_VALID -->|"بله"| REVIEWER --> SUMMARY SUMMARY --> SAVE SAVE --> SAVED SAVED -->|"خیر"| RETRY RETRY -.-> SAVE SAVED -->|"بله"| DONE classDef start fill:#DBEAFE,stroke:#2563EB,color:#172554,stroke-width:2px; classDef user fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E; classDef system fill:#F3F4F6,stroke:#6B7280,color:#111827; classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:2px; classDef success fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:2px; classDef error fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D;

نقاط کنترل محصول

  • تمام مبالغ رابط با «تومان» نمایش داده می‌شوند.
  • شروع سریع سه روش یکسان، گروهی و واحدبه‌واحد دارد و مبلغ اختصاصی واحد بر مبلغ گروه و مبلغ عمومی اولویت دارد.
  • هر واحد دقیقاً یک منبع مبلغ مؤثر دارد؛ واحد بدون قاعده یا عضویت هم‌زمان در چند گروه مانع ذخیره نهایی است.
  • Action مبهم «افزودن گروه یا استثنای واحدی» به «افزودن گروه شارژ» و «تعیین مبلغ اختصاصی برای واحد» تفکیک می‌شود.
  • زمان صدور و مهلت پرداخت در سطح برنامه‌اند، نه هر گروه.
  • در محاسبه دقیق، هر ردیف هزینه یک مبنای تخصیص دارد؛ ترکیب چند مبنا فقط با فرمول و وزن صریح مجاز است.
  • آب قبض جداگانه است و تعداد نفرات Snapshot همان دوره را استفاده می‌کند؛ تغییر بعدی ساکنان دوره بسته‌شده را بازنویسی نمی‌کند.
  • سیاست واحد خالی و باقی‌مانده گردکردن باید صریح باشد و جمع سهم واحدها با کل هزینه تطبیق کند.
  • بازکردن این بخش هیچ Charge، Bill یا Expense منتشرشده‌ای ایجاد نمی‌کند.
  • پرداخت آنلاین روش پیش‌فرض است، اما بدون مقصد تسویه معتبر فعال نمی‌شود.
  • مدیر می‌تواند واریز بانکی را در کنار پرداخت آنلاین فعال کند.
  • کارت‌به‌کارت و حساب‌به‌حساب هر دو به ارسال قبض و تأیید مدیر یا Role مالی مجاز وابسته‌اند.
  • مانده واحد فقط پس از تأیید معتبر Provider یا تأیید قبض کاهش می‌یابد.
  • موفقیت و شکست ذخیره State مستقل دارند و موفقیت به صفحه اصلی ساختمان بازمی‌گردد.

۱۰.۱. OBM-UF-06A — ثبت و تأیید قبض واریز بانکی

شناسنامه

  • بازیگر اصلی: مالک، مستأجر یا پرداخت‌کننده مجاز واحد
  • بازیگر تأییدکننده: مدیر ساختمان، حسابدار یا Role مالی مجاز
  • شروع: انتخاب یک Bill یا مانده قابل پرداخت از صفحه واحد
  • پایان موفق: Payment دستی تأیید و مانده Unit Ledger کاهش یافته است
flowchart TD accTitle: ثبت و تأیید قبض واریز بانکی accDescr: پرداخت‌کننده کارت‌به‌کارت یا حساب‌به‌حساب را انتخاب می‌کند و مانده فقط پس از تأیید قبض کاهش می‌یابد START(["بازکردن Bill یا مانده واحد"]):::start METHODS["نمایش پرداخت آنلاین، کارت‌به‌کارت و حساب‌به‌حساب"]:::system CHOOSE{"روش پرداخت چیست؟"}:::decision ONLINE["انتقال به درگاه و اعتبارسنجی Provider"]:::external ONLINE_OK{"پرداخت آنلاین معتبر است؟"}:::decision BANK["نمایش مقصد بانکی و دستورالعمل"]:::system TRANSFER["انجام واریز خارج از تری‌پیلون"]:::external RECEIPT["ثبت مبلغ، تاریخ، شماره پیگیری و تصویر قبض"]:::user VALID{"اطلاعات قبض کامل و معتبر است؟"}:::decision FIX["نمایش خطا و درخواست اصلاح"]:::error PENDING["ثبت قبض در وضعیت در انتظار تأیید"]:::system REVIEW["بررسی قبض توسط Role مالی مجاز"]:::user DECISION{"تصمیم تأییدکننده چیست؟"}:::decision REJECT["ثبت دلیل رد و امکان ارسال مجدد"]:::error APPLY["ثبت Payment و تخصیص به Bill"]:::system LEDGER["کاهش مانده Unit Ledger به‌صورت idempotent"]:::system DONE(["نمایش رسید و مانده جدید"]):::success START --> METHODS --> CHOOSE CHOOSE -->|"پرداخت آنلاین"| ONLINE --> ONLINE_OK ONLINE_OK -->|"خیر"| METHODS ONLINE_OK -->|"بله"| APPLY CHOOSE -->|"کارت‌به‌کارت یا حساب‌به‌حساب"| BANK --> TRANSFER --> RECEIPT --> VALID VALID -->|"خیر"| FIX FIX -.-> RECEIPT VALID -->|"بله"| PENDING --> REVIEW --> DECISION DECISION -->|"رد"| REJECT REJECT -.-> RECEIPT DECISION -->|"تأیید"| APPLY --> LEDGER --> DONE classDef start fill:#DBEAFE,stroke:#2563EB,color:#172554,stroke-width:2px; classDef user fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E; classDef system fill:#F3F4F6,stroke:#6B7280,color:#111827; classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:2px; classDef external fill:#F3E8FF,stroke:#9333EA,color:#581C87; classDef success fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:2px; classDef error fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D;

نقاط کنترل محصول

  • ثبت قبض بدون تأیید، مانده واحد را تغییر نمی‌دهد.
  • تأیید دوباره همان قبض، Payment تکراری ایجاد نمی‌کند.
  • دلیل رد برای پرداخت‌کننده قابل مشاهده است.
  • جزئیات کامل حساب بانکی فقط در Context پرداخت و برای کاربر مجاز نمایش داده می‌شود.

۱۱. OBM-UF-07 — راه‌اندازی امکانات ساکنان

شناسنامه

  • بازیگر اصلی: مدیر راه‌اندازی
  • هدف: ثبت امکانات قابل رزرو و حداقل قواعد MVP بدون ورود به تنظیمات پیشرفته
  • شروع: انتخاب بخش «امکانات ساکنان»
  • پایان موفق: نبود Facility قابل رزرو ثبت شده یا حداقل یک Facility معتبر فعال است
flowchart TD accTitle: راه‌اندازی امکانات ساکنان accDescr: مدیر نبود امکانات رزروپذیر را ثبت می‌کند یا Facility را با یکی از مدل‌های ساعتی، سانسی یا روز کامل فعال می‌کند START(["بازکردن امکانات ساکنان"]):::start HAS_FACILITY{"ساختمان Facility قابل رزرو دارد؟"}:::decision NONE["ثبت «امکان قابل رزرو نداریم»"]:::user DISABLED(["تکمیل بخش و غیرفعال‌ماندن ماژول رزرو"]):::success SELECT["انتخاب امکان پیشنهادی یا تعریف امکان سفارشی"]:::user DRAFT["ایجاد امکان در وضعیت Draft"]:::system MODEL{"مدل رزرو چیست؟"}:::decision HOURLY["ساعتی: روزها، بازه ساعت و مدت"]:::user SESSION["سانسی: روزها و فهرست سانس‌ها"]:::user DAILY["روز کامل: روزهای مجاز و مدت روزانه"]:::user PRICING["تعیین رایگان/پولی و مبلغ مرتبط"]:::user APPROVAL["تعیین تأیید خودکار یا مدیر"]:::user VALID{"حداقل قواعد همان مدل معتبر است؟"}:::decision INCOMPLETE["حفظ امکان در Draft و نمایش موارد ناقص"]:::error ACTIVATE["تأیید مدیر و فعال‌سازی امکان"]:::system MORE{"امکان دیگری باقی مانده است؟"}:::decision DONE(["همه امکانات انتخاب‌شده فعال هستند"]):::success START --> HAS_FACILITY HAS_FACILITY -->|"خیر"| NONE --> DISABLED HAS_FACILITY -->|"بله"| SELECT --> DRAFT --> MODEL MODEL -->|"ساعتی"| HOURLY --> PRICING MODEL -->|"سانس ثابت"| SESSION --> PRICING MODEL -->|"روز کامل"| DAILY --> PRICING PRICING --> APPROVAL --> VALID VALID -->|"خیر"| INCOMPLETE INCOMPLETE -.->|"تکمیل تنظیمات"| MODEL VALID -->|"بله"| ACTIVATE --> MORE MORE -->|"بله"| SELECT MORE -->|"خیر"| DONE classDef start fill:#DBEAFE,stroke:#2563EB,color:#172554,stroke-width:2px; classDef user fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E; classDef system fill:#F3F4F6,stroke:#6B7280,color:#111827; classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:2px; classDef success fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:2px; classDef error fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D;

نقاط کنترل محصول

  • انتخاب نام یک امکان به‌تنهایی آن را فعال نمی‌کند.
  • مدل‌های Setup فقط «ساعتی»، «سانس ثابت» و «روز کامل» هستند.
  • در روز کامل، انتخاب تاریخ کل روز عملیاتی را با احتساب آماده‌سازی و نظافت مسدود می‌کند.
  • زیرساخت‌ها و خدمات بدون تخصیص زمان وارد این Flow نمی‌شوند.
  • سهمیه، بدهی، مهمان، ودیعه، بازپرداخت، No-show و بازه‌های استثنا پس از Setup در داشبورد تکمیل می‌شوند.

۱۱.۱. OBM-UF-07A — ثبت اطلاعات تکمیلی و پایان Setup

شناسنامه

  • بازیگر اصلی: مدیر راه‌اندازی
  • هدف: ثبت اختیاری نشانی و تصویر ساختمان و پایان راه‌اندازی اولیه
  • شروع: انتخاب بخش «اطلاعات تکمیلی»
  • پایان موفق: تصمیم مدیر درباره هر دو مرحله ذخیره و در صورت حل‌شدن پنج بخش، داشبورد اصلی باز شده است
flowchart TD accTitle: ثبت اطلاعات تکمیلی و پایان راه‌اندازی accDescr: مدیر در دو مرحله اختیاری نشانی و تصویر ساختمان را ثبت یا رد می‌کند و پس از تکمیل پنج بخش وارد داشبورد می‌شود START(["بازکردن اطلاعات تکمیلی"]):::start ADDRESS["مرحله ۱ از ۲: استان، شهر، نشانی، پلاک و کد پستی"]:::user ADDRESS_VALID{"داده واردشده معتبر است؟"}:::decision ADDRESS_ERROR["نمایش خطای همان فیلد و حفظ داده‌ها"]:::error IMAGE["مرحله ۲ از ۲: بارگذاری تصویر یا انتخاب آواتار"]:::user IMAGE_VALID{"فایل انتخابی معتبر است؟"}:::decision IMAGE_ERROR["حفظ مرحله و پیشنهاد Retry یا آواتار"]:::error SAVE["ذخیره تصمیم مدیر و حل‌کردن بخش"]:::system ALL_DONE{"هر پنج بخش حل شده‌اند؟"}:::decision RETURN(["بازگشت به Setup Dashboard"]):::success REMOVE["حذف کارت موقت راه‌اندازی"]:::system DASHBOARD(["ورود به داشبورد ساختمان"]):::success START --> ADDRESS --> ADDRESS_VALID ADDRESS_VALID -->|"خیر"| ADDRESS_ERROR -.-> ADDRESS ADDRESS_VALID -->|"بله یا بدون داده"| IMAGE --> IMAGE_VALID IMAGE_VALID -->|"خیر"| IMAGE_ERROR -.-> IMAGE IMAGE_VALID -->|"بله یا بدون تصویر"| SAVE --> ALL_DONE ALL_DONE -->|"خیر"| RETURN ALL_DONE -->|"بله"| REMOVE --> DASHBOARD classDef start fill:#DBEAFE,stroke:#2563EB,color:#172554,stroke-width:2px; classDef user fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E; classDef system fill:#F3F4F6,stroke:#6B7280,color:#111827; classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:2px; classDef success fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:2px; classDef error fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D;

نقاط کنترل محصول

  • نشانی و تصویر در Setup اختیاری‌اند؛ تأیید صریح مدیر معیار حل‌شدن بخش است.
  • فرمت تصویر jpg، png یا webp و حداکثر حجم ۲ MB است.
  • در نبود تصویر، Fallback سیستم حفظ می‌شود.
  • همه داده‌ها پس از Setup از تنظیمات ساختمان قابل ویرایش‌اند.
  • پایان این Flow تنها زمانی ثبت‌نام و Setup را می‌بندد که هر پنج بخش حل شده باشند.

۱۲. OBM-UF-08 — ایجاد و ارسال دعوت‌نامه

شناسنامه

  • بازیگر اصلی: مدیر مجاز
  • هدف: ارسال دعوت فردی یا گروهی بدون ایجاد Envelope تکراری
  • شروع: انتخاب شخص از لیست واحدها، جزئیات واحد، تیم مدیریت یا فهرست کارکنان
  • پایان موفق: نتیجه ارسال هر گیرنده ثبت شده است
  • پایان قابل قبول: Envelopeها تا اصلاح موجودی یا داده ناقص در Draft باقی می‌مانند
flowchart TD accTitle: ایجاد و ارسال دعوت‌نامه فردی و گروهی accDescr: مدیر اشخاص را انتخاب می‌کند و نتیجه ارسال هر گیرنده به‌صورت مستقل ثبت می‌شود START(["شروع از ردیف شخص در واحد یا Role مرتبط"]):::start SELECT["انتخاب یک یا چند شخص"]:::user LOAD["نمایش رابطه، Role پیشنهادی و Scope هر شخص"]:::system ROLES["تنظیم یک یا چند Role در یک Envelope"]:::user VALID{"موبایل، Role و Scope معتبر هستند؟"}:::decision INVALID["حذف مورد نامعتبر از Batch و نمایش علت"]:::error COST["نمایش تعداد پیامک‌ها، هزینه و موجودی پنل"]:::system BALANCE{"موجودی کافی است؟"}:::decision DRAFT(["حفظ Envelopeها در Draft"]):::success CONFIRM["تأیید فهرست و هزینه ارسال"]:::user EXISTING{"Envelope در انتظار از قبل وجود دارد؟"}:::decision UPDATE["به‌روزرسانی همان Envelope"]:::system CREATE["ایجاد Envelope یکتا برای شخص و ساختمان"]:::system SEND["ارسال یک پیامک برای هر Envelope"]:::external DELIVERY{"نتیجه ارسال این گیرنده چیست؟"}:::decision SENT["ثبت ارسال موفق"]:::system FAILED["ثبت ارسال ناموفق برای Retry"]:::error RESULT(["نمایش نتیجه مستقل همه گیرندگان"]):::success START --> SELECT --> LOAD --> ROLES --> VALID VALID -->|"خیر"| INVALID INVALID -.->|"اصلاح"| ROLES VALID -->|"بله"| COST --> BALANCE BALANCE -->|"خیر"| DRAFT DRAFT -.->|"پس از افزایش موجودی"| COST BALANCE -->|"بله"| CONFIRM --> EXISTING EXISTING -->|"بله"| UPDATE --> SEND EXISTING -->|"خیر"| CREATE --> SEND SEND --> DELIVERY DELIVERY -->|"موفق"| SENT --> RESULT DELIVERY -->|"ناموفق"| FAILED --> RESULT classDef start fill:#DBEAFE,stroke:#2563EB,color:#172554,stroke-width:2px; classDef user fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E; classDef system fill:#F3F4F6,stroke:#6B7280,color:#111827; classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:2px; classDef external fill:#F3E8FF,stroke:#9333EA,color:#581C87; classDef success fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:2px; classDef error fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D;

نقاط کنترل محصول

  • دعوت ساکن عادی شرط ایجاد Membership عملیاتی نیست و پذیرش اجباری ندارد.
  • Role حساس تا پذیرش صریح در PENDING_ACCEPTANCE باقی می‌ماند.
  • Invitation انقضای کسب‌وکاری ندارد، اما بازکردن آن همیشه نیازمند OTP است.
  • شکست بخشی از Batch باعث Rollback ارسال‌های موفق نمی‌شود.
  • صفحه مرکزی Invitation وجود ندارد؛ وضعیت و Actionها داخل Context همان واحد، شخص یا Role نمایش داده می‌شوند.

۱۳. OBM-UF-09 — ورود و تصمیم درباره نقش‌های دعوت‌شده

شناسنامه

  • بازیگر اصلی: شخص دعوت‌شده
  • هدف: اتصال Account موجود و تصمیم مستقل درباره Roleهای حساس
  • شروع: بازکردن لینک پیامک یا ورود با شماره موبایل
  • پایان موفق: Account Link برقرار و Roleهای پذیرفته‌شده فعال شده‌اند
  • خارج از محدوده: ایجاد Account جدید
flowchart TD accTitle: ورود شخص دعوت‌شده و تصمیم درباره نقش‌ها accDescr: شخص با رمز یک‌بارمصرف وارد می‌شود و درباره هر نقش حساس به‌صورت مستقل تصمیم می‌گیرد START(["بازکردن لینک دعوت یا ورود با موبایل"]):::start OTP["ورود و تأیید رمز یک‌بارمصرف"]:::user OTP_VALID{"رمز یک‌بارمصرف معتبر است؟"}:::decision OTP_ERROR["نمایش خطا و امکان تلاش مجدد"]:::error KNOWN{"شماره موبایل در رکورد معتبری شناخته شده است؟"}:::decision NO_ACCOUNT(["Account جدید ساخته نمی‌شود؛ هدایت به مسیر ثبت ساختمان"]):::success CANCELED{"Invitation لغو شده است؟"}:::decision CANCELED_VIEW(["نمایش وضعیت لغو؛ Membership عملیاتی حفظ می‌شود"]):::success DISPUTE{"شخص تعلق به ساختمان یا واحد را رد می‌کند؟"}:::decision DISPUTED["ثبت Contact Point به‌صورت Disputed"]:::system NOTIFY(["توقف دسترسی حساس و اطلاع به مدیر"]):::success LINK["اتصال Account موجود به Person و Membership معتبر"]:::system SENSITIVE{"Role حساس در انتظار وجود دارد؟"}:::decision NORMAL(["ورود مستقیم بدون پذیرش عضویت عادی"]):::success SHOW["نمایش Role، Scope و خلاصه دسترسی"]:::system DECIDE["پذیرش یا رد مستقل هر Role"]:::user APPLY["فعال‌سازی فقط Roleهای پذیرفته‌شده"]:::system PRESERVE["حفظ Membership و Unit Relationship مستقل از تصمیم Role"]:::system ENTER(["انتخاب ساختمان معتبر و ورود به تری‌پیلون"]):::success START --> OTP --> OTP_VALID OTP_VALID -->|"خیر"| OTP_ERROR OTP_ERROR -.-> OTP OTP_VALID -->|"بله"| KNOWN KNOWN -->|"خیر"| NO_ACCOUNT KNOWN -->|"بله"| CANCELED CANCELED -->|"بله"| CANCELED_VIEW CANCELED -->|"خیر"| DISPUTE DISPUTE -->|"بله"| DISPUTED --> NOTIFY DISPUTE -->|"خیر"| LINK --> SENSITIVE SENSITIVE -->|"خیر"| NORMAL SENSITIVE -->|"بله"| SHOW --> DECIDE --> APPLY --> PRESERVE --> ENTER classDef start fill:#DBEAFE,stroke:#2563EB,color:#172554,stroke-width:2px; classDef user fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E; classDef system fill:#F3F4F6,stroke:#6B7280,color:#111827; classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:2px; classDef success fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:2px; classDef error fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D;

نقاط کنترل محصول

  • این Flow حساب جدید ایجاد نمی‌کند.
  • مالک، مستأجر و ساکن برای اصل رابطه عملیاتی پذیرش یا رد ندارند.
  • هر Role حساس مستقل پذیرفته یا رد می‌شود.
  • رد Role، Membership، رابطه واحد، Charge یا Bill را حذف نمی‌کند.

۱۴. OBM-UF-10 — ارسال مجدد یا لغو دعوت‌نامه

شناسنامه

  • بازیگر اصلی: مدیر مجاز
  • هدف: مدیریت Envelope موجود بدون ایجاد دعوت تکراری
  • شروع: انتخاب شخص یا Role دارای دعوت در انتظار از همان لیست واحد، تیم مدیریت یا کارکنان
  • پایان موفق: Delivery Attempt جدید ثبت یا Envelope لغو شده است
flowchart TD accTitle: ارسال مجدد یا لغو دعوت‌نامه accDescr: مدیر دعوت موجود را بدون ایجاد دعوت تکراری ویرایش، دوباره ارسال یا لغو می‌کند START(["بازکردن واحد یا فهرست Role مرتبط"]):::start SELECT["انتخاب شخص یا Role دارای دعوت در انتظار"]:::user ACTION{"اقدام مدیر چیست؟"}:::decision EDIT["ویرایش Role یا Scope در انتظار"]:::user VERSION["نسخه‌بندی و ثبت تغییر روی همان Envelope"]:::system RESEND["انتخاب Resend"]:::user INTERVAL{"حداقل ۲۴ ساعت از ارسال قبلی گذشته است؟"}:::decision WAIT["نمایش زمان باقی‌مانده"]:::error BALANCE{"موجودی پیامک کافی است؟"}:::decision TOPUP["حفظ دعوت و درخواست افزایش موجودی"]:::error CONFIRM["نمایش هزینه و تأیید مدیر"]:::user ATTEMPT["ثبت Delivery Attempt جدید روی همان Envelope"]:::system SEND["ارسال و ثبت مستقل نتیجه گیرندگان"]:::external RESEND_DONE(["حفظ ارسال‌های موفق و Retry موارد ناموفق"]):::success CANCEL["انتخاب Cancel"]:::user IMPACT["نمایش Roleهای Pending و اثر لغو"]:::system SENSITIVE{"دعوت شامل Role حساس است؟"}:::decision REASON["ثبت دلیل الزامی"]:::user CANCEL_CONFIRM["تأیید لغو"]:::user CANCEL_PENDING["لغو Envelope و توقف پذیرش Roleهای Pending"]:::system CANCEL_DONE(["حفظ Membership، روابط و Roleهای فعال"]):::success START --> SELECT --> ACTION ACTION -->|"ویرایش"| EDIT --> VERSION --> RESEND ACTION -->|"ارسال مجدد"| RESEND --> INTERVAL INTERVAL -->|"خیر"| WAIT WAIT -.->|"پس از پایان محدودیت"| RESEND INTERVAL -->|"بله"| BALANCE BALANCE -->|"خیر"| TOPUP TOPUP -.-> BALANCE BALANCE -->|"بله"| CONFIRM --> ATTEMPT --> SEND --> RESEND_DONE ACTION -->|"لغو"| CANCEL --> IMPACT --> SENSITIVE SENSITIVE -->|"بله"| REASON --> CANCEL_CONFIRM SENSITIVE -->|"خیر"| CANCEL_CONFIRM CANCEL_CONFIRM --> CANCEL_PENDING --> CANCEL_DONE classDef start fill:#DBEAFE,stroke:#2563EB,color:#172554,stroke-width:2px; classDef user fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E; classDef system fill:#F3F4F6,stroke:#6B7280,color:#111827; classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:2px; classDef external fill:#F3E8FF,stroke:#9333EA,color:#581C87; classDef success fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:2px; classDef error fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D;

نقاط کنترل محصول

  • Resend، Envelope یا Role Assignment جدید ایجاد نمی‌کند.
  • حداقل فاصله ارسال مجدد ۲۴ ساعت است و Resend خودکار وجود ندارد.
  • Cancel فقط Roleهای Pending همان Envelope را متوقف می‌کند و Role فعال را غیرفعال نمی‌کند.

۱۵. OBM-UF-11 — پایان یا جایگزینی رابطه و نقش

شناسنامه

  • بازیگر اصلی: مدیر مجاز
  • هدف: پایان‌دادن رابطه قبلی و در صورت نیاز ثبت جانشین، بدون حذف تاریخچه
  • شروع: انتخاب شخص از «لیست واحدها ← جزئیات واحد ← افراد واحد» یا از فهرست کارکنان
  • پایان موفق: رکورد قبلی با Effective Date آرشیو و رکورد جدید مستقل ایجاد شده است
flowchart TD accTitle: پایان یا جایگزینی رابطه و نقش accDescr: مدیر رابطه قبلی را بدون حذف تاریخچه پایان می‌دهد و در صورت نیاز شخص جدیدی را جایگزین می‌کند START(["انتخاب رابطه در جزئیات واحد یا ردیف کارکن"]):::start TYPE{"نوع تغییر چیست؟"}:::decision TENANT["نمایش Household، بدهی واحد و دسترسی‌ها"]:::system ARCHIVE_HOUSE["ثبت End Date و آرشیو مستأجر و ساکنان وابسته"]:::user DEBT{"بدهی واحد باقی مانده است؟"}:::decision OWNER_DEBT["حفظ بدهی در Unit Ledger و انتقال مسئولیت به مالک جاری"]:::system OWNER["نمایش مانده و صورت بدهی واحد"]:::system TRANSFER["ثبت مدرک و Effective Transfer Date"]:::user OWNERSHIP["آرشیو مالک قبلی و ایجاد رابطه مالک جدید"]:::system STAFF["نمایش Task، Shift و Assignmentهای باز"]:::system OPEN_WORK{"مورد بازی باقی مانده است؟"}:::decision RESOLVE["Reassign یا Close موارد باز"]:::user ROLE_END["ثبت End Date برای Role و Scope قبلی"]:::system REPLACEMENT{"شخص جایگزین اکنون ثبت می‌شود؟"}:::decision VACANT(["پایان رابطه؛ واحد خالی یا موقعیت بدون متصدی"]):::success NEW_PERSON["انتخاب شخص موجود یا ثبت شخص جدید و Start Date"]:::user OVERLAP{"بازه جدید معتبر و بدون تداخل است؟"}:::decision DATE_ERROR["نمایش خطا و درخواست اصلاح تاریخ"]:::error ATOMIC["ثبت اتمیک پایان رابطه قبلی و ایجاد رابطه جدید"]:::system ACCEPTANCE{"Role جدید نیازمند پذیرش است؟"}:::decision PENDING["ایجاد Role یا Invitation در انتظار"]:::system ACTIVE["فعال‌سازی رابطه عملیاتی معتبر"]:::system DONE(["حفظ تاریخچه، Bill، Payment و Scopeهای نامرتبط"]):::success START --> TYPE TYPE -->|"مستأجر"| TENANT --> ARCHIVE_HOUSE --> DEBT DEBT -->|"بله"| OWNER_DEBT --> REPLACEMENT DEBT -->|"خیر"| REPLACEMENT TYPE -->|"مالک"| OWNER --> TRANSFER --> OWNERSHIP --> REPLACEMENT TYPE -->|"کارکن یا سرویس‌کار"| STAFF --> OPEN_WORK OPEN_WORK -->|"بله"| RESOLVE --> ROLE_END OPEN_WORK -->|"خیر"| ROLE_END ROLE_END --> REPLACEMENT REPLACEMENT -->|"خیر"| VACANT REPLACEMENT -->|"بله"| NEW_PERSON --> OVERLAP OVERLAP -->|"خیر"| DATE_ERROR DATE_ERROR -.-> NEW_PERSON OVERLAP -->|"بله"| ATOMIC --> ACCEPTANCE ACCEPTANCE -->|"بله"| PENDING --> DONE ACCEPTANCE -->|"خیر"| ACTIVE --> DONE classDef start fill:#DBEAFE,stroke:#2563EB,color:#172554,stroke-width:2px; classDef user fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E; classDef system fill:#F3F4F6,stroke:#6B7280,color:#111827; classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:2px; classDef success fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:2px; classDef error fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D;

نقاط کنترل محصول

  • Person و Account حذف یا به شخص جدید تبدیل نمی‌شوند.
  • خروج مستأجر، اعضای وابسته همان Household را آرشیو می‌کند؛ روابط مستقل آن‌ها حفظ می‌شود.
  • بدهی متعلق به Unit Ledger است و با تغییر شخص حذف نمی‌شود.
  • جایگزینی کارکن تا تعیین تکلیف Task و Shiftهای باز نهایی نمی‌شود.

Warning

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

۱۶. OBM-UF-12 — درخواست تغییر مدیر راه‌اندازی

شناسنامه

  • بازیگر اصلی: درخواست‌کننده تغییر
  • بازیگران فرعی: شخص پیشنهادی و تیم پشتیبانی مجاز
  • هدف: ثبت و پیگیری درخواست تغییر مدیر راه‌اندازی
  • شروع: انتخاب موضوع «تغییر مدیر راه‌اندازی» در پشتیبانی
  • پایان موفق: تغییر تأیید و پس از پذیرش شخص جدید کامل شده است
  • پایان ناموفق: درخواست با دلیل رد شده و دسترسی مدیر فعلی حفظ شده است
  • خارج از محدوده: جزئیات بررسی داخلی اسناد و State Machine کامل Ticket
flowchart TD accTitle: درخواست تغییر مدیر راه‌اندازی accDescr: درخواست‌کننده مدارک را از طریق تیکت ثبت می‌کند و پس از بررسی دستی و پذیرش شخص جدید، مدیر تغییر می‌کند START(["شروع درخواست تغییر مدیر راه‌اندازی"]):::start FORM["ثبت ساختمان، مدیر فعلی، شخص پیشنهادی، دلیل و مدارک"]:::user TICKET["ایجاد Support Ticket و نمایش کد پیگیری"]:::system REVIEW["بررسی دستی هویت، اختیار و مدارک"]:::external COMPLETE{"مدارک کامل هستند؟"}:::decision REQUEST_INFO["درخواست اطلاعات تکمیلی"]:::system ADD_INFO["تکمیل مدارک توسط درخواست‌کننده"]:::user SECURITY{"خطر امنیتی فوری وجود دارد؟"}:::decision SUSPEND["تعلیق موقت مدیر فعلی و ثبت دلیل"]:::external APPROVED{"درخواست تأیید شد؟"}:::decision REJECTED(["نمایش رد و دلیل؛ حفظ مدیر فعلی"]):::success PENDING["ایجاد Role مدیر جدید در انتظار پذیرش"]:::system ACCEPT{"شخص پیشنهادی Role را پذیرفته است؟"}:::decision WAITING(["نمایش وضعیت در انتظار؛ حفظ مدیر فعلی"]):::success SWITCH["سلب و فعال‌سازی اتمیک Role مدیران"]:::system SWITCH_OK{"تغییر اتمیک موفق بود؟"}:::decision ROLLBACK["Rollback امن و تلاش مجدد"]:::error DONE(["تکمیل درخواست و فعال‌شدن مدیر جدید"]):::success START --> FORM --> TICKET --> REVIEW --> COMPLETE COMPLETE -->|"خیر"| REQUEST_INFO --> ADD_INFO --> REVIEW COMPLETE -->|"بله"| SECURITY SECURITY -->|"بله"| SUSPEND --> APPROVED SECURITY -->|"خیر"| APPROVED APPROVED -->|"خیر"| REJECTED APPROVED -->|"بله"| PENDING --> ACCEPT ACCEPT -->|"خیر یا هنوز نه"| WAITING WAITING -.->|"پس از پذیرش"| ACCEPT ACCEPT -->|"بله"| SWITCH --> SWITCH_OK SWITCH_OK -->|"خیر"| ROLLBACK ROLLBACK -.-> SWITCH SWITCH_OK -->|"بله"| DONE classDef start fill:#DBEAFE,stroke:#2563EB,color:#172554,stroke-width:2px; classDef user fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E; classDef system fill:#F3F4F6,stroke:#6B7280,color:#111827; classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:2px; classDef external fill:#F3E8FF,stroke:#9333EA,color:#581C87; classDef success fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:2px; classDef error fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D;

نقاط کنترل محصول

  • این قابلیت Self-service نیست و تصمیم نهایی توسط پشتیبانی مجاز گرفته می‌شود.
  • تا پذیرش مدیر جدید، مدیر فعلی در حالت عادی فعال می‌ماند.
  • Roleهای نامرتبط مدیر قبلی با این تغییر حذف نمی‌شوند.
  • مسیر اضطراری فقط تعلیق موقت است و جایگزین بررسی نهایی مدارک نیست.

Warning

قاعده حمایت بیش از ۵۰٪ مالکان، نحوه شمارش رأی و اولویت درخواست‌ها نیازمند بررسی حقوقی است.

۱۷. تصمیم‌های باز و Flowهای وابسته

شناسه موضوع اثر بر Flow
OPEN-PRICE-01 مبلغ ثابت شارژ اولیه پنل پیامکی ساختار UF-01 تغییر نمی‌کند؛ فقط مقدار باید پیش از اجرا تعیین شود
OPEN-SUB-01 اصلاح ظرفیت اشتراک پس از ثبت واحدهای بیشتر در UF-03 فقط هشدار داده می‌شود و Flow مستقل تغییر اشتراک لازم است
OPEN-LEGAL-01 مسئولیت مالک جاری برای بدهی Unit Ledger منطق UF-11 پیش از اجرا نیازمند تأیید حقوقی است
OPEN-LEGAL-02 شمارش حمایت مالکان برای تغییر مدیر منطق تصمیم در Workflow پشتیبانی نیازمند تأیید حقوقی است

۱۸. معیار پذیرش مجموعه Flowها

  • تمام سناریوهای تأییدشده حداقل در یک Flow پوشش داده شده‌اند.
  • هر Flow بازیگر و هدف اصلی روشن دارد.
  • مسیرهای اصلی، جایگزین، خطا و Retry از هم قابل تشخیص‌اند.
  • ثبت ساختمان از تکمیل مرحله‌ای اطلاعات جدا شده است.
  • ثبت عضویت عملیاتی از پذیرش Role حساس جدا شده است.
  • Invitation از Membership و Delivery پیامک از Acceptance تفکیک شده‌اند.
  • ورود فرد دعوت‌شده Account جدید ایجاد نمی‌کند.
  • پایان رابطه با Archive و Effective Date مدل شده است، نه حذف Person.
  • جزئیات Wireframe، API و State Machine وارد نمودارها نشده‌اند.
  • تصمیم‌های حقوقی باز پیش از پیاده‌سازی تأیید شوند.
  • Flow مستقل تغییر ظرفیت اشتراک طراحی شود.

۱۹. قواعد Mermaid استفاده‌شده

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

منابع مرجع:

بازگشت