درس ۷ — تغییرناپذیری، بایگانی، و اینکه چه کسی چه کاری میتواند بکند
درس آخر دربارهٔ کارهایی است که نمیتوانید بکنید، و همین بخش است که همهٔ آنچه پیش از آن آمد را ارزشمند میکند.
الزام. سند مالیاتیِ ارسالشده یک رکورد است. رکوردی که بعداً بیسروصدا قابل ویرایش باشد شاهد هیچچیز نیست، و سامانهای که چنین اجازهای بدهد نمیتواند از صورتحسابی که تولید کرده پشتیبانی کند. پس نرمافزار این توانایی را از همه میگیرد، در همان لحظهٔ ارسال.
مدل ذهنی. صورتحساب الکترونیکیِ ارسالشده با SHA-256 مُهر خورده و تغییرناپذیر است. نه میتوان دوباره تولیدش کرد و نه به پیشنویس بازگرداند. مُهر همان چیزی است که «این نسخهٔ ما از فایل XML است» را به «این همان فایلی است که فرستادیم و این هم گواه اینکه از آن زمان تکان نخورده است» تبدیل میکند. هر وقت لازم شد آن را ارائه دهید، با View XML فایل بایگانیشده و مُهرخورده را دانلود کنید.
Reset to Draft کنشی برای مدیر است، و کنشی که از ارسال جان بهدر نمیبرد. تنها Manager میتواند سندی را به پیشنویس بازگرداند، و پس از ارسال آن هم نمیتواند. پس وقتی مشتری تغییری روی صورتحسابی میخواهد که رفته است، پاسخ ویرایش نیست. پاسخ یک برگهٔ اعتباری است و بعد یک صورتحساب اصلاحشده — و هر کدام خودشان سند مشتریِ ثبتشده به واحد AED برای طرف حسابی در دامنهاند، پس هر کدام صورتحساب الکترونیکی خودشان با مُهر خودشان میشوند. اصلاح بهصورت اصلاح دیده میشود، و نکته همین است.
چه کسی چه کاری میتواند بکند. ماژول یک امتیاز UAE E-Invoicing با دو گروه تعریف میکند، و این تفکیک آگاهانه است نه اتفاقی.
| کنش | User | Manager |
|---|---|---|
| ایجاد، تولید، اعتبارسنجی، ارسال و تلاش مجدد اسناد | بله | بله |
| خواندن حسابهای ASP | بله | بله |
| مدیریت حسابهای ASP | خیر | بله |
| مشاهده و ویرایش اعتبارنامههای محرمانه | خیر | بله |
| حذف اسناد صورتحساب الکترونیکی | خیر | بله |
| Reset to Draft، پیش از ارسال | خیر | بله |
نبودِ منوها یک مسئلهٔ گروه است، نه ایراد نرمافزار. اگر منوهای ASP Accounts یا E-Invoice Documents آنجا نیستند، یا فیلدهای اعتبارنامه بهسادگی از حساب ASPای که در غیر این صورت میتوانید بخوانیدش غایباند، کاربر در گروه درست نیست. از مدیر سیستم گروه UAE E-Invoicing ← User را بخواهید، یا Manager را جایی که مدیریت حسابها و نگهداری رازها واقعاً بخشی از کار است. اسناد و حسابهای ASP با قواعد رکورد بر پایهٔ شرکت هم محدود میشوند، پس در پایگاه دادهٔ چندشرکتی هر کاربر رکوردهای شرکت خودش را میبیند نه رکوردهای گروه را.
مثال عملی. صورتحساب INV/2026/00187 صبح سهشنبه ارسال شد. بعدازظهر همان روز مشتری تماس میگیرد: سطر یراقآلات باید ۱۰ ست میبود، نه ۱۲. هیچکس در Marina Ridge نمیتواند آن صورتحساب را به پیشنویس بازگرداند و دکمههایی که این کار را میکردند بهدرستی غایباند. پس کارشناس برای مابهالتفاوت یک برگهٔ اعتباری به واحد AED صادر میکند — ۲ ست به قیمت AED 875.00، یعنی AED 1,750.00 بهعلاوهٔ مالیات ارزش افزودهٔ AED 87.50، در مجموع AED 1,837.50 — آن را ثبت میکند، Send & Print را میزند، و برگهٔ اعتباری سند PINT AE خودش میشود، با مُهر خودش و جایگاه خودش در ردّ اسناد.
حالت خطا. دو روایت از یک سوءتفاهم. یکی کاربری که دنبال دکمهٔ Reset to Draft میگردد که بهدرستی غایب است و نتیجه میگیرد ماژول خراب است. دیگری مدیری که Reset to Draft را با موفقیت روی سندی که هنوز ارسال نشده به کار برده و فرض میکند همان امکان پس از ارسال هم هست. واقعیت تعیینکننده ارسال است، نه گروه: پیش از آن Manager میتواند بازگرداند، پس از آن هیچکس نمیتواند، و همین تضمینی است که بایگانی بر آن استوار است.