استعلام چک صیادی پیش از پذیرش: چه چیزی را با برگه مقایسه کنیم؟

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

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

شش فیلدی که باید با برگه مقایسه شوند

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

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

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

در نمونهٔ پاسخ مستندات، تاریخ صدور به شکل 1370/1/1 آمده: ماه و روز بدون صفر ابتدایی. اگر کاربر روی برگه «۱۳۷۰/۰۱/۰۱» را تایپ کرده باشد و برنامه‌تان دو رشته را مستقیم مقایسه کند، همیشه ناهمخوان اعلام می‌شود، یعنی هر چک درست هم رد می‌شود.

پیش از مقایسه، هر دو تاریخ را به سه عدد صحیح تبدیل کنید و عددها را مقایسه کنید:

js const parts = (s) => s.replace(/[۰-۹]/g, d => '۰۱۲۳۴۵۶۷۸۹'.indexOf(d)) .split(/[/-]/).map(Number); // [سال، ماه، روز] const sameDate = (a, b) => parts(a).join() === parts(b).join();

این قطعه فقط ایده است؛ در محصول خودتان ورودی نامعتبر را هم مدیریت کنید.

سه پاسخی که نباید یکی شمرده شوند

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

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

خطای ورودی. شناسه ۱۶ رقم نیست یا ساختار دیگری دارد. استعلامی انجام نشده و هزینه‌ای کسر نمی‌شود؛ ورودی را درست کنید. اگر در این مورد گیر کرده‌اید، راهنمای خطاهای رایج استعلام چک صیادی کمک می‌کند.

فیلدهایی که باید با احتیاط خوانده شوند

تاریخ سررسید می‌تواند خالی برگردد. خالی بودن را به «امروز» یا «۱۳۰۰/۱/۱» تبدیل نکنید؛ در رابط کاربری همان «ثبت نشده» را نشان دهید.

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

نمونهٔ فراخوان و شکل پاسخ

فراخوان یک POST ساده است و کلید API را در هدر می‌فرستید:

bash curl -X POST 'https://<دامنه>/api/v1/sayad-check/' \ -H 'Authorization: Bearer melli_live_…' \ -H 'Content-Type: application/json' \ -d '{"sayadId": "1234567890123456"}'

پاسخ موفق، پاسخ سرویس را در data می‌گذارد و کنارش source می‌گوید نتیجه تازه است یا از کش آمده. این فیلد برای پذیرش چک مهم است: اگر stale درست باشد، یعنی سرویس مرجع در لحظه در دسترس نبوده و آخرین پاسخ معتبر برگردانده شده، با زمانش. در چنین حالتی تصمیم بزرگ را به همان زمان بسپارید یا چند دقیقه بعد دوباره استعلام بگیرید.

چه زمانی دوباره استعلام بگیریم

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

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

سه چیز را از این پاسخ نخواهید:

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

یک روال پیشنهادی برای تیم فروش

فرض کنید یک فروشگاه عمده‌فروشی چک صیادی مشتریانش را می‌پذیرد. روال ساده‌ای که پیشنهاد می‌کنم:

1. شناسه را از برگه بخوانید و استعلام بگیرید.
2. شش فیلد بالا را با برگه مقایسه کنید؛ نتیجه، «همه خواند» یا «یکی نخواند» است، بینابین ندارد.
3. اگر چک دست سوم است، زنجیره را هم بگیرید.
4. نتیجه را همراه تاریخ استعلام در پرونده نگه دارید، تا بعدها بدانید چه چیزی را در آن لحظه دیده‌اید.

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

پیشنهاد من

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

اگر این روال را خودکار می‌کنید، خود سرویس استعلام چک صیادی با یک فراخوان همین شش فیلد را می‌دهد.