انجمن‌ها

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

 

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

 

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

 

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

 

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

 

 

 

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

 

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

 

 

 

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

 

در جدول زیر به شرح این وضعیت‌ها می‌پردازیم:

 

 

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

 

 

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

شماره سند فاکتور فروشي که با اينکار ابطال خواهد شد: --- (در کل ---)

شماره/سري ساير صورت‌حساب(هاي) برگشت از فروشي که ابطال خواهند شد:

---/---

---/---

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

 

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

 

 

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

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

 

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

 

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

 

 

 

 

 

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

 

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

 

 

 

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

 

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

 

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

 

 

 

 

 

تاثیر ابزار سامانه مودیان نوسا در مشخصات سیستم اطلاعاتی (Admin)

 

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

 

 

 

 

 

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

 

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

 

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

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

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

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

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

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

 

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

 

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

 

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

 

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

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

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

 

 

 

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

 

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

 

 https://en.wikipedia.org/wiki/ISO_4217

 

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

 

 

 

 

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

 

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

 

 

 

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

 

 

 

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

 

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

 

 

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

 

• تاریخ

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

• مشتری (خریدار)

• برخی از مشخصات مشتری متفرقه (شماره اقتصادی، شناسه ملی، کد پستی)

• کد شعبه فروشنده

• کد شعبه خریدار

• فیلدهای مربوط به فروش صادراتی (پروانه و کوتاژ گمرکی و کد گمرک محل اظهار)

• شناسه یکتای ثبت قرارداد پیمانکاری

• درصد نسیه در پرداخت

• رخداد انبار یا انجام خدمات (و در نتیجه کالا یا خدمت، مقدار اصلی، مقدار و واحد فرعی)

• فروش برحسب واحد فرعی

• وزن خالص

• شناسه یکتای قرارداد حق‌العمل‌کاری

• انواع فیلدهای مربوط بها (و مالیات و عوارض اعم از ریالی یا ارزی)

 

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

 

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

 

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

 

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

 

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

 

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

 

 

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

 

 

 

 

 

 

 

 

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

 

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

 

 

 

 

 

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

 

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

 

 

 

 

 

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

 

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

 

 

 

 

 

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

 

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

 

 

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

 

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

 

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

 

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

 

در استفاده از نسخه‌ی V1 سامانه (بدون گواهی امضا)، خواندن کلید عمومی در اطلاعات نوسا الزامی نیست. فایل حاوی این کلید (***_publickey.pem) باید به درگاه اینترنتی سامانه مودیان معرفی شود. با این همه می‌توانید کلید عمومی را در همین حافظه مالیاتی نیز آرشیو نمایید تا هم به صورت متنی به آن دسترسی داشته باشید و هم در صورت تمایل آنرا در یک فایل pem ذخیره کنید. اما برای استفاده از نسخه‌ی V2 سامانه (با گواهی امضا)، خواندن گواهی امضا در اطلاعات نوسا الزامی است. گفتیم که در پایان عملیات درخواست و دریافت گواهی از gica، فایل حاوی این گواهی باید از سایت gica دریافت شود (و فرمت آن از crt به cer تغییر داده شود) + در کارپوشه‌ی سامانه (بخش عضویت – شناسه‌های مالیاتی) بارگذاری شود. همین فایل cer باید با انتخاب گزینه‌ی "خواندن کلید عمومی یا گواهی امضا از فایل" در حافظه‌ی مالیاتی درج شود (منوی تکمه‌ی "مدیریت کلید خصوصی و کلید عمومی یا گواهی امضا" در محاوره‌ی حافظه مالیاتی در نوسا).

 

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

 

 

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

 

 

 

 

روش پیاده سازی ارتباط بخش‌ها به حافظه‌ی مالیاتی

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

 

 

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

 

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

 

 

 

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

 

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

 

 

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

 

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

 

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

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

 

 

تغییر و بروزرسانی روش‌های ارسال به سامانه مودیان

 

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

 

 

ما رفتار سامانه در کنترل حاصل محاسبات اعشاری با پیش‌فرض قطع کردن را یک اشکال مهم در سامانه‌ی مودیان می‌دانیم. بارها به صورت حضوری و مکتوب این اشکال را به کارگروه مربوط اعلام کرده‌ایم. مستقل از اینکه حاصل محاسبات اعشاری باید گرد شوند یا قطع شوند (که نمونه‌ای ازمحاسبات و توضیح مربوط را در خود محاوره هم آورده‌ایم) مواردی پیش می‌آیند که حاصل باید به جای محاسبات اعشاری، مستقل از روش گرد کردن (یا قطع کردن)، از مانده‌ی عملیات قبلی بدست آید. مثلا اگر همان 3 واحد کالای ذکر شده در شکل فوق را به تدریج برگشت دهیم، در برگشت دو عدد باید 66 ریال لحاظ کنیم و در برگشت آخر باید بدون توجه به عملیات اعشاری و بهای واحد و غیره، یک عدد باقیمانده را به بهای 34 ریال برگشت دهیم – وگرنه مانده‌ی مقدار صفر و مانده‌ی بها یک ریال خواهد شد! طبیعی است که اگر روی حاصل محاسبات اعشاری کنترل صحت بی‌‎مورد وجود داشته باشد حتما با ارسال یک واحد به بهای 34 ریال در سامانه خطا خواهیم داشت. این در حالی است که مجبوریم بهای واحد را کماکان 33333333/33 ارسال کنیم (در سامانه‌ی مودیان، بهای واحد در صورت‌حساب برگشت باید حتما مساوی بهای واحد در فاکتور فروش – یعنی صورت‌حساب مرجع – باشد)

 

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

 

 

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

 

• اطلاعات عمومی صورت‌حساب

• سطرهای صورت‌حساب

•  اطلاعات پرداخت

 

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

 

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

 

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

 

• یکی از فیلدها

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

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

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

• خالی (null)

 

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

 

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

 

 

 

تنظیم فاکتور فروش و صورت‌حساب برگشت از فروش

 

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

 

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

 

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

 

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

 

 

 

 

 

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

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

 

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

 

 

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

 

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

 

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

 

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

 

 

 

 

نیاز به ارسال صورت‌حساب اصلاحی

 

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

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

 

 

 

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

 

 

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

• تاریخ

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

• مشتری (خریدار)

• برخی از مشخصات مشتری متفرقه (شماره اقتصادی، شناسه ملی، کد پستی)

• کد شعبه فروشنده

• کد شعبه خریدار

• فیلدهای مربوط به فروش صادراتی (پروانه و کوتاژ گمرکی و کد گمرک محل اظهار)

• شناسه یکتای ثبت قرارداد پیمانکاری

• درصد نسیه در پرداخت

• رخداد انبار یا انجام خدمات (و در نتیجه کالا یا خدمت، مقدار اصلی، مقدار و واحد فرعی)

• فروش برحسب واحد فرعی

• وزن خالص

• شناسه یکتای قرارداد حق‌العمل‌کاری

• انواع فیلدهای مربوط بها (و مالیات و عوارض اعم از ریالی یا ارزی)

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

 

 

 

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

 

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

 

 

 

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

 

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

 

 

 

ارسال و استعلام صورت‌حساب‌های اصلی (فاکتورهای فروش)

 

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

 

 

 

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

 

 

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