انجمن‌ها

سلام

جناب مولایی، لطفا با بنده تماس بگیرید. حقیر کلا در جریان نیستم.
جناب آقای / سرکار خانم خلیلی اجازه بفرمایید از خواسته‌ی حضرت‌عالی مطلع شوم. نتیجه را همینجا اطلاع خواهم داد.

ارادت

سلام مجدد

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

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

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

از طرفی وجود متد API فقط بخشی از ماجرا است؛ نرم‌افزار مرکزی فرآیند باید امکان اجرای متد مزبور را داشته باشد + همکاران ما در پیاده‌سازی فرآیند باید قادر باشند متد را با تشریفات خاص خود اجرا کنند - و همه‌ی اینها به زمان برای پیاده‌سازی نیاز دارد. به خصوص متدی مثل برگه‌ی نقل و انتقال که به صورت صریح در مستندات API به آن اشاره کرده‌ایم و ذکر شده که به علت پیچیدگی فوق‌العاده داده‌های این برگه، آنرا به صورت API پیاده‌سازی نکرده‌ایم - استفاده از آن واقعا مشکل می‌شد. اگر با ساختار داده‌های برگه‌های انبار (ورود و خروج) که هم‌اکنون در API قابل استفاده هستند آشنایی داشته باشید، ساختار برگه‌ی نقل و انتقال به صورت زیر است:

سند - برگه
رخداد طرف حساب عمومی
رخداد انبار نقل و انتقال با امکان شناسایی ویژه
رخداد طرف حساب اختصاصی
رخداد طرف نقل و انتقال
رخداد طرف حساب اختصاصی طرف نقل و انتقال
رخداد طرف نقل و انتقال
رخداد طرف حساب اختصاصی طرف نقل و انتقال
:
رخداد انبار نقل و انتقال با امکان شناسایی ویژه
رخداد طرف حساب اختصاصی
رخداد طرف نقل و انتقال
رخداد طرف حساب اختصاصی طرف نقل و انتقال
رخداد طرف نقل و انتقال
رخداد طرف حساب اختصاصی طرف نقل و انتقال
:
:

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

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

ارادت

سپاس از وقت و حوصله ای که گذاشتید برای این موضوع

ما برای رفع یک نیاز اساسی و تسریع و دقت در کار پس از مشاوره با کارشناسان محترم شرکت نوسا اقدام به خرید سیستم فرایند کردیم

پس از پیاده سازی اکنون  برای رسیدن به خواسته اولیه دو راهکار  از طرف کارشناسان اعلام شده که هیچ یک عملی نیست

1- ثبت برگه های نقل و انتقال بصورت روزانه و دستی توسط انباردار که به دلیل نبود امکان API باید دستی باشد ولی به دلیل حجم بالای برگه ها بصورت دستی هم ممکن نیست یا قابل توجیه نیست.

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

حال با این توضیحات چه باید کرد؟

آیا این موضوع نیاز به بررسی تیمی کارشناسان ندارد؟

امیدوارم با کمک جنابعالی و سایر همکاران راه حل جایگزین عملی پیدا شود

دیگه کاری جز تمنا و دعا از بنده ساخته نیست.

با سپاس 

فرهنگ خلیلی

سلام

جناب خلیلی، عرض کردم که آنچه از ما برمی‌آید را حتما انجام خواهیم داد. بقیه‌ی جزییات را در جریان نیستم. ممنون که ما را دعا می‌کنید.

ارادت

با سلام و عرض ادب خدمت جناب آقای مومنی و خلیلی

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

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

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

قبل از ادامه بحث، ذکر یک نکته حائز اهمیت است:
ما در زمان طراحی و مدلسازی فرآیندهای گوناگون، داده های مربوط به هر بخش از فرآیند را، در سیستم مالک آن بخش ثبت می کنیم و در زمان نیاز نیز، اطلاعات را از همان سیستم مالک می خوانیم. به این صورت اولا همواره نتیجه ی هر بخش از فرآیند، در سیستم مالک آن بخش در دسترس است؛ ثانیا اطلاعات در دو مکان ذخیره و نگهداری نمی شود و به این ترتیب از مغایرت اطلاعات جلوگیزی می شود. در مورد فرآیند مورد اشاره، در بخش نگهداری موجودی ها (مواد اولیه - نیمه ساخته - محصول)، مالک اطلاعات، نرم افزار انبار و کنترل موجودی است. به همین جهت مبنای ما در تمام مراحل و محاسبات، اطلاعاتی است که در سیستم انبار ثبت شده است.
حال به مساله اصلی بر گردیم:
بر اساس اطلاعاتی که در سیستم انبار مجموعه ثبت شده است، کلیه ی مواد تحویلی به خط، در زمان تحویل، از موجودی انبار کسر شده و به عنوان تحویل به تولید یا مصرف، از انبار خارج شده است. از طرفی مواد مازاد در پایان تولید، به صورت برگه ی برگشت تحویل به تولید یا برگشت مصرف، به انبار بازگردانده نمی شود. در این شرایط، دستیابی به موجودی نزد خط، بر اساس اطلاعات انبار، غیر ممکن است.
راه حل های پیشنهادی:
1- استفاده از انبار پای کار: در این شیوه، کالای تحویلی به خط، از انبار اصلی، به انبار پای کار منتقل می شود (با ثبت برگه ی نقل و انتقال). در زمان اعلام تولید محصولات، بر اساس BOM از موجودی انبار پای کار، خروج مواد ثبت می شود و به این ترتیب، موجودی انبار پای کار، در سیستم انبار در دسترس خواهد بود.
2- برگشت مواد اضافی نزد خط به انبار: از آن جا که مواد به صورت فیزیکی به انبار اصلی عودت داده نمی شود، نمی توان برگشت مواد را به انبار اصلی انجام داد. بلکه می بایست برگشت را در انبار جدیدی (مانند انبار نزد تولید) ثبت کرد. نتیجتا امکان استفاده از رخداد برگشت دوره جاری (به دلیل یکسان نبودن انبار مبدا و برگشت) میسر نبوده و می بایست از رخداد برگشت دوره قبل استقاده شود.

در واقع وضع موجود، حاصل کنار هم قرار گرفتن تمام موارد فوق و عملی نشدن تمام پیش نیازهای مذکور است.

وقت بخیر با آرزوی سلامتی و پایان خوش برای وضع موجود

جناب مولایی فکر می کنم موضوع رو پیچیده تر فرمودید

هر دو پیشنهاد با اشکالاتی مواجه است وگرنه ما پیشنهاد اول را پذیرفتیم که انبار پای کار ایجاد کنیم

اما متوجه شدیم که باید برگه های نقل و انتقال را به صورت دستی ثبت کنیم و سیستم امکان ثبت از طریق API را ندارد

ثبت دستی برای ما مقدور نیست چون حجم  برگه ها بالاست و کلا این کار توجیه استفاده از سیستم و مکانیزاسیون را زیر سوال می برد

پیشنهاد دوم هم در صورت اجبار اجرا می کنیم اما آن هم سیستم با اشکال ثبت می کند و تمامی برگه ها به صورت دوره قبل ثبت می شود که این هم برای مالی یک دوباره کاری و قیمت گذاری پیچیده ایجاد می کند که عملی نیست.