این مثال مربوط به فروشگاه یا مشتری واقعی نیست و تمام نامها و اعداد برای آموزش طراحی شدهاند. سناریو کمک میکند نرمافزار فروشگاهی با یک روز کامل و چند وضعیت خطاپذیر آزمایش شود، نه فقط با صدور یک فاکتور ساده.
شروع روز فرضی
فروشگاه فرضی «سپهر» دو کاربر صندوق و یک مدیر دارد. مانده نقدی ابتدای شیفت ثبت میشود. پنج قلم کالا با واحد، بارکد، قیمت خرید و موجودی مشخص تعریف شدهاند. صندوقدار اجازه تغییر قیمت پایه و حذف قطعی فاکتور ندارد.
ثبت خرید و هزینه جانبی
یک فاکتور خرید شامل سه کالا ثبت میشود. هزینه حمل باید طبق سیاست فروشگاه جدا یا روی بهای کالا توزیع شود. سیستم باید موجودی و بدهی تأمینکننده را بههم متصل کند. تغییر تعداد بعد از تأیید باید سابقه قابل پیگیری داشته باشد.
فروشهای روز
فروش اول نقدی، فروش دوم ترکیبی کارت و نقد و فروش سوم با تخفیف مجاز انجام میشود. برای تخفیف بالاتر از سقف، تأیید مدیر لازم است. سرعت صدور فاکتور مهم است، اما کنترل دسترسی و ثبت روش پرداخت نیز باید آزمایش شود.
مرجوعی و اصلاح
یک قلم از فاکتور دوم مرجوع میشود. سیستم باید موجودی را برگرداند، روش استرداد وجه را ثبت کند و اثر مالی را در گزارش روزانه نشان دهد. حذف ساده فاکتور بدون سابقه، نتیجه قابل اعتمادی ایجاد نمیکند.
بستن صندوق و تطبیق
| کنترل | نتیجه مورد انتظار |
|---|---|
| فروش نقدی | برابر با پول نقد مورد انتظار صندوق |
| کارتخوان | قابل تطبیق با رسیدهای پایانه |
| مرجوعی | جدا از فروش و با کاربر ثبتکننده |
| تخفیف | گزارش سقف و تأیید مدیر |
| موجودی | خرید + موجودی اول − فروش + مرجوعی |
گزارش مورد نیاز مدیر
مدیر باید فروش خالص، حاشیه سود تقریبی، کالاهای پرفروش، تخفیفها، اصلاحات و اختلاف صندوق را در یک گزارش قابل پیگیری ببیند. عدد نهایی بدون امکان رسیدن به فاکتورهای سازنده آن، برای کنترل کافی نیست.
نحوه استفاده از سناریو
اعداد واقعی فروشگاه خود را جایگزین کنید و از ارائهدهنده بخواهید تمام مراحل را در دمو اجرا کند. هر مرحلهای که با اکسل یا ثبت دوباره خارج از سیستم تکمیل میشود، بهعنوان محدودیت ثبت شود. این روش شفافتر از تصمیم براساس تعداد امکانات فهرستشده است.