انجمن‌ها

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

 

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

 

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

 

در این مستند، به توصیف امکانات پیاده‌سازی شده در این ابزار جدید و تغییراتی که در سیستم فروش به عمل آورده‌ایم خواهیم پرداخت. در این مسیر، در بخش مقدمه به سوابق قانونی و دستورالعمل‌ها و وظایف جدیدی که برای مودیان لحاظ شده‌اند می‌پردازیم. در ادامه، در یک بخش، به مفاهیم جدیدی که در این رابطه در سیستم فروش نوسا معرفی و پیاده‌سازی شده‌اند خواهیم پرداخت. سیر عملیاتی که باید برروی برگه‌های فروش انجام شوند و انواع و وضعیت‌های فاکتور فروش در همین رابطه را در یک بخش اختصاصی توضیح خواهیم داد. انجام عملیات مزبور، نیازمند تغییراتی در داده‌های پایه و مشخصات برگه‌های فروش بودند که در یک بخش جداگانه به آنها نیز پرداخته‌ایم. جهت ساده سازی مفاهیم، عموم مفاهیم مهم در این مستند همراه با ویدیوهای آموزشی ارائه گردیده و همچنین بخشی در سایت نوسا جهت ارائه کلیات این موضوع به آدرس go.nosa.com/sm آماده شده تا با بروزرسانی قوانین، زیرساخت‌های سازمان و نرم‌افزارهای نوسا، مشتریان نوسا همواره با آخرین تغییرات در رابطه با این سامانه بروز باشند.

 

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

 

 

 

تاریخچه و اطلاعات کلی در رابطه با قانون پایانه های فروشگاهی و سامانه مودیان

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

 

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

 

• "اخذ سند (صورت‌حساب) برای کلیه کالا و خدمات خریداری شده به شکل یک امر مرسوم و متداول و قابلیت پیگیری مستند در خصوص مبالغ پرداخت شده بابت کالا و خدمات."

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

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

• "قابلیت رصد و کنترل نظام توزیع کالا با هدف جلوگیری از احتکار."

 

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

 

• "ثبت نام و عضویت در سامانه مودیان"

• "تهیه و استفاده از پایانه‌های فروشگاهی"

• "صدور صورت‌حساب‌های الکترونیکی در ازای فروش کالا / خدمات و ارائه صورت‌حساب به خریدار"

• "ارسال اطلاعات صورت‌حساب‌های الکترونیکی صادره به سامانه مودیان"

 

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

 

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

• مفاهیم جدیدی مانند حافظه مالیاتی را در سیستم معرفی و پیاده‌سازی گردید.

• تغییراتی در تعریف اطلاعات پایه و برگه‌های فروش در سیستم نوسا اعمال گردید.

• رویه‌هایی برای ارسال و استعلام صورت‌حساب‌ها در سیستم پیاده‌سازی گردید.

 

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

 

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

 

زمان بندی محور‌های اصلی این ویدیو:

1. تعاریف کلی، ماده یک قانون و تعریف حافظه مالیاتی 00:00:56

2. نگاهی اولیه به ابزار نوسا جهت ارسال مستقیم اطلاعات به سامانه مودیان 01:14:25

3. تکلیف مودیان و فرآیند کلی اجرایی قانون پایانه‌های فروشگاهی و سامانه مودیان 1:26:24

4. جریمه‌ها، مشوق‌ها و الزامات قانون پایانه‌های فروشگاهی و سامانه مودیان 1:52:06

 

 

 

 

مفاهیم جدید نوسا در رابطه با حافظه مالیاتی سامانه مودیان

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

 

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

 

 

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

 

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

 

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

 

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

 

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

 

• دریافت زوج کلید از نوسا (به صورت دو فایل متنی)

• ثبت نام در سامانه مودیان و بارگزاری فایل حاوی کلید عمومی و دریافت شناسه‌ی حافظه مالیاتی

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

• ارتباط دادن بخش‌ها به حافظه‌ی مالیاتی

 

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

 

زمان بندی محور‌های اصلی این ویدیو:

1. ثبت نام در کارپوشه مودیان سازمان مالیات 00:00:07

2. اتصال نرم‌افزار فروش نوسا به سامانه مودیان و شناسایی کلید امنیتی 00:05:16

3. فراخوانی روش‌های ارسال اطلاعات مستقیم از ابزار سامانه مودیان نوسا 00:08:00

 

 

 

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

 

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

 

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

 

 

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

 

 

 

 

استعلام کارکرد حافظه مالیاتی و کد اقتصادی از سامانه مودیان

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

 

 

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

 

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

 

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

 

در این ویدیو نحوه تنظیمات اتصال مستقیم حافظه مالیاتی و تست کارکرد صحیح آن در نرم افزارهای نوسا جهت ثبت داده فروش در کارپوشه سامانه مودیان بصورت آنلاین طی زیرساخت موجود سازمان مالیات در سایت tax.gov.ir و قانون پایانه های فروشگاهی و سامانه مودیان در فروردین 1402 آموزش داده خواهد شد:

 

زمان بندی محور‌های اصلی این ویدیو:

1. تنظیمات حافظه مالیاتی در نرم افزار نوسا 00:00:34

2. نحوه استعلام کارکرد صحیح حافظه مالیاتی 00:03:22

3. کنترل روش های ارسال اطلاعات به کارپوشه سامانه مودیان 00:05:38

 

 

 

 

روش‌های ارسال اطلاعات به سامانه مودیان

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

 

1. برخی از فیلدهایی که در JSON مورد نیاز هستند مثل کدهای جدید واحد‌های مقدار یا نوع ارز و شناسه‌ی کالا / خدمت به تازگی در سیستم نوسا تعبیه شده‌اند. اما ممکن است کاربران از قبل همین فیلدها را به صورتی در داده‌های نوسا تامین کرده باشند، مثلا کد واحد مقدار در سامانه مودیان را به عنوان کد واحد مقدار وارد کرده باشند یا کد ISO 4217 انواع ارز را به عنوان علامت اختصاری ارز درج کرده باشند یا شناسه‌ی کالا / خدمت را به عنوان کد میله‌ای یا شماره فنی وارد کرده باشند. برای اینکه کاربران در این شرایط نیاز به اصلاح داده‌های خود نداشته باشند، روش ارسال را قابل تعریف کرده‌ایم تا کاربران بتوانند در شرایط فوق فیلد مبداء را تغییر دهند و مثلا به جای شناسه‌ی کالا / خدمت از کد میله‌ای یا شماره‌ی فنی استفاده کنند.

 

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

 

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

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

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

 

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

 

 

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

 

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

 

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

 

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

 

• یکی از فیلدهای موجود در نرم‌افزار

• مقدار ثابت (عدد)

• مقدار ثابت (رشته)

• مقدار ثابت (منطقی)

• خالی (null)

 

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

 

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

 

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

 

 

تغییرات سرور 12.02 نر‌م‌افزار یکپارچه مالی نوسا جهت بروز‌ررسانی امکانات با نسخه 6.3 سامانه مودیان (اردیبهشت 1402)

همانطور که انتظار می‌رفت، اولین بروزرسانی ساختار سامانه مودیان با تیتر فروردین 1402 در اردیبهشت ماه سال 1402 ارائه  گردید، برخی تغییرات در نسخه 6.3 API سامانه مودیان مستند شده در این مستند با توجه به انعطاف ابزار موجود نوسا، نیازی به تغییر نداشته، برخی اصلاحات از قبل قابل انتظار بوده و در ابزار نوسا پیش‌بینی شده و برخی از دیگر تغییرات، شرکت را ملزم داشته تا نسخه جدیدی از سرور نسخه 12.02 را ارائه نماید.

 

 

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

 

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

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

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

• تاریخ کوتاژ صادراتی در نسخه 6.3 سامانه تعیین تکلیف شد و به صورت صحیح ارسال می‌شود.

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

 

 

برخی محدودیت‌ها و نکات مهم در رابطه با نسخه فعلی ابزار ارائه شده، وضعیت سامانه مودیان، روش ارسال و فیلدهای مربوطه:

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

• شماره‌ی ذکر شده در ستون ردیف، به شماره‌ی فیلدها در مستند «دستورالعمل صدور صورت‌حساب الکترونیکی» اشاره دارد.نسخه مستند مذکور، نسخه‌ی 6.2 به تاریخ دی 1401 (که عملا در میانه‌ی بهمن ماه منتشر شده است) استفاده شده. این مستند توسط مرکز تنظیم مقررات، نظام پایانه‌های فروشگاهی و سامانه مودیان ارائه شده است.  این نسخه در اردیبهست 1402 به نسخه 6.3 ارتقا یافت، عموم اطلاعات ردیف‌ها همچنان یکسان می‌باشند. 

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

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

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

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

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

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

• مالیات ماده 17 را پشتیبانی نمی‌کنیم.

• سایر وجوه قانونی (موضوع، نرخ و مبلغ) را پشتیانی نمی‌کنیم.

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

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

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

• مبلغ پرداخت نقدی از عوارض قانونی در header و سهم نقدی از عوارض قانونی در body قاعدتا باید در JSON لحاظ می‌شدند (با توجه به شباهت آنها با مالیات بر ارزش افزوده). این دو فیلد در فهرست فیلدهای مبداء نوسا لحاظ شده‌اند تا چنانچه در آینده مورد نیاز باشند مشکلی نداشته باشیم.

• از آنجا  که سامانه مودیان بر مبنای وب سرویس بر بستر وب پیاده سازی گردیده، در زمان ارسال اطلاعات به سامانه مودیان و یا استفاده از هرگونه استعلام موجود در ابزار نوسا، دسترسی به اینترنت و IP سامانه سازمان امور مالیاتی توسط سرور نوسا الزامیست. 

• جهت کارکرد این ابزار، زمان و تاریخ سرور باید درست تنظیم شده باشد، در غیر اینصورت در زمان کنترل کلید امنیتی با سامانه با مشکل مواجه خواهیم شد.

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

• در نسخه فعلی سامانه مودیان، مبلغ مالیات بر ارزش افزوده و درصد آن باید برای هر یک از سطرهای فاکتور به سامانه ارسال شود. در زمان آزمایش صحت اطلاعات،  عمل Round در کنترل سامانه در نسخه فعلی انجام نمی‌گردد و در مواردی خطا می‌گیرند. مثلا اگر بهای یک سطر 56711 ریال باشد، 9 درصد آن 5103/99 ریال می‌شود که "طبیعتا" باید 5104 لحاظ شود. این محاسبه در سامانه‌ی مودیان خطا می‌دهد و عدد 5103 انتظار دارد، این مشکل به سازمان اطلاع رسانی شده و تا زمان اصلاح، اصلاح دستی فاکتور قبل از ارسال تنها راه حل منطقی می‌باشد. 

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

ابزار جدید قابل تهیه در نسخه 12.02: ابزار اتصال نرم‌افزار فروش به سامانه مودیان (برخی قابلیت‌ها و فیلد‌های جدید در نرم‌افزار مالی نوسا)

 

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

 

زمان بندی محور‌های اصلی این ویدیو:

1. فعال سازی ارتباط حافظه مالیاتی به نرم افزار فروش 00:00:30

1. فیلد اجباری کالاها و خدمات در نرم افزار فروش نوسا 00:02:04

1. واحد های مقدار و کدهای استاندارد جدید آن 00:03:23

1. کد استاندارد ISO4217 برای استفاده از ارزهای گوناگون 00:04:12

 

 

 

 

نوع شرکت (سازمان) در دفتر تلفن و نشانی

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

 

 

 

شناسه‌ی کالا / خدمت

همه‌ی کالاها و خدماتی که در صورت‌حساب‌ها درج شده و به سامانه مودیان ارسال می‌شوند باید شناسه‌ی استاندارد داشته باشند. فایل اکسل آخرین نسخه از شناسه کالا و خدمات عمومی از سایت سازمان امور مالیاتی به آدرس stuffid.tax.gov.ir قابل دریافت بوده و همچنین جهت دریافت شناسه کالا اختصاصی مراجعه به سایت سامانه جامع تجارت به آدرس www.ntsw.ir در دسترس می‌باشد. در صورت نیاز به دریافت شناسه کالا اختصاصی در این سایت ثبت نام نموده و سپس مراحل را طی نمایید، ویدیو آموزشی ارائه شده توسط این سامانه واقع در آپارات صرفا جهت همکاری با مودیان در دسترس قرار گرفته، لطفا در صورت نیاز به آشنایی بیشتر با نحوه ثبت شناسه کالا و خدمات اختصاصی با پشتیبانی این سامانه تماس حاصل فرمایید.

 

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

 

 

 

 

مشخصات سیستم اطلاعاتی

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

 

 

 

 

روش‌های پرداخت و درصد نسیه در سامانه مودیان

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

 

33) روش تسویه: یکی از حالت‌های 1 نقدی، 2 نسیه و 3 نقدی نسیه.

34) مبلغ پرداختی نقدی: این، جمع مبلغ پرداخت نقدی از بهای کالاها و خدمات صورت‌حساب (بدون احتساب مالیات و عوارض) است.

35) مبلغ نسیه: میزان باقیمانده و پرداخت نشده‌ی جمع بهای کالاها و خدمات صورت‌حساب است.

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

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

65) سهم مالیات بر ارزش افزوده از پرداخت: در هر سطر میزانی از مالیات بر ارزش افزوده‌ای است که به صورت نقدی پرداخت شده است.

 

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

 

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

 

فیلدهای اجباری فوق، همگی با استفاده از درصد نسیه در پرداخت به صورت خودکار محاسبه و در JSON درج می‌شوند. اگر درصد نسیه صفر باشد، روش تسویه، نقدی (1) خواهد بود، اگر 100 باشد روش تسویه، نسیه (2) خواهد بود و هر مقدار دیگری منجر به روش تسویه‌ی نقدی / نسیه (3) خواهد شد. مبالغ پرداختی نقدی (از کل و مالیات و سطر و...) و همچنین مبلغ نسیه نیز با همین درصد نسبت به مبالغ مندرج در سطرهای فاکتور محاسبه می‌شوند. دو نکته قابل تذکر است:

 

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

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

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

 

 

 

واحد‌های پول (ارز)

در دستورالعمل صدور صورت‌حساب الکترونیکی، فیلدی به نام cut در هر یک از اقلام فاکتور (اجزاء body) با عنوان "نوع ارز" تعریف شده است. گفته شده که "شامل انواع پول رایج کشورهای مختلف می‌باشد." و در ادامه ذکر شده که باید حاوی کد ISO 4217  باشد. همانجا، در پانویس، صفحه‌ی فارسی "کد ISO 4217 – فهرست یکای پول رایج کشورها" لینک شده است. فهرست کامل‌تر کدهای مورد اشاره از لینک زیر نیز قابل حصول است:  https://en.wikipedia.org/wiki/ISO_4217

 

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

 

 

واحد‌های مقدار

در دستورالعمل صدور صورت‌حساب الکترونیکی، فیلدی به نام mu در هر یک از اقلام فروش (اجزاء body) با عنوان "واحد اندازه‌گیری" تعریف شده است. گفته شده که "معیاری برای اندازه‌گیری مقدار یا شمارش کالا/خدمت است." و در ادامه ذکر شده که "واحد اندازه‌گیری می‌بایست از کدهای جدول واحدهای اندازه‌گیری در سند واحدهای اندازه‌گیری کالا/خدمت استخراج و ثبت شود". سند مورد اشاره فقط یک جدول دارد که آنرا عینا مطابق آنچه در ویرایش RC_UMGS.ST_V1.3 (27 اسفند 1401) مستند سامانه مودیان در سایت intamedia.ir آمده است ارائه کردیم:

 

 

 

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

 

 

برخی از فیلدهای جدید در برگه‌های فروش

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

 

 

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

 

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

 

 

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

 

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

 

 

 

 

برخی از فیلدهای جدید در سطرهای اصلی برگه‌های فروش

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

 

 

 

 

برخی از فیلدهای جدید در فاکتور‌های باطل شده

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

 

 

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

 

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

 

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

 

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

 

فروش عادی                                                               (نوع 1 الگوی 1)

فروش ارزی                                                                (نوع 1 الگوی 2)

قرارداد پیمانکاری                                                        (نوع 1 الگوی 4)

صادرات                                                                     (نوع 1 الگوی 7)

فروش به مصرف‌کننده نهایی                                       (نوع 2 الگوی 1)

 

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

 

 

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

 

زمان بندی محور‌های اصلی این ویدیو:

1. فرم محاوره فاکتور فروش برای سامانه مودیان 00:00:24

2. نکات مهم در رابطه با ثبت فاکتورهای فروش برای سامانه مودیان 00:01:57

3. نحوه ارسال صورتحساب به سامانه مودیان 00:08:20

4. نحوه استعلام صحت صورتحساب از سامانه مودیان و رفع خطاها 00:12:41

5. برخی فیلدهای سیستمی اطلاعات سامانه مودیان 00:15:04

6. اصلاح فاکتور فروش پس از ارسال به سامانه مودیان 00:17:16

7. حذف و یا ابطال صورتحساب ارسال شده به سامانه مودیان 00:24:01

 

 

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

 

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

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

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

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

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

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

 

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

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

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

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

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

• در انتظار استعلام اصلاحی: صورت‌حساب، پس از ارسال به عنوان اصلاحی، در این وضعیت قرار می‌گیرد و طبیعتا باید بعدا استعلام شود.

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

• در انتظار استعلام ابطالی: صورت‌حساب، پس از ارسال به عنوان ابطالی در این وضعیت قرار می‌گیرد.

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

 

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

 

 

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

 

 

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

 

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

 

زمان بندی محور‌های اصلی این ویدیو:

1. وضعیت ها و عملیات مجاز صورتحساب ها برای سامانه مودیان 00:00:22

1. برخی از پارامترهای جدید در گزارش های فروش برای سامانه مودیان 00:06:42

 

 

 

 

محدودیت‌های ناشی از وضعیت صورت‌حساب در عملیات عادی سیستم فروش (اصلاح و حذف یا ابطال برگه‌های فروش)

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

 

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

 

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

 

 

 

مراحل تنظیم فاکتور فروش

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

 

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

 

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

 

 

 

 

تغییر حافظه مالیاتی

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

 

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

 

 

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

 

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

 

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

 

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

 

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

 

 

 

صورت‌حساب اصلاحی

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

 

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

 

 

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

 

 

فیلدهایی که در این وضعیت محدودیت خواهند داشت و اصلاح آنها میسر نخواهد بود را یادآوری می‌کنیم:

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

 

 

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

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

 

 

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

 

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

 

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

 

 

ارسال و استعلام صورت‌حساب‌ها

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

 

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

 

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

ملاحظات مربوط به فعالیت همزمان کاربران

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

 

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

 

 

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

 

 

 

 

ملاحظات مربوط به فعالیت همزمان کاربران

در حذف و ابطال عادی برگه‌های فروش، طبیعی است که محدودیت زیر را داشته باشیم:

 

 

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

 

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

 

 

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

 

 

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

 

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

 

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

 

 

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

 

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

 

 

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

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

 

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

 

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

 

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

 

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

 

 

 

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

 

 

 

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

 

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

 

 

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

 

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

 

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

 

 

 

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

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

 

 

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

 

 

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

 

 

 

فرمت‌های جدید قابل پشتیبانی در فیلدهای تصویر

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

 

 

 

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

 

تعیین یکباره طرف حساب اختصاصی در فهرست رخدادهای انبار

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

 

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

 

 

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

 

 

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

 

 

 

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

 

جستجوی بلادرنگ در فیلد‌های تعیین تحویل‌گیرنده و بازدید عینی در رخدادهای دارایی‌ها

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

 

 

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

 

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

 

 

 

پیشنهاد پلاک اموال جدید برای دارایی‌ها بصورت داینامیک

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

 

در همه‌ی این کاربردها سیستم می‌تواند پلاک اموال جدیدی را پیشنهاد نماید. این کار با Ctrl+Enter در همان دریچه‌ای که از قبل برای پلاک اموال تعبیه شده بود قابل انجام است. محاوره‌ای به شکل زیر بازنمایی خواهد شد:

 

 

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

 

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

 

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

 

 

 

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

 

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

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

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

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

 

 

-- پایان

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

تغییرات سرور 12.02 نر‌م‌افزار یکپارچه مالی نوسا جهت بروز‌رسانی امکانات با نسخه 6.4 سامانه مودیان (خرداد 1402)

 

همانطور که انتظار می‌رفت، از اردیبهشت ماه سال 1402 چندین تغییر در سامانه انجام گرفت و جهت راحتی استفاده کاربران و عدم نیاز بروزرسانی تمامی کلاینت‌ها، بنا به نیاز چند بار فایل سرور جدید سامانه مودیان نوسا برای مشتریانی که نیاز به تغییرات داشتند ارائه شد.

دومین بروزرسانی اساسی ساختار سامانه مودیان از زمان ارائه نرم‌افزار ابزار نوسا با نسخه 6.4 در خرداد ماه 1402 ارائه شده و از 27 خرداد 1402 اجرایی گردید. برخی تغییرات در نسخه 6.4 API سامانه مودیان ارائه شده در این مستند با توجه به انعطاف ابزار موجود نوسا، نیازی به تغییر نداشته، برخی اصلاحات از قبل قابل انتظار بوده و در ابزار نوسا پیش‌بینی شده و برخی از تغییرات، شرکت را ملزم داشته تا نسخه جدیدی از سرور 12.02 را ارائه نماید. فهرستی از برخی از تغییرات ارائه شده توسط سازمان مالیات به شرح زیر است: 

 

 

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

 

چند نکته مهم در رابطه با نسخه جدید سامانه مودیان ارائه شده توسط سازمان مالیات:

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

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

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

 

با توجه به توضیحات فوق، عموم تغییرات در Build4 نسخه 12.02 ارائه شده با توجه به تغییرات جدید در سامانه مودیان به شرح زیر است:

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

• فیلدهای مبلغ پرداخت نقدی و مبلغ پرداخت نسیه در صورت‌حساب‌هایی که روش تسویه آنها نقدی / نسیه نباشد «باید» پس از نسخه 6.4 بصورت null باشند. در سیستم ما، به این معنی است که اگر درصد نسیه در پرداخت صفر یا 100 باشد، این دو فیلد نباید صادر شوند. تغییر لازم را در سیستم اعمال کردیم.

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

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

 

وضعیت های فعلی در آخرین تغییرات سامانه با توجه به تست های مرداد ماه سال 1402 نوسا:

 

1. اصلاح صورتحساب اصلی: 

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

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

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

 

2. ابطال صورتحساب اصلی: 

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

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

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

 

3. اصلاح صورتحساب اصلاحی: 

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

 

4. ابطال صورت حساب اصلاحی: 

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

 

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

1. هنوز تکلیف سامانه با مفهوم مرجع و ارجاعی مشخص نیست.
2. وضعیت تایید و یا رد خریدار در API سامانه موجود نبوده ولیکن در تغییرات جدید، رفتار مرتبط با اصلاح، ابطال و برگشت به این اطلاعات نیاز دارد. 
3. با ترکیب برگشت و اصلاحی و ابطالی و وضعیت تایید خریدار، پیچیدگی این کاموای گره خورده – ترکیب وضعیت‌ها و عملیات – به توان 3 خواهد رسید.
4. با مراجعه به مستندات، کاملا مشخص است که خود سامانه هم اصلا به صورت جدی روی برگشت کار نکرده است.
5. اینکه هم وضعیتِ تحت تاثیر عملیات داریم و هم وضعیت تحت تاثیر سامانه و هم وضعیت تحت تاثیر خریدار و هم انواع صورت‌حساب جداگانه دارای سریال (حتی برای اصلاح یا ابطال) که طبق تعریف فقط وقتی با موفقیت درج می‌شوند که وجودشان بدون دلیل است (مثلا ابطال موفق یا اصلاح تایید شده بلافاصله منجر به ابطال مرجع می‌شوند + ابطال اگر در انتظار واکنش باشد اصولا قابل تایید نخواهد بود + بیش از دو اصلاح میسر نیست +...)

 

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

 

 

 

-- پایان

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