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

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

وضعیت سند

آماده بازبینی محصول — این سند از سناریوهای 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-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 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 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 STAFF["کارکنان و دسترسی‌ها"]:::user FINANCE["تنظیمات مالی و شارژ"]:::user FACILITIES["امکانات و تنظیمات تکمیلی"]:::user SAVE["ذخیره نتیجه معتبر بخش"]:::system UPDATE["به‌روزرسانی وضعیت و تعداد بخش‌های باقی‌مانده"]:::system ALL_DONE{"همه بخش‌ها حل شده‌اند؟"}:::decision CONTINUE{"مدیر اکنون ادامه می‌دهد؟"}:::decision LATER(["خروج و ادامه در زمان دلخواه"]):::success DONE(["راه‌اندازی مرحله‌ای کامل شده است"]):::success START --> DASHBOARD --> SELECT SELECT --> UNITS & MANAGEMENT & STAFF & FINANCE & FACILITIES UNITS & MANAGEMENT & STAFF & FINANCE & FACILITIES --> 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 MANUAL["ثبت دستی واحد و اشخاص مرتبط"]:::user MANUAL_VALID{"اطلاعات دستی معتبر است؟"}:::decision MANUAL_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 -->|"دستی"| MANUAL --> MANUAL_VALID MANUAL_VALID -->|"خیر"| MANUAL_ERROR MANUAL_ERROR -.->|"اصلاح"| MANUAL 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 مستقل تغییر اشتراک پیگیری می‌شود.

۸. OBM-UF-04 — تعیین تیم مدیریت و هیئت‌مدیره

شناسنامه

  • بازیگر اصلی: مدیر راه‌اندازی
  • هدف: تعیین مدل اداره، نقش‌های حاکمیتی و اشخاص مسئول
  • شروع: انتخاب بخش «تیم مدیریت و هیئت‌مدیره»
  • پایان موفق: مدل مدیریت و حداقل مسئول لازم ثبت شده‌اند
flowchart TD accTitle: تعیین تیم مدیریت و هیئت‌مدیره accDescr: مدیر مدل اداره ساختمان، نقش‌ها و اشخاص مسئول را مشخص می‌کند و دعوت سایر افراد را به زمان دیگری موکول می‌کند START(["بازکردن بخش تیم مدیریت"]):::start MODEL["انتخاب مدل مدیریت ساختمان"]:::user UNKNOWN{"ساختار مدیریت هنوز مشخص نیست؟"}:::decision INCOMPLETE(["ذخیره با وضعیت «در حال تکمیل»"]):::success SUGGEST["پیشنهاد Roleهای متناسب با مدل انتخاب‌شده"]:::system ASSIGN["انتخاب شخص موجود یا ثبت شخص جدید برای هر Role"]:::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["تأیید بسته دسترسی پیش‌فرض"]:::user EDIT["ویرایش Permissionهای گروه‌بندی‌شده"]:::user SENSITIVE{"Permission حساس تغییر کرده است؟"}:::decision WARNING["نمایش هشدار و دریافت تأیید"]:::system SAVE["ذخیره ساختار مدیریت"]:::system COMPLETE{"حداقل مدیر یا رئیس هیئت‌مدیره تعیین شده است؟"}:::decision REQUIRED["درخواست تعیین شخص مسئول"]:::error DONE(["بخش تکمیل‌شده؛ دعوت شرط تکمیل نیست"]):::success START --> MODEL --> UNKNOWN UNKNOWN -->|"بله"| INCOMPLETE UNKNOWN -->|"خیر"| SUGGEST --> ASSIGN --> 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 --> SENSITIVE SENSITIVE -->|"بله"| WARNING --> SAVE SENSITIVE -->|"خیر"| SAVE 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ها مسیر پیشرفته است.

۹. OBM-UF-05 — تعیین کارکنان و دسترسی پایه

شناسنامه

  • بازیگر اصلی: مدیر راه‌اندازی
  • هدف: تعریف انواع نیروی موردنیاز و 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 — آغاز تنظیمات مالی

شناسنامه

  • بازیگر اصلی: مدیر راه‌اندازی
  • هدف: فعال‌سازی پرداخت آنلاین پیش‌فرض و در صورت نیاز واریز بانکی با تأیید قبض
  • شروع: انتخاب بخش «تنظیمات مالی و شارژ»
  • پایان موفق: تنظیمات اولیه ذخیره شده یا تصمیم «بعداً» ثبت شده است
  • خارج از محدوده: ساخت و انتشار Charge، Bill و Expense
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;

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

  • بازکردن این بخش هیچ Charge، Bill یا Expense ایجاد نمی‌کند.
  • پرداخت آنلاین روش پیش‌فرض است، اما بدون مقصد تسویه معتبر فعال نمی‌شود.
  • مدیر می‌تواند واریز بانکی را در کنار پرداخت آنلاین فعال کند.
  • کارت‌به‌کارت و حساب‌به‌حساب هر دو به ارسال قبض و تأیید مدیر یا Role مالی مجاز وابسته‌اند.
  • مانده واحد فقط پس از تأیید معتبر Provider یا تأیید قبض کاهش می‌یابد.
  • Schedule شارژ تکرارشونده فقط Draft می‌سازد و Publish نیازمند تأیید مدیر است؛ این منطق متعلق به ماژول مالی است.

۱۰.۱. 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 — تعریف امکانات و قواعد استفاده

شناسنامه

  • بازیگر اصلی: مدیر راه‌اندازی
  • هدف: ثبت امکانات و حداقل قواعد لازم برای فعال‌سازی هرکدام
  • شروع: انتخاب بخش «امکانات و تنظیمات تکمیلی»
  • پایان موفق: نبود امکانات ثبت شده یا تمام امکانات انتخاب‌شده فعال‌اند
flowchart TD accTitle: تعریف امکانات و قواعد استفاده accDescr: مدیر نبود امکانات را ثبت می‌کند یا برای هر امکان قواعد مستقل استفاده و رزرو را تعیین می‌کند START(["بازکردن بخش امکانات"]):::start HAS_FACILITY{"ساختمان امکانات دارد؟"}:::decision NONE["ثبت «ساختمان امکانات ندارد»"]:::user DISABLED(["تکمیل بخش و غیرفعال‌ماندن ماژول رزرو"]):::success SELECT["انتخاب امکان پیشنهادی یا تعریف امکان سفارشی"]:::user DRAFT["ایجاد امکان در وضعیت Draft"]:::system USAGE["تعیین مدل استفاده یا رزرو"]:::user AUDIENCE["تعیین گروه‌های مجاز"]:::user PRICING["تعیین مدل قیمت‌گذاری"]:::user RULES["تعیین زمان‌بندی، ظرفیت، محدودیت و قواعد لغو"]:::user APPROVER["تعیین Role مدیریت یا تأییدکننده"]:::user VALID{"حداقل قواعد و دسترسی تأییدکننده معتبر است؟"}:::decision INCOMPLETE["حفظ امکان در Draft و نمایش موارد ناقص"]:::error ACTIVATE["تأیید مدیر و فعال‌سازی امکان"]:::system MORE{"امکان دیگری باقی مانده است؟"}:::decision DONE(["همه امکانات انتخاب‌شده فعال هستند"]):::success START --> HAS_FACILITY HAS_FACILITY -->|"خیر"| NONE --> DISABLED HAS_FACILITY -->|"بله"| SELECT --> DRAFT DRAFT --> USAGE --> AUDIENCE --> PRICING --> RULES --> APPROVER --> VALID VALID -->|"خیر"| INCOMPLETE INCOMPLETE -.->|"تکمیل تنظیمات"| USAGE 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;

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

  • انتخاب نام یک امکان به‌تنهایی آن را فعال نمی‌کند.
  • هر امکان قواعد مستقل دارد و تا تکمیل حداقل تنظیمات در Draft باقی می‌ماند.
  • کاتالوگ، امکانات ورزشی، گردهمایی، فضای باز، پارکینگ، خدمات مشترک، زیرساخت و ایمنی را پوشش می‌دهد.
  • امکانات رزروپذیر تنظیمات رزرو و قیمت دارند؛ زیرساخت‌ها مشخصات، وضعیت و برنامه نگهداری دارند.
  • تعیین تأییدکننده دسترسی جدید ایجاد نمی‌کند و به Role و Permission معتبر وابسته است.

۱۲. 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 برای دسترس‌پذیری هر نمودار.

منابع مرجع:

بازگشت