Go to previous topic
Go to next topic
آخرين ارسال 09 مرداد 1397 11:24 ق.ظ توسط momeni
ثبت رخداد تکراری کسور و اضافات فروش
�10 پاسخ
مرتب:
مولف پيغام ها
debrahimi
کاربر
کاربر

--
30 تیر 1397 01:11 ب.ظ

    با عرض سلام و احترام خدمت جناب آقای مهندس مؤمنی

     

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

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

    ما برای کشف برگه ها و قوانین مشکل دار،  یک کوئری به شکل زیر در دیتابیس اجرا کردیم:

     SELECT count ([sadtr_Key])
          ,[sadtr_ArtKey]
          ,[sadtr_RuleKey]
    FROM [_AccXP_parham].[dbo].[_SalesADTranses]
    group by      [sadtr_ArtKey],[sadtr_RuleKey]
    having count ([sadtr_Key])>1

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

    تصویر نمونه این چنین فاکتوری به صورت زیر است، که تأیید هم شده است:

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

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

     

    ما هر چه کردیم نتوانستیم مشکل را شبیه سازی کنیم. فروشنده ها هم کمکی نتوانستند بکنند. فقط ناگهان یک فاکتور به این شکل در حسابداری ظاهر می شود.

    اگر به تحلیل موضوع کمک میکند:

    • مشتری از نسخه 502 استفاده میکند و نرم افزارهای موجود حسابداری، انبار، فروش و دریافت و پرداخت هستند. البته نرم افزار گزارش ساز هم در خرداد ماه خریداری شده است (بعد از شروع این مشکلات)
    • سیستم فروش بسیار سنگین است و در کمی بیش از 6 ماه نزدیک به 30 هزار سند فروش و برگشت از فروش صادر شده که تقریبا در همه آنها از نوعی قوانین کسور و اضافات استفاده شده است. در زمان شروع این مشکل (اواخر اردیبهشت) هم حدود 20 هزار فاکتور بدون مشکل صادر شده بوده.
    • نسخه بکاپ پایگاه هم اکنون در تهران در اختیار بنده هست و می توانم برای همکاران پشتیبانی تهران ارسال کنم.

     

    با تشکر از پشتیبانی دائمی جنابعالی

    داود ابراهیمی

    مدیریت پایدار

    momeni
    کاربر ارشد
    کاربر ارشد

    --
    30 تیر 1397 03:06 ب.ظ
    سلام

    از توضیحات کامل و دقیق شما بسیار ممنونم

    متاسفانه هیچ رویه‌ای که ممکن باشد چنین وضعیتی را در سیستم بوجود آورد به ذهن من نمی‌رسد. داستان چنین است:

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

    به این ترتیب مسیر بررسی را به این سمت هدایت می‌کنیم: چه سناریوهایی برای افزودن سطرهای کسور و اضافات به یک برگه فروش وجود دارد؟ فقط 4 مسیر داریم: اجرای صریح "محاسبه کسور و اضافات (Shift+F9)" در برگه فروش / افزودن صریح (و دستی) یک قانون به سطرها (با کلید افزودن یا "+") / فراخوانی یک فایل EAR / فراخوانی فایل صادره XML از تعدادی برگه یا سند فروش. حالت آخر از همه غیرقابل تصورتر است و بسیار بعید است که در فرآیندهای شرکت مورد اشاره بکار رفته باشد (مثلا اگر دو پایگاه داشته باشند و از یک پایگاه فایل صادره بگیرند و در دیگری فراخوانی نمایند این وضعیت را می‌داشتیم). ضمن اینکه اگر این مشکل مربوط به فایل صادره XML باشد، به این معنی نیز خواهد بود که در پایگاه مبداء نیز همین مشکل وجود داشته است.

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

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

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

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

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

    ممنون و ارادت
    debrahimi
    کاربر
    کاربر

    --
    30 تیر 1397 04:13 ب.ظ

    سلام

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

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

    پس بنده فایل پشتیبان را تحویل دفتر تهران میدهم که ان‌شاءالله به دست شما برسد.

     

    باز هم ممنونم

    momeni
    کاربر ارشد
    کاربر ارشد

    --
    30 تیر 1397 04:21 ب.ظ
    سلام

    ممنونم
    sajjadi
    کاربر با تجربه
    کاربر با تجربه

    --
    31 تیر 1397 09:06 ق.ظ

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

    جناب آقای مومنی، Backup دریافتی از آقای ابراهیمی در nas شما قرار داده شد.

    نسخه نرم افزار 502 و SQL2016 است

     

    با سپاس

    momeni
    کاربر ارشد
    کاربر ارشد

    --
    31 تیر 1397 09:14 ق.ظ
    سلام

    خیلی ممنونم
    momeni
    کاربر ارشد
    کاربر ارشد

    --
    31 تیر 1397 10:16 ب.ظ
    سلام

    مدت‌ها بود با سناریویی تا این حد چالش‌برانگیز و دشوار مواجه نشده بودم. تمرینِ ذهنِ خوبی بود.

    انجام مراحل زیر وضعیت مشابهی را پدید می‌آورد:

    1) یک فاکتور فروش جدید با مثلا یک سطر اصلی تنظیم کنید. کسور و اضافات را با Shift+F9 محاسبه نمایید. برای سادگی فقط قانون روند (اجباری) را انتخاب نمایید. قوانین طرف حساب فاکتور را نیز تنظیم کنید. فاکتور را ذخیره کنید.
    2) مجددا همان فاکتور را برای اصلاح احضار کنید (تکمه قلم برای صدور فرمان آغاز اصلاح را نیز فشار دهید و پیام محدودیت اصلاح ناشی از محاسبه‌ی کسور و اضافات را نیز تایید فرمایید).
    3) در همان فاکتور فرمان برگشت از محاسبه‌ی کسور و اضافات را صادر کنید. سپس دوباره با Shift+F9 کسور و اضافات را احضار کنید و همان قانون قبلی را دوباره انتخاب کنید. در اینجا ممکن است قانون دیگری را نیز به همراه قانون قبلی انتخاب نمایید ولی تاثیری در نتیجه نخواهد داشت. فاکتور را ذخیره نکنید و به حال خود رها کنید.
    4) فهرست برگه‌های فروش را احضار کنید و همان فاکتوری که مشغول اصلاح آن بوده‌اید را عملیاتی نمایید. فهرست برگه‌ها را به همان صورت باقی بگذارید.
    5) حال به همان فاکتوری که مشغول اصلاح آن بودید بازگردید و فاکتور را ذخیره کنید.
    6) پیغام خطا خواهید گرفت: حذف سطر کسور و اضافات از برگه عملیاتی میسر نیست. خطا را تایید کنید ولی فاکتور را نبندید و به همان صورت باقی گذارید. اگر توجه کنید سطری که حذف آن منجر به خطا شده است (نسخه‌ی قبلی از همان قانونِ مثلا روند) برای بازنمایی وضعیتی که منجر به خطا شده است دوباره در فاکتور ظاهر خواهد شد.
    7) در فهرست برگه‌های فروش (مثلا برای رفع خطایی که در ذخیره‌ی برگه با آن مواجه شده بودید) همان برگه را دوباره پیش‌نویس نمایید. البته این سناریو احتمالا از دو ایستگاه کاری مختلف اتفاق می‌افتد ولی در اینجا برای سادگی از دو پنجره در یک ایستگاه استفاده کرده‌ایم.
    8) دوباره به فاکتور در دست اصلاح بازگردید. حال دیگر فاکتور پیش‌نویس است و ذخیره‌سازی آن میسر است - غافل از اینکه سطری که قبلا حذف شده بود (نسخه‌ی قبلی قانونِ روند) و در اثر خطا دوباره بازنمایی شده است عملا به فاکتور بازگردانده شده است و مکان‌نما هم برروی آن قرار دارد. اما بدیهی است که کاربر لزوما به وجود آن توجهی نمی‌کند.

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

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

    نکات اصلی: 1) اگر در حین حذف سطری از برگه با خطا مواجه شویم، سیستم سطری که منجر به خطا شده است را به برگه بازمی‌گرداند. 2) محاسبه‌ی کسور و اضافات با حذف سطرهای قبلی و اضافه کردن سطرهای جدید انجام می‌شود و به این ترتیب "حذف سطر" در برگه اتفاق می‌افتد.

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

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

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

    از همکاری شما سپاسگزارم
    ارادت
    debrahimi
    کاربر
    کاربر

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

    --
    01 مرداد 1397 10:41 ق.ظ
    سلام
    ارادتمندم
    کار ما تا پاسی از شب به طول کشید اما شما هم تا نزدیک نیمه‌شب فعال هستید و پیگیر - خسته نباشید
    از لطف شما بسیار ممنونم
    debrahimi
    کاربر
    کاربر

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

    با تشکر
    momeni
    کاربر ارشد
    کاربر ارشد

    --
    09 مرداد 1397 11:24 ق.ظ
    سلام

    ممنون از اطلاع رسانی

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


    ---