بازنویسی اساسی ابزار اتصال نرم‌افزار فروش به سامانه مودیان - بخش چهارم: شرح استفاده از نرم‌افزار در ارتباط با سامانه مودیان
تغییر و بروزرسانی روش‌های ارسال به سامانه مودیان
تعریف روش‌های ارسال اطلاعات به سامانه مودیان با انتخاب گزینه‌ای به همین نام از منوی سیستم میسر است. برای هر روش ارسال به روال عادی، کد، نام، نام لاتین و یادداشت قابل تعیین است. از آنجا که اسامی مولفه‌های 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 قاعدتا باید حاوی یکی از فیلدهای قابل ارائه توسط سیستم نوسا باشند – که در بیشتر موارد نیز چنین است. اما برای پشتیبانی از حالت‌های خاص و استثنایی گزینه‌های دیگری را نیز به عنوان "نوع محتوی" لحاظ کرده‌ایم:
انتظار داریم که گزینه‌ی "یکی از فیلدها" بیشترین کاربرد را داشته باشد و در ادامه بیشتر در این مورد صحبت خواهیم کرد. در مواردی ممکن است بخواهیم یک مقدار ثابت را در یکی از فیلدهای 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 می‌پردازیم:
پیش از این اشاره کردیم که ارسال و استعلام صورتحسابها (اصلی، اصلاحی، برگشت از فروش، ابطالی) از فهرست برگه‌های فروش انجام می‌شود. تکمه‌ی "عملیات مربوط به سامانه مودیان" در فهرست برگه‌های فروش و منویی که با فشار آن تکمه احضار می‌شود را در شکل زیر مشاهده می‌کنید:
در مورد صورتحسابهای برگشت، اصلاحی و ابطالی در فصل‌های آتی توضیح خواهیم داد. فاکتورهای فروش به عنوان صورتحسابهای اصلی به سامانه ارسال می‌شوند: فاکتورهای فروش مورد نظر از بین سطرهای بازنمایی شده در گزارش انتخاب می‌شوند و فرمان "ارسال صورتحسابهای اصلی" (با انتخاب گزینه‌ی مربوط از منوی فوق) صادر می‌گردد. اگر چند فاکتور فروش به صورت همزمان انتخاب نشده باشند عملیات برروی تک فاکتور فروش تحت مکان‌نما اجرا خواهد شد. در ادامه باید روش ارسال (از بین روش‌هایی که از قبل تعریف شده‌اند) انتخاب شود و پس از آن محاوره‌ای به شکل زیر بازنمایی می‌شود:
با این محاوره در انواع عملیات ارسال مواجه خواهیم شد. در یک متن توصیفی در ابتدای محاوره تعداد صورتحسابهای انتخاب شده به تفکیک وضعیت گزارش می‌شوند. در ارسال اصلی، وضعیت‌های قابل قبول "ارسال نشده" و "اعلام خطا در استعلام اصلی" هستند. البته قبلا کنترل شده است که همه‌ی برگه‌های انتخاب شده حافظه مالیاتی مشترکی داشته باشند و در وضعیت‌های پیش‌گفته قرار داشته باشند. واضح است که اگر پس از ارسال، در استعلام، از سامانه خطا بگیریم قاعدتا باید بتوانیم پس از اصلاحات لازم دوباره همان صورت‌حساب را ارسال کنیم و به همین دلیل است که وضعیت‌های "اعلام خطا در استعلام" نیز برای ارسال قابل قبول هستند.
عملیات ارسال با تکمه‌ی اختصاصی انجام می‌شود. صورتحسابهای انتخاب شده تک به تک و به ترتیب تاریخ و شماره سند (ترتیب پیش‌فرض) ارسال می‌شوند. به ازای هر صورت‌حساب یک شماره‌ی سریال جدید در حافظه مالیاتی تخصیص داده می‌شود و با ترکیب آن سریال با شناسه‌ی حافظه مالیاتی و تاریخ صورت‌حساب، شناسه‌ی منحصر به فرد جدیدی برای صورت‌حساب تشکیل می‌شود. همچنین یک uid نیز ایجاد و به صورت‌حساب نسبت داده می‌شود. اینها در پایان ارسال صورت‌حساب در داده‌های صورت‌حساب در پایگاه اطلاعاتی نوسا نیز ذخیره می‌شوند.
ممکن است در ارسال خطایی پیش بیاید که احتمالا ناشی از مشکلات شبکه یا درست نبودن کلیدها یا گواهی امضا در حافظه مالیاتی و مواردی از این قبیل است. توجه کنید که این خطا به صورت اساسی و کلی با خطاهایی که بعدا از استعلام حاصل می‌شوند متفاوت است. این خطا یعنی موفق به ارسال نشدیم – مثلا شبکه قطع است – و باید پس از رفع مشکل دوباره دقیقا همین صورت‌حساب، بدون اصلاح محتویات، دوباره ارسال شود. به همین دلیل اگر در حین ارسال با خطایی برخورد کنیم، آن خطا صرفا گزارش می‌شود و وضعیت و سایر داده‌های صورت‌حساب در سیستم نوسا تغییری نخواهند کرد. همچنین آخرین سریال صادر شده از یک حافظه مالیاتی، در صورتی که خطایی رخ داده باشد، تغییری نخواهد کرد و همین سریال (و احتمالا شناسه‌ی منحصر به فرد حاصل از آن) مجددا مورد استفاده قرار خواهد گرفت. آخرین نکته‌ی قابل اشاره این است که اگر در حین ارسال تعدادی صورت‌حساب در میانه‌ی راه با خطا مواجه شویم باید عملیات ارسال را متوقف کنیم و خطای ارسال را گزارش دهیم – چرا که اگر از ارسال یک صورت‌حساب صرف‌نظر کنیم و بقیه را صادر کنیم حتما شماره سریال صورتحسابهای ارسالی به ترتیب مناسب نخواهند بود (و مثلا بین‌شان فاصله خواهد افتاد).
اگر در ارسال یک صورت‌حساب خطایی پیش نیاید اولا آخرین سریال صادر شده از حافظه مالیاتی در پایگاه داده‌ها اصلاح می‌شود و ثانیا صورت‌حساب در وضعیت "در انتظار استعلام اصلی" قرار خواهد گرفت. همزمان، شناسه‌ی منحصر به فرد صورت‌حساب، uid و شماره‌ی ارجاع بازگشته از سامانه نیز در صورت‌حساب ذخیره خواهند شد.
صورتحسابهای ارسال شده به سامانه‌ی مودیان بلافاصله پردازش نمی‌شوند و باید وضعیت آنها را پس از ارسال، از سامانه استعلام کنیم. استعلام انواع صورتحسابهای ارسال شده، به همراه هم، از فهرست برگه‌های فروش قابل انجام است. رویه استعلام چنین است: برگه‌های فروش در فهرست انتخاب می‌شوند + فرمان استعلام صادر می‌شود. در ادامه محاوره‌ای به شکل زیر بازنمایی می‌شود:
استعلام (طبیعتا) نیاز به روش ارسال ندارد اما پیغام وضعیت و حافظه‌ی مالیاتی، درست شبیه قبل، در محاوره‌ی استعلام هم وجود دارند. فرمان "استعلام صورتحسابها" عمومی است و برای همه‌ی برگه‌های فروشی که در یکی از وضعیت‌های "در انتظار استعلام" قرار داشته باشند قابل اجرا است. به همین دلیل وضعیت‌های نهایی صورتحسابها در پیغام ابتدایی محاوره در اینجا متنوع‌تر هستند. همانند محاوره‌های قبلی، در اینجا هم نسخه‌ی API قابل تعیین است. در استفاده از نسخه‌ی V2 نکاتی وجود دارند که قبلا توضیح دادیم:
- همانند سایر کاربردهای V2، استعلام با نسخه‌ی V2 فقط در صورتی میسر است که فایل گواهی امضا در حافظه‌ی مالیاتی خوانده شده باشد.
- استعلام صورتحسابها در V2 فقط در یک بازه‌ی زمانی میسر است. محدوده‌ی تاریخ استعلام با توجه به صورتحسابهای انتخاب شده به صورت خودکار توسط سیستم تشخیص داده و در درخواست اعمال می‌شود.
- محدوده‌ی تاریخ مزبور مربوط به تاریخ ارسال صورتحسابها به سامانه است. به یاد داریم که فیلد مناسب برای حفظ این تاریخ را به برگه‌های فروش اضافه کرده‌ایم. این فیلد در زمان ارسال به صورت خودکار مقداردهی می‌شود.
- محدوده‌ی تاریخ مورد بحث نمی‌تواند بزرگتر از یک هفته باشد – یعنی در صورت استعلام گروهی صورتحسابها، فقط برگه‌هایی را می‌توانیم به همراه هم انتخاب و استعلام کنیم که در یک محدوده‌ی یک هفته‌ای به سامانه ارسال شده باشند.
- حتی در صورت ارسال صورت‌حساب با V1 نیز فیلد تاریخ ارسال توسط سیستم مقداردهی می‌شود – یعنی می‌توانیم صورت‌حساب ارسال شده با V1 را بعدا با V2 استعلام کنیم.
- از آنجا که برگه‌های فروش ارسال شده با ویرایش 1202 نوسا فاقد فیلد تاریخ ارسال بوده‌اند، استعلام آنها با V2 در ویرایش 1210 میسر نیست. البته استعلام با V1 مشکلی نخواهد داشت.
استعلام، به صورت پیش‌فرض، با uidای که در ارسال به هر برگه‌ی فروش اختصاص یافته است انجام می‌شود. امکان استعلام با استفاده از شماره‌ی ارجاع دریافتی از سامانه نیز میسر است و دریچه‌ای به همین منظور در محاوره تعبیه شده است. همانطور که در توضیح درج شده در محاوره دیده می‌شود، همیشه پیش از استعلام صورتحسابها 10 ثانیه مکث خواهیم داشت. پس از این مکث، درخواست به سامانه ارسال می‌شود و پاسخ استعلام در همان محاوره به صورت زیر بازنمایی می‌گردد:
درخواست استعلام عملا به سامانه "ارسال" می‌شود که این عمل با یک تکمه‌ی اختصاصی قابل انجام است. حاصل استعلام ممکن است یکی از 3 وضعیت زیر باشد:
- پردازش صورت‌حساب در سامانه مودیان هنوز به انجام نرسیده است
- صورت‌حساب صحیح بوده و خطایی نداشته است
- صورت‌حساب دارای خطا بوده است.
اگر پردازش هنوز انجام نشده باشد هیچ تغییری در صورت‌حساب داده نمی‌شود و صرفا به کاربر اطلاع داده می‌شود تا در آینده دوباره استعلام صورت‌حساب را درخواست نماید. اگر صورت‌حساب صحیح بوده باشد، فیلد "وضعیت صورت‌حساب در سامانه‌ی مودیان" به "اعلام صحت" تبدیل می‌شود. اگر خطایی وجود داشته باشد، فیلد وضعیت، به "اعلام خطا در استعلام اصلی" مقداردهی می‌شود. گفتیم که این صورتحسابها باید پس از رفع خطا دوباره به سامانه ارسال شوند. در هر صورت خطاها و اخطارهای گزارش شده از سامانه، علاوه بر بازنمایی در این محاوره، در فیلدهای متناظر در صورت‌حساب نیز درج خواهند شد. این فیلدها در فرم ویرایش فاکتور فروش، در محاوره‌ی فاکتور و در صفحه‌ی "سامانه مودیان" و همچنین در ناحیه‌ی بازشونده در فهرست برگه‌های فروش (فرم اختصاصی سامانه مودیان) قابل مشاهده خواهند بود. در مثال فوق برخی از فیلدها را نادرست ارسال کرده‌ایم تا نمونه‌ای از اخطارها را مشاهده کنید.
ارسال و استعلام صورت‌حساب برگشت از فروش
جهت سهولت در این ویدیو به ثبت فاکتور فروش برگشتی در سامانه مودیان، شرایط و نحوه دریافت استعلام آن جهت ثبت داده فروش در کارپوشه سامانه مودیان بصورت آنلاین طی زیرساخت موجود سازمان مالیات در سایت tax.gov.ir و قانون پایانه های فروشگاهی و سامانه مودیان در بهمن ماه سال 1402 می‌پردازیم:
مطابق رویه‌های مرسوم (و استاندارد) در عملیات مالی، برگشت از فروش باید به صورت مستقل در یک نظام مالی مستند شود و به صورت مناسب در گزارش‌های مالی افشا گردد. استقلال برگشت از فروش تقریبا در همه‌ی سیستم‌های مکانیزه (و دستی)، به عنوان یک اصل، پذیرفته شده و به همان صورت نیز عمل می‌شود. در سامانه‌ی مبتنی بر TTMS نیز برگشت از فروش‌ها به صورت مستقل گزارش می‌شدند. در سامانه‌ی مودیان مبتنی بر نظام پایانه‌های فروشگاهی، اما، از این رویه‌ی استاندارد تبعیت نشده است و صورتحسابهای برگشت از فروش، با ترتیبات عجیب و غریبی دریافت می‌شوند؛ برای ارسال صورتحسابهای برگشت از فروش به سامانه‌ی مودیان، نباید کالاها و خدمات برگشتی را گزارش کرد، بلکه باید وضعیت جدید فاکتور فروش ارسال شدهی قبلی (پس از برگشت) را به سامانه ارسال نمود. در صورت‌حساب برگشت از فروش باید شناسه‌ی یکتای صورت‌حساب ارسال شدهی قبلی را به عنوان مرجع مشخص نمود. صورت‌حسابی که به عنوان برگشتی به سامانه ارسال می‌شود، پس از تایید خریدار، جایگزین صورت‌حساب ارسال شدهی قبلی می‌گردد (صورت‌حساب قبلی باطل می‌شود):
- اگر فروش مربوط به دوره‌ای باشد که فاکتور فروش آن به سامانه‌ی مودیان ارسال نشده باشد، امکان ارسال برگشت از فروش به سامانه را نخواهیم داشت.
- همچنین، اگر سطرهای یک صورت‌حساب برگشت از فروش در نرم‌افزار مربوط به فاکتورهای فروش متفاوتی باشند.
- در برگشت‌های متعدد برروی یک فاکتور فروش همیشه باید به آخرین برگشت ارسال شده به سامانه (مربوط به همان فاکتور فروش) توجه شود و شناسه‌ی یکتای آخرین برگشت به عنوان مرجع برگشت جدید لحاظ شود.
- برگشت از فروش حتما باید با همان بهای فاکتور ثبت شده باشد.
- اگر تمام مقدار یک کالا برگشت داده شده باشد آن کالا نباید در صورت‌حساب برگشت از فروش ارسال شود. چرا که رخداد برگشت به صورت مستقل به رسمیت شناخته نشده و فقط به وضعیت جدید صورت‌حساب پس از برگشت توجه شده است (سامانه هیچ آماری از برگشت‌ها در اختیار نخواهد داشت).
- اگر تمام مقادیر تمام کالاها برگشت داده شده باشند با یک صورت‌حساب برگشت از فروش خالی مواجه خواهیم شد. از آنجا که سامانه توانایی دریافت صورت‌حساب خالی را ندارد عملا برگشت کل را پشتیبانی نمی‌کند. در مستندات به صراحت گفته شده که در این موارد باید به جای برگشت از فروش، صورت‌حساب ابطالی به سامانه ارسال شود!!! این شیوه به هیچ وجه در یک نرم‌افزار فروش قابل قبول نیست و عملیات برگشت حتما باید به صورت مستقل در پایگاه داده‌ها مستند شده باشند (و به همان صورت باقی بمانند – ابطال یا حذف نشوند).
با عنایت به نکات فوق، و با قطع امید از اینکه عقلا برای خارج کردن سنگ از چاه کمترین تلاشی به خرج دهند، در ویرایش 1210 امکاناتی را برای کار با صورتحسابهای برگشت از فروش فراهم کردیم. تا حد توان سعی کرده‌ایم که کاربر، هر چه کمتر، با پیچیدگی‌های این طرح درخشان درگیر شود. در روشی که پیاده کرده‌ایم، برگه‌های فروش نوسا، از نوع صورت‌حساب برگشت از فروش، به صورت مستقیم به سامانه ارسال می‌شوند. پیش از ارسال، مجموعه‌ای از شرایط در محتویات برگه‌ی فروش بررسی می‌شوند که در ادامه ذکر خواهیم کرد. آنچه به جای هر صورت‌حساب برگشت از فروش به سامانه ارسال می‌شود وضعیت جدید فاکتور فروش مرجع با اعمال اصلاحات قبلی + برگشت‌های قبلی + اصلاحات برگشت‌های قبلی + برگشت جاری است. با این روش، کاربر برگه‌های فروش خود (اعم از فاکتور فروش یا صورت‌حساب برگشت از فروش) را با همان وضعیت‌های آشنای ارسال نشده / در انتظار استعلام اصلی / اعلام صحت / ... خواهد دید و حسب مورد فرمان‌های لازم را صادر خواهد کرد.
ارسال صورت‌حساب برگشت از فروش به سامانه‌ی مودیان در فهرست برگه‌های فروش انجام می‌شود. ارسال صورت‌حساب برگشت از فروش در هر بار فقط برای یک برگه‌ی فروش قابل انجام است. انتخاب گزینه‌ی مربوط از منوی متصل به تکمه‌ی "عملیات مربوط به سامانه مودیان" (شکل زیر) منجر به ارسال صورت‌حساب برگشت از فروش تحت مکان‌نما به سامانه خواهد شد:
شرایط ارسال صورت‌حساب برگشت از فروش به سامانه‌ی مودیان – محتویات برگه‌ی فروش در نوسا
با صدور فرمان ارسال صورت‌حساب برگشت از فروش، سیستم باید وضعیت جدید فاکتور فروش مرجع همان صورت‌حساب برگشت را محاسبه نماید و به سامانه ارسال کند. تشخیص فاکتور فروش مرجع با بررسی رخداد انبار برگشت از فروش یا رخداد برگشت فروش خدمات انجام می‌شود. در برگشت فروش خدمات به رخداد مرجع (رخداد فروش خدمات) توجه می‌شود و همان فاکتور فروشی که رخداد فروش خدمات مرجع در آن درج شده است به عنوان فاکتور فروش مرجع لحاظ می‌شود. در برگشت فروش کالاها با دو نوع رخداد انبار مواجه خواهیم بود: برگشت از فروش دوره‌ی جاری و برگشت از فروش دوره‌ی قبل. در دوره‌ی جاری به رخداد مرجع (رخداد انبار از نوع فروش) توجه می‌شود. در دوره‌ی قبل رخداد مرجع وجود ندارد – این رخدادها باید درخواست برگشت از فروش داشته باشند و این بار به رخداد مرجع درخواست برگشت از فروش (مجددا رخداد انبار از نوع فروش) توجه می‌شود. با مشخص شدن رخداد انبار فروش کالای مرجع، فاکتور فروشی که این مرجع در آن درج شده است به عنوان فاکتور فروش مرجع لحاظ می‌شود.
موفقیت این عملیات پیچیده مستلزم شرایطی است که توسط سیستم کنترل می‌شود و اگر برآورده نشود امکان ارسال صورت‌حساب برگشت از فروش (به عنوان اصلی یا اصلاحی) را نخواهیم داشت. توجه کنید که برگه‌ی برگشت از فروش به صورت سطر به سطر مورد پردازش و بررسی قرار می‌گیرد:
- در تمام سطرهای برگه‌ی برگشت از فروش باید فاکتور فروش مرجع قابل تشخیص باشد. یعنی مثلا در برگشت‌های فروش کالای دوره‌ی قبل درخواست درج شده باشد و رخداد انبار فروش کالا در آن درخواست مرجع شده باشد / رخدادهای فروش کالا یا خدمات مرجع، قبلا فاکتور شده باشند و مواردی از این قبیل.
- همه‌ی سطرهای برگه‌ی برگشت از فروش باید مربوط به یک فاکتور فروش باشند. یعنی فاکتور فروش مرجع در همه‌ی سطرها باید یکسان باشد.
- حافظه‌ی مالیاتی برگه‌ی برگشت از فروش باید با حافظه‌ی مالیاتی فاکتور فروش مرجع یکسان باشد.
- وضعیت ارسال به سامانه‌ی مودیان در فاکتور فروش مرجع باید "اعلام صحت" باشد. یعنی فاکتور فروش قبلا به سامانه ارسال شده و با استعلام تعیین تکلیف شده باشد.
- فاکتور فروش مرجع نباید "نیازمند ارسال اصلاحی" باشد.
- سطرهای برگه‌ی برگشت از فروش باید "هم‌بها با سطر مرجع" باشند. سامانه مودیان تفاوت بهای واحد بین فروش و برگشت را غیرمجاز می‌داند.
- اگر برای همان فاکتور فروش مرجع برگه‌های برگشت از فروش دیگری (به جز برگه‌ای که مشغول ارسال آن هستیم) در سیستم وجود داشته باشد، آن سایر برگه‌های برگشت باید ارسال نشده یا اعلام صحت باشند (و نیازمند ارسال اصلاحی نباشند). یعنی اگر برای یک فاکتور فروش برگه‌های برگشت متعدد داشته باشیم و در حال ارسال یکی از آن برگشت‌ها باشیم، برگه‌های برگشت قبلی باید اعلام صحت شده باشند و برگه‌های برگشت بعدی باید ارسال نشده باشند. البته این احتمال را لحاظ کرده‌ایم که کاربر نخواهد برخی از برگشت‌های قبلی را به سامانه ارسال کند. به همین دلیل در مورد برگه‌های برگشت قبلی صرفا اخطار داده‌ایم اما به هر حال قبلی‌ها هم حداکثر می‌توانند "ارسال نشده" باشند (مثلا در انتظار استعلام یا اعلام خطا نباشند).
- در بند بعدی، در بررسی شرایط ارسال صورت‌حساب برگشت به سامانه‌ی مودیان خواهیم دید که اگر برای فاکتور فروش مرجع، صورت حساب اصلاحی به سامانه ارسال شده باشد، ارسال صورت‌حساب برگشت از فروش فقط در صورتی میسر است که صورت‌حساب اصلاحی مزبور در سامانه‌ی مودیان توسط خریدار (یا سیستم) تایید شده باشد یا در وضعیت عدم نیاز به واکنش باشد (که گفتیم در اکثر کاربردها همانند تایید است). همانطور که پیش از این گفتیم، هیچ روشی برای اینکه سیستم نوسا از وضعیت تایید صورتحسابها در سامانه اطلاع پیدا کند وجود ندارد. به همین دلیل لازم است تا کاربر با مراجعه به کارپوشه‌ی فروشنده در سامانه‌ی مودیان، وضعیت تایید صورت‌حساب اصلاحی مزبور را بررسی کند و اگر تایید شده بود این تایید را با فرمان "تعیین وضعیت تایید صورت‌حساب اصلاحی در سامانه" در فهرست برگه‌های فروش و برای فاکتور فروش مرجع به نرم‌افزار اطلاع دهد.
- گفتیم که اگر قبلا برای فاکتور فروش، یک صورت‌حساب برگشت به سامانه ارسال شده باشد، صورت‌حساب برگشت مزبور به عنوان مرجع برای برگشت جدید لحاظ می‌شود. در بند بعدی خواهیم دید که در این شرایط، صورت‌حساب برگشتی که به عنوان مرجع تشخیص داده می‌شود باید در سامانه‌ی مودیان توسط خریدار (یا سیستم) تایید شده باشد یا در وضعیت عدم نیاز به واکنش باشد. لازم است تا کاربر با مراجعه به کارپوشه‌ی فروشنده در سامانه‌ی مودیان، وضعیت تایید صورت‌حساب برگشتی مزبور را بررسی کند و اگر تایید شده بود این تایید را با فرمان "تعیین وضعیت تایید صورت‌حساب در سامانه" در فهرست برگه‌های فروش و برای آن برگه‌ی برگشت از فروش مرجع به نرم‌افزار اطلاع دهد.
- اگر در همان شرایط بند قبلی، برای برگه‌ی برگشت از فروشی که به عنوان مرجع تشخیص داده شده است، قبلا صورت‌حساب اصلاحی به سامانه ارسال شده باشد، این بار همان صورت‌حساب اصلاحی به عنوان مرجع برای برگشت جدید لحاظ می‌شود. در بند بعدی خواهیم دید که در این شرایط، صورت‌حساب اصلاحی مزبور باید در سامانه‌ی مودیان توسط خریدار (یا سیستم) تایید شده باشد یا در وضعیت عدم نیاز به واکنش باشد. لازم است تا کاربر با مراجعه به کارپوشه‌ی فروشنده در سامانه‌ی مودیان، وضعیت تایید صورت‌حساب اصلاحی مزبور را بررسی کند و اگر تایید شده بود این تایید را با فرمان "تعیین وضعیت تایید صورت‌حساب اصلاحی در سامانه" در فهرست برگه‌های فروش و برای آن برگه‌ی برگشت از فروش مرجع به نرم‌افزار اطلاع دهد.
زنجیره‌ی برگشت و شرایط ارسال از نقطه‌نظر سامانه
همانطور که چند بار اشاره کردیم، ماهیت عجیب صورتحسابهای برگشت از فروش در سامانه‌ی مودیان (اینکه به جای برگشت متعارف، وضعیت جدید صورت‌حساب را دریافت می‌کند) در کنار وضعیت آشفته‌ای که در کل صورتحسابهای ارجاعی (به خصوص اصلاحی) وجود دارد منجر به بروز پدیده‌ای می‌شود که ما آنرا زنجیره‌ی برگشت می‌نامیم. حالت‌های زیر که در فصل نوع و وضعیت برگه‌های فروش / تفکیک برحسب موضوع ذکر شده‌اند را یادآوری می‌کنیم:
برگشت یک فاکتور فروش پس از اصلاح – در این وضعیت، صورت‌حساب اصلاحی، مرجع برگشت خواهد بود:
- صورت‌حساب اصلی – فاکتور فروش – مرجع
- صورت‌حساب اصلاحی – فاکتور فروش اصلاح شده – ارجاعی – مرجع
- صورت‌حساب برگشت از فروش – مانده‌ی فاکتور فروش اصلاح شده پس از برگشت – ارجاعی (با مرجع سطر قبل)
برگشت مجدد یک فاکتور فروش – صورت‌حساب برگشت اول، مرجع برگشت دوم:
- صورت‌حساب اصلی – فاکتور فروش – مرجع
- صورت‌حساب برگشت از فروش اول – مانده‌ی فاکتور فروش پس از برگشت اول – ارجاعی – مرجع
- صورت‌حساب برگشت از فروش دوم – مانده‌ی فاکتورفروش پس از هر دو برگشت – ارجاعی (با مرجع سطر قبل)
برگشت مجدد پس از اصلاح برگشت اول – صورت‌حساب اصلاحی مربوط به برگشت اول، مرجع برگشت دوم:
- صورت‌حساب اصلی – فاکتور فروش – مرجع
- صورت‌حساب برگشت از فروش اول – مانده‌ی فاکتور فروش پس از برگشت اول – ارجاعی – مرجع
- صورت‌حساب اصلاحی – مانده‌ی فاکتور فروش پس از برگشت اول اصلاح شده – ارجاعی (با مرجع سطر قبل) – مرجع
- صورت‌حساب برگشت از فروش دوم – مانده‌ی فاکتور فروش پس از برگشت اول اصلاح شده و برگشت دوم – ارجاعی (با مرجع سطر قبل)
همانطور که مشاهده می‌شود مرجع برگشت حالت‌های متنوعی دارد: صورت‌حساب اصلی (که البته در مثال‌ها نیامده ولی طبیعی‌ترین حالت است) / صورت‌حساب اصلاحی مربوط به یک صورت‌حساب اصلی / صورت‌حساب برگشت / صورت‌حساب اصلاحی مربوط به یک صورت‌حساب برگشت. این زنجیره اهمیت بسیار زیادی دارد و به خصوص در فصل مربوط به صورت‌حساب ابطالی، دوباره به آن بازخواهیم گشت. گفتیم که محاسبه‌ی وضعیت جدید فاکتور فروش (با تاثیر برگشت‌های قبلی و جاری) و همچنین تشخیص شناسه‌ی یکتای صورت‌حسابی که باید به عنوان مرجع لحاظ شود، بدون دخالت کاربر توسط سیستم انجام می‌شود.
اما سامانه‌ی مودیان در پردازش صورتحسابهای ارجاعی از انواع برگشت (و همانطور که در فصل بعد خواهیم دید، اصلاحی) قواعد عجیبی را مد نظر قرار می‌دهد؛ اگر صورت‌حساب مرجع، یک صورت‌حساب اصلی نباشد، مرجع باید در کارپوشه‌ی خریدار در سامانه‌ی مودیان تایید شود یا با مرور زمان در وضعیت تایید سیستمی قرار بگیرد. اگر در API سامانه‌ی مودیان روشی وجود داشت که سیستم نوسا از وضعیت تایید صورتحسابها توسط خریدار (یا سیستم) اطلاع حاصل کند، همانند رویه‌های پیش‌گفته، در اینجا نیز عملیات بدون دخالت کاربر قابل اجرا می‌بودند. اما همانطور که در بند قبل، در توضیح شرایط ارسال مبتنی بر محتویات برگه‌ی برگشت از فروش نوسا گفتیم، وضعیت تایید صورتحسابهای مرجع از نوع برگشت یا اصلاحی باید حسب مورد توسط کاربر بررسی شود و با فرمان‌های مناسب به سیستم اطلاع داده شود.
از طرف دیگر، هر صورت‌حساب فقط می‌تواند یکبار به عنوان مرجع برای صورتحسابهای برگشتی (و اصلاحی و ابطالی) بکار رود. به این معنی که اگر مثلا بخواهیم صورت‌حساب مرجع برگشت را اصلاح کنیم باید قبلا صورت‌حساب برگشتی (ارجاعی) را ابطال نماییم. این ابطال ممکن است نیاز به تایید خریدار نیز داشته باشد – تلاش برای بازکردن این کلاف سردرگم را در فصل مربوط به صورت‌حساب ابطالی ادامه خواهیم داد.
پیش از این اشاره کردیم که اگر تمام اقلام یک فاکتور فروش، به تدریج یا در یک برگه، برگشت شده باشند، سامانه امکان ارسال صورت‌حساب برگشتی را نمی‌دهد. در مستندات سامانه، در کمال آسودگی خیال، دستور داده شده که در این شرایط به جای برگشت از فروش، از ابطال استفاده شود. این محدودیت (و شرط ارسال) را در بند بعدی به تفصیل بررسی خواهیم کرد.
برگشت کامل (ابطال)
جهت سهولت در این ویدیو به ثبت فاکتور فروش برگشت کل / ابطال در سامانه مودیان، شرایط و نحوه دریافت استعلام آن جهت ثبت داده فروش در کارپوشه سامانه مودیان بصورت آنلاین طی زیرساخت موجود سازمان مالیات در سایت tax.gov.ir و قانون پایانه های فروشگاهی و سامانه مودیان در بهمن ماه سال 1402 می‌پردازیم:
برگشت کامل یک فروش انجام شده، یک وضعیت بسیار متداول و معقول است که مجبور شده‌ایم، با توجه به مشخصات کنونی سامانه‌ی مودیان، آنرا یک حالت خاص فرض کنیم و تا حد امکان با پیچیدگی کمتر برای کاربر پیاده‌سازی نماییم. مسیر کلی چنین است سیستم در ارسال یک برگه‌ی برگشت از فروش، حالت برگشت کامل را تشخیص می‌دهد و پیغام تایید اختصاصی زیر را نمایش می‌دهد:
با ثبت اين صورت‌حساب برگشت از فروش، تمامي اقلام فاکتور فروش مرجع برگشت داده شده است. سامانه‌ي موديان، برگشت کل فروش با ثبت صورت‌حساب برگشت از فروش را پشتيباني نمي‌کند. تنها روش براي برگشت کل در سامانه، ابطال صورت‌حساب است. طبيعي است که برگشت با ابطال تفاوت دارد! (اطلاعات کامل فاکتور فروش و برگشت مربوط به آن حتما بايد در سيستم اطلاعاتي حفظ شوند).
با توجه به اين نکات، ما عملا يک صورت‌حساب ابطالي براي سامانه موديان ارسال مي‌کنيم اما صورت‌حساب برگشت از فروش جاري را پس از استعلام در وضعيت اختصاصي "اعلام صحت برگشت کل / ابطال" قرار خواهيم داد. توجه کنيد که با اين کار فاکتور فروش مرجع عملا در سامانه‌ي موديان ابطال خواهد شد. به جاي صورت‌حساب برگشت از فروش جاري نيز يک صورت‌حساب ابطالي به سامانه ارسال خواهد شد. از اين پس هيچ عملياتي با فاکتور فروش و هيچيک از صورت‌حساب‌هاي برگشت از فروش مرتبط با آن قابل انجام نخواهد بود (اصلاح، ابطال، برگشت...).
ادامه‌ي عمليات مستلزم توجه ويژه‌ي کاربر و عکس‌العمل مناسب است.
آيا مايل هستيد که پيش از ادامه‌ي عمليات مجددا محتويات فاکتور فروش، صورت‌حساب برگشت از فروش و احيانا وضعيت کارپوشه در سامانه‌ي موديان را بررسي نماييد؟
تمام نکات در همین پیغام توضیح داده شده‌اند. مهم‌تر از همه، اینکه صورت‌حساب برگشت از فروش، پس از استعلام به وضعیت خاص "اعلام صحت برگشت کل / ابطال" خواهد رفت – به این معنی که کار ما با این صورت‌حساب برگشت از فروش به پایان رسیده است اما این اعلام صحت با موارد قبلی متفاوت است و به معنی برگشت کل است و در سامانه هم ابطال شده است. با این روش می‌توانیم تاثیر برگشت را در سامانه‌ی مودیان به صورت مناسب اعمال کنیم و در سیستم نوسا نیز کماکان فاکتور فروش ابتدایی و همه‌ی برگه‌های برگشت از فروش مربوط به آنرا حفظ کنیم.
ارسال ابطال به جای برگشت در سامانه کار بسیار خطرناکی است – چون خریدار این صورت‌حساب را در کارپوشه‌ی خود به عنوان ابطالی مشاهده می‌کند و بسیار احتمال دارد که آنرا رد کند. اما در سیستم نوسا با ابطال مواجه نیستیم و صرفا یک برگشت از فروش داریم. به همین دلیل رد شدن این ابطال را نمی‌توانیم به نوسا اعلام کنیم. از طرف دیگر برای برگه‌ای که به این صورت به سامانه ارسال شده است دیگر هیچیک از عملیات و رویه‌های مربوط به سامانه‌ی مودیان قابل اجرا نخواهد بود (اصلاح، ابطال، برگشت...).
با توجه به این نکات بوده که پیغام به صورتی تنظیم شده که اگر به اشتباه تایید شود مشکلی ایجاد نکند (ادامه‌ی عملیات و ارسال برگشت کل مستلزم پاسخ منفی – با تکمه‌ی خیر – به این پرسش خواهد بود). آخرین نکته مربوط است به اصلاح یک صورت‌حساب برگشت از فروش، به صورتی که با این اصلاح برگشت کل فروش رخ داده باشد. این وضعیت قابل قبول نیست و با پیغام خطای زیر مواجه خواهد شد:
با اصلاح اين صورت‌حساب برگشت از فروش، تمامي اقلام فاکتور فروش مرجع برگشت داده شده است. سامانه‌ي موديان، برگشت کل فروش با ثبت صورت‌حساب اصلاحي براي يک صورت‌حساب برگشت از فروش را پشتيباني نمي‌کند. لازم است تا صورت‌حساب جاري را به صورتي اصلاح نماييد تا ديگر برگشت کل نباشد و آنگاه اقدام به ارسال صورت‌حساب اصلاحي
نماييد. سپس مي‌توانيد مقدار باقيمانده از برگشت کل را در يک صورت‌حساب برگشت از فروش جديد ثبت و به سامانه ارسال کنيد.
ارسال و استعلام
همانطور که پیش از این اشاره کردیم، ارسال صورتحسابهای برگشت از فروش، در فهرست برگه‌های فروش، با قرار دادن مکان‌نما برروی "یک برگه‌ی برگشت از فروش" و انتخاب گزینه‌ی مربوط از منوی عملیات با سامانه انجام می‌شود. با توجه به درگیری‌ها و پردازش‌های ویژه‌ای که در برگشت مکرر مطرح هستند، برای تفکیک برگه‌های برگشت مربوط به یک فاکتور فروش به جاری، قبلی‌ها و بعدی‌ها، مجبوریم در این ارسال، هر بار فقط یک برگه‌ی فروش را برای اجرای عملیات لحاظ کنیم.
ارسال صورت‌حساب برگشت از فروش برروی برگه‌ی برگشتی که در وضعیت‌های "ارسال نشده" یا "اعلام خطا در استعلام اصلی" باشند قابل اجرا است. اگر ارسال با خطا مواجه نشود، برگه به وضعیت "در انتظار استعلام اصلی" خواهد رفت (وضعیت‌ها مشابه فاکتور فروش هستند). استعلام همه‌ی صورتحسابهای ارسالی به سامانه (در انواع وضعیت‌های در انتظار استعلام) به همراه هم میسر است. در مورد استعلام، البته، نکات مربوط به تاریخ ارسال و محدودیت یک هفته‌ای (که قبلا در ارسال صورتحسابهای اصلی دیده بودیم) در اینجا هم برقرار است.
ممنوعیت‌های برگشت کامل (ابطال)
- اصلاح یک فاکتور فروش یا برگه‌ی برگشت از فروش که به عنوان مرجع در یک صورت‌حساب برگشت از فروش بکار رفته باشد ممنوع است.
- به صورت مشابه، ارسال صورت‌حساب ابطالی برای همان موارد فوق نیز میسر نیست.
- برگه‌ی برگشت از فروش با وضعیت "اعلام صحت برگشت کل / ابطال" قابل اصلاح نخواهد بود.
- به صورت مشابه ابطال چنین برگه‌ای نیز میسر نیست.
- همچنین برگه‌ی برگشت کل شده نمی‌تواند به عنوان مرجع صورت‌حساب دیگری قرار بگیرد.
ارسال و استعلام صورت‌حساب اصلاحی
جهت سهولت در این ویدیو به ثبت فاکتور فروش اصلاحی در سامانه مودیان، شرایط و نحوه دریافت استعلام آن جهت ثبت داده فروش در کارپوشه سامانه مودیان بصورت آنلاین طی زیرساخت موجود سازمان مالیات در سایت tax.gov.ir و قانون پایانه های فروشگاهی و سامانه مودیان در بهمن ماه سال 1402 می‌پردازیم:
گفتیم که اصلاح برگه‌های فروشی که وضعیت ارسال به سامانه در آنها "اعلام صحت" باشد با تشریفاتی همراه است. این برگه‌ها اگر شرایط لازم را داشته باشند، به صورت کامل قابل اصلاح خواهند بود و پس از اصلاح در وضعیت "نیازمند ارسال اصلاحی" قرار خواهند گرفت. اما اگر شرایط مزبور برقرار نباشد اصلاح برگه با محدودیت‌هایی همراه خواهد بود – کاربر تا آنجا اجازه‌ی اصلاح را خواهد داشت که JSON ارسالی به سامانه‌ی مودیان تغییر نکند. موارد زیر منجر به محدودیت در اصلاح برگه خواهند شد.
- کاربر اختيار "اصلاح اطلاعات اصلي صورت‌حساب‌هاي نهايي (اعلام صحت)" را ندارد.
- صورت‌حساب برگشت از فروش به عنوان اعلام برگشت کل به سامانه ارسال شده است.
- به پيغام تاييد اختصاصي اصلاح چنين برگه‌هاي فروشي، پاسخ "خير" داده نشده است.
- اين برگه‌ي فروش به عنوان مرجع يک صورت‌حساب برگشت از فروش به سامانه موديان ارسال شده است.
- اصلاح صورت‌حساب برگشت از فروش ارسال شده به سامانه فقط در صورتي ميسر است که صورت‌حساب برگشت از فروش در سامانه موديان توسط خريدار (يا سيستم) تاييد شده باشد و اين تاييد با فرمان "تعيين وضعيت تاييد صورت‌حساب در سامانه" در فهرست برگه‌هاي فروش به نرم‌افزار اطلاع داده شود.
- براي اين برگه‌ي فروش صورت‌حساب اصلاحي به سامانه ارسال شده است. اصلاح مجدد فقط در شرايط زير ميسر است:
- اصلاح قبلي ابطال شود (با ارسال صورت‌حساب ابطالي برروي همين برگه‌ي فروش).
- صورت‌حساب اصلاحي مربوط در سامانه موديان توسط خريدار (يا سيستم) تاييد شود و اين تاييد با فرمان "تعيين وضعيت تاييد صورت‌حساب اصلاحي در سامانه" در فهرست برگه‌هاي فروش به نرم‌افزار اطلاع داده شود.
برخی از این محدودیت‌ها واضح هستند و پیش از این هم به آنها اشاره کرده‌ایم. در مورد دو آیتم آخر در ادامه‌ی همین فصل توضیح خواهیم داد:
ارسال صورتحسابهای اصلاحی به تفکیک برای فاکتورهای فروش و برگه‌های برگشت از فروش انجام می‌شود. در فهرست برگه‌های فروش، در منوی عملیات با سامانه، گزینه‌ی "ارسال صورتحسابهای اصلاحی" برای فاکتورهای فروش اصلاح شده و "ارسال صورت‌حساب اصلاحی برگشت از فروش" برای یک برگه‌ی برگشت از فروش اصلاح شده بکار می‌روند (ارسال اصلاحی برای برگشت از فروش نیز، همانند ارسال اولیه، هر بار فقط برای یک برگه قابل انجام است). برگه‌های فروشی که در وضعیت‌های "نیازمند ارسال اصلاحی" یا "اعلام خطا در استعلام اصلاحی" قرار داشته باشند قابل ارسال خواهند بود. چنین است که اگر پس از ارسال، در استعلام از سامانه خطا بگیریم قاعدتا باید بتوانیم پس از اصلاحات لازم دوباره همان صورت‌حساب را ارسال کنیم و به همین دلیل است که وضعیت‌های "اعلام خطا در استعلام" نیز برای ارسال قابل قبول هستند.
- روال ارسال بسیار شبیه به ارسال صورتحسابهای اصلی یا برگشت از فروش است که پیش از این بررسی کردیم: برگه‌های فروش در فهرست انتخاب می‌شوند (همه باید مربوط به یک حافظه‌ی مالیاتی و در وضعیت‌های مجاز باشند) + فرمان ارسال صادر می‌شود + روش ارسال انتخاب می‌شود (از بین روش‌هایی که از قبل تعریف شده است – یا پیش‌فرض نوسا). در ادامه محاوره‌ی ارسال مشابه آنچه پیش از این دیدیم بازنمایی می‌شود (این محاوره در انواع عملیات ارسال مشاهده می‌شود).
اگر در ارسال یک صورت‌حساب خطایی پیش نیاید اولا آخرین سریال صادر شده از حافظه مالیاتی در پایگاه داده‌ها اصلاح می‌شود و ثانیا صورت‌حساب در وضعیت "در انتظار استعلام اصلاحی" قرار خواهد گرفت. همزمان، شناسه‌ی منحصر به فرد صورت‌حساب، uid و شماره‌ی ارجاع بازگشته از سامانه نیز در برگه‌ی فروش ذخیره خواهند شد. از ویرایش 1210 به بعد، تاریخ ارسال صورت‌حساب نیز در برگه‌ی فروش حفظ می‌شود. این تاریخ برای استعلام با نسخه‌ی V2 سامانه مورد نیاز است.
- در سامانه‌ی مودیان، صورت‌حساب اصلاحی به صورت یک صورت‌حساب جداگانه (نسبت به صورت‌حساب ابتدایی) دیده شده است و این یعنی شناسه‌ی منحصر به فرد و uid جدیدی برای صورت‌حساب اصلاحی انتظار دارد! عملا چنین است که صورت‌حساب مرجع (فاکتور فروش یا صورت‌حساب برگشت از فروش) ابطال می‌شود و صورت‌حساب اصلاحی جایگزین آن می‌گردد. اما طبیعی است که این رویه در سیستم‌های فروش قابل قبول نیست و اصلاح، قاعدتا با ترکیب ابطال و درج برگه‌ی جدید متفاوت است. ضمن اینکه بحث اصلاح مکرر را نیز داریم که در یک بند جداگانه در ادامه به آن خواهیم پرداخت.
پیاده‌سازی صورت‌حساب اصلاحی در سیستم نوسا، به این صورت است که مشخصات سیستمی صورت‌حساب اصلاحی (شناسه‌ی منحصر به فرد، uid، شماره‌ی ارجاع دریافتی از سامانه و حتی تاریخ ارسال)، پس از ارسال، جایگزین مقادیر اصلی برگه‌ی فروش می‌شوند و در مقابل مقادیری که از قبل در برگه‌ی فروش وجود داشته‌اند به صورت فیلدهای مربوط به "مرجع اصلاح" در برگه‌ی فروش حفظ می‌شوند. به این ترتیب با مراجعه به هر برگه‌ی فروشی که صورت‌حساب اصلاحی برای آن ارسال شده باشد می‌توانیم علاوه بر آخرین مقادیر مشخصات سیستمی، از مشخصات ابتدایی برگه‌ی فروش (پیش از اصلاح) نیز مطلع شویم. در بندهای بعدی خواهیم دید که با این روش می‌توانیم اصلاح مکرر را نیز پشتیبانی کنیم. در مبحث "انصراف از ارسال صورت‌حساب اصلاحی به سامانه" (یکی از مباحث فصل سایر نکات و امکانات) نیز به همین فیلدهای حاوی مشخصات سیستمی مرجع اصلاح خواهیم پرداخت.
وضعیت تایید مرجع
صورت‌حساب اصلاحی، یک صورت‌حساب ارجاعی است – یعنی شناسه‌ی منحصر به فرد یک صورت‌حساب دیگر که قبلا به سامانه ارسال شده است باید به عنوان شناسه‌ی مرجع در آن مشخص شود. اگر مرجع یک فاکتور فروش (صورت‌حساب اصلی) باشد محدودیتی در وضعیت تایید آن (توسط خریدار در کارپوشه‌ی خود) وجود ندارد اما اگر جز این باشد، مرجع مزبور باید حتما توسط خریدار (یا سیستم) تایید شده باشد یا "عدم نیاز به واکنش" باشد. این نکته در اصلاح مکرر فاکتور فروش، اصلاح برگه‌ی برگشت از فروش و اصلاح مکرر برگه‌ی برگشت از فروش قابل توجه است. به جز این، یک صورت‌حساب در هر لحظه می‌تواند فقط مرجع یک صورت‌حساب ارجاعی باشد – یعنی اگر قبلا اصلاح شده باشد یا برگشت داده شده باشد دیگر قابل اصلاح مجدد یا برگشت نخواهد بود. این همان نکته‌ای است که منجر به طرح "زنجیره‌ی برگشت" در فصل قبل شد. در اینجا نیز به صورت مشابه "زنجیره‌ی اصلاح" پیش می‌آید (و حتی از آن فراتر زنجیره‌ی ترکیبی اصلاح – برگشت – اصلاح – برگشت)؛ در ادامه‌ی عملیات با صورتحسابهای ارجاعی، آخرین صورت‌حساب ارجاعی باید به عنوان مرجع برای صورتحسابهای ارجاعی بعدی لحاظ شود.
با توجه به این نکات چنین برداشت می‌شود که اگر یک فاکتور فروش قبلا اصلاح شده باشد، برای اصلاح مجدد، باید صورت‌حساب اصلاحی ارسال شده قبلی را به عنوان مرجع لحاظ کنیم و به همین دلیل بوده که با ارسال اصلاح، مشخصات سیستمی صورت‌حساب اصلاحی (شناسه، uid، شماره ارجاع دریافتی از سامانه و تاریخ ارسال) جایگزین مشخصات سیستمی فاکتور فروش می‌شود تا به صورت خودکار در اصلاحات بعدی، صورت‌حساب اصلاحی به عنوان مرجع لحاظ شود. اما داستان نیاز به تایید مرجع (وقتی مرجع فاکتور فروش – صورت‌حساب اصلی – نیست) باقی می‌ماند. مرجع (در اینجا صورت‌حساب اصلاحی) باید توسط خریدار در کارپوشه‌ی سامانه‌ی مودیان تایید شود. در بخش‌های قبلی دیدیم که چون روشی برای اطلاع از این تایید در API سامانه تعبیه نشده است، این تایید باید توسط کاربر در فهرست برگه‌های فروش با گزینه‌ی "تعیین وضعیت تایید صورت‌حساب اصلاحی در سامانه" به سیستم اطلاع داده شود.
اما چه می‌شود اگر صورت‌حساب اصلاحی تایید نشده باشد یا توسط کاربر "رد" شده باشد. در این وضعیت برای اصلاح مجدد فاکتور فروش لازم است تا صورت‌حساب اصلاحی مزبور باطل شود – یعنی یک صورت‌حساب ابطالی با مرجع صورت‌حساب اصلاحی پیش‌گفته به سامانه ارسال شود. در فصل بعدی (که مربوط به صورتحسابهای ابطالی است) بیشتر در این مورد توضیح خواهیم داد. نکاتی که در مورد اصلاح فاکتور فروش ذکر کردیم، با اندکی اختلاف، در اصلاح برگه‌ی برگشت از فروش نیز صادق هستند. تفاوت در اینجا است که چون خود برگه‌ی برگشت نیز به صورت یک صورت‌حساب ارجاعی (با موضوع برگشت از فروش) به سامانه ارسال می‌شود، اصلاح آن مستلزم تایید صورت‌حساب برگشت توسط خریدار در کارپوشه‌ی سامانه‌ی مودیان است. این تایید باید در فهرست برگه‌های فروش با گزینه‌ی "تعیین وضعیت تایید صورت‌حساب در سامانه" به سیستم اطلاع داده شود. همانطور که در ابتدای این فصل ذکر کردیم، اگر شرایط اصلاح (تایید مرجع + تعقیب زنجیره‌ی اصلاح) برقرار نباشد، سیستم اجازه‌ی اصلاح برگه‌ی فروش به صورتی که "نیازمند ارسال اصلاحی" شود را نمی‌دهد. آخرین نکته، یادآوری وضعیت برگشت کامل است (که در فصل قبلی توضیح دادیم). اصلاح یک برگه‌ی برگشت از فروش به صورتی که منجر به برگشت کلیه اقلام فاکتور فروش مرجع شود ممنوع است و منجر به پیغام خطای زیر می‌شود (تکرار از فصل قبل):
با اصلاح اين صورت‌حساب برگشت از فروش، تمامي اقلام فاکتور فروش مرجع برگشت داده شده است. سامانه‌ي موديان، برگشت کل فروش با ثبت صورت‌حساب اصلاحي براي يک صورت‌حساب برگشت از فروش را پشتيباني نمي‌کند. لازم است تا صورت‌حساب جاري را به صورتي اصلاح نماييد تا ديگر برگشت کل نباشد و آنگاه اقدام به ارسال صورت‌حساب اصلاحي
نماييد. سپس مي‌توانيد مقدار باقيمانده از برگشت کل را در يک صورت‌حساب برگشت از فروش جديد ثبت و به سامانه ارسال کنيد.
ارسال و استعلام صورت‌حساب ابطالی
جهت سهولت در این ویدیو به ثبت فاکتور فروش ابطالی در سامانه مودیان، شرایط و نحوه دریافت استعلام آن جهت ثبت داده فروش در کارپوشه سامانه مودیان بصورت آنلاین طی زیرساخت موجود سازمان مالیات در سایت tax.gov.ir و قانون پایانه های فروشگاهی و سامانه مودیان در بهمن ماه سال 1402 می‌پردازیم:
برگه‌های فروشی که به سامانه‌ی مودیان ارسال شده‌اند، قابل حذف یا ابطال در سیستم نوسا نیستند – مگر اینکه قبلا صورت‌حساب ابطالی مناسب به سامانه ارسال و استعلام شود و اعلام صحت ابطال از سامانه دریافت شود. در غیراینصورت، در حذف یا ابطال با پیغام خطای زیر مواجه خواهیم شد:
حذف يا ابطال برگه فروش فقط در صورتي ميسر است که وضعيت ارسال صورت‌حساب به سامانه موديان، "ارسال نشده" يا "اعلام صحت ابطال" باشد. وضعيت اعلام صحت ابطال با استعلام صورت‌حساب ابطالي در فهرست برگه‌هاي فروش حاصل مي‌شود.
ارسال صورت‌حساب ابطالی با صدور فرمان مناسب (از منوی عملیات با سامانه‌ی مودیان) در فهرست برگه‌های فروش انجام می‌شود. یادآوری می‌کنیم که این منو به صورت زیر (متصل به تکمه‌ی مربوط) احضار می‌شود:
ارسال صورت‌حساب ابطالی به صورت گروهی برای برگه‌های فروش میسر نیست و هر بار باید برای یک برگه (سطر تحت مکان‌نمای فهرست برگه‌های فروش) انجام شود. برگه‌ی انتخاب شده باید تعیین تکلیف شده باشد (در وضعیت اعلام صحت قرار داشته باشد). به صورت استثنایی، اگر برگه‌ای اصلاح شده باشد (و در وضعیت نیازمند ارسال اصلاحی قرار داشته باشد) برای آن برگه نیز می‌توانیم صورت‌حساب ابطالی ارسال کنیم – به این معنی که از ارسال صورت‌حساب اصلاحی برای آن برگه منصرف شده‌ایم و به جای آن می‌خواهیم کل برگه را ابطال کنیم. صورتحسابهای ابطالی ارسال شده در وضعیت "در انتظار استعلام ابطالی" قرار می‌گیرند و باید از سامانه استعلام شوند – یعنی پردازش ابطال نیز بلافاصله پس از ارسال انجام نمی‌شود و به همین دلیل نیاز به استعلام داریم. استعلام صورتحسابهای ابطالی، به همراه سایر صورتحسابهایی که در وضعیت‌های مختلف در انتظار استعلام قرار داشته باشند، با گزینه‌ی "استعلام صورتحسابها" (شکل فوق) انجام می‌شود. طبق معمول، حاصل استعلام ممکن است "اعلام خطا در استعلام ابطالی" باشد. همانند اعلام خطاهای مشابه قبلی، اینها نیز باید (پس از رفع خطا) دوباره به عنوان ابطالی ارسال شوند. پس، ارسال صورت‌حساب ابطالی در برگه‌هایی که در وضعیت "اعلام خطا در استعلام ابطالی" قرار داشته باشند، همانند وضعیت‌های "اعلام صحت" و "نیازمند ارسال اصلاحی" میسر است.
صورت‌حساب ابطالی نیز، همانند موارد مشابه قبلی، به صورت یک JSON به سامانه‌ی مودیان ارسال می‌شود. این JSON البته فاقد سطر (بردار body) است ولی محتویات header آن با همان روش ارسال اطلاعات به سامانه (که برای ارسال صورتحسابهای اصلی، اصلاحی و برگشتی نیز بکار می‌رود) تشکیل می‌شود. به یاد داریم که در سطرهای یک روش ارسال، می‌توانستیم "ارسال در موضوعات" را کنترل کنیم و به این ترتیب مشخص کنیم که در صورتحسابهای ابطالی چه فیلدهایی باید ارسال شوند. در ارسال صورت‌حساب ابطالی، پس از انتخاب روش صدور، محاوره‌ی زیر را خواهیم دید:
وضعیت برگه‌ی فروش به همراه توضیحات متعارف بازنمایی شده‌اند. طبق معمول یک دریچه برای انتخاب نسخه‌ی سامانه نیز تعبیه شده است. در اینجا با یک مفهوم جدید، "تاریخ صورت‌حساب ابطالی" مواجه هستیم. چنین است که سامانه‌ی مودیان در مورد تاریخ صورتحسابها محدودیت دارد و اجازه‌ی ارسال صورت‌حساب به تاریخ‌های قدیم (مثلا از یک ماه پیش به قبل) را نمی‌دهد. مطابق این محدودیت، قاعدتا نباید امکان ابطال صورتحسابهای قدیمی را داشته باشیم. اما از آنجا که صورت‌حساب ابطالی به صورت یک موجودیت مستقل از صورت‌حساب اصلی به سامانه ارسال می‌شود، مشاهده شده که اگر تاریخ این صورت‌حساب ابطالی در محدوده‌ی مجاز قرار داشته باشد، سامانه نسبت به تاریخ صورت‌حساب مرجع حساسیتی از خود نشان نمی‌دهد – یعنی مثلا صورت‌حسابی که در فصل بهار ارسال شده (و قاعدتا در گزارش فصلی مربوط نیز منعکس شده است) را می‌توان با تغییر تاریخ در فصل زمستان ابطال کرد(!!!) و کل نظام گزارش‌دهی (و تجزیه و تحلیل‌هایی که حتما انجام نمی‌شوند) را مخدوش نمود.
واضح است که این رفتار یک اشکال در سامانه است و احتمال می‌دهیم در آینده برطرف شود. اما متاسفانه فشار همه‌جانبه‌ای وجود داشت مبنی بر اینکه از این اشکال سامانه در سیستم بهره‌گیری کنیم و با تغییر تاریخ صورت‌حساب ابطالی امکان ابطال را فراهم کنیم. متعاقب تسلیم ما در برابر این فشارها، فیلد تاریخ صورت‌حساب ابطالی را به برگه‌های فروش اضافه کردیم که کارکرد مشخصی دارد. این تاریخ در همین محاوره تعیین می‌شود و در برگه‌ی فروش نیز ذخیره می‌گردد. اگر این تاریخ تعیین نشده باشد، صورت‌حساب ابطالی به تاریخ برگه‌ی فروش ارسال خواهد شد.
اگر در ارسال صورت‌حساب ابطالی خطایی پیش نیاید اولا آخرین سریال صادر شده از حافظه مالیاتی در پایگاه داده‌ها اصلاح می‌شود و ثانیا صورت‌حساب در وضعیت "در انتظار استعلام ابطالی" قرار خواهد گرفت. همزمان، شناسه‌ی منحصر به فرد صورت‌حساب، uid و شماره‌ی ارجاع بازگشته از سامانه نیز در برگه‌ی فروش ذخیره خواهند شد. از ویرایش 1210 به بعد، تاریخ ارسال صورت‌حساب نیز در برگه‌ی فروش حفظ می‌شود. این تاریخ برای استعلام با نسخه‌ی V2 سامانه مورد نیاز است.
پیاده‌سازی صورت‌حساب ابطالی در سیستم نوسا، به این صورت است که مشخصات سیستمی صورت‌حساب ابطالی (شناسه‌ی منحصر به فرد، uid، شماره‌ی ارجاع دریافتی از سامانه و حتی تاریخ ارسال)، پس از ارسال، جایگزین مقادیر اصلی برگه‌ی فروش می‌شوند و در مقابل مقادیری که از قبل در برگه‌ی فروش وجود داشته‌اند به صورت فیلدهای مربوط به "مرجع ابطال" در برگه‌ی فروش حفظ می‌شوند. به این ترتیب با مراجعه به هر برگه‌ی فروشی که صورت‌حساب ابطالی برای آن ارسال شده باشد می‌توانیم علاوه بر آخرین مقادیر مشخصات سیستمی، از مشخصات ابتدایی برگه‌ی فروش (پیش از ابطال) نیز مطلع شویم. در مباحث "اعلام رد شدن صورت‌حساب ابطالی در سامانه" و "انصراف از ارسال صورت‌حساب ابطالی به سامانه" (فصل سایر نکات و امکانات) نیز به همین فیلدهای حاوی مشخصات سیستمی مرجع ابطال خواهیم پرداخت.
صورتحسابهایی که در وضعیت "در انتظار استعلام ابطالی" قرار داشته باشند، همزمان با سایر صورتحسابهایی که در وضعیت‌های در انتظار استعلام هستند، باید با انتخاب گزینه‌ی "استعلام صورتحسابها" در فهرست برگه‌های فروش استعلام شوند. همان نکات مربوط به تاریخ ارسال و محدوده‌ی یک هفته‌ای که پیش از این گفتیم در اینجا نیز صادق است (اصولا فقط یک روش استعلام برای همه‌ی کاربردها داریم):
اگر خطایی در استعلام گزارش شود، صورت‌حساب به وضعیت "اعلام خطا در استعلام ابطالی" برده می‌شود. گفتیم که این صورتحسابها باید پس از رفع خطا دوباره به سامانه ارسال شوند. در هر صورت خطاها و اخطارهای گزارش شده از سامانه در فیلدهای متناظر در صورت‌حساب درج خواهند شد. اما اگر خطایی وجود نداشته باشد، صورت‌حساب به وضعیت "اعلام صحت ابطال" برده می‌شود. این همان وضعیتی است که حذف یا ابطال برگه‌ی فروش در سیستم نوسا را مجاز می‌کند.
در حذف یا ابطال این برگه‌های فروش، هنوز یک خطر مهم وجود دارد که طبق معمول به رفتار سامانه‌ی مودیان در ارتباط با رفتار خریدار در تایید یا رد صورتحسابها (در کارپوشه‌ی خریدار در سامانه‌ی مودیان) باز می‌گردد: اگر صورت‌حساب مرجع ابطال در وضعیت‌های در انتظار واکنش یا عدم نیاز به واکنش باشد یا اگر خریدار صورت‌حساب مرجع را رد کرده باشد، صورت‌حساب ابطالی بلافاصله در سامانه اعمال می‌شود. در نتیجه خود صورت‌حساب ابطالی در وضعیت "عدم نیاز به واکنش" قرار می‌گیرد و صورت‌حساب مرجع بلافاصله به وضعیت "باطل شده" می‌رود. اما اگر صورت‌حساب مرجع ابطال توسط خریدار (یا سیستم – به مرور زمان) تایید شده باشد، صورت‌حساب ابطالی در وضعیت "در انتظار واکنش" خواهد بود و نیاز به تایید دارد – یعنی تا وقتی خریدار (یا سیستم) آنرا تایید نکرده باشد تاثیری در صورت‌حساب مرجع ایجاد نخواهد کرد. این وضعیت خطرناکی است که در سیستم نوسا، با صدور فرمان‌های حذف یا ابطال برگه‌ی فروش، در پیغامی به صورت زیر به کاربر اطلاع داده می‌شود:
»» توجه: صورت‌حساب ابطالي به سامانه موديان ارسال و اعلام صحت دريافت شده است. با اين وجود ممکن است صورت‌حساب ابطالي در سامانه نياز به تاييد داشته باشد و درانتظار واکنش (يا حتي رد شده باشد). اگر چنين باشد صورت‌حساب مرجع در سامانه‌ي موديان باقي مانده است (ابطال نشده است). متاسفانه هيچ روشي براي تشخيص خودکار اين شرايط در سامانه‌ي موديان تعبيه نشده است و تنها راه اين است که به کارپوشه مراجع کرده و وضعيت صورت‌حساب ابطالي و مرجع را بررسي نماييد. اگر صورت‌حساب ابطالي هنوز تاييد نشده يا رد شده باشد، حذف يا ابطال صورت‌حساب از سيستم نوسا کار نادرستي خواهد بود؛ چرا که صورت‌حساب در سامانه موجود ولي از نوسا حذف خواهد شد.
لطفا فقط در صورتي اين پيغام را تاييد فرماييد که از وضعيت ابطال صورت‌حساب در سامانه‌ي موديان اطمينان داشته باشيد.
آيا ادامه‌ي عمليات را تاييد مي‌کنيد؟
برخی از موارد خاص و خطرناک در سلامت داده فروش سامانه مودیان
جهت سهولت در این ویدیو موارد خاص و خطرناک در فرآیندهای صورتحسابها در نرم افزار نوسا مانند اصلاح در اصلاح، اصلاح برگشت، برگشت اصلاح، ابطال اصلاح و ... در کارپوشه سامانه مودیان بصورت آنلاین طی زیرساخت موجود سازمان مالیات در سایت tax.gov.ir و قانون پایانه های فروشگاهی و سامانه مودیان در بهمن ماه سال 1402 می‌پردازیم:
ابطال برگه‌ی فروش اصلاح شده
یکی از عجیب‌ترین رفتارهای سامانه در ابطال صورتحسابهایی است که قبلا برای آنها صورت‌حساب اصلاحی به سامانه ارسال شده است. برحسب اینکه خریدار (یا سیستم) صورت‌حساب اصلاحی را تایید یا رد کرده باشد (یا در وضعیت در انتظار واکنش باقی گذاشته باشد) رفتار سامانه متفاوت خواهد بود. اولا با توجه به زنجیره‌ی ارجاع و مرجع در صورتحسابها، اگر صورت‌حساب اصلاحی برای یک برگه‌ی فروش ارسال شده باشد، مرجع آن صورت‌حساب اصلاحی خود برگه‌ی فروش خواهد بود و هر صورت‌حساب اصلاحی مرجع صورتحسابهای ارجاعی بعدی (من جمله صورت‌حساب ابطالی). پس، ارسال ابطالی برای برگه‌ی فروش در این وضعیت به معنی ارسال ابطالی برای صورت‌حساب اصلاحی خواهد بود.
قاعدتا انتظار داریم که این عمل منجر به ابطال صورت‌حساب اصلاحی در سامانه بشود – تا متعاقب آن بتوانیم از صورت‌حساب اصلی (فاکتور فروش یا برگه‌ی برگشت از فروش) به عنوان مرجع برای اصلاح، برگشت یا حتی ابطال استفاده کنیم. یعنی مثلا اگر بخواهیم یک فاکتور فروش که قبلا اصلاح شده را ابطال کنیم باید ابتدا برای صورت‌حساب اصلاحی ارسال شده به سامانه ابطالی ارسال کنیم و سپس همین کار را برای صورت‌حساب اصلی (خود فاکتور فروش) انجام دهیم.
در اصلاح مکرر نیز می‌توانیم همین توقع را داشته باشیم: چون ارسال صورت‌حساب اصلاحی دوم (همانطور که در فصل قبل دیدیم) مستلزم تایید صورت‌حساب اصلاحی اول توسط خریدار (یا سیستم) است، تا زمانی که این تایید انجام نشده یا خریدار حاضر یا قادر به تایید نیست، می‌توانیم با ارسال صورت‌حساب ابطالی، آن صورت‌حساب اصلاحی اول را باطل کنیم و سپس نسبت به اصلاح برگه‌ی فروش و ارسال صورت‌حساب اصلاحی جدید اقدام کنیم. پس، ارسال صورت‌حساب ابطالی در این موارد به معنی ابطال صورت‌حساب اصلاحی خواهد بود و تا زمانی که صورت‌حساب اصلاحی تایید نشده باشد یا اگر احیانا توسط خریدار رد شده باشد یک رویه‌ی متعارف و کاربردی در سیستم خواهد بود. پس از تعیین تکلیف این ابطال (با استعلام) صورت‌حساب اصلی (برگه‌ی فروشی که قبلا اصلاح شده بوده است) به وضعیت "نیازمند ارسال اصلاحی" خواهد رفت – چرا که اصلاحاتی که قبلا روی این صورت‌حساب انجام شده و به صورت اصلاحی به سامانه ارسال شده بوده است کماکان در داده‌های برگه اعمال شده و باقی مانده‌اند.
اما اشکال اینجاست که اگر صورت‌حساب اصلاحی توسط خریدار (یا سیستم) تایید شده باشد، همانطور که پیش از این گفته‌ایم، صورت‌حساب مرجع اصلاح در سامانه‌ی مودیان، خود به خود، در وضعیت باطل شده قرار می‌گیرد. در این شرایط اگر اقدام به ارسال صورت‌حساب ابطالی برای آن برگه‌ی فروش نماییم، عملا با ابطال صورت‌حساب اصلاحی تایید شده، کل فروش را باطل کرده‌ایم (چون صورت‌حساب اصلی قبلا توسط خود سامانه باطل شده است). با توجه به این نکات در ارسال صورت‌حساب ابطالی برای برگه‌های فروشی که قبلا در سامانه اصلاح شده‌اند یک پیغام ترسناک به صورت زیر در همان محاوره‌ی ارسال بازنمایی می‌شود (که دو نکته فوق را اطلاع می‌دهد و توجه کاربر را می‌طلبد):
»» توجه: اين صورت‌حساب قبلا اصلاح شده است (صورت‌حساب اصلاحي به سامانه موديان ارسال و اعلام صحت شده است). در اين شرايط، "ابطال" به معني ابطال صورت‌حساب اصلاحي مزبور خواهد بود (نه ابطال صورت‌حساب مرجع).
با پايان عمليات ابطال (پس از استعلام) اين صورت‌حساب به وضعيت "نيازمند ارسال اصلاحي" خواهد رفت (نه وضعيت اعلام صحت ابطال). از آن پس، اصلاح مجدد صورت‌حساب مرجع يا ابطال آن ميسر خواهد بود.
»» توجه (بسيار مهم): اگر صورت‌حساب اصلاحي در سامانه موديان تاييد شده باشد، صورت‌حساب مرجع خود به خود در وضعيت ابطال شده قرار خواهد داشت. متاسفانه هيچ روشي براي اينکه سيستم ما بتواند اين شرايط را تشخيص دهد در سامانه موديان تعبيه نشده است. در اين وضعيت ابطال صورت‌حساب اصلاحي عملا به معني ابطال صورت‌حساب مرجع نيز خواهد بود!!!
لازم است تا با مراجعه به کارپوشه‌ي سامانه‌ي موديان، وضعيت صورت‌حساب اصلاحي و مرجع (اصلي يا برگشت) را بررسي نماييد. اگر صورت‌حساب اصلاحي تاييد شده (و در نتيجه صورت‌حساب مرجع ابطال شده) باشد لازم است تا پيش از ابطال صورت‌حساب، در فهرست برگه‌هاي فروش فرمان "تعيين وضعيت تاييد صورت‌حساب اصلاحي در سامانه" را صادر کنيد و "تاييد شده" بودن صورت‌حساب اصلاحي را اعلام نماييد. با اينکار ابطال صورت‌حساب به معني ابطال صورت‌حساب مرجع خواهد بود - وگرنه يک صورت‌حساب مرجع (اصلي يا برگشت) در سيستم خواهيم داشت که در سامانه‌ي موديان ابطال شده است. ابطال صورت‌حساب ابطال شده در سامانه با خطا مواجه خواهد شد.
همانطور که در متن فوق آمده است، تایید صورت‌حساب اصلاحی توسط خریدار به این معنی است که آن صورت‌حساب عملا جایگزین صورت‌حساب اصلی شده است و به همین دلیل در این وضعیت، ارسال صورت‌حساب اصلاحی به معنی ابطال برگه‌ی فروش تلقی می‌شود و آن برگه‌ی فروش پس از استعلام، در همان وضعیت "اعلام صحت ابطال" که پیش از این دیده بودیم قرار می‌گیرد. پیش از این، در مورد تایید صورت‌حساب اصلاحی و اعلام آن به سیستم (در فهرست برگه‌های فروش) توضیحات کاملی ارائه کرده‌ایم.
ابطال برگه‌ی برگشت از فروش
در فصل "ارسال و استعلام صورت‌حساب برگشت از فروش" در مورد مرجع برگشت، برگشت‌های متعدد روی یک فاکتور فروش و زنجیره‌ی برگشت‌ها توضیح دادیم. ابطال یک برگه‌ی فروش که به عنوان مرجع برای یک صورت‌حساب برگشت از فروش لحاظ شده باشد (طبیعتا) میسر نیست و با خطای زیر مواجه خواهد شد:
برگه‌ي فروش به عنوان مرجع يک برگه‌ي برگشت به سامانه موديان معرفي شده است. ابطال اين برگه‌ي فروش، بدون ابطال صورت‌حساب برگشت از فروش مذکور ميسر نيست.
همانند آنچه در مورد فاکتور فروش گفتیم، حذف یک برگه‌ی برگشت از فروش که در وضعیت‌هایی بجز "ارسال نشده" یا "اعلام صحت ابطال" قرار داشته باشد میسر نیست. ارسال صورت‌حساب ابطالی برای یک برگه‌ی برگشت از فروش نیز شبیه فاکتور فروش انجام می‌شود. همچنین تمام مطالبی که در مورد ابطال صورت‌حساب اصلاحی (در بند قبل) گفتیم در مورد برگه‌ی برگشت از فروش نیز صدق می‌کنند. تفاوت اصلی در زمانی است که برگه‌ی مرجع ابطال (در اینجا صورت‌حساب برگشت از فروش) توسط خریدار (یا سیستم) در سامانه تایید شده باشد. در مورد صورت‌حساب اصلی، دیدیم که تایید مرجع صرفا باعث می‌شد که صورت‌حساب ابطالی بلافاصله در سامانه عمل نکند و نیاز به تایید داشته باشد (در سامانه، در وضعیت "در انتظار واکنش" قرار بگیرد). اما در ابطال صورت‌حساب برگشت از فروش تایید شده با فراز دیگری از این حماسه مواجه هستیم.
ماجرا از آنجا آغاز می‌شود که صورت‌حساب برگشت از فروش خود یک صورت‌حساب ارجاعی است. گفتیم که تایید یک صورت‌حساب ارجاعی توسط خریدار (یا سیستم) در سامانه، خود به خود باعث می‌شود که صورت‌حساب مرجع بلافاصله در وضعیت "باطل شده" قرار بگیرد. این نکته به خصوص در مورد صورتحسابهایی که بیش از یک ماه از ارسال آنها به سامانه گذشته باشد اهمیت زیادی دارد؛ چرا که با گذشت زمان در وضعیت "تایید سیستمی" قرار می‌گیرند. حال چه می‌شود اگر ما اقدام به ارسال ابطالی برای یک برگشت از فروش تایید شده نماییم؟ همانند آنچه در مورد اصلاح گفتیم، در اینجا هم این ابطال اخیر، نه به معنی ابطال برگشت، بلکه به معنی ابطال کل فروش خواهد بود (چون صورت‌حساب اصلی، قبلا، با تایید صورت‌حساب برگشت، خود به خود باطل شده است). توجه کنید که این وضعیت در زنجیره‌ی برگشت‌ها هم پیش می‌آید؛ اگر بیش از یک صورت‌حساب برگشت برای یک فاکتور فروش ارسال شده باشد، یا فاکتور فروش قبلا اصلاح شده باشد، مرجع برگشت بعدی، صورت‌حساب برگشتی یا اصلاحی قبلی خواهد بود. در فصل برگشت گفتیم که یک صورت‌حساب اصلاحی یا برگشتی فقط در صورتی می‌تواند به عنوان مرجع در یک صورت‌حساب برگشت جدید بکار رود که توسط خریدار (یا سیستم) در کارپوشه‌ی سامانه‌ی مودیان تایید شده باشد و این یعنی وقتی با زنجیره‌ی برگشت مواجه باشیم، کلیه‌ی صورتحسابهای قبلی در این زنجیره «حتما» به ترتیب تایید شده‌اند و با هر تاییدی صورت‌حساب مرجع قبلی باطل شده است. واقعا با یک کلاف سردرگم مواجه هستیم – ناشی از تعاریف، معماری، روش‌ها و نتایج تجزیه و تحلیل و پیاده‌سازی بی‌نهایت نادرست و پراشکال. البته مستندات سیستم هم پراشکال هستند که البته به این بحث مربوط نمی‌شود.
در ارسال صورت‌حساب ابطالی برای یک برگه‌ی برگشت از فروش که قبلا صورت‌حساب اصلاحی برای آن ارسال نشده یا صورت‌حساب اصلاحی مزبور توسط خریدار (یا سیستم) در کارپوشه‌ی سامانه‌ی مودیان تایید شده و این تایید به صورت مناسب به سیستم نوسا اطلاع داده شده است، اگر تایید صورت‌حساب برگشت از فروش در سامانه به اطلاع سیستم نوسا نرسیده باشد پیغام زیر در محاوره‌ی ارسال بازنمایی می‌شود (که بسیار مهم است):
»» توجه (بسيار مهم): اگر اين صورت‌حساب برگشت از فروش در سامانه موديان توسط خريدار (يا سيستم) تاييد شده باشد، ابطال آن به معني ابطال صورت‌حساب فروش اصلي (فاکتور فروش) و تمام برگشت‌هاي قبلي آن فاکتور فروش که به سامانه ارسال شده‌اند خواهد بود – چرا که اگر يک صورت‌حساب ارجاعي (در اينجا برگشت از فروش) در سامانه موديان تاييد شده باشد، صورت‌حساب مرجع (در اينجا فاکتور فروش يا برگشت قبلي همان فاکتورفروش) خود به خود در وضعيت ابطال شده قرار خواهد داشت. متاسفانه هيچ روشي براي اينکه سيستم ما بتواند اين شرايط را تشخيص دهد در سامانه موديان تعبيه نشده است. در اين وضعيت ابطال صورت‌حساب برگشت از فروش عملا به معني ابطال صورت‌حساب‌هاي مرجع نيز خواهد بود!!!
لازم است تا با مراجعه به کارپوشه‌ي سامانه‌ي موديان، وضعيت صورت‌حساب برگشت را بررسي نماييد. اگر صورت‌حساب برگشت تاييد شده (و در نتيجه صورت‌حساب مرجع ابطال شده) باشد لازم است تا پيش از ابطال صورت‌حساب، در فهرست برگه‌هاي فروش فرمان "تعيين وضعيت تاييد صورت‌حساب در سامانه" را صادر کنيد و "تاييد شده" بودن صورت‌حساب برگشت را اعلام نماييد. با اينکار ابطال صورت‌حساب برگشت به معني ابطال زنجيره‌ي صورت‌حساب‌هاي مرجع (فاکتور فروش و برگشت‌هاي قبلي آن) خواهد بود - وگرنه تعدادي صورت‌حساب مرجع (فاکتور فروش يا برگشت) در سيستم خواهيم داشت که در سامانه‌ي موديان ابطال شده‌اند. ابطال صورت‌حساب ابطال شده در سامانه با خطا مواجه خواهد شد.
ذکر مصیبت، تقریبا به صورت کامل در پیغام فوق انجام شده است. در مقابل، اگر صورت‌حساب برگشت از فروش در سامانه تایید شده و این تایید به اطلاع سیستم نیز رسیده باشد پیغام زیر در محاوره‌ی ارسال بازنمایی می‌شود (که این نیز بسیار مهم است):
»» توجه (بسيار مهم): قبلا به نرم‌افزار اعلام شده است که اين صورت‌حساب برگشت از فروش در سامانه‌ي موديان توسط خريدار (يا سيستم) تاييد شده است. از آنجا که اگر يک صورت‌حساب ارجاعي (در اينجا برگشت از فروش) در سامانه موديان تاييد شده باشد، صورت‌حساب مرجع (در اينجا فاکتور فروش يا برگشت قبلي همان فاکتورفروش) خود به خود در وضعيت ابطال شده قرار خواهد داشت، ابطال اين صورت‌حساب برگشت به معني ابطال زنجيره‌ي صورت‌حساب‌هاي مرجع (فاکتور فروش و برگشت‌هاي قبلي آن) خواهد بود.
شماره سند فاکتور فروشي که با اينکار ابطال خواهد شد: --- (در کل ---)
شماره/سري ساير صورت‌حساب(هاي) برگشت از فروشي که ابطال خواهند شد:
--/--
--/--
نکته‌ی قابل توجه در پیغام فوق این است که علاوه بر آنچه قبلا گفتیم، مشخص می‌کند که این ابطال (یک برگشت تایید شده) همزمان با ابطال صورت‌حساب برگشت از فروش جاری، برخی از برگه‌های فروشی که قبلا به سامانه ارسال شده‌اند را نیز پس از استعلام در وضعیت "اعلام صحت ابطال" قرار می‌دهد. چنین است که برگه‌های ذکر شده از قبل در سامانه باطل شده‌اند و صرفا وضعیت نهایی آنها در آخرین برگشتی که ابطال کردیم منعکس شده بوده است. حال با ابطال این برگشت اخیر عملا تمام فروش را باطل کرده‌ایم. هیچیک از برگه‌هایی که در این زنجیره تشخیص داده شده و اعلام شدند، عملا در سامانه وجود ندارند و قاعدتا در نوسا هم باید حذف یا ابطال شوند.
ابطال و وضعیت برگه‌ها در سیستم نوسا (پیش‌نویس، عملیاتی...)
قابل پیش‌بینی است که سیستم فقط برای برگه‌های فروش پیش‌نویس اجازه‌ی ارسال صورت‌حساب ابطالی را بدهد – همانطور که حذف یا ابطال برگه‌های فروش عملیاتی یا تایید شده ممنوع هستند:
در مقابل، برگه‌هایی که در فرآیند ارسال صورت‌حساب ابطالی قرار داشته باشند (در یکی از وضعیت‌های "در انتظار استعلام ابطالی"، "اعلام خطا در استعلام ابطالی" و "اعلام صحت ابطال" ) را نمی‌توانیم عملیاتی کنیم.
تنها نکته‌ای که ارزش توضیح بیشتر دارد، مربوط است به ارسال صورت‌حساب ابطالی برای یک صورت‌حساب برگشت از فروش تایید شده (توسط خریدار یا سیستم). همانطور که در بند قبل گفتیم، ابطال این صورت‌حساب به معنی ابطال کل فروش و همه‌ی برگه‌های زنجیره‌ی برگشت (فاکتور فروش و برگه‌های برگشت از فروش قبلی) است. به همین دلیل هیچیک از آن برگه‌ها نیز نباید عملیاتی یا تایید شده باشند:
قبلا به نرم‌افزار اعلام شده است که اين صورت‌حساب برگشت از فروش در سامانه‌ي موديان توسط خريدار (يا سيستم) تاييد شده است. از آنجا که اگر يک صورت‌حساب ارجاعي (در اينجا برگشت از فروش) در سامانه موديان تاييد شده باشد، صورت‌حساب مرجع (در اينجا فاکتور فروش يا برگشت قبلي همان فاکتورفروش) خود به خود در وضعيت ابطال شده قرار خواهد داشت، ابطال اين صورت‌حساب برگشت به معني ابطال زنجيره‌ي صورت‌حساب‌هاي مرجع (فاکتور فروش و برگشت‌هاي قبلي آن) خواهد بود. همه‌ي برگه‌هاي اين زنجيره بايد "پيش‌نويس" باشند.
فاکتور فروش با شماره سند -- (در کل --) "پيش‌نويس" نيست.
يکي يا برخي از صورت‌حساب‌هاي برگشت از فروش زير (برگه‌هاي قبلي در زنجيره‌ي برگشت) "پيش‌نويس" نيست:
--/--
--/--