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

نسخهٔ اصلاح‌شده

صفحهٔ اول فقط برای شناخت و انتخاب خدمات است:

عنوان کوتاه «خدمات چهارسو».
سه کارت خدمات: «ارتباط با کارشناسان»، «ارسال فیش واریزی» و «شماره حساب‌ها». کارت ارتباط با کارشناسان دو اقدام مستقل و مشخص دارد: ثبت درخواست جدید و مشاهده درخواست‌های من.
هیچ فهرست درخواست، آمار درخواست‌ها، بخش «پیگیری‌ها» یا یادآوری تکمیل پروفایل در خانه نمایش داده نمی‌شود.
بنر بزرگ و خوشامدگویی جدا حذف شده‌اند تا خدمات بالاتر دیده شوند.
نوار پایین به سه مقصد «خدمات، درخواست‌ها، پروفایل» محدود شده؛ خانه و خدمات یک مقصد هستند.
«درخواست‌های من» نمای جدا در همین نمونه دارد؛ انتخاب کارت یا منو آن را باز می‌کند. بازگشت به خدمات و دکمه‌های Back/Forward مرورگر کار می‌کنند.
وضعیت خدمات مالی آینده با «به‌زودی» مشخص است؛ کلیک روی آن‌ها به دو فایل HTML مستقل می‌رود؛ هیچ پنجرهٔ modal برای خدمات مالی باز نمی‌شود.

نام چهارسو محدودیتی برای تعداد خدمات ایجاد نمی‌کند. خدمات بعدی می‌توانند به شبکهٔ کارت‌ها اضافه شوند؛ برای هر خدمت جدید نیازی به افزودن گزینه به نوار پایین نیست.

فایل‌های بازبینی

index.html: نمونهٔ تعاملی خانه
payment-receipt.html: صفحهٔ مستقل ارسال فیش واریزی
bank-accounts.html: صفحهٔ مستقل شماره حساب‌ها
service-pages.css: سبک‌های مشترک دو صفحهٔ خدمات مالی
receipt-mobile.png و accounts-mobile.png: تصاویر موبایل صفحات مالی
mobile.png: صفحهٔ نخست موبایل
desktop.png: صفحهٔ نخست دسکتاپ
requests-mobile.png: نمای مستقل درخواست‌ها

نمای جدا در نمونه با index.html#requests نیز باز می‌شود. این یک مسیر اجرایی جدید در Django نیست.

مبنای بررسی معماری

در مرحلهٔ نخست، Graphify برای معماری و Ripwire برای تطبیق با سورس فعلی استفاده شد. گراف موجود مربوط به گزارش ۲۰۲۶/۱۰/۰۴ و commit 39e64854 بود؛ تصمیم‌های طراحی با سورس فعلی تطبیق داده شدند. گراف بازسازی یا تغییر داده نشد.

پروژه Django Modular Monolith است. حساب‌ها، مشتریان، کارکنان، درخواست‌ها، پیام‌ها، پیوست‌ها، اعلان‌ها و core مسئولیت‌های جدا دارند.
مسیر /tickets/ به customer_list می‌رسد و مخصوص مشتری است. customer_tickets درخواست‌های همان مشتری را برمی‌گرداند.
صفحه فعلی از templates/base.html ارث می‌برد. برند و متن‌های معرفی با SiteBranding و عنوان‌ها با PageTitle تنظیم می‌شوند.
پوسته فارسی و RTL است و از وزیرمتن، Tailwind 4، HTMX و Alpine استفاده می‌کند. Compressor نیز در پروژه موجود است.
شماره حساب، شناسه واریز و ثبت فیش در مسیرهای فعلی مشتری وجود ندارند؛ خدمات مالی در این طراحی امکانات آینده‌اند.
این نمونه برند را از فایل لوگوی محلی نمایش می‌دهد و متن‌های پیشنهادی دارد؛ دیتابیس را نمی‌خواند.

منابع: config/settings/base.py، config/urls.py، apps/tickets/customer_urls.py، apps/tickets/views.py:customer_list، apps/tickets/selectors.py:customer_tickets، apps/core/context_processors.py، templates/base.html، templates/tickets/customer_list.html، static/src/tailwind.css، package.json و docs/THEMING.md.

منطق UI/UX

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

سوابق فقط پس از انتخاب «درخواست‌های من» دیده می‌شوند. جست‌وجو، فیلتر «همه / در جریان / بسته» و نمایش همه، پیشنهادهای این نمونه‌اند؛ آمار نمایشی نباید به حساب واقعی نسبت داده شود.

در موبایل کارت مشترک ارتباط با کارشناسان تمام عرض را می‌گیرد و دو اقدام آن کنار هم هستند؛ خدمات مالی در ردیف بعدی دو ستون دارند. در دسکتاپ کارت مشترک دو ستون از شبکهٔ چهارستونه را می‌گیرد و دو اقدام آن کنار هم هستند.

وفاداری و جداسازی

فونت وزیرمتن، لوگو، فایل CSS کامپایل‌شده Tailwind و رنگ‌های فعلی پروژه استفاده می‌شوند.
سرمه‌ای #08376b، آبی #0693e3، نارنجی #fa9f00، زمینه #eeeeee و کارت‌های سفید حفظ شده‌اند.
CSS و JavaScript خانه داخل HTML نمونه هستند؛ دو صفحهٔ مالی از service-pages.css مستقل در همین پوشه استفاده می‌کنند.
URL دارایی‌ها نسخه دارد؛ مقدار نسخه هنگام ساخت بر اساس الگوریتم فعلی static_asset_version، یعنی بیشترین زمان تغییر فایل‌های static و templates، محاسبه شده است.
هیچ وابستگی، فونت یا CDN جدید اضافه نشده و build اجرا نشده است.
Service Worker ثبت نمی‌شود. کش و PWA برنامه اصلی تغییر نکرده‌اند.
همهٔ فایل‌های نمونه در design-prototypes/chaharsu/ هستند؛ فایل‌های فعلی templates، static و بک‌اند دست‌نخورده‌اند.

تعامل‌های نمونه

ثبت درخواست لینک به نمونهٔ مستقل موجود فرم در ../ticket-new-wizard/index.html دارد. درخواست‌های نمونه پنجره توضیح دارند؛ مکالمه واقعی باز نمی‌شود. پروفایل پنجره توضیح دارد. «ارسال فیش واریزی» و «شماره حساب‌ها» با لینک معمولی به صفحات HTML مستقل می‌روند و هر دو صفحه لینک بازگشت به خانه و دسترسی به خدمت مالی دیگر دارند. انتخاب فیش فقط نام فایل را نشان می‌دهد؛ محتوای تصویر برای اعتبارسنجی در مرورگر خوانده می‌شود؛ بارگذاری یا ذخیره نمی‌شود. تمام داده‌ها نمایشی‌اند.

پنجره‌ها با Escape، دکمه بستن و کلیک بیرون بسته می‌شوند. dialog بومی مدیریت فوکوس را انجام می‌دهد. جابه‌جایی نما فوکوس را به عنوان آن می‌برد.

بررسی نسخهٔ اصلاح‌شده

Playwright موجود در محیط مجازی پروژه برای بررسی مرورگر نمونه استفاده شد:

خانه فقط خدمات را نشان می‌دهد و سوابق در آن مخفی‌اند.
کارت مشترک و دو اقدام آن در موبایل ۳۹۰×۸۴۴ بررسی شدند؛ هر سه کارت خدمات بالاتر از نوار پایین قرار دارند.
نمای جدا درخواست‌ها، جست‌وجو، فیلتر، حالت بدون نتیجه، نمایش همه و بازگشت به خدمات بررسی شدند.
Back/Forward مرورگر، ناوبری واقعی به دو صفحهٔ مالی، بازگشت به خانه، انتخاب فایل بدون ارسال و حذف انتخاب بررسی شدند.
در عرض‌های ۳۲۰، ۳۶۰، ۳۹۰، ۶۴۰، ۷۶۸، ۱۰۲۴ و ۱۴۴۰ اسکرول افقی مشاهده نشد.
خطای JavaScript مشاهده نشد.
تصاویر خانه و نمای درخواست‌ها به‌روز شدند.

این بررسی‌ها مخصوص نمونهٔ مستقل‌اند؛ تست یا کد اصلی Django تغییر نکرده است.

قرارداد پیاده‌سازی صفحات مالی

در HTML خانه کنار لینک‌های دو خدمت و در ابتدای هر صفحهٔ مستقل کامنت IMPLEMENTATION NOTE درج شده است:

برای ارسال فیش و شماره حساب‌ها باید URL نام‌گذاری‌شده، view و template مستقل در Django تعریف شود.
این لینک‌ها نباید به modal یا data-dialog تبدیل شوند.
مسیرهای فعلی فایل HTML فقط مسیرهای نمونه‌اند؛ نام مسیرهای نهایی Django هنوز تعیین نشده است.
پوستهٔ نهایی باید از base.html ارث ببرد و دارایی‌ها با static_asset_version نسخه‌گذاری شوند.
دکمهٔ ارسال فیش تا پیاده‌سازی بک‌اند، اعتبارسنجی و رسید ثبت غیرفعال است. انتخاب فایل به معنی ثبت پرداخت نیست.
حساب‌ها و شناسهٔ واریز باید از منبع معتبر بک‌اند بیایند؛ هیچ شمارهٔ واقعی یا ساختگی در نمونه درج نشده است.

متن کارت فیش: «تصویر فیش پرداخت خود را برای بررسی بفرستید.» متن کارت شماره حساب‌ها: «شماره حساب، شبا و شناسهٔ واریز را دریافت کنید.»

فشرده‌سازی برای گوشی کوچک

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

بررسی نسخهٔ فشرده: در اندازه‌های ۳۲۰×۵۶۸، ۳۶۰×۶۴۰، ۳۷۵×۶۶۷، ۳۹۰×۸۴۴ و ۴۱۲×۷۳۲ هر سه کارت به‌طور کامل، بدون اسکرول و بالاتر از نوار پایین دیده شدند. عرض‌های ۶۴۰، ۷۶۸، ۱۰۲۴ و ۱۴۴۰ نیز بدون سرریز افقی بررسی شدند. ارتفاع هر دو دکمهٔ درخواست حداقل ۴۴ پیکسل است. مسیر ثبت درخواست، سوابق و صفحات مستقل مالی پس از فشرده‌سازی مجدداً بررسی شدند. تصویر mobile-small.png مربوط به گوشی ۳۲۰×۵۶۸ است.

عنوان خدمت و امضای توسعه‌دهنده

عنوان کارت مشترک «ارتباط با کارشناسان» است؛ ثبت درخواست و مشاهدهٔ درخواست‌های من دو مسیر داخل آن هستند. توضیح «سؤال بپرسید، درخواست ثبت کنید یا برای پیگیری و هماهنگی با کارشناسان در ارتباط باشید.» در تمام اندازه‌ها، از جمله موبایل، نمایش داده می‌شود تا سایر خدمات همچنان در نگاه اول دیده شوند. امضای پایین هر سه صفحه: «طراحی و توسعه: محمد جواد فصاحت 09202202129». شماره لینک تماس دارد؛ هیچ تماس خودکاری برقرار نمی‌شود. کامنت HTML یادآوری می‌کند که در نسخهٔ اصلی امضا از تنظیم developer_credit موجود در برند تأمین شود.

خوانایی در آخرین نسخه

عنوان کارت «ارتباط با کارشناسان» است و جملهٔ «سؤال بپرسید، درخواست ثبت کنید یا برای پیگیری و هماهنگی با کارشناسان در ارتباط باشید.» در همهٔ اندازه‌ها دیده می‌شود. توضیحات و دکمه‌ها حداقل ۱۴ پیکسل‌اند، عنوان کارت در موبایل ۱۸ و در دسکتاپ ۲۰ پیکسل است، و برچسب‌های وضعیت، ناوبری و امضا ۱۲ پیکسل‌اند. خط توضیح با ضریب ۱٫۶۵ یا بیشتر تنظیم شده است. روی موبایل متن کارت‌های مالی کوتاه‌تر است و اقدام تکراری انتهای کارت نمایش داده نمی‌شود؛ خود کارت همچنان لینک صفحهٔ مستقل است. در عرض کمتر از ۳۶۰ پیکسل آیکون دکمه‌ها حذف می‌شود تا متن با همان اندازه خوانا جا بگیرد. اندازه‌های ۳۲۰×۵۶۸ تا دسکتاپ بررسی شدند: متن کامل نمایش داده شد، هیچ عنوانی سرریز نداشت و تمام خدمات بالاتر از نوار پایین موبایل قرار داشتند.

هماهنگی خوانایی صفحات مالی

هر دو صفحهٔ شماره حساب‌ها و ارسال فیش به همان الگوی خوانایی خانه ارتقا یافته‌اند: متن‌ها، اطلاعات حساب و اقدام‌ها حداقل ۱۴ پیکسل؛ عنوان بخش‌ها ۱۸ پیکسل در موبایل و ۲۰ پیکسل در دسکتاپ؛ عنوان صفحه ۲۴/۲۸ پیکسل؛ برچسب‌ها و امضا ۱۲ پیکسل. در موبایل فاصله‌ها کمتر و متن‌های تکراری حذف شده‌اند؛ متن مهم پنهان نشده است. توضیح اصلی تمام عرض را می‌گیرد تا به ستون باریک کنار آیکون محدود نشود. اقدام‌های فعال و انتخاب فایل حداقل ۴۴ پیکسل ارتفاع دارند. اندازه و خوانایی متن با فشرده‌سازی فضا قربانی نشده است.

بررسی صفحات مالی: هر دو صفحه در عرض‌های ۳۲۰، ۳۶۰، ۳۷۵، ۳۹۰، ۶۴۰، ۷۶۸ و ۱۴۴۰ پیکسل، بدون اسکرول افقی یا بریدگی متن بررسی شدند. اندازهٔ متن‌های اصلی حداقل ۱۴ پیکسل و ارتفاع لینک‌های اصلی و انتخاب فایل حداقل ۴۴ پیکسل بود. انتخاب فایل، نام بسیار بلند فایل، حذف انتخاب، غیرفعال‌بودن ارسال و لینک‌های بین دو خدمت و خانه بررسی شدند؛ خطای JavaScript دیده نشد. تصاویر accounts-small.png و receipt-small.png برای گوشی ۳۲۰×۵۶۸ و تصاویر accounts-desktop.png و receipt-desktop.png برای دسکتاپ اضافه شدند. صفحات جزئیات مالی به اندازهٔ محتوایشان اسکرول عمودی طبیعی دارند؛ شرط دیده‌شدن همهٔ خدمات در نگاه اول همچنان مربوط به خانهٔ خدمات است.

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

نمای درخواست‌ها از نوار پایین و کارت کارشناسان به یک مقصد می‌رسد. عنوان ردیف‌ها در موبایل ۱۴ و دسکتاپ ۱۶ پیکسل، شماره درخواست ۱۴، وضعیت و اطلاعات ثانویه ۱۲ پیکسل‌اند. فیلترها، اقدام‌های اصلی و جست‌وجو حداقل ۴۴ پیکسل ارتفاع دارند. جست‌وجو ۱۶ پیکسل است. در موبایل موضوع و اطلاعات در خط بالایی و وضعیت/شماره در ردیف بعد قرار می‌گیرند و امکان wrapping حفظ می‌شود. حالت فعال «درخواست‌ها» در نوار پایین سرمه‌ای روشن‌تر است تا سفید روی آن با قواعد کنتراست راهنما هماهنگ باشد. پنجرهٔ جزئیات نمونهٔ درخواست هم متن اصلی ۱۴ پیکسل دارد.

جریان اعلامیهٔ واریز و فیش مرتبط

نسخهٔ جدید bank-accounts.html فهرست عمومی حساب‌های شرکت نیست؛ فقط اعلامیه‌های واریزی را نشان می‌دهد که کارشناس برای همین مشتری فرستاده است. ابتدا موضوع، مبلغ، فاکتور، تاریخ و وضعیت فیش نمایش داده می‌شود. با باز کردن هر کارت، بانک، صاحب حساب، شماره حساب، شبا، کارت، شناسه، مبلغ، فاکتور و توضیحات همان اعلامیه دیده می‌شود. فقط مبلغ، شماره حساب، شبا، شماره کارت و شناسهٔ واریز موجود دکمهٔ کپی تکی دارند؛ مبلغ بدون جداکننده و بدون واحد کپی می‌شود. کپی کامل متن چندخطی شامل همهٔ اطلاعات و واحد ریال است. مقادیر اعلام‌نشده کپی ندارند. بازخورد کپی به موفقیت واقعی وابسته است؛ در صورت منع Clipboard، روش انتخاب دستی متن در پنجرهٔ دسترس‌پذیر ارائه می‌شود.

payment-demo-data.js فقط سه fixture ساختگی با حساب‌های نامعتبر دارد؛ دیتابیس نیست. payment-services.js رفتار محلی هر دو صفحه را مدیریت می‌کند؛ هیچ ارسال، ذخیره یا وابستگی شبکه‌ای ندارد. دادهٔ واقعی باید از دیتابیس تأمین و به مشتری مخاطب محدود شود. پنهان بودن جزئیات کارت جای کنترل دسترسی سمت سرور را نمی‌گیرد.

«ارسال فیش این واریز» فقط شناسهٔ اعلامیه را با پارامتر notice به فرم می‌برد. فرم همان مورد را انتخاب می‌کند و مبلغ مورد انتظار، فاکتور، بانک و شناسه را نشان می‌دهد؛ لینک بازگشت، جزئیات همان مورد را باز می‌کند. ورود مستقیم به فرم حالت مرتبط را به‌عنوان گزینهٔ اول و پیشنهادی نشان می‌دهد؛ مستقل همیشه قابل انتخاب است. انتخاب مرتبط بدون مورد، پیام راهنما دارد؛ شناسهٔ نامعتبر با خطای روشن نمایش داده می‌شود و هرگز به اعلامیهٔ دیگری وصل نمی‌شود. تغییر به مستقل، شناسهٔ ارتباط را از فرم و URL حذف می‌کند. مبلغ پرداخت‌شدهٔ مشتری و فایل انتخاب‌شده هنگام تغییر نوع/اعلامیه حفظ می‌شوند. هیچ موفقیت ارسال ساختگی نشان داده نمی‌شود؛ دکمهٔ نمونه برای بررسی کلاینت فعال است؛ ارسال واقعی تا پیاده‌سازی اصلی انجام نمی‌شود.

شماره‌ها و مبلغ می‌توانند در هر اعلامیه متفاوت باشند. پنل کارشناس، مدل داده، API، مجوزها و ذخیرهٔ فیش در محدودهٔ این طراحی نیستند. یادآوری قراردادهای ضروری در کامنت HTML هر دو صفحه آمده است.

بررسی نسخهٔ اعلامیه‌ها: هفت عرض ۳۲۰، ۳۶۰، ۳۹۰، ۶۴۰، ۷۶۸، ۱۰۲۴ و ۱۴۴۰، کپی واقعی شبا/مبلغ/متن کامل، باز و بسته شدن کارت‌ها، جست‌وجو، نبود شماره کارت، اتصال دوطرفهٔ اعلامیه و فرم، حذف ارتباط با انتخاب مستقل، حفظ مبلغ/فایل، شناسهٔ نامعتبر، انتخاب دستی هنگام منع Clipboard و Escape بررسی شدند. خطای JavaScript یا درخواست HTTP خارجی مشاهده نشد. accounts-list-mobile.png حالت اولیهٔ بسته و تصاویر accounts-*.png جزئیات باز را نشان می‌دهند. این بررسی جای تست اتصال واقعی سرور یا تأیید کامل WCAG را نمی‌گیرد.

فشرده‌سازی کارت‌ها و اولویت واریز مرتبط

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

اطلاعات تکمیلی ثابت و تاریخ شمسی فیش

اطلاعات تکمیلی و توضیحات اکنون بخش ثابت داخل کارت بازشده هستند؛ نیازی به باز کردن بخش دوم نیست و کاربر نمی‌تواند آن بخش را جمع کند. کپی کامل همچنان از تمام داده‌ها تولید می‌شود.

receipt-date.js انتخابگر تاریخ شمسی با سه select استاندارد روز/ماه/سال است؛ کتابخانه یا فایل خارجی ندارد. ماه و سال جاری برای سهولت انتخاب آماده‌اند، ولی روز ابتدا خالی است تا تاریخ واقعی فیش با تأیید کاربر ثبت شود. «امروز» بر اساس منطقهٔ زمانی ایران تاریخ کامل را انتخاب می‌کند. طول ماه‌ها و اسفند با تقویم Persian در Intl مرورگر بررسی می‌شوند؛ تغییر به ماه/سال کوتاه‌تر، روز نامعتبر را پاک و راهنمای انتخاب دوباره را اعلام می‌کند. تاریخ انتخاب‌شده هنگام تغییر نوع فیش یا اعلامیه حفظ می‌شود. در نمونه سال‌های ده سال قبل تا یک سال بعد قابل انتخاب‌اند؛ بازهٔ نسخهٔ اصلی باید با نیاز واقعی تعیین شود.

مقدار قابل ارسال paid_date تاریخ میلادی YYYY-MM-DD با ارقام ASCII است؛ انتخابگر همچنان شمسی نمایش داده می‌شود. قرارداد اعتبارسنجی و تبدیل با ابزار جلالی موجود پروژه در کامنت HTML آمده است؛ در نمونه هیچ تاریخ یا فایلی ارسال/ذخیره نمی‌شود.

بررسی تاریخ: طول ۱۴۴ ماه در تمام سال‌های قابل انتخاب با jdatetime موجود پروژه تطبیق داده شد؛ اسفند کبیسه، حذف روز نامعتبر، دکمهٔ امروز با ساعت ایران، حفظ تاریخ بین حالت‌ها و خوانایی کنترل‌ها در هفت اندازهٔ نمایش بررسی شدند. تصاویر مالی به‌روز شدند.

اعتبارسنجی کلاینت فیش

receipt-validation.js فرم را بدون ارسال شبکه‌ای بررسی می‌کند. مبلغ صحیح مثبت ریال (پذیرش ارقام فارسی/عربی و جداکنندهٔ معتبر)، روز/ماه/سال کامل، تاریخ غیرآینده و تصویر فیش الزامی‌اند. مبلغ آمادهٔ ارسال در paid_amount رشتهٔ عدد ASCII بدون جداکننده است؛ paid_date میلادی و receipt_image فایل است. فیش مرتبط به notice_id معتبر نیاز دارد؛ در حالت مستقل این select غیرفعال است و شناسه به FormData وارد نمی‌شود.

حد نمونهٔ تصویر مطابق پیش‌فرض IMAGE در bootstrap پروژه، ۱۰ مگابایت و JPG/JPEG/PNG/GIF/WEBP است. علاوه بر پسوند و MIME، امضای فایل و باز شدن تصویر در مرورگر بررسی می‌شوند؛ نتیجهٔ بررسی فایل در حافظه و فقط برای همان File نگهداری می‌شود. فایل خالی، بزرگ، خراب یا دارای نوع ناسازگار پیام مشخص دارد. محدودیت واقعی در نسخهٔ اصلی باید از AttachmentPolicy سرور دریافت شود، نه این عدد نمونه.

خطا زیر فیلد، aria-invalid و فهرست خطاهای لینک‌دار نمایش داده می‌شود. با بررسی ناموفق، اولین فیلد دارای خطا فوکوس می‌گیرد و به مرکز نمایش می‌آید؛ برای ورودی فایل پنهان، کنترل فارسی انتخاب تصویر در معرض دید قرار می‌گیرد. پس از اصلاح، خطا پاک می‌شود. ارسال دوباره حین بررسی کنترل می‌شود؛ اگر کاربر هنگام بررسی فایل فرم را تغییر دهد، نتیجهٔ قدیمی معتبر اعلام نمی‌شود. در حالت معتبر، متن صریح «این پیش‌نمایش است؛ فیش ارسال یا ذخیره نشده» نمایش داده می‌شود. اعتبارسنجی مرورگر جای اعتبارسنجی سرور نیست و کامنت قرارداد در HTML آمده است.

نمایش مبلغ و انتخاب بانک‌ها

receipt-amount.js هنگام تایپ مبلغ ریالی، جداکنندهٔ هزارگان فارسی اضافه می‌کند. ارقام فارسی، عربی و انگلیسی پذیرفته می‌شوند؛ ورودی غیرعددی/اعشاری به عدد دیگری تبدیل نمی‌شود و اعتبارسنجی خطا می‌دهد. محل انتخاب و نشانگر بر اساس تعداد ارقام حفظ می‌شود؛ Backspace/Delete روی جداکننده گیر نمی‌کنند. paid_amount همچنان ریالی و بدون جداکننده است.

زیر مبلغ، معادل تومان به حروف نمایش داده می‌شود: ۲۸۰٬۰۰۰٬۰۰۰ ریال → «بیست و هشت میلیون تومان». محاسبه با BigInt و تقسیم/باقی‌ماندهٔ دقیق انجام می‌شود؛ مثلاً ۱۲۳۴۵ ریال → «هزار و دویست و سی و چهار و پنج دهم تومان»، بدون گرد کردن.

receipt-banks.js فهرست محلی بانک مبدأ با نام‌های شناخته‌شده، گروه نام‌های قدیمی روی فیش‌ها و «سایر» دارد. مبدأ اختیاری است؛ با سایر، نام بانک اختیاری نیز قابل ورود می‌شود. فهرست بانک‌ها در نسخهٔ اصلی باید به‌صورت متمرکز به‌روز نگه داشته شود.

حساب مقصد اجباری است و کاربر خودش انتخاب می‌کند؛ انتخاب اعلامیه یا نوع فیش مقصد را تغییر نمی‌دهد. فهرست مقصد فقط نام حساب‌های شرکت را نشان می‌دهد، نه شماره حساب/کارت/شبا. chaharsuCompanyAccounts در payment-demo-data.js صرفاً fixture با ID و نام است؛ در نسخهٔ اصلی این فهرست باید از دیتابیس حساب‌های فعال/مجاز شرکت بیاید. سرور ID انتخابی را دوباره اعتبارسنجی و نام حساب را از دیتابیس بخواند. این قرارداد در HTML و فایل داده کامنت شده است.

بررسی مرورگر: گروه‌بندی زنده و اصلاح وسط متن، حذف کنار جداکننده، جایگزینی انتخاب، ارقام عربی، صفرهای ابتدایی، معادل دقیق تومان، خطای مقصد و فوکوس، نام‌های بدون شماره، مبدأ اختیاری/سایر، حفظ انتخاب‌ها و FormData ریالی/میلادی بررسی شدند؛ هفت اندازهٔ نمایش بدون سرریز و هیچ منبع خارجی بودند.