سیستم حسابداری فروشگاهی؛ راهنمای چندشعبه، کالا، صندوق و وصول

معماری نرم‌افزار چندشعبه و چندانبار

نخست واحدهای سازمانی را از محل نگهداری کالا جدا کنید. شعبه می‌تواند مرکز فروش و مسئول سود باشد؛ انبار محل فیزیکی یا منطقی نگهداری است؛ صندوق نقطه ثبت معامله؛ و شرکت شخصیت مالی و قانونی. یک شعبه ممکن است چند انبار و صندوق داشته باشد و یک انبار مرکزی به چند شعبه خدمت دهد. اگر همه این مفاهیم در یک فیلد «محل» ادغام شوند، انتقال، دسترسی، قیمت، شمارش و گزارش سود قابل کنترل نخواهند بود. ^{[۲] [۹]}

برای هر رویداد یک شناسه سراسری بسازید: فروش، ردیف کالا، مرجوعی، پرداخت، تسویه، قبض یا حواله و سند مالی. اتصال نباید فقط جمع روزانه بدون امکان ردیابی باشد. از فروش دفتر تا ردیف صندوق و از تراکنش بانک تا روش پرداخت باید قابل حرکت باشد. اگر ارتباط قطع شد، رکورد در صف خطا با علت، مالک و مهلت بماند؛ ارسال دوباره نیز نباید فروش یا سند تکراری تولید کند. ^{[۹] [۶]}

در معماری آنلاین، سناریوی قطع شبکه را پیش از خرید اجرا کنید. آیا صندوق متوقف می‌شود، در صف محلی ثبت می‌کند یا فقط پرداخت را می‌پذیرد؟ شماره‌گذاری، قیمت، موجودی و مجوز در حالت آفلاین چگونه کنترل و پس از بازگشت تعارض چگونه حل می‌شود؟ برای چندشعبه، زمان همگام‌سازی باید با تصمیم کسب‌وکار هماهنگ باشد. موجودی با تأخیر چندساعته برای گزارش مدیریتی شاید کافی باشد اما برای وعده فروش کالای کمیاب مناسب نیست. ^{[۶] [۴]}

تجهیزات فروشگاهی، POS و اتصال ترازو را چگونه انتخاب کنیم؟

تجهیزات را از جریان کار استخراج کنید، نه از فهرست خرید آماده. رایانه یا پایانه، نمایشگر، بارکدخوان، چاپگر، کشوی پول، ترازو، کارتخوان و شبکه هرکدام نقطه شکست و نگهداری‌اند. تعداد تراکنش، محیط، نوع کالا، عرض رسید، سرعت، فضای پیشخوان، برق پشتیبان و امکان تعویض قطعه را ثبت کنید. یک دستگاه همه‌کاره می‌تواند نصب را ساده کند، اما خرابی آن نیز چند وظیفه را هم‌زمان متوقف می‌کند. ^{[۵] [۲]}

POS در گفت‌وگوی بازار گاهی کارتخوان و گاهی کل سامانه نقطه فروش است. قانون پایانه‌های فروشگاهی ایران، پایانه را وسیله دارای اتصال به شبکه پرداخت رسمی و قابلیت صدور صورتحساب الکترونیکی تعریف می‌کند؛ اما اتصال فنی و تکلیف اجرایی هر مؤدی باید با مقررات روز سنجیده شود. از فروشنده بخواهید نشان دهد مبلغ، شناسه فروش، روش پرداخت، وضعیت ارسال صورتحساب و نتیجه تسویه چگونه بدون ورود دوباره به دفتر مالی می‌رسند. ^[۹]

برای ترازو، مشخص کنید وزن از کدام درگاه و با چه قالبی خوانده می‌شود، صفر و پایداری چگونه کنترل می‌شوند و کاربر چه زمانی اجازه ویرایش دارد. کالاهای وزنی به واحد پایه، دقت، تبدیل بسته و قیمت در واحد نیاز دارند. یکپارچگی ترازو نباید عدد را بدون نمایش و تأیید وارد کند. الزامات قانونی اندازه‌شناسی و تأیید وسیله را نیز از مرجع ایرانی مربوط کنترل کنید؛ این راهنما یک مدل یا برند را تأیید نمی‌کند. ^{[۲] [۳]}

امنیت پرداخت را از حسابداری جدا اما متصل ببینید. PCI SSC توصیه می‌کند پایانه و نرم‌افزار پرداخت معتبر، تنظیم امن، حفاظت شبکه، بررسی دست‌کاری فیزیکی و حداقل نگه‌داری داده کارت رعایت شود. نرم‌افزار حسابداری نباید داده حساس کارت را فقط برای تطبیق نگه دارد؛ شناسه مرجع و مبلغ کافی است. دسترسی راه دور فروشنده تجهیزات باید محدود، زمان‌دار، ثبت‌شده و پس از خدمت لغو شود. ^{[۴] [۵] [۶]}

کد کالا، ماتریس ویژگی و تجزیه یا ترکیب

هر قلم باید یک شناسه پایدار داشته باشد و نام تجاری تنها کلید آن نباشد. GS1، GTIN را برای شناسایی یکتای اقلامی به کار می‌برد که قیمت‌گذاری، سفارش یا صورتحساب می‌شوند؛ بارکد حامل شناسه و گاهی ویژگی‌هایی مانند بچ، سریال یا تاریخ است. فروشگاه ممکن است شناسه داخلی نیز داشته باشد، اما نگاشت آن به بارکد تأمین‌کننده، واحد خرید، واحد فروش و سطح بسته‌بندی باید صریح و بدون بازاستفاده باشد. ^{[۳] [۲]}

ماتریس کالا برای خانواده‌ای با ویژگی‌های تکراری—مثلاً رنگ و اندازه—ساخت سریع گونه‌ها را ممکن می‌کند. هر ترکیب قابل فروش باید شناسه و موجودی خود را داشته باشد و ویژگی‌ها از واژه‌نامه کنترل‌شده بیایند. ساخت آزاد «مشکی»، «سیاه» و «Black» گزارش را می‌شکند. تغییر ویژگی مادر پس از تراکنش نباید تاریخچه گونه قدیمی را بازنویسی کند. غیرفعال‌سازی، جایگزینی و ادغام رکورد تکراری باید با اثر بر فروش و موجودی انجام شود. ^{[۳] [۲]}

تجزیه و ترکیب یعنی تبدیل کنترل‌شده یک قلم یا بسته به اجزای دیگر: بازکردن کارتن به عدد، ساخت سبد فروش، بسته‌بندی مجدد یا کیت. سند تبدیل باید ورودی، خروجی، ضریب، ضایعات، تاریخ، انبار و مسئول را ثبت کند. این عملیات فروش یا خرید نیست؛ حرکت مقدار و گاهی تخصیص بهاست. اگر کاربر صرفاً موجودی یک کالا را کم و دیگری را زیاد کند، رابطه علت، تفاوت تبدیل و بهای هر واحد قابل رسیدگی نمی‌ماند. ^{[۱] [۳]}

موجودی، بهای خرید، فروش و سفارش مجدد

موجودی عملیاتی حداقل چهار وضعیت دارد: در دسترس، رزروشده، در انتقال و مسدود یا آسیب‌دیده. عدد کل بدون وضعیت می‌تواند فروش بیش از موجودی بسازد. هر قبض، حواله، انتقال، مرجوعی و شمارش باید سند و زمان داشته باشد. موجودی منفی اگر برای تداوم کار مجاز است، باید استثنا با مالک و مهلت رفع باشد؛ استفاده دائمی از منفی، بهای فروش و سفارش‌گذاری را غیرقابل اعتماد می‌کند. ^{[۱] [۲]}

فروش بر مبنای قیمت خرید می‌تواند یک سیاست قیمت‌گذاری باشد، اما قیمت خرید آخر با بهای دفتری موجودی یکی نیست. IAS 2 هزینه خرید، تبدیل و هزینه رساندن کالا به وضعیت فعلی را در بهای موجودی می‌آورد و برای اقلام قابل تعویض فرمول‌هایی مانند FIFO یا میانگین موزون را مطرح می‌کند. نرم‌افزار باید قیمت فروش، بهای دفتری، قیمت خرید آخر و حاشیه برآوردی را جدا نشان دهد و سیاست مصوب را در تاریخ نگه دارد. ^[۱]

سفارش مجدد از موجودی حداقل، زمان تأمین، تقاضا و واحد بسته‌بندی می‌آید؛ عنوان «هوشمند» بدون منطق و امکان توضیح ارزش ندارد. پیشنهاد سیستم باید قابل بازبینی باشد و موجودی در راه، رزرو، فصل، حداقل سفارش فروشنده و ضریب کارتن را ببیند. کسری و انباشت هر دو هزینه‌اند. شاخص‌هایی مانند روزهای پوشش، گردش، فروش ازدست‌رفته، کالای راکد و اختلاف شمارش کنار هم تصمیم بهتری از یک نقطه سفارش ثابت می‌سازند. ^{[۱] [۳]}

شمارش ادواری را بر اساس ریسک برنامه‌ریزی کنید؛ قلم گران، پرگردش یا پرمغایرت بیشتر شمارش شود. شمارشگر نباید موجودی دفتری را پیش از ثبت ببیند اگر این کار نتیجه را منحرف می‌کند. اختلاف باید به دریافت ثبت‌نشده، فروش، ضایعات، خطای واحد، سرقت یا زمان‌بندی شکسته شود. تعدیل موجودی نیازمند مجوز و سند است و گزارش علت باید به اصلاح فرایند برسد، نه صرفاً صفرکردن مغایرت. ^{[۱] [۶]}

تغییر سریع و دسته‌ای قیمت بدون از دست‌دادن کنترل

تغییر دسته‌ای قیمت باید پیش‌نمایش، دامنه، تاریخ اجرا و امکان لغو کنترل‌شده داشته باشد. کاربر باید بداند کدام شعبه، فهرست قیمت، گروه مشتری و گونه کالا تغییر می‌کند؛ گردکردن، حداقل حاشیه و مالیات نیز بخشی از قاعده‌اند. فایل ورودی باید نسخه، جمع ردیف، خطای شناسه و موارد ردشده را نشان دهد. اجرای ناقص نباید نیمی از شعب را با قیمت تازه و نیم دیگر را بدون توضیح رها کند. ^{[۳] [۷]}

مجوز پیشنهاد قیمت، تأیید و انتشار را جدا کنید. تخفیف خارج از حد، فروش زیر بهای کنترلی و قیمت دستی صندوق استثنا هستند و باید دلیل، مسئول و اثر را ثبت کنند. قیمت تاریخی فاکتور پس از تغییر فهرست نباید بازنویسی شود. برای ترویج فروش نیز بازه شروع و پایان، محدودیت تعداد، ترکیب با تخفیف دیگر و روش برگشت روشن باشد. گزارش باید نشان دهد حاشیه واقعی بعد از تخفیف و مرجوعی چه شده است. ^{[۷] [۱]}

گزارش بدهکاران و بستانکاران و یادآوری سررسید چک

گزارش طرف حساب باید مانده را به اسناد سازنده آن باز کند: فروش، مرجوعی، دریافت، پرداخت، چک، علی‌الحساب و تعدیل. عنوان بدهکار یا بستانکار به‌تنهایی معنای تجاری کامل ندارد؛ پیش‌دریافت مشتری و طلب از مشتری هر دو ممکن است در گردش یک طرف دیده شوند. سن بدهی، سررسید، سقف اعتبار، تعهد باز و اختلاف مورد رسیدگی جدا نمایش داده شوند. مانده‌های غیرعادی و بدون حرکت به تأییدیه و پیگیری نیاز دارند. ^{[۶] [۹]}

یادآوری چک یک کنترل تقویمی است، نه تضمین وصول. تاریخ سررسید، بانک، شناسه، طرف، مبلغ، وضعیت صیادی و سند منشأ باید معتبر باشند. اعلان به نقش مسئول برسد و مشاهده، اقدام بعدی و تصعید ثبت شود. هشدارهای بسیار زیاد نادیده گرفته می‌شوند؛ قواعد بر اساس مبلغ، روز تا سررسید و ریسک طرف تنظیم شوند. تغییر سررسید یا وضعیت باید سابقه داشته باشد و فایل تصویر چک با دسترسی محدود نگه‌داری شود. ^{[۷] [۶]}

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

کپی دسترسی صندوقدار و امنیت عملیات شعبه

کپی نقش می‌تواند راه‌اندازی شعبه را سریع کند، اما کپی کاربر قبلی خطر انتقال امتیاز اضافی دارد. الگوی نقش باید بر وظیفه ساخته شود: فروش، مرجوعی محدود، بازکردن کشو، مشاهده موجودی همان شعبه و بستن شیفت. تغییر قیمت، ابطال پس از پایان شیفت، خروجی مشتری، اصلاح تسویه و مدیریت کاربر مجوزهای جدا هستند. OWASP بر کمترین امتیاز، رد پیش‌فرض و بررسی مجوز در هر درخواست تأکید می‌کند. ^[۷]

انتقال یا خروج کارمند باید همان روز دسترسی را تغییر دهد. حساب مشترک صندوق، نسبت‌دادن ابطال و کسری را ناممکن می‌کند؛ هر کاربر شناسه شخصی و احراز هویت مناسب می‌خواهد. CISA، MFA را لایه مهم حفاظت معرفی می‌کند، اما تجربه صندوق باید با ریسک و ابزار سازگار طراحی شود. نشست رهاشده، دستگاه مفقود، دسترسی پشتیبان و رمز پیش‌فرض تجهیزات نیز در بازبینی شعبه قرار گیرند. ^{[۸] [۶] [۴]}

ردپای ممیزی باید رویدادهای مهم را با کاربر، زمان، شعبه، دستگاه، مقدار قبل و بعد و دلیل نگه دارد. لاگ فقط برای پس از تقلب نیست؛ الگوی ابطال، تخفیف، بازکردن کشو و ورود ناموفق می‌تواند آموزش یا نقص فرایند را زود نشان دهد. دسترسی به لاگ و امکان حذف آن محدود باشد و هشدارها به مالک مشخص برسند. پایش باید متناسب باشد و داده شخصی غیرضروری جمع نکند. ^{[۶] [۷]}

تحلیل فروش، معیار خرید و مرز قابلیت ژرف‌بان

داده‌کاوی زمانی معنا دارد که داده پایه سالم باشد. سبد خرید، تکرار، هم‌خریدی، فصل، شعبه و پاسخ به ترویج می‌توانند به چیدمان و خرید کمک کنند، اما همبستگی علت نیست و تخفیف می‌تواند نتیجه را منحرف کند. پیش از مدل پیچیده، گزارش فروش خالص، حاشیه، موجودی، مرجوعی، روزهای پوشش و تسویه را پایدار کنید. هدف تحلیل باید تصمیم، مالک، تناوب و آزمون اثر داشته باشد؛ نمودار بدون اقدام هزینه تولید می‌کند. ^{[۶] [۱]}

در دمو، یک شیفت کامل اجرا کنید: ورود کاربر محدود، فروش کالای ماتریسی و وزنی، تخفیف استثنا، پرداخت ترکیبی، مرجوعی، انتقال انبار، تغییر قیمت فردا، چک مدت‌دار، بستن صندوق، تطبیق تسویه و سند مالی. سپس برق یا اتصال را قطع و بازیابی کنید. تعداد کلیک مهم است، اما مهم‌تر این است که هر خطا کجا می‌ماند، چه کسی آن را می‌بیند و آیا ثبت دوباره رخ می‌دهد. ^{[۵] [۹]}

ژرف‌بان هسته مالی، انبار، خزانه، بانک، مودیان، چندشرکتی و نقش را فعال معرفی می‌کند. اتصال صندوق و فروش آنلاین، تطبیق تخصصی کارتخوان و درگاه، انتقال تخصصی شعب و سود کامل شعبه و گروه کالا در نقشه راه خرده‌فروشی‌اند. این مقاله راهنمای طراحی و خرید است و ادعا نمی‌کند همه قابلیت‌های شرح‌داده‌شده امروز در محصول فعال‌اند. در جلسه فقط جریان قابل اجرا را ملاک قرار دهید و دامنه توسعه را مکتوب بخواهید. ^{[۶] [۱] [۵] [۹]}

• شناسه فروش، پرداخت، تسویه، حرکت کالا و سند مالی را تا ردیف حفظ کنید.
• ماتریس کالا و تبدیل بسته را با موجودی و بهای تمام‌شده واقعی آزمایش کنید.
• دسترسی صندوقدار، تغییر قیمت، ابطال و خروجی داده را مجوزهای جدا بگیرید.
• قابلیت فعال ژرف‌بان را از نقشه راه اتصال صندوق و خرده‌فروشی تخصصی جدا ببینید.