چنانچه در هریک از مراحل نصب یا کاربری نرم‌افزارها به مشکلی برخورد کرده‌اید یا هر سوال، اشکال یا ابهامی در این زمینه دارید، می‌توانید پاسخ خود را ابتدا در مطالب موجود جستجو و در صورت لزوم به عنوان یک مبحث جدید مطرح کنید، تا کارشناسان پشتیبانی به آن پاسخ دهند.

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

قبليقبلي Go to previous topic
بعديبعدي Go to next topic
آخرين ارسال 17 آذر 1400 04:11 ب.ظ توسط momeni
عدم کنترل موجودی پس از کسر رزرو در زمان نقل و انتقال
�11 پاسخ
مرتب:
شما مجاز به پاسخ به اين پست نمي باشيد.
مولف پيغام ها
farshad5642
کاربر جدید
کاربر جدید

--
08 آذر 1400 04:55 ب.ظ

    زمانی که انبار شماره یک موجودی دارد می توانیم درخواست خروج ثبت نموده و آنرا رزرو نماییم
    پس از آن برگه نقل و انتقال ثبت می کنیم اما اگر برگه دیگری از نوع خروج ثبت شود خطای موجودی می دهد
    با توجه به اینکه در زمان رزرو در صورتی که در یک انبار خاص موجودی کافی نباشد خطا موجودی داریم پس در زمان کم کردن موجودی آن انبار به هر نحوی بایستی خطا داشته باشیم
    با تشکر تشک برن

    momeni
    کاربر ارشد
    کاربر ارشد

    --
    08 آذر 1400 08:28 ب.ظ
    سلام

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

    ارادت
    farshad5642
    کاربر جدید
    کاربر جدید

    --
    10 آذر 1400 07:07 ق.ظ
    دیروز با موردی برخورد کردم که کالایی در انبار داریم که 10 عدد موجودی دارد 15 عدد رزرو شده و زمانی که کاربر درخواست ثبت می کند و رزرو می کند با پیام خطا مواجه می شود ولی می تواند حواله خروج (فروش) آنرا ثبت کند.
    farshad5642
    کاربر جدید
    کاربر جدید

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

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

    --
    10 آذر 1400 09:07 ق.ظ
    سلام

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

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

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

    --
    10 آذر 1400 09:39 ق.ظ
    خیلی ممنونم . در دسترسی ها این مورد را دیدم و انجام دادم
    momeni
    کاربر ارشد
    کاربر ارشد

    --
    10 آذر 1400 07:47 ب.ظ
    سلام مجدد

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

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

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

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

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

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

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

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

    ارادت
    farshad5642
    کاربر جدید
    کاربر جدید

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

    --
    17 آذر 1400 10:37 ق.ظ

    سلام مجدد

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

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

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

    همانطور که گفته شد در بررسی مجدد و با تجربه سال‌های اخیر به نظر می‌رسد که بهتر است از این اشکال به نفع گزارش تفکیک شده برحسب انبار صرف نظر کنیم. حتما به همین صورتی که اشاره فرمودید و در متن هم توضیح دادم عمل خواهیم کرد. انشالله در ویرایش 11 سیستم.

    ارادت

    farshad5642
    کاربر جدید
    کاربر جدید

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

    باتشکر
    momeni
    کاربر ارشد
    کاربر ارشد

    --
    17 آذر 1400 04:11 ب.ظ
    سلام

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

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