شرط

چه زمانی استفاده کنیم؟

خطاهای رایج

• «کوچک‌تر از» به جای «کوچک‌تر یا مساوی» برای صفر

  اگر می‌خواهید حالت «صفر» هم در شاخهٔ true بیفتد (مثلاً «ماندهٔ بدهی ۰ یا منفی = تسویه شده»)، حتماً اپراتور «کوچک‌تر یا مساوی» (`<=`) را با مقدار `0` انتخاب کنید، نه «کوچک‌تر از» (`<`). چون `0 < 0` نادرست است و شرط برقرار نمی‌شود.
• مقایسهٔ عدد و رشته

  برای عملگرهای متنی (مساوی/شامل) مقدارها به‌صورت رشته مقایسه می‌شوند. اگر می‌خواهید اعداد را بسنجید حتماً از عملگرهای عددی استفاده کنید.
• شاخهٔ نادرست بدون اتصال

  هر دو شاخهٔ true/false را وصل کنید وگرنه نیمی از کاربرها در فلو گم می‌شوند.

نکات حرفه‌ای

• برای منطق پیچیده (AND/OR چند شرط) چند نود شرط را زنجیر کنید — خواناتر از یک شرط غول‌پیکر است.
• نیازی به فیلتر دستی برای تبدیل ارقام فارسی به انگلیسی در مقادیر عددی نیست؛ خود نود شرط نرمال‌سازی می‌کند.
• برای گیت‌هایی که باید بین نشست‌ها پایدار بمانند (مثل «این خانواده قبلاً طرح تقسیط را انتخاب کرده؟»)، به‌جای افزودن یک فیلد گیت جداگانه، با `load_data` یا `get_record` همان فیلد منبع روی رکورد والد (مثلاً `family_o.installment_plan`) را بخوانید و با اپراتور «خالی نیست» (`is_set`) گیت بزنید. این کار از وجود فیلدهای حسابداری مضاعف جلوگیری می‌کند و وضعیت گیت همیشه با خود دادهٔ کاری همگام می‌ماند.
• اگر یک پیام «خلاصه» در چند مسیر مختلف (مسیر اول، بازگشت از منو، تأیید نذر، اعمال مجدد) به یک نود مشترک می‌رسد و وابسته به متغیرهای انباشتی مثل `total_tuition` یا `children_lines` است، پیش از آن یک نود `load_data` برای لود لیست منبع (مثلاً enrollments) و یک حلقهٔ بازمحاسبه (re-loop) قرار دهید و *همهٔ* یال‌های ورودی را از همان نود لود عبور دهید. اگر حتی یک مسیر مستقیم به نود خلاصه برسد، آن مسیر مقادیر را صفر/خالی نشان می‌دهد.
• قرارداد علامت برای فیلدهای «مانده»: فیلد فرمول `family_remaining_after_gateway` = `family_effective_balance - family_gateway_paid` است؛ مقدار *مثبت* یعنی کاربر هنوز بدهکار است و مقدار *منفی* یعنی کاربر طلبکار/اعتبار دارد. بنابراین برای کسر اعتبار از مبلغ این ثبت‌نام، در زنجیرهٔ محاسبهٔ `total_final` (پس از `b_sum_calc_final` و قبل از پیام خلاصه) دو `set_var` با mode=expression اضافه کنید: ابتدا `family_gw_credit = max(0, -family_o.family_remaining_after_gateway)` (با علامت منفی، تا فقط حالت طلبکار به مبلغ مثبت قابل کسر تبدیل شود و بدهی قبلی به‌اشتباه از شهریه جدید کم نشود)، سپس `total_payable_final = max(0, total_final - family_gw_credit)` (با `max(0,…)` که از منفی شدن مبلغ پرداختی جلوگیری می‌کند). در متن پیام خلاصه با فیلتر `sign:"بدهکار,طلبکار,تسویه"` روی `family_o.family_remaining_after_gateway` وضعیت کاربر را برچسب‌گذاری کنید و با فیلتر `abs` مبلغ آن را به شکل مثبت نمایش دهید. هیچ‌گاه فیلد فرمول را دوباره از DB نخوانید یا در فیلد جدا روی خانواده ذخیره نکنید.