azizi
کاربر
17 آذر 1393 01:22 ب.ظ |
|
سلام در درخت حساب امکان تعریف تفصیلی ها و ارتباط بین حساب و تفصیلی ما را از سردرگمی و گستردگی حساب ها نجات داده و کمک شایانی به گرفتن گزارشات مختلف و دلچسب به ما میکنه. حال در درخت کالاها یک شرکت بازرگانی را تصور نمایید که به خرید و فروش کاشی و سرامیک و ... مشغوله و محصولات مختلف کارخانجات را خریداری و در بازار به مشتریان داخل و خارج میفروشه ، فقط کاشی را تصور نمایید هر کارخانه ای مثلا 10مدل طرح داره، هر طرحی 8رنگ داره، هر رنگی 6 سایز داره، هر سایزی مدل A و B داره، هر مدلی 5درجه کیفی ساخت داره و ...(مثلا 9سطح دسته بندی میچینیم میایم پایین تا برسیم به کالای عملیاتی!! و تازه کاشی ها بچ هم دارن) خب اگه بخواهیم این دسته بندی برای هر طرح از کاشی تا کالای عملیاتی آن را انجام بدیم( درسته که امکان جابجایی و کپی کالاها در ساختار درختی کمک شایانی به ما میکنه) به نظرم این مشکلات را در پی داره: 1. گستردگی درخت کالا و تکراری بودن این دسته بندی در سطوح مختلف درخت کالا سرسام آوره 2. با فرض اینکه ما بخواهیم از تفصیلی کالا در نرم افزار فروش استفاده کنیم درج 9سطح کالا در درخت تفصیلی و مجددا در درخت کالا(با توجه به اینکه فقط سطح عملیاتی قابل فراخوانی از درخت تفصیلی ها هستند) 3. در رسید و حواله در زمانی که میخواهیم کالا را با // انتخاب کنیم چند ثانیه(3 الی 4) طول میکشه تا پنجره جستجو باز بشه 4. یکی از مشتریان تماس میگیره و مثلا میپرسه کاشی رنگ فیروزه ای چی دارین درسته در گزارشات میتونیم الگوی کد کاشی با رنگ فیروزه ای بگذاریم تا در تراز گردش کالاهای موجود را ببینیم ولی همینم یکم دشواره(این یخرده ایراد الکیه خودمم میدونم!!) خب بزرگواران راهکارتان برای حل این مساله چیست؟
(اگه در درخت کالا یجورایی درخت سطح بندی جداگانه(مثل تفصیلی که برای حساب داریم!) برای کالا داشته باشیم مثلا من کالا را نام کاملش تایپ کنم و از درخت فرضی تفصیلی سطح های مختلف آن(9مدل دسته بندی) را تیک کنم اینجوری گستردگی درخت کالا را نداشتیم و کار ما راحت میشد ولی خداییش علم سیستمی و برنامه نویسی در این مورد ندارم که چه مشکلات و باگ هایی میتونه در این راستا ایجاد کنه)
|
|
|
|
momeni
کاربر ارشد
17 آذر 1393 02:24 ب.ظ |
|
سلام امکان تعریف تفصیلیهای شناور "اصلا" برای کاستن از تعداد حسابها نیست! همینطور برای ممانعت از موارد تکراری هم نیست! از قضا یکی از بلایایی که گریبان اشخاصی که حسابها را با این ایده به تفصیلی تفکیک میکنند همین است که تصور میکنند هر جا آیتمهای تکراری مطرح است باید آنها را از حسابها به تفصیلیها ببرند. چنین میشود که مثلا یک حساب مشترک برای هزینههای سربار و هزینههای عمومی اداری و فروش تعریف میکنند و فرض میکنند که با تفصیلی میتوانند اقلام را تفکیک نمایند! این شیوه نادرست است و اطلاعات بسیار مهمی را از تراز حسابها حذف میکند. 1. وقتی تعداد کالاها زیاد است - خوب زیاد است و باید همه را تعریف کرد. تکراری بودن هم از ماهیت محصولات حاصل میشود. دلیلی برای سرسام نیست - ضمن اینکه به ما هم ربطی ندارد. 2. هیچ لزومی ندارد که برای هر قلم کالا یک تفصیلی جداگانه داشته باشیم. تفکیک تفصیلیهای اقلام قابل فروش در حسابداری به این بازمیگردد که با چه جزییاتی بخواهیم عمل گزارشگیری را فقط از حسابداری انجام دهیم. به همین دلیل ارتباط کالا با تفصیلی با درج تفصیلی در کالا انجام میشود. معمولا برای کالاهایی که فقط رنگ و طرح آنها متفاوت است از تفصیلیهای جداگانه استفاده نمیشود. 3. واقعا صبر ایوب میخواهد که 3 یا 4 ثانیه معطل شوند. 4. خودتان فرمودید... یکی از مشتریان ما در یک تولید کننده کاشی برای رفع این مشکل (که البته من درست متوجه نشدم اشکال از کجا است؟ جز اینکه تعداد کالاها زیاد است و 3 تا 4 ثانیه طول میکشد - واقعا زمان زیادی است) خلاصه از بچ استفاده کرده است. این روش، دقیقا همان مکانیزم ارتباط حساب و تفصیلی را در کالاها پیاده میکند - که البته به نظر من روش مناسبی نیست، اما چون توسط یکی از استادان بنده پیشنهاد و پیاده شده و الآن هم به خوبی کار میکند - علی رغم مخالفت شخصی - آنرا ذکر کردم. ضمن اینکه با اینکار تقریبا هیچیک از مشکلاتی که فرمودید رفع نمیشود (شاید به جز آن 3 یا 4 ثانیه). در واقع همه کارها را دشوارتر خواهد کرد.
|
|
|
|
azizi
کاربر
18 آذر 1393 02:06 ب.ظ |
|
با تشکر از عنایت شما اینطور که شما فرمودین برای رفع این مشکلاتی که عرض شد راه چاره ای نیست و به دلیل گستردگی کالا به خودشان مربوط می شود!! ولی میخواستم بدونم آیا راهکاری برای جلوگیری از این گستردگی کالاها وجود ندارد؟ (9سطح کالا همراه با بچ) آیا طرز چیدمان پیشنهادی کالا که در انتهای پیغام خدمتتان عرض شد میتواند راهکاری برای آینده باشد یا از نظر سیستمی به مشکل برمیخورد؟
|
|
|
|
momeni
کاربر ارشد
18 آذر 1393 03:06 ب.ظ |
|
سلام اگر توجه کرده باشید اصل عرض بنده این بود که گستردگی یک عملیات مشکل محسوب نمیشود - بلکه ذاتی عملیات است. پیشنهاد شما مبتنی بر درخت فرضی تفصیلی بود که وجود ندارد (و از دید بنده ضرورتی هم ندارد). همه آنچه از این درخت فرضی انتظار دارید الآن با بچ قابل دسترسی است. که آن هم مشکلات را رفع نمیکند - صرفا به کاهش تعداد کالاها کمک میکند که از دید بنده یک پدیده ذاتی و طبیعی است و مشکلی هم ندارد. ارادت
|
|
|
|
molaei
کاربر پیشرفته
19 آذر 1393 12:33 ب.ظ |
|
با سلام و عرض ادب آقای عزیزی عزیز، آیا قرار گرفتن کالاهای مذکور در یک ساختار 9 سطحی لزومی دارد؟ مگر غیر از این است که این طبقات بیشتر به منظور اخذ گزارشات از کالاهای سرگروه استفاده می شود؟ آیا از همه سطوح ماقبل کالاها گزارش خواهند گرفت؟ اگر برخی از این عناصر را صرفا در نام کالا بیاوریم؛ با جستجوی نام کالا با استفاده از % به راحتی و بدون شلوغ بودن کدینگ می توانند جستجوها را انجام دهند. در تایید فرمایش آقای مومنی: اینکه تعداد کالاها زیاد است، اشکال نیست که برای آن دنبال راه حل باشیم. به نظر بنده آنچه از نظر شما صرصام آور است، تعداد سطوح زیاد ما قبل آخر است؛ که ممکن است با روش عرض شده کمی تعدیل شود. مثال: فرض کنید در هنگام اخذ گزارشات، از سطوح مطرح شده، دو المان اهمیت ویژه ای دارند: طرح و سایز. طبقه بندی فرضی کالاها: سطح اول -------سطح دوم --------- کالای عملیاتی طرح نسترن ---- سایز 30*50 ---- کاشی نسترن 30*50 زمینه کرم درجه یک طرح نسترن ---- سایز 30*50 ---- کاشی نسترن 30*50 زمینه سفید درجه یک طرح نسترن ---- سایز 30*50 ---- کاشی نسترن 30*50 زمینه کرم درجه دو طرح نسترن ---- سایز 30*50 ---- کاشی نسترن 30*50 زمینه صورتی درجه یک و ... البته همچنان می توانیم در تعریف کالای سطح آخر، الگویی در نظر بگیریم که در گزارشات خاص کارگشا باشد. آیا این روش مشکلی دارد؟
|
|
|
|