انجمن‌ها

سلام

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

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

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

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

ارادت

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

سلام

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

در مورد کنترل بدهی، این عمل در سیستم فروش و بدون نیاز به مراجعه به گزارش‌های مالی صرفا با کنترل اعتبار مشتری انجام می‌شود.

ارادت

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

سلام

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

ارادت

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