ارسال صورتحساب الکترونیکی به سامانه مؤدیان؛ راهنمای مستقل
ارسال موفق یک دکمه نیست؛ زنجیرهای از عضویت، داده پایه، الگوی درست، کنترل مبلغ، امضا یا مسیر معتبر، پاسخ و آشتی با حسابداری است.
ارسال صورتحساب دقیقاً چه مسئلهای را حل میکند؟
قانون پایانههای فروشگاهی، صورتحساب الکترونیکی را صورتحساب یا کاربرگ دارای شماره منحصربهفرد مالیاتی میداند که اطلاعات آن در حافظه مالیاتی ذخیره میشود و مرجع نهایی ثبت، صدور و استعلام را سامانه مؤدیان معرفی میکند. پس تولید PDF، چاپ فاکتور یا ثبت فروش در حسابداری بهتنهایی همان ارسال قانونی نیست. باید داده مطابق مشخصات جاری از مسیر مجاز منتقل شود و نتیجه قابل بازیابی سامانه با رویداد فروش پیوند بخورد. [۱] [۸] [۷]
نرمافزار حسابداری، راهکار ابری، اتصال مستقیم، شرکت معتمد یا سامانه دولتی میتواند بخشی از مسیر باشد؛ انتخاب روش مسئولیت مؤدی را فقط در حدود مقررات و قرارداد تغییر میدهد. عبارت «ارسال توسط ارائهدهنده» را به معنی انتقال همه مسئولیت داده نگیرید. فروشنده همچنان باید واقعیبودن معامله، هویت طرف، شرح، مبلغ، نرخ و زمان را کنترل کند. قرارداد خدمات باید مسئول صدور، انتقال، نگهداری پاسخ، رفع خطا و پشتیبانی در قطعی را روشن سازد. [۷] [۶] [۱]
مرحله صفر: آمادگی هویت، نقش و روش ارسال
پیش از اولین صورتحساب، پرونده مالیاتی، شخص صادرکننده، شعبه یا واحد، نقش کاربران و روش ارسال را تطبیق دهید. شناسه یکتای حافظه توسط سازمان اختصاص مییابد و به حافظه و مسیر مربوط است؛ استفاده از حافظه شخص دیگر تخلف مستقل دارد. دسترسی مدیر، اپراتور و پشتیبان را جدا کنید و کلیدها یا اسرار اتصال را در پیامرسان نگه ندارید. تغییر ارائهدهنده یا شعبه باید فرایند انتقال و خاتمه دسترسی داشته باشد، نه جابهجایی ناگهانی در روز فروش. [۱] [۷] [۶]
یک آزمون آمادگی بنویسید: آیا شناسه حافظه معتبر است؟ آیا پرونده و شعبه درست متصلاند؟ آیا ساعت سیستم و توالی داخلی کنترل میشود؟ آیا کاتالوگ کالا/خدمت نسخه دارد؟ آیا الگوهای موردنیاز کسبوکار پشتیبانی میشوند؟ آیا مسئول خطا و قطعی معلوم است؟ پاسخ هر سؤال باید فایل یا مشاهده مستند داشته باشد. این مقاله عمداً ترتیب منوی کارپوشه را بازگو نمیکند، چون رابط میتواند تغییر کند؛ راهنمای جاری درگاه و دسترسی خود مؤدی مرجع اجراست. [۸] [۷] [۱۱]
از رویداد واقعی و الگوی درست شروع کنید
صورتحساب از قرارداد، سفارش، تحویل یا ارائه خدمت آغاز میشود. نوع و الگوی آن باید با ماهیت معامله، خریدار، شیوه تسویه و الزامات دستورالعمل سازگار باشد. فروش کالا، خدمت، پیمان، برگشت، اصلاح یا ابطال را با یک فرم واحد و ویرایش آزاد مدیریت نکنید. ابتدا رویداد تجاری را طبقهبندی و سپس فیلدهای الزامی همان الگو را تولید کنید. اگر قرارداد مرکب است، نحوه تفکیک ردیفها و زمان صدور را با حکم قابل استناد تعیین نمایید. [۹] [۸] [۳]
داده پایه شامل هویت طرفین، شناسه کالا یا خدمت، واحد، مقدار، مبلغ، تخفیف، نرخ، مالیات و تسویه است. هر کدام باید مالک داده و منبع داشته باشد. فروشنده نباید نرخ را از فاکتور قبلی یا توضیح کوتاه محصول کپی کند. سامانه رسمی شناسه کالا/خدمت و قانون ارزش افزوده نقاط کنترلاند. برای خریدار نهایی و مؤدی عضو، نوع اطلاعات و اثر اعتبار یکسان نیست؛ الگو و نقش خریدار را مطابق دستورالعمل جاری بسنجید. [۱۰] [۹] [۳]
اعتبارسنجی پیش از ارسال و ثبت بسته انتقال
پیش از انتقال سه لایه کنترل کنید. لایه شکلی، نوع و طول فیلد و اقلام الزامی را با نسخه مشخصات میسنجد. لایه حسابی، جمع ردیف، تخفیف، مالیات و تسویه را باز محاسبه میکند. لایه تجاری، قرارداد، تاریخ، طرف و ماهیت را تأیید میکند. عبور از اعتبارسنجی شکلی به معنی صحت معامله نیست. نتیجه هر لایه، نسخه قواعد و تأییدکننده را نگه دارید تا خطا بعداً قابل بازسازی باشد. [۸] [۹] [۱]
برای هر تلاش ارسال، شناسه داخلی تغییرناپذیر، زمان، نسخه payload کنترلشده، مسیر ارسال و نتیجه فنی را ثبت کنید. داده حساس و کلید خصوصی نباید در لاگ عمومی قرار گیرد. سیاست retry باید بداند کدام خطا موقت و کدام نیازمند اصلاح داده است؛ ارسال کور میتواند تکرار یا ابهام بسازد. اگر شرکت معتمد واسط است، رسید دریافت او و پاسخ نهایی سامانه را جدا نگه دارید. موفقیت تحویل به واسط لزوماً موفقیت ثبت در مرجع نهایی نیست. [۶] [۸] [۷]
پاسخ و وضعیت را به سند داخلی گره بزنید
پس از ارسال، شماره منحصربهفرد، شناسه مرجع پاسخ، زمان و وضعیت قابل بازیابی را کنار شماره سفارش و سند حسابداری ذخیره کنید. یک صف بازبینی باید موارد بدون پاسخ، ردشده، نیازمند اصلاح و ناسازگار با ثبت را جدا نشان دهد. نام وضعیتها را از مستند جاری بگیرید و ترجمه داخلی را در فرهنگ داده توضیح دهید. کاربر نباید با دیدن علامت سبز نرمافزار، سند را قطعی فرض کند مگر آن علامت دقیقاً به پاسخ معتبر و ثبتشده متصل باشد. [۷] [۸] [۱]
در فروش به مؤدی، واکنش خریدار و آثار آن بر اعتبار یا اظهارنامه موضوع جداگانهای است. فروشنده نباید پذیرش خریدار را جای موفقیت ارسال بگذارد و خریدار نیز نباید صرف حضور صورتحساب را جای اثبات معامله واقعی بگیرد. قرارداد، تحویل و پرداخت باید با صورتحساب تطبیق شوند. اختلاف را در صف بررسی نگه دارید و دلیل رد یا عدم واکنش را مستند کنید؛ هیچ وضعیت سامانهای بهتنهایی حقیقت اقتصادی را قطعی نمیکند. [۱] [۲] [۷]
اصلاح، ابطال، برگشت و قطعی را قاطی نکنید
اگر مبلغ، شناسه، تاریخ یا طرف نادرست است، روش اصلاح به نوع صورتحساب و وضعیت مرجع وابسته است. حذف رکورد داخلی یا صدور فاکتور تازه بدون رابطه با مرجع میتواند زنجیره را قطع کند. دستورالعمل صدور برای صورتحساب اصلاحی، ابطالی و برگشت از فروش قواعد دارد؛ همان نسخه را اجرا و شماره مرجع را حفظ کنید. علت اصلاح، درخواستکننده، تأیید مالی و اثر بر سند حسابداری باید یکجا ثبت شود. [۹] [۸] [۵]
در حادثه یا نقص فنی، قانون و دستورالعمل ماده ۱۲ مسیر اعلام و اقدام جایگزین را پیشبینی کردهاند. از ساختن مهلت یا روش خودسرانه پرهیز کنید و دستورالعمل جاری را دنبال نمایید. زمان شروع و پایان قطعی، صورتحسابهای متاثر، تلاشهای ارسال و مکاتبه با ارائهدهنده را ثبت کنید. پس از بازیابی، آشتی کامل انجام دهید تا هیچ فروش دوباره یا جاافتاده نماند. قطعی اینترنت دلیل حذف فروش از حسابداری نیست و بازگشت سرویس نیز اثبات کاملشدن صف نیست. [۴] [۱] [۷]
کنترل روزانه و آشتی پایان دوره
روزانه تعداد و مبلغ فروش منبع را با صورتحسابهای آماده، ارسالشده و پاسخگرفته آشتی دهید. اختلاف را به برگشت، نسیه، قطع ارتباط، خطای داده یا رویداد ثبتنشده طبقهبندی کنید. نسبت موفقیت بدون مبلغ و سن موارد باز تصویر کامل نمیدهد. هر مورد باید مالک و موعد پیگیری داشته باشد. در پایان روز، بسته پاسخ را نسخهبرداری امن کنید و از تکیه بر حساب کاربری یک اپراتور برای تاریخچه سازمانی پرهیز نمایید. [۵] [۸] [۷]
پایان دوره، فروش دفتر کل، صورتحسابهای سامانه، اظهارنامه ارزش افزوده، برگشتها و دریافتها را تطبیق دهید. اختلاف زمانی مشروع را با کاربرگ توضیح دهید و اختلاف ماهیتی را پیش از ارسال گزارش اصلاح کنید. گزارش واسط را بدون نمونهگیری با مرجع نهایی برابر ندانید. پنج نمونه از الگوهای مختلف را از سفارش تا پاسخ و سند دنبال کنید. اگر مسیر قطع شد، نقص کنترل را ثبت کنید؛ تنظیم عدد برای مساویشدن جمعها بدون یافتن علت، ریسک را پنهان میکند. [۳] [۵] [۱]
تاریخ راستیآزمایی و نقش ژرفبان
این راهنما در ۷ شهریور ۱۴۰۵ بازبینی شده است. اصلاحات ۱۴۰۴ قانون و نسخههای فنی میتوانند دامنه فیلد، نقشها یا ترتیبات را تغییر دهند؛ پیش از اجرا متن رسمی، مستند فنی و اطلاعیه همان دوره را بررسی کنید. شماره نسخه، تاریخ دریافت و اثر تغییر بر الگوهای فعال را در صورتجلسه انتشار ثبت کنید و پیش از استقرار، نمونههای مرزی را در محیط کنترلشده دوباره بیازمایید. این مقاله درباره الگوریتم داخلی سازمان، منوی ثابت، پذیرش خودکار یا مهلت منتشرنشده ادعا نمیکند. برای معامله خاص، الگو و نرخ را با قرارداد واقعی و مشاور یا مرجع رسمی تطبیق دهید. [۱] [۱۲] [۸] [۱۱]
ژرفبان در قابلیت فعال سامانه مؤدیان، صدور و ارسال صورتحساب، دریافت وضعیت و خطا و دریافت صورتحساب خرید را پوشش میدهد و پیشنهاد تطبیق با سند و طرف حساب ارائه میکند. این محصول مرجع نهایی ثبت نیست و قضاوت حقوقی درباره الگو یا نرخ را جایگزین نمیکند. در دمو، الگوهای کسبوکار، شرکت معتمد یا اتصال، رفتار قطعی، تاریخچه اصلاح و خروجی آشتی را با نمونه واقعی کنترل کنید. [۱] [۷]
منابع مستقیم
- قانون پایانههای فروشگاهی و سامانه مؤدیان؛ متن تنقیحی مجلس شورای اسلامی؛ نظامات
- قانون تسهیل تکالیف مؤدیان مجلس شورای اسلامی؛ نظامات
- قانون مالیات بر ارزش افزوده مصوب ۱۴۰۰ مجلس شورای اسلامی؛ نظامات
- دستورالعمل اصلاحی ماده ۱۲ درباره حادثه و نقص فنی سازمان امور مالیاتی؛ نظامات
- آییننامه اجرایی ماده ۲۱۹ وزارت اقتصاد؛ نظامات
- آییننامه ماده ۲۶ شرکتهای معتمد هیئت وزیران؛ نظامات
- پرسشهای متداول صدور و ارسال صورتحساب مرکز آموزش شرکت معتمد مالیاتی
- سند ویژگیها و مشخصات فنی سامانه مؤدیان سازمان امور مالیاتی کشور
- دستورالعمل صدور صورتحساب الکترونیکی سازمان امور مالیاتی کشور
- سامانه شناسه کالا و خدمات مالیاتی سازمان امور مالیاتی کشور
- درگاه ملی خدمات الکترونیک مالیاتی سازمان امور مالیاتی کشور
- روزنامه رسمی جمهوری اسلامی ایران روزنامه رسمی
تحلیلهای مرتبط
مطالب همموضوع که همین تصمیم را از زاویهٔ دیگری کامل میکنند.
شناسه یکتای حافظه مالیاتی و شناسه کالا/خدمت؛ نقشه کنترل
چهار شناسه در یک فرایند دیده میشوند اما جای یکدیگر نیستند. کنترل درست، هر شناسه را به مالک، مرجع صدور، محل مصرف و نسخه داده پایه پیوند میدهد.
خواندن گزارش
ثبتنام و ورود سامانه مؤدیان؛ راهنمای کنترل دسترسی شرکت
ورود موفق به یک صفحه پایان ثبتنام نیست. شرکت باید پرونده فعال، کارپوشه درست، روش ارسال، امضاکننده مجاز، نگهداری امن کلید و جانشین عملیاتی را به یک زنجیره قابل آزمون تبدیل کند.
خواندن گزارش
عدم نیاز به واکنش در سامانه مودیان یعنی چه؟ راهنمای کنترل
«عدم نیاز به واکنش» مجوز نادیدهگرفتن صورتحساب نیست. این برچسب میگوید چرخهٔ جاری برای آن رکورد منتظر تأیید یا رد خریدار نیست؛ مدیر مالی هنوز باید نوع صورتحساب، طرف معامله، اعتبار مالیاتی و نیاز به اصلاح یا ابطال را کنترل کند.
خواندن گزارش
«نرمافزار حسابداری مورد تأیید دارایی»؛ ادعا را چگونه راستیآزمایی کنیم؟
عبارت «مورد تأیید دارایی» بدون نام مرجع، سند، دامنه، نسخه و تاریخ، ادعای قابل سنجش نیست. ممکن است تأیید فقط به یک خدمت مالیاتی یا مشخصات فنی صورتحساب مربوط باشد، نه صحت حسابداری، امنیت یا پذیرش همه دفاتر.
خواندن گزارش
قانون تسهیل تکالیف مؤدیان؛ راهنمای اجرایی برای مدیر مالی
این قانون فقط یک تعویق تاریخی نبود؛ ثبتنام خودکار، اظهارنامه مبتنی بر داده سامانه، حد مجاز فروش، فراخوان ارزش افزوده و مسئولیت صورتحساب را تغییر داد. راهنمای حاضر حکم پایدار را از امتیازهای زماندار جدا و آن را به کنترل روزانه واحد مالی تبدیل میکند.
خواندن گزارش
صورتحساب شمس چیست؟ راهنمای صدور، ثبت پس از حادثه و کنترل مستندات
شمس راه میانبر برای فروش عادی نیست؛ سازوکار تداوم صدور صورتحساب در حادثه یا نقص فنی است. این راهنما متن قانون و دستورالعمل را از برداشتهای رایج جدا میکند و پرونده کنترلی لازم را میسازد.
خواندن گزارشخلاصه را سریع ببینید؛ گزارش کامل را با یک لمس باز کنید
هر پست با تصویر اختصاصی، دو دلیل اهمیت، یک اقدام مدیریتی، یک مورد قابل رصد و مسیر مستقیم به متن کامل و منابع منتشر میشود.