انجمن‌ها

سلام

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

سلام

ممنون از توضیح تکمیلی شما

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

با سلام

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

سلام

ممنون از توضیح تکمیلی شما

آیا از اصلاح تاریخ اسنادی که به این شیوه تنظیم شده‌اند نیز باید جلوگیری شود؟

با سلام

ببخشی منظورتان را متوجه نشدم

سلام

برای توضیح بیشتر در خدمتم

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

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

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

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

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

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

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

امیدوارم توضیحات فوق کافی بوده باشند.
ارادت

با سلام مجدد

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

سلام

به هر حال من در حد توانم سعی کردم وضعیت را توضیح دهم.

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

ارادت

اینو میذاریم تو بدهکاری نوسا

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

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

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

با سلام

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

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

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

با سلام خدمت اساتید گرامی

علت اینکه سیستم بانک اجازه وصول دوبار یک چک را میدهد و ثبت هم میکند و در گزارش اسناد چک در وضعیت موجود نمایش داده میشود چیست ؟

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

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

با سلام خدمت اساتید گرامی

علت اینکه سیستم بانک اجازه وصول دوبار یک چک را میدهد و ثبت هم میکند و در گزارش اسناد چک در وضعیت موجود نمایش داده میشود چیست ؟ مجددا

سلام

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

با سلام خدمت اساتید گرامی

چکی در تاریخ 10/28 به سر رسید 11/28 صادر گردیده و در تاریخ 11/25 چک ابطال شده است و معامله فسخ گردیده لطفا راهنمایی فرمایید نحوه ابطال چک به چه صورت میباشد با تشکر

سلام



به شرط آنکه مدرک در وضعیت جدید باشد کافی است پنجره ی تدوین مدرک دریافت پرداخت مورد نظر را باز کنید و در tab اطلاعات اصلی تیک "باطل شده" را فعال کنید