انجمن‌ها

سلام

متوجه منظور شما نشدم !
اگر حین کار به نکاتی برخورد می کنید که فکر می کنید انعکاس آنها در سامانه پشتیبانی نوسا خالی از لطف نیست که محبت نمائید و این کار را انجام دهید و اگر منظورتان ایجاد یک انجمن جدید است که باز هم لطفا بفرمائید با چه عنوانی باشد که اگر در بین انجمنهای موجود نبود آنرا ایجاد نمائیم .

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

2- اگر در برگه های شمارش کالا این امکان وجود داشته باشد که بتوانیم بچ های فاقد مانده را شمارش نکنیم ، برای شرکتهای صنایع غذایی و داروسازی بسیار کارآمد خواهد بود . به دلیل اینکه در ساختار این شرکتها ، استفاده از بچ یک موضوع کلیدی و بسیار حیاتی است و ممکن است برای هر کد کالا سالیانه بالغ بر صد بچ مختلف ایجاد شود و تمام این بچها در همان سال منقضی و غیر قابل استفاده و نیز فاقد مانده شود ، لذا این شرکت بعد از دوسال برای انبار گردانی بایستی هزاران کد بی خاصیت را بدون دلیل در سیستم وارد نماید .

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

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

5 - اگر در گزارشات تراز در حسابداری مانند سایر گزارشات از درج علامت " / " در بین کدها معاف شویم بسیار ممنون و متشکر خواهیم شد .

6 - اگر در گزارشات " ریز عملیات " و سایر گزارشاتی که پنجره " شرایط " دارند ، در پنجره شرایط نیز مانند همه جا کلیدهای Insert , Ctrl+Delete برای ایجاد و حذف عمل کنند ، بسیار باعث سهولت کاربر خواهد بود .

7- اگر در هنگام ارتباط کالا با انبار مانند ارتباط حساب با تفصیلی بتوانیم از کلید Ctrl+R استفاده کنیم ، خیلی خوب است .

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

قبلا از همکاری صمیمانه جناب مومنی و سایر همکاران عزیز در تیم برنامه نویسی نوسا کمال تشکر و امتنان را دارم .
ارادت

سلام

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

2- کاملا درست می‌فرمایید. این مشکل رفع شده و در نسخه بعدی (زمستان امسال) وجود نخواهد داشت.

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

4- در این زمینه یک بحث قدیمی داشتیم که منجر به تغییراتی در یکی از نسخه‌های قبلی شد:

http://accsupport.nosa.co...v/topic/Default.aspx

مدتی پیش هم یک بحث جنبی در این زمینه داشته‌ایم

http://accsupport.nosa.co...v/topic/Default.aspx

متاسفانه امکان تغییر بیشتر در سیستم را در این زمینه نداریم. اما توضیحات فوق برای توضیح وضعیت موجود تلاش می‌کنند...


5 - متوجه منطور شما نشدم - اگر ممکن است بیشتر توضیح دهید.

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

7- بررسی می‌کنیم و اگر مشکلی نبود در نسخه بعدی پیاده می‌کینم.

8- همانطور که پیش از این وعده داده بودیم انجام شده است.

ارادت

سلام .

- در مورد بند 3 ، موضوع حساب اصلی درگیر است ، نه طرف حساب . در سیستم فروش برعکس انبار ، رخدادها دقیقا بر روی حساب اصلی اثر میگذارند .

- در مورد بند 5 منظور زمان اخذ گزارشات تراز است ، هنگامی که میخواهیم محدوده حساب را تعیین کنیم ( هم در تراز کلان و هم در ترازهای 4 و 8 ستونی در صفحه آخر) مثلا حتما باید درج کنیم : 211/05/01 در حالیکه در سایر گزارشات کافیست بنویسیم : 2110501 . البته این مساله در گزارشات انبار و فروش نیز وجود دارد .

ارادت

سلام

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

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

در مورد 5، اختلافی بین محدوده کد حسابها و انتخاب حساب صریح وجود دارد. همین اختلاف در مورد کد تفصیلی، کالا، مرکز و محل جغرافیایی هم برقرار است. وقتی محدوده تعیین می‌کنید قرار نیست کد یک حساب موجود تعیین شود - بلکه صرفا عبارتی تعیین می‌شود که کد حساب‌های موجود با آن مقایسه می‌شود. بنابراین در زمان تصویب محاوره سیستم به کنترل وجود حساب و درج خودکار /ها نمی‌پردازد. در صورتی که در دفتر و ریزعملیات قرار است که حتما یک حساب موجود انتخاب شود و به همین دلیل پردازش مورد نظر شما در آنجا انجام می‌شود. در زمان تعیین محدوده (و الگوی) کد، در صورتی که منظورتان انتخاب یکی از حساب‌های موجود است (نه صرفا درج عبارتی برای تعیین غیردقیق ابتدای محدوده)، می‌توانید از تکمه Ellipsis (همان 3 نقطه کنار کدهای شروع، خاتمه و الگو که با Ctrl+Enter هم کارمی‌کند) استفاده نمایید. تبدیل 2110501 به 211/05/01 هم در این وضعیت انجام می‌شود. در ضمن تعداد ارقام زیرگروه هم در فرآیند درج /های اضافی توسط سیستم تشخیص داده می‌شود و صفرهای مورد نیاز هم علاوه بر / به کد اضافه می‌شود. در مثال فوق، می‌توانید در کد شروع صرفا 21151 را وارد کنید و Ctrl+Enter را فشار دهید - به این معنی که منظور شما انتخاب یکی از حساب‌های موجود بوده است.

خلاصه این بحث چنین شد که در تنظیم شرایط کلیدهای Ins، Ctrl+Del و Shift+Enter را داشته باشیم + برای ارتباط کالاها با انبارها Ctrl+R را داشته باشیم که انشالله در نسخه بعدی پیاده خواهد شد.

ارادت

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

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

باز هم تشکر میکنم از اینکه حوصله فرمودید و تمام موارد را پاسخ دادید .

ارادت

سلام

در مورد اصلاح یکباره شرح، اطاعت. این مورد هم به نظر قابل انجام می‌آید.

در خدمت هستیم

ممنون

با عرض سلام

8 درخواست کوچک ولی جالب و قابل تامل
ممنون از شما جناب آقای مومنی و همکار عزیز آقای تاج الدینی
جناب آقای تاج الدینی: فکر کتم در اولین پست (ارادت) شما باعث شبه برای جناب اعتمادی شد که مطلبتان تمام شده ولی پس از مدتی درخواستهایتان ارسال شد!!

ممنون از همگی (خدا قوت)

سلام دوباره ؛
ممنون از اظهار لطف جناب آقاي مؤمني و افزودن درخواستهاي كوچك حقير در نسخه هاي قبلي !
چند نكته جديد داشتم كه حضورتان عرض ميكنم :
١- در تعريف سطوح دسترسي كاربران در نرم افزار. اگر بخواهيم از امكانات يك گروه فقط برخي مجاز باشند ، حتماً بايستي اول سرشاخه را مجاز نماييم و بعد زيرشاخه هاي موردنظر را غير مجاز كنيم و اگر برعكس عمل كنيم و سرشاخه را غير مجاز كنيم و برخي زيرشاخه ها را مجاز كنيم. امكانات مورد نظر مجاز نميشود .

٢- اگر در ارتباط يكباره كالاها به انبارها از سمت چپ درخت ، مانند ارتباط حسابها با تفصيليها ، اين امكان افزوده شود كه پس از ارتباط ، اين ارتباط پس از زدن كليدctrl+r مشاهده شود ، بسيار سپاسگذار خواهيم شد و از اشتباه كاربران نيز خودداري مينمايد .
٣- هنگامي كه يك برگه انبار كه رخدادهاي آن برگشت دوره جاري است ، در فايل صادره ذخيره ميشود ، پس از فراخواني مجدد برگه در يك برگه جديد ، تمام رخدادها به برگشت دوره قبل تبديل شده و مرجع هاي ثبت شده همگي حذف ميشوند و مجبوريم مجدداً رخدادها را اصلاح و مرجعها را ثبت كنيم .

٤- اگر در فرم چاپي برگه شمارش نهائي كالا ، علاوه بر ستونهاي شمارش نهائي و موجودي ، ستون مغايرت نيز موجود باشد ، بسيار كاربردي خواهد بود .
٥- اگر در كليه گزارشات فروش (بجز گزارشات فروش كالا كه تابع سطرهاي فاكتور است ) ، امكان افزودن ستون بهاي نهائي برگه نيز باشد ، همانطور كه ستونهاي مكمل بها و كسور و اضافات موجود است ، بسيار سپاسگذار خواهيم شد .

٦- در امكان ثبت يكباره تعدادي رخداد برگشت دوره جاري كه در برگه هاي انبار وجود دارد ، نرم افزار بجاي اينكه مانده مرجعها را برگشت دهد ، مقادير اوليه مرجع را برگشت ميدهد ، كه بعد از ثبت برگه مجددا مجبور به اصلاح مقادير برگشت هستيم تا برگه قابل ذخيره باشد .
ارادت

سلام

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

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

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

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

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


ارادت

با سلام و احترام

درخصوص برخي درخواستهايي که مطرح نموديد، متوجه منظورتان نشدم:

با سپاس

سلام مجدد ؛
در مورد درخواست اول به عنوان مثال اگر امكانات درخت حساب را براي يك كاربر غير مجاز كنيم و مثلاً فقط ملاحظه درخت حساب را براي وي مجاز كنيم ، باز هم كاربر امكان ملاحظه درخت حساب را نخواهد داشت .
براي اينكه درخواست ما قابل اجرا باشد ، حتماً بايست امكانات درخت حساب را تماماً مجاز نماييم و سپس تك به تك تمام امكانات زير شاخه بجز امكان ملاحظه درخت حسابها را غير مجاز كنيم تا نرم افزار متوجه منظور ما بشود . اين خاصيت را به عنوان يك مشكل پيش فرض در ذهن خود ثبت كرده ام تا در شركتهاي مختلف دچار مشكل نشوم و به اصطلاح قِلِق سيستم را ياد گرفته ام .
ارادت

سلام

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

درباره مورد دوم تمام فرمايشات جناب مؤمني صحيح است ، اما سوال بنده اين بود كه آيا ميتوانيم خواهش كنيم كه دقيقاً مانند ارتباط حساب با تفصيلي ، در صورتي كه ارتباط از سمت چپ به إرث برسد ، باز هم در سمت راست در كالاي زيرگروه نيز اين ارتباط در فهرست انبارها رويت شود ؟ كه از سردرگمي كاربر جلوگيري نموده و كاربر بتواند راجع به يك كالاي خاص براي ارتباطهاي بعدي بهتر تصميم گيري نمايد ؟
خيلي ممنون ميشم اگر اين امكان افزوده شود .

با سلام و احترام


با سپاس