درس ۵ — قواعد فیلدهای اجباری، و خطایی که باید از دیدنش خوشحال شوید
این همان درسی است که یک صبح ارتقای ترسناک را به یک سهشنبهٔ معمولی تبدیل میکند.
الزام. پیش از ارسال، سند در برابر دیکشنری دادهٔ وزارت دارایی بررسی میشود. این لطفی نیست که نرمافزارتان در حق شما میکند؛ این همان استانداردی است که نقطهٔ دسترسی در آن سو اعمال میکند. نقطهٔ دسترسی اسناد را رد میکند و کاستیهایشان را پر نمیکند، پس هر فیلدی که لازم دارد باید پیش از خروج سند حاضر باشد.
مدل ذهنی. بیشتر این بررسیها درونساختهاند. آنهایی که نشانیها، کشورها و شرح سطرها را پوشش میدهند بهصورت رکوردهای قاعدهٔ قابل ویرایش عرضه میشوند که روی صفحه میخوانیدشان — و چون رکوردند نه کد، میتوانید یکی را بایگانی کنید تا بررسی نکند، یا قاعدهای مخصوص شرکت خودتان بیفزایید. همین سه حوزه دقیقاً به این دلیل روی صفحهاند که بیش از بقیه به رسیدگی شرکتبهشرکت نیاز دارند.
مسیر کلیک. حسابداری ← پیکربندی ← UAE E-Invoicing ← Mandatory-Field Rules. فهرست را یک بار پیش از آغاز به کار بخوانید؛ چند دقیقه بیشتر طول نمیکشد و دقیقاً به شما میگوید چه چیزی بررسی خواهد شد.
| قواعد عرضهشده چه چیزی را پوشش میدهند | آن داده کجا زندگی میکند | علت معمول ناموفقشدن |
|---|---|---|
| نشانیها | رکورد شرکت شما و مخاطب مشتری | مخاطبی که سالها پیش با یک نام و یک شمارهٔ تلفن و هیچچیز دیگر ساخته شده |
| کشورها | رکورد شرکت شما و مخاطب مشتری | مخاطب واردشدهای که کشورش هرگز نگاشت نشده است |
| شرح سطرها | خود سطر صورتحساب | سطری که فقط یک کد کالا دارد، یا شرحی که روی سطر دستی خالی مانده است |
یک پیام، یک جا برای نگاهکردن. قاعدهٔ ناموفق از راه همان پیام Send & Print گزارش میشود که هر خطای اعتبارسنجی دیگر. نه گزارش جداگانهای هست، نه صفحهٔ دومی، نه صف فنیای که در آن بگردید. این نکته مهمتر از آن است که به نظر میرسد: سامانهٔ اعتبارسنجیای که دو جا برای نگاهکردن دارد، سامانهای است که یکی از آن دو جا خوانده نمیشود.
میتوانید قاعدهای را بایگانی کنید، و بهتر است پیشش فکر کنید. بایگانی، بررسی قاعده را متوقف میکند و دلایل مشروعی هم دارد — مثلاً قاعدهای که بررسی سختگیرانهتر خودتان را تکرار میکند. اما آنچه بایگانی انجام نمیدهد، تغییر آن چیزی است که در نقطهٔ دسترسی رخ میدهد. مشخصات با فهرست قواعد شما اجرا نمیشود؛ فهرست قواعد شما هشدار زودهنگام محلیِ آن است. قاعدهای را که ناموفق میشود بایگانی کنید و هشدار را برداشتهاید و عیب را نگه داشتهاید، و همان مشکل بعدها بهصورت ردشدنی که جای بحث ندارد به شما بازمیگردد.
پیام «نشانی موجود نیست» پس از ارتقا یعنی این قابلیت درست کار میکند. اگر صورتحسابهایی که سالها بیدردسر بیرون میرفتند ناگهان نبودِ نشانی را گزارش کنند، هیچچیز خراب نشده است. نشانی طبق مشخصات وزارت دارایی الزامی است و نقطهٔ دسترسی هم سند را رد میکرد. نشانی شرکت و مشتری را کامل کنید تا خطا برطرف شود. روبهروشدن با این خطا درون سامانهٔ خودتان و در زمان خودتان ارزان است؛ روبهروشدن با آن بهصورت ردشدن پس از آغاز به کار ارزان نیست.
مثال عملی. Marina Ridge فهرست مشتریانش را در اوت، پیش از آنکه چیزی زنده شود، خروجی میگیرد. از ۴۱۲ مشتری فعال، ۶۳ نفر سطر خیابان ندارند و ۹ نفر اصلاً کشور ندارند. آن ۶۳ نفر مشکل آشکار و آساناند: هرکدام در قاعدهٔ نشانی ناموفق میشد و در پیام Send & Print گزارش میشد. آن ۹ نفر خطرناکاند، چون مخاطب بدون کشور به قالب PINT AE نگاشت نمیشود، پس صورتحسابهایشان بهجای ناموفقشدن با صدای بلند، بیصدا از دامنه بیرون میافتند. یک بعدازظهر کار روی داده در اوت هر دو را برمیدارد.
حالت خطا. خطایی که باید از آن پرهیز کرد، برخورد با فهرست قواعد بهمثابهٔ خود مشخصات است. فهرست قواعد، مشخصات نیست. بیشتر بررسیها درونساختهاند و هرگز روی آن صفحه نمیآیند، پس فهرست قواعدی که سر تا ته خواندهاید تضمین نمیکند چیز دیگری بررسی نمیشود. قواعد را بخوانید تا بفهمید چه چیزی بهصورت محلی بررسی میشود و آنچه شرکتتان لازم دارد را بیفزایید — نه برای اینکه کل دیکشنری دادهٔ وزارت دارایی را کشف کنید، که کنار مشخصات Peppol PINT AE زندگی میکند و موضوع دورهٔ 3.1 است.