انجمن‌ها

ابزار جدید ارائه شده در نسخه 14.02 نرم‌افزار حسابداری: ارسال رخدادهای مالی به سامانه دفاتر تجاری الکترونیکی (نسخه ارائه شده تیر ماه 1403)

با اجرای بند «ج» ماده ۴ قانون برنامه هفتم توسعه، دفاتر پلمپ‌شده فیزیکی حذف و جای خود را به سامانه‌های الکترونیکی داده اند. در همین راستا، سامانه ثبت درخواست پلمپ دفاتر قانونی از سال ۱۴۰۳ توسط سازمان ثبت اسناد فعال شده و سامانه ارسال اطلاعات دفاتر تجاری الکترونیکی سازمان امور مالیاتی نیز از 25 خرداد ماه پس از سلسله تغییرات گسترده جهت بهره‌برداری عمومی برای اشخاص حقوقی و حقیقی گروه اول الزامی گردید. طی آخرین فایل راهنما ارائه شده توسط سازمان امور مالیاتی، قوانین فعلی در رابطه با مهلت بارگذاری اطلاعات دفاتر تجاری الکترونیکی به شرح زیر است.
 

سامانه مذکور سازمان امور مالیاتی کشور در آخرین نسخه فعلی اطلاعات را به صورت فایل‌های Excel و یا CSV (یعنی Comma Separated Value) دریافت می‌کند که البته برای داده‌های بزرگ انتظار فرمت CSV دارد. روش نوسا برای تهیه‌ی این فایل، ارائه‌ی گزارشی حاوی رخدادهای مالی‌ای که قرار است صادر شوند و پس از آن پیاده‌سازی یک فرمان صدور برای ایجاد فایل حاوی داده‌های مزبور است. در ادامه این پست بازپخش ویدیو آموزشی کامل وبینار ارائه شده در 4 خرداد ماه سال 1404 جهت آشنایی با قوانین جدید و آموزش ابزار نوسا و قابلیت‌های آن در دسترس قرار گرفته است. دقت بفرمایید، سامانه مذکور پس از پخش وبینار نوسا، شامل تغییرات جدیدی گردیده است که این تغییرات و تغییرات مربوطه در نرم‌افزارهای نوسا پس از ارئه وبینار در ادامه ویدیو بازپخش وبینار در این پست در دسترس می‌باشند، خلاصه برخی از تغییرات جدید قانون و سامانه مذکور پس از ارائه وبینار آموزشی نوسا به شرح زیر است:

• تغییر و شفاف سازی در رابطه با مهلت بارگذاری اطلاعات طی آخرین راهنمای ارائه شده موجود، این مهلت در بخش بالای این پست در دسترس است.

• تغییر در فرمت فایل قابل دریافت توسط سامانه و جابجایی ستون شرح در گزارش مربوطه، این تغییرات در نسخه ارائه شده اعمال گردیده است. 

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

شرکت نوسا با نگاهی کاربردی به الزامات جدید قانون، به روند ثبت درخواست پلمپ دفاتر قانونی در سامانه ثبت اسناد و به‌ویژه راهکار ارسال اطلاعات دفاتر تجاری الکترونیکی در سامانه جدید سازمان امور مالیاتی پرداخته. همچنین آموزش ابزار جدید ارسال اطلاعات به دفاتر تجاری الکترونیکی موجود در نسخه 14.02 نرم‌افزار مالی نوسا با تأکید بر الزامات، ابهامات، قابلیت‌ها و انعطاف‌های مورد نیاز آتی را مورد توجه قرار داده و در پایان، به معرفی برخی از امکانات نرم‌افزارهای نوسا منطبق با ساختار جدید و تغییرات جدید ابزار ارسال اطلاعات فروش نوسا به سامانه مودیان مالیاتی نیز می‌پردازد. دقت بفرمایید با توجه به اعلام فوق بخش کوچکی از این وبینار برگزار شده در 4 خرداد ماه سال 1404 دیگر بروز نبوده و این تغییرات جدید در ادامه مستند در دسترس می‌باشند ولیکن عموم کارکرد و نحوه استفاده از ابزار جدید نوسا طی آموزش ارائه شده در این وبینار همچنان درست و قابل استفاده می‌باشد.  

زمان بندی وبینار:

1. معرفی موضوع وبینار و اطلاعات تکمیلی 00:00:00

2. مروری بر قوانین مرتبط با دفاتر تجاری الکتورنیکی 00:02:29

3. افراد مشمول قوانین دفاتر تجاری سازمان امور مالیاتی 00:06:03

4. جرایم عدم ارائه دفاتر پلمپ شده طی قوانین فعلی 00:08:40

5. بازه زمانی مورد تایید جهت ارائه اطلاعات دفاتر 00:10:40

6. مراحل درخواست ثبت پلمپ دفاتر قانونی در سامانه سازمان ثبت اسناد 00:17:00

7. مراحل ثبت اطلاعات در سامانه دفاتر تجاری الکترونیکی سازمان امور مالیاتی 00:18:37

8. آموزش ابزار ارسال اطلاعات به سامانه دفاتر تجاری الکترونیکی نوسا 00:29:36

9. سایر امکانات مرتبط و موجود در نسخه 14.02 نرم افزار مالی نوسا 00:44:59

10. پاسخ به برخی موارد عام و مطرح شده توسط مخاطبان وبینار 00:57:48​

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

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

همانطور که در توضحیات فوق مشاهده می‌کنید بحث حساب‌های کل و معین مطرح است. در نسخه‌ی ابتدایی سامانه حساب‌های تفصیلی هم درخواست شده بود که البته در راهنمای 15 اردبیهشت 1404حساب تفصیلی از خواسته‌ها حذف شد و در راهنمای جدید ارائه شده برای خرداد 1404 نیز حساب معین و شرح، اختیاری اعلام گردید. با این همه از آنجا که سامانه‌های سازمان امور مالیاتی عادت به تغییرات مخرب و متعدد دارند، ما امکان 3 نوع صدور اطلاعات 1- حساب تفصیلی به همراه حساب کل و معین، 2- حساب کل و معین، 3- حساب کل به تنهایی را فراهم نمودیم.

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

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

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

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

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

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

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

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

امکانات جدید ارائه شده در نسخه 14.02 ابزار سامانه مودیان: استعلام و بروزرسانی خودکار آخرین وضعیت صورت‌حساب‌ها بر مبنای داده موجود در کارپوشه سامانه

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

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

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

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

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

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

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

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

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

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

توجه کنید که:

1) این محاوره صرفا برای استعلام وضعیت صورت‌حساب «ابطالی» در کارپوشه بازنمایی می‌شود. این عمل به صورت اختصاصی برای این کاربرد طراحی شده است و برخلاف موارد مشابه قبلی از منوی عملیات با سامانه قابل انجام نیست.

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

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

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

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

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

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

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

امکانات جدید ارائه شده در نسخه 1402: مقدار برحسب واحدهای اضافه 1 و 2 در گزارش‌های نرم افزار فروش

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

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

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

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

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

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

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

بروزرسانی زیرساخت مرکزی نرم‌افزار: ارائه نسل جدید 64 بیتی سرور SOAP

سرور SOAP سیستم مالی یکپارچه‌ی نوسا در ویرایش 1402 به روز شده و نسل یوم آن در دسترس قرار گرفته است. اگر سرور SOAP به صورت استاندارد و توسط نرم‌افزار Admin نصب شده باشد، این سرور در فولدری به نام SOAPServer تحت فولدر Server قرار می‌گیرد. اگر چنین باشد، نسخه‌ی سرور SOAP در ابتدای اجرای نرم‌افزار Admin بررسی شده و چنانچه قدیمی باشد با پیغامی به صورت زیر به کاربر اطلاع داده می‌شود:

اما اگر سرور SOAP در یک مکان دیگر (مثلا در یک رایانه‌ی دیگر) نصب شده باشد، کنترل نسخه‌ی آن توسط Admin میسر نخواهد بود و لازم است تا dll جدید سرور SOAP به صورت دستی به مکان جدید منتقل گردد.

پیش از این فقط گونه‌ی 32 بیتی این سرور (Win32) ارائه شده بود. در ویرایش جدید هر دو گونه‌ی 32 و 64 بیتی از سرور SOAP ارائه شده‌اند. یادآوری می‌کنیم که نصب سرور SOAP از Admin / منوی سیستم / با انتخاب گزینه‌ی "تنظیمات سرور SOAP" انجام می‌شود. با اینکار محاوره‌ای به شکل زیر بازنمایی می‌شود:

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

قاعدتا در حال حاضر اکثر رایانه‌هایی که اقدام به اجرای سرور SOAP می‌نمایند، رایانه‌های 64 بیتی هستند. در IISهای 64 بیتی، به صورت پیش‌فرض، امکان اجرای سرور‌های 32 بیتی (همانند سرور SOAP ویرایش قبلی) وجود ندارد و برای اجرای سرورهای 32 بیتی تنظیمات اضافه‌ای لازم است. چنین است که هر سرور از یک Application Pool استفاده می‌کند (که در خود سرور تعیین می‌شود). مثلا اگر پس از نصب سرور SOAP در Admin، در IIS، در Sites / Default Web Site روی سطر AccXPSOAP قرار بگیرید و از فهرست Actions (در سمت راست پنجره‌ی IIS) Basic Settings را انتخاب نمایید، با محاوره‌ای به شکل زیر مواجه خواهید شد که Application Pool مورد استفاده توسط این سرور را بازنمایی می‌کند و همچنین امکان تغییر آنرا فراهم می‌نماید:

Application Pools به صورت جداگانه در درخت اصلی IIS (درخت سمت چپ پنجره‌ی IIS) بازنمایی می‌شوند. هر Application Pool دارای تنظیمات مفصلی است. برای احضار این تنظیمات، مکان‌نما را روی Application Pool مورد نظر (مثلا DefaultAppPool) قرار دهید و از فهرست Actions (از سمت راست پنچره‌ی IIS)، Advanced Settings را انتخاب کنید. محاوره‌ای به شکل زیر بازنمایی می‌شود:

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

اما اشکالی وجود دارد (که دلیل مطرح کردن این بحث بوده است): فعال کردن حالت 32 بیتی به معنی غیرفعال شدن حالت 64 بیتی است! یعنی مثلا این پارامتر باید از ابتدا به صورت یک انتخاب دو گزینه‌ای 32 یا 64 بیتی طرح می‌شد و به هر حال ما باید از آن چنین برداشتی داشته باشیم. با توجه به این نکته، اگر از قبل سرور SOAP از گونه‌ی 32 بیتی در یک IIS نصب شده و در حال اجرا باشد، حتما به صورت پیش‌فرض نخواهیم توانست آنرا به 64 بیتی تبدیل کنیم و لازم است تا Application Pool مربوط را به صورت مناسب اصلاح کنیم (سرورهای 32 بیتی را در آن غیرفعال کنیم – با انتخاب گزینه‌ی False در سطری که در شکل بالا مورد اشاره قرار گرفت).

اما فقط این نیست! یک Application Pool ممکن است برای بیش از یک سرور (یا Application) بکار رفته باشد و اگر چنین باشد هر تنظیمی که روی آن انجام می‌دهید همه‌ی سرورها یا Applicationهایی که با آن کار می‌کنند را تحت تاثیر قرار می‌دهد. به این ترتیب مطابق تعریف و ساختار IIS نمی‌توانیم ترکیبی از سرورهای 32 یا 64 بیتی را با یک Application Pool اجرا کنیم و شاید لازم باشد که Poolها را تفکیک کنیم (و مثلا دو آیتم برای 32 بیتی و 64 بیتی داشته باشیم). برای مشاهده‌ی فهرست سرورها (یا Applicationها)یی که از یک Pool استفاده می‌کنند، مکان‌نمای فهرست را روی سطر مورد نظر (مثلا DefaultAppPool) قرار دهید و Right Click نمایید. منویی به شکل زیر احضار خواهد شد:

با انتخاب گزینه‌ی View Applications فهرست سرورهایی که از این Pool استفاده می‌کنند بازنمایی خواهد شد.
چنانچه گونه‌ی سرور SOAP با آنچه در Application Pool تنظیم شده است مطابقت نداشته باشد، در صورت استفاده از سرور SOAP با یک خطای عجیب به صورت زیر مواجه خواهیم شد، آن هم پس از اخذ نام و کلمه‌ی عبور! – بدانید که مربوط به این داستان است:

ارتقا زیرساخت نرم‌افزارهای درگیر با واحد فنی در نسخه 14.02: تعیین رفتار سیستم در گرد کردن در محاسبات دقیق مربوط به واحدهای فرعی کالاها و خدمات

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

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

بنا به نیاز مشتریان در ویرایش 14.02 یک فیلد جدید با همین نام به تعریف واحدهای فرعی اضافه شده است که نحوه‌ی ویرایش و گزینه‌های آنرا در شکل زیر مشاهده می‌کنید:
 

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

1) اگر در واحد فرعی از اعشار استفاده می‌شد دیگر اصولا خطای گرد کردن نمی‌داشتیم.

2) خطای گرد کردن در ارقام دقیق‌تر از 4 رقم اعشار اصولا قابل اندازه‌گیری نیست. پس در واحدهای با 4 رقم اعشار اصولا خطای گرد کردن نخواهیم داشت و هرگز اخطار یا خطا ناشی از این ویژگی جدید را مشاهده نخواهیم کرد.

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

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

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

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

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

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

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

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

ارتقا زیرساخت هسته مرکزی نرم‌افزار مالی یکپارچه مالی نوسا نسخه 14.02: ارتقا حروف "ک" و "ی" از کد پیج 1256 به یونیکد فارسی. 

با توجه به قدمت شرکت نرم‌افزار و سخت‌افزار ایران و مشتریان آن، با توجه به عدم پشتیبانی مناسب نسخ قدیمی ابزار زیرساخت مایکروسافت از جمله ویندوز از ساختار بونیکد فارسی، حروف "ی" و "ک" در اطلاعات وارده مشتریان در نرم‌افزار یکپارچه مالی نوسا همواره تا به امروز "ي" و "ك" ثبت می‌گردید، هر چند با ارائه نسل‌های جدید نرم‌افزار، ساختار داده نوسا به یونیکد فارسی تبدیل شد ولیکن تا به امروز به دلیل پیچیدگی بسیار بزرگ مواجهه با داده قبلی ثبت شده توسط مشتریان و قدمت استفاده از نرم‌افزارها این حروف همچنان بصورت کد پیج 1256 پشتیبانی می‌گردیدند. در سال 1404 با توجه به عمومیت اتصال انواع وب سرویس های ورودی و خروجی، API ها، سامانه‌های تحمیلی و ساختار مورد استفاده روزمره در ابزاری مانند اکسل و یا نیاز به کپی و پیست از وب. یک پروژه بزرگ و پیچیدهبرنامه ریزی گردید تا نه تنها ساختار این دو حرف با قدمت را در تمامی ساختار نرم‌افزار بروز نمایم، بلکه تمامی داده قبلی ثبت شده در پایگاه‌های توسط مشتریان بروز نرم‌افزارها هم برای یک باز بروز کرده و پس از این در تمامی حروف و داده‌های موجود از استاندارد یونیکد فارسی بروز استفاده کنیم. این تغییر اساسی زیرساخت برخی نکات مهم را همراه دارد که آن نکان به شرح زیر است:

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

    

2. تغییر نسخه برای هر پایگاه از نسخ قدیمی به نسخه 14.02 زمان بر خواهد بود! در زمان تغییر نسخه مشتری با پنجره بروز رسانی حروف مربوطه مواجه گردیده و در جریان تغییرات قرار خواهد گرفت. لطفا جهت تغییر نسخ پایگا‌های خود (مخصوصا پایگاه های بزرگ) زمان لازم را برنامه‌ریزی نمایید. 

    

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

    

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

    

5. در صورتی که مشتری از API نوسا استفاده می‌نماید، انجام تغییرات و درسافت و ارائه اطلاعات "ی" و "ک" با استاندار یونیکد فارسی پس از این نسخه الزامی خواهد بود.

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

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

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

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

   

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

   

• ارائه متد جدید API جهت ثبت برگه‌های نقل و انتقال در API Server متعلق به نرم‌افزار انبار نوسا. 

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

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

   

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

     

• فیلد "شناسه‌ی منحصر به فرد صورت‌حساب در سامانه‌ی مودیان" از ترکیب شناسه‌ی حافظه‌ی مالیاتی، تاریخ، سریال و یک رقم کنترلی در انتها تشکیل می‌شود. سریال عددی است که برای هر حافظه‌ی مالیاتی توسط سیستم ایجاد و پیگیری می‌شود و به صورت hexadecimal (بازنمایی عدد در مبنای 16) در شناسه‌ی منحصر به فرد قرار می‌گیرد. مثلا در شناسه‌ی منحصر به فرد A111DW04E8300004349008 شناسه‌ی حافظه‌ی مالیاتی A111DW است، 04E83 نوعی از بازنمایی تاریخ صورت‌حساب است، 0000434900 سریال و 8 رقم کنترلی است.

در ویرایش 1402، در مشخصات برگه‌های فروش، فیلدهای سریال صورت‌حساب در سامانه‌ی مودیان به صورت عدد عادی و hex اضافه شدند و در فرم‌های برگه‌ها و انواع گزارش‌های فروش قابل استفاده هستند. در مثال فوق؛ سریال مزبور (معادل دهدهی عدد مبنای 16) معادل 4409600 خواهد بود. فیلد hex دقیقا همان بخش از شناسه که در بالا به آن اشاره شد را بازنمایی خواهد کرد.

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

   

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

   

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

   

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

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

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

• در تعریف انواع روش‌های صدور اطلاعات دستمزد (اصلی یا رخداد به DBF یا Text) از این پس روش‌های صدور به صورت ثابت برحسب کد مرتب خواهند شد.

   

• در تعریف سطرهای روش‌های صدور اطلاعات دستمزد (اصلی یا رخداد به DBF یا Text) امکان کپی سطر قبل (Alt+Enter) فراهم شده است. از آنجا که ماهیت این فرم به گونه‌ای است که مکان‌نمای جدول در سطر خالی انتهایی قرار نمی‌گیرد (و هر سطر جدیدی همیشه در انتها بازنمایی می‌شود) کپی سطر قبل برای آخرین سطر از جدول قابل استفاده نیست. به همین دلیل امکان جدیدی تحت عنوان "تکرار (کپی) سطر آخر – Ctrl+Enter" نیز در این فرم‌ها تعبیه شده است.

   

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

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

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

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

                 o شرح برگه‌ی هزینه

                 o شرح دیگر (لاتین)

                 o یادداشت

                 o شماره فاکتور

                 o تاریخ فاکتور

                 o اطلاعات مشتری متفرقه (نام، نشانی، کدپستی، شماره ثبت، محل جغرافیایی، کد اقتصادی، شناسه ملی)

                 o شماره و تاریخ عطف و ارجاع

                 o طرف معامله‌ی خارجی که در ایران اقامت و فعالیت اقتصادی ندارد

                 o معامله از طریق حق‌العملکار (دارایی 96)

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

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

   

• عمومی: در تعریف فرم‌ها، تعریف ستون‌های حاوی نماهای جدول پیشرفته، استفاده از فیلدهای rich text (مثل یادداشت حساب یا تفصیلی) ممنوع است. این ممنوعیت در تعریف ستون با Drag / Drop فیلد کنترل شده بود ولی در تدوین مشخصات ستون (انتخاب فیلد محتوی) لحاظ نشده بود. این کنترل اضافه گردید.

   

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

   

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

   

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

   

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

   

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

   

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

   

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

   

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

پایان

-- گروه توسعه نرم‌افزارهای مالی نوسا
   تیر ماه سال 1404