چرا نشانی برگشتی از کد پستی با آدرس من فرق دارد؟

نشانی برگشتی از کد پستی با آدرسی که شما می‌نویسید فرق دارد، و بیشتر وقت‌ها هیچ‌کدام اشتباه نیستند؛ فقط دو نوع نوشتن متفاوتِ یک مکان‌اند. پیش از اینکه بگویید «سرویس غلط داده»، چهار چیز را بررسی کنید.

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

اول: خیابان اصلی و خیابان فرعی را با هم اشتباه نگیرید

پاسخ دو فیلد جدا برای خیابان دارد. در نمونه پاسخ، یکی «خیابان ۱۲ فروردین» است و دیگری «خیابان انقلاب اسلامی». این دو فرق دارند: یکی خیابانی است که در آن ایستاده‌اید و دیگری خیابان بزرگ‌تری که نشانی به آن تعلق دارد.

مردم در عمل نشانی را از آن طرف می‌گویند: «انقلاب، نبش ۱۲ فروردین». نتیجه این است که اگر شما فقط یکی از دو فیلد را در تطبیق به کار ببرید، نشانی «غلط» به نظر می‌رسد. پیش از هر مقایسه، هر دو را کنار هم بخوانید.

نکته عملی: هنگام مقایسه با متنی که کاربر نوشته، آن را تکه‌تکه نکنید. کلمهٔ اصلی خیابان‌ها (بی‌«خیابان» و «کوچه») را جدا کنید و ببینید کدام یک در متن کاربر هست.

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

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

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

سوم: فیلد خالی با خط تیره

بعضی فیلدها در نمونه پاسخ - هستند، مثل نام ساختمان و توضیحات. خط تیره یعنی «برای این نشانی ثبت نشده»، نه «نشانی ناقص است». طبقه هم در نمونه پاسخ -1 است، یعنی مقدار منفی هم دیده می‌شود؛ آن را «غلط» حساب نکنید و بی‌دلیل رد نکنید.

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

یک جدول کوتاه برای تصمیم:

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

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

پاسخ‌های ما فیلد source دارند که می‌گوید پاسخ تازه است یا از کش آمده و چه زمانی گرفته شده. اگر اختلاف شما پیش از یک تغییر شناخته‌شده در منطقه است، همین فیلد را ببینید.

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

در عمل: یک فرم که از اختلاف نمی‌ترسد

فرض کنید یک فروشگاه اینترنتی دارید. مشتری کد پستی می‌نویسد و نشانی دستی را هم پر می‌کند (چون فرم قدیمی است). اگر دو نشانی با هم نمی‌خوانند، دو راه دارید:

• رد کنید. ساده است، اما مشتری درست‌کار را عصبانی می‌کند.
• نشان بدهید و بپرسید. «نشانی ثبت‌شده برای این کد پستی این است. کدام را برای ارسال استفاده کنیم؟»

به نظر من دومی بهتر است، چون اختلاف بیشتر وقت‌ها نوشتاری است. با یک سؤال حل می‌شود و کاربر هم می‌فهمد که با نشانی‌اش مشکلی نیست.

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

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

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

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

یک روش برای مستندکردن اختلاف

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

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

سؤال‌هایی که پشتیبانی باید بپرسد

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

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

پیشنهاد من

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