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

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

اگر مارکت‌پلیس، سامانهٔ تأمین یا هر محصولی می‌سازید که فروشندهٔ کوچک می‌پذیرد، استعلام اطلاعات صنف به شما سه چیز می‌دهد که استعلام شرکت نمی‌دهد. در ادامه می‌گویم چطور از آن‌ها یک جریان احراز می‌سازید.

چرا برای فروشندهٔ حقیقی استعلام شرکت کافی نیست

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

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

سه چیزی که باید بسنجید

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

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

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

یک جدول نگاشت فرضی

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

جریان پیشنهادی

1. کاربر شناسهٔ صنفی را وارد می‌کند (ده رقم، رشته).
2. شما استعلام می‌گیرید.
3. اگر پاسخ نبود: «شناسه یافت نشد، دوباره بررسی کنید» و امکان بارگذاری تصویر برای بررسی دستی.
4. اگر پاسخ بود: کد ملی را با کد ملی کاربر احرازشده مقایسه کنید.
5. تاریخ انقضا را با امروز بسنجید.
6. رسته را با دستهٔ کالاهایی که فروشنده انتخاب کرده بسنجید.
7. نتیجه را با تاریخ استعلام ذخیره کنید.

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

قاعدهٔ داده‌ی شخصی

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

بازبینی دوره‌ای

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

آنچه این روش به شما نمی‌دهد

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

همچنین جست‌وجو بر اساس نام یا نشانی ندارد. اگر فروشنده شناسه‌اش را نمی‌داند، این مسیر برای او باز نیست و باید مسیر جایگزین داشته باشید. و اگر فروشنده شرکت دارد، اینماد سایتش یک لایهٔ دیگر کنترل می‌دهد که جدا از جواز است.

یک خطای طراحی رایج

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

مثال فرضی: مارکت‌پلیس صنایع دستی

تصور کنید یک مارکت‌پلیس صنایع دستی فروشنده‌های کوچک می‌پذیرد. فروشنده‌ای شناسهٔ صنفی را وارد می‌کند. استعلام اطلاعات صنف نشان می‌دهد پروانه برای رستهٔ فروش پوشاک صادر شده، اما فروشنده در پلتفرم شما ظرف سفالی می‌گذارد. سیستم او را رد نمی‌کند؛ پرونده با دلیل «رسته با دستهٔ کالا نمی‌خواند» به بازبینی می‌رود. بازبین با فروشنده تماس می‌گیرد و معلوم می‌شود پروانهٔ دومی هم دارد که شناسه‌اش را هنوز وارد نکرده. پرونده تأیید می‌شود.

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

وقتی پاسخ «یافت نشد» است

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

چرا موبایل دارنده را جداگانه نگه ندارید

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

پیشنهاد من

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