احراز نمایندهٔ شرکت با استعلام هیئت‌مدیره: طراحی تطبیق نام و سمت

اگر کاربر در فرم ثبت‌نام می‌گوید «من نمایندهٔ شرکت هستم»، تنها کاری که لازم است بکنید این نیست که یک عکس از معرفی‌نامه بگیرید. می‌توانید نام او را با ترکیب ثبتی هیئت‌مدیره مقایسه کنید و تصمیم بگیرید پرونده خودکار پیش برود، به بازبینی دستی برود یا مدرک بیشتری بخواهد.

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

چه چیزی را واقعاً می‌خواهید ثابت کنید

سه ادعای مختلف هست که اغلب با هم قاطی می‌شوند.

1. این شخص با این شرکت رابطهٔ ثبتی دارد (در فهرست هست).
2. این رابطه از نوعی است که برای این کار کافی است (مثلاً مدیرعامل یا رئیس هیئت‌مدیره).
3. این شخص اجازهٔ انجام همین کار مشخص را دارد.

استعلام هیئت‌مدیره ادعای ۱ را قوی و ادعای ۲ را معقول پوشش می‌دهد. ادعای ۳ را پوشش نمی‌دهد. اگر محصول شما برای فعال‌سازی یک سرویس کم‌ریسک است، ۱ و ۲ کافی‌اند. اگر برای گشودن حساب با تراکنش بالاست، به مدرک اضافه، مثل معرفی‌نامه یا آگهی تغییرات، نیاز دارید و استعلام فقط یک فیلتر اولیه است.

مقایسهٔ نام: جایی که بیشترین اشتباه می‌شود

مقایسهٔ دقیق رشته‌ای دو نام فارسی تقریباً همیشه شکست می‌خورد. دلیل‌ها آشنا هستند: حروف عربی و فارسی، نیم‌فاصله، فاصلهٔ اضافه، ترتیب نام و نام خانوادگی، و گاهی لقب یا پیشوند.

یک ترتیب ساده که معقول کار می‌کند:

1. هر دو رشته را به ی و ک فارسی تبدیل کنید و نیم‌فاصله و فاصلهٔ اضافه را برداشته و یکی کنید.
2. نام را به واژه‌ها بشکنید و مجموعهٔ واژه‌ها را مقایسه کنید، نه ترتیبشان را.
3. اگر همهٔ واژه‌های ورودی کاربر در نام ثبتی بود، «تطبیق قوی» بدهید.
4. اگر فقط نام خانوادگی و حرف اول نام می‌خواند، «تطبیق ضعیف» بدهید و به بازبینی بفرستید.
5. هرگز تطبیق ضعیف را رد خودکار نکنید.

یک نمونهٔ فرضی از منطق (فقط برای نشان‌دادن ایده، نه نسخهٔ آمادهٔ تولید):

```js const norm = (s) => s.replace(/\u064A/g, 'ی').replace(/\u0643/g, 'ک').replace(/‌/g, ' ') .replace(/\s+/g, ' ').trim();

function nameMatch(typed, registered) { const a = new Set(norm(typed).split(' ')); const b = new Set(norm(registered).split(' ')); const hit = [...a].filter((w) => b.has(w)).length; return hit === a.size ? 'strong' : hit >= 2 ? 'weak' : 'none'; } ```

به نظر من، پیچیده‌تر کردن این تابع (فاصلهٔ ویرایشی، آوانگاری) معمولاً ارزشش را ندارد. بیشتر اختلاف‌ها با همین یکدست‌سازی حل می‌شوند و بقیه را بهتر است انسان ببیند.

سمت‌ها را به قاعدهٔ محصول خودتان ترجمه کنید

فیلد سمت یک رشتهٔ آزاد است. «مدیرعامل»، «مدیر عامل» و «مدیرعامل و عضو هیئت‌مدیره» هر سه ممکن است دیده شوند. اگر قاعدهٔ شما «فقط مدیرعامل یا رئیس هیئت‌مدیره» است، بر اساس شمول واژه تصمیم بگیرید، نه تساوی کامل رشته.

یک جدول ساده برای شروع:

این جدول سلیقهٔ من است و به ریسک محصولتان بستگی دارد. نکتهٔ اصلی این است که قاعده را صریح بنویسید و در کد نگه دارید، نه در حافظهٔ تیم پشتیبانی.

دو حالت متفاوت «نتیجه نیست»

حالت اول: برای شناسه اطلاعاتی ثبت نشده. این پاسخ معتبر است و به کاربر می‌گویید «برای این شناسه اطلاعاتی نیافتیم؛ شناسه را بررسی کنید یا مدرک دیگری بفرستید».

حالت دوم: استعلام به هر دلیل فنی کامل نشد. این‌جا نباید به کاربر چیزی دربارهٔ شرکتش بگویید. فقط «چند دقیقهٔ دیگر دوباره تلاش می‌کنیم» و یک تلاش مجدد خودکار.

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

داده شخصی و نگه‌داری

نام و سمت اشخاص حقیقی داده‌ای شخصی است. سه توصیه:

• فقط همان فیلدهایی را ذخیره کنید که تصمیم بر آن‌ها استوار بود (مثلاً نتیجهٔ تطبیق، سمت و تاریخ استعلام).
• کل پاسخ خام را بی‌دلیل در لاگ عمومی ننویسید.
• برای پرونده‌های رد شده، مدت نگه‌داری کوتاه‌تری تعیین کنید.

نتیجهٔ استعلام یک عکس لحظه‌ای است. اگر پرونده‌ای ماه‌ها باز بماند، پیش از تصمیم نهایی دوباره استعلام بگیرید. ترکیب هیئت‌مدیره می‌تواند در این فاصله عوض شده باشد.

آنچه نباید از این روش انتظار داشت

این روش هویت فیزیکی کاربر را احراز نمی‌کند. اگر کسی نام مدیرعامل را بداند و در فرم بنویسد، تطبیق نام موفق می‌شود. برای اینکه بفهمید پشت صفحه واقعاً چه کسی نشسته، به احراز هویت جداگانه (مثلاً تطبیق کد ملی و موبایل یا مدرک زنده) نیاز دارید.

همچنین ثابت نمی‌کند شرکت فعال است یا بدهی ندارد. فقط ساختار مدیریتی ثبت‌شده را نشان می‌دهد. برای مشخصات خود شرکت، سرویس جداگانهٔ استعلام شرکت هست و در مستندات API تفکیک‌شان آمده است.

تست پیش از انتشار

پیش از اینکه تطبیق را روی کاربران واقعی روشن کنید، یک مجموعهٔ آزمون کوچک بسازید. بیست جفت نام را در نظر بگیرید که عمداً مشکل دارند: یکی با حرف عربی به‌جای فارسی، یکی با نیم‌فاصلهٔ جاافتاده، یکی با ترتیب جابه‌جا، یکی با یک واژهٔ اضافه مثل لقب، و چند نمونهٔ کاملاً نامرتبط. مطمئن شوید تابع شما نمونه‌های اول تا چهارم را «قوی» یا «ضعیف» و نمونه‌های نامرتبط را «هیچ» می‌گوید.

نکتهٔ مهم این است که مقدار آستانه‌ها را از روی همین نمونه‌ها بیاورید، نه از روی حدس. اگر بعداً در تولید دیدید پرونده‌ای اشتباه رد یا تأیید شده، آن جفت را به مجموعهٔ آزمون اضافه کنید. همین عادت ساده، در یک ماه تابع شما را از یک حدس به یک ابزار آزموده تبدیل می‌کند.

ردیابی تصمیم

برای هر تصمیم سه چیز ذخیره کنید: ورودی کاربر، نسخهٔ قاعده‌ای که اجرا شد و نتیجهٔ استعلام هیئت‌مدیره به‌همراه تاریخ آن. اگر بعداً کسی پرسید «چرا این پرونده تأیید شد؟» با این سه می‌توانید دقیق جواب بدهید، حتی اگر ترکیب هیئت‌مدیره در این فاصله عوض شده باشد.

پیشنهاد من

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