Go to previous topic
Go to next topic
آخرين ارسال 13 تیر 1400 01:16 ب.ظ توسط روزبه
نسخه 10.02 (1002)
�8 پاسخ
مرتب:
مولف پيغام ها
روزبه
کاربر با تجربه
کاربر با تجربه

--
13 تیر 1400 11:24 ق.ظ

    امکانات جدید در نسخه 10.02 نرم‌افزار مالی یکپارچه نوسا

     

    ویرایش 10.02 نرم‌افزار مالی یکپارچه نوسا در اردیبهشت ماه سال 1400 بصورت محدود ارائه گردید و از تیر ماه سال 1400 برای عموم مشتریان در دسترس قرار گرفت، فایل اجرایی سرور و کلاینت‌های این نسخه در بخش فایل و مستندات قابل دریافت می‌باشد. پیرو ویرایش اساسی نسخه 9.02 در سال 1399 و قابلیت‌های نسل جدید نرم‌افزار، بزرگ ترین تغییر در این ویراش در بعد جدیدی از گزارش‌های محوری (Pivot Tables)، نموداری (Pivot Diagrams)، و مؤلفه‌های شاخص‌های عملکرد (KPIs) نقش ایفا می‌کنند. به کمک این ابزارها، قادر خواهیم بود حجم زیادی از داده‌ها شامل مقادیر، مبالغ و سایر پارامترهای مربوط را دریافت کرده و از ترکیب آن‌ها اطلاعاتی معنا دار را به انواع حالت‌های مختلف از جمله جدول ماتریسی یا بصورت گرافیکی استخراج نماییم. در این گزارش‌ها که خود به تنهایی حجم عظیمی از قابلیت‌های جدید را به هسته مرکزی و ماژول‌های گوناگون نرم‌افزار اضافه می‌کنند، بسیاری امکانات نهفته است که بخشی از آن در ادامه این پست همراه با ویدیوهای آموزشی پیوست در دسترس می‌باشند. 

     

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

     

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

     

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

     

    شایان ذکر است که در هر نسخه از نر‌م‌افزار علاوه بر ارائه امکانات نوین و سازگاری با تغییرات در قوانین و نیاز‌های کلی مشتریان، بخش عمده‌ای از زمان صرف همسویی با آخرین بستر‌های نرم‌افزاری و ساختاری می‌گردد تا نرم‌افزار همچنان بروز با آخرین تکنولوژی در دسترس بوده و کاربرد آن همواره قابل اطمینان باشد، افتخار می‌کنیم که در نسخه 10.02 از آخرین بروز‌رسانی‌های ویندوز سرور 2019، ویندوز 10، اکسل 2019 و SQL 2019 ارائه شده تا اسفند 1399 پشتیبانی می‌کنیم. شایان ذکر است بنا به عدم پشتیبانی شرکت مایکروسافت از نسخه‌های قدیمی نرم‌افزارهای خود، مشکلات امنیتی این نرم‌افزارهای قدیمی و نیاز به استفاده از برخی امکانات جدید ویندوز و SQL جهت ارائه ابزار نوین در این نسخه، همانطور که در نسخه 9.02 اعلام گردید، از این نسخه تنها SQL 2016 و ویندوز 8.1 یا سرور 2016 به بالا جهت استفاده از نرم‌‍‌‌افزارهای مالی نوسا پیشنهاد و پشتیبانی می‌گردند.

     

    در صورتی که سرور و و یا کلاینت‌های شما حداقل از ویندوز 8.1 و یا سرور 2016 استفاده نکرده و یا SQL سرور شما از 2016 قدیمی‌تر است، لطفا قبل از بروز‌رسانی نسخه، با توجه به آخرین نیازمند‌ی‌های سخت‌افزاری موجود در بخش فایل و مستندات، از بروز‌رسانی ساختار‌های مورد نیاز اطمینان حاصل فرمایید. این نسخه قابلیت کارکرد صحیح در نسخ قدیمی نرم‌افزارهای زیرساخت را نخواهد داشت.  

     

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

     

    هیچ یک از مولفه‌های جدول، نمودار و شاخص‌های عملکرد در مدل S نرم‌افزارها موجود نمی‌باشد، همچنین شاخص‌های عملکرد در مدل M نرم‌افزارها نیز در دسترس نخواهند بود. تمامی امکانات جدید در مدل‌های L و T نرم‌افزار در دسترس می‌باشد.

     

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

     

     

    لیست کامل‌تر برخی از امکانات و تغییرات و نحوه استفاده از آن در ادامه این متن همراه با 28 ویدیوی آموزشی در دسترس می‌باشد:

    روزبه
    کاربر با تجربه
    کاربر با تجربه

    --
    13 تیر 1400 12:12 ب.ظ

    ابزار جدید ارائه شده در هسته مرکزی نسخه 10.02: مکانیزم‌های پیش‌تنظیم گزارش‌ها و تکمه‌های میان‌بر به تفکیک کاربران

     

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


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

     

     

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

     

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

     

     

    فهرست پیش‌تنظیم‌ها

     

    فهرست پیش‌تنظیم‌های ذخیره‌شده‌ در فرمی به صورت زیر بازنمایی می‌شود:

     

     

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

     

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

     

     

    تاثیر در تکمه‌های میان‌بر و ویرایش آنها

     

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

     

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

     

     

    ویرایش یکی از تکمه‌های میان‌بر (Shift+Enter یا قلم) در حال حاضر در محاوره‌ای به شکل زیر انجام می‌شود:

     

     

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

     

     

     

    نکات مهم در رابطه با این مکانیزم‌ها:

     

    پیش تنظیم ناقص گزارش‌ها و رفتار تکمه‌ میان‌بر

     

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

     

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

     

     

    خطا در پیش تنظیم خارج از دسترس و رفتار تکمه‌ میان‌بر بدون محاوره ابتدایی

     

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

     

     

    گزارش‌هایی که مبتنی بر یک سوژه هستند

     

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

     

     

    برخی از حالت‌های گزارش‌ها فاقد پیش‌تنظیم هستند

     

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

     

     

    استفاده از پیش‌تنظیم در حین تغییر پارامترهای گزارش (Ctrl+F3) میسر نیست

     

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

     

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

     

     

    گزارش‌های پیگیری مدارک دریافت و پرداخت

     

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

     

     

    پارامترهایی که در پیش‌تنظیم لحاظ نمی‌شوند

     

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

     

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

    روزبه
    کاربر با تجربه
    کاربر با تجربه

    --
    13 تیر 1400 01:08 ب.ظ

    ابزار جدید ارائه شده در زیرساخت و ماژول‌های نسخه 10.02: گزارش‌های عادی مجهز به جداول محوری و گزارش‌های اختصاصی محوری پیشرفته

     

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

     

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

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

     

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

     

     

     

    تفاوت گزارش‌های عادی مجهز به جدول محوری و گزارش‌های اختصاصی محوری

     

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

     

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

     

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

     

     

    نواحی تشکیل‌دهنده‌ی جداول محوری

     

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

     

     

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

     

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

     

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

     

     

     

    انواع فیلد‌ها در گزارش‌های محوری

     

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

     

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

     

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

     

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

     

    حرکت دادن فیلدها در بین نواحی جداول محوری

     

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

     

     

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

     

     

    فیلدواره‌ی سرجمع داده‌ها در جداول محوری

     

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

     

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

     

    به عنوان نمونه به گزارش ساده‌ی زیر توجه کنید:

     

     

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

     

     

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

     

    روزبه
    کاربر با تجربه
    کاربر با تجربه

    --
    13 تیر 1400 01:09 ب.ظ

    برخی امکانات خاص گزارش‌های محوری

     

    پردازش اختصاصی فیلدهای تاریخ

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

     

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

     

     

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

     

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

     

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

     

     

     

    فیلتر کردن از روی محتویات فیلدها

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

     

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

     

     

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

     

     

     

    مرتب‌سازی داده‌ها در جداول محوری

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

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

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