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