انجمن‌ها

ابزار جدید قابل تهیه در نسخه 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 در دسترس می‌باشد. در صورت نیاز به دریافت شناسه کالا اختصاصی در این سایت ثبت نام نموده و سپس مراحل را طی نمایید، ویدیو آموزشی ارائه شده توسط این سامانه واقع در آپارات صرفا جهت همکاری با مودیان در دسترس قرار گرفته، لطفا در صورت نیاز به آشنایی بیشتر با نحوه ثبت شناسه کالا و خدمات اختصاصی با پشتیبانی این سامانه تماس حاصل فرمایید.

 

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