قولوا الحقيقة أولاً: لا يُشحن مع هذا النظام أي تخطيط بنكي. فالمحرك مكتمل ومختبَر، لكن تخطيط السجل يُحمَّل بوصفه إعداداً، ولا تجد شاشات SIF تخطيطاً يمكن اختياره إلى أن تُحمَّل مواصفة بنككم الحالية.

ولماذا هذا قرار لا نقص. يُحفظ التخطيط بوصفه بيانات لا شفرة، فتُحمَّل مواصفة أي بنك كسجل إعداد. وقد تبيّن عند التحقق أن أحد المصدرين البنكيين المتوقعين لم يعد موجوداً — لا يملك مضيفه أي سجل DNS ولا نسخة مؤرشفة — وأن الآخر مؤرخ بعام 2018، أي أقدم بثماني سنوات من قرار 2026 الذي يفترض أن يستوفيه. وشحن أيٍّ منهما كان سيكون أسوأ من عدم الشحن: فالتخطيط القديم أو غير الموثَّق يُنتج ملفاً يرفضه بنككم، أو، وهو الأسوأ، ملفاً يقبله وهو يحمل قيماً خاطئة.

وما الذي تفعلونه بدلاً من ذلك. اطلبوا من بنككم مواصفة SIF الحالية وحمّلوها كسجل تخطيط، مع ملء حقول المنشأ — المصدر والرابط وبصمة SHA-256 والتاريخ — ليعرف القارئ لاحقاً من أي وثيقة جاء التخطيط بالضبط. وهذا الطلب رسالة قصيرة إلى مدير علاقتكم في البنك، وهو أعلى الأعمال قيمة في الأسبوع التالي لإنهاء هذه الدورة.

وبعد توفر تخطيط، يصير المسار ثلاث خطوات.

1. انتقلوا إلى الموظفون ← ملفات SIF (Employees → SIF Files) وأنشئوا سجلاً لفترة الأجر، مع الإشارة اختيارياً إلى دفعة قسائم رواتب.
2. التحقق (Validate). تُبلَّغ كل المشكلات دفعة واحدة، مع ذكر اسم الموظف والحقل.
3. إنشاء الملف (Generate File). يُكتب الملف ويُحفظ ويُختم السجل مع بصمة SHA-256 الخاصة به.

ولماذا يُبلّغ التحقق عن كل شيء دفعة واحدة. لأن البنك يرفض ملف SIF ككل. فرقم IBAN خاطئ واحد لدى آخر موظف يعني ألا يتقاضى أحد أجره، ورسالة تتوقف عند أول خطأ كانت ستحوّل تصحيح دفعة من 400 موظف إلى 400 جولة. صححوا القائمة كلها، ثم أعيدوا التحقق، ثم أنشئوا الملف.

ولماذا يهم الختم. لأن التصحيح تصدير جديد لا إعادة إنشاء. وهذا ما يجعل لسؤال «ماذا أرسلنا بالضبط في اليوم 3؟» جواباً، وهو دليل المادة 1(3) في أكثر صوره حرفية: ملف، وبصمة، وتاريخ.

ومن يدخل الملف. عمال نظام المنشأة وحدهم. أما عمال النظام المنزلي والمستثنون بموجب المادة 4 فيُحتسبون في مراقب الامتثال بدلاً من ذلك، ولهذا يحسم حقل النظام في الدرس 6 أمرين في آن واحد.

إنشاء ملف SIF يُخبر البنك بالدفع، ولا يُخبر دفاتركم بشيء. ويسدّ تسجيل دفعة حماية الأجور (Register WPS Payment) على سجل SIF مُنشأ هذه الفجوة. فهو يُرحِّل قيد يومية واحداً يُصفّي صافي الأجور المستحقة الذي أنشأته قسائم الرواتب ويُقيّد البنك دائناً، من دفتر يومية دفع حماية الأجور (WPS Payment Journal) المضبوط على الشركة.

ويحمل القيد سطراً مديناً واحداً لكل موظف، بشريكه الخاص، مقابل الحساب الذي تُحوَّل إليه قاعدة الراتب NET. وهذا الشكل هو صلب الفكرة كلها. فسطر واحد بمبلغ إجمالي كان سيتوازن تماماً ولا يُسوَّى مقابل أي شيء، تاركاً ذمة كل موظف مفتوحة إلى الأبد — ولا يكتشف أحد ذلك حتى يحاول أحدهم تحليل أعمار الحساب.

وثلاثة أمور يمتنع عنها:

• تخمين حساب. فبلا دفتر يومية للدفع، أو بلا حساب افتراضي عليه، أو بلا ربط محاسبي لقاعدة NET، يسمّي الفجوة بدقة ولا يُرحِّل شيئاً.
• الدفع مرتين. فبمجرد تسجيل قيد يختفي الزر ويُرفض أي محاولة ثانية. ويبقى القيد الأول قائماً، والتصحيح عكسٌ يتم عن قصد من داخل المحاسبة.
• إعادة فتح الملف. يبقى سجل SIF مختوماً، وببصمة SHA-256 نفسها التي كانت له من قبل. فما أرسلتموه إلى البنك لا يتغيّر لأنكم رحّلتموه.

ويساوي إجمالي المبلغ المُرحَّل دائماً الإجمالي الرقابي للملف نفسه لا صافياً يُعاد احتسابه حديثاً. فإن اختلف الاثنان يوماً، عرفتم ذلك هنا لا عند البنك.

الصلاحيات الأربع. الزر مرتبط بصلاحيات المحاسبة، لكن الإجراء يقرأ أيضاً عملية الرواتب التي يقوم عليها الملف، وتُفرض تلك القراءات كلٌّ على حدة. والشخص الذي يسجّل الدفعة يحمل هذه الأربع كلها.

الخطأ الشائع. خطأ الصلاحيات هنا يبدو كعطل برمجي وليس كذلك. فلا شيء في هذا المسار يعمل بصلاحيات مرفوعة — ما يُسمح لكم برؤيته هو ما يُدفع — فالحل هو منح المجموعة الناقصة، لا الالتفاف حولها أبداً. وإن رفض الإجراء ولم تعرفوا أي الأربع ناقصة، فافحصوا عضوية الشركة أولاً: فهي التي تُنتج رسالة خطأ أبعد ما تكون شبهاً عن سببها الحقيقي.