الفكرة الثانية أصغر من الأولى وتوفّر جدلاً أكثر: تبحث الوحدة عن الحساب بأربع طرق مختلفة، وإنشاؤه آخرها.

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

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

كل سطر ربط يخبركم أي خطوة فازت. يسجّل كل سطر في ملاحظته كيف عُثر على حسابه، فتميّزون حساب التوطين المُعاد استخدامه من حساب أنشأته هذه الوحدة. وتلك الملاحظة أول ما يُقرأ حين يبدو رصيد ما خاطئاً، لأنها تجيب عن السؤال الكامن تحت أغلب الخلافات على أستاذ الرواتب: أهذا حسابنا أم حساب صنعته الوحدة؟

مسار النقر. افتحوا كشوف الرواتب ← الإعداد ← ربط حسابات الأستاذ العام (Payroll → Configuration → GL Account Mapping)، وجمّعوا القائمة حسب الشركة. تحصلون على سطر واحد لكل قاعدة راتب في كل شركة، ومعه حسابه وملاحظته. ولا شيء هنا مخبوء في الشيفرة، فنتيجة الزرع كاملةً ظاهرة في قائمة واحدة.

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

نمط الفشل. إن وجدتم بالفعل حسابين يبدوان الشيء نفسه، فليس الزرع من صنعهما معاً. افتحوا ملاحظة الربط وانظروا أي حساب تُرحِّل الوحدة إليه فعلاً، ثم عالجوا الآخر بوصفه مسألة شجرة حسابات كما هو. والحالة المعاكسة أشيع وأيسر: ألا يُزرع شيء أصلاً، وتلك مسألة بلد لا مسألة حساب، ويعالجها الدرس 5.