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

گردش‌کارها و وضعیت‌ها

وضعیت سند

آماده بازبینی محصول — استخراج‌شده از سناریوهای SET-01 تا SET-06، MEM-01 تا MEM-05 و User Flowهای OBM-UF-01 تا OBM-UF-12.

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

این سند چرخه عمر موجودیت‌ها، Transitionهای مجاز، فرایندهای Async و هماهنگی میان Actorها و سامانه‌ها را تعریف می‌کند.

  • مسیر قابل مشاهده یک کاربر در سند «جریان‌های کاربر» قرار دارد.
  • ساختار موجودیت‌ها و روابط آن‌ها متعلق به Domain Model است.
  • جزئیات Permissionها در سند «دسترسی‌ها» تعریف می‌شوند.
  • متن و زمان اعلان‌ها در سند «اعلان‌ها» تعریف می‌شوند.
  • چیدمان صفحه یا کنترل رابط کاربری در این سند تعریف نمی‌شود.

۲. اصل تفکیک وضعیت‌ها

وضعیت‌هایی که مستقل از هم تغییر می‌کنند نباید در یک State Machine ادغام شوند.

به‌طور مشخص:

  • وضعیت Invitation Envelope از وضعیت Delivery پیامک مستقل است.
  • وضعیت Delivery Attempt از وضعیت Batch مستقل است.
  • وضعیت پذیرش Role از Membership عملیاتی مستقل است.
  • Account Link از Unit Relationship مستقل است.
  • Payment از Provisioning ساختمان مستقل است.
  • وضعیت هر بخش Setup از وضعیت کلی ساختمان مستقل است.

در نتیجه، «پیامک ارسال شد» به معنی «Role پذیرفته شد» یا «Membership ایجاد شد» نیست.

۳. فهرست Workflowها

شناسه عنوان نوع موجودیت یا فرایند اصلی مرجع
OBM-WF-01 چرخه درخواست راه‌اندازی State Machine Setup Request SET-01 تا SET-04
OBM-WF-02 چرخه پرداخت State Machine Payment SET-04
OBM-WF-03 ایجاد ساختمان پس از پرداخت State + Sequence Provisioning Job SET-05
OBM-WF-04 وضعیت بخش‌های راه‌اندازی State Machine Setup Section SET-06
OBM-WF-05 ورود اطلاعات با Excel State Machine Import Attempt SET-06A
OBM-WF-06 فعال‌سازی امکانات State Machine Facility SET-06E
OBM-WF-07 چرخه Invitation Envelope State Machine Invitation Envelope MEM-01، MEM-03
OBM-WF-08 ارسال و تحویل پیامک دعوت State Machine Delivery Attempt و Batch MEM-01، MEM-03
OBM-WF-09 پذیرش و فعال‌سازی Role State Machine Role Assignment MEM-01، MEM-02
OBM-WF-10 پایان و جایگزینی رابطه State + Orchestration Unit Relationship یا Role Assignment MEM-04
OBM-WF-11 بررسی تغییر مدیر راه‌اندازی State Machine Support Ticket MEM-05
OBM-WF-12 جابه‌جایی اتمیک مدیر راه‌اندازی Sequence Role Assignmentها MEM-05
OBM-WF-13 ثبت و تأیید قبض واریز بانکی State Machine Manual Payment Receipt SET-06D

۴. قواعد سراسری

۴.۱. Idempotency

  • هر Payment Request شناسه یکتا دارد.
  • هر پرداخت موفق حداکثر یک ساختمان ایجاد می‌کند.
  • Callback تکراری نتیجه ثبت‌شده قبلی را برمی‌گرداند.
  • Retry ایجاد ساختمان نباید Building، Subscription، Membership یا Role تکراری بسازد.
  • Retry دعوت باید از Envelope موجود استفاده کند.
  • Retry Import نباید داده ناقص یا رکورد تکراری ایجاد کند.

۴.۲. Audit

این رویدادها حداقل Audit می‌شوند:

  • ایجاد و تغییر Setup Request
  • ایجاد Payment و نتیجه اعتبارسنجی آن
  • ایجاد و فعال‌شدن ساختمان
  • تخصیص Role به خود مدیر راه‌اندازی
  • تغییر Role Template و Permission حساس
  • ایجاد، ویرایش، ارسال مجدد و لغو Invitation
  • پذیرش یا رد Role حساس
  • ارسال، تأیید یا رد قبض واریز بانکی و اثر آن بر Unit Ledger
  • پایان و جایگزینی رابطه یا Role
  • تعلیق یا تغییر مدیر راه‌اندازی

۴.۳. اعلان به‌عنوان Side Effect

شکست ارسال SMS یا اعلان، Transition اصلی موجودیت را Rollback نمی‌کند؛ مگر Business Rule همان Workflow صریحاً ارسال موفق را شرط ادامه قرار داده باشد.

۵. OBM-WF-01 — چرخه درخواست راه‌اندازی

شناسنامه

  • موجودیت: Setup Request
  • شروع: انتخاب «ثبت ساختمان جدید»
  • پایان موفق: پرداخت معتبر به درخواست متصل شده است
  • پایان بدون خرید: درخواست پیش از پرداخت رها یا لغو شده است
  • User Flow مرجع: OBM-UF-01

وضعیت‌ها

کد عنوان تعریف
DRAFT پیش‌نویس درخواست ایجاد شده اما اطلاعات پایه کامل نیست
BASE_INFO_COMPLETED اطلاعات پایه کامل نام و تعداد معتبر واحدها ثبت شده‌اند
QUOTED قیمت‌گذاری‌شده دوره و محاسبات معتبر ثبت شده‌اند
PAYMENT_IN_PROGRESS پرداخت در جریان Payment Request برای آخرین قیمت معتبر ایجاد شده است
PAID پرداخت‌شده پرداخت معتبر و موفق به درخواست متصل است
CANCELED لغوشده ادامه درخواست پیش از پرداخت متوقف شده است
stateDiagram-v2 accTitle: چرخه درخواست راه‌اندازی ساختمان accDescr: درخواست از پیش‌نویس به اطلاعات کامل، قیمت‌گذاری، پرداخت و وضعیت پرداخت‌شده می‌رود state "پیش‌نویس" as DRAFT state "اطلاعات پایه کامل" as BASE_INFO_COMPLETED state "قیمت‌گذاری‌شده" as QUOTED state "پرداخت در جریان" as PAYMENT_IN_PROGRESS state "پرداخت‌شده" as PAID state "لغوشده" as CANCELED [*] --> DRAFT DRAFT --> BASE_INFO_COMPLETED: ثبت نام و حداقل ۲ واحد BASE_INFO_COMPLETED --> DRAFT: ناقص یا نامعتبرشدن اطلاعات BASE_INFO_COMPLETED --> QUOTED: انتخاب دوره و ثبت قیمت QUOTED --> BASE_INFO_COMPLETED: تغییر تعداد واحدها QUOTED --> PAYMENT_IN_PROGRESS: ایجاد Payment Request PAYMENT_IN_PROGRESS --> QUOTED: لغو یا شکست پرداخت PAYMENT_IN_PROGRESS --> PAID: اتصال پرداخت معتبر DRAFT --> CANCELED: لغو درخواست BASE_INFO_COMPLETED --> CANCELED: لغو درخواست QUOTED --> CANCELED: لغو درخواست PAID --> [*] CANCELED --> [*]

Transitionهای کلیدی

از Event Guard به Side Effect
DRAFT ثبت اطلاعات پایه مجموع واحدها حداقل ۲ است BASE_INFO_COMPLETED ذخیره آخرین اطلاعات معتبر
BASE_INFO_COMPLETED ثبت قیمت تعرفه معتبر موجود است QUOTED ثبت دوره، تخفیف و شارژ اولیه پیامک
QUOTED شروع پرداخت قیمت همچنان معتبر است PAYMENT_IN_PROGRESS ایجاد Payment یکتا
PAYMENT_IN_PROGRESS پرداخت معتبر مبلغ و درخواست منطبق‌اند PAID آغاز OBM-WF-03

Transitionهای ممنوع

  • DRAFT مستقیم به PAID
  • QUOTED مستقیم به ایجاد ساختمان
  • تغییر اطلاعات قیمت‌گذاری پس از PAID در همان درخواست

۶. OBM-WF-02 — چرخه پرداخت

وضعیت‌ها

کد عنوان نوع
CREATED ایجادشده پایدار کوتاه‌مدت
REDIRECTED منتقل‌شده به درگاه موقت
VERIFYING در حال اعتبارسنجی موقت
UNDER_REVIEW در حال بررسی پایدار موقت
SUCCEEDED موفق پایانی
FAILED ناموفق پایانی برای همان تلاش
CANCELED لغوشده توسط کاربر پایانی برای همان تلاش
AMOUNT_MISMATCH مغایرت مبلغ خطای پایانی و نیازمند بررسی
stateDiagram-v2 accTitle: چرخه وضعیت پرداخت accDescr: پرداخت از ایجاد و انتقال به درگاه به اعتبارسنجی و نتیجه موفق، ناموفق، لغو یا بررسی می‌رود state "ایجادشده" as CREATED state "منتقل‌شده به درگاه" as REDIRECTED state "در حال اعتبارسنجی" as VERIFYING state "در حال بررسی" as UNDER_REVIEW state "موفق" as SUCCEEDED state "ناموفق" as FAILED state "لغوشده" as CANCELED state "مغایرت مبلغ" as AMOUNT_MISMATCH [*] --> CREATED CREATED --> REDIRECTED: انتقال کاربر CREATED --> FAILED: ایجاد یا انتقال ناموفق REDIRECTED --> VERIFYING: بازگشت یا Callback REDIRECTED --> CANCELED: لغو در درگاه VERIFYING --> SUCCEEDED: نتیجه معتبر و مبلغ منطبق VERIFYING --> FAILED: نتیجه قطعی ناموفق VERIFYING --> UNDER_REVIEW: نتیجه نامشخص یا سرویس خارج از دسترس VERIFYING --> AMOUNT_MISMATCH: مبلغ نامنطبق UNDER_REVIEW --> VERIFYING: بررسی مجدد SUCCEEDED --> [*] FAILED --> [*] CANCELED --> [*] AMOUNT_MISMATCH --> [*]

قواعد Workflow

  • بازگشت کاربر از درگاه اثبات موفقیت نیست.
  • فقط اعتبارسنجی مستقیم سرویس پرداخت می‌تواند SUCCEEDED ایجاد کند.
  • Callback تکراری روی SUCCEEDED نتیجه قبلی را برمی‌گرداند و Side Effect را تکرار نمی‌کند.
  • UNDER_REVIEW نه موفق و نه ناموفق است.
  • تلاش مجدد کاربر Payment جدید می‌سازد، اما Setup Request قبلی را حفظ می‌کند.

۷. OBM-WF-03 — ایجاد ساختمان پس از پرداخت

وضعیت‌های Provisioning Job

کد عنوان تعریف
PENDING در انتظار پرداخت معتبر ثبت شده و Job هنوز آغاز نشده است
IN_PROGRESS در حال اجرا اجزای ضروری در حال ایجاد هستند
RETRYING تلاش مجدد بخشی از عملیات داخلی شکست خورده و Retry امن در جریان است
ACTIVE فعال همه اجزای ضروری ایجاد و ساختمان قابل استفاده است
stateDiagram-v2 accTitle: چرخه ایجاد ساختمان پس از پرداخت accDescr: Job پس از پرداخت معتبر آغاز می‌شود و تا ایجاد کامل ساختمان، اشتراک، عضویت و نقش مدیر ادامه دارد state "در انتظار" as PENDING state "در حال اجرا" as IN_PROGRESS state "تلاش مجدد" as RETRYING state "ساختمان فعال" as ACTIVE [*] --> PENDING: پرداخت معتبر PENDING --> IN_PROGRESS: شروع Job IN_PROGRESS --> ACTIVE: تکمیل همه اجزای ضروری IN_PROGRESS --> RETRYING: شکست داخلی RETRYING --> IN_PROGRESS: Retry امن ACTIVE --> [*]

توالی ایجاد

sequenceDiagram accTitle: توالی ایجاد ساختمان پس از پرداخت accDescr: تریپیلون پس از اعتبارسنجی پرداخت، ساختمان و اجزای ضروری را بدون ایجاد رکورد تکراری فعال می‌کند autonumber actor User as متقاضی participant Pay as سرویس پرداخت participant App as تریپیلون participant Provision as سرویس راه‌اندازی Pay-->>App: پرداخت معتبر و یکتا App-->>User: نمایش «در حال راه‌اندازی» App->>Provision: شروع با شناسه پرداخت critical ایجاد اجزای ضروری Provision->>Provision: کنترل عدم ایجاد ساختمان قبلی Provision->>Provision: ایجاد ساختمان و اشتراک Provision->>Provision: ایجاد Membership مدیر راه‌اندازی Provision->>Provision: تخصیص Role مدیر راه‌اندازی Provision->>Provision: تعیین Current Context و Setup Dashboard option شکست داخلی Provision->>Provision: حفظ پرداخت و Retry بدون رکورد تکراری end Provision-->>App: ساختمان فعال App-->>User: ورود به صفحه اصلی ساختمان

Invariantها

  • یک Payment موفق حداکثر یک Building و یک Subscription اولیه دارد.
  • ساختمان پیش از تکمیل Membership و Role مدیر راه‌اندازی قابل استفاده اعلام نمی‌شود.
  • در خطای داخلی، کاربر دوباره پرداخت نمی‌کند.
  • تاریخ شروع اشتراک در خطای داخلی به زمان فعال‌شدن واقعی منتقل می‌شود.

۸. OBM-WF-04 — وضعیت بخش‌های راه‌اندازی

وضعیت‌ها

کد عنوان معیار
NOT_STARTED شروع نشده هیچ تصمیم یا داده معتبری ثبت نشده است
IN_PROGRESS در حال تکمیل بخشی از داده ثبت شده، اما معیار تکمیل برقرار نیست
COMPLETED تکمیل‌شده معیار کامل بخش برقرار است
NOT_APPLICABLE در این ساختمان وجود ندارد نبود کارکنان یا امکانات صریحاً ثبت شده است
DEFERRED فعلاً تکمیل‌شده مدیر آگاهانه ادامه را به بعد موکول کرده است
stateDiagram-v2 accTitle: چرخه وضعیت هر بخش راه‌اندازی accDescr: هر بخش از شروع‌نشده به در حال تکمیل و سپس یکی از پایان‌های تکمیل، نامرتبط یا موکول‌شده می‌رود state "شروع نشده" as NOT_STARTED state "در حال تکمیل" as IN_PROGRESS state "تکمیل‌شده" as COMPLETED state "در این ساختمان وجود ندارد" as NOT_APPLICABLE state "فعلاً تکمیل‌شده" as DEFERRED [*] --> NOT_STARTED NOT_STARTED --> IN_PROGRESS: ثبت اولین داده یا تصمیم ناقص NOT_STARTED --> NOT_APPLICABLE: ثبت نبود قابلیت NOT_STARTED --> DEFERRED: انتخاب «بعداً» IN_PROGRESS --> COMPLETED: برقراری معیار تکمیل IN_PROGRESS --> NOT_APPLICABLE: ثبت نبود قابلیت IN_PROGRESS --> DEFERRED: موکول‌کردن ادامه COMPLETED --> IN_PROGRESS: تغییر داده و نقض معیار تکمیل NOT_APPLICABLE --> IN_PROGRESS: افزودن قابلیت DEFERRED --> IN_PROGRESS: ادامه تنظیمات

قواعد محاسبه پیشرفت

  • وضعیت هر بخش مستقل محاسبه می‌شود.
  • COMPLETED، NOT_APPLICABLE و DEFERRED برای شمارش «بخش حل‌شده» محسوب می‌شوند.
  • DEFERRED به معنی فعال‌بودن قابلیت وابسته نیست.
  • تغییر داده‌ای که معیار تکمیل را نقض کند، بخش را به IN_PROGRESS بازمی‌گرداند.
  • تکمیل همه بخش‌ها بر تاریخ شروع اشتراک اثر ندارد.

۹. OBM-WF-05 — ورود اطلاعات با Excel

وضعیت‌ها

کد عنوان
UPLOADED بارگذاری‌شده
VALIDATING در حال اعتبارسنجی
BLOCKED متوقف به‌علت خطای مسدودکننده
READY_FOR_CONFIRMATION آماده تأیید
IMPORTING در حال ثبت
COMPLETED تکمیل‌شده
FAILED شکست ثبت نهایی
stateDiagram-v2 accTitle: چرخه ورود واحدها و ساکنان با Excel accDescr: فایل بارگذاری و اعتبارسنجی می‌شود و فقط پس از نبود خطای مسدودکننده و تأیید مدیر ثبت می‌شود state "بارگذاری‌شده" as UPLOADED state "در حال اعتبارسنجی" as VALIDATING state "متوقف با خطای مسدودکننده" as BLOCKED state "آماده تأیید" as READY_FOR_CONFIRMATION state "در حال ثبت" as IMPORTING state "تکمیل‌شده" as COMPLETED state "شکست ثبت نهایی" as FAILED [*] --> UPLOADED UPLOADED --> VALIDATING: شروع اعتبارسنجی VALIDATING --> BLOCKED: وجود خطای مسدودکننده VALIDATING --> READY_FOR_CONFIRMATION: نبود خطای مسدودکننده BLOCKED --> [*]: پایان این Attempt READY_FOR_CONFIRMATION --> IMPORTING: تأیید مدیر IMPORTING --> COMPLETED: ثبت یکپارچه موفق IMPORTING --> FAILED: شکست ثبت FAILED --> IMPORTING: Retry امن COMPLETED --> [*]

Invariantها

  • هر Upload جدید Import Attempt جدید می‌سازد.
  • Warning مانع READY_FOR_CONFIRMATION نیست.
  • خطای مسدودکننده هیچ داده نهایی ایجاد نمی‌کند.
  • Import نهایی All-or-Nothing است.
  • Import موفق Invitation یا SMS ایجاد نمی‌کند.

۱۰. OBM-WF-06 — فعال‌سازی امکانات

وضعیت‌های قطعی نسخه فعلی

کد عنوان تعریف
DRAFT پیش‌نویس امکان ایجاد شده اما حداقل قواعد کامل یا تأیید نشده‌اند
ACTIVE فعال حداقل قواعد معتبرند و مدیر فعال‌سازی را تأیید کرده است
stateDiagram-v2 accTitle: چرخه فعال‌سازی امکان ساختمان accDescr: امکان ابتدا در پیش‌نویس ایجاد و پس از تکمیل قواعد و تأیید مدیر فعال می‌شود state "پیش‌نویس" as DRAFT state "فعال" as ACTIVE [*] --> DRAFT: انتخاب یا ایجاد امکان DRAFT --> DRAFT: ذخیره تنظیمات ناقص DRAFT --> ACTIVE: تکمیل قواعد و تأیید مدیر

Guard فعال‌سازی

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

تصمیم باز

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

۱۱. OBM-WF-07 — چرخه Invitation Envelope

تصمیم مدل‌سازی

فهرست سناریوها وضعیت‌های Envelope، Delivery و Role Acceptance را کنار هم نام برده است، اما همان سناریو استقلال آن‌ها را الزام می‌کند. مدل مرجع به سه State Machine مستقل تفکیک می‌شود.

وضعیت‌های Envelope

کد عنوان تعریف
DRAFT پیش‌نویس Envelope ساخته یا ویرایش شده، اما برای استفاده فعال نیست
ACTIVE فعال Envelope معتبر است و می‌تواند برای ورود یا تصمیم Role استفاده شود
COMPLETED تکمیل‌شده همه Roleهای نیازمند تصمیم تعیین تکلیف شده‌اند یا فقط اتصال عادی انجام شده است
CANCELED لغوشده مدیر استفاده بعدی از Envelope را متوقف کرده است
stateDiagram-v2 accTitle: چرخه Invitation Envelope accDescr: دعوت‌نامه از پیش‌نویس به فعال می‌رود و با تعیین تکلیف نقش‌ها تکمیل یا توسط مدیر لغو می‌شود state "پیش‌نویس" as DRAFT state "فعال" as ACTIVE state "تکمیل‌شده" as COMPLETED state "لغوشده" as CANCELED [*] --> DRAFT DRAFT --> DRAFT: ویرایش Role یا Scope DRAFT --> ACTIVE: تأیید برای ارسال یا استفاده ACTIVE --> ACTIVE: Resend روی همان Envelope ACTIVE --> COMPLETED: تعیین تکلیف همه Roleها یا اتصال عادی DRAFT --> CANCELED: لغو مدیر ACTIVE --> CANCELED: لغو مدیر پیش از تکمیل COMPLETED --> [*] CANCELED --> [*]

قواعد

  • Envelope انقضای کسب‌وکاری ندارد.
  • Resend وضعیت Envelope را تغییر نمی‌دهد و فقط Delivery Attempt جدید می‌سازد.
  • ویرایش Role فعال از مسیر Envelope مجاز نیست.
  • لغو Envelope، Membership، Unit Relationship یا Role فعال را حذف نمی‌کند.
  • Role حساس لغوشده برای فعال‌شدن به Envelope جدید نیاز دارد.

۱۲. OBM-WF-08 — ارسال و تحویل پیامک دعوت

Delivery Attempt

کد عنوان
CREATED ایجادشده
SENT ارسال‌شده
DELIVERY_FAILED ارسال یا تحویل ناموفق
stateDiagram-v2 accTitle: چرخه هر تلاش ارسال پیامک دعوت accDescr: برای هر ارسال یا ارسال مجدد یک تلاش مستقل ایجاد و نتیجه آن موفق یا ناموفق ثبت می‌شود state "ایجادشده" as CREATED state "ارسال‌شده" as SENT state "ناموفق" as DELIVERY_FAILED [*] --> CREATED CREATED --> SENT: پذیرش ارسال توسط سرویس پیامک CREATED --> DELIVERY_FAILED: شکست ارسال SENT --> [*] DELIVERY_FAILED --> [*]

وضعیت مشتق‌شده Batch

وضعیت قاعده
COMPLETED همه گیرندگان Attempt موفق دارند
PARTIALLY_FAILED حداقل یک موفق و حداقل یک ناموفق وجود دارد
FAILED هیچ ارسال موفقی وجود ندارد
NOT_SENT به‌دلیل کمبود موجودی، Attempt آغاز نشده است

قواعد

  • کمبود موجودی پیش از شروع باعث می‌شود هیچ Attempt ساخته نشود.
  • موفقیت بخشی Rollback نمی‌شود.
  • Retry فقط برای گیرندگان ناموفق، Attempt جدید می‌سازد.
  • حداقل فاصله Resend برای یک Envelope و شخص ۲۴ ساعت است.
  • Delivery موفق هیچ Role را فعال نمی‌کند.

۱۳. OBM-WF-09 — پذیرش و فعال‌سازی Role

وضعیت‌ها

کد عنوان تعریف
PENDING_ACCEPTANCE در انتظار پذیرش Role پیشنهاد شده اما Permission فعال ندارد
ACTIVE فعال شخص Role را پذیرفته و Scope معتبر است
REJECTED ردشده شخص Role را رد کرده است
CANCELED لغوشده مدیر پیش از پذیرش، امکان پذیرش را متوقف کرده است
INVALIDATED نامعتبرشده Role یا Scope پیش از پذیرش دیگر معتبر نیست
ENDED پایان‌یافته Role فعال با Effective End Date خاتمه یافته است
stateDiagram-v2 accTitle: چرخه پذیرش و فعال‌سازی نقش accDescr: نقش حساس در انتظار پذیرش است و پس از تصمیم شخص فعال یا رد می‌شود و می‌تواند بعداً پایان یابد state "در انتظار پذیرش" as PENDING_ACCEPTANCE state "فعال" as ACTIVE state "ردشده" as REJECTED state "لغوشده" as CANCELED state "نامعتبرشده" as INVALIDATED state "پایان‌یافته" as ENDED [*] --> PENDING_ACCEPTANCE PENDING_ACCEPTANCE --> ACTIVE: پذیرش شخص و Scope معتبر PENDING_ACCEPTANCE --> REJECTED: رد شخص PENDING_ACCEPTANCE --> CANCELED: لغو مدیر PENDING_ACCEPTANCE --> INVALIDATED: نامعتبرشدن Role یا Scope ACTIVE --> ENDED: پایان با Effective Date ACTIVE --> ACTIVE: تغییر Role Template ساختمان REJECTED --> [*] CANCELED --> [*] INVALIDATED --> [*] ENDED --> [*]

Invariantها

  • PENDING_ACCEPTANCE هیچ Permission فعالی ندارد.
  • هر Role داخل Envelope مستقل پذیرفته یا رد می‌شود.
  • رد Role، Membership و Unit Relationship را تغییر نمی‌دهد.
  • تغییر Role Template بر Roleهای فعال همان نوع اثر دارد، اما State آن‌ها را تغییر نمی‌دهد.

۱۴. OBM-WF-10 — پایان و جایگزینی رابطه

چرخه رابطه

کد عنوان تعریف
ACTIVE فعال رابطه در تاریخ جاری معتبر است
END_SCHEDULED پایان برنامه‌ریزی‌شده End Date آینده ثبت شده است
ENDED پایان‌یافته Effective End Date رسیده و Scope مرتبط غیرفعال شده است
stateDiagram-v2 accTitle: چرخه پایان رابطه شخص با واحد یا نقش accDescr: رابطه فعال می‌تواند برای آینده پایان‌گذاری شود و در تاریخ مؤثر بدون حذف تاریخچه پایان یابد state "فعال" as ACTIVE state "پایان برنامه‌ریزی‌شده" as END_SCHEDULED state "پایان‌یافته" as ENDED [*] --> ACTIVE ACTIVE --> END_SCHEDULED: ثبت End Date آینده ACTIVE --> ENDED: ثبت End Date جاری یا گذشته END_SCHEDULED --> ACTIVE: لغو پایان پیش از تاریخ مؤثر END_SCHEDULED --> ENDED: رسیدن Effective Date ENDED --> [*]

Orchestration جایگزینی

sequenceDiagram accTitle: پایان رابطه قبلی و ایجاد رابطه جایگزین accDescr: تریپیلون وابستگی‌ها را بررسی و پایان رابطه قبلی و ایجاد رابطه جدید را به‌صورت اتمیک انجام می‌دهد autonumber actor Manager as مدیر مجاز participant App as تریپیلون participant Ledger as دفتر مالی واحد participant Access as سرویس دسترسی Manager->>App: ثبت نوع تغییر و Effective Date App->>App: اعتبارسنجی تداخل تاریخ‌ها و روابط alt مستأجر App->>App: شناسایی Household وابسته App->>Ledger: بررسی مانده Unit Ledger else مالک App->>Ledger: دریافت مانده و صورت بدهی else کارکن یا سرویس‌کار App->>App: بررسی Task و Shiftهای باز end critical پایان قبلی و ایجاد رابطه جدید App->>App: پایان Relationship یا Role قبلی App->>App: ایجاد Relationship یا Role جدید App->>Access: اصلاح Scopeهای معتبر option شکست هر بخش App->>App: Rollback یا Retry امن end App-->>Manager: نتیجه نهایی و وضعیت دعوت شخص جدید

قواعد

  • Person و Account حذف نمی‌شوند.
  • پایان مستأجر، Household وابسته را با هم پایان می‌دهد.
  • بدهی روی Unit Ledger باقی می‌ماند.
  • Task و Shift باز پیش از پایان Role کارکن تعیین تکلیف می‌شوند.
  • پایان Scope واحد، Scopeهای نامرتبط شخص را غیرفعال نمی‌کند.
  • Close Old و Create New باید اتمیک یا قابل بازیابی باشند.

Warning

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

۱۵. OBM-WF-11 — بررسی تغییر مدیر راه‌اندازی

وضعیت‌های Ticket

کد عنوان نوع
OPEN باز شروع
NEEDS_INFO نیازمند اطلاعات انتظار اقدام درخواست‌کننده
UNDER_REVIEW در حال بررسی بررسی دستی
APPROVED تأییدشده انتظار پذیرش مدیر پیشنهادی
REJECTED ردشده پایانی
COMPLETED تکمیل‌شده پایانی
CANCELED لغوشده پایانی
stateDiagram-v2 accTitle: چرخه Ticket تغییر مدیر راه‌اندازی accDescr: درخواست از حالت باز به تکمیل اطلاعات و بررسی می‌رود و سپس تأیید، رد، تکمیل یا لغو می‌شود state "باز" as OPEN state "نیازمند اطلاعات" as NEEDS_INFO state "در حال بررسی" as UNDER_REVIEW state "تأییدشده" as APPROVED state "ردشده" as REJECTED state "تکمیل‌شده" as COMPLETED state "لغوشده" as CANCELED [*] --> OPEN OPEN --> NEEDS_INFO: مدارک ناقص OPEN --> UNDER_REVIEW: مدارک اولیه کامل NEEDS_INFO --> UNDER_REVIEW: تکمیل مدارک NEEDS_INFO --> CANCELED: لغو یا عدم ادامه UNDER_REVIEW --> NEEDS_INFO: نیاز به مدرک بیشتر UNDER_REVIEW --> APPROVED: تأیید دستی UNDER_REVIEW --> REJECTED: رد با دلیل APPROVED --> COMPLETED: پذیرش مدیر جدید و Switch موفق APPROVED --> CANCELED: انصراف یا ابطال پیش از Switch REJECTED --> [*] COMPLETED --> [*] CANCELED --> [*]

قواعد

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

۱۶. OBM-WF-12 — جابه‌جایی اتمیک مدیر راه‌اندازی

sequenceDiagram accTitle: جابه‌جایی اتمیک مدیر راه‌اندازی accDescr: پس از تأیید Ticket و پذیرش شخص جدید، نقش مدیر قبلی سلب و نقش مدیر جدید به‌صورت اتمیک فعال می‌شود autonumber actor NewManager as مدیر پیشنهادی participant App as تریپیلون participant Ticket as سرویس پشتیبانی participant Access as سرویس دسترسی participant Audit as گزارش فعالیت‌ها Ticket->>App: Ticket تأییدشده App->>Access: ایجاد Role در انتظار پذیرش App-->>NewManager: امکان ورود و پذیرش Role NewManager->>App: پذیرش Role با هویت تأییدشده App->>Access: کنترل معتبرماندن Ticket و Scope critical جابه‌جایی مدیر Access->>Access: سلب Role مدیر قبلی Access->>Access: فعال‌سازی Role مدیر جدید Access->>Audit: ثبت Actor، زمان و وضعیت قبل و بعد option شکست عملیات Access->>Access: Rollback به مدیر قبلی و Retry امن end Access-->>App: نتیجه جابه‌جایی App->>Ticket: ثبت COMPLETED App-->>NewManager: نمایش دسترسی فعال

Invariantها

  • پیش از پذیرش مدیر جدید، Role مدیر فعلی حفظ می‌شود.
  • نتیجه عملیات یا «مدیر قبلی فعال» است یا «مدیر جدید فعال»؛ حالت بدون مدیر مجاز نیست.
  • Roleهای دیگر مدیر قبلی حذف نمی‌شوند.
  • درخواست تکراری Switch نتیجه قبلی را برمی‌گرداند.
  • Suspension اضطراری باید Actor، دلیل و زمان داشته باشد.

۱۶.۱. OBM-WF-13 — ثبت و تأیید قبض واریز بانکی

وضعیت‌ها

کد عنوان اثر بر مانده
DRAFT پیش‌نویس بدون اثر
SUBMITTED ارسال‌شده بدون اثر
UNDER_REVIEW در حال بررسی بدون اثر
NEEDS_CORRECTION نیازمند اصلاح بدون اثر
REJECTED ردشده بدون اثر
APPROVED تأییدشده آماده ثبت Payment
APPLIED اعمال‌شده مانده Unit Ledger کاهش یافته است
stateDiagram-v2 accTitle: چرخه قبض واریز بانکی accDescr: قبض پس از ارسال و بررسی مدیر فقط در صورت تأیید به Payment تبدیل و روی مانده واحد اعمال می‌شود state "پیش‌نویس" as DRAFT state "ارسال‌شده" as SUBMITTED state "در حال بررسی" as UNDER_REVIEW state "نیازمند اصلاح" as NEEDS_CORRECTION state "ردشده" as REJECTED state "تأییدشده" as APPROVED state "اعمال‌شده" as APPLIED [*] --> DRAFT DRAFT --> SUBMITTED: ثبت مبلغ، تاریخ، پیگیری و فایل SUBMITTED --> UNDER_REVIEW: ورود به صف بررسی UNDER_REVIEW --> NEEDS_CORRECTION: اطلاعات ناقص یا ناخوانا NEEDS_CORRECTION --> SUBMITTED: اصلاح و ارسال مجدد UNDER_REVIEW --> REJECTED: رد با دلیل UNDER_REVIEW --> APPROVED: تأیید Role مالی مجاز APPROVED --> APPLIED: ثبت Payment و تخصیص به Bill REJECTED --> [*] APPLIED --> [*]

Invariantها

  • هیچ وضعیت پیش از APPLIED مانده Unit Ledger را کاهش نمی‌دهد.
  • Transition از APPROVED به APPLIED باید با شناسه قبض idempotent باشد.
  • قبض تأییدشده به یک Payment و تخصیص مشخص به Bill یا مانده واحد متصل می‌شود.
  • تأییدکننده نباید همان پرداخت‌کننده باشد، مگر Policy ساختمان صریحاً اجازه دهد.
  • تغییر فایل یا مبلغ پس از UNDER_REVIEW نیازمند بازگشت به NEEDS_CORRECTION و ارسال مجدد است.
  • رد قبض باید دلیل قابل مشاهده برای پرداخت‌کننده داشته باشد.

۱۷. Transitionهای ممنوع سراسری

موجودیت Transition ممنوع
Setup Request ایجاد ساختمان پیش از PAID
Payment FAILED به SUCCEEDED بدون اعتبارسنجی مجدد
Provisioning دریافت وجه مجدد برای Retry داخلی
Setup Section اعلام COMPLETED بدون معیار معتبر همان بخش
Import Attempt ثبت بخشی از فایل دارای خطای مسدودکننده
Facility DRAFT به ACTIVE بدون Guardهای کامل
Manual Payment Receipt SUBMITTED یا UNDER_REVIEW به کاهش مانده بدون APPROVED و ثبت Payment
Invitation Envelope فعال‌سازی مجدد CANCELED بدون Envelope جدید
Delivery Attempt تغییر نتیجه Attempt قبلی به‌جای ساخت Attempt جدید برای Retry
Role Assignment PENDING_ACCEPTANCE به ACTIVE بدون پذیرش و Scope معتبر
Relationship حذف Person یا Account برای پایان رابطه
Support Ticket APPROVED به COMPLETED پیش از پذیرش و Switch موفق
Manager Switch سلب مدیر قبلی بدون فعال‌سازی اتمیک مدیر جدید، مگر Suspension اضطراری

۱۸. تصمیم‌های باز

شناسه موضوع اثر
OPEN-WF-01 نام نهایی وضعیت‌های Envelope پیش از پیاده‌سازی با Domain Model هماهنگ شود
OPEN-WF-02 وضعیت‌های غیرفعال‌سازی و آرشیو Facility به طراحی ماژول رزرو وابسته است
OPEN-WF-03 سیاست Timeout و Retry خودکار Payment در UNDER_REVIEW SLA عملیاتی باید تعیین شود
OPEN-WF-04 سیاست Retry و هشدار Provisioning طولانی SLA و Escalation باید تعیین شود
OPEN-LEGAL-01 مسئولیت مالک جاری برای بدهی واحد نیازمند بررسی حقوقی
OPEN-LEGAL-02 شمارش و اولویت حمایت مالکان برای تغییر مدیر نیازمند بررسی حقوقی

۱۹. معیارهای پذیرش

  • Payment از Setup Request و Provisioning جدا شده است.
  • Invitation، Delivery و Role Acceptance سه Lifecycle مستقل دارند.
  • Membership عملیاتی به پذیرش Invitation وابسته نشده است.
  • تمام Workflowهای دارای Retry، رفتار ضدتکرار دارند.
  • ایجاد ساختمان و تغییر مدیر مرز اتمیک یا Rollback دارند.
  • پایان رابطه با Effective Date انجام می‌شود و Person حذف نمی‌شود.
  • Transitionهای ممنوع ثبت شده‌اند.
  • Workflowها به سناریو و User Flow مرجع متصل‌اند.
  • نمودارها دارای عنوان و توضیح دسترس‌پذیر هستند.
  • SLA پرداخت در حال بررسی تعیین شود.
  • SLA راه‌اندازی طولانی و Escalation آن تعیین شود.
  • تصمیم‌های حقوقی پیش از اجرا تأیید شوند.
  • نام وضعیت‌ها با Domain Model فنی نهایی تطبیق داده شود.

۲۰. منابع مرجع Mermaid

بازگشت