انجمن‌ها

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

 

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

 

• تمامی شرکت‌ها و اشخاص حقوقی (به استثنای اشخاص حقوقی موضوع ماده 16 قانون مالیات بر ارزش افزوده) از تاریخ 1 مهر ماه 1402

• تمامی صاحبان مشاغل (اشخاص حقیقی) که تا پایان شهریور ماه بیش از 180 میلیارد ریال فروش در سال 1402 داشتند از تاریخ اول دی ماه 1402

• تمامی صاحبان مشاغل (اشخاص حقیقی) که تا پایان آذر ماه بیش از 180 میلیارد ریال فروش در سال 1402 داشتند از تاریخ اول فروردین ماه 1403

• تمامی صاحبان مشاغل (اشخاص حقیقی) که تا پایان اسفند ماه بیش از 180 میلیارد ریال فروش در سال 1402 داشتند از تاریخ اول تیر ماه 1403

 

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

 

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

 

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

 

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

 

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

1. تحلیل زیرساخت سامانه مودیان و بخش‌های آن 00:04:04

2. یکپارچگی ابزار اتصال به سامانه مودیان و نرم‌افزار فروش نوسا 00:11:02

3. نحوه برخورد با اختلالات و محدودیت های زمانی در سامانه مودیان 00:17:03

4. روش ثبت نام و دریافت توکن GICA برای API جدید سامانه مودیان 00:23:14

5. ثبت انواع حافظه مالیاتی، استعلام ها و روش‌ها در نرم افزار نوسا 00:38:54

6. آشنایی اولیه با نحوه دریافت کد کالا یا خدمات عمومی و یا خاص 00:52:20

7. ثبت اطلاعات عمومی فروش مورد نیاز سامانه مودیان در نرم افزار 00:53:46

8. انواع فاکتورها و الگوهای سامانه مودیان قابل استفاده در نوسا 00:58:40

9. شرایط و نحوه ثبت و استعلام فاکتور اصلی سامانه مودیان در نوسا 01:00:56

10. نکات مهم کلی در رابطه با کارکرد ابزار سامانه مودیان یکپارچه نوسا 01:17:39

11. نحوه ثبت و استعلام فاکتور برگشت سامانه مودیان در نوسا 01:19:51

12. نحوه ثبت و استعلام فاکتور اصلاحی و ابطالی سامانه مودیان در نوسا 01:32:17

13. نحوه درخواست افزایش سقف مجاز فروش در سامانه مودیان مالیاتی 01:54:44

14. نوع، وضعیت و فرآیند‌های فروش در نسخه 6.8 سامانه مودیان و ابزار نوسا 01:56:16

15. مفهوم صورتحساب‌های مرجع و ارجاعی و پیچیدگی‌های فعلی سامانه مودیان 02:11:11

16. نحوه ثبت و استعلام فاکتور برگشت کل / ابطال سامانه مودیان در نوسا 02:31:03

17. پیچیدگی‌های فعلی سامانه، موارد خطرناک و مورد توجه جهت اطمینان از سلامت داده 02:40:32

18. نکات خاص و برخی از امکانات جانبی ابزار اتصال به سامانه مودیان یکپارچه نوسا 03:13:02

 

 

 

 

 

 

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

 

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

 

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

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

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

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

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

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

• مالیات ماده 17 در ابزار ارسال اطلاعات به سامانه مودیان نوسا قابل پشتیبانی نمی‌باشد.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

 

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

 

مطالبی که در ادامه آمده‌اند به صورت ضمنی یا صریح از نسخه‌ی اصلاح شده‌ی کتاب «قانون پایانه‌های فروشگاهی و سامانه مودیان در یک نگاه»؛ تیرماه 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

 

 

 

 

 

برخی از تغییرات در سامانه مودیان، API مربوطه و روش کارکرد آن

 

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

 

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

• تیم طراحی و تولید ابزار Web API سازمان مالیات برای ارائه قابلیت ارسال و استعلام صورت‌حساب‌ها توسط تولید کنندگان نرم‌افزارها تا به امروز 3 نسخه از API سامانه مودیان را ارئه داده که البته هر سه نسخه فعلا همچنان قابل استفاده بوده و زمان الزام استفاده کنندگان از نسخه 2 مشخص نیست. نسخه 0 و 1 این ابزار هر دو در نسخه 12.02 ابزار سامانه مودیان نوسا پشتیبانی می‌گردید و نسخه 2 که البته نیاز به کلید دریافتی از مراکز gica داشته و پیچیدگی هایی را بهمراه خواهد داشت در نسخه 12.12 این ابزار به شرح این مستند جهت استفاده در آینده، و در صورت توقف کارکرد نسخه 1 این ابزار در دسترس می‌باشد. 

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

 

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

 

خلاصه برخی از تغییرات مهم نسخه 12.10 ابزار سامانه مودیان نسبت به نسخه 12.02 و DLL های ارائه شده آن طی سال 1402 در ادامه این بخش در دسترس است، توجه داشته باشید این بخش از مستند بیشتر برای کاربرانی که با امکانات قبلی سیستم نوسا در ارسال صورت‌حساب‌ها به سامانه‌ی مودیان آشنایی دارند آماده شده است. مجموعه‌ی تغییرات انجام شده در ویرایش 1210 با توضیحات مختصر و اشاره به بخش حاوی مطالب اصلی ارائه می‌گردد:

 

 

 

نسخه‌ی جدید سامانه‌ی مودیان در 12.10 (که نیازمند گواهی امضا است – V2)

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

 

 

 

 

 

برخی از فیلدهای جدید در برگه‌های فروش ارائه شده در نسخه 12.10

 

 

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

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

 

 

 

آیتم‌های جدید در وضعیت ارسال به سامانه مودیان در نسخه 12.10 

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

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

 

 

 

فرمان‌های جدید ارسال و استعلام در نسخه 12.10

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

 

منوی ارسال و استعلام فاکتور ها در سامانه مودیان نسخه 12.02

 

منوی ارسال و استعلام فاکتور ها در سامانه مودیان نسخه 12.10

 

 

 

تغییرات کلی مکانیزم ارسال و استعلام صورت‌حساب ابطالی در نسخه 12.10

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

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

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

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

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

 

 

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

این نکات به صورت کامل در مبحث اختصاصی روش‌های ارسال توضیح داده شده‌اند.

• امکان ارسال مبالغ به صورت قطع شده

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

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

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

• کد شعبه خریدار در فیلدهای header اضافه شد.

 

 

برخی از سایر تغییرات اساسی در ابزار سامانه مودیان نوسا نسخه 12.10

اکثر این مطالب در فصل «سایر نکات» به ریز توضیح داده شده‌اند:

• در فهرست برگه‌های فروش فرمانی برای بازنمایی JSON ارسالی به سامانه‌ی مودیان تعبیه شده است.

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

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

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

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

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

 

 

 

مفاهیم و تغییرات رمزنگاری نامتقارن (RSA) در سامانه مودیان و نحوه دریافت گواهی برای نسخه 2 API سامانه مودیان

 

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

 

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

 

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

 

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

 

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

 

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

 

 

 

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

 

در پایان این مبحث، چند نکته قابل توجه‌اند:

• نسخه‌ی قبلی سامانه‌ی مودیان (که با کلید عمومی کار می‌کرد و نیازی به گواهی امضا نداشته – V1) هنوز عملیاتی است ولی احتمال بسیار زیادی وجود دارد که در آینده‌ی نزدیک غیرعملیاتی شود و کاربران مجبور به استفاده از نسخه‌ی جدید (که به گواهی امضا نیاز دارد – V2) شوند.

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

• با گذشت بیش از 4 ماه از ارائه‌ی نسخه‌ی V2، هنوز اشکالات زیادی در آن وجود دارد و به همین دلیل، با اینکه سیستم نوسا به صورت کامل برای استفاده از V2 توسعه داده شده است اما به صورت پیش‌فرض از V1 برای کار با سامانه استفاده می‌شود.

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

• در پایان عملیات با gica یک فایل حاوی گواهی الکترونیکی با فرمت crt دریافت می‌شود. این فرمت برای سامانه‌ی مودیان مناسب نیست و باید به فرمت cer تبدیل شود. به این منظور فایل crt دریافت شده از gica را با Double Click باز کنید (محاوره‌ی بازنمایی محتویات در Windows ظاهر می‌شود). در صفحه‌ی Details، تکمه‌ی Copy To File را فشار دهید. یک Export Wizard بازنمایی خواهد شد. در صفحه‌ی دوم این Wizard گزینه‌ی دوم (Base-64 encoded X.509) را انتخاب کنید و در ادامه نام فایل cer را مشخص کنید. فایلی که از این روش حاصل می‌شود برای بارگذاری در سامانه‌ی مودیان و درج در حافظه‌ی مالیاتی در سیستم نوسا مناسب است.

 

 

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

 

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

 

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

 

 

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

 

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

 

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

 

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

 

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

• دریافت فایل گواهی الکترونیکی مبتنی بر CSR ایجاد شده در مرحله‌ی قبل از gica (این مرحله برای استفاده از نسخه‌ی V2 سامانه ضروری است ولی برای استفاده از نسخه‌ی V1 اختیاری است) + تبدیل فایل دریافت شده از gica از فرمت crt به فرمت cer.

• ثبت نام در سامانه مودیان و بارگذاری فایل حاوی گواهی امضای الکترونیکی (cer – برای V2 یا V1) یا کلید عمومی (برای V1) و دریافت شناسه‌ی حافظه مالیاتی

• تعریف حافظه‌ی مالیاتی در سیستم نوسا با شناسه‌ی دریافت شده از سامانه مودیان و بارگذاری فایل حاوی کلید خصوصی و فایل حاوی گواهی امضا (cer – برای V2).

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

 

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

 

 

 

 

 

 

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

 

طی تعریف، صورت‌حساب‌ها توسط API در قالب 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 تا به حال (دی ماه 1402)، بیش از 8 بار تغییر کرده و از این تغییرات 3 مورد پس از آبان ماه 1401، 1 مورد در نیمه‌ی بهمن‌ماه 1401 و 3 مورد در سال 1402 بوده است (زمان زیادی پس از اجبار شرکت‌های بورسی به ارسال صورت‌حساب به سامانه مودیان) به احتمال بسیار بسیار زیاد باز هم تغییر خواهیم داشت و آن تغییرات آتی مستلزم تغییر در سیستم نوسا نیز خواهند بود. با این همه یک احتمال ضعیف هم وجود دارد که تغییرات به صورتی باشند که فقط با اصلاح روش ارسال اطلاعات قابل مدیریت بوده و نیازی به تغییر سیستم نداشته باشیم. حتی اگر چنین نباشد (و مجبور باشیم سیستم را تغییر دهیم) وجود روش ارسال قابل تعریف باعث می‌شود که مشکلی با داده‌هایی که قبلا با روش قدیمی به سامانه مودیان ارسال شده‌اند نداشته باشیم.

 

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

 

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

 

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

 

 

 

بازنویسی اساسی ابزار اتصال نرم‌افزار فروش به سامانه مودیان - بخش دوم: نوع و وضعیت برگه‌های فروش و سیر عملیات مرتبط با سامانه در نرم‌افزار نوسا

 

 

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

 

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

 

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

 

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

 

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

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

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

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

 

در گذشته، الگوی فروش ارز، مربوط به فروش ارزی بود و در ویرایش 12.02 نوسا هم پشتیبانی می‌شد. در یکی از تغییرات سال 1402، فروش ارزی را به فروش ارز تغییر دادند و در همین رابطه ساختار JSON مربوط به این الگو را نیز به صورت اساسی اصلاح کردند. این الگو در ویرایش 1210 نوسا حذف یا غیرفعال شده است.

 

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

 

 

 

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

 

 

 

 

تفکیک صورت‌حساب‌ها در سامانه‌ی مودیان برحسب "موضوع"

 

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

 

 

 

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

 

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

 

اصلاح یک فاکتور فروش

• صورت‌حساب اصلی – فاکتور فروش – مرجع
  • صورت‌حساب اصلاحی – فاکتور فروش اصلاح شده – ارجاعی

 

ابطال یک فاکتور فروش

• صورت‌حساب اصلی – فاکتور فروش – مرجع
  • صورت‌حساب ابطالی – خالی – ارجاعی

 

اصلاح مجدد یک فاکتورفروش

• صورت‌حساب اصلی – فاکتور فروش – مرجع
  • صورت‌حساب اصلاحی اول – فاکتور فروش اصلاح شده (1) – ارجاعی – مرجع
    • صورت‌حساب اصلاحی دوم – فاکتورفروش اصلاح شده – ارجاعی (با مرجع سطر قبل)

 

ابطال اصلاحی یک فاکتور فروش

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

 

ابطال فاکتور فروش پس از اصلاح

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

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

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

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

 

برگشت یک فاکتور فروش

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

 

ابطال صورت‌حساب برگشتی

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

 

ابطال فاکتور فروش پس از برگشت

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

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

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

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

 

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

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

 

برگشت یک فاکتور فروش پس از اصلاح

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

 

برگشت مجدد یک فاکتور فروش

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

 

برگشت مجدد پس از اصلاح برگشت اول

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

 

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

 

 

 

تفکیک صورت‌حساب‌ها در سامانه‌ی مودیان برحسب "واکنش خریدار"

 

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

 

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

1) کارپوشه‌ی خریدار در سامانه‌ی مودیان وجود دارد و عملیاتی است.

2) کارپوشه‌ی خریدار در سامانه‌ی مودیان وجود ندارد – مثلا خریدار مصرف‌کننده‌ی نهایی است یا اصلا فاقد پرونده‌ی مالیاتی یا کارپوشه است.

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

 

 

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

 

 

 

وضعیت برگه‌ی فروش در ارتباط با سامانه (در سیستم نوسا) و عملیات قابل اجرا

 

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

 

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

 

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

 

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

 

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

 

 

 

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

 

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