انجمن‌ها

سلام

ممنون از اطلاع‌رسانی - حتما بررسی می‌کنیم و نتیجه را در همینجا اعلام می‌کنیم.

ارادت

دیروز با موردی برخورد کردم که کالایی در انبار داریم که 10 عدد موجودی دارد 15 عدد رزرو شده و زمانی که کاربر درخواست ثبت می کند و رزرو می کند با پیام خطا مواجه می شود ولی می تواند حواله خروج (فروش) آنرا ثبت کند.

روند تشک برن به این صورت است که یک انبار مرکزی داریم و چندین فروشگاه. در صورتی که یک فروشنده کالایی را بفروشد باید برای آن درخواست ثبت و رزرو کند تا اگر فروشنده دیگری همین کالا را فروخت متوجه شود که موجودی نداریم و کالا قبلا فروخته شده است. (فاصله ی ثبت درخواست تا ارسال بار حداقل 24 ساعت است) و درخواست آنرا با رزرو خیر ذخیره می کند. واحد تامین کالا بر اساس درخواست های رزرو نشده اقدام به تامین کالا می کند. داشتن موجودی فیزیکی انبار های مرکزی (تهران مشهد و شیراز و اهواز) موجودی پس از کسر رزرو و درخواست های رزرو نشده برای تشک برن بسیار اهمیت دارد.

روند تشک برن به این صورت است که یک انبار مرکزی داریم و چندین فروشگاه. در صورتی که یک فروشنده کالایی را بفروشد باید برای آن درخواست ثبت و رزرو کند تا اگر فروشنده دیگری همین کالا را فروخت متوجه شود که موجودی نداریم و کالا قبلا فروخته شده است. (فاصله ی ثبت درخواست تا ارسال بار حداقل 24 ساعت است) و درخواست آنرا با رزرو خیر ذخیره می کند. واحد تامین کالا بر اساس درخواست های رزرو نشده اقدام به تامین کالا می کند. داشتن موجودی فیزیکی انبار های مرکزی (تهران مشهد و شیراز و اهواز) موجودی پس از کسر رزرو و درخواست های رزرو نشده برای تشک برن بسیار اهمیت دارد.

سلام

در مورد موجودی پس از کسر رزرو گزارش‌های لازم قابل تهیه است - همان گزارش گردش و موجودی کالاها با فرم "موجودی و درخواست". در همانجا می‌توان گفت که فقط کالاهای رزرو شده بازنمایی شوند.

رزرو کالایی که "موجودی قابل رزرو" ندارد برای هیچ کاربردی میسر نیست. خروج کالاهای رزرو شده برای کاربری که اختیار این کار را داشته باشد میسر است. این کاربر با اخطار مواجه می‌شود و اگر تایید کند می‌تواند کالای رزرو شده را خارج نماید. در واقع همین یک اختیار منجر به تفاوت کالای رزرو شده و کالای ناموجود است. در مثالی که فرمودید احتمالا این نکات در کار هستند. لطفا با توضیحاتی که عرض شد مسئله را دوباره بررسی بفرمایید و اگر رفتار سیستم جز این است بفرمایید تا رفع اشکال کنیم.

در مورد کنترل رزرو در زمان انتقال به یک انبار دیگر مشغول کار هستیم و همانطور که عرض کردم نتیجه را در همینجا اعلام خواهیم کرد.

خیلی ممنونم . در دسترسی ها این مورد را دیدم و انجام دادم

سلام مجدد

ابتدا نکاتی را شرح می‌دهم و پس از آن تغییرات مورد نظر را بیان خواهم کرد؛

1) در سیستم انبار کنترل موجودی کالاها به تفکیک انبار (و بچ و مرجع شناسایی ویژه) در سرور انجام می‌شود. این مطمئن‌ترین مکان برای پیاده‌سازی قانون و منطق عملیات است. به این ترتیب امکان ندارد که مثلا موجودی کالایی منفی شود (البته مگر اینکه داده‌ها خراب شده باشند).

2) در مورد کنترل موجودی با احتساب رزرو، متاسفانه امکان کنترل و پیاده‌سازی در سرور را نداشته‌ایم - تنها دلیل این وضعیت این بوده که برخی از کاربران می‌خواهند این اختیار را داشته باشند که کالای رزرو شده را به مصرف دیگری (به جز مرکزی که آنرا رزرو کرده است) برسانند و باید در این زمینه اختیار داشته باشند.

3) کنترل در سرور روی وضعیت نهایی داده‌ها (پس از اعمال تغییرات) انجام می‌شود ولی کنترل در کلاینت باید "پیش از" اعمال تغییرات انجام شود. این تغییرات ممکن است بسیار متنوع باشند: درج رخداد جدید، اصلاح یک رخداد (کالا یا انبار یا بچ یا مقدار...)، حذف کل برگه... باید هر مورد را به دقت بررسی کنیم.

4) برخی از کلاس‌های برگه‌ها (و رخدادها) در انبار حالت سیستمی (ستادی و غیرعملیاتی) دارند؛ ابتدای دوره، انتهای دوره، اصلاح بها و انبارگردانی از این دست هستند. کنترل رزرو در این کلاس منطقی نیست - مثلا فرض کنید پس از شمارش کالاها در انبارها بخواهید تغییرات دلخواه را اعمال کنید و با خطای رزرو شدن کالا مواجه شوید! تا پیش از این نقل و انتقال را نیز کلاس سیستمی فرض کرده بودیم.

5) هر رخداد نقل و انتقال دارای یک یا چند رخداد طرف نقل و انتقال نیز هست. با اینکه این رخدادها حالت افزاینده (به موجودی) دارند اما ممکن است تغییرات یک برگه، نسبت به آنچه قبلا در سیستم وجود داشته است منجر به کاهش موجودی شود. مثلا قبلا طرف نقل و انتقال 4 واحد بوده و در اصلاح برگه به دو واحد کاهش داده شود. این تغییر منجر به کاهش دو واحد از موجودی می‌شود. یا از این بدتر، ممکن است رخداد انتقال (به همراه طرف آن) حذف شود. در این وضعیت اصولا دسترسی به داده‌هایی که حذف شده‌اند هم نخواهیم داشت!

6) اگر فقط به رخدادهای انتقال توجه کنیم، از آنجا که به احتمال زیاد کالاهای مندرج در رخدادهای انتقال و طرف انتقال یکسان هستند (و صرفا انبار یا بچ آنها تغییر داده شده است)، کنترل رزرو در کل سیستم (نه به تفکیک انبار یا بچ) کارساز نخواهد بود -- کالایی که موجودی آن در رخداد انتقال کاسته شده است در رخداد طرف، تامین موجودی شده است.

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

ارادت

خیلی ممنونم از توضیحات کامل شما و وقتی که گذاشته اید.
آیا این امکان وجود دارد که در گزارش گردش و موجودی ( با استفاده از فرم مربوط به احتساب درخواست ها) فقط رزرو های یک انبار (در صورتی که فقط یک انبار انتخاب شده باشد) در گزارش لحاظ شود. در این صورت ما می توانیم موجودی و رزرو را در یک انبار مشاهده و کنترل کنیم

سلام
از توضیحات ارزشمند شما سپاسگذارم
اتفاقا قبلا با مجموعه هایی که درخواست های مستقل از انبار داشتند برخورد داشته ام . یعنی شرکت و مشتری موافق هستند تحت هر شرایطی کالا از هر انباری که موجودی دارد تحویل شود. اما در تشک برن ثبت درخواست بدون انبار ممنوع است و هیچ اقدامی برای درخواست بدون انبار صورت نمی گیرد (حتی اگر می شد ثبت انبار در درخواست اجباری بود برای برن بهتر بود).
بنابراین درخصوص لحاظ شدن درخواستهای بدون انبار به همراه سطرهای دارای انبار و تشابه آن با مرکز، از قضا همانطور که برای مراکز به کمک Tab شرایط می توانیم صرفا درخواستهای دارای مرکز را در گزارش منعکس کنیم، درصورت امکان شرایطی هم درخصوص رخدادهای درخواست دارای انبار در Tab شرایط در نظر گرفته شود

باتشکر

سلام

در گزارش‌هایی که سوژه آنها درخواست است این امکان را داریم - نیازی هم به شرایط نیست. در فهرست برگه‌های درخواست در Tab محتوی و در فهرست رخدادهای درخواست در Tab محتوی و در سایر گزارش‌های مبتنی بر درخواست‌ها (انواع سرجمع‌ها و محوری) در Tab رخدادها امکان لحاظ کردن درخواست‌های دارای انبار یا فاقد انبار(یا هردو) پیاده شده‌اند. در همان گزارش‌ها البته می‌توانیم در شرایط نیز از فیلد انبار و عملگرهای "وجود دارد/ندارد" به همین منظور استفاده کنیم.

اما در گزارش مورد بحث در اینجا، سوژه گزارش درخواست‌ها نیستند (بلکه عملیات انبار هستند) و به همین دلیل پارامترها و شرایط نیز صرفا برای رخدادهای انبار یا سطرهای گزارش (مثلا کالاها) یا سرجمع داده‌های محاسبه شده تنظیم می‌شوند. اطلاعات درخواست‌ها (و رزروها) به صورت داده‌های جانبی ارائه می‌شوند.

با سلام،

 

راهکارهای مناسب جهت پاسخگویی به بخشی از پیشنهادهای شما در نسخه 11.02 پیاده سازی گردیده‌اند. لطفا جهت کسب اطلاعات بیشتر به لینک امکانات نسخه 11.02 مراجعه فرمایید.

 

با ارادت