انجمن‌ها

سلام

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

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

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

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

ارادتمند

ارسال توسط momeni روشن 30 بهمن 1389 12:10 ب.ظ
سلام


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

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

سلام

کاملا درست فرمودید - شماره فنی روشی برای انتخاب کالا است. تبعاتی هم ندارد.

ممنون

سلام
آقای مومنی از حسن توجه شما خیلی ممنون . فقط دو مورد برای من حل نشد :
اول اینکه اگر درست متوجه شده باشم در مورد درج تفضیلی انجام دهنده خدمات بطور خودکار باید از قسمت مکمل بها استفاده کنیم ، در این قسمت هم جائی وجود ندارد که بتوان گفت تفضیلی انجام دهنده خدمات را بطور خودکار بیاورد ؟!! در ضمن با وجود 5 تفضیلی اکثر مشتریان از تفضیلی 2 به بعد بعنوان Tag استفاده می کنند . ولی با فرمایش شما در مورد نادرستی این موضوع کاملا موافقم .
و دوم اینکه منظورم از اضافه کردن شماره فنی دقیقا برای انتخاب کالا است اما در فرم نمایشی تعرفه نمی توان ستون شماره فنی را بعنوان مشخصات کالای انتخاب شده اضافه نمود و همین طور هنگامی که Ctrl+F گرفته می شود ، نمی توان براساس شماره فنی جستجو انجام داد .
باتشکر

سلام

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

در قوانین مکمل بها، از نوع پورسانت انجام دهنده خدمات، تفصیلی پرداختنی پورسانت همان تفصیلی انجام دهنده خدمت خواهد یود.

در مورد عدم وجود فیلد شماره فنی در فرم تعرفه، اگر جا افتاده باشد قصور ما است. حتما بررسی می‌کنم و در نسخه بعد به تعرفه اضافه خواهد شد. البته اصولا در Ctrl+F فقط فیلدهایی که در فرم استفاده شده باشند قابل جستجو هستند. به هر حال این مورد را بررسی خواهم کرد و حتما اگر کسری وجود داشته باشد در نسخه بعدی اضافه خواهد شد.

ممنون

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

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

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

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

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

خانم هاشمیه
1- این که مورد بحث یک شخص است یا خیر ، اهمیت موضوع را در حسابداری بالا نمی برد .
2- می گوییم این کار صحیح نیست ، شما می گویید اگر یک امکان اضافه شود ، این کار غیر صحیح هم عملی می شود ؟!!

آقای دادرس
1- با توجه به فرمایش آقای مومنی انجام دهنده خدمات نباید بستانکار شود به همین دلیل در الگوی عملیاتی فروش گنجانده نشده است . خب این قبول . اما مشتری و نماینده و ... هم نباید بستانکار شوند . پس آنها هم نباید گنجانده شوند . می دانم ثبت مشتری و انجام دهنده با هم متفاوت است اما در مورد نماینده شبیه به انجام دهنده خدمات است . پس از تفضیلی انجام دهنده به عنوان تگ چیزی نیست که به اعتبار سیستم لطمه بزند بلکه می تواند جهت گزارشگیری بسیار مفید باشد .
باتشکر

سلام

سرکار خانم هاشمیه، کاملا درست می‌فرمایید. نماینده فروش و بازاریاب و مشتری و طرف بدهکار در الگوی عملیات مالی فروش کالاها و خدمات کاملا زائد هستند. آنها به اشتباه (به همراه طرف بدهکار و به صورت یک Package) آمده‌اند. اصلا یادم نیست که به چه دلیل آنها را در این الگو قرار داده‌ایم. انشاءلله در نسخه 303 آنها را حذف می‌کنیم. شرمنده

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

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

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

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

ارادت

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

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

با تشکر و عرض خسته نباشید

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

سلام

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

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

نسخه 303 هم درست در همان زمانی که نسخه‌های قبلی تکمیل شدند ارائه خواهد شد: هر زمان که کارهایش تمام شود

زنده باشید

با عرض سلام

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

    با تشکر

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

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