انجمن‌ها

سلام

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

ارادت

سلام

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

با تشکر
داود ابراهیمی
مدیریت پایدار

سلام

اطاعت - بیشتر بررسی می‌کنم

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

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

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

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

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

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

"به رؤیت رساندن نمونه عملی سناریوی فوق در دفتر نوسا به آقای روزبه محمد زاده و توضیح حجم مشکل کاربران" تغییری در وضعیت نمی‌دهد. مثل این است که دشواری تنظیم یک سند مثلا با 10000 سطر را بخواهیم بازنمایی کنیم یا توضیح دهیم.

امیدوارم انتهایی برای این مسائلی که به بیان خودتان کوچک هستند وجود داشته باشد (ما 30 سال است در این مسیر حرکت می‌کنیم و هنوز این انتها به رؤیت ما نرسیده است) اما امان از احتمال خطای کاربر که به نظر می‌رسد مسئولیت آن نیز با ما است.

ارادت

خیلی ممنون از توضیحات کامل جنابعالی در تاریخچه دردناک زندگی این ابزار!

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

با تشکر مداوم!
داود ابراهیمی
مدیریت پایدار