Skip to Content

درس ۸ — فایل SIF، و چرا هیچ چیدمان بانکی همراه نیست

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

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

به‌جای آن چه کنید. مشخصات فعلی SIF را از بانک خود بخواهید و آن را به‌عنوان یک رکورد چیدمان بارگذاری کنید و فیلدهای خاستگاه — منبع، نشانی، SHA-256 و تاریخ — را پر کنید تا خوانندهٔ بعدی دقیقاً بداند چیدمان از کدام سند آمده است. این درخواست یک ایمیل کوتاه به مدیر ارتباط شما در بانک است، و ارزشمندترین کاری است که در هفتهٔ پس از پایان این دوره می‌توانید انجام دهید.

پس از آنکه چیدمانی وجود داشت، مسیر سه گام است.

  1. به کارکنان ← فایل‌های SIF (Employees → SIF Files) بروید و برای دورهٔ دستمزد رکوردی بسازید، در صورت تمایل با اشاره به یک دستهٔ فیش حقوقی.
  2. اعتبارسنجی (Validate). همهٔ مشکل‌ها یک‌جا گزارش می‌شوند و نام کارمند و فیلد را ذکر می‌کنند.
  3. ساخت فایل (Generate File). فایل نوشته و ذخیره می‌شود و رکورد همراه با SHA-256 آن مهروموم می‌گردد.

چرا اعتبارسنجی همه‌چیز را یک‌جا گزارش می‌کند. چون بانک یک SIF را به‌صورت یکپارچه رد می‌کند. یک IBAN نادرست — یعنی شمارهٔ حساب بانکی بین‌المللی — روی آخرین کارمند یعنی هیچ‌کس پرداخت نمی‌شود، پس پیامی که در نخستین خطا متوقف شود اصلاح یک دستهٔ ۴۰۰ نفره را به ۴۰۰ رفت‌وبرگشت تبدیل می‌کند. کل فهرست را اصلاح کنید، دوباره اعتبارسنجی کنید، سپس فایل را بسازید.

چرا مهروموم اهمیت دارد. چون اصلاح یعنی یک خروجی جدید، نه ساخت دوباره. همین است که «دقیقاً روز 3 چه چیزی فرستادیم؟» را به پرسشی با پاسخ تبدیل می‌کند، و این شواهد ماده 1(3) در تحت‌اللفظی‌ترین شکل ممکن است: یک فایل، یک اثر انگشت و یک تاریخ.

چه کسانی در فایل هستند. تنها کارگران رژیم مؤسسه. کارگران رژیم خانگی و مستثناشدگان ماده 4 به‌جای آن در پایشگر انطباق لحاظ می‌شوند، و به همین دلیل فیلد رژیم در درس ۶ هم‌زمان دو چیز را تعیین می‌کند.

ساخت فایل SIF به بانک می‌گوید پرداخت کند، و به حساب‌های شما هیچ نمی‌گوید. ثبت پرداخت WPS (Register WPS Payment) روی یک رکورد SIF ساخته‌شده همین شکاف را می‌بندد. یک سند حسابداری ثبت می‌کند که بدهی دستمزد خالصِ ایجادشده توسط فیش‌ها را تسویه و بانک را بستانکار می‌کند، از دفتر روزنامهٔ پرداخت WPS (WPS Payment Journal) که روی شرکت تنظیم شده است.

این سند به‌ازای هر کارمند یک سطر بدهکار دارد، هرکدام با طرف‌حساب همان کارمند، در برابر حسابی که قاعدهٔ حقوق NET به آن نگاشت می‌شود. همین شکل، تمام نکته است. یک سطر واحد و یکجا کاملاً موازنه می‌شد و با هیچ‌چیز مغایرت‌گیری نمی‌کرد و بدهی هر کارمند را تا ابد باز نگه می‌داشت — و تا وقتی کسی سراغ تحلیل سنی آن حساب نمی‌رفت، هیچ‌کس متوجه نمی‌شد.

سه کاری که انجام نخواهد داد:

  • حدس‌زدن حساب. بدون دفتر روزنامهٔ پرداخت، بدون حساب پیش‌فرض روی آن، یا بدون نگاشت دفتر کل برای قاعدهٔ NET، دقیقاً همان شکاف را نام می‌برد و چیزی ثبت نمی‌کند.
  • پرداخت دوباره. پس از ثبت یک سند، دکمه ناپدید می‌شود و تلاش دوم رد می‌شود. سند نخست پابرجا می‌ماند، و اصلاح یعنی یک برگشت که عمداً در حسابداری انجام می‌شود.
  • بازگشایی فایل. رکورد SIF مهروموم‌شده باقی می‌ماند، با همان SHA-256 پیشین. آنچه به بانک فرستادید با ثبت‌کردن آن تغییر نمی‌کند.

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

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

نیازمندی چرا لازم است
حسابداری ← حسابدار (account.group_account_user) چون یک سند حسابداری به بانک ثبت می‌کند، و این بررسی درون خود اقدام تکرار می‌شود، زیرا ویژگی groups= تنها دکمه را مقید می‌کند و هرگز فراخوان RPC پشت آن را
حقوق‌ودستمزد ← مدیر (مدیر حقوق‌ودستمزد Odoone) چون هر فیش حقوقی در آن اجرا را می‌خواند، و کاربر حقوق‌ودستمزد با قاعدهٔ رکورد به فیش‌های خودش محدود است، پس مدیر واقعاً لازم است
منابع انسانی ← کارشناس / مدیر منابع انسانی (hr.group_hr_manager) چون تفکیک درآمد دستمزد قرارداد را می‌خواند و این کار مشخصاً به گروه مدیر منابع انسانی محدود شده است
عضویت در شرکت پرداخت‌کننده چون قواعد رکورد چندشرکتی فیش‌های بیرون از شرکت‌های مجاز کاربر را پنهان می‌کنند، پس بدون عضویت اقدام کسی را برای پرداخت پیدا نمی‌کند

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

ثبت نظر برای این دوره فعال نیست.