انجمن‌ها

ابزار جدید قابل خرید در نسخه 11.02: وب سرویس ورود و دریافت اطلاعات محدود انبار و فروش از خارج از محیط نرم‌افزار یکپارچه مالی نوسا ( INV & Sales API Server)

 

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

 

• هزینه تولید چنین محصولی، بسیار زیاد و مدت زمان مورد نیاز جهت طراحی، اجرا و استقرار آن قابل توجه خواهد بود.

• تولید چنین نرم افزارهایی معمولا به صورت غیر منعطف و به صرفه خواهد بود ولیکن تیم‌های تولید از تمامی نیاز‌های روز سازمان آگاه نمی‌باشند.

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

• پیاده سازی نرم افزار بر اساس نیاز‌های روز انجام می‌گردد، در طول زمان و با تغییر در ساختار و یا قوانین، محصول کارایی خود را از دست خواهد داد.

 

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

شرکت نوسا به عنوان شرکتی پیشرو در حوزه تولید نرم افزار، به منظور پوشش عملیات شرکت هایی که بخشی از رویدادهای عملیاتی خاص آن‌ها در فضایی خارج از نرم‌افزارهای مالی نوسا بوده و نیاز به ثبت داده مالی خارج از این محیط را خواهند داشت، اقدام به تولید راه حل API از خارج از محیط نرم‌افزار مالی خود کرده و ورود داده توسط وب سرویس کنترل شده نوسا را برای مشتریان بوجود آورده است. این ابزار در نسخه 9.02 در سال 1399 قابلیت ورود اسناد حسابداری، تفصیلی، مرکز و دفتر تلفن را به مشتریان ارائه داد، و در ادامه روند تکمیل خود، در سال 1401 قابلیت ارسال و دریافت اطلاعات از نرم‌افزارهای انبار و فروش نوسا را فراهم آورده است. بخشی از اطلاعات مرتبط با قابلیت های INV & Sales API Server نوسا به این ابزار به شرح زیر می‌باشد:

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

• قابلیت دریافت بخشی از اطلاعات موجود در نرم افزارهای انبار و فروش از خارج از محیط نرم‌افزارها شامل:
  • اخذ مشخصات کالاهای تعریف شده در نرم افزار
  • اخذ مشخصات خدمات تعریف شده در نرم افزار
  • اخذ مشخصات تعرفه‌های موجود در نرم افزار
  • اخذ موجودی کالا ها بر اساس
    • انبارها
    • بچ ها
    • رخدادهای مرجع شناسایی ویژه
    • وضعیت درخواست های کالاها
    • مقادیر رزرو شده

• پشتیبانی از ساختار استاندارد SOAP و ساختار تحت وب http و https در زمان دریافت اطلاعات از خارج از نرم‌افزار مالی نوسا

• احراز هویت کاربر خارجی (آنلاین) ورود داده و کنترل اختیارات وی، شامل تمامی کنترل‌های موجود کاربران و برخی امکانات خاص جدید

• کدهای نمونه و کلاینت تست و آشنایی با ساختار ابزار و روش ارسال اطلاعات در پنج زبان C# , Delphi, Python, PHP, HTML/Javascript

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

• قابلیت پشتیبانی ارسال تاریخ فارسی و یا میلادی از نرم‌افزار خارجی

• قابلیت تعریف الگوی تعیین خودکار داده‌های ورودی انبار و فروش

• ...

 

 

 

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

ابزار جدید ارائه شده در هسته مرکزی نسخه 11.02: استفاده از هوش مصنوعی و یادگیری ماشینی جهت کنترل صحت انواع داده موجود

 

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

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

 

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

 

یادگیری ماشینی و علوم داده

 

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

از طرف دیگر سیستم‌های یادگیری ماشینی بسته به اینکه محدوده‌ی نتایج آنها از قبل مشخص باشد یا خیر نیز به دو گروه تقسیم می‌شوند؛ نظارت شده (Supervised) یا بدون نظارت (Unsupervised). مثلا یک سیستم تشخیص چهره باید ابتدا با تعدادی تصویر از اشخاص از پیش معلوم آموزش داده شود (درست این است که بگوییم مدلی داریم که باید با داده‌های برچسب‌داری fit شود). بعد می‌توان از آن انتظار داشت که با دریافت یک تصویر از بین اشخاصی که قبلا تصویر آنها را دیده است، شخص یا اشخاصی که در تصویر هستند را شناسایی نماید. این یک سیستم نظارت شده یا Supervised است. در مقابل اگر سیستمی داشته باشیم که قرار باشد با بررسی تصویر تعدادی از اشخاص، بدون اینکه از قبل با آنها fit شده باشد اشخاص مختلف را از هم تمیز دهد و مثلا تکرار یا تعداد اشخاص را تعیین کند، آن سیستم، بدون نظارت یا Unsupervised است. راه‌حل‌های Supervised با نتیجه‌ی منفصل یا گسسته را Classification و با نتیجه‌ی پیوسته را Regression می‌گویند. موارد Unsupervised با نتیجه‌ی گسسته را Clustering و با نتیجه‌ی پیوسته را Dimension Reduction می‌گویند.

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

 

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

 

 

تشخیص ناهنجاری در داده‌ها با کمک یادگیری ماشینی

 

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

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

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

در 20 سال اخیر مدل‌های ریاضی بسیار جالبی به صورت بدون نظارت (Unsupervised) توسعه داده شده‌اند که برای تشخیص ناهنجاری قابل استفاده هستند. یکی از این روش‌ها مدلی است که برای محاسبه‌ی Local Outlier Factor توسعه داده شده است. این مدل مبتنی بر یک روش (پارامتریک) برای تشخیص فاصله بین داده‌ها است. در این روش داده‌ها به صورت n عدد اعشاری به عنوان مختصات در یک فضای n بعدی دریافت می‌شوند. این مدل، مبتنی بر فاصله‌ی تشخیص داده شده در بین داده‌ها و یک الگوریتم مثل kdtree یا brute یا مانند آنها (پارامتریک) و دریافت تعدادی پارامتر اضافی، داده‌ها را در چند همسایگی قرار می‌دهد – یعنی مدل از انواع Clustering است. برای هر داده برحسب اینکه در همسایگی آن (آنچه تشخیص داده شده است) چه تعداد داده‌ی دیگر قرار دارند (پارامتریک) و نیز اینکه از مرکز همسایگی چه میزان فاصله دارد و بسته به اینکه همسایگی مربوط چقدر «چگال» باشد یک فاکتور (امتیاز – میزان) محاسبه می‌شود. از روی این فاکتور موارد ناهنجاری (Outlierها) تشخیص داده می‌شوند. این یک عدد بزرگتر از 1 است که 1 به معنی اطمینان از عادی بودن داده (ناهنجار نبودن) آن است و تا دو میلیارد (یا بیشتر) هم می‌رود که به معنی اطمینان مطلق از ناهنجار بودن داده است.
روشی که ما در استفاده از این مدل بکار می‌بریم مبتنی است بر محاسبه و بازنمایی همان عدد در یک فیلد از گزارش، به نام "میزان ناهنجاری" و تشخیص را به عهده‌ی کاربر قرار می‌دهیم. گزارش را بر حسب میزان ناهنجاری به ترتیب نزولی بازنمایی خواهیم کرد. این محاسبات را برای برخی از گزارش‌های سیستم پیاده کرده‌ایم. در این گزارش‌ها میزان ناهنجاری به صورت یک فیلد در گزارش تعبیه شده و در فرم‌های گزارش قابل بازنمایی است. 

 

 

 

استفاده از زبان برنامه‌سازی پایتون جهت پیاده سازی هوش مصنوعی در نرم‌افزارهای نوسا

 

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

 

زبان پایتون تا 10 سال پیش به عنوان یک پدیده و اتفاق مهم در مهندسی نرم‌افزار شناخته می‌شد – با ترکیبی از ویژگی‌ها که باعث شده بود ناظران رابطه‌ی برنامه‌نویسان و این زبان را به "عشق" تعبیر کنند (یعنی تلاشی برای توضیح و دفاع از این رابطه انجام ندهند). زبان پایتون، با اینکه Script است اما کاملا شیءگرا (Object Oriented) است و این ویژگی در ذات زبان قرار دارد. نصب و آماده‌سازی محیطی که برای اجرای آن مورد نیاز است بسیار ساده و بی‌دردسر انجام می‌شود. شاید به جرأت بتوان گفت که بخش مهمی از گفتمان‌های مطرح در مهندسی نرم‌افزار در سال‌های اخیر همگی ابتدا در پایتون بروز و ظهور کرده‌اند. با اطمینان بسیار می‌توان گفت برنامه‌نویسانی که بیش از 10 سال سابقه کار دارند، اگر اشتیاق یا علاقه یا عشق نسبت به این زبان نداشته باشند، حداقل برای آن احترام ویژه‌ای قائل هستند.

در 10 سال گذشته، البته، بسیاری از ویژگی‌ها و امکانات اختصاصی پایتون توسط توسعه‌دهندگان سایر زبان‌ها (Java، Javascript، C#، C++، Delphi...) مورد توجه قرار گرفته و عمده‌ی آنها به سایر زبان‌ها نیز اضافه شده‌اند و به همین دلیل برای برنامه‌نویسان جوان، در غیاب دید تاریخی نسبت به زبان‌های مختلف، اینکه پایتون یک اتفاق مهم در مهندسی نرم‌افزار بوده است شاید دیگر خیلی واضح نباشد. نرم‌افزارهای تولید شده با زبان پایتون در مقایسه با سایر زبان‌ها بسیار کندتر هستند – سرعت آنها تقریبا نصف java script، بیش از 10 برابر کندتر از java یا C#، بیش از 20 برابر کندتر از C++ یا Delphi است. اما در نگارش ابزارها و کتابخانه‌های مورد استفاده در برنامه‌سازی پایتون می‌توان از کدهای نوشته شده در C++ یا Delphi (یا حتی فرترن)  استفاده نمود. این باعث شده که ابزارهایی مثل مکانیزم حل دستگاه معادلات را بتوان در یک بسته پایتون در اختیار داشت که به سهولت قابل استفاده باشد و در عین حال کدی که معادلات را حل می‌کند و نیاز به سرعت اجرای بالا دارد در آن با C++ و فرترن نوشته شده و سرعت معقولی داشته باشد.
اما مهم‌ترین مشخصه‌ی زبان پایتون چندان به ماهیت و مشخصات زبان بستگی ندارد، بلکه به مجموعه‌ی اشخاصی که با این زبان کار می‌کنند و اکوسیستمی (زیست‌بوم) که مبتنی بر این زبان ایجاد شده است برمی‌گردد. دیگر اینکه، پایتون و تمام امکاناتی که مبتنی بر آن نوشته شده است حالت متن باز دارند و دانش مورد استفاده در پیاده‌سازی آنها در اختیار همگان قرار دارد.

امکانات مختلف پایتون در موجوداتی به نام "بسته – Package" توسط توسعه‌دهندگان "بسیار" متعدد و متنوعی در طی سالیان اخیر ایجاد شده و در اختیار همگان قرار گرفته‌اند. ترکیب این امکانات، به همراه مستندات بسیار مفصلی که توسط توسعه‌دهندگان یا کاربران آماده شده‌اند بخش مهمی از آنچه ما اکوسیستم پایتون نامیدیم را تشکیل می‌دهند. متن باز بودن این امکانات همچنین باعث شده که این بسته‌ها مبتنی بر یکدیگر توسعه داده شوند – مثلا Numpy مهم‌ترین بسته برای جبرخطی و امکانات بسیار متنوع مربوط به این مفهوم است. Scipy مبتنی بر Numpy پیاده‌سازی شده و مجموعه‌ی بسیار متنوعی از امکانات موردنیاز برای محاسبات ریاضی (با کاربردهای علمی) را مهیا کرده است. این بسته برای در اختیار داشتن امکاناتی شبیه Matlab در زبان پایتون نوشته شده است. Scikit-learn مبتنی بر Numpy و Scipy نوشته شده است و به یادگیری ماشینی و هوش مصنوعی می‌پردازد. امکانات یادگیری عمیق (Deep Learning) و یادگیری کم‌عمق (Shallow Learning) در آن وجود دارد – اما به خاطر امکانات کم‌عمق خود شهرت دارد. مجموعه‌ی بسیار کامل، جامع و کارآمدی از انواع مدل‌ها و الگوریتم‌های مورد استفاده در یادگیری ماشینی در این بسته پیاده‌سازی شده است. اما از آنجا که شرکت گوگل یک بسته‌ی جامع و بسیار مهم در زمینه‌ی یادگیری ماشینی عمیق به نام Tansorflow توسعه داده است، سایر توسعه‌دهندگان دیگر به صورت جدی در این زمینه کار نمی‌کنند و اصولا با وجود Tansorflow (که به صورت متن باز در اختیار قراردارد) ایجاد بسته‌ی مشابه توجیه زیادی هم ندارد.

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

 

 

نحوه محاسبه‌ عوامل ناهنجار (LOF) Local Outlier Factor در نوسا

 

Scikit-learn دارای یک مدل آماده برای محاسبه‌ی LOF است. این مدل (همانند بسیاری از موارد مشابه) یک کلاس پایتون است که با دریافت پارامترها تشکیل می‌شود، با داده‌ها تغدیه می‌شود و حاصل را برای داده‌های جدید پیش‌بینی می‌کند. با توجه به ماهیت مسئله، در اینجا داده‌های موجود و داده‌های جدید یکی هستند به همین دلیل تغذیه و پیش‌بینی همزمان انجام می‌شوند. حاصل LOF به صورت کلاسیک، یک مقدار دوگانه (بله / خیر) برای هر یک از رکوردهای داده است که ناهنجار بودن آن رکورد را مشخص می‌کند. در کاربردهای ما، مثلا در فهرست سطرهای برگه‌های فروش، داده‌های تغذیه شده به مدل، برخی از فیلدهای گزارش هستند. گفتیم که ما به جای تشخیص مستقیم ناهنجاری، میزان ناهنجاری را در این گزارش‌ها بازنمایی خواهیم کرد.

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

 

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

 

 

 

گزارش‌های سیستم مالی نوسا مبتنی بر هوش مصنوعی و روش استفاده از آن

 

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

• فهرست رخدادهای انبار
• فهرست رخدادهای درخواست‌های کالا
• فهرست رخدادهای انجام خدمات
• فهرست رخدادهای درخواست‌های خدمات
• فهرست سطرهای پیش‌فاکتور و قرارداد
• فهرست سطرهای برگه‌های فروش
• جستجو در شرح اسناد

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

 

 

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

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

فیلدهای مزبور از سطرهای گزارش (رخدادهای فروش) استخراج می‌شوند و به مدل LOF تغذیه می‌شوند. مدل همزمان یاد می‌گیرد (Fit می‌شود) و حاصل مورد نظر را پیش‌بینی (Predict) می‌کند. گفتیم که این حاصل همان «میزان ناهنجاری» است که در هر سطر از گزارش درج و ارائه می‌شود. داستان این است؛ مُدل با استفاده از میزان ناهنجاری به ما می‌گوید که کدام‌یک از داده‌ها باید مورد بازبینی و بررسی مجدد قرار گیرند. اگر میزان ناهنجاری کوچک باشد (حدود 1) یعنی از دید مُدل به احتمال بسیار زیاد، هیچ ناهنجاری وجود ندارد و اگر بزرگ باشد یعنی به احتمال زیاد ناهنجاری وجود دارد. البته توجه کنید که این ناهنجاری در مدل LOF به این معنی است که داده‌ی مزبور در همسایگی معقول با سایر داده‌ها قرار ندارد / یا تعداد داده‌های همسایه اندک است / یا همسایگی «چگال» نیست. این وضعیت ممکن است از دید ما ناهنجاری نباشد – مثلا مربوط به کالایی است که خیلی به ندرت فروخته شده یا یک مرکز فروش که تعداد رخدادهای فروش بسیار اندکی دارد. اما به هر حال سیستم هم نظر قطعی نداده است – صرفا گفته که به نظر من بد نیست که محتویات این رخداد را مرور کنید.

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

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

 

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

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

• بسته به فیلدهایی که به عنوان Feature انتخاب می‌کنید، ممکن است داده‌های سال‌های مالی مختلف با هم هم‌گون و هم‌خانواده نباشند. این وضعیت ممکن است در اثر تورم و افزایش قیمت‌ها یا در اثر تغییر روش‌های ثبت عملیات پیش بیاید. به همین دلیل در بسیاری از کاربردها، شاید لازم باشد که فقط از داده‌های یک سال مالی در گزارش استفاده شود.

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

• Featureها حتما باید عدد باشند. این ویژگی برای بسیاری از داده‌ها برقرار است. کدهای داده‌های درختی (حساب، تفصیلی، کالا، مرکز...) واقعا عدد نیستند اما با محاسبات ساده‌ای سعی می‌کنیم آنها را به عدد تبدیل کنیم تا به عنوان Feature قابل استفاده باشند. الگوریتمی که بکار برده‌ایم در شرایطی بهتر کار می‌کند که بخش آخر از کد، با / از بخش‌های قبلی جدا شده باشد. یعنی مثلا در تعریف حساب‌های سرگروهِ حساب‌های عملیاتی (سطح ماقبل آخر) «درج ‘/’ در کد حساب‌های زیرگروه» علامت‌گذاری شده باشد.

• عملیات مربوط به LOF، در سرور و پس از خواندن داده‌های سطرهای گزارش از SQL Server اجرا می‌شوند. خطاهای متعدد و متنوعی ممکن است در این عملیات پیش بیایند – از اشکالات مربوط به پایتون یا Packageها یا پارامترهای LOF و مانند آنها. ترتیبی داده شده که خطاهای این مرحله از ارائه‌ی گزارش حتی‌الامکان تحمل شوند و اشکال جدی برای کاربر ایجاد نکنند. کاربر این خطاها را به صورت زیر مشاهده خواهد کرد و همانطور که در متن خطا مشخص است، در صورت برخورد با این خطاها گزارش به صورت عادی (بدون اجرای LOF) ارائه خواهد شد:

 

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

ابزار جدید ارائه شده در زیرساخت و ماژول‌های نسخه 11.02: زیرساخت گزارش‌های چند بخشی و امکان دریافت گزارش‌های همزمان از فهرستی از بخش‌های مجاز کاربر

 

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

 

 

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

 

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

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

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

 

 

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

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

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

 

 

امکانات جدید بخش‌ها در گزارش‌های انبار، فروش و مدیریت هزینه

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

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

 

 

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

 

گزارش‌ها و امکاناتی از نرم‌افزار انبار که این تغییر در آنها اعمال شده است را در ادامه ذکر می‌کنیم:

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

 

گزارش‌ها و امکاناتی از نرم‌افزار فروش (خدمات) که این تغییر در آنها اعمال شده است:

• چاپ برگه‌های درخواست خدمات
• فهرست برگه‌های درخواست خدمات
• فهرست رخدادهای درخواست خدمات
• ایجاد فایل صارده از برگه‌های درخواست خدمات
• چاپ برگه‌های انجام خدمات
• فهرست برگه‌های انجام خدمات
• فهرست رخدادهای انجام خدمات
• ایجاد فایل صارده از برگه‌های انجام خدمات

 

گزارش‌ها و امکاناتی از نرم‌افزار فروش (پیش‌فاکتورها و قراردادها) که این تغییر در آنها اعمال شده است:

• چاپ پیش‌فاکتورها و قراردادها (فرم نهایی و فرم ویرایش)
• چاپ قراردادهای الحاقی
• فهرست پیش‌فاکتورها و قراردادها
• فهرست سطرهای پیش‌فاکتور و قرارداد
• فهرست قراردادهای الحاقی
• ایجاد فایل صادره از پیش‌فاکتورها و قراردادها
• ایجاد فایل صادره از قراردادهای الحاقی

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

 

سایر گزارش‌ها و امکانات نرم‌افزار فروش که این تغییر در آنها اعمال شده است:

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

 

گزارش‌ها و امکانات سیستم مدیریت هزینه که این تغییر در آنها اعمال شده است:

• چاپ برگه‌های هزینه
• فهرست برگه‌های هزینه
• فهرست رخدادهای هزینه
• فهرست طرف حساب‌های برگه‌های هزینه
• گزارش سرجمع رخدادهای هزینه
• قراردادهای خرید (هزینه)
• ایجاد فایل صادره از برگه‌های هزینه
• ایجاد فایل صادره از قراردادهای خرید (هزینه)

 

 

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

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

 

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

 

 

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

 

در گزارش‌های حسابداری و دریافت و پرداختی که در آنها انتخاب بخش‌های برگزیده با مولفه‌ی فهرست کرکره‌ای قابل علامت‌گذاری میسر شده بود، در فهرست مزبور فشار کلیدهای Ctrl+Del به معنی حذف علامت از همه‌ی گزینه‌ها خواهد بود.

 

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

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

​تغییرات در انتخاب برگه‌ها و اسناد نرم‌افزارها

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

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

 

 

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

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

 

 

تغییرات در تنظیمات سیستم و گزینه‌های موجود در امکانات بخش‌ها

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

 

 

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

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

 

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

 

 

تغییرات در تنظیمات سیستم و گزینه‌های موجود در امکانات بخش‌ها

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

 

 

با این تغییرات گسترده، انتظار می‌رود که پس از این استفاده کاربران از قابلیت‌های بخش در نرم‌افزارهای نوسا بیش از پیش نمایان بوده و بسیاری از نیاز‌های درخواستی طی سال‌ها با این ابزار قابل ارائه شناخته شوند. لازم به ذکر است که قابلیت استفاده از بخش همواره تنها در نسخ U , L و T نرم‌افزارهای یکپارچه نوسا پیاده سازی گردیده و در نسخ M و یا هدیه در دسترس نمی‌باشند. 

 

 

سایر تغییرات به فراخور نیاز تغییرات در بخش‌ها

همزمان با بروزرسانی کاربرد بخش در نرم‌افزارها تغییرات خاص دیگری در زیرساخت نرم‌افزار یکپارچه الزامیست که در این بخش به برخی از این تغییرات می‌پردازیم:

 

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

    وضعيت بخش (شعبه) تعيين شده در محدوده برگه‌ها، با بخش (شعبه) سند حاصله مطابقت ندارد. در اين شرايط اگر يك يا چند حساب (يا تفصيلي) وابسته به بخش (شعبه) ديگري بوده ولي در اين فرآيند داراي مانده باشند، ايجاد سند با خطا مواجه خواهد شد.

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

ابزار جدید ارائه شده در زیرساخت و ماژول‌های نسخه 11.02: قابلیت جستجو بلادرنگ اطلاعات تفصیلی، مرکز تامین و مصرف و دفتر تلفن و نشانی همزمان با تعریف و یا تغییر

 

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

 

 

 

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

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

 

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

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

• ابتدا یافته‌هایی می‌آیند که عین عبارت جستجو در ابتدای آنها بکار رفته باشد
• بعد مواردی که عین عبارت جستجو در آنها بکار رفته باشد (نه لزوما در ابتدا)
• بعد مواردی که کلمات تشکیل دهنده‌ی عبارت جستجو به همان ترتیب در آنها حضور داشته باشند 
• در نهایت سایر یافته‌های می‌آیند (یعنی اقلامی که همه‌ی کلمه‌های عبارت جستجو را دارند ولی با ترتیب متفاوت)

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

گسترش و تغییرات در گزارش‌ها و نمودار‌های محوری از قبل ارائه شده در زیرساخت و ماژول‌های نسخه 11.02

 

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

 

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

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

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

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

در بازنمایی ماه، سه‌ماهه و فصل، m و mm منجر به بازنمایی عددی می‌شوند. سه‌ماهه و فصل با اعداد 1 تا 4 بازنمایی می‌شوند (m و mm برای آنها تفاوتی نخواهد کرد). در مورد ماه، mm باعث می‌شود که همیشه یک عدد دو رقمی 01 تا 12 بازنمایی شود اما اگر m استفاده شود، 9 ماه اول یک رقمی و 3 ماه بعدی دو رقمی خواهند بود. mmm و mmmm منجر به بازنمایی متنی می‌شوند. در صورت استفاده از mmm، در صورت امکان از گونه‌ی خلاصه شده‌ی عبارت‌ها استفاده خواهد شد (که در جدول زیر آمده‌اند):

محدوده	mmm	mmmm
ماه فارسی	فروردین ... اسفند	فروردین ... اسفند
سه‌ماهه فارسی	اول ... چهارم	سه ماهه اول ... سه ماهه چهارم
فصل فارسی	به، تا، پا، زم	بهار ... زمستان
ماه لاتین	Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec	January ... December
سه ماهه لاتین	1st, 2nd, 3rd, 4th	First Quarter ... Fourth Quarter
فصل لاتین	Sp, Su, Au, Wi	Spring ... Winter

خالی گذاشتن فرمت دلخواه به معنی رفتار پیش‌فرض سیستم خواهد بود (yyyy برای سال و mmmm برای سایر اجزاء – ترکیب این دو حسب مورد). فرمتی که در شکل فوق به عنوان نمونه نشان داده شده است منجر به بازنمایی ترکیب سه‌ماهه و سال مالی مثلا به صورت 1-92-91، 2-92-91 و مانند آنها خواهد شد. اگر سال مالی از ابتدای فروردین آغاز شود، 1-91، 2-91 و مانند آنها را خواهیم داشت.

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

 

قابلیت استفاده از فرمت در فیلد‌های مدت در زمان ارسال اطلاعات به اکسل

در رابطه با صدور سرجمع‌های فیلدهای «مدت» از انواع جداول محوری به Excel، در نسخه 10.02 بدلیل محدودیت‌های Excel این اطلاعات بصورت فیلد‌های عددی ارائه می‌گردید و لازم بود تا فرمت آنها بعدا در Excel مرتب شود. دو دلیل برای این کار داشتیم؛ یکی اینکه فرمت‌های Excel در بازنمایی مدت مختصرتر از فرمت‌های ما هستند و لزوما نمی‌توانستیم همان فرمت تعیین شده در تعریف فرم را در Excel لحاظ کنیم و دوم اینکه Excel توانایی کار با مدت‌های منفی را ندارد. در این نسخه یک تلاش دیگر برای بهبود این مورد انجام دادیم: اولا از فرمت ثابت ‎[hh]:mm:ss استفاده کردیم که مدت را با شروع از ساعت و با دقت ثانیه بازنمایی می‌کند و ثانیا ترتیبی دادیم که مدت‌های منفی کماکان به همان صورت عددی صادر شوند تا در Excel با خطا مواجه نشویم. البته فرمتی که به این ترتیب ایجاد کرده‌ایم، طبق معمول، بعدا در خود Excel توسط کاربر قابل تغییر است.

 

قابلیت استفاده از سری رنگ‌های از پیش تعریف شده گوناگون

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

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

 

گزارش‌ها و نمودارهای محوری جدید در نسخه 11.02

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

• گزارش خلاصه اسناد
• فهرست رخدادهای انبار
• فهرست برگه‌های درخواست
• فهرست برگه‌های انبار
• فهرست برگه‌های رسید موقت
• فهرست برگه‌های درخواست خدمات
• فهرست برگه‌های انجام خدمات
• فهرست پیش‌فاکتورها و قراردادها
• فهرست برگه‌های فروش
• فهرست سطرهای برگه‌های فروش
• فهرست کسور و اضافات برگه‌های فروش
• فهرست پورسانت‌های برگه‌های فروش

برخی از دیگر امکانات پایه و عمومی پیاده‌سازی شده یا بروز شده در زیرساخت کلی نرم‌افزار یکپارچه مالی نوسا نسخه 11.02:

 

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

• از این پس Compatibility Level در همه‌ی پایگاه‌های SQL ما به صورت پیش‌فرض 110 خواهد بود. البته کاربران می‌توانند در صورت تمایل این سطح را افزایش دهند – اما باید توجه کرد که رفتار SQL Server با Queryها تحت تاثیر این عدد قرار می‌گیرد و این رفتار کاملا وابسته به ماهیت داده‌ها نیز خواهد بود. به همین دلیل برای برخی از پایگاه‌ها ممکن است افزایش سطح مزبور وضعیت کلی سیستم را بهتر کند و برای برخی دیگر ممکن است تاثیر معکوس داشته باشد و وضعیت را بدتر کند. سطح 110 از نظر ما یک وضعیت تست شده و مناسب به عنوان پیش‌فرض است.

• از این پس در تنظیمات پایگاه‌ها در SQL Server (در DB Options) در قسمت Recovery، Page Verify روی حالت CheckSum خواهد بود. در اثر این تغییر ممکن است خطاهای موجود در برخی از پایگاه‌ها (که با تنظیم قبلی لزوما آشکار نمی‌شده است) در نسخه‌ی جدید پدیدار شوند. این خطاها از قبل در سیستم‌ها موجود بوده، و صرفا به دلیل کنترل قوی‌تر و استفاده از امکانات جدید تر SQL پس از نصب نسخه قابل ملاحضه می‌باشند.

• در نسخه‌های Express نرم‌افزار SQL، زمان ساخت پایگاه اطلاعاتی با معرفی مستقیم فایل‌ها، پس از این گزینه AutoClose در پایگاه کنترل می‌گردد. 

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

 

• محدودیت تعداد سطرهایی که به صورت همزمان می‌توانند در یک جدول با Ctrl+A به یکباره انتخاب شوند را از 3000 به 5000 تغییر دادیم. محدودیت اصلی ما در این عملیات، رفتار SQL Server در برخورد با Queryهای پیچیده است. ممکن است در برخی از عملیات، با انتخاب تعداد زیادی سطر به صورت همزمان با خطای Complicated Query مواجه شویم، به این دلیل و به دلیل محدودیت‌های سخت‌افزاری عموم کلاینت‌های استفاده گنندگان، افزایش این تعداد بیش از این عدد در حال حاضر توجیه پذیر نمی‌باشد. 

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

• پس از این نسخه، در حین مشاهده‌ گزارش‌ها و فرم‌ها، در جستجوی آزاد در فیلدهای حرفی (با Ctrl+F) از این پس به جای کل عبارت جستجو، کلمات تشکیل‌دهنده‌ آن جستجو می‌شوند. یافته، سطری است که همه‌ کلمات در آن بکار رفته باشد. این کلمات ممکن است به دنبال هم و یا حتی به همان ترتیب وجود نداشته باشند.

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

• در تعریف جدول در فرم‌های نمایش گزارش‌ها امکان افزودن ستون جدید در محل مکان‌نما پس از این اضافه شد. همچنین Hotkeyهای استاندارد ویرایش این امکان نیز اضافه گردیدند.

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

 

برخی از امکانات پیاده‌سازی شده یا بروز شده در نرم‌افزار حسابداری و حسابداری با رویکرد تعهدی نوسا نسخه 11.02:

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

• در گزارش‌های حسابداری که در آنها انتخاب بخش‌های برگزیده با مولفه‌ی فهرست کرکره‌ای قابل علامت‌گذاری میسر شده بود، در فهرست مزبور فشار کلیدهای Ctrl+Del به معنی حذف علامت از همه‌ی گزینه‌ها خواهد بود.

• افزایش کنترل میزان ناهنجاری داده با استفاده از هوش مصنوعی و ارائه فرم مربوط به آن در گزارش جستجو در شرح اسناد.

• افزایش گزارش‌ها، جداول و نمودارهای محوری جدید پیاده سازی شده در گزارش خلاصه اسناد

• فرم‌ها، گزارش‌ها و امکاناتی که در نرم‌افزار حسابداری به ابزار چند بخشی متصل گردیده‌اند:
  • فهرست حسابها
  • فهرست تفصیلی‌ها
  • افزودن یکباره تعدادی حساب به یک مجموعه
  • افزودن یکباره تعدادی تفصیلی به یک مجموعه
  • گزارش خلاصه اسناد
  • اصلاح یکباره اسناد
  • ریزعملیات یک حساب
  • ریزعملیات یک تفصیلی
  • ریزعملیات یک مجموعه حساب
  • ریزعملیات یک مجموعه تفصیلی
  • دفتر روزنامه
  • دفتر یک حساب
  • دفتر یک تفصیلی
  • جستجو در شرح اسناد
  • تراز و سایر گزارش‌های 4 ستونی حساب‌ها
  • تراز و سایر گزارش‌های 4 ستونی تفصیلی‌ها
  • تراز و سایر گزارش‌های 8 ستونی حساب‌ها
  • تراز و سایر گزارش‌های 8 ستونی تفصیلی‌ها
  • تراز گروه‌بندی شده کلان
  • تراز آزمایشی جامع
  • تراز مبتنی بر الگوهای عملیات حساب
  • گزارش محوری جامع مالی
  • خلاصه عملیات یک حساب
  • خلاصه عملیات یک تفصیلی
  • خلاصه عملیات یک مجموعه حساب
  • خلاصه عملیات یک مجموعه تفصیلی
  • گردش و مانده‌ی اجزاء یک مجموعه حساب (قابل احضار از خلاصه عملیات یک مجموعه حساب)
  • گردش و مانده‌ی اجزاء یک مجموعه تفصیلی (قابل احضار از خلاصه عملیات یک مجموعه تفصیلی)
  • تفکیک اسناد به اجزاء
  • خلاصه مانده حسابهای یک مجموعه
  • خلاصه مانده تفصیلی‌های یک مجموعه
  • تفکیک عملیات حساب به یک شماره تفصیلی (سرجمع)
  • تفکیک عملیات تفصیلی به یک شماره تفصیلی (سرجمع)
  • تفکیک عملیات تفصیلی به حسابها (سرجمع)
  • تفکیک عملیات حساب به طبقات تفصیلی (سرجمع)
  • تفکیک عملیات تفصیلی به طبقات تفصیلی (سرجمع)
  • تفکیک حساب‌های یک مجموعه به تفصیلی‌ها
  • تفکیک تفصیلی‌های یک مجموعه به حساب‌ها
  • تفکیک عملیات حساب به یک شماره تفصیلی (گروه‌بندی شده)
  • تفکیک عملیات تفصیلی به یک شماره تفصیلی (گروه‌بندی شده)
  • تفکیک عملیات تفصیلی به حسابها (گروه‌بندی شده)
  • تفکیک عملیات حساب به طبقات تفصیلی (گروه‌بندی شده)
  • تفکیک عملیات تفصیلی به طبقات تفصیلی (گروه‌بندی شده)
  • تصفیه رخدادها و صورت مغایرت
  • صورت مغایرت‌های ذخیره شده
  • ایجاد فایل صادره از اسناد
  • ایجاد فایل صادره از حساب‌ها
  • ایجاد فایل صادره از تفصیلی‌ها

 

 

 

برخی از امکانات پیاده‌سازی شده یا بروز شده در نرم‌افزار دریافت و پرداخت (خزانه داری) نوسا نسخه 11.02:

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

برخی از امکانات پیاده‌سازی شده یا بروز شده در نرم‌افزار انبار و کنترل موجودی تولید نوسا نسخه 11.02:

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

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

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

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

 

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

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

• در خلاصه‌ی اطلاعات کالا (Alt+F11)، در صفحه‌ی سایر کاربردها، برگه‌های شمارش کالایی که کالای موضوع گزارش در آنها بکار رفته است بازنمایی می‌شوند. برای هر برگه، تاریخ، نام انبار و شرح ذکر می‌شوند. 

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

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

• افزایش کنترل میزان ناهنجاری داده با استفاده از هوش مصنوعی و ارائه فرم مربوط به آن در گزارش‌ فهرست رخدادهای انبار.

• افزایش کنترل میزان ناهنجاری داده با استفاده از هوش مصنوعی و ارائه فرم مربوط به آن در گزارش‌ فهرست رخدادهای درخواست‌های کالا.

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

• افزایش گزارش‌ها، جداول و نمودارهای محوری جدید پیاده سازی شده در گزارش‌های انبار:
  • فهرست رخدادهای انبار
  • فهرست برگه‌های درخواست
  • فهرست برگه‌های انبار
  • فهرست برگه‌های رسید موقت

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

برخی از امکانات پیاده‌سازی شده یا بروز شده در نرم‌افزار فروش کالا و خدمات نوسا نسخه 11.02:

 

• در فهرست سطرهای پیش‌فاکتورها و قراردادها و فهرست سطرهای برگه‌های فروش، به عنوان بخشی از امکانات بر مبنای کنترل هوشمند، کنترل تطابق داده‌ها با تعرفه‌ها و / یا قوانین تغییر تعرفه پیاده‌سازی شده‌اند.

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

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

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

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

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

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

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

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

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

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

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

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

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

• تغییرات مربوط به گزارش‌های فصلی فروش و قراردادهای فروش کالا و خدمات. این تغییرات که بر اساس تغییر در نحوه کارکرد نرم‌افزار TTMS سازمان مالیات پیاده‌سازی گردیده‌اند این قابلیت را بوجود می‌آورند تا مبلغ عوارض قانونی (عوارض ارزش‌افزوده) به صورت مستقل صادر نشود و در مقابل جمع مبالغ عوارض و مالیات ارزش افزوده به عنوان مالیات ارزش افزوده صادر شوند. این تغییر به خودی خود نمی‌بایست مشکلی برای ما در نسخ قبل ایجاد می‌کرد، چرا که مکانیزم صدور در سیستم ما قابل تعریف است. کافی بود مقدار ثابت صفر را برای عوارض صادر می‌کردیم و در کنار آن جمع مالیات و عوارض را نیز به عنوان فیلد مالیات بر ارزش افزوده صادر می‌کردیم. اشکال این است که در مکانیزم کنترل فایل مالیات تا تاریخ 4 مرداد، وجود صفر در فیلد عوارض منجر به خطا می‌گردید و انتظار می‌رفت که این فیلد خالی باشد. این در حالی است که ساختار فایل access تغییر نکرده بود و فیلد مزبور در این فایل کماکان required بود – یعنی در صدور اطلاعات، اگر در روش صدور لحاظ نشده یا خالی باشد خطا داشتیم (با این پیغام که محتوای فیلد مزبور نمی‌تواند خالی باشد). برای اینکه متوجه شویم در این پارادوکس قطعی، خود نرم‌افزار TTMS چگونه قادر به ورود اطلاعات است بررسی‌های لازم انجام شد و مشخص شد که در رکوردهای فایل access حاصل از این نرم‌افزار یک رشته‌ی حرفی خالی در فیلد عوارض درج می‌شود. پس ما هم باید از همین روش برای صدور اطلاعات استفاده می‌کردیم. به این منظور باید ترتیبی می‌دادیم که رشته‌ی حرفی خالی از سیستم ما قابل صدور باشد + ترتیباتی می‌دادیم که در سرجمع کردن اطلاعات (فرآیند ثانویه‌ای که روی فایل صادر شده انجام می‌شود) نیز فیلد عوارض حاوی رشته‌ی حرفی خالی مشکلی ایجاد نکند و در رکوردهای سرجمع حاصله نیز فیلد مزبور یک رشته‌ی حرفی خالی باقی بماند. به این منظور تمهیدات زیر را انجام دادیم، توجه فرمایید برخی از این تغییرات با اصلاح TTMS در ساختار ارائه شده در 4 مرداد ماه امسال حل گردید ولیکن از آنجا که ممکن است در آینده با مشکلاتی مشابه مواجه گردیم و از آنجا که راهکار غیر استاندارد برای حل این مشکل در تیر ماه 1401 به نرم‌افزار اضافه شده بود، این امکانات به شرح زیر در دسترس می‌باشند:
  • ترتیبی دادیم که اگر در تعریف روش صدور، محتوی یک فیلد «خالی» باشد و عبارت ثابت آن ترکیب عجیب و قرارداد شده‌ی _@_ باشد، یک رشته‌ی حرفی خالی در فیلد مقصد درج شود. از این روش در تعریف روش صدور برای فیلد عوارض استفاده خواهیم کرد.
  • در محاوره‌ی سرجمع کردن محتویات یک فایل access یک پارامتر جدید به صورت یک دریچه‌ی قابل علامت‌گذاری و با عنوان «TTMS4043 یا پس از آن (فاقد عوارض قانونی)» تعبیه کردیم. این پارامتر، هم در سرجمع کردن فروش و هم در سرجمع کردن هزینه لحاظ شده است و باعث می‌شود که در حین محاسبه‌ی سرجمع به فیلد عوارض توجه نشود و آن فیلد در رکوردهای سرجمع یک رشته‌ی حرفی خالی باشد. دریچه‌ی پیش‌گفته به صورت پیش‌فرض علامت‌گذاری شده است. (وجود یا عدم وجود این پیش فرض در ساختار بروز شده TTMS دیگر مشکل ساز نخواهد بود)

• افزایش کنترل میزان ناهنجاری داده با استفاده از هوش مصنوعی و ارائه فرم مربوط به آن در گزارش‌ فهرست رخدادهای انجام خدمات.

• افزایش کنترل میزان ناهنجاری داده با استفاده از هوش مصنوعی و ارائه فرم مربوط به آن در گزارش‌ فهرست رخدادهای درخواست‌های خدمات.

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

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

• در نسخه 11.02 سه فیلد کد پستی، شماره ثبت و یا شماره ملی، و شناسه ملی در کنترل و مکانیزم‌های زیر اضافه گردیند:
  • کپی انواع برگه‌های فروش
  • ذخیره و بازیابی برگه‌های فروش در فایل وارده XP
  • فراخوانی پیش‌فاکتور یا قرارداد در فاکتور فروش

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

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

برخی از امکانات پیاده‌سازی شده یا بروز شده در ابزار مدیریت هزینه و خرید نوسا نسخه 11.02:

 

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

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

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

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

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

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

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

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

• از این پس در قوانین طرف حساب برگه‌های هزینه، در حین تنظیم شرح رخداد می‌توان از شرح عمومی برگه نیز استفاده کرد. این شرح با کد 44 در زیرگروه برگه در محاوره‌ی تعیین شرح قرار داده شده است.

• تغییرات مربوط به گزارش‌های فصلی خرید و قراردادهای خرید کالا و خدمات. این تغییرات که بر اساس تغییر در نحوه کارکرد نرم‌افزار TTMS سازمان مالیات پیاده‌سازی گردیده‌اند این قابلیت را بوجود می‌آورند تا مبلغ عوارض قانونی (عوارض ارزش‌افزوده) به صورت مستقل صادر نشود و در مقابل جمع مبالغ عوارض و مالیات ارزش افزوده به عنوان مالیات ارزش افزوده صادر شوند. این تغییر به خودی خود نمی‌بایست مشکلی برای ما در نسخ قبل ایجاد می‌کرد، چرا که مکانیزم صدور در سیستم ما قابل تعریف است. کافی بود مقدار ثابت صفر را برای عوارض صادر می‌کردیم و در کنار آن جمع مالیات و عوارض را نیز به عنوان فیلد مالیات بر ارزش افزوده صادر می‌کردیم. اشکال این است که در مکانیزم کنترل فایل مالیات تا تاریخ 4 مرداد، وجود صفر در فیلد عوارض منجر به خطا می‌گردید و انتظار می‌رفت که این فیلد خالی باشد. این در حالی است که ساختار فایل access تغییر نکرده بود و فیلد مزبور در این فایل کماکان required بود – یعنی در صدور اطلاعات، اگر در روش صدور لحاظ نشده یا خالی باشد خطا داشتیم (با این پیغام که محتوای فیلد مزبور نمی‌تواند خالی باشد). برای اینکه متوجه شویم در این پارادوکس قطعی، خود نرم‌افزار TTMS چگونه قادر به ورود اطلاعات است بررسی‌های لازم انجام شد و مشخص شد که در رکوردهای فایل access حاصل از این نرم‌افزار یک رشته‌ی حرفی خالی در فیلد عوارض درج می‌شود. پس ما هم باید از همین روش برای صدور اطلاعات استفاده می‌کردیم. به این منظور باید ترتیبی می‌دادیم که رشته‌ی حرفی خالی از سیستم ما قابل صدور باشد + ترتیباتی می‌دادیم که در سرجمع کردن اطلاعات (فرآیند ثانویه‌ای که روی فایل صادر شده انجام می‌شود) نیز فیلد عوارض حاوی رشته‌ی حرفی خالی مشکلی ایجاد نکند و در رکوردهای سرجمع حاصله نیز فیلد مزبور یک رشته‌ی حرفی خالی باقی بماند. به این منظور تمهیدات زیر را انجام دادیم، توجه فرمایید برخی از این تغییرات با اصلاح TTMS در ساختار ارائه شده در 4 مرداد ماه امسال حل گردید ولیکن از آنجا که ممکن است در آینده با مشکلاتی مشابه مواجه گردیم و از آنجا که راهکار غیر استاندارد برای حل این مشکل در تیر ماه 1401 به نرم‌افزار اضافه شده بود، این امکانات به شرح زیر در دسترس می‌باشند:
  • ترتیبی دادیم که اگر در تعریف روش صدور، محتوی یک فیلد «خالی» باشد و عبارت ثابت آن ترکیب عجیب و قرارداد شده‌ی _@_ باشد، یک رشته‌ی حرفی خالی در فیلد مقصد درج شود. از این روش در تعریف روش صدور برای فیلد عوارض استفاده خواهیم کرد.
  • در محاوره‌ی سرجمع کردن محتویات یک فایل access یک پارامتر جدید به صورت یک دریچه‌ی قابل علامت‌گذاری و با عنوان «TTMS4043 یا پس از آن (فاقد عوارض قانونی)» تعبیه کردیم. این پارامتر، هم در سرجمع کردن فروش و هم در سرجمع کردن هزینه لحاظ شده است و باعث می‌شود که در حین محاسبه‌ی سرجمع به فیلد عوارض توجه نشود و آن فیلد در رکوردهای سرجمع یک رشته‌ی حرفی خالی باشد. دریچه‌ی پیش‌گفته به صورت پیش‌فرض علامت‌گذاری شده است. (وجود یا عدم وجود این پیش فرض در ساختار بروز شده TTMS دیگر مشکل ساز نخواهد بود)
  • فیلد جمع مالیات و عوارض در صدور اطلاعات رخدادهای هزینه (به صورت فاقد علامت – آن‌طور که TTMS انتظار دارد) وجود نداشت و اضافه شد.
  • به صورت مشابه فیلد جمع مالیات و عوارض ارزی در همانجا اضافه شد.
  • همچنین فیلد نرخ برابری جمع مالیات و عوارض ارزی نیز یه صورت مشابه اضافه شد.

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

 

 

 

برخی از امکانات پیاده‌سازی شده یا بروز شده در نرم‌افزار حقوق و دستمزد و رخدادهای پرسنلی نوسا نسخه 11.02:

 

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

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

 

 

 

برخی از امکانات پیاده‌سازی شده یا بروز شده در نرم‌افزار اموال و دارایی‌های ثابت نوسا نسخه 11.02:

 

• پس از این، در فهرست رخدادهای دارایی‌ها امکان «تشکیل مشروط سند اموال از تمام رخدادها» پیاده‌سازی گردیده است. جهت استفاده از این امکان در فهرست رخدادهای دارایی‌ها، تکمه‌ای برای تنظیم سند اموال از رخداد تحت مکان‌نما با رخدادهای انتخاب شده وجود دارد. در ویرایش جدید این تکمه را به یک منو با دو آیتم مجهز کردیم. آیتم نخست کارکردی مشابه تکمه‌ی مزبور دارد. آیتم دوم یک امکان جدید با عنوان «تشکیل مشروط سند اموال از تمام رخدادها» است که در ادامه توضیح می‌دهیم. مکانیزم تشکیل سند اموال (مبتنی بر رخدادهای اموال) در ویرایش‌های قبلی مبتنی بر انتخاب رخدادهای موردنظر در فهرست بود. از آنجا که تعداد سطرهایی که همزمان قابل انتخاب هستند محدود است (3000 در نگارش قبلی و 5000 در نگارش جدید)، برای تسهیل عملیات تشکیل سند، امکان تشکیل سند از همه‌ی رخدادهای فهرست شده را در نگارش جدید فراهم کرده‌ایم. این روش تشکیل سند در مقایسه با روشی که پیش از این داشتیم تفاوت‌هایی دارد که در ادامه به آنها خواهیم پرداخت.
  امکانات متنوعی در احضار فهرست رخدادهای دارایی‌ها در اختیار داریم؛ یعنی برای تعیین دقیق رخدادهایی که میل داریم در فهرست بازنمایی شوند پارامترهای متعددی را می‌توانیم تنظیم کنیم. همه‌ی این پارامترها در تشکیل سندِ مشروط قابل اعمال نیستند. از بین پارامترهای مزبور فقط به موارد زیر توجه می‌شود:
  • محدوده‌‎ی تاریخ
  • محدوده‌ی شماره و سری
  • محدوده‌ یا الگوی کد دارایی‌ها
  • محدوده‌ی کد گروه دارایی
  • محدوده‌ی کد طبقه دارایی
  • بخش
  • انواع رخدادها

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

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

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

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

• در نسخه 11.02، در فهرست دارایی‌ها امکان محاسبه و حذف مقاطع استهلاک برای "همه دارایی‌ها" به منوی ویرایش (قلم) اضافه شدند.

 

 

 

برخی  تغییرات و اشکالات رفع شده در نسخه 11.02 نرم‌افزار مالی یکپارچه نوسا به تفکیک نرم‌افزار زیر مجموعه:

 

• عمومی: در نمودارهای شاخص عملکرد فرمول‌ها و متغیرها در محدوده‌های زمانی محاسبه می‌شوند، اما اگر در تعریف آنها از وضعیت‌های پیش از محدوده و در انتهای محدوده استفاده شده باشد مقدار آنها تحت تاثیر مقادیر محدوده‌های قبلی نیز قرار می‌گیرند. اشکال اینجا بود که اگر یک متغیر در یک محدوده‌ی زمانی اصلا داده نداشته باشد (مثلا یک حساب در یک ماه فاقد گردش باشد) آن متغیر در آن محدوده اصلا مورد محاسبه قرار نمی‌گرفت – یعنی مقادیر متغیر در محدوده‌های قبلی مورد توجه واقع نمی‌شدند. این مشکل در نسخه 11.02 برطرف گردید.
• عمومی: برخی از کاربران ممکن است به صورت یک کاربر اختصاصی در سیستم تعریف نشده باشند ولی کماکان با توجه به گروه‌هایی که در آنها عضو هستند بتوانند از سیستم استفاده کنند. این به شرطی است که گروه(ها) در سیستم تعریف شده و امکانات و بخش(های) آنها تعیین شده باشند. این گروه‌ها همانند کاربران عادی یک بخش اصلی و تعدادی بخش فرعی دارند. رویه سیستم چنین است که بخش‌های کاربر در نهایت از ترکیب بخش اصلی و بخش‌های فرعی حاصل می‌شوند. اشکال در کاربرانی بود که شناسایی آنها مبتنی بر گروه انجام شده باشد (خودشان کاربر صریح سیستم نباشند)؛ برای این کابران، بخش اصلی گروه (که توسط کاربر به ارث رسیده است) جزء بخش‌های کاربر لحاظ نمی‌شد. این اشکال که در فهرست بخش‌های بازنمایی شده در گزارش‌های اموال و دستمزد برای کاربران گزارش‌گیری که از طریق گروه شناسایی شده باشند قابل مشاهده بود در نسخه 11.02 برطرف گردید.
• عمومی: در حین ملاحظه‌ی برگه‌ها یا سندها، اگر از ابتدا برگه‌های "همه‌ی بخش‌ها" را احضار کرده باشیم و در ادامه، با حرکت در بین برگه‌ها روی یک برگه قرار داشته باشیم که بخش آن متفاوت از بخش کاربر باشد و فرمان پرش به برگه‌ی دلخواه یا Ctrl+F3 را صادر کنیم با خطای "برگه یا سند یافت نشد" مواجه می‌شدیم. این مکانیزم بروز شد و خطا برطرف گردید.
• عمومی: اگر یک پیش‌تنظیم برای یکی از گزارش‌های مالی، در زمانی ذخیره شده باشد که کاربر به یک نرم‌افزار Login کرده ولی در زمان بازخوانی آن پیش‌تنظیم کاربر دیگر در آن نرم‌افزار Login نباشد، تنظیمات مربوط به آن نرم‌افزار به صورت فعال در گزارش مالی لحاظ می‌شدند – این در حالی بود که مولفه‌های مربوط به آن تنظیمات در محاوره‌ی ابتدایی گزارش غیرفعال بودند. اشکال اینجا است که فقط اسناد نرم‌افزارهای Login شده باید در گزارش لحاظ شوند، این اشکال در نسخه 11.02 برطرف گردید. 
• عمومی (SOAP): در اتصال کلاینت به سرور از طریق SOAP، چنانچه در تنظیمات Windows، Time Zone سرور پیش از کلاینت بود (مثلا کلاینت روی ایران و سرور روی بریتانیا یا آمریکا تنظیم شده بود)، در ورق زدن برگه‌ها با مشکل مواجه می‌شدیم، این مشکل در نسخه 11.02 برطرف گردید. رفع این اشکال مستلزم نصب سرور SOAP جدید روی رایانه‌ها است. وجود سرور قدیمی در ابتدای اجرای Admin تشخیص و اطلاع داده می‌شود.

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

• حسابداری: کاربران حسابداری دولتی با رویکرد تعهدی که به جز حسابداری در هیچ نرم‌افزار دیگری Login نکرده باشند، در حین تعریف کاربران و امکانات آنها اختیار "تعیین الگوی عملیات و برچسب‌ها در درخت حسابها" را مشاهده نمی‌کردند.

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

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

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

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

• فروش: اختیار کاربر در "ملاحظه پیش‌فاکتورها و قراردادها (سایر بخش‌ها)" در ملاحظه فرم نهایی پیش‌فاکتور کنترل نشده بود، این کنترل در نسخه 11.02 اضافه گردید. 

• فروش: در گزارش محوری جامع فروش، محاسبات مربوط به نمودارهای شاخص عملکرد باید در هر بار بازخوانی گزارش (با F5) یا در تغییر پارامترهای گزارش (Ctrl+F3) تکرار شوند. در این محاسبات حاصل به جا مانده از محاسبات قبلی پاک نمی‌شد و مقادیر جدید به موارد قبلی افزوده می‌شد، این مشکل در نسخه 11.02 برطرف گردید.

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

• مدیریت هزینه: در احضار سند حسابداری یا دریافت و پرداخت از برگه‌ی هزینه، اگر کاربری اختیار ملاحظه‌ی برگه‌های هزینه سایر بخش‌ها را داشته باشد ولی اختیار ملاحظه‌ی اسناد سایر بخش‌ها را نداشته باشد و مشغول ملاحظه‌ی برگه‌های هزینه‌ی همه‌ی بخش‌ها باشد، احضار سند با خطای اختیارات کاربر مواجه می‌شد، این مشکل در نسخه 11.02 برطرف گردید.

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

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

 

 

-- پایان

گروه توسعه سیستم‌های مالی نوسا