چرا نام شرکت در فاکتور با نام ثبتی فرق دارد؟

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

این مقاله برای تیم‌هایی است که با استعلام اطلاعات شرکت نام ثبتی را می‌گیرند و می‌خواهند با نام اظهارشدهٔ مشتری بسنجند. شناسه ملی و تفاوتش با شماره ثبت را در راهنماهای جدا گفته‌ایم؛ اینجا فقط درباره نام حرف می‌زنیم.

نام در پاسخ استعلام چگونه می‌آید

در نمونهٔ پاسخ مستندات، نام و نوع شرکت دو فیلد جدا هستند: name برابر «راهکار نوین هیوا» است و company_type برابر «شرکت سهامی خاص». یعنی نوع شرکت داخل نام نیامده است.

همین یک جزئیات بخش بزرگی از اختلاف‌ها را توضیح می‌دهد. مشتری روی فاکتور می‌نویسد «شرکت راهکار نوین هیوا (سهامی خاص)» و شما name را با آن برابر می‌کنید. نابرابر است؛ ولی شرکت همان است.

نکتهٔ مهم: به نمونه تکیه نکنید. در پاسخ‌های واقعی نام را هم باید قبل از مقایسه خودتان بررسی کنید که پیشوند و پسوندی دارد یا نه. این مقاله فرض نمی‌کند هر ثبتی دقیقاً مثل نمونه است.

ریشهٔ اختلاف‌های معمول

۱. نوع شرکت. «شرکت»، «سهامی خاص»، «با مسئولیت محدود» و «سهامی عام» ممکن است در نوشتهٔ مشتری باشند و در name نباشند.

۲. یای و کاف عربی. نامی که از فایل قدیمی یا یک کیبورد خاص می‌آید، ممکن است به‌جای ی و ک فارسی، یای و کاف عربی (U+064A و U+0643) داشته باشد. چشم هر دو را یکی می‌خواند، رشته نه.

۳. نیم‌فاصله و فاصله. «راهکار نوین» و «راه‌کار نوین» و «راهکارنوین».

۴. ارقام. یک شرکت با عدد در نام («پارس ۲۰۰۰») ممکن است به لاتین یا فارسی نوشته شود.

۵. نام تجاری. برند فروشگاه یا سایت اغلب نام ثبتی شرکت نیست. «فروشگاه الف» ممکن است نام برند باشد و شرکت پشتش نام دیگری داشته باشد.

۶. کوتاه‌نویسی. مشتری «شرکت ایران ...» را «ایران ...» می‌نویسد، یا برعکس.

یک تابع مقایسهٔ ساده

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

```js const TYPE_WORDS = ['شرکت', 'سهامی خاص', 'سهامی عام', 'با مسئولیت محدود'];

function normalizeName(s) { let t = s .replace(/\u064A/g, '\u06CC') // ی عربی به فارسی .replace(/\u0643/g, '\u06A9') // ک عربی به فارسی .replace(/[‌\s\-()]+/g, ' ') .trim(); for (const w of TYPE_WORDS) t = t.replace(w, ''); return t.replace(/\s+/g, ' ').trim(); } ```

پس از نرمال‌سازی، به‌جای برابری دقیق، سه حالت تعریف کنید:

• یکی است: ادامه.
• یکی در دیگری است: بازبینی خفیف، مثلاً از کاربر بپرسید.
• هیچ ارتباطی نیست: بازبینی انسانی.

عددی برای «چقدر شبیه کافی است» نمی‌دهیم؛ آستانه را با نمونه‌های واقعی خودتان بسنجید.

چرا نام به‌تنهایی کافی نیست

اگر شناسه ملی درست است و نام کمی فرق دارد، شناسه را معیار بگیرید، نه نام. شناسه ملی در سراسر کشور یکتاست و دو شرکت همان شناسه را ندارند؛ نام ممکن است شبیه باشد. اگر اختلاف نام بزرگ بود (کاملاً متفاوت)، دو احتمال دارید: شناسه را غلط وارد کرده‌اند، یا شرکت دیگری را معرفی می‌کنند. هر دو دلیل کافی است که یک انسان نگاه کند.

یک سناریوی فرضی: مشتری شناسه ملی را درست می‌نویسد ولی نام شرکت دیگری را. پاسخ استعلام نام ثبتی را نشان می‌دهد. نام را از کاربر نپرسید و جایگزین نکنید؛ هر دو را نشان بدهید و بپرسید «منظورتان این شرکت است؟».

نکات اجرایی

درخواست از سمت سرور و با کلید در هدر است:

bash curl -X POST 'https://<دامنه-ما>/api/v1/company-inquiry/' \ -H 'Authorization: Bearer melli_live_…' \ -H 'Content-Type: application/json' \ -d '{"companyNationalId":"<شناسه-ملی-۱۱-رقمی>"}'

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

آنچه این استعلام نمی‌کند

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

نام نمایش‌داده‌شدهٔ مغازه یا سایت را از طریق استعلام شرکت نمی‌شود ثابت کرد. اگر سایت اینترنتی است، اعتبار سایت مسئله دیگری است.

یک نمونه از جدول بازبینی

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

بعد از این جدول، تابع نرمال‌سازی را با موردهای عجیب همان فهرست تقویت کنید.

نام در قرارداد و نام در پنل

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

این کار دو سود دارد: خطای تایپی کم می‌شود و نام فاکتور با سند ثبتی هم‌خوان می‌ماند. اگر مشتری نام دیگری لازم دارد، دلیلش را بپرسید و در رکورد بنویسید.

چند سؤال پیش از نوشتن قاعده

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

در یک نگاه

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