امکانات تازهٔ حسابشاپ: مرکز عملیات فروشگاه، چک و بهای تمامشده
مرکز عملیات فروشگاه جایی است که سفارشهای نیازمند رسیدگی (لغو در سایت با فاکتور صادرشده، مرجوعی، مغایرت) با دلیل و راهحلشان یکجا دیده میشوند. کنارش چرخهٔ کامل چک و بهای تمامشده به تفکیک محموله اضافه شده است.
یک دورهٔ کاری دور یک سؤال چرخید: وقتی سفارش فروشگاه اینترنتی درست پیش نمیرود، کجا میشود دیدش و چه کارش میشود کرد؟ گزارش کامل چیزهایی که اضافه شد.
بیشتر کار این دوره دور یک سؤال چرخید که فروشندهها مدام میپرسیدند و جواب روشنی نداشت: «سفارشی که در سایت لغو شد ولی فاکتورش صادر شده بود، الان کجاست؟»
جواب قبلی درست بود ولی به درد نمیخورد: در پایگاه داده هست، اما هیچ صفحهای نشانش نمیدهد. سفارشهای ووکامرس فقط بهصورت چند عدد روی داشبورد همگامسازی هر فروشگاه دیده میشدند. نه فهرستی بود، نه جستوجویی، نه راهی برای دخالت کردن. این نوشته میگوید چه چیزی عوض شد و چه چیزی هنوز عوض نشده.
خلاصهٔ مهمترین تغییرها
- مرکز عملیات فروشگاههای آنلاین: یک میز کار برای همهٔ سفارشهای فروشگاه. نمای کلی، فهرست جستوجوپذیر، صفحهٔ تکسفارش با ردپای حسابداری، مغایرتها و تاریخچهٔ ارتباطها.
- صف تأیید سفارش: اگر بخواهید، سفارش تازه تا وقتی کسی تأییدش نکند هیچ اثری روی انبار و حسابها نمیگذارد. تأیید تکی، گروهی، و «بررسی و ثبت کل صف».
- رسیدگی به لغو بعد از فاکتور: راهنمای گامبهگامی که وضعیت فاکتور، پول و انبار را نشان میدهد و بدون تصمیم صریح شما دست به پول نمیزند.
- چک با مسیرهای مشخص: یک چک دیگر نمیتواند هم وصول شود هم خرج.
- دریافت و پرداخت در صندوق یا بانک واقعی: سند از خزانهای ساخته میشود که انتخاب کردهاید، نه از عنوان روش پرداخت.
- درگاه پرداخت، کارمزد و تسویه: پول درگاه تا تسویه در حساب واسط میماند و تفاوت تسویه ثبت میشود.
- بهای تمامشده به روش FIFO: بهعنوان جایگزین میانگین موزون، انتخابی و برای هر فروشگاه جدا.
مرکز عملیات فروشگاههای آنلاین
مشکل قبلی این نبود که سفارشها وارد نمیشدند. میشدند و خودکار فاکتور میشدند. مشکل، سفارشهایی بود که سر راهشان به مشکل میخوردند و هیچجا دیده نمیشدند: مشتریای که شمارهاش به دو نفر میخورد، مبلغی که با فاکتور نمیخواند، کالایی که به هیچ کالای حسابشاپ وصل نبود.
حالا یک بخش در منو هست، که فقط وقتی ظاهر میشود که دستکم یک فروشگاه وصل کرده باشید. داخلش:
- نمای کلی با کارتهایی که عدد نشان میدهند و کلیکشدنیاند: سفارشهای امروز، در انتظار تأیید، ثبتشده در حسابداری، نیازمند رسیدگی، مغایرتها و خطاها.
- فهرست سفارشها با جستوجو روی شمارهٔ سفارش سایت، شمارهٔ فاکتور، نام و تلفن مشتری. یعنی وقتی مشتری زنگ میزند، با همان چیزی که در دست دارید پیدایش میکنید.
- صفحهٔ یک سفارش که سه وضعیت را جدا نگه میدارد و عمداً یکیشان نمیکند: فروشگاه چه میگوید، رسیدگی کجاست، حسابداری چه کرده. پایینتر، ردپای کامل: فاکتور، اسناد حسابداری، رسیدهای پرداخت و برگشتها.
صف تأیید، و «ثبت همهٔ صف»
برای هر فروشگاه میشود گفت سفارشها مستقیم ثبت شوند یا اول تأیید بخواهند. در حالت دوم، سفارش تازه در صف مینشیند و تا کسی تأییدش نکند نه فاکتوری میسازد نه از انبار کم میکند.
دکمهای هم هست که کل صف را بررسی و ثبت میکند، نه فقط صفحهٔ جاری. نکتهٔ مهم اینجاست: این دکمه میانبر نمیزند. هر سفارش از همان مسیر همیشگی رد میشود، پس سفارشی که مبلغش نمیخواند یا مشتریاش مبهم است ثبت نمیشود و با ذکر دلیل و لینک مستقیم در فهرست میماند. «تأیید همه» یعنی بررسی همه، نه چشمبستن روی همه.
لغو سفارش بعد از صدور فاکتور
این همان سؤالی است که اول نوشته آمد. قبلاً سفارش لغوشده در ووکامرس بدون اینکه بفهمید به «نادیده بگیر» تطبیق میشد و در حسابداری همچنان یک فروش ثبتشده باقی میماند.
حالا چنین سفارشی به صف رسیدگی میرود و یک راهنمای گامبهگام باز میشود که چهار چیز را نشان میدهد: فاکتور در چه وضعی است، چقدر پول دریافت شده، کالا از انبار خارج شده یا نه، و اگر ادامه دهید دقیقاً چه اتفاقی میافتد. فاکتور پیشنویس حذف میشود. فاکتور قطعی با سند برگشتی باطل میشود، نه با پاککردن. و اگر پولی گرفته شده باشد، تا صریحاً نگویید با آن پول چه شود (بماند، از فاکتور جدا شود، یا برگردد) هیچ کاری انجام نمیشود.
مرکز مغایرتها
مرکز مغایرت هفت نوع ناهماهنگی را فهرست میکند: سفارش لغوشده با فاکتور فعال، اختلاف مبلغ، مشتری تطبیقنداده، بازپرداخت بدون سند، برگشت ثبتنشده در فروشگاه، کالای تطبیقنداده، و خطای پردازش. هر ردیف درجهٔ فوریت دارد و لینکش مستقیم به همان جایی میرود که رفعش میکند.
نکتهٔ فنیاش ارزش گفتن دارد: این فهرست ذخیره نمیشود و هر بار از روی دادههای همان لحظه حساب میشود. اگر مغایرتها را در یک جدول جدا ذخیره کنید، یک نسخهٔ دوم از واقعیت ساختهاید که دیر یا زود با نسخهٔ اول اختلاف پیدا میکند.
برگشت از فروش، و ثبتش در فروشگاه
برگشت از فروشی که در حسابشاپ ثبت کردهاید را میشود با یک دکمه بهعنوان Refund در خود ووکامرس هم ثبت کرد. یک بار، و بدون دستور به درگاه پرداخت. منطقش ساده است: پول را خودتان قبلاً برگرداندهاید و این کار فقط سفارش سایت را با حساب و کتاب شما یکی میکند. اگر به درگاه هم دستور داده میشد، خطر بازپرداخت دوباره واقعی بود.
برگشتی که از اول از خود فروشگاه آمده باشد، ارسال دوبارهاش رد میشود، وگرنه فروش فروشگاه دو بار کم میشد.
چک: مسیر مشخص بهجای یک ستون وضعیت
چک تا پیش از این یک ستون «وضعیت» داشت و جابهجاییها فقط به مقصد نگاه میکردند. هر سیستمی که اینطور ساخته شود دو راه باز میگذارد: وصول دوبارهٔ یک چک، و وصول چکی که قبلاً به تأمینکننده خرج شده. یعنی یک چک، هم در بانک هم در دست دیگری.
حالا مسیرهای مجاز هر وضعیت از قبل تعریف شدهاند، دکمههای روی بورد از همان جدول ساخته میشوند، و وضعیت فعلی قبل از هر جابهجایی دوباره و با قفل خوانده میشود.
دو اصلاح حسابداری هم از دلش درآمد. اول اینکه سند از «از کجا به کجا» ساخته میشود، نه فقط از مقصد: چک برگشتی که دوباره به جریان میافتد باید به اسناد دریافتنی برگردد و دادنش به مشتری نباید دوباره از آنجا خارجش کند. دوم اینکه خرجکردن چک، که قبلاً فقط وضعیت را عوض میکرد، حالا سند میزند.
هر دریافت و پرداخت، در صندوق یا بانک واقعی
تا پیش از این، سند یک پرداخت از روش پرداخت ساخته میشد و صندوق یا بانکی که کاربر انتخاب کرده بود نادیده میماند. حالا حساب از خود خزانهٔ انتخابی میآید. برای دریافت نقدی باید صندوق انتخاب کنید و برای کارت و انتقال بانکی، حساب بانکی. اگر روش با خزانه نخواند، ثبت اصلاً انجام نمیشود.
قاعدهٔ اصلاح هم عوض نشد: هر جابهجایی لازم با سند اصلاحی تاریخدار انجام میشود، نه با دستکاری سند اصلی. سند قطعی همچنان تغییرناپذیر است. و جایی که از روی داده معلوم نباشد کدامیک اشتباه بوده، مثلاً «نقدی» که از حساب بانکی پرداخت شده، چیزی حدس زده نمیشود و فهرست میشود تا آدم تصمیم بگیرد.
درگاه پرداخت، کارمزد و تسویه
درگاههای پرداخت را میشود مستقیم از سایت وصلشده خواند و انتخاب کرد که کدامها ثبت شوند. تایپکردن دستی کد درگاه یک حرف اشتباه هم برنمیداشت. برای هر درگاه مشخص میکنید پولش به کدام حساب بانکی مینشیند، کارمزدش چقدر است و چند روز بعد تسویه میشود.
نتیجهاش روی حسابها مهم است: دریافت درگاهی تا تسویه در حساب واسط میماند، نه در بانک، چون پول واقعاً هنوز آنجاست. موقع تسویه، مبلغ خالص به بانک، کارمزد به هزینه، و تفاوت آنچه انتظار میرفت با آنچه رسید ثبت میشود. تسویههای عقبافتاده هم شمرده میشوند و یادآوری دارند.
روی صفحهٔ فاکتور هم اثر دارد. فاکتوری که از فروشگاه آمده حالا میگوید از کدام درگاه پرداخت شده، پول کجا نشسته، و کدام اسناد دریافت به آن تخصیص خوردهاند. اگر درگاهی تطبیق نشده باشد، فقط عنوان روش پرداخت سایت نشان داده میشود و هیچ حساب بانکیای حدس زده نمیشود.
بهای تمامشده به روش FIFO
کنار میانگین موزون، روش اولینصادره از اولینوارده (FIFO) هم قابل انتخاب است، برای هر فروشگاه جدا، در تنظیمات انبار. یک هشدار مهم هم دارد: این انتخاب فقط تا قبل از اولین گردش انبار قابل تغییر است. بعد از آن قفل میشود، چون عوضکردن روش وسط کار یعنی بهای تمامشدهٔ گذشته و آینده با دو منطق حساب شده باشد.
یک نکتهٔ مهم در پیادهسازی: لایهٔ FIFO باید پشت هر کالایی باشد که وارد انبار میشود، نه فقط پشت خرید. کالایی که از سند افتتاحیه، انتقال بین انبار یا اضافی انبارگردانی میآید هم لایهٔ خودش را میگیرد، وگرنه فروشش بهای تمامشدهای پیدا نمیکرد و سود، ساختگی بزرگ میشد. حالا لایه در همان دری ساخته میشود که کالا از آن وارد میشود، و اگر برای بخشی از فروش لایهای نماند، آن بخش به میانگین متحرک قیمتگذاری و گزارش میشود، نه اینکه بیسروصدا صفر بماند.
یک سناریوی واقعی
فرض کنید یک فروشگاه پوشاک است. ساعت ۱۱ شب سفارشی با پرداخت آنلاین ثبت میشود. چون فروشگاه روی حالت «تأیید دستی» است، صبح روز بعد در صف تأیید مینشیند.
صبح، مسئول فروش «بررسی و ثبت همهٔ صف» را میزند. از دوازده سفارش، یازدهتا ثبت میشوند و یکی برمیگردد با دلیل مشتری مبهم: شمارهای که به دو مخاطب میخورد. رویش کلیک میکند، مشتری درست را انتخاب میکند، سفارش همانجا ثبت میشود و انتخابش برای همیشه روی همان سفارش میماند.
ظهر، مشتری یکی از سفارشها زنگ میزند و انصراف میدهد و سفارش در ووکامرس لغو میشود. چون فاکتورش قطعی شده و پولش هم از درگاه گرفته شده، سفارش خودکار «نادیده» نمیشود و به صف رسیدگی میرود. مسئول، راهنما را باز میکند، میبیند فاکتور قطعی است و فلان مبلغ دریافت شده، و انتخاب میکند که پول از فاکتور جدا شود تا بهعنوان بستانکاری مشتری بماند. فاکتور با سند برگشتی باطل میشود، کالا به انبار برمیگردد، و در مرکز مغایرتها یک ردیف میماند که میگوید وضعیت سفارش را در خود فروشگاه هم بهروز کنید، چون این یکی را نرمافزار بهجای شما انجام نمیدهد.
آخر ماه، گزارش سود بهای تمامشده را از لایههای واقعی برمیدارد، کارمزد درگاه در هزینهها نشسته، و تفاوت تسویهٔ درگاه هم جایی گم نشده.
برای هر گروه چه فرقی میکند
- صاحب فروشگاه: میداند کدام سفارش هنوز به حسابداری نرسیده و چرا. سود ماه دیگر با بهای تمامشدهٔ صفر باد نمیکند.
- مسئول فروش و پشتیبانی: سفارش را با شمارهٔ تلفن مشتری پیدا میکند و همانجا میبیند فاکتورش چه شد و پولش کجاست.
- حسابدار: دریافتها در خزانهٔ واقعی نشستهاند، پول درگاه تا تسویه در حساب واسط است، و چکی که وصول شده دوباره وصول نمیشود. یعنی تراز درست است.
- انباردار: کالای تطبیقنداده دیگر بدون اینکه بفهمید رد نمیشود و در فهرست مغایرتها با لینک تطبیق میآید.
نسبتش با بخشهای قبلی
هیچکدام از اینها ماژول موازی نیست. مرکز عملیات روی همان اتصال ووکامرس و همان فاکتورها کار میکند و فقط پنجرهای رو به آنها باز کرده. تطبیق وضعیتها، همگامسازی دورهای و وبهوکها، و نوشتن شمارهٔ سند روی سفارش ووکامرس از قبل بودند و همانها به کار گرفته میشوند، با افزونهٔ وردپرس که همان اطلاعات را روی صفحهٔ سفارش نشان میدهد.
سؤالهای پرتکرار
این امکانات را باید جداگانه فعال کنم؟
نه. برای همهٔ فروشگاهها فعال است و چیزی نصب نمیشود. فقط تنظیمهای اختیاری مثل ارسال قیمت به سایت را خودتان روشن میکنید.
روی دادههای قبلیام اثری دارد؟
نه، اسناد قبلی همانطور میمانند. امکانات تازه از این به بعد کار میکنند و گزارشهای قدیمی همان چیزی را میگویند که قبلاً میگفتند.
پیشنهاد امکانات تازه را کجا بدهم؟
از همان بخش پشتیبانی داخل پنل. بیشتر چیزهایی که اینجا نوشته شده، از همین درخواستها شروع شدهاند.
اگر امکان تازهای به کارم نمیآید چه؟
لازم نیست استفاده کنید و جلوی کار روزانه را نمیگیرد. منوها بر اساس دسترسی و تنظیمات نمایش داده میشوند، پس چیزی که خاموش باشد سر راهتان نیست.
حسابشاپ سفارشهای ووکامرس را میگیرد، فاکتور و سند حسابداری را خودش میسازد و موجودی را همتراز نگه میدارد.
شروع رایگان