نرم‌افزار انبارداری ساده به چه سؤال‌هایی باید جواب بدهد؟
بیشترِ فروشنده‌های کوچک و متوسط «انبارداری» را به‌عنوانِ یک تخصصِ جدا لازم ندارند. چیزی که لازم دارند جوابِ سریع به چهار سؤال است: چه چیزی داریم که هنوز به کسی قولش را نداده‌ایم؟ کالای این فاکتور از کدام انبار میرود؟ بار واقعاً تحویل شده یا هنوز در انبار است؟ و چه کسی اجازه دارد این عددها را ببیند یا عوض کند؟ هر نرم‌افزاری که به این چهار سؤال جوابِ درست بدهد، برای یک شرکتِ پخش یا یک فروشگاهِ عمده‌فروشی کافی است. بقیه‌ی نیازهای چنین شرکتی، از منطقه تا چک، در CRM برای شرکت پخش و بازرگانی آمده است.
مشکل معمولاً از جای دیگری شروع میشود: فروش در یک سیستم ثبت میشود و انبار در سیستمی دیگر — یا در یک فایلِ اکسل که هر هفته یک نفر به‌روزش میکند. فروشنده از عددِ هفته‌ی پیش می‌فروشد، انباردار از روی کاغذ بار می‌زند، و حسابدار آخرِ ماه اختلاف را پیدا میکند. به همین دلیل برای تیم‌هایی که از موجودی می‌فروشند، انبار و فروش در یک نرم افزار منطقی‌تر از دو نرم‌افزارِ عالیِ جداست: خودِ فاکتور منبعِ گردشِ کالا میشود و هیچ چیز دو بار تایپ نمی‌شود.
یک نکته را هم از اول روشن کنیم: «ساده» یعنی سندِ کمتر، نه قاعده‌ی کمتر. هر جابه‌جاییِ کالا همچنان یک سند، یک دلیل و یک نامِ مسئول می‌خواهد؛ فقط آن سندها خودکار از کارِ روزمره‌ی فروش ساخته می‌شوند.
حواله انبار چیست و با رسید انبار چه فرقی دارد؟
در زبانِ انبارداری دو سندِ پایه داریم. رسید انبار ورودِ کالا را ثبت میکند: خرید از تأمین‌کننده، کالایی که مشتری پس آورده، یا تحویلی که هیچ سندِ دیگری ندارد. حواله انبار خروجِ کالا را ثبت میکند: کدام کالا، چند عدد، از کدام انبار، برای کدام فاکتور، و چه کسی تحویلش داده. اگر کسی پرسید حواله انبار چیست، کوتاه‌ترین جواب این است: دستوری که به انباردار میگوید این بار را بیرون بده.
سؤالِ طبیعی این است که وقتی فاکتور هست، حواله چه لازم است؟ جوابش این است که این دو سند برای دو مخاطبِ متفاوت‌اند. فاکتور سندِ مالی بینِ شما و مشتری است؛ نمی‌داند کالا از انبارِ شمالِ شهر میرود یا از انبارِ جنوب، و نمی‌داند کامیون راه افتاده یا نه. حواله سندِ داخلی بینِ فروش و انبار است و دقیقاً همین دو چیز را می‌داند. اگر یک فاکتور سه قلم داشته باشد که در دو انبار نگه‌داری می‌شوند، منطقی است دو حواله صادر شود — هر انبار فقط برگه‌ی خودش را ببیند.
رایج‌ترین اشتباه در طراحیِ این دو سند، کسرِ دوباره است: فاکتور موجودی را کم میکند، حواله هم کم میکند، و کالا دو بار از حساب میرود. قاعده ساده است: فقط یک سند موجودی را کم کند و دیگری جای کالا و تحویلِ واقعی را ثبت کند. در بیشترِ سیستم‌های ساده فاکتور کم میکند — چون از لحظه‌ی فروش، کالا دیگر آزاد نیست — و حواله فقط خروجِ فیزیکی را تأیید میکند.
حواله سه وضعیتِ کافی دارد: صادرشده (بار هنوز در انبار است)، تحویل‌شده (انباردار تأیید کرده بار رفته) و باطل‌شده. ابطال باید با دلیل باشد و حواله پاک نشود؛ حواله‌ای که بی‌ردپا حذف شود، سه ماه بعد هیچ‌کس نمی‌داند چرا مشتری میگوید جنس نرسیده. شماره‌ی حواله هم باید دنباله‌ی خودش را داشته باشد، وگرنه دنباله‌ی رسمیِ فاکتورها سوراخ میشود؛ و برگه‌ی چاپی‌اش جای امضای انباردار، راننده و تحویل‌گیرنده را می‌خواهد.
موجودی انبار: آزاد، فیزیکی و نقشِ پیشفاکتور
«موجودی» در واقع دو عدد است. موجودیِ آزاد آن چیزی است که هنوز به هیچ مشتری‌ای تعهد نشده و میشود فروخت. موجودیِ فیزیکی آن چیزی است که اگر همین حالا به انبار بروید، می‌شمارید. اختلافِ این دو، کالاهایی است که فروخته شده و حواله خورده‌اند ولی هنوز از درِ انبار بیرون نرفته‌اند. وقتی همهی حواله‌ها تحویل شده باشند، دو عدد برابرند.
هر کدام از این دو عدد مخاطبِ خودش را دارد. فروشنده باید فقط عددِ آزاد را ببیند؛ اگر عددِ فیزیکی را ببیند، کالایی را که دیروز به مشتریِ دیگری فروخته شده و منتظرِ بارگیری است، دوباره می‌فروشد. انباردار و مدیر به عددِ فیزیکی نیاز دارند، چون انبارگردانی و برنامه‌ی بارگیری با آن انجام میشود.
سؤالِ بعدی این است که پیشفاکتور موجودی را کم کند یا نه. جوابِ کوتاه: نه. پیشفاکتور پیشنهاد است و مشتری هنوز چیزی نخریده؛ اگر هر پیشنهادِ قیمت موجودی را قفل کند، بعد از یک ماه نیمی از انبار پشتِ پیشنهادهایی گیر کرده که هیچ‌وقت جواب نگرفته‌اند. ولی بی‌تفاوتی هم درست نیست: فروشنده‌ای که پیشفاکتورِ ۲۰۰ عددی برای کالایی با موجودیِ ۵۰ صادر میکند، باید همان لحظه هشدار بگیرد. اینکه پیشفاکتور چطور صادر، تأیید و به فاکتور تبدیل میشود را در راهنمای پیشفاکتور نوشته‌ایم.
نکته‌ی فنی‌ای که ارزشِ دانستن دارد: موجودی بهتر است از سندها محاسبه شود، نه اینکه به‌صورتِ یک عدد جایی ذخیره شود؛ عددِ ذخیره‌شده با هر ویرایش یا ابطالِ فاکتور دیر یا زود از سندها جدا می‌افتد. فرمولش ساده است: موجودیِ اولِ دوره، بهاضافهی خرید و برگشت از فروش و اصلاحیه‌ها، منهای فروش و برگشت از خرید و ضایعات. هر تغییرِ دستی — انبارگردانی یا ضایعات — هم باید با ذکرِ دلیل ثبت شود.
موجودی منفی: هشدار یا توقفِ فروش؟
موجودیِ منفی در نگاهِ اول غیرممکن به نظر می‌رسد، ولی در عمل زیاد پیش می‌آید و معمولاً یکی از سه معنا را دارد: خرید هنوز ثبت نشده، موجودیِ اولِ دوره هیچ‌وقت وارد نشده، یا واقعاً کمبود داریم. دو سیاستِ کلی وجود دارد. سیاستِ آزاد اجازه می‌دهد فاکتور با کمبود هم صادر شود و عددِ منفی را قرمز نشان می‌دهد تا کسی پیگیرش شود. سیاستِ سخت‌گیر جلوی صدورِ فاکتور را می‌گیرد و میگوید چقدر موجودی هست و چقدر خواسته شده.
سیاستِ سخت‌گیر یک پیش‌شرط دارد که زیاد فراموش میشود: اول باید موجودیِ اولِ دوره‌ی همهی کالاها وارد شده باشد. اگر نشده باشد، موجودیِ همه‌چیز صفر است و هیچ فاکتوری صادر نمی‌شود. برای همین پیشنهادِ عملی ما این است: ماهِ اول با سیاستِ آزاد کار کنید، عددهای منفی را یکی‌یکی ریشه‌یابی کنید (بیشترشان خریدِ ثبت‌نشده‌اند)، و بعد برای فاکتور سیاستِ سخت‌گیر را روشن کنید. فاکتورِ خرید را هم هرگز نباید متوقف کرد؛ ورودِ کالا کمبود نمی‌سازد.
راهِ میانه هم هست: پیشفاکتور فقط هشدار بدهد، چون ممکن است تا تبدیل‌شدنش کالا برسد؛ فاکتور مسدود شود، چون آنجا قولِ واقعی به مشتری داده میشود.
انتقال بین انبارها: جای کالا عوض میشود، جمعش نه
وقتی ده کارتن از انبارِ اصفهان به انبارِ تهران میرود، شرکت نه چیزی خریده و نه چیزی فروخته. انتقال بین انبارها نه ورود است نه خروج؛ فقط جای کالا عوض میشود و جمعِ موجودی باید دقیقاً همان قبلی بماند. این بدیهی به نظر می‌رسد، ولی بسیاری از سیستم‌ها انتقال را با دو سندِ جدا ثبت می‌کنند: یک خروج از مبدأ و یک ورود به مقصد. کافی است یکی از این دو فراموش یا حذف شود تا کالا از هوا ساخته شود یا دود شود.
طراحیِ درست، انتقال را یک ردیف می‌بیند با دو انبار: مبدأ و مقصد. چند قاعده‌ی دیگر هم جلوی خطاهای رایج را می‌گیرد: مبدأ و مقصد نباید یکی باشند؛ تعداد همیشه مثبت نوشته شود و جهت از انتخابِ مبدأ و مقصد معلوم شود، نه از علامتِ عدد؛ کسی که انتقال را ثبت میکند باید به هر دو انبار دسترسی داشته باشد؛ و جای یک توضیح باشد برای شماره‌ی بارنامه یا نامِ راننده. انتقالِ اشتباه را هم حذف و دوباره ثبت کنید، نه ویرایش.
چه کسی کدام انبار را ببیند؟ دسترسی و قیمت خرید
در شرکتی که دو یا سه انبار دارد، لازم نیست همه همه‌چیز را ببینند. انباردارِ تهران با حواله‌های تهران کار دارد، نه مشهد. دسترسی بهتر است به‌ازای هر انبار داده شود و پیش‌فرضش بسته باشد: مدیران همه‌چیز را می‌بینند و بقیه فقط آنچه صریحاً به آن‌ها داده شده. باز گذاشتنِ پیشفرض و بستنِ دستی، یعنی همیشه یک نفر هست که یادتان رفته ببندید.
دو چیز را هم نباید با هم قاطی کرد. «دسترسی» یعنی کسی بخشِ انبار را ببیند؛ «انبارداری» یعنی مسئولِ تحویلِ کالای آن انبار باشد. انباردار باید خودبه‌خود به انبارِ خودش دسترسی داشته باشد، ولی هر کسی که دسترسی دارد انباردار نیست و لازم نیست خبرِ ورودِ هر کارتن را بگیرد.
موضوعِ حساسِ دیگر قیمت خرید است. قیمتِ خرید یعنی حاشیه‌ی سودِ شما، و فروشنده‌ای که آن را می‌داند در مذاکره راحت‌تر تا مرزِ ضرر تخفیف می‌دهد. یک انبارداریِ ساده هم باید بتواند قیمتِ خرید را برای افرادِ مشخص پنهان کند. موضوعِ گسترده‌ترِ حفاظت از داده را در امنیت اطلاعات مشتریان نوشته‌ایم.
گزارشِ برند و کالا: انبار فقط شمارش نیست
وقتی کالا و فروش در یک جا باشند، سؤال‌های تازه‌ای قابلِ جواب می‌شوند: کدام برند بیشترین فروش را داشت؟ کدام کالا در کدام شرکتِ زیرمجموعه بهتر فروخته؟ برای اینکه این گزارش‌ها راست بگویند، دو قاعده لازم است. اول، برند باید از یک فهرستِ ثابت انتخاب شود، نه اینکه تایپ شود؛ با تایپِ آزاد، «آلفا»، «آلفا » با یک فاصله‌ی اضافه و «Alfa» سه برندِ جدا می‌شوند و گزارش برای همیشه غلط می‌ماند. دوم، گزارشِ گذشته باید از خودِ سندِ صادرشده خوانده شود، نه از کارتِ کالا؛ وگرنه با عوض‌کردنِ برندِ یک کالا، فروشِ پارسال هم عوض میشود. و فقط فاکتورِ قطعی فروش است؛ پیشفاکتور عددها را باد میکند.
کِی انبارداریِ ساده کافی نیست؟
صادقانه بگوییم: انبارداریِ ساده برای همه نیست. اگر چندتا از این‌ها درباره‌ی شما درست است، به نرم‌افزارِ انبارداریِ تخصصی یا یک ERP نیاز دارید:
- محلِ قفسه: انبارتان آن‌قدر بزرگ است که «کالا کجای انبار است» خودش یک سؤال است.
- اسکنر و بارکد در هر جابه‌جایی: چند نفر هم‌زمان بار می‌چینند و ثبتِ دستی دیگر جواب نمی‌دهد.
- روشِ ارزش‌گذاریِ دیگری جز میانگینِ موزون: حسابرس روشِ دیگری برای بهای تمام‌شده می‌خواهد، یا بها باید برای هر انبار جدا حساب شود.
- تولید: مواد اولیه به محصول تبدیل میشود و فرمولِ ساخت دارید.
نشانه‌ی برعکس هم مهم است. اگر دردِ اصلی‌تان «چیزی را فروختیم که نداشتیم» یا «نمی‌دانیم بار از کدام انبار رفت» است، این دردِ ERP نیست؛ دردِ فاصله‌ی بینِ فروش و انبار است و با ابزارِ سبک‌تری حل میشود. مقایسه‌ی کامل‌تر را در تفاوت CRM و ERP و نرم‌افزار حسابداری و برای تیم‌های کوچک در CRM برای کسب‌وکار کوچک ببینید.
انبار و فروش در یک نرم‌افزار: ملل CRM چه دارد
تا اینجا گفتیم یک انبارداریِ ساده چه قاعده‌هایی لازم دارد. نرم‌افزار CRM ملل انبار را کنارِ پیشفاکتور و فاکتور نگه می‌دارد، نه در نرم‌افزاری جدا؛ یعنی همان سی آر امی که پرونده‌ی مشتری و پیگیری‌ها در آن است، حواله و موجودی را هم دارد. نامِ داخلِ «» همان چیزی است که در نرم‌افزار می‌بینید.
از فاکتور تا حواله
انبارِ هر ردیف در جدولِ ردیف‌های فاکتور از کشوی «انبار» انتخاب میشود. وقتی پیشفاکتورِ تأییدشده به فاکتورِ فروش تبدیل میشود، برای هر انباری که در ردیف‌ها آمده خودکار یک حواله صادر میشود و در صفحهی «حواله‌های انبار» با وضعیتِ «صادر شده» می‌نشیند؛ ردیفی که انبار نداشته باشد حواله نمی‌گیرد و پیامِ تبدیل هشدارش را می‌دهد. انباردار بعد از بارگیری «تحویل شد» را می‌زند؛ «ابطال» هم با «دلیلِ ابطال» اجباری انجام میشود و حواله پاک نمی‌شود. دکمه‌ی «چاپ» برگه‌ای با سه جای امضا (انباردار، راننده، تحویل‌گیرنده) می‌دهد و شماره‌ی حواله، مثلِ ح-۱۴۰۵-۰۰۰۱، از شمارنده‌ی جدا می‌آید نه از شماره‌ی فاکتورها. کسرِ موجودی کارِ خودِ فاکتور است و حواله دوباره کم نمی‌کند. جزئیاتِ صدور و تأییدِ خودِ فاکتور در CRM با صدور فاکتور رسمی و وصول مطالبات آمده است.
موجودی و سیاستِ کمبود
صفحهی «موجودی انبار» در حالتِ «کلِ شرکت» دو ستونِ اصلی دارد: «موجودی» که همان موجودیِ آزاد است، و «موجودیِ فیزیکی» که فقط مدیرِ شرکت و انباردار می‌بینند، با نشانی مثلِ «−۵ حواله» برای کالای حواله‌خورده‌ای که هنوز تحویل نشده. موجودی از فاکتورهای قطعی و سندهای انبار («رسیدهای انبار»، حواله‌ی مصرف و انبارگردانی) محاسبه میشود؛ پیشفاکتور اثری ندارد و سندِ باطل خودبه‌خود کنار میرود. چیزهایی که سندِ دیگری ندارند با «گردش دستی» ثبت می‌شوند: «موجودی اول دوره» (یک بار برای هر کالا در هر انبار)، «رسید کالا» برای تحویل‌های روزانه (هرچند راهِ اصلیِ ورودِ کالا حالا «رسید انبار جدید» در صفحهی «رسیدهای انبار» است)، و «اصلاح انبارگردانی» و «ضایعات» با دلیلِ اجباری. هر «رسید کالا» در نوارِ بالای صفحه اعلانِ ورودِ کالا می‌سازد که به مدیرِ شرکت و انباردارِ همان انبار می‌رسد.
سیاستِ کمبود در «تنظیمات» است: «اجازهی منفی‌شدن موجودی انبار» بهطورِ پیشفرض روشن است و اگر خاموشش کنید، فاکتورِ فروش و برگشت از خرید با کمبود صادر نمیشوند (فاکتورِ خرید هرگز متوقف نمی‌شود). کارتِ «کمبودِ موجودی هنگامِ صدور» هم برای پیشفاکتور و فاکتور جداگانه یکی از سه حالتِ «پیشفرض»، «فقط هشدار» یا «مسدود» را می‌گیرد و فقط مدیرِ شرکت عوضش میکند. روی خودِ فرم، کادرِ زرد یعنی هشدار و ذخیره، کادرِ سرخ یعنی ذخیره انجام نمی‌شود.
انبارها، انتقال و دسترسی
در صفحهی «انبارها» با «انبار جدید» برای هر شرکت چند انبار می‌سازید (مثلاً تهران و مشهد)؛ انباری که گردش دارد حذف نمی‌شود و به‌جایش غیرفعال میشود. انتقال از «موجودی انبار» با «گردش دستی» و بعد «انتقال بین انبارها» انجام میشود: «از انبار»، «به انبار»، تعدادِ مثبت و «ثبت انتقال»؛ یک ردیف، با نمایشِ «مبدأ ← مقصد». دسترسی از ستونِ «دسترسی» در همان صفحهی «انبارها» و با «ذخیره دسترسی» داده میشود و پیش‌فرضش بسته است: مدیرانِ شرکت همهی انبارها را می‌بینند، انباردار انبارِ خودش را، و بقیه فقط آنچه مدیر داده. کشوی انبارِ فاکتور اما برای همه باز است تا فروشنده بتواند انبارِ بار را انتخاب کند — بی‌آنکه عددِ موجودی ببیند. برای قیمت خرید هم در «اجازهی دیدن، ویرایش و حذف هر همکار» کلیدِ «دیدنِ قیمت خرید» هست؛ پیشفرض روشن است و مدیر میتواند برای هر همکار خاموشش کند.
برند در صفحهی «برندها» ساخته و در فرمِ کالا از کشو انتخاب میشود و پایینِ همان صفحه گزارشِ فروش بر اساسِ برند هست؛ «فروش کالا به تفکیک شرکت» هم فروشِ هر کالا را در هر شرکتِ زیرمجموعه کنارِ هم می‌گذارد. برای آوردنِ فهرستِ کالاها از نرم‌افزارِ قبلی، انتقال به CRM جدید را ببینید.
| قابلیت | در ملل CRM | توضیح |
|---|---|---|
| چند انبار زیرِ هر شرکت | ✓ داریم | «انبار جدید» با نام، کد، شرکت، انباردار و آدرس؛ انبارِ بی‌شرکت «مشترک» است؛ انبارِ گردش‌دار فقط غیرفعال میشود |
| حواله‌ی خودکار برای هر انبار | ✓ داریم | هنگامِ تبدیلِ پیشفاکتورِ تأییدشده به فاکتورِ فروش؛ «صادر شده» / «تحویل شد» / «باطل شد»؛ «ابطال» با دلیلِ اجباری |
| برگه‌ی چاپیِ حواله | ✓ داریم | «چاپ» با سه جای امضا؛ شماره‌ی جدا از فاکتور |
| موجودیِ آزاد و فیزیکی | ✓ داریم | «موجودی» و «موجودیِ فیزیکی» (فقط مدیرِ شرکت و انباردار)؛ پیشفاکتور موجودی را کم نمی‌کند |
| گردشِ دستی با دلیل | ✓ داریم | «موجودی اول دوره»، «رسید کالا»، «اصلاح انبارگردانی» و «ضایعات» |
| سیاستِ موجودیِ منفی و کمبود | ✓ داریم | «اجازهی منفی‌شدن موجودی انبار» و «کمبودِ موجودی هنگامِ صدور» جدا برای پیشفاکتور و فاکتور |
| انتقال بین انبارها | ✓ داریم | یک ردیف با مبدأ و مقصد؛ جمعِ موجودی ثابت می‌ماند؛ دسترسی به هر دو انبار لازم است |
| دسترسی به‌ازای هر انبار | ✓ داریم | پیشفرض بسته؛ «ذخیره دسترسی»، «همهی همکاران» و «هیچ‌کس»؛ انباردار خودکار دسترسی دارد |
| اعلانِ ورودِ کالا | ✓ داریم | با هر «رسید کالا» در نوارِ بالا، برای مدیرِ شرکت و انباردارِ همان انبار؛ بعد از ۲۴ ساعت خودش می‌افتد |
| پنهان‌کردنِ قیمت خرید | ✓ داریم | کلیدِ «دیدنِ قیمت خرید» برای هر همکار؛ خودِ فاکتورهای خرید پنهان نمیشوند |
| گزارشِ فروش بر اساسِ برند و کالا | ✓ داریم | پایینِ صفحهی «برندها»؛ «فروش کالا به تفکیک شرکت» |
| موجودیِ جداگانه‌ی هر انبار | ✓ داریم | کشوی «انبار» در «موجودی انبار»: «کلِ شرکت»، «همهی انبارها» یا یک انبار. کمبود بهطورِ پیشفرض در سطحِ شرکت سنجیده میشود، و با تیکِ «کمبود در سطح انبارِ هر ردیف سنجیده شود» در «تنظیمات انبار» در سطحِ همان انبار |
| انتقالِ کالا بینِ انبارِ دو شرکتِ زیرمجموعه | به‌زودی | انتقال فعلاً بینِ انبارهای یک شرکت است |
| موجودی به تفکیکِ سری ساخت (بچ) و تاریخِ انقضا | ✓ داریم | تیکِ «ردیابی با سری ساخت» در فرمِ کالا؛ جدولِ «سری‌های این کالا» در «موجودی انبار» با انقضا و انبار؛ صفحهی «سری‌های نزدیک به انقضا»؛ در فاکتور، سری‌های موجود پیشنهاد می‌شوند و برای سریِ منقضی هشدارِ زرد می‌آید |
| موجودی به تفکیکِ محلِ قفسه | ملل این کار را نمی‌کند | محلِ نگه‌داری داخلِ انبار ثبت نمی‌شود؛ در انبارگردانی فقط یک «برچسب» ی اختیاری برای شماره‌ی کارت یا قفسه هست |
پرسش‌های متداول درباره‌ی انبارداریِ ساده
حواله انبار چیست؟
حواله انبار سندِ خروجِ کالا از یک انبارِ مشخص است: چه کالایی، چند عدد، از کدام انبار و برای کدام فاکتور. در ملل CRM وقتی پیشفاکتورِ تأییدشده به فاکتورِ فروش تبدیل میشود، برای هر انباری که در ردیف‌ها آمده خودکار یک حواله صادر میشود.
حواله موجودی را دوباره کم میکند؟
نه. در ملل CRM موجودی را خودِ فاکتورِ فروش کم میکند و حواله فقط میگوید کالا از کدام انبار میرود و انباردار تحویل داده یا نه. اگر هر دو کم میکردند، کالا دو بار کسر میشد.
پیشفاکتور موجودی انبار را کم میکند؟
نه. پیشفاکتور تعهد است، نه گردشِ کالا، و فقط فاکتورِ قطعی شمرده میشود. ولی مدیرِ شرکت میتواند تعیین کند هنگامِ ثبتِ پیشفاکتورِ بیشتر از موجودی فقط هشدار داده شود یا ذخیره مسدود شود.
موجودی هر انبار جداگانه نشان داده میشود؟
بله. در صفحهی «موجودی انبار» کشوی «انبار» سه حالت دارد: «کلِ شرکت»، «همهی انبارها» (یک ستون برای هر انبار، بهاضافهی «بیانبار» و «سایر انبارها») یا یک انبار. کمبود بهطورِ پیشفرض در سطحِ کلِ شرکت سنجیده میشود، و مدیرِ شرکت میتواند در «تنظیمات انبار» تیکِ «کمبود در سطح انبارِ هر ردیف سنجیده شود» را بزند.
میشود قیمت خرید را از فروشندهها پنهان کرد؟
بله. مدیر در صفحهی «اجازهی دیدن، ویرایش و حذف هر همکار» کلیدِ «دیدنِ قیمت خرید» را برای آن همکار خاموش میکند تا ستون و فیلدِ قیمت خرید را نبیند. خودِ فاکتورهای خرید با این کلید پنهان نمیشوند.
ملل CRM موجودی را به تفکیک سری، بچ یا قفسه نگه می‌دارد؟
سری و بچ بله، قفسه نه. برای کالایی که در فرمش تیکِ «ردیابی با سری ساخت» خورده، «موجودی انبار» موجودیِ هر سری را با تاریخِ انقضا و انبار نشان می‌دهد. صفحهی «سری‌های نزدیک به انقضا» سری‌هایی را که به انقضا نزدیک‌اند فهرست میکند، و در فاکتور سری‌های موجود در انبارِ هر ردیف پیشنهاد می‌شوند. ولی محلِ قفسه نگه‌داری نمی‌شود و برای آن نرم‌افزارِ انبارداریِ تخصصی لازم است.
